IDNA support

[bal-e]

At the moment, Domain does not have any support for IDNA (neither in base nor new::base). While some preliminary code for it is visible in #422, it needs significant design work (esp. to distinguish different kinds of labels in the type system) and testing.

• Design an ergonomic and efficient API for IDNs in new::base.
  • Account for U-labels, A-labels, etc.
• Implement this design.
  • Implement Punycode encoding and decoding (with extensive tests).

[Philip-NLnetLabs]

We have to make sure that IDN support remains optional in labels. Labels may contain arbitrary data, so we have to make sure a label is only parsed as IDN when requested.

[bortzmeyer]

We have to make sure that IDN support remains optional in labels. Labels may contain arbitrary data, so we have to make sure a label is only parsed as IDN when requested.

Isn't it the role of the xn-- prefix and all the fuss at its creation? Starts with xn-- -> parse as IDN. Otherwise -> just arbitrary data.

[Philip-NLnetLabs]

Yes, but in Rust it is easy to go wrong and (for example, after reading RFC 5891) require that labels need to contain ASCII.

[bal-e]

IDNA introduces terms like U-labels and A-labels, which I looked at a long time ago but don't remember the details of. These terms should encode the right validity requirements and we will probably need separate types to represent each of them. The standard Label and Name types are not going to change.