Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11

Eliot Lear <lear@cisco.com> Thu, 08 March 2012 13:18 UTC

Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4313621F8685; Thu, 8 Mar 2012 05:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.546
X-Spam-Level:
X-Spam-Status: No, score=-110.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh1j18p6UjVR; Thu, 8 Mar 2012 05:18:41 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F621F8668; Thu, 8 Mar 2012 05:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1378; q=dns/txt; s=iport; t=1331212721; x=1332422321; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/VqbGu4/4b/5CNMfJdOYqKsguJxvtGxfLJfuaNOY3uQ=; b=YLqeUFD6qcOfh3OxEUTFVsuFu34+FIHw1wMXslQdO93xCI8fYj72eACf f/iDoyz410l+353vE1X/ETV4ynGmpxbzc42VXpO17Y0atXjqV2i8i3jMJ Z9IVVEiVDMu7jIkTNlHEDGgM5NYkjzJoZ+sU1jt+EA9QtWXnop4ZrVcZy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoIFAPuwWE+Q/khN/2dsb2JhbABDhTWsVoMTgQeCCgEBAQMBEgEQDwFGEAsYAgIFIQICDwJGBg0BBwEBHodjBZsuAYxnkjOBL44pgRYElUWQGIJk
X-IronPort-AV: E=Sophos;i="4.73,552,1325462400"; d="scan'208";a="67988869"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 13:18:39 +0000
Received: from dhcp-10-55-89-64.cisco.com (dhcp-10-55-89-64.cisco.com [10.55.89.64]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28DIdFe010641; Thu, 8 Mar 2012 13:18:39 GMT
Message-ID: <4F58B1AF.20008@cisco.com>
Date: Thu, 08 Mar 2012 14:18:39 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4F588C9D.2090403@cisco.com> <4F58A77A.6090706@gmx.de>
In-Reply-To: <4F58A77A.6090706@gmx.de>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: draft-desruisseaux-caldav-sched.all@tools.ietf.org, Mark Nottingham <mnot@mnot.net>, Peter Saint-Andre <Peter.SaintAndre@webex.com>, 'IESG' <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 13:18:42 -0000

On 3/8/12 1:35 PM, Julian Reschke wrote:
> On 2012-03-08 11:40, Eliot Lear wrote:
>> ...
>>>    This document inherits, and sometimes extends, DTD productions from
>>>    Section 14 of [RFC4918].
>>
>> I would reword- "This document inherits and extends DTD productions..."
>>
>> If so, should this specification update RFC4918 in rfc-index.txt?
>
> This is similar to other specs building on WebDAV, and we haven't done
> that (saying "updates") before.
>
>> §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and
>> similar:
>>
>>>    PROPFIND behavior:  This property SHOULD NOT be returned by a
>>>       PROPFIND allprop request (as defined in Section 14.2 of
>>>       [RFC4918]).
>>
>> Why SHOULD NOT and not MUST NOT?  How should the client interpret the
>> information, if returned?
>
> SHOULD NOT is right; returning it does no harm. Also, it's consistent
> with other WebDAV specs. Having SHOULD NOT in one place and MUST NOT
> somewhere else would be awkward.

Great.  What's the client behavior if it sees it?

>
>> Throughout:
>>
>> Tables should be numbered for reference.
>
> If this is supposed to be a general rule, I would object to it. It's a
> matter of style, and thus should be discussed in the RFC style manual,
> if it ever gets updated.

No it's not.  It's for internal referencing.

Eliot