Subject: aliasing and other (primarily) editorial issues with -protocol-08

From: "Larry Masinter" <[email-masked]>
Date: Tue, 8 Sep 1998 23:58:11 PDT

I've owed it to the group to submit an analysis of -protocol-08 over
the issue of URL aliases; I apologize for the delay.

As you may recall, the issue I raised was one of whether the
webdav draft required that a DAV-compliant resource had one, and
only one, URI. I pointed out the various situations of aliasing,
of which 'case sensitive URI' is only one instance, but other kinds
of aliasing might also be possible.

   A collection is a resource whose state consists of at least a list
   of internal members and a set of properties, but which may have
   additional state such as entity bodies returned by GET.  An internal
   member resource MUST have a URI that is immediately relative to the
   base URI of the collection.  That is, the internal member's URI is
   equal to the parent collection's URI plus an additional segment
   where segment is defined in section 3.2.1 of RFC 2068 [Fielding et
   al., 1996].

In this paragraph, it isn't clear whether "MUST have a URI that is ..."
means "MUST have only one URI; that URI is ..." or 
      "MUST have at least one URI which is ..." 
that is, is the requirement of the member resource be that it
has no aliases anywhere, or just that aliases are out of scope,
or is it just that the requirement on member resources be that there
is at least one way of accessing it.

Now, if it is allowed that referent of "the internal member's URI"
is "the URI that fits the description above", i.e., an internal
member might also have other URIs too.

   Any given internal member MUST only belong to the collection once,
   i.e., it is illegal to have multiple instances of the same URI in a
   collection.

Perhaps you mean "e.g." instead of "i.e." here; that is, the
example of 'the same URI' is one way of having 'the same resource'
in a collection; but it is probably intended that it be illegal
to have "Ford" and "FORD" as elements of the "Cars" collection,
if the server is case insensitive, even though their URIs aren't
'the same'.

I will note the curious phrase under 'locking':

   Some servers automatically replicate resources across multiple URLs.
   In such a circumstance the server MUST only accept a lock on one of
   the URLs if the server can guarantee that the lock will be honored
   across all the URLs.

and note that this might be considered a kind of aliasing, but seems
to also allow for other operations ("replication").

In any case, these are, as far as I can tell, the only places in the
entire WebDAV protocol document anything that hint at requirement that
a resource have only one URI. Adding that requirement in order
to be WebDAV compliant would seem to eliminate popular features of
web servers; eliminating the confusion and clarifying that a resource
might have multiple URIs would improve the spec.

Having done so, there seems to be no good reason to require that
the multiple URIs for a resource have the same parentage property.

In some ways, this just means that clients cannot easily be interoperable
if they have some need to perform a (currently unsupported) DAV operation
of "going up the parent tree". However, it's not clear, at this point,
whether "going up the parent tree" is a necessary operation, so my
original call for adding it may be moot. Mainly all we need is to
remove the presumption that one can "go up the parent tree" merely by
manipulating the URI used to originally access the resource.

-----------------------------------
A few minor (editorial) issues that occurred to me as I was looking
for areas that might affect this:

Throughout the document, the phrases "DAV compliant server"
and "DAV complaint resource" are used. But what is the scope of
a DAV compliant server? Is it required that all resources served
by a DAV compliant server be DAV compliant resources? In the middle
of the document, there is the phrase "DAV compliant proxy". However,
section 14, DAV Compliance Classes, only describes the compliance
classes for DAV resources, and not for servers or proxies.

Is a "Dav compliant resource" one that is served by a DAV compliant
server, then? Or are some resources served by DAV-compliant servers
themselves not DAV-compliant?

What are the new requirements for "DAV compliant proxy" that are not
requirements for HTTP/1.1 proxies? (That there would be any is
curious for a protocol whose T-shirt proclaims it to be Firewall
Friendly.)

   WebDAV servers MUST treat HTTP URL namespaces as collections,
   regardless of whether they were created with the MKCOL method
   described in section 7.3.

