Subject: Re: [iucg] Browser IDN display policy: opinions sought

From: JFC Morfin <[email-masked]>
Date: Fri, 09 Dec 2011 15:22:03 +0100

Dear Gervase,

IMHO if we want to force everyone to be happy in the only way we 
would want and use mandatory lists, we will make no one happy. IDNofA 
as an architecture is broken: your questions demonstrate it: five 
sister applications, at least 3 approximative different behaviours, 
and possibly five different IP resolution.

The only stable solution is a single common IDNApplication because 
there is a single common Internet DNS. This was not in our charter, 
but this was Lisa Dussault's wished us to address once we agreed over 
the WG/LC. Either the IAB eventually documents it, or we will 
disseminate it. The point is in the "WITISWISISWIS" IDNApplications 
requirement: what I type is what I see is what I send.

Please let us explain around that :

- there are 22500 language entities throught the world listed by the 
FLOSS Linguasphere database.
- there will be billions of TLDs and trillions of IDNs supported by 
IDv6 (IPv6 ID used on a global basis)
- the open code browsers will be forked to support IDNA transparent support.

Why not to just keep the browsers transparent and support your 3 
buckets as a single option set (one can chose the default depending 
on the local needs pattern). As they are I really fail to see how 
each of these bucket can clearly and easily support plurilingual 
users, multilingual applications or be used in an aerport or hotel cybercafe.

jfc

At 12:12 09/12/2011, Gervase Markham wrote:
>Recently, Mozilla community member Jothan Frakes was kind enough to do
>some research about how different popular web browsers implement IDN,
>and when they display the real characters and when they display
>Punycode. This is in the context of a Mozilla review of our policy. I am
>interested in the opinions of people on this list (see below).
>
>As it turns out, the behaviour of all popular browsers is summarised at
>the bottom a Chromium project document here:
>http://www.chromium.org/developers/design-documents/idn-in-google-chrome
>
>The policies fall into 3 approximate buckets:
>
>A (IE, Chrome): Unicode if the (single) 'language' of the string is
>configured in the options, Punycode otherwise.
>
>B (Firefox, Opera): Unicode if the TLD is in a whitelist, Punycode
>otherwise. Arbitrary script mixing permitted (registry policy used to
>prevent abuse).
>
>C (Safari): Unicode if the script is in a whitelist (which by default
>does not include Cyrillic or Greek), Punycode otherwise. Not sure about
>script mixing.
>
>
>Firefox has historically resisted adopting a Type A policy because we
>consider it seriously detrimental to IDN adoption and use. It seems to
>me that IDN can never be reliable for site owners, and therefore will
>not succceed, if a significant proportion of the world's browsers adopt
>Type A or Type C policies. This is because site owners can never know
>what proportion of their visitors will see gobbledegook in the URL bar
>rather than their nice domain name. Perhaps for sites whose visitors are
>all guaranteed to be from a particular country or language group, with
>properly-configured browsers and OSes which know that they speak a
>certain language or use a certain script, it might work - but I suggest
>that's a small subset of all sites. Many people in non-English-speaking
>countries still use English OSes and English browsers, with default
>settings.
>
>Type C is particularly bad - Russian and Greek IDNs are broken by
>default, but even if you persuade your users to turn it on, they can
>then be mixed-script spoofed. You get to choose between functionality
>and security.
>
>By contrast, with a Type B policy, if your IDN domain works in one copy
>of Firefox, it works in them all. If everyone had Type B policies, there
>would be no risk of a properly-registered domain coming up as gibberish.
>
>It has been suggested that Firefox switch to a Type A policy. As it is,
>the mix of policies means that the goal of universal acceptability is
>not being met anyway. Firefox switching to Type A would also not meet
>that goal by itself, but one could argue that there's a bit more
>consistency to browser behaviour.
>
>I would be interested in the opinion of people on this list as to:
>
>- whether my analysis seems reasonable;
>- whether they prefer type A, B or C; and
>- whether they see any particular policy as more damaging to IDN
>   adoption than another.
>
>Has anyone lobbied one browser manufacturer or another to change their
>policy? Is there another option that is not currently in use which would
>be better?
>
>(Note that "no restrictions" is not an option, given what happened in
>2005 with payp-cyrillic-a-l.com, and I would rather not derail this
>debate by rehearsing those arguments again.)
>
>Gerv
>_______________________________________________
>Idna-update mailing list
>[email-masked]
>http://www.alvestrand.no/mailman/listinfo/idna-update

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Sat, 10 Dec 2011 01:19:48 +0100

