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
- [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