2.1.2 Calendaring and Scheduling Standards Simplification (calsify)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-27

Chair(s):

Lisa Dusseault <lisa@osafoundation.org>
Aki Niemi <aki.niemi@nokia.com>

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: ietf-calsify@osafoundation.org
To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

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:

Jul 05  Submit draft documenting interoperability issues for use in progressing RFCs to Draft Standard.
Sep 05  Submit iCalendar bis draft 00, with formatting changes from RFC2445.
Sep 05  Submit iTIP bis draft 00
Sep 05  Submit iMIP bis draft 00
Oct 05  Submit revised interoperability issues draft version based on WG discussion.
Dec 05  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 06  WG last call on interoperability issues draft.
May 06  Submit interoperability issues document to IESG for Informational RFC.
May 06  Submit version of iCalendar bis draft that addresses known interoperability issues from interop events.
Jun 06  Submit versions of iTIP and iMIP that address known interoprability issues.
Jul 06  Submit version of iCalendar draft that addresses WG open discussions.
Sep 06  Submit version of iCalendar draft ready for WG last call.
Nov 06  Complete WG last call of iCalendar and submit new draft.
Nov 06  Submit versions of iTIP and iMIP ready for last call.
Jan 07  Submit iCalendar (bis) to IESG for Draft Standard.
Jan 07  Complete WG last call of iTIP
Feb 07  Complete WG last call of iMIP
Mar 07  Submit iTIP to IESG for Draft Standard.
Apr 07  Submit iMIP to IESG for Draft Standard.

No Current Internet-Drafts

No Request For Comments

Current Meeting Report
clasify CALSIFY meeting notes from IETF 63

 
- agenda bashing
  - overview
  - http://ietf.webdav.org/calsify
- charter review
  - document interoperability and usage issues
  - revise calendaring and scheduling for advancing to draft
  - work on transition effort
- announcements
  - various suspects^Wauthors
  - PROTO is in effect
  - warning: moving to draft may leave products behind
    - ...but advanced features (by-second occurance) may be dropped
    - Pete: question on process of moving to draft
      - What does "independent" mean?
        - Ted: codebases are independently developed
        - ...but language in std should be changed to reflect outside agreements
- Lear: if the feature velocity is high, whether negative or positive, then another round at proposed may be in order
  - calDAV not in scope
  - planned US timezone change
- 2445bis strategy
  - simplify and *tighten*
  - a plea for implementors to keep up with drafts
- interop data
  - calconnect work (recurrences, timezones)
    - why was stuff left out of implementations
    - rescheduling of overlapping entries varied wildly
    - unbounded rules
    - ackward rules
      - e.g. "30st of each month"  What about Feb?
    - timezones
      - support for finite sets on servers
      - arbitrary zones not realistic
  - use case data (Jeff)
    - (list of stuff that has few implementations)
    - Patrick Fahlstrom: need abstraction layer between events and timezones, e.g., a 'location' that could move.  Urge group to step back and figure how to handle this
      - discussion of example
      - Chris Newman: Olson DB uses locations for names
        - Lear: sufficiently normative?
- Chris Newman: ain't nothing better
- Lear: but how to map from name to zone data?
- Chris Newman: use the database
- Pete Resnick: UN may have better now?  <silence>
- Ted Hardie: think hard about two uses:
  - stuff involving humans
  - stuff that is scheduled sans humans
        - Nathaniel: zone data change; an IANA registry can fix that
  - Rowan: hard to stuff this in IANA
  - Randy Presuhn: language tag registry has similar problems,
    you have to tag entries with dates, e.g.
  - Patrick: this confirms need to abstract timezone
  - Corby: client had TZ data, converted all to UTC+/-NNNN
   - <various examples of pain pain pain>
   - Bob Morgan: use cases critical to resolve pain
    - Doug Royer's draft to be made managable by IANA
      - political and process issues are complicated
      - Bernard: Oracle implementation looks up stuff
      - Keith: just listing issues may be valuable
      - Patrick: need special effort for TZ handling?
- Chris: perfect is impossible; Good Enough must be sufficient; QoI issue
- Pete: willing to look into political issue (UN)
- Ted: protocol service of interest?
    - Lisa: interop issues are *NOT* just about TZ
 

Slides

Agenda