Subject: [calsify] Gen-art LC (and telechat) review: draft-ietf-calext-rscale-04

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Mar 2015 11:02:39 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-calext-rscale-04
Reviewer: Robert Sparks
Review Date: 03-03-2015
IETF LC End Date: 03-03-2015
IESG Telechat date: 03-05-2015

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?

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 03 Mar 2015 12:21:37 -0500

Hi Robert,
Thanks for your review.

> 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?

-- 
Cyrus Daboo

---

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Mar 2015 11:54:09 -0600

On 3/3/15 11:21 AM, Cyrus Daboo wrote:
> 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:
>
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.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 14:45:42 +0200

>> 
>> 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:
>> 

This works for me as well.

I am assuming the sponsoring AD will ensure that the changes get implemented in the draft before the RFC Editor takes it over. I have balloted No-Obj for this draft in tonight’s IESG telechat.

Jari

P.S. Many thanks for your review, Robert!