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

[Mike Astle <astle@new.net>]

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