Re: Please submit last call on draft-ietf-webdav-bind-05.txt

Patrik Fältström wrote:

> Let me phrase this differently:
> 
> Will two parties which only read the text in the spec be able to write 
> code independent of each other which interoperate?
> 
> Is your view the answer to that question is 'Yes'?

I think the answer is "yes", if the reader indeed boths reads and 
understands the normative references as well.

Note that being more verbose has drawbacks, such as (1) reduced 
maintainability (if the same thing is described in different places) and 
(2) simply the size of the spec (I do remember the complaints about the 
length of the ACL spec; and BIND really really should be a simple spec).

Also note that "interoperate" doesn't mean the same thing to everybody. 
In a perfect world, every implementation will behave exactly the same 
(generally only the case for systems that have a single-source 
implementation such as Perl).

The BIND spec however simply can't invent new rules that are 
incompatible with it's base specs (HTTP, WebDAV...). So if things are 
already implementation-dependent for plain HTTP/WebDAV servers, things 
won't be different with BIND. That doesn't mean that software isn't 
interoperable; it just means that the spec in some cases simply has to 
allow different behaviours.

Remember that BIND doesn't introduce a new concept or model, the concepz 
of multiple URIs mapped to the same resource is already present in HTTP, 
WebDAV and DeltaV (RFC3233); all the spec adds is...:

- discoverability (is this the same resource as...? what bindings does 
this resource have...)

- explitic authorability (make a new binding exactly here...)

- specific new namespace operations where the HTTP/WebDAV-inherited 
methods (DELETE, MOVE) not always do the "right" thing for a BIND-aware 
system; and where the BIND spec couldn't change existing definitions 
(such as is a server allowed to do a "best-effort" MOVE?).

So there are scenarios where server implementations *will* vary, but 
this is because HTTP and WebDAV servers *do* vary, not because the 
authors couldn't do better.

For example: we've been asked to normatively specify the behaviour of 
HTTP ETags when bindings change. We simply can't, as there's an inherent 
conflict between the use case ETags were designed for (disambiguating 
represensations for the same URI), and the later addition of namespace 
operations in WebDAV. A server that doesn't have globally or at least 
server-wide unique ETags simply will have to do a fixup of ETags after 
namespace operations to prevent ETag collisions. There's nothing the 
BIND spec can do about that (however, the base spec RFC2518bis *should* 
recommend practices for selecting ETags that avoid this kind of 
post-namespace-op fixup).

Regards, Julian


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

Received on Sunday, 4 April 2004 16:13:08 UTC