Impact of Punycode
jefsey
jefsey at jefsey.com
Fri Mar 26 22:28:44 CET 2010
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
More information about the Idna-update
mailing list