Message-Id: <6.1.2.0.2.20050324080839.0406a570@mail.jefsey.com>
Date: Thu, 24 Mar 2005 10:41:35 +0100
To: ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <42425B3B.12DA@xyzzy.claranet.de>
References: <634978A7DF025A40BFEF33EB191E13BC0AB82B68@irvmbxw01.quest.com>
	<42425B3B.12DA@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Subject: [Ltru] is there some wiskey in the jar - [was: Registry in
 record-jar format]
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Just a minute, gentlemen!
Could you please investigate first what will be the resulting use?

The IANA is a reference source, for a "few" developers or politics to 
consult. What was documented by the RFC 3066 up to now was a more flexible 
manner to register, store and make accessible for free what ISO do with 
paid papers.

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. If we consider the workload represented by registrations 
(proposition received from Michael Everson, registration, verification, 
possible errors and support) we are here in the range of a very large ccTLD 
with top quality services (we are only a few checking registered DNs). 
Also, before that I am not sure ietf-languages can cope with that workload 
(with a 15 days debate, etc.). Let remember that we have 7500 languages and 
240 countries (rough figures), I suppose that the total amount of 
registrations may be in the range of  30-100.000. Plus private registration 
- over the years this may amount to millions if SNHNs start playing the way 
every indication show they will. The first question about this is: who will 
pay?

Now, if you start talking of DTD, with several versions, and of XML 
presentations with additional data and linked URLs and IRIs, questions are:
- who is going to maintain the entries?
- 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 
it. I am not sure, but we are replicating bigger than the DNS root here. 
One has to be aware that DoS and bug are very heavy on this kind of WHOIS 
is like systems (Iegitimate calls to the DNS root amount to 2.5% - 97.5% 
being more or less junk). I am not sure the IANA agreement with SRI or who 
ever else can stand the load.

I note also that for such a standardized and hopefully stable formatted 
system, the format can certainly be prototyped in using XML but a more
compact solution should to be considered. Most probably UDP supported.

I do not know the INRIA, etc. project we will see documented. But I note 
that this is a paid access service.

Resources have a cost. IANA is a "free" service because it is donated to 
the Internet community. I understand that Unicode/W3C want to use IANA 
"free" resources, but how much are these close paying membership structures 
ready to contribute to permit everyone to get this free service?

Right now ccTLDs are discussing how much to pay ICANN for its IANA service. 
And want to keep it very very low. Since the more we would ask from IANA 
the more we would depend on ICANN, so the more our economies and people 
would depend on a foreign uncontrolled source. (this is a common concern by 
every ccTLD, that USA share: no one knows who will manage the IANA two 
years from now).

We will certainly want to look in detail at this RFC 3066 ter service since 
our communities will most probably be large users of it. And we will 
certainly question its use and design to make sure we are requested to pay 
for the most appropriate solution. Several countries (and this is my own 
direct concern with AFRAC) consider how best to replicate and extend the 
IANA system for surety, security, stability, scalability, support, 
simplicity, sovereignty, innovation reasons. Economics, data consistency 
and operations considerations are also of the essence, since the 
granularity of these referencing systems will certainly extend down to the 
SNHNs.

I do not know why but I feel we are considering a gas refinery where a 
straw would be enough to sip the wiskey in the -jar.
jfc


At 07:16 24/03/2005, Frank Alderman wrote:
>Addison Phillips wrote:
>
> > If we're going to consider different formats for the
> > registry, might I suggest that an even better format would
> > be XML?
>
><http://xml.resource.org/authoring/rfc2629.dtd> would be nice
>to create I-Ds and later RfCs, see <http://xml.resource.org>
>
> > This would also allow for some other useful things.
>
>Apparently you want a completely new DTD for this purpose.
>Does _any_ IANA registry use XML ?
>
> > provide alternate language descriptions or native language
> > descriptions (since an XML file could use UTF-8 as the
> > encoding or at least NCRs).
>
>The resulting plain text ASCII RfC and registry could be messy,
>from the POV of a reader.  One or two literal &#1234; or u+04D2
>in a paragraph are okay, but numerous of these beasts are ugly.
>
> > The registry could also use a URI (or rather, an IRI) to
> > reference the registration form itself (tying registration
> > to the registry).
>
>That's a good idea, add an URL as (optional) 7th column to the
>registry, pointing to the approval of the tag reviewer, e.g.
>http://www.iana.org/assignments/lang-tags/en-scouse
>
>In the record-jar part of a future I-D or RfC something like:
>
>%%
>Type: variant
>Subtag: scouse
>Description: Scouse
>Date: 2000-05-25
>Recommended_Prefix: en
>URL: http://www.iana.org/assignments/lang-tags/en-scouse
>%%
>
> > The DTD could also enforce a certain level of validity on the
> > registry and could itself be versioned to accommodate 3066ter
> > and 639-3 as necessary.
>
>Is that a good idea ?  Matching language tags shouldn't depend
>on XML parsers.  It's also recursive, 3066bis is a definition
>of what we do in a xml:lang, and if that definition has its own
>XML DTD not mentioned in the document with the xml:lang then
>it's confusing.  If we'd want DC we'd know where to find it.
>
> > XML offers lots of flexibility for automating views of the
> > data for that matter.
>
>True, but gawk is also a nice tool, it has no problem with the
>record-jar (or similar) format.  But it's not exactly the best
>choice to parse XML.
>                         Bye, Frank
>
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru