2.1.2 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

Bob Mahoney <bobmah@mit.edu>
Pat Egen <pregen@egenconsulting.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
In Body: SUBSCRIBE/UNSUBSCRIBE
Archive: http://www.imc.org/ietf-calendar/mail-archive/

Description of Working Group:

Calendaring and group scheduling products are well established for organizational use, but they usually are limited to exchange of information among users of the same system, usually within the boundaries of a single organization. This working group will pursue development of standards to enable different products to interoperate and to work across organizational boundaries. This work will include the development of MIME content types to represent common objects needed for calendaring and group scheduling transactions and access protocols between systems and between clients and servers. The working group will also consider and recommend solutions to the security issues concerning the exchange of calendar information between network entities.

The group will exist to create standards that make calendaring and scheduling software significantly more useful and to enable a new class of solutions to be built that are only viable if open standards exist. The Calendaring and Scheduling Working Group is chartered to focus on Internet standards for three basic problems facing group scheduling and calendaring users today. These include the following:

1. A standard content type for capturing calendar event and to-do information. The content type should be suitable as a MIME message entity that can be transferred over MIME based email systems or HTTP World Wide Web. The basic objects along with their representation using MIME will be specified in the document entitled "Core Object Specification".

2. A standard peer-to-peer protocol for common calendaring and group scheduling transactions. For example, these may include exchanging over the Internet, event-requests, reply to event-requests, cancellation notices for event-requests, requesting free/busy time and replying to free/busy time requests between different calendaring products. The working group will undertake this work in two phases, with the first phase focusing on meeting requests and the second phase on free-busy time. To the extent that the peer-to-peer protocol has requirements related to security, the working group will attempt to apply existing Internet standards for authentication, and to assure privacy and integrity of sensitive calendaring information. The protocol for the interoperable transactions will be specified in a document called "Calendar Interoperability Protocol" in the milestone list.

3. A standard access protocol to allow for the management of calendars, events and to-dos over the Internet. This protocol will be specified in the document called "Calendar Access Protocol" in the milestone list.

This working group effort should be developed and stabilized with a 6-9 months since there has been considerable prior work done in this area. This prior body of work includes:

* Distributed Scheduling Protocol (CHRONOS) IETF Working Group * ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling and Appointments * MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP) * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and Calendaring and Scheduling Interoperabilty Specification (CSIS) * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's Specification * Versit vCalendar format

The working group will focus on harmonizing, evolving and developing protocols and algorithms based on this work. The process is subject to extension if many new features are added, or more revision is needed.

Goals and Milestones:

Done

  

Submit core object specification as Internet-Draft.

Done

  

Submit second draft of core object specification as Internet-Draft.

Done

  

Submit first Internet-Draft of Calendar Interoperability Protocol.

Done

  

Submit revised Internet-Draft of Calendar Interoperability Protocol.

Done

  

Submit core object specification to IESG for consideration as a Proposed Standard.

Done

  

Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft.

Nov 99

  

Submit Internet-Draft (informational) on Guide to Implementors using Calendaring Protocols

Feb 00

  

Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard.

Feb 00

  

Submit proposed changes to all drafts affected by Calendar Access Protocol submission

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2445

PS

Internet Calendaring and Scheduling Core Object Specification (iCalendar)

RFC2446

PS

iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries

RFC2447

PS

iCalendar Message-based Interoperability Protocol (iMIP)

RFC2739

PS

Calendar attributes for vCard and LDAP

Current Meeting Report

Minutes taken by Richard Shusterman and Pat Egen

WG co-Chair Pat Egen acted as session chair for the meeting. There were 31 people in attendance.

Update on draft activities:
The chair showed the current Draft/RFC numbers for Calendaring and Scheduling. These included the following:

ICalendar
IMIP
ITIP
iRIP
CAP Requirements Doc
Implementer Guide
CAP

- RFC2445
- RFC2447
- RFC2446
- draft-ietf-calsch-irip-02
- draft-ietf-calsch-capreq-02
- draft-ietf-calsch-imp-guide-01
- draft-ietf-calsch-cap-03 **

** located at ftp://royer.com/pub/CALSCH - this was published to the list prior to Pittsburg but not in time to make the IETF-Drafts file area. It will be reposted with additional editing changes two weeks after Pittsburg.

For unknown reasons, "guide to implementors" was not posted to the IETF Announce list, even though it was submitted and accepted prior to the deadline. An email did go out with the correct URL link (from IETF-Drafts). We pointed attendees to that link and asked that they give the document one more "look see" and put comments on the list.

