Re: Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt]

Bernard Desruisseaux wrote:
> Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF 
> last week. See Internet-Draft announcement below.
> 
> Before requesting the IESG to consider this Internet-Draft as a Proposed 
> Standard, we would like to get as much feedback as possible from the 
> participants of the "caldav" mailing list as well as from the members of 
> the WebDAV and Calsify Working Groups.
> 
> Please review the document and send your comments to the caldav@ietf.org 
> mailing list by July 7th, 2009.
> 
> We would like to submit draft -08 before July 13, 2009, i.e., the final 
> submission cut-off for the 75th IETF in Stockholm, Sweden.
> ...
Hi Bernard,
I'm sorry that I'm late with my feedback (attached below). Most are nits 
of editorial nature. Also, I have only read the spec from an HTTP/WebDAV 
point of view, as I'm no expert on calendaring at all.
There is a single non-editorial issue I found, and that is the 
introduction of the scheduling tag, with associated HTTP headers. I 
think it would be good to discuss this in more detail.
BR, Julian
--- snip ---
1.5. XML Namespaces and Processing
 Definitions of XML elements in this document use XML element type
 declarations (as found in XML Document Type Declarations), described
 in Section 3.2 of [W3C.REC-xml-20081126].
JR: should this be a section reference?
 The XML declarations used in this document do not include namespace
 information. Thus, implementers must not use these declarations as
 the only way to create valid CalDAV properties or to validate CalDAV
 XML element type. Some of the declarations refer to XML elements
JR: I realize this sentence is borrowed from 4791. Does anybody recall what
the "...create valid CalDAV properties..." refers to? What does the DTD have
to do with that?
4.1. Scheduling Outbox Collection
 While there is currently no defined use for child resources in a
 scheduling Outbox collection, a scheduling Outbox collection MAY
 contain child resources.
JR: may say "...MAY contain child resources, whose semantics are 
undefined for now..."?
...if this is correct, is it planned to add semantics later? How?
4.2. Scheduling Inbox Collection
 Scheduling Inbox collections MUST only contain calendar object
 resources that obey the restrictions specified in iTIP
 [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox
 collections MUST NOT contain any types of collection resources.
 Restrictions defined in Section 4.1 of CalDAV "calendar-access"
 [RFC4791] on calendar object resources contained in calendar
 collections (e.g., "UID" uniqueness) don't apply to calendar object
 resources contained in a scheduling Inbox collection. Multiple
 calendar object resources contained in a scheduling Inbox collection
 MAY have the same "UID" property value (i.e., multiple scheduling
 messages for the same calendar component).
JR: last sentence just seems to rephrase the previous one. So maybe say 
"Thus, ..."
and remove the RFC2119 keyword.
5.1. Identifying Scheduling Object Resources
 Calendar object resources on which the server performs automatic
 scheduling transactons are refered to as scheduling object resources.
JR: spelling.
5.2.1.1. Create
 The attempt to deliver the scheduling message will either succeed or
 fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
 iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
 iCalendar property in the scheduling object resource being created,
 and set its value as described in Section 9.2. This will result in
 the created calendar object resource differing from the calendar data
 sent in the HTTP request. As a result clients MAY reload the
 calendar data from the server as soon as it is created on the server
 in order to update to the new server generated state information.
The "MAY" doesn't seem to be right here. This is not an interop requirement
but simply a statement of fact. They "MAY" reload whenever they want
anyway :-) (there are more occurrences of this language later on).
7.2.7. CALDAV:max-resource-size Precondition
 Name: max-resource-size
 Namespace: urn:ietf:params:xml:ns:caldav
 Apply to: POST
 Use with: 403 Forbidden
 Purpose: (precondition) -- The resource submitted in the POST
 request MUST have an octet size less than or equal to the value of
JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"?
8. Conditional Requests on Scheduling Object Resources
 In order to do that, this specification introduces a new WebDAV
 resource property CALDAV:schedule-tag with a corresponding response
 header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
 header to allow client changes to be appropriately merged with server
 changes in the case where the changes on the server were the result
 of an "inconsequential" scheduling message update. An
 "inconsequential" scheduling message is one which simply updates the
 status information of Attendees due to a reply from an Attendee.
JR: that sounds really heavy-weight; I think it would be good to discuss
this scenario over on the HTTPbis working group's mailing list. Even if new
state tokens need to be added it is not totally clear why the RFC4918
can not be used for checking.
11.1. Schedule-Reply Request Header
 Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")
 Example:
 Schedule-Reply: F
 When an Attendee executes an HTTP DELETE request on a scheduling
 object resource, and the Schedule-Reply header is not present, or
 present and set to the value "T", the server MUST send an appropriate
 reply scheduling message with the Attendee's "PARTSTAT" iCalendar
 property parameter value set to "DECLINED" as part of its normal
 automatic scheduling transaction processing.
JR: is this header really really needed? Would it be possible to pass
that information in the request body instead?

Received on Monday, 13 July 2009 11:46:45 UTC

AltStyle によって変換されたページ (->オリジナル) /