I am afraid this debate is among people who read ASCII characters, believe
that Registries have IDNA2003 policies when IDNA2008 default should be OK
for all and is the rule for 3rd level DNs, confuse the TCP/IP international
network with the Internet, and think that ICANN and GAC have something to
do with the digital ecosystem technology.

There is only one thing which is demanded by users : WITISWISISWIS and no
application interference. Otherwise it means that every application and
each application version will result in its own internet.

Now, if browsers manufacturers want to support additional optional service
pluggins with A,B,C,.... Y,Z strategies this is very nice of them: they
write an RFC describing their protocosl and make their complete support
optional.

1. Browsers MUST support any IDN made of any IDNA2008 permitted character,
whatever the TLD, etc. etc.
2. Right clicking on an URL should allow users to see its punycode
equivalent.

PORTZAMPARC

---

From: "J-F C. Morfin" <[email-masked]>
Date: Sun, 11 Dec 2011 03:06:16 +0100

>At 17:35 10/12/2011, Patrik Fältström wrote:
>Let me emphasize that what John writes here is extremely important. 
>If you have the slightest opinion of what "confusing" implies, and 
>what implications approval of "too similar" TLDs might have, 
>specifically cross scripts, you should let ICANN know.
>Now.
>I do explicitly also sign this email as the chair of SSAC. That is 
>not a mistake.
>Patrik Fältström
>Chair ICANN Security and Stability Committee

>At 17:48 10/12/2011, Cary Karp wrote:
>The advisory group for ICANN's Variant Issues Project will be holding
>its wrap-up meeting in Marina del Rey on Monday and Tuesday The issues
>report it is focusing on will finalized in short order thereafter. At
>least three of the people on the idna-update list will be in MdR so
>anything said on it can also be channeled into the VIP discussion.
>
>The "now" that paf mentions really is NOW.
>/Cary

At 16:28 10/12/2011, John C Klensin wrote:
>As to how realistic that assumption is, you might consider:
>
>(1) ICANN's Board apparently (minutes have not yet been posted)
>passed a resolution on Thursday exempting IDN variations on .EU
>from review for visual spoofing and other forms of
>confusability.

Dear John,

ICANN has nothing to do with the Internet *technology* that the IETF
is meant to positively influence (RFC 3935) and that Gervase has
questions about on behalf of Firefox.

The IAB has.

ICANN claims benefits from a limited set of TLDs in class IN, outside
of private networks, outside of IUsers interests, and outside of
non-Internet digital technologies that want to use/already use the
digital naming system and its root names (e.g.: .gsm, the Chinese TLDs
and keywords, etc.). The area of use of browsers (and probable forked
browsers, if open source ones become IUsers-foreign) is much larger.

IMHO, the last thing we need, hence my slowdown for more than one
year, is an inadvertent browser war, or Internet use confusion, over
IDNA. This is why, as IUsers, we certainly are interested in
presentation-layer-related-services being offered by browser
manufacturers, as long as they are RFC documented and we can turn them
up/down at our own will.

The way I understand the problem is that the ball has been in your IAB
field for more than one year after my appeal and the IESG/IAB have
clarified that my area of concerns did affect, but did not belong to,
the IETF scope. The IAB was (this is how I understood its road map) to
decide how IDN/IDNA SHOULD be used in the Internet technology context.
We did not move on this because I had hoped that we could maintain the
IDNA2008 consensus and permit the IAB to move faster in not
interfering. However, it turns out that I was wrong because the
blocking reality questioned by you, me, Lisa, etc. remains: the
IDNA2003/stringprep application-to-application architectural scheme
does not scale to IDNA2008.

We all have also known for years that this issue is to be addressed
prior to January 12, 2012.

The only viable architectural solution that I can figure out, but I
could also be totally wrong, is subsidiarity at the IUI (intelligent
use interface) on a fringe to fringe basis. The implications on many
other diversity related items should have been discussed, over the
course of the last two years, if some interests (IAB, IETF, ICANN,
IGF, GAC, Unicode, Google, etc.) wanted to keep the transition under
joint control. Since nothing has been discussed and, therefore,
prepared and tested, we are heading towards an entirely new internet
(IDv6 addressing, shared virtual unique root file, IDNgTLDs shambles,
IANA revamp, etc.) without any idea of the way we want to manage it
together, or even if we want to manage it together.

