Peter Saint-Andre | 30 Nov 16:24 2011

Re: [ietf-calsify] [Editorial Errata Reported] RFC5546 (3037)

Cyrus, please let us know if you agree with this report.

On 11/30/11 5:29 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5546,
> "iCalendar Transport-Independent Interoperability Protocol (iTIP)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5546&eid=3037
> 
> --------------------------------------
> Type: Editorial
> Reported by: Praveen Bhamidipati <bhamidipati_praveen <at> rediffmail.com>
> 
> Section: 3.1.3
> 
> Original Text
> -------------
>    |   DURATION         | 0 or 1   | If present, REPEAT MUST be        |
>    |                    |          | present.                          |
>    |   REPEAT           | 0 or 1   | If present, DURATION MUST be      |
>    |                    |          | present.                          |
> 
> Corrected Text
> --------------
>    |   DURATION         | 0 or 1   | If present, DURATION MUST be      |
>    |                    |          | present.                          |
>    |   REPEAT           | 0 or 1   | If present, REPEAT MUST be        |
>    |                    |          | present.                          |
> 
(Continue reading)

Reinhold Kainhofer | 30 Nov 16:33 2011

Re: [ietf-calsify] [Editorial Errata Reported] RFC5546 (3037)

On 30/11/2011 16:24, Peter Saint-Andre wrote:
> Cyrus, please let us know if you agree with this report.
>
> On 11/30/11 5:29 AM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5546,
>> "iCalendar Transport-Independent Interoperability Protocol (iTIP)".
>> [...]
>> --------------------------------------
>> Type: Editorial
>> Reported by: Praveen Bhamidipati <bhamidipati_praveen <at> rediffmail.com>
>>
>> Section: 3.1.3
>>
>> Original Text
>> -------------
>>    |   DURATION         | 0 or 1   | If present, REPEAT MUST be        |
>>    |                    |          | present.                          |
>>    |   REPEAT           | 0 or 1   | If present, DURATION MUST be      |
>>    |                    |          | present.                          |
>>
>> Corrected Text
>> --------------
>>    |   DURATION         | 0 or 1   | If present, DURATION MUST be      |
>>    |                    |          | present.                          |
>>    |   REPEAT           | 0 or 1   | If present, REPEAT MUST be        |
>>    |                    |          | present.                          |
>>
>> Notes
>> -----
>> Currently, the Component/Property doesn't match the term used in Comment. That needs to be corrected.
(Continue reading)

Eliot Lear | 30 Nov 16:40 2011
Picon

Re: [ietf-calsify] [Editorial Errata Reported] RFC5546 (3037)

I agree with Reinhold on this one.

On 11/30/11 4:33 PM, Reinhold Kainhofer wrote:
> On 30/11/2011 16:24, Peter Saint-Andre wrote:
>> Cyrus, please let us know if you agree with this report.
>>
>> On 11/30/11 5:29 AM, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC5546,
>>> "iCalendar Transport-Independent Interoperability Protocol (iTIP)".
>>> [...]
>>> --------------------------------------
>>> Type: Editorial
>>> Reported by: Praveen Bhamidipati <bhamidipati_praveen <at> rediffmail.com>
>>>
>>> Section: 3.1.3
>>>
>>> Original Text
>>> -------------
>>>    |   DURATION         | 0 or 1   | If present, REPEAT MUST be        |
>>>    |                    |          | present.                          |
>>>    |   REPEAT           | 0 or 1   | If present, DURATION MUST be      |
>>>    |                    |          | present.                          |
>>>
>>> Corrected Text
>>> --------------
>>>    |   DURATION         | 0 or 1   | If present, DURATION MUST be      |
>>>    |                    |          | present.                          |
>>>    |   REPEAT           | 0 or 1   | If present, REPEAT MUST be        |
>>>    |                    |          | present.                          |
>>>
(Continue reading)

Peter Saint-Andre | 30 Nov 16:43 2011

Re: [ietf-calsify] [Editorial Errata Reported] RFC5546 (3037)

With my individual hat on, I agree. I was going to immediately reject it
but wanted to check with the author / WG first.

On 11/30/11 8:40 AM, Eliot Lear wrote:
> I agree with Reinhold on this one.
> 
> On 11/30/11 4:33 PM, Reinhold Kainhofer wrote:
>> On 30/11/2011 16:24, Peter Saint-Andre wrote:
>>> Cyrus, please let us know if you agree with this report.
>>>
>>> On 11/30/11 5:29 AM, RFC Errata System wrote:
>>>> The following errata report has been submitted for RFC5546,
>>>> "iCalendar Transport-Independent Interoperability Protocol (iTIP)".
>>>> [...]
>>>> --------------------------------------
>>>> Type: Editorial
>>>> Reported by: Praveen Bhamidipati <bhamidipati_praveen <at> rediffmail.com>
>>>>
>>>> Section: 3.1.3
>>>>
>>>> Original Text
>>>> -------------
>>>>    |   DURATION         | 0 or 1   | If present, REPEAT MUST be        |
>>>>    |                    |          | present.                          |
>>>>    |   REPEAT           | 0 or 1   | If present, DURATION MUST be      |
>>>>    |                    |          | present.                          |
>>>>
>>>> Corrected Text
>>>> --------------
>>>>    |   DURATION         | 0 or 1   | If present, DURATION MUST be      |
(Continue reading)

Cyrus Daboo | 30 Nov 16:48 2011

Re: [ietf-calsify] [Editorial Errata Reported] RFC5546 (3037)

Hi Peter,

--On November 30, 2011 8:24:26 AM -0700 Peter Saint-Andre 
<stpeter <at> stpeter.im> wrote:

> Cyrus, please let us know if you agree with this report.

As Reinhold just pointed out the errata is wrong. RFC5546's current text is 
absolutely correct. The correct text is simply stating that if any one of 
DURATION or REPEAT is present, then the other must be present too.

--

-- 
Cyrus Daboo
Bernard Desruisseaux | 1 Dec 15:30 2011
Picon

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

To improve consistency, we should modify Section 3.8.7.2. Date-Time Stamp and Section 3.8.7.3. Last Modified to use the same phrasing as Section 3.8.7.1. Date-Time Created and Section 3.8.2.1. Date-Time Completed.

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] 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] 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 ModifiedOriginal 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 <brent <at> beanfield.com> 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
ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Gmane