Re: NEW ISSUE: Drop Content-Location

The mail below 
seems to be the last in this thread, and seems to reflect the consensus 
we reached.

Should we record this as an issue then (it wasn't before), and implement 
this change?

BR, Julian

Roy T. Fielding wrote:
> On Dec 4, 2006, at 11:09 AM, Mark Nottingham wrote:
>> HTTP headers have a separate name space in the message header 
>> registry, so it can be done;
> That's a nice theory, but HTTP carries MIME messages and they are actually
> the same fields in one namespace. Conflicts are noticed by the folks who
> are responsible for maintaining MIME and they do, historically, object to
> the IESG when HTTP attempts to reuse them in a way that might lead to
> confusion if a message passes across protocol boundaries.
> At most, what we could do is say that a recipient may ignore the
> base-setting semantics of Content-Location when present in the
> outermost fields of an HTTP message received during HTTP communication.
> Personally, I think that would be a mistake.  I would prefer to say
> that a recipient may disregard the base-setting semantics if there also
> exists a base URI from the retrieval context and use of that base URI
> for parsing relative references within the entity results in fewer
> errors than use of the Content-Location URI.  A bad Content-Location
> value SHOULD be reported to the user as an error.
> ....Roy

Received on Monday, 30 March 2009 13:24:57 UTC