If the IAB wants to document its IAB chosen architecture for this new
internet, it has exactly one month left to be clear about a framework.
Then, practical experimentation will have to start prior to the first
ICANN IDNgTLD being officially accepted. Otherwise, it will not be
innovation towards a better internet for all. It will be a long-term
costly competition (global fight) between an obsolete use, a
commercial+ use and an emerging efficient use of the Internet.

I am going to document an IUse position that is to be I_Ded on January
10 if the IAB does not commit beforehand to a position that IUsers can
consensually support. I have no objection to discussing my memo while
I am preparing it (on the [email-masked] mailing list: as you know, I
cannot discuss it on the [email-masked] mailing list).

However, please let seriously discuss only network architecture and
stop cosmetic layer violation confusions.

At 02:02 11/12/2011, Paul Hoffman wrote:
>[the response to the users] needs to come from a stable, trusted body.
>I question whether such a body who is willing to make a table exists.

Until now I thought that such a competent body was the IAB.

This "really NOW" I will know if I was right.

Best

jfc

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Sun, 11 Dec 2011 03:31:28 +0100

I just put this mail on line at http://iucg.org/wiki/IAB!_NOW!
This initiate the IUsers Group work on the discussed I_D.

Portzamparc

2011/12/11 J-F C. Morfin <[email-masked]>

>> Let me emphasize that what John writes here is extremely important. If
>> you have the slightest opinion of what "confusing" implies, and what
>> implications approval of "too similar" TLDs might have, specifically cross
>> scripts, you should let ICANN know.
>> Now.
>> I do explicitly also sign this email as the chair of SSAC. That is not a
>> mistake.
>> Patrik Fältström
> presentation-layer-related-**services being offered by browser
> ______________________________**_________________
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/iucg<https://www.ietf.org/mailman/listinfo/iucg>
>

---

From: JFC Morfin <[email-masked]>
Date: Tue, 13 Dec 2011 04:17:42 +0100

I am responding to Vint and Martin in the same mail because the
response proceeds from the same idea. Gervase is outside of the IETF
scope: why and hence what is the border of that scope and its implications.

IESG and IAB have clearly explained that the points discussed by my
2010 appeals were outside of their scope. This is why the BoF that
they proposed for me to engage was inappropriate. This is also why I
relied on the IAB roadmap for them to sort out their own definition of
the upper-border of their area. I needed before I would engage in the
documentation of the scope of the communication stratum above, what I
call the semiotic and the semantic layers of the Intersem extending
the OSI communication model to intercomprehension.

At 08:38 12/12/2011, Vint Cerf wrote:
>as ugly as it might be, I wonder whether showing both UNICODE and
>PUNYCODE expressions would be useful? By itself, this might not reveal
>a spoof unless one had bookmarked domain names against which to
>compare, of course. If the viewer does not have an appropriate
>font/script, of course, then only the PUNYCODE is displayable to any
>useful effect. Again, one would need reference points to detect a
>spoof.

Vint,

In "IUser" the "I" stands for many things: IETF, International,
Intelligent, Intertechnology, Internet+, etc. and "lead" (as in "lead
user"), but *not* for the Internet as such (and absolutely not for
ICANN), because it may not be the only infrastructural system
(infrasystem) being used to support their relational space.

Gervase's concerns are "located" outside the Internet, at a layer
where human brains (people) and end-applications (process) belong and
relate through his smart window (browser). His context is, therefore,
the bridge of the person's "cybship" (i.e. the personal digital
continuity that he/she builds and governs, where he/she is
authoritative in the way that he/she uses it and interconnects it to
establish and maintain his/her relations.

-  At the hardware stratum, the cybship will be made of clouds,
servers, PCs, laptops, tablets, mobiles, telemates, appliances,
nanoimplants, browthers, etc. with ultimately at the core and  in
central remote control.  his/her own neurons.

-  At the software stratum, everything may be either binary or
localized. This is the IETF stratum.

