Subject: [idn] Alternative Solutions

From: "Edmon" <[email-masked]>
Date: Tue, 1 May 2001 20:23:15 -0400

> At 09:26 AM 4/30/2001, Russ Rolfe wrote:
> >Instead of waiting for Walid, should we be looking at what other
> >alternatives exists.  Do people have any thoughts on what the possible
> >two-three major alternatives may be.
>
> and I entirely concur with pursuing alternatives immediately.
>

There are a number of alternatives, but I see two main streams:

Server-side ACE - ACE transformation takes place at server end
Protocol Extension - use extension mechanisms such as EDNS or other bit
flagging & use UTF

Edmon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 May 2001 17:43:53 -0700

>Server-side ACE - ACE transformation takes place at server end

If the transformation is done at the server, then the data travel from the 
client as binary.  How is that different from your second alternative?

For that matter, why bother with an ACE transformation at that point?

Please clarify.

>Protocol Extension - use extension mechanisms such as EDNS or other bit

This is a class, "dual-stack" operation.  One stack is the original system 
and the second is the new.

(By way of raising a warning flag early, one danger with this approach is 
what we have seen with IPv6.  Namely, people will try to add zillions of 
changes and features, thereby delaying the effort by years.)

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 2 May 2001 01:17:08 +0000

> Server-side ACE - ACE transformation takes place at server end

If it's on the server, it doesn't have to be an algorithmic
transformation; it can just be a distributed lookup table (which is what
DNS is anyway).

Two new resource record types could be created, one that gives the
Unicode domain name associated with an LDH (letter/digit/hyphen) name,
and one that gives the LDH name associated with a Unicode name.  This
is analogous to the A and PTR records that map between LDH names and IP
addresses in both directions.

Example scenario:  I type a Cyrillic email address into my IDN-aware
email program.  It performs nameprep and sends the result in a DNS
query using a canonical encoding (UTF-16 say).  It gets back both an IP
address (which it uses to connect to the remote SMTP server if there is
no MX record) and an LDH domain name.  It puts the LDH name in the To:
field of the message header, in order to conform to RFC 822.

Suppose the message is sent to multiple recipients.  They can all reply
to everyone in the To: field, because the domain names there are LDH
names.  Additionally, IDN-aware mail programs can do a DNS lookup on the
LDH domain names to discover the corresponding Unicode domain names, and
show the latter to the user.

I don't think this requires any changes to the DNS protocol, only the
addition of two new resource record types.

I don't like this idea as much as ACE, for two reasons:  First, the
mapping between LDH names and Unicode names cannot be done offline.
Second, there is no guarantee that the mapping is consistent in the
two directions (just as there is currently no guarantee of consistency
between A and PTR records).  It has one advantage over ACE, though:  The
LDH names can be chosen arbitrarily, and need not look like gibberish.

AMC

---

From: "Edmon" <[email-masked]>
Date: Tue, 1 May 2001 21:24:48 -0400

> For that matter, why bother with an ACE transformation at that point?

There are a number of reasons, including:
- ACE domain can be used after the DNS, such as web & mail (part of the
argument for using ACE)
- ACE domain could be used for administration purposes, for sys admins to
configure and edit zone files, etc.
- will be able to transition to the "long-term" protocol extension solution
easily

> changes and features, thereby delaying the effort by years.)

EDNS is pretty much in place and other extension mechanisms could be easily
introduced also.  As to lengthy discussions, it depends on whether we are
zoomed into providing a multilingual dns only and leave bells and whistles
to the implementors.  So long as the core platform is there, if implementors
decide to add features and delay their own roll out then its their decision.

Edmon

---

From: "Maynard Kang" <[email-masked]>
Date: Wed, 2 May 2001 09:29:19 +0800

> LDH names can be chosen arbitrarily, and need not look like gibberish.

I think that this approach would be a major impediment to e-mail users;
after all, one of the main features of e-mail is that the user can
read/compose/reply mail offline, and connect only as and when required to
send/receive.

Alternatively, the e-mail application might be absolved of any code
transformation duties and leave that entirely up to the originating SMTP
server. Since most MUAs these days depend on a relay MTA and do not send
directly to destination hosts anyway, perhaps it might make sense to do the
code conversion at that particular relay MTA instead of at the MUA itself.

