Subject: Possible problem in collection definition

From: Lisa Dusseault <[email-masked]>
Date: Thu, 16 Feb 2006 18:46:20 -0800

From bug 227 <http://ietf.webdav.org:8080/bugzilla/show_bug.cgi? 
id=227>:

     For all WebDAV compliant resources A and B, identified by URLs "U"
     and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST
     be a collection that contains a mapping from "SEGMENT" to B. So, if
     resource B with URL "http://example.com/bar/blah" is WebDAV  
compliant
     and if resource A with URL "http://example.com/bar/" is WebDAV
     compliant, then resource A must be a collection and must contain a
     mapping from "blah" to B.

and an example from just after:

     An example for this case are servers that support multiple alias  
URLs
     for each WebDAV compliant resource.  For instance, a server may
     implement case-insensitive URLs, thus "/col/a" and "/col/A"  
identify
     the same resource, yet only either "a" or "A" are reported upon
     listing the members of "/col".

This example may be inconsistent with the requirement just stated.   
We can argue that '/col/a' maps to a WebDAV compliant resource and "/ 
col" maps to a WebDAV collection, thus "/col" MUST have a mapping  
from "a" to the child resource.  We can argue the same for "/col/ 
A".   Following that logic could make URL-case-insensitive servers  
rather difficult ...

It may *not* be inconsistent if we claim that "/col/a" and "/col/A"  
are the same URL. It also may not be inconsistent if we say that  
resource B is identified by one of "/col/a" or "/col/A" but not the  
other, but that wouldn't be the meaning of "identified by" that I'd  
expect.
	
Not proposing what to do about this just yet.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Feb 2006 09:29:23 +0100

Lisa Dusseault wrote:
> 
>  From bug 227 <http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=227>:
> 
>     resource B with URL "http://example.com/bar/blah" is WebDAV compliant
>     An example for this case are servers that support multiple alias URLs
>     implement case-insensitive URLs, thus "/col/a" and "/col/A" identify
> This example may be inconsistent with the requirement just stated.  We 
> can argue that '/col/a' maps to a WebDAV compliant resource and "/col" 
> maps to a WebDAV collection, thus "/col" MUST have a mapping from "a" to 
> the child resource.  We can argue the same for "/col/A".   Following 
> that logic could make URL-case-insensitive servers rather difficult ...

Correct. Note however that this is also a problem with the original 
definition.

> It may *not* be inconsistent if we claim that "/col/a" and "/col/A" are 
> the same URL. It also may not be inconsistent if we say that resource B 
> is identified by one of "/col/a" or "/col/A" but not the other, but that 
> wouldn't be the meaning of "identified by" that I'd expect.

But they aren't the same URL. And even if they would, are "/col/a." and 
"/col/a" the same URL? Or "/col/%20a"? All of these map to the same 
resource on IIS.

> Not proposing what to do about this just yet.

We need to relax the language such that the server is allowed to 
suppress alias URLs. Let's just note this problem right now and fix it 
during WGLC.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 18 Feb 2006 08:27:20 -0700

I think the following addition would solve the problem.  Following
the paragraph quoted below, add the paragraph:

  An exception to this rule occurs if the server performs "case-folding"
  on the URL segments, e.g. considers the segment "AB" to be equivalent
  to the segements "Ab", "aB", and "ab".  In this case, A MUST contain
  a mapping to B from one of the segments that are equivalent to 
"SEGMENT".

Cheers,
Geoff

[email-masked] wrote on 02/17/2006 01:29:23 AM:
> >  From bug 227 
compliant
URLs
identify

> > It may *not* be inconsistent if we claim that "/col/a" and "/col/A" 
are

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 19 Feb 2006 09:29:32 -0800

That's nearly what I had in mind, but I wonder if case-folding is the  
only acceptable way for servers to have multiple URLs for the same  
resources and only advertise one of them.  What about a server that  
automatically finds a "foo.html" file when clients ask for "foo.htm"?

Lisa