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
