Mapping and Variants

[JFC Morfin]

The basic concept documented in RFC 3402 DDDS algorithm.

   The "i" flag indicates that the ERE matching SHALL be performed in a
   case-insensitive fashion.  Furthermore, any backref replacements MAY
   be normalized to lower case when the "i" flag is given.  This flag
   has meaning only when both the Application and Database define a
   character set where case insensitivity is valid.

This is the case when the chosen "x.--" means an "i" flag. This is not
the case in the default "xn--" which is appropriate to support ASCII
English and its possible caracter variations (ex. people foreign
names, or foreign TM).

jfc



2009/3/6 Andrew Sullivan <ajs at shinkuro.com>

> On Fri, Mar 06, 2009 at 12:13:35PM -0500, John C Klensin wrote:
>
> > Well... A different way to look at this is that you can have all
> > of the case sensitivity, case-independent matching, and case
> > preservation you like in A-labels (as well as all other labels
> > that contain ASCII characters and maybe some others).  IDNA does
> > not change the DNS.
> >
> > A different way to state Erik's observation/suggestion would be
> > that, in IDNA-aware "slots" use (on registration, lookup,
> > storage in files, etc.) of anything but lower case needs to be
> > really strongly discouraged.   That would imply that, in a given
> > "slot", the decision that IDNA can be used is a decision that
> > upper case is discouraged and violence may be done to it if it
> > appears.  That is an application-layer design tradeoff, not a
> > statement about the DNS or a problem for 1034.
>
> Actually, putting something like those two paragraphs together might
> make this idea rather more palatable.  The more I think about this the
> more I think it has a certain appeal.  It has slightly odd effects,
> because the traditional DNS case-preservation does go all the way
> through an IDNA-unaware application, and does _not_ go all the way
> through an IDNA-aware application.  I am going to post a note to
> various dns weenies I know to try to get review of exactly this
> suggestion, because it does seem to be a way forward.
>
> > FWIW, 1034 could easily have contained a statement to the effect
> > that one MUST NOT take a label that one receives, map it through
> > a local (as in client-side) aliasing process and then look the
> > result up as if it were the original label.   Presumably it was
> > omitted because, at the time, everyone thought it was obvious
> > (and they probably still do).  But, if 1034 prohibits a strong
> > application and registration preference for lower-case native
> > character strings in IDNA, that implicit statement would
> > prohibit any IDNA mapping at all.
>
> True.
>
> > We are doing a lot of that lately (Erik is certainly not the
> > only one).
>
> I have the feeling that may be a charge of which I am guilty, yes.
>
> A
>
> --
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090306/b0a6d9af/attachment.htm