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

Julian Reschke <julian.reschke@gmx.de> Fri, 13 March 2009 14:49 UTC

Return-Path: <julian.reschke@gmx.de>
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 4D9F83A680E for <vcarddav@core3.amsl.com>; Fri, 13 Mar 2009 07:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.912
X-Spam-Level:
X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-1.913, 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 pdh8xfekf+3B for <vcarddav@core3.amsl.com>; Fri, 13 Mar 2009 07:49:24 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1B61A3A687E for <vcarddav@ietf.org>; Fri, 13 Mar 2009 07:49:23 -0700 (PDT)
Received: (qmail invoked by alias); 13 Mar 2009 14:50:00 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp066) with SMTP; 13 Mar 2009 15:50:00 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1820NlNV802qCAcV5WRzZe/46h26qr4RN3hrpNr4b qG0uufzu17zFbs
Message-ID: <49BA7294.9010305@gmx.de>
Date: Fri, 13 Mar 2009 15:49:56 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
References: <49A2CFC8.3080805@viagenie.ca>
In-Reply-To: <49A2CFC8.3080805@viagenie.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.54
Subject: [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: Fri, 13 Mar 2009 14:49:31 -0000

Hi,

below some comments related to the WebDAV reports defined in Section 8 
(<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8>).

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).

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).

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".

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.

Best regards, Julian