Re: [Ietf-caldav] comments on -02

[Lisa Dusseault <[e-mail]>]

Responses to these comments inline...

On Sep 29, 2004, at 9:41 AM, Dan Winship wrote:
>> 4.2  Recurrence and the Data Model
>
> How/where are "detached" instances of a recurrence represented? Eg, if 
> I
> change the SUMMARY of one instance of a meeting, does that require
> creating a new resource (with the same UID as an existing resource)?

My intent was that would create a new WebDAV resource with the same UID 
as an existing resource. Anybody else have other suggestions?

>
>> 4.3  CalDAV and timezones
>
> This feels like it presupposes a certain calsify outcome...

It supposes that either iCalendar will keep VTIMEZONES in recurring 
VEVENTS, or that even if it does change CalDAV servers will have to 
deal with RFC2445 compliant VEVENTS.  If calsify makes a bunch of 
changes we'll certainly have to rewrite this and other sections but 
it's too early to do that now.

>
>> 4.4  Scheduling, Fanout and the Data model
>
>> The Inbox contains inbound iTIP messages long after they are
>> handled/seen by the user
>
> OK. How long?

How about this language, later on after the overview material?

"Servers SHOULD NOT delete messages before or after
     a client has retrieved the messages in the inbox; instead the 
server SHOULD
     leave Inbox cleanup to the client.  A server MAY apply a quota to 
the iTIP
     Inbox (limiting the number of messages, the total size, or some 
other
     measurable) and MAY bounce incoming messages if the iTIP inbox is 
full
     or some other repository or account problem has occurred."

>
>> CalDAV defines an iTIP Outbox collection...
>
> In email clients and real life, an outbox/"out box" is for things that
> are on their way out. The CalDAV Outbox stores things that have
> *already* gone out. Seems weird, but I don't know if this is going to
> annoy anyone but me. :)

I know, we realized this after putting that wording in a bunch of 
places, and haven't resolved the wording because we may still be 
debating the purpose.  If we in fact use it to store things that have 
already gone out we should rename it to "sent" or something.

Any input on the purpose of the iTIP "outbox" ? Is it useful to have a 
collection of sent invitations?

>
>> Two users coordinating scheduling with one calendar (e.g.  a calendar
>> user and her assistant) can see what scheduling messages the other
>> user has sent.
>
> But does that actually tell them what they want to know? Wouldn't it
> would be better to look in the calendar folder instead?
>
>       * If some invitees have already responded to the invite, the copy
>         of the event in the calendar will show updated PARTSTATs, but
>         the copy in the Outbox won't.
>       * If the other user made changes to the event after first
>         scheduling it (eg, added an attendee who was forgotten in the
>         original invite), that will be reflected all in one place in 
> the
>         calendar folder, but the information would be split across
>         multiple separate Outbox messages.
>       * If a meeting was scheduled entirely via iMIP (perhaps because 
> it
>         was received as a REQUEST from a non-CalDAV user), then it will
>         appear in the calendar, but not in the Outbox.
>
> Another problem is that the Outbox doesn't record the responses to the
> SCHEDULE request. So you might see an invite that appears to have been
> sent to several people, when in fact the server returned a 502 for 
> every
> Recipient.

An event in the calendar doesn't tell you what the wording in the 
invitation has, necessarily.  Don't forget you can theoretically send 
out an invitation for a meeting which you're not an attendee of .  
Maybe we should clarify whether an invitation in the sent items folder 
necessarily has to correspond to an event in the calendar?

Also the sent items record tells you when the invitation went out, 
which could be after the event item was created.

I don't know what to do about recording the responses to the SCHEDULE 
request.  A concrete proposal would be welcome here.


>
>> However, the server MAY be configured (how is not defined here) to
>> auto-accept or auto-reject invitations, and if the server
>> auto-accepts invitations then the server is responsible for creating
>> VEVENT resources in the user's calendar.
>
> ("VEVENT" is wrong here, it might be automatically accepting VTODOs
> too.)

I'm fixing that....

>
> If the spec is going to explicitly allow servers to do this, it should
> specify how the client is expected to behave in such a situation. How
> does a client determine if the server has already processed an
> invitation? And is the server allowed (or REQUIRED) to process it
> *before* putting it in the Inbox, to avoid a race condition?

Wouldn't this be the same case as detecting whether another client has 
already processed the invitation?  It's the same problem as the 
multi-client problem -- the server is just another potential active 
client or user agent.

