John Klensin writes:
I believe that I'm in agreement with this, but...
Are you in agreement with the stronger version? I don't think so.
Yes, I am in agreement with the stronger version. Why? Because my
analysis of the cases in which I think that nested encoding would be
very useful has gradually caused me to conclude (again, I might add)
that there aren't any.
Well, if you'll pardon my saying so, this is fan-f***ing-tastic!
This leads me to offer a compromise proposal. I'm going to spell it out now,
we can discuss the details, and then I'd like to get a vote on it.
In brief, these are the points of my proposal:
(1) Nested encodings will be banned completely in RFC-XXXX. Specifically, this
means that a Content-TransferEncoding of either base64 or quoted-printable
is illegal on bodyparts of type multipart, multipart/mixed,
multipart/digest, message, and message/partial.
Encoding specifications may possibly be needed/useful on message/pem parts
(although they may appear at a lower level); this is an item for a later
day and probably a different WG.
(2) A Content-TransferEncoding _can_ be specified on multipart, multipart/mixed,
multipart/digest, message, and message/partial bodyparts. If specified,
it identifies the "most general" encoding used in the bodypart. There are
three possibilities:
(1) binary <-- most general
(2) 8bit
(3) 7bit <-- least general
For example, if 7bit is specified, it means that the most general
encoding used by any subpart of this bodypart is 7bit. 8bit means that
subparts may be either 7bit or 8bit, and binary means that the subparts
may be binary, 8bit, or 7bit.
Note that no provisions for transporting binary have yet been defined. This
stuff is only a placeholder at present; it would be illegal in either
old-SMTP or the current draft extended-SMTP.
This information is useful for determining what sort of message is at
hand without having to scan it. Should this information be mandatory?
Should we get rid of this idea completely? Comments?
(3) A new header will be defined: TransferEncoding-Conversion:. It can have
the values "prohibited" or "allowed". This header only has meaning in
the outermost set of headers -- if present, it controls whether or not
an agent is allowed to change the Content-TransportEncoding for any
part or parts of the message to make it possible for the message to
pass over "narrower" channels (like old SMTP).
(4) The SMTP extensions document should specifically allow an MTA faced with the
need to convert a message from 8bit to 7bit to do one of the following:
(a) Bounce the message, either without return-of-contents or with the
contents converted using the procedure below. This is mandatory if
the TransferEncoding-Conversion header specifies "prohibited".
(b) Convert the message using the procedure below. This may only be done
is the TransferEncoding-Conversion header is either missing or
specifies "permitted".
No other actions are permitted. The conversion procedure is, roughly:
Scan the message, paying attention only to the structure and to the
Content-TransferEncoding headers that appear. A
Content-TransferEncoding header that specifies 8bit should be changed
to quoted-printable, and the bodyparts it applies to should be
encoded accordingly. (Future extension: binary bodyparts should be
converted to base64, and encoded appropriately.)
Errors, such as the specification of 7bit encoding on what turns out
to be an 8bit bodypart, should cause the message to bounce immediately.
This needs to be tightened up and formalized, but all I'm interested in
now is getting the meaning clear enough to see if its is agreeable to
everyone. The writing of the formal specification can come later.
Comments on this are welcome.
Ned