2.1.2 Calendaring and Scheduling Simplification (calsify)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-02


Cyrus Daboo <daboo@isamet.com>
RL Bob Morgan <rlmorgan@washington.edu>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Calendaring and Scheduling is currently defined in RFCs 2445, 2446 and
2447. These documents have been available for several years now, and a
number of implementations exist. However, a number of interoperability
problems exist between these implementations, some due to bugs in the
specifications, some due to lack of clarity in the specifications and
some due to under specification of key behaviors. As a result,
interoperable calendaring and scheduling has not been truly achieved.

The purpose of this BOF is to discuss revising RFCs 2445, 2446 and 2447
with the primary goal of achieving interoperability over the range of
calendaring and scheduling tasks needed in real world situations. The
goal of the BOF is to come up with a clear direction on how those
revisions should be done, including the scope of changes. The desired
outcome is a set of major charter points and milestones for a proposed
IETF calsify working group.

Input to this BOF will be a problem statement internet-draft
draft-daboo-calsify-issues-00.txt that pulls together existing document
errata, known problems with the specs and results from interoperability
tests. In addition, draft-royer-ical-basic-01.txt provides one possible
direction for revisions.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Minutes of CALSIFY BOF at IETF 62, 10-Mar-2005

(Raw log at <http://www.xmpp.org/ietf-logs/calsify@ietf.xmpp.org/2005-03-10.html>)


Bob runs through presentation (slides included with proceedings)

C: - comment
Q: - question
A: - answer

C: CPL (Call processing language) also depends on iCal - RFC3880.

Q: Test cases generated from use cases from existing data is useful. How does that interact with approaches in presentation?

A: Could be 'item 0' on possible approaches.

C: Test cases have been useful to deal with interoperatibility issues with RDF/iCalendar stuff. Is that different from the approaches considered here? or is it implicit in the approaches you've listed.

C: We could look at this as IETF draft standard process: those features that we can show working stay, those that don't go.

C: This looks like a familiar list of issues the goal, and the value of this work, should be very clear. So first folks should agree what benefits we're looking for, and then the tasks should flow from that.

Q: I'm boggled by the notion that "This has the side-effect of removing the need to specify timezones". You don't know the timezone offset when you schedule an event in the future

A: That's not what we mean by "getting rid of timezones". What we mean is that we can pass them around by reference, rather than by copy [to paraphrase]

A: Perhaps doing recurrences based on [this sort of] timezone is too hard

Q: major changes are only relevant if we're doing redesign. if we're just finishing the draft standard work, it's not needed

A: I think there's enough that needs to change that we'd need to go back to proposed regardless

C: One thing we may want to change is the version info that iCalendar doesn't provide.

Q: What _needs_ to change?

A: A real interop problem is changing an instance of a recurring meeting, across the lotus notes/ms outlook boundary.

A: In an odd case, the pope came to Brazil and daylight savings time changed suddenly. [?] in that case, meetins scheduled in Brazil should work, though interop with places outside Brazil would break.

Q: That two vendors don't interoperate... does that mean the spec is broken?

A: The IETF bar for draft standard is two interoperable implementations.

Q: re changing syntax..

A: Having lots of experience with syntax wars, I don't see much value. You could spend a lot of time and not improve much, by looking at XML.

A: Syntax issues should be trivial once the domain is properly spec'd and understood.

A: There's a mistaken impression that XML tools are going to solve problems, but they're not.

A: Either (1) keep RFC2441 syntax and transform ... or (2) completely scrap 2445 and start again.

A: I wrote a draft, went thru the excercise of converting to/from XML ... convinced myself it's doable...

A: folks that only want an XML parser might want it... there are also XML-based vcards flying around in jabber

C: please take 2445 to draft standard; converting to XML is fun work, but it's different work.

C: Semantics are always harder than syntax; it's semantics where iCalendar is weak.

C: Doing the conversion in parallel [outside this work] seems best.

C: CPL specifies a mapping from iCalendar to XML.

C: CPL's subset isn't really appropriate for full iCalendar, though. It's just RRULEs.

C: Transform to XML is not a bad idea; just don't let it interfere with this work.

C: ABNF defines the problem domain in 2445 et al. You can drop your syntax on top of that (in separate drafts even).

C: As CPL author, I don't care if I have to do a mechanical transformations from some other format than RFC 2445.

C: clarification of RFC2445 could have impact on CPL.

C: we had nightmares with recurrence... [in CPL]. did we write down the problems? perhaps... - I've not written down a specific document. Some of it's on the ietf-calendar list archive, some on the iptel list archive.

C: CPL isn't in _wide_ use, but I've seen some deployment, e.g. at vonage.

Comments on Editing Goals:

C: Figuring out what subset of iCal works now, pushing it to DRAFT standard.

C: If it's cleanly subsettable...you can't easily pull off the fuzzy corner cases of RRULE from the main parts that everyone agrees on.

C: Document what's currently unsatisfactory.

C: consider upgrade and version problems so that, e.g., sending invitations isn't completely stuck at lowest-common-demoninator
e.g. negotiation in CalDAV.

C: in email, you can use multipart/alternative for that.

C: limit what we add to what is required by IETF process, i.e. Internationalization in order to avoid new interoperability problems

C: poll for support on calisfy taking on XML transform. XML produced by a transform, as opposed to designed as XML, is going to be ugly, and it won't get support as an individual submission.

C: there's a lot of web-based XML calendaring stuff out there, but it doesn't seem in scope

C: perhaps the WG should be chartered to consider whether or not to do the XML transform.

Q: perhaps it's premature to call for support in a WG, since we don't have a charter... Mr. AD?

A: AD we've just spent 90 minutes without anyone saying this shouldn't happen. So the next step is to put your draft together...

Q: is there a chance of having a WG before the next IETF?

A: AD: expect a month turn around from 1st draft charter to WG

Volunteers for charter writing called for...Lisa + others offer to do first charter and post to list