- From: Jacob Palme <jpalme@dsv.su.se>
- Date: Sun, 25 Jan 1998 13:31:15 +0100
- To: Albert Lunde <Albert-Lunde@nwu.edu>, IETF working group on HTML in e-mail <mhtml@segate.sunet.se>, http-wg@cuckoo.hpl.hp.com
At 23.45 -0600 98-01-24, Albert Lunde wrote: > and from 19.4.4: > > >Proxies and gateways from HTTP to MIME-compliant protocols are > >responsible for ensuring that the message is in the correct format > >and encoding for safe transport on that protocol, where "safe > >transport" is defined by the limitations of the protocol being used. > >Such a proxy or gateway SHOULD label the data with an appropriate > >Content-Transfer-Encoding if doing so will improve the likelihood of > >safe transport over the destination protocol. > > My reading of this is that HTTP only imposes its own requirements on the > HTTP headers and body: which are those of an almost-binary transport > (almost because of the CR/LF/CRLF rules), with no line length limits. > > Especially the paragraph from 19.4.4 puts the responsibity on HTTP-> mail > (and mail-> HTTP) gateways for unscrewing the real incompatabilties with > MIME. Certainly HTTP must *allow* all the current variants of document formats with various end-of-line characters. But the HTTP spec could still *mention* the problem that security checksums will not work if messages are converted from HTTP to mail, unless they already in HTTP are in the canonical form. Security checksums will probably be more and more important in the future, and more and more people will want to provide documents with digital seals and digital signatures, and which can be moved from HTTP to mail. ------------------------------------------------------------------------ Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme
Received on Sunday, 25 January 1998 11:03:57 UTC