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

From: "L.Gillam" <[email-masked]>
Date: Thu, 24 Mar 2005 11:06:38 -0000

[snip]

> The load resulting from RFC 3066 bis is more substantial since there are
> far more languages, possible subtags and resulting langtags to register and
> manage

[snip]

One might suggest that if a future ISO 639-4 provides for ISO 11179-3 / ISO 12620 (in revision) conformant collections (XML-based), and eventually perhaps ISO 3166 and 15924 could go the same way, an XML-based RFC 3066 is a composition with additional documentation, and the pages themselves form part of what one might suggest to be the semantic web. Such an approach, based on technologies of the W3C itself, seems to be quite sensible.

The beauty of current technologies like XSL (T and FO) and database to XML converters is that you can have quite a lot of formats. Profusion of formats becomes problematic, and hence the consideration of metamodels which allow for extensibility for specific purposes (see documents on www.tc37sc4.org <http://www.tc37sc4.org/>  dealing with LMF for example). Many computer programmers are more than capable of dealing with format conversions. Selecting one, or more, poses no problems as far as I can tell. I would, though, encourage the provision of interchange routines alongside the formatted data. Theoretically, as yet I see no problems.

> - there will be millions/billions of pages referencing the DTD, the urls,
> etc. which will lead to a IANA access 24/366. 

> Some evaluations are needed about the resulting traffic and the CPU load before IANA can just discuss

Why would it? I don't look at a dictionary every time I write a word, then apply a spell check to that word and a grammar check to the sentence so far. Moore's law applies to the technology. Around 5 exabytes of new information are estimated to be created every year. A billion pages isn't a lot - how many does Google currently claim to handle? How many will it handle in 2 years? I suggest you investigate the number of page impressions handled by certain existing web servers technologies (Apache) and present a scientific argument about the possible future limitations of the technology for handling the application, rather than faulting the application. Stating that DoS attacks should prevent people from undertaking these efforts is akin to putting the cart before the horse. 
 
I do have a proposal . Following your scientific argument about the possible future limitation of the technology, you approach the right parties about fixing DoS problems. If, as you say, if only 2.5% are valid requests, based on figures from where I know not, and you work towards reducing the 97.5% by just another 2.5% you will double the capacity at a stroke and remove the barriers to the valuable work being undertaken here. How does that sound? 
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 24 Mar 2005 15:56:04 +0100

At 12:06 24/03/2005, L.Gillam wrote:
>One might suggest that if a future ISO 639-4 provides for ISO 11179-3 / 
>ISO 12620 (in revision) conformant collections (XML-based), and eventually 
>perhaps ISO 3166 and 15924 could go the same way, an XML-based RFC 3066 is 
>a composition with additional documentation, and the pages themselves form 
>part of what one might suggest to be the semantic web. Such an approach, 
>based on technologies of the W3C itself, seems to be quite sensible.
>
>The beauty of current technologies like XSL (T and FO) and database to XML 
>converters is that you can have quite a lot of formats. Profusion of 
>formats becomes problematic, and hence the consideration of metamodels 
>which allow for extensibility for specific purposes (see documents on 
><http://www.tc37sc4.org/>www.tc37sc4.org dealing with LMF for example). 
>Many computer programmers are more than capable of dealing with format 
>conversions. Selecting one, or more, poses no problems as far as I can 
>tell. I would, though, encourage the provision of interchange routines 
>alongside the formatted data. Theoretically, as yet I see no problems.

Dear L.Gillam,
I think you have yourself responded to your remark: "theoretically, as yet 
you see no problems". I am not talking of theory, but of reality. From what 
you write about "many computer progammers" you probably are not a 
programer. I suspect that having no problem in selecting "one, or more, 
poses no problem" you are not a normalizer either. But the real problem I 
rise is not technical but financial: who is going to pay for all these 
things. The other point I rise is also operational, because even if 
theoretically possible, even if paid, there is the difficulty of deploying 
it. As you may know for example, IPv6 which is the top priority deployment 
for the Internet for ... 13 years.

>Why would it? I don't look at a dictionary every time I write a word, then 
>apply a spell check to that word and a grammar check to the sentence so 
>far. Moore's law applies to the technology.

Happily, the law of Moore does not necessarily apply. BTW I am no sure that 
you realise that quoting the law of Moore make you lingua franca centric. 
In your reasoning, the law of Reed applies (from each language to each 
language). Happily, I don't think either necessarily apply.

>Around 5 exabytes of new information are estimated to be created every 
>year. A billion pages isn't a lot – how many does Google currently claim 
>to handle? How many will it handle in 2 years? I suggest you investigate 
>the number of page impressions handled by certain existing web servers 
>technologies (Apache) and present a scientific argument about the possible 
>future limitations of the technology for handling the application, rather 
>than faulting the application. Stating that DoS attacks should prevent 
>people from undertaking these efforts is akin to putting the cart before 
>the horse.

I am afraid I do not understand the developped argument. I just ask that 
before specifying something real, one gets a real picture of what it 
implies and requires.

>  I do have a proposal . Following your scientific argument about the 
> possible future limitation of the technology, you approach the right 
> parties about fixing DoS problems. If, as you say, if only 2.5% are valid 
> requests, based on figures from where I know not, and you work towards 
> reducing the 97.5% by just another 2.5% you will double the capacity at a 
> stroke and remove the barriers to the valuable work being undertaken 
> here. How does that sound?

That sound so fine that I suggest you get elected to the ICANN board to 
explain them that :-)
Or may be that you join the WG-DNSOPS 
http://ietf.org/html.charters/dnsop-charter.html,
or may be support the CRADA 
http://www.icann.org/general/crada-report-summary-14mar03.htm,
the results of which are well documented by Karl Auerbach (may be you know 
Karl?)
http://www.cavebear.com/cbblog-archives/000007.html.

Actually, I do not know what prompted to respond this. And I tried to 
respond it as friendly possible to show you that reality is not so easy to 
implement as writing or debating a Draft. But at the end of the day what 
makes a difference is feasibility. I will just ask you (this matter has not 
been discussed): what it is the calendar you think realistic for the IANA 
database to be operational? Milestones for the work to be achieved would be 
of use. Having an RFC saying this is "how it should be done", may not be 
enough to document the langtags of 7500 languages in 192 countries, with a 
15 days discussion period per language, represents how many days of 
exchanges on [email-masked] ?

So when will this WG plans the programers, users and other standardizers be 
reasonably able to use the IANA database in real operations?
jfc