Thanks to Tim Greenwood for acting as Secretary at this meeting, and providing notes to supplement those taken by Steve Greenfield as Scribe. Please review the Minutes for accuracy, and send any amendments to Steve Greenfield at unicode-inc@unicode.org. Please note that corrections to the section on Korean have been made to reflect the postings that several people made to unicore@unicode.org after the UTC meeting. -- Joan ============================================================ Unicode Technical Committee Meeting #62 Friday, September 30, 1994 Toronto, Ontario Hosted by IBM-Canada Chair: Joan Aliprand Vice-Chair: John Jenkins Secretary: Tim Greenwood Scribe: Steve Greenfield Attendees: Corporate Members: John McConnell, Apple jmcc@apple.com Tim Greenwood, Digital greenwood@r2me2.dec.com Mike Ksar, HP ksar@hpcea.ce.hp.com Don Carroll, HP don_carroll@hpboi1.desk.hp.com John Gioia, IBM gioia@vnet.ibm.com Fred Bealle, IBM fbealle@vnet.ibm.com Alexis Cheng, IBM alexis@vnet.ibm.com Hossein Kushki, IBM kushki@vnet.ibm.com Marty Marchyshyn, IBM martian@vnet.ibm.com Lisa Moore, IBM lisam@vnet.ibm.com Uma Umamaheswaran, IBM umavs@torolab6.vnet.ibm.com Ed Batutis, Lotus ebatutis@lotus.com Sungi Hong , Microsoft sghong@microsoft.com Young Lim, Microsoft youngl@microsoft.com Lloyd Honomichl, Novell lloyd_honomichl@novell.com Joan Aliprand, RLG br.jma@rlg.stanford.edu John Jenkins, Taligent john_jenkins@taligent.com Kelsey Bruso, Unisys bruso@unirsvl.rsvl.unisys.com Associate Members: John Bennett, Sybase jrb@sybase.com Individual Members: Tex Texin, Progress Software texin@bedford.progress.com Officers: Joe Becker, Xerox becker.osbu_north@xerox.com Liaison: T.J. Kang, WG2-Korea Liaison Unicode Office Manager: Steve Greenfield unicode-inc@unicode.org Guest: Dirk Vermeulen, CASEC ============================================================ Document Registration: UTC62-94-020 Agenda UTC62-94-021 Action Items from UTC #61 UTC62-94-022 Korean Proposal UTC62-94-023 Missing Glyph Font UTC62-94-024 Glenn Adam's Report on IRG-Peking UTC62-94-025 Text of Draft comments on PDAM UTC62-94-026 Proposed Draft of Amendment 1 (ISO Doc) UTC62-94-027 Comment concerning PDAM UTC62-94-028 Repertoire of Unified Aboriginal Syllabics UTC62-94-028A Revision provided by John Gioia ISO-IEC JTC1/SC2/WG2 N884 Multi-Octet Coded Character Set UTC62-94-029 Draft UTF-16 (PDAM 2) UTC62-94-030 Draft UTF-8 (PDAM 1) ============================================================ Approval of Minutes for UTC #61: Joan Aliprand had some typographical corrections. Mike Ksar pointed out that the dates for the WG2 meeting in October should be "October 10-14". Motion to approve the Minutes as amended moved by Lloyd Honomichl, seconded by John Jenkins. Motion approved by consensus. *** Action Item (Aliprand, Greenfield) *** Incorporate amendments into the Minutes for UTC #61, and distribute amended Minutes to "minutes" distribution list, and to anyone present at UTC meeting #61 who is not on the "minutes" distribution list. Future UTC and Other Meetings: UTC #63: This meeting, originally scheduled for December 1-2, is the annual Membership Meeting, at which Directors are elected. Apple and Borland are co-hosts. It was previously decided that the meeting would be held in Cupertino (at Apple facilities) rather than at Borland's offices in Scotts Valley (which would necessitate a longer drive from the airport via Highway 17). Aliprand said that, because of the crowded agenda for UTC #62, the formal announcement listing the Directors whose terms expire at the end of the year, and soliciting nominations, would be sent to Voting Members by e-mail. *** Action Item (Aliprand, Greenfield) *** Send preliminary announcement re Board elections. X3L2 Meeting Schedule: Ed Hart, Chair of X3L2, had requested co-location of X3L2's meeting with UTC #63, and suggested the following schedule: Wed. 11/30, AM X3L2 meeting Wed. 11/30, PM UTC Subcommittee meetings Thurs. 12/1 UTC meeting Fri. 12/2 X3L2 meeting Ksar expressed support for co-location of the meetings. Hart's proposed schedule was approved by consensus. *** Action Item (Ksar) *** Inform Hart verbally that UTC agreed to his proposed schedule. *** Action Item (Greenfield) *** Formal notification to Hart that UTC agreed to proposed schedule. UTC #64 (March 1995): Bay Area meeting. Taligent is willing to host. Friday, March 10, 1995 was set as the date. UTC #65 (June 1995): Bay Area meeting. To be coordinated with X3L2. X3L2 may be meeting with X3V1 in Colorado. Friday, June 2, 1995 was set as the tentative date. *** Action Item (Greenfield) *** Contact Ed Hart re X3L2 plans. UTC #66 (September 1995): Outside Bay Area meeting. Digital and Lotus offered to co-host this meeting. Exact location (Boston or Nashua) to be settled by the host companies. The meeting will be held late in September; Friday, Sept. 29 was set as the tentative date. Note that UTC #62 should have been held in the Bay Area, but was held in Toronto because Toronto's fall weather was preferred to winter. UTC #66 conforms to the regular cycle. Report from the Unicode Office: Greenfield reported that the Office receives 5-10 inquiries per day. Favorable articles have appeared; Byte Magazine and PC Magazine will be publishing articles, as will two Japanese magazines. A reporter from the Wall Street Journal's Tokyo office asked for information. Unicode Implementers' Workshop #6: Because of the crowded agenda for this meeting, Honomichl had limited time for this report. Aliprand said that a more detailed report would be sent by e-mail to members. Tim Greenwood formally congratulated Lloyd Honomichl for a job well done. *** Action Item (Kernaghan, Honomichl) *** Send more detailed report on UIW #6 to members. Editorial Sub-Committee: The full Unicode 1.1 will be published with an accompanying CDROM (which has been agreed to by Addison-Wesley). Contents of the CD-ROM were envisioned as the mapping tables, sample code, excerpts from documents, etc. The deadline for submitting material for inclusion on the CD-ROM is the end of October. Projected date for final text is the end of December, with publication in 1Q95. *** Action Item (All) *** Anything that people wish to contribute should be sent in by the end of October. Please make sure that your contribution is error-free. *** Action Item (Taligent) *** Taligent is taking charge of making sure the Han mapping tables are as clean as possible. *** Action Item (Greenwood) *** Non-Han mapping tables need to be reviewed. Greenwood has this work item, and is to contact McGowan. *** Action Item (Corporate Members) *** To put their corporate mapping tables on ftp site. Each corporate member is responsible for accuracy of its mapping tables. Ksar recommended including the workshop papers on the CD-ROM since they are already in soft copy. All UTC members were most concerned that accuracy be the prime goal of the publication, and that if required the publication date be slipped to enable a thorough review. This may require a special meeting, or perhaps an extension of the December UTC meeting. It was the sense of the meeting that final copy should not be sent to Addison-Wesley without review by Member representatives, even if it meant a later publication date. Gioia asked for a review period of 4-6 weeks, to allow distribution within IBM. Motion for Davis and Adams to prepare a publication schedule with milestones, and send it to the Membership via e-mail, moved by Honomichl, seconded by Moore and Batutis. Approved by consensus. *** Action Item (Jenkins) *** By Oct 3, notify Davis and Adams about the motion. *** Action Item (Davis, Adams) *** Establish a calendar with milestones for publication, including a period for Membership review. A special meeting to review the text may be needed. By Oct 7, send the calendar to potential reviewers. Proposal for a "Missing Glyph" Font (UTC62-94-023): This paper was prepared by Mark Davis (Taligent), who proposed a small standardized set of glyphs, each representing a particular script block, to be used when a font for the script is unavailable. Though you could see the character itself, you could tell what its script block is. This paper received a mixed response. Some of the glyphs that Mark had chosen were considered too complex to show up well on video screen resolutions. Several people felt that establishing such a font not an appropriate activity for th e UTC, and that other methods of identifying a script block were possible (e.g., an abbreviation based on the name of the block). There was no objection to including Taligent's font on the CDROM, but the UTC will not endorse it as a standard. East Asian Sub-Committee: Report on IRG #3 in Beijing from Glenn Adams (UTC62-94-024) was distributed. IRG #6 is to be held in the United States. The Officers have discussed whether the Consortium should co-sponsor with other organizations (e.g., ANSI and/or AFII), but no action has been taken as yet. Jenkins reported that a mapping table between Unicode and GB12345 has been published in Taiwan, but it is full of errors. This is not an official mapping table compiled by the Consortium, but, because of the errors, it is harmful to h ave it available. We need to work with the originators to correct the errors. As an inducement to correct the table, we will offer to make the table available at our the FTP site and include it on the CDROM provided the errors are corrected. *** Action Item (McGowan, Jenkins) *** Put a copyright notice *in* each of the tables to deter proliferation at multiple sites (and possible modification). This notice should include a statement that the original source table can be obtained from the "unicode.org" ftp site. *** Action Item (Jenkins) *** Contact the compilers of the Unicode-GB12345 mapping table. Offer to place their table at the ftp site and on the CD-ROM if they clean it up. Presentation on Canadian Aboriginal Scripts: Dirk Vermeulen of the Canadian Aboriginal Syllabics Encoding Committee (CASEC) presented the Committee's work on identifying a repertoire of writing symbols used in various communities in the north of Canada to write the languages of the Algonquian (Cree and others), Athapascan, and Inuktitut peoples. CASEC has reworked its original character repertoire to make use of composed character sequences. Dirk works with a school board whose territory covers 400,000 square Km. These very isolated communities make high use of fax and computers. Probably about 70,000 people in all. The school systems each developed computer material using the native scripts, but could not exchange data. There was a conference in 1985, about 4 years study, went to Government level in 1990. Missionaries introduced the syllabic script based on Pitman shorthand symbols for Algonquian languages. The base set moved to two other language groups -- Inuktitut and Athapascan -- introducing new symbols. Note that comparable language groups in the United States do not write in syllabic script, but use Latin script. Issue of composing or fully composed characters. CASEC would like all 651 precomposed characters in the BMP. Alternatives are put all precomposed outside the BMP, or use composed character sequences, with the 274 base characters and no n-spacing marks in the BMP. (These characters could also be placed outside the BMP, but a request to add only 274 is likely to be received more favorably than a request for 651 precomposed characters.) General arguments are in favor of coding as decomposed: gives advantages on searching, and accommodating new forms of characters that may be found in isolated communities. Display technology is fairly stable for support of decomposed encoding. It was the sense of the meeting that the UTC would support a work item proposal from the Canadian national body to WG2. *** Action Item (McGowan) *** Make sure the Scripts and Symbols SC has latest version of the CASEC work. PDAM-1 (UTF-16) and PDAM-2 (UTF-8): The U.S. positions on PDAM-1 and PDAM-2 were reviewed. The UTC recommended removal of editorial and typographical comments to strengthen the U.S. technical comments; editorial and typographical comments could be submitted as a persona l contribution from Ed Hart (Chair of X3L2). Some other clarifications were made. *** Action Item (Jenkins) *** Send UTC comments to Ed Hart for inclusion in U.S. position documents. Implementation Sub-Committee: John Gioia sent e-mail outlining the current state of the "Unicode Implementation Guidelines" prior to the UTC meeting. He requested UTC members to read what has been done, and submit new material (including details of vendor-specific implementations). The target date for completion is 4Q95. Some of the proposed text repeats introductory material from "The Unicode Standard," and could be dropped. Moved by Greenwood, seconded by Honomichl, that Gioia publish a timeline for the project, showing milestones. Approved by consensus. *** Action Item (Gioia) *** To request volunteers via a posting to unicore@unicode.org. *** Action Item (Gioia) *** Publish timeline per motion. Proposal re Korean Hangul from Microsoft Corporation: Composite of notes taken by Joan Aliprand, Steve Greenfield, Tim Greenwood, and John Jenkins. Composite prepared by Joan Aliprand, and posted to unicore@unicode.org on Monday, October 3. This version incorporates the corrections/clarifications posted to unicore@unicode.org by several UTC attendees. For consistency, "ancient" has been changed to "old" throughout. Corrected lines are marked with '|' in the left-hand margin. =========================================================================== Alternatives for Encoding Modern Hangul --------------------------------------- Jenkins listed the alternative solutions to the problem of encoding all modern hangul. This list was compiled at Taligent, by Jenkins, Mark Davis, | Lee Collins, and David Goldsmith. No additional alternatives were proposed | at the UTC meeting, but Joe Becker suggested that the final category, "Do | nothing," should be was divided into two subsections (see below). The alternatives are designated "a" through "f". Alternative "f" (current status) has two options (designated "1" and "2"). Although this list was presented in the middle of the UTC's discussion of the issue, it is put here at the beginning because it is a key element. a) add the additional 4,516 hangul to the BMP b) Move all 11,172 hangul to another plane c) Put the additional 4,516 hangul into another plane | - This option would require use of UCS-4 or of UTF-16 (assuming | successful ballot) d) Copy all 11,172 hangul to another plane | - This option would require use of UCS-4 or of UTF-16 (assuming | successful ballot) e) Permanently shrink the user zone in the Unicode standard and put the additional 4,516 hangul into the former user space. f) Do nothing (i.e., maintain current status) 1) Use conjoining jamos 2) Encode the additional 4,516 hangul in the user zone =========================================================================== Presentation by T.J. Kang on Unicode in Korea --------------------------------------------- Kang outlined the events that have occurred since June 1992 meeting of ISO/JTC1/SC2/WG2 in Seoul, Korea. Revision of KSC 5601 was completed after the 1992 WG2 meeting, and published as KSC 5601-1992. This adds the 11,732 "Johab" precomposed syllables. Scope of the principal standards that include modern hangul: KSC 5601-1987 has 2,350 precomposed modern hangul KSC 5657 (a standard that no one implemented) has 1,800 modern and 2,000+ | old hangul KSC 5601-1992 introduced a new coding scheme for all 11,172 modern hangul ISO 10646 has 2,350 hangul (from KSC 5601) 1,800+ hangul (part of KSC 5657) 2,000+ old hangul of KSC 5657 were deleted and replaced by modern hangul The hangul from KSC 5657 were selected on the basis of frequency. The set of 2,000+ modern hangul which replaced the old hangul is in alphabetical order (not by frequency of occurrence). The remaining 4,516 hangul from KSC 5601 - 1992 take up three-quarters of the private use zone. Ministry of Commerce and Industry set up a committee to study the future character set needs of Korea. The Committee recommended (in its report published in November 1993) that Korean should go its own way, and not use the Unicode standard or ISO 10646. The modern part is finished; the | Committee is now studying old hangul. Korea's WG2 participants were initially excluded from the Committee's deliberations, but were included after the Committee's report was published. The general view was that the Korean delegates at the WG2 meeting in Korea had let the nation down by not getting full hangul set into ISO 10646. There is enough flux within Korea that ISO 10646/Unicode can possibly be set aside and ignored. Microsoft Windows is a major platform for most computer users in Korea. Currently, it supports only the earlier version of KSC 5601. Some Korean companies are doing their own modifications using the full 11,000 hangul (johab) of KSC 5601-1992. The dominant Korean word processing software (between 65-85% of the population) developed by Angin (spelling?) does its own character handling on DOS and supports all 11,172 johab and some | old characters. Now porting to Windows - not using Windows text API for text display. HanSoft is also writing a driver supporting all 11,172 johab hangul but with slightly different extensions to KSC5601-1992 (for old hangul and Chinese character support). Standards people in Korea are concerned about the proliferation of coding schemes. The Korean national character code committee is wondering about proposing the addition of a complete set of hangul to ISO again. The arguments for encoding hangul are: * economy of storage (one code, rather than a number of codes for conjoining jamos); and, * backwards compatibility (Microsoft is interested for this reason). Koreans have not seen an implementation of Unicode/ISO 10646. Microsoft is not sure whether it will have conjoining jamos in Windows NT. The Korean national character code committee is responsible for reviewing national standards as well as WG2 participation. There is a difference of opinion in the Committee on the development of national Korean character sets versus adoption of an international standard (i.e., a national version of ISO 10646). T.J. Kang requested support from the Consortium if the Korean national standards body proposes addition of the 4,000+ hangul characters to the BMP. The Korean national standards body does not want to propose this to WG2 without Unicode Consortium support. Becker: How stable is the 11,000 hangul set? A (Kang with Hong): It is not an open set. The hangul repertoire is also true for North Korea. | Q. Is old hangul a separate issue? A. Character coding is a passionate issue in Korea. There have been features in the newspapers and on TV. Scholars want old hangul, as well as Chinese (that is, hanja). The repertoire of 11,172 hangul meets only modern needs. The need for old hangul is a minority opinion on the character set committee. Because of the number and variety of old hangul, conjoining jamos may be used to encode them. Greenwood: A Korean colleague said that johab were in the KSC 5601-1992 standard as an appendix, and were designated as "for internal use only and not for interchange." A. This statement reflects a compromise. Government computers still use the earlier version of KSC 5601, and the government wanted to enforce its use for communication. Small scale LAN users, on the other hand, are using the new standard. Q. Use of private user space? A. An out for the Koreans. Later, companies and Korean delegates felt betrayed. Is the inclusion of the missing hangul in the BMP "too good to be true"? Ksar (in his ISO capacity as Convenor of WG2) pointed out that the Korean delegates to WG2 had not said anything about this in over three years, and have not asked for this to be put on the agenda of WG2. Kang: Koreans feel that they have nothing to lose by asking the UTC for support. Presentation by S.G. Hong ------------------------- The proposal is from Microsoft Corporation as a member company. Unless we include the KSC 5601 characters in precomposed form, Microsoft will not be competitive in Korea. Microsoft wants to comply with the Unicode standard, and also provide backwards compatibility. If a complete set of precomposed hangul are not included in the main code space, Microsoft would have to support the conjoining jamos method. This would mean that a printer driver (for example) would have to convert from conjoining jamos to KSC 5601 -1992 encoding. Jenkins: Why is using conjoining jamos a problem? To use 5601 a printer driver has to convert from Unicode to 5601 fonts. Conversion has to be made from either precomposed Unicode or conjoining jamos. Hong: This may be a Microsoft-specific problem. Honomichl: Are there things we are doing that we are not aware of and | might cause us problems? He added: If so, it would be good to know | about them (i.e., any problems arising from specific implementation | choices that Microsoft may have identified while working on Korean.) Hong: Microsoft needs to have 1:1 mappings from code page to Unicode in driver APIs for printers, screens, etc. Looking for a trivial 1:1 mapping, so can recompile to provide Unicode functionality. Jenkins: Means that this (1:1 mapping need) is true for all Microsoft Unicode implementations. The problem just surfaced in Korea. Double API structure of Windows requires Unicode to be basically the same as the "native" code page for any language. (That is, people would have to actually rewrite their printer drivers, etc. if they could no longer make casual assumptions about the structure of the code set. Becker: Two different pleas: Why can't the current status (additional hangul in private use area) get us somewhere? A. Does not satisfy the belief of Koreans that the whole set should be in there. Becker: But why isn't it (current status) ok for Microsoft? Hong: We want to comply with the standard and promote Unicode. Microsoft has been promoting the Unicode standard to ISVs. But the Product Development Group found problems: they say "cannot ship product." There is debate within Microsoft whether to use Unicode or to use DBCS for Korean. | Jenkins: Because Microsoft is using private user space for the | user zone of Shift-JIS, there is a conflict with needs for Korean. There | is insufficient room in the user zone for both Shift-JIS's user zone and the 4,516 hangul. (Option f2 conflicts with Microsoft implementation for Shift-JIS.) | [Clarification: In subsequent e-mail, Jenkins noted that (a) IBM, and | possibly other companies, are also mapping Shift-JIS's user zone into the | Unicode user zone, and (b) everything else in Shift-JIS (i.e., outside | of its user zone) is already in the Unicode standard.] Jenkins presented the alternatives (see above), and said that Taligent does | not consider alternatives b or e to be viable options. Kang: Alternative d corresponds to a recommendation in the study issued by the Korean character set committee. Hong: Microsoft would prefer Alternative e (because of conflict between Shift-JIS and hangul). This may be a viable option in Microsoft view. Greenwood: Alternative e means a break with ISO 10646. This point was discussed in detail. The private use zone is not part of the conformance clause of ISO 10646, so such a change would not cause the Unicode standard to be non-conformant (at least, legalistically). However, Alternative e would mean a non-compatible upgrade of the Unicode standard. Hong: Microsoft is looking for consensus on how to use user zone for hangul. Cannot agree on Shift-JIS use. The UTC saw several problems with Alternative e: * The Unicode user zone is made permanently smaller; * Breaks with ISO 10646; * Breaks with existing implementations. Problem of gaiji characters in Japanese applications. Ksar: Where do UTF-16 and USC-4 fit in this? Has Korea considered a Korean national variant of ISO 10646? Hong asked for advice on strategies for the implementation of hangul. Initial opinion of the UTC was that the best long-term strategies are: * Alternative f1 (conjoining jamos); or, | * Combined hangul on another plane (using UCS-4 or UTF-16). | With respect to combined hangul on another plane, there was general | agreement that Alternative b is untenable. Ksar pointed out that it | would require changing code point assignments of ISO 10646. When the eventual need to convert data from Alternative f2 (some hangul in the user zone) is taken into account, UTC opinion was that the better choices are: * Alternative c (4,516 combined hangul in another plane); or * Alternative d (all 11,000 hangul in another plane). These alternatives parallel current combined single byte/double byte systems, with which Korea has considerable experience. The alternatives are also consistent with UTF-16, which has been approved by the UTC. Alternative c was considered preferable to Alternative d, as it avoids duplicate encoding of the same hangul. McConnell said he is against putting hangul in extra planes, because they are encoding variants, not presentation variants. Does not like the prospect of multiple encodings (i.e., conjoining jamos and precomposed hangul). Jenkins: Prefers putting them on another plane to putting them in the BMP. The problem with Alternative f2 (additional hangul in user zone) is that users are not *required* to use particular encoding values. Because this is user space, companies could declare their own arrangement for encoding these characters. Greenwood argued against changing the principles of the Unicode standard just because of simplistic implementation choices. Bennett asked Hong: What happens when you receive data encoded with conjoining jamos? Hong: Are member companies willing to pursue Alternative a (additional hangul in the BMP proper)? The consensus of the UTC was that Microsoft needs to present a detailed cost/benefit analysis examination of all the alternatives, to explain why Microsoft prefers Alternative a. Jenkins pointed out that, in the short term, Microsoft can do Alternative f2, and would be compliant with the Unicode standard. The UTC needs solid reasons explaining why Alternatives c, d and f are not going to happen in Korea. Jenkins said that supporting Alternative a is telling us "you have to choose between Korea and Taiwan" (which has proposed a collection of additional ideographs). Alternative a would also mean rejection of the German proposal for additional characters. Gioia: This brings in an additional factor: What is happening at the ISO level? The Koreans will have to compete with everyone else for the unassigned code points of the BMP. Ksar: Koreans have not even made a proposal to ISO for addition of the 4,000+ hangul to the BMP. | Greenwood: If Korea wishes to pursue this request then the Korean national standards body should propose the addition of the hangul to WG2. It would be improper for the Unicode Consortium to make such a proposal. [No UTC member disagreed with this statement.] Hong: Will bring alternatives to Product Group, ask them to evaluate each, and say how hard it would be to do each. Ksar: It is important for Microsoft to continue to participate in the Unicode Technical Committee and WG2. Unicode, Inc. is a liaison to WG2, and so any resolutions of the UTC have to be presented to WG2 for a vote. There are real advantages for a company to be part of this process. Korea is not the only country that wants to add characters to the BMP. The issues are described in ISO document N884 (copies were distributed at the UTC meeting). Microsoft needs to provide more information to convince the UTC that one alternative is better than the others, and that this alternative is better for other member companies as well as for Microsoft. (But then you need to convince ISO.) There is no question that the UTC is firmly committed to keeping ISO 10646 and the Unicode standard synchronized. Those present at the meeting expressed vehement support for this. Action item (Greenwood, Aliprand, Greenfield, others?): Send copy of personal notes (draft Minutes in the case of Greenfield) to S.G. Hong and T.J. Kang. [DONE per this composite] Action item (S.G. Hong): Prepare a detailed cost/benefit analysis examination of all the alternatives. State which alternative is preferred by Microsoft (and why). Give reasons why this alternative may be better for other companies too. This analysis to be submitted to the UTC. Other Items: *** Action Item (Greenfield, Greenwood, Aliprand) *** The minutes for this meeting are to be provided by Friday morning. Let the Minutes show: With respect to Version 1.1, that the editorial comments be passed onto the Editor and he shall take them accordingly. *** Action Item (All members) *** Please review the Unicode Character Property Data Table at the ftp site, and send any corrections or feedback to Mark Davis by the end of October. This table is to be published on the CD-ROM. WWW Home Page: During the lunch break, Tim Greenwood demonstrated a preliminary draft of a Unicode Consortium home page for the World Wide Web. The text is extracted from various published documents. John Jenkins later remarked that Web browsers ought to be Unicode-enabled, and suggested to John Gioia that IBM might want to consider this. Joan Aliprand said that the Officers had already discussed this possibility, and that any proposals should be coordinated through them. *** Action Item (Aliprand) *** Let Officers know about Jenkins' suggestion. Meeting adjourned at 3:44 p.m. =END=