iCalendar/iMIp/iTIP Update:
The Chair went over the results of the first CalConnect Interoperability testing. The key items are noted on the Powerpoint slides that will be sent with these minutes. The biggest issue was MIME and multipart handling. Every vendor appears to do it differently. There will be another CalConnect in the Fall/Winter timeframe and the chair will post the details by the week of 8/15. One issue is funding for the Open Source developers. We would like to see them at the testing, but need to overcome the funding issue. No solutions were suggested.

The slides show that no scheduling was tested. Steve Mansour from Netscape stated that there was some scheduling tested. We will update our results to reflect that comment.

We solicited vendors to provide examples that we can use during testing. If vendors then test to those examples, we have a better chance of ironing out incompatibilities. Bob Mahoney will post a note to the list asking for examples.

We will be working with the IMC.ORG people (Paul Hoffman) to put up a matrix showing what has been implemented by which vendor. This will be a living document that will continually be updated as vendors add interoperability and standard support.

Implementors Guide:
Bob Mahoney (co/chair) went over the Implementers Guide. He stated that we are going to change the name to Guide to Internet Calandaring Standards so that it can be of use to end users as well as developers and implementors. We added George Babics from CS&T as an editor. We still need more feedback from real implementors.

iRIP update:
The Chair gave an update on the status of resubmission/non resubmission of iRIP. Some dialog from the list says resubmit, some says do not because the functionality of iRIP is in CAP. John Stracke submitted a new draft (during Pittsburg) using what he calls CRISP - which is a smaller version of IRIP that pulls out "verbage" not in CAP and resubmit as a standard draft. John said that CAP can handle iTIP so it can be used as a iRIP-only server. The Capability command would indicate that new iCalendar components like VCAR are not supported. Since this was posted this week, people will need to have time to read and comment on this draft.

One attendee objected to the RFC track - said he found it confusing and that it should be incorporated into CAP. Another attendee said it's still CAP but limited. The chair stated the discussion should be on the list.

CAP Update:
The Chair then went over CAP. There has been activity but the draft did not make it in time to the draft submission. There will be ongoing telephone conference calls with the editors and the chair will act as Scribe and then post the minutes and key items to the list (in succinct format).

We will at some point need to register the CAP URI and port with IANA.

The charter for the WG is being updated. One item added is to Evaluate readiness for interop in Dec 2001. The charter will also be updated to make the dates accurate.

Steve Mansour, CAP editor, went over an example Restriction Table. He said there is a lot more work that will need to be done on each component table. The next effort is to take it to the list and get more feedback. These tables are the key thing missing from CAP and is part of the final process to complete the draft. The editors intend to follow iTIP examples for tables. He went over the fact there will be lots of transactions per command, many responses, one per transaction, and no rollback. He explained the layout of the table and then went over the CREATE COMMAND table. The example will be included with the Powerpoint slides. Other key items noted were:

The restriction table discussed follows: This is an example for the CREATE command.
- - - - - -
This is the proposed format for CAP restriction tables. Their purpose is to define the composition of commands sent to a CAP server and the composition of the command replies.

While the tables list every property, it is not meant to define the meaning of the property. It is meant to define presence or absence of a property.

There will be a RESPONSE-STATUS for each VCALENDAR and/or component created, modified, deleted, or requested. The number of response status valuesreturned MUST be equal to the number of TARGETS times the number of objects in the command. The responses MUST be ordered first by TARGET then by the order of the objects as supplied in the command.

Client Restriction Table for the Create command

Component/Property

Presence

Comment

     

VCALENDAR

1+

 
     

CMDID

0 or 1

If CMDID is not supplied, then there must not be pending replies to previous command.

VERSION

1

MUST be 2.0

VCOMMAND

   

METHOD

1

MUST be CREATE.

TARGET

1+

 
     

VCALENDAR

0+

 

CALMASTER

1

 

NAME

0 or 1

The user friendly name, localizable.

OWNER

1+

 

RELCALID

1

This is only present when creating a new calendar.
This is the name of the calid to create.

TZID

0 or 1

 
     

VCAR

0+

 

CARID

0 or 1

A reference name

DENY

0+

permissions denied. Note, there must be at least one GRANT or DENY within the VCAR.

GRANT

0+

permissions granted. Note, there must be at least one GRANT or DENY within the VCAR.

VQUERY

0+

EXPAND

