Re: [idn] Re: [JET-member 446] Re: Fw: Re: new members invitation

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

James,

> I agree with you - "scale" is an engineering consideration.
> But "cost" (economy), OTOH, is not.

Assume that "registration" of a "name" containing characters in the SC and/or
TC character sets with the .FROTZ TLD registry is "free". No VISA card, no
wire transfer, postal coupons or micro-payments. Free. Like .US.

Assume also that "dispute resolution" of a "name" containing characters in
the SC and/or TC character sets under the Dispute Resolution Policy (DRP)
of the .FROTZ TLD registry is "free". No VISA card, no wire transfer, postal
coupons or micro-payments. Free. Also like .US, at least in theory.


Now that everything in the problem space is zero "cost", and "buy" means
only perform whatever non-cash ritual is required by the the .FROTZ registry
system (registrars don't charge money either), and "defend" in the .FROTZ DRP
means only perform whatever non-cash ritual is required by the .FROTZ registry
system (mediators and lawyers don't charge money either), and the non-cash
ritual is simply to read and write modest bits of email without the use of
any autonoma other than a comodity MUA ...

For a 10 character "name", assuming only 1-to-1 equivalences for all 10 of
the characters, 2^^10 items of email are required to "register" the name.
Another 2^^10 items to "defend" the name. That's about the total volume of
email on the IDN list this year (between 1K and 2K seperate mailings, but
I'm _not_ counting -- the point is tedium, saturation even boredom). Even
if there is no "cost" associated with any action, the take-to-exhaustion
"solution" has the effect of limiting the length of character strings to a
fraction of whatever scheme is employed to use the 63 bytes available.


You had this issue in another WG, where you thought that the authentication
mechanism could be, without cost, extended from a end-point set the size of
10^^3 or 10^^4, to an end-point set the size of 10^^6 or 10^^7.

Neither that activity nor this one is theoretical. Cost is not "layer 9",
if you really think it is, go sit in on variable- vs fixed-length forwarding
lookup or any equivalent problem in layers 2 or 3.


Now, on the registry side that was 2^^10 blips in the zone file for each
name, assume 10^^6 distinct names, each 10 character, plus 2^^10 extra
equivalences ... that's 10^^9 records. To be equitable, assume I/O, store,
and processing are "free", but not instantaneous. Even if there is no "cost"
associated with any action, the multiple entries in zone files recommended
(the UTC recommendataion) "solution" has the effect of limiting the length
of character strings to a fraction of whatever scheme is employed to use the
63 bytes available.

Eric