Subject: Re: [iucg] WG Last Call for Four Primary IDNABIS I-Ds

From: Elisabeth Blanconil <[email-masked]>
Date: Mon, 10 Aug 2009 20:20:53 +0200

2009/8/10 Vint Cerf <[email-masked]>:
> Folks,
> the following documents are now officially on last call ending August 24,
> 2009. Editorial comments and new issues (only) will be considered:

These documents are now on http://wikidna.org with the exception of
the full tables document. I have two question IRT Patrik's Draft:

1. is it on purpose that section 8 and author come before the
Appendixes? I restored them in the wiki page.
2. the port of the appendix B.1. table did not work with our tool. I
am therefore going to work on the list under excel first. I understand
that IDNA uses the NFC table. I am not sure if the listed codepoints
are only NFC or if not if NFC codepoints should not noted?

I am sure our multilinguists, some ccTLDs and many users will like to
access the excel version of the table.
Best

Elisabeth Blanconil

> Definitions and Document Framework: draft-ietf-idnabis-defs-10.txt
> Protocol: draft-ietf-idnabis-protocol-14.txt
> The Unicode code points and IDNA: draft-ietf-idnabis-tables-06.txt
>
> An updated IDNA criterion for right-to-left scripts:
> draft-ietf-idnabis-bidi-04
>
> The other two IDNABIS documents, Rationale and Mapping, will be submitted as
> soon as possible (this week I hope) for final WG call.
>
> vint

---

From: Elisabeth Blanconil <[email-masked]>
Date: Mon, 10 Aug 2009 20:58:59 +0200

Sorry, I meant that section 8 and author came _after_ the appendixes.

Elisabeth Blanconil

---

From: Elisabeth Blanconil <[email-masked]>
Date: Tue, 11 Aug 2009 13:29:46 +0200

Updated I_D on mapping now in WG/LC has been added to
http://wikidna.org. WG/LC ends August 24, 2009. Editorial comments and
new issues (only) will be considered. As soon as the Rational I_D is
published I will build a single document (with reduced tables) for
printing/working convenience.

Elisabeth

2009/8/11 Vint Cerf <[email-masked]>:
>WG should consider these five documents to be in WG final call.
> vint
>
> On Aug 10, 2009, at 7:45 PM, Erik van der Poel wrote:
>> http://www.ietf.org/id/draft-ietf-idnabis-defs-10.txt
>> http://www.ietf.org/id/draft-ietf-idnabis-protocol-14.txt
>> http://www.ietf.org/id/draft-ietf-idnabis-tables-06.txt
>> http://www.ietf.org/id/draft-ietf-idnabis-bidi-04.txt
>> http://www.ietf.org/id/draft-ietf-idnabis-mappings-02.txt

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 11 Aug 2009 14:05:37 +0200

Elisabeth,

Thanks for noticing this difference in how the documents are generated  
from the XML that is in use in the IETF.

The exact order of the sections will be decided upon (and sections  
will potentially be moved around) at the time of publication by the  
RFC Editor while doing other formatting changes.

I have been in contact with the other document editors, and our  
suggestion to our wg chair is to *NOT* risk destroying the actual  
content of the messages by moving things around at the time of last  
call (both wg and IETF).

     Regards, Patrik

On 10 aug 2009, at 20.58, Elisabeth Blanconil wrote:

> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 11 Aug 2009 08:22:33 -0400

anything that generates diff noise is strongly depricated. the editor 
can sort out template induced artifacts.

---

From: Elisabeth Blanconil <[email-masked]>
Date: Fri, 21 Aug 2009 13:38:14 +0200

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@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 <[email-masked]>:
> 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:[email-masked]]
>> Sent: Friday, 21 August 2009 12:19 PM
>> To: James Mitchell; Vint Cerf; Gihan Dias
>> Cc: idns; Patrik Fältström; [email-masked]; 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
>> <[email-masked]> 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
>>
>>
>>
>

---

From: Elisabeth Blanconil <[email-masked]>
Date: Fri, 21 Aug 2009 19:04:39 +0200

Dear John,
we definitly have two different perspective. You as a designer from
inside the network and me as a use from outside of the network. What
is important is that we can match our position as on an interface no
one is to win.

2009/8/21 John C Klensin <[email-masked]>:
> Elizabeth,
>
> It appears that you are viewing all requests or suggestions from
> language communities as equivalent to each other and,

Absolutely. This is the very basis of multilingualism.

> more
> important, as a situation in which "...different French or Tamil
> registries may adopt different mapping practices...".  In case
> there is still confusion, let me stress two things:
>
> (1) The specifications _forbid_ a registry doing _any_ mapping
> (converting one character or code sequence into another) other
> than
>
>        (i) testing for and, if necessary, applying Unicode
>        Normalization Form C (NFC)
>
>        (ii) Converting one Unicode encoding form (e.g., UTF-8)
>        into another (e.g., UTF-32) for consistency with
>        internal character storage.

you forget one which is :

          (iii) to correct a misuse of Unicode.
          Unicode is Unicode. It is not responsible of the way it
          is being used.

> Registrations occur in terms of final characters only.

I do not know what "final characters" is.
U-labels are expressed in Unicode-points and A-label in ASCII.
Registrations may occur in either or both forms.

> Of
> course, the IETF, as a voluntary standards body, cannot enforce
> that rule.  But it cannot enforce any other rule either.  Those
> who do not follow the standards may encounter interoperability
> problems and may be subject to other authorities.

Correct. The first authority is the user.
Our job is to try to prevent his/her interoperability problems.

> (2) The request from the Sri Lankan Tamil community asks for
> exclusion of a range of characters, i.e., classifying them as
> DISALLOWED.  If they are DISALLOWED, then no registry is
> permitted to register strings that contain them and no lookup
> application should look up any string that contains them either.
> That case produces absolutely predictable behavior.  It also
> does not violate any fundamental rules of Unicode or of the
> IDNA2008 protocol design -- an exception would just be made to
> treat some collection of characters as DISALLOWED that would
> otherwise be PVALID.
>
> What you are asking for where French is involved is a very
> different situation.

The discussion is over the IETF disallowing desire: refusing/forcing.

> First, you want certain characters treated
> differently for some languages that use a given script than for
> others that use the same script.  That is nearly impossible to
> think about, just because there is, in general, no way to know
> what language a particular label is supposed to be associated
> with, nor is there a way to know what top-level domain has the
> label in one of its subtrees (even if one could reliably
> associate top-level domains with languages).

French does not use Unicode. Unicode supports French.

>  Second, if I
> understand your latest note correctly, you would like to have
> those characters treated via some contextual rule ("CONTEXTO").
> But the contextual rules yield either "valid" or "invalid" based
> on adjacent or nearby characters -- they do not provide
> different mappings, nor different rules for different languages
> (the latter at least partially for the reasons above).

We just speak of scripts and their correct semantic usage
(orthotypography). When other characters are Tamil don't we know we
are in a Tamil context?

> And,
> finally, your suggestion requires treating capital letters (or
> at least some capital letters) as distinct from their lower-case
> forms, which would create massive inconsistencies with IDNA2003
> (not just the two characters of inconsistency with which we have
> have had such extensive debates) as well as inconsistencies with
> DNS and host table practices that go back to the 1970s.  No
> matter how strong your justification, and even if it were not
> also tied to differential treatment for a particular language, I
> cannot imagine the WG (or the IETF more broadly) agreeing to
> that change.
>
> Another part of the difference is that the Tamil script is used
> to write only one language or, depending on how one counts, a
> small collection of very closely related languages.

Our point is simple. Future is to idolects (support, authentication,
etc.) and personalized presentations. We do not want anything that
might prevent or delay innovations in that area.

> That makes
> thinking about an exception request much easier than it is with
> the Latin script, which is used to write a very large number of
> languages, some of them with no recent (e.g., conservatively in
> the last 3000 years or so) linguistic relationship to each other
> and that use the script in different ways.  That is a
> long-standing historical problem; there is nothing that the WG
> can do about it today other than to recognize it and move on.

You will note that this is roughly what we advise.
Best.

Elisabeth Blanconil.

---

From: jefsey <[email-masked]>
Date: Sat, 22 Aug 2009 00:11:35 +0200

Dear Andrew and Elisabeth,
I suggest you drop this because you definitly do not speak of the same thing.

>Tough.  The world provides a context which limits our ability to do
>certain things, and part of that world is the technology within it,
>including all its limitations. Just because we made a technology does
>not mean that we control it completely.  It shapes us just as we have
>shaped it.

Andrew, this is precisely what we (users) consider as untechnical and 
want to and will address. We are the bosses, not the machines. This 
is the difference between a network centric (IETF) and a people 
centric (WSIS) vision. IETF wants the Internet to work better (but 
does not document what it does mean), we want our network system to 
work just as we need it.

>In the present case, there is a limitation the technology
>provides, and if you want around that limitation you need to replace
>the technology.

Elisabeth thinks the limitation is in the text.
I think it is in the authors' opposing minds, not in the text.
This is why I say you do not speak of the same thing.
And that the text is technically acceptable.

>I think the chances of DNSng being developed and
>deployed within my remaining lifetime are very small, and surely its
>non-deployment would also prevent or delay the innovations you want.

Not really. This is because we are not actually interested in the DNS 
as a tool. We only are interested in the naming plan it supports. The 
same we are not interested in IPvX, but in the numbering plans they may serve.

One thing at a time. Let first complete the IDNA document set.
Best

jfc

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Aug 2009 11:55:43 -0400

Elizabeth,

language communities as equivalent to each other and, more

	

Registrations occur in terms of final characters only.  Of

different situation.  First, you want certain characters treated
associate top-level domains with languages).  Second, if I
(the latter at least partially for the reasons above).  And,

small collection of very closely related languages.   That makes

So I don't see the analogy you are drawing as being at all
accurate, nor does it appear to me to be helpful to dealing with
either the perceived Tamil numeral problem or the French
majuscule one.

I believe that your inferences about single "IDN tables", etc.,
are 

regards,
   john

p.s. My impression is that the WG is not going to accept this
change unless it can be demonstrated that these characters pose
serious risks (beyond confusability, even within the script) and
that the problems cannot be addressed by registry restrictions.
That would be consistent with other decisions in the past.
However, that is a personal impression as of right now.  It is
not a statement about the WG opinion, nor is it a prediction.
And it is certainly not a statement about my personal
preferences (in part because I don't have one yet).  Things
could change as discussion continues.

--On Friday, August 21, 2009 13:38 +0200 Elisabeth Blanconil
<[email-masked]> wrote:

> 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.
> 
> 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
>...