W3C D. Burnett Internet-Draft Voxeo Intended status: Informational Z. Shuang Expires: June 7, 2010 IBM December 4, 2009 Pronunciation Alphabet Registry draft-burnett-pronunciation-alphabet-registry-00 Abstract 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. Status of this Memo 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 Notice 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 Burnett & Shuang Expires June 7, 2010 [Page 1] Internet-Draft PAR December 2009 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 3. Registry Format and Maintenance . . . . . . . . . . . . . . . 3 3.1. Format of the Pronunciation Alphabet Registry . . . . . . 3 3.2. Pronunciation Alphabet Reviewer . . . . . . . . . . . . . 9 3.3. Maintenance of the Registry . . . . . . . . . . . . . . . 9 3.4. Stability of Pronunciation Alphabet Registry Entries . . . 10 3.5. Registration Procedure for Pronunciation Alphabet Tag . . 11 3.6. Initialization of the Registries . . . . . . . . . . . . . 12 3.6.1. Initial registry requests . . . . . . . . . . . . . . 12 3.7. Choice of Pronunciation Alphabet Tags . . . . . . . . . . 13 3.8. Security Considerations . . . . . . . . . . . . . . . . . 13 3.9. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 3.9.1. New registries . . . . . . . . . . . . . . . . . . . . 14 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Normative References . . . . . . . . . . . . . . . . . . . 15 4.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Burnett & Shuang Expires June 7, 2010 [Page 2] Internet-Draft PAR December 2009 1. Introduction 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 [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 [W3C.REC-pronunciation-lexicon-20081014]. 2. Document Conventions 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 [RFC2119]. 3. Registry Format and Maintenance 3.1. Format of the Pronunciation Alphabet Registry 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. The set of initial tags (see Section 3.9.1.1) will not have registration forms created for them. The format of the registry is described by the following ABNF (per RFC5234 [RFC5234]): registry = file-date record-separator records record-separator = "%%" CRLF records = record *(record-separator record) record = (alphabet-record / alias-record) Burnett & Shuang Expires June 7, 2010 [Page 3] Internet-Draft PAR December 2009 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]. Each line of text is limited to 72 characters, including all whitespace. Records are separated by lines containing only the Burnett & Shuang Expires June 7, 2010 [Page 4] Internet-Draft PAR December 2009 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 [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 [W3C.REC-xml-20081126] (see ). 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]. 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. Burnett & Shuang Expires June 7, 2010 [Page 5] Internet-Draft PAR December 2009 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. Burnett & Shuang Expires June 7, 2010 [Page 6] Internet-Draft PAR December 2009 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.3or via the registration process described in Section 3.5. 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 Burnett & Shuang Expires June 7, 2010 [Page 7] Internet-Draft PAR December 2009 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 Burnett & Shuang Expires June 7, 2010 [Page 8] Internet-Draft PAR December 2009 3.2. Pronunciation Alphabet Reviewer The Pronunciation Alphabet Reviewer moderates the mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3. 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 [RFC2026]). The IESG can reverse or overturn the decisions of the Pronunciation Alphabet Reviewer, provide guidance, or take other appropriate actions. 3.3. Maintenance of the Registry 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 to register the appropriate update. The Pronunciation Alphabet Reviewer MUST ensure that new tags meet the requirements in Section 3.5. 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 Burnett & Shuang Expires June 7, 2010 [Page 9] Internet-Draft PAR December 2009 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: <> CC: 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] "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. 3.4. Stability of Pronunciation Alphabet Registry Entries 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: Burnett & Shuang Expires June 7, 2010 [Page 10] Internet-Draft PAR December 2009 1. Values in the fields 'Type', 'Tag', 'Added', and 'Deprecated' MUST NOT be changed and are guaranteed to be stable over time. 2. Values in the 'Description' and 'Reference to published description of the pronunciation alphabet' fields MUST NOT be changed in a way that would invalidate previously-existing tags. They MAY be broadened somewhat in scope, changed to add information, or adapted to the most common modern usage. 3. The field 'Comments' MAY be added, changed, modified, or removed via the registration process or any of the processes or considerations described in this section. 4. The field 'Alias' MAY be modified via the registration process or any of the processes or considerations described in this section. 3.5. Registration Procedure for Pronunciation Alphabet Tag 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. 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 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 . 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: 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 , according to the procedure described in Section 3.3, 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. Burnett & Shuang Expires June 7, 2010 [Page 11] Internet-Draft PAR December 2009 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 . 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. 3.6. Initialization of the Registries 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. IANA SHALL publish the initial version of the registry described by this document from the content of Section 3.6.1. Once published by IANA, the maintenance procedures, rules and registration processes described in this document will be available for new registrations or updates. 3.6.1. Initial registry requests 3.6.1.1. pinyin2001 Burnett & Shuang Expires June 7, 2010 [Page 12] Internet-Draft PAR December 2009 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: 3.6.1.2. pinyin 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 3.7. Choice of Pronunciation Alphabet Tags 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. 3.8. Security Considerations Although the specification of registry entries MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it Burnett & Shuang Expires June 7, 2010 [Page 13] Internet-Draft PAR December 2009 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). 3.9. IANA Considerations 3.9.1. New registries This section describes the name spaces (registries) for PAR that IANA is requested to create and maintain. Assignment/registration policies are described in RFC5226 [RFC5226]. 3.9.1.1. Pronunciation Alphabets 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. The initial contents of the registry, defined in Section 3.6.1, 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 ** Burnett & Shuang Expires June 7, 2010 [Page 14] Internet-Draft PAR December 2009 4. References 4.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [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, . [W3C.REC-xml-20081126] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, . [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, . Burnett & Shuang Expires June 7, 2010 [Page 15] Internet-Draft PAR December 2009 4.2. Informative References [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. Appendix A. Contributors Paul Bagshaw (France Telecom) Paolo Baggia (Loquendo) Appendix B. Acknowledgements 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). Authors' Addresses 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 Burnett & Shuang Expires June 7, 2010 [Page 16]