REPORT related comments, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}
Julian Reschke <julian.reschke@gmx.de> Fri, 13 March 2009 14:51 UTC
Return-Path: <w3c-dist-auth-request@listhub.w3.org>
X-Original-To: ietfarch-webdav-archive@core3.amsl.com
Delivered-To: ietfarch-webdav-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A5A3A6BE9 for <ietfarch-webdav-archive@core3.amsl.com>; Fri, 13 Mar 2009 07:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.852
X-Spam-Level:
X-Spam-Status: No, score=-7.852 tagged_above=-999 required=5 tests=[AWL=2.147, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8]
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 a+ztjXKw-ADN for <ietfarch-webdav-archive@core3.amsl.com>; Fri, 13 Mar 2009 07:51:36 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D82903A6BC1 for <webdav-archive@lists.ietf.org>; Fri, 13 Mar 2009 07:51:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1Li8im-00018O-JM for w3c-dist-auth-dist@listhub.w3.org; Fri, 13 Mar 2009 14:50:48 +0000
Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from <julian.reschke@gmx.de>) id 1Li8il-00017k-5A for w3c-dist-auth@listhub.w3.org; Fri, 13 Mar 2009 14:50:47 +0000
Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from <julian.reschke@gmx.de>) id 1Li8iW-0006Gq-5o for w3c-dist-auth@w3.org; Fri, 13 Mar 2009 14:50:46 +0000
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
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Li8iW-0006Gq-5o d328d454959799bcde914ae390a269fb
X-Original-To: w3c-dist-auth@w3.org
Subject: REPORT related comments, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}
Archived-At: <http://www.w3.org/mid/49BA7294.9010305@gmx.de>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13089
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1Li8im-00018O-JM@frink.w3.org>
Resent-Date: Fri, 13 Mar 2009 14:50:48 +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
- Re: [VCARDDAV] vcarddav WGLC on draft-ietf-vcardd… Julian Reschke
- WGLC comments on draft-ietf-vcarddav-webdav-mkcol… Julian Reschke
- allprop behaviour, was: [VCARDDAV] vcarddav WGLC … Julian Reschke
- use of DTD in draft-ietf-vcarddav-carddav-06, was… Julian Reschke
- broken XML in examples, was: [VCARDDAV] vcarddav … Julian Reschke
- IANA Considerations, was: [VCARDDAV] vcarddav WGL… Julian Reschke
- REPORT related comments, was: [VCARDDAV] vcarddav… Julian Reschke
- Pseudo-properties in reports, was: vcarddav WGLC … 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
- Re: [VCARDDAV] use of DTD in draft-ietf-vcarddav-… Julian Reschke
- Re: [VCARDDAV] REPORT related comments, was: vcar… Julian Reschke
- some more editorial issues with carddav-06, was: … Julian Reschke
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Arnaud Quillaud
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Julian Reschke
- carddav requirements on DAV:displayname, was: [VC… Julian Reschke
- Entity tag related requirements in carddav, was: … Julian Reschke
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Arnaud Quillaud
- Re: [VCARDDAV] Pseudo-properties in reports, was:… Cyrus Daboo
- Minor issues in carddav, was: [VCARDDAV] vcarddav… Julian Reschke
- Incosinstent definition of DAV:displayname in RFC… Julian Reschke
- late feedback on MKCOL ext response body, was: [V… Julian Reschke