Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

On Thu, Oct 27, 2011 at 9:44 PM, Andrew Sullivan <[email protected]>wrote:

> On Wed, Oct 26, 2011 at 01:04:47PM +0200, Jens Wagner wrote:
>
> > for now, the extension needs to cover IDNA2003 too, imho we can't
> > stick to IDNA2008 in the forseeable future.
> > But - do we need the unicode labels at all? The set of 'usable'
> > domain names always matches the set of them encoded in punycode.
>
> It's of course true that the IDNA2003 Punycode-encoded label, or the
> IDNA2008 A-label, is the only thing that actually gets looked up.  But
> given that people seem to want variants, those variants are based on
> the string requested by the originator of the registration request (we
> usually call this the registrant).  But what qualifies as a variant is
> at least partly determined by registry policy, the registry will need
> to be able to evaluate the extent to which a UTF-8 label (in IDNA2003)
> or U-label (in IDNA2008) has variants.
>
>
I can't think of a case where the registry can't determine the variants
from the ToUnicode(ToAscii(input)) alone. The language/script variant
tables are constructed such that only the permitted codepoints after
mapping (IDNA2003), normalisation and case folding have been applied. I'd
expect that the internal data structures within registries' implementations
also similarly only operate on permitted code points.

So, if given the input UTF-8 label, the registry would only either store
and forget about it, or perform ToUnicode(ToAscii()) on it.


Moreover, IDNA2008 suggests that the repository evaluate the
> U-label/A-label pair for conformance with one another, in order to
> ensure that the A-label to be placed in the zone really corresponds to
> the desired U-label (and that that U-label is a real U-label).  See
> section 4.2.1 of RFC 5891.
>
>
Practically, in an SRS environment, I'd expect this evaluation of
U-label/A-label pair to be done by the registrar, rather than the registry
(repository) because registrants should be educated about IDNA2008 rules at
the entry point, rather than being presented with a cryptic EPP error
message.

.wil

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg