home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-calsch-ical-issues-00.txt < prev    next >
Text File  |  1997-02-04  |  24KB  |  682 lines
  1.  
  2. IETF CALSCH Working Group                           Anik Ganguly/OnTime
  3. Issues Document                                        Frank Dawson/IBM
  4. <draft-ietf-calsch-ical-issues-00.txt>        Derik Stenerson/Microsoft
  5. Expire in six months                                   February 2, 1997
  6.  
  7.  
  8.  
  9.  
  10.  
  11.               Core Object Specification - Issues Document
  12.  
  13.  
  14. Abstract
  15.  
  16.    This document is an IETF CALSCH working group document. The document
  17.    is used as a tool for recording issues and their resolution with
  18.    mailing list discussions.
  19.  
  20.    This Issues Document is intended to track the resolution of issues
  21.    related to the _Core Object Specification_ deliverable.
  22.  
  23.    The most current version of this document can be found on the IETF
  24.    CALSCH Working Group document archive at http://www.imc.org.
  25.  
  26.    Issues within this document are classified as either being OPEN or
  27.    RESOLVED. Additionally, an issue may be found to no longer be a
  28.    concern and may be classified as WITHDRAWN. Issues falling into each
  29.    of these categories is listed in a separate section.
  30.  
  31.    An issues is documented with a short summary title, a brief
  32.    description, and a list of identified alternatives. A resolved issue
  33.    will also include a description of the resolution and the date/venue
  34.    that the resolution was reached.
  35.  
  36.    Distribution of this document is unlimited.
  37.  
  38. 1.      Open Issues
  39.  
  40. 1.1     Property Definition (Normalization)
  41.  
  42.    Description: Should data type values be defined using simple base
  43.            data types or should we allow structured data types (like a
  44.            'C' struct)?
  45.  
  46.    Requirements: Solution must have
  47.  
  48.           .  Mechanism for grouping.
  49.  
  50.           .  Named parameters for simplified parsing/ease of
  51.              extensibility
  52.  
  53.           .  Extensibility
  54.  
  55.    Alternatives:
  56.  
  57.         1.Type name and value consisting of multiple data types
  58.           combined..
  59.  
  60.  
  61.                                    1
  62.  
  63.  
  64. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  65.  
  66.  
  67.           For example:
  68.                 DALARM:19960415T235000;PT5M;2;Your Taxes Are Due !!!
  69.  
  70.           The advantage of this format is compactness of the data.  The
  71.           disadvantage is the cost of more specialized parsing code
  72.           that is required to break this specialized data type apart
  73.           and extract the base data type components.
  74.  
  75.         2.Type name and value consisting of a single base data type.
  76.           (Normalized).
  77.  
  78.           For example:
  79.                 DALARM-DATE:19960415T235000
  80.                 DALARM-REMIND:000500
  81.                 DALARM-SNOOZE:2
  82.                 DALARM-MESSAGE:Your Taxes Are Due !!!
  83.  
  84.           The disadvantage of this format is compactness of the data.
  85.           The advantage is that generic parsing code can be used and no
  86.           specialized data types beyond the base data types (string,
  87.           date-time, etc) need to be defined.
  88.  
  89.  
  90.         3.Combine alternative 2 with the BEGIN:ALARM/END:ALARM, to meet
  91.           the grouping requirement.
  92.  
  93.         4.Use TERM CAPS type model.  (Need someone to expand on this.)
  94.  
  95.         5.Combine alternative 2 with MIME-DIR style grouping.  Allows
  96.           for unambiguous, multiple occurrences of property.  Example:
  97.                 A.DALARM-DATE:19960415T235000
  98.                 A.DALARM-REMIND:000500
  99.                 A.DALARM-SNOOZE:2
  100.                 A.DALARM-MESSAGE:Your Taxes Are Due !!!
  101.  
  102. 1.2     Content Type
  103.  
  104.    Description: What content type and subtype should be specified in the
  105.            specification?
  106.  
  107.    Alternatives:
  108.  
  109.         1. Use the "application/calendar" content type/subtype. The
  110.           purpose of the "application" Content-Type as defined in
  111.           section 7.4 of [RFC-1521] is "for data to be processed by
  112.           mail-based uses of application programs." Calendaring and
  113.           scheduling data falls into this category as recommended by
  114.           [RFC-1521]. The "application/calendar" Content-Type is used
  115.           to hold textual calendaring and scheduling information.
  116.           Applications that want to supply a textual representation for
  117.           legacy systems should use multipart/alternative with a
  118.           text/plain representation and an application/calendar
  119.           representation.
  120.  
  121.  
  122.  
  123.                                    2
  124.  
  125.  
  126. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  127.  
  128.  
  129.         2. Use the "text/calendar" content type/subtype. The
  130.           specification uses a clear-text format that is reasonably
  131.           readable. In addition, the default action for MIME user
  132.           agents that do not understand the "calendar" subtype will be
  133.           to render as a "text/plain" content type/subtype. This is
  134.           what will need to be done for all legacy systems. This is a
  135.           very important constituent for this content type. Otherwise,
  136.           the content type would be rendered as a binary attachment.
  137.  
  138.         3. Use a framework media type such as being used in MIME-DIR.
  139.  
  140. 1.3     BEGIN/END Content Sentinel Properties
  141.  
  142.    Description: Should the MIME calendaring and scheduling content
  143.            include a BEGIN and END sentinel property?
  144.  
  145.    Alternatives:
  146.  
  147.         1. Include the BEGIN/END sentinel properties. These properties
  148.           will allow the content to be identified outside of the MIME
  149.           message transport. They do have any significant overhead.
  150.  
  151.         2. Do not include the BEGIN/END sentinel properties. They are
  152.           not needed in the MIME encapsulation of the content type.
  153.           Having another mechanism for delimiting MIME objects, adds to
  154.           the overhead required to parse such objects, particularly if
  155.           multiple calendaring and scheduling objects are permitted in
  156.           a single body part.  On the other hand, using the
  157.           encapsulation methods provided by MIME allows applications to
  158.           leverage protocols, such as IMAP, extract individual
  159.           calendaring and scheduling content objects.
  160.  
  161. 1.4     Recurring Event Model
  162.  
  163.    Description: What model should be used for representing recurrences
  164.            within calendar component descriptions. For example, how will
  165.            recurring events be represented?
  166.  
  167.    Alternatives:
  168.  
  169.         1. Base the recurrences model on that specified in the vCalendar
  170.           specification. The vCalendar specification includes a model
  171.           that allows both the representation of recurrences as a
  172.           sequence of discrete recurring dates and as a recurrence
  173.           pattern with a recurrence grammar. The model also allows the
  174.           inclusion of exceptions to a calendar component description
  175.           using the same options of a sequence of discrete exception
  176.           dates or an exception pattern. This model has been
  177.           implemented by numerous vendors. It is based on previous work
  178.           of the IETF CHRONOS working group and accepted practice in
  179.           _small foot print_ machines such as Personal Digital
  180.           Assistants (PDA).
  181.  
  182.  
  183.  
  184.  
  185.                                    3
  186.  
  187.  
  188. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  189.  
  190.  
  191.         2. Base the representation of recurring events on a model that
  192.           describes calendar based recurrence patterns ranging from the
  193.           simple to the complex in a manner that is simple to implement
  194.           properly and flexible enough to allow for support non-
  195.           gregorian calendars.  The draft-ietf-calsch-sch-00.txt draft
  196.           attempts to define such a model, implemented as a set
  197.           calendar restrictions, similar to a database query, combined
  198.           with reference date and time information. Each restriction,
  199.           or pattern, is combined with the next pattern using the
  200.           logical AND operations.  The query style method allows for a
  201.           wide variety of patterns to be specified without complex
  202.           parsing or grammar.
  203.  
  204. 1.5     Date and Time Format
  205.  
  206.    Description: What date and time format should be used for properties
  207.            with date and time value types?
  208.  
  209.    Alternatives:
  210.  
  211.         1. Use the revised RFC 822 date and time format defined by RFC
  212.           1123. This is the format that is used within the MIME
  213.           messaging transport. It is also used by numerous IETF
  214.           protocols.
  215.  
  216.         2. Use the ISO 8601 based date and time format defined by the _-
  217.           csct-01.txt_ Internet Draft. This is the format that is used
  218.           with
  219.  
  220. 1.6     DST Rule Support
  221.  
  222.    Description: Should the specification for Time Zone include support
  223.            for specifying the behavior and rules DST? If so, what format
  224.            should be used?
  225.  
  226.    Alternatives:
  227.  
  228.         1. No. The specification should not include support for
  229.           calendaring functionality that depends on the specification
  230.           of the behavior and rules for DST observance.
  231.  
  232.         2. Yes. The specification should include a property that defines
  233.           the behavior and rules for DST observance; based on the POSIX
  234.           model. This would include a boolean value defining DST
  235.           observance, the offset from UTC for standard time, offset
  236.           from UTC for daylight savings time, date and time or
  237.           recurrence rule for beginning standard time, date and time or
  238.           recurrence rule for beginning DST, optional string for the
  239.           standard time zone name, optional string for the DST zone
  240.           name.
  241.  
  242.         3. Yes. The specification should include a set of properties
  243.           that define the behavior and rules for the time zone.   This
  244.           would include at a minimum the time zone time delta from the
  245.  
  246.  
  247.                                    4
  248.  
  249.  
  250. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  251.  
  252.  
  253.           prime meridian. In addition, if necessary (if DST is
  254.           observed): a) a time delta used in DST, b) a Standard Time
  255.           transition rule, i.e. a recurrence rule or list of absolute
  256.           date/times; and c) a DST transition rule, i.e. a recurrence
  257.           rule or list of absolute date/times.  Additional optional
  258.           properties may be desirable including a Time Zone
  259.           identifiers, a time zone name  for STD and DST time, a date-
  260.           stamp to indicate "freshness" of the time zone rule, a URL to
  261.           standardized time zone rule definitions, etc.
  262.  
  263. 1.7     Exceptions To Recurrence Rules
  264.  
  265.    Description: How should exceptions to a recurrence rule be specified
  266.            (e.g., as a sequence of dates, an exception recurrence rule,
  267.            or optionally both)?
  268.  
  269.    Alternatives:
  270.  
  271.         1. The recurrence model should support the specification of
  272.           exceptions to the recurrence as a sequence of dates.
  273.  
  274.         2. The recurrence model should support the specification of
  275.           exceptions to the recurrence as a sequence of dates and
  276.           optionally an exception recurrence rule or both.
  277.  
  278. 1.8     Infinite Recurring Patterns
  279.  
  280.    Description: Should the recurrence rules allow for an infinite number
  281.            of recurrences?
  282.  
  283.    Alternatives:
  284.  
  285.         1.   No. The recurrence rules need to specify a finite number of
  286.           occurrences.
  287.  
  288.         2.   Yes. The recurrence rules need to allow for an open-ended,
  289.           infinite number of recurrences.
  290.  
  291.         3.   Yes. The recurrence rules need to allow for open-ended
  292.           recurrence rules. However, there also needs to be a way of
  293.           specifying a stop date or count to the open-ended recurrence
  294.           rule.
  295.  
  296. 1.9     Non-Standard Extensibility
  297.  
  298.    Description: Should the specification support a formal method for
  299.            making _non-standard_ extensions to the specification?
  300.  
  301.    Alternatives:
  302.  
  303.         1. No. The specification should limit support for extensions in
  304.           order to maximize possible interoperability.
  305.  
  306.  
  307.  
  308.  
  309.                                    5
  310.  
  311.  
  312. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  313.  
  314.  
  315.         2. Yes. The specification should include the RFC 1521 method of
  316.           _X-_ tags for non-standard extensions to the property names
  317.           and values and non-standard extensions to the property
  318.           parameter names and values. Standard extensions should also
  319.           be supported via the IANA registration process of new
  320.           property names and values or new property parameter names and
  321.           values.
  322.  
  323. 1.10    Local Time Values
  324.  
  325.    Description: Should we allow local time values for date and time
  326.            value types within the specification?
  327.  
  328.    Requirement: Solution must have time values specified such that they
  329.            are globally unambiguous to the recipient(s) of the calendar
  330.            object.
  331.  
  332.    Alternatives:
  333.  
  334.         1. No. Only UTC values should be specified for data and time
  335.           values.
  336.  
  337.         2. Yes. However, the local time should always include the time
  338.           zone offset from UTC.
  339.  
  340. 2.      Resolved Issues
  341.  
  342. 2.1     Scope and Application of Specification
  343.  
  344.    Description: Should the specification be defined with the intent that
  345.            the content type is to be used solely within a SMTP/MIME
  346.            message transport or should there be a broader scope and
  347.            application taken into the definition of the specification?
  348.  
  349.    Alternatives:
  350.  
  351.         1. The specification should be designed with the scope and
  352.           application target of just the SMTP/MIME messaging transport.
  353.  
  354.         2. The specification should be designed with the scope and
  355.           application target of just the IETF transport protocols.
  356.  
  357.         3. The specification is for an industry calendaring and
  358.           scheduling standard. The scope and application target should
  359.           be a broad range of IETF and non-IETF transport protocols.
  360.  
  361.    Resolution: Alternative 3. (Working Group Charter/1996-10)
  362.  
  363. 2.2     Property Syntax
  364.  
  365.    Description: What syntax should be used to represent individual
  366.            properties or MIME body elements within the specification?
  367.  
  368.    Alternatives:
  369.  
  370.  
  371.                                    6
  372.  
  373.  
  374. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  375.  
  376.  
  377.         1. Properties are to be defined using the syntax from vCalendar:
  378.                 propname *[;parmname _=_ parmvalue] _:_ propvalue
  379.  
  380.         2. Properties are to be defined using the syntax from the July
  381.           1996 Microsoft document:
  382.                 propname [_,_ parmname _=_ parmvalue] _:_ propvalue
  383.  
  384.    Resolution: Alternative 1. (Mailing List/1996-12).
  385.  
  386. 2.3     Ordering of Properties
  387.  
  388.    Description: Should the specification require ordering of properties?
  389.  
  390.    Alternatives:
  391.  
  392.         1. No. There is not ordering requirement for properties, other
  393.           than sentinel properties.
  394.  
  395.         2. Yes. The ordering of some properties is important.
  396.  
  397.    Resolution: Alternative 1. (Mailing List/1996-11)
  398.  
  399. 2.4     Specification of Usage Profiles
  400.  
  401.    Description: How should the specification encode the originator's
  402.            intent with respect to the usage profile for content
  403.            information conforming to the specification?
  404.  
  405.    Alternatives:
  406.  
  407.         1. Include within the specification a new MIME header field
  408.           CONTENT-PROFILE that will declare the intended usage profile.
  409.  
  410.         2. Include within the specification a new _profile=_ header
  411.           field parameter for the MIME Content-Type header field. This
  412.           parameter will declare the intended usage profile.
  413.  
  414.         3. Include within the specification both a new _profile=_ header
  415.           field parameter for the MIME Content-Type header field and a
  416.           new optional PROFILE property for the content information.
  417.           These two elements will be used to declare the intended usage
  418.           profile. The PROFILE property is needed within the content
  419.           information in the event that the content information is
  420.           transported using a non-MIME messaging transport, but is not
  421.           required when the content information is transported in MIME.
  422.  
  423.    Resolution: Alternative 3 (Mailing list/1996-12).
  424.  
  425. 2.5     Strong, Explicit Data Typing
  426.  
  427.    Description: Should the specification include the definition of
  428.            properties with strong data typing?
  429.  
  430.    Alternatives:
  431.  
  432.  
  433.                                    7
  434.  
  435.  
  436. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  437.  
  438.  
  439.         1. The specification should implicitly define the data types for
  440.           the properties within the specification. While the content
  441.           information itself does not include any explicit data typing
  442.           information with the properties, it is defined within the
  443.           specification.
  444.  
  445.         2. The specification must include a mechanism for explicitly
  446.           defining the data types for the properties within the
  447.           specification. The content information includes explicit data
  448.           typing with a VALUETYPE property parameter. A minimal set of
  449.           value data types are defined by the specification. Additional
  450.           value data types can be registered within the IANA
  451.           registration procedures. The value data type must be
  452.           explicitly declared on each property within the content
  453.           information.
  454.  
  455.         3. The specification must include a mechanism for explicitly
  456.           defining the data types for the properties within the
  457.           specification. Additionally, the specification must include a
  458.           default value for the data type; in the event that the value
  459.           data type is not explicitly specified in the content
  460.           information. The content information includes explicit data
  461.           typing with a VALUETYPE property parameter. A minimal set of
  462.           value, data types are defined by the specification.
  463.           Additional value, data types can be registered within the
  464.           IANA registration procedures. The value, value data type may
  465.           be explicitly declared on each property within the content
  466.           information. If the value data type is not specified, it is
  467.           defaulted to the default data type for the property value.
  468.  
  469.    Resolution: Alternative 3. (Mailing list/1996-10)
  470.  
  471. 2.6     Minimalization of Property Names
  472.  
  473.    Description: Should property names be specified using the verbose
  474.            style of MIME or a more minimal style for _low chat_ and
  475.            _small foot print_ devices?
  476.  
  477.    Alternatives:
  478.  
  479.         1. Use the verbose style of MIME for defining names. This is
  480.           easier to read and comprehend.
  481.  
  482.         2. Use a minimal, short name for properties. This is more
  483.           suitable for small size datagrams. In addition, it is
  484.           friendly to _low chat_ transports and small _foot print_
  485.           devices, like a PDA.
  486.  
  487.    Resolution: Alternative 1. When creating property names, make them as
  488.            short as possible. (Mailing List/1996-11)
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.                                    8
  496.  
  497.  
  498. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  499.  
  500.  
  501. 2.7     Multi-valued Property Values
  502.  
  503.    Description: Should property values be allowed to have multiple
  504.            values?
  505.  
  506.    Alternatives:
  507.  
  508.         1. No. A property value can only appear once in a content
  509.           information with one value.
  510.  
  511.         2. Yes. A property value may appear multiple times in a content
  512.           information with multiple values.
  513.  
  514.    Resolution: Alternative 2 (Mailing List/1996-11)
  515.  
  516. 2.8     Data Model
  517.  
  518.    Description: What calendaring and scheduling data model should the
  519.            specification use?
  520.  
  521.    Alternatives:
  522.  
  523.         1.   Base the model on the vCalendar specification. This includes
  524.           a model of a calendar object as a conceptual container for
  525.           calendar components including events and todos. This model is
  526.           heavily borrowed from the XAPIA and X/Open Calendaring and
  527.           Scheduling API (CSA) which represents a data model that has
  528.           some broad consensus among a group of calendaring and
  529.           scheduling vendors. It has also been implemented on over four
  530.           operating system platforms by numerous vendors.
  531.  
  532.         2.   Base the model on an architecture that is new and developed
  533.           within the IETF. Where appropriate, utilize the best ideas
  534.           from existing products or model specifications to derive a
  535.           standard based on the consensus of the IETF Calendaring and
  536.           Scheduling Working Group.
  537.  
  538.    Resolution: Per the pre-working group meeting, we've decided to use
  539.    the CSCT draft as our starting point for the working group spec. The
  540.    entire draft is up for review and group consensus will be reflected
  541.    in any modification made to the draft.  Modifications will be made
  542.    via postings of change text to the list.
  543.  
  544. 2.9     Attendees In MIME Header Fields and Content Body
  545.  
  546.    Description: When calendar components are transported in the form of
  547.            a MIME message, how should the attendees be specified?
  548.  
  549.    Alternatives:
  550.  
  551.         1. Attendees specified using the RFC-822 addressing fields.  For
  552.           example, "To:" header are "required", those in the "Cc:"
  553.           header are "optional", etc.
  554.  
  555.  
  556.  
  557.                                    9
  558.  
  559.  
  560. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  561.  
  562.  
  563.         2. Attendees specified with the _ATTENDEE_ properties in the
  564.           content information.
  565.  
  566.         3. Attendees specified by 1 and 2.
  567.  
  568.         4. Attendees specified by 1 and optionally 2,where 2 has
  569.           precedence over 1 if 2 is specified.
  570.  
  571.    Resolution: Alternative 2, Attendees specified with the _ATTENDEE_
  572.    properties in the content information.
  573.  
  574. 2.10    Non-Gregorian Calendar
  575.  
  576.    Description: Should support be provided in the specification for
  577.            specifying calendar components using non-Gregorian calendar
  578.            systems?
  579.  
  580.    Alternatives:
  581.  
  582.         1. No. Only Gregorian-based descriptions of calendar components
  583.           are supported?
  584.  
  585.         2. Yes. The specification should support specification of
  586.           calendar components using a non-Gregorian calendar scale.
  587.  
  588.    Resolution: Modification of alternative 2. A mechanism for specifying
  589.    alternate calendar types will be defined: a calendar scale property
  590.    will allow the calendar scale to be named. However, the specification
  591.    will only define behavior for the Gregorian calendar scale. Alternate
  592.    calendar types and their behaviors, conversion rules, etc. will be
  593.    defined in separate documents.
  594.  
  595. 3.      Withdrawn Issues
  596.  
  597. 3.1     Functional Completeness
  598.  
  599.    Description: What types of scheduling functionality should be
  600.            included in the specification?
  601.  
  602.    Alternatives:
  603.  
  604.         1. Just include support for requesting, replying-to and
  605.           canceling an event.
  606.  
  607.         2. Begin with the base concepts of requesting, replying-to and
  608.           canceling an event.  Add additional functionality that is
  609.           deemed as required by the group.
  610.  
  611.         3. Start with as full a set of scheduling functionality as
  612.           possible (e.g., requesting, replying-to, canceling,
  613.           modifying, replacing, resending, negotiating events and
  614.           todos, as well as requesting and replying-to free/busy time
  615.           requests.).  Let the group decide what to add and remove.
  616.  
  617.  
  618.  
  619.                                    10
  620.  
  621.  
  622. IETF CALSCH   Core Object Specification - Issues Document      02/03/97
  623.  
  624.  
  625.    Resolution: Alternative #3 fairly closely represents the decision of
  626.    the group by accepting the CSCT draft as the basis for the core
  627.    object specification.  However, the issue is still valid in the
  628.    context of the Calendaring and Scheduling Content Type Profile
  629.    document <draft-ietf-calsch-csp-xx.txt> and should be addressed
  630.    there.
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.                                    11
  682.