IETF CALSCH Working Group                           Anik Ganguly/OnTime
Issues Document                                        Frank Dawson/IBM
<draft-ietf-calsch-ical-issues-00.txt>
<draft-ietf-calsch-ical-issues-01.txt>        Derik Stenerson/Microsoft
Expire in six months                                   February 2,
                                                         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 "Core Object Specification_ 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 is are listed in a separate section.

   An issues 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     Property Definition (Normalization)  Recurrence Rule Grammar

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

   Alternatives:

  1.      New grammar as defined using simple base
           data types or should we allow structured data types (like in draft-ietf-calsch-ical-01.txt. The new
     grammar was based on the original CSA semantics, with a
           'C' struct)?

   Requirements: Solution must have

          .  Mechanism for grouping.

          .  Named parameters for simplified parsing/ease different
     syntax styled after the rest of
             extensibility

          .  Extensibility

   Alternatives:

        1.Type name and value consisting the iCalendar specification. It
     also has been enhanced to handle a wider range of multiple data types
          combined..

                                   1
     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      02/03/97

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

          The advantage of this format is compactness
                            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 the data. property parameters.
     The
          disadvantage current format, while correct, is viewed as inelegant.

1.3  Divide the cost of more specialized parsing code
          that is required to break this specialized data type apart dictionary into core/non-core

   Description: Classify the properties into a core subset of properties
   and extract the base data type components.

        2.Type 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 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 secondary
     set of additional "non-core" properties.

  3.      Divide the data.
          The advantage is property set by categories that generic parsing code can be used 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 no
          specialized data types beyond "Type" as
   parameters of a property value are confusing.

   Resolution: This comment is accepted, and this editorial issue will
   be fixed in the base data types (string,
          date-time, etc) need next draft.

1.5  Usage of local time and Interoperability.

   Description: Local time usage needs to be defined.

        3.Combine alternative 2 with the BEGIN:ALARM/END:ALARM, clarified to meet avoid
   potential interoperability issues. Text must be clear so that the grouping requirement.

        4.Use TERM CAPS type model.  (Need someone
   interpretations of time/date values are globally unambiguous to expand on this.)

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

1.2     Content Type

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

   Alternatives:

        1. Use calendar object.

   Usage of local time has a very specific interpretation for
   calendaring _ this means that the "application/calendar" content type/subtype. The
          purpose recipient of the "application" Content-Type as defined calendar object
   interpret the time in
          section 7.4 of [RFC-1521] the recipients local time (no adjustment for
   time zone). This allows for "floating" events; e.g."lunch" is "for data to be processed by
          mail-based uses of application programs." Calendaring and
          scheduling data falls into this category as recommended by
          [RFC-1521]. The "application/calendar" Content-Type at noon
   no matter where I am. In general, local time + time zone information
   (or UTC offset) is used
          to hold textual calendaring and scheduling information.
          Applications that want to supply a textual representation for
          legacy systems should use multipart/alternative recommended.

   Some text exists in the current draft describing the meaning of
   local time with a
          text/plain representation and an application/calendar
          representation.

                                   2 out time zone or UTC offset, but the text needs
   clarification.

                                  215

IETF CALSCH   Core Object Specification - Issues Document      02/03/97

        2. Use the "text/calendar" content type/subtype. The
          specification uses a clear-text format that
                            04/27/9704/27/97

   Resolution: This comment is reasonably
          readable. In addition, accepted, and this editorial issue will
   be fixed in the default action 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 MIME user
          agents that do 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 understand the "calendar" subtype will versioned. Vendors generally ignore these
   properties anyway.

1.8  DUE property definition.

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

   Alternatives:

   1. Allow DUE property to be a "text/plain" content type/subtype. This DURATION. May be useful in project
   management applications where a task is
          what 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 done for all legacy systems. described.

   Resolution: This comment is a
          very important constituent for accepted, and this content type. Otherwise,
          the content type would editorial issue will
   be rendered as a binary attachment.

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

1.3     BEGIN/END Content Sentinel Properties the next draft.

                                  315

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

1.10 Complex Registration Process

   Description: Should The PROFILE registration process is complex. Separate
   definition of new profiles from the MIME calendaring and scheduling content
           include a BEGIN registration process. New
   PROFILEs to be published as an RFC.

   Resolution: This comment is accepted, and END sentinel property?

   Alternatives:

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

        2. Do not include next draft.

