Subject: RE: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format]

From: "L.Gillam" <[email-masked]>
Date: Thu, 31 Mar 2005 18:59:51 +0100

JFC,

> why to be agressive? 
...
> If you are a programer and a standardizer 
...
> If you are involved in the Internet as a programer and as a standardizer you know as 
> much as I do about IPv6?
...
> May be you are not a network architect
...
> May be you are an operational too
...
> - you are selfish grown boys
...
> I hope - and still hope - you could help, as an European 
> academic, with a 
> more open minded apporach, culturally more sophisticated and 
> inclusive than 
> employees of large multinational coporations or of their 
> resellers are allowed.

Please do not make assumptions about what others do or do not, or aim accusations at others and then accuse them of being aggressive when they correct you - it does not help the discussion. 
Also, where did you discover that Moore's law was a "joke"? Not from Intel, surely? (http://www.intel.com/research/silicon/mooreslaw.htm)

> Happily, the law of Moore does not necessarily apply. 

While applying Moore's law to every situation does not necessarily fit, technology moves quickly. UDC, and its predecessor, was a good example of a large system of identifiers in existence before any of the web technologies. The truth, I suspect, is a consideration of technological capabilities and advances alongside expectations of growth. But these are both predictions, and we know what the problem with prediction is. Now, you suggested that an "IANA considerations" section needs to predict how many accesses such a registry will have, right? Based perhaps on the frequency of access of the list that goes along with RFC 3066? Can you point to somewhere that this has been done already? I'm interested in how people have made such predictions in these documents - predicting system loading is an interesting topic.

As a network architect, perhaps you also have good suggestions to make for how to handle a distributed registry that would reduce infrastructural requirements and help to fulfill such a requirement. Though you seemed to dismiss John Cowan's (or somebody else's) suggestions of cacheing. Is your concern purely financial? 

> In your reasoning, the law of Reed applies(from each language to each language)

If it did, we'd have a massive amount of languages based on every person possibly speaking to every other person in the world. We have standards of terminology in specific areas. The contrast between these 2 statements seems to be very relevant to such considerations. Perhaps the former is why you suggest significant loading on systems?

> the current Draft will not fly. As usual on the Internet: it is a default ASCII Internet 
> solution for one application having circumvented another one.

I do not understand this comment, perhaps you would like you to elaborate on it? Are you suggesting to "do away" with ASCII? Why does an ASCII solution for language tagging pose a problem? The tag provides the interoperability - what it "stands in place of" requires representation (its human-readable name in given a language and associated data). The multilinguality of which you speak would be its representation, not its tag. Call the airport what you want, your luggage tag will have 3 letters and be in ASCII. 

> Lang5tag is no problem managing as such: it happens to be 
> well managed for centuries by every library. No need for the IANA.

Where is it documented? How do people use it for interoperability? Who ensures it is well maintained? I've no experiences of libraries that use such a systems. I am also intrigued by your suggestion that it's less complex than what you refer to as a lang3tag, when what you identify as lang5tag seems to be an extension of lang3tag.

> you are not taking care of the needs of others (like me) 

What exactly are these needs that you allude to? I don't consider these to be clear. A number of others have asked this also. I'm not sure people can realistically take an individual's budget into consideration when they aim to provide something for the wider community. Should the tail wag the dog?

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 31 Mar 2005 21:15:00 +0200

At 19:59 31/03/2005, L.Gillam wrote:
>Also, where did you discover that Moore's law was a "joke"? Not from 
>Intel, surely? (http://www.intel.com/research/silicon/mooreslaw.htm)

Moore law applies to computers not to networks. On networks Metcalfe and 
Reeds laws are to be used as a never reached limit or as a maximum filtering.

>appily, the law of Moore does not necessarily apply.
>While applying Moore's law to every situation does not necessarily fit, 
>technology moves quickly. UDC, and its predecessor, was a good example of 
>a large system of identifiers in existence before any of the web 
>technologies. The truth, I suspect, is a consideration of technological 
>capabilities and advances alongside expectations of growth. But these are 
>both predictions, and we know what the problem with prediction is. Now, 
>you suggested that an "IANA considerations" section needs to predict how 
>many accesses such a registry will have, right? Based perhaps on the 
>frequency of access of the list that goes along with RFC 3066? Can you 
>point to somewhere that this has been done already? I'm interested in how 
>people have made such predictions in these documents - predicting system 
>loading is an interesting topic.

I have no other model to offer than existing systems. This is why I ask and 
why I worry. I do not document, I ask it to be documented. There is to date 
no other request to IANA such as some of the discussed propositions. IMHO 
the IANA is not conceptually what fits these demands. I just want to 
understand first what is the demand. This Draft is made to address specific 
application needs: I just ask how will this applications operate. What are 
the risks of usage creep.

>As a network architect, perhaps you also have good suggestions to make for 
>how to handle a distributed registry that would reduce infrastructural 
>requirements and help to fulfill such a requirement. Though you seemed to 
>dismiss John Cowan's (or somebody else's) suggestions of cacheing.

I am open to every suggestion. But first I want to understand the problem. 
Who is accessing, for what purpose, the length and the size of the 
transaction. For example caching what, where, when, for how long. I 
documented long caching in using a langtags file and yearly update???