-  At the brainware stratum, English may not be the language, may
not be understood and may not be even readable. This means that one
has to accept that ASCII may not belong to personal environments and
that punycode strings may be as foreign to users as ASCII domain
names. This is "above the IETF stratum", IAB/IESG said it is research.
As a consequence, how the IETF stratum is to better support that
"above" is IETF research.

This is why we have to scale from "internationalization", as in Mark
Davis' "globalization", (i.e. quoting localized non-English texts into
International English), to "multilingualisation", i.e. to use Mark's
terms, in localizing internationalization.

Multilingualisation then has to be understood as the cybernetics of
the linguistic diversity, where English is to be accepted as one of
the 22,500 technically strictly equal linguistic entities and Latin
charset as one of 100 technically strictly equal charsets. English and
ASCII may be absent from the user's device. What Gervase asks for is
how his smart windows should display this multilingualisation as far
as IDNs are involved.

OSI wise, the response is with the Internet multilingual layer number
seven service, not with the internationalized internet, which is a way
to name a part of the Internet number six presentation layer. IDNA2008
documents the Internet layer six and the subsidiary support of its
corresponding level seven services on the user side.

At 08:10 12/12/2011, Martin J. DÃ¼rst wrote:
>I very much think it is correct. From their very timid start with
>IDNs, ICANN has a strong and confusing tendency to cast issues in
>terms of "language" even if they are script issues. That has
>influenced the surroundings, too.

Martin,

We (IETF) have shared that confusion, e.g. the way we initially
approached langtags, and the fuss that I had to create to obtain a non
destructive langtag RFC set. I acknowledge that there was an effort to
progressively teach the IETF people (not externally) that the language
layer was not appropriate. This led to John Klensin's (quite briefly
at first) conclusion that scripting was the upper concern of the IETF
and that languages were outside of the IETF scope.

This was a great technical clarification progress. However, this did
not free the IETF from Unicode. To the contrary, it gave the illusion
to the IETF that its technical upper border was the same as the
Unicode one (so Unicode and IETF could be bound together).

This is incorrect on at least three points that both IUse and ICANN
had to live with:

a. Unicode version changes that might result from cultural change or
deeper Unicode knowledge.

b. Mapping, an issue that IDNA2008 was set to get rid of and achieved,
but that left unanswered issues and as a result some Unicode
legitimate objections.

c. Lack of orthotypographical (scripting syntax) considerations.

The solutions:

1. Patrik came up with a solution to (a). It seems to be stable enough.

2. Paul and Pete came up with a perspective that permitted a consensus
on (b). However only described by way of an example, the introduced
general solution is subsidiarity: persons do locally what they
authoritatively want as long as their fringe to fringe Internet+
solution respects the end to end Internet requirements.

This calls for an IUI to support a fringe2fringe IUse of the Internet,
i.e. an Internet+ architecture. Limited/initial phase IUI examples are:

o  the Google+ architecture (that we implemented in the Tymnet
technology as the "menuserver" 25 years ago).

o  browsers in the HTTP area. Since there are five major browser
manufacturers, Gervase requests quidance for one of them, and if
possible concertation for them all.

3. The solution to (c) is more complex. It is approached by ICANN as
"variant support". It calls for metadata to be previously known or for
them to be transmitted in parallel. The paradigmatic (typical example)
need is the support of the "majuscule" metadata. This clearly shows
the different responsibility grades between the Unicode, IETF, and IUse areas.

o  if I am correct, Unicode wished to remove the capacity for its
codes to escape to metadata. I think this is correct, and clearly
identifies their character oriented plane, where Unicode/ISO 10646 are
free to correlate with other encodings.

o  the IETF refused to consider orthotypography. I first opposed that
disinterest but I must acknowledge that if this disinterest leaves
only one solution, it seems architecturally the best one: to include
that respective support as a transparently added feature of punycode.
What I call punyplus.

Punycode/Punyplus is, therefore, within the IETF scope. This clearly
shows that it is not a matter for applications and browsers.

The same, anti-phishing and logo/symbol support are not IETF or
Unicode issues but rather IUse issues, through possibly an
anti-phishing algorithm on top of Unicode.

At 07:54 12/12/2011, Martin J. DÃ¼rst wrote:
>Yes indeed. The browser vendors overreacted on issues such as
>script-mixing, stuff that the user isn't able to read, and so on,
>because overreacting was easier than a more careful reaction, and they
>were able to say that they did something.

