Re: Issues remaining with Bind draft

Lisa Dusseault wrote:

> I suggest adding the following text to the Bind draft:

Lisa, I appreciate the effort to provide additional wording. However, in 
each of the cases I think it's either unnecessary (because the behaviour 
follows from the very nature of bindings), or actually incorrect.

In particular:

> "Methods that create a new resource (MKCOL, MKWORKSPACE, MKACTIVITY,  
> PUT when the destination is unbound) each create only one binding and  
> one resource.  Methods that create a new binding (BIND) leave other  

*Usually* that's true. However, servers can do what they want. There's 
nothing preventing a server to create *two* resources and bindings upon 
each PUT (for instance, that may be the case for a server that has 
"source" and "transformed" content in different namespaces).

> bindings unaffected.

 From 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_BIND>:

"The BIND method modifies the collection identified by the Request-URI, 
by adding a new binding from the segment specified in the BIND body to 
the resource identified in the BIND body."

This is the purpose of the BIND method, and I really don't want to get 
into the business of enumerating what a method *doesn't* do.

> "The following methods MUST have an identical result on every binding  
> to a resource, regardless of which binding is addressed:
>  - GET, PUT (to an existing binding), OPTIONS, HEAD.
>  - PROPPATCH, LOCK, UNLOCK
>  - all the methods defined in RFC3253 (except the ones that create a  
> new resource)
>  - ORDERPATCH
>  - ACL

Which of course provokes the question if there are any methods that do 
*not* have that property. Which of RFC3253's methods do you think have 
that property? And why do you feel that for instance BIND and REBIND 
don't have that property?

The only difference I'm aware of is that sometimes some bindings are 
protected by a lock, while other's aren't. In those cases only namespace 
operations that will affect these URIs behave differently.

> "The following methods have a result that only affects the binding that  
> is addressed, and don't affect other bindings to the same resource:  
> REBIND, UNBIND.  MOVE, COPY and DELETE have special behavior described  
> in detail in sections 2.3 to 2.5.

That doesn't offer any additional information, right? It's just a 
forward pointer to information that follows later.

> "The REPORT and PROPFIND methods could conceivably provide different  
> information depending on which binding to a resource is addressed but  
> by default they return the same information regardless of binding.  The

Let's see...

<http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_PROPFIND>:

"The PROPFIND method retrieves properties defined on the resource 
identified by the Request-URI...."

<http://greenbytes.de/tech/webdav/rfc3253.html#METHOD_REPORT>:

"A REPORT request is an extensible mechanism for obtaining information 
about a resource."

So no, they should provide identical information.  We're getting 
information from resources, and as long as the resource is the same, the 
information is the same. The access path doesn't matter.

> definition of each property or report ought to make clear if this  
> property or report diverges from the default.  All reports defined in  
> RFC3253 and the ACL RFC return the same result for any binding to the  
> same resource.  All (live) properties defined in RFC2518, RFC3253,  
> RFC3648 and the ACL RFC MUST have the same value appearing on all  
> bindings to the same resource. All dead properties MUST appear the same  
> on all bindings to the same resource. An implementation MAY define  
> custom live properties which have different values on different  
> bindings to the same resource."

I strongly disagree -- a live property that varies based on the request 
URI IMHO is a violation of the binding semantics defined in this spec.

> This text is intended to supplement the model description by making  
> requirements on implementations to encourage them to behave  
> consistently, and to clear up confusion in applying the model in  
> specific cases.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 24 March 2004 17:04:43 UTC