Re: BIND and live property value consistency

Hello,

As a mere implementor, I have never posted on this list before, but now 
I am getting a little worried. I have been working on a specific backend 
for the SAP Netweaver WebDav server that does not (and never will) 
implement BIND. But it does implement large parts of RFC 3253. In 
particular it supports the Version-Controlled-Collection feature, which 
forces the existence of multiple bindings of the same resource in some 
cases.
Our implementation neither implements BIND nor a spec depending on BIND. 
So I really do not want BIND to put any constraints on our implementation.
The existence of multiple bindings has nothing to do with the existence 
of the BIND method. The BIND spec is the wrong place to describe the 
behavior of properties that are defined by other specifications under 
methods that are defined by other specifications.

Regards,
Manfred

Lisa Dusseault wrote:
> 
> 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.
> 
> 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.
> 
> 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.
>  - 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.
>  - 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.
>  - 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.
>  - 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.
> 
> 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.
>  - If the spec explicitly allows variation, that would be pretty weird. 
>  I'm not sure what we would say to justify that.
>  - If the spec remained silent, well, probably no harm, that would only 
> be weird if the spec were explicit about other property behaviors.
> 
> 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.
> 
> 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.
> 
> DAV:displayname
> 
> RFC2518 underspecifies this property and we know the problems that has 
> caused. Nevertheless BIND could say something here.
>  - 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.
>  - 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.
>  - 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.
> 
> 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 
> 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.
> 
> Lisa
> 
>