Subject: Re: [iucg] Impact of Punycode

From: JFC Morfin <[email-masked]>
Date: Fri, 26 Mar 2010 16:52:54 +0100

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 <<mailto:[email-masked]>[email-masked]>
>>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.

---

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 [email-masked] effort to consider how things are to be 
implemented on the IUI (Internet Usage Interface) to match IDNA2008,

- and then [email-masked] 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).

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.

---

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

This also is why ICANN FAST TRACK testing and their new "sameness" 
fancy 
<<http://www.icann.org/en/announcements/announcement-22mar10-en.htm>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 <<mailto:[email-masked]>[email-masked]>
>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".
>
>
>
>
>_______________________________________________
>Idna-update mailing list
>[email-masked]
>http://www.alvestrand.no/mailman/listinfo/idna-update

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Fri, 26 Mar 2010 18:10:08 +0100

Jefsey,
comments interspread in the text.

2010/3/26 JFC Morfin <[email-masked]>

>  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 <[email-masked]>
> 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:
>
> 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 [email-masked]. 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” …
>
> 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 [email-masked]?

> 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 <[email-masked]> 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".
>
>
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Mar 2010 13:40:12 -0400

On Fri, Mar 26, 2010 at 04:52:54PM +0100, JFC Morfin wrote:
> 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 

Uh, to be clear, Pete didn't have to explain anything to me.  I
thought the turn of phrase he used was just right, so I cited him.
But this feature of IDNA2008 was clear to me, because it was a
significant part of the _point_ of chartering IDNABIS.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: jefsey <[email-masked]>
Date: Fri, 26 Mar 2010 22:28:44 +0100

At 18:10 26/03/2010, jean-michel bernier de portzamparc wrote,
>We did not yet started the 
><mailto:[email-masked]>[email-masked]. 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:[email-masked]>[email-masked]?

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