Subject: [iucg] IDNA2008 context

From: JFC Morfin <[email-masked]>
Date: Wed, 06 Jan 2010 10:57:20 +0100

Dear IESG Members,

I understand that there is an IESG conference call on Jan 7 that may 
discuss IDNA. I had hoped that I could publish a general framework 
I_D prior to that date on the practical evolution of Internet usage, 
in turn covering IDNA as a working example. A family emergency has 
delayed that work by a few days.  This mail is expressed within an 
IDNA perspective. FYI, I chair Project.FRA for a French speaking netspace.

IDNA has been specified as permitting a support of IDNs without any 
DNS change. I identify five layers in these proceedings, which are:

1. the internet layer
2. the IDNA interface protocol
3. the user implementation of this protocol
4. the impact on the network naming topology
5. the technical and political interinfluence of the resulting changes.

1. The Internet layer:

The internet is to provide regular Internet transport, network, and 
DNS LDH resolution services. This is to remain unaffected. This has 
been respected thus far.

2. The IDNA interface protocol:

This was controverted between Unicode, the IETF culture, and us. 
Moreover, the proper support of French is turning out to be the most 
complex issue due to the use of the same Roman charset as English, 
while the French key concept of "majuscules" is absent in English and 
Unicode. The success of IDNA2008 is to have reached a workable 
consensus between these three positions (however proper French [Latin 
languages] orthotypography obliges ".FRA" to find an additional way 
to support them). We designate IDNA2010 a BCP Draft project that 
would document the various ways IDNA2008 is/can be implemented by 
Zone Managers. For the time being, the related [email-masked] 
mailing list is only for the informational purposes of its respective 
members. Active debate will only be started in coordination with the 
WG/IDNABIS Chair, so that there is no confusion. To date, there are 
people of various origins on the list, but none from ICANN.

3. The user implementation of this protocol

In suppressing Nameprep, IDNA2008 means progress in flexibility. 
However, this flexibility may lead different applications on the same 
machine to resolve the same IDN to different IP addresses. This means 
that there is not only a problem of transition, but also a problem in 
the architecture of the user's machine in order to address this risk. 
As initially indicated, I had planned to address this need in full 
compatibility with IDNA2008 via the ML-DNS approach (cf. infra) I 
announced, as soon as IDNA2008 would be approved by the IESG. Lisa 
Dussault preferred raising the question once IDNA2008 was completed 
but still not yet approved. This provides you with full control over 
the decision, but you now need to know the resulting upward and 
downward contexts better.

The simplest and most rewarding solution is an "IDNApplication" that:

1. respects the IDNA architectural principle of U-Labels that are to 
be dealt with at the user application layer.

2. intercepts all the domain name entries

3. transcodes them before sending them to the DNS in:

--- leaving ASCII domain names unchanged.
--- differentiating the few TLDs supporting IDNA2003 in order to 
address them specifically.
--- respecting IDNA2008 otherwise.

In this way all applications and protocols will be provided 
transparently with the same adequately formatted labels. In addition, 
IDNA2003 transition schemes will be possible at dates that are 
decides by each of the concerned TLD Managers.

The fastest and easiest ways to deploy this IDNApplication are either:

- to use an OPES like front-end to existing nameservers (work on this 
was foreseen but not completed by the WG/OPES)

