Re: MIME multipart/* vs HTTP

>   If the intent is/was that Content-Length should be used in each part
>   of a multipart/* body part rather than boundary markers, then I
>   believe that the spec needs some clarification on this point.  While
>   I expect that others may disagree, I believe that such a change
>   would be a big improvement.

I think that the situation is now similar to that of Gopher where there
were also unhelpful demands. The Web is now the main engine for adoption
of MIME and it is quite reasonable to expect changes in MIME to reflect
HTTP usage at this point.


> PH-B> Against this the MIME argument was that you might want to gate
> PH-B> HTTP to mail.  The idea that the gateway should handle the
> PH-B> convbersion was not acceptable.
> 
>   A gateway would also have to do work to change the HTTP 8-bit data
>   to some Content-Transfer-Encoding anyway, wouldn't it?  Adding a
>   boundary marker (or the Content-Length in the other direction) in
>   the process hardly seems an extraordinary requirement.

I entirely agree. I never understood the boundary gateway argument at
the time. Conversations tended to go '"but you have to encode the
character set because HTTP requires an 8 bit clean connection. In reply we
got a demand to cease using 8 bit clean connections and base 64 encode
EVERY message.

MIME should have a content-length header and it should specify a 
subset for tunneling through backward compatible gateways.

I would like to see a radical overhaul of SMTP that ignores the sendmail
legacy and explicitly considers the store and forward mail delivery
paradigm. SMTP is designed to deliver from source to destination, the
idea that mail gateways should gateway SMTP-SMTP is really not considered
in the script.

As part of this overhaul I would like to see a specification for "gold-class"
handlers. These would not introduce arbitary crap like stripping to 7-bits,
truncating lines or any other stupid transformation. The only character 
sets permitted in this class would be ASCII and UNICODE. The protocol
would explicitly support transaction like semantics including giving a
reliable notification of delivery. Mail delivered through the gold class 
network would never be held in "resend queues" and never screw up mailing
lists. It would support address books allowing them to acquire knowledge 
of the display abilities of mail users so the Word97 to Word95 user problem
would be avoided. Oh and all clients would support HTML.

In short it would work when a gold class object talked to another gold class
object. Gateways would be possible but the spec would not be corrupted to
support a bunch of braindammaged bozos who use a mailler written by
Thomas Jefferson with help from Charles Babbage which can only cope with
line lengths of 8 characters written in morse code.


I'm sure that more effort goes into making the broken work than would be 
required to buiild somethin that really worked. All we need is some competent
engineers, the big vendors and some people who are willing to insist on 
extreeme principle. 

	Phill

Received on Wednesday, 30 April 1997 13:55:59 UTC