Re: [idn] I-D ACTION:draft-ietf-idn-idna-03.txt

["Soobok Lee" <lsb@postel.co.kr>]

I found the following addition in  section 2.1.4 of new IDNA-3:

>If an application decodes an ACE name but cannot show all of the
>characters in the decoded name, such as if the name contains characters
>that the output system cannot display, the application SHOULD show the
>name in ACE format instead of displaying the name with the replacement
>character (U+FFFD). This is to make it easier for the user to transfer
>the name correctly to other programs. Programs that by default show the
>ACE form when they cannot show all the characters in a name part SHOULD
>also have a mechanism to show the name with as many characters as
>possible and replacement characters in the positions where characters
>cannot be displayed.  (from IDNA-02)

>In many cases, the application doesn't know exactly
>what the underlying rendering engine can or cannot display.  (new)

I suggest to add the following sentence to the end of this paragraph:

  Likewise, in some cases,  end users don't know exactly what characters
the rendered glyphs represent, especially when they are not familiar
with the glyphs or the glyphs have other similarly-looking glyphs.

>In addition to the condition above, if an application decodes an ACE
>name but finds that the decoded name was not properly prepared according
>to [NAMEPREP] (for example, if it has illegal characters in it), the
>application SHOULD show the name in ACE format and SHOULD NOT display
>the name in its decoded form. This is to avoid security issues described
>in [NAMEPREP].

I suggest to insert the following sentence before the last sentence above:

  If the decoded ACE name contains ambiguous characters that are allowed
 in [NAMEPREP] but may cause confusion to end users, the application
 SHOULD display the name not only in its decoded form  but also
 in ACE format or in disambiguating user interfaces.


Soobok Lee, lsb@postel.co.kr


----- Original Message -----
From: <Internet-Drafts@ietf.org>
To: <IETF-Announce:>
Cc: <idn@ops.ietf.org>
Sent: Wednesday, July 25, 2001 7:35 PM
Subject: [idn] I-D ACTION:draft-ietf-idn-idna-03.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Internationalized Domain Name Working Group
of the IETF.
>
> Title : Internationalizing Host Names In Applications (IDNA)
> Author(s) : P. Hoffman, P. Faltstrom
> Filename : draft-ietf-idn-idna-03.txt
> Pages :
> Date : 24-Jul-01
>
> The current DNS infrastructure does not provide a way to use
> internationalized host names (IDN). This document describes a mechanism
> that requires no changes to any DNS server or resolver that will allow
> internationalized host names to be used by end users with changes only
> to applications. It allows flexibility for user input and display, and
> assures that host names that have non-ASCII characters are not sent to
> DNS servers or resolvers.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-03.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-idn-idna-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-idn-idna-03.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>