Re: [idn] nameprep back-compatibility

[David Hopwood <david.hopwood@zetnet.co.uk>]

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

Mike Astle wrote:
> If I'm a client with a resolver that uses nameprep_version1, I expect X to
> always map to A.  When I upgrade my resolver to nameprep_version2, X
> now maps to B - possibly leading me to a different IP address than what I
> intended.
>
> Is this kind of remapping forbidden by the draft or an associated
> document?

Yes, it is forbidden, provided that X does not contain any characters that
were unassigned in the version of Unicode used by nameprep_version1.

At 00:57 01/07/30 +0000, Mike Astle wrote:
> I'm new to this process, so please let me know if this message is
> misdirected.  After reading over what I believe to be the newest version
> of the nameprep draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-05.txt
>
> I was left wondering what happens if the mapping of a code point changes
> between versions of nameprep.  That is, the case where:
>
> nameprep_v1(S) != nameprep_v2(S)
>
> and S contains no unassigned codepoints (as of v1).
>
> I read back over the document and found this paragraph in section 6.2:
>
> "The processing in this document is always stable. If a string S is the
> result of processing on newVersion, then it will remain the same when
> processed on oldVersion."

This is obviously not correct; it should be something like:

  "The processing in this document is always stable. If a string X
  contains no characters that are unassigned in the version of Unicode
  used by oldVersion, then the result of processing X on oldVersion and
  on newVersion will be the same."

> Does this paragraph mean that nameprep(S) will always be the same no
> matter what the version of nameprep (provided that S does not contain
> any previously unassigned codepoints)?

Yes, that's what the corrected version means.

- -- 
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

iQEVAwUBO2nS6zkCAxeYt5gVAQHxQAgAi5vQlW48LwBT3VDWho0B6D0qB5Ce6GDO
Pqsb/6lYxMScdM3bzIX+ZKySYajHENM587SyLhilGMvUwlFnA8SvsWFihBt+fgHD
QaYm8cvBhMwlGjZDOuou1KMSfR1sVRiYJ1cu9vfOaqDyBTbvKhu+ECsEMM0nFSkD
E9fvmp+FY7iiX6NprdKP/b1q9OAcRupebVA+5YW1q3Dw9wu7yscpkjKAlqsE2TJN
IN2/vCAPa9rieyVKaB8RtNkYJhWW5tqtdBbEyWbbuW1y1umL/YUvBsJRuFpecBdF
H/xWL7Zibf/Rw8j4GA9JK1Em5JrPBjAzGBW/UnGSFkXD9lWQ/3f8LA==
=SAWP
-----END PGP SIGNATURE-----