CalSch WG mtg on 12 Dec 1997: o Agenda review Anik called the meeting to order. To begin he referred to the agenda he had published to the mailing list. Because of the anticipated discussion for iCalendar, iTIP and Model and the desire to reach closure for these documents, he acceded to requests to delete iRIP and CAP requirements from today's agenda. It was noted that a draft for iRIP is available in internet-drafts. Based on WG discussion on the mailing list prior to the meeting, Anik believes that iCalendar, iTIP and the Model will be ready after today's meeting for submission to the IESG to move them to PROPOSED status (FYI status for the Model). Of course, if problems are discovered, then they must be fixed first. The balance of the meeting will be devoted to reviews of iCalendar, iMIP and the Model in that order. o iCalendar review Derik Stenerson and Frank Dawson explained they wished to list the issues known to need resolution and attempt to close them, then seek other issues from floor. o Time zone syntax Derik began with the time zone syntax. He recently published a set of changes for iCalendar time zone syntax that incorporates suggestion made on the mailing list. Harald accepted the changes. However, Keith Moore was more circumspect. Keith's initial concern was there are not enough examples that show the use of time zones in events. He asserted that no successful protocol will omit explicit references to timezones. As the discussion developed, it became clear that the timezone reference must be in terms of a label whose value is resolved each time the event is presented. This is necessary because events are scheduled in terms of the current time, irrespective of clock shifts that may occur between the scheduling of an event and the arrival of the time for the event. This implies that changes throughout the document are still required. Without those changes or their equivalent, the IESG will certainly not allow iCalendar to go forward. As a further example of this problem, Keith described a recurring meeting scheduled at 11am US Eastern Time each Tuesday. In terms of UTC, during EST this is UTC-0500, but during EDT, this is equivalent to UTC-0400. However, from the perspective of the attendees, the meeting is *always* at 11am ET, even though the offset from UTC is different at different times of the year. If the meeting time is resolved to an absolute UTC at the time the meeting is scheduled, then the meeting time shifts when the clock shifts. This behavior is unacceptable. Allowing a label in the time zone introduces more changes than simply allowing a label in time zone syntax. A set of labels and their interpretation must be specified. So that new labels may be registered or old one meaning modified, responsibility for maintenance of the list must be passed to IANA. This discussion had grown quite animated. So that other topics for iCalendar could be discussed, Anik summarized this debate, and asked the WG to move on to the next item. He summarized the debate, as follows: 1. Event start and end times may be in different time zones 2. A time zone must be expressed in terms of a time zone label. 3. There must be an accepted set of time zone labels 4. No set of accepted labels currently exist 5. An authoritative source for label semantics must be created (perhaps as a function of IANA) o Recurrence grammar Recurrence rule grammar is complex. Is it possible to define a minimal set of rules that provide enough functionality? iTIP response codes could be used to negotiate what recurrence rules are interpretable. A meta-property could be usd to identify what set is supported. But iTIP doesn't have real-time negotiation, so peers will likely assume the minimum implementation to avoid having messages rejected. o iCalendar Summary The discussion of time zone and recurrence rules exhausted the time available to discuss iCalendar. Before moving on to iTIP, Anik asked the editors to supply a list of outstanding issues to be included in the minutes. Current outstanding issues are: Title Doc Sections Status Source Time specification is not adequate iCAL 4.1.10.11 Open Keith Moore Must allow "late binding" to time iCAL 4.4.6 zone information. Recurrence grammar should have iCAL 4.10.9 Open Dan Hickman minimum required set Ordering of evaluation of BYxxx iCAL 4.1.10.9 Open Dan Hickman components inconsistent with example. Eliminate "SOURCE". Use "Content-Location" instead iCAL 4.5.4 Open Alex Hopmann Does the URL attribute duplicate iCAL x.x.x Open Alex Hopmann the MHTML Content-Location header? Related-To, make it a URL Open Alex Hopmann Should we support Basic or Extended iCAL 4.1.9.3 Open Alex Hopmann or Both ISO 8601? Can the owner also make changes? iCAL 3 Open Yvonne Tso Owner needs to be defined or iCAL 3 Open Harald Alvestrand removed Can the Date/time DUE be the same iCAL 4.6.9 Open Yvonne Tso as the DTSTART? iTIP issues Steve Mansour and Frank Dawson began by listing all of the unresolved iTIP issues, and then began working through the list. o Multiple request status replies This seemed unresolved in mailing list discussion. However during the meeting, it was agreed that adding some examples will be sufficient. o Recurrence rule minimum set Echoing the iCalendar discussion, the difficulty defining the set was noted. iTIP has defined error responses for inability to interpret recurrence rules. What to do about the minimum recurrence rule set remained unresolved. o Representing restrictions on required/excluded properties Alex Hopmann has written a program to analyze the iTIP grammar. While he believes it is correct, as far as it goes, there were some rules he was unable to code in his analyzer. This led to a discussion of whether the specification was sufficiently complete, even if the grammar could not be parsed by machine. The discussion concluded that human readability was more crucial than insuring a mechanical parse. o Change of ownership of component The WG felt the ownership concept lacks clarity, specifically how it differs from the organizer. Nevertheless, it was felt to be an important concept. Currently iTIP has no mechanics to express changing the owner of a component. It was specifically omitted because of fears that the channel could be compromised. But it was noted that if the owner changes, this must be advertised to those CUs who have the component on their calendar. Because organizers do exist, some suggested unifying owner and organizer into a single role. Several in the WG felt this was a bad choice. Expressing ownership changes remained unresolved. o Are multiple organizers allowed? iTIP has no provision for multiple organizers, however, this is allowed in the model. Currently the single organizer in iTIP can be an individual, group or an unknown CU. There was a request on the list to eliminate the group. However, those at the meeting disagreed. Multiple organizers are still unresolved. o Delegation of organization and response The iTIP authors would like clarification on how this should work in the model. The model author agreed to address this. iMIP o Signing and encryption The iMIP authors bravely took made this the first item on their agenda. They repeated the requirements as they saw them: all conforming implementations MUST provide the ability to sign components all conforming implementations MUST provide the ability to authenticate all conforming implementations SHOULD encrypt and decrypt o Multiple calendar components in a single message iMIP messages could be constructed as multipart/mixed messages with each part containing a single component. The could be composed as a single text/calendar with multiple components. Expected behavior is that text/calendar parameters will identify the component type contained in the part. The first alternative is the one the authors prefer. The WG concurred. o Content Disposition MIME semantics only specifies whether object is in-line or to be stored as external file. Other interpretations should not be allowed or inferred. Model Two issues were identified for the Model, resolving the concept of delegation, and removing ambiguity about Calendar Service. o Delegation As noted above, the author has agreed to identify the kinds of delegation possible in Calendaring and Scheduling and incorporate them into the model. o Calendar Service ambiguity The model combines a calendar store and component transfer agent into a single concept called Calendar Service. This creates ambiguities for when the functions of the Calendar Service are required. The author will divide Calendar Service into two separate concepts to remove the ambiguitiy. Because of the extensive discussion, and the readily apparent need to resolve the problems discussed, we made no effort to assess consensus that any documents were ready for submittal to the IESG. We were out of time at that point, so the meeting was quickly adjourned. john w noerenberg, ii jwn2@qualcomm.com ------------------------------------------------------------------ "YOU THINK THEY GIVE YOU THE SHIVERS NOW," Owen said. "JUST WAIT UNTIL HE STARTS MAKING DECISIONS!" -- John Irving, A Prayer for Owen Meany, 1989 ------------------------------------------------------------------