[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] proposed i18n naming rules



-----BEGIN PGP SIGNED MESSAGE-----

"Eric A. Hall" wrote:
> 1) Expand the IHN rules to accomodate a larger ("reasonable") set of
>    characters, such as "_" for SRV and some common mail characters.
> 
>    This breaks backwards compatibility, and is not really much of an
>    option.

Agreed.

> 2) Define a stringprep profile for IDNs explicitly.
> 
>    One of the hard part of this approach is deciding on case-
>    conversion. Life is easier if everything is lowercased but as
>    shown, this breaks local-parts of email addresses.

It breaks e-mail addresses only if a local part encoded as a label
in an RR is required to be normalised. Why would it need to be normalised?

The same name equivalence relation should be used for all names in
queries, and names in RRs should preserve case (just as it is now for
ASCII).

>    Also, there is a potential future problem with normalization of
>    characters, in that some future version of RFC 2822 may allow for
>    non-normalized characters in local-parts. Requiring mandatory
>    normalization would prohibit this usage, or at the least, would
>    make such usage more complex.
> 
>    Finally, there is a problem with the eight-bit codes which are
>    currently unspecified but legal in DNS. These codes map to the
>    Latin-1 subset,

No, they don't. IDNS interprets them as Latin-1, but I don't understand
why it does that; it's completely unnecessary, and incompatible with
the specification in section 3.1 RFC 1035 that octets >= 0x80 are
caseless ("Non-alphabetic codes must match exactly.", where "alphabetic"
means ASCII a-z and A-Z).

>    so if they are always mandatorily interpreted and
>    managed as such and are always normalized and case converted,
>    then the wrong data will be returned.
> 
> 3) Redefine the allowable data in DNS.

Not an option.

> 4) Clarify the protocol usage rules. EG, clarify SRV to be
>    [service].[transport].<IHI>.

There's no need to do that if a single equivalence relation is used.

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBO/2KqDkCAxeYt5gVAQFNUQgAhKyEMa73fHrIfyRFCP/QdRFkN0hoAITF
YAKwpHxoDWSTrq67eJCExL3UD5pIRgDM/BVc41lZ5UIahXRWmpWrGqyi8ADLCa8I
tdG+nTmb65emkSNmwEq8Nsp5DXyBMDtcbe5i64E2Fo5UpxypDGibXDB+88eUkX6W
6vgyvYJ7PL6FHAMq+HuPEleoewmYUh0XrwBWcN3X4YUDcw9xx+s8Ye69boEuiVvq
Qv5sY156ieeqoqDa4Miv4LMmDoJUBKYRaMnjpaezzkKSIzrTJfRcZzIkZnBTxPWl
w+WYv/WMz2MIu0+MbOlIpH/ATngCKfieSoHa5zcjpP029lewXxBXzg==
=WQ0W
-----END PGP SIGNATURE-----