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

["James Seng/Personal" <jseng@pobox.org.sg>]

You whole long mail basically "scale" (not "economy cost") maybe a
problem we need to look into.

As I said, I agree with you that discussion of "scale" is within
technical scope, but not "economy cost" on how much V charges per name
or B charges per cert etc and how much it would cost C to use it.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>
To: "James Seng/Personal" <jseng@pobox.org.sg>
Cc: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>;
<jet-member@nic.ad.jp>; <idn@ops.ietf.org>; <brunner@nic-naa.net>
Sent: Monday, October 29, 2001 4:05 AM
Subject: Re: [idn] Re: [JET-member 446] Re: Fw: Re: new members
invitation


> 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