>Is your concern purely financial?

My concern is also financial. There is a necessary compromise between cost, 
quality of the service, volume of access, procedures, ways to limiting 
traffic. I want to understand first what we are talking about. So, I ask.

>If it did, we'd have a massive amount of languages based on every person 
>possibly speaking to every other person in the world. We have standards of 
>terminology in specific areas. The contrast between these 2 statements 
>seems to be very relevant to such considerations. Perhaps the former is 
>why you suggest significant loading on systems?

I am not sure that impact of every language to every language is so 
important on the resulting load (but again I have yet no real idea of when 
people will access, why, etc. and I mean in real life, not in theory: we 
all know that real use if far bigger than the supposed one). My rational is 
that when two people want to talk they talk, whatever the language. But 
obviously there is certainly an impact. If someone updates his tables every 
time it calls someone, the impact is zero, but if he does it only when he 
calls a new language, if he speaks only one language, no impact, but if he 
speaks 10 languages the impact if 10 times more, plus possible errors.

>Are you suggesting to "do away" with ASCII? Why does an ASCII solution for 
>language tagging pose a problem? The tag provides the interoperability - 
>what it "stands in place of" requires representation (its human-readable 
>name in given a language and associated data). The multilinguality of 
>which you speak would be its representation, not its tag. Call the airport 
>what you want, your luggage tag will have 3 letters and be in ASCII.

There is no use in having to enter/read something which is not on your 
keyboard. People at the Airport can type ASCII - for the time being as 
probably RFID will change many things. Not end users.

>Where is it documented? How do people use it for interoperability? Who 
>ensures it is well maintained?

No one. You know the Babel symbolism: it is precisely to free people from 
the one who wanted things to be well maintained. So people are free to do 
it the way they want. So there is no single point of failure. 7520 
languages are the way to make us free from someone ensuring maintenance. 
This is for us to feel secure we found a reliable way to be stable, secure 
and innovative without having to rely on a single one, with all the 
possible cross verifications, which will insure us that our system is well 
maintained.

More complex, smarter, more work to find it? Probably yes.

>I've no experiences of libraries that use such a systems. I am also 
>intrigued by your suggestion that it's less complex than what you refer to 
>as a lang3tag, when what you identify as lang5tag seems to be an extension 
>of lang3tag.

Open a dictionary. It will tell you five things about every word, plus 
information on the meaning, nature and syntax:

- the language (on the cover)
- the script (you see it)
- where it was published (ISSN-ISBN) or the title
- the author (on the cover)
- either it is standard style by default, or it mentions the style: fam. 
pop, old, etc.

> > you are not taking care of the needs of others (like me)

There are many needs to consider.

1. application needs. The only considered needs are XML/HTML pages by W3C 
and some CLDR needs? OPES, DNS, Web Services, History, Users communities, 
CRC, etc. and innovation.

2. there is not such a thing as a "wider community". There are machines, 
bandwidth, operators, etc. These people need a budget and someone to pay 
for this budget. In the case of the IANA the budget is the ICANN budget. 
ICANN need to collect that money. I am one of those who are asked to pay. I 
suggest you access the ICANN strategic plan for the years to come 
http://nuts/strategic-plan/strategic-plan-v6.pdf and search for IANA. It 
will give you a fair understanding of what ICANN intents to pay when you 
compare the number of times RIRs, DNS and Parameters and quoted.

>What exactly are these needs that you allude to? I don't consider these to 
>be clear. A number of others have asked this also. I'm not sure people can 
>realistically take an individual's budget into consideration when they aim 
>to provide something for the wider community. Should the tail wag the dog?

Depends what is the tail what is the dog. This is precisely what I want to 
determine. Let assume that one of the self regulation of IANA load is the 
delay in getting a IANA response. Let assume that the delay is 1 minutes. 
Is this acceptable? Is this because there a lot abandon? Is this not 
draining resources on developing countries more than larger bandwidth 
countries? etc.

Again, at this time we do not discuss a solution. We just need to 
understand if there is a problem (I am surprised nobody came in saying: 
there is no problem because ....). Roughly there are comments saying "on OS 
installation" - I do not know why, nor the size of the access. But with 
usual 10 times markup this means 3 to 4 billions a year increasing. I do 
not know the size, but I tend to think the lower the size the greater the 
number of accesses?

My first real concern is why do I need the IANA for? Let take the DNS. The 
IANA delivers the Master file to the Alpha Machine and to the Internic, and 
the Whois file online. I would be very interested in IANA documenting the 
load each represents.
jfc

---

From: John Cowan <[email-masked]>
Date: Thu, 31 Mar 2005 15:10:10 -0500

> - either it is standard style by default, or it mentions the style: fam. 

Many dictionaries do not have this last item, particularly dictionaries of
and in English, where the boundaries are extremely permeable.

-- 
John Cowan  [email-masked]  www.reutershealth.com  www.ccil.org/~cowan
Assent may be registered by a signature, a handshake, or a click of a computer
mouse transmitted across the invisible ether of the Internet. Formality
is not a requisite; any sign, symbol or action, or even willful inaction,
as long as it is unequivocally referable to the promise, may create a contract.
       --Specht v. Netscape