<html>
<body>
At 18:10 26/03/2010, jean-michel bernier de portzamparc wrote, <br>
<blockquote type=cite class=cite cite="">Jefsey,<br>
comments interspread in the text.<br>
<br>
We did not yet started the
<a href="mailto:workon@idna2012.org">workon@idna2012.org</a>. Should we,
to clarify the ccNSO confusion in showing the IDNA2008/2010/2012
coherence? </blockquote><br>
Jean-Michel,<br><br>
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. <br><br>
<blockquote type=cite class=cite cite="">So, you mean that this would
establish that necessarily <a href="http://ibm.com">ibm.com</a> in class
IN and <a href="http://ibm.com">ibm.com</a> in every other class NN
should be owned by the same registrant? </blockquote><br>
Not that blunt, but<br>
- 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".<br>
- 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.<br><br>
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.<br><br>
<blockquote type=cite class=cite cite="">Should we not try to work first
on a document explaining these needs to the techies? Could this be a
first objective for
<a href="mailto:workon@inda2010.org">workon@inda2010.org</a>?</blockquote>
<br>
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. <br><br>
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<br><br>
<blockquote type=cite class=cite cite=""> So, you mean that Mapping
will however be a document of reference through its relations with the
the IAB final response. </blockquote><br>
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 :<br><br>
- where IETF can say MUST (core Internet)<br>
- where IETF can only say SHOULD (IUI)<br>
- where IETF can only say MAY (user application)<br><br>
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:<br>
- rough consensus in the IETF core Internet domain area: since there is
only one single core Internet.<br>
- 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).<br><br>
jfc<br>
</body>
</html>