Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings

Lisa Dusseault wrote:

> I don't think everybody else agrees that there is no problem.  I have  
> only heard a couple people directly address this issue.

Well, I can only make statements about people who *do* say something 
about the topic. Those who did seemed to agree that the spec shouldn't 
say anything specific about this issue.

> The last time we discussed this (this fall but also way earlier), we  
> did come to rough consensus that properties, even live properties, must  
> have the same value no matter which binding is used to request the  
> value of the property.  (I am not sure I agree with the conclusion, but  
> I agree there was rough consensus.)
> 
> Now I'm saying that it's not clear in the spec that this is required  
> and we should put it in the spec.  This is a different issue (what  
> should be in the spec) than the previous issue ( what should be  
> allowed) although clearly one follows from the other.   In the message  
> you point to, Geoff and Jason and yourself addressed the "what should  
> be allowed" issue.  Now let's discuss "what should be in the spec".

I'm happy to discuss the issue "what should be in the spec". However, 
BIND does *not* introduce the concept of bindings. What it introduces is 
a new method for explicitly creating them (BIND), some BIND-optimized 
equivalents for MOVE and DELETE (REBIND and UNBIND), live properties and 
status codes that help in living with multiple bindings. But the basic 
concept of multiple URIs being mapped to the same URI is already present 
in RFC2518, thus if there is anything that needs to be clarified 
regarding the behaviour of properties, this needs to go into RFC2518 (as 
Jim already mentioned, the containment model described in the BIND spec 
really should be part of the base spec, not BIND).

So should I open an issue against RFC2518bis regarding this topic?

Julian

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

Received on Monday, 6 December 2004 20:03:56 UTC