Subject: [icalendar] Expert review requested

From: Daniel Migault <[email-masked]>
Date: Wed, 8 Jun 2016 15:53:39 +0000

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 9 Jun 2016 10:40:29 -0400

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.

> 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 <[email-masked]> 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, [email-masked] wrote:
>> 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].
>>

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 22 Jun 2016 11:23:20 -0400

Hi Bernard,
Thanks for your review. Sorry I have not been able to address your comments 
until now. All changes described below have been made to my working copy 
and will be published in a new draft once I have addressed comments from 
other reviewers.

> clarified / be authoritative.

I have changed the above text to follow on from the previous sentence so we 
now have:

    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, unless [RFC7809] is in effect.

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

Added. I also decided that we need some additional text in the privacy 
section to cover the case of published or iTIP messaged VAVAILABILITY 
components too.

> - Should clarify « from highest to lowest »

Fixed.

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

Fixed.

> - 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/

Fixed.

> - Incorrect line folding for the DAV response header

Fixed.

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

Fixed.

> - 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. :-(

I chose to remove the VTIMEZONE component entirely since we are trying to 
promot use of timezones by reference. To encourage that, I have added text 
and a link to RFC7809.

> component is allowed in the property.

Fixed.

-- 
Cyrus Daboo