- 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
>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 UTC