ietf-822
[Top] [All Lists]

8-bit SMTP and 8-bit 822

1991-09-24 12:02:50
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

<Prev in Thread] Current Thread [Next in Thread>