Re: [caldav] various question on scheduling draft

[Bernard Desruisseaux <[e-mail]>]

[Note: Arnaud, Cyrus and I discussed these issues face to face last week 
at CalConnect Roundtable XVI.]

Arnaud Quillaud wrote:
> Hello,
>
> Some questions and comments on the latest scheduling draft:
>
> * SCHEDULE-AGENT parameter
> In the case of a recurring event where a particular attendee might 
> appear in multiple instances,  is it worth mentioning that given a 
> particular attendee, the value of this parameter should remain 
> constant between instances ?
We will add a new requirement to specify that SCHEDULE-AGENT=SERVER and 
SCHEDULE-AGENT=CLIENT MUST NOT be used simultaneously for the same 
Attendee in different recurrence instances. Otherwise the Attendee could 
received different subset of recurrence instances from different 
channels (i.e., invitation delivered in CalDAV account, invitation 
delivered in email inbox with iMIP) and would end up being confused...
>
>
> * About 5.2.1.2. Modify (by the organizer)
> Without defining what is a modification in this context, it seems like 
> any modification by a client will trigger a REQUEST to all attendees 
> with (old=SERVER,new=SERVER) when it is not really the case (e.g 
> VALARM change).
> If the change is significant enough but the client has not reset the 
> PARTSTAT of the attendee, should a REQUEST still be sent ?
We will specify that the server is REQUIRED to deliver a REQUEST 
whenever the SEQUENCE property is modified by the client or by the 
server.  We will also specify that the server MUST NOT send a REQUEST 
when changes that only impact the Organizer, such as adding a VALARM 
component, is done.  Note that the server MAY send a REQUEST in other 
situations. Finally, note that the server is REQUIRED to send a REQUEST 
whenever SCHEDULE-FORCE-SEND=REQUEST is specified on an ATTENDEE property.
>
> * About 5.2.2.1. Allowed Attendee Changes
>
> Why allow changes to the CREATED property ?
An Attendee that wants to specify a different PARTSTAT value or 
different VALARM for a specific recurrence instance will end up creating 
a new overridden component and may thus set the CREATED property in this 
new overridden component.
>
> * About 5.2.2.3. Modify (by an attendee)
>
> There is no mention of the EXDATE case (that should trigger a REPLY 
> with PARTSTAT=DECLINED). EXDATE is actually mentioned as an allowed 
> change right before and the example section contains this scenario but 
> it might still belongs here.
We will add a comment that Attendee can decline by adding an EXDATE in 
paragraph 2.  The use of EXDATE on a recurrence instance is similar to a 
DELETE request on a calendar object resource, that is, (1) a REPLY with 
PARTSTAT=DECLINED will be sent to the Organizer, and (2) there is no 
define mechanism to allow the Attendee to undo this operation (i.e.,  
the iCalendar object won't contain the required information to know 
whether the EXDATE was added by the Attendee or by the Organizer).
>
>
> PERCENT-COMPLETE is also listed as an allowed change for attendees. 
> Looking at iTIP (http://tools.ietf.org/html/rfc2446#section-4.5.4), 
> REPLY can be used by ATTENDEEs to convey the progress on the delegated 
> task. As a consequence, should a change in PERCENT-COMPLETE by an 
> attendee also trigger a REPLY ?
We will specify when a REPLY MUST be delivered and when a REPLY MAY be 
delivered:

- A REPLY MUST be delivered for VEVENT and VTODO when an ATTENDEE's 
PARTSTAT is modified for any recurrence instance, including newly 
created overridden component, or when an EXDATE value is added either by 
adding a new EXDATE property or by adding a value to an existing EXDATE 
property in the master component.

- A REPLY MAY be delivered for VEVENT and VTODO when the COMMENT 
property is added, modified, or removed for any recurrence instance.

- A REPLY MAY be delivered for VTODO when the PERCENT-COMPLETE or 
COMPLETED property is added, modified, or removed for any recurrence 
instance.

Furthermore, we will add the following statements in section 5.2.2.1 
Allowed Attendee Changes

   * add, modify or remove any "COMPLETED" iCalendar properties.
   * add, modify or remove any "COMMENT" iCalendar properties.
>
> * About 6.1. Processing Attendee Replies
>
> It says:
>
> <<
>
> The server SHOULD send scheduling messages to all the other Attendees
>    indicating the change in participation status of the Attendee 
> replying, subject to the recurrence requirements of Section 5.2.6
>
> >>
>
> This might indeed trigger quite a few messages. What about attendees 
> who have declined ? Are they really interested in those messages ? I 
> guess, their CUA could just filter those messages out but...
Given that an Attendee may reconsider his PARTSTAT based on the PARTSTAT 
of other Attendees, an updated REQUEST SHOULD be sent by the server.
>
> About 6.2. Processing Organizer Requests, Additions, and Cancellations
>
> There is no guideline as far as processing a CANCEL (should the server 
> just set the STATUS of the meeting to CANCELLED or might it choose to 
> simply delete the calendar resource from the attendees copy).
We will add text in this section to clarify that this is up to the 
implementation. Some server may automatically remove the calendar object 
resource from the calendar, other may simply modify the STATUS property, 
and perhaps offer the Attendee to remove the calendar object resource 
when processing the cancellation notification received in the scheduling 
inbox.
>
> * implementation question:
> This is a rather philosophical one: the server is now altering 
> calendar resources as much as the client (even on a simple create, 
> just to update the SCHEDULE-STATUS). Should we preserve the PRODID of 
> the client although the server altered the content, possibly in some 
> drastic way ?
CalDAV doesn't impose additional requirements on the PRODID property. As 
such, refer to RFC5545 for PRODID requirements.  In my opinion, PRODID 
should be set to the application that generated the iCalendar 
representation. If the server always (re)generate the iCalendar 
representation then it should specify its own PROPID.

Thanks a lot for your feedback!

Cheers,
Bernard
>
> Thanks,
>
> Arnaud Q
>
>
> _______________________________________________
> caldav mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/caldav
>