Re: BIND and live property value consistency

We disagree on some pretty fundamental issues here, it seems...

On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote:

>
> Lisa,
>
> thanks for the feedback.
>
> 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.

> 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.

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.

>
> 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.

>
> 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.

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.

>
>>  - 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 Monday, 27 June 2005 22:02:41 UTC