Re: Multiple Content-Location headers

All,

I have reviewed the relevant Content-Base and Content-Location language in
<draft-ietf-http-v11-spec-rev-01.txt>. All that would be required to fully
align <draft-ietf-mhtml-rev-04X.txt> with this usage would be a reversion
to allowing only 0 or 1 Content-Location header field, per content or
message header. If we wish to continue to allow a resource, carried as an
MHTML body part, to be labeled with additional URIs, then I suggest we
adopt Stef's suggestion, though I would opt for Content-Alternate-Location
in place of Content-Location-Alternate. This would allow us to associate
additional URIs with a body part for the purpose of satisfying multiple URI
referrences with a single body part. Note, that I am not a great fan of
this additional complexity, but others hav argued strongly for its
inclusion, and rough concensus was reached.

Right now, I can see no role for a Content-Alternate-Location header field
in *single object* HTTP, but I leave for others to argue otherwise.

Nick