ietf
[Top] [All Lists]

Re: Gen-art LC (and telechat) review: draft-ietf-calext-rscale-04

2015-03-03 11:54:53

On 3/3/15 11:21 AM, Cyrus Daboo wrote:
Hi Robert,
Thanks for your review.

--On March 3, 2015 at 11:02:39 AM -0600 Robert Sparks <rjsparks(_at_)nostrum(_dot_)com> wrote:

Summary: Ready modulo one nit

This draft reads easily (describing the  actual work converting between
calendars is hard, but this draft doesn't have to talk about that).

The body of the draft says it updates 5546 and 4791, but those are not
listed in the Updates: line in the header?

There was a lot of debate about exactly what should go in the "Updates" header. In the end we settled on this:

1) The draft does "update" 5545/6321/7265 in the sense that its changes do not use any of the standard extension points that those specs have defined (i.e., 5545 never defined how an RRULE could be extended with new elements). Thus 5545/6321/7265 ought to appear in the "Updates" header.

2) The draft clarifies what should happen when rscale is used with iTIP (5546) - but it does not introduce any new protocol elements - it simply suggests the appropriate behaviors to use. Thus 5546 does not appear in the "Updates" header.

3) The draft uses existing extension mechanisms in CalDAV (4791) to explain how it is used in that environment. Thus 4791 does not appear in the "Updates" header.

Now you are right that the introduction does use "updates" in the prose for 5546 and 4791. Perhaps it would be better to use "clarifies use of" for 5546 and "extends" for 4791. So I am proposing the following change:

     It updates iCalendar [RFC5545], xCal [RFC6321], and jCal
     [RFC7265], to extend the "RRULE" property definition.

It clarifies use of iTIP [RFC5546] to specify how the extended "RRULE"
     property should be handled in iTIP messages.

     It extends CalDAV [RFC4791] to specify how the extended "RRULE"
     property can be supported by CalDAV servers and clients.

Would that be better?
I think so.

You might also consider including the exposition above in the shepherd writeup to help avoid multiple ADs asking the same question later.