========================================================================= Date: Tue, 4 Jun 91 09:38:26 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: Edwin Hart Subject: Final Disposition of Minutes This is what I hope will be the final disposition of the minutes. I had numerous discussions with my SHARE manager, Mike Ksar, Isai Scheinberg, Jerry Andersen, ANSI JTC1/SC2 coordinator, etc. Here is what I am doing today: 1. The "Draft Document" with the 30 May will be mailed. Note: "Hannover" is incorrectly spelled as "Hanover". This will be corrected in the Final (August) Version. 2. I replaced the header in the letter to JTC1 Member countries with a US X3L2 header. This gets the document into the US set of records as document number X3L2/91-75. This is the first cover letter. 3. I added a short cover letter to send it to WG2 for distribution as a personal contribution. This gets the document into the ISO records. Note: JTC1 and JTC1/SC2 do not accept "personal" or "expert" contributions, but WG2 does. This is the reason for submission to WG2. This is the second cover letter. 4. I have different fourth cover letters for different organizations: a. for the JTC1 countries b. for Unicode Consortium c. for ECMA/Mr. Hekimi No mention is made of a followup meeting in Geneva in any of the materials. (More on this in another message.) This procedure gets us into the formal ISO distribution, and quickly gets the document to the 30 national standards organizations on my list. Sending it to the US X3L2 committee puts it on the record on one national standards committee. Sending it to WG2 lets ISO know that something is happening and to expect a final document in August (that is, a document in August should not be a surprise to WG2). Ed ========================================================================= Date: Wed, 5 Jun 91 08:54:53 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Comments: Resent-From: Edwin Hart Comments: Originally-From: whistler@zarasun.Metaphor.COM (Ken Whistler) From: Edwin Hart Subject: Re: 10646M Minutes --Notes FYI, anyone else experiencing similar problems? I will be mailing paper copies to everyone shortly. Ed ----------------------------Original message---------------------------- Ed, Plea¬Z¬Z¬Z¬Ze remove the ¬Z's from the document (presumably they are appearing to you as underlining or boldface highlighting). I have had to hand-edit them out of at least 4 versions of the 10646M document now! Anyone who brings that document out of a Unix email environment into a DOS environment is going to be in for an unpleasant surprise when it gets truncated about 20% of the way down the document! --Ken ========================================================================= Date: Wed, 5 Jun 91 08:12:43 -0700 Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: John Jenkins Subject: Re: 10646M Minutes --Notes The Macintosh doesn't truncate when it runs into a ¬Z, but it isn't entirely sure what to do with it, either. Characters outside the range 32-127 would best be left out. (You know, that gives me a really neat idea. Why don't we create a new, really big character set that includes codes for characters not in the ASCII 32-127 range? Then we could exchange data in lots of different languages really easily! Wow! I wonder who I could talk to about trying to do something like that... :-) :-) ) John Jenkins ========================================================================= Date: Wed, 5 Jun 91 14:34:28 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: Edwin Hart Subject: Acknowledgement Please confirm that you received the 3-part message dated yesterday and which was the coverletters and draft document from our meeting. I also mailed everyone paper copies done in a proportion font. Thanks, Ed ========================================================================= Date: Wed, 5 Jun 91 14:39:47 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: Edwin Hart Subject: Next Meeting in August We need to confirm some things for the next meeting: 1. Who will be coming to the Geneva Meeting? 2. Do we want to combine the informal meeting into the WG2 meeting? At our ad hoc meeting, we decided that we needed to have another separate meeting to create the final proposal for submission to WG2. The separate meeting was to occur just before the WG2 meeting but be outside of the WG2 meeting. Mike Ksar has kindly offered to have these discussions as part of the WG2 meeting when WG2 reviews the comments made by the countries and others. He made the points: a. WG2 is a proper place to have these discussions because WG2 ultimately will be rewriting the standard document b. If we need extra time for this discussion, Mike will extend the number of days planned for the WG2 meeting. If we want to take advantage of Mike's offer, then the 10646M committee would not have a final document with a complete proposal. We would only have the existing draft, which is incomplete, and any additional reports that were assigned at the first meeting. Do you (a) want to have a separate meeting as originally planned to create a complete proposal or (b) want to meet as part of WG2 and use the draft proposal as it stands? You need decide so that I can let Mike know if he needs to plan extra time for this topic. Thanks, Ed ========================================================================= Date: Wed, 5 Jun 91 15:00:40 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: Edwin Hart Subject: PLEASE Send Ack to HART@APLVM.BITNET not 10646M Please send the acknowledgement directly to me rather than to the 10646M distribution. I can summarize the results to the distribution. In this way, I will get the mail and not everyone on the distribution. Thanks, Ed ========================================================================= Date: Wed, 5 Jun 91 16:26:01 -0700 Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: John Jenkins Subject: Re: Acknowledgement Got it. John Jenkins jenkinsj@apple.com ========================================================================= Date: Wed, 5 Jun 91 16:35:25 -0700 Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: John Jenkins Subject: Re: Next Meeting in August 1. I can't speak for Apple--especially given the current State of Things, but I do know that Mark asked me to make sure I had a current passport. It looks like Apple will have somebody at the Geneva meeting. 2. I'm going to be wishy-washy and say both (a) and (b). I think that the informal process worked remarkably well in San Francisco and feel that having an informal meeting before the formal WG2 meeting would help people both iron out any problems they have with the current "10646M" and also work towards a common ground in a setting when they feel more com- fortable because they aren't formally committing themselves to anything. At the same time, I think that having 10646M formally part of the Geneva meeting would help convince Unicoders that the 10646 fans are serious in trying to achieve a common ground. In short, I think a brief ad hod meeting before the formal meeting is the best bet. By the way, let me as a low person on the Apple totem pole add my congratulations to how you handled the SF meeting. I admit that my understanding of the past poilitics is limited, but I was very im- pressed that you were able to help people of such disparate viewpoints understand one another and strive towards a common understanding. John Jenkins jenkinsj@apple.com ========================================================================= Date: Thu, 6 Jun 91 11:52:00 +0100 Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: KNAPPEN@VKPMZD.KPH.UNI-MAINZ.DE Subject: Re: Acknowledgement Yes, I received all three parts. Yours, J"org Knappen. ========================================================================= Date: Thu, 6 Jun 91 09:36:54 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: Edwin Hart Subject: Re: Next Meeting in August In-Reply-To: Your message of Wed, 5 Jun 91 16:35:25 -0700 > >By the way, let me as a low person on the Apple totem pole add my >congratulations to how you handled the SF meeting. I admit that my >understanding of the past politics is limited, but I was very im- >pressed that you were able to help people of such disparate viewpoints >understand one another and strive towards a common understanding. Thank you. Remember that I had a lot of help from BOTH sets of people and that most of the people really wanted to have one code. We had to have an environment where we could explore merger issues openly. We were able to set that environment in San Francisco. With some new people in Geneva, this will be another challenge if we choose to meet informally. Ed ========================================================================= Date: Thu, 6 Jun 91 17:00:00 GMT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: "Ecological Linguistics,Anderson, PRT" Subject: Yes on August Ad Hoc 1. I will attempt to be there for the August Ad Hoc meeting and for WG2 2. There should probably be both an AD HOC ahead of the WG2 and also discussion within WG2, so that we can have a relatively more neutral environment in which to work out further proposals for a compromise. Do not see why need to extend the time for WG2, since under normal conditions all proposals and comments made available to it by national member bodies must be considered within it, and time allocated accordingly. 3. We need to be careful in the meantime to prepare long BEFORE the next Ad Hoc meeting. Various considerations: A. TO INCLUDE THE EUROPEANS (not as suggested by one participant deliberately to exclude certain people). This inclusion must be from the beginning, in planning meetings, not just as invited guests after everything is planned. We are currently making the mistake of following this second procedure. B. TO TREAT THE GLASS AS HALF FULL AND HALF EMPTY AT THE SAME TIME. As noted in a previous paper, the current minutes of the compromise meeting are slightly slanted towards the Unicode point of view. Redressing this bias requires separating the C0 and C1 space issues, and being excruciatingly careful in asking questions about C0 space from all points of view. All participants need to be on notice to be open and forthright in admitting that either current solution with existing software, or the very simplest rewrite of any kind of software (whether programming languages or communications links) will not achieve everything that has sometimes been claimed for it. When these questions have been asked in both directions, and clear facts established, then everyone may be in a position to agree at least about what is technically possible. Then negotiations about what balance to strike will be fruitful. C. Isai Scheinberg has started off well in one respect, by carefully inviting representatives of several compoanies to get involved in the C0 committee, since they have strong concerns about C0 and communications software or hardware. However, the same invitation is needed for representatives of companies who have concerns about the null-prefix for ASCII from the point of view of programming languages. There is no asymmetrical burden-of-proof, nor should anyone go into these meetings feeling that it is only misguided individuals on the other side who need to have things clearly explained to them after which they will of course see the light and change their view. Isai does not have the advantage of Ed Hart in being at least relatively neutral on the possible solutions which would be desirable on this question. He has been a very active proponent of one particular solution which he himself proposed. This requires incredible amounts of leaning over backwards if it is to either be or be seen as a fair proceedings. If there is someone highly knowledgable on this subject who has not been a strong advocate of one side or the other (hard to find such a person) we should do everything in our power to get them to chair this effort. This is nothing personal against Isai, just the facts of his involvement in promoting one side of the debate. He has himself stated the criteria in indicating why Mike Ksar would not be a neutral chairman in matters of working out a compromise. D. While a great deal of credit goes to all of the participants at the Ad Hoc meeting in San Francisco after the WG2, and especially to chairman Ed Hart for his tireless work, there is another category where we need special awards. CREATIVE COMPROMISE AWARD should go to Masami Hasegawa for taking the leap and the risk, in recognizing that it is possible to have a pure 16-bit code (for Unicoders) as one PART, and a pure 32-bit code as another PART, and all compaction methods as a third PART of a single code standard. This cut through one of the major barriers to compromise, to the great surprise (I heard it expressed) of several Unicoders. DO WE HAVE ANY CANDIDATES from the other side? Perhaps there have been some I take for granted and do not credit sufficiently? The only issue I can see immediately concerns C0 space. It would be an admission that Unicoders could live with an international standard in which ASCII were prefixed by Hex 20 not 00, and transform internally to prefixing 00 if they really need it for their programming languages (until those are further rewritten?) (but of course if prefixing ASCII with Hex 32 does not really gain much of anything for the other side of this debate, then it should be dropped as a requirement. At that point, the entire 64K would be free for coding as Unicode or perhaps in any other way which our present knowledge sees as superior. E. And YES to Ed Hart, did receive even the printed copy already in the mail. Lloyd Anderson ========================================================================= Date: Fri, 14 Jun 1991 13:31:05 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: schein@TOROLAB5.VNET.IBM.COM Subject: Next 10646M meeting in August Ed, I will be most probably coming. I prefer alternative (a) - to have a separate meeting, immediately before the WG2 meeting, the way we planned it in SF. The status of such meeting can be either completely informal, as in SF, or WG2 AD HOC meeting for a special purpose - to prepare 10646M draft. However, if majority prefers to extend WG2 meeting and to start 10646M discussions there - I can live with this option too. In any case, I assume that the extended or separate meeting will start on Monday, August 19. Please confirm. Isai ========================================================================= Date: Wed, 19 Jun 1991 12:34:24 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: Edwin Hart Subject: Decision on August Meeting Enclosed is my list of people and their responses to 1. receiving the minutes 2. if they will be in Geneva for the meeting 3. do they want to meet as part of WG2 or separately 4. notes on other who do not have e-mail, or other comments. What I think we should do is to get together informally just before the WG2 meeting for a short period of time (dinner the night before/breakfast?). The goal would be to bring everyone up-to-date, to obtain the reports, etc. (Those reports must also go to WG2.) This goes along with the idea of John Jenkins that we should get together but it should be a short meeting. This also is the result of a recent phone conversation with Mike Ksar. From Isai, I learned that the DIS did not pass. Mike has seen nothing official yet. Assuming that Isai's information is correct (and I have every reason to believe him), those of us who want an international standard are in deep trouble. If we cannot achieve consensus in WG2 and SC2, we will have no international standard. Mike Ksar certainly wants an international standard and wants WG2 to get to consensus at the August WG2 meeting. We need to work with Mike (in the same way that you worked with me) at Geneva in WG2 to achieve that consensus. What we achieved in San Francisco in our informal meeting was 1. people open to a new opportunity 2. people willing to consider new viewpoints 3. people WHO WANTED to achieve consensus on features to get to one code 4. people who wanted to avoid supporting two incompatible codes We were trying to get a win/win situation where 1. we would agree on the features of one code 2. features of Unicode would be incorporated into 10646 3. ISO would get broader agreement (consensus) on 10646 and therefore have a much better chance of having a positive ballot When every delegate goes into the WG2 meeting with this kind of attitude, like the informal meeting in San Francisco, WG2 will have an excellent chance of achieving consensus. If indeed the 10646 ballot was negative, the delegates will know that 10646 is in trouble unless consensus is achieved and the delegates will be more open to changes to achieve consensus. In summary, make travel plans to attend the WG2 editing meeting and we will meet just before it for a short while. Mike is waiting to read the comments before he decides on the actual WG2 meeting dates. He is inclined to start on Monday (19 August) and end when the work is done on either Friday (23 August) or on Wednesday (28 August). Let's push our support behind the WG2 effort to gain consensus. Best regards, Ed __________________________________________________________ Receive Attend Join WG2/ No Response Minutes Geneva? Separate? Jerry Andersen No Lloyd Anderson Yes? Separate Joseph Becker Yes F. Avery Bishop Yes WG2 Willy Bohn Indirect Email Mark Davis x Asmus Freytag Yes Yes Joachim Friemelt Not on Email Edwin Hart Yes Yes Masami Hasegawa Yes WG2 Huang, Weimin Not on Email Olle Jarnefors x John Jenkins Yes Apple Separate Bo Jensen Indirect Email Mike Ksar Yes Yes WG2 Takayuki Sato x Isai Scheinberg Yes Yes Separate Karen Out of Office until 1 July Smith-Yoshimura Michel Suignard Yes J. G. Van Stee Yes No Kenneth Whistler Yes No Zhang, Zhoucai Not on Email ¬ ¬ ¬ | | | | | | | | 3-WG2 | | 3-Separate | | 9-yes 8-yes 13-no 3-no answer 11-no answer Apple will likely send a representative ========================================================================= Date: Wed, 19 Jun 1991 16:29:34 EDT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: schein@TOROLAB5.VNET.IBM.COM Subject: C0 work group Hello 10646M folks! Below pls find the objective, methodology and plan for the C0 working group: The objective of the C0 working group is to assess the impact of assigning graphic characters to the C0 area. To simplify the work the two alternatives will be analyzed: A) 2-octet code which assigns graphic characters only to code positions, which do not have values '00'-->'1F' and '7F' in either of the two octets. B) 2-octet code which assigns graphic characters to all code positions, except: '0000' --> '001F', '007F', '0080' --> '009F' The group will assess benefits and problems of each approach, the scope of the problems, the solutions (if any) and costs of the solutions, and provide recommendation to the ISO SC2/WG2 by August 19, 1991. The methodology, that I propose, is to analyze consequences for several VERY SPECIFIC applications (e.g. Internet, X/400, X/500, ...) which seriously consider implementation of the global code in the foreseeable future. The draft 'project' plan is: Step 1: To form the group and select editor for the report - by June 20 The following people are in the C0 group now: Willy Bohn (University of Hannover/ECMA) Mark Davis (Apple) Tom Hastings (Digital) Robert Hawley (Aplle) Johnny Eriksson (INTERNET) Mike Ksar (HP) Bernard Marti (SC2/CCITT) Greg Vaudreuil (INTERNET) Yun-Foo Lum (CCITT) I asked Willy Bohn to serve as editor and waiting for his reply. Step 2: Ask for contributions which will identify specific problems in major applications (communications or elsewhere) when C0 is coded or not coded. As stated above, it is important that the applications should be the ones which reasonably consider to implement UCS sometime (for example, the fact that some ASCII terminal can not cope with C0 will be of little interest, IF it is not able to cope with ANY 2-octet code - with or without C0 coding). The contributions should preferably describe possible solutions to the potential problems with assessment of the costs of the solution. Contributions should be sent by July 12. I am taking upon myself to obtain information from the X.400 and X.500 groups on whether C0 coding imposes any difficulties to them (X.500 and X.400 have indicated that they plan to implement UCS, when available). Step 3: Discuss the contributions by EMAIL/phone/etc, with possibility to have a meeting in Toronto (in July). Step 4: Editor will write a draft report based on the contributions and discussions - completed by August 9. Step 5: C0 work group meeting in Geneva on August 15-16 (before the WG2 and/or 10646M ad-hoc meeting). Objective of the meeting will be to discuss the draft report and propose necessary corrections. I assume/hope that we will be able to reach the consensus. Step 6: The updated report submitted to the WG2 in August. I will appreciate any comments or suggestions to the above. Isai ========================================================================= Date: Wed, 26 Jun 1991 17:30:00 GMT Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: "Ecological Linguistics,Anderson, PRT" Subject: C0 work group comments This note is being transmitted to the 10646M distribution list. My apologies if you are receiving a duplicate. I had originally sent it only to 10646 and Unicode mailing lists, among other things on the assumption that anyone on 10646M would be on one or the other of those. Isai has specifically requested that it be sent properly to the 10646M list, to receive a proper response, and in this he is correct. Perhaps my other distribution would have excluded someone, and indeed that is the last thing I would want to do. Are there any of you on the 10646M distribution list who are NOT on the 10646 or the Unicode lists? If so, please let me know, so that I can more efficiently avoid duplicates in the future. (I will try to find out about all future additions to 10646M to check them against other lists.) Also, if you have not received my earlier pape "Progress on C0 ??" which I recently sent out again, please let me know and I can send it to you individually. I am very conscious of the excess amount of EMail and paper and the burdens on all of us. -------------- This note concrns the proposed plan of action for the "C0 work group" within the framework of the 10646M merger discussions between Unicode and 10646. I urge all participants in international coding efforts to contribute to this discussion by formulating the most cooperative and creative presentations of the questions they can, and contributing these to the discussion. No mailing list has yet been published that I am aware of to communicate questions and proposals to those working on the technical problems, or to receive interim indications of their thinking. My purposes in this note are to assist in insuring a full and fair consideration of technical questions, and open procedures, so that both substance and appearance of validity can attach to the results. It is important that any proposal should in fact be the technically best possible. It is important that those who take semi-strong positions on these issues on one side or another should have a high likelihood of being convinced by any resultant proposal. (There are some extremists no doubt on both sides who, as in any debate, may not be convinced. We hope of course to minimize this but must accept reality.) I have no personal view as to what the technical outcome should be, nor that some compromise should be somewhere in the middle merely for the sake of compromise. Because of much difficulty in getting fair consideration of these issues in the past, disputes which not all receiving this message will be aware, I will be very detailed in my comments below. 1. The statement of purpose is *balanced* in its two paragraphs for the two alternatives for analysis, which I repeat here (with the minor exception that a high proportion of Unicode representatives consider only a 16-bit code and not a 2-octet code to be at issue -- this is a purely terminological and political-religious distinction until specific consequences of the distinction are invoked): A) 2-octet code which assigns graphic characters only to code positions, which do not have values '00'-->'1F' and '7F' in either of the two octets. B) 2-octet code which assigns graphic characters to all code positions, except: '0000' --> '001F', '007F', '0080' --> '009F' 2. The overall statement which precedes it is not quite balanced, because it says "The objective of the C0 working group is to assess the impact of assigning graphic characters to the C0 area." where it could say "... of assigning graphic characters to the C0 area or of not assigning graphic characters to the C0 area." This choice tends to assign a burden-of-proof, not considering what the other side of this debate could do to compensate in case of not assigning graphic characters to the C0 area. 3. In creferring to applications which have relevant interaction with this question, there is the paragraph: "As stated above, it is important that the applications should be the ones which reasonably consider to implement UCS sometime (for example, the fact that some ASCII terminal can not cope with C0 will be of little interest, IF it is not able to cope with ANY 2-octet code - with or without C0 coding)." This properly states the burden of proof from one side, via an illustrative example, and that applications which cannot cope with ANY 20-octet code are not relevant in the same ways. However, *there is no corresponding burden-of-proof statement from the other side*. For example, one might say that the fact that some programming language cannot cope with the basic ASCII 128 characters assigned anywhere EXCEPT to row 00 will be of little interest, IF that programming language is not able to cope with a full set of constants and variable names which is truly multilingual, allowing all writing systems of the world.". 4. In fact, such burden-of-proof statements in both directions can be a lot more subtle and sophisticated. I have made some attempts at this in a paper "Progress on C0 ??" which is enclosed. 5. The definition of the problem and the example cited above in (3.) does not refer to "how much work is it to gain X goal" in either direction, but only to implementations which in their current forms cannot cope with C0. The more sophisticated questions include "how much work is it to make existing implementations (of whatever) capable of handling a 16-bit or 2-octet code which does not use C0 space, versus how much work is it to make existing implementations capable of handling a 16-bit or 2-octet code which does use C0 space." On the other hand, the questions include "how much work is it to make existing programming languages able to handle a 16-bit or 2-octet code which places the 128 ASCII characters in row 00, versus how much work is it to make existing programming languages capable of handling a 16-bit or 2-octet code which places the 128 ASCII characters in for example row Hex 20, decimal 32." 6. It is very important to distinguish between the 00 row of the 16-bit plane, and the 00 plane of the 00 group of the 32-bit space. I used to think these were the same issue, but recent discussions on the Unicode side have revealed to me that they are potentially distinct. The Unicode response to 10646M specifically indicates that in order to have compatibility between 16-bit and 32-bit codes (even assuming only these two modes and no other compactions) that it is important to have the numerical values the same in both, so that uppercase "A" would have the values for example (if ASCII were placed in the row for Hex 20) in Hex "2041" and "002041" rather than "2041" and "202041" or "572041". Of course Unicoders are actually advocating "0041" and "000041", with the further numerical equivalence to the 8-bit form "41". Whether there is any gain from having the 16-bit multilingual plane not use C0 but be in plane 00 of the larger 32-bit space is I think one of many technical and practical questions to be considered. I can certainly argue on both sides of it, based on the arguments which have been circulating. 7. The limitation of the considerations to applications which are implementing or considering implementing a full 2-octet or 16-bit code *does* eliminate from consideration a portion of the issues concerning easy upward migration path, and the possibility of transmitting 16-bit or 2-octet codes across devices not originally intended for them, precisely a part of the issues relevant to the discussions over use or non-use of the C0 space. The delimitations of relevant issues should be made by the members of the work group themselves, with a generally inclusive rather than exclusive perspective (nevertheless with a clear sense of relevance). Composition of the group: 8. Willi Bohn will certainly do a fine job as editor, and we should be very grateful to him for agreeing to take on this task (especially given limited resources we all have). 9. I am somewhat concerned becausse I personally know that two of the individuals participating from the "we-must-use-C0" side are very strong willed and have extensive experience in these debates. I am not as clear about who representing the other side is represented on the committee who is equally tenacious and experienced in these debates (and I certainly do not know all of these individuals from their past participation in EMail or international standards committee work, nor should the participants all be from such backgrounds). There *may* thus be a very substantial imbalance, of a sort which for example jury selection procedures in the USA attampt deliberately to avoid. (Yes this is not a jury, but ...) 10. The short time frame is necessitated by the meeting of WG2 in Geneva on 19th August. And by adequate time for the editor Mr. Bohn to prepare a report (information received by 12 July, report by 9 August). This has the result that those participants who are not already highly experienced in the ways of debate on this topic will hardly have time to become become familiar with them. However, it has apparently been decided not to have a meeting of the 10646M group prior to the WG2. Therefore it might be possible to continue discussions till the end of August, and Mr. Bohn send out a draft report for comments by the 9th, with a final report to be distributed at the meeting of the 19th August? I realize this is an extra burden on the editor Mr. Bohn which may not be possible. It is my experience in similar situations that time for extensive feedback on a draft report is essential, as even the most well-meaning editor can easily choose words which have an unintended interpretation or which unnecessarily inflame one side of the discussion for totally non-technical reasons. 11. It is customary in difficult negotiations to include a number of people whose commitment is to negotiation, mediation, full consideration of all issues, and fair process, rather than to particular technical concerns or particular outcomes. This leavening stabilizes the social "center" of the group, emphasizing the goal of the common good rather than particular special or vested interests. Perhaps several such individuals can be added? 12. Because I put in a lot of work summarizing the arguments available to me at the time, with no intent to prejudge any outcome, I enclose the paper "Progress on C0 ??" (to the Unicode list only; the 10646 list already received it). I will participate in this as actively as I am able to and permitted to until the 29th June and after the 16th of July. Yours, Lloyd Anderson, Ecological Linguistics ========================================================================= Date: Wed, 26 Jun 1991 18:36:36 pdt Reply-To: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> Sender: "10646M: Multibyte code working group" <10646M@JHUVM.BITNET> From: SATO_TAKAYUKI_K/HP8900_E2@HPCC05.CORP.HP.COM Subject: Models ....................................................................... FROM: SATO_TAKAYUKI_K/HP8900_E2@hpcc05 TO: 10646M@jhuvm.bitnet ....................................................................... Are there any one who did take a note of presentation with regarding Unicode model and 10646 model ? Takayuki K Sato