Minutes from 47th IETF meeting of the
Calendar and Scheduling Workgroup in
Adelaide, Australia
March 28, 2000

Bob Mahoney, CALSCH co-chair presiding ([email protected])
Reported by Richard Shusterman ([email protected])
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

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.