Impact of Punycode
jean-michel bernier de portzamparc
jmabdp at gmail.com
Fri Mar 26 18:10:08 CET 2010
comments interspread in the text.
2010/3/26 JFC Morfin <jefsey at jefsey.com>
> 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
> 2010/3/26 Andrew Sullivan <ajs at shinkuro.com>
> IDNA of any kind inserts a layer above the DNS but possibly below the
> application interface that converts one kind of input (U-labels) into
> another kind for the DNS (A-labels), and conversely. Now, it might be
> true that changes in IDNA, or from binary DNS labels to A-labels,
> require changes to that software in ways that are inconvenient.
> Moreover, as Pete Resnick said to me this week, part of what IDNA2008
> did was move some things from one side of an interface (mappings in
> the IDNA protocol) to another side. But that wasn't an accident: it's
> a backward-incompatible change because we'd concluded that the old
> approach was harmful.
> Yes, it's very inconvenient for our purposes that the DNS has the
> protocol, history, and operational practice that it does. But if the
> goal is actually to solve user problems, then this pain is in fact
> smaller than "reformat the Internet".
> At 09:54 26/03/2010, jean-michel bernier de portzamparc wrote:
> He understood it !!!
> 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.
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.
> 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:
> - the workon at idna2010.org effort to consider how things are to be
> implemented on the IUI (Internet Usage Interface) to match IDNA2008,
> - and then workon at idna2012.org 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
We did not yet started the workon at idna2012.org. Should we, to clarify the
ccNSO confusion in showing the IDNA2008/2010/2012 coherence?
> 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").
> 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:
> - 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” …
> - 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.
> 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.
> 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.
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?
> 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
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?
> 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.
So, you mean that Mapping will however be a document of reference through
its relations with the the IAB final response.
> This also is why ICANN FAST TRACK testing and their new "sameness" fancy <http://www.icann.org/en/announcements/announcement-22mar10-en.htm>
> 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.
> 2010/3/26 Andrew Sullivan <ajs at shinkuro.com> IDNA of any kind inserts a
> layer above the DNS but possibly below the application interface that
> converts one kind of input (U-labels) into another kind for the DNS
> (A-labels), and conversely.
> I wanted to ask: would it not be a good general introduction of Interplus?
> Now, it might be true that changes in IDNA, or from binary DNS labels to
> A-labels, require changes to that software in ways that are inconvenient. Moreover,
> as Pete Resnick said to me this week, part of what IDNA2008 did was move
> some things from one side of an interface (mappings in the IDNA protocol)
> to another side. But that wasn't an accident: it's a
> backward-incompatible change because we'd concluded that the old approach
> was harmful. Yes, it's very inconvenient for our purposes that the DNS has
> the protocol, history, and operational practice that it does. But if the goal
> is actually to solve user problems, then this pain is in fact smaller than
> "reformat the Internet".
> Idna-update mailing list
> Idna-update at alvestrand.no
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update