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

Hi Julian,

After our offline discussion here's a summary of the changes we will do 
(see comments inline below)

Thanks a lot for your review!

Cheers,
Bernard

Julian Reschke wrote:
> 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?
We will modify Section 1.5 to use the same text as currently specified 
in Section 2 of vCard Extensions to WebDAV (CardDAV) 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-07#section-2>.
>
>
> 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?
We will change the text to specify that the use of child resources is 
reserved for future revisions or extensions of this specifications.
>
>
> 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.
Will add "Thus," and change MAY to "can".
>
> 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.
s/transactons are refered/transactions are referred/
>
>
> 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).
s/MAY/can/
>
>
>
>
> 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"?
Yes.
>
>
>
> 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.

We will modify the text to make it clear that If-Schedule-Tag-Match is 
more than a conditional header, i.e., the server is required to resolve 
conflicts when this request header is specified.
>
>
>
> 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?

We would like to avoid defining a new request body just for that 
purpose.  As discussed, this request header can also be specified on the 
MOVE method.  BTW, we will clarify the text to specify that this request 
header applies to any "removal" operation, i.e., DELETE or  MOVE request 
directly targeted at a resource or targeted at any parent of a resource 
(e.g., DELETE on calendar collection).

Thanks,
Bernard