Scheduling Extensions to CalDAV
draft-desruisseaux-caldav-sched-12

[Ballot comment]
This is a huge document and it did make me worry that so many pages are needed to describe an *extension*. But I didn't find anything that was superfluous or wordy, so I have no issue with its publication.

---

I did expect to see a short piece of text about how implementations of this spec would interact with deployed 4791 implementations. Not withstanding that this document updates 4791 (such that new 4791 implementations are presumably expected to include support for this document), we do have to worry about the deployed base.

This would probably not take many words.

[Ballot comment]
Generally: I think the 2119 language could use a good scrub. I think you use it in places where there is no real option, or there is no real interoperability implication. Please review.

Section 3.2.8:

  Servers MUST reset the "PARTSTAT" property parameter value of all
  "ATTENDEE" properties, except the one that corresponds to the
  Organizer, to "NEEDS-ACTION" when the Organizer reschedules an event.

Don't you mean for all "ATTENDEE" properties *on each affected component*? I wouldn't have complained about this except for the MUST; if it's a requirement, you've got to be clear. If the change is for a recurrence instance that does not include that attendee, PARTSTAT shouldn't be reset, correct? (See section 3.2.6.)

[Ballot comment]

- Thanks for handling Klaas Wierenga's good secdir review so well and
quickly!

- 3.2.2.1 says the server "MUST allow" but later says how the server
can return errors if e.g. the client hasn't permission for the change
requested. It might be better to say at the top that "The server MUST
be able to allow Attendees to:"

- 3.2.3 says its about HTTP methods, but uses webdav methods as well
(e.g. COPY, MOVE) so maybe a reference to rfc 4918 would be useful at
the start here?  (Or wherever is best to go for those.)

- I guess this is maybe not too likely but just to check. If a client
guesses a UID to try find out who's up to what, 3.2.4.1 says the
server SHOULD return the URL if there is a collision. I wondered
whether that URL might expose some information, in which case the
question is whether such UIDs are easily guessed or not.  If such
UIDs can be guessable, then maybe say something to the effect that
the server might want to not return URLs that might expose details of
the events (if such exist) and might want to return an innocuous
error. Or better might be to RECOMMNEND that the UIDs (and URLs as
well maybe) used for this be hard to guess. Note that the attack here
(if it exists) could come from an authenticated client as well as
from the Internet.  The point here is to check that the UIDs don't
allow me to get at information for which I'd get only 403 if I sent a
request to the URL. (I guess its a separate question as to whether
sending 403 gives away something that a 404 doesn't, but if so,
that'd be for another day and draft.)

- In 7.x sections you say clients MUST NOT include these parameters.
Is there a need to say that server MUST NOT accept messages from
(bad) clients that do in fact contain these parameters? Might be easy
enough to get wrong if the server developer didn't pay any attention
to what the client developer might get or do wrong.

[Ballot discuss]
This is a well written document, thanks for writing it. I have a small problem with the ABNF, however, please see below for further details and correct as you see necessary. Perhaps this video also illustrates my point:

http://www.youtube.com/watch?feature=player_embedded&v=LbK-g8tKnoc

[Ballot comment]
Section 7.1 and 7.2 ABNF definitions should point out that "x-name" and
"iana-token" definitions are from RF 5545, just as Section 7.3 does for
other definitions. It took a while for me to search where this definitions are,
particularly when the RFC series has multiple different definitions for
these two productions.

Updated PROTO writeup.

###

Shepherd write-up for: draft-desruisseaux-caldav-sched-11
Intended status: Proposed Standard

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?
     
        Mike Douglass  is
        shepherding this document. The document is ready for forwarding to
        the IESG.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?
     
        This document has been discussed and reviewed on the CalDAV
        () mailing list. The original draft
        was developed in 2006, with a substantial re-working in 2007.
        Experienced calendar/CalDAV developers have been involved in its
        development, and new implementors have appeared over time too. There
        are already many deployed implementations of this protocol, with
        feedback from those deployments having been incorporated into the
        specification. The specification has been the subject of regular
        interoperability tests at Calendaring and Scheduling Consortium
        events.

        A Security Directorate review has been carried out and issues
        addressed in the -11 draft. An Application Directorate review has
        been carried out and issues addressed for the next draft update.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?
       
        No concerns.
       
  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.
       
        No concerns.
       
  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

        This document was originally published in 2006. A major revision to
        the protocol took place in 2007 when it was switched to use an
        "implicit" scheduling model based on implementation experience of
        the early drafts. Since then the "implicit" model has been refined
        based mostly on deployment and interoperability testing experience.
        It has been the subject of much discussion and testing at the
        Calendaring & Scheduling Consortium in addition to the IETF mailing
        list. There are already many deployed implementations of this
        protocol (many documented here
        http://caldav.calconnect.org/implementations.html), with feedback
        from those deployments having been incorporated into the
        specification, and the community is behind this specification.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)
       
        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

        ID nits were checked and passed subject to a normative downref (see
        below).

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].
       
        Normative and informative reference sections exist. There is a
        normative reference to an Informational RFC: RFC 2818. A downref
        waiver is requested for this. A downref was already granted for RFC
        2818 in the base CalDAV specification RFC 4791, as per
       
        and the usage in this specification is the same - namely a
        requirement to support HTTP with TLS.
   
  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?
       
        IANA considerations exists. There are a set of message header field
        registrations as per RFC 3864. There are a set of iCalendar object
        registrations as per RFC 5545. No new registries are created. Note
        that both authors of this specification are the expert reviewers for
        the iCalendar registry. Therefore the IESG needs to appoint someone
        else to review the iCalendar registrations.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?
       
        Yes.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
       
    Technical Summary
        Scheduling is a core function of a calendaring system and this
        extension defines the process by which CalDAV clients and servers
        can use iCalendar (RFC 5545) and iTIP (RFC 5546) to accomplish that
        in a manner that ensures data consistency between organizer and
        attendee views of a scheduled event.
       
    Working Group Summary
        Discussion has taken place on the CalDAV mailing list over a long
        period of time as the document has evolved. There has been an
        "informal" last call on the document. In addition, there are now
        several implementations of the protocol in various client/server
        CalDAV products. Further discussions and interoperability testing
        has occurred in the Calendaring and Scheduling Consortium.
       
    Document Quality   
        This document has been discussed and reviewed on the CalDAV
        () mailing list. The original draft
        was developed in 2006, with a substantial re-working in 2007.
        Experienced calendar/CalDAV developers have been involved in its
        development, and new implementors have appeared over time too. There
        are already many deployed implementations of this protocol (many
        documented here http://caldav.calconnect.org/implementations.html),
        with feedback from those deployments having been incorporated into
        the specification. The specification has been the subject of regular
        interoperability tests at Calendaring and Scheduling Consortium
        events.


###

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (CalDAV Scheduling Extensions to WebDAV) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'CalDAV Scheduling Extensions to WebDAV'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines extensions to the CalDAV "calendar-access"
  feature to specify a standard way of performing scheduling
  transactions with iCalendar-based calendar components.  This document
  defines the "calendar-auto-schedule" feature of CalDAV.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-desruisseaux-caldav-sched/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-desruisseaux-caldav-sched/


No IPR declarations have been submitted directly on this I-D.

The proto writeup follows.

###

Shepherd write-up for: draft-desruisseaux-caldav-sched-10
Intended status: Proposed Standard

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?
     
        Mike Douglass  is
        shepherding this document. The document is ready for forwarding to
        the IESG.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?
     
        This document has been discussed and reviewed on the CalDAV
        () mailing list. The original draft
        was developed in 2006, with a substantial re-working in 2007.
        Experienced calendar/CalDAV developers have been involved in its
        development, and new implementors have appeared over time too. There
        are already many deployed implementations of this protocol, with
        feedback from those deployments having been incorporated into the
        specification. The specification has been the subject of regular
        interoperability tests at Calendaring and Scheduling Consortium
        events.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?
       
        No concerns.
       
  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.
       
        No concerns.
       
  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

        This document was originally published in 2006. A major revision to
        the protocol took place in 2007 when it was switched to use an
        "implicit" scheduling model based on implementation experience of
        the early drafts. Since then the "implicit" model has been refined
        based mostly on deployment and interoperability testing experience.
        It has been the subject of much discussion and testing at the
        Calendaring & Scheduling Consortium in addition to the IETF mailing
        list. There are already many deployed implementations of this
        protocol (many documented here
        http://caldav.calconnect.org/implementations.html), with feedback
        from those deployments having been incorporated into the
        specification, and the community is behind this specification.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)
       
        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

        ID nits were checked and passed subject to a normative downref (see
        below).

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].
       
        Normative and informative reference sections exist. There is a
        normative reference to an Informational RFC: RFC 2818. A downref
        waiver is requested for this. A downref was already granted for RFC
        2818 in the base CalDAV specification RFC 4791, as per
       
        and the usage in this specification is the same - namely a
        requirement to support HTTP with TLS.
   
  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?
       
        IANA considerations exists. There are a set of message header field
        registrations as per RFC 3864. There are a set of iCalendar object
        registrations as per RFC 5545. No new registries are created. Note
        that both authors of this specification are the expert reviewers for
        the iCalendar registry. Therefore the IESG needs to appoint someone
        else to review the iCalendar registrations.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?
       
        Yes.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
       
    Technical Summary
        Scheduling is a core function of a calendaring system and this
        extension defines the process by which CalDAV clients and servers
        can use iCalendar (RFC 5545) and iTIP (RFC 5546) to accomplish that
        in a manner that ensures data consistency between organizer and
        attendee views of a scheduled event.
       
    Working Group Summary
        Discussion has taken place on the CalDAV mailing list over a long
        period of time as the document has evolved. There has been an
        "informal" last call on the document. In addition, there are now
        several implementations of the protocol in various client/server
        CalDAV products. Further discussions and interoperability testing
        has occurred in the Calendaring and Scheduling Consortium.
       
    Document Quality   
        This document has been discussed and reviewed on the CalDAV
        () mailing list. The original draft
        was developed in 2006, with a substantial re-working in 2007.
        Experienced calendar/CalDAV developers have been involved in its
        development, and new implementors have appeared over time too. There
        are already many deployed implementations of this protocol (many
        documented here http://caldav.calconnect.org/implementations.html),
        with feedback from those deployments having been incorporated into
        the specification. The specification has been the subject of regular
        interoperability tests at Calendaring and Scheduling Consortium
        events.

###

State Change Notice email list has been changed to cyrus@daboo.name, bernard.desruisseaux@oracle.com, douglm@rpi.edu, draft-desruisseaux-caldav-sched@tools.ietf.org, julian.reschke@greenbytes.de, lisa.dusseault@gmail.com from cyrus@daboo.name, bernard.desruisseaux@oracle.com, julian.reschke@greenbytes.de, draft-desruisseaux-caldav-sched@tools.ietf.org, julian.reschke@greenbytes.de, lisa.dusseault@gmail.com

State Change Notice email list has been changed to cyrus@daboo.name, bernard.desruisseaux@oracle.com, julian.reschke@greenbytes.de, draft-desruisseaux-caldav-sched@tools.ietf.org, julian.reschke@greenbytes.de, lisa.dusseault@gmail.com from cyrus@daboo.name, bernard.desruisseaux@oracle.com, draft-desruisseaux-caldav-sched@tools.ietf.org, julian.reschke@greenbytes.de, lisa.dusseault@gmail.com

State Change Notice email list have been change to cyrus@daboo.name, bernard.desruisseaux@oracle.com, draft-desruisseaux-caldav-sched@tools.ietf.org, julian.reschke@greenbytes.de, lisa.dusseault@gmail.com from cyrus@daboo.name, bernard.desruisseaux@oracle.com, draft-desruisseaux-caldav-sched@tools.ietf.org, julian.reschke@greenbytes.de