1.11 BNF definition

   Description: Change BNF to an acceptable form. Use a single
   specification, rather than the BEGIN/END sentinel properties. They are
          not needed iterative form in the MIME encapsulation of current
   document. Noted that the content type.
          Having another mechanism for delimiting MIME objects, adds iterative form can lead to inconsistencies
   across the overhead required to parse such objects, particularly if
          multiple calendaring overall grammar.

   Resolution: This comment is accepted, and scheduling objects are permitted in
          a single body part.  On the other hand, using editors will work with
   Ned Freed to correct this issue in the
          encapsulation methods provided by next draft.

1.12 MIME allows applications encoding considerations

   Description: Insure conformance to
          leverage protocols, such as IMAP, extract individual
          calendaring MIME. Current draft does not
   conform to MIME encoding with respect to quoted-printable. Change
   text needed here.

   Resolution: This comment is accepted, and scheduling content objects.

1.4     Recurring Event Model 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: What model should Should the specification be defined with the intent that
           the content type is to be used for representing recurrences solely within calendar component descriptions. For example, how will
           recurring events a SMTP/MIME
           message transport or should there be represented?

   Alternatives:

        1. Base a broader scope and
           application taken into the recurrences model on that specified in definition of the vCalendar
          specification. specification?

   Alternatives:

        1.           The vCalendar specification includes a model
          that allows both should be designed with the representation of recurrences as a
          sequence of discrete recurring dates scope and as a recurrence
          pattern with a recurrence grammar.
          application target of just the SMTP/MIME messaging transport.

        2.           The model also allows specification should be designed with the
          inclusion scope and
          application target of exceptions to a calendar component description
          using just the same options of a sequence of discrete exception
          dates or an exception pattern. This model has been
          implemented by numerous vendors. It IETF transport protocols.

        3.           The specification is based on previous work for an industry calendaring and
          scheduling standard. The scope and application target should
          be a broad range of the IETF CHRONOS working group and accepted practice in
          _small foot print_ machines such as Personal Digital
          Assistants (PDA).

                                   3 non-IETF transport protocols.

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

                                  415

IETF CALSCH   Core Object Specification - Issues Document      02/03/97

        2. Base the representation of recurring events on a model that
          describes calendar based recurrence patterns ranging from the
          simple to the complex in a manner that is simple to implement
          properly and flexible enough to allow for support non-
          gregorian calendars.  The draft-ietf-calsch-sch-00.txt draft
          attempts to define such a model, implemented as a set
          calendar restrictions, similar to a database query, combined
          with reference date and time information. Each restriction,
          or pattern, is combined with the next pattern using the
          logical AND operations.  The query style method allows for a
          wide variety of patterns to be specified without complex
          parsing or grammar.

1.5     Date and Time Format
                            04/27/9704/27/97

2.2  Property Syntax

   Description: What date and time format syntax should be used for to represent individual
           properties
           with date and time value types? or MIME body elements within the specification?

   Alternatives:

        1. Use the revised RFC 822 date and time format           Properties are to be defined by RFC
          1123. This is the format that is used within using the MIME
          messaging transport. It is also used by numerous IETF
          protocols. syntax from vCalendar:
                propname *[;parmname "=" parmvalue] ":" propvalue

        2. Use the ISO 8601 based date and time format           Properties are to be defined by using the _-
          csct-01.txt_ Internet Draft. This is syntax from the format that is used
          with

1.6     DST Rule Support July
          1996 Microsoft document:
                propname ["," parmname "=" parmvalue] ":" propvalue

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

2.3  Ordering of Properties

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

   Alternatives:

        1.           No. The specification should There is not include support for
          calendaring functionality that depends on the specification
          of the behavior and rules ordering requirement for DST observance. properties, other
          than sentinel properties.

        2.           Yes. The specification should include a property that defines
          the behavior and rules 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 DST observance; based on content
           information conforming to the POSIX
          model. This would include specification?

   Alternatives:

        1.           Include within the specification a boolean value defining DST
          observance, new MIME header field
          CONTENT-PROFILE that will declare 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 intended usage profile.

        2.           Include within the
          standard time zone name, optional string specification a new "profile=" header
          field parameter for the DST zone
          name. MIME Content-Type header field. This
          parameter will declare the intended usage profile.

        3. Yes. The           Include within the specification should include both a set of properties
          that define new "profile=" header
          field parameter for the behavior MIME Content-Type header field and rules a
          new optional PROFILE property for the time zone.   This
          would include at a minimum content information.
          These two elements will be used to declare the time zone time delta from 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

                                   4 content information is transported in MIME.

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

                                  515

IETF CALSCH   Core Object Specification - Issues Document      02/03/97

          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
                            04/27/9704/27/97

2.5  Strong, Explicit Data Typing

   Description: Should the specification include the definition of absolute
          date/times; and c)
           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 DST transition rule, i.e. mechanism for explicitly
          defining the data types for the properties within the
          specification. The content information includes explicit data
          typing with a recurrence
          rule or list VALUETYPE property parameter. A minimal set of absolute date/times.
          value data types are defined by the specification. Additional optional
          properties may
          value data types can be desirable including 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 Time Zone
          identifiers, mechanism for explicitly
          defining the data types for the properties within the
          specification. Additionally, the specification must include a time zone name
          default value for STD and DST time, 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 date-
          stamp to indicate "freshness" VALUETYPE property parameter. A minimal set of
          value, data types are defined by the time zone rule, a URL 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
          standardized time zone rule definitions, etc.

1.7     Exceptions To Recurrence Rules the default data type for the property value.

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

2.6  Minimalization of Property Names

   Description: How should exceptions to a recurrence rule Should property names be specified
           (e.g., as a sequence using the verbose
           style of dates, an exception recurrence rule, MIME or optionally both)? a more minimal style for "low chat" and
           "small foot print" devices?

   Alternatives:

        1. The recurrence model           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 support the iCalendar specification be
           based on?

   Alternatives:

        1.             Base the specification of
          exceptions to on the recurrence as vCalendar document. This
          includes a sequence model of dates.

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

        2.             Base the recurrence as specification on a sequence set of dates semantics that is new and
          optionally an exception recurrence rule or both.

1.8     Infinite Recurring Patterns

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

   Alternatives:

        1.   No. The recurrence rules need IETF. Where appropriate, utilize the
          best ideas from existing products or model specifications to specify
          derive a finite number standard based on the consensus of
          occurrences.

        2.   Yes. The recurrence rules need the IETF
          Calendaring and Scheduling Working Group.

   Resolution: Per the pre-working group meeting, we've decided to allow use
   the CSCT draft as our starting point for an open-ended,
          infinite number of recurrences.

        3.   Yes. the working group spec. The recurrence rules need to allow
   entire draft is up for open-ended
          recurrence rules. However, there also needs review and group consensus will be reflected
   in any modification made to the draft.  Modifications, as needed,
   will be a way made via postings of
          specifying a stop date or count change text to the open-ended recurrence
          rule.

1.9     Non-Standard Extensibility list. Posting should
   indicate the "broken" component of the existing specification.

2.9  Attendees In MIME Header Fields and Content Body

   Description: Should When calendar components are transported in the specification support form of
           a formal method for
           making _non-standard_ extensions to MIME message, how should the specification? attendees be specified?

   Alternatives:

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

                                   5

                                  715

IETF CALSCH   Core Object Specification - Issues Document      02/03/97
                            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 include the RFC 1521 method support specification of
          _X-_ tags
          calendar components using a non-Gregorian calendar scale.

   Resolution: Modification of alternative 2. A mechanism for non-standard extensions to the specifying
   alternate calendar types will be defined: a calendar scale property names
          and values and non-standard extensions to
   will allow the property
          parameter names and values. Standard extensions should also calendar scale to be supported via named. However, the IANA registration process of new
          property names and values or new property parameter names specification
   will only define behavior for the Gregorian calendar scale. Alternate
   calendar types and
          values.

1.10    Local Time Values 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 local time values structured data types (like a
           'C' struct)?

   Requirements: Solution must have

          .  Mechanism for date 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 time value consisting of multiple data types within
          combined.

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

          The advantage of this format is compactness of the specification?

   Requirement: Solution must have time values specified such that they
           are globally unambiguous to data.  The
          disadvantage is the recipient(s) cost of the calendar
           object.

   Alternatives:

        1. No. Only UTC values should be specified for more specialized parsing code
          that is required to break this specialized data type apart
          and time
          values.

        2. Yes. However, the local time should always include extract the time
          zone offset from UTC.

2.      Resolved Issues