- or to embed the support of punycode (or rather, "punyplus" 
(<http://tools.ietf.org/html/draft-iucg-punyplus-03.txt>http://tools.ietf.org/html/draft-iucg-punyplus-03.txt) 
within new various nameservers releases.

4. The impact on the network naming topology

There are three quick (and, therefore, stabilizing) large scale and 
easy to disseminate deployment strategies:

- ISP "patching", as is currently and similarly done for Chinese 
Domain and Key Names.

- public DNS services, such as Google's PDNS proposition that may 
help enforce that type of service immediately on a large scale.

- implementation of non-external-caching DNS servers at the user's machine.

4.1. Impact on the virtual root file

This happens while a demand for many more IDNg/ccTLDs than ICANN is 
prepared to accept in their Root file. In addition, ICANN in Seoul 
has strategically and commercially favored some non-Roman IDNccTLDs 
that will enter the NTIA root file through the "Fast Track" 
experiment; private, civil, and government IDNgTLDs projects that 
were previously incitatedto be planned and to apply ed will probably 
be delayed for several years.

The solution for these rebuked TLDs candidates (like .FRA) is very 
simple: to be declared as ULDs at the user's nameservers (for 
improved clarity, we call "user level domain"the top level or New.Net 
style domains that are declared byusers). This means, in other words, 
local root files with all the TLDs and ULDs that each user needs. At 
a PDNS, this will call for the support of all of them. All of this 
amounts to acknowledging the need to manage the virtual root file 
that has already been in use for years (cf. the way Chinese TLDs are 
declared in top level nameservers).

4.2. Impact on the Internet usage architecture

As indicated, the user innovative project (.FRA) introduced by 
france@large, together with the IUCG early @large participants, 
committed to document an IDNA2008 extension called ML-DNS 
(multi-layer). ML-DNS is part of an Internet Usage architectural 
framework that is able to provide a comprehensive and robust basis to 
the semiotic strata (Intersem) of which .FRA is interested in order 
to support intercomprehension facilitation (Internet of the Users and 
of their thoughts).

Its principles are:

(1) the strict equivalence (synonymy) of a domain name pile ranging 
from the UDN (user domain name) to the IDN (Internet Domain Name as 
documented by IDNA2008)

(2) a generalized extended value IDNA consistent syntax (our 
rationale is that languages are supported through the presentation 
layer. If IDNA works, it means that it uses the Internet presentation 
layer, i.e. in this specific case, the "xn--" presentation).

Our .FRA (as many other TLD projects including the Multilinc set of 
one sociolinguistic per ISO 639-6/LS 640 linguistic entity) requirements are:

- French (Latin languages) majuscules support (and other similar 
particularities in other scripts),
- extension of the Internet passive content support to ambient and 
active contents,
- complete access to presentations and classes,
- a "commuting cloud" network service open capacity,
- Unicode TR46 considerations
- etc.

All of this is embodied through the "Interplus" (internet plus 
plugged layers on the user side), which does not change a single 
Internet bit and conceptually adds on the user side:

- two real layers:

-- an interapplication communications overlay.

-- and a pseudo-network service area. Its general purpose is to 
support network extended services that users may easily "interplug" 
for an optional "smart network" experience. Software slots may 
support services such as:

---- ML-DNS nameserver
---- an Application Firewall
---- Virus protection, social network, Intersem metastructural 
distributed referential services (MDRS)

- the virtual presentation layer (managed by the ML-DNS along 
the  the "xx--" format, with the "x--" format that is being used for 
a "Netix" interapplication command set).

5. The technical and political interinfluence of the resulting changes

ICANN has imposed pressure on the IDNA text finalization in order to 
match the Seoul date. This led to some transition confusion (now 
sorted out) between the WG/IDNABIS and the [email-masked] 
mailing list. Then, the ICANN Seoul announcements were both perceived 
as an ICANN opposition to the open deployment of IDNA and as a 
technically premature move, since Fast Track is more of a legal work 
than a technical test, and there has been no consideration as of yet 
of IDNA2008 practical implementation and usage issues.

ICANN participants in WG/IDNABIS either did not perceive the stakes 
or were not entitled to comment. They did not answer the various 
questions that we raised regarding their position(s) on IDNA2008 and ULDs.

As a result, we may have:

(1) four different works on the way in order to implement IDNA2008:

- ICANN Guidelines supporting closed committees representing approx. 
120 second level zone managers among millions.

- IUCG [email-masked] open mailing list, targeting an 
informational BCP for concerted and interoperable implementations of IDNA2008

- some major Public DNS services unilateral policies

- idem for some national deployments.

(2) confusion over the namespace, with ULDs popping up here and there 
without any coordination. Local root dissemination means a 
heterarchic naming structure. This was foreseen in the ICANN ICP-3 
document, but we are the only ones to have run a community test-bed 
as requested by ICANN. If we want to keep the DNS namespace stable, 
we need some virtual root cooperative management through an IDNAlliance.

We also have to take into account that:

- class usage is off-the-shelves of any IDNApplication solution

- I only describe the simplest thing that I am to deploy as the 
Project.FRA Chair in order to get the .FRA namespace operational, at 
NO change whatsoever except for the loading of a slightly enhanced 
version of Bind on the participating machines. Everyone else can do 
the same, and many other TLD project may wish and have better funding 
to do it. There is NO change in any way. This is simply a normal 
reading of the RFCs from an IDNA2008 point of view. The Internet 
legacy turns out being still more powerfull than expected.

6. Suggestion

The decision is yours. You can either approve or delay IDNA2008 and 
request more information.

- IMHO, if you do not approve IDNA2008, which is certainly excellent 
work, you will cast suspicion on the entire IDNA scheme, as ICANN 
will have to delay Fast Track due to an IESG decision. Furthermore, 
this would delay what needs to be built over IDNA2008. During that 
time, people would certainly start building it up over IDNA2003, 
thereby initiating a terrible mess.

- this is why we have started building a technical position against 
IDNA2008 under the terms imposed by ICANN's urgency (lack of 
consideration of the abovementioned points). If you approve IDNA (as 
you technically should), I will appeal against your decision (I fully 
approve) due to its non considered specific context. I will upset 
many. However, my expectation is that it would provide many more 
people with a four to six month respite in order to better organize 
and work out an IDNA2010 BCP proposition or start a WG/VIRTUALROOT, 
in turn preventing the current 500 ICANN TLD candidates (and probably 
many more) from deploying as uncoordinated and most probably 
conflicting ULDs. In this case, some will initiate lawsuits against 
others (this has already started): this will result in an unknown US 
jurisprudence on TLD and ULD attribution that, by essence, no ULD 
will respect outside the USA.

