W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

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

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 6 Dec 2004 12:19:24 -0800
Message-Id: <1EFA6E09-47C4-11D9-A94C-000A95B2BB72@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: Julian Reschke <julian.reschke@gmx.de>

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

Only if RFC2518bis is going to include the whole bindings 
specification, or at least the resource-id property.  The reason why 
RFC2518 never needed to answer this question definitively is because  
clients had no way of knowing when two URLs point to the same resource. 
  If clients can't identify bindings, then there's no way to violate the 
client's expectations around property values of two bindings to the 
same resource.

With the bindings specification, the client can detect multiple 
bindings with 'resource-id', or for that matter the client may have 
used BIND.  So now that we have a spec describing how to identify and 
manipulate bindings, that spec needs to be clear on what the client 
must expect and/or what the server must do to meet expectations.

Received on Monday, 6 December 2004 20:19:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC