Scheduling Extensions to CalDAV
RFC 6638

Note: This ballot was opened for revision 11 and is now closed.

(Jari Arkko) Discuss

Discuss (2012-03-11 for -11)
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:
Comment (2012-03-11 for -11)
No email
send info
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.

Barry Leiba Yes

(Peter Saint-Andre) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-03-15 for -11)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2012-03-11 for -11)
No email
send info
- Thanks for handling Klaas Wierenga's good secdir review so well and

- 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, 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.

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2012-03-14 for -11)
No email
send info
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.)

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection