Tamil Numerals in IDNA - Re: WG Last Call for Four Primary IDNABIS I-Ds

[Elisabeth Blanconil]

Dear colleagues,

This is a collective mail which discusses a strategic non-disclosed
IUCG proposition in the multilinguistics area. It has been reveiwed by
the IUCG Chair and will be published on the IUCG site.

This is a new case of orthotypography based difficulty. The WG is in
theory only interested by characters, translated in unicode points.
However, in many cases natural languages are interfering or quoted in
its Rationale. The WG must officially say how this is to be
consistently addressed.

For exemple, in the WG definitly not considered French case,
upper-cases that support majuscules are DISALLOWED. This is absurd.
They should be CONTEXTO. This seems to be equivalent here. Otherwise,
different French or Tamil registries may adopt different mapping
practices, confuse users, and introduce semantic addressing related
problems. This means that there must be a single "IDN table" (see
below the considered scope) by linguistic entity - that cross natural
language gTLDs may also refer to in their registration policy. JFC has
engaged in a solution which is a mecalanguage layer that must be
specified (hence grammatically documented) for every empowered
linguistic entity (this would be their default "presentation" [IRT
presentation layer] on the network).

However, this calls for much research and multiple agreements (MLTF,
france at large and now IUCG started investigating them several years
ago, within the MAAYA network, in relation with UNESCO, ITU, SIL,
Linguasphere, Intlnet, Linguamon, etc. and in relation with ISO TC39
and 46). The target is that mecalects support, not regulate, human
natural languages, down to idiolects and avalects (avatars). IMHO this
is beyond the scope of this WG.

I would therefore suggest that these issues are :

(1) addressed through a short sub-section in Rationale and left to
CONTEXTO, so registries have an IETF position as a basis for their
policy,

(2) managed by encouraging mapping conventions to be established on a
language basis, most probably in continuation with the effort engaged
by ISO TC46/SG2 introducing administrative languages in ISO 3166-1. We
are touching here national sovereignties when the considered languages
are official languages (let remember there is no official language in
the USA and in many countries - what may delay mecalanguage issues
there. This has WTO related consequence when considering TBT
[technical barriers to trade]).

The IUCG plans to introduce the concept of an NWIP (New Work Item
Proposal) on mecalanguages related tables as an ISO 3166-4 standard.
We have been delayed by late ISO 639-6 publishing. This standard is
now in FDIS. This will permit us to proceed. It is planned to be
introduced in Barcelona at the MAAYA meeting, end of september.

May be the IETF and Unicode could associate themselves to this effort.
The target are normative "mecalocale" files documenting the globally
accepted mecalanguage corresponding to a set of given locale files. In
most of the cases we expect this file to become a national laws as
they will impact legal texts, official databases, passports, automatic
reading, knowledge management, etc. They will actually define national
legal "network presentations" (as in network presentation layer).

This proposition is based upon the achievement of this WG which shown
that one can start from the DNS and Unicode to obtain a stable
multilinguistic basis (in the sense of mult-language interoperation)
and a good presentation layer support (interplus - that we will
publish once the documents of this WG are accepted). This is why we
support this effort, and accept the Charter change if the WG is to
disband; but would also support the current charter, would the WG
continue working towards a full and well documented separation between
the technical (network and unicode), use (interplus and mecalocales),
and UI (user applications) planes.

Elisabeth Blanconil.

2009/8/21 James Mitchell <james.mitchell at ausregistry.com.au>:
> Are we wanting to set the expectation that specific IDN groups can make
> characters DISALLOWED?  What should happen once this WG concludes and
> another IDN group decides some of their characters should be DISALLOWED; do
> we reopen this WG and publish updated documents?  Note that the original
> email said that it was believed that a similar situation exists for other
> South Indian scripts as well as Thai.
>
> I appreciate the work done by the Sri Lanka IDN Task Force, however believe
> this information should be made available to those registries wishing to
> support Tamil and not made an exception in the protocol.  How this
> information is made available is another question, but putting it into these
> documents does not seem the right place.
>
> James
>
>> -----Original Message-----
>> From: John C Klensin [mailto:klensin at jck.com]
>> Sent: Friday, 21 August 2009 12:19 PM
>> To: James Mitchell; Vint Cerf; Gihan Dias
>> Cc: idns; Patrik Fältström; idna-update at alvestrand.no; lisa Dusseault
>> Subject: RE: Tamil Numerals in IDNA - Re: WG Last Call for Four Primary
>> IDNABIS I-Ds
>>
>>
>>
>> --On Friday, August 21, 2009 12:02 +1000 James Mitchell
>> <james.mitchell at ausregistry.com.au> wrote:
>>
>> > I disagree.
>> >
>> > This is a result of case-by-case analysis of individual
>> > characters.  If one does not want the characters in a label
>> > then do not allow them during registration.
>>
>> James, without taking a position on this, it is not
>> "case-by-case analysis of individual characters".  It is
>> exclusion of a block, albeit a small one.
>>
>>     john
>>
>>
>>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>