Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / calsch / calsch-minutes-97aug.txt < prev

Wrap

Text File | 1997-10-10 | 14KB | 343 lines

Minutes of the Working Group on Calendaring and Scheduling Held at Munich (39th IETF), Aug 11, 12 WG Co-chair Anik Ganguly, called the meeting to order at=20 7:30 pm and reviewed the following agenda. Calendaring and Scheduling Working Group Meeting 39th IETF Munich, Germany Monday, 11-August-1997 1930 - 2200 (7:30 - 10:00 pm) Agenda 19:30 Agenda review 19:35 Discuss Model document Title : Internet Calendar Model Specification Author(s) : J. Noerenberg Author(s) : J. Noerenberg <ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-mod-01.txt> 20:20 Discuss iTIP part 1 Title : iCalendar Transport-Independent= Interoperability=20 Protocol (iTIP) Part One: Scheduling Events and BusyTime Author(s) : S. Silverberg, S. Mansour, F. Dawson, R. Hopson Author(s) : S. Silverberg, S. Mansour, F. Dawson, R. Hopson <ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-itip-part1-00.txt> 21:05 Discuss iCalendar Title : Internet Calendaring and Scheduling Core Object= =20 Specification (iCalendar) Author(s) : F. Dawson, D. Stenerson Author(s) : F. Dawson, D. Stenerson <ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-02.txt> 21:50 Review next steps Setup Agenda for Tuesday meeting 22:00 Collect WG Roster, Adjourn ----- Calendaring and Scheduling Working Group Meeting 39th IETF Munich, Germany Tuesday, 12-August-1997 10:15 =96 11:15 am Agenda 10:15 Discuss iTIP part=20 11:15 Collect WG Roster, Adjourn Model Document -------------- The first item of business was discussion of the Model=20 Document. A number of editorial changes were identified=20 and accepted for the next revision. There was some=20 discussion of the use of the term =93minimal requirements=94 in=20 the model document and it was agreed that the term=20 =93minimal=94 would be removed. The model document made reference to the exchange of=20 calendar properties using iTIP. Since iTIP does not really=20 allow property exchange, the model document will remove=20 this statement. There was a suggestion to describe how to-dos can roll over=20 from day to day. This was rejected because the model=20 document should be as general as possible with respect to=20 the objects that can be exchanged between protocol elements=20 and since we did not envision adding to the model document=20 whenever a new object was added. There was a discussion of the role of the owner and=20 organizer and it was decided that the model document would=20 describe these and in particular the policy regarding=20 ownership of entries in a calendar. There was a great deal of discussion on the notion of an=20 authoritative store. The issues underlying this discussion=20 are: the existence of multiple copies of a user=92s calendar,=20 the access to them and the resolution of differences among=20 them. Since the model document has two distinct purposes, it was=20 suggested that the document be separated into two. One=20 would be the abstract model itself and would say as little=20 as absolutely necessary in an effort to be descriptive but=20 not overly constraining. The second would describe by way=20 of numerous examples and scenarios how the calendar=20 specification might be applied. This would be an aid to=20 implementers who had not participated in the creation of=20 the specifications. This suggestion was rejected in favor=20 of keeping both =93sections=94 in one document, with=20 appropriate guidance to readers. The model document would=20 eventually become an informational RFC. With that, the discussion of the model document was closed=20 and the iTIP editors were invited to discuss their=20 document. ITIP (part 1) ------------- The editors listed the recently resolved issues from the=20 ongoing discussion on the mailing list and identified a=20 collection of typographical and grammatical errors that=20 would be addressed in the next draft. =20 The issue of delegation was discussed and in particular=20 questions were raised about multiple people delegating the=20 same meeting to the same person, and about the method to=20 avoid looping. It was resolved that multiple delegations=20 will be accepted. The iTIP editors restated the long-standing criticism about=20 the structure and semantics of the profile property and=20 offered a solution. The solution is to separate the=20 information contained in the profile into two attributes. =20 The name of the component/object would be specified=20 implicitly by the iCalendar object and a new property would=20 specify the method/verb (e.g. request, cancel etc.). The=20 MIME headers specified in iMIP would specify both the=20 component and the method explicitly as parameters on the=20 =93Content-type=94 header. This proposal was accepted. On the subject of return codes it was stated that=20 experience has taught that 3digit return codes were=20 problematic because of the finite nature of the space they=20 could represent. The solution of dot-separated,=20 hierarchical return codes was offered and accepted. There was discussion about generation of UIDs and Pete=20 Resnick suggested that the DRUMS WG had come up with a good=20 solution and that we should use the same solution. He took=20 the assignment to get the solution from DRUMS to the=20 editors of iTIP. Members of the audience noted that if the=20 solution was structured as local-part@hostname, the local-part=20 better not have meaning. They also noted that it was=20 essential to specify a maximum length for the UID. The iTIP editors noted that they were still working on and=20 open to discussion on when to increment the sequence number=20 for an event and suggested that the issue be discussed on=20 the mailing list. Finally, the iTIP editors discussed the plan for completing=20 the document. They wanted to finish the next revision of=20 the document in 6 weeks. A question was raised about the=20 relationship between the model document and the iTIP=20 document. The chair noted that, contrary to the charter,=20 it made sense to submit the two documents (and indeed=20 iCalendar also) at the same time to make sure that there=20 were no inconsistencies between the documents. The iTIP=20 editors noted that if both drafts were revised in the next=20 several weeks, the WG members at large could help ensure=20 that they were consistent. A question was raised about the=20 need to submit one or more bindings for iTIP with the=20 submission of iTIP to the IESG. A mail binding is in the=20 works and a second binding, to a real-time transport, would=20 demonstrate the transport independence of the iTIP=20 specification. This led to an inconclusive discussion of=20 the merits of HTTP as a real-time protocol for calendar=20 interoperability as time ran out. iCalendar --------- Next, the editors of the iCalendar specification discussed=20 the few open issues with that specification. The issue of =93version=94 and =93profile-version=94 was discussed=20 and it was decided that Alex would submit to the mailing=20 list a proposal for a mechanism that would flag individual=20 properties with the =93Fail=94 parameter if a receiver that=20 does not comprehend the property encounters it. The=20 default behavior of the receiver would be to simply ignore=20 the property. This was accepted as a reasonable solution=20 to the problem. The time-zone syntax was criticized a too wordy and it was=20 decided that a concrete alternative should be proposed on=20 the list by Harald Alvestrand as soon as possible and no=20 later than 4 weeks so this issue gets resolved. There was an issue with multiple layers of encoding in the=20 specification and Chris Newman took an assignment to=20 specify the solution to this problem.=20 There was discussion again about the package of=20 specifications that should be submitted together and=20 someone raised the issue of the calendar access protocol. =20 It was decided that the model document would make a=20 reference to the access protocol and explain the=20 distinction between the interoperability and access=20 protocols but that, as agreed before and documented in the=20 charter, the work on the access protocol would continue=20 after the submission of the interoperability protocol. =20 Further, if the model document needed revision to support=20 the access protocol, a new RFC would be published to=20 obsolete the original. iTIP (parts 2 & 3)=20 ------------------ There was significant disagreement, even among the iTIP=20 editors, about the need to support to-dos and journal=20 entries at the same time as events. Some felt that the=20 specification would be incomplete without them and others=20 felt that the specification of to-dos and journals did not=20 have sufficient depth and the quality of that part of the=20 specification was suffering as a result. Also, the volume=20 of the specification was daunting. After significant debate that appeared not be converging,=20 the chair suggested that the WG has accepted a time of=20 about 6 weeks for revisions of the iTIP documents. That=20 time should be allowed to enable anyone to surface=20 substantive issues that would prevent the editors from=20 coming to closure on to-dos and journals. And if none=20 arose, those components would remain in the specification. The meeting adjourned for the night at 10:05pm and was=20 scheduled to continue at 10:15am the following morning. 12-Aug-1997 10:15am the meeting reconvened There was some discussion to confirm the conclusions of the=20 previous night regarding iTIP. First, to-dos and journals=20 would be presented alongside events and the iTIP=20 specification would no longer have 3 distinct parts. A=20 unified presentation of the objects and the methods that=20 apply to them is the goal. Security -------- The chair made introductory remarks on the importance of=20 properly addressing security in the specifications that the=20 WG submitted to the IESG. The ADs underscored this point=20 but pointed out that there were no easy answers. At the=20 chair=92s request, the AD for Security, Jeff Schiller, had=20 asked Paul Hill and Bob Mahoney to work with the CalSch WG=20 to make sure that the protocols adequately addressed=20 security. =20 Bob and Paul led the discussion and identified the areas of=20 concern as authentication, encryption and authorization. =20 The current iTIP does not address the authorization issue=20 and the feeling was that it should because it was a=20 transport-independent issue. The issue about the availability of an S/MIME specification=20 as a mechanism that the calendar protocol could refer to=20 was raised. It was stated that the only available,=20 referenceable mechanism was PGP/MIME. A suggestion was made that the security model be described=20 in the model document and this was accepted by the editor=20 of the model document who invited contributions. Bob and Paul accepted the assignment of posting a threat=20 model to the mailing list so that it could be discussed and=20 incorporated into the model document. Additionally, the=20 protocols themselves would specify the mechanisms they use=20 to mitigate the various threats. The editors of iTIP and=20 iMIP agreed to address security in their next revisions. The Internet Draft that is supposed to provide protocol=20 writers guidance on writing the security considerations=20 section is available as draft-iab-secwks-sec-guidelines- 00.txt. LDAP Schema ----------- Alec Dun led a discussion of a proposal he had made for=20 using LDAP to locate a user=92s calendar and to store free- busy information in the directory. He described the=20 proposal briefly, the associated draft is draft-dun-calsch- schema-00.txt. He also noted that he was proposing that=20 the vCard schema be extended to include the calendar=20 related attributes. Several issues were raised about the proposal, including: 1. How to associate multiple calendars with a user 2. The impact of putting free-busy time data inside a=20 directory 3. The calendar URL as specified in the proposal is very=20 mail centric and may not be appropriate for some systems 4. Security implications of the existence of this data in=20 the directory 5. Effect of LDAP caching on the calendar applications 6. The dependence of the implementations of the CalSch=20 protocols on LDAP 7. Lack of clarity on whether this is a mandatory or=20 optional mechanism Based on these objections, and a general sentiment that we=20 needed a simple, non-LDAP dependent, solution to locate a=20 users calendar server, Alec took the assignment of=20 specifying the problem that the proposal attempted to solve=20 and get consensus on the list before we continued the=20 discussion of the details of the solution. Closing ------- The chair noted that the following work items were=20 committed at this meeting: 1. Model document 3rd revision with the results of the=20 discussions at this meeting 2. iCalendar document 4th revision with the results of the=20 discussions at this meeting and anything needed to support=20 iTIP 3. iTIP document 2nd revision with the 3 parts merged, new=20 format for presentation, security considerations and the=20 other results of the discussions at this meeting. 4. iMIP/iRIP binding documents =96 first drafts. ------------- The End -------------------------- Respectfully submitted, Anik Ganguly Note: These minutes were written by Anik Ganguly from the transcript recorded by Alex Hopmann. The original transcript is available either from Alex or Anik.