[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
IETF CALSCH Working Group                           Anik Ganguly/OnTime
Issues Document                                        Frank Dawson/IBM
<draft-ietf-calsch-ical-issues-01.txt>        Derik Stenerson/Microsoft
                                                         April 27, 1997



              Core Object Specification - Issues Document


Abstract

   This document is an IETF CALSCH working group document. The document
   is used as a tool for recording issues and their resolution with
   mailing list discussions.

   This Issues Document is intended to track the resolution of issues
   related to the "Core Object Specification" deliverable.

   The most current version of this document can be found on the IETF
   CALSCH Working Group document archive at http://www.imc.org.

   Issues within this document are classified as either being OPEN or
   RESOLVED. Additionally, an issue may be found to no longer be a
   concern and may be classified as WITHDRAWN. Issues falling into each
   of these categories are listed in a separate section.

   An issue is documented with a short summary title, a brief
   description, and a list of identified alternatives. A resolved issue
   will also include a description of the resolution and the date/venue
   that the resolution was reached.

   Distribution of this document is unlimited.

1.      Open Issues
The following issues were raised at the 1997-04-07 IETF CALSCH Meeting
in Memphis, TN


1.1  Recurrence Rule Grammar

   Description: What model/grammar should be used for representing
           recurrences within calendar component descriptions.

   Alternatives:

  1.      New grammar as defined in draft-ietf-calsch-ical-01.txt. The new
     grammar was based on the original CSA semantics, with a different
     syntax styled after the rest of the iCalendar specification. It
     also has been enhanced to handle a wider range of
     patterns/occurrences.

  2.      Original (vCal) grammar. This grammar is more terse. It has already
     been implemented by a number of vendors.



                                   11


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

1.2  Property Parameters

   Description: Property parameter use should be minimized.

   Alternatives:

  1.      Usage as defined in current draft

  2.      Redefine all properties to minimize usage of property parameters.
     The current format, while correct, is viewed as inelegant.

1.3  Divide the data dictionary into core/non-core

   Description: Classify the properties into a core subset of properties
   and the more complete set.

   Alternatives:

  1.      One complete dictionary of properties, listed alphabetically by
     their descriptive name (current draft format).

  2.      Divide the property set in to a "core" primary set and a secondary
     set of additional "non-core" properties.

  3.      Divide the property set by categories that describe their intended
     use (e.g., General Use, Identification, Recurrence, Time zone,
     Freebusy, Alarm, Entry Definition, Security, Management, etc.).

1.4  ValueType, Type, etc. usage confusing.

   Description: The use of the terms "Value Type" and "Type" as
   parameters of a property value are confusing.

   Resolution: This comment is accepted, and this editorial issue will
   be fixed in the next draft.

1.5  Usage of local time and Interoperability.

   Description: Local time usage needs to be clarified to avoid
   potential interoperability issues. Text must be clear so that the
   interpretations of time/date values are globally unambiguous to the
   recipient(s) of the calendar object.

   Usage of local time has a very specific interpretation for
   calendaring _ this means that the recipient of the calendar object
   interpret the time in the recipients local time (no adjustment for
   time zone). This allows for "floating" events; e.g."lunch" is at noon
   no matter where I am. In general, local time + time zone information
   (or UTC offset) is recommended.

   Some text exists in the current draft describing the meaning of
   local time with out time zone or UTC offset, but the text needs
   clarification.


                                  215


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

   Resolution: This comment is accepted, and this editorial issue will
   be fixed in the next draft.

1.6  Usage of non-significant LWSP

   Description: Non-significant LWSP-Characters can lead to
   interoperability problems.

   Alternatives:

   1. Non-significant LWSP-Characters should be restricted everywhere.

   2. Usage as in the current draft-ietf-calsch-ical-01.txt draft.

1.7  PROFILE-VERSION

   Description: Need for PROFILE-VERSION is questioned.

   Alternatives:

   1. Retain PROFILE-VERSION property to allow versioning of profiles.
   Revisioning, while ignored by some implementations, has been a known
   requirement for sometime.

   2. Eliminate PROFILE-VERSION property. Revisions to a profile
   specification are not versioned. Vendors generally ignore these
   properties anyway.

1.8  DUE property definition.

   Description: DUE property value should be limited to DATE-TIME, not
   allow DURATION

   Alternatives:

   1. Allow DUE property to be a DURATION. May be useful in project
   management applications where a task is specified in terms of its
   duration. This will also allow the specification of an originator's
   intent (i.e., "the task is due in three days", "the activity has been
   sized to take 12 hours").

   2. Limit to DATE-TIME. Use of duration adds an unnecessary
   complexity.

1.9  UID uniqueness hints needed

   Description: Ways of achieving UID uniqueness need to be described.

   Resolution: This comment is accepted, and this editorial issue will
   be fixed in the next draft.





                                  315


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

1.10 Complex Registration Process

   Description: The PROFILE registration process is complex. Separate
   definition of new profiles from the registration process. New
   PROFILEs to be published as an RFC.

   Resolution: This comment is accepted, and this editorial issue will
   be fixed in the next draft.

1.11 BNF definition

   Description: Change BNF to an acceptable form. Use a single
   specification, rather than the iterative form in the current
   document. Noted that the iterative form can lead to inconsistencies
   across the overall grammar.

   Resolution: This comment is accepted, and the editors will work with
   Ned Freed to correct this issue in the next draft.

1.12 MIME encoding considerations

   Description: Insure conformance to MIME. Current draft does not
   conform to MIME encoding with respect to quoted-printable. Change
   text needed here.

   Resolution: This comment is accepted, and the editors will work with
   Ned Freed to correct this issue in the next draft.

2.      Resolved Issues

2.1  Scope and Application of Specification

   Description: Should the specification be defined with the intent that
           the content type is to be used solely within a SMTP/MIME
           message transport or should there be a broader scope and
           application taken into the definition of the specification?

   Alternatives:

        1.           The specification should be designed with the scope and
          application target of just the SMTP/MIME messaging transport.

        2.           The specification should be designed with the scope and
          application target of just the IETF transport protocols.

        3.           The specification is for an industry calendaring and
          scheduling standard. The scope and application target should
          be a broad range of IETF and non-IETF transport protocols.

   Resolution: Alternative 3. (Working Group Charter/1996-10)





                                  415


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

2.2  Property Syntax

   Description: What syntax should be used to represent individual
           properties or MIME body elements within the specification?

   Alternatives:

        1.           Properties are to be defined using the syntax from vCalendar:
                propname *[;parmname "=" parmvalue] ":" propvalue

        2.           Properties are to be defined using the syntax from the July
          1996 Microsoft document:
                propname ["," parmname "=" parmvalue] ":" propvalue

   Resolution: Alternative 1. (Mailing List/1996-12).

2.3  Ordering of Properties

   Description: Should the specification require ordering of properties?

   Alternatives:

        1.           No. There is not ordering requirement for properties, other
          than sentinel properties.

        2.           Yes. The ordering of some properties is important.

   Resolution: Alternative 1. (Mailing List/1996-11)

2.4  Specification of Usage Profiles

   Description: How should the specification encode the originator's
           intent with respect to the usage profile for content
           information conforming to the specification?

   Alternatives:

        1.           Include within the specification a new MIME header field
          CONTENT-PROFILE that will declare the intended usage profile.

        2.           Include within the specification a new "profile=" header
          field parameter for the MIME Content-Type header field. This
          parameter will declare the intended usage profile.

        3.           Include within the specification both a new "profile=" header
          field parameter for the MIME Content-Type header field and a
          new optional PROFILE property for the content information.
          These two elements will be used to declare the intended usage
          profile. The PROFILE property is needed within the content
          information in the event that the content information is
          transported using a non-MIME messaging transport, but is not
          required when the content information is transported in MIME.

   Resolution: Alternative 3 (Mailing list/1996-12).

                                  515


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

2.5  Strong, Explicit Data Typing

   Description: Should the specification include the definition of
           properties with strong data typing?

   Alternatives:

        1.           The specification should implicitly define the data types for
          the properties within the specification. While the content
          information itself does not include any explicit data typing
          information with the properties, it is defined within the
          specification.

        2.           The specification must include a mechanism for explicitly
          defining the data types for the properties within the
          specification. The content information includes explicit data
          typing with a VALUETYPE property parameter. A minimal set of
          value data types are defined by the specification. Additional
          value data types can be registered within the IANA
          registration procedures. The value data type must be
          explicitly declared on each property within the content
          information.

        3.           The specification must include a mechanism for explicitly
          defining the data types for the properties within the
          specification. Additionally, the specification must include a
          default value for the data type; in the event that the value
          data type is not explicitly specified in the content
          information. The content information includes explicit data
          typing with a VALUETYPE property parameter. A minimal set of
          value, data types are defined by the specification.
          Additional value, data types can be registered within the
          IANA registration procedures. The value, value data type may
          be explicitly declared on each property within the content
          information. If the value data type is not specified, it is
          defaulted to the default data type for the property value.

   Resolution: Alternative 3. (Mailing list/1996-10)

2.6  Minimalization of Property Names

   Description: Should property names be specified using the verbose
           style of MIME or a more minimal style for "low chat" and
           "small foot print" devices?

   Alternatives:

        1.           Use the verbose style of MIME for defining names. This is
          easier to read and comprehend.

        2.           Use a minimal, short name for properties. This is more
          suitable for small size datagrams. In addition, it is
          friendly to "low chat" transports and small "foot print"
          devices, like a PDA.

                                  615


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

   Resolution: Alternative 1. When creating property names, make them as
           short as possible. (Mailing List/1996-11)

2.7  Multi-valued Property Values

   Description: Should property values be allowed to have multiple
           values?

   Alternatives:

        1.           No. A property value can only appear once in a content
          information with one value.

        2.           Yes. A property value may appear multiple times in a content
          information with multiple values.

   Resolution: Alternative 2 (Mailing List/1996-11)

2.8  Data Syntax/Base Core Object Specification

   Description: What semantics should the iCalendar specification be
           based on?

   Alternatives:

        1.             Base the specification on the vCalendar document. This
          includes a model of a calendar object as a conceptual
          container for calendar components including events and todos.
          This model is heavily borrowed from the XAPIA and X/Open
          Calendaring and Scheduling API (CSA) which represents a data
          model that has some broad consensus among a group of
          calendaring and scheduling vendors. It has also been
          implemented on over four operating system platforms by
          numerous vendors.

        2.             Base the specification on a set of semantics that is new and
          developed within the IETF. Where appropriate, utilize the
          best ideas from existing products or model specifications to
          derive a standard based on the consensus of the IETF
          Calendaring and Scheduling Working Group.

   Resolution: Per the pre-working group meeting, we've decided to use
   the CSCT draft as our starting point for the working group spec. The
   entire draft is up for review and group consensus will be reflected
   in any modification made to the draft.  Modifications, as needed,
   will be made via postings of change text to the list. Posting should
   indicate the "broken" component of the existing specification.

2.9  Attendees In MIME Header Fields and Content Body

   Description: When calendar components are transported in the form of
           a MIME message, how should the attendees be specified?

   Alternatives:

                                  715


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

        1.           Attendees specified using the RFC-822 addressing fields.  For
          example, "To:" header are "required", those in the "Cc:"
          header are "optional", etc.

        2.           Attendees specified with the "ATTENDEE" properties in the
          content information.

        3.           Attendees specified by 1 and 2.

        4.           Attendees specified by 1 and optionally 2,where 2 has
          precedence over 1 if 2 is specified.

   Resolution: Alternative 2, Attendees specified with the "ATTENDEE"
   properties in the content information.

2.10 Non-Gregorian Calendar

   Description: Should support be provided in the specification for
           specifying calendar components using non-Gregorian calendar
           systems?

   Alternatives:

        1.           No. Only Gregorian-based descriptions of calendar components
          are supported?

        2.           Yes. The specification should support specification of
          calendar components using a non-Gregorian calendar scale.

   Resolution: Modification of alternative 2. A mechanism for specifying
   alternate calendar types will be defined: a calendar scale property
   will allow the calendar scale to be named. However, the specification
   will only define behavior for the Gregorian calendar scale. Alternate
   calendar types and their behaviors, conversion rules, etc. will be
   defined in separate documents.

2.11 Property Definition (Normalization)

   Description: Should data type values be defined using simple base
           data types or should we allow structured data types (like a
           'C' struct)?

   Requirements: Solution must have

          .  Mechanism for grouping.

          .  Named parameters for simplified parsing/ease of
             extensibility

          .  Extensibility

   Alternatives:



                                  815


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

        1.Type name and value consisting of multiple data types
          combined.

          For example:
                DALARM:19960415T235000;PT5M;2;Your Taxes Are Due !!!

          The advantage of this format is compactness of the data.  The
          disadvantage is the cost of more specialized parsing code
          that is required to break this specialized data type apart
          and extract the base data type components.

        2.Type name and value consisting of a single base data type.
          (Normalized).

          For example:
                DALARM-DATE:19960415T235000
                DALARM-REMIND:000500
                DALARM-SNOOZE:2
                DALARM-MESSAGE:Your Taxes Are Due !!!

          The disadvantage of this format is compactness of the data.
          The advantage is that generic parsing code can be used and no
          specialized data types beyond the base data types (string,
          date-time, etc.) need to be defined.


        3.Combine alternative 2 with the BEGIN:ALARM/END:ALARM, to meet
          the grouping requirement.

        4.Use TERM CAPS type model.  (Need someone to expand on this.)

        5.Combine alternative 2 with MIME-DIR style grouping.  Allows
          for unambiguous, multiple occurrences of property.  Example:
                A.DALARM-DATE:19960415T235000
                A.DALARM-REMIND:000500
                A.DALARM-SNOOZE:2
                A.DALARM-MESSAGE:Your Taxes Are Due !!!


   Resolution: Alternative #3 was used when the ALARM and DAYLIGHT
   properties were redefined in the current specification.

2.12 Content Type

   Description: What content type and subtype should be specified in the
           specification?

   Alternatives:

        1.           Use the "application/calendar" content type/subtype. The
          purpose of the "application" Content-Type as defined in
          section 7.4 of [RFC-1521] is "for data to be processed by
          mail-based uses of application programs." Calendaring and
          scheduling data falls into this category as recommended by

                                  915


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

          [RFC-1521]. The "application/calendar" Content-Type is used
          to hold textual calendaring and scheduling information.
          Applications that want to supply a textual representation for
          legacy systems should use multipart/alternative with a
          text/plain representation and an application/calendar
          representation.

        2.           Use the "text/calendar" content type/subtype. The
          specification uses a clear-text format that is reasonably
          readable. In addition, the default action for MIME user
          agents that do not understand the "calendar" subtype will be
          to render as a "text/plain" content type/subtype. This is
          what will need to be done for all legacy systems. This is a
          very important constituent for this content type. Otherwise,
          the content type would be rendered as a binary attachment.

        3.           Use a framework media type such as being used in MIME-DIR.

   Resolution: Alternative #2 was used.  Of additional note, the MIME-
   DIR framework media type has changed to be text/directory from
   application/directory.

2.13 BEGIN/END Content Sentinel Properties

   Description: Should the MIME calendaring and scheduling content
           include a BEGIN and END sentinel property?

   Alternatives:

        1.           Include the BEGIN/END sentinel properties. These properties
          will allow the content to be identified outside of the MIME
          message transport. They do have any significant overhead.

        2.           Do not include the BEGIN/END sentinel properties. They are
          not needed in the MIME encapsulation of the content type.
          Having another mechanism for delimiting MIME objects, adds to
          the overhead required to parse such objects, particularly if
          multiple calendaring and scheduling objects are permitted in
          a single body part.  On the other hand, using the
          encapsulation methods provided by MIME allows applications to
          leverage protocols, such as IMAP, extract individual
          calendaring and scheduling content objects.

   Resolution: Alternative #1. We have found them to be useful in
   grouping as well as bounding the content.

2.14 Date and Time Format

   Description: What date and time format should be used for properties
           with date and time value types?

   Alternatives:



                                  1015


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

        1.           Use the revised RFC 822 date and time format defined by RFC
          1123. This is the format that is used within the MIME
          messaging transport. It is also used by numerous IETF
          protocols.

        2.           Use the ISO 8601 based date and time format defined by the "-
          csct-01.txt" Internet Draft. This is the format that is used
          with

   Resolution: Alternative #2, ISO 8601 date and time format. Explicit
   BNF for this format has been included in the iCalendar document.

2.15 DST Rule Support

   Description: Should the specification for Time Zone include support
           for specifying the behavior and rules DST? If so, what format
           should be used?

   Alternatives:

        1.           No. The specification should not include support for
          calendaring functionality that depends on the specification
          of the behavior and rules for DST observance.

        2.           Yes. The specification should include a property that defines
          the behavior and rules for DST observance; based on the POSIX
          model. This would include a Boolean value defining DST
          observance, the offset from UTC for standard time, offset
          from UTC for daylight savings time, date and time or
          recurrence rule for beginning standard time, date and time or
          recurrence rule for beginning DST, optional string for the
          standard time zone name, optional string for the DST zone
          name.

        3.           Yes. The specification should include a set of properties
          that define the behavior and rules for the time zone.   This
          would include at a minimum the time zone time delta from the
          prime meridian. In addition, if necessary (if DST is
          observed): a) a time delta used in DST, b) a Standard Time
          transition rule, i.e. a recurrence rule or list of absolute
          date/times; and c) a DST transition rule, i.e. a recurrence
          rule or list of absolute date/times.  Additional optional
          properties may be desirable including a Time Zone
          identifiers, a time zone name  for STD and DST time, a date-
          stamp to indicate "freshness" of the time zone rule, a URL to
          standardized time zone rule definitions, etc.

   Resolution: A variant on Alternative #3. A new VTIMEZONE component
   was added to encapsulate the behavior and rules for the time zone.






                                  1115


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

