[icalendar] Expert review requested

[Daniel Migault <[e-mail]>]

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