[Ietf-not43] issues and questions on FIRS

[Leslie Daigle]

Eric,

Eric A. Hall wrote:
> on 8/26/2003 1:42 PM Leslie Daigle wrote:
> 
> 
>>If we don't build the core properly (and that is the part that
>>is intimately entwined with operator considerations you so determinedly
>>brush off)
> 
> 
> I'm not brushing it off, I'm trying to point out a fundamental principle
> that continues to be ignored: the demands of an operator-to-operator
> service are different from the demands of an operator-to-user or
> user-to-user service, and the technologies which may be appropriate for
> the former are not necessarily suitable to the latter. The demand to use
> IDNA because it's the same as the data in the ~com. zone file is a pure
> example of this in action: the community doesn't give a flying crap about
> what bits are in that specific text file. It's the wrong focus point.

Ah.  I didn't realize you were not responding to the points
I had raised.  I was neither focused on operator-operator nor
was I urging the strict use of IDNA formats (let alone
for ~com zone convenience).


>>>How does IRIS intend to satisfy the actor-specific requirements for
>>>substring searching within an IDNA-encoded name?
>>>
>>>How does IRIS justify the imposition of IDNA-encoded naming when the
>>>community space of an edge-based application consists of native language
>>>speakers who would prefer to work with resources in the representation
>>>they paid for, instead of the represntation that is convenient for the
>>>operators of a supposed "service"?
>>
>>I don't really know why you're bringing IRIS into this.
> 
> 
> It seems apropos to the discussion at hand given the direction you are
> arguing, and it's on my list of IRIS issues anyway. I can change it: How
> do you propose to satisfy the actor-specific requirements for substring
> searching with an IDNA-encoded name? This is unsolvable using IDNs, and
> running parrallel systems is outrageously expensive and makes the whole
> thing fragile. Using a single canonical form for everything makes it
> cheap, efficient, and gives people what they paid for anyway. What was
> your argument again?

I believe you'll have read Andy's response by now -- separation
in protocol doesn't necessarily mean duplication of representation
in the database.  What was yours, again?

> 
> 
>>With respect to my point on variants, which I think you also
>>missed, I was referring to the language-specific variant tables
>>currently under discussion in Taiwan, China, Japan and CENTR,
>>and the possibility (probability?) that registering one IDN
>>is going to necessarily block out a *set* of IDNs.  You can
>>normalize user input all day long, but if they've entered
>>a recognized variant of the IDN, is it appropriate to return
>>"no match" or a fuzzy match?
> 
> 
> As you describe it, each variant would get an entry, which would exist as
> a referral to the canonical entry. The variant query would match the
> variant registration and get redirected.

That is one way to implement a fuzzy match for this problem.

> 
>>So, my point is: conflating domain name and internationalized
>>domain name in the protocol is a mistake, because these things
>>will have inherently different handling requirements.
> 
> 
> I disagree.
> 

Ain't nothin' I can do about that :-)

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
     Yours to discover."
                                -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------