WebDAV Bindings - Issue Yaron.NoSlash

The first sentence of section 5.1 reads: The BIND method creates a new
binding between the resource identified by the Request-URI and the final
segment of the Destination header (minus any trailing slash)." 

This requirement makes it impossible to directly address a collection in the
manner allowed by section 5.2 of RFC 2518. For example, if a user wishes to
bind the resource pointed to by http://foo/bar/blah to the name
http://icky/bicky/boo/ then the result of the bind method will be, due to
the removal of the trailing slash, a binding to "boo" instead of "boo/". The
second to last paragraph of section 5.2 of RFC 2518 states that
http://icky/bicky/boo/ and http://icky/bicky/boo SHOULD be the same resource
but are not required to be the same resource. Therefore the result of the
BIND method would be to cause a binding to http://icky/bicky/boo which may
be a completely different resource from the resource specified by the user,
http://ficky/bicky/boo/.

It would appear that the essential problem is that HTTP URLs can end in a
"/". In an ideal world this would not have been allowed. We would only use
"/" as a separator and therefore having it at the end of the a HTTP URL
wouldn't make any sense as there would be nothing to separate. This would
solve a lot of problems for WebDAV. Unfortunately the cat is already out of
the bag. RFC 2616 allows a "/" at the end of a URI. Implementers of RFC 2616
already use the "/" to mean a different resource from the slash less
version. Even RFC 2518 explicitly recognizes that the trailing slash and
non-trailing slash version of a HTTP URL may be different resources.
Therefore the BIND spec is directly violating RFC 2518. You absolutely can
not do this without at least pointing out, explicitly, that you are doing
this.

That having been said, what the hell? The trailing slash issue has been
dogging us forever. I would LOVE to upgrade the SHOULD in RFC 2518 to a
MUST. This, essentially, is what the BIND spec has done. But the onus is on
the BIND authors to prove that upgrading the requirement from a SHOULD to a
MUST won't cause an interoperability issue.

Therefore the BIND authors have, in my opinion, two options:

Option 1 - Change the BIND spec to allow a trailing slash and watch your
model get shredded as you attempt to deal with the semantics of a trailing
slash.

Option 2 - Keep the current language but add a note specifically stating
that you are violating RFC 2518 and, on the mailing list, provide a listing
of existing WebDAV client/server implementations and see if any of them
actually differentiate resources based on the trailing slash. If the answer
(as I suspect) is that no one differentiates based on the trailing "/" then
I think we have the basis for declaring consensus on the change. However, if
the authors fail to perform this analysis then I believe the chair MUST
strike down the BIND draft by declaring that in the absence of such an
analysis it is impossible to declare a consensus on the issue of upgrading
the SHOULD to a MUST. We can't use silence as a sign of assent on such a
serious change.

I move that we force the authors with threats of jeering and paying for
every IETF dinner from here to eternity to adopt Option 2 and free us from
the nonsense of the trailing slash.

			Yaron

P.S. The requirement that http://foo/blah/ and http://foo/blah point to the
same resource would ONLY apply to WebDAV compliant resources. So we are not
changing 2616. We are only saying "If you voluntarily choose to support
WebDAV THEN you must follow this rule." That way the only spec that needs to
change is 2518, NOT 2616. That having been said, I would LOVE to get 2616
changed to say this as well but I don't have enough free time on my hands to
push for this change to 2616.

P.P.S. Normally I would ante up under the rule of "put your money where your
mouth is" and do the analysis myself but I have to fly to Israel on the 19th
to make the last day of my Grand Father's Shiva. Unfortunately my schedule
is already completely filled and now I have to fly off to Israel at the last
second to attend to family duties. So I'm completely swamped until February.
So unless we want to hold up the spec until sometime in late February
someone else is going to have to perform the analysis. As it is I am sending
in my comments on the BIND spec during the weekend because I am so swamped.