Subject: IANA XML registries

From: JFC Morfin <[email-masked]>
Date: Thu, 21 Sep 2006 01:54:04 +0200

At 20:38 20/09/2006, David Conrad wrote:
>The implication of this is that the entire registry would need to be
>fetched, right?  Given I'm told the registry under discussion is a
>bit on the large-ish size, this might be somewhat problematic.  Can
>you give me an idea of the anticipated scale of the number of
>applications that will be wanting to fetch this registry?

David,
let think in terms of network for once (IETF is about networking). 
You have currently 500 millions users. I think a conservative figure 
for the ten years to come we discuss, is a Multilingual Internet is 2 
billions CPU. These CPU must be able to check if they are up to date, 
on a regular basis. Best practice would be at connect time and once every day.

The IETF registry adds complexity (extlangs, comments, changes) on 
top of the ISO 639 series. The ISO 639-3 7,500 items table will not 
be printed because it will be constantly maintained (please, Peter, 
can you comment). This will be the same (and probably more ) for the 
ISO 639-6 tables which may range in between 15 and 30.000 items 
(please, Debbie, can you comment). Peter commented that one or 
several updates a week is most probable.

This means an updating scheme comparable to a DNS root system with 
40.000 TLDs. You probably have the figures of the rs.internic.org to 
compare with, plus the access to the RSSAC root servers. Except that 
the root file is 65 K and we talk of a file probably 100 to 10,000 
larger. And that the root file is supported by the DNS protocol (the 
root servers are only occasionally called upon by users - in case of 
a TLD typo or when their ISP nameserver has not yet/no more 
information on a called TLD).

Fetching the file would be like carrying an axfr of the root or an 
FTP access to rs.internic.org. A DNS like protocol I proposed in vain 
could permit to decrease, organise, and distribute that load. 
Langtags are probably like TLDs: some will never be queried in some 
geographic areas. Many will have a very long TTL (reasonably 
equivalent to root real life TTL). But many reasons may call for a 
shorter system TTL.

Obviously caching the registry at the user end would help a lot (each 
user would probably need a limited number of languages to be 
documented [those in his filters and those in his relational area]. 
The others representing pollution to him.

However, this must be considered in an interoperable context with 
other language codes. RFC 4646 does not care about interoperability, 
but "x-tags" are enough constrained to permit to build a partial 
strategy based upon 8 alphanum tags + signature.

These private tags will need to be verified and validated the same. 
Either you support them and queries go to you and your mirrors. Or 
you don't and necessarily queries will go to private resolvers (much 
like for the DNS root, so an equivalent top system load). I initially 
explained that langtags had to document referents to be of interest 
to computers and extended services (to the content). Now, a simple 
format for private langtags can be x-8 alphas (three for languages, 2 
for script, 2 for country, one by referent in that context - 36 
possibilities is large enough until RFC 4646ter which will adapt) - a 
langtag private library signature. The size of the central registry 
will be quite large with more information. But the checking traffic 
can be limited to a warning on changes through the distribution of a 
regex of the 8 alpha change and a compacted date. This means 12 
alphanum per change announcement. This may mean a 100 to 2000 chars 
message a day at login time, obtained by the ISP from the IANA. This 
information could even be added at the root footer, since this 
information is already downloaded by ISPs.

We considered these avenues and others for the MDRS project, and 
tested them. They call for crosswalks with different standards/codes 
outside of the Internet (languages are not restricted to the Internet).

I hope this gives you some elements.
jfc

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Sep 2006 11:02:21 +0100

Is anyone else being BCCed jefsey's messages, rather than receiving them
via the mailing list? This is extremely irritating because I have had to
adjust my killfile to block him more effectively.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN
OR SHOWERS. MODERATE OR GOOD.

---

From: Peter Dambier <[email-masked]>
Date: Thu, 21 Sep 2006 12:16:24 +0200

Just as an idea, China has a single ccTLD '.CN'.

I can see them experimenting with three others

Status China Root

soa("XN--55QX5D.","2006092104","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--55QX5D.","2006092104","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--55QX5D.","2006092104","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--55QX5D.","2006092104","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--FIQS8S.","2006092104","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--FIQS8S.","2006092103","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--FIQS8S.","2006092104","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--FIQS8S.","2006092104","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--IO0A7I.","2006092104","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--IO0A7I.","2006092104","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--IO0A7I.","2006092104","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--IO0A7I.","2006092104","HAWK2.CNNIC.NET.CN","159.226.6.185").

To enable the chinese views, all I had to do was adding three stub
zones in my Bind 9.4.0b2 named.conf file and I could use them.

We have put them into the Cesidian Root and I know other Racines Libres
are doing the same.

I must admit this is not XML yet, but I am shure it would work with
XML just the same.

Kind regards
Peter and Karin Dambier

JFC Morfin wrote:
> ------------------------------------------------------------------------
> 

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: JFC Morfin <[email-masked]>
Date: Thu, 21 Sep 2006 15:46:02 +0200

