list of items

Tim Hare <[email protected]>
Newsgroups gmane.ietf.calendar
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.