draft-ietf-calsch-ical-issues-00.txt   draft-ietf-calsch-ical-issues-01.txt 
IETF CALSCH Working Group Anik Ganguly/OnTime IETF CALSCH Working Group Anik Ganguly/OnTime
Issues Document Frank Dawson/IBM Issues Document Frank Dawson/IBM
<draft-ietf-calsch-ical-issues-00.txt> Derik Stenerson/Microsoft <draft-ietf-calsch-ical-issues-01.txt> Derik Stenerson/Microsoft
Expire in six months February 2, 1997 April 27, 1997
Core Object Specification - Issues Document Core Object Specification - Issues Document
Abstract Abstract
This document is an IETF CALSCH working group document. The document This document is an IETF CALSCH working group document. The document
is used as a tool for recording issues and their resolution with is used as a tool for recording issues and their resolution with
mailing list discussions. mailing list discussions.
This Issues Document is intended to track the resolution of issues This Issues Document is intended to track the resolution of issues
related to the _Core Object Specification_ deliverable. related to the "Core Object Specification" deliverable.
The most current version of this document can be found on the IETF The most current version of this document can be found on the IETF
CALSCH Working Group document archive at http://www.imc.org. CALSCH Working Group document archive at http://www.imc.org.
Issues within this document are classified as either being OPEN or Issues within this document are classified as either being OPEN or
RESOLVED. Additionally, an issue may be found to no longer be a RESOLVED. Additionally, an issue may be found to no longer be a
concern and may be classified as WITHDRAWN. Issues falling into each concern and may be classified as WITHDRAWN. Issues falling into each
of these categories is listed in a separate section. of these categories are listed in a separate section.
An issues is documented with a short summary title, a brief An issue is documented with a short summary title, a brief
description, and a list of identified alternatives. A resolved issue description, and a list of identified alternatives. A resolved issue
will also include a description of the resolution and the date/venue will also include a description of the resolution and the date/venue
that the resolution was reached. that the resolution was reached.
Distribution of this document is unlimited. Distribution of this document is unlimited.
1. Open Issues 1. Open Issues
The following issues were raised at the 1997-04-07 IETF CALSCH Meeting
in Memphis, TN
1.1 Property Definition (Normalization) 1.1 Recurrence Rule Grammar
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 Description: What model/grammar should be used for representing
recurrences within calendar component descriptions.
Alternatives: Alternatives:
1.Type name and value consisting of multiple data types 1. New grammar as defined in draft-ietf-calsch-ical-01.txt. The new
combined.. grammar was based on the original CSA semantics, with a different
syntax styled after the rest of the iCalendar specification. It
1 also has been enhanced to handle a wider range of
patterns/occurrences.
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 2. Original (vCal) grammar. This grammar is more terse. It has already
the grouping requirement. been implemented by a number of vendors.
4.Use TERM CAPS type model. (Need someone to expand on this.) 11
5.Combine alternative 2 with MIME-DIR style grouping. Allows IETF CALSCH Core Object Specification - Issues Document
for unambiguous, multiple occurrences of property. Example: 04/27/9704/27/97
A.DALARM-DATE:19960415T235000
A.DALARM-REMIND:000500
A.DALARM-SNOOZE:2
A.DALARM-MESSAGE:Your Taxes Are Due !!!
1.2 Content Type 1.2 Property Parameters
Description: What content type and subtype should be specified in the Description: Property parameter use should be minimized.
specification?
Alternatives: Alternatives:
1. Use the "application/calendar" content type/subtype. The 1. Usage as defined in current draft
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. 2. Redefine all properties to minimize usage of property parameters.
The current format, while correct, is viewed as inelegant.
1.3 BEGIN/END Content Sentinel Properties 1.3 Divide the data dictionary into core/non-core
Description: Should the MIME calendaring and scheduling content Description: Classify the properties into a core subset of properties
include a BEGIN and END sentinel property? and the more complete set.
Alternatives: Alternatives:
1. Include the BEGIN/END sentinel properties. These properties 1. One complete dictionary of properties, listed alphabetically by
will allow the content to be identified outside of the MIME their descriptive name (current draft format).
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 2. Divide the property set in to a "core" primary set and a secondary
set of additional "non-core" properties.
Description: What model should be used for representing recurrences 3. Divide the property set by categories that describe their intended
within calendar component descriptions. For example, how will use (e.g., General Use, Identification, Recurrence, Time zone,
recurring events be represented? Freebusy, Alarm, Entry Definition, Security, Management, etc.).
Alternatives: 1.4 ValueType, Type, etc. usage confusing.
1. Base the recurrences model on that specified in the vCalendar Description: The use of the terms "Value Type" and "Type" as
specification. The vCalendar specification includes a model parameters of a property value are confusing.
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 Resolution: This comment is accepted, and this editorial issue will
be fixed in the next draft.
IETF CALSCH Core Object Specification - Issues Document 02/03/97 1.5 Usage of local time and Interoperability.
2. Base the representation of recurring events on a model that Description: Local time usage needs to be clarified to avoid
describes calendar based recurrence patterns ranging from the potential interoperability issues. Text must be clear so that the
simple to the complex in a manner that is simple to implement interpretations of time/date values are globally unambiguous to the
properly and flexible enough to allow for support non- recipient(s) of the calendar object.
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 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.
Description: What date and time format should be used for properties Some text exists in the current draft describing the meaning of
with date and time value types? local time with out time zone or UTC offset, but the text needs
clarification.
Alternatives: 215
1. Use the revised RFC 822 date and time format defined by RFC IETF CALSCH Core Object Specification - Issues Document
1123. This is the format that is used within the MIME 04/27/9704/27/97
messaging transport. It is also used by numerous IETF
protocols.
2. Use the ISO 8601 based date and time format defined by the _- Resolution: This comment is accepted, and this editorial issue will
csct-01.txt_ Internet Draft. This is the format that is used be fixed in the next draft.
with
1.6 DST Rule Support 1.6 Usage of non-significant LWSP
Description: Should the specification for Time Zone include support Description: Non-significant LWSP-Characters can lead to
for specifying the behavior and rules DST? If so, what format interoperability problems.
should be used?
Alternatives: Alternatives:
1. No. The specification should not include support for 1. Non-significant LWSP-Characters should be restricted everywhere.
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 2. Usage as in the current draft-ietf-calsch-ical-01.txt draft.
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 1.7 PROFILE-VERSION
Description: How should exceptions to a recurrence rule be specified Description: Need for PROFILE-VERSION is questioned.
(e.g., as a sequence of dates, an exception recurrence rule,
or optionally both)?
Alternatives: Alternatives:
1. The recurrence model should support the specification of 1. Retain PROFILE-VERSION property to allow versioning of profiles.
exceptions to the recurrence as a sequence of dates. Revisioning, while ignored by some implementations, has been a known
requirement for sometime.
2. The recurrence model should support the specification of 2. Eliminate PROFILE-VERSION property. Revisions to a profile
exceptions to the recurrence as a sequence of dates and specification are not versioned. Vendors generally ignore these
optionally an exception recurrence rule or both. properties anyway.
1.8 Infinite Recurring Patterns 1.8 DUE property definition.
Description: Should the recurrence rules allow for an infinite number Description: DUE property value should be limited to DATE-TIME, not
of recurrences? allow DURATION
Alternatives: Alternatives:
1. No. The recurrence rules need to specify a finite number of 1. Allow DUE property to be a DURATION. May be useful in project
occurrences. 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. Yes. The recurrence rules need to allow for an open-ended, 2. Limit to DATE-TIME. Use of duration adds an unnecessary
infinite number of recurrences. complexity.
3. Yes. The recurrence rules need to allow for open-ended 1.9 UID uniqueness hints needed
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: Ways of achieving UID uniqueness need to be described.
Description: Should the specification support a formal method for Resolution: This comment is accepted, and this editorial issue will
making _non-standard_ extensions to the specification? be fixed in the next draft.
Alternatives: 315
1. No. The specification should limit support for extensions in IETF CALSCH Core Object Specification - Issues Document
order to maximize possible interoperability. 04/27/9704/27/97
5 1.10 Complex Registration Process
IETF CALSCH Core Object Specification - Issues Document 02/03/97 Description: The PROFILE registration process is complex. Separate
definition of new profiles from the registration process. New
PROFILEs to be published as an RFC.
2. Yes. The specification should include the RFC 1521 method of Resolution: This comment is accepted, and this editorial issue will
_X-_ tags for non-standard extensions to the property names be fixed in the next draft.
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 1.11 BNF definition
Description: Should we allow local time values for date and time Description: Change BNF to an acceptable form. Use a single
value types within the specification? specification, rather than the iterative form in the current
document. Noted that the iterative form can lead to inconsistencies
across the overall grammar.
Requirement: Solution must have time values specified such that they Resolution: This comment is accepted, and the editors will work with
are globally unambiguous to the recipient(s) of the calendar Ned Freed to correct this issue in the next draft.
object.
Alternatives: 1.12 MIME encoding considerations
1. No. Only UTC values should be specified for data and time Description: Insure conformance to MIME. Current draft does not
values. conform to MIME encoding with respect to quoted-printable. Change
text needed here.
2. Yes. However, the local time should always include the time Resolution: This comment is accepted, and the editors will work with
zone offset from UTC. Ned Freed to correct this issue in the next draft.
2. Resolved Issues 2. Resolved Issues
2.1 Scope and Application of Specification 2.1 Scope and Application of Specification
Description: Should the specification be defined with the intent that Description: Should the specification be defined with the intent that
the content type is to be used solely within a SMTP/MIME the content type is to be used solely within a SMTP/MIME
message transport or should there be a broader scope and message transport or should there be a broader scope and
application taken into the definition of the specification? application taken into the definition of the specification?
skipping to change at line 337 skipping to change at line 224
2. The specification should be designed with the scope and 2. The specification should be designed with the scope and
application target of just the IETF transport protocols. application target of just the IETF transport protocols.
3. The specification is for an industry calendaring and 3. The specification is for an industry calendaring and
scheduling standard. The scope and application target should scheduling standard. The scope and application target should
be a broad range of IETF and non-IETF transport protocols. be a broad range of IETF and non-IETF transport protocols.
Resolution: Alternative 3. (Working Group Charter/1996-10) 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 2.2 Property Syntax
Description: What syntax should be used to represent individual Description: What syntax should be used to represent individual
properties or MIME body elements within the specification? properties or MIME body elements within the specification?
Alternatives: Alternatives:
6
IETF CALSCH Core Object Specification - Issues Document 02/03/97
1. Properties are to be defined using the syntax from vCalendar: 1. Properties are to be defined using the syntax from vCalendar:
propname *[;parmname _=_ parmvalue] _:_ propvalue propname *[;parmname "=" parmvalue] ":" propvalue
2. Properties are to be defined using the syntax from the July 2. Properties are to be defined using the syntax from the July
1996 Microsoft document: 1996 Microsoft document:
propname [_,_ parmname _=_ parmvalue] _:_ propvalue propname ["," parmname "=" parmvalue] ":" propvalue
Resolution: Alternative 1. (Mailing List/1996-12). Resolution: Alternative 1. (Mailing List/1996-12).
2.3 Ordering of Properties 2.3 Ordering of Properties
Description: Should the specification require ordering of properties? Description: Should the specification require ordering of properties?
Alternatives: Alternatives:
1. No. There is not ordering requirement for properties, other 1. No. There is not ordering requirement for properties, other
skipping to change at line 381 skipping to change at line 269
Description: How should the specification encode the originator's Description: How should the specification encode the originator's
intent with respect to the usage profile for content intent with respect to the usage profile for content
information conforming to the specification? information conforming to the specification?
Alternatives: Alternatives:
1. Include within the specification a new MIME header field 1. Include within the specification a new MIME header field
CONTENT-PROFILE that will declare the intended usage profile. CONTENT-PROFILE that will declare the intended usage profile.
2. Include within the specification a new _profile=_ header 2. Include within the specification a new "profile=" header
field parameter for the MIME Content-Type header field. This field parameter for the MIME Content-Type header field. This
parameter will declare the intended usage profile. parameter will declare the intended usage profile.
3. Include within the specification both a new _profile=_ header 3. Include within the specification both a new "profile=" header
field parameter for the MIME Content-Type header field and a field parameter for the MIME Content-Type header field and a
new optional PROFILE property for the content information. new optional PROFILE property for the content information.
These two elements will be used to declare the intended usage These two elements will be used to declare the intended usage
profile. The PROFILE property is needed within the content profile. The PROFILE property is needed within the content
information in the event that the content information is information in the event that the content information is
transported using a non-MIME messaging transport, but is not transported using a non-MIME messaging transport, but is not
required when the content information is transported in MIME. required when the content information is transported in MIME.
Resolution: Alternative 3 (Mailing list/1996-12). 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 2.5 Strong, Explicit Data Typing
Description: Should the specification include the definition of Description: Should the specification include the definition of
properties with strong data typing? properties with strong data typing?
Alternatives: Alternatives:
7
IETF CALSCH Core Object Specification - Issues Document 02/03/97
1. The specification should implicitly define the data types for 1. The specification should implicitly define the data types for
the properties within the specification. While the content the properties within the specification. While the content
information itself does not include any explicit data typing information itself does not include any explicit data typing
information with the properties, it is defined within the information with the properties, it is defined within the
specification. specification.
2. The specification must include a mechanism for explicitly 2. The specification must include a mechanism for explicitly
defining the data types for the properties within the defining the data types for the properties within the
specification. The content information includes explicit data specification. The content information includes explicit data
typing with a VALUETYPE property parameter. A minimal set of typing with a VALUETYPE property parameter. A minimal set of
skipping to change at line 442 skipping to change at line 331
IANA registration procedures. The value, value data type may IANA registration procedures. The value, value data type may
be explicitly declared on each property within the content be explicitly declared on each property within the content
information. If the value data type is not specified, it is information. If the value data type is not specified, it is
defaulted to the default data type for the property value. defaulted to the default data type for the property value.
Resolution: Alternative 3. (Mailing list/1996-10) Resolution: Alternative 3. (Mailing list/1996-10)
2.6 Minimalization of Property Names 2.6 Minimalization of Property Names
Description: Should property names be specified using the verbose Description: Should property names be specified using the verbose
style of MIME or a more minimal style for _low chat_ and style of MIME or a more minimal style for "low chat" and
_small foot print_ devices? "small foot print" devices?
Alternatives: Alternatives:
1. Use the verbose style of MIME for defining names. This is 1. Use the verbose style of MIME for defining names. This is
easier to read and comprehend. easier to read and comprehend.
2. Use a minimal, short name for properties. This is more 2. Use a minimal, short name for properties. This is more
suitable for small size datagrams. In addition, it is suitable for small size datagrams. In addition, it is
friendly to _low chat_ transports and small _foot print_ friendly to "low chat" transports and small "foot print"
devices, like a PDA. devices, like a PDA.
Resolution: Alternative 1. When creating property names, make them as 615
short as possible. (Mailing List/1996-11)
8 IETF CALSCH Core Object Specification - Issues Document
04/27/9704/27/97
IETF CALSCH Core Object Specification - Issues Document 02/03/97 Resolution: Alternative 1. When creating property names, make them as
short as possible. (Mailing List/1996-11)
2.7 Multi-valued Property Values 2.7 Multi-valued Property Values
Description: Should property values be allowed to have multiple Description: Should property values be allowed to have multiple
values? values?
Alternatives: Alternatives:
1. No. A property value can only appear once in a content 1. No. A property value can only appear once in a content
information with one value. information with one value.
2. Yes. A property value may appear multiple times in a content 2. Yes. A property value may appear multiple times in a content
information with multiple values. information with multiple values.
Resolution: Alternative 2 (Mailing List/1996-11) Resolution: Alternative 2 (Mailing List/1996-11)
2.8 Data Model 2.8 Data Syntax/Base Core Object Specification
Description: What calendaring and scheduling data model should the Description: What semantics should the iCalendar specification be
specification use? based on?
Alternatives: Alternatives:
1. Base the model on the vCalendar specification. This includes 1. Base the specification on the vCalendar document. This
a model of a calendar object as a conceptual container for includes a model of a calendar object as a conceptual
calendar components including events and todos. This model is container for calendar components including events and todos.
heavily borrowed from the XAPIA and X/Open Calendaring and This model is heavily borrowed from the XAPIA and X/Open
Scheduling API (CSA) which represents a data model that has Calendaring and Scheduling API (CSA) which represents a data
some broad consensus among a group of calendaring and model that has some broad consensus among a group of
scheduling vendors. It has also been implemented on over four calendaring and scheduling vendors. It has also been
operating system platforms by numerous vendors. implemented on over four operating system platforms by
numerous vendors.
2. Base the model on an architecture that is new and developed 2. Base the specification on a set of semantics that is new and
within the IETF. Where appropriate, utilize the best ideas developed within the IETF. Where appropriate, utilize the
from existing products or model specifications to derive a best ideas from existing products or model specifications to
standard based on the consensus of the IETF Calendaring and derive a standard based on the consensus of the IETF
Scheduling Working Group. Calendaring and Scheduling Working Group.
Resolution: Per the pre-working group meeting, we've decided to use 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 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 entire draft is up for review and group consensus will be reflected
in any modification made to the draft. Modifications will be made in any modification made to the draft. Modifications, as needed,
via postings of change text to the list. 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 2.9 Attendees In MIME Header Fields and Content Body
Description: When calendar components are transported in the form of Description: When calendar components are transported in the form of
a MIME message, how should the attendees be specified? a MIME message, how should the attendees be specified?
Alternatives: Alternatives:
715
IETF CALSCH Core Object Specification - Issues Document
04/27/9704/27/97
1. Attendees specified using the RFC-822 addressing fields. For 1. Attendees specified using the RFC-822 addressing fields. For
example, "To:" header are "required", those in the "Cc:" example, "To:" header are "required", those in the "Cc:"
header are "optional", etc. header are "optional", etc.
9 2. Attendees specified with the "ATTENDEE" properties in the
IETF CALSCH Core Object Specification - Issues Document 02/03/97
2. Attendees specified with the _ATTENDEE_ properties in the
content information. content information.
3. Attendees specified by 1 and 2. 3. Attendees specified by 1 and 2.
4. Attendees specified by 1 and optionally 2,where 2 has 4. Attendees specified by 1 and optionally 2,where 2 has
precedence over 1 if 2 is specified. precedence over 1 if 2 is specified.
Resolution: Alternative 2, Attendees specified with the _ATTENDEE_ Resolution: Alternative 2, Attendees specified with the "ATTENDEE"
properties in the content information. properties in the content information.
2.10 Non-Gregorian Calendar 2.10 Non-Gregorian Calendar
Description: Should support be provided in the specification for Description: Should support be provided in the specification for
specifying calendar components using non-Gregorian calendar specifying calendar components using non-Gregorian calendar
systems? systems?
Alternatives: Alternatives:
skipping to change at line 552 skipping to change at line 445
2. Yes. The specification should support specification of 2. Yes. The specification should support specification of
calendar components using a non-Gregorian calendar scale. calendar components using a non-Gregorian calendar scale.
Resolution: Modification of alternative 2. A mechanism for specifying Resolution: Modification of alternative 2. A mechanism for specifying
alternate calendar types will be defined: a calendar scale property alternate calendar types will be defined: a calendar scale property
will allow the calendar scale to be named. However, the specification will allow the calendar scale to be named. However, the specification
will only define behavior for the Gregorian calendar scale. Alternate will only define behavior for the Gregorian calendar scale. Alternate
calendar types and their behaviors, conversion rules, etc. will be calendar types and their behaviors, conversion rules, etc. will be
defined in separate documents. 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. Withdrawn Issues
3.1 Functional Completeness 3.1 Functional Completeness
Description: What types of scheduling functionality should be Description: What types of scheduling functionality should be
included in the specification? included in the specification?
Alternatives: Alternatives:
1. Just include support for requesting, replying-to and 1. Just include support for requesting, replying-to and
skipping to change at line 574 skipping to change at line 731
2. Begin with the base concepts of requesting, replying-to and 2. Begin with the base concepts of requesting, replying-to and
canceling an event. Add additional functionality that is canceling an event. Add additional functionality that is
deemed as required by the group. deemed as required by the group.
3. Start with as full a set of scheduling functionality as 3. Start with as full a set of scheduling functionality as
possible (e.g., requesting, replying-to, canceling, possible (e.g., requesting, replying-to, canceling,
modifying, replacing, resending, negotiating events and modifying, replacing, resending, negotiating events and
todos, as well as requesting and replying-to free/busy time todos, as well as requesting and replying-to free/busy time
requests.). Let the group decide what to add and remove. 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 Resolution: Alternative #3 fairly closely represents the decision of
the group by accepting the CSCT draft as the basis for the core the group by accepting the CSCT draft as the basis for the core
object specification. However, the issue is still valid in the object specification. However, the issue is still valid in the
context of the Calendaring and Scheduling Content Type Profile context of the Calendaring and Scheduling Content Type Profile
document <draft-ietf-calsch-csp-xx.txt> and should be addressed document <draft-ietf-calsch-csp-xx.txt> and should be addressed
there. there.
11 1315
 End of changes. 80 change blocks. 
268 lines changed or deleted 421 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/