Subject: Re: [iucg] Prohibiting mapping of PVALID characters

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Thu, 10 Dec 2009 03:33:24 +0100

Dear colleagues,

fascinating is the way our Unicode fellow Members are going to "oppose the
charter, disregard a consensus, reverse a 80% feed back, force the Chair to
"change his mind" and most probably its consensus evaluation, imposing their
interest to their commercial competition, and writing themseleves a paper
legitimacy against the demand of their own users they most probably are
certain they can influence in the same manner".

Also fascinating to realize that all this small group of "60 Hz" people
effort is void. The 60hzians' strategy already failed on TATWEEL. This was
due to the reasonable positions of Siavash Shahshahani and Roozbeh
Pournader. Users' interest and number and technical influence is moving to
the [email-masked] subscribers diversity.

Portzamparc

NB. Microsoft's position regarding the French language has now been archived
as an important pre-experimentation input
http://iucg.org/wiki/Microsoft_IRT_the_French_language_orthotypography -
comments welcome.

2009/12/10 Kenneth Whistler <[email-masked]>

> Paul,
>
> > >Protocol, 5.2:
> > >
> > >5.2. Conversion to Unicode
> > >
> > >The string is converted from the local character set into
> > >Unicode, if it is not already in Unicode. Depending on local
> > >needs, this conversion may involve mapping some characters
> > >into other characters as well as coding conversions...
> > >The results MUST be a Unicode string in NFC form.
> > >
> > >
> > >Strings don't magically get to be "in NFC form", without
> > >being mapped (via normalization algorithm) from whatever form
> > >they started out as, *into* NFC form.
> >
> > In this case, yes they do. That "MUST" is probably wrong; I believe
> > that the statement is meant to say "The results will be a
> > Unicode string in NFC form".
> >
> > John, et. al.: is my understanding correct here?
>
> I repeat: strings do not turn into NFC form by magic. They
> are mapped by the normalization algorithm. And that mapping
> involves, necessarily, PVALID --> PVALID characters in
> this case.
>
> And "the results" will not be a "Unicode string in NFC form"
> unless it is mapped to that. (Except of course, by accident,
> if it happens to start out as NFC in the first place.)
>
> I think what you may be trying to get at is a requirement that
> the only valid *input* to the label processing is a string
> which is already a Unicode string in NFC form -- and that
> how it got to be that way and indeed whether it started out
> as a string in SJIS or 8859-7 or whatever, is beyond the
> protocol's scope of caring.
>
> But if that is the case, then why are we talking about trying
> to add into Section 5.2 a prohibition (a MUST NOT) against
> mapping PVALID characters? Because manifestly, for any
> actual implementation to meet the requirement of having
> Unicode strings in NFC format as valid input for the label
> processing, it MUST map strings (including PVALID
> characters) using the Unicode normalization algorithm.
>
> I understand that maybe you want to say that that isn't
> a requirement *in* the protocol -- it is simply a requirement
> on the well-formedness of valid input to be handled as
> labels. And maybe I don't understand how you distribute
> the MUSTs, SHOULDs and wills around the document to accomplish
> that.
>
> But my essential point here is that you cannot have you cake
> and eat it too -- trying to prohibit mapping of PVALID
> characters in Section 5.2 at the same time that you
> are requiring mapping of PVALID characters in Section 5.2 --
> however the exact protocol wordsmanship of that gets
> worked out.
>
> Maybe you can, for example, prohibit *case* mapping of PVALID
> characters in Section 5.2, while requiring canonical
> normalization mapping of PVALID characters to NFC. That
> at least would be a coherent position. But you cannot
> just prohibit mapping and require mapping of the same
> class of characters, without being more discriminating
> in what you mean.
>
> --Ken
>
>
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: JFC Morfin <[email-masked]>
Date: Thu, 10 Dec 2009 05:03:33 +0100

At 03:33 10/12/2009, jean-michel bernier de portzamparc wrote:
>fascinating is the way our Unicode fellow Members are going to 
>"oppose the charter, disregard a consensus, reverse a 80% feed back, 
>force the Chair to "change his mind" and most probably its consensus 
>evaluation, imposing their interest to their commercial competition, 
>and writing themseleves a paper legitimacy against the demand of 
>their own users they most probably are  certain they can influence 
>in the same manner".

Thank you to quote me!  However, the current effort is _NOT_ void !!!

The Internet standard process requires a certain decorum, otherwise 
the IETF would be flooded.
We known very well that the Chair would try to insert one "MUST" or 
two between the IETF/LC and the IESG.
The current debate is about why he wants to do it, and what IESG will 
think and decide about it.

The issue in front of the IESG at this occasion is the following : 
who should have the IETF leadership (cf. RFC 3935 which describes the 
leadership and its role):
- (a) those who consider the better for the machines
- (b) those who consider the better for the people or
- (c) those who try to uncover the best for both
- (c) those who consider the better for their own agenda

This is not a trivial matter. It MUST be treated with the greatest 
care. And we will certainly appeal if it was not, because we all need 
a clear and documented position which is missing in RFC 3935. RFC 
3935 says that the IETF must influence those who design, use and 
manage the Internet for it to work better. But it does not say better 
for who, and what better means. We MUST know it. This is no 
contention. This is necessity. For example, we cannot talk of network 
neutrality if we do not state that before.

This also is true for ISOC and ICANN. So, we might have to escalate 
an appeal to ISOC if we do get a clear answer (we being the Internet 
community). Life is necessarily made of decisions that some people 
will take as bias. This Internet has a linguistic bias, we must know 
which is its priority bias.

- we known the Chair favors "a". James Seng has been very clear about 
it and he confirmed.
- politically most of people favor "b". We have people like Patrick 
Yeu reminding us all the day long.
- we are many to feel (specially due to Fast Track and IDNgTLDs) that 
ICANN favors "d", and we cannot accept that as stable until it is clarified
- but if we want to serve people with something which works "c" is necessary.

This is why the current debate and its review by the IESG (and IAB, 
and ISOC if we had to escalate an appeal of it) is very important and 
MUST be very seriously considered. Also, technically a new fractal 
element just came in with Andrew Sullivan. I wrote a Draft on IDNA 
being a smooth Transition paradigm for the IETF. Another on IETF 
precautionary duty. Andrew has introduced the concept of a transition 
in this transition. Then Shawn Steele just introduced the idea of a 
transition _within_ an IETF consensus as acceptable, depending on the 
outcome of further debate. This is rather new. Disturbing on a large 
scale, but may be vital on a microecosystem one

It is too bad that we wasted so much time. All the WG work could have 
been wraped-up in three months, and most of the time spent on the two 
fundamental questions we now have to see addressed in the new 
Internet context (greatest change on 40 years, says ICANN).

- who is the IETF working for? what does "better" mean for the Internet ?
- wht about transition as a part of the Internet architecture and 
IETF process?

We must listen, ask, require clarifications to be sure we all 
understand each others on these points. This can call for a lot of 
time if the points are disregarded (three appeals). Or can be very 
quick. The document that Vint promised will a first key indication.

jfc