COM/NET informational message

Tue Jan 7 17:40:43 UTC 2003

At 17:00 07/01/2003 +0000, Verd, Brad wrote:

>>This message explains an upcoming change in certain behavior of the
>>com and net authoritative name servers related to internationalized
>>domain names (IDNs).

Hi,

This is to inform you that Characterisation GmbH (www.characterisation.de) 
has patents pending Ref PCT/DE02/00632 filed 28th February 2001. It appears 
that the method of resolution used by VGRS in the announcement below uses 
this process. Characterisation GmbH is willing to discuss licence agreements.

Best regards

Stephen Dyer
Geschäftsführender Gesellschafter
Characterisation GmbH

>>VeriSign Global Registry Services (VGRS) has been a longtime advocate
>>of IDNs. Our IDN Test Bed has been active for over two years and we
>>have followed and supported IETF developments in the IDN area. The
>>protocol for IDNs developed by the IETF's IDN Working Group has been
>>approved by the IESG and we anticipate that RFCs will be published
>>soon. That protocol, Internationalizing Domain Names in Applications
>>(IDNA), calls for changes to individual applications to support IDNs.
>>VGRS has developed a plug-in, called i-Nav, for Microsoft's Internet
>>Explorer browser to support IDNs in a manner consistent with IDNA.
>>i-Nav is free and more information about it is available at
>><<http://www.idnnow.com>>.
>>
>>Before IDNA, some application developers had developed proprietary
>>mechanisms designed to support IDNs. The Internet Explorer browser,
>>for example, sends a DNS query in UTF-8 or another, local encoding
>>when a user types a domain name with characters other than letters,
>>digits and the hypen in the address bar. These efforts, however, were
>>not entirely successful. For example, if such a domain name ends in
>>com or net these queries reach the com/net name servers and fail.
>>
>>Our research indicates that the average user expects IDNs to work but
>>does not understand the need for additional software to support this
>>functionality. Such users attempt to enter IDNs in their browsers,
>>but when the queries fail, they become frustrated and do not know
>>what action to take to enable IDNs. They are unaware that downloading
>>a browser plug-in such as i-Nav would enable IDN resolution.
>>To improve this user experience and to encourage the adoption of an
>>application that supports IDNA, VGRS is announcing a measure intended
>>to stimulate widespread distribution of the i-Nav plug-in. Starting
>>on January 3, 2003, some queries to the com/net name servers that
>>previously failed with a DNS Name Error (NXDOMAIN) response will
>>instead return an address (A) record. Any queries for A records with
>>at least one octet greater than decimal 127 in the second-level label
>>will trigger this A record response. For example, a query for the A
>>record for "foo?.com", where "?" represents an octet with a value
>>greater than 127, would return an A record rather than NXDOMAIN
>>response. The goal is to match unrecognized domain names generated by
>>browsers attempting to resolve IDNs. Since browsers construct DNS
>>queries for such IDNs using UTF-8 or a local encoding, and since
>>these encodings use octets with all possible values (i.e., from 0
>>through 255), the presence of octets with values greater than 127 as
>>described above can indicate a web browser's failed IDN resolution
>>attempt.
>>
>>The A record that will be returned by VGRS points to a farm of web
>>servers that will attempt to resolve the query. The browser that sent
>>the original DNS query will connect to one of these web servers and
>>its HTTP request will contain a Host header with the representation
>>of the IDN originally entered by the user in the address bar. The web
>>servers will attempt to interpret the contents of the Host header. If
>>the Host header corresponds to an IDN registered in VeriSign's IDN
>>Test Bed, the web server will return a page that gives the user an
>>opportunity to download the free i-Nav plug-in. The page will also
>>allow the user to navigate to the corresponding IDN web site via an
>>HTTP redirect. If the contents of the Host header cannot be matched
>>to an IDN registered in the Testbed, the web server will return an
>>HTTP 404 response.
>>
>>If a user downloads and installs the i-Nav plug-in, his or her
>>browser will convert any IDNs entered to ASCII compatible encoding
>>(ACE) format, according to the method described in IDNA. As a result,
>>subsequent DNS queries will use ASCII characters only.
>>The user experience for web browsing will change only slightly from
>>the current experience if the contents of the Host header cannot be
>>interpreted. If the web farm cannot match the Host header to an IDN,
>>the user will see an error page resulting from the HTTP 404 error
>>returned, rather than an error page resulting from a DNS NXDOMAIN
>>response. The web servers refuse connections on all other UDP and TCP
>>ports, so other network services are minimally affected.
>>
>>The overriding goal is to improve Internet navigation by encouraging
>>widespread adoption of software supporting the emerging IETF
>>standards for IDNs. These measures allow distribution of such
>>software.
>>
>>- --------
>>Brad Verd
>>Resolution Systems Operations Manager
>>VeriSign Global Registry Services
>><<http://www.verisign-grs.com>>
>>Email: bverd at verisign.com
>>- --------
>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: PGP 7.1
>>
>>iQEVAwUBPhXOL/Al8hAO5uPhAQFASQgAuu9y0LF5/2SuddtdRNDbyUd9ccNkPwnw
>>fip2bSh1EW7+b2jykw2tDxIAl2iejg2GVwhXmMiGOdm+FBOyBPtbQaM/DMCXHJ3r
>>JlaEmKgqKwjyVHVxxEmNYHQ0uU5V8khskWorhsobjDb+l5bPumkUaGsVnRvTMFGR
>>CZTrHdn1bo1Q0IvfD1IBCq5qUugRimLc47TZdibYccCty8TmdtL/8jz4r6W90JPL
>>KxXdjMpk6SOQj1SqErV/S6ypd5TFpXi1fEv6QEIrsqVoMCdELjFRZbmDTAMObvcR
>>MpS75jUWbNmO7KENJCyacWzLTkh951+dszszwYig9jGIIXEpmrYGFA==
>>=g2df
>>-----END PGP SIGNATURE-----
>
>
>--
>Joel Rowbottom BSc.(Hons) - vaguely human and mostly harmless
>Self-confessed was-kid, Unix geek & Net addict since 1991
>Personal: http://www.joel.co.uk | Pics: http://photos.jml.net
>