2.1.2 Calendaring and Scheduling Standards Simplification (calsify)
NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
Last Modified: 2005-10-03
Lisa Dusseault <email@example.com>
Aki Niemi <firstname.lastname@example.org>
Applications Area Director(s):
Ted Hardie <email@example.com>
Scott Hollenbeck <firstname.lastname@example.org>
Applications Area Advisor:
Ted Hardie <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Description of Working Group:
The Calendaring and Scheduling standards, defined in RFC's 2445, 2446,
and 2447 were released in November 1998, and further described in RFC
3283. They were designed to progress the level of interoperability
between dissimilar calendaring and scheduling systems. The Calendaring
and Scheduling Core Object Specification, iCalendar, succeeded in
establishing itself as the common format for exchanging calendaring
information across the Internet. On the other hand, only basic
interoperability as been achieved between different scheduling systems.
The Calsify working group is chartered to:
(1) Publish the interoperability issues that have arisen between
calendaring and scheduling systems, as well as document the usage of
iCalendar by other specifications.
(2) Revise the Calendaring and Scheduling standards to advance the
state of interoperable calendaring and scheduling by addressing
the published interoperability issues. As far as it is possible, the
working group will ensure backwards compatibility with widely deployed
implementations and other specifications that use it.
(3) Clarify the registration process for iCalendar extensions (i.e.,
the current core object specification only provides a template
to register new properties).
(4) Advance the Calendaring and Scheduling standards to Draft Standard.
(5) Work on transition (upgrade or versioning) mechanisms for calendar
Proposing an XML representation or transformation of iCalendar
objects is out of the scope of this working group.
Goals and Milestones:
|Jul 2005|| ||Submit draft documenting interoperability issues for use in
progressing RFCs to Draft Standard. |
|Sep 2005|| ||Submit iCalendar bis draft 00, with formatting changes from
|Sep 2005|| ||Submit iTIP bis draft 00 |
|Sep 2005|| ||Submit iMIP bis draft 00 |
|Oct 2005|| ||Submit revised interoperability issues draft version based on
WG discussion. |
|Dec 2005|| ||WG decision on what document(s) require transition mechanisms
and hopefully rough idea what these will look like (and add new
goals if needed) |
|Mar 2006|| ||WG last call on interoperability issues draft. |
|May 2006|| ||Submit interoperability issues document to IESG for
Informational RFC. |
|May 2006|| ||Submit version of iCalendar bis draft that addresses known
interoperability issues from interop events. |
|Jun 2006|| ||Submit versions of iTIP and iMIP that address known
interoprability issues. |
|Jul 2006|| ||Submit version of iCalendar draft that addresses WG open
|Sep 2006|| ||Submit version of iCalendar draft ready for WG last call. |
|Nov 2006|| ||Complete WG last call of iCalendar and submit new draft. |
|Nov 2006|| ||Submit versions of iTIP and iMIP ready for last call. |
|Jan 2007|| ||Submit iCalendar (bis) to IESG for Draft Standard. |
|Jan 2007|| ||Complete WG last call of iTIP |
|Feb 2007|| ||Complete WG last call of iMIP |
|Mar 2007|| ||Submit iTIP to IESG for Draft Standard. |
|Apr 2007|| ||Submit iMIP to IESG for Draft Standard. |
No Request For Comments
Current Meeting Report
[13:37:49] --- DougRoyer has become available
[15:23:52] --- Jason has become available
[15:24:06] --- Jason has left
[15:27:32] --- bdesruisseaux has become available
[15:34:58] --- bdesruisseaux has left
[17:56:43] --- Jason has become available
[17:56:57] --- Jason has left
[18:33:59] --- Jason has become available
[18:34:08] --- Jason has left
[19:22:20] --- bdesruisseaux has become available
[19:22:39] The slides are available online: http://ietf.webdav.org/calsify/meetings/IETF64_CALSIFY.ppt
[19:24:56] Audio streaming: http://www.ietf.org/audio//ietf645.m3u
[19:30:46] --- Jason has become available
[19:31:40] --- Jason has left: Disconnected
[19:36:41] --- Jason has become available
[19:40:49] --- Jason has left
[19:41:08] --- cyrus_daboo has become available
[19:42:22] Well this is my dinner time.
[19:43:29] --- kmurchison has become available
[19:46:11] --- Jason has become available
[19:48:22] --- tonyhansen has become available
[19:50:08] --- pguenther has become available
[19:50:18] agenda bashing
[19:50:19] * pguenther starts to scribe, or something
[19:50:29] I'll tag team with you
[19:50:31] --- rlbob has become available
[19:50:42] * pguenther turns on the 'echo' effect
[19:51:15] Yes I am here!!!
[19:51:41] cyrus: can you hear Bernard?
[19:51:49] Yes he is loud and clear.
[19:51:51] status update
[19:52:05] new -00 draft of rfc2445bis
[19:52:34] separate rfc2445bis-issues draft for traacking stuff
[19:52:49] "to make sure all the issues raised are closed"
[19:53:20] minor edits by Bernard and Chris
[19:53:27] Active Threads:
[19:53:44] VFREEBUSY: can it be used to block off time in calendars?
[19:53:52] Has anyone thought of using a Wiki for group Collaboration. It may be easier then the spreadsheet to issues list?
[19:54:22] or are they just queries?
[19:54:35] --- email@example.com has become available
[19:54:36] The IETF tools team has a list of issue tracking systems that other groups are using. One of those might be appropriate.
[19:55:13] --- corby has become available
[19:55:20] We should clarify VFREEBUSY in iCalendar.
[19:55:30] (2445bis I mean).
[19:55:51] semi-proposal: they should be able to live in your calendar and block off time
[19:56:40] --- firstname.lastname@example.org has become available
[19:56:45] next: how to derive VFREEBUSY from VEVENT in a calendar?
[19:56:58] part is controlled by organized
[19:58:08] also, does PARTSTAT parameter of the calendar owner be considered?
[19:58:20] --- alexeymelnikov has become available
[19:58:21] no consensus on vfreebusy
[19:59:02] other properties that ownership/"who can modify" semantics need clarification on
[20:01:37] how are those handled in calendars that exist as shared calendars?
[20:02:03] e.g., can user A modify the transparency of user B?
[20:02:41] any feedback?
[20:02:55] --- kmurchison has left
[20:03:00] on to 2446bis
[20:03:12] cyrus: any comments
[20:03:22] I did send two points I wanted to discuss.
[20:03:53] lisa is looking
[20:03:56] 1. Format of abnf vs tables. In 2445 pseudo abnf is used to describe which components are allowed etc.
[20:04:06] In iTIP tables are used to describe the same thing.
[20:04:26] We should ideally standardise on one format or the other. What do people think?
[20:05:33] OK, I will liaise with Chris/Bernard.
[20:05:56] 2. I also want an issue tracker and can setup my own but would prefer general WG tracker if possible.
[20:06:36] Other than that the 2446bis draft is really just a clone of the original. I will get around to much more re-org/bug fixes for the next version.
[20:07:41] on to interop report
[20:07:58] 2445: everyone does _not_ do:
[20:08:14] - separate values in a list with commas,
[20:08:50] see slides on the site for the complete list
[20:09:43] 9 orgs and sep interop
[20:14:04] (all in the slides)
[20:14:33] --- lisa has become available
[20:19:50] --- email@example.com has left
[20:20:10] any comments on anything from these slides?
[20:21:23] discussion about consortium meeting on the side that provides input into calsify
[20:22:43] alexey is up, talking about 2447bis
[20:22:46] Its all gone quiet...
[20:22:59] OK - Alexey is back.
[20:23:23] (lisa was having tech difficulties -- pause in the action while she did so)
[20:26:27] open issues:
[20:26:44] 1) is "method" C-T parameter required? uses "must" not "MUST" right now
[20:27:02] common clients (e.g., Thunderbird) don't set it
[20:27:20] should "must" be "MUST" or "SHOULD"?
[20:27:58] METHOD will be set in the actual iCalendar object, so the question is is it useful to the client to have it in MIME too?
[20:28:01] Bernard: if no "method", then you're just sending an object and not doing iMIP
[20:28:17] No - Bernard - METHOD is in the iCal object.
[20:28:41] The mthod= MIME parameter is simply a hint to the client about what is inside.
[20:29:40] Philip: does this create a silly-state if they don't match?
[20:30:14] lisa: no proposal on how to fix, so take to list
[20:30:36] todo #2: add example for q-p and base64
[20:30:38] Yes, but its no worse than the charset= not representing the actual charset being used!
[20:30:51] todo #3: add IANA considerations
[20:32:13] todo #4: section on using Content-Disposition to work around bad content-type support
[20:32:28] proposal: drop like a lead brick
[20:33:31] todo #5: insufficient specification of how authorization of changing other people's calendars is done, so how can we require it?
[20:33:59] (this is in section 3: "...implementaitons MUST provide mechanisms...")
[20:34:30] --- firstname.lastname@example.org has become available
[20:34:46] lisa: regarding using a wiki: recommend against
[20:35:56] last chance for comments
[20:35:59] too late
[20:36:03] * pguenther laughs evilly
[20:36:07] --- email@example.com has left
[20:36:15] meeting is closed
[20:36:15] --- alexeymelnikov has left
[20:36:17] ya ha ha ha
[20:36:24] --- tonyhansen has left
[20:36:27] --- pguenther has left
[20:36:36] --- firstname.lastname@example.org has left
[20:36:46] --- cyrus_daboo has left
[20:37:48] --- Jason has left
[20:38:05] --- rlbob has left
[20:38:31] --- bdesruisseaux has left
[20:41:57] --- lisa has left
[20:44:17] --- corby has left
[20:50:08] --- lisa has become available
[21:01:51] --- bdesruisseaux has become available
[21:04:46] --- bdesruisseaux has left
[21:49:15] --- lisa has left