2.1     Scope base data type components.

        2.Type name and Application 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 Specification

   Description: Should the specification data.
          The advantage is that generic parsing code can be defined 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 intent that BEGIN:ALARM/END:ALARM, to meet
          the content grouping requirement.

        4.Use TERM CAPS type is model.  (Need someone to be 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 solely within a SMTP/MIME
           message transport or should there be a broader scope when the ALARM and
           application taken into DAYLIGHT
   properties were redefined in the definition of current specification.

2.12 Content Type

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

   Alternatives:

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

        2. "application/calendar" content type/subtype. The specification should be designed with the scope and
          application target
          purpose of just the IETF transport protocols.

        3. The specification "application" Content-Type as defined in
          section 7.4 of [RFC-1521] is for an industry calendaring and
          scheduling standard. The scope and application target should "for data to be a broad range processed by
          mail-based uses of IETF application programs." Calendaring and non-IETF transport protocols.

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

2.2     Property Syntax

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

   Alternatives:

                                   6
          scheduling data falls into this category as recommended by

                                  915

IETF CALSCH   Core Object Specification - Issues Document      02/03/97

        1. Properties are
                            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 defined using 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 syntax from vCalendar:
                propname *[;parmname _=_ parmvalue] _:_ propvalue

        2. Properties are MIME-
   DIR framework media type has changed to be defined using the syntax text/directory from the July
          1996 Microsoft document:
                propname [_,_ parmname _=_ parmvalue] _:_ propvalue

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

2.3     Ordering of
   application/directory.

2.13 BEGIN/END Content Sentinel Properties

   Description: Should the specification require ordering of properties? MIME calendaring and scheduling content
           include a BEGIN and END sentinel property?

   Alternatives:

        1. No. There is not ordering requirement for properties, other
          than           Include the BEGIN/END sentinel properties.

        2. Yes. The ordering of some These 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
          will allow the usage profile for content
           information conforming to be identified outside of the specification?

   Alternatives:

        1. Include within the specification a new MIME header field
          CONTENT-PROFILE that will declare the intended usage profile.
          message transport. They do have any significant overhead.

        2. Include within           Do not include the specification a new _profile=_ header
          field parameter for BEGIN/END sentinel properties. They are
          not needed in the MIME Content-Type header field. This
          parameter will declare the intended usage profile.

        3. Include within encapsulation of the specification both a new _profile=_ header
          field parameter content type.
          Having another mechanism for the delimiting MIME Content-Type header field and a
          new optional PROFILE property for the content information.
          These two elements will be used objects, adds to declare the intended usage
          profile. The PROFILE property is needed within
          the content
          information overhead required to parse such objects, particularly if
          multiple calendaring and scheduling objects are permitted in
          a single body part.  On the event that the content information is
          transported other hand, using a non-MIME messaging transport, but is not
          required when the
          encapsulation methods provided by MIME allows applications to
          leverage protocols, such as IMAP, extract individual
          calendaring and scheduling content information is transported in MIME. objects.

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

2.5     Strong, Explicit Data Typing

   Description: Should the specification include #1. We have found them to be useful in
   grouping as well as bounding the definition of content.

2.14 Date and Time Format

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

   Alternatives:

                                   7

                                  1015

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

        1. The specification should implicitly define the data types for
          the properties within the specification. While           Use the content
          information itself does not include any explicit data typing
          information with revised RFC 822 date and time format defined by RFC
          1123. This is the properties, it format that is defined used within the
          specification. MIME
          messaging transport. It is also used by numerous IETF
          protocols.

        2. The specification must include a mechanism for explicitly
          defining           Use the data types for ISO 8601 based date and time format defined by the properties within "-
          csct-01.txt" Internet Draft. This is the
          specification. The content information includes explicit data
          typing format that is used
          with a VALUETYPE property parameter. A minimal set of
          value data types are defined by

   Resolution: Alternative #2, ISO 8601 date and time format. Explicit
   BNF for this format has been included in the specification. Additional
          value data types can be registered within iCalendar document.

2.15 DST Rule Support

   Description: Should the IANA
          registration procedures. The value data type must specification for Time Zone include support
           for specifying the behavior and rules DST? If so, what format
           should be
          explicitly declared used?

   Alternatives:

        1.           No. The specification should not include support for
          calendaring functionality that depends on each property within the content
          information.

        3. specification
          of the behavior and rules for DST observance.

        2.           Yes. The specification must should include a mechanism for explicitly
          defining property that defines
          the data types behavior and rules for DST observance; based on the properties within the
          specification. Additionally, the specification must POSIX
          model. This would include a
          default Boolean value for the data type; in defining DST
          observance, the event that 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 value
          data type is not explicitly specified in
          standard time zone name, optional string for the content
          information. DST zone
          name.

        3.           Yes. The content information includes explicit data
          typing with specification should include a VALUETYPE property parameter. A minimal set of
          value, data types are defined by properties
          that define the specification.
          Additional value, data types can be registered within behavior and rules for the
          IANA registration procedures. The value, value data type may
          be explicitly declared on each property within time zone.   This
          would include at a minimum the content
          information. If time zone time delta from the value data type is not specified, it
          prime meridian. In addition, if necessary (if DST 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
          observed): a) a time delta used in DST, b) a Standard Time
          transition rule, i.e. a more minimal style for _low chat_ and
           _small foot print_ devices?

   Alternatives:

        1. Use the verbose style recurrence rule or list of MIME for defining names. This is
          easier to read absolute
          date/times; and comprehend.

        2. Use c) a minimal, short 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 properties. This is more
          suitable for small size datagrams. In addition, it is
          friendly to _low chat_ transports STD and small _foot print_
          devices, like DST time, a PDA. date-
          stamp to indicate "freshness" of the time zone rule, a URL to
          standardized time zone rule definitions, etc.

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

                                   8 #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      02/03/97

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 Model
                            04/27/9704/27/97

