David Robinson writes:
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.)
This message is not sufficiently clear to me. See below.
The statement "Just declare 7-bit mailers broken." has *NEVER* been
stated by us! (Greg will confirm.)
I would disagree, but that's not the point.
What we do state is "Just declare 8-bit mailers more functional."
I have no idea what this means.
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.)
You have yet to demonstrate this.
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.
Keeping in mind that I don't know the details of AUC, the only phrase
that is meaningful to me here is "the AUC codes 00-9F". If AUC uses the
octet 9F, well, 9F(16) = 159(10) > 127. This is 8 bit material. You can label
and relabel to your heart's content but it will remain an 8 bit character.
Unless you're proposing some sort of subset of AUC, or encoded AUC is not
what the range 0-9F refers to, or... ?
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).
Once again you seem to imply that octets with values > 127 will be used.
This remains unacceptable.
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".
The enclaves will be the people who are willing to start using this
scheme (well in advance of any standard describing it, and with the
strong possibility that it will get nuked and/or modified before it
actually becomes a standard of any sort).
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.
My reading of this may be wrong. But the ONLY question that matters to me is:
Do you make use (at ANY point in the protocol) of octets with the high bit lit?
Yes or no?
If the answer is yes this is just the same old tired proposal that Prime
has been pushing since day 1. The only change you have made is that you
have gussied it up in new clothes -- to wit, you're now advocating the use
of a highly preliminary piece of standards-in-the-making in conjunction with
your old song and dance.
It does not, however, change the fundamental interoperability problems of the
earlier proposal in any way, shape, or form. And that proposal was shot down
on precisely those grounds and no others.
If, on the other hand, the answer is no, we never ever ever use an octet
with a value greater than 127 at any point in the protocol, then I'm willing
to listen a little more. But then note that your proposal is covered by
existing proposals, in fact, modulo the addition of appropriate identifiers
to identify this AUC stuff it is a small subset of RFC-XXXX plus a resolution
of the header text problem, as far as I can tell.
Ned