Re: ETags?

Thanks for continuing with this, but I think there's still a slight 
misunderstanding somewhere.

Of course you are correct that any implementation that allows 
functionality like bindings under the cover can have multiple URLs to 
the same resource, and the BIND spec doesn't introduce that.  I 
understand that, and I can see how that would leave the situation 
materially unchanged (although I can't see how clarification would be 
harmful).

What the BIND spec does is it adds the ability for a client to detect 
unambiguously that two different URLs are bindings to the same 
resource.  BIND introduces the possibility that a client may behave 
differently with respect to two URLs when it knows that they map to the 
same resource.

So by implementing RFC2616 alone, a client clearly has no option other 
than to cache one ETag per URL (and per variant, version, etc).  Now by 
implementing BIND, a client might believe that it can deal more 
directly with the resource because we've now provided the client a way 
to identify the resource.

---

Apparently I need to address the issue of why some client might believe 
they can cache 1 ETag per resource.  Looking at RFC2518:
"However the If header is intended for use with any URI which 
represents state information, referred to as a state token, about a 
resource as well as ETags.".
   -- This implies that ETag is about a resource.

" Every state token or ETag is either current, and hence describes the 
state of a resource, or is not current, and does not describe the state 
of a resource. The boolean operation of matching a state token or ETag 
to the current state of a resource thus resolves to a true or false 
value."
  -- This declares that an ETag describes the state of a resource.

"The getetag property MUST be defined on any DAV compliant resource 
that returns the Etag header."
  -- As with much other text about properties in RFC2518, this clearly 
defines that the property relates to the resource.

Looking at RFC2616: "Entity tags are used for comparing two or more 
entities from the same requested resource."
  and "The entity tag MAY be used for comparison with other entities 
from the same resource."
  -- and with BIND, the client can now compare with entities from 
another binding to the same resource.

Conclusion: At least one reader finds from reading specification text 
that it implies that ETags are consistent for a resource across 
bindings.  While I would slightly prefer BIND to make my conclusion 
clear to readers (would make synchronization easier), I would find it 
acceptable if BIND made Roy's answer clear in the spec.  We just need 
to come down on it on one side or another, and put that in the spec.

Lisa

On Jan 27, 2005, at 7:27 PM, Roy T. Fielding wrote:

> On Jan 27, 2005, at 6:31 PM, Lisa Dusseault wrote:
>> Yes, but as I explained in this email --
>> http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html
>>
>> -- the bindings draft introduces the possibility for client behavior 
>> which could be harmful to interoperability unless the way that ETags 
>> interact with bindings is defined.
>
> And has been explained in multiple responses, bindings does not
> introduce such behavior -- it is present in any implementation
> that allows such things as Alias configurations -- and there
> is absolutely nothing that bindings can say about it that isn't
> already in the definition of etag in RFC 2616.
>
>> Since bindings first introduces this possibility, that's our best 
>> choice for a document in which to resolve that potential 
>> interoperability problem.
>
> There is no interoperability problem.  You are imagining that there
> might be an interoperability problem if the client developer makes
> an egregious mistake in assuming the implementation behind the
> interface defined by HTTP.  Quite frankly, that is not our problem.
>
> ....Roy
>

Received on Friday, 28 January 2005 15:32:41 UTC