---

From: JFC Morfin <[email-masked]>
Date: Thu, 07 Jan 2010 21:42:26 +0100

At 20:16 07/01/2010, Russ Housley wrote:
>JFC:
>
>Thanks for you IETF Last Call comments.  Your comments stimulated a 
>significant amount of discussion of the documents from the IDNAbis 
>WG. The IESG approved the documents that you are most concerned with 
>on their telechat today.  The announcement of this action will come 
>out next week.
>
>I think it is important to point out that some of your suggestions 
>are beyond the scope of the IDNAbis WG charter, and in fact, some of 
>them are research.
>
>Best regards,
>   Russ

Dear Russ,
thank you for telling me. This means that now we can work on IDNA2008 
as the Internet PLUS stable core building block, fully protecting the LDH DNS.

I fully agree that some of my points are beyond the scope of the 
IDNAbis Charter: thanks to Vint, John, Patrick, Harald, Pete and Paul 
the Charter has been fully fulfilled. I also fully agree that some 
are research, however, that research is of a new kind: it is not to 
be discussed within the IRTF but to be quickly tested, partly 
deployed, and then competitively validated at Internet User level if 
we do not want an architectural confusion. This is because it has a 
real impact, is at everyone's reach, and needs no change at the 
Internet legacy level.

My target now is to help with a general framework I_D to engage the 
necessary debate and solutions before ICANN's Fast Track becomes too 
much a problem.
Best regards
jfc

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Jan 2010 14:16:48 -0500

JFC:

Thanks for you IETF Last Call comments.  Your comments stimulated a 
significant amount of discussion of the documents from the IDNAbis WG. 
The IESG approved the documents that you are most concerned with on 
their telechat today.  The announcement of this action will come out 
next week.

I think it is important to point out that some of your suggestions are 
beyond the scope of the IDNAbis WG charter, and in fact, some of them 
are research.

Best regards,
   Russ

On 1/6/2010 4:57 AM, JFC Morfin wrote:
> discuss IDNA. I had hoped that I could publish a general framework I_D
> prior to that date on the practical evolution of Internet usage, in turn
> covering IDNA as a working example. A family emergency has delayed that
> work by a few days. This mail is expressed within an IDNA perspective.
> FYI, I chair Project.FRA for a French speaking netspace.
>
> IDNA has been specified as permitting a support of IDNs without any DNS
> change. I identify five layers in these proceedings, which are:
>
> 1. the internet layer
> *1. The Internet layer:
> *The internet is to provide regular Internet transport, network, and DNS
> LDH resolution services. This is to remain unaffected. This has been
> respected thus far.
>
>
> *2. The IDNA interface protocol:
>
> *This was controverted between Unicode, the IETF culture, and us.
> complex issue due to the use of the same Roman charset as English, while
> the French key concept of "majuscules" is absent in English and Unicode.
> The success of IDNA2008 is to have reached a workable consensus between
> these three positions (however proper French [Latin languages]
> orthotypography obliges ".FRA" to find an additional way to support
> them). We designate IDNA2010 a BCP Draft project that would document the
> various ways IDNA2008 is/can be implemented by Zone Managers. For the
> time being, the related [email-masked] mailing list is only for the
> informational purposes of its respective members. Active debate will
> only be started in coordination with the WG/IDNABIS Chair, so that there
> is no confusion. To date, there are people of various origins on the
> list, but none from ICANN.
>
>
> *3. The user implementation of this protocol
>
> *In suppressing Nameprep, IDNA2008 means progress in flexibility.
> the architecture of the user's machine in order to address this risk. As
> initially indicated, I had planned to address this need in full
> Dussault preferred raising the question once IDNA2008 was completed but
> still not yet approved. This provides you with full control over the
> decision, but you now need to know the resulting upward and downward
> contexts better.
>
> 1. respects the IDNA architectural principle of U-Labels that are to be
> dealt with at the user application layer.
>
> --- differentiating the few TLDs supporting IDNA2003 in order to address
> them specifically.
> IDNA2003 transition schemes will be possible at dates that are decides
> by each of the concerned TLD Managers.
>
> - or to embed the support of punycode (or rather, "punyplus" (
> http://tools.ietf.org/html/draft-iucg-punyplus-03.txt) within new
> various nameservers releases.
>
>
> *4. The impact on the network naming topology
>
> *There are three quick (and, therefore, stabilizing) large scale and
> - ISP "patching", as is currently and similarly done for Chinese Domain
> and Key Names.
>
> - public DNS services, such as Google's PDNS proposition that may help
> enforce that type of service immediately on a large scale.
>
> *4.1. Impact on the virtual root file
>
> *This happens while a demand for many more IDNg/ccTLDs than ICANN is
> prepared to accept in their Root file. In addition, ICANN in Seoul has
> strategically and commercially favored some non-Roman IDNccTLDs that
> will enter the NTIA root file through the "Fast Track" experiment;
> private, civil, and government IDNgTLDs projects that were previously
> incitatedto be planned and to apply ed will probably be delayed for
> several years.
>
> simple: to be declared as ULDs at the user's nameservers (for improved
> clarity, we call "user level domain"the top level or New.Net style
> domains that are declared byusers). This means, in other words, local
> root files with all the TLDs and ULDs that each user needs. At a PDNS,
> this will call for the support of all of them. All of this amounts to
> acknowledging the need to manage the virtual root file that has already
> been in use for years (cf. the way Chinese TLDs are declared in top
> level nameservers).
>
> *4.2. Impact on the Internet usage architecture
>
> *As indicated, the user innovative project (.FRA) introduced by
> committed to document an IDNA2008 extension called ML-DNS (multi-layer).
> ML-DNS is part of an Internet Usage architectural framework that is able
> to provide a comprehensive and robust basis to the semiotic strata
> (Intersem) of which .FRA is interested in order to support
> intercomprehension facilitation (Internet of the Users and of their
> thoughts).
>
> Its principles are:
>
> (1) the strict equivalence (synonymy) of a domain name pile ranging from
> the UDN (user domain name) to the IDN (Internet Domain Name as
> documented by IDNA2008)
>
> (2) a generalized extended value IDNA consistent syntax (our rationale
> is that languages are supported through the presentation layer. If IDNA
> works, it means that it uses the Internet presentation layer, i.e. in
> this specific case, the "xn--" presentation).
>
> Our .FRA (as many other TLD projects including the Multilinc set of one
> sociolinguistic per ISO 639-6/LS 640 linguistic entity) requirements are:
>
> All of this is embodied through the "Interplus" (internet plus plugged
> layers on the user side), which does not change a single Internet bit
> and conceptually adds on the user side:
>
> - two real layers:
>
> -- and a pseudo-network service area. Its general purpose is to support
> network extended services that users may easily "interplug" for an
> optional "smart network" experience. Software slots may support services
> such as:
>
> ---- ML-DNS nameserver
> - the virtual presentation layer (managed by the ML-DNS along the the
> "xx--" format, with the "x--" format that is being used for a "Netix"
> interapplication command set).
>
>
> *5. The technical and political interinfluence of the resulting changes
>
> *ICANN has imposed pressure on the IDNA text finalization in order to
> match the Seoul date. This led to some transition confusion (now sorted
> out) between the WG/IDNABIS and the [email-masked] mailing list.
> Then, the ICANN Seoul announcements were both perceived as an ICANN
> opposition to the open deployment of IDNA and as a technically premature
> move, since Fast Track is more of a legal work than a technical test,
> and there has been no consideration as of yet of IDNA2008 practical
> implementation and usage issues.
>
> ICANN participants in WG/IDNABIS either did not perceive the stakes or
> were not entitled to comment. They did not answer the various questions
> that we raised regarding their position(s) on IDNA2008 and ULDs.
>
> - ICANN Guidelines supporting closed committees representing approx. 120
> second level zone managers among millions.
>
> - IUCG [email-masked] open mailing list, targeting an informational
> BCP for concerted and interoperable implementations of IDNA2008
>
> without any coordination. Local root dissemination means a heterarchic
> naming structure. This was foreseen in the ICANN ICP-3 document, but we
> are the only ones to have run a community test-bed as requested by
> ICANN. If we want to keep the DNS namespace stable, we need some virtual
> root cooperative management through an IDNAlliance.
>
> Project.FRA Chair in order to get the .FRA namespace operational, at NO
> change whatsoever except for the loading of a slightly enhanced version
> of Bind on the participating machines. Everyone else can do the same,
> and many other TLD project may wish and have better funding to do it.
> There is NO change in any way. This is simply a normal reading of the
> RFCs from an IDNA2008 point of view. The Internet legacy turns out being
> still more powerfull than expected.
>
>
> *6. Suggestion
>
> *The decision is yours. You can either approve or delay IDNA2008 and
> work, you will cast suspicion on the entire IDNA scheme, as ICANN will
> have to delay Fast Track due to an IESG decision. Furthermore, this
> would delay what needs to be built over IDNA2008. During that time,
> people would certainly start building it up over IDNA2003, thereby
> initiating a terrible mess.
>
> consideration of the abovementioned points). If you approve IDNA (as you
> technically should), I will appeal against your decision (I fully
> approve) due to its non considered specific context. I will upset many.
> However, my expectation is that it would provide many more people with a
> four to six month respite in order to better organize and work out an
> IDNA2010 BCP proposition or start a WG/VIRTUALROOT, in turn preventing
> the current 500 ICANN TLD candidates (and probably many more) from
> deploying as uncoordinated and most probably conflicting ULDs. In this
> case, some will initiate lawsuits against others (this has already
> started): this will result in an unknown US jurisprudence on TLD and ULD
> attribution that, by essence, no ULD will respect outside the USA.
>
>
>