Re: [idn] Alternative Solutions

["Sean X. Zhang" <sean_xzhang@yahoo.com>]

--- Keith Moore <moore@cs.utk.edu> wrote:
> > > 
> > > 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]; 
[...]

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

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.

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

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.

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

Sean

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