[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [idn] Prefix for testing AMC-Z implementations



> So the question I would ask you is whether you see a 
> strong case for reserving, e.g., 3166-1 alpha-2 names 
> as ACE prefixes, rather than just reserving them as 
> labels.

John,

I guess a strong case or not should be made based
on one's answers to the following questions:

1. Will an IDNA solution emerge as the answer?

2. If so, will a single encoding format emerge?

3. If not, how does one uniquely identify different
   encoding formats for interoperability? The 
   answer seems to be different ACE prefixes.

4. Should these ACE prefixes be based on another 
   classification scheme? If so, what scheme?

Different views have been expressed here on the script 
versus language encoding debates (with you expressing 
that this WG should focus on the former and not the latter). 
If others share that view, this might be an argument against 
ISO 639 alpha-2s for ACE prefixes as they identify 
languages and not scripts. As you note, that doesn't 
preclude 639 being used at another non-DNS problem level.

My impression (and perhaps I'm wrong) is that different 
national IDN solutions have and are emerging. If that is
the case, it seems reasonable, for future interoperability 
needs, to reserve ISO 3166 alpha-2 codes for ACE-prefix 
reservation.

In the meantime, I did check with the 3166 Secretariat and 
as someone else has pointed out on the list, any possible 
ISO 3166 alpha-2 conflict at this stage can be avoided by 
simply using ACE prefixes in the range:

AA, QM to QZ, XA to XZ, and ZZ

That seems to give a fair amount of playing space (~40 prefixes).

Bob