ietf-822
[Top] [All Lists]

Re: non-ASCII in headers

1991-10-02 22:33:23
You ( Mark Crispin <MRC(_at_)Panda(_dot_)COM> ) said:
I wish people would read messages before replying to them.

I might say the same thing.

I *implemented* a system which allowed ISO-2022 kanji in the Subject
line as well as in the body.  I was told, by the Japanese customer,
not to bother (*after* the code had been written and debugged) because
they would never use it.

This just goes to reaffirm what someone else just pointed out, that
different people relying on different personal experiences can be
confusing.

You can not say that `everyone' in Japan wanted to be able to use
Japanese characters in Subject lines.  I just gave you a
counter-example.  You yourself admit that although your lab did so
internally they were cautioned not to do so if the mail was going
outside the lab.

No, just as I can not say that everyone in the US wants to use
English.  There are many exceptions in both cases.  My feeling is that
your experience must have been one.  I did in fact feel that everyone
WANTED to use Japanese in Subject lines.  They were cautioned not to
do so with external mail simply because so many mailers couldn't
handle it.  It had nothing to do with whether or not they *wanted* to
do it.  (They did.)  Practically speaking they *couldn't*.

The only thing that is more disgusting than foreigners predicating
their arguments on a bogus assumption of an opponent's `American bias'
is an American predicating his argument on a bogus assumption of an
opponent's `American bias.'

Let's take the name calling offline.

The `rules' must take the most narrow interpretation.  Locally, you
can take a more general interpretation.

What do you mean by locally?  I want to send mail to friends in Japan
with Japanese in the Subject line.  They want to send it to me.
Others I am sure want to do the same between here and Europe with
other languages.  Where is local?

The bias is INTEROPERABILITY.  We will have this problem as long as most of
the mail programs in the world are in the dark ages and implement
`presentation to the user' as `output the text of the headers and body in
image form to the terminal'.

 ... text deleted ...

This does not belong in RFC-XXXX.  It's a major issue in its own
light.  It should be deferred to another RFC.

Whether or not this is addresses separately or in the same RFC, it
needs to be addressed simultaneously if you want to ever have
interoperability.  It's worth the time in the long run.  The "most
narrow interpretation" must allow it.  "Most narrow" views of
standards can no longer be restricted to US-ASCII if we want to be
competetive and/or interoperable in countries that don't speak
"US-ASCII".   

Interoperability is one thing, but absence of support is another.  I
would personally feel awfully silly, in 1991, producing yet another
standard that was even in as small but important a way as this
restricted to US-ASCII.  Wouldn't you?  It is technically the right
thing to do to encourage vendor support by standardizing it in a
timely manner.  Let RFC-XXXX come out significantly before an RFC to
cover this, and you can add one more flavor to e-mail
interoperability.  I hope you see this, and that it's worth the time
to do it right.

feldmark

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