[Ietf-caldav] Comments on: 3.2.3.3. HTTP Methods

[Bernard Desruisseaux]

Arnaud Quillaud wrote:
> ** DELETE of unprocessed iTIP REQUEST on calendar-inbox **
> 
> Could we define the behavior of a DELETE on an unprocessed iTIP REQUEST 
> in the calendar-inbox as corresponding to a remove action.
> By doing that, we would allow a client to directly decline a meeting 
> without having to first insert it into one of the owner's calendar to 
> just delete it from there to trigger a decline.

Interesting idea. I don't believe that should be the default behavior
of DELETE though. Perhaps the server could send a reply only when
the resquest header "Schedule-Reply" is explicitly set to "T".

> ** MOVE of unprocessed iTIP REQUEST on calendar-inbox to scheduling 
> collection **
> 
> Could we define the behavior of a MOVE of an unprocessed iTIP REQUEST on 
> calendar-inbox into a scheduling collection as corresponding to the 
> automatic processing of an invitation into that scheduling collection.
> By doing that, we would allow a client to process an invitation, accept 
> and store in one single operation, without even having to to know how to 
> translate an iTIP message (potentially containing only info about a 
> particular instance, etc...) into a calendar resource.
> 
> We might want to add an http header to specify the PARSTAT to set.

I'm not sure it would be wise to play with the semantic of MOVE that 
way. While I may be wrong, I'm expecting most server to provide support 
for a default calendar and thus make this potential performance 
improvement unneeded.

Also, clients may actually want to change more than just the ATTENDEE's 
PARTSTAT from the incoming invitation. For instance, when the invitation 
is accepted the client may actually need to add some reminders (VALARM), 
and when the invitation is declined, the client may actually need to 
also set TRANSP to TRANSPARENT.

> ** DELETE on default calendar collection **
> 
> Should we add a new precondition when trying to delete the default 
> calendar collection ?

Yes. This is missing.

Thanks,
Bernard

> 
> Arnaud Q
> _______________________________________________
> Ietf-caldav mailing list -- Ietf-caldav at osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>