RE: A proposal for Advanced Collection binding semantics

> The state of an advanced collection includes a set of "bindings".  A
> binding is an association of a name (a string) with a resource.  A
> legal binding name must satisfy the constraints for a URL path segment,
> as defined by section 3.3 of RFC 2396.  (Note: if the definition of
> "internal member name" is fixed in RFC 2518, we can just use that as
> the binding name).

We might want to strengthen the definition of "internal member" that is in
RFC 2518.

Your definition needs to be extended to allow for internal member names to
end in a "/", and to be consistent with RFC 2518, they should start with
"./".

> - The BIND method
>
> The new BIND method is provided to allow direct manipulation of
> bindings.  In particular, BIND can be used to create a new binding to
> an existing resource,

I agree with this.

> or to modify an existing binding (by associating
> it with a different resource).

But I don't like this, since it's essentially an atomic UNBIND/BIND pair.
My concern is whether such an operation is really needed, and whether this
means that access control for BIND can be disentangled from access control
for UNBIND.  It seems like a bad separation of concerns.

> But the inverse does not hold, namely, the fact that the server maps
> two URL's to the same resource doesn *not* imply that this resource
> must be an internal member of an advanced collection, *nor* does it
> imply that there must be two bindings to that resource.  For example,
> if the server maps http://host/todays-weather.html to the same
> resource as http://host/5-1-1999-weather.html, this does not imply
> that http://host is an advanced collection, nor that there are two
> bindings to this resource.

I'd add:

However, if http://host/ is an advanced collection, then it MUST have
bindings to todays-weather.html and 5-1-1999-weather.html.


That is, the existence of multiple mappings doesn't imply the collection is
advanced, but if it is advanced, every mapping must have a corresponding
binding.


> - DELETE of an Advanced Collection Internal Member
>
> To "delete" a resource, R1, that is an internal member of an advanced
> collection, R2, means to remove the binding with R1 from the set of
> bindings in R2.
>
> Since there can be multiple bindings to a resource in the same or in
> different advanced collections, the binding to be removed is
> determined from the URL to which the DELETE request is applied.  In
> particular, in the request "DELETE /xxx/yyy", then the binding that is
> removed is the binding named "yyy" in the advanced collection to which
> the server maps the URL "/xxx/".
>
> For example, suppose http://host/public/ maps to a collection resource
> R1, and R1 contains a binding of "index.html" with resource R2, then
> the request:
>
>   DELETE http://host/public/test.html HTTP/1.1
>
> removes from R1 the binding of "test.html" with R2.
>
> Note: This definition of delete is compatible with RFC-2068, but is
> not compatible with wording in RFC-2518.  I support Jim Whitehead's
> proposal that the wording in RFC-2518 be modified in order to allow
> this definition of delete.

Right -- we'll make this change going from Proposed to Draft.

- Jim

Received on Saturday, 1 May 1999 20:15:05 UTC