Subject: Re: [iucg] IDNA 2008 Question Re: "Confusable" Characters in Domain Names

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Sat, 6 Nov 2010 03:13:12 +0100

Dear John,

Until now this thread shown the possible sustainabilty of the IDNA2008
consensus between concerned IETF engineers and Innovative Users. This mail
introduces an ICANN oriented pertinent (
http://www.icann.org/en/reviews/affirmation/application-brunner-williams-motivation-letter-16feb10-en.pdf)
point of view which is technically less open minded.

At a time, the Chair suggested that this WG could transfer as an ICANN WG to
discuss the user side. I then started the IUCG [email-masked] to that
end because ICANN does not really represent us. Then we found that such a
debate had to be in the public domains and to include every  type of
stakeholder in the ICANN/IETF/IUsers.

PORTZAMPARC

2010/11/6 Eric Brunner-Williams <[email-masked]>

> On 11/5/10 10:17 AM, john daw wrote:
>
>> JFC Morfin wrote:
>>
>
> [the usual rubbish]
>
>
>  I agree with this, and must say that i'm not involved in the
>> architecture of the Internet in
>> any way, as my original email might suggest. €.com, however, ought to
>> be "supported"
>>
>
> As you're making a keyboard (or anything the lower half of a tty driver
> handles) claim, how about space, backspace, tab, dot, and all those
> delicious control characters?
>
> Eric
>
>
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: "J-F C. Morfin" <[email-masked]>
Date: Sat, 06 Nov 2010 13:06:41 +0100

At 10:35 06/11/2010, Andrew Sullivan wrote:
>I think you're not making a distinction you may need.
>
>Anyone looking up anything in the DNS can tell what rules everyone
>else is using: they're using RFC 1034 and RFC1035 and a larger or
>smaller set of subsequent RFCs that refine the way the DNS is used.
>Nothing in IDNA, or for that matter the policies encoded in RFC 1123
>or in ICANN's various agreements or in the CIRA .ca (or pick your
>favourite ccTLD) or the .name registration agreement or the rules
>about blogspot.com names or whatever else you like constrains any of
>that.  Moreover, if you want to set up shawnsteele.example.com and put
>ISO-8859-1 labels in the next level down, _that's also_ perfetly
>legitimate in the DNS, and will "work" in the sense that someone else
>who knows what kind of bitstring you have in that 8859-1 label will be
>able to interpret it.
>
>The distinction you need is that there is no way, in the DNS or,
>currently as far as I know, outside of it, to look up the policies for
>what code points would be acceptable U-label pieces in a U-label in
>that zone.  It might be the case that having such a mechanism would be
>good.  But we don't have it right now.  If we think making such a
>mechanism (or even just defining conventions for how to publish that
>policy) is important, then people should speak up.  The last couple
>times I proposed it, the reaction seemed to me that it wasn't
>important.  So I never bothered to write it up.

Dear Andrew,

it was a real and great pleasure to read this post. And I concurr 
that people needing such a mechanism should speak-up asap. At the 
present time I do not see how such a mechanism could help the ML-DNS 
but I see how it could hamper it. This does not mean however that I 
considered everything and I am not wrong. So it could be worth 
discussing it before we commit experimentation code that we could not 
easily repell.

Again, I am prevented to fully explain the ML-DNS due to ISOC 
Copyrights. But it is public domain that one can consider the ML-DNS 
as an "Internet peritem" DNS front-end. This means a smart gateway 
into the Internet DNS application function, that is logically located 
in the Internet Use Interface, i.e. on the users side of the Internet 
peripheral.

The problem is that the DNS is supported by a distributed function, 
which can be, in toto or in parte, located on the user side. Due to 
that user side part, such a mechanism could conflict with the ML-DNS 
which precisely also include the (peripheral) support of  such a 
mechanism. At DNS level, this mechanism would document the typography 
being used. At ML-DNS front-end extension level,  will be document - 
among others - the orthotypography being used (ex. support of 
$€£.net). However, there are two other mechanisms that are to be 
considered in here, that have been enlighted by IDNA2008: they are 
presentations and classes.

This is why I am over cautious with ML-DNS. IESG considers it as 
research and I consider it only as pre-experimental. Let consider it 
is adopted, as there are chances, by a few (experimental) eTLD 
projects and becomes operational. Either I was right and I am better 
to be exhaustive, or I am mistaken and the lack of guidance/help I 
have seeked for in vain will have fathered confusion.

Vint proposed to help and advertize our work within the IETF. 
Unfortunately we (IUsers and appeal process) identified (as 
Portzamparc underlined it) that the ML-DNS is not an IETF Internet 
but an IUsers system; and as such:

(1) MUST therefore remain in public domain to permit every other 
technology to freely use/adapt it in any other context
(2) MUST be based on rough consensus of the interested parties (we 
need first to gather, including the IETF), running code (such as 
alfaDNS underway) and "living mode" i.e. live testing by the young 
and emerging IUser community.

Nevertheless, let me "speak-up". I propose you that as soon as I can 
have an alfaDNS running code and test environment embryo, we discuss 
the whole matter and test it to understand if there is a need and 
exactly where it is to be answered and for what.

However, my first impulse is to strongly agree with you that: "Anyone 
looking up anything in the DNS can tell what rules everyone else is 
using: they're using RFC 1034 and RFC1035 and a larger or smaller set 
of subsequent RFCs that refine the way the DNS is used. Nothing in 
IDNA, or for that matter the policies encoded in RFC 1123 [...] 
constrains any of that". ML-DNS only means that this extends well 
outside of the sole IP topology Internet.

jfc

---

From: "J-F C. Morfin" <[email-masked]>
Date: Tue, 09 Nov 2010 00:32:18 +0100

At 17:29 08/11/2010, Nicolas Williams wrote:

>I'd rather we avoid it as much as possible.  ISTM that the best way 
>to avoid it is to get IDNA2008 deployed.

http://iucg.org/wiki/Road-map
Best
jfc