2.16 Exceptions To Recurrence Rules

   Description: How should exceptions to a recurrence rule be specified
           (e.g., as a sequence of dates, an exception recurrence rule,
           or optionally both)?

   Alternatives:

        1.           The recurrence model should support the specification of
          exceptions to the recurrence as a sequence of dates.

        2.           The recurrence model should support the specification of
          exceptions to the recurrence as a sequence of dates and
          optionally an exception recurrence rule or both.

   Resolution: Alternative #2.

2.17 Infinite Recurring Patterns

   Description: Should the recurrence rules allow for an infinite number
           of recurrences?

   Alternatives:

        1.             No. The recurrence rules need to specify a finite number of
          occurrences.

        2.             Yes. The recurrence rules need to allow for an open-ended,
          infinite number of recurrences.

        3.             Yes. The recurrence rules need to allow for open-ended
          recurrence rules. However, there also needs to be a way of
          specifying a stop date or count to the open-ended recurrence
          rule.

   Resolution: Alternative #3 as drafted in the new recurrence grammar.

2.18 Non-Standard Extensibility

   Description: Should the specification support a formal method for
           making "non-standard" extensions to the specification?

   Alternatives:

        1.           No. The specification should limit support for extensions in
          order to maximize possible interoperability.

        2.           Yes. The specification should include the RFC 1521 method of
          "X-" tags for non-standard extensions to the property names
          and values and non-standard extensions to the property
          parameter names and values. Standard extensions should also
          be supported via the IANA registration process of new
          property names and values or new property parameter names and
          values.

                                  1215


