RE: Yaron.Redirect.NoRelative

I've been assuming that we would stand by our general philosophy, that
servers never have to verify that the target exists, or track the target as
it moves.  So they don't have to maintain the value of DAV:reftarget.  Of
course, we don't currently forbid servers to do that.

I've also assumed that servers would generally do the minimum required of
them.  So in general, when they receive a MKRESOURCE to create a redirect
reference, they would just stuff the value of DAV:reftarget into the (dead)
property.  The client would know enough about its application to make a
judgment about whether a relative or absolute URI in DAV:reftarget would be
more likely to survive unbroken over time, given that the server is not
going to do anything to maintain it.  If the application is one where most
redirect references have targets within a hierarchy that typically gets
moved as a whole, it will be safer to use relative URIs than absolute URIs.

--Judy

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Monday, February 21, 2000 3:19 AM
To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
Subject: RE: Yaron.Redirect.NoRelative


I am not arguing that relative URLs must be banned from everything,
everywhere. I am just asking that relative URL support be removed from the
DAV:RefTarget element used in the MKRESOURCE method.

If there is a scenario where a MKRESOURCE intended to create a redirect
resource cannot properly work without the ability to specify a relative URL
in the DAV:RefTarget XML element then I will withdraw my objection. 

Otherwise, based on K.I.S.S. and my arguments below, we need to pull out
relative URL support in the DAV:RefTarget XML element.

			Yaron

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@Rational.Com]
> Sent: Sun, February 20, 2000 5:54 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Yaron.Redirect.NoRelative
> 
> 
> There are many cases where "fixing up the references" is not feasible.
> For example, if you are not moving a collection, but rather 
> are creating
> an alias for it (e.g. via BIND), then you need references that work
> with either of the legal names for the collection.
> 
> Since relative references are trivial for a server to implement, and
> very useful for many client applications, I believe it is important
> for them to be supported.  
> 
> Cheers,
> Geoff
> 
> 
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Yaron Goland
> Sent: Friday, February 11, 2000 2:53 AM
> To: 'w3c-dist-auth@w3.org'
> Subject: Yaron.Redirect.NoRelative
> 
> 
> Section 9 of the redirect spec allows for the use of relative 
> URIs in the
> reftarget production. Relative URIs are an extremely 
> dangerous feature that
> have caused havoc amongst system implementers. Even so, in many
> circumstances they offer such a high value that the problems 
> they cause are
> worth dealing with. I do not believe that this is one of those
> circumstances.
> The primary (and in my opinion only) utility for relative 
> URIs is to allow
> humans to type in relative URIs so that they can create links 
> and documents
> without having to specify their final location. For example, 
> a web site
> designer can use Notepad to type in the links for their web page using
> relative URLs. That way the web site designer can test out 
> the site in their
> test location and not have to go through and change all the 
> links when they
> move it to their final destination.
> This exact functionality could, of course, be implemented 
> automatically. For
> example, Microsoft FrontPage is able to check Office and HTML 
> documents and
> identify their links. If an Office or HTML document is moved 
> then FrontPage
> will automatically check all the links, see if the move 
> breaks any of them
> and if so it will automatically fix them.
> Hence the utility of relative URIs is mainly that it saves 
> some humans in
> some cases some work. That is, it was easier to implement 
> relative URIs then
> to enable all servers to read all file formats and be able to 
> fix links.
> There is a second benefit to relative URIs that apply 
> uniquely to protocols
> - they save bytes. If one is returning a large number of 
> links that are all
> relative to some base one can save bytes by returning the 
> URIs in a relative
> form.
> The downside to relative URIs is figuring out what the base is. HTTP
> provides at least two different mechanisms including the 
> request-URI and the
> content-base header. Various data formats then provide their 
> own solutions.
> Both HTML and XML have proposals/implementations for what the 
> base should
> be. The rules for figuring out the base are complex and 
> rarely implemented
> consistently. As the PM for WinInet dealing with the 
> subtleties of relative
> URIs was one of the banes of my experience.
> What is especially bad is the conflict. If a request has a 
> content-base
> header and a base specification in the HTML in the request 
> which one is to
> be used? There are rules for figuring this out but they are 
> rarely properly
> implemented.
> The end result of the confusion is that it is best to avoid 
> relative URIs
> whenever possible. 
> In the case of WebDAV the human benefits for the use of 
> relative URIs are
> obviously irrelevant. Therefore the only argument for the use 
> of relative
> URIs is that they save bytes. However given that we are using XML the
> bandwidth taken by the URIs is the absolutely least of our 
> problems. As such
> when choosing between a simple, easy to process rule "the URI 
> is always
> absolute" and a rule that introduces additional complexity for little
> benefit "the URI is relative", we should clearly come down on 
> the side of
> simplicity.
> Therefore I move that relative URIs be removed from protocol 
> elements in the
> redirect spec and that section 9 be deleted in its entirety.
>

Received on Monday, 21 February 2000 14:16:16 UTC