0 or 1

Expand recurrences or not

MAXRESULTS

0 or 1

Limit the solution set to no more than this many enries.

MAXSIZE

0 or 1

Maximum number of octets to transfer

QUERYNAME

1

Name by which this query is referenced

QUERY

1

The query

     

VEVENT

0+

 

ATTENDEE

0+

 

SEQUENCE

0 or 1

MUST be present if value is greater than 0, MAY be present if 0

SUMMARY

1

Can be null

UID

1

 

ATTACH

0+

 

CATEGORIES

0 or 1

This property may contain a list of values

CLASS

0 or 1

 

COMMENT

0 or 1

 

CONTACT

0+

 

CREATED

0 or 1

 

DESCRIPTION

0 or 1

Can be null

DTEND

0 or 1

if present DURATION MUST NOT be present

DTSTAMP

1

 

DTSTART

1

 

DURATION

0 or 1

if present DTEND MUST NOT be present

EXDATE

0+

 

EXRULE

0+

 

GEO

0 or 1

 

LAST-MODIFIED

0 or 1

 

LOCATION

0 or 1

 

METHOD

1

MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE.

ORGANIZER

1

 

PRIORITY

0 or 1

 

RDATE

0+

 

RECURRENCE-ID

0 or 1

only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present.

RELATED-TO

0+

 

REQUEST-STATUSSSSS

0+

 

RESOURCES

0 or 1

This property MAY contain a list of values

RRULE

0+

 

STATUS

0 or 1

MAY be one of TENTATIVE/CONFIRMED/CANCELLED

TRANSP

0 or 1

 

URL

0 or 1

 

X-PROPERTY

0+

 

[IANA-PROP]

0+

any IANA registered property

     

VTODO

0+

 

ATTENDEE

0+

 

SEQUENCE

0 or 1

MUST be present if value is greater than 0, MAY be present if 0

SUMMARY

1

Can be null.

UID

1

 

ATTACH

0+

 

CATEGORIES

0 or 1

This property may contain a list of values

CLASS

0 or 1

 

COMMENT

0 or 1

 

CONTACT

0+

 

CREATED

0 or 1

 

DESCRIPTION

0 or 1

Can be null

DTSTAMP

1

 

DTSTART

1

 

DUE

0 or 1

If present DURATION MUST NOT be present

DURATION

0 or 1

If present DUE MUST NOT be present

EXDATE

0+

 

EXRULE

0+

 

GEO

0 or 1

 

LAST-MODIFIED

0 or 1

 

LOCATION

0 or 1

 

METHOD

1

MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE.

ORGANIZER

1

 

PRIORITY

1

 

PERCENT-COMPLETE

0 or 1

 

RDATE

0+

 

RECURRENCE-ID

0 or 1

MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present.

RELATED-TO

0+

 

REQUEST-STATUS

0

 

RESOURCES

0 or 1

This property may contain a list of values

RRULE

0+

 

STATUS

0 or 1

MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS/CANCELLED

URL

0 or 1

 

X-PROPERTY

0+

 

[IANA-PROP]

0+

any IANA registered property

     

VJOURNAL

0+

 

METHOD

1

MUST be one of CREATE, PUBLISH, REQUEST, CANCEL, REFRESH, If the value is that of an iTIP method, the property values must be consistent with those specified in iTIP. The values shown below reflect restrictions when the method is CREATE.

ATTENDEE

0

 

DESCRIPTION

1

Can be null.

DTSTAMP

1

 

DTSTART

1

 

ORGANIZER

1

 

UID

1

 
     

ATTACH

0+

 

CATEGORIES

0 or 1

This property MAY contain a list of values

CLASS

0 or 1

 

COMMENT

0 or 1

 

CONTACT

0+

 

CREATED

0 or 1

 

EXDATE

0+

 

EXRULE

0+

 

LAST-MODIFIED

0 or 1

 

RDATE

0+

 

RECURRENCE-ID

0 or 1

MUST only if referring to an instance recurring calendar component. Otherwise it MUST NOT be present.

RELATED-TO

0+

 

RRULE

0+

 

SEQUENCE

0 or 1

MUST echo the original SEQUENCEnumber. MUST be present if non-zero. MAY be present if zero.

STATUS

0 or 1

MAY be one of DRAFT/FINAL/CANCELLED

SUMMARY

0 or 1

Can be null

URL

0 or 1

 

X-PROPERTY

0+

 
     

VALARM

0+

 

ACTION

1

 

