Re: [idn] Alternative Solutions

[Keith Moore <moore@cs.utk.edu>]

> > 
> > Or has WALID actually gotten a patent on a generic concept without
> > actually specifying a particular technique to accomplish it??
> > 
> > --Ken
> 
> 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, 

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

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