Re: [icalendar] [IANA #912438] Expert review requested (icalendar)

Bernard Desruisseaux <bernard.desruisseaux@oracle.com> Thu, 09 June 2016 14:41 UTC

Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: icalendar@ietfa.amsl.com
Delivered-To: icalendar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336AB12D804 for <icalendar@ietfa.amsl.com>; Thu, 9 Jun 2016 07:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.645
X-Spam-Level:
X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaJyqb2v5vcv for <icalendar@ietfa.amsl.com>; Thu, 9 Jun 2016 07:41:01 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2230412D818 for <icalendar@ietf.org>; Thu, 9 Jun 2016 07:41:00 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u59EeMUe024682 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Jun 2016 14:40:23 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u59EeMBG022026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Jun 2016 14:40:22 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u59EeI14007794; Thu, 9 Jun 2016 14:40:19 GMT
Received: from dhcp-amer-vpn-rmdc-anyconnect-10-159-106-37.vpn.oracle.com (/10.159.106.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Jun 2016 07:40:18 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F26A06C-C5D9-424C-BC4B-1CBA77C29703"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
In-Reply-To: <rt-4.2.9-10897-1465434874-602.912438-6-0@icann.org>
Date: Thu, 9 Jun 2016 10:40:29 -0400
Message-Id: <7BFEA834-957C-41CC-AC22-42C0B679FBA1@oracle.com>
References: <RT-Ticket-912438@icann.org> <2DD56D786E600F45AC6BDE7DA4E8A8C117F160D4@eusaamb107.ericsson.se> <rt-4.2.9-10897-1465434874-602.912438-6-0@icann.org>
To: drafts-expert-review@iana.org, daniel.migault@ericsson.com
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/icalendar/Yk37rk5yZkDXTRjq9GZtfsBrfSY>
Cc: icalendar@ietf.org, "iana@iana.org" <iana@iana.org>
Subject: Re: [icalendar] [IANA #912438] Expert review requested (icalendar)
X-BeenThere: icalendar@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: iCalendar <icalendar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/icalendar>, <mailto:icalendar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icalendar/>
List-Post: <mailto:icalendar@ietf.org>
List-Help: <mailto:icalendar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/icalendar>, <mailto:icalendar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2016 14:41:04 -0000

Daniel, Amanda,

There are two minor changes I would like to see in Section 3.1.   Otherwise, it is OK.

The authors should also review my other comments prior to publication.

Section 3.1.  VAVAILABILITY Component

> Note that extensions, such as [RFC7809], might relax this constraint.

- Now that RFC7809 is published the following statement should be clarified / be authoritative.

> Other calendar properties MAY be specified in "VAVAILABILITY" or
> "AVAILABLE" components and are considered attributes of the marked
> block of time.  Their usage is application specific.  For example,
> the "LOCATION" property might be used to indicate that a person is
> available in one location for part of the week and a different
> location for another part of the week.

- A reference to Section 9. Privacy Considerations should be added here.

Section 5.  Calculating Free-Busy Time

>    2.  For each "VAVAILABILITY" component ordered by PRIORITY:

- Should clarify « from highest to lowest » 

Section 5.1.2. Further Example

- In the example the PRIORTY property should be specified in the VAVAILABILITY component, not in the AVAILABLE sub-component.

Section 7.1.  CalDAV Requirements Overview

- Typo: s/VAVAILBILITY/VAVAILABILITY/
- Typo/consistency: s/CALDAV scheduling inbox collection/CalDAV scheduling inbox collection/
- Typo/consistency: s/CALDAV calendar-auto-schedule/CalDAV calendar-auto-schedule/
- Typo/consistency (again): s/CALDAV scheduling inbox collection/CalDAV scheduling inbox collection/

Section 7.2.1.1.  Example: Using OPTIONS for the Discovery of Calendar Availability Support

- Incorrect line folding for the DAV response header

Section 7.2.4. CALDAV:calendar-availability Property

- Appendix B mentions the following change was made in draft-ietf-calext-availability-01 

>   7.  Limit the calendar-availability property to a single "VAVAILABILITY" component.

- The Purpose paragraph needs to clarify that the value is an iCalendar object that contains a single VAVAILABILITY component.

- The Conformance paragraph needs to be modified to specify that only one VAVAILABILITY component is allowed.

- Perhaps the following text in the Description paragraph should be moved into the Conformance paragraph

> Fot simplicity, only a single "VAVAILABILITY" component MUST be
> present in the property.  For more complex availability scenarios,
> clients can store multiple "VAVAILABILITY" components in the
> calendar user's calendar collections.

- Typo: s/Fot simplicity/For simplicity/

- The America/Montreal VTIMEZONE component definition is incorrect (i.e., pre-2006 definition).  Furthermore, the America/Montreal time zone was "turned into a link" (deprecated) in the IANA Time Zone Database (2015c).  The author may want to consider using America/Toronto instead. :-(

Section 7.2.5.  iTIP free-busy requests

> In addition,
> any "VAVAILABILITY" component specified in the CALDAV:calendar-
> availability property on the owner's Inbox, MUST be included in the
> free-busy calculation.

- Text needs to be adjusted to clarify that a single VAVAILABILITY component is allowed in the property.

Thanks,
Bernard

> Le 8 juin 2016 à 21:14, Amanda Baber via RT <drafts-expert-review@iana.org> a écrit :
> 
> Dear Bernard,
> 
> Please let us know when your review is complete. If these are OK, we'll make the assignments when the IESG notifies us that the document has been approved for publication.
> 
> Best regards,
> 
> Amanda Baber
> IANA Senior Specialist
> ICANN
> 
> On Wed Jun 08 15:54:03 2016, daniel.migault@ericsson.com wrote:
>> Hi Bernard and icalendar mailing list members,
>> 
>> 
>> As described in RFC5545, registering of an icalendar component, a
>> subcomponent or a property requires an expert review. [1] mentions
>> Bernard Desruisseaux and Cyrus Daboo as expert but the expert must be
>> someone else then the author of the draft. For that reason you have
>> been designated as the expert to review the components and properties
>> described in draft-ietf-calext-availability [2].
>> 
>> If you have any question, please feel free to contact me.
>> 
>> BR,
>> Daniel
>> [1] http://www.iana.org/assignments/icalendar/icalendar.xhtml
>> [2] https://datatracker.ietf.org/doc/draft-ietf-calext-availability/
>> 
>> Please find the components and properties with their associated
>> templates.
>> 
>> 1) Registration of component VAVAILABILITY and subcomponent AVAILABLE
>> 
>> 
>> Component Name:  VAVAILABILITY
>> 
>> Purpose:  Provide a grouping of component properties and sub-
>>   components that describe the availability associated with a
>>   calendar user.
>> 
>> Format Definition:  A "VAVAILABILITY" calendar component is defined
>>   by the following notation:
>> 
>> availabilityc  = "BEGIN" ":" "VAVAILABILITY" CRLF
>>                availabilityprop *availablec
>>                "END" ":" "VAVAILABILITY" CRLF
>> 
>> 
>> availabilityprop  = *(
>>                 ;
>>                 ; the following are REQUIRED,
>>                 ; but MUST NOT occur more than once
>>                 ;
>>                 dtstamp / uid
>>                 ;
>>                 ; the following are OPTIONAL,
>>                 ; but MUST NOT occur more than once
>>                 ;
>>                 busytype / class / created / description /
>>                 dtstart / last-mod / location / organizer /
>>                 priority /seq / summary / url /
>>                 ;
>>                 ; Either 'dtend' or 'duration' MAY appear
>>                 ; in an 'availableprop', but 'dtend' and
>>                 ; 'duration' MUST NOT occur in the same
>>                 ; 'availabilityprop'.
>>                 ; 'duration' MUST NOT be present if
>>                 ; 'dtstart' is not present
>>                 ;
>>                 dtend / duration /
>>                 ;
>>                 ; the following are OPTIONAL,
>>                 ; and MAY occur more than once
>>                 ;
>>                 categories / comment / contact /
>>                 x-prop / iana-prop
>>                 ;
>>                 )
>> 
>> availablec  = "BEGIN" ":" "AVAILABLE" CRLF
>>             availableprop
>>             "END" ":" "AVAILABLE" CRLF
>> 
>> availableprop  = *(
>>              ;
>>              ; the following are REQUIRED,
>>              ; but MUST NOT occur more than once
>>              ;
>>              dtstamp / dtstart / uid /
>>              ;
>>              ; Either 'dtend' or 'duration' MAY appear in
>>              ; an 'availableprop', but 'dtend' and
>>              ; 'duration' MUST NOT occur in the same
>>              ; 'availableprop'.
>>              ;
>>              dtend / duration /
>>              ;
>>              ; the following are OPTIONAL,
>>              ; but MUST NOT occur more than once
>>              ;
>>              created / description / last-mod /
>>              location / recurid / rrule / summary /
>>              ;
>>              ; the following are OPTIONAL,
>>              ; and MAY occur more than once
>>              ;
>>              categories / comment / contact / exdate /
>>              rdate / x-prop / iana-prop
>> 
>> )
>> 
>> Description:  A "VAVAILABILITY" component indicates a period of time
>>   within which availability information is provided.  A
>>   "VAVAILABILITY" component can specify a start time and an end time
>>   or duration.  If "DTSTART" is not present, then the start time is
>>   unbounded.  If "DTEND" or "DURATION" are not present, then the end
>>   time is unbounded.  Within the specified time period, availability
>>   defaults to a free-busy type of "BUSY-UNAVAILABLE" (see
>>   Section 3.2), except for any time periods corresponding to
>>   "AVAILABLE" sub-components.
>> 
>> "AVAILABLE" sub-components are used to indicate periods of free
>> time within the time range of the enclosing "VAVAILABILITY"
>> component.  "AVAILABLE" sub-components MAY include recurrence
>> properties to specify recurring periods of time, which can be
>> overridden using normal iCalendar recurrence behavior (i.e., use
>> of the "RECURRENCE-ID" property).
>> 
>> If specified, the "DTSTART" and "DTEND" properties in
>> "VAVAILABILITY" components and "AVAILABLE" sub-components MUST be
>> "DATE-TIME" values specified as either date with UTC time or date
>> with local time and a time zone reference.
>> 
>> The iCalendar object containing the "VAVAILABILITY" component MUST
>> contain appropriate "VTIMEZONE" components corresponding to each
>> unique "TZID" parameter value used in any DATE-TIME properties in
>> all components.  Note that extensions, such as [RFC7809], might
>> relax this constraint.
>> 
>> When used to publish available time, the "ORGANIZER" property
>> specifies the calendar user associated with the published
>> available time.
>> 
>> 
>> If the "PRIORITY" property is specified in "VAVAILABILITY"
>> components, it is used to determine how that component is combined
>> with other "VAVAILABILITY" components.  See Section 4.
>> 
>> Other calendar properties MAY be specified in "VAVAILABILITY" or
>> "AVAILABLE" components and are considered attributes of the marked
>> block of time.  Their usage is application specific.  For example,
>> the "LOCATION" property might be used to indicate that a person is
>> available in one location for part of the week and a different
>> location for another part of the week.
>> 
>> Example:  The following is an example of a "VAVAILABILITY" calendar
>>   component used to represent the availability of a user, always
>>   available Monday through Friday, 9:00 AM to 5:00 PM in the
>>   America/Montreal time zone:
>> 
>> BEGIN:VAVAILABILITY
>> ORGANIZER:mailto:bernard@example.com
>> UID:vavail-1@example.com
>> DTSTAMP:20111005T133225Z
>> BEGIN:AVAILABLE
>> UID:avail-1-A@example.com
>> SUMMARY:Monday to Friday from 9:00 to 17:00
>> DTSTART;TZID=America/Montreal:20111002T090000
>> DTEND;TZID=America/Montreal:20111002T170000
>> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
>> END:AVAILABLE
>> END:VAVAILABILITY
>> 
>> The following is an example of a "VAVAILABILITY" calendar
>> component used to represent the availability of a user available
>> Monday through Thursday, 9:00 AM to 5:00 PM at the main office,
>> and Friday 9:00 AM to 12:00 PM in the branch office in the
>> America/Montreal time zone between October 2nd and December 2nd
>> 2011:
>> 
>> 
>> BEGIN:VAVAILABILITY
>> ORGANIZER:mailto:bernard@example.com
>> UID:vavail-1@example.com
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Montreal:20111002T000000
>> DTEND;TZID=America/Montreal:20111202T000000
>> BEGIN:AVAILABLE
>> UID:avail-1-A@example.com
>> SUMMARY:Monday to Thursday from 9:00 to 17:00
>> DTSTART;TZID=America/Montreal:20111002T090000
>> DTEND;TZID=America/Montreal:20111002T170000
>> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH
>> LOCATION:Main Office
>> END:AVAILABLE
>> BEGIN:AVAILABLE
>> UID:avail-1-B@example.com
>> SUMMARY:Friday from 9:00 to 12:00
>> DTSTART;TZID=America/Montreal:20111006T090000
>> DTEND;TZID=America/Montreal:20111006T120000
>> RRULE:FREQ=WEEKLY
>> LOCATION:Branch Office
>> END:AVAILABLE
>> END:VAVAILABILITY
>> 
>> The following is an example of three "VAVAILABILITY" calendar
>> components used to represent the availability of a traveling
>> worker: Monday through Friday, 9:00 AM to 5:00 PM each day.
>> However, for three weeks the calendar user is working in Montreal,
>> then one week in Los Angeles, then back to Montreal.  Note that
>> each overall period is covered by separate "VAVAILABILITY"
>> components.  The last of these has no DTEND so continues on "for
>> ever".  This example shows one way "blocks" of available time can
>> be represented.  See Section 4 for another approach using
>> priorities.
>> 
>> 
>> BEGIN:VAVAILABILITY
>> ORGANIZER:mailto:bernard@example.com
>> UID:vavail-1@example.com
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Montreal:20111002T000000
>> DTEND;TZID=America/Montreal:20111023T030000
>> BEGIN:AVAILABLE
>> UID:avail-1-A@example.com
>> SUMMARY:Monday to Friday from 9:00 to 17:00
>> DTSTART;TZID=America/Montreal:20111002T090000
>> DTEND;TZID=America/Montreal:20111002T170000
>> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
>> LOCATION:Montreal
>> END:AVAILABLE
>> END:VAVAILABILITY
>> BEGIN:VAVAILABILITY
>> ORGANIZER:mailto:bernard@example.com
>> UID:vavail-2@example.com
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Los_Angeles:20111023T000000
>> DTEND;TZID=America/Los_Angeles:20111030T000000
>> BEGIN:AVAILABLE
>> UID:avail-2-A@example.com
>> SUMMARY:Monday to Friday from 9:00 to 17:00
>> DTSTART;TZID=America/Los_Angeles:20111023T090000
>> DTEND;TZID=America/Los_Angeles:20111023T170000
>> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
>> LOCATION:Los Angeles
>> END:AVAILABLE
>> END:VAVAILABILITY
>> BEGIN:VAVAILABILITY
>> ORGANIZER:mailto:bernard@example.com
>> UID:vavail-3@example.com
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Montreal:20111030T030000
>> BEGIN:AVAILABLE
>> UID:avail-3-A@example.com
>> SUMMARY:Monday to Friday from 9:00 to 17:00
>> DTSTART;TZID=America/Montreal:20111030T090000
>> DTEND;TZID=America/Montreal:20111030T170000
>> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
>> LOCATION:Montreal
>> END:AVAILABLE
>> END:VAVAILABILITY
>> 
>> 
>> 
>> 2)  Registration of property BUSYTYPE
>> 
>> Property Name:  BUSYTYPE
>> 
>> Purpose:  This property specifies the default busy time type.
>> 
>> Value Type:  TEXT
>> 
>> Property Parameters:  IANA and non-standard property parameters can
>>   be specified on this property.
>> 
>> Conformance:  This property can be specified within "VAVAILABILITY"
>>   calendar components.
>> 
>> Format Definition:  This property is defined by the following
>>   notation:
>> 
>> busytype      = "BUSYTYPE" busytypeparam ":" busytypevalue CRLF
>> 
>> busytypeparam = *(";" other-param)
>> 
>> busytypevalue = "BUSY" / "BUSY-UNAVAILABLE" /
>>                "BUSY-TENTATIVE" / iana-token / x-name
>>               ; Default is "BUSY-UNAVAILABLE".
>> 
>> Description:  This property is used to specify the default busy time
>>   type.  The values correspond to those used by the "FBTYPE"
>>   parameter used on a "FREEBUSY" property, with the exception that
>>   the "FREE" value is not used in this property.  If not specified
>>   on a component that allows this property, the default is "BUSY-
>>   UNAVAILABLE".
>> 
>> Example:  The following is an example of this property:
>> 
>> BUSYTYPE:BUSY
> 
> 
>