Subject: new issue: DAV:displayname

From: "Julian Reschke" <[email-masked]>
Date: Sun, 17 Aug 2003 13:03:21 +0200

Hi,

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.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Jason Crawford <[email-masked]>
Date: Sun, 17 Aug 2003 16:01:20 -0400

> is not set until it get's explicitly set by a client (Apache moddav)

I tend to agree with you that among these two choices (2) is superior. But
that seems obvious.  What's more interesting is whether

(3) A server can treat it as a dead property but initialize it to the 
segment
name. 

My impression is that (2) is still a better approach.

Are there issues for mapping this to a file system? 

J.

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 17 Aug 2003 22:25:53 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Sunday, August 17, 2003 10:01 PM
> To: Julian Reschke
> Cc: 'Webdav WG'
> Subject: Re: new issue: DAV:displayname
>
>
>
segment
> name.

If I understand you correctly the server would set an initial value, and
then treat the property as dead. The result would be that unless a client
resets the DAV:displayname, it will always be the last segment of the
request URL where the resource was initially created (even if it was MOVEd
later). I think that sounds even worse than (1).

> My impression is that (2) is still a better approach.

Yes.

> Are there issues for mapping this to a file system?

Not really. A server that supports setting of dead properties (such as
Apache/moddav) doesn't have any issue. A server that does not support dead
properties on a certain resource will just reject the PROPPATCHH attempt.

Julian

---

From: Horst Liermann <[email-masked]>
Date: Mon, 18 Aug 2003 15:52:54 +0200

Hi,

I have installed "MS Sharepoint" and I tested the behavior of Sharepoint. 
Sharepoint is a basic WebDAV implementation. They have something like
versioning, but it's not DeltaV.

As far as I understand MS-Sharepoint, the behavior is:

	There is a URL "segment name" for the name of the resource.
	There is a DAV:displayname for the "title" of the resource. 

DAV:displayname normaly is not the same as the "segment name". So
DAV:displayname is a "dead" property
It's also possible NOT setting the property DAV:displayname.

Behavior is like 2). 

Horst

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Sunday, August 17, 2003 1:03 PM
To: 'Webdav WG'
Subject: new issue: DAV:displayname

Hi,

Julian