Impact of Punycode

[jean-michel bernier de portzamparc]

Here is the response to my last mail.
Portzamparc

2010/3/26 jefsey <jefsey at jefsey.com>

>  At 18:10 26/03/2010, jean-michel bernier de portzamparc wrote,
>
> Jefsey,
> comments interspread in the text.
>
> We did not yet started the 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 ibm.com in class
> IN and 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 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/20100327/37d0ae93/attachment.htm