W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

Re: ldp-ISSUE-10 (Guidance around ETags): Include clarifications and guidance around ETags [Linked Data Platform core]

From: Raúl García Castro <rgarcia@fi.upm.es>
Date: Mon, 04 Feb 2013 16:58:46 +0100
Message-ID: <510FDAB6.2090608@fi.upm.es>
CC: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
Hi,

My proposal for keeping things simple:

Replace:
[[
4.1.13 BPR server responses must contain accurate response ETag header 
values.
]]

with
[[
4.1.13 BPR server responses MUST use entity tags (either weak or strong 
ones) as response ETag header values.
]]

I think that with this is enough (it is mainly a rewrite of the previous 
sentence).

The HTTP protocol already describes how ETags and If-Match work, and 
clients can already differentiate between strong and weak (these start 
with "W/") entity tags.

Other things, such as how ETags can be generated should be out of the 
specification (e.g., deployment guide).

Kind regards,

El 04/02/13 12:59, Pierre-Antoine Champin escribió:
> Hi,
>
> +1 to using weak etags, for the good reasons mentionned above. This is
> what I resort to in the platform I am building.
>
> Note however that, in strict HTTP 1.1, weak etags can not be used for
> validation of PUT content. Section "14.24 If-match" of RFC2616 says
>
>     A server MUST use the strong comparison function (see section 13.3.3)
>     to compare the entity tags in If-Match.
>
> This restriction no longer exists in HTTPbis, so I take that as an
> ackowledgement that the restriction above was a misfeature. But I guess
> everyone should be aware of that if the group decides to go that path
> (which, again, I'm in favor of).
>
> I also think we should be clear about the rationale of using weak etags.
> For example, something like:
>
> The server MAY provide a strong etag (ref), but only if it can guarantee
> that the same graph will always be serialized the exact same way
> (byte-wise). This is not always the case, as the order of triples or
> blank node labels are not significant in RDF and may vary across
> serializations. If the server can not ensure that, the etags it provides
> MUST be weak etags (ref).
>
>    pa
>
>
>
> On Mon, Feb 4, 2013 at 11:58 AM, Henry Story <henry.story@bblfish.net
> <mailto:henry.story@bblfish.net>> wrote:
>
>
>     On 4 Feb 2013, at 11:53, Steve Battle <steve.battle@sysemia.co.uk
>     <mailto:steve.battle@sysemia.co.uk>> wrote:
>
>      >> -----Original Message-----
>      >> From: Wilde, Erik [mailto:Erik.Wilde@emc.com
>     <mailto:Erik.Wilde@emc.com>]
>      >
>      >> On 2013-02-04 09:24 , "Raúl García Castro" <rgarcia@fi.upm.es
>     <mailto:rgarcia@fi.upm.es>> wrote:
>      >>> .- I think that using ETags should be a MUST, since it is the
>     minimum
>      >>> requirement for detecting conflicts in updates.
>      > ...
>      >>
>      >>> .- I would keep things simple and not mention in the specification
>      >>> things like using :weakEtag properties in resource descriptions.
>      >>
>      >> +1, let's keep HTTP concepts in HTTP.
>      >
>      > To be clear _here_  (yes - I did raise etags in resource
>     descriptions in
>      > another context), we're recommending using weak ETags, not in
>     resource
>      > descriptions, but in the response header.
>      > Can we agree that the use of weak ETags with RDF content should
>     at least
>      > be a best practice recommendation?
>
>     +1 for best practice.
>
>     Also while we are at it, is there a good efficient algorithm for
>     calculating this?
>
>     ( I suppose just the hash for the hash of every triples )
>
>      >
>      > Steve.
>      >
>
>     Social Web Architect
>     http://bblfish.net/
>
>


-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19
Received on Monday, 4 February 2013 15:59:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC