Minutes from 47th IETF meeting of the Calendar and Scheduling Workgroup in Adelaide, Australia March 28, 2000 Bob Mahoney, CALSCH co-chair presiding (bobmah@mit.edu) Reported by Richard Shusterman (rans@netscape.com) Approximatly 25+ people in attendance 1. Guide to Implementors (5 minutes) Discussion lead by Bob Mahoney (co-author) Bob: This draft needs to be rev'd soon; it is about to expire. The authors will work on posting an updated draft in the near future. We need input from developers that are reading the calendar documents. Please send in your "war stories". There were no comments or questions from the crowd. 2. CAP draft discussion (15 minutes) Discussion lead by Bob Mahoney, with presentations by Paul Hill (co-author) and Steve Mansour (co-author), with help from Doug Royer (co-author) Bob: The latest draft, draft-ietf-calsch-cap-02.txt, was posted on March 10, 2000. We are making good progress; there has been discussion on the mailing list that is reflected in this draft. There was one interim meeting scheduled this past January in Boston that was sparsely attended, probably due to the snow storm. Bob: What is our timeframe? Soon. Bob: What features are our priorities? There is no one feature that is prioritized above another feature. However, some features have had more discussion on the mailing list than other features. Recently there has been a lot of discussion in 2 areas, security and groups, which will now be presented by Paul and Steve. 2A. Security - presented by Paul Hill Security Model The requirements are very similar to the authentication and access control requirements of LDAP. The current language is very closely aligned with the LDAP authentication draft. User Principal Name (UPN) An identifier that denotes a unique CU. A UPN is an RFC 822 compliant email address, with exceptions listed below, and in most cases it is deliverable to the CU. In some cases it is identical to the CU's well known email address. A CU's UPN MUST never be deliverable to a different person. It consists of a realm in the form of a valid, unique DNS domain name and a unique username. UPN may be the authentication ID used by the authentication method. UPN may also be the optional SASL authentication ID. CAP IDENTIFY command may also be used to assert the UPN. Question: Is a UPN independent of the authentication method? Paul: Yes, it is the same ID regardless of the authentication method used by the CU. The same UPN is used by VCARs. UPN and Certificates When using X.509 certificates for purposes of CAP authentication, the UPN should appear in the certificate. Unfortunately there is no single correct guideline for which field should contain the UPN. Since no single method of including the UPN in the certificate will work in all cases, CAP implementations MUST support the ability to configure what the mapping will be by the CS administrator. Implementations MAY support multiple mapping definitions, for example, the UPN may be found in either the subject alternative name field, or the UPN may be embedded in the subject distinquished name as an EmailAddress attribute. Question: Is there a preferred field? Paul: Yes, a preferred field is specified in the draft. TLS Ciphersuites Section 2.4.2.4 mentions which ciphersuites may be appropriate. This is aligned with the LDAP access control draft. 2B. Groups - presented by Steve Mansour Usage For VCARs (UPNEXPAND) To invite groups of individuals to an event/todo (CALIDEXPAND) Example Why do groups need to be expanded? An example diagram was presented, showing 2 CS, coach.com and publicIsp.com that are connected together using CAP. The CS coach.com has an embedded directory with group and calendar "baseball team", and current members bill, joe, and bob, each with their own calendar. The scenario is for the "coach" to setup a team calendar in coach.com with a VCAR definition that only allows the members of his team to access this calendar. Any changes to the membership of his team will automatically be enforced by this VCAR definition. If the "coach" would like to invite the calendars for each member of his team to a meeting, his CUA can use CALIDEXPAND to retrieve the list of CALIDs. "joe" would like to view the current members of his team. His CUA, connected to publicIsp.com, can attempt to use UPNEXPAND to retrieve the list of UPNs. Since the definition of his team is embedded in coach.com, this request will be fanned out to coach.com by publicIsp.com and if allowed, the list will be returned. "joe" would now like to invite his team to a meeting. His CUA, creates an event with his team as the only attendee. In order to track the responses of each member, publicIsp.com can use CALIDEXPAND to retrieve the list of CALIDs from coach.com before fanning this request out. Paul: The current draft has a mistake showing CALIDs being returned by UPNEXPAND. This should be UPNs. 2C. iCalendar enhancements in CAP Bob: Do these belong in CAP? Should iCalendar be revised or should these be treated as IANA extensions? There were no comments or questions from the crowd. Doug: There are also bugs in iCalendar that need to be fixed. 3. iMIP security (2 minutes) Bob: RFC 1847 vs RFC 2633 (PGP vs S/MIME) S/MIME is excluded because it doesn't support multipart/encrypted, thus not being RFC 1847-compliant. This was not the WG intent. iCalendar was written before S/MIME RFC was ready. This issue should be addressed in iCalendar. Bob: Does anyone know if S/MIME will ever support multipart/encrypted? There were no comments or questions from the crowd. 4. CalConnect (2 minutes) April 11-12, Cambridge, MA (MIT) Question: How many participants? Bob: Potentially 4-5 vendors, and hopefully 1 open source. Cost is $1K and you can send 2 participants. Other comments and questions from the crowd Question: What's left to be done on the draft? Steve: Examples that show multipart responses and groups. Also, restriction tables, i.e., what commands are allowed and where. This is very tedious work but it was found to be a key part of iTIP. These examples and tables should come out in the next few weeks and any input from the mailing list is welcome. Doug: We need more examples. Question: Have all the issues on searching, raised by Lisa Lippert, been addressed? Paul: Since Lisa has not been participating lately on the mailing list, there has been no further discussion (or apparent interest) on these issues. Question: What's the interest level in CAP? Doug: So far, there have been 570 downloads of the CAP draft, many from the same individuals, which also reflects the multiple revisions of the draft since the ftp site was setup. Bob: Editors are available for discussion after this meeting. We are all --working towards finishing up this work, which the AD's appreciate. Meeting was adjourned