The MUA would have to be made aware of the MTA's code transformation
feature though; maybe this can be achieved by an SMTP extension. But I
digress; this is not the working group to do this. =)

maynard

---

From: "Maynard Kang" <[email-masked]>
Date: Wed, 2 May 2001 09:38:21 +0800

> - will be able to transition to the "long-term" protocol extension
solution

Web & Mail involve the application layer. A DNS server-side ACE approach
would require that web and mail applications communicate in binary (ok,
8-bit, "binary" sounds a little ASCII-bigoted), and neither of these
applications are perfectly capable of doing this.

I always thought it has been established that the IDN problem does not lie
with the DNS protocol or RFC 1034/35, but rather, that the applications
will balk and die upon seeing "binary" data in places where it is not
supposed to appear.

maynard

---

From: Keith Moore <[email-masked]>
Date: Tue, 01 May 2001 23:35:39 -0400

> Server-side ACE - ACE transformation takes place at server end

even if you set up another way to do queries for IDNs
(whether this is a separate protocol or a mode bit or whatever)
you still need ACE for client protocols that only support ASCII names.

---

From: "Edmon" <[email-masked]>
Date: Tue, 1 May 2001 23:47:24 -0400

Extending your idea back to an algorithmic approach, we could set it so that
the LDH names be created using ACE and that nameservers during loading would
check that they are consistent with the unicode name.  When the LDH response
is received by the DNS, it will be utilized for other protocols such as
mail.
Edmon

---

From: "Maynard Kang" <[email-masked]>
Date: Wed, 2 May 2001 12:18:43 +0800

Actually I think there was a similar approach presented by the JPNIC team in
Pittsburgh, which proposes using the DNS server to perform canonicalization.
This can be extended to do transformation to ACE or mapping to an LDH.

However, the problem with these solutions is that we are lacing DNS with
meta-records which cause additional burden on applications as they have yet
again another layer to deal with when processing these identifiers.

Again, this makes me seriously doubt that a pretty solution to
internationalized identifiers can be found by tweaking DNS as it is.

maynar

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 May 2001 03:53:28 -0400

> you still need ACE for client protocols that only support ASCII

Unless we go either into a new class (or some EDNS-required
mechanism) that prevents an "international" name from being seen,
and an "international" query from being made, except by IDN-aware
applications.  If unconverted client protocols, and unconverted
clients using converted protocols, cannot access
international-format names or have such names returned to them,
one doesn't _need_ ACE to protect them from damage.

There are, of course, still some advantages of using ACE
encodings rather than something else with such mechanisms, but
they could presumably be used without a tagging prefix, saving
some of the strange appearance of the things and four characters
of label length.

     john

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 02 May 2001 11:28:26 +0200

--On 01-05-01 17.43 -0700 Dave Crocker <[email-masked]> wrote:

> If the transformation is done at the server, then the data travel from
> the  client as binary.  How is that different from your second
> alternative?
> 

...and how does this solve the problem with domainnames used as protocol
parameters in applications?

  paf

---

From: Keith Moore <[email-masked]>
Date: Wed, 02 May 2001 08:26:30 -0400

> applications.  

*AND* we insist that "international" names are never leaked 
*by any protocol* (including, say, SMTP) to an application that
doesn't understand them.  In practice this means not just a mode
bit for DNS but also a mode bit for every protocol that carries
DNS names.

which doesn't seem like a very attractive path to me.

Keith

---

From: "Edmon" <[email-masked]>
Date: Wed, 2 May 2001 20:03:57 -0400

What about this:
since for IDNA we assume that there needs to be a client upgrade anyway,
adding more stuff should be ok.

- client sends DNS request with mode bit in UTF
- Server returns UTF=A/A6/MX, etc AND UTF=LDH(in an ACE)
- client then chooses to use straight UTF or LDH info when using DNS info in
other apps
  based on - if the other app is IDN aware, it uses UTF with mode bit
                 - if the other app is nonIDN aware, it uses LDH in ACE

