gmane.ietf.idnabis

WG Last Call for draft-ietf-websec-strict-transport-sec

Paul Hoffman — 2012-03-21T01:09:50

Greetings again. The websec WG is in WG Last Call for draft-ietf-websec-strict-transport-sec, an interesting document that is likely to be widely deployed in web browsers and servers. There are a few places in the document that touch (slam?) into IDNA 2003 and IDNA 2008, so I thought this list should pay attention now rather than later. In specific, please see section 8 (just the beginning), section 9, and section 13.

The WG LC ends April 9. Please send any comments to the websec WG mailing list, not here. Thanks!

--Paul Hoffman

Re: Proposed new Firefox IDN display algorithm

Mark Davis ☕ — 2012-03-20T17:06:30

https://wiki.mozilla.org/IDN_Display_Algorithm has a few questions. There
is a new proposed version of #39; it would be useful to get feedback as to
whether it answers the questions you have (if not, we need to propose
additional language for the upcoming Unicode meeting).

http://www.unicode.org/review/pri209/

------------------------------
Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Tue, Mar 20, 2012 at 08:46, Gervase Markham <gerv< at >mozilla.org> wrote:

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

Re: Proposed new Firefox IDN display algorithm

Gervase Markham — 2012-03-20T15:46:11

Members of this list may be interested to know that the first cut of a
patch to implement UTR#39 "Moderately Restrictive" and "Highly
Restrictive", as interpreted here:
  https://wiki.mozilla.org/IDN_Display_Algorithm
has been written for Firefox. This algorithm would be used for TLDs
which are not on our existing whitelist.

You can follow along in this bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=722299
and can find builds to try out here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smontagu< at >mozilla.com-b7a042eb454e/

Feedback very much welcomed, particularly on what to do about those bits
of UTR#36 which our engineer considered too underspecified to implement,
as noted in comment #16.

Gerv

Re: Draft on IDN Tables in XML

Andrew Sullivan — 2012-03-14T18:39:38

I strongly agree, and would go farther: I think it would be a bad idea
for registries to blindly import tables from other registries.

But registries are not the only people who may be interested in the
variant relationships in a registry.  For instance, the anti-abuse
community might reasonably want to use those tables as the basis for
constructing policies for what domains ought to be expected to be
delegated.  The anti-abuse community might want to use those tables to
detect opportunities for phishing, and to try to produce mitigation
strategies.  The corollary to using registry policy as the source of
sane IDN deployment is that clients need to be able to know what those
policies are, and to test actual network behaviour against the
policy.  In the absence of such tests, the registry policies aren't
enough.

The only way that applications are going to be able to integrate the
expected policies in their applications is if the policies can be
expressed in a machine-readable way.  If they can't be, then I predict
the policies will be "boutique" ones: some applications will work, but
others won't.  (This is written from the ICANN Universal Acceptance of
TLDs session, where I am keenly hoping this application perspective
will be expressed.)

Best,

A

RE: Draft on IDN Tables in XML

John C Klensin — 2012-03-14T17:34:50

Ram,

Agreed.  Indeed, we quite deliberately made absolutely no
attempt to define a machine-readable format when the idea of
these tables was introduced.  One reason was that we saw no
chance of getting consensus on a format, partially for the
reasons Ram identifies.  But the more important reason was that
we didn't want to encourage anyone to casually import a table
without studying it and, indeed, having enough script (and
language?) expertise around to be sure that they understood it.  

I think many of us can remember the degree of upset and concern
that arose when one registry decided to allow a script that they
didn't understand well because they knew that a language that
used the script was used in that country.  It is not clear
whether importing a table that was equally poorly understood who
make that situation worse, but it seems to me it would be very
unlikely to make it better.

Jaap's recollection is correct and a machine-readable form would
be useful in some cases.  However, the risk of mindless import
of tables actually creates a tradeoff between "...Having a
machine readable format that allows the tables to be imported
and repurposed aids this greatly" and the possibility of real
harm.  

My sense would be that, especially if the intent is to capture
not just character lists but variant concepts, we would be much
better off with a list of characters and explanations.   I
believe that the character lists and explanations that we would
be likely to see fall into three categories:

