> -----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