[Ietf-not43] issues and questions on FIRS

Eric A. Hall ehall at ehsco.com
Tue Aug 26 15:47:08 EDT 2003


on 8/26/2003 2:31 PM Andrew Newton wrote:

> Eric A. Hall wrote:

>> How does IRIS intend to satisfy the actor-specific requirements for 
>> substring searching within an IDNA-encoded name?
> 
> Good question!  First, I'll be the first one to admit we do not fully 
> understand all the IDN implications.  So if anything is not quite
> right, I'm sure we can change it for the better.
> 
> One the search side, IRIS defines two separate searches: 1) find
> domains by name (<findDomainsByName>) and 2) find domains by
> internationalized name (<findDomainsByI18NName>).  I realize that it
> could be one search with a modifier switch, but for the sake of
> simplified server code paths I thought this might be better.  Anyway...

So we have two searches against two data-stores, where all of the entries
and search values require edge normalization.

I don't see any algorithms for normalizing or validating data.

Are errors supposed to be blocked at the client, caught by the server's
query parser, or bounced off the data-store (aka, where should data be
normalized and validated)?

I don't see any requirements for synchronizing the contents of the
entries, or for synchronizing indexes across a shared pool of entries. Is
it okay if a server doesn't return the same answer data for two different
query forms? Is it okay if a server doesn't support one of the query forms
at all?

> On the lookup side, entity names can be UTF-8, so a registry can allow
> lookup by either the 7-bit ASCII name, the 8-bit UTF-8 name, or both.
> Its their choice.

How does the client know which form is acceptable as user input? On the
other hand, if the client is supposed to normalize regardless of input,
then there needs to be an algorithm.


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



More information about the Ietf-not43 mailing list