MHTML/HTTP 1.1 Conflicts

All,

Now that the dust has settled, we may be able to look more clearly at
potential conflicts between the latest MHTML and HTTP 1.1 draft documents.


1. Content-Base and Content-Location
------------------------------------

MHTML and HTTP 1.1 both employ two syntactically identical MIME header
fields. These fields are Content-Base and Content-Location. In both MHTML
and HTTP 1.1, either or both can be employed in any top-level message
header, any embedded MIME message header, and any  MIME content header.
Content-Base has identical semantics in both MHTML and HTTP 1.1.
Content-Location has different semantics (see below), though in both cases
it can be used to establish a content base.


1.1 HTTP 1.1 Content-Location
-----------------------------

HTTP 1.1 defines the semantics of Content-Location as follows.

>From Section 3.7.2

  In HTTP, multipart body-parts MAY contain header fields which are
  significant to the meaning of that part. A Content-Location header field
  (section 14.15) SHOULD be included in the body-part of each enclosed
  entity that can be identified by a URL.

>From Section 14.15

  The Content-Location entity-header field MAY be used to supply the
  resource location for the entity enclosed in the message when that
  entity is accessible from a location separate from the requested
  resource's URI..

  ...

  The Content-Location value is not a replacement for the original
  requested URI; it is only a statement of the location of the resource
  corresponding to this particular entity at the time of the request.
  Future requests MAY use the Content-Location URI if the desire is to
  identify the source of that particular entity.

Given the definition of Content-Location from Section 14.15, it is not
clear what purpose the specification of Content-Location in a content
header as per Section 3.7.2 serves.


1.2 MHTML Content-Location
--------------------------

A Content-Location header field is employed in MHTML to label a MIME body
part with an URI, and this URI is used only to satisfy URI references from
Text/HTML objects in the same MIME Multipart/Related structure.  While an
MHTML Content-Location may be viewed as a *hint* to the original source of
a MIME body part, it is explicitly constrained from carrying any more
weight than that. It does not, as in HTTP, "identify the source" of a body
part.


1.3 Resolving the Semantic Conflict
-----------------------------------

There seem to be three possible approaches.

1. We can merely accept that the semantics of Content-Location
   are different in the two documents and proceed.

2. HTTP can distinguish between the use of Content-Location in
   message headers and MIME content headers. In message headers
   it would have existing HTTP semantics. In content headers
   it would have MHTML semantics.

3. MHTML can introduce a new header field (Content-Label ?) which
   would inherit current MHTML Content-Location semantics.
   Content-Location could, therefore, fully retain its HTTP
   semantics.

Hopefully, we can rapidly move to concensus on which approach to adopt.


1.4 MIME Line Length Considerations
-----------------------------------

Header fields in top level HTTP message headers are not subject to MIME
line length constraints, and none is introduced in the HTTP 1.1 draft.
Header fields in MIME Message/HTTP message headers and MIME content headers
are subject to MIME line length constraints. This is not addressed by the
HTTP draft, though header fields can be folded and unfolded as per RFC 822.
It is addressed by the MHTML draft. The MHTML draft explicitly addresses
the encoding/folding and unfolding/decoding of long URIs as per MIME, to
satisfy MIME line length constraints. It could be argued that the HTTP 1.1
draft should employ identical language.

Nick

Received on Friday, 23 January 1998 02:07:03 UTC