[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
- [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{… Marc Blanchet
- [VCARDDAV] WGLC comments on draft-ietf-vcarddav-w… Julian Reschke
- Re: [VCARDDAV] vcarddav WGLC on draft-ietf-vcardd… Helge Hess
- Re: [VCARDDAV] vcarddav WGLC on draft-ietf-vcardd… Helge Hess
- Re: [VCARDDAV] vcarddav WGLC on draft-ietf-vcardd… Julian Reschke
- Re: [VCARDDAV] vcarddav WGLC on draft-ietf-vcardd… Filip Navara
- [VCARDDAV] allprop behaviour, was: vcarddav WGLC … Julian Reschke
- [VCARDDAV] use of DTD in draft-ietf-vcarddav-card… Julian Reschke
- [VCARDDAV] broken XML in examples, was: vcarddav … Julian Reschke
- [VCARDDAV] IANA Considerations, was: vcarddav WGL… Julian Reschke
- [VCARDDAV] REPORT related comments, was: vcarddav… Julian Reschke
- [VCARDDAV] Pseudo-properties in reports, was: vca… Julian Reschke
- Re: [VCARDDAV] allprop behaviour, was: vcarddav W… Cyrus Daboo
- Re: [VCARDDAV] use of DTD in draft-ietf-vcarddav-… Cyrus Daboo
- Re: [VCARDDAV] broken XML in examples, was: vcard… Cyrus Daboo
- Re: [VCARDDAV] IANA Considerations, was: vcarddav… Cyrus Daboo
- Re: [VCARDDAV] REPORT related comments, was: vcar… Cyrus Daboo
- [VCARDDAV] Minor issues in carddav, was: vcarddav… Julian Reschke
- Re: [VCARDDAV] use of DTD in draft-ietf-vcarddav-… Julian Reschke
- Re: [VCARDDAV] REPORT related comments, was: vcar… Julian Reschke
- [VCARDDAV] some more editorial issues with cardda… Julian Reschke
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Arnaud Quillaud
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Julian Reschke
- [VCARDDAV] carddav requirements on DAV:displaynam… Julian Reschke
- [VCARDDAV] Entity tag related requirements in car… Julian Reschke
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Arnaud Quillaud
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Cyrus Daboo
- [VCARDDAV] Incosinstent definition of DAV:display… Julian Reschke
- [VCARDDAV] late feedback on MKCOL ext response bo… Julian Reschke