One document matched: draft-ietf-calsch-ical-issues-01.txt
Differences from draft-ietf-calsch-ical-issues-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 12:44:23 |