From nobody Wed Jun 8 08:53:45 2016 Return-Path: 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 ; 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 ; 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 ; 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 To: ":" , "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: Cc: "iana@iana.org" Subject: [icalendar] Expert review requested X-BeenThere: icalendar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: iCalendar List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:53:44 -0000 Hi Bernard and icalendar mailing list members,=20 =20 As described in RFC5545, registering of an icalendar component, a subcompon= ent or a property requires an expert review. [1] mentions Bernard Desruisse= aux 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-ava= ilability [2]. If you have any question, please feel free to contact me. BR,=20 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 =3D "BEGIN" ":" "VAVAILABILITY" CRLF availabilityprop *availablec "END" ":" "VAVAILABILITY" CRLF availabilityprop =3D *( ; ; 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 =3D "BEGIN" ":" "AVAILABLE" CRLF availableprop "END" ":" "AVAILABLE" CRLF availableprop =3D *( ; ; 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=3DAmerica/Montreal:20111002T090000 DTEND;TZID=3DAmerica/Montreal:20111002T170000 RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111002T000000 DTEND;TZID=3DAmerica/Montreal:20111202T000000 BEGIN:AVAILABLE UID:avail-1-A@example.com SUMMARY:Monday to Thursday from 9:00 to 17:00 DTSTART;TZID=3DAmerica/Montreal:20111002T090000 DTEND;TZID=3DAmerica/Montreal:20111002T170000 RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111006T090000 DTEND;TZID=3DAmerica/Montreal:20111006T120000 RRULE:FREQ=3DWEEKLY 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=3DAmerica/Montreal:20111002T000000 DTEND;TZID=3DAmerica/Montreal:20111023T030000 BEGIN:AVAILABLE UID:avail-1-A@example.com SUMMARY:Monday to Friday from 9:00 to 17:00 DTSTART;TZID=3DAmerica/Montreal:20111002T090000 DTEND;TZID=3DAmerica/Montreal:20111002T170000 RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Los_Angeles:20111023T000000 DTEND;TZID=3DAmerica/Los_Angeles:20111030T000000 BEGIN:AVAILABLE UID:avail-2-A@example.com SUMMARY:Monday to Friday from 9:00 to 17:00 DTSTART;TZID=3DAmerica/Los_Angeles:20111023T090000 DTEND;TZID=3DAmerica/Los_Angeles:20111023T170000 RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111030T030000 BEGIN:AVAILABLE UID:avail-3-A@example.com SUMMARY:Monday to Friday from 9:00 to 17:00 DTSTART;TZID=3DAmerica/Montreal:20111030T090000 DTEND;TZID=3DAmerica/Montreal:20111030T170000 RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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 =3D "BUSYTYPE" busytypeparam ":" busytypevalue CRLF busytypeparam =3D *(";" other-param) busytypevalue =3D "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 nobody Thu Jun 9 07:41:05 2016 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Thu, 9 Jun 2016 10:40:29 -0400 Message-Id: <7BFEA834-957C-41CC-AC22-42C0B679FBA1@oracle.com> References: <2DD56D786E600F45AC6BDE7DA4E8A8C117F160D4@eusaamb107.ericsson.se> 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: Cc: icalendar@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:41:04 -0000 --Apple-Mail=_9F26A06C-C5D9-424C-BC4B-1CBA77C29703 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =C2=AB from highest to lowest =C2=BB=20 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=20 > 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 =C3=A0 21:14, Amanda Baber via RT = a =C3=A9crit : >=20 > Dear Bernard, >=20 > 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. >=20 > Best regards, >=20 > Amanda Baber > IANA Senior Specialist > ICANN >=20 > On Wed Jun 08 15:54:03 2016, daniel.migault@ericsson.com wrote: >> Hi Bernard and icalendar mailing list members, >>=20 >>=20 >> 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]. >>=20 >> If you have any question, please feel free to contact me. >>=20 >> BR, >> Daniel >> [1] http://www.iana.org/assignments/icalendar/icalendar.xhtml >> [2] https://datatracker.ietf.org/doc/draft-ietf-calext-availability/ >>=20 >> Please find the components and properties with their associated >> templates. >>=20 >> 1) Registration of component VAVAILABILITY and subcomponent AVAILABLE >>=20 >>=20 >> Component Name: VAVAILABILITY >>=20 >> Purpose: Provide a grouping of component properties and sub- >> components that describe the availability associated with a >> calendar user. >>=20 >> Format Definition: A "VAVAILABILITY" calendar component is defined >> by the following notation: >>=20 >> availabilityc =3D "BEGIN" ":" "VAVAILABILITY" CRLF >> availabilityprop *availablec >> "END" ":" "VAVAILABILITY" CRLF >>=20 >>=20 >> availabilityprop =3D *( >> ; >> ; 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 >> ; >> ) >>=20 >> availablec =3D "BEGIN" ":" "AVAILABLE" CRLF >> availableprop >> "END" ":" "AVAILABLE" CRLF >>=20 >> availableprop =3D *( >> ; >> ; 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 >>=20 >> ) >>=20 >> 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. >>=20 >> "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). >>=20 >> 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. >>=20 >> 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. >>=20 >> When used to publish available time, the "ORGANIZER" property >> specifies the calendar user associated with the published >> available time. >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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: >>=20 >> 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=3DAmerica/Montreal:20111002T090000 >> DTEND;TZID=3DAmerica/Montreal:20111002T170000 >> RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,TU,WE,TH,FR >> END:AVAILABLE >> END:VAVAILABILITY >>=20 >> 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: >>=20 >>=20 >> BEGIN:VAVAILABILITY >> ORGANIZER:mailto:bernard@example.com >> UID:vavail-1@example.com >> DTSTAMP:20111005T133225Z >> DTSTART;TZID=3DAmerica/Montreal:20111002T000000 >> DTEND;TZID=3DAmerica/Montreal:20111202T000000 >> BEGIN:AVAILABLE >> UID:avail-1-A@example.com >> SUMMARY:Monday to Thursday from 9:00 to 17:00 >> DTSTART;TZID=3DAmerica/Montreal:20111002T090000 >> DTEND;TZID=3DAmerica/Montreal:20111002T170000 >> RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111006T090000 >> DTEND;TZID=3DAmerica/Montreal:20111006T120000 >> RRULE:FREQ=3DWEEKLY >> LOCATION:Branch Office >> END:AVAILABLE >> END:VAVAILABILITY >>=20 >> 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. >>=20 >>=20 >> BEGIN:VAVAILABILITY >> ORGANIZER:mailto:bernard@example.com >> UID:vavail-1@example.com >> DTSTAMP:20111005T133225Z >> DTSTART;TZID=3DAmerica/Montreal:20111002T000000 >> DTEND;TZID=3DAmerica/Montreal:20111023T030000 >> BEGIN:AVAILABLE >> UID:avail-1-A@example.com >> SUMMARY:Monday to Friday from 9:00 to 17:00 >> DTSTART;TZID=3DAmerica/Montreal:20111002T090000 >> DTEND;TZID=3DAmerica/Montreal:20111002T170000 >> RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Los_Angeles:20111023T000000 >> DTEND;TZID=3DAmerica/Los_Angeles:20111030T000000 >> BEGIN:AVAILABLE >> UID:avail-2-A@example.com >> SUMMARY:Monday to Friday from 9:00 to 17:00 >> DTSTART;TZID=3DAmerica/Los_Angeles:20111023T090000 >> DTEND;TZID=3DAmerica/Los_Angeles:20111023T170000 >> RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111030T030000 >> BEGIN:AVAILABLE >> UID:avail-3-A@example.com >> SUMMARY:Monday to Friday from 9:00 to 17:00 >> DTSTART;TZID=3DAmerica/Montreal:20111030T090000 >> DTEND;TZID=3DAmerica/Montreal:20111030T170000 >> RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,TU,WE,TH,FR >> LOCATION:Montreal >> END:AVAILABLE >> END:VAVAILABILITY >>=20 >>=20 >>=20 >> 2) Registration of property BUSYTYPE >>=20 >> Property Name: BUSYTYPE >>=20 >> Purpose: This property specifies the default busy time type. >>=20 >> Value Type: TEXT >>=20 >> Property Parameters: IANA and non-standard property parameters can >> be specified on this property. >>=20 >> Conformance: This property can be specified within "VAVAILABILITY" >> calendar components. >>=20 >> Format Definition: This property is defined by the following >> notation: >>=20 >> busytype =3D "BUSYTYPE" busytypeparam ":" busytypevalue CRLF >>=20 >> busytypeparam =3D *(";" other-param) >>=20 >> busytypevalue =3D "BUSY" / "BUSY-UNAVAILABLE" / >> "BUSY-TENTATIVE" / iana-token / x-name >> ; Default is "BUSY-UNAVAILABLE". >>=20 >> 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". >>=20 >> Example: The following is an example of this property: >>=20 >> BUSYTYPE:BUSY >=20 >=20 >=20 --Apple-Mail=_9F26A06C-C5D9-424C-BC4B-1CBA77C29703 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 =C2=AB = from highest to lowest =C2=BB 

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 =C3=A0 21:14, Amanda Baber via RT <drafts-expert-review@iana.org> a =C3=A9crit :

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  =3D "BEGIN" ":" "VAVAILABILITY" CRLF
=             &n= bsp;  availabilityprop *availablec
=             &n= bsp;  "END" ":" "VAVAILABILITY" CRLF


