W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2005

BIND and live property value consistency

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Sun, 19 Jun 2005 13:04:26 -0700
Message-Id: <bef0c930ba496386b1f0a453d8a9bcb9@osafoundation.org>
To: webdav WG <w3c-dist-auth@w3.org>

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
Received on Monday, 20 June 2005 17:03:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:08 GMT