(1) Rather short lists, under a hundred or so characters.   This
would be the case for most alphabetic scripts, including Latin.
It is not clear that a standardized table format helps with that
case because anyone trying to import a table is really going to
need considerable explanation about what is going on (e.g., the
ability to represent "oe" as a variant of o-dieresis does not
imply that importing that relationship would be wise). 

(2) Lists that involved a great deal of complexity because of
concerns about look-alike characters, characters that are
sometimes used interchangeably, or distinctly different uses
(and rendering styles) for the same script.   All three of those
situations have been illustrated in the ASIWG work on Arabic
(some of which is incorporated into the Arabic variant
information project team), but I have every confidence that
there are other scripts out there with one or more of those
issues (some would argue that the Japanese - Chinese situation
poses problems not much different from the [Western] Arabic -
Perso-Arabic one).  The complexity of those situations cannot be
easily represented in a simple table, whether in XML or
otherwise.

(3) Chinese (Han) script.   The tables there are large enough to
make automatic import useful, but the CNDC table requires a
specialized table because of the paired preferred variants and,
as we know, neither Japanese nor Korean require variant
treatment (although they may have other issues).  It would make
lots of sense to have a standardized machine-readable format for
the Chinese use of Han script, but that involves a different set
of issues than such a format for other scripts and may or may
not be the correct format for a Japanese or Korean table.  

As a general comment, it seems to me that people on this mailing
list and the technical and script communities have repeatedly
told ICANN, its staff, and various "constituencies" that Han
script is fundamentally different from the collection of
alphabet-phonetic scripts and that trying to treat them as the
same just yields one problem after another (for one group or the
other).  That advise has been consistently ignored in ICANN's
efforts, including this one.  I don't know if the reason is
determined ignorance (which I certainly wouldn't not expect from
Kim) or that the advice is politically inconvenient but, from my
point of view, even decision made on the basis that they were
really the same just makes ICANN look silly and puts the
predictability and stability of the Internet at risk.  

Certainly it would be more convenient if they were really the
same --same variant issues, same order magnitude of relevant
characters, same relationships of "character" to sounds and
meanings, and so on-- but the odds of everyone who thinks they
would like one being awarded a pony and the wherewithal to keep
it are much higher.

best,
   john


--On Wednesday, March 14, 2012 10:45 -0400 Ram Mohan
<rmohan< at >afilias.info> wrote:

RE: Draft on IDN Tables in XML

Ram Mohan — 2012-03-14T14:45:58

Kim,

I am not certain registries would want to use an automated/machine-readable
mechanism for importing tables from other registry IDN implementations.
Implementations vary widely from one registry to another, each IDN
implementation often requires hand-verification of allowed code points
combined with business policies.



Let’s try an example:

CDNC regularly publishes and updates the set of valid codepoints in the Han
script, along with contextual and variant generation rules/guidelines.
Publishing those set of rules in this rich format would be useful; however,
registries will still need to manually verify both the codepoints and the
rules for variant generation, and create business rules for allocation and
delegation of applied for strings.



Feels like a nice to have, not a must have.



-Ram



---------------------------------------------------------------------------------

Ram Mohan

(o) +1.215.706.5700 x103  (m) +1.215.431.0958  (f) +1.215.706.5701

rmohan< at >afilias.info | Skype: gliderpilot30 | Twitter < at >rmohan123

---------------------------------------------------------------------------------



*From:* Kim Davies [mailto:kim.davies< at >icann.org]
*Sent:* Monday, March 12, 2012 9:24 AM
*To:* Jaap Akkerhuis
*Cc:* idna-update< at >alvestrand.no; Dillon, Chris; Abdulrahman I. ALGhadir;
vip< at >icann.org
*Subject:* Re: Draft on IDN Tables in XML



Hi Jaap,



On Mar 12, 2012, at 3:34 AM, Jaap Akkerhuis wrote:


As far as I know, the idea of the tables have always been to provide
a public central place where the registries could list which
characters they support and which they don't in their registrer
plolicies. It is an "for your information only" registry and meant
for human consumption.

