W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2009

some more editorial issues with carddav-06, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 16 Mar 2009 17:51:32 +0100
Message-ID: <49BE8394.9030707@gmx.de>
To: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org

below are some more minor issues...:

1) 6.1.1:

"In this example, the OPTIONS response indicates that the server 
supports CardDAV in this namespace, therefore the '/addressbooks/users/' 
collection may be used as a parent for address book collections as the 
extended MKCOL method is available, and as a possible target for REPORT 
requests for address book reports."

The fact that (a) the server does know about carddav, and (b) that it 
supports extended MKCOL does not necessarily mean it will be able to 
create address books everywhere below the Request-URI... If this kind of 
feature discovery is needed, then we probably need to invent something 
like DAV:supported-resource-types (and define that in ext-mkcol).

2) 6.2.2: legacy types

It would be interesting to see an example where the server also supports 
the "legacy" mime types (as they use a parameter).

3) 6.2.2: copy/move behavior

     MUST be protected as it indicates the level of support provided by 
the server.
COPY/MOVE behavior:
     This property value MUST be preserved in COPY and MOVE operations."

That essentially means that best-effort copy of address books is not 
allowed -- is this really intended??? I think it's not consistent with 
the behavior in other WebDAV specs (such as a copy of a version history 
resource that is also a collection). See also, 

4) 6.3 Creating Resources

"Address book collections and address object resources may be created by 
either a CardDAV client or by the CardDAV server."

Actually, it's always the server creating them. I believe this should 
state that creation can be *initiated* by both the server or the client.

5) 6.3.2 Creating Address Object Resources

"The request to change an existing address object resource is the same, 
but with a specific ETag in the "If-Match" header, rather than the 
"If-None-Match" header."

That suggests that an update operation *needs* If-Match. Proposal: 
rephrase to make clear it's optional, but provides protection against 
overlapping updates.

Best regards, Julian
Received on Monday, 16 March 2009 16:52:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:43 UTC