Message-Id: <6.1.2.0.2.20050324135452.040fa950@mail.jefsey.com>
Date: Thu, 24 Mar 2005 15:56:04 +0100
To: "L.Gillam" <L.Gillam@surrey.ac.uk>, ltru <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] is there some wiskey in the jar - [was: Registry in
	record-jar format]
In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A2121A592E@EVS-EC1-NODE1.surre
	y.ac.uk>
References: <4A7C6FA2AB31194E80E13FE585F6A2121A592E@EVS-EC1-NODE1.surrey.ac.uk>
Mime-Version: 1.0
Cc: 
Precedence: list
Content-Type: multipart/mixed; boundary="===============0709097668=="
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

--===============0709097668==
Content-Type: multipart/alternative;
	boundary="=====================_31897105==.ALT"

--=====================_31897105==.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA18700

At 12:06 24/03/2005, L.Gillam wrote:
> > The load resulting from RFC 3066 bis is more substantial since there =
are
> > far more languages, possible subtags and resulting langtags to regist=
er and
> > manage
>[snip]
>
>One might suggest that if a future ISO 639-4 provides for ISO 11179-3 /=20
>ISO 12620 (in revision) conformant collections (XML-based), and eventual=
ly=20
>perhaps ISO 3166 and 15924 could go the same way, an XML-based RFC 3066 =
is=20
>a composition with additional documentation, and the pages themselves fo=
rm=20
>part of what one might suggest to be the semantic web. Such an approach,=
=20
>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 X=
ML=20
>converters is that you can have quite a lot of formats. Profusion of=20
>formats becomes problematic, and hence the consideration of metamodels=20
>which allow for extensibility for specific purposes (see documents on=20
><http://www.tc37sc4.org/>www.tc37sc4.org dealing with LMF for example).=20
>Many computer programmers are more than capable of dealing with format=20
>conversions. Selecting one, or more, poses no problems as far as I can=20
>tell. I would, though, encourage the provision of interchange routines=20
>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 ye=
t=20
you see no problems". I am not talking of theory, but of reality. From wh=
at=20
you write about "many computer progammers" you probably are not a=20
programer. I suspect that having no problem in selecting "one, or more,=20
poses no problem" you are not a normalizer either. But the real problem I=
=20
rise is not technical but financial: who is going to pay for all these=20
things. The other point I rise is also operational, because even if=20
theoretically possible, even if paid, there is the difficulty of deployin=
g=20
it. As you may know for example, IPv6 which is the top priority deploymen=
t=20
for the Internet for ... 13 years.

> > - there will be millions/billions of pages referencing the DTD, the u=
rls,
> > etc. which will lead to a IANA access 24/366.
> > Some evaluations are needed about the resulting traffic and the CPU=20
> load before IANA can just discuss
>Why would it? I don't look at a dictionary every time I write a word, th=
en=20
>apply a spell check to that word and a grammar check to the sentence so=20
>far. Moore's law applies to the technology.

Happily, the law of Moore does not necessarily apply. BTW I am no sure th=
at=20
you realise that quoting the law of Moore make you lingua franca centric.=
=20
In your reasoning, the law of Reed applies (from each language to each=20
language). Happily, I don't think either necessarily apply.

>Around 5 exabytes of new information are estimated to be created every=20
>year. A billion pages isn't a lot =96 how many does Google currently cla=
im=20
>to handle? How many will it handle in 2 years? I suggest you investigate=
=20
>the number of page impressions handled by certain existing web servers=20
>technologies (Apache) and present a scientific argument about the possib=
le=20
>future limitations of the technology for handling the application, rathe=
r=20
>than faulting the application. Stating that DoS attacks should prevent=20
>people from undertaking these efforts is akin to putting the cart before=
=20
>the horse.

I am afraid I do not understand the developped argument. I just ask that=20
before specifying something real, one gets a real picture of what it=20
implies and requires.

>  I do have a proposal . Following your scientific argument about the=20
> possible future limitation of the technology, you approach the right=20
> parties about fixing DoS problems. If, as you say, if only 2.5% are val=
id=20
> requests, based on figures from where I know not, and you work towards=20
> reducing the 97.5% by just another 2.5% you will double the capacity at=
 a=20
> stroke and remove the barriers to the valuable work being undertaken=20
> here. How does that sound?

That sound so fine that I suggest you get elected to the ICANN board to=20
explain them that :-)
Or may be that you join the WG-DNSOPS=20
http://ietf.org/html.charters/dnsop-charter.html,
or may be support the CRADA=20
http://www.icann.org/general/crada-report-summary-14mar03.htm,
the results of which are well documented by Karl Auerbach (may be you kno=
w=20
Karl?)
http://www.cavebear.com/cbblog-archives/000007.html.

