W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2005

Re: BIND and live property value consistency

From: Brian Korver <briank@briank.com>
Date: Tue, 05 Jul 2005 16:30:06 -0700
Message-ID: <42CB17FE.7020108@briank.com>
To: webdav <w3c-dist-auth@w3.org>

Geoffrey M Clemm wrote:
> 
> 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.

Add me to the "disagree" group.

Certainly there are cases were I agree with the authors of
the BIND spec, but there ar lots of cases when the
redefinition/refinement/clarification is only relevant in
the context of the new document or when it's not possible
to change the document that introduces the live property
(eg 2616) -- in these cases I believe the redefinition/
refinement/clarification should appear in a spec that does
not obsolete the original definition.

-brian
briank@briank.com



> 
> 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
>  >
>  >
Received on Tuesday, 5 July 2005 23:30:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:09 GMT