This gives us the benefits of ACE being able to be used for other protocols
which are not upgraded yet and also provides a clear path foward towards a
UTF+mode bit longer term solution.

Edmon

---

From: Keith Moore <[email-masked]>
Date: Wed, 02 May 2001 20:52:48 -0400

Edmon,

I'm not at all sure it's desirable to have a DNS query protocol which 
allows the server to specify the relationship between the native form 
and the ACE form - you want consistent results regardless of whether
the lookup is done using native or ACE format, and a protocol like you
describe is almost begging servers to play games with the relationship
between the two and to produce inconsistent results.

and even if you allow queries in a native format, you also have to
support queries in ACE format, for the benefit of legacy apps that
don't have any specific knowledge of IDNs but still need to be able 
to look up ACE IDNs.  so I'm not sure how much this helps.

Keith

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 3 May 2001 01:21:33 +0000

This discussion seems to be getting more complicated than necessary.

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.  If we're going to use an ACE at all, we might
as well stick with IDNA, so the alternative ideas, whatever they are,
should not require the use of an ACE.

The main problem that IDN needs to solve is the problem of higher-layer
protocols and software assuming that domain names contain only LDH
characters and dots.  So for every Unicode domain name, there needs
to be an LDH domain name that these older protocols and software can
use.  If we're not allowed to do the transformation algorithmically, the
obvious other option is a giant lookup table.  And that's what DNS is.

So take the IDNA architecture, replace the ace_encode operation by a
dns_lookup_ldh_of(unicode_name) operation, and replace the ace_decode
operation by a dns_lookup_unicode_of(ldh_name) operation.  Everything
else can stay the same.

That bears repeating:  Everything else can stay the same as IDNA.
Things that work or don't work in IDNA will still work or not work in
the new scheme.  The only exceptions are:

  * Applications now need to be online to do these operations, whereas
    in IDNA they could be offline.

  * IDNs can exist only in domains served by upgraded DNS servers that
    know the new resource record types, whereas IDNA requires no changes
    to DNS.

  * The LDH name need not look like gibberish (as in IDNA), but
    can be chosen at the whims of the registrants and/or name
    server administrators.  (Some may choose to manually select
    meaningful LDH names, while others may choose to use an algorithmic
    transformation for ease of administration, but there is no need for
    standardization, or even publication, of the algorithm.)

As someone already pointed out, this is just adding another layer.  Just
as domain names are a layer of abstraction on top of IP addresses,
mapped back and forth by A and PTR records, IDNs would be a layer of
abstraction on top of LDH domain names, mapped back and forth by two new
record types.

I don't like this scheme very much.  I'd prefer IDNA.  But if IDNA were
not an option, this would be an obvious thing to look at instead.

Keith Moore <[email-masked]> wrote:

> *AND* we insist that "international" names are never leaked *by any
> protocol* (including, say, SMTP) to an application that doesn't
> understand them.  In practice this means not just a mode bit for DNS
> but also a mode bit for every protocol that carries DNS names.

Existing protocols carry only LDH names, so there is no mode bit.  New
protocols (or new versions of old ones) could choose to use a mode
bit, or could choose to continue to carry only LDH names, and let the
receiver look up the Unicode name if it wants to.

AMC

---

From: Kenneth Whistler <[email-masked]>
Date: Wed, 2 May 2001 18:55:06 -0700 (PDT)

> 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.

Before this discussion goes too far off track discussing alternatives,
can no one come up with a functional plugin for ace_encode and
ace_decode that avoids any particular techniques covered by the
patent, but which is still *algorithmic* and does not require online
lookup tables?

Trying to think outside the box:

Has anyone considered trying bit and byte transforms directly on
the UTF-8 encoding form, rather than on the Unicode code point?

How about some deterministic and quick compression run on the
UTF-16 encoding form of a Unicode string, and *then* rearranging
the resulting bytes to accomodate ASCII restrictions?

Something else?

Or has WALID actually gotten a patent on a generic concept without
actually specifying a particular technique to accomplish it??

--Ken

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 May 2001 00:00:35 -0400

> What started this thread was the possibility that patents might prevent

We have to use some sort of ASCII name if we expect any IDN to be usable 
in an existing application, because those applications can only deal 
with ASCII names.  