And Kim, do correct me if this isn't the case anymore.



It is certainly correct that the notion of tables is to publicly share
registry policy as it relates to code points that are accepted for
registration. I think, however, it is a bit beyond merely informational, as
a key driver in publishing them has been to allow sharing and re-use by
other registries. Having a machine readable format that allows the tables
to be imported and repurposed aids this greatly.



One of the reasons I feel this is a good initiative is an increasing number
of tables appear to be published as PDF files with various contextual rules
described in paragraphs of normative text. It would be nice to reverse this
trend and have a format rich enough that it can express most if not all
registry policies in a common way using a set of agreeable primitives.



kim
_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

RE: Draft on IDN Tables in XML

JFC Morfin — 2012-03-13T02:07:27

Noted.
jfc

RE: Draft on IDN Tables in XML

Shawn Steele — 2012-03-12T18:28:16

I don't see a relationship between the proposed XML behavior and JFC's ideas.  Nor am I interested in JFC's ML stuff, sorry.

-Shawn

-----Original Message-----
From: idna-update-bounces< at >alvestrand.no [mailto:idna-update-bounces< at >alvestrand.no] On Behalf Of JFC Morfin
Sent: Monday, March 12, 2012 10:31 AM
To: Gervase Markham; J-F C. Morfin
Cc: Shawn Steele; iutf< at >iutf.org; Kim Davies; idna-update< at >alvestrand.no; James Mitchell; iucg< at >ietf.org; vip< at >icann.org
Subject: Re: Draft on IDN Tables in XML

At 17:16 12/03/2012, Gervase Markham wrote:

Lead users. As you do not want to listen and talk to them, some grassroots people have decided the safest was to reconsider the whole user architecture, back to the IUI and ML-DNS.  They probably are not on the same wave lengths as both of you? Don't ask me.

My personnal focus here is only the IUI and ML-DNS architectural, documentation and safe testing framework; and to try to keep some liaison with the Internet stratum. This is juste because the "Internet+" stratum is necessary multiservice menu synergy and access, to multilinguistic support, and to my interest in the Intersem.

I therefore only listen to the requests and investigate how the IUI could address them when the project matches my interest. I will know better once my I_Ds are finalized, a PLUS software architecture adopted, and some first prototyping achieved. Then IUI "slots" (smart local operating tasks) from projects will be experimented. Only by then we will know which projects have actually gone through and what they bring. You know FLOSS, it may take some time before all that preparatory process stabilizes. However, I have good hopes to see the things running in my old age.

jfc  

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

RE: Draft on IDN Tables in XML

Shawn Steele — 2012-03-12T18:22:15

IMO IDN can be implemented as it is.  There are the problems around multiple variations of names (not just eszett/ss, but also o-umlaut/oe, etc), but I see that as something to be solved on the DNS side.  Also I'd like to see DNS handle UTF-8 to lessen some of the challenges around punycode, but that's about it. 

There are interesting management problems and decisions for zone admins to address, and presumably tools that they want to help, but that's pretty restricted to each zone.

For the proposed XML structure, I don't see it being useful on the client side.  I'm also uncertain how interesting it is on the registrar side.  Either a TLD sells me the name I want, or they don't.  Once I have my name, I can manage my zone as I'd like, so these rules only apply to each administrator.  The cases when I need to share this information with others seems rare-ish to me, but I'm not someone who deals with this normally.  I need to explain to a registrant why I won't register their preferred domain, or the names that are bundled with it, but I think that's best handled in a human language, not a XML file of rules.

-Shawn

-----Original Message-----
From: Gervase Markham [mailto:gerv< at >mozilla.org] 
Sent: Monday, March 12, 2012 9:17 AM
To: J-F C. Morfin
Cc: Shawn Steele; Kim Davies; vip< at >icann.org; James Mitchell; idna-update< at >alvestrand.no
Subject: Re: Draft on IDN Tables in XML

On 12/03/12 03:07, J-F C. Morfin wrote:

Shawn, representing Microsoft, asked this question, which I presume suggests that Microsoft isn't sure what this data is for. I, representing Mozilla, echo his question.

