Subject: RE: Comments on the "new" 2518--Display Name

From: "Kevin Wiggen" <[email-masked]>
Date: Fri, 3 Mar 2006 15:36:57 -0800

Well I am not a spec writer nor an English major and I often say Pascal
is my native language BUT:

Webdav servers and clients must understand that the method for
identifying resources is still the URL.  While generic Webdav clients
will be able to display DAV:displayname to end users, both sides of the
Webdav protocol must understand that if users are allowed to do things
like rename, move, copy etc, generic clients must show the URLs to these
end users to allow these operations.  Changes to DAV:displayname do not
issue moves or copies to the server, but simply change a piece of
meta-data on the individual resource.

Language should be added to the spec that makes this clear, as we
routinely hear from people whom have read the spec that expectations
around displayname are not the same as what the spec designers are
telling me on this list.

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 6:06 AM
To: Kevin Wiggen
Cc: [email-masked]
Subject: Re: Comments on the "new" 2518--Display Name

Kevin Wiggen wrote:
> 
> Not sure you understood my question.  I would like readers of the spec
> to understand the difference between a URL and Display Name and
> understand how that operates in the real world (MS Webfolders, Apple
> OSX, Xythos).  Webdav clients that make Webdav server look like file
> systems should expect the URL to be used in displays to users and NOT
> display name.  As client developers we often get into conflict on this
> point.  We of course can add a column in windows explorer to SHOW the
> display name, but the URL is the correct item to show users in this
> generic Webdav client.

Well, I wanted to make sure that what you're after is a clarification of

  how WebDAV has been working all the time, not something we changed in 
RFC2518bis.

So yes, I agree that it would be useful to state that the 
DAV:displayname property is not a replacement for the URL, that even in 
presence of nice DAV:displayname there are still good reason to assign 
meaningful URLs, and that clients can not assume that displaynames will 
be unique for the members of a collection.

Do you want to propose specific text?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Mar 2006 14:58:57 +0100

> around displayname are not the same as what the spec designers are

+1 on the language proposed by Kevin.

best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 6 Mar 2006 09:07:59 -0500

+1 from me as well.  I believe Kevin's paragraph addresses the key
confusions around DAV:displayname.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Mar 2006 21:44:27 +0100

> confusions around DAV:displayname.

OK, I have opened an issue for proposed changes to DAV:displayname, see 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=236>.

The proposed changes are:

Section 15.2., para. 6:
OLD:

     Description:   The DAV:displayname property should be defined on all
       DAV compliant resources.  If present, the property contains a
       description of the resource that is suitable for presentation to a
       user.  This property is defined on the resource, and hence SHOULD
       have the same value independent of the Request-URI used to
       retrieve it (thus computing this property based on the Request-URI
       is deprecated).

NEW:

     Description:   The property contains a description of the resource
       that is suitable for presentation to a user.  This property is
       defined on the resource, and hence SHOULD have the same value
       independent of the Request-URI used to retrieve it (thus computing
       this property based on the Request-URI is deprecated).

       Servers and clients must understand that the method for
       identifying resources is still the URL.  While generic clients
       will be able to display DAV:displayname to end users, both sides
       of the protocol must understand that if users are allowed to
       perform operations such as rename, move, copy etc, generic clients
       must display the URLs (or the path segments used in the displayed
       collection) to allow these operations.  Changes to DAV:displayname
       do not issue moves or copies to the server, but simply change a
       piece of meta-data on the individual resource.

1) Take out the statement "The DAV:displayname property should be 
defined on all DAV compliant resources." - that doesn't make any sense 
at all. If a server doesn't know a good displayname, it shouldn't return 
one.

2) Incorporate text based on Kevin's suggestion.

Best regards, Julian