Actually, I do not know what prompted to respond this. And I tried to=20
respond it as friendly possible to show you that reality is not so easy t=
o=20
implement as writing or debating a Draft. But at the end of the day what=20
makes a difference is feasibility. I will just ask you (this matter has n=
ot=20
been discussed): what it is the calendar you think realistic for the IANA=
=20
database to be operational? Milestones for the work to be achieved would =
be=20
of use. Having an RFC saying this is "how it should be done", may not be=20
enough to document the langtags of 7500 languages in 192 countries, with =
a=20
15 days discussion period per language, represents how many days of=20
exchanges on ietf-languages@alvestrand.no ?

So when will this WG plans the programers, users and other standardizers =
be=20
reasonably able to use the IANA database in real operations?
jfc



>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru

--=====================_31897105==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA18700

<html>
<body>
At 12:06 24/03/2005, L.Gillam wrote:<br>
<blockquote type=3Dcite class=3Dcite cite=3D""><font face=3D"arial" size=3D=
2>&gt;
The load resulting from RFC 3066 bis is more substantial since there
are<br>
&gt; far more languages, possible subtags and resulting langtags to
register and<br>
&gt; manage<br>
[snip]<br><br>
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.<br><br>
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
<a href=3D"http://www.tc37sc4.org/">www.tc37sc4.org</a> 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.</font></blockquote><br>
Dear L.Gillam,<br>
I think you have yourself responded to your remark: &quot;theoretically,
as yet you see no problems&quot;. I am not talking of theory, but of
reality. From what you write about &quot;many computer progammers&quot;
you probably are not a programer. I suspect that having no problem in
selecting &quot;one, or more, poses no problem&quot; 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.<br><br>
<blockquote type=3Dcite class=3Dcite cite=3D""><font face=3D"arial" size=3D=
2>&gt; -
there will be millions/billions of pages referencing the DTD, the
urls,<br>
&gt; etc. which will lead to a IANA access 24/366. <br>
&gt; Some evaluations are needed about the resulting traffic and the CPU
load before IANA can just discuss<br>
Why would it? I don=92t 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=92s law applies to the technology. </font></blockquote><br>
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.<br><br>
<blockquote type=3Dcite class=3Dcite cite=3D""><font face=3D"arial" size=3D=
2>Around
5 exabytes of new information are estimated to be created every year. A
billion pages isn=92t a lot =96 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. </font></blockquote><br>
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. <br><br>
<blockquote type=3Dcite class=3Dcite cite=3D""><font face=3D"arial" size=3D=
2>&nbsp;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? </font></blockquote><br>
That sound so fine that I suggest you get elected to the ICANN board to
explain them that :-) <br>
Or may be that you join the WG-DNSOPS
<a href=3D"http://ietf.org/html.charters/dnsop-charter.html" eudora=3D"au=
tourl">http://ietf.org/html.charters/dnsop-charter.html</a>,<br>
or may be support the CRADA
<a href=3D"http://www.icann.org/general/crada-report-summary-14mar03.htm"=
 eudora=3D"autourl">http://www.icann.org/general/crada-report-summary-14m=
ar03.htm</a>,<br>
the results of which are well documented by Karl Auerbach (may be you
know Karl?)<br>
<a href=3D"http://www.cavebear.com/cbblog-archives/000007.html" eudora=3D=
"autourl">http://www.cavebear.com/cbblog-archives/000007.html</a>.<br><br=
>
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 &quot;how it
should be done&quot;, 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
ietf-languages@alvestrand.no ?<br><br>
So when will this WG plans the programers, users and other standardizers
be reasonably able to use the IANA database in real operations?<br>
jfc<br><br>
<br><br>
<blockquote type=3Dcite class=3Dcite cite=3D"">__________________________=
_____________________<br>
Ltru mailing list<br>
Ltru@lists.ietf.org<br>
<a href=3D"https://www1.ietf.org/mailman/listinfo/ltru" eudora=3D"autourl=
">https://www1.ietf.org/mailman/listinfo/ltru</a></blockquote></body>
</html>

--=====================_31897105==.ALT--



--===============0709097668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

--===============0709097668==--