Subject: [idn] Re: [idn-nameprep] nameprep back-compatibility

From: Mike Astle <[email-masked]>
Date: Thu, 2 Aug 2001 17:49:07 +0000 (GMT)

The silence from the idn-nameprep list is leading me to believe that I
might be asking a stupid question here, but I'll give it a go nonetheless.

Please see below...

On Mon, 30 Jul 2001, Mike Astle wrote:

> Heya Martin,
>
> First off, let me say thanks for taking the time to answer my questions.
>
> I agree that the handling of newly assigned codepoints is very sensible
> and will ease the adoption process.  I'm interested in what happens to
> "reassigned" codepoints.  To use the language of Section 6 of the draft,
> what if a character in MN changes mappings between two versions of
> nameprep?  That is:
>
> nameprep_version1( X ) = A
> nameprep_version2( X ) = B
>
> where X is in MN and A and B are in AO.  X remains in MN.
>
> 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?
>
> -mike
>
> On Mon, 30 Jul 2001, Martin Duerst wrote:
>
> > Hello Mike,
> >
> > Here's a short summary.
> > The main thing that can happen is that new characters get
> > defined in Unicode/iso10646. For these codepoints, the
> > current version of nameprep requires that registrars/registries/
> > dns administrators reject such domain names, otherwise it would
> > be possible to have domain names with undefined characters.
> >
> > After new characters have been defined, nameprep will be updated.
> > Some of the new characters (those that make sense in domain names)
> > will be newly excluded, others will be prohibited. New implementations
> > of nameprep can then use the new rules, and registrars/registries/
> > dns administrators can start to add names with such new characters.
> >
> > For clients on the resolving side, nameprep says that they should
> > not reject names with unassigned characters. So for the new characters,
> > client software will not have to be updated.
> >
> > That's basically how it works, and how it is described in the
> > Internet-Draft. Please read it again. If you have any suggestions
> > on how to improve the wording, please send them in (of course,
> > suggestions on different ways of handling the problem of newly
> > assigned characters are also of interest, but I think we are
> > pretty sure we got the most reasonable solution for what is
> > inherently not an easy problem).
> >
> > Regards,   Martin.
> >
> > 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
> > >fo 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."
> > >
> > >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)?
> > >
> > >-mike
> > >
> >
> >
>
>

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 02 Aug 2001 22:30:34 +0200

> might be asking a stupid question here, but I'll give it a go nonetheless.

As myself and Mark came up with section 6, I will respond to this.

>> nameprep?

According to Unicode Consortium, this will not happen. Yes, it happened a
few months ago, but that was a change that was agreed could be made at that
point in time as the tables are not referenced by any standard (yet). The
same decision would be different if IDN/Nameprep was a done deal.

I got this as a response when I as liason from IETF asked this very
question.

>>  That is:
>> 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

See above, forbidden in the Unicode Consortium.

   paf

---

From: David Hopwood <[email-masked]>
Date: Thu, 02 Aug 2001 23:24:03 +0100

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

> Is this kind of remapping forbidden by the draft or an associated

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:
> of the nameprep draft:

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

> 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 <[email-masked]>

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