Re: [radext] WGLC #1 for draft-ietf-radext-nai-03

[Alan DeKok <[e-mail]>]

Bernard Aboba wrote:
> [BA] Assuming that the realm is encoded in UTF-8 (which I believe the
> draft can require), I don't see why proxy P would have insufficient
> information.

  From the Unicode docs:

http://unicode.org/reports/tr15/#Versioning

...To see what difference the composition version makes, suppose that a
future version of Unicode were to add the composite Q-caron. For an
implementation that uses that future version of Unicode, strings in
Normalization Form C or KC would continue to contain the sequence Q +
caron, and not the new character Q-caron, because a canonical
composition for Q-caron was not defined in the composition version. See
Section 5, Composition Exclusion Table, for more information.
...

  And later:

...
If an implementation normalizes a string that contains characters that
are not assigned in the version of Unicode that it supports, that string
might not be in normalized form according to a future version of
Unicode. For example, suppose that a Unicode 5.0 program normalizes a
string that contains new Unicode 5.1 characters. That string might not
be normalized according to Unicode 5.1.
...

  i.e. End points and proxies will necessarily have different versions
of Unicode.  Endpoints (by definition) know about the Unicode version
that they have installed.  Therefore, they can normalize the realm.

  Proxies will very often have older versions of unicode than endpoints.
 Therefore, by the Unicode docs above, they will be unable to create a
NFC form when the endpoint sends them non-normalized strings.

  Therefore, proxies will receive multiple representations of the "same"
name, and will be unable to determine that they are the same.  The only
action that proxies can take is two treat two different strings as being
different.  Even though updated unicode specs say that they are
normalized to the "same" string.

>  The "opaque string" comparison doesn't even work for
> realms which contain no international characters.  For example,
> "exAMPLE.com" and "example.com" would not be recognized as equivalent. 

  Well, yes.  I ignored ASCII-only names in my example.  I was trying to
focus on i18n names.

  Alan DeKok.