Charter changes and a possible new direction

[Andrew Sullivan]

On Wed, Jan 14, 2009 at 05:57:05AM +0100, Patrik Fältström wrote:
> 
> If you look for problems that are serious problems, you should not  
> look at resolution. You should start looking at registration.
> 
> The bad cases are for example:
> 
> A is registering a domain name, B is registering a different domain  
> name. Where different is defined by IDNA(N). When IDNA(N+1) is  
> released, A and B are not different anymore.
> 
> A is registering a domain name, that can be registered according to  
> IDNA(N+1). A, or the customers of A, is then trying to look up the  
> domain name, but that is not possible in IDNA(N).

Ok.  But has that ever happened?  My point is partly that, to me, a
big motivation has been to replace the tables (which are bound to a
particular version of Unicode) with rules that can be applied no
matter what version of Unicode we use.  I used to think that was a big
win.  But the accretion of exceptions, plus the potential effects of
local mappings, now makes me wonder whether I was right.  

> Unicode might announce for version (N+1) that "Hey, we have added  
> support for this language". What do you think that language community  
> will say if ICANN have to wait for IETF action before they can assign  
> an IDN-ccTLD? (Addition of a new script/language/codepoint will  
> certainly not require changes in backward compatibilities or  
> exceptions.) This is what we have to optimize the standard for.

They'll be annoyed, of course.  That's in the "negatives" column in
the square of opposition that one might build to decide whether the
trade-off is a good one.

> As I have said many times before, I think we need mappings, but the  
> details of the mappings must be treated with application by  
> application due to the corner cases that exists. There might be a core  
> substance that is shared, and that will solve the majority of the  
> issues. And just because the core exists, I do not think we will see  
> the problems you talk about.

The reason I feel queasy about this is that it's basically an argument
from faith: we _think_ we can solve that majority of cases, and we
_think_ we can do the mapping; but the protocol is "done" without
having even a proposal for how this ought to work.  I think,
therefore, that it is more accurate to say that we simply don't know
whether we can solve the problem, since we haven't investigated it
enough to get a scratch proposal together.  

I'm particularly worried because what we seem to be doing here is
taking all the really hard, contentious cases, and deferring dealing
with them.  But they are, of course, exactly where the problems are
going to be.  I don't think we get to say, "Don't worry about that,
it'll be ok."  I should be very surprised if this issue wasn't exactly
where the objections turned up when the product of this WG goes to
IETF LC.  I'd really like to cope with such problems here, if only so
that we have something intelligent to say about wht, formally, the
protocol allows an end node to do more or less anything it wants to a
label before the label gets into the IDNA2008 processing.

> minority in the wg. The community, and specifically the registry that  
> will be affected by this incompatible change, have said "we have  
> things under control", and as I have said before, I am *not* the one  
> arguing against a community that ask for things. They know things in  
> their context better than I do.

Well, "the registry" bothers me in the above.  There's certainly more
than one registry involved, and at least one of them hasn't weighed
in.  I have some ideas about what I'd say if I _were_ such a registry
(some of it isn't printable ;-) but exactly where I'd come down, I
can't be certain.
 
> That is what I see. And note that *I* might be in the minority that  
> even want IETF action on the first change. 

I can buy the argument that, for the sake of introducing the process
in the most conservative way possible, reqiring IETF action for the
first changes is worth doing.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.