Re: [idn] Alternative Solutions

[John C Klensin <klensin@jck.com>]

--On Wednesday, 02 May, 2001 18:55 -0700 Kenneth Whistler
<kenw@sybase.com> wrote:

>> First, let's make sure we all mean the same thing when we say
>> "ACE". When I say "ACE", I mean a reversible algorithmic
>> mapping from Unicode strings to LDH strings.
>> 
>> What started this thread was the possibility that patents
>> might prevent us from using an ACE.
> 
> Has it actually been determined that the WALID patent covers
> *all* possible "reversible algorithmic mappings from Unicode
> strings to LDH strings"? That seems like a stretch to me.

As I understand the patent claims, and the claims about them,
there is no practical way to "actually determine that" other
than to try to litigate (and invalidate) the patent.  But, from
reading the correspondence with Walid, and based on what I've
been told several times, the main threat is to IDNA, not to the
set of ACE proposals themselves.

In any event, while I hope we aren't forced to go there (whether
any of those ideas are good ones is another question),
draft-ietf-idn-dumb-00 is an attempt to drive a stake in the
ground relative to some ACE methods that are certainly
unencumbered and/or extremely defensible.  Summary for those who
haven't looked at it (those who have, or who have otherwise
gotten the point, can stop reading here):

* The use of simple "hexification" produces an ACE, is extremely
old in terms of prior art use.  When 32-bit machines and octets
started to become common, they were considered an obvious
extension from expressing characters, and portions of
then-common 18 and 36 bit machine words, in octal, which goes
back even further.  Hex and octal representatives have been
applied in enough different areas that the applicability of the
latter to the DNS should be obvious to an idiot, much less a
skilled practitioner.

* A reference to a character in a code table by its row and
column position, and the joining (catenation) of row and column
(or column and row) positions together, go back at least to the
first BCD table I saw and probably longer.  Such a reference
also generates an ACE, or several different ones, some of which
are slightly different from the hexification ACE.   And, again,
these have been widely enough applied that applicability to the
DNS would be quite obvious (as would be simply inserting a
string of the form "UxNNNN", another ACE.

* Taking the simple binary representation of a code point, or
some other value, from some particular character set coding and
representing it by conversion into a different number base,
where the base is considerably larger than 10, has been long and
widely used in the Internet and elsewhere.   If Roman alphabetic
characters from the ASCII alphanumeric set are used to represent
the "digits" above nine, the mechanisms form ACEs.   The Base64
coding of MIME was, as far as I know, the first of these to be
widely deployed.  But it predates any patent that might be filed
today by a safe margin and, even then, was by no means the first
of these codings (e.g., if I recall, a slightly different Base
64 encoding was used in the first version of Privacy Enhanced
Mail).  Again, the range of applications have been broad enough
that application to the DNS is obvious.

* Taking binary strings, compressing them using a conventional
method (e.g., dictionaries or string length), and then encoding
the result by hexification or coding to some larger base using
letters and/or ASCII symbols also produces an ACE.  And the
sequence of operations is also historically well-known and its
application to a new area should be obvious to anyone familiar
with even a small fraction of those applications.

In Internet time first two approaches data from roughly the time
dinosaurs roamed the earth and the others aren't much more
recent.  And there are more of these, enough to give the WG a
very broad range of choices on the ACE front.

Whether they are the Right Thing to do is another matter.

    john