[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [idn] RE: An idn protocolfor consideration in making therequirements



Title: RE: [idn] RE: An idn protocolfor consideration in making the req uirements
For a fair number of people in the world, ASCII is barely readable, and their scripts are unreadable many others. An I18N design, while it has to accommodate to the existing systems in place, should should be script neutral and not biased in favor of English.
 
If I understand your proposal correctly, in essence you propose that the official name will be ASCII, with synonyms in other scripts. The non-ASCII names will only be used if the user agent in some way asks for them.
 
I think the problem you raise is not a real problem, it is just a nuisance. People will not very often be exposed to "gibberish" ASCII names, they will have to ask for them in some way or receive mail. People who will be intentionally using IDNS will necessarily have a suitable user agent. And if you are exposed to these names in the raw, they are just meaningless, not causing any other difficulty. If you reply to such mail, it should still work.
 
Jony
-----Original Message-----
From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf Of Karlsson Kent - keka
Sent: Friday, February 11, 2000 8:36 PM
To: idn@ops.ietf.org
Subject: RE: [idn] RE: An idn protocolfor consideration in making the requirements



> -----Original Message-----
> From: Jonathan Rosenne [mailto:rosenne@qsm.co.il]
...
> What the user sees is a function of the user agent software,
> not of the protocol.

Yes, and?  The reencodings that I'm complaining about
are not hidden at some very low level where they never
escape.  They are indeed shown in their reencoded form
to the end user.  Always, initially.  Often, later on.
May (which is too often) still escape, forever. (This
is based on experience with QP and BASE64 for e-mails.)

If the reencoding (of non-ASCII into ASCII) was well
hidden and *always* kept under wraps, *never* to escape
to any user's eyes (network geeks excepted), then I
would indeed have nothing to complain about. But that
is not the case for the suggestion(s) (CIDNUC and
iDN/UTF-5) currently tentatively being put forward,
and that I'm complaining about.

As I've said before, a registrant selected ASCII fallback
name is fine (semi-permanently), assuming that UIs
will more and more often be able to use (and show) the
'proper' (non-ASCII) name.  A registrant may even wish
to register several names for a domain, e.g. one in
Japanese, one transliterated to Hangul, one Hepburn
transliterated to the Latin script, and one fallback
transliterated into ASCII.  But no user, or registrant,
would (I do hope) be interested at all in having any
strangely transformed name that is just ASCII gibberish.

And, as I said, I'll be very open-minded to any
suggestions that always exposes *only* deliberately
selected registered names to actual users, and does
so only in some commonly accepted globally viable
encoding (there are only two to choose from...).

What's at a low level *guaranteed* to be kept under wraps
(from an 'end user's' point of view)?  Please select
whatever "works" (in Ned's sense), reencoded or not.

                Kind regards
                /kent k