Re: BIND and live property value consistency

Lisa Dusseault wrote:
> 
> 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.

The issue with Apache/mod_dav is this: mod_dav does *not* compute entity 
tags (or lastmodified on it's own), it simply uses the ones already 
implemented in httpd (or whatever the name of the base component is). 
This core component is designed to function completely independantly of 
WebDAV, so it's simply impossible to change the ETag requirements here. 
Of course things look different if a server implements all of 
HTTP/WebDAV/BIND in the same place, but that approach simply isn't going 
to work in all use cases.

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

Actually, this is what you seem to suggest. You're asking for new 
requirements on the behaviour of DAV:get* properties, and these 
requirements affect all servers, not only those aware of bindings.

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

It depends on what the target audience of that spec is. Of course you 
can profile HTTP/WebDAV for some specific scenarios, but that also means 
that what you spec may not be implementable for many servers. This is 
something the BIND spec editors want to avoid.

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

OK, so that's a To-Do item for RFC2518bis.

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

Of course.

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

I'm not sure I follow. In the IETF, this (updates of a base document) 
happens all the time and nobody seems to suggest that RFCs absolutely 
need to be updated just because a base document has progressed to a new 
standards level.

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

Interesting. So why are we talking of RFC2616 all the time, when the 
spec that RFC2518 refers to is actually RFC2068???

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

(see separate email 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0144.html>).

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

So how is it supposed to do that without risking to disagree with 
RFC2518bis?

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

That sounds like you're trying to use BIND to enforce a specific server 
behaviour to everybody else. I disagree with that approach, although I 
may agree that it's good if a server behaves that way. To get there, 
it's IMHO better to (1) explain the issue and (2) potentially make it 
easier for clients to find out whether a server follows that model. Both 
would be action items for RFC2518bis.

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

I think it's inacceptable because it describes what may be desirable in 
some scenarios, but not reality.

Best regards, Julian

Received on Wednesday, 29 June 2005 15:39:36 UTC