I do like the idea of processing it before it shows up to avoid a race 
condition.  However, that problem might also have to be solved for the 
multi-client use cases.  in fact this shows me we'll need another 
section in the scheduling/fanout section of the document, explaining 
*how* to accept/reject invitations and avoid race conditions.  (To 
avoid race conditions I'll recommend how to use locks or strong ETags).

>
>> 5.2  Calendars Collection
>
>> A WebDAV collection which corresponds to a single calendar or VAGENDA
>> is a Calendar.
>
> VAGENDA is a CAP-ism. RFC 2445 has only VCALENDARs.

Fixing...

>
>> It MUST contain one event collection
>
> Any reason for that? What if a system wants to support just todo data?
> (Eg, a bug-tracking system could export your bugs as tasks.)

Thats a pretty good idea.  so the server MAY contain one and no more 
than one event collection, just like todos.

>
>> and one alarm collection.
>
> That's wrong now, right?

Fixing...

>
>> 5.3  Event Collection
>
>> and each one contains exactly one VEVENT or VFREEBUSY object.
>
> Do we really want static VFREEBUSY objects?

yes- these don't duplicate VEVENT data, they supplement it with blocked 
out time.

>
>> 5.7  iTIP Outbox Collection
>
>> Every non-collection resource in the scheduling collection is
>> considered to be a REQUEST or REPLY.
>
> No COUNTER, DECLINE-COUNTER, etc?

I thought COUNTER was a REPLY?  Do you think these should also be added?

>
>> 6.  Creating Resources
>
> Why not just say that the client should use POST (to the collection 
> URL)
> rather than PUT, and let the server generate an object URL?

That's not a standard part of WebDAV although as we know Exchange 
server does that :)

I'm not against that feature but it's not one that WebDAV servers 
already do, so CalDAV servers would need to add that if we specify 
that.

>
>> 7.  Users and Groups
>>
>> The WebDAV ACL specification requires that any principal to whom
>> permissions can be represented via a WebDAV resource (complete with
>> WebDAV properties and a HTTP URL).
>
> Something is missing in that sentence. (s/can be represented/can be
> granted can be represented/ ?)

fixed text: "The WebDAV ACL specification requires that any principal 
to whom permissions
           can be granted is represented via a WebDAV resource"

>
>> 9.  Scheduling and Fanout
>
>> In other words, the server MUST handle fanout if requested
>
> I think that sentence predates the calendar-schedule capability... the
> section probably needs a little rewriting

Yeah, deleted that sentence.

>
>> CalDAV servers that return the value "calendar-schedule" in the DAV
>> response header MUST support iTIP to send and receive scheduling
>> requests as well as reply to scheduling request.  Outgoing iTIP
>> messages MUST be submitted to an iTIP Outbox collection.
>
> Who is being MUSTed in the second sentence? The paragraph starts out
> talking about servers, but servers don't submit things to Outboxes. And
> if it means "Clients MUST submit outgoing iTIP messages to an iTIP
> Outbox collection", that would imply they weren't allowed to do iMIP,
> which also sounds wrong.

This seems better to me:
"These servers MUST
	handle outgoing iTIP messages submitted to an iTIP Outbox collection,
     and MUST deliver incoming iTIP messages to an iTIP Inbox 
collection."

>
>> Incoming iTIP messages MUST be delivered to an iTIP Inbox collection.
>
> Another dangling MUST.

see above
>
>> 9.1  SCHEDULE Method for WebDAV
>
>> The list of attendees and the organizer information in this request
>> body might well be redundant with the values of the Recipient and
>> Originator headers.  This is intentional, so that the client can have
>> more control over who receives invitations and who sends them:
>
> I think each of the three examples you give is redundant with existing
> iCalendar/iTIP functionality:
>
>> o  The client may send invitations to calendar users not on the
>>    attendee list (for example, to an assistant, caterer, observer,
>>    etc).
>
> They could also be listed as ATTENDEEs with ROLE=NON-PARTICIPANT.

That's like a "cc", the way we outlined in the draft is more like a 
"bcc".  The difference is whether everybody else sees that they are in 
the attendee list or not.

>
>> o  The client may choose not to send invitations to calendar users
>>    who are on the attendee list (for example, attendees who have been
>>    scheduled through an out-of-band mechanism).
>
> Maybe they could just be listed with PARTSTAT=ACCEPTED? (Maybe not...)

I don't like that -- that seems to be overloading something to mean 
something that it doesn't mean.

>
>> o  The originator may be different than the organizer, for example an
>>    assistant who has calendar-bind privileges on the organizer's
>>    calendar.
>
> You can specify that with the SENT-BY property on the ORGANIZER.

Hmm, I recall something convincing here that made our header trick a 
neat one, but now i can't reconstruct the details...  what a four-day 
vacation can do to you!

>
>> 9.1.1  Status Codes for use with 207 (Multi-Status)
>
> Tying back to the Outbox comments earlier, does every successful
> SCHEDULE result in a message being appended to Outbox, even when every
> Recipient fails?

I would say, yes, that's the intended model...  as I said above it 
would be even  more useful to have some way to store the results as 
well as the outgoing message.

>
> Need a little more discussion of the exact scheduling flow. Section 9
> mentions "(c) a new method requests fanout of a resource that has
> already been uploaded", but the description of SCHEDULE itself doesn't
> mention ordering at all, which it probably should. (If you do SCHEDULE
> first, then PUT, there's a race condition in that someone else's REPLY
> could come in before you PUT the event they're REPLYing to, especially
> if there are auto-accepting/rejecting resources on the system.)
>
> OTOH, what's the advantage in doing a PUT to the calendar followed by a
> SCHEDULE to the Outbox, rather than just doing a SCHEDULE to the
> calendar?

