I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).


Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-desruisseaux-caldav-sched-11
Title: CalDAV Scheduling Extensions to WebDAV
Reviewer: Eliot Lear
Review Date: 8 Mar. 2012
IESG Telechat Date: 15 Mar 2012

Summary:

This is a marked improvement from the previous version, represents YET
ANOTHER very valuable contribution from these two authors, and is nearly
ready for publication.  I would suggest one more respin.  I believe this
could happen, however, AFTER the IESG discussion.

Major Issues:

A question: can the new status codes defined in this specification leak
to non-participating implementations in Reply operations?


Minor Issues:

In general the document suffers from a lack of conciseness.  What
follows are some of the more glaring examples.

In Section 1, 2nd paragraph, There is no need to describe so early what
functions aren't covered.  The way this is traditionally handled is to
have a "Future Work" section.  That can be done in the intro or it can
even be put after examples.  I prefer the latter, especially if you mean
for the text to be non-normative.  If it is meant to be normative, be
explicit about it.

Similarly, in the 4th paragraph, same section, it is sufficient to say
(above) that this mechanism works compatibly with iMIP. You're using a
double negative.  And this problem recurs in the same paragraph.  You
should consider a search on the word "not".

§1, pg 6:
>    In iTIP-based scheduling, there is an event "Organizer" whose role is
>    to schedule an event between one or more "Attendees", and this is
>    done by sending out invitations and handling responses from each
>    Attendee.  Often times an Organizer will do a "freebusy" lookup to
>    check on Attendees' availability (free-time).

This document needn't and shouldn't repeat or review iTIP.  Suggest remove.

>    Servers supporting this specification advertise their capabilities
>    and provides new collections for scheduling operations as described
>    in Section 2.

This is mundane and not needed in § 1.  Suggest you cut it.

§1, ppg 6-7:

>    Scheduling works by having the client store iCalendar data with
>    appropriate scheduling properties included ("ORGANIZER" and
>    "ATTENDEE" iCalendar properties).  This is called a "Scheduling
>    Operation" and fully described in Section 3.  The server detects that
>    the data represents a scheduling operation (as per Section 3.1) and
>    identifies the operation as one initiated by the Organizer or
>    Attendee.  Processing of the scheduling operation, then depends on
>    who is initiating the scheduling operation (as per Section 3.2.1 or
>    Section 3.2.2 respectively).  In each case, one of three scheduling
>    operations can take place: "create", "modify" or "remove".  Which
>    operation occurs is based on the HTTP method used for the request, as
>    well as a comparison between any existing iCalendar data and any new
>    iCalendar data in the request (as per Section 3.2.3).

Let's be more clear about about the theory of operation specified in
this document.  Suggest reword along the following lines:

In order to automate the process of scheduling, we define the term
"scheduling operation" that consists of a client storing an iCal VEVENT
in a CALDAV store and then the server taking specific actions in
response.  In each case... (and lop off "as per..").

Also add one sentence here about atomicity (or lack thereof) of the
operations.


§1, pg. 7:
>    Control over who is allowed to send scheduling messages, or from whom
>    scheduling messages will be received or freebusy results returned to,
>    is controlled via a set of access control privileges dedicated to the
>    various scheduling operations that can occur as per Section 6.

Suggest active tense reword as follows:
> Section 6 describes access authorization mechanisms for the various
> scheduling operations that this memo specifies.
§1.1, ppg 7-8:

No need to restate definitions from other documents– unless you see a
difference in the meaning of the term amongst documents.  In particular,
I see that you chose to reference RFC-3283 instead of RFC-5546 for
Calendar User.  3283 would be a downref if you referenced it
normatively.  The definition should be normative.  You want 5546.

Also see nit on this.

§1.3 pg 9:

I've asked Mark Nottingham for an additional set of eyes on this
section.  I have one immediate comment and question:

>    This document inherits, and sometimes extends, DTD productions from
>    Section 14 of [RFC4918].

I would reword- "This document inherits and extends DTD productions..."

If so, should this specification update RFC4918 in rfc-index.txt?

§2.1, pg 10, and similar text in §2.2, pg 11:

>    The following WebDAV properties specified in CalDAV "calendar-access"
>    [RFC4791] MAY also be defined on scheduling...

Do you mean "*Only* the following WebDAV..."?  If not, why state these
properties?

§2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and
similar:

>    PROPFIND behavior:  This property SHOULD NOT be returned by a
>       PROPFIND allprop request (as defined in Section 14.2 of
>       [RFC4918]).

Why SHOULD NOT and not MUST NOT?  How should the client interpret the
information, if returned?

§3.2.1.1, pg 18:

>    When a scheduling object resource is created by the Organizer, the
>    server will inspect each "ATTENDEE" property to determine if a
>    scheduling message ought to be delivered to this Attendee according
>    to the value of the "SCHEDULE-AGENT" property parameter (see
>    Section 7.1) as described in the table below:

