|
Re: IANA XML registries
2006-09-21 07:04:25
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
At 12:16 21/09/2006, Peter Dambier wrote:
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:
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
--
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: peter(_at_)peter-dambier(_dot_)de
mail: peter(_at_)echnaton(_dot_)serveftp(_dot_)com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|