Re: BIND and live property value consistency

We have gone over these exact arguments many times.
It is true that we disagree, but that disagreement is over
a single simple point.

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.

A key question is whether disagreement on such a point
from a single workgroup participant can veto a specification.

Cheers,
Geoff

p.s. A few additional comments interspersed below.

Lisa wrote on 06/27/2005 06:02:28 PM:
> We disagree on some pretty fundamental issues here, it seems...
> 
> On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote:
> > Let me make some base statements before I dig into the details:
> >
> > 1) If the spec can't be implemented within Apache/moddav on a Unix 
> > filesystem (using hard links), there's something wrong with the spec.
> 
> I am not sure about this.  ACL couldn't be implemented on a Unix 
> filesystem using Unix permissions and in the end we had to live with 
> that.  For that matter, you can't implement WebDAV properties on a Unix 
> fs without creating extra data store constructs of some kind.  So I 
> wouldn't agree with a statement this broad although I would agree with 
> a statement to the effect that it's a "nice to have" if bindings can be 
> implemented using Unix fs hard links.

A more important point here is that the Unix file system is a common
example of an existing WebDAV implementation that exposes multiple 
bindings,
just as is defined and allowed by RFC 2616 (and therefore inherited by
RFC 2518). So any constraints you try to place on the semantics of 
multiple bindings
are new constraints being placed on existing properties and methods. 

> > In general, introducing new requirements not present in either RFC2616 
 
> > or RFC2518 is a bad idea.
> 
> I don't agree with this -- a new spec is all about adding new 
> requirements.   Are you talking instead about new requirements that 
> would affect an implementor who wasn't implementing bindings?  That I 
> do agree with, but I'm not suggesting that kind of thing, naturally 
> that is ineffectual.

You appear to be suggesting exactly that kind of thing.  As indicated 
above,
multiple bindings are defined in RFC-2616, and exist in common 
implementations
(such as Unix file-system based implementations).

> The argument (seen elsewhere, e.g. in the property behavior proposal) 
> that any feature that is defined in HTTP can't be defined more 
> carefully in a draft that extends HTTP is one I have to reject for all 
> the interoperability problems that must cause if taken as a general 
> argument.  We can't expect authors of specs to be omniscient -- they 
> can only deal with issues they are made aware of -- and we must be able 
> to help implementors out by making things clear when we have the 
> chance.

And we do so by doing defining a particular property more carefully in
a "bis" specification that replaces the one that previously defined
that property, so that the implementor of that property does not have
to be omniscient and guess all the specifications that they need
to read in order to understand the behavior of that property.

> > 2) The behaviour of live properties for multiple URIs follows the same 
 
> > patterns as for plain HTTP/WebDAV when namespace operations such as 
> > MOVE are involved (see discussion in 
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/ 
> > 0001.html>).
> 
> That may be, but I don't see that sufficiently spelled out for 
> implementors to end up with something consistent.  Nor do I think we've 
> examined all the ramifications of that kind of broad statement.

The specification is not an implementation guide, exactly to allow for
a variety of implementations.  So it is not always the case that "more
guidance is better", if that guidance invalidates reasonable alternative
implementations.  So this will always be a value-judgement that is 
unlikely
to ever get unanimous agreement.
 
> > 3) I disagree that it is a problem when RFC2518bis (containing 
> > clarifications on live property behaviour) comes out after BIND; once 
> > it's officially updating RFC2518, this is what readers of the BIND 
> > spec should read (just like RFC3986 is now the current URI spec, and 
> > both RFC2518 and RFC2616 still point to older revisions).
> 
> So Bind will reference RFC2518?  If so, then implementors *can't* 
> automatically update the reference to what replaces RFC2518 unless that 
> makes no interoperability differences.  To do so would be to be 
> non-compliant with Bind and what it references.

