[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.