draft-klensin-idnabis-protocol-04 section 4.5
vint at google.com
Fri Mar 28 11:42:59 CET 2008
this is an area where clarity will help so your assistance is
on the surface, I can see Martin's point. Is there additional
language in "rationale" that might clear up this uncertainty? Or
perhaps more needs to be said?
> This is irrelevant to the charter, but I have difficulties
> from the citations below how registration is stricter than lookup.
> Registration only mentions DISALLOWED and UNASSIGNED, whereas
> lookup mentions NFC, contextual rules, and combining marks in
> first position on top of that. So I get the impression that
> lookup is more restricted that registration. What did I get wrong?
> Regards, Martin.
> At 21:37 08/03/27, Harald Alvestrand wrote:
>> From draft-klensin-idnabis-protocol-04:
>> 4.3. Permitted Character and Label Validation
>> 4.3.1. Rejection of Characters that are not Permitted
>> The Unicode string is examined to prohibit characters that IDNA
>> not permit in input. Those characters are identified in the
>> "DISALLOWED" and "UNASSIGNED" lists that are discussed in
>> [IDNA200X-Rationale]. The normative rules for producing that list
>> and the initial version of it are specified in [IDNA200X-Tables].
>> Characters that are either DISALLOWED or UNASSIGNED MUST NOT be
>> of labels being processed for registration in the DNS.
>> 5.4. Validation and Character List Testing
>> In parallel with the registration procedure, the Unicode string is
>> checked to verify that all characters that appear in it are
>> valid for
>> IDNA resolution input. As discussed in [IDNA200X-Rationale], the
>> resolution check is more liberal than that of the registration one.
>> Putative labels with any of the following characteristics MUST BE
>> rejected prior to DNS lookup:
>> o Labels containing code points that are unassigned in the version
>> of Unicode being used by the application, i.e., in the
>> "Unassigned" Unicode category or the UNASSIGNED category of
>> o Labels that are not in NFC form.
>> o Labels containing prohibited code points, i.e., those that are
>> assigned to the "DISALLOWED" category in the permitted character
>> table [IDNA200X-Tables].
>> o Labels containing code points that are shown in the permitted
>> character table as requiring a contextual rule and that are
>> flagged as requiring exceptional special processing on lookup
>> ("CONTEXTJ" in the Tables) MUST conform to the rule, which
>> MUST be
>> o Labels containing other code points that are shown in the
>> permitted character table as requiring a contextual rule
>> ("CONTEXTO" in the tables), but for which no such rule
>> appears in
>> the table of rules. With the exception in the rule immediately
>> above, applications resolving DNS names or carrying out
>> operations are not required to test contextual rules, only to
>> verify that a rule exists.
>> o Labels whose first character is a combining mark. [[anchor15:
>> in Draft: this definition may need to be further tightened.]]
>> .... more text follows .....
>>> What I'm trying to understand is what an IDNA200x implementation
>>> will do
>>> (i.e., which output string or what error) when the user types
>>> or 'dェtェkonsult'.
>> Read the drafts. It helps.
>> Idna-update mailing list
>> Idna-update at alvestrand.no
> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-# http://www.sw.it.aoyama.ac.jp
> mailto:duerst at it.aoyama.ac.jp
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update