Reasons for disallowing Arabic script digit mixing at the protocol level

Andrew Sullivan ajs at
Thu Mar 12 15:05:29 CET 2009

Dear colleagues,

On Tue, Mar 10, 2009 at 08:25:37AM -0400, Ram Mohan wrote:

> As I wrote yesterday, attached to this note is output from the ASIWG
> (Arabic Script IDN Working Group)'s drafting team on Arabic script
> digit mixing.  The discussion centers on a "no digit mixing"
> philosophy to be implemented at the protocol level.

I have read that document.  It seems to me that it does not provide
the argument necessary to show that the no-mixing rule _needs_ to be
implemented in the protocol.

As near as I can tell, the argument claims that digit types should
never be mixed: mixing is never needed by any user, and it has
potential for serious harm. But the no-mixing restriction could be
trivially adopted for registration by every registry.  There is a
claim that such a decision should not be left up to registries, but it
seems complete nonsense to me.  I think first of all that it is
contrary to the approach we have been taking so far, which has been to
try to remove from the protocol as much policy as possible.  This rule
is plainly a policy one, although one that perhaps ought to be adopted
everywhere.  Moreover, we leave _lots_ of important decisions up to
registries.  That's why we even have registries.  If we forbid the
mixing in the lookup protocol too, do we really believe that
implementers are going to check this stuff -- especially since we're
trying to take _out_ any other such checks, so the lookup code
wouldn't even have a natural place for such a check to fit?

The only real argument I can construct in favour of adopting a "no
digit mixing" rule in the protocol is that interoperability is
possibly better served by that rule; and the interoperability does not
come at the cost of policies that might be valuable to someone.  If
anyone has a counter-argument to that "such policy can't be valuable"
premise, then the whole argument in favour of forbidding digit type
mixing in the protocol collapses.

As a result of the above, my conclusion now is roughly the same as
what I came to after Minneapolis.  I don't think I completely
understand this case, but the restriction is something I can
reluctantly support given what an unusual case it seems to be.
Nevertheless, I would prefer a cleaner protocol which did not have
this piece of policy built in.  If anyone comes up with an argument
(that I can understand) as to why digit-type mixing might (note,
"might", which is weaker than "is") be a reasonable policy for
U-labels, then I might have to re-evaluate my conclusion.  To the
extent I think I understand these digit cases, however, I don't
believe such mixing could ever be reasonable for U-labels, even if it
is reasonable in some other contexts.  Remember the "no literature in
DNS" rule.

Best regards,


Andrew Sullivan
ajs at
Shinkuro, Inc.

More information about the Idna-update mailing list