availabilityprop  =3D *(
=             &n= bsp;   ;
=             &n= bsp;   ; the following are REQUIRED,
=             &n= bsp;   ; but MUST NOT occur more than once
=             &n= bsp;   ;
=             &n= bsp;   dtstamp / uid
=             &n= bsp;   ;
=             &n= bsp;   ; the following are OPTIONAL,
=             &n= bsp;   ; but MUST NOT occur more than once
=             &n= bsp;   ;
=             &n= bsp;   busytype / class / created / description /
=             &n= bsp;   dtstart / last-mod / location / organizer /
=             &n= bsp;   priority /seq / summary / url /
=             &n= bsp;   ;
=             &n= bsp;   ; Either 'dtend' or 'duration' MAY appear
=             &n= bsp;   ; in an 'availableprop', but 'dtend' and
=             &n= bsp;   ; 'duration' MUST NOT occur in the same
=             &n= bsp;   ; 'availabilityprop'.
=             &n= bsp;   ; 'duration' MUST NOT be present if
=             &n= bsp;   ; 'dtstart' is not present
=             &n= bsp;   ;
=             &n= bsp;   dtend / duration /
=             &n= bsp;   ;
=             &n= bsp;   ; the following are OPTIONAL,
=             &n= bsp;   ; and MAY occur more than once
=             &n= bsp;   ;
=             &n= bsp;   categories / comment / contact /
=             &n= bsp;   x-prop / iana-prop
=             &n= bsp;   ;
=             &n= bsp;   )