ALARMID

0 or 1

MUST be 1 if multiple VALARMs are present in same component.

ATTACH

0+

 

DESCRIPTION

0 or 1

 

DURATION

0 or 1

if present REPEAT MUST be present

REPEAT

0 or 1

if present DURATION MUST be present

SUMMARY

0 or 1

 

TRIGGER

1

 

X-PROPERTY

0+

 
     

VFREEBUSY

0

 
     

VTIMEZONE

0+

MUST be present if any date/time refers to timezone

DAYLIGHT

0+

MUST be one or more of either STANDARD or DAYLIGHT

COMMENT

0 or 1

 

DTSTART

1

MUST be local time format

RDATE

0+

if present RRULE MUST NOT be present

RRULE

0+

if present RDATE MUST NOT be present

TZNAME

0 or 1

 

TZOFFSET

1

 

TZOFFSETFROM

1

 

TZOFFSETTO

1

 

X-PROPERTY

0+

 

LAST-MODIFIED

0 or 1

 

STANDARD

0+

MUST be one or more of either STANDARD or DAYLIGHT

COMMENT

0 or 1

 

DTSTART

1

MUST be local time format

RDATE

0+

if present RRULE MUST NOT be present

RRULE

0+

if present RDATE MUST NOT be present

TZNAME

0 or 1

 

TZOFFSETFROM

1

 

TZOFFSETTO

1

 

X-PROPERTY

0+

 

TZID

1

 

TZURL

0 or 1

 

X-PROPERTY

0+

 

Server Restriction Table for the CREATE command

Component/Property

Presence

Comment

     

VCALENDAR

1+

 

TARGET

1

 
     

VERSION

1

MUST be 2.0

     

CMDID

0 or 1

MUST be returned if the request contained a CMDID

     

VALARM

0

 
     

RESPONSE-STATUS

0

if not creating a calendar

1+

if creating a calendar

     

VCAR

0+

 

RESPONSE-STATUS

1+

 

*

0

No other VCAR properties are present

     

VCOMMAND

0

 
     

VEVENT

0+

 

RESPONSE-STATUS

1+

 

*

0

No other VEVENT properties are present

     

VFREEBUSY

0+

 

RESPONSE-STATUS

1+

 

*

0

No other VFREEBUSY properties are present

     

VJOURNAL

0+

 

RESPONSE-STATUS

1+

 

*

0

No other VJOURNAL properties are present

     

VQUERY

0+

 

RESPONSE-STATUS

1+

 

*

0

No other VQUERY properties are present

     

VTODO

0+

 

RESPONSE-STATUS

1+

 

*

0

No other VTODO properties are present

Issues:
freebusy - a cap server should dynamically calculate freebusy information

we recommend that you cannot create, modify, or delete freebusy composers
- - - - -

Attendee Questions:
John Stracke said if CMDID is 0, flag to indicate no pipelining?

Steve showed the server response table to create. IS * if no other properties are present. He then showed the order of response codes, target first, then components as they were supplied.

At the completion of this table review, the Chair asked for a show of hands of how many people have read CAP - a few hands. How many people have read implementors - a few hands. How many people are just waiting for a calendar standard - the majority of the audience.

The chair stated she is trying to make list less intimidating (i.e. less combative) in order to provide a good vehicle for people to ask questions or provide answers.

She then asked did anyone need/want to know why we need CAP and where it fits - a few hands. Some time was spent explaining how CAP fits into the calendaring area. CAP is the piece that manages how you write calendar entries to your datafile or "calendar Store". It kind of equates to POP in the email world.

General Questions/Answer session:
The chair then reiterated that we are actively trying to get interoperabilty and completing the missing piece.

Then asked what is everyone here expecting? One person, a user representing 230K (Dept of Energy) users, uses Outlook + calendaring products.
Question:
Is there a place to figure out each vendor's compliance. Bob - No, but working to post something soon. That's the IMC.org work.

Question: We also need to identify contacts for each vendor.

Patrik - pointed you at Paul/imc.org to force vendors to test for interop.

Dave - Can you publish list of vendors who don't support a standard?
Patrik - It's still up to the vendor to expose/promote their support for standards.

The session officially ended at 2:00pm. One person came up to the chair at the end to ask if there was an informal web site about calendaring products etc. We may look into setting something like this up. Watch for details soon.

Thanks to Richard Shusterman for taking notes during the session.

Respectively submitted by Pat Egen, co-Chair.

Slides

Agenda