Which browser makers have asked for this data?

Gerv

Re: Draft on IDN Tables in XML

JFC Morfin — 2012-03-12T17:30:51

Lead users. As you do not want to listen and talk to them, some 
grassroots people have decided the safest was to reconsider the whole 
user architecture, back to the IUI and ML-DNS.  They probably are not 
on the same wave lengths as both of you? Don't ask me.

My personnal focus here is only the IUI and ML-DNS architectural, 
documentation and safe testing framework; and to try to keep some 
liaison with the Internet stratum. This is juste because the 
"Internet+" stratum is necessary multiservice menu synergy and 
access, to multilinguistic support, and to my interest in the Intersem.

I therefore only listen to the requests and investigate how the IUI 
could address them when the project matches my interest. I will know 
better once my I_Ds are finalized, a PLUS software architecture 
adopted, and some first prototyping achieved. Then IUI "slots" (smart 
local operating tasks) from projects will be experimented. Only by 
then we will know which projects have actually gone through and what 
they bring. You know FLOSS, it may take some time before all that 
preparatory process stabilizes. However, I have good hopes to see the 
things running in my old age.

jfc

Re: Draft on IDN Tables in XML

Gervase Markham — 2012-03-12T16:16:39

Shawn, representing Microsoft, asked this question, which I presume 
suggests that Microsoft isn't sure what this data is for. I, 
representing Mozilla, echo his question.

Which browser makers have asked for this data?

Gerv

Re: Draft on IDN Tables in XML

Patrik Fältström — 2012-03-12T14:26:42

On 12 mar 2012, at 08:09, Kim Davies wrote:


The reason I ask is because on the epp mailing list in IETF there is an ongoing discussion where the registries and registrars completely disagree on how the validation of a string is to happen, and who has the responsibility to implement it.

So, this is another stick that someone poked into the ant hill.

   paf

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

Re: Draft on IDN Tables in XML

Kim Davies — 2012-03-12T14:09:49

On Mar 12, 2012, at 7:52 AM, Patrik Fältström wrote:


On 12 mar 2012, at 07:22, Kim Davies wrote:

The target is really registries

Not registrars?

I'm not aware of any registrars today that use IDN tables in their business logic. They could use them to filter out known-bad labels before they start an EPP transaction, and to generate variant sets for registries that do not do their own variant handling, so I agree they could be another potential user.

kim
_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

Re: Draft on IDN Tables in XML

Patrik Fältström — 2012-03-12T13:52:31

On 12 mar 2012, at 07:22, Kim Davies wrote:


Not registrars?

   paf

_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

Re: Draft on IDN Tables in XML

Kim Davies — 2012-03-12T13:23:31

Hi Jaap,

On Mar 12, 2012, at 3:34 AM, Jaap Akkerhuis wrote:

As far as I know, the idea of the tables have always been to provide
a public central place where the registries could list which
characters they support and which they don't in their registrer
plolicies. It is an "for your information only" registry and meant
for human consumption.

And Kim, do correct me if this isn't the case anymore.

It is certainly correct that the notion of tables is to publicly share registry policy as it relates to code points that are accepted for registration. I think, however, it is a bit beyond merely informational, as a key driver in publishing them has been to allow sharing and re-use by other registries. Having a machine readable format that allows the tables to be imported and repurposed aids this greatly.

One of the reasons I feel this is a good initiative is an increasing number of tables appear to be published as PDF files with various contextual rules described in paragraphs of normative text. It would be nice to reverse this trend and have a format rich enough that it can express most if not all registry policies in a common way using a set of agreeable primitives.

kim
_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

Re: Draft on IDN Tables in XML

Kim Davies — 2012-03-12T13:22:17

Hi Shawn,

On Mar 11, 2012, at 8:13 PM, Shawn Steele wrote:

So, as a 3rd party, I'm not sure how this information is very helpful to me?  I mean, it'd tell me what the registry hoped to do for it's zone, but that may or may not match the DNS entries.  I can discover valid domains by querying the DNS itself, I don't need to access the list.

