- From: Brian Korver <briank@briank.com>
- Date: Tue, 05 Jul 2005 16:30:06 -0700
- 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 UTC