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

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

Julian Reschke

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