|
> > o Normalization requirements, as specified in Section 2.2 of > > [RFC4013], are also designed to assist in comparisons. > > > > [BA] This assumes that the NAI is being entered by a user, rather than > > being automatically configured, which is often the case. Why should > > normalization be required for an automatically configured NAI? > > Perhaps normal form when multiple encodings are possible? RFC 5198 > defines a "normalization form NFC", which could apply here. I think the issue is *when* the NAI is normalized. For example is the RADIUS server expected to do the normalization, or is it the client? If the server has the responsibility (or if it can guarantee that the client is always automatically configured), then client normalization isn't needed. > > [BA] It seems that the set of prohibited characters should be the same > > within IDNAbis as within a realm that is also an FQDN. However, this > > statement ensures that they will be different since RFC 4013 and IDNAbis > > are not in sync. Why not just cite IDNAbis? > > Ok... is there a draft with ABNF for internationalized domain names, > *before* the punycode encoding? The closest I've found is email > internationalization (RFC5234), which is "experimental". That is the closest document, I believe. While the extensions specified in the document are experimental, the encoding isn't -- it's been in use for quite some time. > > Can't we just say that the realm is required to be registerable as an > > FQDN, and that registry and IDNAbis restrictions must be obeyed? This > > would leave sufficient flexibility for registry-specific restrictions. > > That might be simplest. Some references to John Klensin's RFCs on registry behavior would probably be appropriate. > > > The realm name is an "IDN-unaware domain name slot" as defined in > > [RFC3490]. That is, it can contain only ASCII characters. An > > implementation MAY support Internationalized Domain Names (IDNs) > > using the ToASCII operation; see [RFC3490] for more information. > > > > [BA] Given that EAP and RADIUS specifications specifically mandate > > UTF-8 usage, this appears wrong. > > I think it's referring to the punycode version of the realm. In which > case I'm left wondering where the ABNF is for the *non* punycode version > of the realm What's wierd is that the ABNF actually includes support for UTF-8 characters. Last time I looked, this appeared to be supported for *both* the username and the realm. > > The responsibility for the conversion of internationalized domain > > names to ASCII is left for the end systems, such as network access > > clients and AAA servers. Similarly, we expect domain name > > comparisons, matching, resolution, and AAA routing to be performed on > > the ASCII versions of the internationalized domain names. This > > provides a canonical representation, ensures that intermediate > > systems such as AAA proxies do not need to perform translations, and > > can be expected to work through systems that are unaware of > > international character sets. > > This is completely and totally wrong, for a host of reasons. For one, > no one does this. (AAA implementors or roaming providers). For two, > systems that are unaware of international character sets need only to > *route* on the realm name. They don't need to *interpret* it, or to > *print* it. As a result, simple checks for equality are good enough. > i.e. "is the realm in this packet identical to the realm an > administrator preconfigured?" One might want to normalize the realm prior to doing the lookup in the realm table. But I agree that this paragraph packs a lot of error into a small space. > > [BA] A more sensible approach would be to require conversion of UTF-8 > > to punycode as specified in IDNAbis. > > Only when the realm name is used to perform DNS lookups. In that > case, the DNS resolving library will Do the Right Thing. Within the AAA > system, the realm MUST be left as UTF-8. Yes, only when DNS lookups are needed. Unfortunately, not *all* DNS libraries do the right thing. For example, GetAddrInfoW() currently sends UTF-8 queries on the wire, not punycode. On *NIX systems, I've seen applications use libidn to do the conversion prior to calling name resolution APIs. |