RE: Problems of Internationalized Mail Address eXtensions (IMAX)

Martin Duerst <[email protected]>
Newsgroups gmane.ietf.imaa
Message-ID <4.2.0.58.J.20030228111508.042cedf0@localhost>
At 19:12 03/02/27 -0800, Dan Kohn wrote:

>Dan Kohn wrote:
>
> >> I believe sysadmins who care can use a punycode decoding tool (or
> >> Emacs macro) and that the vast majority won't care.
>
>D. J. Bernstein writes:
>
> > Won't care? _Won't care_?
>
>Yes, won't care.  The difference between <display-name> and <addr-spec>
>(using the constructs from Section 3.4 of RFC 2822) is that the former
>is unambiguously user text (in the RFC 2277 sense) and the latter can be
>treated much more like a protocol element.  I agree that it is nice to
>often be able to guess usernames or use heuristics about their meaning,
>but it's not necessary.

We are not talking about guessing here. Having somebody tell
that there is a problem with her mail (address FOO), and you
as a sysadmin go looking for that address FOO in some of
your files has nothing to do with guessing.

And the argumentation about protocol elements doesn't really
work, of course it is a protocol element, but the whole effort
we are making here is just about making it readable for users
(at all levels, not just the end recipients).


>(One could argue that it would also be nice to
>know what MAIL FROM or Content-Disposition means in your native tongue
>rather than treating them as abstract protocol elements, which they
>obviously are.)

Administrators (not end users) can and do obviously learn these.
And there is a big difference between something being English, and
always being the same, whereas something actually being e.g. Japanese,
but mutilated beyond recognition.

Just think about it the other way round: If you were a sysadmin
and everything was in Chinese, you would probably pick up on the
character for 'MAIL FROM' rather quickly, but then if user
'John Smith' with address [email protected] came over with
a problem, you wouldn't want to have to put [email protected]
into a tool and then go hunt for the problem with some Chinese
characters.


>Anyway, I'm not making an absolutist argument here, that things are only
>protocol or text and never anything in between.

Rather than 'between', I'd say 'overlap'.


>I'm just pointing out
>that a Japanese mail admin certainly *could* get by just fine treating
>the LHS and RHS of <addr-spec> as opaque text, as they would have to do
>anyway for many of their users' correspondents' ASCII addresses.

Japanese don't treat ASCII email addresses as opaque. If you have
an address such as [email protected], they don't have that many
problems recognizing the element in the address. It will take them
a lot longer than it will take the average native reader, but it's
not really a problem. And even Japanese users do feel much
better with [email protected] than with $%&^*@#%$((^&%(.
So why should we work on a system that makes things worse for them?

Regards,    Martin.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.