Re: [idn] UTC recommendations on TC/SC

[Eric Brunner <brunner@nic-naa.net>]

Paul,

If the UTC wants to dip into zone administrator operational technique, it
doesn't mean they can do so correctly. Desire isn't competency. When they
publish their analysis of the set of mechanisms they evaluated, and a
comment on why the mechanism they selected as "reasonable" was, and on why
the alternatives were not "reasonable", their comment on A records may
meet the usual test for content, coverage and correctness.

I've lost count of the number of times people have consisdered "fixing" a
code point problem in this WG, and have been told it is out of scope. The
fences between us (IETF and UTC, and ICANN, and W3C, and ITU, and ETSI),
help us, they don't hinder us.

I'll pass on your last gem. There are reasons to question the work of any
group, including the UTC, arising from their abilities and accomplishments,
that don't require putting on an ICANN hat. Your point does come back to a
point of whether or not we (the IETF, not this WG) can accomodate national
standards other than ASCII, or can only, due to some form of universalism,
accomodate a (unique) multi-standard, which quite possibly depricates some
national standard(s).

When a national standards body has something to say, particularly when it
does so in disagreement with the UTC, it is a poor choice to pick either
on a basis other than discernable correctness.

Lets stick to the engineering, not haigiography (worship of UTC saints) or
deamonology (worship of ICANN deamons), and work out which, the UTC or the
authors of tsconv, got the better end of the stick, if either.

Eric


> >In any event, I can't imagine how a conversation in a code-point standards
> >body ended with a paraphrasing of "multiple (zone) registrations reasonably
> >meet user requirements".
> 
> Others might not be as incredulous. As Mark said, there are 
> essentially only two zone registrations, and that is really only 
> needed for names where the user might do a traditional-to-simplified 
> conversion.
> 
> >  It is as odd as an IETF conversation ending with
> >the observation that "multiple code-point allocations reasonably meet the
> >glyph <foo>'s requirements as a character in scripts <bar> and <baz>".
> 
> No, that is completely different. In the T-S case, the question is 
> how might the user who does an inherent conversion be accommodated, 
> and who will be doing the accomodating (the protocol or the zone 
> holder); in the code-point case, you are not accomodating a user, and 
> you are only making the change in the protocol.
> 
> >In this one note I'm troubled to see the UTC presume to know better than
> >the sources available to the authors of tsconv, and to know better than
> >the authors of some eventual STANDARD and/or BCP trace APPS or DNS IDs.
> 
> Why? The IETF looks to outside experts for advice, and I think it can 
> reasonably be stated that the UTC are experts on Unicode. Until this 
> WG, I had *never* heard anyone claim that a typical person in China 
> would do a partial conversion of a name to a mixture of traditional 
> and simplified. This is not to say that the CNNIC/TWNIC folks are 
> wrong; they are clearly trying to make a strong case for helping 
> native Chinese speakers more than the DNS ever has.
> 
> Questioning the UTC's expertise in scripts, and deferring instead to 
> national name registries who have very different concerns, may make 
> sense for a policy-based body like ICANN, but probably not for a 
> standard-based body like the IETF.