IDNA 2008 Question Re: "Confusable" Characters in Domain Names
J-F C. Morfin
jfc at morfin.org
Sat Nov 6 13:06:41 CET 2010
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
More information about the Idna-update
mailing list