W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

new issue: DAV:displayname

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 17 Aug 2003 13:03:21 +0200
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCGEBGIDAA.julian.reschke@gmx.de>


looking at our recent discussion, I feel that we clearly have a problem with
the usage of DAV:displayname.

The current situation seems to be:

1) Some servers implement DAV:displayname as protected live property that
just reflects the last name segment of the request URI (Microsoft IIS)

2) Other servers implement DAV:displayname as dead property that by default
is not set until it get's explicitly set by a client (Apache moddav)

We are currently discussing whether 1) is ok. My position is that it's
clearly not, as

- the value of the last path segment is not "a description of the resource
that is suitable for presentation to a user",

- replicating something that's already available from the <href> element of
the PROPFIND response into a property just has no benefit at all,

- clients demonstratibly can cope with absent DAV:displayname values (as
they all interoperate with Apache moddav today) and finally

- the concept of a property that varies with the request URI is deeply
incompatible with the concept of multiple bindings to resources.

So my preference would be just to state that DAV:displayname SHOULD NOT be
used to replicate the information from the last path segment.

Another alternative would be to *deprecate* DAV:displayname and to define a
new property with more precisely defined semantics, such as DAV:description.

Note that this in fact *is* a interoperability issues, as we are getting
lots of complaints from users not being able to set display names on some
remote WebDAV servers mounted into the SAP Enterprise Portal.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 17 August 2003 07:04:20 UTC

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