[icalendar] Expert review requested

Daniel Migault <daniel.migault@ericsson.com> Wed, 08 June 2016 15:53 UTC

Return-Path: <daniel.migault@ericsson.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 2BFC412D772 for <icalendar@ietfa.amsl.com>; Wed, 8 Jun 2016 08:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 OoUkMhcT0TWf for <icalendar@ietfa.amsl.com>; Wed, 8 Jun 2016 08:53:41 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA60712D776 for <icalendar@ietf.org>; Wed, 8 Jun 2016 08:53:41 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-35-57583640b829
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F7.61.09012.04638575; Wed, 8 Jun 2016 17:14:08 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 11:53:39 -0400
From: Daniel Migault <daniel.migault@ericsson.com>
To: ":" <icalendar@ietf.org>, "bernard.desruisseaux@oracle.com" <bernard.desruisseaux@oracle.com>
Thread-Topic: Expert review requested
Thread-Index: AdHBnXLPYjSRCTgaRs+Q05u1XQjNQQ==
Date: Wed, 8 Jun 2016 15:53:39 +0000
Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F160D4@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPlK6DWUS4wbrvWhbPXr1ntviz+zSL Rffh92wOzB498h5Llvxk8vj49BZLAHMUl01Kak5mWWqRvl0CV8b/7j/MBcdjK6427WdrYFxs 18XIySEhYCLx5/wRJghbTOLCvfVsXYxcHEICRxklHv9/xAzhLGOU+Dl3HzNIFZuAkUTboX52 EFtEIFni7oL1LCA2s4CyxPHtv1hBbGEBBYnOxcfYIGpUJfbfesAKYetJfDzwkRHEZhFQkbi8 7xlYDa+Ar8T7i1fAbEagK76fWsMEMVNc4taT+VDXCUgs2XOeGcIWlXj5+B8rhK0kMWnpOVaI eh2JBbs/sUHY2hLLFr5mhpgvKHFy5hOWCYwis5CMnYWkZRaSlllIWhYwsqxi5CgtLsjJTTcy 2MQIjINjEmy6OxjvT/c8xCjAwajEw/vAOTxciDWxrLgy9xCjBAezkgivvG1EuBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFesUeK4UIC6YklqdmpqQWpRTBZJg5OqQZGbxet2/7lZxa9Str3Zr5s 6qp7l/9uOXS/R2VjbPbz69yvtaewbi/oulPfftBjx4TQcnFJI19vN66LbnoFr9nMZiXWnpU7 /te22dz+seapd6s+zDf6GZrONsdc4tmJ+6ZJXWnWHWbpkTeatqoetI1asf2+idqKtTwTrl6Z Po+997pMsISds6WAEktxRqKhFnNRcSIA6Ww9+38CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/icalendar/UfOzRUkPPEKO6Zb7GlMxqn_hDG8>
Cc: "iana@iana.org" <iana@iana.org>
Subject: [icalendar] Expert review requested
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: Wed, 08 Jun 2016 15:53:44 -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: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