I am afraid that they do not overreact, but rather react to a lack of
the IETF, which was the reason for my appeals. The IDNA RFC set should
have included an IAB disclaimer (as the one they spelled out in their
response) warning that, IDNA2008 made the IETF/Internet community
trespass its own top border, that RFC 5895 was a cross border
involvement (RFC 5895), and how/where to discuss the cross and over
border issues.

>But they didn't do much for in-script attacks, because that's much
>more difficult. (Not that I'm advocating a browser that shows
>MlCR0S0FT.com with punycode.)

Correct, but this is not "they" as in "browser vendors" (actually
"manufacturers") but as in IUsers. Therefore, this is my fault because
I am advocating the IUTF (Intelligent Use Task Force) to emerge and
take over responsibility. Russ Housley carried the IETF role correctly
in creating the [email-masked] mailing list, allowing the emerging IUse
community to liaise with the IETF. However, it has low traffic, not
only because Jefsey the Troll is facilitating it, because it is young,
but also because:

o   the IUse working methods, purpose, deliverables/confusables, and
people dedication are not to be the same as the IETF, in the same way
as ITU methods are not those of the IETF.

o   and mostly because we still have to discover them (and this is
really a very deep discovery process if we want to reach consistency
with world simplicity (RFC 3439) and human noetics (semantic
intercomprehension process.

The only thing I know is that the emerging IUTF will be a place for
browser manufacturers and other W3C web applications plane interests,
but, by far, not only for them.

This is because they are "only" involved in a part of the HTTP
protocol fall outs. The Internet is about TCP/IP: there are other
technologies, and people (as the ultimate target) are interested (cf.
above) in semantic intercomprehension. As an SDO, we are interested in
facilitating that intercomprehension through relational digital tools.

The point here is to understand how to better facilitate it through
the IETF environment stratum (this is actually "making the Internet
work better") in cooperation or not with the fringe to fringe IUI
layers. We see the need confirmed by what we did not specify and what
Gervase requests. We acknowledged its structural existence through the
RFC 5895. However,

o   we have not yet accepted its implications on the IDNA and the
whole Internet architecture.

o   therefore, we did not work and complete yet a list of its
requirements from an Internet point of view (IAB roadmap).

o   and as a result, we did not motivate ICANN and others to seriously
consider all the resulting consequences;

This is why I stated that I will try to complete an IUI Internet
conformant framework description before:

o   ICANN economically and politically settles the technical confusion.

o   in being paid to accept studying requests of IDNgTLDs that it has
absolutely no technical capacity, legal right and, therefore,
political legitimacy to discuss and contract.

Most will certainly dispute my description but my hope is that this
will engage the debate that Lisa Dussault wanted, but which was not in
our charter. My targetsare:

  o   the completion of the first post-IDNA2008 phase (what I called
IDNA2010, i.e. how to use IDNA2008 on the user side) that we need to
achieve before

  o   engaging in the second phase (what I called IDNA2012 - I was
optimistic! - i.e. the way we adapt the Internet stratum to fully
support IDNA2010 [punyplus, IANA, PRECIS, RFC 3935bis, langtags, net
centricity documentation, externets, IP/ID/GRIDv6 consequences,
general lessons on Internet+ architecture, etc.])

  o   while the IUTF (starting through the [email-masked] liaison) will
consider the resulting needs and opportunities (ML-DNS, anti-phishing
algorithm, cybship operance, semiotic implications, distributed root
and IANA, etc.)

  (NB. I know that I use terms that are new for some: they will be
explained in the iucg-internet-plus I_D).

  jfc

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Tue, 13 Dec 2011 12:25:48 +0100

2011/12/13 Gervase Markham <[email-masked]>

>
> We are certainly open to proposals D, E, F and beyond. (Although due to
> the way Mozilla works, I can't promise an implementation timescale!)
>

Users only expect every browser to do its browser job and to possibly
provide a choice among the 0, A, B, C, ... X, Y, Z protection technically
and commercially competitive options. Please remember that ICANN and IETF
are to foster competition in these areas in the best public interest.

Disregarding the 0 protection option is therefore a marketing choice. My
opinion is that it will lead many, if not most to use another browser
offering that option.

Portzamparc

---

From: JFC Morfin <[email-masked]>
Date: Wed, 14 Dec 2011 01:56:05 +0100

At 07:44 13/12/2011, Patrik Fältström wrote:
>ICANN only police the TLD, no other levels in the domain name tree.

Uncorrect. ICANN only try to police the minority of NTIA root TLD 
managers who contracted with them. IETF is for everyone who use TCP/IP.

Anyway, all this debate looks like the IETF people being reasonable 
but trying evading responsibility by hiding behind ICANN? Let 
clarify: Vint attempted to transfer responsbility of the 
post-IDNA2008 work to ICANN. However:

- ICANN has not taken the bait.
- Lisa's architectural questions belong to the IETF scope and have to 
be addressed first.
- ICANN, as everyone else, has no capacity to speak on behalf of all 
the Internet Users.

Gervase was correct in soughting opinions. No one has legitimate 
authority nor practical capacity to decide for the whole existing and 
future internet community. The only thing which can be done is for 
some to document what they suggest (IAB), what they think (this 
thread), or what they intend to do or already did.

Pragmatically, since IAB did not wish to provide guidance and 
opinions are divided, what will actually forge the future are those 
who specify, develop, test and deploy. They are authoritative for the 
community of those adhering to their postulates or locked in their 
"+" services. This is traditionally called in IETF jargon a market 
decision. It should traditionnally be made under IETF influence (RFC 
3935) for the Internet to work better. However, this thread shows 
that a RFC 3935bis is first needed to document what "work better" 
means today. This is what browser manufacturers, as many others, try 
to be told, in order to build a "better internet" window in the http 
web application context.

jfc

---

From: "J-F C. Morfin" <[email-masked]>
Date: Mon, 19 Dec 2011 15:16:06 +0100

At 11:42 19/12/2011, Gervase Markham wrote:
>Hi Raed,
>Thank you for your input.
>
>I would say that the vendor you quote is using sloppy language and it's
>not actually about 'prioritizing English', but your point about
>first-class citizenship is a good one.

No one is prioritizing English. English IS, by mutual convenience, 
the Internet language (cf. RFC 3935).

This is why the IETF solution is "internationalization" and not 
"multilingualization". Internationalization is a component of 
"globalization" together with "localization" and "langtags" and is 
embodied in CLDR tools. Internationlization is to make the medium 
(here the Internet) language neutral. For that it uses an 
International English and ASCII programming to quote Unicoded strings 
independently from the actual language these strings correspond to 
(identfied by the langtag), including English. These quotes are of 
two forms: the real text, i.e. a batch of code points, or an URL that 
permit an option indirect access. For good consustency (RFC 1958) the 
quotes should use the same script displaying context (UTF-8).

IDNA2008 has organized this to properly work through:

- an Internet technology core,
- and a subsidiary support of languages at the periphery.

In this architecture it happens that the Internet architectural core 
happens to currently work in ASCII, but it could work the same in any 
other charset, including binary.(what may be the evolution of the 
Internet 2.0 architecture).

IDNA2008 however has left two unaddressed issues.

1. to be broadly explained as being an example of the way the end to 
end Internet architecture actually (RFC 1958) supports diversity, any 
diversity. This support is at the intelligent fringe to fringe layer 
set which includes the presentation layer.

The difficulty is that OSI was wrong: the OSI model in uncomplete and 
the layer pile must dissociate Network and Subsidiary Network Use 
layers. I appealed against the lack of a IAB/IESG disclaimer which 
would have prevented the current debate. The response I obtained 
clearly indicated that this issue did not belong to the IETF scope, 
but that IETF wanted to detail its own needs in this area. This is 
why I delayed as much as I could the description of the fringe to 
fringe IUI framework. However, the technically illegitimate ICANN 
opening to gTLD registration calls for it to be published before January 10.

2. fringe to fringe calls for metadata exchanges: IDNA2008 has not 
considered the need to support orthotypography (i.e. script use 
variations depending on the meaning). Basically what you say about 
second-zone languages also applies to real life English which 
actually needs more than the ASCII charset, and obviously to French 
as I reported it to the IESG. The management of the fringe to fringe 
metadata intercommunications is more complex than the data 
intercommunications. It calls for a dedicated channel that has to be 
transparent to the existing core technology and common usage. What 
Gervase asks for is to be told how this is to work.

>If all registries were are responsible as yours, there would hardly be a
>need for browser restrictions on IDN display at all (perhaps just a
>blacklist of homographs for "." and "/", and that should have been
>achieved by IDNA2008 anyway).

This "registries being responsible" is an wrong interference where we 
technicians are judging use, instead of supporting it properly.  The 
principle of the Internet is that technology is to best support the 
user needs and the IETF is to influence those who design, use and 
manage the Internet for it to work better. The problem are (1) that 
no one ever explained what working "better" means and (2) that some 
of us want to unilaterally constrain uses along with their own 
understanding of that "better" means, moreover in areas where things 
have not been fully defined.

> > IDNs should not be treated as second-class citizens on the Internet.
>
>I entirely agree. This is why we went for option B - once a registry has
>a responsible policy, their IDNs are treated as first-class citizens
>everywhere (at least, in Firefox). No additional configuration required.

This means that you decide who is a second-zone Registry and treat 
their registrants as third-zone netizens. Then the question 
unfortunately comes: "Who made you king to decide this?"

>Unfortunately, IDNs are still not treated as first-class citizens. So
>the question is: how do we get from where we are now to a situation
>where they are treated that way?

This is easy as far as you are concerned.

- you treat them as your user application layer is to treat them: as 
unique-class Internet Domain Name citizens.
- you demand those who are to take care of the difficulties you 
identify to address them properly. They are the IAB and the emerging 
IUTF (on the [email-masked]) where this mailing thread belongs since 
the WG/IDNAbis is closed, its RFC set is published, and the remaining 
points are on the IDNA2008 use side.

Cheers.

jfc

---

From: "J-F C. Morfin" <[email-masked]>
Date: Wed, 21 Dec 2011 16:29:39 +0100

At 11:58 21/12/2011, Gervase Markham wrote:
>As I understand it, these sites are merely records of policy; no
>restrictions are imposed. So if .newtld decided to register with IANA to
>say "we accept every character", then the tables would duly record that
>fact, despite there being a big potential problem.
>
>So, unless I have missed something, such lists are of no help in this
>situation.

Gervase,

please let stay within the RFC framework.

The DNS is built to accept every byte. IDNA2008 accept RFC 5892 UTF-8
characters. Internet DNS practice favors ASCII only. This is the
universal policy by default. Every zone manager may restrict its
registrations policy and universally publish it (TLDs) or not (other
zone managers). Your request is to know when a domain name entered by
a user conforms or not with this registration policy, so you may
practice your own policy to be defined.

1. there is as yet no protocol for TLD to disseminate that information
between them and application designers.

2. You may engage into a BoF to show that such a protocol is necessary
for the Internet to work better and propose an IETF WG Charter.

3. personnally I think that such a protocol belongs to the whole
digital ecosystem area and is to be discussed and possibly
standardised outside of the sole IETF. Its discussions calls for the
preliminary emergence of its requirement out of experimentation. Such
an Internet+ community experimentation has been engaged through the
files documented by Abdulrahman, ICANN work on variants, and works
engaged within the IUse community within the so called "IDNA2012"
framework (the so called IDNA2010 being the issues on the user side).

jfc

---

From: "J-F C. Morfin" <[email-masked]>
Date: Sun, 25 Dec 2011 02:37:15 +0100

At 06:47 24/12/2011, Abdulrahman I. ALGhadir wrote:
>I guess you have missed something.
>The second link was broken I didn't copy it correctly and I think 
>that you haven't check it, have you?
>
>http://www.icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm
>
>When you want to register an IDN you should define the script and 
>the language which your label will follow.
>
>http://www.icann.org/en/topics/idn/fast-track/idn-cctld-implementation-plan-15dec11-en.pdf 
>(check 3.2)
>http://www.icann.org/en/topics/new-gtlds/rfp-clean-19sep11-en.pdf 
>(check 1.3.1)
>
>As you see it is part from ICANN application process and it is a 
>must and I think this will help us in having a solid resource which 
>can provide us with needed information?

Dear Abdulrahman,

the only documents that should be considered by Gervase:

- MUST be RFCs (i.e. RFC 5890-5895) in particular RFC 5895 which 
gives him an example.
- SHOULD be IANA files.
- MAY be ICANN files as examples of what a money centric network 
community may want to do (NB culturally or people centric network 
community or coporate private networks might want to do differently).

Best
jfc