RE: [idn] compatibility chars in draft-ietf-idn-nameprep

[RJ Atkinson <rja@inet.org>]

At 00:19 16/08/00, Jonathan Rosenne wrote:
>I think it is more friendly to convert them at entry. But this is no
>contradiction: the user agent converts them, afterwards they are not
>allowed.

        Good point.

        I'll make an observation about IETF standards for existing DNS.  
The IETF standards for existing DNS don't say anything about
the "DNS Resolver API" [1] and don't say anything about the 
user-interface.  They do specify canonicalisation/normalisation
rules and there is an RFC that limits "hostnames" to a subset of
domain names.

        So, for that reason, I think that while it is reasonable
to prohibit certain characters from use "on the wire", it is
unreasonable to prohibit all user interfaces from converting from
a prohibited character to an *fully equivalent* allowed character.
It would be worth documenting the issues raised with such conversions,
but prohibiting a particular user interface operation outright seems 
outside the scope of the IETF standards process.

        Regardless of the above, we do need to have canonicalisation
and normalisation rules for IDNs so that we are fully interoperable
on a global basis.  In short, we need internationalisation rather
than localisation. :-)

Regards,

Ran
rja@inet.org

[1] IETF does publish some API specifications as "Informational" RFCs,
        where an Informational RFC is not any sort of IETF standard.
        These are generally then taken into the IEEE POSIX standards
        group, which is in the business of standardising APIs.  Not
        all get taken to IEEE POSIX and not all that get taken there
        are approved by IEEE POSIX.  I would suggest that the IDN WG
        might consider documenting an IDN API as an Informational RFC,
        but only AFTER all of the other issues are resolved.  Someone
        from Nominum might be able to help with the API topic when/if
        that time arises.