[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