I suppose it doesn't absolutely have to be an algorithmic mapping 
between the ASCII name and the native IDN, but I really don't like 
the idea of doing the mapping on the server.  I see two problems 
with doing the mapping on the server (in addition to those that 
you've already identified):

1. it's difficult to do the mapping in a way that is guaranteed to
produce consistent results between applications using the native IDN
and applications using the ASCII form of the name.

(without this guarantee, when people upgrade to IDN-aware applications
lookups of the same names that they previously used will sometimes 
produce different results - and fail at different times - than before)

2. (sort of like #1) it's difficult to do the mapping in such a way
that the server responsible for ascii->native mapping is the same as 
that for native->ascii mapping.

(without this guarantee, we open up an opportunity for there to be
different authoritative servers - and thus conflicting authorities -
for names that should be equivalent)

however if a solution can satisfy those two constraints, it might 
be worth a try. 

--

one way to do this might be to define a new RR type that specified
that a single ASCII label and a single IDN label (both relative 
to the current zone) were equivalent.  for instance,

#####	IEQ	xyzzy

would specify to the DNS server that (native) label ##### was
equivalent to ASCII label xyzzy.

labels in IEQ records could contain suffixes (and these might
be needed for glue) but only if left and right side had the 
same suffix up to the least significant label.  Thus

#####.a.b	IEQ	xyzzy.a.b

would be legal, but

#####.a.b	IEQ	xyzzy.c.d

would not.

if such a RR appeared in the example.com zone, the servers for
that zone would know to answer queries (regardless of query type)
for #####.example.com identically to queries for xyzzy.example.com.   
in either case one or more IEQ records could be returned as additional 
information, allowing the caller to discover the mapping between the 
native IDN and the ASCII equivalent.

IEQ RRs could either be explicitly specified on a per-zone 
basis or automatically generated by the master server.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 May 2001 06:54:58 -0400

--On Wednesday, 02 May, 2001 18:55 -0700 Kenneth Whistler
<[email-masked]> 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

---

From: "Sean X. Zhang" <[email-masked]>
Date: Thu, 3 May 2001 08:28:59 -0700 (PDT)

> to LDH strings"? That seems like a stretch to me.

What can be "actually determined" has already been commented upon by John.

[...]

> actually specifying a particular technique to accomplish it??

He claimed only "a method". But it appears to be a very broad one.

From the US Patent Office's web site, www.uspto.gov, you can get the 
text of the 6,182,148 patent. Its claim 1 states (with [my comments]
in square brackets):

       1. A method of converting an internet international domain name 
          [that's an IDN] to an RFC1035 compliant format [or, an LDH string],
          where the international domain name includes non-English characters
          which are RFC1035 non-compliant, the method comprising [i.e.,
          requires at least the following]: 
              intercepting the international domain name, where the
                   intercepting is transparent to the user 
                   [this appears to be the role of the "DNS proxy" 
                   discussed at http://www.apng.org/idns/]; 
              transforming the international domain name to an RFC1035
                   compliant domain name 
                   [convert the IDN to an LDH string in any way you want,
                   reversible or not; no, a particular technique is not
                   specified for this step, and yes, this step does seem
                   to correspond to a generic concept; 
                   following steps 1, 2, and part of step 3 discussed at
                   http://www.apng.org/idns/ might be one particular
                   technique to accomplish this]; 
             automatically generating a redirector string 
                   [this is probably the string "ar.i18n.net" referred to 
                   in the "Detailed Description" section, in association 
                   with Fig. 2 and numeral "130"; if so, that would 
                   correspond to "idns.apng.org" in the "Note" section 
                   on www.apng.org/idns and the appended string in step 3,
                   above] 
                which includes information for resolving 
                   [cannot tell what information is required; maybe simply
                   another way of saying that the "redirector string" cannot 
                   be arbitrary and must be something like the ones above]
                the RFC1035 compliant domain name; and 
             appending the redirector string to the RFC1035 compliant 
                   do main [appears to be a typo; should be "domain"] name
                   [if above interpretation of "redirector string" is
                   correct, this would be the second half of step 3, above].

If my understanding of the claim language, the technology and the terminology
is correct, then yes, he seems to have a patent covering the generic concept
of converting IDNs to LDH strings. In claim 1, nothing's said about reversible
algorithmic mappings, though it seems to be broad enough to cover the concept.
In particular, his claim 1 would seem to cover the method discussed at
http://www.apng.org/idns/. 

Maybe someone could look at other claims or take a closer look at claim 1 to
see what kind of patent he has obtained?

--
Sean

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 May 2001 12:43:40 -0400

>           which are RFC1035 non-compliant, 

interesting.  are any characters in UTF-8 "RFC1035 non-compliant"?
It appears that RFC 1035 anticipated the need to store non-ASCII characters
by stating that "attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided."
(section 2.3.3, first paragraph)

> the method comprising [i.e.,
> of converting IDNs to LDH strings. 

to me, this particular claim doesn't say this at all.  

1. 'intercepting' the domain name seems to imply some sort of proxy 
(something interposed between existing components rather than having 
the components changed to explicitly support IDNs).  

2. an RFC1035 compliant domain name appears to be any string of octets 
less than 256 octets, not beginning with '.', without consecutive '.'s,
and with the labels between the '.'s less than 64 characters in length.  
with the possible exception of length restrictions on labels, ACE isn't 
needed to make a domain name RFC 1035 compliant, it's needed to make the 
domain name compliant with other protocols that expect ASCII.

3. there have been numerous proposals here that don't need any kind
of redirect - the IDN components are looked up directly rather than
via any kind of referral, and IDN lookups are made relative to the 
DNS root rather than relative to any string that is appended to a 
transformed IDN.

maybe it really would be worthwhile for a group of people to pick apart
those claims and write up an argument as to why they do or do not apply 
to one or more of the proposals on the table.  according to 2026, IETF 
as an organization cannot make any statement on the validity of a patent,
but I don't see why one or more individuals cannot try to write up an
persuasive argument and publish it as an I-D.  (if they could recruit
the assistance of some patent attorneys while doing so, so much the 
better). perhaps the document could even be published as Informational,
in due time, after appropriate review by IETF counsel.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 May 2001 10:20:07 -0700

>old in terms of prior art use.  When 32-bit machines and octets

20+ years ago, we fondly -- if irreverently -- referred to the technique as 
"half-ascii"...

d/

----------

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 3 May 2001 21:46:20 +0000

Kenneth Whistler <[email-masked]> wrote:

> Has anyone considered trying bit and byte transforms directly on the
> UTF-8 encoding form, rather than on the Unicode code point?

My intuition is that this would result in much longer encodings than
any of the ACEs considered so far.  UTF-8 is already pretty bad for
non-Latin languages.

> How about some deterministic and quick compression run on the UTF-16
> encoding form of a Unicode string, and *then* rearranging the
> resulting bytes to accomodate ASCII restrictions?

You have just described RACE and LACE.

> actually specifying a particular technique to accomplish it??

That's my impression.

Keith Moore <[email-masked]> wrote:

> that a single ASCII label and a single IDN label (both relative to the
> current zone) were equivalent.

In other words, instead of doing one lookup to map ####.%%%%.org to
foo.bar.org, you would first look up %%%%.org to get bar.org, then look
up ####.bar.org to get foo.bar.org.  This might be a good idea.  It
looks like more steps, but the single lookup of ####.%%%%.org can be
just as many steps in practice.

I still think you need two new RR types, one to map ####.bar.org to
foo.bar.org, and one to map foo.bar.org to ####.bar.org.  And there's
nothing to stop the administrator of the *.bar.org zone from making
those two pointers inconsistent, just like there's nothing to stop
people from making A and PTR records inconsistent today.  But no one can
usurp your authority.  If you want your own domains to be well-behaved,
then you make your pointers consistent.

You can encourage consistency, but there's no way to guarantee it.  For
example, some name servers today return different responses depending
on the source address of the query.  The administrator of a zone can do
anything they want with that zone.

John C Klensin <[email-masked]> wrote:

> 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

That's my impression as well, in which case it doesn't matter whether
we use an old dumb ACE or a new clever ACE, the problem is the whole
IDNA approach.  And maybe the idea of using a DNS lookup instead of an
algorithm to do the transformation still doesn't go far enough to escape
the scope of the patent.  I don't know.

Keith Moore <[email-masked]> wrote:

> are any characters in UTF-8 "RFC1035 non-compliant"?

This phrase undoubtedly intendsd to refer to section 2.3.1 "Preferred
name syntax", which says:

    However, when assigning a domain name for an object, the prudent
    user will select a name which satisfies both the rules of the domain
    system and any existing rules for the object, whether these rules
    are published or implied by existing programs.

    For example, when naming a mail domain, the user should satisfy both
    the rules of this memo and those in RFC-822.  When creating a new
    host name, the old rules for HOSTS.TXT should be followed.  This
    avoids problems when old software is converted to use domain names.

    The following syntax will result in fewer problems with many
    applications that use domain names (e.g., mail, TELNET).

The BNF that follows describes the syntax, but that syntax was relaxed
by RFC 1123 to allow labels to start with digits.

> with the possible exception of length restrictions on labels, ACE
> isn't needed to make a domain name RFC 1035 compliant, it's needed to
> make the domain name compliant with other protocols that expect ASCII.

Right, the patent claim doesn't quite say what it means.  But I think
judges usually try to interpret language "reasonably" rather than
literally.

AMC

---

From: "Sean X. Zhang" <[email-masked]>
Date: Thu, 3 May 2001 20:45:35 -0700 (PDT)

[...]

> the components changed to explicitly support IDNs).  

Proxy, such as the one shown at APNG's website, could be one way of
"intercepting". But as far as conversion goes, can "intercepting" 
be part of the "converter"? Or the "converter" be part of an existing
component? No matter what, the domain name has to be intercepted by, or
fed into, the "converter" (whether a layer, a proxy, or part of an existing
component) before it can be converted. No? The part of being "transparent
to a user" may suggest that the conversion claimed here cannot be some 
form of offline conversion. I raise these questions only because I feel
that this step does not seem to be a serious limitation as long as we
are not talking about some form of offline conversion. But, then, I can 
be wrong.

> and with the labels between the '.'s less than 64 characters in length.  

A strict reading of RFC1035 seems to suggest this. In other words, RFC1035
seems to permit any octet (with above restrictions) to appear in a domain 
name. However, in the section dealing with the preferred convention, it 
does limit domain names to use only LDH characters. On the other hand, 
the patent itself seems to equal RFC1035 compliant with English letters
only, rightly or wrongly.

Sean

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 May 2001 23:55:57 -0400

in the IETF community it has been clear for many years that DNS was
intended to be 8-bit clean, so for us the interpretation of RFC 1035
is clear.  

the interpretation may not be so "clear" (or it may be "clear" in a 
different way) to a court.  just like what is "obvious" to a person
experienced in Internet applications protocols  (and which therfore
should not be patentable) is not "obvious" to a patent examiner.

for this reason, and unfortunately, technically clueful people are 
probably not very good at trying to second-guess how technically 
clueless people will interpret technical prose.  we might be able to
come up with a compelling (to us) argument that the patent doesn't
apply because of language in 1035, but the best we can hope for is
that this would provide ammunition to a competent patent attorney
who isn't working for the Dark Side.

Keith

---

From: "Edmon" <[email-masked]>
Date: Fri, 4 May 2001 13:26:41 -0400

From my understanding, the Walid Patent states that the method is
1. intercept multilingual request
2. convert multilingual characters into LDH
3. resolve using LDH

which means using a client or proxy to intercept and convert before sending
LDH to DNS.  ACEing mutlilingual characters is not part of the patent if it
is not done during DNS request.

my suggestion below should have no conflict with the Walid Patent
1. there is no interception -- requests are sent and responded to as is
2. there are no conversion -- additional record contains LDH which could be
used
3. resolution depends on the UTF characters

It gives us the benefit of working with ACE
- alphanumeric could be typed by admins or other people who wish to contact
the domain using its LDH form
- other protocols and apps could use LDH
- mode bit response could be introduced to other protocols as needed (if
apps need to upgrade for display of ACE, then they might as well upgrade for
the mode bit, while in the intermediary, they can use the LDH)
and avoids the Walid Patent

Edmon

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 May 2001 13:29:43 -0400

Edmon,

the problem with your proposal is that it provides no way for 
applications which don't support IDNs to deal with IDNs
(whether ACE-encoded or not) that get sent to them in email 
addresses, URLs, etc.

Keith

---

From: "Edmon" <[email-masked]>
Date: Fri, 4 May 2001 14:23:57 -0400

But if the ACE domain is used for the apps, then the worse case scenario is
still the same if IDNA was used, that is, the ACE string will be displayed.
But that does not affect the resolution or transportation.

In order for a person to send out an email with IDN, they must either:
1. have an IDN aware app; or
2. type in the ACE.

for scenario 1, the IDN aware app will correctly obtain the LDH/ACE before
sending so that the recepient could use it for reply purposes (how this is
done depends on the implementation of the IDN aware MUA and could be
discussed when a mail wg is created)
for scenario 2, the ACE name will be used directly so there should be no
concern except of aesthetics

In order for a person to use an IDN URL, they must either:
1. have an IDN aware browser/app; or
2. type in the ACE

for scenario 1, the IDN aware app will obtain the LDH/ACE and use this to
communicate with the http/web server so there should be no problem
retrieving the resource
for scenario 2, the ACE name is used and will be resolved as if it was an
English domain name

I dont see why you say that there is no way for the ACE to be utilized for
other apps and protocols.

Edmon

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Edmon" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; "John C Klensin" <[email-masked]>;
<[email-masked]>
Sent: Friday, May 04, 2001 1:29 PM
Subject: Re: [idn] Alternative Solutions

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 May 2001 14:25:35 -0400

> other apps and protocols.

the non-IDN-aware app still has to be able to lookup the domain using
its ACE format.  this implies that the servers have to support ACE in
addition to supporting native format.

if they can do this without violating the patent, fine.

Keith

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 4 May 2001 20:11:36 +0000

I think I finally understand Edmon's proposal.

In the current IDNA scheme, the only form of the domain name stored
in DNS is the ACE form.  Applications algorithmically convert Unicode
domain names to and from ACE.

In Edmon's proposal, applications still algorithmically convert ACE to
Unicode, but not Unicode to ACE.  For Unicode to ACE, they do a DNS
lookup, which requires that DNS store duplicate information under both
the ACE names and the Unicode names (or appear to do so).

Presumably this is intended to get around the patent.  I don't know if
it does.  In any case, it seems like such a shame to do a DNS lookup
when a local computation would suffice, and get nothing in return for
that extra cost.  If we're going to pay for a DNS lookup on one end, we
might as well pay for DNS lookups at both ends, because then we can get
something in return: meaningful (non-gibberish) LDH names.

AMC

---

From: "Jonathan Rosenne" <[email-masked]>
Date: Sat, 5 May 2001 10:43:11 +0300

Maybe, if the spec says to go to the server for the conversion from Unicode to
ACE, and someone short circuits this and saves a lookup, the spec would not be
in conflict with the purported patent.

Jony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Adam M. Costello
> Sent: Friday, May 04, 2001 11:12 PM
> To: [email-masked]

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 8 May 2001 08:30:29 -0700

John has mentioned many other examples of prior art. I will mention one more
example: A paper given in 1997, encoding Unicode in barcodes. This is very
similar to the actual method used in WALID. There are 47 allowable values,
and it uses differencing (like xor) to typically get small values, then uses
a variable number of them.

B3: Ultracode: A Barcode Symbology Encoding Unicode 2.0, at:
http://www.unicode.org/iuc/iuc10/program.html

<opinion>
It is clear that the US Patent office has thrown in the towel, and is
resting on the courts to do their job for them. There is a massive amount of
prior art for the WALID patent.

Given that the PO doesn't do even the most casual research as to prior art,
even if the IETF chose an alternative -- and that alternative was
implemented -- the PO might even ignore that implementation and grant a
patent to some DILAW company after the fact. There is some non-zero
probability of that, probably near the probability that the WALID patent
would hold up in court.
</opinion>