Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review
Andrew Sullivan <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
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. > <var:domain type='simplified-chinese'>xn--fiqu1az03c18t.cn</var:domain> > <var:domain type='traditional-chinese'>xn--fiq228c54pg81a.cn</var:domain> > <var:domain type='variant'>xn--fsq470a.xn--fiqz9s</var:domain> > </var:list> > </var:infData> > > should do, where type is a text attribute, and could be e.g. > 'simple-chinese', 'traditional-chinese' and so on. For management > purposes, the type doesn't really matter. Where are these types going to come from? The term "variant", I have to say, has been so miserably overloaded that we have serious problems with using it. A -- Andrew Sullivan [email protected] _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg