Jacob Palme wrote:
>>From an implementor's point of view, having to cope with both
>a Content-Location and a Content-ID header field, the implementor
>anyway has to be able to handle multiplce such identification
>fields.
>
>One reason against it might be the Base. Another, of course, is
>if some implementors has strongly committed his implementation
>to a solution which does not allow this.


From our point of view, we already have to cope with Content-Location and
Content-ID, so this doesn't complicate stuff much. As Jacob points out the
only additional complexity it introduces for us is in the spec where we need
to be clear that ONLY the first Content-Location is used for determining the
base.

Let me build up some additional justification for this. URIs are case
sensitive (depending on your definition, they are just octet streams).
However web servers are free to support them in a case insensitive manner
(for example most servers on MacOS. Windows, and I think OS/2 do so). This
means that authors might accidentally refer to the same included document
via several distinct URLs that just case changes (foo.gif, foo.GIF). From
the point of view of MHTML, these are distinct URLs, but a smart UA might
detect that the resources returned by these two URLs are byte-for-byte
identical, and encode the message more efficiently.

Alex Hopmann
Microsoft Corporation