From ietf-calsify-bounces@osafoundation.org Thu Dec 1 06:30:57 2011 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@ietfa.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93871F0CB4 for ; Thu, 1 Dec 2011 06:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghxnSlFLvDjq for ; Thu, 1 Dec 2011 06:30:56 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0701F0C5C for ; Thu, 1 Dec 2011 06:30:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id A5FB63E1F98; Thu, 1 Dec 2011 06:30:55 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76AF-t+GczPn; Thu, 1 Dec 2011 06:30:51 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9E8393E017E; Thu, 1 Dec 2011 06:30:49 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DF54E3E017E for ; Thu, 1 Dec 2011 06:30:47 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjTkz+jd+1Sv for ; Thu, 1 Dec 2011 06:30:32 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTPS id 55E8C3E017D for ; Thu, 1 Dec 2011 06:30:31 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pB1EURng022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 14:30:27 GMT Received: from hqcfmt0202.oracle.com (hqcfmt0202.oracle.com [148.87.24.201]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pB1EUPPc001358; Thu, 1 Dec 2011 14:30:25 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (server vdefault) with ESMTP ; Thu, 01 Dec 2011 06:30:19 -0800 Message-ID: <4ED78F79.8080202@oracle.com> Date: Thu, 01 Dec 2011 09:30:17 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: RFC Errata System References: <20111130191518.B8DEA6217F@rfc-editor.org> In-Reply-To: <20111130191518.B8DEA6217F@rfc-editor.org> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4ED78F84.00BF,ss=1,re=-2.300,fgs=0 Cc: presnick@qualcomm.com, ietf-calsify@osafoundation.org, brent@beanfield.com Subject: Re: [ietf-calsify] [Technical Errata Reported] RFC5545 (3038) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1030231336==" Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============1030231336== Content-Type: multipart/alternative; boundary="------------060904090204070808000908" This is a multi-part message in MIME format. --------------060904090204070808000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 > > 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 --------------060904090204070808000908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 <brent@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


--------------060904090204070808000908-- --===============1030231336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============1030231336==-- From ietf-calsify-bounces@osafoundation.org Tue Dec 6 09:39:01 2011 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@ietfa.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD81021F8A67 for ; Tue, 6 Dec 2011 09:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.278 X-Spam-Level: X-Spam-Status: No, score=-104.278 tagged_above=-999 required=5 tests=[AWL=-1.679, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvgUmJriMaUE for ; Tue, 6 Dec 2011 09:39:00 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by ietfa.amsl.com (Postfix) with ESMTP id E463121F886A for ; Tue, 6 Dec 2011 09:38:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EEEE677D702; Tue, 6 Dec 2011 09:38:56 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erbu7teRfXfu; Tue, 6 Dec 2011 09:38:56 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 72D7F794018; Tue, 6 Dec 2011 09:38:52 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 531EE77D70B for ; Tue, 6 Dec 2011 09:32:25 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVNW8iqH07WE for ; Tue, 6 Dec 2011 09:31:58 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by leka.osafoundation.org (Postfix) with ESMTP id C486477D6F9 for ; Tue, 6 Dec 2011 09:31:57 -0800 (PST) Received: from dhcp-64-101-72-158.cisco.com (unknown [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0C1E42341; Tue, 6 Dec 2011 10:39:08 -0700 (MST) Message-ID: <4EDE5189.3040603@stpeter.im> Date: Tue, 06 Dec 2011 10:31:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Bernard Desruisseaux References: <20111130191518.B8DEA6217F@rfc-editor.org> <4ED78F79.8080202@oracle.com> In-Reply-To: <4ED78F79.8080202@oracle.com> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Cc: presnick@qualcomm.com, ietf-calsify@osafoundation.org, brent@beanfield.com, RFC Errata System Subject: Re: [ietf-calsify] [Technical Errata Reported] RFC5545 (3038) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org 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: > 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 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 >> >> 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@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify