Scheduling Extensions to CalDAV
RFC 6638
Discuss
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
(Jari Arkko; former steering group member) 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
(Barry Leiba; former steering group member) Yes
(Peter Saint-Andre; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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.)
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection