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

From: Julian Reschke <[email-masked]>
Date: Sun, 04 Apr 2004 21:18:32 +0200

Jason Crawford wrote:

> We've addressed all issues brought up, right?  Count me as +1.

We did. Basically the issues raised here fell into three categories...:

1) Specific problems in the spec (those have been resolved in draft 05 
that we'd like to last-call).

2) General problems with the reference model introduced by the spec: the 
BIND spec specifies a very specific model; and this is the model it was 
supposed to specify. There are other possible models that behave slighty 
differently. One of them is the redirect reference model (separate 
spec), another is the "direct reference model" (that was mentioned in 
earlier versions of the REDIRECT spec, but as far as I can tell, nobody 
was interested to work on). There hasn't been any new discussion on this 
topic since Geoff's and my answers, so I'll assume it's resolved.

3) Issues with the organization and writing style of the spec. BIND 
adopts the same editorial style as RFC3253; and as there has been only 
one WG member finding problems with that, it seems that there's no 
change necessary. If more people feel differently about that, please 
speak up.

That being said, the draft really should be last-called -- it has been 
in this close-to-be-last-called state for quite some time now.

Regards, Julian

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 4 Apr 2004 21:38:12 +0200

> change necessary. If more people feel differently about that, please 

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

     Patrik

---

From: Julian Reschke <[email-masked]>
Date: Sun, 04 Apr 2004 22:11:59 +0200

> 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

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 5 Apr 2004 10:08:54 +0200

Am 04.04.2004 um 21:38 schrieb Patrik Fältström:
>> adopts the same editorial style as RFC3253; and as there has been 
>> only one WG member finding problems with that, it seems that there's 
>> no change necessary. If more people feel differently about that, 
>> please speak up.
>

The bind spec is in an excellent shape to make interoperability between 
two parties
more than likely. And if people want to shoot themselves into the foot, 
there's nothing
a spec can do to prevent that.

//Stefan

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 5 Apr 2004 07:25:30 -0400

In my view, yes, two parties which only read the text in the
spec (and the normative document it extends, i.e. RFC2518),
will be able to write code independent of each other that
interoperates.

Since only one expert group member has had concerns in that
regard, I think it is appropriate to last call the document,
to determine whether a significant number of other readers
share that concern.

Cheers,
Geoff