2.16 Exceptions To Recurrence Rules

   Description: What calendaring and scheduling data model How should the
           specification use?

   Alternatives:

        1.   Base the model on the vCalendar specification. 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 exceptions to a data model that has
          some broad consensus among recurrence rule be specified
           (e.g., as a group sequence of calendaring and
          scheduling vendors. It has also been implemented on over four
          operating system platforms by numerous vendors.

        2.   Base the model on dates, an architecture that is new and developed
          within the IETF. Where appropriate, utilize the best ideas
          from existing products exception recurrence rule,
           or optionally both)?

   Alternatives:

        1.           The recurrence model specifications to derive a
          standard based on should support the consensus specification of the IETF Calendaring and
          Scheduling Working Group.

   Resolution: Per the pre-working group meeting, we've decided
          exceptions to use the CSCT draft recurrence as our starting point for the working group spec. a sequence of dates.

        2.           The
   entire draft is up for review and group consensus will be reflected
   in any modification made to recurrence model should support the draft.  Modifications will be made
   via postings specification of change text
          exceptions to the list.

2.9     Attendees In MIME Header Fields recurrence as a sequence of dates and Content Body
          optionally an exception recurrence rule or both.

   Resolution: Alternative #2.

2.17 Infinite Recurring Patterns

   Description: When calendar components are transported in Should the form recurrence rules allow for an infinite number
           of
           a MIME message, how should the attendees be specified? recurrences?

   Alternatives:

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

                                   9

IETF CALSCH   Core Object Specification - Issues Document      02/03/97             No. The recurrence rules need to specify a finite number of
          occurrences.

        2. Attendees specified with the _ATTENDEE_ properties in             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
          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. open-ended recurrence
          rule.

   Resolution: Alternative 2, Attendees specified with the _ATTENDEE_
   properties #3 as drafted in the content information.

2.10    Non-Gregorian Calendar new recurrence grammar.

2.18 Non-Standard Extensibility

   Description: Should support be provided in the specification support a formal method for
           specifying calendar components using non-Gregorian calendar
           systems?
           making "non-standard" extensions to the specification?

   Alternatives:

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

        2. Yes. The specification should limit support for extensions in
          order to maximize possible interoperability.

        2.           Yes. The specification should include the RFC 1521 method of
          calendar components using a non-Gregorian calendar scale.

   Resolution: Modification of alternative 2. A mechanism
          "X-" tags for specifying
   alternate calendar types will be defined: a calendar scale property
   will allow non-standard extensions to the calendar scale property names
          and values and non-standard extensions to the property
          parameter names and values. Standard extensions should also
          be named. However, supported via the specification
   will only define behavior 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 Gregorian calendar scale. Alternate
   calendar types and their behaviors, conversion rules, etc. model used by iCalendar.

   Resolution: Agreed this will either be
   defined in a separate documents. 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.

                                   10

IETF CALSCH   Core Object Specification - Issues Document      02/03/97

   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.

                                   11

                                  1315