Proposed new Firefox IDN display algorithm

J-F C. Morfin jfc at
Wed Feb 8 12:44:39 CET 2012

At 10:25 07/02/2012, Vint Cerf wrote:
>At the risk of jumping in at mid-stream, it occurs to me that John's 
>idea below (show U-label, show A-label, show Unicode character 
>identifiers) is a variant of the "show source" that some users will 
>choose to do for web pages, or "show original" for display of all 
>the extra stuff that goes along with an email. Highlighting an FQDN 
>and having a drop down opportunity to display it in various ways 
>might be one way to help users signal this desire. Obviously, the 
>u-label display won't work if the fonts aren't available.

Excellent remark. The only thing we need now is for the users to be 
able to send and receieve in a similar way (options or options on a 
TLD list with a default choosable option) non-filtered strings in the 
case of usages or TLDs not respecting IDNA2008 restrictions, like 
initially documented by ".su", a position that will most probably be 
adopted by most non-ICANN bound TLD managers (ccTLDs, private networks).

>On Tue, Feb 7, 2012 at 1:35 AM, John C Klensin 
><<mailto:klensin at>klensin at> wrote:
>--On Tuesday, February 07, 2012 02:02 +0100 "J-F C. Morfin"
><<mailto:jfc at>jfc at> wrote:
> > At 21:24 06/02/2012, John C Klensin wrote:
> >> Gerv,
> >
> > John,
> >
> > as long as we are talking of a Mozilla-IPI (International
> > Plug-In) that can be used with a transparent Firefox and every
> > other browser when in transparent mode, so we get the same
> > result whatever the browser or we can use whatever other IPI
> > approved by the local ISOC Chapter, ICANN, the national
> > university association, ZDNet, the national ccTLD, etc. with
> > Firefox there is no problem with IUsers.
>I actually wasn't talking about that.  My reason is one of those
>in which we may converge in the extreme case even if we disagree
>on most of the details (I'm not sure we do).
>I'm quite certain that there is no perfect solution to the
>problems and alternatives to drive Gerv's policy (and other
>policies in other browsers).   I think that the classic remedy
>of "a good compromise is one that makes everyone equally
>unhappy" is not a good solution in this type of human interface
>situation.   And, while I really like the idea of Gerv and his
>colleagues that every version of Firefox, on every platform and
>in every language adaptation, should behave the same way wrt
>IDNs, I'm not sure that is the most important objective.  In
>particular, I think it is possible that ability to localize and
>to adjust to different user usage pattern may be more important.
>I'm also really, really afraid of the possible consequences of
>widespread appearance appearance of "????" or other "tried to
>display that and couldn't" situations.  I think that many of the
>people who are concerned about confusion among characters are
>paying too little attention to that one.
>As a result, my preference is that:
>(1) Different browsers try the ideas that they think will work
>best so that we can all compare, ideas that are clearly good can
>gradually spread, and, if it turns out that there are only
>tradeoffs, users can make choices based on what suits their
>needs and matches their taste.  Coming up with a universal
>solution (or even a clear definition of a "transparent mode") at
>this point seems to me to require knowledge that none of us
>really have, independent of whether our guesses and hypotheses
>agree or disagree.
>(2) I deliberately didn't mention it in my long note but, from a
>UI design standpoint, I'd like to see Firefox do two additional
>One is to provide a switch that permits a user to say "I think
>I'm smarter than you are and am willing to take responsibility
>for that belief and its consequences".  If set in this case (it
>should obviously be off by default), it should simply disable
>all of the "display algorithm" stuff, causing the browser to
>display whatever it can in native character form.  From my point
>of view, similar switches in other browsers to disable _their_
>algorithms and approaches to the problem would be a good idea
>too.  For reasons that I think I understand, I don't expect
>Mozilla to provide that switch (or perhaps to provide it and
>make it hard for any but the most sophisticated users to find),
>but I still think it would be a good idea.
>The second, and even more important, is that I believe the
>browser should provide a very accessible, very easy-to-use,
>transcoder for these labels.  The best UI may differ among
>browsers and platforms, but, as an example for desktop machines,
>I'd like to be able to right-click on a domain name or label or
>even highlighted/ selected string and have all three of U-label
>form, A-label form, and a list of Unicode code points (in U+NNNN
>or \u'NNNN' form) easily available.  For the user who does know
>what is going on (or who can learn) that particular
>tool/facility is likely to be far more useful in the long run
>than any collection of "we know more about this than you do and
>are here to protect you" tools.  For what I think Gerv believes
>is the more typical user (and he is probably right) such a tool
>is, at worst, another feature like "display source" that will
>never be used.
>If I have to copy a string and carry it to another tool, the
>value of the approach goes down significantly, not just because
>the inconvenience might discourage me from checking strings I
>ought to check, but because the uncertainties of copy-and-paste
>operations might yield false results.
>As a trivial, ASCII-only, example, if I see "rn" on a small
>screen and in poor light, it would be a huge advantage to be
>able to be able to get the browser to show me code points that
>would tell me if I'm looking at U+006D or at U+0072 U+006E.
>Similar examples for far more complex IDN cases should be
>obvious.  For that set of examples, the code point list is
>likely to be a lot more useful than an A-label.  There will
>likely be other cases where the A-label (or the U-label if the
>A-label is displayed) will be more useful.  FWIW, such a
>facility will, IMO, become even more important if we start
>seeing wide deployment of non-trivial IRIs (and, for them,
>%-encoded UTF-8 needs to be on the list of forms that can be
>seen or obtained too).
> > This is why I suggest that your mail is published as an
> > extension of RFC 5895.
>I actually don't think it has much to do with 5895.  Independent
>of that, if others think it is useful enough, I could certainly
>put it together either as an I-D  that might lead to an RFC or
>as an article for publication elsewhere.   At least at this hour
>of the night, I'd guess the latter might be more appropriate, if
>only because the IETF and the RFC Series rarely go that far down
>the path toward UI design.
>    john
>Idna-update mailing list
><mailto:Idna-update at>Idna-update at
>Idna-update mailing list
>Idna-update at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Idna-update mailing list