I can see how this information might be helpful for tools that help people manage their zones, however any tools that talked to themselves wouldn't necessarily need this format (though it'd help to be able to import/export the data this way, and maybe interoperate better with other tools).

I guess what I'm getting at is:  What kinds of applications are expected to consume this data?  What's the target?

The target is really registries, albeit potentially registries at multiple levels of the DNS — not just TLD registries. While other software like end-user applications consume the data, I am not sure what the benefit would be. Once it is in a DNS zone, it is a domain name, and would be expected to resolve. Tables are really beneficial as part of the provisioning process.

kim
_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

Re: Draft on IDN Tables in XML

Jaap Akkerhuis — 2012-03-12T09:34:03

    Is it possible to add the relation type for each variant like
    is it exactly similar or partially?

    Also, what about the registry rules? Some registries impose
    more restriction on the IDNA protocol is it possible to add a
    tag the describe them?

As far as I know, the idea of the tables have always been to provide
a public central place where the registries could list which
characters they support and which they don't in their registrer
plolicies. It is an "for your information only" registry and meant
for human consumption.

And Kim, do correct me if this isn't the case anymore.

jaap

RE: Draft on IDN Tables in XML

Abdulrahman I. ALGhadir — 2012-03-12T06:30:20

Hello,

Is it possible to add the relation type for each variant like is it exactly similar or partially?

Also, what about the registry rules? Some registries impose more restriction on the IDNA protocol is it possible to add a tag the describe them?

AbdulRahman,

-----Original Message-----
From: idna-update-bounces< at >alvestrand.no [mailto:idna-update-bounces< at >alvestrand.no] On Behalf Of Dillon, Chris
Sent: 5/Mar/2012 3:23 PM
To: Kim Davies; vip< at >icann.org; idna-update< at >alvestrand.no
Subject: RE: Draft on IDN Tables in XML

Dear colleagues,

I have been reading this correspondence with Chinese in mind and would like to raise some questions.

This is a case where there are two major forms of a script (Simplified Chinese used, for example in mainland China and Singapore) and Traditional Chinese, used elsewhere. Many characters are the same everywhere but a subset of characters have been abbreviated in the case of Simplified Chinese.

There is an additional complication in the form of a small number of characters that are only used e.g. in Hong Kong (for Cantonese) or Singapore. What would be the best way to include those?

In the RFC3743-style tables at http://www.iana.org/domains/idn-tables/ typically Simplified Chinese Preferred Variants and Traditional Chinese Preferred Variants have their own columns.

http://tools.ietf.org/html/rfc5646 gives the following example tags for Chinese; which should be standard for Chinese in this XML-based system?

==
Language subtag plus Script subtag:

      zh-Hant (Chinese written using the Traditional Chinese script)

      zh-Hans (Chinese written using the Simplified Chinese script)

     Extended language subtags and their primary language subtag counterparts:

      zh-cmn-Hans-CN (Chinese, Mandarin, Simplified script, as used in China)

      cmn-Hans-CN (Mandarin Chinese, Simplified script, as used in China)

      zh-yue-HK (Chinese, Cantonese, as used in Hong Kong SAR)

      yue-HK (Cantonese Chinese, as used in Hong Kong SAR)

   Language-Script-Region:

      zh-Hans-CN (Chinese written using the Simplified script as used in mainland China) ==

A problem that many tables share is that one sees only Unicode numbers, no characters, and so when humans work with the tables, they often need to turn Unicode codes into characters or characters into Unicode codes. Is there any way that the XML could contain both (I think there are Unicode fonts containing nearly all the characters)?

I would be grateful for the answers to any or all of these questions.

Regards,

Chris Dillon.
==
Research Associate in Linguistic Computing, Dept of Information Studies, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) ucl.ac.uk/dis/people/chrisdillon

-----Original Message-----
From: vip-bounces< at >icann.org [mailto:vip-bounces< at >icann.org] On Behalf Of Kim Davies
Sent: 01 March 2012 19:15
To: vip< at >icann.org; idna-update< at >alvestrand.no
Subject: [vip] Draft on IDN Tables in XML

Colleagues,

