Re: [idn] WG last call documents

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

[this is part 1 of a multi-part response]

"Adam M. Costello" wrote:

> "Eric A. Hall" <ehall@ehsco.com> wrote:

> > The point here is that EVERY network service has its own
> > considerations.  Demanding that all services implement a user-level
> > feature is absurd.
> 
> We recommend, we don't demand.

 | 2) ACE labels SHOULD be hidden from users whenever possible.

Just to be clear, is your argument that the use of SHOULD does not impose
mandatory behavior? See 2119:

 | may exist valid reasons in particular circumstances to ignore a
 | particular item, but the full implications must be understood and
 | carefully weighed before choosing a different course.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SHOULD defines *default* behavior, it is mandatory UNLESS there is a
reason NOT to do it.

The word you are looking for is MAY, but I would argue with that as a
default position as well.

> And we don't try to apply the user-level feature in absurd places,
> we say "before a domain name is displayed to a user or is output into
> a context likely to be viewed by users".

The problem I have here is that you apply to ALL places, some of which are
absurd, some of which are not. You need to choose your defaults with
greater position. The default you have chosen results in tremendous
absurdities. Consider the following DEFAULT mandatory interpretation:

  From: <support>
  To: <customer>

  Please add zz--gobbledygook to your sendmail.cf file

which is converted BY DEFAULT into

  Please add <IDN> to your sendmail.cf file

Or, consider a web-based tutorial explaining how IDNA works:

  Ignore all of the munchkins behind the curtain, the basic principle
  is as follows:

    a domain name is encoded per punycode
    a prefix of zz-- is appended to the encoded output
    thus the domain name of <IDN> is encoded as zz--gobbledygook

which is converted BY DEFAULT into

    thus the domain name of <IDN> is encoded as <IDN>

Congratulations on producing a specification that cannot be used to
document itself. Everytime an example is given, the example is
transliterated. :/

> Maybe you think that description is too broad.  Suggest
> some alternative wording.  But we need to give some sort of
> encouragement for ToUnicode to be applied in some situations.

  1) Connection identifiers (as used for forward lookups by
     application clients, or as generated by reverse lookups)
     MAY be transliterated for display purposes, although
     careful consideration is to be given to any effects such a
     conversion may have on any secondary applications.  For
     example, if a utility or library is commonly used by
     multiple applications as part of a network service, a
     separate function call or command-line switch may be needed
     to generate internationalized domain names as output.

  2) Domain names which are provided as protocol data MUST NOT
     be transliterated, except where the governing
     specification  explicitly permits and describes such usage.

  3) Domain names which are provided as structured data (such
     as email addresses, URLs, and other common data-formats)
     MUST NOT be transliterated, except where the governing
     specification explicitly permits and describes such usage.

  4) Domain names which are provided as unstructured data in
     application output MUST NOT be transliterated, except where
     the governing  specification explicitly permits and
     describes such usage.

I think we all agree on 2 and 3. I don't think you have given 1 much
consideration, but think about things like tcpdump or netstat as examples
of where this needs to be treated gingerly. You seem to be suggesting that
an application should be able to intuit where 4 should or should not be
applied. As the two examples above illustrate, rule #4 is also needed if
there is to be any consistency in implementations.

> > CONVERSION MUST ONLY OCCUR WHERE A PROTOCOL OR DATA-FORMAT EXPLICITLY
> > DEFINES THE BEHAVIOR.
> 
> That would defeat the whole point of IDNA, which is to allow
> applications to use internationalized domain names with legacy
> protocols and interfaces, without having to revise those protocols
> and interfaces.

I'm sorry that you are operating under that belief. As I have pointed out
multiple times on the mailing list, IDNA serves a single objective of a
backwards-compatible encoding format. It does not bring i18n domain names
to legacy applications, protocols or data-formats by itself.

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