referencing IDNA2008 (and IDNA2003?)

[J-F C. Morfin]

Peter,

what IDNA2008 did was to determine the Internet border with the 
users' area and to build an Internet Iron Curtain on the Internet 
side guaranteeing the independent DNS stability for ever. I was one 
of the most concerned by the location of the future curtains on 
behalf the users' interests and coherence with other technologies. 
Because up to now new diversity was supported by technology internal 
growth and will now have to be supported by external multiplicty.

The concern was over the UTS 36 and RFC 5895 like issues and 
presentation layer, orthotypography, semantic addressing, user side 
architecture coherence, fringe intelligence, multilinguisation, etc. 
related issues: should they be dealt with inside or outside of the 
Curtain. I raised the question from the very onset, asking the Chair 
how he understood the Charter. The response was by both Chairs - of 
the initial WG/IDNA (IDNA2003) and of the WG/IDNABIS (IDNA2008) - 
these issues were mostly outside of the IDNA charter, provided 
IDNA2003 could be accommodated as much as possible.

I then committed to address these issues through a multi-layer 
encapsulation of the DNS on the user side (ML-DNS). This is what I am 
now working on providing an extended Linux/Windows end user solution 
to be first experimented by the Internet Users community. After I 
made (through appeals to the IESG and IAB) made sure that Internet 
network legacy and Internet Use where considered as two different 
standardization areas that currently liaise through the iucg at ietf.org 
mailing list.

The remaining problem was to clarify what "mostly outside of the IDNA 
charter" meant, i.e. to define precisely where was the border. The 
border was eventually consensually agreed at lowercase A-labels. I 
reported the IESG that as promoter of the Project.FRA (Francophone 
space) and of the Intersem (semiotic Internet of thoughts) :

1. I was satisfied with this location, and urged them to approve the 
document set

2. but that it led me to address several key-issues at a "no-mans 
land" between the Iron Curtain and the users.

2.1. One of the typical usage problem was orthotypography, when 
Unicode does not specifically support some metadata necessary to a 
proper semantic presentation like in the case of French majuscules, 
they support in using ASCII uppercases. This will be addressed by the 
ML-DNS and a transparent extension of the punycode algorithm (I 
published a draft to discuss possible solutions)

2.2. One of the typical architectural problem is the IDNA 
(Internationalized domain names in applications) architecture itself 
which permits different user applications to behave differently and 
to resolve different addresses for the same U-label. This point was 
also raised by the AD : it was not specific of IDNA2008 but is one of 
the issues the IAB has on its shopping list (cf. John Klensin Draft 
on IDNA). My solution is that the "no-mans land" becomes part of the 
Internet Use architecture an "Internet Use Interface [IUI]" and among 
many other extended services to diversity and innovation provides an 
unique IDNA (Internet Domain Name Application)  service to the users 
and to the Internet DNS (and other DNS) for the users to uniquely resolve.

IMHO in the cookie case, there are three types of cookies:

- those documented as part of the Internet technology, subject to 
standard track document, that can only document their use within the 
Internet Iron Curtain (i.e. lowercase A-labels)
- those being used by IUI level applications that are to be 
documented by the Internet Users community that can be documented 
through BCP or for information like RFC 5895.
- those being used by the users applications that are documented by 
their developers.

The IU community has many needs and solutions that can be supported 
in respecting the now existing and confirmed Iron Curtain separation. 
Let try to not erode it and create instability.

To make sure everyone understand IDNA2008 is here to stay, we call 
IDNA2010 the debate on the IDNA2008 support on the User Side, and 
IDNA2012 the debate of the mutual support of IDNA2008 and IDNA2010.

Best
jfc