Current Meeting Report
Slides
2.1.1 Calendaring and Scheduling (calsch)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
21-Jan-02
Chair(s):
Bob Mahoney <bobmah@mit.edu>
Pat Egen <pregen@egenconsulting.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.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
vent-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. |
| Done | | Submit Internet-Draft (informational) on Guide to Implementors using Calendaring Protocols |
| Feb 01 | | Hold second CalConnect Interoperability Testing on iCalendar, iMIP and iTIP |
| Mar 01 | | Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard. |
| Jul 01 | | Request last call on Guide to Internet Calendaring |
| Jul 01 | | Submit Internet-Draft on Guide to Internet Calendaring for consideration as a Proposed Standard |
| Jul 01 | | Submit revisions for Internet-Draft for iCalendar, iMIP and iTIP |
| Jul 01 | | Submit revisions for Internet-Draft for Calendar Access Protocol |
| Jan 02 | | Evaluate readiness for interoperability testing of Calendar Access Protocol |
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
IETF 52 CalSched Working Group Meeting
Thursday 21-Mar-02
Minneapolis, MN
Introductions (Pat / Bob):
Quick poll of those in the room: 5 are "new" to the WG: several already on the list and 2 were "Curious Users"
Agenda:
Agenda Bashing
Guide to Internet Calendaring status
CalConnect status
CAP status
Bruce Kahn graciously steps up to be scribe.
Guide to Internet Calendaring (Pat):
The Guide has been approved for release as an RFC; in the queue for the actual number. The guide is intended to be used by implementers of the C&S standards.
CalConnect III (Pat):
The one scheduled for next week was cancelled due to several factors (proximity to IETF, travel concerns, etc). Novell still wants to host the next non-virtual CalConnect in Provo, UT. The next CalConnect will be a 'virtual' one and is slated for the June timeframe, probably before the next IETF in Japan. The goals/benefits of having it virtual are:
Decreased participation costs (supplemented by scheduled conference calls to keep things moving)
We should be able to do this in a "virtual environment" given our design criteria.
We will rely on secure instant messaging and regularly scheduled conference calls between participants.
Virtual event will have the following:
- Virtual environment will have the following:
- POP/IMAP/SMTP/FTP/HTTP servers
- A Secure collaborative environment for instant messaging, electronic conferencing, and discussion
= All dialogs will be encrypted
- Timed periodic conference calls with all attendees
- Expectation is you are available for the duration of the two days
- A set of scenarios to test and a table/matrix with items to test and "check off" as complete/broke/needs more testing
Currently there are 7+ vendors interested in participating; no word on any Open Source interest yet. Tentatively targeting August/September 2002 as the timeframe for the next "in person" event.
Calendar Access Protocol (CAP):
Steve Mansour went over the CAP items
Steve went over major items since the last meeting review. They were:
- Information inconsistency between transport layer and application layer - there is no clear separation between application and transport layers.
- A review VCARS and Queries is in order
- We need to add iCalendar extensions to draft
- Scheduling restriction tables need more work
- Obtaining the UPN after authentication in BEEP - Getting UPNs from BEEP;
Need UPN information to properly resolve other identity/security aspects in CAP but unclear how/if BEEP can provide this.
Next Steve went over the status of version 7 of the draft.
Slide items:
- Mixing of Transport and Application Data
- Fixed issues from last time
- A few things remain (ex: get-capability)
- Obtaining the UPN after authentication in BEEP
- Proposed Security Model Change:
- Current: deny unless explicitly granted
- Proposed: grant unless explicitly denied
We still have some mixing of the Transport and Application layers. This is due to lack of a clear definition of what each layer really is (it varies by reader so we must nail down the distinction and resolve the layering).
Getting UPNs from BEEP. Paul Hill, our security guy, went over this topic.
Paul is working with the BEEP and SASL folks to see what can be bubbled up for CAP to get/use. Currently, only WebMail is known to support it. We want to build BEEP and SASL on Windows (not only on Unix as is currently the case); Currently Paul is working on the port (as we have the WG meeting even). The model as it exists should work; He will look at it again to be sure once we have some more information.
The next topic was the proposal to change the security model: We want to go from an implicitly Deny w/explicit
Grants to an implicit Grant model w/explicit Denys. This scales better and is easier to evaluate.
Essentially the evaluation of access is done from the CS -> Calendar -> Entity levels where any Deny at any point prevents access "below" that point.
Steve, Paul and others will put together and propose some actual text pending tentative agreement on the conceptual change.
Slide items:
- SCHEDULE is gone, CREATE to cover it
- METHOD value verb or status (STATE)?
- BOOKED versus CREATED
- DELETED (remember tombstoning?)
- What properties MUST be maintained?
- iTIP method
- Abort versus bounded latency
- Do we need abort capability other than latency
- Reorder the draft so that it's easy to follow
- iCal extensions are currently at the end draft
The SCHEDULE command is gone. Reusing the CREATE command instead. This leads to some confusion about the use of METHOD in 'booking'; is METHOD a verb or a state?
DELETED is a new METHOD value added to codify the "Tombstone" concept we previously had [explicitly or implicitly at some points -BK]. We need to clearly define what the CS behavior is with respect to deleted entries (ie: exactly what MUST be preserved for sync and other reasons, etc and what MAY be preserved, etc).
ABORT vs Bounded Latency - Do we need to have an ABORT command?
WE need to reorder the draft to make it easier to follow. The layout is more than a bit hard to read [especially the ABNF that appears in the back after its used elsewhere
Slide items:
- UIDs for components:
- VCARs (Default, Predefined, Decreed)
- VALARMs
- Querys
- Stored Queries | do we need them?
- Scoping
- component.prop
- USING_PROPERTIES
- USING_COMPONENTS
- Querying for floating time events
It is unclear how UIDs for some components should be added and how to deal with uniqueness. Also, it was questioned how some of the VCARs function (ie: predefined ones: Are they 'templates' for creating instances in each VAGENDA or are they copied. If they are templates, thats a new concept. If they are copied then the UIDS are no longer unique.)
Regarding queries, how useful are stored queries given that the majority of queries used in C&S are 'time sensitive' and we have no ability to macro substitute values into saved queries. For example: Give me all my events that have an alarm that triggers in the next hour requires that the CUA send an explicit UTC time for the bounds. As such, tomorrow the query would be basically useless.
There are questions/issues regarding the scoping of queries: The design currently restricts them to COMPONENT.PROPERTY [without any clear reason apart from some apparently implicit assumption about the underlying actual search engine like SQL.
There is no clear definition for the use/need of USING_PROPERTIES and USING_COMPONENTS. They appear to be used as a form of shorthand at best without any functional need/description for them.
There is no way to query for "floating time" entries. The query code expressly declares that all queried time must be in UTC but thats not possible for the "Every morning I go jogging from 6AM - 7AM no matter where I am" case. "Floating time" (aka Local only) entries have no associated time zone and as such cannot be converted and stored in UTC.
Going forward:
Slide items:
- Post all issues to the list
= Analyses for all
= Recommendations for many
- Targeting getting issues posted by end of the month
- Work through the issues one at a time
All issues will be taken to the list. There should be an analysis of each one and preferably a recommendation for resolving them as well (in the interest of time). Target posting all of the issues is by the end of March 2002 to the WG list. We will work thru the issues 1 at a time instead of "flailing" on several at once and seemingly resolving none.
Pat will be the Keeper of Order. TBD will be the Keeper of Issues. Pat noted that there exist WG chair tools to aid in this process and she will investigate them and get the relevant parties up to speed on them.
The cochairs/editors want more WG feedback on postings (ie: more than just 2 people going back and forth on a topic). Pat suggests that the "techies" take care to put the painful technical details/explainations into Plain English (TM) for the rest of the WG so that "less techie folks" are more inclined to participate.
A quick poll shows that we may not have sufficient people to have a WG meeting in Japan. As such we want to get more progress done on the list before then.
We will deal with the layer issue first. Much of this is due to the BEEP changeover. We want to finish off the concerns of "XML creep" and the layer bleeding before we get back to the actual protocol details.
Pat put out a call for "anyone" with BEEPCOREC and SASL implementations to get engaged in dealing with this.
Larry noted that SASL is lightweight in design. MD5 is "heavy duty" as the minimum base for CAP authentication. There are lots of SASL implementations and they mostly interoperate. Larry asked why not just adopt XML now with the new work the WG is doing. He finds it confusing to have both XML and iCalendar in the draft. This gets back to the prior issue about XML creep that we need to finally resolve.
Steve responded that we could do the change but we need to make changed to xcal (which is expired now). Also, its odd to mix XML and iCalendar data but the mix is an artifact of the BEEP changeover. One example is the SEARCh command that is in XML but it has no data.
Larry pointed out the mix of data dn commands/actions (ie: search) in 1 blob is still confusing.
Steve: we need to better explain the mix in the design text and descriptions.
Wrapup (Pat):
The WG site calsch.org (or www.calsch.org) is up and has the drafts, texts and relevant links.
Meeting adjourned.
Respectively submitted by Pat Egen.
Slides
None received.