Subject: Re: [ietf-calsify] [Technical Errata Reported] RFC5545 (3038)

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 01 Dec 2011 09:30:17 -0500

To improve consistency, we should modify Section 3.8.7.2. Date-Time 
Stamp <http://tools.ietf.org/html/rfc5545#section-3.8.7.2> and Section 
3.8.7.3. Last Modified 
<http://tools.ietf.org/html/rfc5545#section-3.8.7.3> to use the same 
phrasing as Section 3.8.7.1. Date-Time Created 
<http://tools.ietf.org/html/rfc5545#section-3.8.7.1> and Section 
3.8.2.1. Date-Time Completed 
<http://tools.ietf.org/html/rfc5545#section-3.8.2.1>.

Section 3.8.7.2. Date-Time Stamp

Original Text
-------------

    Conformance:  This property MUST be included in the "VEVENT",
       "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

    Description:  The value MUST be specified in the UTC time format.

       This property is also useful to protocols such as [2447bis  <http://tools.ietf.org/html/rfc5545#ref-2447bis>] that
       have inherent latency issues with the delivery of content.  This
       property will assist in the proper sequencing of messages
       containing iCalendar objects.

Corrected Text
--------------

    Conformance:  This property MUST be included in the "VEVENT",
       "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.
       The value MUST be specified as a date with UTC time.

    Description:  This property is also useful to protocols such as [2447bis  <http://tools.ietf.org/html/rfc5545#ref-2447bis>] that
       have inherent latency issues with the delivery of content.  This
       property will assist in the proper sequencing of messages
       containing iCalendar objects.

Section 3.8.7.3. Last Modified

Original Text
-------------

    Conformance:  This property can be specified in the "VEVENT",
       "VTODO", "VJOURNAL", or "VTIMEZONE" calendar components.
       The value MUST be specified as a date with UTC time.

    Description:  This property specifies the date and time that
       the calendar

Corrected Text
--------------

    Conformance:  This property can be specified in the "VEVENT",
       "VTODO", "VJOURNAL", or "VTIMEZONE" calendar components.

    Description:  This property specifies the date and time that the
       information associated with the calendar component was last
       revised in the calendar store.

Thanks,
Bernard

On 11/30/2011 2:15 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5545,
> "Internet Calendaring and Scheduling Core Object Specification (iCalendar)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=3038
>
> --------------------------------------
> Type: Technical
> Reported by: Brent Bloxam<[email-masked]>
>
> Section: 3.8.7.2
>
> Original Text
> -------------
> Value Type:  DATE-TIME
>
>     Property Parameters:  IANA and non-standard property parameters can
>        be specified on this property.
>
>     Conformance:  This property MUST be included in the "VEVENT",
>        "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.
>
>     Description:  The value MUST be specified in the UTC time format.
>
>        This property is also useful to protocols such as [2447bis] that
>        have inherent latency issues with the delivery of content.  This
>        property will assist in the proper sequencing of messages
>        containing iCalendar objects.
>
> Corrected Text
> --------------
> Value Type:  DATE-TIME. The time value MUST be in the DATE WITH UTC
>        TIME form defined for the DATE-TIME value type.
>
>     Property Parameters:  IANA and non-standard property parameters can
>        be specified on this property.
>
>     Conformance:  This property MUST be included in the "VEVENT",
>        "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.
>
>     Description:  This property is also useful to protocols such as
>        [2447bis] that have inherent latency issues with the delivery of
>        content.  This property will assist in the proper sequencing of
>        messages containing iCalendar objects.
>
> Notes
> -----
> Application of the DATE-TIME value type is inconsistent in the RFC, and can lead to ambiguity since DATE-TIME can take on three different forms. The wording for the corrected Value Type for DTSTAMP is similar to the DTSTART property's Value Type. This is to make it clear that the only acceptable form is DATE WITH UTC TIME. You can also see evidence of defining specificity inline with the Value Type in the GEO property.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5545 (draft-ietf-calsify-rfc2445bis-10)
> --------------------------------------
> Title               : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
> Publication Date    : September 2009
> Author(s)           : B. Desruisseaux, Ed.
> Category            : PROPOSED STANDARD
> Source              : Calendaring and Scheduling Standards Simplification
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Dec 2011 10:31:53 -0700

That sounds like "Hold For Document Update" to me...

http://www.ietf.org/iesg/statement/errata-processing.html

On 12/1/11 7:30 AM, Bernard Desruisseaux wrote:
>> Reported by: Brent Bloxam <[email-masked]>
>>
>> Section: 3.8.7.2
>>
>> Original Text
>> -------------
>> Value Type:  DATE-TIME
>>