Editor's note: These minutes have not been edited. Co-chair Anik Ganguly called the meeting to order at 1pm. He announced the agenda: * summarize 12/9 WG Chair - COS author 12/9 meeting * COS open issues * CIP open issues * Moskowitz thoughts * Next Steps He proceeded to describe the meeting which took place the previous evening between the WG chairs and the authors of the two Common Object Spec (COS) documents that have been the topic of much recent debate. As a result of the meeting, the authors agreed, pending consensus from the WG, to use the vCalendar draft as the basis for the COS. Frank Dawson and Derek Stenerson will act as document editors. The WG is not required to maintain compatibility with the last Versit version of vCalendar. However, this is not license to make arbitrary changes. Any changes must be justified. In general things which are considered to be broken by the WG will be removed and/or replaced. To facilitate understanding of the draft's status within the WG, a document describing issues to be resolved will be maintained by the WG chair. Anik will take care of the list. For issues for which no consensus can be found, the chair will arbitrate the discussion between the editors. Bob Moskowitz will be the arbitrator. To prevent confusion in the future about WG documents, only documents posted to the WG by the chair will be authoritative. In response to a question from a WG member, AD Harald Alvestrand answered this way of working would be acceptable. He further reminded the WG the goal is to produce the RFCs we've agreed to generate, according to our charter. There was consensus by the WG this plan would be acceptable. In particular, the WG agreed < will be the basis for the COS. . Properties will be unordered within an event object, excepting sentinels. This passed without comment initially. However, later discussion indicated grouping of properties may be desirable. The applicable usage profile for an object could appear either as a property or as a parameter to the MIME content type. The preferred approach is as a property. Proposed property syntax permits datatype specification for the value of the property. Specifying the datatype will be optional. It was observed that if property values could have multiple datatypes, optional inclusion could lead to problems with interoperability. Implementation experience will provide valuable feedback. In an effort to keep event objects compact, acronymic or abbreviated property names will be adopted. It is not anticipated that event objects would be generally human-readable even without this rule, so adopting it won't affect readability. A means to extend the COS will be included. The editors believed there would be few restrictions on the nature of extensions. In particular, they were not concerned about a standard mechanism to extend the protocol. However, the WG did not accept that recommendation. It will continue on the open issues list. The editors believed the WG was satisfied that time coordinates could be expressed in local time with an offset to UTC. This prompted a long discussion proving this was not the case. The issue of time representation continues unresolved. It was agreed that time coordinates must be globally unambiguous. Further there was strong sentiment there be a single representation for time coordinates. It was observed this choice may make some time specifications in use by some cultures impossible or at least very difficult. Harald observed that not only was there lack of consensus, there was lack of definition of the terms under discussion prohibiting consensus. More discussion of this issue will occur on the mailing list. Multi-valued properties will be allowed, according to the editors understanding of the WG's consensus. However, the syntax for representing multiple values is still under debate. It is not clear if all values must share the same datatype, when multiple datatypes for a property are allowed. There will be more discussion on the list. We then moved to issues known to be unresolved. proposes an extensive set of operations to insure functional completeness. Some believe a smaller set will be sufficient and promote faster adoption of the protocol. This issue has not yet had much discussion. Much more is needed. Alternative methods for property normalization have been proposed. Harald Alvestrand stated this must be reworked. Keith Moore observed this WG should not feel bound by choices made in other WGs, but that we should use others work if applicable to our own. It was suggested that only one method be chosen. Ned Freed observed there were numerous syntactic issues that need to be taken up, but would prefer to defer discussion to the mailing list. MIME content types of application/calendar and text/calendar have been proposed. Those who believe the object content is not expected to be easily human readable, advocate application/calendar. Some believe a readable form is both achievable and desirable and advocate text/calendar. The difference is that MUAs substitute app/octet-stream and text/plain for subtypes they don't recognize. Practical experience is that app/octet-stream objects are less accessible to human receivers than text/plain, hence the out-of-band opportunity to interpret the object seems smaller with app/calendar than text/calendar. Resolution of this point will require better understanding of object syntax. Whether to allow the content of addressee headers to be interpreted as meeting attendees in event objects remains unresolved. Little time was left for debate during the meeting. The other items on the open issue list were deferred to the mailing list for discussion as time allotted for COS discussion had elapsed. Calendaring Interoperability Protocol issues Anik reclaimed the microphone and announce we must move onto "The Protocol Formerly Known as CIP". He then turned the meeting over to Steve Hanna and Peter O'Leary who are editing the document.. Steve and Pete recalled that originally 3 different drafts were proposed. One week before the meeting (just before the cutoff) they succeeded in submitting a merged draft. They also posted a open issues document to the list. (It was not resolved if Anik would maintain the CIP list as he is doing for COS). Steve and Pete began reviewing the open issues. The protocol is based on TCP and the transport layer, rather than on the presentation layer as is the case with email transport. Reasons to do this are to enable clients to provide more immediate response for confirmation or errors. This prompted a lengthy discussion where advocates of email-as-the-only transport and advocates of transport-layer transport enunciated their points of view. It was observed that existing applications for group calendaring generally don't use email as a principal means for negotiating meeting acceptance. Chris Newman of CMU pointed out that when an immediate response to a request is not possible, email-transport is perfectly adequate. Bob Moskowitz observed that diversity resulting from using multiple transports limits the damage when a catastrophic failure takes one transport off-line but leaves others available. Alex Haupmann asked why a new transport layer protocol was needed at all? Why not use an existing one like HTTP? Discussion followed where advocates of this point of view argued this would simplify our task, being able to rely on existing transport. It also would avoid problems with gaining its acceptance. Advocates of an new protocol argued it would be better tuned to the scheduling task. If existing protocols are not a perfect match, then limiting or adapting their use for calendaring could be problematic. In addition, it could impose unacceptable burdens on the use of other transport protocols for their original intent. A concern was raised that a new transport protocol would demand an additional, and as yet undefined address space for locating targets of calendar messages. This led to a further discussion of how to locate Calendar Transport Protocol servers. Adaptations of DNS MX records were suggested, as well as using NAPTR records for this purpose. More comment on the merged draft is needed, as well as resolution of the debate over the necessity for a new protocol. With that, Anik turned the meeting over to Bob Moskowitz for a broader discussion of transport issues regarding calendaring protocols. Bob began by summarizing the arguments for and against a transport protocol: a new protocol enables: * better change control * faster startup * avoids inter-wg negotiations but risks: * more revisions before achieving a satisfactory design * difficult penetration of the firewall * complex intra-wg negotiations over both transport and object definition reuse of existing protocols enables: * use of shared code * use of others' experience but risks: * necessity to profile use of other protocol elements * requiring inter-wg negotiation to insure inclusion of necessary features Reusing an existing protocol may cause unintended side effects for the original purpose of the existing protocol, as observed earlier. Keith Moore observed that if multiple wg adopt the "same" protocol, that may cause parallel evolution of the protocol that may be undesirable. Bob proceeded to outline some possible choices for existing protocols that might be adaptable for transport. Between servers he suggested http and smxp. SMXP has been proposed by workers at First Virtual Holding. Anik promised to publish a pointer to the protocol as it has not been proposed as a stds-track RFC. For client-server protocols, he suggested imap, though others may be possible. In order to reach closure, he suggested that unless agreement was made on reusing existing protocols within N days, we should proceed with our own definition. A number of different points of view about this recommendation were expressed. He deferred choosing a value of N to the WG, but suggested it should be less than 30. Keith Moore asked if someone would be interested defining an applicable subset of http. Dave Crocker raised the point there has been little discussion to date about security concerns for these protocols. He suggested we not go out of our way to develop specific protocols for this purpose within either transport or object definitions. Instead, this would be a area we could profit from work by other WGs. We should make the effort to specify what is required to adequately secure information exchange by calendaring protocols. To close the meeting, Anik summarized the next steps that need to be taken. The open issues for COS will be posted to the mailing list. CIP needs to justify its definiton of a new protocol, as well as take up other open issues on the mailing list. Specific proposals are needed on how servers will be identified. They should be proposed as Internet Drafts and offered to the chairman to be submitted to WG and IETF editor. There was no discussion of usage scenarios. Some would like that to be completed. Anik suggested a survey of existing systems would be needed. Anik thanked the editors for leading their discussions, and the WG for its participation. With that he concluded the meeting at 3pm. Respectfully submitted, john noerenberg