Re: Lastest drfat of RFC-XXXX

[Greg Vaudreuil <gvaudre@xxxxxxxxxxxxxxxx>]

> My only concern with the "Wretched" solution is that it requires the
> SMTP implementation to reach into the content of the "DATA", interpret
> it as headers+text (an assumption it currently does not make), interpret
> one of the headers as "content-type", adjust its behaviour accordingly,
> and perhaps change both the format of the "DATA" and the content of the
> "content-type" header if it decides to do a new encoding.

Alas, That is one of the reasons the "Wretched" solution died. The
RFC XXXX assumes that any future migration to 8 bit transport will be
done with gateways that look into the body of the DATA part and make
any necessary modifications.  

I would like to see a special case of the outermost content-encoding
header which would apply to the entire message in such a way that a
conversion gateway could encode the entire message and add a header
line indicatating that it had done so.  This however gets into the
problem of having multiple headers indicating encoding.  I feel there
is a solution, but it is not really elegant......

Greg Vaudreuil