Subject: Re: NEW ISSUE: Drop Content-Location

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 1 Dec 2006 22:24:52 -0800

On Nov 29, 2006, at 1:41 PM, Roy T. Fielding wrote:
> 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/;

Actually, that can't be done either because Content-Location is a
MIME header field and its meaning for MIME parts and RTSP is applicable
regardless of the current behavior of browsers.

    http://tools.ietf.org/html/rfc2557
    http://www.zvon.org/tmRFC/RFC2557/Output/chapter4.html

I think the browser vendors should put a little more effort into
deploying the feature.  For example, by selectively disabling it for
specific servers based on run-time testable behavior and
reporting the errors when found so that the owner can fix them.
It is, after all, a detectable error that can be worked around.
It could even be a configurable option wherein content-location
would only be used if the base URI is unknown or if the option is set.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Dec 2006 11:09:15 -0800

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

--
Mark Nottingham
[email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 4 Dec 2006 15:57:34 -0800

>   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

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 10 Dec 2006 20:15:45 +0100

> value SHOULD be reported to the user as an error.

Fully agreed.

Regards
Henrik