| TOC |
|
This document describes a new registry for Pronunciation Alphabets, such as pinyin, that can be used to describe pronunciations of words and phrases in a particular language.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 7, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
2.
Document Conventions
3.
Registry Format and Maintenance
3.1.
Format of the Pronunciation Alphabet Registry
3.2.
Pronunciation Alphabet Reviewer
3.3.
Maintenance of the Registry
3.4.
Stability of Pronunciation Alphabet Registry Entries
3.5.
Registration Procedure for Pronunciation Alphabet Tag
3.6.
Initialization of the Registries
3.6.1.
Initial registry requests
3.7.
Choice of Pronunciation Alphabet Tags
3.8.
Security Considerations
3.9.
IANA Considerations
3.9.1.
New registries
4.
References
4.1.
Normative References
4.2.
Informative References
Appendix A.
Contributors
Appendix B.
Acknowledgements
§
Authors' Addresses
| TOC |
The Pronunciation Alphabet Registry contains a list of Pronunciation Alphabet tags. This allows implementers a straightforward and reliable way to validate Pronunciation Alphabet tags. The Pronunciation Alphabet Registry will be maintained so that it is possible to validate all of the Pronunciation Alphabet tags under the provisions of this document or its revisions or successors. In addition, the meaning of the various Pronunciation Alphabet tags will be unambiguous and stable over time. (The meaning of private use Pronunciation Alphabet, of course, is not defined here.)
Pronunciation Alphabet tags can be used in the alphabet attribute of the phoneme element in the Speech Synthesis Markup Language (Shuang, Z. and D. Burnett, “Speech Synthesis Markup Language (SSML) Version 1.1,” August 2009.) [W3C.CR‑speech‑synthesis11‑20090827]. At some point in the future they may also be usable within the alphabet attribute of the phoneme and lexicon elements in the Pronunciation Lexicon Specification (Baggia, P., “Pronunciation Lexicon Specification (PLS) Version 1.0,” October 2008.) [W3C.REC‑pronunciation‑lexicon‑20081014].
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
| TOC |
The Pronunciation Alphabet Registry (PAR) consists of a text file including all registered Pronunciation Alphabet tags in the format defined in this section, plus copies of the registration forms approved in accordance with the process described in Section 3.5 (Registration Procedure for Pronunciation Alphabet Tag). The set of initial tags (see Section 3.9.1.1 (Pronunciation Alphabets)) will not have registration forms created for them.
The format of the registry is described by the following ABNF (per RFC5234 (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234]):
registry = file-date record-separator records
record-separator = "%%" CRLF
records = record *(record-separator record)
record = (alphabet-record / alias-record)
kv-separator = *SP ":" *SP
text = *(ASCCHAR/LWSP)
ASCCHAR = %x21-25 / %x27-7E / UNICHAR
UNICHAR = AMPERSAND "#x" 2*6HEXDIG ";"
AMPERSAND = %x26
date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
file-date = "File-Date" kv-separator date CRLF
alphabet-record = alphabet-type tag 1*description added reference
[deprecated] *comments
alias-record = alias-type tag *description added alias
[deprecated] *comments
alphabet-type = type kv-separator "alphabet" CRLF
alias-type = type kv-separator "alias" CRLF
type = "Type"
tag = "Tag" kv-separator tag-format CRLF
description = "Description" kv-separator text CRLF
added = "Added" kv-separator date CRLF
reference = "Reference" kv-separator text CRLF
alias = "Alias" kv-separator tag-format CRLF
deprecated = "Deprecated" kv-separator date CRLF
comments = "Comments" kv-separator text CRLF| Figure 1: Registry Format ABNF |
This format was based on the language tags format described in [RFC5646] (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.).
Each line of text is limited to 72 characters, including all whitespace. Records are separated by lines containing only the sequence "%%" (%x25.25).
Each field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body separated by a COLON character (%x3A). For convenience, a field-body allowing text can be split into a multiple-line representation; this is called "folding".
Characters from outside the US-ASCII ISO646 (International Organization for Standardization, “Information technology - ISO 7-bit coded character set for information interchange,” 1991.) [ISO.646.1991] repertoire, as well as the AMPERSAND character ("&", %x26) when it occurs in field body text, are represented by a "Numeric Character Reference" using hexadecimal notation in the style used by XML 1.0 (Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fifth Edition),” November 2008.) [W3C.REC‑xml‑20081126] (see <http://www.w3.org/TR/REC-xml/#dt-charref>). This consists of the sequence "&#x" (%x26.23.78) followed by a hexadecimal representation of the character's code point in ISO 10646 followed by a closing semicolon (%x3B). For example, the EURO SIGN, U+20AC, would be represented by the sequence "€". Note that the hexadecimal notation MAY have between two and six digits.
All fields whose field-body contains a date value use the "full-date" format specified in [RFC3339] (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.). For example: "2004-06-28" represents June 28, 2004, in the Gregorian calendar.
The first record in the file contains the single field whose field-name is "File-Date". The field-body of this record contains the last modification date of this copy of the registry, making it possible to compare different versions of the registry. The registry on the IANA (Internet Assigned Numbers Authority) website is the most current. Versions with an older date than that one are not up-to-date.
File-Date: 2004-06-28 %%
| Figure 2: Example of the File-Date Record |
Subsequent records represent tags in the registry. Each of the fields in each record MUST occur no more than once, unless otherwise noted below. Each record MUST contain the following fields unless otherwise noted:
- Type
- Type's field-value MUST consist of one of the strings "alphabet" or "alias", denoting the type of tag.
- Tag
- Tag's field-value contains a Pronunciation Alphabet tag.
- Description
- Description's field-value contains a non-normative description of the tag. This field MUST appear in records whose 'Type' is "alphabet" and MAY appear in records whose 'Type' is "alias".
- Reference to published description of the pronunciation alphabet
- This field-value contains normative information that identifies a reference defining the Pronunciation Alphabet associated with this tag, for example a national standard, an association's standard, a book, or an article. It is strongly RECOMMENDED that this reference be published, public, and stable. This field MUST appear in records whose 'Type' is "alphabet" and MUST NOT appear in records whose 'Type' is "alias".
- Alias
- Alias' field-value MUST be another registered Pronunciation Alphabet tag whose 'Type' is "alphabet". This field MUST appear in records whose 'Type' is "alias" and MUST NOT appear in records whose 'Type' is "alphabet".
- Added
- Added's field-value contains the date the record was added to the registry.
The 'Tag' field MUST use lowercase letters to form the tag.
The field 'Description' MAY appear more than one time and contains a description of the tag in the record. At least one of the 'Description' fields MUST be written or transcribed into the Latin script; the same or additional fields MAY also include a description in a non-Latin script.
Note: The purpose of the "Reference to published description of the pronunciation alphabet" in the record is intended as an aid to people trying to verify whether a pronunciation alphabet is registered. The contents of this field SHOULD reference a published standard; if no such standard exists, other well known works describing that pronunciation alphabet MAY be provided instead. The Pronunciation Alphabet Tag Reviewer decides what constitutes "good enough" reference material.
The field 'Alias' contains a mapping between the record in which it appears and another tag.
A tag which is defined as an alias must always remain an alias, although the value of the Alias field may change.
Each record MAY also contain the following fields:
- Deprecated
- Deprecated's field-value contains the date the record was deprecated.
- Comments
- Comments contains additional information about the tag, as deemed appropriate for understanding the registry and implementing the associated Pronunciation Alphabet tag.
The field 'Deprecated' MAY be added to any record via the maintenance process described in Section 3.3 (Maintenance of the Registry)or via the registration process described in Section 3.5 (Registration Procedure for Pronunciation Alphabet Tag). Usually, the addition of a 'Deprecated' field is due to the action on the mailing list. Although valid as Pronunciation Alphabet tags, tags with a 'Deprecated' field are deprecated and document authors SHOULD NOT use these tags.
The field 'Comments' MAY appear more than once per record. This field MAY be inserted or changed via the registration process and no guarantee of stability is provided. The content of this field is not restricted, except by the need to register the information, the suitability of the request, and by reasonable practical size limitations.
The values for fields 'Tag' and 'Alias' MUST use the following syntax:
tag-format = 2ALPHA *5(["."] 1*20(ALPHA / DIGIT))
| Figure 3: Tag and Alias ABNF |
File-Date: 2007-09-18 %% Type: alphabet Tag: pinyin2001 Description: Chinese Mandarin Pronunciation Alphabet Added: 2007-09-18 Reference to published description of the pronunciation alphabet: "Standard for the Scheme of Chinese Pronunciation Alphabet Input with Universal Keyboard" (China GF 3006-2001) published by Chinese government in 2001. A Chinese language version is available in the website of Education of the People's Republic of China at http://www.moe.gov.cn/edoas/website18/level3.jsp?tablename=1264&infoid=13149 Comments: Please refer to "Standard for the Scheme of Chinese Pronunciation Alphabet Input with Universal Keyboard" (China GF 3006-2001) published by Chinese government in 2001. This standard defines how to input tone sandis and some special vowels of Chinese Pronunciation Alphabet by Universal Keyboard. %% Type: alias Tag: pinyin Alias: pinyin2001 Added: 2007-09-18 %% Type: alphabet Tag: jyutping Description: Chinese Cantonese Pronunciation Alphabet Added: 2007-09-18 Reference to published description of the pronunciation alphabet: Please refer to "The LSHK Cantonese Romanization Scheme", published by "Linguistic Society of Hong Kong" in 1993. %% Type: alphabet Tag: jeita Description: Pronunciation Alphabet published by JEITA Added: 2007-09-18 Reference to published description of the pronunciation alphabet: Please refer to the "JEIDA-62-2000 Phoneme Alphabet", published by "Japan Electronics and Information Technology Industries Association" (JEITA) (http://www.jeita.or.jp). An abstract of this document (in Japanese) is available at: http://it.jeita.or.jp/document/publica/standard/summary/JEIDA-62-2000.pdf
| Figure 4: Examples of Pronunciation Alphabet Tag Entries |
| TOC |
The Pronunciation Alphabet Reviewer moderates the <ietf-par@iana.org> mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3 (Maintenance of the Registry). Except as described there, only the Pronunciation Alphabet Reviewer is permitted to request IANA to change, update, or add records to the Pronunciation Alphabet Registry. The Pronunciation Alphabet Reviewer MAY delegate list moderation and other clerical duties as needed.
The Pronunciation Alphabet Reviewer is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. The IESG will solicit nominees for the position (upon adoption of this document or upon a vacancy) and then solicit feedback on the nominees' qualifications. Qualified candidates should be familiar with this document and its requirements; be willing to fairly, responsively, and judiciously administer the registration process; and be suitably informed about the issues of pronunciation alphabets so that the reviewer can assess the claims and draw upon the contributions of experts in the use and definition of pronunciation alphabets and tag requesters.
The subsequent performance or decisions of the Pronunciation Alphabet Reviewer MAY be appealed to the IESG under the same rules as other IETF decisions (see RFC2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) [RFC2026]). The IESG can reverse or overturn the decisions of the Pronunciation Alphabet Reviewer, provide guidance, or take other appropriate actions.
| TOC |
The Pronunciation Alphabet Reviewer MUST evaluate each suggested change, determine whether it conflicts with existing registry entries, and submit the information to IANA for inclusion in the registry. If a suggestion is submitted and the Pronunciation Alphabet Reviewer does not do this in a timely manner, then any interested party MAY use the procedure in Section 3.5 (Registration Procedure for Pronunciation Alphabet Tag) to register the appropriate update.
The Pronunciation Alphabet Reviewer MUST ensure that new tags meet the requirements in Section 3.5 (Registration Procedure for Pronunciation Alphabet Tag). When either a change or addition to the registry is needed, the Pronunciation Alphabet Reviewer MUST prepare the complete record, including all fields, and forward it to IANA for insertion into the registry. Each record being modified or inserted MUST be forwarded in a separate message.
If a record represents a new tag that does not currently exist in the registry, then the message's subject line MUST include the word "INSERT". If the record represents a change to an existing tag, then the subject line of the message MUST include the word "MODIFY".
The message MUST contain both the record for the tag being inserted or modified and the new File-Date record. Here is an example of what the body of the message might contain:
From: par_reviewer@example.com To: <<IANA>> CC: <ietf-par@iana.org> Subject: PRONUNCIATION ALPHABET TAG INSERT File-Date: 2006-08-25 %% Type: alphabet Tag: abcdef Description: US English alphabet Added: 2006-08-25 Reference to published description of the pronunciation alphabet: Any young child's word book. Comments: This is a comment shown as an example. %%
| Figure 5: Example of a Pronunciation Alphabet Tag Insertion Form |
Whenever an entry is created or modified in the registry, the 'File-Date' record at the start of the registry is updated to reflect the most recent modification date in the [RFC3339] (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) "full-date" format. Before forwarding a new registration to IANA, the Pronunciation Alphabet Reviewer MUST ensure that values in the record are valid according to the description in Section 3.1 (Format of the Pronunciation Alphabet Registry).
| TOC |
The stability of entries and their meaning in the registry is critical to the long term stability of pronunciation alphabet tags. Once registered, a tag will not be removed from the registry and will remain a valid way in which to specify a specific pronunciation alphabet or variant. The rules in this section guarantee that a specific pronunciation alphabet tag's meaning is stable over time and will not change.
While corrections to mistakes in the registry MAY be undertaken from time to time, attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright.
Assignments to the Pronunciation Alphabet Registry MUST follow the following stability rules:
| TOC |
The procedure given here MUST be used by anyone who wants to use a tag not currently in the Pronunciation Alphabet Registry.
This procedure MAY also be used to register or alter the information in a tag's record as described in Section 3.4 (Stability of Pronunciation Alphabet Registry Entries).
Registering a new tag or requesting modifications to an existing tag starts with the requester submitting an email containing a filled out registration form (reproduced below) to the email address <ietf-par@iana.org> for a 90 day review period before it can be submitted to IANA. This is an open list and can be joined by sending a request to <ietf-par-request@iana.org>. Note that emails are not limited in size so that the request can adequately describe the registration.
PRONUNCIATION ALPHABET TAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested: <record as defined in Section 3.1> 4. Any other relevant information:
| Figure 6: Pronunciation Alphabet Tag Registration Form |
When the 90 day period has passed the Pronunciation Alphabet Reviewer either forwards the record to be inserted or modified to IANA, with a CC to <ietf-par@iana.org>, according to the procedure described in Section 3.3 (Maintenance of the Registry), or rejects the request because of significant objections raised on the list or due to problems with constraints in this document (which MUST be explicitly cited). The Pronunciation Alphabet Reviewer MAY also extend the review period in 90 day increments to permit further discussion. The Pronunciation Alphabet Reviewer MUST indicate on the list whether the registration has been accepted, rejected, or extended following each 90 day period.
Note that the Pronunciation Alphabet Reviewer MAY raise objections on the list if he or she so desires. The important thing is that the objection MUST be made publicly.
The applicant is free to modify a rejected application with additional information and submit it again; this restarts the 90 day comment period.
Individuals who disagree strongly with a decision SHOULD register with the Pronunciation Alphabet Reviewer any Formal Objections. When individuals believe that their concerns are not being duly considered by the group, they MAY ask the IESG to confirm or deny the decision. The Pronunciation Alphabet Reviewer MUST inform the IESG when a group participant has raised concerns about due process. Any requests to the IESG to confirm a decision MUST include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions MUST be recorded. It is RECOMMENDED that all such communications include a CC to <ietf-par@iana.org>. The IESG can reverse or overturn the decision of the Pronunciation Alphabet Reviewer, provide guidance, or take other appropriate actions.
Updates or changes to existing records follow the same procedure as new registrations. The Pronunciation Alphabet Reviewer decides whether there is consensus to update the registration following the 90 day review period; normally objections by the original registrant will carry extra weight in forming such a consensus.
| TOC |
Upon adoption of this document an initial version of the Pronunciation Alphabet Registry is necessary. The initial Pronunciation Alphabet Registry contains the initial set of valid tags. This collection of tags is described in Section 3.6.1 (Initial registry requests).
IANA SHALL publish the initial version of the registry described by this document from the content of Section 3.6.1 (Initial registry requests). Once published by IANA, the maintenance procedures, rules and registration processes described in this document will be available for new registrations or updates.
| TOC |
| TOC |
Request for pinyin2001 1. Name of requester: Zhiwei Shuang 2. E-mail address of requester: shuangzw@cn.ibm.com 3. Record Requested: Type : alphabet Tag: pinyin2001 Description: Chinese Mandarin Pronunciation Alphabet Reference to published description of the pronunciation alphabet: "Standard for the Scheme of Chinese Pronunciation Alphabet Input with Universal Keyboard" (China GF 3006-2001) published by Chinese government in 2001. A Chinese language version is available in the website of Education of the People's Republic of China at http://www.moe.gov.cn/edoas/website18/level3.jsp?tablename=1264&infoid=13149 Comments: Please refer to "Standard for the Scheme of Chinese Pronunciation Alphabet Input with Universal Keyboard" (China GF 3006-2001) published by Chinese government in 2001. This standard defines how to input tone sandis and some special vowels of Chinese Pronunciation Alphabet by Universal Keyboard. 4. Any other relevant information:
| TOC |
Request for pinyin 1. Name of requester: Zhiwei Shuang 2. E-mail address of requester: shuangzw@cn.ibm.com 3. Record Requested: Type : alias Tag: pinyin Alias: pinyin2001
| TOC |
One is sometimes faced with the choice between several possible pronunciation alphabets for the same tag. It is strongly RECOMMENDED that the most widely accepted and used pronunciation alphabet is chosen for the specific tag. Pronunciation alphabets that refer to published national or association standards are preferred.
Interoperability is best served when all users use the same pronunciation alphabet tag in order to represent the same pronunciation alphabet. If one pronunciation alphabet is registered with one tag, it MUST NOT be registered with other tags. The only exception to this is the use of Alias.
| TOC |
Although the specification of registry entries MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks.
An SSML application can fail if someone hijacks and changes an alias value to something a processor does not support (if the processor relies on checking the alias value mechanically).
An SSML application can fail if someone hijacks and changes an alias value to an earlier version of an alphabet which the processor supports but which may have different alphabet characters supported (if the processor relies on checking the alias value mechanically).
| TOC |
| TOC |
This section describes the name spaces (registries) for PAR that IANA is requested to create and maintain. Assignment/registration policies are described in RFC5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226].
| TOC |
IANA SHALL create a new name space of "Pronunciation Alphabets". All maintenance within and additions to the contents of this name space MUST be according to Section 3 (Registry Format and Maintenance). The initial contents of the registry, defined in Section 3.6.1 (Initial registry requests), are given below:
File-Date: ** PLEASE FILL IN ** %% Type : alphabet Tag: pinyin2001 Description: Chinese Mandarin Pronunciation Alphabet Reference to published description of the pronunciation alphabet: "Standard for the Scheme of Chinese Pronunciation Alphabet Input with Universal Keyboard" (China GF 3006-2001) published by Chinese government in 2001. A Chinese language version is available in the website of Education of the People's Republic of China at http://www.moe.gov.cn/edoas/website18/level3.jsp?tablename=1264&infoid=13149 Comments: Please refer to "Standard for the Scheme of Chinese Pronunciation Alphabet Input with Universal Keyboard" (China GF 3006-2001) published by Chinese government in 2001. This standard defines how to input tone sandis and some special vowels of Chinese Pronunciation Alphabet by Universal Keyboard. Added: ** PLEASE FILL IN ** %% Type: alias Tag: pinyin Alias: pinyin2001 Added: ** PLEASE FILL IN **
| TOC |
| TOC |
| [RFC2026] | Bradner, S., “The Internet Standards Process -- Revision 3,” BCP 9, RFC 2026, October 1996 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC5226] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT). |
| [RFC3339] | Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML). |
| [RFC5234] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT). |
| [ISO.646.1991] | International Organization for Standardization, “Information technology - ISO 7-bit coded character set for information interchange,” ISO Standard 646, 1991. |
| [W3C.REC-pronunciation-lexicon-20081014] | Baggia, P., “Pronunciation Lexicon Specification (PLS) Version 1.0,” World Wide Web Consortium Recommendation REC-pronunciation-lexicon-20081014, October 2008 (HTML). |
| [W3C.REC-xml-20081126] | Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fifth Edition),” World Wide Web Consortium Recommendation REC-xml-20081126, November 2008 (HTML). |
| [W3C.CR-speech-synthesis11-20090827] | Shuang, Z. and D. Burnett, “Speech Synthesis Markup Language (SSML) Version 1.1,” World Wide Web Consortium CR CR-speech-synthesis11-20090827, August 2009 (HTML). |
| TOC |
| [RFC5646] | Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT). |
| TOC |
Paul Bagshaw (France Telecom) Paolo Baggia (Loquendo)
| TOC |
Many thanks to the following additional members of the W3C Voice Browser Working Group.
Yan Jun (iFLYTEK) Lou Xiaoyan (Toshiba) Dezhi Huang (France Telecom) Kazuyuki Ashimura (W3C)
The chairs of the W3C Voice Browser Working Group are Jim Larson (Independent Consultant) and Scott McGlashan (HP).
| TOC |
| Daniel C. Burnett | |
| Voxeo | |
| 189 South Orange Avenue #2050 | |
| Orlando, FL 32801 | |
| USA | |
| Email: | dburnett@voxeo.com |
| ZhiWei Shuang | |
| IBM | |
| 8 Dongbeiwang WestRoad | |
| Haidian District, Beijing 100094 | |
| PRC | |
| Email: | shuangzw@cn.ibm.com |