<html>
<body>
The problem we face seem to consists in having men and computers writing
and communicating together along a common standard: there are constraints
on the three sides involed. <br>
- Patrick supports the <b>computer</b>, <br>
- Michael the <b>man</b> side, <br>
- and Debbie the <b>standard</b> side. <br>
The need is for a practical, stable and secure interintelligibility among
them.<br><br>
Question: where are the blocking factors we did not identified (we would
have addressed them). I suggest two: <br><br>
- <b>our conceptal confusion. <br><br>
</b>We deal with countries, scripts, and languages is if they were the
same everywhere, based on the same attributes, with the same
characteristics, wherever they are and used. IMHO, to help clarifying
this belongs to the Debbie's standard (metadata) side she already has to
address with ISO 639-4/-6 and her proposed TC46 NWIP.<br><br>
-<b> the lack of conceptual interoperability between man and computer.
<br><br>
</b>We need an interreadibility solution which <b>will not change</b> (so
the network can constantly support it without being delayed by its 10
years hysteresis) <b>but extend</b> (so Michael can support every new
script and writing system he may discover). I think this is possible.
However, the first problem is not with the IETF (which takes care of the
pipe) but with Unicode/ISO (which take care of the UCS). The second
problem will be with IETF: to support a registry architecture for them
(no update, but dated additions). In a nutshell: the current UCS is for
people. We need an UCS for people-and-machines that can span
revisions.<br><br>
This is a challenge. <b>Can Unicode/ISO come with an UCS system Patrick
can work with</b> in using registry based algorithms? Until then I am
afraid all Patrick/IETF can do is to match the current Unicode version.
<br><br>
To better explain what I mean, I introduced the example of the
<b>UCSSEC</b> idea (one code for one secure glyph for several characters
in different script/languages) to extend UCS (one code for one character
for several general glyphs). This means a unique grapheme oriented table,
documented with language/script oriented metadata. Michael can use the
whole data/metadata spectrum, and Patrick use algorithms on the data
layer only. The Internet will only have to work out an adapted
presentation layer mechanism to rebuild the current Unicode set from the
UCSSEC data+matadata. IDNA presently puts it at application level, I
would prefer to put it at OPES level (on the inner edge) for the updates
to be carried by the ISP.<br><br>
<b>This is just an example</b>, there might be simpler and more stable
solutions?<br>
jfc<br><br>
PS. I am glad to see that progressively the points I was denied are going
through (eg. IETF/Unicode MoU would be of great help to formalize the
different inter relational aspects and responsibilities). <br><br>
At 11:12 20/06/2007, Debbie Garside wrote:<br>
<blockquote type=cite class=cite cite="">Hi <br>
I see both sides of this and I think there could be a compromise. I
like<br>
Patrik's "rules" but I can see that they will not work without
some human<br>
intervention. Is there a way forward that will utilise the rules as
a<br>
starting point to produce a base list which is then revised by<br>
UNICODE/script experts?<br><br>
For me, as Editor if ISO 639-6, I would like to see Unicode
Codepoints<br>
allocated to the language writing system (alpha4) code within ISO 639-6
-<br>
that's why I put them there! I put this to the CLDR group last
year. A lot<br>
of work but it would be a beautiful result. Subsets of the
codepoints<br>
allocated to a writing system could be created for IDN purposes.<br><br>
Best regards<br><br>
Debbie<br><br>
> -----Original Message-----<br>
> From: idna-update-bounces@alvestrand.no <br>
>
[<a href="mailto:idna-update-bounces@alvestrand.no" eudora="autourl">
mailto:idna-update-bounces@alvestrand.no</a>] On Behalf Of <br>
> Michael Everson<br>
> Sent: 20 June 2007 09:52<br>
> To: Patrik Fältström<br>
> Cc: idna-update@alvestrand.no<br>
> Subject: Re: New version, <br>
> draft-faltstrom-idnabis-tables-02.txt, available<br>
> <br>
> At 10:27 +0200 2007-06-20, Patrik Fältström wrote:<br>
> <br>
> >>I don't think you can get away with updating without human
<br>
> >>intervention, discussion, and decision. The writing systems
of the <br>
> >>world are not tidy.<br>
> >><br>
> >>If you take this notion on board and embrace it, I think
<br>
> you will be <br>
> >>more comfortable about updating to future versions of
Unicode.<br>
> ><br>
> >The Unicode Consortium have already today a process when adding
<br>
> >codepoints to decide on the property values that today
exists.<br>
> <br>
> Yes, they do.<br>
> <br>
> >I see a big difference between:<br>
> ><br>
> > - Having the IETF use those properties and calculate what
<br>
> codepoints <br>
> >can be used in IDN<br>
> <br>
> Um, that would be a bad idea. The IETF must work together <br>
> with the Unicode Consortium to do this work. There must be <br>
> cooperation... now and in future... between the two
organizations.<br>
> <br>
> > - Having IETF ask Unicode Consortium to define a new
property,<br>
> > and learn how to evaluate for every codepoint
added what property<br>
> > value it should have<br>
> <br>
> I don't see why IETF would be asking for new property <br>
> definitions. What properties do you have in mind?<br>
> <br>
> Again, the IETF has to build into its IDN process a healthy <br>
> liaison with the UTC. Script and character expertise is on <br>
> the side of those who develop the UCS. That's where you can <br>
> ask questions and get clarification. I doubt that IETF has <br>
> the competence to evaluate what property values a character <br>
> "should have". That's not a problem, so long as there is a
<br>
> good liaison process.<br>
> <br>
> >So, starting to have rules for individual codepoints will be a
<br>
> >completely different kind of thing than an algorithm based <br>
> on existing <br>
> >properties, and one of the reasons IDNA is locked today to <br>
> Unicode 3.2.<br>
> <br>
> Patrick.<br>
> <br>
> Of course you have no particular reason to listen to me. I am <br>
> only a linguist and expert in the writing systems of the <br>
> world, who am mostly concerned with adding new scripts and <br>
> characters to the UCS. But I have said for a long time now <br>
> that YOU CANNOT DO THIS WORK ALGORITHMICALLY. Six months? A <br>
> year? I don't know how long. You're going to have to grasp <br>
> this nettle. The writing systems of the world can't be <br>
> reduced to an algorithm. There will ALWAYS be some exception. <br>
> That is why Ken and Mark and Michel have worked on a table <br>
> for use. You can't generate that table from properties. You <br>
> have to choose the table based on intelligent analysis.<br>
> <br>
> Perhaps IDNA is locked on Unicode 3.2 because the IETF is <br>
> uncomfortable with human-selected tables. <br>
> Well, that's IETF's problem, and it is easily solved. Remove <br>
> the pre-condition which you have set, that "an algorithm <br>
> based on existing properties" is the way in which the table
<br>
> is "generated". Then you will be able to make progress.
But <br>
> it's *your* pre-condition.<br>
> <br>
> >I.e. I am extremely nervous implications will be that <br>
> IDNA200x vill be <br>
> >locked to Unicode 5.0 because of this (or 5.1 or whatever
fixed<br>
> >version) just like IDNA we have today.<br>
> <br>
> Write into the rules a joint IETF/UTC process for evaluating <br>
> and agreeing updates as the character set grows in time.<br>
> <br>
> >I was hoping the existing properties would be enough for doing
<br>
> >IDNA200x, and I have still not given up. If the Unicode <br>
> people tell me <br>
> >that is not possible, then things changes quite
drastically.<br>
> <br>
> It is not dramatic. It is simple. You (IETF/UTC) agree a <br>
> table which has a certain content. When Unicode 6.0 comes <br>
> out, you (IETF/UTC) sit together and agree a revised table.<br>
> <br>
> >Yes, I have heard you personally (and others) say that one <br>
> have to have <br>
> >exceptions here and there, but I have still been hoping we <br>
> do not have <br>
> >to have that.<br>
> <br>
> At what point will you give up this hope? You will have to do <br>
> so, I believe. In fact I think (if you will forgive me for <br>
> saying so) that *your<br>
> hope* is the primary stumbling block which has prevented this <br>
> IETF/UTC group from making progress. If *you* give up this <br>
> "hope" we should be able to make progress.<br>
> <br>
> That is my opinion. Perhaps others share it. I am independent <br>
> enough to say it out loud. I am sorry if my opinion finds <br>
> disfavour with you.<br>
> <br>
> >We have sort of had this discussion before, but never really
<br>
> dived into <br>
> >the question of "what happens if we do NOT have the <br>
> exceptions, how bad <br>
> >is that" and compare with the implications of doing
inspection on <br>
> >codepoint level. Is it worth it (regardless of what path we
choose)?<br>
> <br>
> We are here now. We can look at the list of characters in the <br>
> table and inspect them. Did you think an algorithm was going <br>
> to know about writing systems? PLEASE jog yourself out of <br>
> your current abstractions. Writing systems are untidy. <br>
> The table has to be selected by PEOPLE. By this group of
people.<br>
> <br>
> >This is definitely the time when we should have the
discussion.<br>
> <br>
> OK. My take on this hasn't changed for six months or more. <br>
> But if the discussion is now, then it is now.<br>
> --<br>
> Michael Everson *
<a href="http://www.evertype.com/" eudora="autourl">
http://www.evertype.com</a> <br>
> _______________________________________________<br>
> Idna-update mailing list<br>
> Idna-update@alvestrand.no<br>
>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
> <br>
> <br><br>
<br><br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>