Re: BIND and live property value consistency

Cullen Jennings wrote:
> On 6/27/05 8:22 PM, "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com> wrote:
> 
> 
>>In particular, the authors of the BIND specification believe
>>that the semantics of a live property should be defined by
>>the specification that introduces that live property,
>>and if those semantics of a given live property are to be
>>redefined/refined/clarified, that should be done in a
>>specification that obsoletes the one with the original definition.
> 
> 
> I have a few random possibilities that might help the WG sort some of this
> issue out. Don't take any of these as the chair saying you should do this.
> They are just some ideas that might lead to figuring out how to do this.
> 
> First, do everyone agree what to do about properties in future specs? I'm
> guessing we do but I'm not sure.

As far as I can tell, Lisa likes to see new constraints on the behaviour 
on some or all of the DAV:get* properties (which in turn are inherited 
from RFC2616's HTTP response headers).

Looking at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0142.html>:

"Where this document explains how MOVE and COPY should work with
getLastModified and ETags, I agree with the explanations.

Where the document explains that ETag behavior on multiple bindings
must remain unspecified, I disagree, as already noted.

Where the document says that header behavior is impossible to predict
because the headers are defined by HTTP, I agree that is the situation
in fact today, however I propose that we do better to help clients
here.  The bind spec can, and should, put more restrictions on servers
that support that spec in how they handle ETags and last-modified
timestamps."

I understand this is an acknowledgment that my analysis about the 
interaction between HTTP's response headers and WebDAV's namespace 
operations 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-properties-latest.html>) 
is indeed correct, but that she would like the BIND spec to introduce 
new constraints.

First of all, it's unclear to me what these new constraints would be, at 
least for the case of DAV:getlastmodified (please clarify).

Furthermore, I don't see *at all* why it would be the BIND spec that 
should introduce these constraints. It may be a good idea to define a 
specific WebDAV profile where clients can rely on some of these 
properties behaving in a more predictable way (including a method for 
clients to detect that), but that would be a *profile* that many 
RFC2518-compliant servers will not be able to implement.

> One thing I wanted to point out is that an RFC can "update" previous RFC
> without obsolescing it. It would be possible to have BIND or bis update all
> the previous documents to provide advice on how properties work in the
> context of links.

As a matter of fact, the current draft indeed says that it is updating 
RFC2518 (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#ED_updates> 
for history of decision).

The question is: if we want to state something which is missing from 
RFC2518 (like a discussion about the behaviour DAV:get* properties under 
namespace operations), does it belong into BIND or into RFC2518bis? What 
would be the benefit of putting it into BIND, when many implementors may 
not even read it there?

> In the glacial time scale that these documents are taking, it seems like bis
> and bind will come out at approximately the same time. Would this all be
> easier if BIND depended on bis?

In the end, it won't matter a lot if we really finish RFC2518bis as 
proposed. However, I'm not sure of any objective benefit of that 
compared of letting BIND refer to RFC2518, and having RFC2518bis 
obsolete RFC2518 later.

> The terms "changing the semantics" sounds good but I get a little lost on
> what is meant at times. Imagine we have some features of RFC 1000 called A,
> then later we defined an extension called RFC 1500 that added a new function
> called X. If 1500 added some additional semantics to feature A to define how
> it works with function X, that seems all find and dandy. If 1500 redefines
> how A works in a way that is not backwards compatible with a client and
> server that was written after 1000 but before 1500, this seem like it will
> introduce huge interop problems and needs to be considered very carefully.

Right.

> I'm get lost if we are doing the equivalent of changing how 1000 works or if
> we are providing additional information about what you need to do if you do
> both 1000 and 1500.

When we're doing something like fixing the definition of DELETE 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#delete.and.bindings>, 
  this is indeed a fix (RFC2518 said something about DELETE on resources 
with multiple URIs that the WG decided is simply incorrect; also 
resulting in a change in RFC2518bis).

On the other hand, we have been very careful in *not* breaking existing 
semantics for BIND. For instance, instead of changing RFC2518's 
definition of MOVE, we have defined a new method REBIND instead. This 
will allow servers to keep implementing RFC2518's definition of MOVE 
(non-atomic, best effort), while also providing a new method with 
stronger sematics (that however may fail where MOVE succeeded for the 
same parameters).

The proposal to constrain the behaviour of the RFC2616-inherited 
properties IMHO will either cause servers not to be implement BIND at 
all, or not to implement that constraint (thus to be non-compliant). 
Thus, tying both things (authoring/discovery of multiple bindings vs 
live property behaviour) seems to me like a very bad idea.

If anybody wants to make things easier for some clients, the right 
approach seems to define a profile of WebDAV/BIND, and provide a method 
for clients to detect support for that. But this does not belong into BIND.

> There was a thread were we were trying to figure out how to get each
> property to behave. This seems like a really good approach, if we can figure
> out how we want them to work, then we can figure out if that is an update to
> where they are defined, then we can figure out what document to put the text
> it. 

As far as I can tell, there's clearly no consensus for adding new 
constraints. That seems to leave us with the following options:

1) Do not say anything at all; and let RFC2518bis provide additional 
clarification. This makes a lot of sense, because the whole discussion 
is really independant of BIND, because it's a result of namespace 
operations in general.

2) State what really shouldn't need to be stated: live properties behave 
  exactly in the manner defined by their base specs, potentially 
including a table.

My personal preference would be in favor of simplicity (thus 1), but I'm 
open for the other options, if this is what the WG wants.

> enough rambling, upon more drinking a bunch more coffee, I may realize this
> email has nothing of any use :-)

Oh yes, it had.

Best regards, Julian

Received on Sunday, 3 July 2005 15:01:53 UTC