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

[Bernard Desruisseaux <[e-mail]>]

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 <[e-mail]> 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, [e-mail] 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:[e-mail]
>> UID:[e-mail]
>> DTSTAMP:20111005T133225Z
>> BEGIN:AVAILABLE
>> UID:[e-mail]
>> 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:[e-mail]
>> UID:[e-mail]
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Montreal:20111002T000000
>> DTEND;TZID=America/Montreal:20111202T000000
>> BEGIN:AVAILABLE
>> UID:[e-mail]
>> 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:[e-mail]
>> 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:[e-mail]
>> UID:[e-mail]
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Montreal:20111002T000000
>> DTEND;TZID=America/Montreal:20111023T030000
>> BEGIN:AVAILABLE
>> UID:[e-mail]
>> 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:[e-mail]
>> UID:[e-mail]
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Los_Angeles:20111023T000000
>> DTEND;TZID=America/Los_Angeles:20111030T000000
>> BEGIN:AVAILABLE
>> UID:[e-mail]
>> 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:[e-mail]
>> UID:[e-mail]
>> DTSTAMP:20111005T133225Z
>> DTSTART;TZID=America/Montreal:20111030T030000
>> BEGIN:AVAILABLE
>> UID:[e-mail]
>> 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
> 
> 
>