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

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.

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

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