Re: BIND and live property value consistency

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. In 
general, introducing new requirements not present in either RFC2616 or 
RFC2518 is a bad idea.

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

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

> As Julian recently noted, the behavior of live properties on bindings 
> (or on resources with multiple bindings) has been raised.  I still don't 
> consider the issue closed and since we're reraising these issues, I 
> wanted to methodically consider some of the implications of requiring 
> consistency, of explicitly allowing variation, or of the spec remaining 
> silent.
> 
> Important note:  Some of the confusion around these properties is 
> increased by lack of explicitness in RFC2518 (source, displayname in 
> particular).  If BIND depends on RFC2518 instead of 2518bis, that may 
> have different implications for our decisions about the consistency of 
> property values across bindings.   As we've discussed before, there's a 
> certain amount of clarification that should be added to 2518bis about 
> whether properties apply to underlying resources, but if BIND is issued 
> as an RFC depending on 2518, before 2518bis is issued, then BIND 
> implementors won't be able to benefit from clarifications in 2518bis.

---> 3).

> DAV:getcontentlanguage
> DAV:getcontentlength
> DAV:getcontenttype
> 
> RFC2518 defines these as the values returned in a GET response in the 
> Content-Language, Content-Length and Content-Type headers, so the value 
> of this property can vary on bindings only if the GET response also 
> varies on bindings.  Yet, the BIND spec doesn't require that the GET 
> response be the same regardless of binding URL used.  A server could 
> conceivably see bindings as a creative way of handling variant access or 
> access to source/output versions of a dynamic resource, because bindings 
> would allow a bindings-aware client to discover the other URLs and 
> possibly to modify variants or source.  I wouldn't say I recommend this 
> approach but it's not forbidden.
>  - We don't have evidence so far that any implementations do anything 
> other than keep these values consistent across bindings.
>  - If the spec says that the values MUST be the same on all bindings, 
> then servers can't implement odd features like using one binding to get 
> to the German version of a resource, and the other binding to get the 
> French version.    That seems fine to me, there are other, probably 
> better ways of handling access to variants and source/output than using 
> bindings.
>  - If the spec explicitly allows variation, then clients must download 
> the property separately for each binding if they care about it, and we 
> might want to say something about why they could vary.
>  - If the spec remains silent, we're unlikely to see odd implementations 
> of this but it's conceivable.  A cautious and perceptive client 
> implementor would behave as if it could differ and download the property 
> an extra time for every binding

Agreed, except I'm not sure what you call "odd". If RFC2616 allows this 
behaviour, and RFC2616 ultimately defines the semantics of these 
properties, it's not up to us to decide what's "odd"...

> DAV:getetag
> 
> Although RFC2518 says that this is tied to the ETag header value in a 
> GET response, this is a little different than the last three, because 
> it's perfectly conceivable for two URLs to have the same GET response 
> (byte for byte) and yet have different ETag values.

I don't agree here that it's different. DAV:etag is whatever the server 
returns upon GET as "ETag" response header. Same behaviour as for the 
above three.

>  - We have evidence that server implementations use the URL to calculate 
> the ETag, so presumably it would be easiest for those to continue that 
> behavior.  OTOH some server implementations only base the ETag on 
> resource characteristics, not on bindings.

Yes. Some really have unique ideas for each content body that's there, 
others compute it dynamically based on timestamps and such.

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

>  - If the spec explicitly allows variation, then clients must behave as 
> if it does vary in order to interoperate against different servers. In 
> some situations the client will have to query the ETag on several 
> bindings to the same resource to verify whether it needs to 
> resynchronize the resource, resulting in more roundtrips.  Of course the 
> client is likely to behave the same way with all servers supporting 
> bindings even if the ETag doesn't vary according to URL.

Yes.

>  - If the spec is silent, then a cautious and perceptive client 
> implementor would behave as if the property could differ and do the 
> extra work -- again, possibly unnecessary.

Yes.


> DAV:supportedlock
> DAV:lockdiscovery
> 
> Since the BIND spec clearly states that locks are on resources, not on 
> URLs, it's a pretty obvious assumption that the values of the 
> lock-related properties must also be related to resources and not vary 
> depending on URL.
>  - If the spec states that the value MUST be the same on all bindings, I 
> see no harm.

Agreed.

>  - If the spec explicitly allows variation, that would be pretty weird. 
>  I'm not sure what we would say to justify that.

I think that would be a bug.

>  - If the spec remained silent, well, probably no harm, that would only 
> be weird if the spec were explicit about other property behaviors.

Yes.


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

> DAV:getlastmodified
> 
> Again, RFC2518 defines this as the value of the Last-Modified header on 
> the GET request, but the server has a lot of leeway to set this to the 
> last time the underlying resource was changed, or to update this when a 
> new binding is created -- perhaps only the newest binding would have a 
> different value because it was created after the underlying resource was 
> last changed.
>  - The implementations I know of would probably treat this as the time 
> the underlying resource body was last modified.
>  - If the spec states that this value MUST be the same on all bindings, 
> and that it MUST reflect only changes to the body of the underlying 
> resource, that would be the most clear and useful statement for clients 
> -- clients could simply display this and users would easily be able to 
> confirm that if this value changed then somebody had changed the body of 
> the resource.  Servers would have to implement this in the same way when 
> they add BIND support and I'm not aware of any problems that would 
> cause.  Clients might sometimes see a new URL appear in a collection on 
> date D2, when the last-modified time is a timestamp D1 from much earlier 
> (before the client last synchronized, for example), but that seems 
> unlikely to cause bugs.
>  - If the spec explicitly allows this to vary then the spec probably has 
> to say something about what that means.
>  - If the spec remains silent, then a cautious and perceptive client 
> implementor would have to assume that it could mean anything.  I'm not 
> sure if it would be best to download all the different bindings' 
> getlastmodified times to see if they're different.  If they are 
> different, what would the client do?  Display the earliest one?  The 
> latest one?  Which value would be most helpful to the user?  Again, 
> existing document archive and retention programs would probably show 
> different behavior if servers end up calculating this property in 
> different ways.

But the DAV:getlastmodified falls into the same category as all the 
other DAV:get* properties. They are defined as per RFC2616, and as I 
have shown multiple times, you cannot rely on them to be stable across 
namespace operations (be it MOVE or BIND). So we really cannot say 
anything above what RFC2616 already says.


> DAV:displayname
> 
> RFC2518 underspecifies this property and we know the problems that has 
> caused. Nevertheless BIND could say something here.

How? If it's underspecified in RFC2518 (with which I agree), it needs to 
be clarified in RFC2518bis...

>  - We do have implementation evidence that some implementations 
> calculate display name from the URL, thus it could conceivably vary 
> according to binding.  We also know some implementations store display 
> name as if it were a dead property, thus it would not vary according to 
> binding.

Yes.

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

>  - If the spec explicitly allows this to vary, that implicitly supports 
> the calculated displayname model.  Probably, however, servers which keep 
> the value consistent would continue to do so.
>  - If the spec is silent, then a cautious and perceptive client 
> implementor would have to assume that displayname could vary and 
> download it again for every binding if the client needs this property.

Depends on what RFC2518 and our bis issues list say; and whether 
there'll be servers that actually do implement multiple bindings while 
having the per-URL displayname functionality. I'm not aware of any.


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

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

Best regards, Julian

Received on Tuesday, 21 June 2005 17:13:58 UTC