ietf-822
[Top] [All Lists]

Working code and rough consensus on RFC 822 interpretation

1994-12-03 00:54:40
<< Then these MUA's have been violating RFC 822 for years.
<
< I know that's a typical view of US-centric people who do not know the real
< world.
<
<< Mr. Ohta would have us believe otherwise, but his claims have been
<< disproven many times.
<
< Show us an example, or we regard your statement disproved.

Mr. Ohta,

It all boils down to whether you believe that RFC 822 specifies NET-ASCII or
US-ASCII. Several people have shown that RFC 822 specifies US-ASCII and the
author of RFC 822 concurs. You, however, persist in believing that RFC 822
specifies NET-ASCII.

So, now is the time to consult the working code and the rough
consensus.

Sendmail, THE WORKING CODE, transmit anything 1-127 regardless of
whether it is US-ASCII or not.

MUAs also, passs anything 1-127 (or even 0-255) regardless of whether
it s US-ASCII or not. Yes, some years ago, a few MUA filters out ESC.
But no MUAs reject input because it receives non-ASCII national variant
of ISO 646.

Old news (old Bnews) did not, but, changed 10 years ago in Japan and
later news systems pass everything worldwide (including in USA).

So, the status of the working code is clear.

And, surely, the rough consensus in USA is that RFC 822 is for US-ASCII.

But, everywhere outside of USA, the smooth consensus is that RFC 822
is for 0-127.

Now, let's have a rough vote on the interpretation of RFC 822:
        
        US-ASCII : 1 (USA only)
        NET-ASCII : more than 10

So, the status of rough consensus is also clear.

In mathematical terms, this is an axiom upon which all else builds.

No mathematics please. It's an engineering issue.

PERIOD.

                                                        Masataka Ohta

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