I would like to clarify/restate what Rob Ullmann and I are proposing
with regard to 8-bit SMTP and 8-bit 822. (The next note will address
some of the questions that have been raised about the proposal.)
The statement "Just declare 7-bit mailers broken." has *NEVER* been
stated by us! (Greg will confirm.)
What we do state is "Just declare 8-bit mailers more functional."
What we *ARE* proposing is that we make 8-bit SMTP and 8-bit 822 a
clean superset of 7-bit SMTP and 7-bit 822. (Where "clean" means
that 7-bit and 8-bit mailers will interoperate safely.)
What we are proposing is as follows...
822/7 (if you will) is currently defined as 7-bit ASCII. 822/8 will
be the 1-5 octet AUC codes currently being discussed for 10646. AUC
is an algorithmically generated 1-5 octet representation of 10646
32-bit codes. The AUC codes 00-9F (hex) ARE the same as 8859. 822/7
*IS* a subset of 822/8.
Header keywords will remain restricted to 7-bit ASCII. Header
"unstructured" (text) field bodies (like "subject:") will be AUC.
Header "structured" field bodies (like "To:") today require
\-escaping of meta characters (like "<" 3C). To be SMTP/7 non-
hostile, "structured" AUC field bodies will require \-escaping of
meta characters *AND* of 8-bit octets which, when stripped to 7-bits,
look like meta characters (like BC).
The value of using AUC is that it will provide us with messages that
are not just in ASCII-7 or in "Western-Euro-centric" 8859/1, but in a
universal code. There will be no "enclaves".
SMTP/8 is simply SMTP/7 with 8-bit DATA. (All of the envelope will
remain in 7-bit ASCII.) No other changes to mailers is required and
most vendors/providers are already shipping 8-bit-clean SMTP and
UUCP.
Yours,
David