I have posted a first draft regarding a format that could be used for representing IDN Tables in XML to the I-D Repository:

https://datatracker.ietf.org/doc/draft-davies-idntables/

After discussion with a number of folks that felt this would be good work to undertake, I've put together a first cut which is not comprehensive, but I think goes some way toward a potential format.

Unless there is interest in this being a more formal activity, my assumption is to aim to publish the final result independently as an Informational RFC. However, the mechanism of publication is secondary to coming up with something useful that would benefit TLD registries and other implementors. A list of design goals, from the document, is as follows:

* MUST be in a format that can be implemented in a reasonably straightforward manner in software;
* The format SHOULD be able to be checked for formatting errors, such that common mistakes can be caught;
* An IDN Table MUST be able to express the set of valid code points that are allowed for registration under a specific zone administrator's policies;
* MUST be able to express computed alternatives to a given domain name based on a one-to-one, or one-to-many relationship. These computed alternatives are commonly known as "IDN variants";
* IDN Variants SHOULD be able to be tagged with specific categories, such that the categories can be used to support registry policy (such as whether to list the computed variant in the zone, or to merely block it from registration);
* IDN Variants MUST be able to stipulated based on contextual information. For example, specific variants may only be applicable when they follow another specific code point, or when the code point is displayed in a specific presentation form;
* The data contained within the table MUST be unambiguous, such that independent implementations that utilise the contents will arrive at the same results;
* IDN Tables SHOULD be suitable for comparison and re-use, such that one could easily compare the contents of two or more to see the differences, to merge them, and so on.
* As many existing IDN Tables are practicable SHOULD be able to be migrated to the new format with all applicable logic retained.

It is explicitly NOT the goal of this format to:

* Stipulate what code points should be listed in an IDN Table by a zone administrator. What registration policies are used for a particular zone is outside the scope of this memo.
* Stipulate what a consumer of an IDN Table must do when they determine a particular domain is valid or invalid; or arrive at a set of computed IDN variants. IDN Tables are only used to describe rules for computing code points, but does not prescribe how registries and other parties utilise them.

I'd appreciate any feedback.

cheers,

kim





_______________________________________________
Idna-update mailing list
Idna-update< at >alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update

RE: Draft on IDN Tables in XML

J-F C. Morfin — 2012-03-12T03:07:06

Shawn,
The browsers want to use them. To validate the IDNs. This is why we 
need to get them synced.
jfc

RE: Draft on IDN Tables in XML

Shawn Steele — 2012-03-12T02:13:10

That's I guess what I was getting at.  Eventually someone's going to change their mind on what's appropriate. They can then grandfather in existing ones or figure out how to deprecate them, but, at that time, it seems the actual DNS entries won't match the file here.  Additionally there could be errors.  Presumably the DNS records are authoratative, however if they don't match it could confuse consumers.

So, as a 3rd party, I'm not sure how this information is very helpful to me?  I mean, it'd tell me what the registry hoped to do for it's zone, but that may or may not match the DNS entries.  I can discover valid domains by querying the DNS itself, I don't need to access the list.

I can see how this information might be helpful for tools that help people manage their zones, however any tools that talked to themselves wouldn't necessarily need this format (though it'd help to be able to import/export the data this way, and maybe interoperate better with other tools).

I guess what I'm getting at is:  What kinds of applications are expected to consume this data?  What's the target?

-Shawn

RE: Draft on IDN Tables in XML

JFC Morfin — 2012-03-11T02:29:33

Dear Shawn,

the need for synchronized multilinguistic (on languages) and 
polylinguistic (same data in different language) is a general need 
that can only be currently addressed in an opendata context by a 
registry or DDDS international system, or by an extended DDDS 
mutually operated architecture. It would be interesting to know what 
Microsoft, Google, and others would have to propose. I would be 
interested in working on a joint exploratory draft on this issue 
which is universal and not limited to the Internet. This could be 
part of the JTC1/SG32/WG2 effort, or a totally separate project. It 
should permit contributions by everyone to be kept synchronized 
within a registrant defined TTL and to be freely accessed for 
validity check of table versions and updates.

Best
jfc