availablec  =3D = "BEGIN" ":" "AVAILABLE" CRLF
=             av= ailableprop
=             "E= ND" ":" "AVAILABLE" CRLF

availableprop =  =3D *(
=             &n= bsp;;
=             &n= bsp;; the following are REQUIRED,
=             &n= bsp;; but MUST NOT occur more than once
=             &n= bsp;;
=             &n= bsp;dtstamp / dtstart / uid /
=             &n= bsp;;
=             &n= bsp;; Either 'dtend' or 'duration' MAY appear in
=             &n= bsp;; an 'availableprop', but 'dtend' and
=             &n= bsp;; 'duration' MUST NOT occur in the same
=             &n= bsp;; 'availableprop'.
=             &n= bsp;;
=             &n= bsp;dtend / duration /
=             &n= bsp;;
=             &n= bsp;; the following are OPTIONAL,
=             &n= bsp;; but MUST NOT occur more than once
=             &n= bsp;;
=             &n= bsp;created / description / last-mod /
=             &n= bsp;location / recurid / rrule / summary /
=             &n= bsp;;
=             &n= bsp;; the following are OPTIONAL,
=             &n= bsp;; and MAY occur more than once
=             &n= bsp;;
=             &n= bsp;categories / comment / contact / exdate /
=             &n= bsp;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=3DAmerica/Montreal:20111002T090000
DTEND;TZID=3DAmerica/Montreal:20111002T170000
RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111002T000000
DTEND;TZID=3DAmerica/Montreal:20111202T000000
BEGIN:AVAILABLE
UID:avail-1-A@example.com
SUMMARY:Monday to Thursday from 9:00 to 17:00
DTSTART;TZID=3DAmerica/Montreal:20111002T090000
DTEND;TZID=3DAmerica/Montreal:20111002T170000
RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111006T090000
DTEND;TZID=3DAmerica/Montreal:20111006T120000
RRULE:FREQ=3DWEEKLY
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=3DAmerica/Montreal:20111002T000000
DTEND;TZID=3DAmerica/Montreal:20111023T030000
BEGIN:AVAILABLE
UID:avail-1-A@example.com
SUMMARY:Monday to Friday from 9:00 to 17:00
DTSTART;TZID=3DAmerica/Montreal:20111002T090000
DTEND;TZID=3DAmerica/Montreal:20111002T170000
RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Los_Angeles:20111023T000000
DTEND;TZID=3DAmerica/Los_Angeles:20111030T000000
BEGIN:AVAILABLE
UID:avail-2-A@example.com
SUMMARY:Monday to Friday from 9:00 to 17:00
DTSTART;TZID=3DAmerica/Los_Angeles:20111023T090000
DTEND;TZID=3DAmerica/Los_Angeles:20111023T170000
RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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=3DAmerica/Montreal:20111030T030000
BEGIN:AVAILABLE
UID:avail-3-A@example.com
SUMMARY:Monday to Friday from 9:00 to 17:00
DTSTART;TZID=3DAmerica/Montreal:20111030T090000
DTEND;TZID=3DAmerica/Montreal:20111030T170000
RRULE:FREQ=3DWEEKLY;BYDAY=3DMO,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 =      =3D "BUSYTYPE" busytypeparam ":" = busytypevalue CRLF

busytypeparam =3D *(";" = other-param)

busytypevalue =3D "BUSY" / = "BUSY-UNAVAILABLE" /
=             &n= bsp;  "BUSY-TENTATIVE" / iana-token / x-name
=             &n= bsp; ; 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




= --Apple-Mail=_9F26A06C-C5D9-424C-BC4B-1CBA77C29703-- From nobody Wed Jun 22 08:37:11 2016 Return-Path: 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 E1BDF12DAEC for ; Wed, 22 Jun 2016 08:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, 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 p6rVsr4DKhP3 for ; Wed, 22 Jun 2016 08:37:08 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (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 E1D0012DA38 for ; Wed, 22 Jun 2016 08:23:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 902D64636074; Wed, 22 Jun 2016 11:23:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGW3FxSHwDKk; Wed, 22 Jun 2016 11:23:24 -0400 (EDT) Received: from [17.168.87.230] (unknown [17.44.178.123]) by daboo.name (Postfix) with ESMTPSA id C59264636066; Wed, 22 Jun 2016 11:23:22 -0400 (EDT) Date: Wed, 22 Jun 2016 11:23:20 -0400 From: Cyrus Daboo To: Bernard Desruisseaux , drafts-expert-review@iana.org, daniel.migault@ericsson.com Message-ID: In-Reply-To: <7BFEA834-957C-41CC-AC22-42C0B679FBA1@oracle.com> References: <2DD56D786E600F45AC6BDE7DA4E8A8C117F160D4@eusaamb107.ericsson.se> <7BFEA834-957C-41CC-AC22-42C0B679FBA1@oracle.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=4174 Archived-At: Cc: icalendar@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:37:10 -0000 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=20 and will be published in a new draft once I have addressed comments from=20 other reviewers. --On June 9, 2016 at 10:40:29 AM -0400 Bernard Desruisseaux=20 wrote: > 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. 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. >> 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. Added. I also decided that we need some additional text in the privacy=20 section to cover the case of published or iTIP messaged VAVAILABILITY=20 components too. > Section 5. Calculating Free-Busy Time > >> 2. For each "VAVAILABILITY" component ordered by PRIORITY: > > - Should clarify =C2=AB from highest to lowest =C2=BB Fixed. > 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. Fixed. > 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/ Fixed. > Section 7.2.1.1. Example: Using OPTIONS for the Discovery of Calendar > Availability Support > > - Incorrect line folding for the DAV response header Fixed. > 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/ 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=20 promot use of timezones by reference. To encourage that, I have added text=20 and a link to RFC7809. > 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. > Fixed. --=20 Cyrus Daboo