Re: U-labels and draft-obispo-epp-idn-00

Klaus Malorny <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
On 15/02/12 05:58, Patrik Fältström wrote:
> On 15 feb 2012, at 04:58, Andrew Sullivan wrote:
>>
>> If those registries plan to use the EPP standard domain name mapping,
>> they couldn't possibly do it this way: the<domain:name>  element is not
>> optional, and it only allows LDH.
>
> Good, then we agree here.
>
>>> - The a-label is what is mandatory and normative in the exchange between epp client and server
>>
>> Already true in the RFCs we have.
>
> Exactly!
>
>

Hi,

where is this stated, if I may ask? Can't find this in RFC 5730/5731 or in the 
RFC 5891 which was mentioned in a later post.

In my humble opinion, it is a bad idea to spread the use of Punycode into areas 
where there is no technical need for it. While I am still fascinated about the 
mathematical tricks that are used in make the code as small as possible, we 
should not forget that it was a technical crutch to add Unicode to DNS in a 
backward-compatible fashion. I may be good for DNS, but should stay there. XML 
as the basis of EPP, on the other hand, has its own means to deal with Unicode, 
it even works with plain ASCII, using numeric entities. So using Punycode with 
XML is unnecessary and some kind of "double encoding". This is similar as one 
would mandate to use "U+NNNN" or "\uNNNN" notations or using UTF-7 within the 
XML document itself (i.e. not as a document encoding), which would of course 
cause head-shaking.

Of course, it is arguable what kind of Unicode string is expected, i.e. whether 
it is demanded that a normalized, prepared or whatever constrained string has to 
be submitted, or whether the registry accepts any form and does the 
normalization before it further processes the name.

Regards,

Klaus

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.