Impact of Punycode

[jefsey]

At 18:10 26/03/2010, jean-michel bernier de portzamparc wrote,
>Jefsey,
>comments interspread in the text.
>
>We did not yet started the 
><mailto:workon at idna2012.org>workon at idna2012.org. Should we, to 
>clarify the ccNSO confusion in showing the IDNA2008/2010/2012 coherence?

Jean-Michel,

I think we should wait for the clarifications asked to the IESG and 
possibly to IAB. The interest in chosing "IDNA2010" was to clarify 
the ccNSO misunderstanding: "IDNA2010" used as a new version  of 
"IDNA2008" was extremelly confusing. Since work has to be carried in 
2010 on IDNA, it made sense to call it IDNA2010. This work concerns 
the Internet Usage Interface's (IUI) user side counter-part to 
IDNA2008. Not necessarily great name, but at least a correct concept. 
The use of "IDNA2012" then makes more sense. But this is our 
proposition, not the result of the IAB guidance we need first.

>So, you mean that this would establish that necessarily 
><http://ibm.com>ibm.com in class IN and <http://ibm.com>ibm.com in 
>every other class NN should be owned by the same registrant?

Not that blunt, but
- we need to work on the Naming Pile and a way to describe the 
purpose of the different name layers we use. This can help a very 
simple simple response to "sameness".
- classes appears to be a logical response, as they are not unlimited 
as presentations could be. Also, we need to fix their use quick 
before they are used for alternative naming spaces like ITU and 
Francis Muguet investigated.

Now, I have nothing against a logic which would say that classes are 
used in the ML-DNS in several manners, or that there could be a 
limited number of classes per naming space. For example, there are 
private use classes, we will test. We are at the begining of the 
ML-DNS. We introduced the idea. Andrew says the idea was here before. 
Let give time to time. Let also remember that classes could have 
different roles depending on the presentation.

>Should we not try to work first on a document explaining these needs 
>to the techies? Could this be a first objective for 
><mailto:workon at inda2010.org>workon at inda2010.org?

I don't think so. IDNA2010 is to be a BCP kind of work. We need 
practical inputs telling how people solved problems. This will help 
understanding what people (and IAB) make of the IUI reality.

What the user expects IMHO is to be approached on a more "holistic" 
manner (in the Smut's original meaning: the more something develops 
the more it gows new needs and the more new ideas will emerge). At 
this time we are just begining to consider what XXIth century usage 
facilitation may be when it roots in semantics

>  So, you mean that Mapping will however be a document of reference 
> through its relations with the the IAB final response.

The Mapping document is intrinsic to IDNA2008. It simply says that 
mapping is not to be carried on the core Internet side; it then 
describes what should be done on the user side to satisfy what the 
user might do. As such it implies three areas :

- where IETF can say MUST (core Internet)
- where IETF can only say SHOULD (IUI)
- where IETF can only say MAY (user application)

 From this you may infer that since IDNA cannot be deployed within 
the core Internet, deploying it at the user application layer is less 
secure than deploying it at IUI where we have more control. This is 
the fundamental point where everyone must agree, since it opposes the 
IDNA premise of an IDNinApplications with an IDNApplication. This why 
it is to the IAB to provide guidance and proper technical wording for 
the issue. Hence my appeal. The point is not to win, but that 
everyone agrees through:
- rough consensus in the IETF core Internet domain area: since there 
is only one single core Internet.
- multiconsensus in the Internet Usage area (there may be different 
forms of usages, but they need to interoperate through the same 
general principles and procedures).

jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20100326/a4ea16b5/attachment-0001.htm