Re: NEW ISSUE: Drop Content-Location

On Tue, 7 Apr 2009, Mark Nottingham wrote:

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

I prefer a third choice ...
  ... a recipient SHOULD disregard the base-setting semantics if there
      also exists a base URI from the retrieval context.

I don't like the 'fewer errors' rule as that suggests the recipient is
expected to try both and make a judgement.

Also, I see no point in reporting a bad Content-Location to the user.
I still hold the belief that here should be an error report method which
clients may use to report errors to the origin server. The origin is
the responsible party with the potential to care. But that concept
was shot down years ago.

Also, reporting a bad value anywhere implies that the recipient must
evaluate the value...

Dave Morris

Received on Tuesday, 7 April 2009 03:16:12 UTC