Jefsey,<br>comments interspread in the text.<br><br><div class="gmail_quote">2010/3/26 JFC Morfin <span dir="ltr"><<a href="mailto:jefsey@jefsey.com">jefsey@jefsey.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
This post is also sent to the IESG because it comments the quoted
positive point of view of a DNSEXT Chair, after an explanation he
received from a co-author of the abandonned IDNA2008 Mapping Document.
Please note that my appeal does not contest the abandon of this document
because it was decided after its submission. However, the abandon of that
WG/IDNABIS consensual document is even more contable than the lack of
IESG/IAB disclaimer. My appeal being more a contribution than an
opposition, I will not appeal this abandon, but should I have to appeal
the IAB it will be added in the annexes of the appeal, because IDNA2008
would have not succeeded without it (cf. Working Group summary) and it
needs to be understood to fully understand IDNA2008.<div><div></div><div class="h5"><br><br>
<blockquote type="cite">
<blockquote type="cite">2010/3/26 Andrew Sullivan
<<a href="mailto:ajs@shinkuro.com" target="_blank">ajs@shinkuro.com</a>> <br>
IDNA of any kind inserts a layer above the DNS but possibly below the
<br>
application interface that converts one kind of input (U-labels) into
<br>
another kind for the DNS (A-labels), and conversely. Now, it might
be <br>
true that changes in IDNA, or from binary DNS labels to A-labels, <br>
require changes to that software in ways that are inconvenient. <br>
Moreover, as Pete Resnick said to me this week, part of what IDNA2008
<br>
did was move some things from one side of an interface (mappings in <br>
the IDNA protocol) to another side. But that wasn't an accident:
it's <br>
a backward-incompatible change because we'd concluded that the old <br>
approach was harmful.<br>
Yes, it's very inconvenient for our purposes that the DNS has the <br>
protocol, history, and operational practice that it does. But if
the <br>
goal is actually to solve user problems, then this pain is in fact <br>
smaller than "reformat the
Internet".</blockquote></blockquote><br><br></div></div>
At 09:54 26/03/2010, jean-michel bernier de portzamparc wrote:<br>
<blockquote type="cite">He understood it
!!!</blockquote><br>
Jean-Michel,<br><br>
This is not that easy to accept, rather than to understand. This is
obvious for you now, however, because we worked on this together. It is
obvious for me because I saw it working and I deployed it with the
International network back in the 1980s with the Tymnet ISIS technology.
This is the reason for my appeal: Pete should not have had to explain it
privately to Andrew. IESG should have asked IAB to explain it to everyone
in an IDNA2008 disclaimer. What Andrew realized is that the legacy way of
approaching the Internet architecture could be harmful. This is the most
difficult change of mind: to change the vision of your evidence.
<br></div></blockquote><div><br>You are right. Andrew I apologize. My reaction was related to your review of JFC's appeal on IETF main, when you know that JFC cannot respond.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
---<br><br>
Well, Andrew, in its process, IDNA harmoniously completed the Internet in
exemplifying the way it addresses diversity and multiplicity. My appeal
is about the fact that concluding that the old approach was harmful was
worth a disclaimer as to the way to address the new and old approaches.
With such a disclaimer by you, along with IESG and IAB explaining that,
Shawn would have understood and joined:<br><br>
- the <a href="mailto:workon@idna2010.org" target="_blank">workon@idna2010.org</a> effort to consider how things are to be
implemented on the IUI (Internet Usage Interface) to match IDNA2008,
<br><br>
- and then <a href="mailto:workon@idna2012.org" target="_blank">workon@idna2012.org</a> to complete the way the IDNA2003 (old
approach), UTF-8 (different approach), IDNA2008 (final core approach),
etc. and IDNA2010 (final user side approach) are to be supported and
maintained together, i.e. what Shawn is requesting (may I remind you that
IDNA2008 uses punycode but does not touch punycode, it can work the same
or even better [less information being lost] with any other algoritm what
I look for with punyplus). <br></div></blockquote><div><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? <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br>
The DNS addition, on top and together with the DNS, builds the ML-DNS.
The ML-DNS job is to rigidly and simultaneously manage the various
avatars of the domain name at its different layers (in an IDNA2008
consistent manner), which I call the Naming Pile. This is why I started
with the ML-DNS issue, and then I dropped it until IDNA2008 was
published, when Vint said it was not his objective. However, we strongly
objected when the WG intended to keep the old harmful approach of mapping
on the Internet core side (i.e. "in the protocol"). <br><br>
---<br><br>
This IDNA2008 implicitly defined an Internet multiplication architectural
ability that is in direct line with RFC 1958 and 3439 principles (they
actually imply it) and is not limited to the DNS. However, it is just as
Paul and Pete state in Mapping; the implications are "unusual"
(for the IETF, which followed the "old harmful approach"). The
two main implications are that:<br><br>
- the IUI (Internet Usage Interface - the Interface that you are
referring to) user side's area does not belong to the IETF scope, for the
time being. This is why I had the IUCG created, because the IETF has
closed the User area in the past. This also is why I opposed Vint's idea
to de facto delegate that area to ICANN, which does not represent the
users (ALAC ???) but rather the gTLD lawyers and never responded clearly
neither to Vint nor to me, except that they could “reassess” …<br><br>
- the IUI split from the core Internet permits IDNA2008 to be fully
consistent, as it only deals with the Internet core issues, while the
IDNofA’s old harmful approach concept is shown as not fitting the job -
and the newly confirmed architecture. What the IAB implies
("conversion can be done only by an entity that knows which
protocols and name space will be used"). This has been documented by
the IAB's I_D and resulted in the AD worries about transitions and
Mapping.<br><br>
1. The Mapping document is a correct Internet core a minima point of
view, and a correct a minima (testing) guidance on the user side (cf.
Patrik responses to my questions: cf. appeal annex). It is to be
completed by a User side architecture, such as Interplus.<br><br>
2. ML-DNS consists in supporting a single domain name pile (one layer per
protocol/namespace) based on the IDN (Internet Domain Name) that is
managed by the Internet DNS. This Internet DNS is understood as a
core service to the other distributed services and application needs.
This could have been achieved by the WG/OPES if they would have
considered DNS support before SMTP, which was too complex in its coming
immediately after HTTP. As a consequence, applications should
transparently interface the ML-DNS at their proper naming pile layer just
as they do it at the current single ASCII DNS layer. This could be
off-the-shelve in attributing one class per ML-DNS layer. At the same
time,it would settle a purpose and a sensible adminance for the
class commodity.<br></div></blockquote><div><br>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? <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br>
---<br><br>
Now, regarding the pure multilinguistic hortotypographic issue, the IAB
is still far from the users' reality. The PPT that John Klensin refers to
is consistent with their I_D. However, its approach sources from the
questions that techies and technology have and not from the needs that
users and usage have.</div></blockquote><div><br>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>?<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div> As a result, Unicode is considered as a
prerequisite. This is awkward because Unicode is typography oriented and
users are demanding an orthotypographic ability, i.e. typography syntax,
which Unicode is not intended to support and IDNA2008 refused to document
(lack of a metadata layer). In addition, the IAB has not considered the
architectural breakthrough of IDNA2008 yet: this is why, through my
appeal, I am calling for them to consider and document it. And why my
appeal opposes nothing, but that lack.<br></div></blockquote><div><br>So, you mean that Mapping will however be a document of reference through its relations with the the IAB final response. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
This also is why ICANN FAST TRACK testing and their new
"sameness" fancy
<<a href="http://www.icann.org/en/announcements/announcement-22mar10-en.htm" target="_blank">
http://www.icann.org/en/announcements/announcement-22mar10-en.htm</a>>
are not reasonable at the present time, neither on the Internet and DNS
core side, nor on the Internet users side. The resulting confusion would
not have happened, if DNSEXT, the IESG, and the IAB would have published
a disclaimer warning ICANN that this is still a territory under
fundamental reworks.<br><font color="#888888"><br>
jfc<br>
</font><blockquote type="cite"><div><div></div><div class="h5">2010/3/26 Andrew Sullivan
<<a href="mailto:ajs@shinkuro.com" target="_blank">ajs@shinkuro.com</a>>
<dl>
<dd>IDNA of any kind inserts a layer above the DNS but possibly below the
</dd><dd>application interface that converts one kind of input (U-labels) into
</dd><dd>another kind for the DNS (A-labels), and conversely.</dd></dl></div></div></blockquote></div></blockquote><div>I wanted to ask: would it not be a good general introduction of Interplus?<br>Thank you <br><br>Portzamparc <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><blockquote type="cite"><div><div class="h5"><dl><dd> Now, it
might be
</dd><dd>true that changes in IDNA, or from binary DNS labels to A-labels,
</dd><dd>require changes to that software in ways that are inconvenient.
</dd><dd>Moreover, as Pete Resnick said to me this week, part of what IDNA2008
</dd><dd>did was move some things from one side of an interface (mappings in
</dd><dd>the IDNA protocol) to another side. But that wasn't an
accident: it's
</dd><dd>a backward-incompatible change because we'd concluded that the old
</dd><dd>approach was harmful.
</dd><dd>Yes, it's very inconvenient for our purposes that the DNS has the
</dd><dd>protocol, history, and operational practice that it does. But
if the
</dd><dd>goal is actually to solve user problems, then this pain is in fact
</dd><dd>smaller than "reformat the Internet".<br><br>
</dd></dl><br><br>
<br></div></div><div class="im">
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></div></blockquote>
</div>
</blockquote></div><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style>