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
Datatracker
Report a datatracker bug
draft-ietf-calsch-ical-issues-01
None
| Document | Document type |
Expired Internet-Draft
(calsch WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors |
Frank Dawson
,
Anik Ganguly
,
Derik Stenerson
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |