W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

RE: Clarifying Content-Location (Issue 136)

From: Robert Brewer <fumanchu@aminus.org>
Date: Sun, 27 Sep 2009 08:44:28 -0700
Message-ID: <F1962646D3B64642B7C9A06068EE1E640A5327C0@ex10.hostedexchange.local>
To: "Julian Reschke" <julian.reschke@gmx.de>, "HTTP Working Group" <ietf-http-wg@w3.org>
Julian Reschke wrote:
> we've got an old issue pending resolution with respect to totally
> confusing language in the introduction of Content-Location (see old
> mail
> quoted at the end and
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/136>).
> 
> The RFC2616 text was:
> 
> -- snip --
> 14.14 Content-Location
> 
>     The Content-Location entity-header field MAY be used to supply the
>     resource location for the entity enclosed in the message when that
>     entity is accessible from a location separate from the requested
>     resource's URI. A server SHOULD provide a Content-Location for the
>     variant corresponding to the response entity; especially in the
> case
>     where a resource has multiple entities associated with it, and
> those
>     entities actually have separate locations by which they might be
>     individually accessed, the server SHOULD provide a
Content-Location
>     for the particular variant which is returned.
> -- snip --
> 
> Note the double SHOULD in the second half, one overlapping the other
in
> scope; more discussion about this is in the old mailing list thread
> starting at
> <http://lists.w3.org/Archives/Public/ietf-http-
> wg/2008JulSep/0259.html>.
> 
> We recently rephrased the header field introductions, and Part 3 now
> states:
> 
> -- snip --
> 5.7.  Content-Location
> 
>     The "Content-Location" entity-header field is used to supply a URI
>     for the entity in the message when it is accessible from a
location
>     separate from the requested resource's URI.
> 
>     A server SHOULD provide a Content-Location for the variant
>     corresponding to the response entity, especially in the case where
> a
>     resource has multiple entities associated with it, and those
> entities
>     actually have separate locations by which they might be
> individually
>     accessed, the server SHOULD provide a Content-Location for the
>     particular variant which is returned.
> -- snip --
> 
> (Note the first sentence was rewritten, and a paragraph break was
> inserted)
> 
> We'd like to reduce this to:
> 
> -- snip --
> 5.7.  Content-Location
> 
>     The "Content-Location" entity-header field is used to supply a URI
>     for the entity in the message when it is accessible from a
location
>     separate from the requested resource's URI.
> 
>     A server SHOULD provide a Content-Location for the variant
>     corresponding to the response entity, especially in the case where
a
>     resource has multiple entities associated with it and those
entities
>     actually have separate locations by which they might be
individually
>     accessed.
> -- snip --
> 
> ...which essentially removes the SHOULD for the case where there's
only
> one entity - I think that reflects common sense.
> 
> (see also
>
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/136/136.d
> iff>)

Yes, although I don't think that quite "removes the SHOULD for the case
where there's only one entity". Also, must we continue the tradition of
adding adverbs ad infinitum to create long, passive, run-on sentences?
;)

  The "Content-Location" entity-header field supplies a URI for the
  entity in the message when it is different than the requested
  resource's URI. When a resource has multiple entities accessible
  at separate locations, a server SHOULD provide a Content-Location
  for the variant.


Robert Brewer
fumanchu@aminus.org
Received on Sunday, 27 September 2009 15:45:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:10 GMT