Re: [VCARDDAV] REPORT related comments, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

Cyrus Daboo <cyrus@daboo.name> Mon, 16 March 2009 02:22 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D443A689F for <vcarddav@core3.amsl.com>; Sun, 15 Mar 2009 19:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.44
X-Spam-Level:
X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=-1.441, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK1xsH5cX4yU for <vcarddav@core3.amsl.com>; Sun, 15 Mar 2009 19:22:13 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id DC56D3A67F2 for <vcarddav@ietf.org>; Sun, 15 Mar 2009 19:22:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 17F9B1295247; Sun, 15 Mar 2009 22:22:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9CYDCKslxHJ; Sun, 15 Mar 2009 22:22:52 -0400 (EDT)
Received: from [10.0.1.197] (unknown [10.0.1.1]) by daboo.name (Postfix) with ESMTP id F33F0129523C; Sun, 15 Mar 2009 22:22:51 -0400 (EDT)
Date: Sun, 15 Mar 2009 22:22:51 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Julian Reschke <julian.reschke@gmx.de>, WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
Message-ID: <C0FC5B418D3606949B2713CE@socrates.local>
In-Reply-To: <49BA7294.9010305@gmx.de>
References: <49A2CFC8.3080805@viagenie.ca> <49BA7294.9010305@gmx.de>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2945"
Subject: Re: [VCARDDAV] REPORT related comments, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "vCard and CardDAV Engineering List, potential WG" <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2009 02:22:14 -0000

Hi Julian,

--On March 13, 2009 3:49:56 PM +0100 Julian Reschke <julian.reschke@gmx.de> 
wrote:

> 1) Editorial: when referring to specific reports (not the REPORT method),
> the spec sometimes uses "report", and sometimes "REPORT". Please be
> consistent (with a preference on the lowercase variant, to distinguish
> from the actual method name).

Fixed.

> 2) WebDAV reports should be consistent in how various depths are handled
> (see RFC 3253, Section 3.6). The best way to achieve this is by exactly
> defining what the scope is for Depth == 0. If the request URI is a WebDAV
> collection, the behavior for Depth == 1 or Depth == infinity will follow
> from that. Otherwise it should be specified or ruled out (see ACL
> reports).
>
> 3) Related to that:
>
> "As a result the "Depth" header MUST be ignored by the server and SHOULD
> NOT be sent by the client." --
> <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>
>
> Nope. Really :-). This is incompatible with generic report handling.
> Instead, specify the desired behavior for Depth == 0, require clients to
> set Depth == 0 or leave it out, and require servers to return status 400
> for other values (like in RFC 3744).

Ok, so then we go with "the Depth header MUST be present and set to the 
value 0 (zero)" in all of these reports. Is that sufficient?

> 4) Editorial:
>
> "The request body MUST be a CARDDAV:addressbook-multiget XML element (see
> Section 10.7, which MUST contain at least one DAV: href XML element, and
> one optional CARDDAV:address-data element as defined in Section 10.4."
> -- <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>
>
> Missing ")" after "Section 10.7".

Fixed.

> 5) It goes on saying:
>
> "If the Request-URI is a collection resource, then the DAV:href elements
> MUST refer to resources within that collection, and they MAY refer to
> resources at any depth within the collection. As a result the "Depth"
> header MUST be ignored by the server and SHOULD NOT be sent by the
> client. If the Request-URI refers to a non-collection resource, then
> there MUST be a single DAV:href element that is equivalent to the
> Request-URI."
>
> I think it would be simpler to define it this way:
>
> "If DAV:href elements are present, the scope of the request is the set of
> resources identified by these elements, which all need to be members (not
> necessarily internal members) of the resource identified by the
> Request-URI. Otherwise, the scope is the resource identified by the
> Request-URI itself."
>
> This avoids the special-casing, and gets rid of the repeated URI in the
> DAV:href element for non-collections.

I have made this change. Whilst this is technically significant in that it 
changes the way things work when the multiget is targeted at a single URI, 
I don't believe I have seen anyone actually using it that way in CalDAV so 
it won't hurt to do the change here.

-- 
Cyrus Daboo