Impact of Punycode

jean-michel bernier de portzamparc jmabdp at gmail.com
Fri Mar 26 18:10:08 CET 2010


Jefsey,
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
> IDNA2008.
>
>
>  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 !!!
>
>
> Jean-Michel,
>
> 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
> punyplus).
>

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
> have.
>

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.
>
> jfc
>
> 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?
Thank you

Portzamparc

>   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
>  http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20100326/001378ee/attachment.htm 


More information about the Idna-update mailing list