W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: WebDAV Bindings - Issue Yaron.MrIntegrity

From: <fielding@ebuilt.com>
Date: Fri, 21 Jan 2000 11:33:37 -0800
To: Jim Whitehead <ejw@ics.uci.edu>
Cc: w3c-dist-auth@w3.org
Message-ID: <OFB1446DC5.E5FA7DA3-ON8825686D.0065D702@ebuilt.net>
>Another way of stating the rationale for the integrity requirement is 
this:
>we wanted to create a requirement that would prevent bindings that 
"dangle".
>It must not be possible for a client to interact with a binding that 
doesn't
>have a destination resource.

There are two points you seem to be missing.  First, the origin
server doesn't know the resource.  The server knows what the URI is and
how to map that URI to a program and/or storage object(s), but the
resource is not the storage object.  There are resources that map to no
storage object.  In fact, there are resources that exist even before
their origin server has been realized in hardware and connected to the
Internet.  There are also storage objects that make up only a small
component of many other resources.  Bindings are not about storage 
objects.
They are about names within a namespace.  If you can create a binding
to another resource, then you can create a binding to no storage object,
which means any requirement that bindings be mappable to storage objects
is completely bogus.

The second point is that I, as an experienced Web developer, have
no interest in the strong integrity requirement.  It is, in fact,
contrary to the already implemented forms of bindings that can be
found in every general-purpose Web server post-1993.  It isn't
necessary for the abstract notion of adding an internal redirect
to a resource within the namespace of a collection, which is what
BIND is supposed to solve.  It is harder to implement than late
binding (in fact, the way it is worded in the spec is simply
impossible to implement, but that can be fixed by talking about
what the server knows and not about resources).  It isn't necessary
for interoperability.   It doesn't change the fact of life that some
bindings will be left dangling even with the requirement in the
protocol, since a normal resource can dangle, which means the protocol
still needs to express those semantics to the client (even if that
means the response is just 404, though I'm sure we can do better).

It is not a desirable feature in the majority of Web implementations,
since Web authors are familiar with the concept of setting up links
to a resource *before* the resource exists and don't want all their
links to disappear and need to be re-bound just because one URI
(which is the only way to identify a resource) goes away.  There is
no conceptual difference between a binding within a collection and
an <img src="binding"> within HTML.

It is okay if the server *wants* to implement strong integrity.
It is okay for some resources to have strong integrity by their
very nature.  All of the HTTP methods that make changes to the origin
are defined such that side-effects on other resources are expected.
It is therefore unnecessary to require it of all resources, even
with the presence of versioning and document management systems on
the backend.

Optional features are meant to be options, not protocol requirements.

...........................................................
Roy T. Fielding                         fielding@ebuilt.com
eBuilt, Inc.                            tel:+1.949.609.0000
2652 McGaw Ave.                         fax:+1.949.609.0001
Irvine, CA 92614-5840   USA           http://www.eBuilt.com
...........................................................
Received on Friday, 21 January 2000 14:35:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:53 GMT