[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] UTC recommendations on TC/SC
> Thanks for your note. I would be glad to try to clarify it. The UTC position
> does disagree with the tsconv document, in maintaining that nameprep does
> not require the addition of TC/SC folding.
The first being the product of a vendor consortia, the second a product of
the .CN and .TW NICs, and the subject matter being in the context of dns
identifiers. This is doubly awkward.
> I believe the consensus view* in the UTC is that SC/TC folding -- when done
> correctly -- is quite complex (cf http://cjk.org/cjk/c2c/c2cbasis.htm), that
> there is no established standard that precisely defines the conversion, and
I'm interested in the consensus view in the PRC, and in Taiwan, also.
This next bit, starting at "since" to the end of the sentence.
> that it is not a required feature of nameprep, since multiple registrations
> will reasonably meet the user requirements. The latter point is based on
> there being typically only two variant spellings: one TC and the other SC.
Earlier someone proposed, and eventually withdrew, a proposal to allow
a character-by-character, registrant election of equivalency, which has
combinatorial scaling properties. A vendor may also have advocated this.
I had dinner with their CTO once and got indigestion.
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". 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>".
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.
I probably misread your mail.
I would like to know how the "typically only two variant spellings" rule
is manifested, or could be expressed as an equivalence rule. We did work
on the question of equivalency rule scope in the discussion of (former)
requirement [30], to motivate an interest in SC/TC conversion at the protocol
vs zone manager (nameprep or not) level.
> * I'm speaking for myself (not the UTC) in the material following the
> asterisk, since this material was not an explicit part of the UTC decision.
Informed guessing is good, and thanks for responding. I hope to see you in
DC next year.
Eric