Nathaniel,
I am enthuistic about the real-headers for extended character
set support in message headers. I have seen no objections to the
scheme, and it appears to be workable. Please include it in the next
draft of the RFCXXXX. BTW, when can we expect a new version?
I propose the following for the next interim-revision of the
document...
1) Prohibit nested encodings
2) Use the new definitions I suggested for content-types with edits
suggested on this list. In particular, emphesise that the content-type
does not imply an encoding of the information.
3) Use the content-encodings as defined previously, with explicit
language that the content-encodings do not imply anything about the
content of the message except the transport requirements. IN
particular, that 8 bit does not imply quoted printable and binary does
not imply Base 64. It is worth emphesizing in the draft that except
for issues of effeciency and asthetics, base 64 and quoted printable
are interchangable, and the selection of one or the other of these
well defined mechanisms is a gateway's choice.
Note: Unless someone gives a proposal for explicitly designating the
encoding to be used in case of conversion, I'd stay with the current
proposal. I do not consider this a closed issue, but for the next
draft I'd like to have real text.
4) Binary should remain as a supported transport mechanism in RFCXXXX.
The decision of whether to support it in Extended SMTP is really not
an issue for this group to resolve.
Comments?
Greg Vaudreuil