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

[Cyrus Daboo <[e-mail]>]

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.

--On June 9, 2016 at 10:40:29 AM -0400 Bernard Desruisseaux 
<[e-mail]> 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 
section to cover the case of published or iTIP messaged VAVAILABILITY 
components too.

> Section 5.  Calculating Free-Busy Time
>
>>    2.  For each "VAVAILABILITY" component ordered by PRIORITY:
>
> - Should clarify « from highest to lowest »

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 
promot use of timezones by reference. To encourage that, I have added text 
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.

-- 
Cyrus Daboo