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

On Wed, Oct 26, 2011 at 10:04 PM, Jens Wagner <[email protected]> wrote:

> On 26.10.2011 12:42, Andrew Sullivan wrote:
>
>> On Wed, Oct 26, 2011 at 12:21:15PM +0200, Jens Wagner wrote:
>>
>>> Furthermore, I'd prefer if there's no redundancy in responses, e.g.
>>> variants should be returned in punycode only.
>>>
>> I don't think you can do that.  The Punycode form of IDNA2003 labels
>> is not lossless, so while you get what is in the DNS, you don't know
>> what the input string for the label was.
>>
>> You could return only the A-label, of course, for IDNA2008, because
>> there's no ambiguity there (each A-label corresponds to exactly one
>> U-label).  But we're not in an IDNA2008-only world yet, and if you'd
>> meant to stick to IDNA2008, you'd have said "A-label" instead.
>>
>>  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.
>
>
Whenever folks suggested that registries should collect the input string,
I've always wondered the practical utility of it other than as an FYI? I
think I've heard some arguments along the lines of "future-proofing".
Perhaps it could be useful in the transition to IDNA2008 (with the ß and
sigma, etc.) but still it can only be used as a partial aid. Moreover,
there's no guarantee that the registrar didn't submit the
ToUnicode(ToAscii(input)) version, in which case it's truly redundant as
Jens stated.

Andrew, could you share your reasoning?

.wil

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