From speechsc-bounces@ietf.org Mon Apr 4 11:38:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19357 for ; Mon, 4 Apr 2005 11:38:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITmL-0003BR-OH for speechsc-web-archive@ietf.org; Mon, 04 Apr 2005 11:46:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITYf-0006z5-UI; Mon, 04 Apr 2005 11:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITYZ-0006yd-5E for speechsc@megatron.ietf.org; Mon, 04 Apr 2005 11:32:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18691 for ; Mon, 4 Apr 2005 11:32:01 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITgW-0002lq-4z for speechsc@ietf.org; Mon, 04 Apr 2005 11:40:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2005 08:31:53 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34FVnDr026308 for ; Mon, 4 Apr 2005 08:31:50 -0700 (PDT) Received: from [10.32.245.158] (stealth-10-32-245-158.cisco.com [10.32.245.158]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j34FN22P023786 for ; Mon, 4 Apr 2005 08:23:15 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <447d707f58bc7a3739352d84913e433a@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SPEECHSC (E-mail) From: David R Oran Date: Mon, 4 Apr 2005 11:30:51 -0400 X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1112628229.811288"; x:"432200"; a:"rsa-sha1"; b:"nofws:15524"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"IkDBOsIM4vCkYvKbhZvrHSVuZq+Zf5mT12rmKjXDnaLXGICFCMciUfFJKBi3mrcxO4Po8tw0" "mcYU/c5SyHLYsgumV8MGAeIXtdG/OsxBqySQzdNEujQUy8629hncq9PHnLPpA/UfNcDUjE/MZSx" "6Tikvh+2lauwAFGXulU3hn9g="; c:"From: David R Oran "; c:"Subject: Fwd: =22Scott Hollenbeck=22: FW: please review draft-froume" "ntin-voice-mediatypes-00"; c:"Date: Mon, 4 Apr 2005 11:30:51 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.8 (/) X-Scan-Signature: 93a9b7eb0f4b3b8a49c341eb77478ab2 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Fwd: "Scott Hollenbeck": FW: please review draft-froumentin-voice-mediatypes-00 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4ad60914b71abd47c285b3604f8c8304 Content-Transfer-Encoding: 7bit We need to check these against MRCPv2. Begin forwarded message: > From: Allison Mankin > Date: April 4, 2005 10:33:42 AM EDT > To: csp@csperkins.org, magnus.westerlund@ericsson.com, oran@cisco.com, > eburger@brooktrout.com > Cc: sah@428cobrajet.net, jon.peterson@neustar.biz > Subject: "Scott Hollenbeck": FW: please review > draft-froumentin-voice-mediatypes-00 > Reply-To: mankin@psg.com > Iim-Verify: s:"n"; v:"n"; r:"0"; h:"imail.cisco.com"; > > Colin, Magnus, Dave, Eric, > > Please draw these mediatypes to the attention of your > working groups. SPEECHSC must be racking some of these > anyway, but do review. > > Allison > > (Thanks, Scott) > > ------- Forwarded Message > > From: "Scott Hollenbeck" > To: "'Allison Mankin'" > Subject: FW: please review draft-froumentin-voice-mediatypes-00 > Date: Mon, 4 Apr 2005 08:12:07 -0400 > Allison, > > This might be of interest to people in the AVT working group. > > - -Scott- > > - -----Original Message----- > From: Max Froumentin [mailto:mf@w3.org]=20 > Sent: Monday, April 04, 2005 8:03 AM > To: ietf-types@iana.org > Cc: w3t-archive@w3.org; ietf-xml-mime@imc.org > Subject: please review draft-froumentin-voice-mediatypes-00 > > > draft-froumentin-voice-mediatypes-00 contains the registration of > the 6 media types of the W3C Speech Interface Framework > (including the following specifications: SSML, SRGS, CCXML, PLS and > VoiceXML) > > Draft available at > http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes > -00.= > txt > and copied below. > > Max Froumentin, W3C > > Network Working Group M. > Froumentin > Internet-Draft > W3C > Expires: September 2, 2005 March > 2005 > > > The W3C Speech Interface Framework Media Types: > application/voicexml+xml, application/ssml+xml, application/srgs, > application/srgs+xml, application/ccxml+xml and application/pls+xml > draft-froumentin-voice-mediatypes-00 > > Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. > > 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 September 2, 2005. > > Copyright Notice > > Copyright (C) The Internet Society (2005). > > Abstract > > This document defines the media type for the languages of the W3C > Speech Interface Framework: VoiceXML, SSML, SRGS, CCXML and PLS. > > > > > > > Froumentin Expires September 2, 2005 [Page > 1] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . > 3 > 2. Registration of application/voicexml+xml, > application/ssml+xml, application/srgs+xml, > application/ccxml+xml and application/pls+xml . . . . . . . . > 4 > 2.1 Encoding considerations . . . . . . . . . . . . . . . . . > 4 > 2.2 Interoperability considerations . . . . . . . . . . . . . > 4 > 2.3 Published specifications . . . . . . . . . . . . . . . . . > 4 > 2.4 Applications which use these media types . . . . . . . . . > 4 > 2.5 Security Considerations . . . . . . . . . . . . . . . . . > 4 > 2.6 Additional Information . . . . . . . . . . . . . . . . . . > 5 > 2.6.1 Magic numbers . . . . . . . . . . . . . . . . . . . . > 5 > 2.6.2 File extensions . . . . . . . . . . . . . . . . . . . > 5 > 2.6.3 Fragment identifiers . . . . . . . . . . . . . . . . . > 5 > 2.6.4 Macintosh File Type Code . . . . . . . . . . . . . . . > 5 > 2.6.5 Person & email address to contact for further > information . . . . . . . . . . . . . . . . . . . . . > 5 > 2.6.6 Intended usage . . . . . . . . . . . . . . . . . . . . > 5 > 2.6.7 Change Controller . . . . . . . . . . . . . . . . . . > 5 > 3. Registration of application/srgs . . . . . . . . . . . . . . . > 7 > 3.1 Encoding considerations . . . . . . . . . . . . . . . . . > 7 > 3.2 Interoperability considerations . . . . . . . . . . . . . > 7 > 3.3 Published specifications . . . . . . . . . . . . . . . . . > 7 > 3.4 Applications which use this media types . . . . . . . . . > 7 > 3.5 Security Considerations . . . . . . . . . . . . . . . . . > 7 > 3.6 Additional Information . . . . . . . . . . . . . . . . . . > 7 > 3.6.1 Magic numbers . . . . . . . . . . . . . . . . . . . . > 7 > 3.6.2 File extensions . . . . . . . . . . . . . . . . . . . > 8 > 3.6.3 Macintosh File Type Code . . . . . . . . . . . . . . . > 8 > 3.6.4 Person & email address to contact for further > information . . . . . . . . . . . . . . . . . . . . . > 8 > 3.6.5 Intended usage . . . . . . . . . . . . . . . . . . . . > 8 > 3.6.6 Change Controller . . . . . . . . . . . . . . . . . . > 8 > 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . > 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . > 9 > Intellectual Property and Copyright Statements . . . . . . . . > 10 > > > > > > > > > > > > > > > Froumentin Expires September 2, 2005 [Page > 2] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > 1. Introduction > > This specification defines the media types of the VoiceXML, SSML, > SRGS, CCXML and PLS, the specifications of the W3C Speech Interface > Platform > > VoiceXML is an XML language designed for creating audio dialogs that > feature synthesized speech, digitized audio, recognition of spoken > and DTMF key input, recording of spoken input, telephony, and mixed > initiative conversations. The associated media type defined in this > document is "application/voicexml+xml". > > The Speech Synthesis Markup Language Specification (SSML) defines an > XML-based markup language for assisting the generation of synthetic > speech in Web and other applications. The essential role of SSML is > to provide authors of synthesizable content a standard way to > control > aspects of speech such as pronunciation, volume, pitch, rate, etc. > across different synthesis-capable platforms. The asociated media > type defined in this document is "application/ssml+xml". > > The Speech Recognition Grammar Specification (SRGS) defines syntax > for representing grammars for use in speech recognition so that > developers can specify the words and patterns of words to be > listened > for by a speech recognizer. The syntax of the grammar format exists > in two forms, an Augmented BNF Form and an XML Form. The respective > media types defined in this document are "application/srgs" and > "application/srgs+xml". > > The Call Control eXtensible Markup Language (CCXML) is an XML > language designed to provide telephony call control support for > dialog systems, such as VoiceXML. The associated media type defined > in this document is "application/ccxml+xml". > > The Pronunciation Lexicon Specification (PLS) defines an XML syntax > for specifying pronunciation lexicons to be used by speech > recognition and speech synthesis engines in voice browser > applications. The associated media type defined in this document is > "application/pls+xml". > > > > > > > > > > > > > > Froumentin Expires September 2, 2005 [Page > 3] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > 2. Registration of application/voicexml+xml, application/ssml+xml, > application/srgs+xml, application/ccxml+xml and application/pls+xml > > MIME media type name: application > MIME subtype names: voicexml+xml, ssml+xml, srgs+xml, ccxml+xml, > pls+xml > Required parameters: none > Optional parameters: > "charset": This parameter has identical semantics to the > charset parameter of the "application/xml" media type as > specified in RFC 3023 [RFC3023]. > > 2.1 Encoding considerations > > Identical to those of "application/xml" as described in RFC 3023 > [RFC3023], section 3.2 > > 2.2 Interoperability considerations > > There are no known interoperability issues. > > 2.3 Published specifications > > Voice Extensible Markup Language 2.0 [VoiceXML2.0] > Voice Extensible Markup Language 2.1 [VoiceXML2.1] > Speech Synthesis Markup Language (SSML) Version 1.0 [SSML] > Speech Recognition Grammar Specification Version 1.0 [SRGS] > Voice Browser Call Control: CCXML Version 1.0 [CCXML] > Pronunciation Lexicon Specification (PLS) Version 1.0 [PLS] > > 2.4 Applications which use these media types > > Various W3C Speech Interface Platform implementations use these > media > types > > 2.5 Security Considerations > > Several instructions in the cited specifications may cause arbitrary > URIs to be dereferenced. In this case, the security issues of > [RFC2396], section 7, should be considered. > > In addition, because of the extensibility features of those > specifications, it is possible that the registered media types may > describe content that has security implications beyond those > described here. However, if the processor follows only the > normative > semantics of the specifications, this content will be ignored. Only > in the case where the processor recognizes and processes the > additional content, or where further processing of that content is > > > > Froumentin Expires September 2, 2005 [Page > 4] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > dispatched to other processors, would security issues potentially > arise. And in that case, they would fall outside the domain of this > registration document. > > 2.6 Additional Information > > 2.6.1 Magic numbers > > Although no byte sequences can be counted on to always be present, > XML MIME entities in ASCII-compatible charsets (including UTF-8) > often begin with hexadecimal 3C 3F 78 6D 6C (" UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D 00 > 6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00 (the Byte Order Mark (BOM) > followed by " [XML]. > > 2.6.2 File extensions > > VoiceXML files: .vxml > > SSML files: .ssml > > SRGS files (XML syntax): .grxml > > CCXML files: .ccxml > > PLS files: .pls > > 2.6.3 Fragment identifiers > > Identical to that of "application/xml" as described in RFC 3023 > [RFC3023], section 5. > > 2.6.4 Macintosh File Type Code > > "TEXT" > > 2.6.5 Person & email address to contact for further information > > World Wide Web Consortium > > 2.6.6 Intended usage > > COMMON > > 2.6.7 Change Controller > > The Speech Interface Framework specifications set is a work product > of the World Wide Web Consortium's Voice Browser Working Group. The > > > > Froumentin Expires September 2, 2005 [Page > 5] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > W3C has change control over these specifications. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Froumentin Expires September 2, 2005 [Page > 6] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > 3. Registration of application/srgs > > MIME media type name: application > MIME subtype names: srgs > Required parameters: none > Optional parameters: none > > 3.1 Encoding considerations > > The ABNF Form of SRGS follows the character encoding handling > defined > for XML: an ABNF grammar processor must accept both the UTF-8 and > UTF-16 encodings of ISO/IEC 10646 and may support other character > encodings. > > 3.2 Interoperability considerations > > There are no known interoperability issues. > > 3.3 Published specifications > > Speech Recognition Grammar Specification Version 1.0 [SRGS] > > 3.4 Applications which use this media types > > Various SRGS implementations use this media type. > > 3.5 Security Considerations > > Several instructions in SRGS may cause arbitrary URIs to be > dereferenced. In this case, the security issues of [RFC2396], > section 7, should be considered. > > In addition, because of the extensibility features of SRGS, it is > possible that the registered media types may describe content that > has security implications beyond those described here. However, if > the processor follows only the normative semantics of the > specifications, this content will be ignored. Only in the case > where > the processor recognizes and processes the additional content, or > where further processing of that content is dispatched to other > processors, would security issues potentially arise. And in that > case, they would fall outside the domain of this registration > document. > > 3.6 Additional Information > > 3.6.1 Magic numbers > > The ABNF self-identifying header must be present in any legal > > > > Froumentin Expires September 2, 2005 [Page > 7] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > stand-alone ABNF Form grammar document. The first character of an > ABNF document must be the "#" symbol (x23) unless preceded by an > optional XML 1.0 byte order mark [XML =FA4.3.3]. The ABNF byte > order > mark follows the XML definition and requirements. For example, > documents encoded in UTF-16 must begin with the byte order mark. > The > optional byte order mark and required "#" symbol must be followed > immediately by the exact string "ABNF" (x41 x42 x4d x46) or the > appropriate equivalent for the document's encoding (e.g. for UTF-16 > little-endian: x23 x00 x41 x00 x42 x00 x4d x00 x46 x00). If the > byte > order mark is absent on a grammar encoded in UTF-16 then the grammar > processor should perform auto-detection of character encoding in a > manner analogous to auto-detection of character encoding in XML [XML > =FAF]. Next follows a single space character (x20) and the required > version number which is "1.0" for this specification (x31 x2e x30). > > 3.6.2 File extensions > > .gram > > 3.6.3 Macintosh File Type Code > > "TEXT" > > 3.6.4 Person & email address to contact for further information > > World Wide Web Consortium > > 3.6.5 Intended usage > > COMMON > > 3.6.6 Change Controller > > The SRGS specification is a work product of the World Wide Web > Consortium's Voice Browser Working Group. The W3C has change > control > over the SRGS specification. > > 4. References > > [CCXML] Auburn, RJ., Ed., "Voice Browser Call Control: CCXML > Version 1.0, W3C Working Draft", January 2005, > . > > [PLS] Baggia, P., Ed., "Pronunciation Lexicon Specification > (PLS) Version 1.0, W3C Working Draft", February 2005, > > 14/>. > > > > > Froumentin Expires September 2, 2005 [Page > 8] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform > Resource Identifiers (URI): Generic Syntax. IETF RFC > 2396", August 1998, > . > > [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media > Types", > January 2001, . > > [SRGS] Hunt, A., Ed. and S. McGlashan, Ed., "Speech Recognition > Grammar Specification Version 1.0, W3C Recommendation", > March 2004, > . > > [SSML] Burnett, D., Ed., Walker, M., Ed. and A. Hunt, Ed., > "Speech Synthesis Markup Language (SSML) Version 1.0, W3C > Recomendation", September 2004, > > > . > > [VoiceXML2.0] > McGlashan, S., Ed., "Voice Extensible Markup Language > (VoiceXML) Version 2.0, W3C Recommendation", March 2004, > . > > [VoiceXML2.1] > Oshry, M., Ed., "Voice Extensible Markup Language > (VoiceXML) Version 2.1, W3C Working Draft", July 2004, > . > > > Author's Address > > Max Froumentin > World Wide Web Consortium > > > > > > > > > > > > > > > > > > > Froumentin Expires September 2, 2005 [Page > 9] > > Internet-Draft W3C Speech Interface Framework Media Types March > 2005 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Disclaimer of Validity > > This document and the information contained herein are provided on > an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Copyright Statement > > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > Froumentin Expires September 2, 2005 [Page > 10] > > > > > > > > ------- End of Forwarded Message > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Apr 13 21:55:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28597 for ; Wed, 13 Apr 2005 21:55:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtk5-0003Hw-AI for speechsc-web-archive@ietf.org; Wed, 13 Apr 2005 22:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtZi-0006M1-Cu; Wed, 13 Apr 2005 21:55:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtZh-0006LU-Mm for speechsc@megatron.ietf.org; Wed, 13 Apr 2005 21:55:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28539 for ; Wed, 13 Apr 2005 21:55:11 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtjR-0003HO-Fj for speechsc@ietf.org; Wed, 13 Apr 2005 22:05:27 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j3E1qAUh014429 for ; Wed, 13 Apr 2005 21:52:10 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Apr 2005 21:47:54 -0400 Message-ID: From: Eric Burger To: "IETF SPEECHSC (E-mail)" Date: Wed, 13 Apr 2005 21:47:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Speechsc] FW: MRCP and the VoiceXML Forum X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb The chairs think this information may be of interest to the list membership. While it isn't about the protocol, we think that gaining commercial acceptance of MRCPv2 will make all of our work worthwhile and not just an academic exercise. Please follow-up directly with Jeff with your or your company's interest. -----Original Message----- From: Jeff Kusnitz [mailto:jk@us.ibm.com] Sent: Wednesday, April 13, 2005 4:46 PM To: Eric Burger Subject: MRCP and the VoiceXML Forum Eric, As you know, the VoiceXML Forum has been a strong proponent of VoiceXML and the related W3C Speech Interface Framework specifications effectively since their inception. The Forum has been actively promoting these standards, developing tutorials for them, even offering developer and platform certification tests. It struck me one day that perhaps the Forum should also take on a similar role for MRCP - promoting it, etc. I discussed the idea with a few other people, some in SPEECHSC, some in the Forum, and all thought it would be a great idea. Based on the initial positive feedback, I brought the idea to the VoiceXML Forum itself, and they were also very receptive. I'd like to gauge the level of interest in the SPEECHSC group. Are members agreeable to the VoiceXML Forum promoting MRCP? And, if so, what sorts of things would members like to see the Forum get involved with, marketing, education, conformance? Other ideas? Also, would members of SPEECHSC like to participate in the Forum activities? Thanks, Jeff Kusnitz _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Apr 25 17:22:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQB1o-0000k3-5y; Mon, 25 Apr 2005 17:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQB1m-0000jq-Mz for speechsc@megatron.ietf.org; Mon, 25 Apr 2005 17:22:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00972 for ; Mon, 25 Apr 2005 17:21:57 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQBE2-0003cF-QA for speechsc@ietf.org; Mon, 25 Apr 2005 17:34:44 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3PLLjAa683912 for ; Mon, 25 Apr 2005 17:21:45 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3PLLi4F241066 for ; Mon, 25 Apr 2005 15:21:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3PLLivM001914 for ; Mon, 25 Apr 2005 15:21:44 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3PLLisd001907 for ; Mon, 25 Apr 2005 15:21:44 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Mon, 25 Apr 2005 17:21:41 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/25/2005 15:21:43, Serialize complete at 04/25/2005 15:21:43 X-Spam-Score: 1.4 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Speechsc] MRCPv2 Recognition Timeout clarification request X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0662772471==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multipart message in MIME format. --===============0662772471== Content-Type: multipart/alternative; boundary="=_alternative 0075583885256FEE_=" This is a multipart message in MIME format. --=_alternative 0075583885256FEE_= Content-Type: text/plain; charset="US-ASCII" Hi, It's not entirely clear as to what RECOGNIZER scenario would generate a RECOGNITION-COMPLETE event with a Completion-Cause: 003 recognition-timeout. The "Recognition Timeout" section of the current MRCPv2 spec indicates that a 008 should be sent if a START-OF-SPEECH event was generated by the RECOGNIZE request. p59 of the draft-ietf-speechsc-mrcpv2-06.txt Recognition Timeout When recognition is started and there is no match for a certain period of time, the recognizer can send a RECOGNITION-COMPLETE event to the client and terminate the recognition operation. It is the timer that is started when START-OF-SPEECH event is generated by the resource and specifies the maximum duration of the utterance. When this timer expires the recognition request would complete with a status code of "008 too-much-speech-timeout". The recognition- timeout header field sets this timeout value. The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value is 10 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS. What RECOGNIZER scenario should generate a Completion-Cause: 003 recognition-timeout? Thanks, Brett Gavagni IBM Voice Systems gavagni@us.ibm.com --=_alternative 0075583885256FEE_= Content-Type: text/html; charset="US-ASCII"
Hi,

It's not entirely clear as to what RECOGNIZER scenario would generate a RECOGNITION-COMPLETE event with a Completion-Cause: 003  recognition-timeout.

The "Recognition Timeout" section of the current MRCPv2 spec indicates that a 008 should be sent if a START-OF-SPEECH event was generated by the RECOGNIZE request.

p59 of the draft-ietf-speechsc-mrcpv2-06.txt
Recognition Timeout
   
   When recognition is started and there is no match for a certain
   period of time, the recognizer can send a RECOGNITION-COMPLETE event
   to the client and terminate the recognition operation. It is the
   timer that is started when START-OF-SPEECH event is generated by the
   resource and specifies the maximum duration of the utterance. When
   this timer expires the recognition request would complete with a
   status code of "008 too-much-speech-timeout". The recognition-
   timeout header field sets this timeout value. The value is in
   milliseconds. The value for this field ranges from 0 to MAXTIMEOUT,
   where MAXTIMEOUT is platform specific. The default value is 10
   seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS or
   GET-PARAMS.  

What RECOGNIZER scenario should generate a Completion-Cause: 003  recognition-timeout?

Thanks,

Brett Gavagni    
IBM Voice Systems  
gavagni@us.ibm.com --=_alternative 0075583885256FEE_=-- --===============0662772471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0662772471==-- From speechsc-bounces@ietf.org Wed Apr 27 09:30:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQmcR-0007Q1-De; Wed, 27 Apr 2005 09:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQmcO-0007Pt-PY for speechsc@megatron.ietf.org; Wed, 27 Apr 2005 09:30:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10730 for ; Wed, 27 Apr 2005 09:30:19 -0400 (EDT) Received: from mx2.scansoft.com ([198.71.64.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQmp0-0003QS-Ts for speechsc@ietf.org; Wed, 27 Apr 2005 09:43:26 -0400 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx2.scansoft.com with InterScan Messaging Security Suite; Wed, 27 Apr 2005 09:33:18 -0400 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Apr 2005 09:28:50 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Brett Gavagni'" , "'sarvi@cisco.com'" Subject: FW: [Speechsc] Recognition Timeout Date: Wed, 27 Apr 2005 09:28:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi Brett, below you find the discussion we had on this topic last April. It seems this did not make it into the spec. Thanks for pointing to this inconsistency. I suggest to mark 003 as deprecated, but leave it in the spec for backwards-compatibility with MRCPv1. Regards, Klaus -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Mittwoch, 28. April 2004 14:32 To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout OK, agreed! This would leave the choice to the recognition engine. The second option would be used if there are worthwhile results to return. Practically speaking, we have not seen this as a common case. Pierre -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of Reifenrath, Klaus Sent: 28 avril, 2004 04:46 To: Pierre Forgues Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout Hi Pierre! Why should the available result be discarded right away? This would only elongate the call. MRCP should allow two ways of handling this situation: 1) immediately return with a 008 "too-much-speech" 2) return 00x "success-maxtime" plus a recognition result In 2) the recognizer treats the situation, when the maximum length of speech has been reached, as if it had detected end-of-speech. Klaus -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Dienstag, 27. April 2004 20:49 To: Reifenrath, Klaus; speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout We return immediately with a 008 "too-much-speech-timeout". How about just clarifying the documentation to reflect this? Pierre -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] Sent: 27 avril, 2004 04:13 To: speechsc@ietf.org Cc: Pierre Forgues Subject: RE: [Speechsc] Recognition Timeout Hi group! In case the callers utterance exceeds the maximum duration (given by the recognition-timeout) and the recognizer has a complete match, but the caller did not stop speaking (speech-complete-timeout did not elapse) the current spec allows the following alternatives 1) continue recognition until speech-complete-timeout indicates that the caller stopped speaking; 2) return completion cause "success" and a recognition result (as if speech-complete-timeout did elapse). In the former case the recognition timeout is only applied to utterances that have no match. But this seems not to go with "maxspeechtimeout" of VoiceXML. In the later case the client does not get informed that only part of the callers utterance was recognized. I suggest to return a recognition result and a new completion cause "success-maxtime" (compare recorder completion causes in 10.4). Either "too-much-speech-timeout" or "recognition-timeout" would become obsolete. Klaus -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Montag, 19. April 2004 19:04 To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout Klaus, In our case, when this timer expires, we never have a match. The 003 recognition-timeout and 008 too-much-speech-timeout are equivalent and ambiguous it seems. In this case, we return a 008 too-much-speech-timeout since in our case we don't produce a match. Pierre -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] Sent: 19 avril, 2004 11:50 To: Pierre Forgues Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout Hi Pierre, this is inline with my understanding of the spec. If the timer expires and there is no match, completion code 003 (recognition-timeout) should be returned, right? If the timer expires and there is a match, completion code 008 (too-much-speech-timeout) along with a recognition result is returned? Klaus -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Montag, 19. April 2004 16:36 To: Reifenrath, Klaus; speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout Hi Klaus, The definition is indeed a bit ambiguous. It is the timer that is started when START-OF-SPEECH event is generated by the server. It is indeed used to specify the maximum duration of an utterance. Pierre -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of Reifenrath, Klaus Sent: 19 avril, 2004 07:51 To: 'speechsc@ietf.org' Subject: [Speechsc] Recognition Timeout The definition of the recognition-timeout header field could be more precise about when the timer is started. Is the timer started when START-OF-SPEECH is generated by the server or when RECOGNIZE/RECOGNITION-START-TIMERS is send by the client? In the former case the parameter specifies the maximum period of time for the utterance and maps nicely to the property maxspeechtimeout in VoiceXML or the attribute babbletimeout in SALT. In the later case it would be equivalent to the attribute maxtimeout in SALT. Klaus _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Apr 27 20:17:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQwiG-0000DT-9H; Wed, 27 Apr 2005 20:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQwiC-0000Bc-7n for speechsc@megatron.ietf.org; Wed, 27 Apr 2005 20:17:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23575 for ; Wed, 27 Apr 2005 20:16:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQwuw-0007Yp-Nv for speechsc@ietf.org; Wed, 27 Apr 2005 20:30:11 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2005 17:16:47 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3S0GhpR009068; Wed, 27 Apr 2005 17:16:43 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Speechsc] Recognition Timeout Date: Wed, 27 Apr 2005 17:17:47 -0700 Message-ID: <6677B3346233B94EBB11C060935101200ADEB43A@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Recognition Timeout Thread-Index: AcVLLXAxgL4+XiAfRwWNQVwHFpXpNwAWElbQ From: "Shanmugham, Saravanan" To: "Reifenrath, Klaus" , "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I will add text to describe the meaning of too much speech and its consequences. But I don't see, the need to depracate "recognition-=3Dtimeout" and = leave it in, conisdering MRCPv2 is not truly backward compatible with MRCPv1 nor was that the aim to be. But we've kept the over model and messaging and headers because it made sense.=20 So I eill go ahead and remove the "recongition-timeout" status from the Completion -Cause code list. Also, if the speech did go on for too long and was expected to be treated as an "end-of-speech" event AND if the speech spoken uptil that point did match up with some grammar, then I would expect the return value to be a Completion-Cause of "000" "success". If the timeout expired and a complete match did not happen, then it should be returning"too-much-speech-timeout". I hope we don't add a different success cause for this case. Specially if its not a common case which I agree it is not. Thanks, Sarvi -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Wednesday, April 27, 2005 6:29 AM To: 'Brett Gavagni'; Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: FW: [Speechsc] Recognition Timeout =20 Hi Brett, =20 below you find the discussion we had on this topic last April. =20 It seems this did not make it into the spec. Thanks for=20 pointing to this inconsistency. =20 I suggest to mark 003 as deprecated, but leave it in the=20 spec for backwards-compatibility with MRCPv1. =20 Regards, Klaus =20 -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Mittwoch, 28. April 2004 14:32 To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout =20 OK, agreed! This would leave the choice to the=20 recognition engine. The second option would be used if=20 there are worthwhile results to return. =20 =20 Practically speaking, we have not seen this as a common case. Pierre =20 -----Original Message----- From: speechsc-admin@ietf.org=20 [mailto:speechsc-admin@ietf.org] On Behalf Of Reifenrath, Klaus Sent: 28 avril, 2004 04:46 To: Pierre Forgues Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout =20 Hi Pierre! =20 Why should the available result be discarded right away?=20 This would only elongate the call. MRCP should allow two ways of handling this situation: 1) immediately return with a 008 "too-much-speech" 2) return 00x "success-maxtime" plus a recognition result=20 In 2) the recognizer treats the situation, when the=20 maximum length of speech has been reached, as if it had=20 detected end-of-speech. =20 Klaus =20 -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Dienstag, 27. April 2004 20:49 To: Reifenrath, Klaus; speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout =20 =20 We return immediately with a 008=20 "too-much-speech-timeout". How about just clarifying the=20 documentation to reflect this? =20 Pierre =20 -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] Sent: 27 avril, 2004 04:13 To: speechsc@ietf.org Cc: Pierre Forgues Subject: RE: [Speechsc] Recognition Timeout =20 Hi group! =20 In case the callers utterance exceeds the maximum duration=20 (given by the recognition-timeout) and the recognizer has a complete=20 match, but the caller did not stop speaking=20 (speech-complete-timeout did not elapse) the current spec=20 allows the following alternatives 1) continue recognition until speech-complete-timeout=20 indicates that the caller stopped speaking; 2) return completion cause "success" and a recognition=20 result (as if speech-complete-timeout did elapse).=20 In the former case the recognition timeout is only applied=20 to utterances that have no match. But this seems not to go=20 with "maxspeechtimeout" of VoiceXML.=20 In the later case the client does not get informed that=20 only part of the callers utterance was recognized. =20 I suggest to return a recognition result and a new=20 completion cause "success-maxtime" (compare recorder=20 completion causes in 10.4). Either=20 "too-much-speech-timeout" or "recognition-timeout" would=20 become obsolete.=20 =20 Klaus =20 -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Montag, 19. April 2004 19:04 To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout =20 =20 Klaus, =20 In our case, when this timer expires, we never have a=20 match. The 003 recognition-timeout and 008=20 too-much-speech-timeout are equivalent and ambiguous it=20 seems. In this case, we return a 008=20 too-much-speech-timeout since in our case we don't produce a match. =20 Pierre =20 -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] Sent: 19 avril, 2004 11:50 To: Pierre Forgues Cc: speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout =20 Hi Pierre, =20 this is inline with my understanding of the spec. =20 If the timer expires and there is no match, completion code 003 (recognition-timeout) should be returned, right? If the timer expires and there is a match, completion code 008 (too-much-speech-timeout) along with a recognition result=20 is returned?=20 =20 Klaus =20 =20 -----Original Message----- From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Montag, 19. April 2004 16:36 To: Reifenrath, Klaus; speechsc@ietf.org Subject: RE: [Speechsc] Recognition Timeout =20 =20 Hi Klaus, =20 The definition is indeed a bit ambiguous. It is the timer=20 that is started when START-OF-SPEECH event is generated by=20 the server. It is indeed used to specify the maximum=20 duration of an utterance. =20 =20 Pierre -----Original Message----- From: speechsc-admin@ietf.org=20 [mailto:speechsc-admin@ietf.org] On Behalf Of Reifenrath, Klaus Sent: 19 avril, 2004 07:51 To: 'speechsc@ietf.org' Subject: [Speechsc] Recognition Timeout =20 The definition of the recognition-timeout header field=20 could be more precise about when the timer is started. Is=20 the timer started when START-OF-SPEECH is generated by the=20 server or when RECOGNIZE/RECOGNITION-START-TIMERS is send=20 by the client? In the former case the parameter specifies=20 the maximum period of time for the utterance and maps=20 nicely to the property maxspeechtimeout in VoiceXML or the=20 attribute babbletimeout in SALT. In the later case it=20 would be equivalent to the attribute maxtimeout in SALT. =20 Klaus =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Apr 28 09:39:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9Ey-000752-ER; Thu, 28 Apr 2005 09:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9Ew-00074x-Py for speechsc@megatron.ietf.org; Thu, 28 Apr 2005 09:39:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14457 for ; Thu, 28 Apr 2005 09:39:35 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR9Rl-0002jy-IT for speechsc@ietf.org; Thu, 28 Apr 2005 09:52:55 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3SDdOAa815966 for ; Thu, 28 Apr 2005 09:39:24 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3SDdOYQ367454 for ; Thu, 28 Apr 2005 07:39:24 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3SDdNSi010067 for ; Thu, 28 Apr 2005 07:39:23 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3SDdNxl010056 for ; Thu, 28 Apr 2005 07:39:23 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Thu, 28 Apr 2005 09:39:21 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/28/2005 07:39:22, Serialize complete at 04/28/2005 07:39:22 X-Spam-Score: 0.5 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1907128266==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multipart message in MIME format. --===============1907128266== Content-Type: multipart/alternative; boundary="=_alternative 004B047185256FF1_=" This is a multipart message in MIME format. --=_alternative 004B047185256FF1_= Content-Type: text/plain; charset="US-ASCII" Hi, There's room for interpretation in the following section of the current draft of MRCPv2. p53 of the draft-ietf-speechsc-mrcpv2-06.txt Hotword Mode Recognition Hotword mode is where the recognizer looks for a specific speech grammar or dtmf sequence and ignores speech or DTMF that does not match. It does not timeout nor generate a no-match and will complete only for a successful match of grammar. What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode? What would justify a server not honoring timeouts if a client has the ability to specify timeout values? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ (561) 862-2097 T/L (975) gavagni@us.ibm.com --=_alternative 004B047185256FF1_= Content-Type: text/html; charset="US-ASCII"
Hi,

There's room for interpretation in the following section of the current draft of MRCPv2.

p53 of the draft-ietf-speechsc-mrcpv2-06.txt
Hotword Mode Recognition
   Hotword mode is where the recognizer looks for a specific speech
   grammar or dtmf sequence and ignores speech or DTMF that does not
   match. It does not timeout nor generate a no-match and will complete
   only for a successful match of grammar.

What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode?

What would justify a server not honoring timeouts if a client has the ability to specify timeout values?

Thanks,

Brett Gavagni    
WebSphere Voice Server Development            
http://www-306.ibm.com/software/pervasive/voice_server/
(561) 862-2097 T/L (975)  
gavagni@us.ibm.com
 --=_alternative 004B047185256FF1_=-- --===============1907128266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1907128266==-- From speechsc-bounces@ietf.org Thu Apr 28 10:39:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRABK-0003Cb-CX; Thu, 28 Apr 2005 10:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRABG-0003AE-Lv for speechsc@megatron.ietf.org; Thu, 28 Apr 2005 10:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21764 for ; Thu, 28 Apr 2005 10:39:52 -0400 (EDT) Received: from mx2.scansoft.com ([198.71.64.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAO9-0005La-7d for speechsc@ietf.org; Thu, 28 Apr 2005 10:53:13 -0400 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx2.scansoft.com with InterScan Messaging Security Suite; Thu, 28 Apr 2005 10:43:45 -0400 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Thu, 28 Apr 2005 09:59:45 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Brett Gavagni'" Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Date: Thu, 28 Apr 2005 09:59:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) X-Spam-Score: 0.9 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1021436328==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1021436328== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54BFA.8160C67C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54BFA.8160C67C Content-Type: text/plain I think the server should return with status code 402 (method not valid in this state). Klaus _____ From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Donnerstag, 28. April 2005 15:39 To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hi, There's room for interpretation in the following section of the current draft of MRCPv2. p53 of the draft-ietf-speechsc-mrcpv2-06.txt Hotword Mode Recognition Hotword mode is where the recognizer looks for a specific speech grammar or dtmf sequence and ignores speech or DTMF that does not match. It does not timeout nor generate a no-match and will complete only for a successful match of grammar. What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode? What would justify a server not honoring timeouts if a client has the ability to specify timeout values? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ (561) 862-2097 T/L (975) gavagni@us.ibm.com ------_=_NextPart_001_01C54BFA.8160C67C Content-Type: text/html
I think the server should return with status code 402 (method not valid in this state).
 
Klaus

From: Brett Gavagni [mailto:gavagni@us.ibm.com]
Sent: Donnerstag, 28. April 2005 15:39
To: speechsc@ietf.org
Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification


Hi,

There's room for interpretation in the following section of the current draft of MRCPv2.

p53 of the draft-ietf-speechsc-mrcpv2-06.txt
Hotword Mode Recognition
   Hotword mode is where the recognizer looks for a specific speech
   grammar or dtmf sequence and ignores speech or DTMF that does not
   match. It does not timeout nor generate a no-match and will complete
   only for a successful match of grammar.

What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode?

What would justify a server not honoring timeouts if a client has the ability to specify timeout values?

Thanks,

Brett Gavagni    
WebSphere Voice Server Development            
http://www-306.ibm.com/software/pervasive/voice_server/
(561) 862-2097 T/L (975)  
gavagni@us.ibm.com
 ------_=_NextPart_001_01C54BFA.8160C67C-- --===============1021436328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1021436328==-- From speechsc-bounces@ietf.org Fri Apr 29 11:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRXtZ-0007q9-Ue; Fri, 29 Apr 2005 11:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRXtX-0007pb-VL for speechsc@megatron.ietf.org; Fri, 29 Apr 2005 11:59:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09357 for ; Fri, 29 Apr 2005 11:59:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRY6c-0002Ir-Rt for speechsc@ietf.org; Fri, 29 Apr 2005 12:12:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2005 08:58:31 -0700 X-IronPort-AV: i="3.92,139,1112598000"; d="scan'208,217"; a="256333562:sNHT1274103764" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3TFvgiW019804 for ; Fri, 29 Apr 2005 08:58:28 -0700 (PDT) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 08:58:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Apr 2005 08:58:26 -0700 Message-ID: Thread-Topic: propose adding "media-type" header field in RECOGNIZE or SET-PARAMS/GET-PARAMS methods Thread-Index: AcVM1EeF6F3QJhBHRniGmUHADY5x4w== From: "Jenny Yao \(jyao\)" To: X-OriginalArrivalTime: 29 Apr 2005 15:58:39.0412 (UTC) FILETIME=[4F1EBF40:01C54CD4] X-Spam-Score: 0.6 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Speechsc] propose adding "media-type" header field in RECOGNIZE or SET-PARAMS/GET-PARAMS methods X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0143122949==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0143122949== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54CD4.48141B52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C54CD4.48141B52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 VoiceXML 2.1 specifies "recording user utterances while attempting recognition". This can be done through recog-only-header "save-waveform" and "waveform-uri" in MRCP V1 and V2. VoiceXML 2.1 also uses recordutterancetype property to specify the media format of the result recording. However, there is no way in MRCP to pass the required media format to the server. We propose using the "Media-Type" header field, currently defined for the recording resource, in the RECOGNIZE method or the SET-PARAMS/GET-PARAMS methods to specify a media type. The Save-Waveform carries a URI pointing to the audio captured during recognition. The captured audio SHOULD be saved with this media-type. =20 Thanks. =20 Jenny ------_=_NextPart_001_01C54CD4.48141B52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
VoiceXML=20 2.1 specifies "recording = user=20 utterances while attempting recognition". This can be done through=20 recog-only-header "save-waveform" and "waveform-uri" in MRCP V1 and V2. = VoiceXML=20 2.1 also uses recordutterancetype = property to=20 specify the media format of the result recording. However, there is = no way=20 in MRCP to pass the required media format to the = server. We=20 propose using the "Media-Type" header=20 field, currently defined for the recording resource, in the RECOGNIZE = method or=20 the SET-PARAMS/GET-PARAMS methods to specify a media type. The = Save-Waveform carries a URI pointing to the audio captured during=20 recognition. The captured audio SHOULD be saved with this=20 media-type.
 
Thanks.
 
Jenny
=
------_=_NextPart_001_01C54CD4.48141B52-- --===============0143122949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0143122949==-- From speechsc-bounces@ietf.org Fri Apr 29 12:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRYeX-0000wc-Us; Fri, 29 Apr 2005 12:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRYeW-0000wV-5r for speechsc@megatron.ietf.org; Fri, 29 Apr 2005 12:47:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13740 for ; Fri, 29 Apr 2005 12:47:41 -0400 (EDT) Received: from vesicle.nsi.edu ([204.128.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRYrb-0004Zf-5c for speechsc@ietf.org; Fri, 29 Apr 2005 13:01:16 -0400 Received: from swing (swing.nsi.edu [198.133.185.118]) by vesicle.nsi.edu (8.12.9/8.12.9) with ESMTP id j3TGkQus030795; Fri, 29 Apr 2005 09:46:26 -0700 Message-Id: <200504291646.j3TGkQus030795@vesicle.nsi.edu> From: "Thomas Gal" To: "'Jenny Yao \(jyao\)'" , Subject: RE: [Speechsc] propose adding "media-type" header field in RECOGNIZE orSET-PARAMS/GET-PARAMS methods Date: Fri, 29 Apr 2005 09:46:51 -0700 Organization: The Neurosciences Institute MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVM1EeF6F3QJhBHRniGmUHADY5x4wAA+Uew X-Spam-Score: 0.3 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1631093934==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1631093934== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C54CA0.61BDBC70" This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C54CA0.61BDBC70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Though this information could probably be inferred from the filename extension, If we are going to follow/emulate the RECORD methodology than it should also be available as a MIME body to the RECOGNITION COMPLETE/STOP events as well. Otherwise I agree completely. -Tom _____ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Jenny Yao (jyao) Sent: Friday, April 29, 2005 8:58 AM To: speechsc@ietf.org Subject: [Speechsc] propose adding "media-type" header field in RECOGNIZE orSET-PARAMS/GET-PARAMS methods VoiceXML 2.1 specifies "recording user utterances while attempting recognition". This can be done through recog-only-header "save-waveform" and "waveform-uri" in MRCP V1 and V2. VoiceXML 2.1 also uses recordutterancetype property to specify the media format of the result recording. However, there is no way in MRCP to pass the required media format to the server. We propose using the "Media-Type" header field, currently defined for the recording resource, in the RECOGNIZE method or the SET-PARAMS/GET-PARAMS methods to specify a media type. The Save-Waveform carries a URI pointing to the audio captured during recognition. The captured audio SHOULD be saved with this media-type. Thanks. Jenny ------=_NextPart_000_0055_01C54CA0.61BDBC70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Though this information could = probably be inferred from the filename extension, If we are going to follow/emulate = the RECORD methodology than it should also be available as a MIME body to the = RECOGNITION COMPLETE/STOP events as well. Otherwise I agree = completely.

 

-Tom

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Jenny Yao (jyao)
Sent: Friday, April 29, = 2005 8:58 AM
To: speechsc@ietf.org
Subject: [Speechsc] = propose adding "media-type" header field in RECOGNIZE orSET-PARAMS/GET-PARAMS methods

 

 

 

VoiceXML 2.1 specifies "recording user = utterances while attempting recognition". This can be done through = recog-only-header "save-waveform" and "waveform-uri" in MRCP V1 and = V2. VoiceXML 2.1 also uses recordutterancetype property = to specify the media format of the result recording. However, there is no way in MRCP to pass the required media format to the = server. We propose using the "Media-Type" header field, = currently defined for the recording resource, in the RECOGNIZE method or the SET-PARAMS/GET-PARAMS methods to specify a media type. The Save-Waveform carries a URI pointing to the audio captured during recognition. The captured audio SHOULD be saved with this = media-type.

 

Thanks.

 

Jenny

------=_NextPart_000_0055_01C54CA0.61BDBC70-- --===============1631093934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1631093934==-- From speechsc-bounces@ietf.org Fri Apr 29 14:02:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRZos-0005Rn-Cs; Fri, 29 Apr 2005 14:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRZor-0005Ri-Ik for speechsc@megatron.ietf.org; Fri, 29 Apr 2005 14:02:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23738 for ; Fri, 29 Apr 2005 14:02:24 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRa1u-0000gm-7U for speechsc@ietf.org; Fri, 29 Apr 2005 14:15:58 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3TI2Eua424256 for ; Fri, 29 Apr 2005 14:02:15 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3TI2EI2318242 for ; Fri, 29 Apr 2005 12:02:14 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3TI2ED5009384 for ; Fri, 29 Apr 2005 12:02:14 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3TI2EPU009368; Fri, 29 Apr 2005 12:02:14 -0600 In-Reply-To: To: "Reifenrath, Klaus" MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Fri, 29 Apr 2005 14:02:12 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/29/2005 12:02:13, Serialize complete at 04/29/2005 12:02:13 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org The following statement is a bit convoluted in the current draft specification w.r.t. hotword mode. "It does not timeout nor generate a no-match and will complete only for a successful match of grammar." The current draft specification doesn't detail that the timeout headers are invalid for a RECOGNIZE request with Recognition-Mode: hotword. What would justify a server not honoring timeouts if a client has the ability to specify timeout values? The hotword statement listed above also raises concerns in terms of a server providing a robust implementation. An implementing server would have to entirely rely on a client to terminate a recognition request where a hotword isn't matched. The complete reliance on a client has a whole separate set of issues for a server to facilitate redundancy. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Reifenrath, Klaus" 04/28/2005 09:59 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification I think the server should return with status code 402 (method not valid in this state). Klaus From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Donnerstag, 28. April 2005 15:39 To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hi, There's room for interpretation in the following section of the current draft of MRCPv2. p53 of the draft-ietf-speechsc-mrcpv2-06.txt Hotword Mode Recognition Hotword mode is where the recognizer looks for a specific speech grammar or dtmf sequence and ignores speech or DTMF that does not match. It does not timeout nor generate a no-match and will complete only for a successful match of grammar. What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode? What would justify a server not honoring timeouts if a client has the ability to specify timeout values? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Apr 29 14:58:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRago-0008PY-MZ; Fri, 29 Apr 2005 14:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRagi-0008Kz-QU for speechsc@megatron.ietf.org; Fri, 29 Apr 2005 14:58:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28400 for ; Fri, 29 Apr 2005 14:58:07 -0400 (EDT) Received: from vesicle.nsi.edu ([204.128.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRatp-000479-3C for speechsc@ietf.org; Fri, 29 Apr 2005 15:11:42 -0400 Received: from swing (swing.nsi.edu [198.133.185.118]) by vesicle.nsi.edu (8.12.9/8.12.9) with ESMTP id j3TIvwus010001; Fri, 29 Apr 2005 11:57:58 -0700 Message-Id: <200504291857.j3TIvwus010001@vesicle.nsi.edu> From: "Thomas Gal" To: "'Brett Gavagni'" , "'Reifenrath, Klaus'" Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Date: Fri, 29 Apr 2005 11:58:23 -0700 Organization: The Neurosciences Institute MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVM5bbqqMgfauOLR564Ht64ZtvSRwABichA X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hotword mode recognition is specifically the case where there's no timeout and you want to be actively listening. I don't really see any problem. But to be pragmatic...... Obviously in the case where there is a limit to the time frame in which the client will want that recognition to occur, they can then send a CANCEL which as you point out may leave holes if there are faulty clients. This doesn't prevent the server from having it's own set of limits for such things, which should obviously be set in the context of the application. Now I wouldn't have a problem with a special hotword mode timeout parameter (or just honoring the other timeout values) to help in that case, but I also don't see why that can't just be an implementation dependant parameter that doesn't need to be specified or investigated in this protocol. Chances are any services/products sold using this protocol will be based on per-port licensing or some other metric which will assure that it's in the best interest of the user to not be wasting recognition resources, as speech recognition is hardware intensive already. The fact remains that having any sort of real timeout value which limits the recognition scope to something short of the complete "speech transaction" (lets say phone call or whatever) makes it become just a regular old recognition and specifically NOT HOTWORD mode recognition as people define it. Personally I agree with Klaus that timeout values should be errors in the context of Hotword recognitions. -Tom -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Friday, April 29, 2005 11:02 AM To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification The following statement is a bit convoluted in the current draft specification w.r.t. hotword mode. "It does not timeout nor generate a no-match and will complete only for a successful match of grammar." The current draft specification doesn't detail that the timeout headers are invalid for a RECOGNIZE request with Recognition-Mode: hotword. What would justify a server not honoring timeouts if a client has the ability to specify timeout values? The hotword statement listed above also raises concerns in terms of a server providing a robust implementation. An implementing server would have to entirely rely on a client to terminate a recognition request where a hotword isn't matched. The complete reliance on a client has a whole separate set of issues for a server to facilitate redundancy. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Reifenrath, Klaus" 04/28/2005 09:59 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification I think the server should return with status code 402 (method not valid in this state). Klaus From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Donnerstag, 28. April 2005 15:39 To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hi, There's room for interpretation in the following section of the current draft of MRCPv2. p53 of the draft-ietf-speechsc-mrcpv2-06.txt Hotword Mode Recognition Hotword mode is where the recognizer looks for a specific speech grammar or dtmf sequence and ignores speech or DTMF that does not match. It does not timeout nor generate a no-match and will complete only for a successful match of grammar. What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode? What would justify a server not honoring timeouts if a client has the ability to specify timeout values? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Apr 29 15:40:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRbLo-0007Er-13; Fri, 29 Apr 2005 15:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRbLm-0007Em-4R for speechsc@megatron.ietf.org; Fri, 29 Apr 2005 15:40:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02491 for ; Fri, 29 Apr 2005 15:40:30 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRbYr-0006Qw-IE for speechsc@ietf.org; Fri, 29 Apr 2005 15:54:06 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3TJeLLg265240 for ; Fri, 29 Apr 2005 15:40:21 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3TJeKnT168506 for ; Fri, 29 Apr 2005 13:40:20 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3TJeKha028498 for ; Fri, 29 Apr 2005 13:40:20 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3TJeKpd028494; Fri, 29 Apr 2005 13:40:20 -0600 In-Reply-To: <200504291857.j3TIvwus010001@vesicle.nsi.edu> To: "Thomas Gal" MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Fri, 29 Apr 2005 15:40:19 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 04/29/2005 13:40:20, Serialize complete at 04/29/2005 13:40:20 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: speechsc@ietf.org, "'Reifenrath, Klaus'" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I'll re-iterate the objection; if a client wants the recognition to last for a timeout, then it should be able to specify this condition. The current wording in the specification doesn't clearly indicate that a client request to START-INPUT-TIMERS is invalid for Recognition-Mode: hotword. The Recognizer State Machine should be clearly documented for both distinct recognition mode if the interpretation is expected to be inconsistent. Inconsistency usually add to the challenge of implementing a specification and facilitating interoperability. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Thomas Gal" 04/29/2005 02:58 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, "'Reifenrath, Klaus'" cc Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hotword mode recognition is specifically the case where there's no timeout and you want to be actively listening. I don't really see any problem. But to be pragmatic...... Obviously in the case where there is a limit to the time frame in which the client will want that recognition to occur, they can then send a CANCEL which as you point out may leave holes if there are faulty clients. This doesn't prevent the server from having it's own set of limits for such things, which should obviously be set in the context of the application. Now I wouldn't have a problem with a special hotword mode timeout parameter (or just honoring the other timeout values) to help in that case, but I also don't see why that can't just be an implementation dependant parameter that doesn't need to be specified or investigated in this protocol. Chances are any services/products sold using this protocol will be based on per-port licensing or some other metric which will assure that it's in the best interest of the user to not be wasting recognition resources, as speech recognition is hardware intensive already. The fact remains that having any sort of real timeout value which limits the recognition scope to something short of the complete "speech transaction" (lets say phone call or whatever) makes it become just a regular old recognition and specifically NOT HOTWORD mode recognition as people define it. Personally I agree with Klaus that timeout values should be errors in the context of Hotword recognitions. -Tom -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Friday, April 29, 2005 11:02 AM To: Reifenrath, Klaus Cc: speechsc@ietf.org Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification The following statement is a bit convoluted in the current draft specification w.r.t. hotword mode. "It does not timeout nor generate a no-match and will complete only for a successful match of grammar." The current draft specification doesn't detail that the timeout headers are invalid for a RECOGNIZE request with Recognition-Mode: hotword. What would justify a server not honoring timeouts if a client has the ability to specify timeout values? The hotword statement listed above also raises concerns in terms of a server providing a robust implementation. An implementing server would have to entirely rely on a client to terminate a recognition request where a hotword isn't matched. The complete reliance on a client has a whole separate set of issues for a server to facilitate redundancy. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Reifenrath, Klaus" 04/28/2005 09:59 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification I think the server should return with status code 402 (method not valid in this state). Klaus From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Donnerstag, 28. April 2005 15:39 To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Hotword Mode Recognition clarification Hi, There's room for interpretation in the following section of the current draft of MRCPv2. p53 of the draft-ietf-speechsc-mrcpv2-06.txt Hotword Mode Recognition Hotword mode is where the recognizer looks for a specific speech grammar or dtmf sequence and ignores speech or DTMF that does not match. It does not timeout nor generate a no-match and will complete only for a successful match of grammar. What response should a server generate for a START-INPUT-TIMERS request, when the current session has a recognition in progress in hotword mode? What would justify a server not honoring timeouts if a client has the ability to specify timeout values? Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc