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

Cyrus Daboo <cyrus@daboo.name> Tue, 03 March 2015 17:21 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA9E1A885C; Tue, 3 Mar 2015 09:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 v8JVY6C8mmoh; Tue, 3 Mar 2015 09:21:44 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA4C1A1B81; Tue, 3 Mar 2015 09:21:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C27BDD539C4; Tue, 3 Mar 2015 12:21:43 -0500 (EST)
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 ArqYygFyzQcP; Tue, 3 Mar 2015 12:21:43 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 866EDD539B6; Tue, 3 Mar 2015 12:21:41 -0500 (EST)
Date: Tue, 03 Mar 2015 12:21:37 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Robert Sparks <rjsparks@nostrum.com>, General Area Review Team <gen-art@ietf.org>, ietf@ietf.org, calsify@ietf.org, draft-ietf-calext-rscale@tools.ietf.org
Subject: Re: Gen-art LC (and telechat) review: draft-ietf-calext-rscale-04
Message-ID: <619D561548E6D87707B49948@caldav.corp.apple.com>
In-Reply-To: <54F5E92F.7030002@nostrum.com>
References: <54F5E92F.7030002@nostrum.com>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1882
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ThLaJWR6XfqP4CJoiMz7aUPgF-o>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2015 17:21:47 -0000

Hi Robert,
Thanks for your review.

--On March 3, 2015 at 11:02:39 AM -0600 Robert Sparks 
<rjsparks@nostrum.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?


-- 
Cyrus Daboo