The PUT and the SCHEDULE are intended to be independent because 
otherwise we tend to design them together and limit what clients can 
do.
  - PUT is the operation which stores the event on a specific calendar.
  - SCHEDULE is the operation which sends an invitation to multiple 
recipients.

What can the client do special if we keep them independent?
  - I can SCHEDULE to a single Outbox, and independently decide whether 
to PUT the event to my karate calendar or my work calendar.
  - Can SCHEDULE without doing PUT: scheduling a meeting that the 
scheduler doesn't actually attend (and I don't show up in attendee 
list).  e.g. when our HR person schedules an interview for me and a 
candidate.
  - Can PUT without SCHEDULE (any event that doesn't have attendees 
other than myself)
  - Can PUT an event that *does* have attendees, and can use another 
mechanism besides SCHEDULE to notify them (Chandler needs this use 
case).
  - Can PUT an event on my calendar long in advance, then when 
date/location are confirmed and I'm ready to write the invitation, send 
SCHEDULE.

But if we continue with this model, you're right, we do need to 
recommend that if the event is going to go on a calendar at all it 
should go before the SCHEDULE is sent.

>
>> 202 (Accepted) - The request was accepted, but the server has not
>> performed any action with it yet.
>
> What happens if the server returns a 202 and is then unable to complete
> the transaction? (Presumably if it *knew* it was going to be able to
> succeed, it would have just returned a 200 instead.) Eg, it might 
> return
> a 202 if it forwards the request to a remote user via iMIP, but then
> what happens if the iMIP message bounces? There doesn't seem to be any
> way for the server to inform the client of that.

Yep, Bernard & I discussed this at great length when we got together.  
No good answers yet.

>
>> 507 (Insufficient Storage) - The server did not have sufficient space
>> to record the iTIP message.
>
> "in the Recipient's iTIP Inbox". Presumably if the Originator is over
> quota, the SCHEDULE would get back a top-level 507 rather than a 207.

True enough.  thx.


>
>> 9.2.1  Example - Retrieve incoming iTIP Message
>
> The example has an "Originator" header in the response. Is that a bug?
> If not, something needs to say explicitly somewhere that that
> information is preserved. (And that the Recipient information isn't?
> What about in the copy in Outbox?)

Actually the text does say "The originator of the iTIP message will be
	specified in the Originator response header."

>
>> 13.  CalDAV Principal Properties
>
> Many of these properties would be useful (or maybe even necessary) for
> resource-type calendars as well, which (according to section 12)
> wouldn't have any principal associated with them. Is there any reason
> these couldn't be defined on the Calendar or Calendar Container instead
> of the Principal?

Cyrus? Bernard?  I think this might be a good idea...

>
>> 13.3  itip-inbox-URL Property
>> 13.4  itip-outbox-URL Property
>
> Both of these are multi-valued... is there any particular behavior
> expected of clients in the presence of multiple Inboxes or Outboxes? 
> (If
> not, then why can you have more than one?)

Damn, you ask too many good questions.  We should discuss the value of 
multiple inboxes/outboxes, and whether the value is worth the 
complexity.  Somebody, please respond with a new subject so we can 
discuss :)

>
>> 14.3  calendar-bind Privilege
>
>> Recipient header.  The SCHEDULE request If the server's calendar-bind
>> privilege check fails for a given inbox, the rest of the SCHEDULE
>
> I think the "The SCHEDULE request " there is a cut+pasto.

Correct

>
>> 15.1  calendar-time-range Report
>
> Need to clarify how free/busy works in CalDAV (probably with an 
> explicit
> example). Do you have to request the Vfreebusy component-filter? What
> does the response data look like? The text sort of implies that view-
> free-busy gives you the ability to ask for and see the dtstart and 
> dtend
> of VEVENTs, as opposed to just asking for a time range and getting back
> a VFREEBUSY object containing anonymous time ranges.
>
> If the response uses VFREEBUSY, are BUSY-TENTATIVE and BUSY-UNAVAILABLE
> periods ever used? (Perhaps the server MAY return BUSY-TENTATIVE 
> periods
> corresponding to unprocessed invites, and MAY allow the user to mark a
> time period BUSY-UNAVAILABLE?)

Agreed.  For now this is a TODO in the spec.

>
>> 15.1.2  Response to 'calendar-time-range'
>
>> The response to this report is a WebDAV Multi-Status response,
>> containing one <response> element for each event AND for each
>> recurrence.  This differs from the PROPFIND response to an event
>> collection only in that the relevant recurrences each have their own
>> <response> element, not just the master event.
>
> That's sort of ambiguous about whether or not the master event is
> returned.

Oooh,  good point.  I intended one resource for each recurrence.

>
> -- Dan
>
>
Thanks Dan!  Great review.