Re: [VCARDDAV] REPORT related comments, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}
Cyrus Daboo <cyrus@daboo.name> Mon, 16 March 2009 02:23 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 4899A3A689F for <ietfarch-webdav-archive@core3.amsl.com>; Sun, 15 Mar 2009 19:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.36
X-Spam-Level:
X-Spam-Status: No, score=-7.36 tagged_above=-999 required=5 tests=[AWL=2.639, 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 tTebP6TxzWJZ for <ietfarch-webdav-archive@core3.amsl.com>; Sun, 15 Mar 2009 19:23:54 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 3AEF83A67F2 for <webdav-archive@lists.ietf.org>; Sun, 15 Mar 2009 19:23:54 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1Lj2UF-0000qR-88 for w3c-dist-auth-dist@listhub.w3.org; Mon, 16 Mar 2009 02:23:31 +0000
Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from <cyrus@daboo.name>) id 1Lj2UC-0000lN-N1 for w3c-dist-auth@listhub.w3.org; Mon, 16 Mar 2009 02:23:28 +0000
Received: from daboo.name ([151.201.22.177]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from <cyrus@daboo.name>) id 1Lj2U3-0004Ht-SN for w3c-dist-auth@w3.org; Mon, 16 Mar 2009 02:23:28 +0000
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"
Received-SPF: none
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599
X-W3C-Scan-Sig: bart.w3.org 1Lj2U3-0004Ht-SN c26ec61cbbd50d6a9113ebda1d027db8
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: [VCARDDAV] REPORT related comments, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}
Archived-At: <http://www.w3.org/mid/C0FC5B418D3606949B2713CE@socrates.local>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13095
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: <E1Lj2UF-0000qR-88@frink.w3.org>
Resent-Date: Mon, 16 Mar 2009 02:23:31 +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
- 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