So presumably all http: URLs served by a WebDAV (compliant) server,
when the URL is a "namespace" (which, although not defined, I assume
means "terminated with "/") are supposed to also function as
DAV (compliant?) collections.

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 9 Sep 1998 15:10:00 -0700

Larry,

Thank you for taking the time to perform a detailed review of the DAV spec.
on this issue -- it has helped me understand your concerns much better.

My comments are below.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Larry Masinter
> Sent: Tuesday, September 08, 1998 11:58 PM
> To: Webdav
> Subject: aliasing and other (primarily) editorial issues with
> -protocol-08
>
>

Let me create a small example which I hope will make my 1:1 URI to resource
mapping position clear, and show how it doesn't have the namespace
restrictions which are being attributed to it.

In my view, there is a 1:1 correspondence between a URI, and an instance of
a resource.  Since a resource is an abstraction, there is a mapping step
where this abstraction is concretely mapped onto the abstractions provided
by a particular repository.

For a file system respository, a resource is mapped onto a file.  If I
understand Larry's position correctly, for a given file "foo.html", there is
exactly one resource instance.  In my view, there can be multiple resource
instances associated with "foo.html".

But, we both recognize that there can be multiple paths by which "foo.html"
can be accessed.  There might be an FTP URL, and an HTTP URL.  As Larry has
pointed out, there can be multiple HTTP URLs (aliases) by which "foo.html"
can be accessed, and I agree that a GET on any of these HTTP URLs will
retrieve an entity based on the contents of "foo.html".

The point of divergence lies with the modeling of "foo.html" with the
resource abstraction.  My position is that there can be many instances of
the resource abstraction which map to the same physical file "foo.html".
Each instance corresponds to a different URI.

I believe that Larry models "foo.html" as having exactly one instance of the
resource abstraction associated with it, but that there can be multiple URIs
which identify this instance.

So, if the file "foo.html" can be retrieved from the following URLs:

http://www.web.com/foocollect/foo.html
http://www.web.com/FOOCOLLECT/foo.html
http://www.web/com/anothercollect/baz.html

Then I view these as being three URLs which identify three resources which
each represent the file "foo.html", while Larry views these as three URLs
which identify one resource which represents the file "foo.html".

Based on this, I view a collection as containing the exactly one URI for a
resource.  However, as the example above shows, this doesn't imply that the
file "foo.html" cannot appear in more than one collection.  This also means
I don't find the language, "MUST have at least one URI which is a member of
the collection", since it isn't meaningful to me for a resource to have more
than one URI.  But, I know what you mean, and this language is perfectly
meaningful if a there is only one resource for an underlying chunk of state,
such as the file "foo.html".

Note that by having a 1:1 correspondence between URI and resource, this
doesn't mean the underlying chunk of state (the file "foo.html") only has
one parent.  However, in the 1:1 mapping, each *resource* does have one
parent, and each resource's parent can be determined by evaluating the
relative URI ".." operator on the resource's URL.

So, getting back to the previous example, for the 1:1 mapping of URI to
resource:

Resource:
http://www.web.com/foocollect/foo.html
Has parent:
http://www.web.com/foocollect/

and Resource:
http://www.web.com/FOOCOLLECT/foo.html
Has parent:
http://www.web.com/FOOCOLLECT/

and Resource:
http://www.web/com/anothercollect/baz.html
Has parent:
http://www.web/com/anothercollect/

For the many-to-one mapping of URI to resource:

The resource which models file "foo.html" has three parents:
http://www.web.com/foocollect/
http://www.web.com/FOOCOLLECT/
http://www.web/com/anothercollect/

It is currently impossible to determine two of the three parents using URL
manipulations.

As for how state-changing operations such as PUT, DELETE, and PROPPATCH
behave when issued against one of many resources which map to the same
underlying chunk of state (the file "foo.html"), this is a server policy
issue.  If the server wishes to delete all resources, and the underlying
chunk of state when a DELETE is issued against one of the URLs for a chunk
of state, that server is OK to do so.

So, following the example some more, if the file "foo.html" can be retrieved
from the following URLs:

http://www.web.com/foocollect/foo.html
http://www.web.com/FOOCOLLECT/foo.html
http://www.web/com/anothercollect/baz.html

The 1:1 mapping of URL to resource would mean that a DELETE issues against
one of these URLs, say, http://www.web.com/foocollect/foo.html, would at
minimum mean future GET requests against
http://www.web.com/foocollect/foo.html would not retrieve an entity based on
"foo.html".  The server could also decide to remove file "foo.html" and also
ensure that accesses via http://www.web.com/FOOCOLLECT/foo.html and
http://www.web/com/anothercollect/baz.html do not retrieve an entity based
on file "foo.html", but this is up to the server.

> if the server is case insensitive, even though their URIs aren't

Based on the 1:1 mapping of URI to resource, this language is internally
consistent, and the "i.e." is seen to mean "that is".

> to also allow for other operations ("replication").

This language is inconsistent with the 1:1 mapping of URI to resource.  I
would rewrite it as:

Some servers allow the same chunk of persistent state to be accessed via
multiple resources, hence URLs, sometimes by replicating and distributing
the persistent state. In such a circumstance the server MUST only accept a
lock on one of the resources if the server can guarantee that the lock will
be honored across all the resources.

> manipulating the URI used to originally access the resource.

This is dependent on your view of how a resource maps to a URI.

- Jim

---

From: John Stracke <[email-masked]>
Date: Wed, 09 Sep 1998 15:36:00 -0700

Larry Masinter wrote:

> However, it's not clear, at this point,
> whether "going up the parent tree" is a necessary operation,

Don't base HTTP clients need it for relative links?

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |Reality is what refuses to go away when I|
[email-masked]      | stop believing in it.                   |
\====================================================================/
New area code for work number: 650

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 9 Sep 1998 23:43:01 PDT

In the context of DAV, I can see things both ways, and that it would
be possible to interpret the DAV spec so that 'a resource' had
a 1-1 mapping to 'a URI', and that different URIs would be considered
different resources. However, I don't think that's consistent with
the language of the URI document, the architecture of URN resolution,
etc. I can't quite imagine how we might write a document that described
URN resolution as mapping the URN (a URI for a resource) to a URL
(a URI for a resource) without describing the relationship of the
resources represented by the two URIs as 'the same resource'.

I suppose I'm surprised that the URI document isn't clearer on this
point.

In any case, I don't think it is good to leave it ambiguous for
WebDAV, since the document actually winds up making different
requirements depending on which reading is taken.

>    i.e., it is illegal to have multiple instances of the same URI in a

If you take the 1-1 model, this basically says that it is OK to have
the same 'chunk of state' as an internal member of a collection more
than once, as long as it is reached using a different URI, e.g.,
you could have a "http://server/cars" resource with internal members
"http://server/cars/Ford" and  also "http://server/cars/FORD".
In this situation, the restriction makes no sense -- what purpose
does it serve?

There are other places where the spec seems to read awkwardly if
URI:resource were 1:1. For example, the wording in section 4.1 on
"Collection Resources":

#   There is a standing convention that when a collection is referred to
#   by its name without a trailing slash, the trailing slash is
#   automatically appended.  Due to this, a resource may accept a URI
#   without a trailing "/" to point to a collection.

(Should it be 'a server may accept a URI' rather than 'a resource
may accept...'?)

Is http://server/a/b a different resource than http://server/a/b/?
That is, they're two (different) collection resources? This would
seem to be the model you're advocating. unless there's a special case
that URI:resource is 1-1 except when the URI is a collection, in which
case there (may) be a 2-1 relationship, where both http://server/a/b and
http://server/a/b/ are actually considered the same resource.

Section 4.4:

#   For this simple case, the URL at which a
#   resource is accessed is identical to the URL at which the source
#   (the persistent state) of the resource is accessed.

This would be more simply said (if URLs = resources) that 
"the accessed resource is identical to the source resource",
wouldn't it?

#   Sometimes the entity returned by GET is the output of a data-
#   producing process that is described by one or more source resources
#   (that may not even have a location in the URL namespace). 

In this paragraph, it seems that URI:resource might be 0:1, i.e.,
if there are resources that don't have URLs.

-------------------
More editorial issues:

# DAV compliant
#   resources MUST maintain the consistency of the HTTP URL namespace.

Is there a definition of what 'the consistency of the HTP URL namespace'
means? It's not defined anywhere, and this sentence only gives an example.

#   However, the server can sometimes process HTML resources before they
 #  are transmitted as a return entity body.

The ability to do server-side processing is not restricted to HTML
entities.

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 10 Sep 1998 00:04:56 PDT

> whether "going up the parent tree" is a necessary operation,

# Don't base HTTP clients need it for relative links?

First of all, relative URI processing is independent of the
protocol. Relative links work for "ftp" and for "gopher" and
for "urn" and for "vnd.blablah".

Relative URI processing is entirely syntactic. It merely
performs a string manipulation of a "relative URI" against
a "base", without regard to any of the semantics. There
is not an operation for "going up the parent tree", there
is only an operation for performing relative URI processing
of the ".." form.

Relative URI processing is entirely under the control of
the data form or context that is providing the URI in the
first place; e.g., an author of a HTML document may or
may not choose to provide relative links within it. Since
DAV does not restrict itself to authoring HTML documents,
any particular form of document at all, there is no particular
reason why DAV resource processors need to deal with relative
forms at all.

Larry

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 10 Sep 1998 02:29:25 -0700

>I suppose I'm surprised that the URI document isn't clearer on this

It is about as clear as it can get without belaboring the point
or specifying something that isn't the case for all resources.
I've been busy writing a paper about the Web's architectural
style this past month and a good part of it tries to explain the
relationship between URI and resources.  Most of it is just a rehash
of what I already wrote for the URI spec's introduction, but I include
more rationale as to why resources are defined the way they are.

A brief summary is that a resource is a conceptual mapping, not a
chunk of state.  It is possible to have both many names for the
same resource (many URI that represent the same conceptual mapping)
and many resources that point to the same chunk of state (URI with
different conceptual mappings that just happen to point to the same
representation at a certain point in time).  Thus, the 1:1 model
does not adequately describe resources even though it is sufficient
to define the namespace requirements.  Likewise, the allocation of
the 'chunk of state' within a server has no relation to a resource
other than as the endpoint of a mapping, and thus it doesn't make
sense for WebDAV to require anything along those lines (and, as far
as I know, it doesn't).

I hate to sound like a broken record, but the problem with the WebDAV
specification is not on the requirements it makes, but rather on using
terminology that makes the requirements seem like they apply to more
than what is actually being specified.

>>    i.e., it is illegal to have multiple instances of the same URI in a

It is in fact making a very simple requirement in a very complicated
way by using the wrong terminology.  What it should say is

   Each name must be unique within a given namespace.

Because the whole issue of multiple "entries" appearing within a
single "collection" is totally irrelevant when you aren't defining
what we would normally refer to as a collection.

>In this situation, the restriction makes no sense -- what purpose

No purpose other than to answer a question leftover from when a
collection was equivalent to a directed graph.

>#   without a trailing "/" to point to a collection.

Ummm, this is bogus.  If there is no resource without the trailing slash,
and the server feels like helping the user, it might REDIRECT the request
to a DIFFERENT RESOURCE that is, in fact, the collection.  At no time
is the URI without a trailing "/" the same resource as the URI with a
trailing "/" within a good server implementation of HTTP.

>if there are resources that don't have URLs.

Everything and anything that can be identified can have a URI, and
certainly anything within a server already does have a URI (the file
scheme gets around).  What it should say is that they might not be
accessible independently, since the ability to access is separate from
the fact that they are resources.  While it is certainly possible for
a resource not to have a URI, there is no need for WebDAV to even
think about them because if it can't be identified, it can't be used.

I should also mention, since it has come up here and on the URI list
a few times, that a good HTTP server administrator does not allow
multiple URI to the same resource to be accessible unless there
is a good reason (such as differentiated access control).  The common
case is for the case-insensitive or misspelled URI to be externally
redirected to the true URI, thus helping a clueless user while at the
same time preventing an exponential explosion of resource references
when spiders come to index your site.  Like the case with the trailing "/"
redirect, these other resources do not exist at the time of the redirect.
The server is simply making a temporary (and very unstable) mapping
based on an implementation decision that is limited to the GET method.

....Roy

---

From: John Stracke <[email-masked]>
Date: Thu, 10 Sep 1998 10:33:11 -0700

Larry Masinter wrote:

> may not choose to provide relative links within it.

Sure, if they don't mind taking on extra pain when they try to
maintain their site.  It's a scalability thing: someone who
authors a large-scale corpus has pretty much got to use relative
links.

> Since

I disagree.  Since relative links are so important for the way
people write content for the Web, it is vital that DAV
accommodate them.  Making DAV collections correspond to the
syntax that relative links depend on will make it easier for
people to organize their content into DAV collections and write
relative links accordingly.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | I'm not imaginary.  I'm ontologically   |
[email-masked]      |  challenged.                            |
\====================================================================/
New area code for work number: 650

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 10 Sep 1998 11:07:27 -0700

> sense for WebDAV to require anything along those lines (and, as far

This makes sense to me.

>    Each name must be unique within a given namespace.

When I read this, I first went, "broken record? What broken record?"  Then I
went "namespace -- what an overloaded term!"  However, checking through the
list archives I find:

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0095.html

which was posted on January 26, 1998, where Roy advocates the use of the
term "namespace" instead of "collection", and discusses containment models.
Of course, not having been involved in the XML Namespace discussion,
"namespace" might seem like a less overloaded term than collection.  But,
given that the DAV spec. currently uses the term "namespace" with its XML
meaning, it behooves us not to reuse the term "namespace" when discussing
collections.

> what we would normally refer to as a collection.

Reading though the DAV spec., I agree that the wording of the terminology in
the collections section could be more precise.

> Each name must be unique within a given namespace.

Except I'd change it to read:

Each collection member URI MUST be unique within a given collection.

Although, this is *exactly* equivalent to the existing language in the spec.
which reads:

"A collection is a resource whose state consists of at least a list of
internal members and a set of properties..."

"Any given internal member MUST only belong to the collection once, i.e., it
is illegal to have multiple instances of the same URI in a collection."

Granted, this last sentence would be more clear if it read, "Any given
internal member *URI* MUST ...", but in combination with the definition of a
collection, the implication that the internal member is a URI seems fairly
clear.

> trailing "/" within a good server implementation of HTTP.

I'm OK with tweaking the wording here to say that this is due to a
redirection, since I agree that a client cannot know ahead of time whether
http://foo.bar.com/a and http://foo.bar.com/a/ are the same resource -- only
the server has this knowledge.

- Jim