draft-liman-tld-names-00.txt and bidi

[John C Klensin]

--On Sunday, March 08, 2009 13:13 +0330 Alireza Saleh
<saleh at nic.ir> wrote:

> Hi,
> 
> Just  would like to mention  that IDNA is not about HTTP,
> there are many other protocols that deserve IDN.  I think that
> finding a global solution that can satisfy all protocol
> clients is impossible and the group should expect some
> backward incompatible issues
> from the clients as we accepted some of them  within the
> protocol itself.

Agreed.  And, just as people discovered in the early days of
ICANN new gTLD allocations that there were client programs that
would refuse to look up any domain with a TLD longer than two
characters and not on a specific list, or longer than three
characters and not "ARPA", I expect that production deployment
of IDNs at the top level will turn up some clients that believe
in the RFC 1123 text and will refuse to lookup up a domain with
a TLD containing hyphens or digits.   Changing the requirement,
as draft-liman-tld-names-00.txt proposes to do (or in some other
way) is an important step but, the ICANN testbed effort
notwithstanding, I believe it is nearly certain that some
clients will reject those names and that it will take a long
time to upgrade them.

> I think one of the options would be making IDNA act only as a
> validation tool  which decides whether the entered label
> should be displayed in U-label or A-label. this validation can
> be done both at look up and registration level.

I don't quite understand this.  The conversion between the two
has to be specified somewhere, and a validation tool doesn't
accomplish that.  A validation tool also would not address
itself to the issue that draft-liman-tld-names is trying to
solve, namely a very specific statement in RFC 1123, updating
1034/1035 and other documents that says "alphabetic" and that,
at the time, clearly meant "ASCII alphabetic".

> Maybe, the resolver can report the client about the
> successful/unsuccessful IDNA checks , this can be done by
> something like 'ad' flag in DNSSEC.

I understand this even less, since resolvers, strictly speaking,
don't know anything about IDNA (and DNS servers don't know
anything either).

Could you explain?

    john