carddav requirements on DAV:displayname, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Hi,

looking at Section 6.3.1:

    Clients SHOULD use the DAV:displayname property for a human-readable
    name of the address book.  Clients can either specify the value of
    the DAV:displayname property in the request body of the extended
    MKCOL request, or alternatively issue a PROPPATCH request to change
    the DAV:displayname property to the appropriate value immediately
    after using the extended MKCOL request.  Clients SHOULD NOT set the
    DAV:displayname property to be the same as any other address book
    collection at the same URI "level".  When displaying address book
    collections to users, clients SHOULD check the DAV:displayname
    property and use that value as the name of the address book.  In the
    event that the DAV:displayname property is not set, the client MAY
    use the last part of the address book collection URI as the name,
    however that path segment may be "opaque" and not represent any
    meaningful human-readable text. -- 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-6.3.1>

In particular:

    ...Clients SHOULD NOT set the
    DAV:displayname property to be the same as any other address book
    collection at the same URI "level"...

I realize that this is another CalDAVism.

What I'm concerned with is that this introduces a normative requirement, 
which, in some cases, may be very expensive to implement, for instance 
if the parent collection of the address books is very large. Also, what 
is a client supposed to do when the user-assigned displayname turns out 
to be already in use? Report an error and ask the user for a different 
name???

In general, WebDAV clients can not rely on DAV:displayname being unique 
across a collection and will have to fall back to the last path segment 
if they need to present something unique to the user. Thus, violating 
the SHOULD level requirement would not cause any interop problems, and 
thus use of RFC2119 terminology is not really required. So, IMHO, the 
spec should better just *encourage* assignment of meaningful names here.

(Besiders, if this really is a problem, shouldn't it also be mentioned 
for COPY and MOVE???)

Related to this: it seems that CARDDAV:calendar-description duplicates 
information that is already contained in DAV:displayname. Compare:

"If present, the property contains a description of the calendar 
collection that is suitable for presentation to a user." 
(CARDDAV:calendar-description)

   and

"Contains a description of the resource that is suitable for 
presentation to a user." (DAV:displayname)

Is there any reason to believe that adding a new property here is really 
useful (other than consistency with CalDAV :-))?

Best regards, Julian

Received on Tuesday, 17 March 2009 13:50:18 UTC