Subject: Re: [calsify] draft-ietf-calext-availability

From: Cyrus Daboo <[email-masked]>
Date: Wed, 02 Mar 2016 12:18:16 -0500

Hi Ken,
Thanks for your review. Comments below:

--On February 29, 2016 at 11:38:46 AM -0500 Ken Murchison 
<[email-masked]> wrote:

> A few comments:
>
> - The current text in Section 4 leaves me unclear as to whether the
> ordering of VAVAILABILITY components by priority means that the expected
> order is:
>      0, 1, 2, ... , 8, 9
> OR
>      0, 9, 8, ... , 2, 1

This is a little awkward as we are re-using the RFC5545 property PRIORITY 
and it defines "1" as the highest priority and "9" as the lowest priority 
and "0" (the default value in the absence of the property) as "undefined". 
However, for arithmetic purposes we need to define how a value of "0" needs 
to be treated and we choose to treat that as a priority lower than "9". 
Hence the ordering from low to high is 0, 9, 8, 7, 6, 5, 4, 3, 2, 1. That 
order is described in the fifth paragraph of Section 4. Is there any 
specific text in that section that leads you to think some other order is 
implied?

> - The text in Section 5.1.1 (available 8:00AM to 6:00PM, 2 hr event)
> doesn't match the iCalendar data in Appendix A (available 9:00AM to
> 6:00PM, 1 hr event) - I'd suggest fixing the iCalendar data to match the
> text since the table in 5.1.1 uses 2 hr blocks of time on even hours

Fixed in my working copy.

> - Since VAVAILABILITY components can be stored in calendar collections,
> do we need to add a section that discusses how it behaves with
> CALDAV:time-range?  Perhaps a new Section 6.2.x such as the following:

Good point - thanks. I have included that in my working copy.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Wed, 2 Mar 2016 14:35:47 -0500

> On Mar 2, 2016, at 12:18 PM, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi Ken,
> --On February 29, 2016 at 11:38:46 AM -0500 Ken Murchison <[email-masked]> wrote:
> 
>> A few comments:
>> 
> This is a little awkward as we are re-using the RFC5545 property PRIORITY and it defines "1" as the highest priority and "9" as the lowest priority and "0" (the default value in the absence of the property) as "undefined". However, for arithmetic purposes we need to define how a value of "0" needs to be treated and we choose to treat that as a priority lower than "9". Hence the ordering from low to high is 0, 9, 8, 7, 6, 5, 4, 3, 2, 1. That order is described in the fifth paragraph of Section 4. Is there any specific text in that section that leads you to think some other order is implied?

Reading it again it seems clear to me. I'm not sure why I was confused in the first place. 

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University