Subject: [Ietf-not43] firs.pl 0.02, idna features

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Sep 3 11:34:57 2003

The 0.02 version of firs.pl demonstrates the IDNA transparency I was
describing earlier. You can provide it with IDNA input, and you can also
give it an --idna switch to force IDNA output on fields that contain i18n
domain names.

Here's ex?mple.com in it's full i18n-native glory:

$whois -h goose.ehsco.com ex?mple.com
 ...
[Entry: cn=ex?mple.com,cn=inetResources,dc=ntrg,dc=com]

         Network resource (cn): ex?mple.com
         Organization name (o): Ex?mple Widgets, AB

                        street: Drammensveien 18
      inetAssociatedDnsDomains: example.com
                             l: Oslo
    inetAssociatedIpv4Networks: 192.168.11.0/24
              inetTechContacts: hostmaster@ex?mple.com
                             c: NO
                    postalCode: 0244
           inetGeneralContacts: info@ex?mple.com
                   description: Example Widgets' Scandinavian Subsidiary
       inetAssociatedAsNumbers: 65535
                    labeledURI: http://www.xn--exmple-cua.com/ Ex?mple

In that example, all of the values use the domain name syntax restrictions
appropriate for each attribute. EG, the labeledURI field is UTF-8 except
that the URI element is seven-bit, while the domain and contact fields use
the i18n domain syntax.

Here's the same entry in full IDNA encoded mode:

$whois -h goose.ehsco.com xn--exmple-cua.com --idna

[Entry: cn=ex?mple.com,cn=inetResources,dc=ntrg,dc=com]

         Network resource (cn): xn--exmple-cua.com
         Organization name (o): Ex?mple Widgets, AB

                        street: Drammensveien 18
      inetAssociatedDnsDomains: example.com
                             l: Oslo
    inetAssociatedIpv4Networks: 192.168.11.0/24
              inetTechContacts: [email-masked]
                             c: NO
                    postalCode: 0244
           inetGeneralContacts: [email-masked]
                   description: Example Widgets' Scandinavian Subsidiary
       inetAssociatedAsNumbers: 65535
                    labeledURI: http://www.xn--exmple-cua.com/ Ex?mple

The contact and domain descriptions are now IDNA encoded, while the other
fields continue to use their native forms.

The important thing here is that these are the same canonical entry, and
that the conversion is all done by the client. The protocol message uses
UTF-8 for the domain and contact fields in every event. Specifically, the
client super-normalizes the query data on input into its UTF-8 form before
passing the query, and super-normalizes the normalized response data on
receipt, allowing it to use any of that data in either format. The strict
syntax rules allow all of this to happen predictably and transparently,
while simplifying the protocol greatly.

Any client can choose either format for their local presentation services
according to the capabilities and/or desires.

As before, use the undocumented --source switch to download the firs.pl
script to your workstation for local use. It will query the demonstration
server from remote if you have the modules and whatnot.

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