NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Robert Moskowitz <firstname.lastname@example.org>
Anik Ganguly <email@example.com>
Applications Area Director(s):
Keith Moore <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
Applications Area Advisor:
Keith Moore <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body]
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:
Submit core object specification as Internet-Draft.
Submit first Internet-Draft of Calendar Interoperability Protocol.
Submit second draft of core object specification as Internet-Draft.
Submit revised Internet-Draft of Calendar Interoperability Protocol.
Submit core object specification to IESG for consideration as a Proposed Standard.
Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft.
Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard.
No Request For Comments
CalSch meeting at 42nd IETF - Chicago
We began with the usual agenda bashing:
- IESG status on drafts
- Locating Draft status
- IRIP status
- CAP requirements
- Next Steps
IESG status on drafts
ICalendar, iTIP, and iMIP have gone through IETF last call and have been offered by
our Area Directors (AD) to the IESG for approval as Proposed Standards. The ADs
noted a few comments about the drafts, but they have been passed, and will be in the
hands of the RFC Editor soon. It may be possible the Editor will request minor
changes before they are assigned RFC numbers. However, these three are nearly
ready to be published!
Working Group Last Call completed with no major objections. It was noted the draft
contained incorrect references to documents. The editor said he'll remove these. After
that, the draft will be ready for review by the ADs. To expedite the review, they will
post the document for IETF Last Call while they review it, instead of completing their
Patrik Falstrom reviewed the steps from Working Group draft to Proposed Standard,
and listed the times the document may need to be edited during this process.
The iRIP team reviewed their work and their plans. They've released a couple of
drafts which have garnered numerous comments. They divided the work to be
accomplished in two parts, clarifications, and open issues. Clarifications are
changes which are not controversial and will be accomplished in the next draft.
Open issues are problems for which the WG has not found consensus.
Clarifications to be incorporated are:
- Changes to the state diagram
- Adding a command table
- Discussion of server behavior if timeout occurs during ICALDATA command
- Better error definitions and examples
- Adding referral syntax and examples
- Specify UTF8 as default charset. Other charsets are allowed as given by MIME
We then began a discussion of the open iRIP issues.
There is a choice to be made regarding the server's behavior on a referral. The server
can simply return the referral address, or it could both return the address, and attempt
to perform the operation on the client's behalf. We were unable to resolve this
during the meeting, further discussion on the list will be necessary. However, there
was noticeable sentiment in the room to choose the first alternative as being simpler.
Attempting to perform the operation may induce the server to attempt an iMIP
connection which would likely not give acceptable real-time performance.
Supporting iRIP will require sysadmins to deploy new server daemons across their
nets, and will require firewall modification to allow the protocol to pass between nets.
Some expressed the fear these changes would inhibit deployment of the protocol
because it would potentially weaken a net's integrity. It was proposed the iRIP
command set be submitted as an extension to SMTP. This avoids punching a new
hole in a firewall for the new protocol. In support of this proposal, it was noted that
the fax WG is considering extensions to SMTP to support fax transmission across the
net. The response to this was the fax WG's requests to extend SMTP are far from
accepted. Those familiar with email protocols thought it unlikely that such extensive
changes to smtp to support iRIP capability would not be accepted by the email
community. AD Patrik Falstrom suggested that this idea may find a warmer reception
in the metad group.
It is unclear when an ICALDATA is complete what should become of the recipient
list in the object. Should it be saved, or does the list reset? No resolution was
apparent in the meeting. This will require further discussion on the list.
Finally (as far as open iRIP issues are concerned), whether iRIP must return all error
codes defined in iTIP is unclear. The editors will seek the WG's advice on the list.
Schedule for iRIP Work
The editors anticipate releasing the next draft within 2 weeks. Over the next 6 to 8
weeks the editors expect to make further revisions with the guidance of the WG.
They anticipate we'll be ready for WG Last Call in approximately 8 weeks. By the
43rd IETF, an iRIP protocol should be ready for AD review prior to an IESG ballot.
CAP Requirements Draft
Having disposed of iRIP, the WG next focused its gaze on CAP requirements. The
editors outlined their hopes and goals for the document. They want to capture as
many requirements as possible so the WG can review and agree on the requirements
before proceeding to design the protocol. They anticipate, as do many others within
the WG, that a usable protocol will be subtle, complicated, and big. Agreeing on the
requirements should erect a sufficiently tall barrier to casual changes to the design in
the future. The WG spent some time debating the future of the document once it is
written. This was returned to several times during the course of discussion of the
requirements so far gathered.
The authors anticipate requirements will break down into five categories: Basic,
Administrative, Component Management, Access Control and Notifications. It was
noted that Access Control refers to calendar object access, not access to calendar
daemons themselves. The authors polled the WG if the explanations were
sufficiently detailed. The WG seemed generally satisfied, although it was noted that
the requirements while clear are not necessarily consistent. Requirements are not yet
sufficiently abstracted. As a result, some are stated as scenarios or examples rather
than a explicit condition that must be met by the protocol. Some worried the authors
intended the scenarios to be normative. Eventually it was understood they are to be
explanatory, but that the scenarios currently are the vehicle to express requirements
not yet fully conceived.
The authors then began to outline what constitutes the different catagories of
requirements. Basic requirements include calendar object manipulation such as
add/modify/delete actions. Requirements for the connection between the CUA
and CS are considered basic.
The WG noted requirements for Searching Calendars will be necessary.
Operations such as discovery, lookup and search should be included.
Notifications should support 2-way communication between client and servers.
Protocol Security requirements must cover 3 areas. The protocol must provide for
authentication between clients and servers. It must be possible for clients and
servers to identify each other. Finally, the protocol must provide a means to
determine if particular actions are authorized.
The CAP requirements authors offered to keep our ADs apprised of the WG's
discussion of the requirements. AD Patrik Falstrom noted that our WG's approach
to setting requirements before embarking on design has not been widely used
within the IETF to date. Others will watch our progress with interest.
To sum up the requirements discussion, the authors expect to have a new
requirements draft prepared in time for the 43rd IETF meeting. They expect to
be able to enumerate major sections of the requirements by Oct 9th. They will
continue considering comments until Nov 25th. Comments after that date will
need to be included in the revision to follow the next meeting. While it is not
necessarily true the requirements document must become an RFC of the IETF, it
certainly should have a strong role in shaping CAP's design. Deviating from the
requirements must not be entered into lightly. A number expressed the hope this
would become an informational RFC for the benefit of future implementors.
Finally, the model document author agreed to resurrect the model document draft, as
it has expired. However, he made no promises on when this feat would be
iCalendar, iTIP and iMIP are in the hands of the RFC Editor. Their issuance as
RFCs is imminent. Locate will be presented to the ADs for their review. Within the
WG, iRIP requires further revision. The WG must provide additional review,
commentary, and revision for CAP Requirements. It was proposed that SCAP be
removed from our Charter.
With our agenda completed, the chairman adjourned the meeting.
go to list