RE: "Variant" language in Content-Location (Issue 109)

Julian Reschke wrote:
> 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)

Totally agree.

> - "...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?

Also sounds good.

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

Going on an anti-verbosity tear:

    The Content-Location entity-header field supplies a location
    for the returned entity that is separate from the Request-URI.
    A server SHOULD provide a Content-Location whenever a resource
    has multiple entities with separate locations.


Robert Brewer
fumanchu@aminus.org

Received on Tuesday, 5 August 2008 23:44:35 UTC