RE: list of items

Was the freebusy model (responsabilities of the CS/CUA) totally clarified ?
I think it would deserve a few examples.

Arnaud Quillaud

> -----Original Message-----
> From: Tim Hare [mailto:[email protected]]
> Sent: Thursday, November 20, 2003 7:04 PM
> To: [email protected]
> Subject: list of items
> 
> 
> 
> I think now is a good opportunity to take a quick vote or survey to 
> determine what are the critical unresolved issues remaining 
> to get the 
> first version out the door, and what are the not-so-critical 
> issues that we 
> may or may not want to resolve before last call. As I am a relative 
> latecomer to the list, I cannot yet come up with an 
> exhaustive list, but 
> here are a few, others can add theirs. Please - let us just 
> list items for 
> now without emotion behind them, we need a list, not another 
> argument (and 
> I _know_ some of these may still be controversial)
> 
> Critical:
>    A.	Consensus that the original author's interpretation of 
> recurrence-ID 
> handling (quoted here) is or is not what should happen.
> 	>"3) Considerable discussion was held on semantics and behavior 
> of  recurring events during the IETF deliberations leading to 
> WG 	>consensus around  the definition of iCalendar. It is 
> our belief that 
> the intent of this consensus  is as follows:
> 
> 	>a) the value for RECURRENCE-ID was agreed to be the 
> date/time  value of 
> the original recurrence instance. This value remains 	>unchanged for 
> as  long as the base recurrence set (or pattern) exists. A 
> rescheduling of 
> an  individual recurrence instance did not 	>cause creation 
> of new base 
> recurrence  set, but only moved the start/end of the 
> specified recurrence 
> instance.
> 
> 	>b) An addition of a new recurrence instance to the set 
> would be 
> an  example of an action that would create a new recurrence 
> set 	>e.g. 
> changing a  Monday weekly meeting to a Monday and Tuesday 
> weekly meeting. 
> This latter action  is an example of an action  	>that 
> *might* also cause 
> the values of the  RECURRENCE-ID properties for each member of the 
> recurrence set to get redefined  	>(*might* is used here 
> and in the RFC 
> because it is possible that occurrences in  the new 
> recurrence set will 
> have the same 	>date/time value). But a rescheduling  
> of a member of the 
> recurrence set would not cause such behavior (i.e., change  
> the value) 
> of 	the RECURRENCE-ID property associated with the 
> rescheduled  recurrence 
> instance.
> 
>    B. 	Whether or not a unique ID is needed to tell 
> local alarms from 
> non-local alarms (and whether this ID will be called ALARMID 
> or SEQUENCE)
> 
>    C.	Whether the CAP version will be a numeric version as in 
> iCalendar or 
> a list of supported RFCs.
> 
>    D.	Consensus about whether stored queries should be 
> retained as part of 
> CAP or not (and if so clarity about how they work)
> 
> Not-so-critical
> 
>    A.	Whether CALSCALE should be a required property returned 
> in response 
> to a GET-CAPABILITY command or not
>    B.	Consensus and clarity in the document about what is 
> returned to a 
> VQUERY with EXPAND=TRUE for a recurrence set: the occurrences 
> within the 
> date range of the query, or an attempt to return all the ocurrences.
> 
> 
> OK - that's my list. If we can all post a short list of 
> items, and merge 
> them together, the scope of what needs to be done will be 
> defined, and we 
> can help get this finished.
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> 
>