Please use normative language and active tense.  Suggest rewording as
follows:

> When the Organizer creates a scheduling object resource, the server SHALL
> inspect each "ATTENDEE" property to determine whether to send a scheduling
> message.  Table XXX below indicates the appropriate action, based on
> the value
> of the "SCHEDULE-AGENT" property.

§3.2.1.1 AND in §3.2.1.2 and §3.2.1.3:

Why are you treating authorization differently between create & modify
operations and the remove operation?

Cannot the text in §3.2.1.1 and §3.2.1.2 simply be moved into the
chapeau (e.g., 3.2.1)?


Also see nit below on tables.



§3.2.1.2, pg 19 has similar, but more involved issues to §3.2.1.1:

>    When a scheduling object resource is modified by the Organizer, the
>    server will inspect each "ATTENDEE" property in the new calendar data
>    to determine which ones have the "SCHEDULE-AGENT" iCalendar property
>    parameter.  It will then need to compare this with the "ATTENDEE"
>    properties in the existing calendar object resource that is being
>    modified.
>    For each Attendee in the old and new calendar data on a per-instance
>    basis, and taking into account the addition or removal of Attendees,
>    the server will determine whether to deliver a scheduling message to
>    the Attendee.  The following table determines whether the server
>    needs to deliver a scheduling message, and if so which iTIP
>    scheduling method to use.  The values "SERVER", "CLIENT", and "NONE"
>    in the top and left titles of the table refer to the "SCHEDULE-AGENT"
>    parameter value of the "ATTENDEE" property, and the values "<Absent>"
>    and "<Removed>" are used to cover the cases where the "ATTENDEE"
>    property is not present (Old) or is being removed (New).


So.. active tense again, same sort of idea:

> When the Organizer modifies a scheduling object resource, the server SHALL
> inspect each "ATTENDEE" property in both the original and modified
> event instance
> to determine whether to send a scheduling message.  Table XXX below
> indicates the
> appropriate action, based on the value of the "SCHEDULE-AGENT" property.
> The values "SERVER", "CLIENT", and "NONE" in the top and left headings
> refer to the "SCHEDULE-AGENT"  parameter value of the "ATTENDEE" property.
> The the values "<Absent>"  and "<Removed>" are used to cover the cases
> where the
>  "ATTENDEE" property is not present (Old) or is being removed (New).

The use of the word ATTENDEE in the upper left-hand corner of the table
is confusing, and I would remove it.  I might also change the headings
to read "Original" (going down)" and "Modified".  This allows for
consistency of language.


§3.2.1.3, Rinse and repeat this exercise for "Remove":


>    When a scheduling object resource is removed by the Organizer, the
>    server will inspect each "ATTENDEE" property in the scheduling object
>    resource being removed to determine which ones have the "SCHEDULE-
>    AGENT" iCalendar property parameter.
>
>    For each Attendee the server will determine whether to attempt to
>    deliver a scheduling message into the Attendee's scheduling Inbox
>    collection, based on the table below:

So...

> When an Organizer removes a scheduling object resource, the server SHALL
> inspect each "ATTENDEE" property in the scheduling object resource being
> removed, and act based on the value of the "SCHEDULE-AGENT" property
> value,
> according to Table XXX below.

§3.2.2.3, pg 23:

>    If the Attendee adds an "EXDATE" property value to effectively remove
>    a recurrence instance, the server MUST deliver an iTIP "REPLY"
>    scheduling message to the Organizer to indicate that the Attendee has
>    declined the instance.

EXDATE isn't the only way an Attendee can decline. a specific event,
right?  Is this the only operation in which a server MUST act?  Why call
this one out?

§3.2.3.2, pg 25, in the COPY table, and 3.2.3.3, pg 26, the MOVE table" :

Remove (1) and replace with "Same as PUT in Table XXX"

Also, move DELETE above MOVE (removes forward reference) and then remove
(2) and replace with "Same as DELETE")

In all of these sections change to both active tense and normative
language.  So for instance:

Old:
>  When a MOVE method request is received, the server will execute
New:
> When the server receives a MOVE request, it SHALL execute
§3.2.9, pg 32:

>    The 1.xx "REQUEST-STATUS" codes are new.  This specification modifies
>    item (2) of Section 3.6 of [RFC5546] by adding the following
>    restriction:
>

Should this memo indicate that it updates RFC-5546?


§3.2.10.1, §3.2.10.1, pg 34:

Change "Clients can" to "Clients MAY"

Nits:

§1, pg. 6:

> This is called a "Scheduling
>    Operation" and fully described in Section 3
Missing verb "is".

Throughout:

Calendar User is not capitalized consistently.

Throughout:

Tables should be numbered for reference.