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