RE: Clarification of URI vs. resource

Jason writes:
> This thread/discussion has been great.  My hat is off to JimW for starting
> it.

Aw, shucks.  But, really, Larry Masinter deserves all the credit for raising
consciousness on this issue, and for motivating this thread.

> It appears to have died down now or moved off-line.  It's unclear to
> me if we've come to an agreement or not.  Jim, perhaps you could update
> (the wording of) your initial proposal based on some of the comments... or
> just sumarize the comments that followed and let everyone say if
> they agree or not.

Let me first summarize points on which I believe the list has come to
agreement:

1) A collection can have more than one URI.

Larry Masinter raised this point in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0127.html

2) The member URIs of a collection will "change" depending on the URI used
to access the collection.

This was brought up by me in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0130.html
And also by Yaron Goland in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0132.html
Jim Davis I believe agrees in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0143.html

Larry Masinter then noted that the definition of internal member URIs in the
specification doesn't match this shared understanding, and should be
changed.
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0135.html

This implies some spec. changes to me:
- the definition of collection and internal member URI requires some
tweaking
- the specification should explicitly note that collections might be
accessible via more than one URI
- when a new resource is created, the Request-URI of the creation method is
only added to a single collection resource (after tweaking to make it a
relative URI), but if this collection resource is accessible via multiple
URLs, then the newly created resource also MUST (SHOULD?) be available via
multiple URLs (so it is available via the multiple names of the collection).

3) Folding the URL space for case insensitive servers (may not have
agreement on this point -- let's see).

Larry Masinter raised this point in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0127.html
Jim Davis also discussed it in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0143.html

Some servers may have case insensitive namespaces, in essence creating 2^n
URIs by which a resource can be accessed (where n is the number of non-slash
characters after the hostname in a URL). In this case a server should only
display one of the 2^n URIs for each resource in a PROPFIND result, and
should accept any of the 2^n URIs as the Request-URI for a method.  The
collection resource contains all 2^n URIs (but will never display all 2^n
URIs, nor should a reasonable implementation actually explicitly store all
2^n URIs).  When creating a new resource, the server will add all 2^n URIs
to its parent collection resource.  Essentially, the server is using its
special knowledge about the namespace to behave more intelligently.

For servers which are not case sensitive, the server cannot behave more
intelligently, and hence the server will behave as if any of the 2^n case
variants of a URI are the URI for a different resource.  Such a server can
contain any of the set of 2^n case variants of a URI in a collection, and
will list all of these URIs on a PROPFIND.

This raises the question of whether a client needs to be able to discover
whether a collection is case insensitive.

4) Cannonicalization of the base URI for a collection

Larry Masinter, in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0127.html

Raises the point that if you're performing relative URI operations, you need
to have a cannonical form of the base part of the URI.  This probably will
look like a restatement of the equality rules for HTTP URLs given in section
3.2.3 of RFC 2068.

5) Clean up use of URI/URL

Larry Masinter, in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0142.html

Highlights that the use of URI and URL is inconsistent in the DAV spec., and
gives an alternate definition of URI/URL for use in the spec.   It seems
prudent to review all uses of these terms to ensure they're being used
consistently, and use the new definition for URI/URL.


Areas of disagreement:

1) Unknown disagreement:

Larry Masinter wrote in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0138.html
> I don't understand why there's a constraint here at all, but
> if there is one, and clients rely on it, then let's make sureit's clear.

Roy Fielding agreed:
> I'll agree with Larry here -- I've been staying out of the debate
> largely because I don't understand the need for the requirement at all.

The only problem is that I don't understand what constraint they're talking
about! Is this a discussion of case sensitivity, or namespace consistency?
I'm not sure.


Please let me know if I have missed any points, or incorrectly summarized an
issue.

- Jim

Received on Wednesday, 11 November 1998 15:42:41 UTC