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

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 13:45:58 +0200

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 [email-masked] 
> 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?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 13:45:58 +0200

Hi Bernard,

BR, Julian

--- snip ---

JR: spelling.

5.2.1.1.  Create

    Name:  max-resource-size

    Apply to:  POST

    Use with:  403 Forbidden

    Example:

       Schedule-Reply: F

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 13:45:58 +0200

Hi Bernard,

BR, Julian

--- snip ---

JR: spelling.

5.2.1.1.  Create

    Name:  max-resource-size

    Apply to:  POST

    Use with:  403 Forbidden

    Example:

       Schedule-Reply: F

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 13:45:58 +0200

Hi Bernard,

BR, Julian

--- snip ---

JR: spelling.

5.2.1.1.  Create

    Name:  max-resource-size

    Apply to:  POST

    Use with:  403 Forbidden

    Example:

       Schedule-Reply: F

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 22:12:22 +0200

> can not be used for checking.

Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...".

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 22:12:22 +0200

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 22:12:22 +0200

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 22:12:22 +0200

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jul 2009 14:43:16 +0200

> Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...".

Expanding on that...:

The spec currently introduces a new type of etag, the "schedule-tag", 
exposed as a live WebDAV property, and a new HTTP response header, plus 
a new conditional HTTP request header.

WebDAV (RFC 4918) however already supports "state tokens" in the "If" 
header; right now only lock tokens are used, but there is no reason why 
a protocol wouldn't be able to introduce new state tokens, and allow 
them to be checked using the "If" header. -- That would at least avoid 
introducing a new conditional request header.

That being said, it would be nice to get rid of the new state tokens ( 
schedule tags altogether.

I do understand the problem with many clients updating the attendee 
information simultaneously.

Two thoughts on this:

1) In general, issues like that can be avoided by enhancing the 
granularity of the resource that needs to be updated. For instance, the 
status for each attendee could be modeled as a separate resource, that 
could then respond to GET/PUT/DELETE. (I guess the server could 
advertise its URL as a parameter on the ATTENDEE).

2) It may also be possible to use PATCH for updating the attendee 
status; we would just need to define a simple payload format which can 
guard the client from unintentionally changing the status on an event 
that just changed (my understanding is that PATCH is likely to be 
finished in time for this spec).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jul 2009 14:43:16 +0200

Expanding on that...:

Two thoughts on this:

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jul 2009 14:43:16 +0200

Expanding on that...:

Two thoughts on this:

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Jul 2009 14:43:16 +0200

Expanding on that...:

Two thoughts on this:

Best regards, Julian

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 14 Jul 2009 15:33:17 -0400

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:
>> 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 
>> [email-masked] 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.
>
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>.
> ...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.
> JR: last sentence just seems to rephrase the previous one. So maybe 
> say "Thus, ..."
Will add "Thus," and change MAY to "can".
>    scheduling transactons are refered to as scheduling object resources.
s/transactons are refered/transactions are referred/
> anyway :-) (there are more occurrences of this language later on).
s/MAY/can/
> JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"?
Yes.
> 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.
> 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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 14 Jul 2009 15:33:17 -0400

Hi Julian,

Cheers,
Bernard

s/MAY/can/
Yes.

Thanks,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 14 Jul 2009 15:33:17 -0400

Hi Julian,

Cheers,
Bernard

s/MAY/can/
Yes.

Thanks,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 14 Jul 2009 15:33:17 -0400

Hi Julian,

Cheers,
Bernard

s/MAY/can/
Yes.

Thanks,
Bernard

---

From: Helge Hess <[email-masked]>
Date: Sun, 19 Jul 2009 15:41:30 +0200

Hi,

small request. It would be good if the example B.5. (Organizer  
Requesting Busy Time Information) would include an ATTENDEE which  
cannot be resolved by the server.

Thanks,
   Helge

---

From: Helge Hess <[email-masked]>
Date: Sun, 19 Jul 2009 15:41:30 +0200

Hi,

Thanks,
   Helge

---

From: Helge Hess <[email-masked]>
Date: Sun, 19 Jul 2009 16:18:03 +0200

Hi,

the 'schedule-default-calendar-URL' WebDAV property is currently  
defined on the Outbox. Would it be possible to have that on the  
principal resource instead?
This would make it a bit easier for us with Outlook, which also has a  
concept of a 'primary calendar'.

Thanks,
   Helge
-- 
http://zideone.com/

---

From: Helge Hess <[email-masked]>
Date: Sun, 19 Jul 2009 16:18:03 +0200

Hi,

Thanks,
   Helge