IETF CALSCH   Core Object Specification - Issues Document
                            04/27/9704/27/97

   Resolution: Alternative #2. IANA registration is preferred, but "x-
   token" non-standard properties and property parameters, as well as,
   enumerated values are allowed.

2.19 Model for iCalendar needs to be defined.

   Description: Need a clear description of the model used by iCalendar.

   Resolution: Agreed this will either be a separate document (general
   consensus) or added as an introduction to the iCalendar document.

3.      Withdrawn Issues

3.1  Functional Completeness

   Description: What types of scheduling functionality should be
           included in the specification?

   Alternatives:

        1.           Just include support for requesting, replying-to and
          canceling an event.

        2.           Begin with the base concepts of requesting, replying-to and
          canceling an event.  Add additional functionality that is
          deemed as required by the group.

        3.           Start with as full a set of scheduling functionality as
          possible (e.g., requesting, replying-to, canceling,
          modifying, replacing, resending, negotiating events and
          todos, as well as requesting and replying-to free/busy time
          requests.).  Let the group decide what to add and remove.

   Resolution: Alternative #3 fairly closely represents the decision of
   the group by accepting the CSCT draft as the basis for the core
   object specification.  However, the issue is still valid in the
   context of the Calendaring and Scheduling Content Type Profile
   document <draft-ietf-calsch-csp-xx.txt> and should be addressed
   there.
















                                  1315