Clarifying Content-Location (Issue 136)

Hi,

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.diff>)


Best regards, Julian






Julian Reschke wrote:
> 
> Hi,
> 
> I was staring at the definition of Content-Language, and trying to 
> figure out how to rephrase it avoiding the term "variant" (as discussued 
> in <http://wiki.tools.ietf.org/wg/httpbis/trac/ticket/109>):
> 
> RFC 2616 says:
> 
>    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. -- 
> <http://tools.ietf.org/html/rfc2616#section-14.14>
> 
> Comments:
> 
> - the first "MAY" seems to be useless and actually distracting ("may be 
> used", "can be used" or "is used" would be just fine)
> 
> - "...when that entity is accessible from a location separate from the 
> requested resource's URI" -- can this be simplified to "when that entity 
> is accessible from a location separate from the request-URI"? Or am I 
> missing something here?
> 
> - then it goes on saying server "SHOULD" return the header, but then 
> "SHOULD return especially" in some special cases -- but there was 
> already an unconditional SHOULD without that condition.
> 
> Part of this confusion seems to be the result of trying to BCP14fy what 
> RFC2068 said (which had the first "SHOULD" in lower case).
> 
> So, looking at RFC 2068:
> 
>    The Content-Location entity-header field may be used to supply the
>    resource location for the entity enclosed in the message. 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. In addition, a server
>    SHOULD provide a Content-Location for the resource corresponding to
>    the response entity. -- 
> <http://tools.ietf.org/html/rfc2068#section-14.15>
> 
> This looks a bit better, except for the last sentence:
> 
> "In addition, a server SHOULD provide a Content-Location for the 
> resource corresponding to the response entity."
> 
> ...which I frankly do not understand -- what does it say what hasn't 
> been said before?
> 
> So if I had to rewrite this I would make it just:
> 
>    The Content-Location entity-header field may be used to supply the
>    resource location for the entity enclosed in the message. 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.
> 
> (BCP14fying the should, dropping the last sentence)
> 
> Feedback appreciated,
> 
> Julian
> 
> 
> 
> 
>

Received on Sunday, 27 September 2009 12:09:00 UTC