Subject: issue 53 -- i18n requirements for FQDNs

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Feb 2004 21:17:39 +0200

Pekka,

> Looking up RFC 3280, from the Trust Anchor option
> (6.2.3), it strikes me that the FQDN part (at least) may be something
> that may be subject to the i18n requirements for strings in the
> specifications (something that always comes up in IESG review, and is
> in ID nits).  I know very little about this myself, but this may be
> something that a subject matter expert from apps area (for example)
> might be able to help with.

I'm not an expert on this either, but it seems that the FQDN
internationalization cab be solved rather easily. Specifically,
RFC 3490 defines internationalized domain names (IDNs) through ToAscii
and FromAscii operations that map international names to good
old FQDNs and map. Protocols with with FQDN slots can most of the
time operate without awareness of IDNs.

So here are my suggested text modifications. Add to Section 6.2.3
under "Name":

     In the FQDN case the Name field 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.

--Jari

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.