Re: U-labels and draft-obispo-epp-idn-00
Patrik Fältström <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On 14 feb 2012, at 22:25, Andrew Sullivan wrote: > A repository, on receiving this, could validate that the A-label and > U-label matched. If they did not, it would be an error. FWIW, I am against passing U-label to the registry. Specifically having it "optional" as some registries will make it mandatory, and some will not. This will once again create a requirement in difference in implementation on the epp client side how to pass such a simple thing as a domain name from the epp client to the epp server. Further, if we go down this path of sending a U-label, then we might in the next step have epp servers that give the ability for the client to send unicode strings that are non-normalized and because of that not 1:1 mappings to the A-label as this piece of the data, and then validation whether the A-label matches or not -- according to the algorithm chosen by the registry. Etc. The slope is *extremely* slippery. The only think I can agree to is that: - The a-label is what is mandatory and normative in the exchange between epp client and server - An epp server might optionally accept a u-label, but that is never mandatory - Wrong u-label (or never sending it) can never block the use of the a-label given it is accepted That way, epp clients can if they want to pass an optional u-label to the registry and get some signalling back. But it is not part of the mandatory communication when dealing with strings. I.e. I ask myself, if you as an epp client do have a U-label, what is the chance the A-label is calculated wrongly? Adding that as a "feature" is just silly. Patrik _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg