Re: NEW ISSUE: Drop Content-Location

It's not helpful to formulate the issue as 'Drop Content-Location';  
ATM, my inclination is to create it as 'Content-Location base-setting  
problems'.

Anne and Ian, does this adequately encompass your issue? If other  
aspects are important, it would be helpful if you provided a succinct  
summary.

I'm not sure we yet have consensus, but I'm optimistic that we're  
close. Roy made two proposals:

> The only thing that should be changed at this point is 14.14:
>
>   The value of Content-Location also defines the base URI for the
>   entity.
>
> s/also defines/does not define/;



> 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, which do you prefer, and does anyone else have a preference?

Furthermore, would it be useful if we gave advice about generating  
relative Content-Locations, to avoid at least some of the errors  
described in this thread?



On 31/03/2009, at 12:24 AM, Julian Reschke wrote:

> The mail below (<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0254.html 
> >) 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;
>>>  http://www.iana.org/assignments/message-headers/perm-headers.html
>> 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
>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 7 April 2009 02:38:25 UTC