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

Cyrus Daboo <cyrus@daboo.name> Wed, 22 June 2016 15:37 UTC

Return-Path: <cyrus@daboo.name>
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 <icalendar@ietfa.amsl.com>; 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 <icalendar@ietfa.amsl.com>; 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 <icalendar@ietf.org>; 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 <cyrus@daboo.name>
To: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>, drafts-expert-review@iana.org, daniel.migault@ericsson.com
Message-ID: <A917D77ACD9D107C47D16DC9@cyrus.local>
In-Reply-To: <7BFEA834-957C-41CC-AC22-42C0B679FBA1@oracle.com>
References: <RT-Ticket-912438@icann.org> <2DD56D786E600F45AC6BDE7DA4E8A8C117F160D4@eusaamb107.ericsson.se> <rt-4.2.9-10897-1465434874-602.912438-6-0@icann.org> <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: <https://mailarchive.ietf.org/arch/msg/icalendar/0rwbEOlFQabi0jhpvW7THQnxLLA>
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 <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, 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 
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 
<bernard.desruisseaux@oracle.com> 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