What?  There is a clearly defined IETF process for defining a replacement
specification (that's what the "obsoletes" keyword is for).
So "automatically updating the reference to what replaces
RFC2518" is exactly what is expected from all implementors, just as they
were expected to implement RFC2616 instead of RFC2068.

> That also means that implementors of RFC2518 and RFC2616 can't cause 
> backward-compatibility problems with clients by implementing RFC3986 
> and still claim compliance with RFC2518/2616.

That is exactly what they can (and are expected) to do.  Of course, the
authors of RFC3986 worked hard to minimize those backward compatibility
issues with RFC2396 (just as the authors of RFC2518bis
are expected to minimize the backward compatibility issues with RFC2518).

The rest of the message below should appear in an RFC2518bis thread,
so I'll wait to respond to it until it appears there.

> >>  - If the spec says that the value MUST be the same on all bindings, 
> >> then this makes for the easiest and most efficient client 
> >> synchronization operations.  OTOH a few server implementations must 
> >> change a little bit to correctly implement BIND.  I think this is 
> >> fine -- a minor server burden for increased efficiency and 
> >> simplicity.
> >
> > As I have pointed out multiple times (see link above), this does not 
> > work. Servers must have the freedom to adjust ETags because of 
> > namespace operations, so they also need to be able to do that for 
> > BIND. Could you *please* follow up on the analysis in 
> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs- 
> > properties-latest.html>? Thanks.
> 
> 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.
> 
> >
> >> DAV:creationdate
> >> RFC2518 defined this property and didn't tie it to any locking or GET 
 
> >> request behavior, and it isn't used for synchronization or cache 
> >> refreshes.  Thus we have little to guide us on behavior but OTOH 
> >> probably not a lot of problems caused if we go either way.
> >>  - If the spec states that the value MUST be the same on all bindings 
 
> >> and that it MUST be the date the resource was first created (e.g. 
> >> with PUT), then this is the best case for people viewing creationdate 
 
> >> (as some clients already display it).  It makes most sense to the 
> >> person that creation date be the date of first uploading the content.
> >>  - If the spec states that the value MUST be the same on all bindings 
 
> >> and that it MUST be the date the last binding was created that could 
> >> be a little weird.
> >>  - If the spec explicitly allows different bindings to have different 
 
> >> creationdate values then this implies that the creationdate is the 
> >> date of creation of the binding.  That's not unreasonable. 
> >> Presumably a client could find the oldest binding and use its 
> >> creationdate as the resource creationdate.
> >>  - If the spec is silent then we really don't know if creation date 
> >> refers to creation of the resource or of the binding.  A person using 
 
> >> a client that simply displays the value might notice the different 
> >> behaviours on different servers.  A document retention or document 
> >> archival program might produce quite different results depending on 
> >> how this was implemented.  A cautious and perceptive client or agent 
> >> implementor would have to assume that they might vary and would have 
> >> to check all bindings.  OTOH there are already clients and archival 
> >> programs which aren't aware of bindings and these would have to be 
> >> upgraded to check the creationdate on different bindings in order to 
> >> regain predictable behavior.
> >
> > I disagree. DAV:resourcetype is defined by RFC2518 to be a property of 
 
> > the resource; and the whole point of the BIND spec is to define 
> > behaviours for multiple URIs mapped to the same resource. So it seems 
> > to be straighforward that the DAV:creationdate will be the same for 
> > all URLs (just like DAV:lockdiscovery).
> 
> I agree that DAV:creationdate should be the same for all URLs to the 
> same resource.  I think that's the best option and I'd like that added 
> to the spec.
> 
> >>  - If the spec says that displayname MUST be consistent across 
> >> bindings, then some implementations would have to change the way they 
 
> >> calculate displayname in order to implement BIND.  I would argue that 
 
> >> would be a good thing and would help alleviate the uncertainty in 
> >> RFC2518.
> >
> > I agree that it would be good if servers would behave that way, and 
> > thus we should clarify that in RFC2518bis.
> 
> The Bindings spec also can, and should, say something about this, 
> particularly if it references RFC2518.
> 
> >> DAV:source
> >> This property isn't widely implemented so it's hard to make any 
> >> statements about implementations or about implications of consistency 
 
> >> across bindings.
> >> General case
> >> It would be best if BIND could say something about the general case 
> >> of live properties even if it leaves some leeway for future live 
> >> properties to be defined as exceptions to the general case. Based on 
> >> looking at the live properties defined in RFC2518, we could define 
> >> those as being the same values across all bindings.  The consequences 
 
> >> of this would be more
> >
> > I guess you mean those except the DAV:get* properties defined by 
> > RFC2616?
> 
> No, I think we could include those as well and it would improve 
> interoperability and make implementations more consistent.   I bet that 
> if servers implementing Binding were required to do these properties a 
> certain way, then even other servers that don't implement Binding would 
> find the guidance and example helpful and can decide whether to update 
> their implementations accordingly even if they're not required to.
> 
> >
> >> consistent and clear server behavior and easier client 
> >> implementations, at the cost of some server implementations having to 
 
> >> change a few things in order to become compliant with BIND.  It's 
> >> conceivable that such a clear requirement would rule out some 
> >> imaginative and odd ways of implementing new  or custom functionality 
 
> >> based on bindings and existing live properties, which might not be a 
> >> bad thing.  A clear requirement for existing live properties to have 
> >> the same values on all bindings could still allow for exceptions for 
> >> new live properties defined differently, and thus not close off 
> >> future innovation.
> >
> > How about suggesting a concrete wording? First thing we should do then 
 
> > is to test it against what RFC3253, RFC3648 and RFC3744 already 
> > define.
> 
> I am not sure about RFC3253.  It's got a bunch of very complex stuff 
> and I am not sure how all its properties should behave.  However, for 
> the others , I suggest wording along these lines:
> 
> "The live properties defined in RFC2518, RFC3648 and RFC3744 are all 
> resource properties, and therefore those values MUST NOT vary due to 
> the binding used to access the resource."
> 
> Lisa
> 
>