At 11:28 21/09/2006, Martin Duerst wrote:
>Hello David,
>At 02:52 06/09/21, David Conrad wrote:
>
> >Internally, we use subversion for version control.  It would be
> >relatively straight forward for us to provide an opt-in mailing list
> >that broadcasts the contextual diffs of any registry update.  We can,
> >of course, also look at other alternatives people might suggest.
>
>If you use subversion internally already, the best way to allow
>differential updates would be to make subversion available publicly.
>I understand that it would have to be considered carefully,
>but it's really the protocol designed for the job.
>
>Also, as an alternative to mail broadcasts, I'd suggest using
>Atom (RFC 4287).
>
>Regards,     Martin.

Dear Martin,
David's choices in this matter will:

- either keep the IANA as the Internationalised IETF Externet 
referent, with external interoperability managed elsewhere. In that 
case knowing that IANA is internally stable and possibly documented 
in a formated unique way, will certainly help such external 
management(s) and keep the IANA as a serious referential partner.

- or engage the IANA in a comprehensive evolution making it either 
the core referent of the whole digital ecosystem or a part of its 
distributed referent system (through ISO 11179 conformace or along an 
IETF published networked/multilingual equivalent [two areas not 
addressed yet as such by the JTC1]).

I know that your WG has a particular role into this due to the size 
(and therefore access problem) scaling of your registry. I am glad 
that one of the main reason of my opposition to your WG proposition 
is at last (18 months) seriously discussed. However, I think this 
issue concerns the whole IETF and actually the whole Internet 
community. I suspect that David's resources are limited and that his 
first orentations may engage our all future. I suggest that this 
calls for common attention and IAB guidance, as when the NTIA also 
planed to reconsider the IANA.

jfc

---

From: Jefsey_Morfin <[email-masked]>
Date: Thu, 21 Sep 2006 15:58:17 +0200

Dear Peter,
The core-values of the Multi-Internet are user-centric distributed 
control, brain to brain interintelligibility, universalisation, 
external interoperability, concerted consensus, etc. while IETF 
core-values (RFC 3935) are decentralised control, end to end 
interoperability, internationalisation, internal interoperability, 
rough consensus, etc.

Basically you can use their well known description "the network of 
the networks" and "the networks of the network of the networks" 
either to oppose them, if you focus on network-centric engineering 
with edge interfaces, or to consider the Mono-Internet as the default 
of the Multi-Internet, if you focus on user-centric open architecture 
with inclusiveness obligations.

What Chinese build is an externet. An external network look-alike 
within the network. We coined the term in 1984, to name what we 
commonly did with countries monopolies and had a good architectural 
understanding. This came from meetings with Jon Postel's team which 
talked of "external networks" they had to interface (preparation of 
RFC 920). What is of interest [as you observed it with stubs] is that 
there is no reason why (except an update of the IETF culture, an RFC 
3935bis) the current technology could not support the Multi-Internet.

Before engaging in the MDRS project, we experimented it for two years 
along with the ICANN ICP-3 request for experimentation. On our 
test-bed we used the same tools as Chinese use. What Chinese have 
implemented shows that a Multi-Internet architecture can pacifically 
coexist with the Mono-Internet. We capitalise on this for the basic 
multilingualisation building block. As you know we have been 
technically delayed for 2 years by the BCP47 Unicode (RFC 3869 
described) confusion, until we obtained RFC 4646 ... I fear they now 
want to corrupt.

A Multi-Internet needs a "Multi-IANA". The control of the IANA is 
actually the crux (this is one of the reason of the Language Registry 
dispute, because they scale the size - and the problems - of the 
IANA. This is a problem similar to Host.txt). Any solution (transfer 
"elsewhere" as suggested by Harald or investigated by the NTIA and 
commented by IESG/IAB, MDRS as I propose, ISO 1179 based or not) 
calls for dramatic IANA changes. As long as IANA was in a messy 
management, considering them practically was the same as proposing 
alt-IANAs. What David has actually engaged into fundamentally changes 
everything: this will _practically_ permit the IANA to be 
_interoperable_ with other network referential systems.

Now, the problem is to know if the IETF will want this 
interoperability to be internal and submitted to decentralised 
control of the IETF leaders and commercial sponsors (cf. IAB RFC 
3869), or external and distributed and therefore to scale. The 
economic impact is enormous so it will answer RFC 3869. Either a 
decentralised costly, hence US industry oriented, solution based on 
selling information on users obtained from queries. Or a distributed 
grassroots low cost sustainable economy oriented architecture. Money 
and lobbies on one side, an emerging understanding (including 
economical model) on the other side.

David's decision forces each of us to make our mind in a short while. 
The decision will be in a wide part at the WG-LTRU because they 
document the last (XMLisable) and by very very far the largest IANA 
registry (as I show it of the size of a 40.000 TLDs root, without a DNS).

jfc