Re: MHTML/HTTP 1.1 Conflicts

Jacob Palme wrote:

> Certainly you cannot ask people to reformat existing documents.
> But a company which buys a WYSIWYG HTML editor like Frontpage
> or Pagemill might require that they produce "canonical" HTML
> which agrees with both e-mail and HTTP rules. This would allow
> company employees to, for example, take pages from the local
> Intranet and send them by mail outside of this Intranet,
> without having digital seals and signatures broken.

I know of no Unix text editor that produces text files that
use the "canonical" format for text/plain using CRLF instead
of just plain LF, and I've never seen a Macintosh text editor
that produces text files using the "canonical" format with
CRLF instead of just plain CR. An editor produces files that
are appropriate for the native environment, and people with
Internet mail who mail documents using SMTP expect the mailer
to convert the file from the local convention to the canonical
one on transmission, and to do the inverse conversion when
saving the document.

The HTTP specification says that at least for the case of converting
end-of-line, such conversion is not necessary. The canonical form is
still CRLF, but conversion is not necessary.

Security checksums _should_ be applied to the canonical form,
but in truth, it is feasible to apply it to the transmitted form,
and it is the choice of the originator whether to do this. Since
an HTTP server should never actually modify the end-of-line convention,
the data as represented by the choice of the original sender can
remain intact. That is, this is not really an issue.

We've been through this topic endlessly in the past, and wrangled
out some specific wording in the HTTP draft that was believed generally
to be adequate to explain the situation, at least as far as
the 'end of line convention' discussion in the HTTP/1.1 specification
was concerned.

If there was some demand, a separate document on "HTTP/mail gateway
implementation considerations" could elaborate on the topic, but the
demand for that seems to be low. (Perhaps IMAP/WebDAV interoperability
might be an interesting application (isn't a mail folder a 'collection'?)).


I believe there's a need for addressing the 'MIME vs MIME-like'
issue, as far as the applicability of future specifications that
might revise MIME and their applicability to HTTP. For example,
if there's a revision of 'content-disposition', does it apply
to HTTP too? I don't think that would be reasonable if the spec
weren't reviewed by the HTTP community, but on the other hand,
keeping HTTP and the rest of MIME in sync is highly desirable.

Larry
-- 
http://www.parc.xerox.com/masinter

Received on Wednesday, 28 January 1998 07:42:41 UTC