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.