> As I said earlier (while many of you were off at the IETF?), I'm > increasingly convinced that HTTP messages are (as the recent spec > suggests) MIME-like, not MIME conforming. With so many other > deviations from MIME, I suggest we should drop the (rather complex) > MIME multi-part structure based on boundaries, etc. and only allow > multi-part messages defined by a Content-Length byte count. I think we went through this with HTML; one might have said (many did) that: "... HTML files are (as the recent spec suggests) SGML-like, not SGML conforming. With so many other deviations from SGML...." I think the original *intent* was to be MIME conforming, and that it isn't *hard* to be MIME-conforming, and that there are *benefits* to being MIME-conforming. Now, we have to be careful to define what we mean by MIME-conforming, and, in particular, we may well want to register some new MIME-types or content-transfer-encodings. The EOL convention issue is not a 'HTTP' issue but centers around whether "text/html" is allowed to be more flexible about EOL convention when transport in binary form than other text forms. MIME is not basically a text-based protocol, any more than HTTP is.Received on Friday, 16 December 1994 01:20:30 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC