IETF CALSCH Working Group Anik Ganguly/OnTime Issues Document Frank Dawson/IBM <draft-ietf-calsch-ical-issues-00.txt> Derik Stenerson/Microsoft Expire in six months February 2, 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 is listed in a separate section. An issues 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 1.1 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: 1.Type name and value consisting of multiple data types combined.. 1 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 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 !!! 1.2 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 [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 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 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. 1.3 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. 1.4 Recurring Event Model Description: What model should be used for representing recurrences within calendar component descriptions. For example, how will recurring events be represented? Alternatives: 1. Base the recurrences model on that specified in the vCalendar specification. The vCalendar specification includes a model that allows both the representation of recurrences as a sequence of discrete recurring dates and as a recurrence pattern with a recurrence grammar. The model also allows the inclusion of exceptions to a calendar component description using the same options of a sequence of discrete exception dates or an exception pattern. This model has been implemented by numerous vendors. It is based on previous work of the IETF CHRONOS working group and accepted practice in _small foot print_ machines such as Personal Digital Assistants (PDA). 3 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 Description: What date and time format should be used for properties with date and time value types? Alternatives: 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 1.6 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 4 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 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. 1.7 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. 1.8 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. 1.9 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. 5 IETF CALSCH Core Object Specification - Issues Document 02/03/97 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. 1.10 Local Time Values Description: Should we allow local time values for date and time value types within the specification? Requirement: Solution must have time values specified such that they are globally unambiguous to the recipient(s) of the calendar object. Alternatives: 1. No. Only UTC values should be specified for data and time values. 2. Yes. However, the local time should always include the time zone offset from UTC. 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) 2.2 Property Syntax Description: What syntax should be used to represent individual properties or MIME body elements within the specification? Alternatives: 6 IETF CALSCH Core Object Specification - Issues Document 02/03/97 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). 2.5 Strong, Explicit Data Typing Description: Should the specification include the definition of properties with strong data typing? Alternatives: 7 IETF CALSCH Core Object Specification - Issues Document 02/03/97 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. Resolution: Alternative 1. When creating property names, make them as short as possible. (Mailing List/1996-11) 8 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 Description: What calendaring and scheduling data model 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 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 model on an architecture 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 will be made via postings of change text to the list. 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: 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 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. 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
Datatracker
Report a datatracker bug
draft-ietf-calsch-ical-issues-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |