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. NickReceived on Friday, 16 January 1998 04:12:04 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC