Re: [idn] WG last call summary

["Eric A. Hall" <ehall@ehsco.com>]

"Eric A. Hall" wrote:

> The new text should essentially state that ...

Section 6.2 of draft-hall-dm-idns-00.txt can be partially adapted for this
purpose. Excerpted and adjusted:

    *   Protocol transaction data. If a protocol supports UTF-8
        encoded  internationalized domain names as parameters to
        commands or responses, UTF-8 encoded IDNs SHOULD be
        used wherever they are allowed. If UTF-8 is not
        supported by the protocol, the ACE equivalents of those
        domain names MUST be used. Protocols that wish to
        provide UTF-8 encoded domain names as protocol data
        as extended functionality MUST provide negotiation
        services which clearly distinguish the IDN encoding to
        be used.

    *   Structured data-types. Structured data-types that
        incorporate domain names as key elements (such as URLs
        and email addresses) MUST be processed according to the
        rules which govern those data formats. Applications MUST
        NOT perform ToUnicode conversions against structured
        data-types unless this conversion has been explicitly
        prescribed by the governing specifications. In some
        situations, new data-type formats will be required in
        order for IDNs to be safely encapsulated.

    *   Unstructured data. Domain names that appear within
        application output as unstructured data (such as email
        message bodies or HTML documents that simply reference
        an IDN, but not as structured data), are subject to the
        restrictions imposed by the specifications which govern
        that data, and by the desires of the users who create
        that data. Generally speaking, it is RECOMMENDED that
        applications allow users to enter or view domain names
        in their preferred encoding formats wherever this is
        allowed, but that any conversions which are subsequently
        applied to that data should use UCS as the translation
        intermediary, so that the IDNs are properly converted
        along with the rest of the application data.

> If the sanctity of the existing data-types are preserved, that won't
> break anything (or as much, anyway), since only the new data-types
> will be able to use native IDNs.

clarification: "only the new data-types [or those data-types which have
been extended by the governing bodies] will be able to use native IDNs."

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/