From speechsc-bounces@ietf.org Wed Jun 01 08:59:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSod-0005F7-0t; Wed, 01 Jun 2005 08:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSob-0005D4-Hl for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 08:59: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 IAA13961 for ; Wed, 1 Jun 2005 08:59:15 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdT8N-00022s-Nm for speechsc@ietf.org; Wed, 01 Jun 2005 09:19:49 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j51Cx8MK011838 for ; Wed, 1 Jun 2005 08:59:08 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j51Cx88c228096 for ; Wed, 1 Jun 2005 06:59:08 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j51Cx8CI002065 for ; Wed, 1 Jun 2005 06:59:08 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j51Cx8eA002053 for ; Wed, 1 Jun 2005 06:59:08 -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: Wed, 1 Jun 2005 08:59:06 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/01/2005 06:59:07, Serialize complete at 06/01/2005 06:59:07 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? 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 Are there currently any plans to include the support for W3C EMMA Working Draft to the MRCPv2 specification for the returning of recognition results? 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 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 01 09:16:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdT5E-0004Tg-6Z; Wed, 01 Jun 2005 09:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdT59-0004Ol-N6 for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 09:16: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 JAA15048 for ; Wed, 1 Jun 2005 09:16:23 -0400 (EDT) Received: from dsl092-077-144.bos1.dsl.speakeasy.net ([66.92.77.144] helo=jerrycarter.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdTOy-0002ol-4f for speechsc@ietf.org; Wed, 01 Jun 2005 09:36:57 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jerrycarter.org (Postfix) with ESMTP id C4FEEA2119C; Wed, 1 Jun 2005 09:16:24 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9ea4dbe4a16c75c4f3da8de7c60b64dd@jerrycarter.org> Content-Transfer-Encoding: 7bit From: Jerry Carter Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? Date: Wed, 1 Jun 2005 09:16:23 -0400 To: Brett Gavagni X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Give that EMMA is at working draft level within the W3C, it would be premature to require any form of EMMA support. Making a provision in MRCP to support EMMA at a later date would be appropriate, though. On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: > Are there currently any plans to include the support for W3C EMMA > Working > Draft to the MRCPv2 specification for the returning of recognition > results? > > 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 > > > _______________________________________________ > 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 Jun 01 09:34:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTMX-0004ON-22; Wed, 01 Jun 2005 09:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTMV-0004OF-0O for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 09:34:23 -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 JAA16260 for ; Wed, 1 Jun 2005 09:34:19 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdTgH-0003hD-ER for speechsc@ietf.org; Wed, 01 Jun 2005 09:54:50 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j51DY9mD390512 for ; Wed, 1 Jun 2005 09:34:10 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j51DY9MM151648 for ; Wed, 1 Jun 2005 07:34:09 -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 j51DY90r022533 for ; Wed, 1 Jun 2005 07:34:09 -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 j51DY9JI022521 for ; Wed, 1 Jun 2005 07:34:09 -0600 In-Reply-To: <9ea4dbe4a16c75c4f3da8de7c60b64dd@jerrycarter.org> To: Jerry Carter MIME-Version: 1.0 Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 1 Jun 2005 09:34:07 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/01/2005 07:34:08, Serialize complete at 06/01/2005 07:34:08 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 current W3 NLSML specification is also a "W3 Working Draft" and not a "W3 Recommendation". http://www.w3.org/TR/nl-spec/ Natural Language Semantics Markup Language for the Speech Interface Framework W3C Working Draft 20 November 2000 The current NLSML specification is actually more outdated in terms of the function required to support the current SGRS specification (ie. Semantic Interpretation). My suggestion would be to amend the current MRCPv2 specification to include EMMA support as at least optional. 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 Jerry Carter 06/01/2005 09:16 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? Give that EMMA is at working draft level within the W3C, it would be premature to require any form of EMMA support. Making a provision in MRCP to support EMMA at a later date would be appropriate, though. On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: > Are there currently any plans to include the support for W3C EMMA > Working > Draft to the MRCPv2 specification for the returning of recognition > results? > > 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 > > > _______________________________________________ > 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 Jun 01 09:49:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTbY-0003TH-Ob; Wed, 01 Jun 2005 09:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTbU-0003T9-JI for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 09:49:55 -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 JAA17384 for ; Wed, 1 Jun 2005 09:49:50 -0400 (EDT) Received: from dsl092-077-144.bos1.dsl.speakeasy.net ([66.92.77.144] helo=jerrycarter.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdTvJ-0004U7-Ch for speechsc@ietf.org; Wed, 01 Jun 2005 10:10:22 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jerrycarter.org (Postfix) with ESMTP id 8F6A0A211FC; Wed, 1 Jun 2005 09:49:50 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <585a5e7b1e8df746f727ae2c29e77fa7@jerrycarter.org> Content-Transfer-Encoding: 7bit From: Jerry Carter Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? Date: Wed, 1 Jun 2005 09:49:49 -0400 To: Brett Gavagni X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 On Jun 1, 2005, at 9:34 AM, Brett Gavagni wrote: > The current W3 NLSML specification is also a "W3 Working Draft" and > not a > "W3 Recommendation". > > http://www.w3.org/TR/nl-spec/ > Natural Language Semantics Markup Language for the Speech Interface > Framework > > W3C Working Draft 20 November 2000 > > The current NLSML specification is actually more outdated in terms of > the > function required to support the current SGRS specification (ie. > Semantic > Interpretation). Actually, the situation for NLSML is worse. The NLSML version that was used with MRCP 1.0 was an internal W3C draft that was (1) never published and (2) never reviewed by the working group. > My suggestion would be to amend the current MRCPv2 specification to > include EMMA support as at least optional. I quite agree. -=- Jerry Carter _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 01 09:51:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTca-0003a9-HV; Wed, 01 Jun 2005 09:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTcY-0003a1-UX for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 09:50:59 -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 JAA17428 for ; Wed, 1 Jun 2005 09:50:56 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdTwN-0004am-35 for speechsc@ietf.org; Wed, 01 Jun 2005 10:11:28 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 1 Jun 2005 09:50:47 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Brett Gavagni'" Subject: RE: [Speechsc] EMMA: Extensible MultiModal Annotation markup lang uage support? Date: Wed, 1 Jun 2005 09:50:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: speechsc@ietf.org, Jerry Carter 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, right, NLSML did not become a W3C Recommendation. Therefore the MRCPv2 spec includes a definition of NLSML (see sections 9.6 and A.2.1 in the 06 version of MRCPv2). Klaus -----Original Message----- From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Mittwoch, 1. Juni 2005 15:34 To: Jerry Carter Cc: speechsc@ietf.org Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? The current W3 NLSML specification is also a "W3 Working Draft" and not a "W3 Recommendation". http://www.w3.org/TR/nl-spec/ Natural Language Semantics Markup Language for the Speech Interface Framework W3C Working Draft 20 November 2000 The current NLSML specification is actually more outdated in terms of the function required to support the current SGRS specification (ie. Semantic Interpretation). My suggestion would be to amend the current MRCPv2 specification to include EMMA support as at least optional. 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 Jerry Carter 06/01/2005 09:16 AM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc speechsc@ietf.org Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? Give that EMMA is at working draft level within the W3C, it would be premature to require any form of EMMA support. Making a provision in MRCP to support EMMA at a later date would be appropriate, though. On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: > Are there currently any plans to include the support for W3C EMMA > Working > Draft to the MRCPv2 specification for the returning of recognition > results? > > 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 > > > _______________________________________________ > 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 Jun 01 10:08:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTtA-0002pX-7u; Wed, 01 Jun 2005 10:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTt5-0002o5-UZ for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 10:08:06 -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 KAA19047 for ; Wed, 1 Jun 2005 10:08:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUCu-0005Q8-OH for speechsc@ietf.org; Wed, 01 Jun 2005 10:28:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2005 07:07:53 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="640079569:sNHT32469082" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51E7olq007281; Wed, 1 Jun 2005 07:07:51 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j51DuIVL010528; Wed, 1 Jun 2005 06:56:19 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C96D84B-A3B8-4587-AC2E-281E643CCB9A@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup lang uage support? Date: Wed, 1 Jun 2005 10:07:48 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117634179.777057"; x:"432200"; a:"rsa-sha1"; b:"nofws:2569"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"JnZgM3h0Nr/j5HYslP92CX79/Q04647yn8DAVlmBUcgp04LUVWsleyVlVE8RDGQkdzm+H9CI" "vNXvV1IUyQXxwLJrtdALMA/1dz3uEgp7mxWGr9Yqa6ZIpUBudovTfbKG4NPWvzYnVenZwkJ5OrU" "oJjAUQBvQBBvV2BTDVmDUyTQ="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation marku" "p lang uage support?"; c:"Date: Wed, 1 Jun 2005 10:07:48 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, Jerry Carter 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 **Chair hat on** The WG consensus, established over a number of IETF meetings and mailing list discussion, was to publish MRCPv2 with the embedded NLSML so that implementations would have a stable base for development and initial deployment. The intent has always been to incorporate EMMA once it was deemed fully cooked. If the WG wants to revisit this consensus in light of the fact we will be going to last call on MRCPv2 imminently, I'll certainly entertain that possibility. Dave. On Jun 1, 2005, at 9:50 AM, Reifenrath, Klaus wrote: > Hi Brett, > > right, NLSML did not become a W3C Recommendation. Therefore the > MRCPv2 spec > includes a definition of NLSML (see sections 9.6 and A.2.1 in the > 06 version > of MRCPv2). > > Klaus > > -----Original Message----- > From: Brett Gavagni [mailto:gavagni@us.ibm.com] > Sent: Mittwoch, 1. Juni 2005 15:34 > To: Jerry Carter > Cc: speechsc@ietf.org > Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup > language support? > > The current W3 NLSML specification is also a "W3 Working Draft" and > not a > "W3 Recommendation". > > http://www.w3.org/TR/nl-spec/ > Natural Language Semantics Markup Language for the Speech Interface > Framework > > W3C Working Draft 20 November 2000 > > The current NLSML specification is actually more outdated in terms > of the > function required to support the current SGRS specification (ie. > Semantic > Interpretation). > > My suggestion would be to amend the current MRCPv2 specification to > include > EMMA support as at least optional. > > 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 > > > > > Jerry Carter > 06/01/2005 09:16 AM > > To > Brett Gavagni/West Palm Beach/IBM@IBMUS > cc > speechsc@ietf.org > Subject > Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language > support? > > > > > > > Give that EMMA is at working draft level within the W3C, it would be > premature to require any form of EMMA support. Making a provision in > MRCP to support EMMA at a later date would be appropriate, though. > > On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: > > >> Are there currently any plans to include the support for W3C EMMA >> Working >> Draft to the MRCPv2 specification for the returning of recognition >> results? >> >> 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 01 10:30:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUEx-0006NC-7X; Wed, 01 Jun 2005 10:30:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUEv-0006My-B4 for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 10:30:37 -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 KAA21649 for ; Wed, 1 Jun 2005 10:30:35 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUYl-0006fJ-0L for speechsc@ietf.org; Wed, 01 Jun 2005 10:51:07 -0400 Received: from daburkewxp (67.5-14-84.ripe.coltfrance.com [84.14.5.67]) by mail.voxpilot.com (Postfix) with ESMTP id 0A26E214041; Wed, 1 Jun 2005 14:30:33 +0000 (GMT) Message-ID: <08d701c566be$d6931530$020aa8c0@db01.voxpilot.com> From: "Dave Burke" To: "David R. Oran" , "Reifenrath, Klaus" References: <6C96D84B-A3B8-4587-AC2E-281E643CCB9A@cisco.com> Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? Date: Wed, 1 Jun 2005 16:30:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, Jerry Carter 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 Having experienced the pain of several MRCPv1 ASR integrations (almost exclusively because of the previously insufficiently defined reco results), we agree with the comment for "stable base for development and deployment". Worried that even a "MAY support EMMA" is damaging but think it a reasonable compromise to add an informative note pointing out that the intent is to incorporate EMMA when it is a stable standard. This way the direction is clear and we don't have to revisit this question bimonthly! -- Dave ----- Original Message ----- From: "David R. Oran" To: "Reifenrath, Klaus" Cc: ; "Jerry Carter" Sent: Wednesday, June 01, 2005 3:07 PM Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language support? > **Chair hat on** > > The WG consensus, established over a number of IETF meetings and mailing > list discussion, was to publish MRCPv2 with the embedded NLSML so that > implementations would have a stable base for development and initial > deployment. > > The intent has always been to incorporate EMMA once it was deemed fully > cooked. > > If the WG wants to revisit this consensus in light of the fact we will be > going to last call on MRCPv2 imminently, I'll certainly entertain that > possibility. > > Dave. > > > On Jun 1, 2005, at 9:50 AM, Reifenrath, Klaus wrote: > >> Hi Brett, >> >> right, NLSML did not become a W3C Recommendation. Therefore the MRCPv2 >> spec >> includes a definition of NLSML (see sections 9.6 and A.2.1 in the 06 >> version >> of MRCPv2). >> >> Klaus >> >> -----Original Message----- >> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >> Sent: Mittwoch, 1. Juni 2005 15:34 >> To: Jerry Carter >> Cc: speechsc@ietf.org >> Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup >> language support? >> >> The current W3 NLSML specification is also a "W3 Working Draft" and not >> a >> "W3 Recommendation". >> >> http://www.w3.org/TR/nl-spec/ >> Natural Language Semantics Markup Language for the Speech Interface >> Framework >> >> W3C Working Draft 20 November 2000 >> >> The current NLSML specification is actually more outdated in terms of >> the >> function required to support the current SGRS specification (ie. >> Semantic >> Interpretation). >> >> My suggestion would be to amend the current MRCPv2 specification to >> include >> EMMA support as at least optional. >> >> 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 >> >> >> >> >> Jerry Carter >> 06/01/2005 09:16 AM >> >> To >> Brett Gavagni/West Palm Beach/IBM@IBMUS >> cc >> speechsc@ietf.org >> Subject >> Re: [Speechsc] EMMA: Extensible MultiModal Annotation markup language >> support? >> >> >> >> >> >> >> Give that EMMA is at working draft level within the W3C, it would be >> premature to require any form of EMMA support. Making a provision in >> MRCP to support EMMA at a later date would be appropriate, though. >> >> On Jun 1, 2005, at 8:59 AM, Brett Gavagni wrote: >> >> >>> Are there currently any plans to include the support for W3C EMMA >>> Working >>> Draft to the MRCPv2 specification for the returning of recognition >>> results? >>> >>> 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 >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 Jun 01 11:45:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVPL-0001Ic-FM; Wed, 01 Jun 2005 11:45:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVPJ-0001IX-0T for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 11:45:26 -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 LAA27813 for ; Wed, 1 Jun 2005 11:45:22 -0400 (EDT) Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdVj8-00029R-Q2 for speechsc@ietf.org; Wed, 01 Jun 2005 12:05:56 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHE00NB0WZH0H@tid.hi.inet> for speechsc@ietf.org; Wed, 01 Jun 2005 17:42:54 +0200 (MEST) Received: from tid.es (valldigna.hi.inet [10.95.12.129]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHE008PVWZHCN@tid.hi.inet> for speechsc@ietf.org; Wed, 01 Jun 2005 17:42:53 +0200 (MEST) Date: Wed, 01 Jun 2005 17:40:24 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Bernat_Vercher?= To: speechsc@ietf.org Message-id: <429DD6E8.3020102@tid.es> Organization: =?iso-8859-1?Q?Telef=F3nica_I=2BD?= MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: es-es, es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:1.6) Gecko/20040113 X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:49.01558 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT Subject: [Speechsc] Question about how to give an error message 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 In the current draft, it says in page 29, section 6.2 (SET-PARAMS): "If some of the headers being set are unsupported for the resource or have illegal values, the server MUST reject the request with a 403, Bad Parameter, and MUST include in the response the header fields that could not be set." Where in the response message should the wrong headers be? I mean, in the message-body, adding in the message-headers only the wrong headers... If the parameter has a wrong value, should not be better to return 404 (Ilegal value for header) instead of 403 (Unsuported Header)? Thanks, Jesus. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 01 12:16:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVtp-0000gj-CB; Wed, 01 Jun 2005 12:16:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVtn-0000ge-Su for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 12:16:55 -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 MAA00359 for ; Wed, 1 Jun 2005 12:16:53 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdWDd-0003gw-U8 for speechsc@ietf.org; Wed, 01 Jun 2005 12:37:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 09:16:45 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51GGhlq013014; Wed, 1 Jun 2005 09:16:43 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Speechsc] Question about how to give an error message Date: Wed, 1 Jun 2005 09:18:35 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B6AACF6@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Question about how to give an error message Thread-Index: AcVmwWlm60xWJTuWRv2Idgm8xBUf+gAA4RJA From: "Shanmugham, Saravanan" To: =?iso-8859-1?Q?Jes=FAs_Bernat_Vercher?= , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Should be returned in the same way it was sent, i.e. not in the body. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Jes=FAs=20 Bernat Vercher Sent: Wednesday, June 01, 2005 8:40 AM To: speechsc@ietf.org Subject: [Speechsc] Question about how to give an error message =20 In the current draft, it says in page 29, section 6.2 (SET-PARAMS): =20 "If some of the headers being set are unsupported for=20 the resource or have illegal values, the server MUST reject the request=20 with a 403, Bad Parameter, and MUST include in the response the=20 header fields that could not be set." =20 Where in the response message should the wrong headers=20 be? I mean, in the message-body, adding in the=20 message-headers only the wrong headers... If the parameter has a wrong value, should not be=20 better to return 404 (Ilegal value for header) instead of 403 (Unsuported Header)? =20 Thanks, Jesus. =20 =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 Wed Jun 01 12:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdW9W-0000rI-R6; Wed, 01 Jun 2005 12:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdW9U-0000lp-GV for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 12:33:08 -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 MAA02381 for ; Wed, 1 Jun 2005 12:33:05 -0400 (EDT) Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdWTK-0004ee-Lp for speechsc@ietf.org; Wed, 01 Jun 2005 12:53:40 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHE008OLZB6CN@tid.hi.inet> for speechsc@ietf.org; Wed, 01 Jun 2005 18:33:07 +0200 (MEST) Received: from tid.es (valldigna.hi.inet [10.95.12.129]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHE00IOGZAQKY@tid.hi.inet> for speechsc@ietf.org; Wed, 01 Jun 2005 18:33:06 +0200 (MEST) Date: Wed, 01 Jun 2005 18:30:22 +0200 From: =?ISO-8859-1?Q?Jes=FAs_Bernat_Vercher?= Subject: Re: [Speechsc] Question about how to give an error message To: "Shanmugham, Saravanan" Message-id: <429DE29E.1060905@tid.es> Organization: =?iso-8859-1?Q?Telef=F3nica_I=2BD?= MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: es-es, es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.6) Gecko/20040113 X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:22 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Just imagine the next example: MRCP/2.0 462 SPEAK 1 Channel-Identifier:3332AECB23433802@speechsynth Voice-gender:neutral Prosody-contour:(0%,+20Hz) (10%,+30% (40%,+10Hz) Speech-Language:en-US Hello World. There is a missing parenthesis in the Prosody-contour field. I think the right answer should be to return the 404 code (Invalid= =20 header value, instead of 403) and returning the Channel-Identifier= =20 header and the Prosody-contour, not adding to the response the correc= t=20 header values: MRCP/2.0 162 543257 404 COMPLETE Channel-Identifier: 32AECB23433802@speechsynth Prosody-contour:(0%,+20Hz) (10%,+30% (40%,+10Hz)=20 Is that correct? Thanks: Jes=FAs. Shanmugham, Saravanan escribi=F3: >Should be returned in the same way it was sent, i.e. not in the body= . > >Sarvi=20 > > -----Original Message----- > From: speechsc-bounces@ietf.org=20 > [mailto:speechsc-bounces@ietf.org] On Behalf Of Jes=FAs=20 > Bernat Vercher > Sent: Wednesday, June 01, 2005 8:40 AM > To: speechsc@ietf.org > Subject: [Speechsc] Question about how to give an error message > =20 > In the current draft, it says in page 29, section 6.2 (SET-PARA= MS): > =20 > "If some of the headers being set are unsupported for=20 > the resource or > have illegal values, the server MUST reject the request=20 > with a 403, > Bad Parameter, and MUST include in the response the=20 > header fields > that could not be set." > =20 > Where in the response message should the wrong headers=20 > be? I mean, in the message-body, adding in the=20 > message-headers only the wrong headers... > If the parameter has a wrong value, should not be=20 > better to return > 404 (Ilegal value for header) instead of 403 (Unsuported Heade= r)? > =20 > Thanks, > Jesus. > =20 > =20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 > > =20 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 01 14:26:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXv0-0003wt-AI; Wed, 01 Jun 2005 14:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXuy-0003wl-BY for speechsc@megatron.ietf.org; Wed, 01 Jun 2005 14:26:16 -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 OAA12485 for ; Wed, 1 Jun 2005 14:26:12 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYEo-0002Cb-EX for speechsc@ietf.org; Wed, 01 Jun 2005 14:46:48 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2005 11:25:36 -0700 X-IronPort-AV: i="3.93,157,1115017200"; d="scan'208"; a="640199963:sNHT79641212232" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51IPQc0023953; Wed, 1 Jun 2005 11:25:31 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Speechsc] Question about how to give an error message Date: Wed, 1 Jun 2005 11:27:22 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B6AAE2F@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Question about how to give an error message Thread-Index: AcVmyATUHa+bg8cuSWqRAq/50dFYrAADzWQA From: "Shanmugham, Saravanan" To: =?iso-8859-1?Q?Jes=FAs_Bernat_Vercher?= X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Correct. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Jes=FAs=20 Bernat Vercher Sent: Wednesday, June 01, 2005 9:30 AM To: Shanmugham, Saravanan Cc: speechsc@ietf.org Subject: Re: [Speechsc] Question about how to give an error message =20 Just imagine the next example: =20 MRCP/2.0 462 SPEAK 1 Channel-Identifier:3332AECB23433802@speechsynth Voice-gender:neutral Prosody-contour:(0%,+20Hz) (10%,+30% (40%,+10Hz)=20 Speech-Language:en-US =20 Hello World. =20 There is a missing parenthesis in the Prosody-contour field. I think the right answer should be to return the 404 code=20 (Invalid header value, instead of 403) and returning the=20 Channel-Identifier header and the Prosody-contour, not=20 adding to the response the correct header values: =20 MRCP/2.0 162 543257 404 COMPLETE Channel-Identifier: 32AECB23433802@speechsynth Prosody-contour:(0%,+20Hz) (10%,+30% (40%,+10Hz)=20 =20 Is that correct? =20 Thanks: =20 Jes=FAs. =20 Shanmugham, Saravanan escribi=F3: =20 >Should be returned in the same way it was sent, i.e. not=20 in the body. > >Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org=20 > [mailto:speechsc-bounces@ietf.org] On Behalf Of Jes=FAs=20 > Bernat Vercher > Sent: Wednesday, June 01, 2005 8:40 AM > To: speechsc@ietf.org > Subject: [Speechsc] Question about how to give an=20 error message > =20 > In the current draft, it says in page 29, section=20 6.2 (SET-PARAMS): > =20 > "If some of the headers being set are unsupported for=20 > the resource or > have illegal values, the server MUST reject the request=20 > with a 403, > Bad Parameter, and MUST include in the response the=20 > header fields > that could not be set." > =20 > Where in the response message should the wrong headers=20 > be? I mean, in the message-body, adding in the=20 > message-headers only the wrong headers... > If the parameter has a wrong value, should not be=20 > better to return > 404 (Ilegal value for header) instead of 403=20 (Unsuported Header)? > =20 > Thanks, > Jesus. > =20 > =20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 > > =20 > =20 =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 Jun 02 12:43:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsnC-0001ms-B6; Thu, 02 Jun 2005 12:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsnA-0001mk-BU for speechsc@megatron.ietf.org; Thu, 02 Jun 2005 12:43:36 -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 MAA05925 for ; Thu, 2 Jun 2005 12:43:33 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddt7B-0008O1-Ve for speechsc@ietf.org; Thu, 02 Jun 2005 13:04:20 -0400 Received: from daburkewxp (unknown [10.0.0.168]) by mail.voxpilot.com (Postfix) with ESMTP id A3D312140FE for ; Thu, 2 Jun 2005 16:43:25 +0000 (GMT) Message-ID: <02bc01c56792$32645710$a800000a@db01.voxpilot.com> From: "Dave Burke" To: Date: Thu, 2 Jun 2005 17:43:25 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Speechsc] Control sessions without media sessions 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="===============1265009494==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1265009494== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B9_01C5679A.940BC130" This is a multi-part message in MIME format. ------=_NextPart_000_02B9_01C5679A.940BC130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, In section 4.3, we say: If there are more than 1 audio m-line, then each audio=20 m-line MUST have a "mid" attribute. Each control m-line MUST have a=20 "cmid" attribute that matches the "mid" attribute of the audio m- line it is associated with.=20 Should there be an "and" linking both sentences since I might want to = set up a control channel without a media session for doing INTERPRETs or = even DEFINE-GRAMMARs? Am curious as to why the channel identifier is not instead a "media = session identifier" and associated with the m=3Daudio line. This way, = control messages could explicitly apply to specific media pipe(s) via a = Media-Identifier header (which would be in place of Channel-Identifier = header). Not relevant for MRCP but is for say conference control where = the non-static 1-to-many relationship is useful. -- Dave ------=_NextPart_000_02B9_01C5679A.940BC130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
In section 4.3, we say:
 
If there are more than 1 audio m-line, = then each=20 audio 
m-line MUST have a "mid" attribute. Each control m-line = MUST have=20 a 
"cmid" attribute that matches the "mid" attribute of the = audio=20 m-
line it is associated with.
 
Should there be an "and" linking both = sentences=20 since I might want to set up a control channel without a media session = for doing=20 INTERPRETs or even DEFINE-GRAMMARs?
 
Am curious as to why the channel = identifier is not=20 instead a "media session identifier" and associated with the = m=3Daudio line.=20 This way, control messages could explicitly apply to specific media = pipe(s) via=20 a Media-Identifier header (which would be in place of = Channel-Identifier=20 header). Not relevant for MRCP but is for say conference control where = the=20 non-static 1-to-many relationship is useful.
 
-- Dave
 
------=_NextPart_000_02B9_01C5679A.940BC130-- --===============1265009494== 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 --===============1265009494==-- From speechsc-bounces@ietf.org Thu Jun 02 12:55:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddsz6-0000Ah-C0; Thu, 02 Jun 2005 12:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddsz4-0000AY-F9 for speechsc@megatron.ietf.org; Thu, 02 Jun 2005 12:55:54 -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 MAA06729 for ; Thu, 2 Jun 2005 12:55:51 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdtJ8-0000XL-2e for speechsc@ietf.org; Thu, 02 Jun 2005 13:16:38 -0400 Received: from daburkewxp (unknown [10.0.0.168]) by mail.voxpilot.com (Postfix) with ESMTP id 84266214041 for ; Thu, 2 Jun 2005 16:55:52 +0000 (GMT) Message-ID: <030c01c56793$ef946360$a800000a@db01.voxpilot.com> From: "Dave Burke" To: References: <02bc01c56792$32645710$a800000a@db01.voxpilot.com> Subject: Re: [Speechsc] Control sessions without media sessions Date: Thu, 2 Jun 2005 17:55:52 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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="===============0159031681==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0159031681== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0309_01C5679C.514C9660" This is a multi-part message in MIME format. ------=_NextPart_000_0309_01C5679C.514C9660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Think I've just answered my curiousity: The Channel-Identifier allows a = server-side resource to be reserved at session establishment time. Still looking for feedback on my first question (that is from other than = from myself!). - Dave ----- Original Message -----=20 From: Dave Burke=20 To: speechsc@ietf.org=20 Sent: Thursday, June 02, 2005 5:43 PM Subject: [Speechsc] Control sessions without media sessions Hello, In section 4.3, we say: If there are more than 1 audio m-line, then each audio=20 m-line MUST have a "mid" attribute. Each control m-line MUST have a=20 "cmid" attribute that matches the "mid" attribute of the audio m- line it is associated with.=20 Should there be an "and" linking both sentences since I might want to = set up a control channel without a media session for doing INTERPRETs or = even DEFINE-GRAMMARs? Am curious as to why the channel identifier is not instead a "media = session identifier" and associated with the m=3Daudio line. This way, = control messages could explicitly apply to specific media pipe(s) via a = Media-Identifier header (which would be in place of Channel-Identifier = header). Not relevant for MRCP but is for say conference control where = the non-static 1-to-many relationship is useful. -- Dave -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0309_01C5679C.514C9660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Think I've just answered my = curiousity: The=20 Channel-Identifier allows a server-side resource to be reserved at = session=20 establishment time.
 
Still looking for feedback on my first=20 question (that is from other than from myself!).
 
- Dave
 
----- Original Message -----
From:=20 Dave=20 Burke
Sent: Thursday, June 02, 2005 = 5:43=20 PM
Subject: [Speechsc] Control = sessions=20 without media sessions

Hello,
 
In section 4.3, we say:
 
If there are more than 1 audio = m-line, then each=20 audio 
m-line MUST have a "mid" attribute. Each control m-line = MUST=20 have a 
"cmid" attribute that matches the "mid" attribute of = the audio=20 m-
line it is associated with.
 
Should there be an "and" linking both = sentences=20 since I might want to set up a control channel without a media session = for=20 doing INTERPRETs or even DEFINE-GRAMMARs?
 
Am curious as to why the channel = identifier is=20 not instead a "media session identifier" and associated with the = m=3Daudio=20 line. This way, control messages could explicitly apply to specific = media=20 pipe(s) via a Media-Identifier header (which would be in place of = Channel-Identifier header). Not relevant for MRCP but is for say = conference=20 control where the non-static 1-to-many relationship is = useful.
 
-- Dave
 

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0309_01C5679C.514C9660-- --===============0159031681== 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 --===============0159031681==-- From speechsc-bounces@ietf.org Thu Jun 02 14:29:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DduRz-0007PG-6B; Thu, 02 Jun 2005 14:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DduRy-0007PB-BD for speechsc@megatron.ietf.org; Thu, 02 Jun 2005 14:29:50 -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 OAA13727 for ; Thu, 2 Jun 2005 14:29:48 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddum2-0004nW-8w for speechsc@ietf.org; Thu, 02 Jun 2005 14:50:35 -0400 Received: from daburkewxp (unknown [10.0.0.168]) by mail.voxpilot.com (Postfix) with ESMTP id 81B41214041; Thu, 2 Jun 2005 18:29:44 +0000 (GMT) Message-ID: <044601c567a1$0cae1ce0$a800000a@db01.voxpilot.com> From: "Dave Burke" To: "Dave Burke" , References: <02bc01c56792$32645710$a800000a@db01.voxpilot.com> <030c01c56793$ef946360$a800000a@db01.voxpilot.com> Subject: Re: [Speechsc] Control sessions without media sessions Date: Thu, 2 Jun 2005 19:29:44 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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="===============0180044273==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0180044273== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0443_01C567A9.6E50CC10" This is a multi-part message in MIME format. ------=_NextPart_000_0443_01C567A9.6E50CC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A related point: The cmid mechanism only allows a 1:1 control:media relationship. = However, I might easily want to extend my speechsynth resource to handle = 3gp files with audio and video. In that case I want a 1:2 relationship = but I can't do that currently because the cmid must match one mid and = each mid is unique within the SDP.=20 A more flexible solution might be to go with RFC3388 (i.e. have a=3Dmid = for the control channel and use a=3Dgroup:MRCP) -- Dave ----- Original Message -----=20 From: Dave Burke=20 To: speechsc@ietf.org=20 Sent: Thursday, June 02, 2005 5:55 PM Subject: Re: [Speechsc] Control sessions without media sessions Think I've just answered my curiousity: The Channel-Identifier allows = a server-side resource to be reserved at session establishment time. Still looking for feedback on my first question (that is from other = than from myself!). - Dave ----- Original Message -----=20 From: Dave Burke=20 To: speechsc@ietf.org=20 Sent: Thursday, June 02, 2005 5:43 PM Subject: [Speechsc] Control sessions without media sessions Hello, In section 4.3, we say: If there are more than 1 audio m-line, then each audio=20 m-line MUST have a "mid" attribute. Each control m-line MUST have a=20 "cmid" attribute that matches the "mid" attribute of the audio m- line it is associated with.=20 Should there be an "and" linking both sentences since I might want = to set up a control channel without a media session for doing INTERPRETs = or even DEFINE-GRAMMARs? Am curious as to why the channel identifier is not instead a "media = session identifier" and associated with the m=3Daudio line. This way, = control messages could explicitly apply to specific media pipe(s) via a = Media-Identifier header (which would be in place of Channel-Identifier = header). Not relevant for MRCP but is for say conference control where = the non-static 1-to-many relationship is useful. -- Dave -------------------------------------------------------------------------= --- _______________________________________________ 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 ------=_NextPart_000_0443_01C567A9.6E50CC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A related point:
 
The cmid mechanism only allows a 1:1 = control:media=20 relationship. However, I might easily want to extend my speechsynth = resource to=20 handle 3gp files with audio and video. In that case I want a 1:2 = relationship=20 but I can't do that currently because the cmid must match one mid and = each mid=20 is unique within the SDP.
 
A more flexible solution might be to go = with=20 RFC3388 (i.e. have a=3Dmid for the control channel and use=20 a=3Dgroup:MRCP)
 
-- Dave
----- Original Message -----
From:=20 Dave=20 Burke
Sent: Thursday, June 02, 2005 = 5:55=20 PM
Subject: Re: [Speechsc] Control = sessions=20 without media sessions

Think I've just answered my = curiousity: The=20 Channel-Identifier allows a server-side resource to be reserved at = session=20 establishment time.
 
Still looking for feedback on my = first=20 question (that is from other than from = myself!).
 
- Dave
 
----- Original Message -----
From:=20 Dave Burke
Sent: Thursday, June 02, 2005 = 5:43=20 PM
Subject: [Speechsc] Control = sessions=20 without media sessions

Hello,
 
In section 4.3, we = say:
 
If there are more than 1 audio = m-line, then=20 each audio 
m-line MUST have a "mid" attribute. Each control = m-line=20 MUST have a 
"cmid" attribute that matches the "mid" = attribute of=20 the audio m-
line it is associated with.
 
Should there be an "and" linking = both sentences=20 since I might want to set up a control channel without a media = session for=20 doing INTERPRETs or even DEFINE-GRAMMARs?
 
Am curious as to why the channel = identifier is=20 not instead a "media session identifier" and associated with = the=20 m=3Daudio line. This way, control messages could explicitly apply to = specific=20 media pipe(s) via a Media-Identifier header (which would be in = place of=20 Channel-Identifier header). Not relevant for MRCP but is for say = conference=20 control where the non-static 1-to-many relationship is = useful.
 
-- Dave
 

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0443_01C567A9.6E50CC10-- --===============0180044273== 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 --===============0180044273==-- From speechsc-bounces@ietf.org Thu Jun 02 14:30:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DduSb-0007V0-H7; Thu, 02 Jun 2005 14:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DduSa-0007Uv-6Y for speechsc@megatron.ietf.org; Thu, 02 Jun 2005 14:30:28 -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 OAA13773 for ; Thu, 2 Jun 2005 14:30:26 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddumf-0004ny-4a for speechsc@ietf.org; Thu, 02 Jun 2005 14:51:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 11:30:18 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52IUGlw003465; Thu, 2 Jun 2005 11:30:16 -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 Date: Thu, 2 Jun 2005 11:32:10 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B6AB36F@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: Small anal point on lexicon search header Thread-Index: AcVneVWcq3+hVxb4QcCn0JErOHSFvQAJ4e3w From: "Shanmugham, Saravanan" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: "Eric W. Burger" , "David R. Oran" Subject: [Speechsc] RE: Small anal point on lexicon search header 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 would suggest that we take this question to the alias. This has been a touchy issue before. I have no problems with this change. Any one else have any thoughts on this. Sarvi=20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com]=20 Sent: Thursday, June 02, 2005 6:43 AM To: Shanmugham, Saravanan; Dan Burnett; Eric W. Burger Subject: Small anal point on lexicon search header =20 The text says: =20 "This header is used to specify the list of active Lexicon=20 URIs and the search order among the active lexicons. Note,=20 the lexicons specified within the SSML document still take=20 precedence over the lexicons specified in this header." =20 To be clear, I assume this means that f the SSML says=20 *anything* about lexicons, then the entire header is=20 ignored. There is no merging, concatenation, or other form=20 of merging of the two lists, right? If you think the text=20 is perfectly clear and I'm worrying about nothing, I'll=20 leave as is, otherwise, I'll change the last sentence to: =20 "If the SSML document for the corresponding SPEAK=20 operation contains any lexicon references, those lexicons=20 are used and the lexicons specified in this header are ignored." =20 Let me know, =20 Dave. =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 02 14:39:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdubF-0004tT-Sm; Thu, 02 Jun 2005 14:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdubE-0004rC-8z for speechsc@megatron.ietf.org; Thu, 02 Jun 2005 14:39:24 -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 OAA15396 for ; Thu, 2 Jun 2005 14:39:22 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DduvG-00050Q-4r for speechsc@ietf.org; Thu, 02 Jun 2005 15:00:09 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 11:39:11 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52Id6lw010339 for ; Thu, 2 Jun 2005 11:39:07 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j52IRUfp022184 for ; Thu, 2 Jun 2005 11:27:32 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <53255921-7B29-461A-AF5B-9FC149646200@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "IETF SPEECHSC ((E-mail))" From: "David R. Oran" Date: Thu, 2 Jun 2005 14:38:58 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117736853.979300"; x:"432200"; a:"rsa-sha1"; b:"nofws:958"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"EADwBxP+lApdVcpqOKLeLmtJqDLE0VUYOxNMw78G1D0YDRrvTwSJcVEE94G81uB1AhfpXPkX" "EGfHUbMNQYeZIo6R4G3f1hlM4hmqYtKzexIgzEyeVIInN9L9A6pakulmMpb40EICF0Crzo+oCcl" "5ENKbl87eYHZ5VQCoIBlqzy0="; c:"From: =22David R. Oran=22 "; c:"Subject: Lexicon search order"; c:"Date: Thu, 2 Jun 2005 14:38:58 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [Speechsc] Lexicon search order 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 Your intrepid co-chair has been doing his assigned due-diligence on the mrcpv2 spec in preparation for last call. This is one of a few issues that have come up for which I would like guidance form the WG. The text says the folowing about the lexicon search oder header: "This header is used to specify the list of active Lexicon URIs and the search order among the active lexicons. Note, the lexicons specified within the SSML document still take precedence over the lexicons specified in this header." This implies, at least to me, if the SSML says *anything* about lexicons, then the entire header is ignored. There is no concatenation or other form of merging of the two lists, right? If you think the text is perfectly clear and I'm worrying about nothing, I'll consider leaving it as is. If you agree with my interpretation and can see the ambiguity, I'll change the last sentence to: "If the SSML document for the corresponding SPEAK operation contains any lexicon references, those lexicons are used and the lexicons specified in this header are ignored." If you think something else was intended, speak now or make your case during last call! Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 03 06:46:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De9gx-0003uu-Uq; Fri, 03 Jun 2005 06:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De9gw-0003up-5x for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 06:46:18 -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 GAA14663 for ; Fri, 3 Jun 2005 06:46:15 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeA18-0000MZ-LO for speechsc@ietf.org; Fri, 03 Jun 2005 07:07:11 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Fri, 3 Jun 2005 06:46:05 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" Subject: RE: [Speechsc] Lexicon search order Date: Fri, 3 Jun 2005 06:45:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "IETF SPEECHSC \(\(E-mail\)\)" 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 Dave! I think the text of the latest spec is OK! Even if the SSML document contains lexicon references, the lexicons specified via the MRCP header should *not* be ignored, but the SSML lexicons take precedence. Example: SSML lexicon contains pronunciations for A and C MRCP lexicon contains pronunciations for A and D Case 1: The text to speak does contain C. The TTS engine uses the SSML lexicon. Case 2: The text to speak does contain A. The TTS engine uses the SSML lexicon, although A is in the MRCP lexicon. Case 3: The text to speak does contain D. The TTS engine uses the MRCP lexicon, because D is not found in the SSML lexicon. Case 4: The text to speak does contain B. The TTS engine uses is language dependent internal "lexicon", because B is neither found in the SSML lexicon nor in the MRCP lexicon. Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Donnerstag, 2. Juni 2005 20:39 To: IETF SPEECHSC ((E-mail)) Subject: [Speechsc] Lexicon search order Your intrepid co-chair has been doing his assigned due-diligence on the mrcpv2 spec in preparation for last call. This is one of a few issues that have come up for which I would like guidance form the WG. The text says the folowing about the lexicon search oder header: "This header is used to specify the list of active Lexicon URIs and the search order among the active lexicons. Note, the lexicons specified within the SSML document still take precedence over the lexicons specified in this header." This implies, at least to me, if the SSML says *anything* about lexicons, then the entire header is ignored. There is no concatenation or other form of merging of the two lists, right? If you think the text is perfectly clear and I'm worrying about nothing, I'll consider leaving it as is. If you agree with my interpretation and can see the ambiguity, I'll change the last sentence to: "If the SSML document for the corresponding SPEAK operation contains any lexicon references, those lexicons are used and the lexicons specified in this header are ignored." If you think something else was intended, speak now or make your case during last call! Dave. _______________________________________________ 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 Jun 03 06:51:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De9m3-00058y-HQ; Fri, 03 Jun 2005 06:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De9m2-00058t-HH for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 06:51: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 GAA14850 for ; Fri, 3 Jun 2005 06:51:32 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeA6G-0000RI-3B for speechsc@ietf.org; Fri, 03 Jun 2005 07:12:28 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Fri, 3 Jun 2005 06:51:25 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'oran@cisco.com'" Subject: FW: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-06.txt Date: Fri, 3 Jun 2005 06:51:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C56829.A3F334E0" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 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_000_01C56829.A3F334E0 Content-Type: text/plain Hi Dave, where can I find the new version of the requirements spec? The link seems to be wrong. Thanks, Klaus -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Montag, 9. Mai 2005 21:55 To: i-d-announce@ietf.org Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : Requirements for Distributed Control of ASR, SI/SV and TTS Resources Author(s) : D. Oran Filename : draft-ietf-speechsc-reqts-06.txt Pages : 18 Date : 2005-5-9 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to- speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-reqts-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-reqts-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C56829.A3F334E0 Content-Type: message/rfc822 To: Subject: Date: Fri, 20 May 2005 07:38:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C56829.A3F334E0" ------_=_NextPart_002_01C56829.A3F334E0 Content-Type: text/plain ------_=_NextPart_002_01C56829.A3F334E0 Content-Type: application/octet-stream; name="ATT28584" Content-Disposition: attachment; filename="ATT28584" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-9160040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-reqts-06.txt ------_=_NextPart_002_01C56829.A3F334E0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-speechsc-reqts-06.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C56829.A3F334E0-- ------_=_NextPart_000_01C56829.A3F334E0 Content-Type: text/plain; name="ATT285850.txt" Content-Disposition: attachment; filename="ATT285850.txt" _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_000_01C56829.A3F334E0 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 ------_=_NextPart_000_01C56829.A3F334E0-- From speechsc-bounces@ietf.org Fri Jun 03 07:41:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeAYe-0001Q4-Da; Fri, 03 Jun 2005 07:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeAYd-0001Pw-3B for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 07:41:47 -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 HAA18422 for ; Fri, 3 Jun 2005 07:41:46 -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 1DeAsq-0001X1-TS for speechsc@ietf.org; Fri, 03 Jun 2005 08:02:41 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 Jun 2005 04:41:37 -0700 X-IronPort-AV: i="3.93,165,1115017200"; d="scan'208"; a="273752847:sNHT48702894" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j53BfZlq017820; Fri, 3 Jun 2005 04:41:35 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j53BTuW2027503; Fri, 3 Jun 2005 04:29:56 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2034E57E-2D29-4794-A652-72B3A73FDB80@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Lexicon search order Date: Fri, 3 Jun 2005 07:41:31 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117798197.125592"; x:"432200"; a:"rsa-sha1"; b:"nofws:2147"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"XTixucag7VZM/kiOV/SFfbqz2bn4W6NAKTX/tPS/ebJ2ylvuKMW7UtY2tzbst7X+DY9j7r8A" "Jp2D+1I0gjVSdIzPUF3Icq4xY+9OAkijBBktrwdTXo8SkS3Ilm2Gtg4BV7eB3IAeL60HZfcVOYf" "YkyXACxty71cO8JWVGzVV5yM="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Lexicon search order"; c:"Date: Fri, 3 Jun 2005 07:41:31 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(\(E-mail\)\)" 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 OK, I wasn't aware that it was trivial to construct a total order among overlapping lexicons at the time a request is received. Is it? On Jun 3, 2005, at 6:45 AM, Reifenrath, Klaus wrote: > Hi Dave! > > I think the text of the latest spec is OK! > > Even if the SSML document contains lexicon references, the lexicons > specified via the MRCP header should *not* be ignored, but the SSML > lexicons > take precedence. > Example: > SSML lexicon contains pronunciations for A and C > MRCP lexicon contains pronunciations for A and D > Case 1: > The text to speak does contain C. The TTS engine uses the SSML > lexicon. > Case 2: > The text to speak does contain A. The TTS engine uses the SSML > lexicon, > although A is in the MRCP lexicon. > Case 3: > The text to speak does contain D. The TTS engine uses the MRCP > lexicon, > because D is not found in the SSML lexicon. > Case 4: > The text to speak does contain B. The TTS engine uses is language > dependent > internal "lexicon", because B is neither found in the SSML lexicon > nor in > the MRCP lexicon. > > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Donnerstag, 2. Juni 2005 20:39 > To: IETF SPEECHSC ((E-mail)) > Subject: [Speechsc] Lexicon search order > > Your intrepid co-chair has been doing his assigned due-diligence on > the > mrcpv2 spec in preparation for last call. This is one of a few > issues that > have come up for which I would like guidance form the WG. > > The text says the folowing about the lexicon search oder header: > > "This header is used to specify the list of active Lexicon > URIs and the search order among the active lexicons. Note, > the lexicons specified within the SSML document still take > precedence over the lexicons specified in this header." > > This implies, at least to me, if the SSML says *anything* about > lexicons, > then the entire header is ignored. There is no concatenation or > other form > of merging of the two lists, right? > > If you think the text is perfectly clear and I'm worrying about > nothing, > I'll consider leaving it as is. > > If you agree with my interpretation and can see the ambiguity, I'll > change > the last sentence to: > > "If the SSML document for the corresponding SPEAK > operation contains any lexicon references, those lexicons > are used and the lexicons specified in this header are ignored." > > If you think something else was intended, speak now or make your > case during > last call! > > Dave. > > _______________________________________________ > 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 Jun 03 07:44:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeAb8-00025q-5s; Fri, 03 Jun 2005 07:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeAb6-00025k-6c for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 07:44:20 -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 HAA18578 for ; Fri, 3 Jun 2005 07:44:19 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeAvJ-0001af-Jc for speechsc@ietf.org; Fri, 03 Jun 2005 08:05:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2005 04:44:10 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j53Bi7lq019627; Fri, 3 Jun 2005 04:44:08 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j53BWSv7027513; Fri, 3 Jun 2005 04:32:29 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-06.txt Date: Fri, 3 Jun 2005 07:44:03 -0400 To: Klaus Reifenrath X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117798349.766535"; x:"432200"; a:"rsa-sha1"; b:"nofws:4549"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"TncX65rdAZgdgDtB6NtC+ToNATmJIB1PmFXbBRDpN69jUTBlh7hA1I4BkpRyaCVFLiOSgxvB" "l5RH4nlqoh0HdK6AQ6hl54K4mlAvWZrGE0MplQlwYreMCWkhDZ8vEnx4zCeYEx53dRV7qW6nFgw" "0tO7d9VPPHyeL7HjvppnfZtg="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-06.txt"; c:"Date: Fri, 3 Jun 2005 07:44:03 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 Hmmm, try http://www.ietf.org/internet-drafts/draft-ietf-speechsc- reqts-07.txt On Jun 3, 2005, at 6:51 AM, Reifenrath, Klaus wrote: > Hi Dave, > > where can I find the new version of the requirements spec? The link > seems to > be wrong. > > Thanks, > Klaus > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Montag, 9. Mai 2005 21:55 > To: i-d-announce@ietf.org > Cc: speechsc@ietf.org > Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Speech Services Control Working > Group of > the IETF. > > Title : Requirements for Distributed Control of ASR, SI/SV > and TTS Resources > Author(s) : D. Oran > Filename : draft-ietf-speechsc-reqts-06.txt > Pages : 18 > Date : 2005-5-9 > > This document outlines the needs and requirements for a protocol to > control distributed speech processing of audio streams. By speech > processing, this document specifically means automatic speech > recognition (ASR), speaker recognition - which includes both > speaker > identification (SI) and speaker verification (SV) - and text-to- > speech (TTS). Other IETF protocols, such as SIP and RTSP, address > rendezvous and control for generalized media streams. However, > speech processing presents additional requirements that none of the > extant IETF protocols address. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging > in, type > "cd internet-drafts" and then > "get draft-ietf-speechsc-reqts-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- > sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speechsc-reqts-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ---------------------------------------------------------------------- > --- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ---------------------------------------------------------------------- > --- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is > prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a > seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this > notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j53GI7rw004318 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > > Date: May 20, 2005 7:38:42 AM EDT > > > > > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 03 10:03:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeCmE-0003rC-W8; Fri, 03 Jun 2005 10:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeCmD-0003r6-FJ for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 10:03:57 -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 KAA00058 for ; Fri, 3 Jun 2005 10:03:55 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeD6R-00055g-Ig for speechsc@ietf.org; Fri, 03 Jun 2005 10:24:52 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2005 07:03:45 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j53E3glq017491 for ; Fri, 3 Jun 2005 07:03:43 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j53Dq3MD028284 for ; Fri, 3 Jun 2005 06:52:04 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <87961EAD-D100-428D-9F40-238E1E1B6E10@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((E-mail))" From: "David R. Oran" Date: Fri, 3 Jun 2005 10:03:38 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117806724.531330"; x:"432200"; a:"rsa-sha1"; b:"nofws:408"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PYuW/gJJbudx2t4SmYHpB9Vt4VG5PigKqvxtP6HyAUMcHS+XF9I8ft0hWOrUctoUsxde88Ar" "wchMEGQubrfg35IgBTv+RpCxNIX98MkNSZBb2t+u4aAgTpClM5ir3xr28Tk4khvZLbc/B2eK0O2" "ciGmQiqniUSONxHZDVHa2h8g="; c:"From: =22David R. Oran=22 "; c:"Subject: sensitivity level header for speech rec"; c:"Date: Fri, 3 Jun 2005 10:03:38 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Speechsc] sensitivity level header for speech rec 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 Why is this a number between 0 and 1? What could these values possibly mean? Does 0 mean total audio suppression? Does 1 mean 0 gain or 0 dbM relative to the reference eve of the signal processor in the recognizer? Is it linear in power or logarithmic? I can't see any way to have an interoperable implementation of this. I'm embarassed I didn't catch this before. If we need such a beast, it really needs to be something like a dB value relative to zero dBm. Is it too late to fix this? I hope not. Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 03 10:16:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeCyo-00083M-Ox; Fri, 03 Jun 2005 10:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeCyn-00083H-9e for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 10:16:57 -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 KAA02162 for ; Fri, 3 Jun 2005 10:16:55 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeDJ1-0005T2-KA for speechsc@ietf.org; Fri, 03 Jun 2005 10:37:52 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2005 07:16:47 -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 j53EGgbw008991 for ; Fri, 3 Jun 2005 07:16:43 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j53E55BH028363 for ; Fri, 3 Jun 2005 07:05:06 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <994BCBD9-5D6F-463D-BA32-98D0A4B8C28E@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((E-mail))" From: "David R. Oran" Date: Fri, 3 Jun 2005 10:16:40 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117807506.776189"; x:"432200"; a:"rsa-sha1"; b:"nofws:1679"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"OAO5ggmnH5Vt4JWTY93k+u6s8vDidhXvbeO7Irt+brmBMhkoTA3/TRyVGf8pW2A+JSbHzOfL" "wOxwLxJUqz3DfQ4g/Xk/MBDYKmeEjDFiqPAR4YCK8rMvflA8qg1S7O397zzYtqUKsRhRjsacLOP" "gWw3hgPEtgOdDsvF7ope3XFA="; c:"From: =22David R. Oran=22 "; c:"Subject: Recognizer queueing versus synthesizer queueing"; c:"Date: Fri, 3 Jun 2005 10:16:40 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Recognizer queueing versus synthesizer queueing 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 For some reason that escapes me these work completely differently. The reasons may be historical, or possibly because we thought queueing of requests processing media input were different from requests processing media output. To refresh memory, SPEAK requests are queued when the client issues one while a current SPEAK is active. If the current request is canceled for any reason (stop, cancel-on-barge-in, etc.) the pending SPEAK requests are nuked, and the completion response for the cancelled SPEAK contains a header with the request id's of the other requests in the queue that are now history. In RECOGNIZE, there is a header (cancel-if-queue) saying whether or not to cancel the current request if the client tries to queue another one. If a request is cancelled, the pending requests are also canceled but each returns a separate completion event. For some reason this header is defined as mandatory rather than having a default value. It seems at a minimum inelegant, to have this disparate machinery, and quite possibly a pain for servers which have a single scheduler implementation for their different resources to have to implement two entirely different schemes, not to mention clients which really should be simple and not have to worry about this kind of inconsistency. If it's too late to change this, I suppose we can live with it. If the WG will entertain a technical change, let me suggest that the other resources adopt the scheduling scheme used by SPEAK, since it's simpler, fully general, and well-described in the spec (the recognize scheme has some pretty tortured language to explain what's supposed to happen). If we do this, the cancel-on-queue header goes away and the active-request-ids header gets adopted by the other resources. I'd probably move the material on request queueing to the common protocol section if we go this route, rather than repeating all the stuff in each resource. Please respond with views, because I don't want to adopt such a change lightly. Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 03 11:27:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeE5B-0006g6-ME; Fri, 03 Jun 2005 11:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeE59-0006fq-Aw for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 11:27:35 -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 LAA07788 for ; Fri, 3 Jun 2005 11:27:32 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeEPO-0006u7-Kx for speechsc@ietf.org; Fri, 03 Jun 2005 11:48:31 -0400 Received: from daburkewxp (unknown [10.0.0.168]) by mail.voxpilot.com (Postfix) with ESMTP id AC40C2140F6; Fri, 3 Jun 2005 15:27:29 +0000 (GMT) Message-ID: <05b501c56850$c14bf460$a800000a@db01.voxpilot.com> From: "Dave Burke" To: , "David R. Oran" References: <994BCBD9-5D6F-463D-BA32-98D0A4B8C28E@cisco.com> Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queueing Date: Fri, 3 Jun 2005 16:27:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org It's probably worth pointing out that SPEAK and RECOGNIZE are not really anti-symmetric since (a) RECOGNIZE requests typically require the audio input to be synchronised with the recognition request and (b) subsequent recognition actions normally depend on the results of previous recognition action(s). I don't think queuing of RECOGNIZE requests is useful and by removing it altogether we also get consistency with RECORD. Dave ----- Original Message ----- From: "David R. Oran" To: Sent: Friday, June 03, 2005 3:16 PM Subject: [Speechsc] Recognizer queueing versus synthesizer queueing > For some reason that escapes me these work completely differently. > > The reasons may be historical, or possibly because we thought queueing of > requests processing media input were different from requests processing > media output. > > To refresh memory, SPEAK requests are queued when the client issues one > while a current SPEAK is active. If the current request is canceled for > any reason (stop, cancel-on-barge-in, etc.) the pending SPEAK requests > are nuked, and the completion response for the cancelled SPEAK contains a > header with the request id's of the other requests in the queue that are > now history. > > In RECOGNIZE, there is a header (cancel-if-queue) saying whether or not > to cancel the current request if the client tries to queue another one. > If a request is cancelled, the pending requests are also canceled but > each returns a separate completion event. For some reason this header is > defined as mandatory rather than having a default value. > > It seems at a minimum inelegant, to have this disparate machinery, and > quite possibly a pain for servers which have a single scheduler > implementation for their different resources to have to implement two > entirely different schemes, not to mention clients which really should be > simple and not have to worry about this kind of inconsistency. > > If it's too late to change this, I suppose we can live with it. > > If the WG will entertain a technical change, let me suggest that the > other resources adopt the scheduling scheme used by SPEAK, since it's > simpler, fully general, and well-described in the spec (the recognize > scheme has some pretty tortured language to explain what's supposed to > happen). If we do this, the cancel-on-queue header goes away and the > active-request-ids header gets adopted by the other resources. > > I'd probably move the material on request queueing to the common protocol > section if we go this route, rather than repeating all the stuff in each > resource. > > Please respond with views, because I don't want to adopt such a change > lightly. > > Dave. > > _______________________________________________ > 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 Jun 03 11:45:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeEMt-0001ye-BP; Fri, 03 Jun 2005 11:45:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeEMr-0001yZ-Ss for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 11:45:53 -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 LAA09282 for ; Fri, 3 Jun 2005 11:45:51 -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 1DeEh5-0007HD-Vp for speechsc@ietf.org; Fri, 03 Jun 2005 12:06:50 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Jun 2005 08:45:42 -0700 X-IronPort-AV: i="3.93,166,1115017200"; d="scan'208"; a="273867983:sNHT1818615712" 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 j53Fjcbw006850; Fri, 3 Jun 2005 08:45:39 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j53FXxkM029009; Fri, 3 Jun 2005 08:33:59 -0700 In-Reply-To: <05b501c56850$c14bf460$a800000a@db01.voxpilot.com> References: <994BCBD9-5D6F-463D-BA32-98D0A4B8C28E@cisco.com> <05b501c56850$c14bf460$a800000a@db01.voxpilot.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D9D5F58-D216-47A0-8274-05D7F4FEC0CF@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queueing Date: Fri, 3 Jun 2005 11:45:35 -0400 To: Dave Burke X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117812840.228137"; x:"432200"; a:"rsa-sha1"; b:"nofws:2649"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"jWIFBAaMJDOvMxHIqx89jyuM3eRR9gcM78tWugMm7gbcU01dlhYYWhDTUUdKc6lwbaHUk1vr" "WC19JMvNl5SM3bGSlPUgfheOD6S/9+KQxVP8j9TiB8cd4kw8ULAWVGxa6TOJRGuGwXGjEQhT+nr" "V55/HmscpKsj8WSI703+7A5M="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queue" "ing"; c:"Date: Fri, 3 Jun 2005 11:45:35 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 On Jun 3, 2005, at 11:27 AM, Dave Burke wrote: > It's probably worth pointing out that SPEAK and RECOGNIZE are not > really anti-symmetric since (a) RECOGNIZE requests typically > require the audio input to be synchronised with the recognition > request and (b) subsequent recognition actions normally depend on > the results of previous recognition action(s). > > I don't think queuing of RECOGNIZE requests is useful and by > removing it altogether we also get consistency with RECORD. > That works for me. The current machinery for recognize queueing is, well, peculiar, and if we don't need it I'd just as soon get rid of it. Let's see how others feel first. Dave. > Dave > > ----- Original Message ----- From: "David R. Oran" > To: > Sent: Friday, June 03, 2005 3:16 PM > Subject: [Speechsc] Recognizer queueing versus synthesizer queueing > > > >> For some reason that escapes me these work completely differently. >> >> The reasons may be historical, or possibly because we thought >> queueing of requests processing media input were different from >> requests processing media output. >> >> To refresh memory, SPEAK requests are queued when the client >> issues one while a current SPEAK is active. If the current >> request is canceled for any reason (stop, cancel-on-barge-in, >> etc.) the pending SPEAK requests are nuked, and the completion >> response for the cancelled SPEAK contains a header with the >> request id's of the other requests in the queue that are now >> history. >> >> In RECOGNIZE, there is a header (cancel-if-queue) saying whether >> or not to cancel the current request if the client tries to >> queue another one. If a request is cancelled, the pending >> requests are also canceled but each returns a separate completion >> event. For some reason this header is defined as mandatory rather >> than having a default value. >> >> It seems at a minimum inelegant, to have this disparate >> machinery, and quite possibly a pain for servers which have a >> single scheduler implementation for their different resources to >> have to implement two entirely different schemes, not to mention >> clients which really should be simple and not have to worry about >> this kind of inconsistency. >> >> If it's too late to change this, I suppose we can live with it. >> >> If the WG will entertain a technical change, let me suggest that >> the other resources adopt the scheduling scheme used by SPEAK, >> since it's simpler, fully general, and well-described in the spec >> (the recognize scheme has some pretty tortured language to explain >> what's supposed to happen). If we do this, the cancel-on-queue >> header goes away and the active-request-ids header gets adopted >> by the other resources. >> >> I'd probably move the material on request queueing to the common >> protocol section if we go this route, rather than repeating all >> the stuff in each resource. >> >> Please respond with views, because I don't want to adopt such a >> change lightly. >> >> Dave. >> >> _______________________________________________ >> 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 Jun 03 11:53:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeEUF-0003jG-3M; Fri, 03 Jun 2005 11:53:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeEUE-0003jA-69 for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 11:53:30 -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 LAA09632 for ; Fri, 3 Jun 2005 11:53:27 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeEoT-0007Pq-Eu for speechsc@ietf.org; Fri, 03 Jun 2005 12:14:26 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Fri, 3 Jun 2005 11:53:15 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" Subject: RE: [Speechsc] sensitivity level header for speech rec Date: Fri, 3 Jun 2005 11:53:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "speechsc@ietf.org \(\(E-mail\)\)" 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 Dave, we can reference the VoiceXML spec for sensitivity, right? Here is how it is defined in VoiceXML 2.0 (http://www.w3.org/TR/voicexml20/#dml6.3.2): Set the sensitivity level. A value of 1.0 means that it is highly sensitive to quiet input. A value of 0.0 means it is least sensitive to noise. The value is a Real Number Designation (see Section 6.5). The default value is 0.5. BTW: There are many other header fields where a reference to the VoiceXML spec would be helpful from my point of view! Regards, Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Freitag, 3. Juni 2005 16:04 To: speechsc@ietf.org ((E-mail)) Subject: [Speechsc] sensitivity level header for speech rec Why is this a number between 0 and 1? What could these values possibly mean? Does 0 mean total audio suppression? Does 1 mean 0 gain or 0 dbM relative to the reference eve of the signal processor in the recognizer? Is it linear in power or logarithmic? I can't see any way to have an interoperable implementation of this. I'm embarassed I didn't catch this before. If we need such a beast, it really needs to be something like a dB value relative to zero dBm. Is it too late to fix this? I hope not. Dave. _______________________________________________ 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 Jun 03 12:45:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFJ0-0006Cb-N6; Fri, 03 Jun 2005 12:45:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFIz-0006CW-BT for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 12:45:57 -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 MAA13571 for ; Fri, 3 Jun 2005 12:45:54 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeFdE-0000AZ-1s for speechsc@ietf.org; Fri, 03 Jun 2005 13:06:54 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Fri, 3 Jun 2005 12:45:46 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , Dave Burke Subject: RE: [Speechsc] Recognizer queueing versus synthesizer queueing Date: Fri, 3 Jun 2005 12:45:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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, I need to think about it. The use-case was a hotword recognition followed by a normal recognition without loosing any audio data between these recognitions. Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Freitag, 3. Juni 2005 17:46 To: Dave Burke Cc: speechsc@ietf.org Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queueing On Jun 3, 2005, at 11:27 AM, Dave Burke wrote: > It's probably worth pointing out that SPEAK and RECOGNIZE are not > really anti-symmetric since (a) RECOGNIZE requests typically require > the audio input to be synchronised with the recognition request and > (b) subsequent recognition actions normally depend on the results of > previous recognition action(s). > > I don't think queuing of RECOGNIZE requests is useful and by removing > it altogether we also get consistency with RECORD. > That works for me. The current machinery for recognize queueing is, well, peculiar, and if we don't need it I'd just as soon get rid of it. Let's see how others feel first. Dave. > Dave > > ----- Original Message ----- From: "David R. Oran" > To: > Sent: Friday, June 03, 2005 3:16 PM > Subject: [Speechsc] Recognizer queueing versus synthesizer queueing > > > >> For some reason that escapes me these work completely differently. >> >> The reasons may be historical, or possibly because we thought >> queueing of requests processing media input were different from >> requests processing media output. >> >> To refresh memory, SPEAK requests are queued when the client issues >> one while a current SPEAK is active. If the current request is >> canceled for any reason (stop, cancel-on-barge-in, >> etc.) the pending SPEAK requests are nuked, and the completion >> response for the cancelled SPEAK contains a header with the request >> id's of the other requests in the queue that are now history. >> >> In RECOGNIZE, there is a header (cancel-if-queue) saying whether or >> not to cancel the current request if the client tries to queue >> another one. If a request is cancelled, the pending requests are also >> canceled but each returns a separate completion event. For some >> reason this header is defined as mandatory rather than having a >> default value. >> >> It seems at a minimum inelegant, to have this disparate machinery, >> and quite possibly a pain for servers which have a single scheduler >> implementation for their different resources to have to implement two >> entirely different schemes, not to mention clients which really >> should be simple and not have to worry about this kind of >> inconsistency. >> >> If it's too late to change this, I suppose we can live with it. >> >> If the WG will entertain a technical change, let me suggest that the >> other resources adopt the scheduling scheme used by SPEAK, since it's >> simpler, fully general, and well-described in the spec (the recognize >> scheme has some pretty tortured language to explain what's supposed >> to happen). If we do this, the cancel-on-queue header goes away and >> the active-request-ids header gets adopted by the other resources. >> >> I'd probably move the material on request queueing to the common >> protocol section if we go this route, rather than repeating all the >> stuff in each resource. >> >> Please respond with views, because I don't want to adopt such a >> change lightly. >> >> Dave. >> >> _______________________________________________ >> 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 Fri Jun 03 12:59:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFW0-0000R2-2A; Fri, 03 Jun 2005 12:59:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFVy-0000Qs-DU for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 12:59: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 MAA14513 for ; Fri, 3 Jun 2005 12:59:19 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeFqE-0000SZ-6V for speechsc@ietf.org; Fri, 03 Jun 2005 13:20:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2005 09:59:12 -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 j53Gx6bw017907; Fri, 3 Jun 2005 09:59:07 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j53GlT93029612; Fri, 3 Jun 2005 09:47:30 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] sensitivity level header for speech rec Date: Fri, 3 Jun 2005 12:59:03 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1117817250.815138"; x:"432200"; a:"rsa-sha1"; b:"nofws:1758"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"k70Sw/hz944xm0sdhXCivss/4KqnssTT89EHswLw2VCw6Y5wH6OZ0Wt3t7CnBazKqHT7uXV8" "/qku6tzpnRCIB5NAyUMZlj9VGzN4pwKuaT+mVMS/YVv/zdL5EMqaNjzuGfnfvAL+PScdAgpH8V7" "3gOLP76toMW22d6kXbzoV6ZE="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] sensitivity level header for speech rec"; c:"Date: Fri, 3 Jun 2005 12:59:03 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: "speechsc@ietf.org \(\(E-mail\)\)" 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 On Jun 3, 2005, at 11:53 AM, Reifenrath, Klaus wrote: > Hi Dave, > > we can reference the VoiceXML spec for sensitivity, right? Sure we can. Copying an existing standard flat tire is a definite improvement over inventing our own. I thought those VXML guys knew something about audio. Or were they trying to "shield the application programmer from having to know what they're doing"? Sheesh, that's like specifying a car design schema without telling the designer that velocity is in meters per second and that you specify the speed range for the car in terms of 0=slow, 1=fast. Sheesh. Dave. > Here is how it is > defined in VoiceXML 2.0 (http://www.w3.org/TR/voicexml20/#dml6.3.2): > Set the sensitivity level. A value of 1.0 means that it is highly > sensitive > to quiet input. A value of 0.0 means it is least sensitive to > noise. The > value is a Real Number Designation (see Section 6.5). The default > value is > 0.5. > > > BTW: There are many other header fields where a reference to the > VoiceXML > spec would be helpful from my point of view! > > Regards, > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Freitag, 3. Juni 2005 16:04 > To: speechsc@ietf.org ((E-mail)) > Subject: [Speechsc] sensitivity level header for speech rec > > Why is this a number between 0 and 1? What could these values > possibly mean? > Does 0 mean total audio suppression? Does 1 mean 0 gain or 0 dbM > relative to > the reference eve of the signal processor in the recognizer? > > Is it linear in power or logarithmic? > > I can't see any way to have an interoperable implementation of this. > I'm embarassed I didn't catch this before. > > If we need such a beast, it really needs to be something like a dB > value > relative to zero dBm. > > Is it too late to fix this? I hope not. > > Dave. > > _______________________________________________ > 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 Fri Jun 03 13:35:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeG5K-0007Eg-40; Fri, 03 Jun 2005 13:35:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeG5I-0007EW-FA for speechsc@megatron.ietf.org; Fri, 03 Jun 2005 13:35:52 -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 NAA17372 for ; Fri, 3 Jun 2005 13:35:51 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeGPZ-0001KH-6R for speechsc@ietf.org; Fri, 03 Jun 2005 13:56:49 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2005 10:35:51 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j53HZmlw002780; Fri, 3 Jun 2005 10:35:49 -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] Recognizer queueing versus synthesizer queueing Date: Fri, 3 Jun 2005 10:37:44 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B6AB812@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Recognizer queueing versus synthesizer queueing Thread-Index: AcVoU+LVVlfyTSTXTTqRLLW74HwOSQACXBWA From: "Shanmugham, Saravanan" To: "David R. Oran" , "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 In general some of these mechanims, like Canel-If-Queue are there to make life easy.=20 But I agree that these can be streamlined a little more.=20 Like I mentioned, in a previous mail, some of the convoluted wording was because the current text was derived from proposed extensions to MRCPv1 and hence was attempting to maintain some backward compatibility. That is not requirment any more and so that can be simplified.=20 Here is my proposal.=20 Synthesizer 1. We leave SPEAK queing mechanism as is.=20 2. We leave the behaviour of STOP as defined for the speech synthesizer. 3. We add that if a SPEAK request fails due to an error, any currently queued SPEAK/RECOGNIZE requests behind the failed one should also be removed from the queue. Here just as in the case of barge-in, the SPEAK-COMPLETE/RECOGNITON-COMPLETE event for the failed SPEAK/RECOGNIZE request MUST contain the request-id of the failed request followed by the list of queued/pending request-ids that were terminted because of the failure. 4. We could generalize the Cancel-If-Queue header proposed for the recongizer to also apply for synthesizer resource with the same behaviour. Default value for "Cancel-If-Queue" header field is "false". Which allows for queing of requests, same as today. 5. We leave the behaviour of BARGE-IN-OCCURRED and its effect on queued requests as is. This operation is unique to synthesizers and has no equivalent in recognition. Recognizer 1. Modify RECOGNIZE to have the same behaviour as synthesizer SPEAK requests. 2. We add text to cover the behaviour of STOP when there are queued RECOGNIZE requests. The behaviour would be the same as for speech. 3. We add that if a RECOGNIZE request fails due to an error, any currently queued RECOGNIZE requests behind the failed one should also be removed from the queue. The RECOGNITON-COMPLETE event for the failed RECOGNIZE request MUST contain the request-id of the failed request followed by the list of queued/pending request-ids that were terminted because of the failure. Default value for "Cancel-If-Queue" header field is "false". Which allows for queing of requests, same as today. 4. Modify Cancel-if-Queue to remove language about what happens to queued SPEAK/RECOGNIZE requests when the active one fails. This has no bearing on the behaviour of this header field and should already have been covered when discussing the queeing behaviour for SPEAK or RECOGNIZE.=20 What do you think. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Friday, June 03, 2005 8:46 AM To: Dave Burke Cc: speechsc@ietf.org Subject: Re: [Speechsc] Recognizer queueing versus=20 synthesizer queueing =20 =20 On Jun 3, 2005, at 11:27 AM, Dave Burke wrote: =20 > It's probably worth pointing out that SPEAK and=20 RECOGNIZE are not=20 > really anti-symmetric since (a) RECOGNIZE requests=20 typically require=20 > the audio input to be synchronised with the recognition=20 request and=20 > (b) subsequent recognition actions normally depend on=20 the results of=20 > previous recognition action(s). > > I don't think queuing of RECOGNIZE requests is useful=20 and by removing=20 > it altogether we also get consistency with RECORD. > That works for me. The current machinery for recognize=20 queueing is, well, peculiar, and if we don't need it I'd=20 just as soon get rid of it. =20 Let's see how others feel first. =20 Dave. =20 > Dave > > ----- Original Message ----- From: "David R. Oran"=20 > To: > Sent: Friday, June 03, 2005 3:16 PM > Subject: [Speechsc] Recognizer queueing versus=20 synthesizer queueing > > > >> For some reason that escapes me these work completely=20 differently. >> >> The reasons may be historical, or possibly because we thought =20 >> queueing of requests processing media input were=20 different from =20 >> requests processing media output. >> >> To refresh memory, SPEAK requests are queued when the=20 client issues =20 >> one while a current SPEAK is active. If the current request is =20 >> canceled for any reason (stop, cancel-on-barge-in, >> etc.) the pending SPEAK requests are nuked, and the completion=20 >> response for the cancelled SPEAK contains a header=20 with the request=20 >> id's of the other requests in the queue that are now history. >> >> In RECOGNIZE, there is a header (cancel-if-queue)=20 saying whether or =20 >> not to cancel the current request if the client tries to queue =20 >> another one. If a request is cancelled, the pending=20 requests are also =20 >> canceled but each returns a separate completion event.=20 For some =20 >> reason this header is defined as mandatory rather than=20 having a =20 >> default value. >> >> It seems at a minimum inelegant, to have this disparate=20 machinery, =20 >> and quite possibly a pain for servers which have a=20 single scheduler=20 >> implementation for their different resources to have to=20 implement two=20 >> entirely different schemes, not to mention clients=20 which really =20 >> should be simple and not have to worry about this kind of=20 >> inconsistency. >> >> If it's too late to change this, I suppose we can live with it. >> >> If the WG will entertain a technical change, let me=20 suggest that the=20 >> other resources adopt the scheduling scheme used by=20 SPEAK, since it's=20 >> simpler, fully general, and well-described in the spec=20 (the recognize=20 >> scheme has some pretty tortured language to explain=20 what's supposed =20 >> to happen). If we do this, the cancel-on-queue header=20 goes away and =20 >> the active-request-ids header gets adopted by the other=20 resources. >> >> I'd probably move the material on request queueing to=20 the common =20 >> protocol section if we go this route, rather than=20 repeating all the =20 >> stuff in each resource. >> >> Please respond with views, because I don't want to=20 adopt such a =20 >> change lightly. >> >> Dave. >> >> _______________________________________________ >> 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 Fri Jun 03 13:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGMo-0002pJ-SW; Fri, 03 Jun 2005 13:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeG0v-0006E0-Ad; Fri, 03 Jun 2005 13:31: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 NAA16743; Fri, 3 Jun 2005 13:31:18 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeGLC-00017K-IE; Fri, 03 Jun 2005 13:52:18 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DeG0s-0005X8-17; Fri, 03 Jun 2005 13:31:18 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 03 Jun 2005 13:31:18 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Fri, 03 Jun 2005 13:53:58 -0400 Cc: speechsc mailing list , Internet Architecture Board , speechsc chair , speechsc chair , RFC Editor Subject: [Speechsc] Document Action: 'Requirements for Distributed Control of ASR, SI/SV and TTS Resources' to Informational RFC 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 IESG has approved the following document: - 'Requirements for Distributed Control of ASR, SI/SV and TTS Resources ' as an Informational RFC This document is the product of the Speech Services Control Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-07.txt Technical Summary This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition - which includes both speaker identification (SI) and speaker verification (SV) - and text-to-speech (TTS). Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. Working Group Summary The SPEECHSC Working Group supported the advancement of the document. Protocol Quality This document was reviewed for the IESG by Jon Peterson. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 03 15:49:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIAp-0008SJ-1m; Fri, 03 Jun 2005 15:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIAn-0008S5-Ld; Fri, 03 Jun 2005 15:49:41 -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 PAA28564; Fri, 3 Jun 2005 15:49:37 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeIV3-0004TF-CV; Fri, 03 Jun 2005 16:10:38 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j53JnSmD558590; Fri, 3 Jun 2005 15:49:28 -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 j53JnS6g150266; Fri, 3 Jun 2005 13:49:28 -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 j53JnRep014294; Fri, 3 Jun 2005 13:49:28 -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 j53JnRgI014284; Fri, 3 Jun 2005 13:49:27 -0600 In-Reply-To: To: "Reifenrath, Klaus" MIME-Version: 1.0 Subject: RE: [Speechsc] Recognizer queueing versus synthesizer queueing X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Fri, 3 Jun 2005 15:49:26 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/03/2005 13:49:27, Serialize complete at 06/03/2005 13:49:27 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: speechsc@ietf.org, "'David R. Oran'" , speechsc-bounces@ietf.org, Dave Burke 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 would agree for the removal of queueing RECOGNIZER requests. What application scenario would require this support? If an application has determined that hotword mode is preferable (due to noisy environment, for example), why would it switch to normal mode and eventually exit due to nomatch? VoiceXML 2.0 has been clarified that in the hotword bargein scenario, a nomatch should not be a collected result after prompts have been played. http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml4.1.5.1 4.1.5.1 Bargein type hotword The prompt will not be stopped until a complete match of an active grammar is detected. Input that does not match a grammar is ignored (note that this even applies during the timeout period); as a consequence, a nomatch event will never be generated in the case of hotword bargein. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Reifenrath, Klaus" Sent by: speechsc-bounces@ietf.org 06/03/2005 12:45 PM To "'David R. Oran'" , Dave Burke cc speechsc@ietf.org Subject RE: [Speechsc] Recognizer queueing versus synthesizer queueing Hi, I need to think about it. The use-case was a hotword recognition followed by a normal recognition without loosing any audio data between these recognitions. Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Freitag, 3. Juni 2005 17:46 To: Dave Burke Cc: speechsc@ietf.org Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queueing On Jun 3, 2005, at 11:27 AM, Dave Burke wrote: > It's probably worth pointing out that SPEAK and RECOGNIZE are not > really anti-symmetric since (a) RECOGNIZE requests typically require > the audio input to be synchronised with the recognition request and > (b) subsequent recognition actions normally depend on the results of > previous recognition action(s). > > I don't think queuing of RECOGNIZE requests is useful and by removing > it altogether we also get consistency with RECORD. > That works for me. The current machinery for recognize queueing is, well, peculiar, and if we don't need it I'd just as soon get rid of it. Let's see how others feel first. Dave. > Dave > > ----- Original Message ----- From: "David R. Oran" > To: > Sent: Friday, June 03, 2005 3:16 PM > Subject: [Speechsc] Recognizer queueing versus synthesizer queueing > > > >> For some reason that escapes me these work completely differently. >> >> The reasons may be historical, or possibly because we thought >> queueing of requests processing media input were different from >> requests processing media output. >> >> To refresh memory, SPEAK requests are queued when the client issues >> one while a current SPEAK is active. If the current request is >> canceled for any reason (stop, cancel-on-barge-in, >> etc.) the pending SPEAK requests are nuked, and the completion >> response for the cancelled SPEAK contains a header with the request >> id's of the other requests in the queue that are now history. >> >> In RECOGNIZE, there is a header (cancel-if-queue) saying whether or >> not to cancel the current request if the client tries to queue >> another one. If a request is cancelled, the pending requests are also >> canceled but each returns a separate completion event. For some >> reason this header is defined as mandatory rather than having a >> default value. >> >> It seems at a minimum inelegant, to have this disparate machinery, >> and quite possibly a pain for servers which have a single scheduler >> implementation for their different resources to have to implement two >> entirely different schemes, not to mention clients which really >> should be simple and not have to worry about this kind of >> inconsistency. >> >> If it's too late to change this, I suppose we can live with it. >> >> If the WG will entertain a technical change, let me suggest that the >> other resources adopt the scheduling scheme used by SPEAK, since it's >> simpler, fully general, and well-described in the spec (the recognize >> scheme has some pretty tortured language to explain what's supposed >> to happen). If we do this, the cancel-on-queue header goes away and >> the active-request-ids header gets adopted by the other resources. >> >> I'd probably move the material on request queueing to the common >> protocol section if we go this route, rather than repeating all the >> stuff in each resource. >> >> Please respond with views, because I don't want to adopt such a >> change lightly. >> >> Dave. >> >> _______________________________________________ >> 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 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 08:15:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfcyM-0008DB-7W; Tue, 07 Jun 2005 08:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfcyL-0008Cy-4R for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 08:14: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 IAA17469 for ; Tue, 7 Jun 2005 08:14:19 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfdJM-0001SE-LO for speechsc@ietf.org; Tue, 07 Jun 2005 08:36:06 -0400 Received: from postcard.nuance.com ([10.3.6.20]:14518) by letter.nuance.com with esmtp id 1Dfcy0-0006yd-ER for speechsc@ietf.org; Tue, 07 Jun 2005 05:14:00 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Jun 2005 08:12:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Jun 2005 08:12:17 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802CFBBDD@mtb1exch01.nuance.com> Thread-Topic: MRCPv2 clarification Thread-Index: AcVrWiX/N8jWqxNnT7KzbIV5HZUQwA== From: "Pierre Forgues" To: "IETF SPEECHSC \(E-mail\)" X-OriginalArrivalTime: 07 Jun 2005 12:12:19.0900 (UTC) FILETIME=[2735E7C0:01C56B5A] X-FromHost: postcard.nuance.com [10.3.6.20]:14518 Lines: 148 X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [Speechsc] MRCPv2 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="===============0102853162==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0102853162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B5A.266388C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B5A.266388C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 9 of the MRCPv2 specification includes the following sentence: "The recognition resource may support recognition in the normal or hotword modes or both." I'm not sure the same recognition resource can support "both" because the state machinery does not allow two concurrent recognition requests to be active, as also stated in section 9.9 "If the resource is in the recognizing state, the RECOGNIZE request MUST respond with a failure status" =20 It is probably safer/simpler to assume hotword recognition will be done by a separate recognition resource. The mention of "both" should then be removed from the spec. =20 Pierre =20 =20 ------_=_NextPart_001_01C56B5A.266388C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Section 9 of the MRCPv2 specification includes the =
following sentence:  “The recognition resource may support =
recognition in the normal or hotword modes or both.” =
 I’m not sure the same recognition resource can support =
“both” because the state machinery does not allow two =
concurrent recognition requests to be active, as also stated in section =
9.9 “If the resource is in the recognizing state, =
the RECOGNIZE request MUST respond with a failure status”

 

It is probably safer/simpler to assume hotword = recognition will be done by a separate recognition resource.  The mention of = “both” should then be removed from the spec.

 

Pierre

 

 

------_=_NextPart_001_01C56B5A.266388C5-- --===============0102853162== 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 --===============0102853162==-- From speechsc-bounces@ietf.org Tue Jun 07 08:29:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfdDH-0002py-Nd; Tue, 07 Jun 2005 08:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfdDG-0002pt-8B for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 08:29:46 -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 IAA18590 for ; Tue, 7 Jun 2005 08:29:44 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfdYI-0001nm-Ce for speechsc@ietf.org; Tue, 07 Jun 2005 08:51:31 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 7 Jun 2005 08:29:20 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Pierre Forgues'" , "IETF SPEECHSC (E-mail)" Subject: RE: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 08:29:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) X-Spam-Score: 0.2 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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="===============0820110468==" 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. --===============0820110468== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B5C.22256DEE" 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_01C56B5C.22256DEE Content-Type: text/plain Hi Pierre, "both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in hotword mode. Regards, Klaus _____ From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification Section 9 of the MRCPv2 specification includes the following sentence: "The recognition resource may support recognition in the normal or hotword modes or both." I'm not sure the same recognition resource can support "both" because the state machinery does not allow two concurrent recognition requests to be active, as also stated in section 9.9 "If the resource is in the recognizing state, the RECOGNIZE request MUST respond with a failure status" It is probably safer/simpler to assume hotword recognition will be done by a separate recognition resource. The mention of "both" should then be removed from the spec. Pierre ------_=_NextPart_001_01C56B5C.22256DEE Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Pierre,
 
"both" does not mean in parallel. But you can = use the same=20 resource to do a "normal" recognition and later use the same resource = to perform=20 a recognition in hotword mode.
 
Regards,
Klaus

From: Pierre Forgues = [mailto:forgues@nuance.com]=20
Sent: Dienstag, 7. Juni 2005 14:12
To: IETF = SPEECHSC=20 (E-mail)
Subject: [Speechsc] MRCPv2 = clarification

Section 9 of the MRCPv2 =
specification includes the following sentence:  "The recognition =
resource may support recognition in the normal or hotword modes or =
both."  I'm not sure the same recognition resource can support =
"both" because the state machinery does not allow two concurrent =
recognition requests to be active, as also stated in section 9.9 =
"If the resource is in the recognizing state, the =
RECOGNIZE request MUST respond with a failure status"

 

It is probably = safer/simpler to=20 assume hotword recognition will be done by a separate recognition = resource.=20  The mention of "both" should then be removed from the=20 spec.

 

Pierre

 

 

------_=_NextPart_001_01C56B5C.22256DEE-- --===============0820110468== 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 --===============0820110468==-- From speechsc-bounces@ietf.org Tue Jun 07 08:41:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfdOu-0004dD-6M; Tue, 07 Jun 2005 08:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfdOt-0004cn-G9 for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 08:41:47 -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 IAA19461 for ; Tue, 7 Jun 2005 08:41:46 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfdjv-00023F-AS for speechsc@ietf.org; Tue, 07 Jun 2005 09:03:33 -0400 Received: from daburkewxp (unknown [10.0.0.140]) by mail.voxpilot.com (Postfix) with ESMTP id 5CA45214041; Tue, 7 Jun 2005 12:41:27 +0000 (GMT) Message-ID: <0b6f01c56b5e$38dde050$a800000a@db01.voxpilot.com> From: "Dave Burke" To: "Reifenrath, Klaus" , "'Pierre Forgues'" , "IETF SPEECHSC (E-mail)" References: Subject: Re: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 13:41:27 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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="===============1028901541==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1028901541== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B6C_01C56B66.9A89DE50" This is a multi-part message in MIME format. ------=_NextPart_000_0B6C_01C56B66.9A89DE50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ... which is what my response was going to be until I read: =20 "or implementations where a=20 single recognition resource does not support both modes, they can be=20 implemented as separate resources and allocated to the same SIP=20 session with different MRCP session identifiers and share the RTP=20 audio feed. " This loosely implies to me that the intent is for parallel hotword and = normal recognition.=20 While MRCP should of course allow you to do this (forking media to = perform simultaneous recognitions), we should probably clarify , to = avoid confusion, that a single speechrecog is not intended to support = both modes concurrently. - Dave ----- Original Message -----=20 From: Reifenrath, Klaus=20 To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail)=20 Sent: Tuesday, June 07, 2005 1:29 PM Subject: RE: [Speechsc] MRCPv2 clarification Hi Pierre, "both" does not mean in parallel. But you can use the same resource to = do a "normal" recognition and later use the same resource to perform a = recognition in hotword mode. Regards, Klaus -------------------------------------------------------------------------= ----- From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification Section 9 of the MRCPv2 specification includes the following sentence: = "The recognition resource may support recognition in the normal or = hotword modes or both." I'm not sure the same recognition resource can = support "both" because the state machinery does not allow two concurrent = recognition requests to be active, as also stated in section 9.9 "If the = resource is in the recognizing state, the RECOGNIZE request MUST respond = with a failure status"=20 It is probably safer/simpler to assume hotword recognition will be = done by a separate recognition resource. The mention of "both" should = then be removed from the spec. =20 Pierre =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0B6C_01C56B66.9A89DE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
... which is what my response was going = to be until=20 I read:
 
   "or implementations where = a=20
   single recognition resource does not support both = modes, they=20 can be
   implemented as separate resources and allocated = to the=20 same SIP
   session with different MRCP session = identifiers and=20 share the RTP
   audio feed. "
 
This loosely implies to me that the = intent is for=20 parallel hotword and normal recognition.
 
While MRCP should of course allow you = to do this=20 (forking media to perform simultaneous recognitions), we should probably = clarify=20 , to avoid confusion, that a single speechrecog is not intended to = support both=20 modes concurrently.
 
- Dave
----- Original Message -----
From:=20 Reifenrath, Klaus =
To: 'Pierre Forgues' ; IETF = SPEECHSC=20 (E-mail)
Sent: Tuesday, June 07, 2005 = 1:29=20 PM
Subject: RE: [Speechsc] MRCPv2=20 clarification

Hi Pierre,
 
"both" does not mean in parallel. But you can = use the=20 same resource to do a "normal" recognition and later use the same = resource to=20 perform a recognition in hotword mode.
 
Regards,
Klaus

From: Pierre Forgues=20 [mailto:forgues@nuance.com]
Sent: Dienstag, 7. Juni 2005=20 14:12
To: IETF SPEECHSC (E-mail)
Subject: = [Speechsc]=20 MRCPv2 clarification

Section 9 of the MRCPv2 =
specification includes the following sentence:  "The recognition =
resource may support recognition in the normal or hotword modes or =
both."  I'm not sure the same recognition resource can support =
"both" because the state machinery does not allow two concurrent =
recognition requests to be active, as also stated in section 9.9 =
"If the resource is in the recognizing state, the =
RECOGNIZE request MUST respond with a failure status"

 

It is probably = safer/simpler to=20 assume hotword recognition will be done by a separate recognition = resource.=20  The mention of "both" should then be removed from the=20 spec.

 

Pierre

 

 

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0B6C_01C56B66.9A89DE50-- --===============1028901541== 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 --===============1028901541==-- From speechsc-bounces@ietf.org Tue Jun 07 10:14:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfep3-0003uI-OV; Tue, 07 Jun 2005 10:12:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfep0-0003uA-SG for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 10:12:52 -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 KAA26199 for ; Tue, 7 Jun 2005 10:12:48 -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 1DffA4-0003sb-Fo for speechsc@ietf.org; Tue, 07 Jun 2005 10:34:37 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 07:12:40 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208,217"; a="275378786:sNHT45158736" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j57ECblq017723; Tue, 7 Jun 2005 07:12:37 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 07:14:40 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B7705FC@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 clarification Thread-Index: AcVrXyKx2qdD5AtxQBy8SUof9LOeNwACqQKQ From: "Shanmugham, Saravanan" To: "Dave Burke" , "Reifenrath, Klaus" , "Pierre Forgues" , "IETF SPEECHSC \(E-mail\)" X-Spam-Score: 0.6 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 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="===============0948218735==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0948218735== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B6B.3E49207E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B6B.3E49207E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This was not not imply parallel recognition. If I remember right this wording was added specifically accomodate some recognition resources that may not be capable of both normal and hot word recognition. Some vendors might have implemented them as 2 separate resources.=20 =20 If you are refering to the statement to return failure when the recognizer is in the RECOGNIZING state, this was also why we have created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an active RECOGNIZE command and go active.=20 Anyway, this text describing queing/cancelling/stopping of requests is being clarified based on Dave's request and I had sent a text proposal to do that. That would streamline this and make it consistent.=20 =20 Sarvi _____ =20 From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 07, 2005 5:41 AM To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification =09 =09 ... which is what my response was going to be until I read: =20 "or implementations where a=20 single recognition resource does not support both modes, they can be=20 implemented as separate resources and allocated to the same SIP=20 session with different MRCP session identifiers and share the RTP=20 audio feed. " =20 This loosely implies to me that the intent is for parallel hotword and normal recognition.=20 =20 While MRCP should of course allow you to do this (forking media to perform simultaneous recognitions), we should probably clarify , to avoid confusion, that a single speechrecog is not intended to support both modes concurrently. =20 - Dave ----- Original Message -----=20 From: Reifenrath, Klaus =20 To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) =20 Sent: Tuesday, June 07, 2005 1:29 PM Subject: RE: [Speechsc] MRCPv2 clarification Hi Pierre, =20 "both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in hotword mode. =20 Regards, Klaus _____ =20 From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification =09 =09 Section 9 of the MRCPv2 specification includes the following sentence: "The recognition resource may support recognition in the normal or hotword modes or both." I'm not sure the same recognition resource can support "both" because the state machinery does not allow two concurrent recognition requests to be active, as also stated in section 9.9 "If the resource is in the recognizing state, the RECOGNIZE request MUST respond with a failure status" =20 It is probably safer/simpler to assume hotword recognition will be done by a separate recognition resource. The mention of "both" should then be removed from the spec. =20 Pierre =20 =20 =09 _____ =20 =09 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =09 ------_=_NextPart_001_01C56B6B.3E49207E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This was not not imply parallel recognition. = If I=20 remember right this wording was added specifically accomodate some = recognition=20 resources that may not be capable of both normal and hot word = recognition. Some=20 vendors might have implemented them as 2 separate resources.=20
 
If you are refering to the statement to = return failure=20 when the recognizer is in the RECOGNIZING state, this  was also why = we have=20 created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an = active=20 RECOGNIZE command and go active. 
Anyway, this text describing = queing/cancelling/stopping=20 of requests is being clarified based on Dave's request and I had sent=20 a text proposal to do that. That would streamline this = and make it=20 consistent. 
 
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Tuesday, June 07, 2005 5:41 AM
To: = Reifenrath,=20 Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail)
Subject: Re: = [Speechsc] MRCPv2 clarification

... which is what my response was = going to be=20 until I read:
 
   "or implementations = where a=20
   single recognition resource does not support both = modes, they=20 can be
   implemented as separate resources and = allocated to the=20 same SIP
   session with different MRCP session = identifiers and=20 share the RTP
   audio feed. "
 
This loosely implies to me that the = intent is for=20 parallel hotword and normal recognition.
 
While MRCP should of course allow you = to do this=20 (forking media to perform simultaneous recognitions), we should = probably=20 clarify , to avoid confusion, that a single speechrecog is not = intended to=20 support both modes concurrently.
 
- Dave
----- Original Message -----
From:=20 Reifenrath, Klaus =
To: 'Pierre Forgues' ; IETF = SPEECHSC=20 (E-mail)
Sent: Tuesday, June 07, 2005 = 1:29=20 PM
Subject: RE: [Speechsc] = MRCPv2=20 clarification

Hi Pierre,
 
"both" does not mean in parallel. But you = can use the=20 same resource to do a "normal" recognition and later use the same = resource=20 to perform a recognition in hotword mode.
 
Regards,
Klaus

From: Pierre Forgues=20 [mailto:forgues@nuance.com]
Sent: Dienstag, 7. Juni 2005=20 14:12
To: IETF SPEECHSC (E-mail)
Subject: = [Speechsc]=20 MRCPv2 clarification

Section 9 of the MRCPv2 =
specification includes the following sentence:  "The recognition =
resource may support recognition in the normal or hotword modes or =
both."  I'm not sure the same recognition resource can support =
"both" because the state machinery does not allow two concurrent =
recognition requests to be active, as also stated in section 9.9 =
"If the resource is in the recognizing state, the =
RECOGNIZE request MUST respond with a failure status"

 

It is probably = safer/simpler to=20 assume hotword recognition will be done by a separate recognition = resource.=20  The mention of "both" should then be removed from the=20 spec.

 

Pierre

 

 

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------_=_NextPart_001_01C56B6B.3E49207E-- --===============0948218735== 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 --===============0948218735==-- From speechsc-bounces@ietf.org Tue Jun 07 10:17:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfetc-0004Xq-Et; Tue, 07 Jun 2005 10:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfetb-0004Xl-3k for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 10:17:35 -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 KAA26849 for ; Tue, 7 Jun 2005 10:17:32 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DffEe-0003zK-Kd for speechsc@ietf.org; Tue, 07 Jun 2005 10:39:21 -0400 Received: from postcard.nuance.com ([10.3.6.20]:15946) by letter.nuance.com with esmtp id 1DfetQ-0000QK-Fx; Tue, 07 Jun 2005 07:17:24 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Jun 2005 10:15:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 10:15:42 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802CFBC24@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] MRCPv2 clarification Thread-Index: AcVrXyKx2qdD5AtxQBy8SUof9LOeNwACqQKQAABMjOA= From: "Pierre Forgues" To: "Shanmugham, Saravanan" , "Dave Burke" , "Reifenrath, Klaus" , "IETF SPEECHSC \(E-mail\)" X-OriginalArrivalTime: 07 Jun 2005 14:15:43.0518 (UTC) FILETIME=[641C5BE0:01C56B6B] X-FromHost: postcard.nuance.com [10.3.6.20]:15946 Lines: 690 X-Spam-Score: 0.3 (/) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 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="===============1805155092==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1805155092== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B6B.6393C60E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B6B.6393C60E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anyway, the majority of vendors will be implementing hotword using a separate resource because it does imply a concurrent recognition on the same media stream. I just think we need to clarify that when a single recognition resource is used for hotword or normal mode, that they cannot both be used concurrently. The statement at the beginning of section 9 is not clear in that respect. =20 =20 Pierre =20 ________________________________ From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Tuesday, June 07, 2005 10:15 AM To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] MRCPv2 clarification =20 This was not not imply parallel recognition. If I remember right this wording was added specifically accomodate some recognition resources that may not be capable of both normal and hot word recognition. Some vendors might have implemented them as 2 separate resources.=20 =20 If you are refering to the statement to return failure when the recognizer is in the RECOGNIZING state, this was also why we have created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an active RECOGNIZE command and go active.=20 Anyway, this text describing queing/cancelling/stopping of requests is being clarified based on Dave's request and I had sent a text proposal to do that. That would streamline this and make it consistent.=20 =20 Sarvi =20 =09 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 07, 2005 5:41 AM To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification ... which is what my response was going to be until I read: =20 "or implementations where a=20 single recognition resource does not support both modes, they can be=20 implemented as separate resources and allocated to the same SIP=20 session with different MRCP session identifiers and share the RTP=20 audio feed. " =20 This loosely implies to me that the intent is for parallel hotword and normal recognition.=20 =20 While MRCP should of course allow you to do this (forking media to perform simultaneous recognitions), we should probably clarify , to avoid confusion, that a single speechrecog is not intended to support both modes concurrently. =20 - Dave ----- Original Message -----=20 From: Reifenrath, Klaus =20 To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) =20 Sent: Tuesday, June 07, 2005 1:29 PM Subject: RE: [Speechsc] MRCPv2 clarification =20 Hi Pierre, =20 "both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in hotword mode. =20 Regards, Klaus =20 =09 ________________________________ From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification Section 9 of the MRCPv2 specification includes the following sentence: "The recognition resource may support recognition in the normal or hotword modes or both." I'm not sure the same recognition resource can support "both" because the state machinery does not allow two concurrent recognition requests to be active, as also stated in section 9.9 "If the resource is in the recognizing state, the RECOGNIZE request MUST respond with a failure status" =20 It is probably safer/simpler to assume hotword recognition will be done by a separate recognition resource. The mention of "both" should then be removed from the spec. =20 Pierre =20 =20 =09 ________________________________ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_001_01C56B6B.6393C60E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anyway, the majority of vendors = will be implementing hotword using a separate resource because it does imply a concurrent recognition on the same media stream.  I just think we = need to clarify that when a single recognition resource is used for hotword or = normal mode, that they cannot both be used concurrently.  The statement at = the beginning of section 9 is not clear in that respect. =  

 

Pierre

 

From: = Shanmugham, Saravanan [mailto:sarvi@cisco.com]
Sent: Tuesday, June 07, = 2005 10:15 AM
To: Dave Burke; = Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] = MRCPv2 clarification

 

This was not not imply parallel recognition. If I remember right this wording was added specifically = accomodate some recognition resources that may not be capable of both normal and = hot word recognition. Some vendors might have implemented them as 2 separate = resources.

 

If you are refering to the = statement to return failure when the recognizer is in the RECOGNIZING state, = this  was also why we have created Cancel-If-Queue header to allow a RECOGNIZE = command to cancel an active RECOGNIZE command and go = active. 

Anyway, this text describing queing/cancelling/stopping of requests is being clarified based on = Dave's request and I had sent a text proposal to do that. That would = streamline this and make it consistent. 

 

Sarvi

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke
Sent: Tuesday, June 07, = 2005 5:41 AM
To: Reifenrath, Klaus; = 'Pierre Forgues'; IETF SPEECHSC (E-mail)
Subject: Re: [Speechsc] = MRCPv2 clarification

... which is what my response was going to be until I = read:

 

   "or implementations where a
   single recognition resource does not support both modes, = they can be
   implemented as separate resources and allocated to the same = SIP
   session with different MRCP session identifiers and share = the RTP
   audio feed. "

 

This loosely implies to me that the intent is for = parallel hotword and normal recognition.

 

While MRCP should of course allow you to do this = (forking media to perform simultaneous recognitions), we should probably clarify = , to avoid confusion, that a single speechrecog is not intended to support = both modes concurrently.

 

- Dave

----- Original Message ----- =

Sent: = Tuesday, June 07, 2005 1:29 PM

Subject: RE: = [Speechsc] MRCPv2 clarification

 

Hi = Pierre,

 

"both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in = hotword mode.

 

Regards,

Klaus

 

From: Pierre Forgues [mailto:forgues@nuance.com]
Sent: Dienstag, 7. Juni = 2005 14:12
To: IETF SPEECHSC = (E-mail)
Subject: [Speechsc] = MRCPv2 clarification

Section 9 of the MRCPv2 =
specification includes the following sentence:  "The =
recognition resource may support recognition in the normal or hotword =
modes or both."  I'm not sure the same recognition resource =
can support "both" because the state machinery does not allow =
two concurrent recognition requests to be active, as also stated in =
section 9.9 "If the resource is in the recognizing =
state, the RECOGNIZE request MUST respond with a failure =
status"

 

It is probably safer/simpler to assume hotword = recognition will be done by a separate recognition resource.  The mention of "both" should then be removed from the = spec.

 

Pierre

 

 

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc<= /p>

------_=_NextPart_001_01C56B6B.6393C60E-- --===============1805155092== 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 --===============1805155092==-- From speechsc-bounces@ietf.org Tue Jun 07 10:25:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dff1d-00062a-Ae; Tue, 07 Jun 2005 10:25:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dff1b-00062Q-F8 for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 10:25:51 -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 KAA27774 for ; Tue, 7 Jun 2005 10:25:49 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DffMb-0004Ci-71 for speechsc@ietf.org; Tue, 07 Jun 2005 10:47:38 -0400 Received: from daburkewxp (unknown [10.0.0.140]) by mail.voxpilot.com (Postfix) with ESMTP id 98517214041; Tue, 7 Jun 2005 14:25:33 +0000 (GMT) Message-ID: <0c4401c56b6c$c3e6ccd0$a800000a@db01.voxpilot.com> From: "Dave Burke" To: "Pierre Forgues" , "Shanmugham, Saravanan" , "Reifenrath, Klaus" , "IETF SPEECHSC (E-mail)" References: <7DE7C4EF3B7C8B4B82955191378290D802CFBC24@mtb1exch01.nuance.com> Subject: Re: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 15:25:33 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8279e2b0006e70acac79ca9454596384 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="===============1067613901==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1067613901== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C41_01C56B75.25945170" This is a multi-part message in MIME format. ------=_NextPart_000_0C41_01C56B75.25945170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about adding the clarification in parenthesis: "The recognition resource may support recognition in the normal or = hotword modes or both (although note that a single speechrecog resource = does not perform normal and hotword mode recognitions in parallel)". Dave ----- Original Message -----=20 From: Pierre Forgues=20 To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF = SPEECHSC (E-mail)=20 Sent: Tuesday, June 07, 2005 3:15 PM Subject: RE: [Speechsc] MRCPv2 clarification Anyway, the majority of vendors will be implementing hotword using a = separate resource because it does imply a concurrent recognition on the = same media stream. I just think we need to clarify that when a single = recognition resource is used for hotword or normal mode, that they = cannot both be used concurrently. The statement at the beginning of = section 9 is not clear in that respect. =20 =20 Pierre =20 -------------------------------------------------------------------------= ----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Tuesday, June 07, 2005 10:15 AM To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC = (E-mail) Subject: RE: [Speechsc] MRCPv2 clarification =20 This was not not imply parallel recognition. If I remember right this = wording was added specifically accomodate some recognition resources = that may not be capable of both normal and hot word recognition. Some = vendors might have implemented them as 2 separate resources.=20 =20 If you are refering to the statement to return failure when the = recognizer is in the RECOGNIZING state, this was also why we have = created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an = active RECOGNIZE command and go active.=20 Anyway, this text describing queing/cancelling/stopping of requests is = being clarified based on Dave's request and I had sent a text proposal = to do that. That would streamline this and make it consistent.=20 =20 Sarvi =20 -------------------------------------------------------------------------= --- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave Burke Sent: Tuesday, June 07, 2005 5:41 AM To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification ... which is what my response was going to be until I read: =20 "or implementations where a=20 single recognition resource does not support both modes, they can = be=20 implemented as separate resources and allocated to the same SIP=20 session with different MRCP session identifiers and share the RTP = audio feed. " =20 This loosely implies to me that the intent is for parallel hotword = and normal recognition.=20 =20 While MRCP should of course allow you to do this (forking media to = perform simultaneous recognitions), we should probably clarify , to = avoid confusion, that a single speechrecog is not intended to support = both modes concurrently. =20 - Dave ----- Original Message -----=20 From: Reifenrath, Klaus=20 To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail)=20 Sent: Tuesday, June 07, 2005 1:29 PM Subject: RE: [Speechsc] MRCPv2 clarification =20 Hi Pierre, =20 "both" does not mean in parallel. But you can use the same = resource to do a "normal" recognition and later use the same resource to = perform a recognition in hotword mode. =20 Regards, Klaus =20 -------------------------------------------------------------------------= - From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification Section 9 of the MRCPv2 specification includes the following sentence: = "The recognition resource may support recognition in the normal or = hotword modes or both." I'm not sure the same recognition resource can = support "both" because the state machinery does not allow two concurrent = recognition requests to be active, as also stated in section 9.9 "If the = resource is in the recognizing state, the RECOGNIZE request MUST respond = with a failure status"=20 It is probably safer/simpler to assume hotword recognition will be = done by a separate recognition resource. The mention of "both" should = then be removed from the spec. =20 Pierre =20 =20 -------------------------------------------------------------------------= - _______________________________________________ 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 ------=_NextPart_000_0C41_01C56B75.25945170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How about adding the clarification in=20 parenthesis:
 
"The recognition resource may support = recognition=20 in the normal or hotword modes or both (although note that a single = speechrecog resource does not perform normal and hotword mode = recognitions=20 in parallel)".
 
Dave
----- Original Message -----
From:=20 Pierre=20 Forgues
To: Shanmugham, Saravanan ; Dave=20 Burke ; Reifenrath, Klaus ; = IETF = SPEECHSC=20 (E-mail)
Sent: Tuesday, June 07, 2005 = 3:15=20 PM
Subject: RE: [Speechsc] MRCPv2=20 clarification

Anyway, the = majority=20 of vendors will be implementing hotword using a separate resource = because it=20 does imply a concurrent recognition on the same media stream.  I = just=20 think we need to clarify that when a single recognition resource is = used for=20 hotword or normal mode, that they cannot both be used concurrently. =  The=20 statement at the beginning of section 9 is not clear in that respect.=20  

 

Pierre

 

From:=20 Shanmugham, Saravanan [mailto:sarvi@cisco.com]
Sent: Tuesday, June 07, 2005 = 10:15=20 AM
To: Dave Burke;=20 Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] MRCPv2=20 clarification

 

This was = not not=20 imply parallel recognition. If I remember right this wording was added = specifically accomodate some recognition resources that may not be = capable of=20 both normal and hot word recognition. Some vendors might have = implemented them=20 as 2 separate resources.

 

If you are = refering=20 to the statement to return failure when the recognizer is in the = RECOGNIZING=20 state, this  was also why we have created Cancel-If-Queue header = to allow=20 a RECOGNIZE command to cancel an active RECOGNIZE command and go=20 active. 

Anyway, = this text=20 describing queing/cancelling/stopping of requests is being clarified = based on=20 Dave's request and I had sent a text proposal to do that. That = would=20 streamline this and make it=20 consistent. 

 

Sarvi

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave = Burke
Sent: Tuesday, June 07, 2005 = 5:41=20 AM
To: = Reifenrath, Klaus;=20 'Pierre Forgues'; IETF SPEECHSC (E-mail)
Subject: Re: [Speechsc] = MRCPv2=20 clarification

... which is what my = response=20 was going to be until I read:

 =20

   "or = implementations=20 where a
   single recognition resource does not = support both=20 modes, they can be
   implemented as separate = resources and=20 allocated to the same SIP
   session with different = MRCP=20 session identifiers and share the RTP
   audio feed.=20 "

 

This loosely implies = to me that=20 the intent is for parallel hotword and normal recognition.=20

 

While MRCP should of = course=20 allow you to do this (forking media to perform simultaneous = recognitions),=20 we should probably clarify , to avoid confusion, that a single = speechrecog=20 is not intended to support both modes=20 concurrently.

 

-=20 Dave

----- Original = Message -----=20

From: Reifenrath, = Klaus=20

To: 'Pierre=20 Forgues' ; IETF SPEECHSC (E-mail)=20

Sent:=20 Tuesday, June 07, 2005 1:29 PM

Subject: RE:=20 [Speechsc] MRCPv2 clarification

 

Hi=20 Pierre,

 

"both" = does not=20 mean in parallel. But you can use the same resource to do a = "normal"=20 recognition and later use the same resource to perform a = recognition in=20 hotword mode.

 

Regards,

Klaus

 

From:=20 Pierre Forgues [mailto:forgues@nuance.com]
Sent: Dienstag, 7. Juni = 2005=20 14:12
To: IETF = SPEECHSC=20 (E-mail)
Subject:=20 [Speechsc] MRCPv2 = clarification

Section 9 =
of the MRCPv2 specification includes the following sentence:  "The =
recognition resource may support recognition in the normal or hotword =
modes or both."  I'm not sure the same recognition resource can =
support "both" because the state machinery does not allow two concurrent =
recognition requests to be active, as also stated in section 9.9 =
"If the resource is in the recognizing state, the =
RECOGNIZE request MUST respond with a failure status"

 

It is probably = safer/simpler=20 to assume hotword recognition will be done by a separate = recognition=20 resource.  The mention of "both" should then be removed from = the=20 spec.

 

Pierre

 

 

_______________________________________________
Speechsc=20 mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0C41_01C56B75.25945170-- --===============1067613901== 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 --===============1067613901==-- From speechsc-bounces@ietf.org Tue Jun 07 10:27:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dff3a-0006OM-IG; Tue, 07 Jun 2005 10:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dff3Z-0006Nq-Nd for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 10:27:53 -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 KAA28092 for ; Tue, 7 Jun 2005 10:27:51 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DffOd-0004GQ-EC for speechsc@ietf.org; Tue, 07 Jun 2005 10:49:40 -0400 Received: from postcard.nuance.com ([10.3.6.20]:16074) by letter.nuance.com with esmtp id 1Dff3P-0000XI-Rz; Tue, 07 Jun 2005 07:27:43 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Jun 2005 10:26:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 10:26:01 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802CFBC29@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] MRCPv2 clarification Thread-Index: AcVrbJBwAzf79SyQSOyxAgI37XvzywAADHrg From: "Pierre Forgues" To: "Dave Burke" , "Shanmugham, Saravanan" , "Reifenrath, Klaus" , "IETF SPEECHSC \(E-mail\)" X-OriginalArrivalTime: 07 Jun 2005 14:26:02.0888 (UTC) FILETIME=[D548B880:01C56B6C] X-FromHost: postcard.nuance.com [10.3.6.20]:16074 Lines: 934 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0f44ec47f6ebd2aaf0f97ba9529b3ca5 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="===============1068963780==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1068963780== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B6C.D4C5AAB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B6C.D4C5AAB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would suit me fine. Thanks. /Pierre =20 ________________________________ From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, June 07, 2005 10:26 AM To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification =20 How about adding the clarification in parenthesis: =20 "The recognition resource may support recognition in the normal or hotword modes or both (although note that a single speechrecog resource does not perform normal and hotword mode recognitions in parallel)". =20 Dave ----- Original Message -----=20 From: Pierre Forgues =20 To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF SPEECHSC (E-mail) =20 Sent: Tuesday, June 07, 2005 3:15 PM Subject: RE: [Speechsc] MRCPv2 clarification =20 Anyway, the majority of vendors will be implementing hotword using a separate resource because it does imply a concurrent recognition on the same media stream. I just think we need to clarify that when a single recognition resource is used for hotword or normal mode, that they cannot both be used concurrently. The statement at the beginning of section 9 is not clear in that respect. =20 =20 Pierre =20 =09 ________________________________ From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Tuesday, June 07, 2005 10:15 AM To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] MRCPv2 clarification =20 This was not not imply parallel recognition. If I remember right this wording was added specifically accomodate some recognition resources that may not be capable of both normal and hot word recognition. Some vendors might have implemented them as 2 separate resources.=20 =20 If you are refering to the statement to return failure when the recognizer is in the RECOGNIZING state, this was also why we have created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an active RECOGNIZE command and go active.=20 Anyway, this text describing queing/cancelling/stopping of requests is being clarified based on Dave's request and I had sent a text proposal to do that. That would streamline this and make it consistent.=20 =20 Sarvi =20 =09 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 07, 2005 5:41 AM To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification ... which is what my response was going to be until I read: =20 "or implementations where a=20 single recognition resource does not support both modes, they can be=20 implemented as separate resources and allocated to the same SIP=20 session with different MRCP session identifiers and share the RTP=20 audio feed. " =20 This loosely implies to me that the intent is for parallel hotword and normal recognition.=20 =20 While MRCP should of course allow you to do this (forking media to perform simultaneous recognitions), we should probably clarify , to avoid confusion, that a single speechrecog is not intended to support both modes concurrently. =20 - Dave ----- Original Message -----=20 From: Reifenrath, Klaus =20 To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) =20 Sent: Tuesday, June 07, 2005 1:29 PM Subject: RE: [Speechsc] MRCPv2 clarification =20 Hi Pierre, =20 "both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in hotword mode. =20 Regards, Klaus =20 =09 ________________________________ From: Pierre Forgues [mailto:forgues@nuance.com] Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification Section 9 of the MRCPv2 specification includes the following sentence: "The recognition resource may support recognition in the normal or hotword modes or both." I'm not sure the same recognition resource can support "both" because the state machinery does not allow two concurrent recognition requests to be active, as also stated in section 9.9 "If the resource is in the recognizing state, the RECOGNIZE request MUST respond with a failure status" =20 It is probably safer/simpler to assume hotword recognition will be done by a separate recognition resource. The mention of "both" should then be removed from the spec. =20 Pierre =20 =20 =09 ________________________________ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =09 ________________________________ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_001_01C56B6C.D4C5AAB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That would suit me fine. =  Thanks.  /Pierre

 

From: Dave = Burke [mailto:david.burke@voxpilot.com]
Sent: Tuesday, June 07, = 2005 10:26 AM
To: Pierre Forgues; = Shanmugham, Saravanan; Reifenrath, Klaus; IETF SPEECHSC (E-mail)
Subject: Re: [Speechsc] = MRCPv2 clarification

 

How about adding the clarification in = parenthesis:

 

"The recognition resource may support = recognition in the normal or hotword modes or both (although note that a single speechrecog resource does not perform normal and hotword mode = recognitions in parallel)".

 

Dave

----- Original Message ----- =

Sent: = Tuesday, June 07, 2005 3:15 PM

Subject: RE: = [Speechsc] MRCPv2 clarification

 

Anyway, the majority of vendors = will be implementing hotword using a separate resource because it does imply a concurrent recognition on the same media stream.  I just think we = need to clarify that when a single recognition resource is used for hotword or = normal mode, that they cannot both be used concurrently.  The statement at = the beginning of section 9 is not clear in that respect. =  

 

Pierre

 

From: = Shanmugham, Saravanan [mailto:sarvi@cisco.com]
Sent: Tuesday, June 07, = 2005 10:15 AM
To: Dave Burke; = Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-mail)
Subject: RE: [Speechsc] = MRCPv2 clarification

 

This was not not imply parallel recognition. If I remember right this wording was added specifically = accomodate some recognition resources that may not be capable of both normal and = hot word recognition. Some vendors might have implemented them as 2 separate = resources.

 

If you are refering to the = statement to return failure when the recognizer is in the RECOGNIZING state, = this  was also why we have created Cancel-If-Queue header to allow a RECOGNIZE = command to cancel an active RECOGNIZE command and go = active. 

Anyway, this text describing queing/cancelling/stopping of requests is being clarified based on = Dave's request and I had sent a text proposal to do that. That would = streamline this and make it consistent. 

 

Sarvi

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke
Sent: Tuesday, June 07, = 2005 5:41 AM
To: Reifenrath, Klaus; = 'Pierre Forgues'; IETF SPEECHSC (E-mail)
Subject: Re: [Speechsc] = MRCPv2 clarification

... which is what my response was going to be until I = read:

 

   "or implementations where a
   single recognition resource does not support both modes, = they can be
   implemented as separate resources and allocated to the same = SIP
   session with different MRCP session identifiers and share = the RTP
   audio feed. "

 

This loosely implies to me that the intent is for = parallel hotword and normal recognition.

 

While MRCP should of course allow you to do this = (forking media to perform simultaneous recognitions), we should probably clarify = , to avoid confusion, that a single speechrecog is not intended to support = both modes concurrently.

 

- Dave

----- Original Message ----- =

Sent: = Tuesday, June 07, 2005 1:29 PM

Subject: RE: = [Speechsc] MRCPv2 clarification

 

Hi = Pierre,

 

"both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in = hotword mode.

 

Regards,

Klaus

 

From: Pierre Forgues [mailto:forgues@nuance.com]
Sent: Dienstag, 7. Juni = 2005 14:12
To: IETF SPEECHSC = (E-mail)
Subject: [Speechsc] = MRCPv2 clarification

Section 9 of the MRCPv2 =
specification includes the following sentence:  "The =
recognition resource may support recognition in the normal or hotword =
modes or both."  I'm not sure the same recognition resource =
can support "both" because the state machinery does not allow =
two concurrent recognition requests to be active, as also stated in =
section 9.9 "If the resource is in the recognizing =
state, the RECOGNIZE request MUST respond with a failure =
status"

 

It is probably safer/simpler to assume hotword = recognition will be done by a separate recognition resource.  The mention of "both" should then be removed from the = spec.

 

Pierre

 

 

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc<= /p>

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc<= /p>

------_=_NextPart_001_01C56B6C.D4C5AAB2-- --===============1068963780== 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 --===============1068963780==-- From speechsc-bounces@ietf.org Tue Jun 07 10:52:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DffRO-0002zQ-Ub; Tue, 07 Jun 2005 10:52:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DffRL-0002zI-U2 for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 10:52:28 -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 KAA00453 for ; Tue, 7 Jun 2005 10:52:25 -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 1DffmP-0004va-Nf for speechsc@ietf.org; Tue, 07 Jun 2005 11:14:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 07:52:16 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208,217"; a="275396660:sNHT58329048" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j57EqDlq014401; Tue, 7 Jun 2005 07:52:14 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 07:54:16 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B77060B@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 clarification Thread-Index: AcVrbJBwAzf79SyQSOyxAgI37XvzywAADHrgAADrTvA= From: "Shanmugham, Saravanan" To: "Pierre Forgues" , "Dave Burke" , "Reifenrath, Klaus" , "IETF SPEECHSC \(E-mail\)" X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e5958278d089090169a903f246b3f39 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="===============0928833215==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0928833215== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56B70.C6B275F5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56B70.C6B275F5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable thats sounds fine with me. =20 Sarvi _____ =20 From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Tuesday, June 07, 2005 7:26 AM To: Dave Burke; Shanmugham, Saravanan; Reifenrath, Klaus; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] MRCPv2 clarification =09 =09 That would suit me fine. Thanks. /Pierre =20 =09 _____ =20 From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, June 07, 2005 10:26 AM To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification =20 How about adding the clarification in parenthesis: =20 "The recognition resource may support recognition in the normal or hotword modes or both (although note that a single speechrecog resource does not perform normal and hotword mode recognitions in parallel)". =20 Dave ----- Original Message -----=20 From: Pierre Forgues =20 To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF SPEECHSC (E-mail) =20 Sent: Tuesday, June 07, 2005 3:15 PM Subject: RE: [Speechsc] MRCPv2 clarification =20 Anyway, the majority of vendors will be implementing hotword using a separate resource because it does imply a concurrent recognition on the same media stream. I just think we need to clarify that when a single recognition resource is used for hotword or normal mode, that they cannot both be used concurrently. The statement at the beginning of section 9 is not clear in that respect. =20 =20 Pierre =20 =09 _____ =20 From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Tuesday, June 07, 2005 10:15 AM To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-mail) Subject: RE: [Speechsc] MRCPv2 clarification =20 This was not not imply parallel recognition. If I remember right this wording was added specifically accomodate some recognition resources that may not be capable of both normal and hot word recognition. Some vendors might have implemented them as 2 separate resources.=20 =20 If you are refering to the statement to return failure when the recognizer is in the RECOGNIZING state, this was also why we have created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an active RECOGNIZE command and go active.=20 Anyway, this text describing queing/cancelling/stopping of requests is being clarified based on Dave's request and I had sent a text proposal to do that. That would streamline this and make it consistent.=20 =20 Sarvi =20 =09 _____ =20 From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 07, 2005 5:41 AM To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification ... which is what my response was going to be until I read: =20 "or implementations where a=20 single recognition resource does not support both modes, they can be=20 implemented as separate resources and allocated to the same SIP=20 session with different MRCP session identifiers and share the RTP=20 audio feed. " =20 This loosely implies to me that the intent is for parallel hotword and normal recognition.=20 =20 While MRCP should of course allow you to do this (forking media to perform simultaneous recognitions), we should probably clarify , to avoid confusion, that a single speechrecog is not intended to support both modes concurrently. =20 - Dave ----- Original Message -----=20 From: Reifenrath, Klaus =20 To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) =20 Sent: Tuesday, June 07, 2005 1:29 PM Subject: RE: [Speechsc] MRCPv2 clarification =20 Hi Pierre, =20 "both" does not mean in parallel. But you can use the same resource to do a "normal" recognition and later use the same resource to perform a recognition in hotword mode. =20 Regards, Klaus =20 =09 _____ =20 From: Pierre Forgues [mailto:forgues@nuance.com]=20 Sent: Dienstag, 7. Juni 2005 14:12 To: IETF SPEECHSC (E-mail) Subject: [Speechsc] MRCPv2 clarification Section 9 of the MRCPv2 specification includes the following sentence: "The recognition resource may support recognition in the normal or hotword modes or both." I'm not sure the same recognition resource can support "both" because the state machinery does not allow two concurrent recognition requests to be active, as also stated in section 9.9 "If the resource is in the recognizing state, the RECOGNIZE request MUST respond with a failure status" =20 It is probably safer/simpler to assume hotword recognition will be done by a separate recognition resource. The mention of "both" should then be removed from the spec. =20 Pierre =20 =20 =09 _____ =20 =09 _______________________________________________ Speechsc mailing list Speechsc@ietf.org =09 https://www1.ietf.org/mailman/listinfo/speechsc =09 _____ =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_001_01C56B70.C6B275F5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
thats sounds fine with me.
 
Sarvi

From: Pierre Forgues=20 [mailto:forgues@nuance.com]
Sent: Tuesday, June 07, 2005 = 7:26=20 AM
To: Dave Burke; Shanmugham, Saravanan; Reifenrath, Klaus; = IETF=20 SPEECHSC (E-mail)
Subject: RE: [Speechsc] MRCPv2=20 clarification

That would = suit me=20 fine.  Thanks.  /Pierre

 

From: Dave=20 Burke [mailto:david.burke@voxpilot.com]
Sent: Tuesday, June 07, 2005 = 10:26=20 AM
To: Pierre = Forgues;=20 Shanmugham, Saravanan; Reifenrath, Klaus; IETF SPEECHSC = (E-mail)
Subject: Re: [Speechsc] MRCPv2=20 clarification

 

How about adding the = clarification=20 in parenthesis:

 

"The recognition = resource may=20 support recognition in the normal or hotword modes or both = (although note=20 that a single speechrecog resource does not perform normal and = hotword=20 mode recognitions in parallel)".

 

Dave

----- Original Message = -----=20

From: Pierre = Forgues=20

To: Shanmugham,=20 Saravanan ; Dave Burke ; Reifenrath, Klaus = ; IETF = SPEECHSC=20 (E-mail)

Sent:=20 Tuesday, June 07, 2005 3:15 PM

Subject: RE:=20 [Speechsc] MRCPv2 clarification

 

Anyway, = the=20 majority of vendors will be implementing hotword using a separate = resource=20 because it does imply a concurrent recognition on the same media=20 stream.  I just think we need to clarify that when a single = recognition=20 resource is used for hotword or normal mode, that they cannot both = be used=20 concurrently.  The statement at the beginning of section 9 is = not clear=20 in that respect.  

 

Pierre

 

From:=20 Shanmugham, Saravanan [mailto:sarvi@cisco.com]
Sent: Tuesday, June 07, 2005 = 10:15=20 AM
To: Dave = Burke;=20 Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC = (E-mail)
Subject: RE: [Speechsc] = MRCPv2=20 clarification

 

This was = not not=20 imply parallel recognition. If I remember right this wording was = added=20 specifically accomodate some recognition resources that may not be = capable=20 of both normal and hot word recognition. Some vendors might have = implemented=20 them as 2 separate resources.

 

If you = are refering=20 to the statement to return failure when the recognizer is in the = RECOGNIZING=20 state, this  was also why we have created Cancel-If-Queue = header to=20 allow a RECOGNIZE command to cancel an active RECOGNIZE command and = go=20 active. 

Anyway, = this text=20 describing queing/cancelling/stopping of requests is being clarified = based=20 on Dave's request and I had sent a text proposal to do that. = That would=20 streamline this and make it=20 consistent. 

 

Sarvi

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave = Burke
Sent: Tuesday, June 07, = 2005 5:41=20 AM
To: = Reifenrath, Klaus;=20 'Pierre Forgues'; IETF SPEECHSC (E-mail)
Subject: Re: [Speechsc] = MRCPv2=20 clarification

... which is what my = response=20 was going to be until I read:

 =20

   "or=20 implementations where a
   single recognition = resource does=20 not support both modes, they can be
   implemented = as=20 separate resources and allocated to the same SIP
   = session=20 with different MRCP session identifiers and share the RTP =
  =20 audio feed. "

 

This loosely implies = to me=20 that the intent is for parallel hotword and normal recognition.=20

 

While MRCP should of = course=20 allow you to do this (forking media to perform simultaneous = recognitions),=20 we should probably clarify , to avoid confusion, that a single = speechrecog=20 is not intended to support both modes=20 concurrently.

 

-=20 Dave

----- Original = Message -----=20

From: Reifenrath, = Klaus=20

To: 'Pierre=20 Forgues' ; IETF SPEECHSC (E-mail)=20

Sent:=20 Tuesday, June 07, 2005 1:29 = PM

Subject: RE:=20 [Speechsc] MRCPv2 = clarification

 

Hi=20 Pierre,

 

"both" does not=20 mean in parallel. But you can use the same resource to do a = "normal"=20 recognition and later use the same resource to perform a = recognition in=20 hotword mode.

 

Regards,

Klaus

 

From:=20 Pierre Forgues [mailto:forgues@nuance.com]
Sent: Dienstag, 7. Juni = 2005=20 14:12
To: = IETF SPEECHSC=20 (E-mail)
Subject:=20 [Speechsc] MRCPv2 = clarification

Section 9 =
of the MRCPv2 specification includes the following sentence:  "The =
recognition resource may support recognition in the normal or hotword =
modes or both."  I'm not sure the same recognition resource can =
support "both" because the state machinery does not allow two concurrent =
recognition requests to be active, as also stated in section 9.9 =
"If the resource is in the recognizing state, the =
RECOGNIZE request MUST respond with a failure status"

 

It is probably = safer/simpler=20 to assume hotword recognition will be done by a separate = recognition=20 resource.  The mention of "both" should then be removed = from the=20 spec.

 

Pierre

 

 

_______________________________________________
Speechsc=20 mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc

_______________________________________________
Speechsc=20 mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc

------_=_NextPart_001_01C56B70.C6B275F5-- --===============0928833215== 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 --===============0928833215==-- From speechsc-bounces@ietf.org Tue Jun 07 14:14:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfiay-0007lK-Ic; Tue, 07 Jun 2005 14:14:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfiax-0007lA-B7 for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:14:35 -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 OAA16465 for ; Tue, 7 Jun 2005 14:14:33 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfiw3-0001AK-LC for speechsc@ietf.org; Tue, 07 Jun 2005 14:36:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2005 11:14:26 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="641697494:sNHT27173544" 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 j57IELbw004057 for ; Tue, 7 Jun 2005 11:14:21 -0700 (PDT) Received: from [128.107.165.82] (dhcp-128-107-165-82.cisco.com [128.107.165.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j57I2QjL024534 for ; Tue, 7 Jun 2005 11:02:30 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <62560556-F42D-4658-8962-43E29EEA48A7@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Tue, 7 Jun 2005 10:17:49 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118167350.310244"; x:"432200"; a:"rsa-sha1"; b:"nofws:422"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"DHdUOnX4d0IbtCxFwdADPSLGT42A5qswtzaMs1asJSRn85MfKA00t+lYUYtWaMsbMm1HBaVN" "ZoWmNfYiVxp/5EBEKIn4hAVGhee3+JXpWNAkl/MwfVGfDP+z7hqNW1HP/TfavB4taOZ8Ikr025G" "GdWkD8SfVEN/F5tYfAsU0sM8="; c:"From: =22David R. Oran=22 "; c:"Subject: Personal grammars"; c:"Date: Tue, 7 Jun 2005 10:17:49 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.7 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Personal grammars 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 text on phrase enrollment says: "The Personal-Grammar-URI, which specifies the grammar to contain the new enrolled phrase, is created if it does not exist. Also, the personal grammar may ONLY contain phrases added via a phrase enrollment session." What's the reason for this restriction? What bad would happen if we got rid of it, especially as the protocol has no mechanisms to enforce this or for the client to generate an error when it happens. (still doing the chair review...hang in there). Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 14:14:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfiay-0007lj-Pu; Tue, 07 Jun 2005 14:14:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfiay-0007lF-33 for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:14:36 -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 OAA16468 for ; Tue, 7 Jun 2005 14:14:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfiw3-0001AJ-D4 for speechsc@ietf.org; Tue, 07 Jun 2005 14:36:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2005 11:14:25 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="641697488:sNHT28437112" 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 j57IEKbw004043 for ; Tue, 7 Jun 2005 11:14:20 -0700 (PDT) Received: from [128.107.165.82] (dhcp-128-107-165-82.cisco.com [128.107.165.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j57I2QjK024534 for ; Tue, 7 Jun 2005 11:02:29 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <879605B8-AD23-49C7-8AC9-831B1B03F99E@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Tue, 7 Jun 2005 09:53:17 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118167349.255247"; x:"432200"; a:"rsa-sha1"; b:"nofws:1361"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"SgGxUjhv0fETN+mgNvTFESLNmXzhK7AIqZ4ndIsaAHw9qMriVUi1gWTuTkAkXTJclcE5FLzn" "5+BrGfOHfVjT7dT/rkC1OnYO3XUr0ohlJk/gEcZEL3JiJRrJhAONGRVW1aCS29N1PCXmh4+9FSK" "6AjdjRYTW/Wcqv26VWfDiYKM="; c:"From: =22David R. Oran=22 "; c:"Subject: =22Race=22 condition between RECOGNIZE.request and media"; c:"Date: Tue, 7 Jun 2005 09:53:17 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.7 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Speechsc] "Race" condition between RECOGNIZE.request and media 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 text says: "Note that since the audio and the messages are carried over separate communication paths there may be a race condition between the start of the flow of audio and the receipt of the RECOGNIZE method. For example, if an audio flow is started by the client at the same time as the RECOGNIZE method is sent, either the audio or the RECOGNIZE can arrive at the recognizer first. As another example, the client may chose to continuously send audio to the Server and signal the Server to recognize using the RECOGNIZE method. A number of mechanisms exist to resolve this condition and the mechanism chosen is left to the implementers of recognition resource. The recognizer should expect the media to start flowing when it receives the recognize request, but should not buffer anything it receives beforehand." Either this race condition doesn't matter, in which case we should either just nuke this paragraph or take out the should/should not guidance at the end, or it does matter, in which case this material is wholly inadequate. If the synchronization of the control and media channels matters, then we really do need to fix the protocol. Luckily, this is relatively easy to do: a) recommend that servers with recognizers buffer at least an RTT worth of media. b) include an NTP timestamp of where in the the input media recognition should start in a RECOGNIZE request header. c) define an error to cover the "lost media" case. My gut tells me that for recognition none of this is necessary and we should just nuke the paragraph above as making implementers think about something they can only screw up if they work too hard at it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 14:14:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfib6-0007mI-15; Tue, 07 Jun 2005 14:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfib5-0007m8-3d for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:14:43 -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 OAA16471 for ; Tue, 7 Jun 2005 14:14:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfiwA-0001AS-BO for speechsc@ietf.org; Tue, 07 Jun 2005 14:36:31 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2005 11:14:32 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j57IEPlw020879 for ; Tue, 7 Jun 2005 11:14:25 -0700 (PDT) Received: from [128.107.165.82] (dhcp-128-107-165-82.cisco.com [128.107.165.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j57I2QjQ024534 for ; Tue, 7 Jun 2005 11:02:36 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <611E32AD-5405-4FC7-89F9-52C66EBBB785@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Tue, 7 Jun 2005 11:39:26 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118167356.987321"; x:"432200"; a:"rsa-sha1"; b:"nofws:460"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"SSG9dq9Ws8G8cWv1Y4hL+Su0+k/h5B2ubHZmBbPXcuVpp3CIQ3KaPeTD2Nen4YzYJBRArZEs" "zIQL7F8zTKgYgyccq58+/gS/5P4C39YUPNeY7gRxoNtn3TXjWJvC/an+LrrtD0gbpu8sbKFxAnx" "HgcEFkAIvTqwBqdNzZn5tNrc="; c:"From: =22David R. Oran=22 "; c:"Subject: trim-length on STOP"; c:"Date: Tue, 7 Jun 2005 11:39:26 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Speechsc] trim-length on STOP 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 text of the STOP method on the recorder resource says: "The STOP method may have a Trim-Length header, in which case the specified length of audio is trimmed from the end of the recording after the stop." Sorry, but unless I'm badly mistaken there's no such header. Do we define the header, re-use the max-time header, or nuke the sentence? My preference is to just re-use max-time, and say if max-time on the STOP is less than max-time on the request, you trim to max-time from the end. Let me know. If I don't hear other views, I'll proceed as above. Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 14:14:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfib6-0007mh-Ak; Tue, 07 Jun 2005 14:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfib5-0007mD-5o for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:14:43 -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 OAA16473 for ; Tue, 7 Jun 2005 14:14:41 -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 1Dfiw9-0001AO-BJ for speechsc@ietf.org; Tue, 07 Jun 2005 14:36:31 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 11:14:31 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="275507169:sNHT28192912" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j57IETlq006036 for ; Tue, 7 Jun 2005 11:14:29 -0700 (PDT) Received: from [128.107.165.82] (dhcp-128-107-165-82.cisco.com [128.107.165.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j57I2QjP024534 for ; Tue, 7 Jun 2005 11:02:35 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <0EAEB5BD-8A9B-4A2E-8B70-F04186A8E6D4@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Tue, 7 Jun 2005 11:29:27 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118167355.764462"; x:"432200"; a:"rsa-sha1"; b:"nofws:885"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"KFY+O0BhDbcZHATM35kAezt/jRVON0TaegKJg0EofrYKJt5nQpbI83hRbgGSf5UBw9IzGShN" "rpW1Fvtn9Hc4H6fDNy2Q1IzVRRyCce3kJUGfDB8NvndMSFQo/9kWhHHuIID7XZ0GyEsjZgThRYV" "nUTALB0lQGt+2dME9uXPlRsc="; c:"From: =22David R. Oran=22 "; c:"Subject: RECORD method"; c:"Date: Tue, 7 Jun 2005 11:29:27 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Speechsc] RECORD method 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 text says: "The RECORD request places the recorder resource in the Recording state. Depending on the headers specified in the RECORD method the resource may start recording the audio immediately or wait for the end pointing functionality to detect speech in the audio. It then saves the audio to the URI supplied in the recording-uri header. If the recording-uri is not specified, the server MUST capture the media onto a local disk and return a URI pointing to the recorded audio in the RECORD-COMPLETE event. The server MUST support HTTP and file URI schemes." Sorry, but a file: URI won't work - it's not generally usable between systems. Because of this and the secuirty issues, the last sentence probably ought to be: "The server MUST support the HTTPS URI scheme and MAY support other schemes. Note that due to the sensitive nature of voice recordings, any other URI schemes supported by the server SHOULD employ integrity and confidentiality on the data transfer (e.g. FTPS)." I changed the text, so let me know if this is going to cause heartburn. dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 14:30:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfiqS-0001pT-No; Tue, 07 Jun 2005 14:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfiqQ-0001pJ-5Q for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:30:35 -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 OAA17640 for ; Tue, 7 Jun 2005 14:30:32 -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 1DfjBV-0001TF-I3 for speechsc@ietf.org; Tue, 07 Jun 2005 14:52:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 11:30:24 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="275516300:sNHT28549808" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j57IU6lw006427; Tue, 7 Jun 2005 11:30:06 -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] RECORD method Date: Tue, 7 Jun 2005 11:32:16 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B770713@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] RECORD method Thread-Index: AcVrjXW1l0qqcUTZSK6SbkLUE1BvCgAAV3qA From: "Shanmugham, Saravanan" To: "David R. Oran" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I think we want to allow for HTTP as well. So, "MUST HTTPS and SHOULD HTTP" would be fine with me. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Tuesday, June 07, 2005 8:29 AM To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] RECORD method =20 the text says: =20 "The RECORD request places the recorder resource in the=20 Recording state. Depending on the headers specified in the=20 RECORD method the resource may start recording the audio=20 immediately or wait for the end pointing functionality to=20 detect speech in the audio. It then saves the audio to the=20 URI supplied in the recording-uri header. If the=20 recording-uri is not specified, the server MUST capture=20 the media onto a local disk and return a URI pointing to=20 the recorded audio in the RECORD-COMPLETE event. The=20 server MUST support HTTP and file URI schemes." =20 Sorry, but a file: URI won't work - it's not generally=20 usable between systems. Because of this and the secuirty=20 issues, the last sentence probably ought to be: =20 "The server MUST support the HTTPS URI scheme and MAY=20 support other schemes. Note that due to the sensitive=20 nature of voice recordings, any other URI schemes=20 supported by the server SHOULD employ integrity and=20 confidentiality on the data transfer (e.g. FTPS)." =20 I changed the text, so let me know if this is going to=20 cause heartburn. =20 dave. =20 =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 Tue Jun 07 14:35:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfiuz-0002Lq-2B; Tue, 07 Jun 2005 14:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfiux-0002Lj-Pq for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:35:16 -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 OAA18087 for ; Tue, 7 Jun 2005 14:35:14 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfjG3-0001aP-Dq for speechsc@ietf.org; Tue, 07 Jun 2005 14:57:04 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2005 11:35:05 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j57IYxlw011469; Tue, 7 Jun 2005 11:35:00 -0700 (PDT) Received: from [128.107.165.82] (dhcp-128-107-165-82.cisco.com [128.107.165.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j57IN7qO024787; Tue, 7 Jun 2005 11:23:08 -0700 In-Reply-To: <6677B3346233B94EBB11C060935101200B77060B@vtg-um-e2k1.sj21ad.cisco.com> References: <6677B3346233B94EBB11C060935101200B77060B@vtg-um-e2k1.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F04928F-6B5D-46DE-A662-F21FF096E83A@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 14:34:59 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118168588.216972"; x:"432200"; a:"rsa-sha1"; b:"nofws:5012"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"CC9e6FGg7qjDqWeIRiX2J1OLC0XPTfU4Mx76ndSIaa7NkvsOMQ8T9xkXlj+gyNiQ+v5uciuA" "hFUC06aMcK3VdLG0qpSDzvSp2qQFumCtPoAqWeMoRjAotks//ndDq6gZ3ne+1hAX3YzfvWYWZOX" "npv3wTfpQdxKGfNDB8BovacM="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] MRCPv2 clarification"; c:"Date: Tue, 7 Jun 2005 14:34:59 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , Pierre Forgues , "Reifenrath, Klaus" , Dave Burke 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 Since I have the editing token at the moment, I decided to just deal with this now. I tweaked the text slightly to fit in better with the rest of the paragraph, so it now reads: "The "speechrecog" can recognize regular speech as well as DTMF digits and hence SHOULD support grammars describing either speech or DTMF. The recognition resource may support recognition in the normal or hotword modes or both (although note that a single speechrecog resource does not perform normal and hotword mode recognitions simultaneously). For implementations where a single recognition resource does not support both modes, or simultaneous normal and hotword recognition is desired, the two modes can be invoked through separate resources and allocated to the same SIP dialog with different MRCP session identifiers and share the RTP audio feed." On Jun 7, 2005, at 10:54 AM, Shanmugham, Saravanan wrote: > thats sounds fine with me. > > Sarvi > > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Tuesday, June 07, 2005 7:26 AM > To: Dave Burke; Shanmugham, Saravanan; Reifenrath, Klaus; IETF > SPEECHSC (E-mail) > Subject: RE: [Speechsc] MRCPv2 clarification > > That would suit me fine. Thanks. /Pierre > > > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 07, 2005 10:26 AM > To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF > SPEECHSC (E-mail) > Subject: Re: [Speechsc] MRCPv2 clarification > > > > How about adding the clarification in parenthesis: > > > > "The recognition resource may support recognition in the normal or > hotword modes or both (although note that a single speechrecog > resource does not perform normal and hotword mode recognitions in > parallel)". > > > > Dave > > ----- Original Message ----- > > From: Pierre Forgues > > To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF > SPEECHSC (E-mail) > > Sent: Tuesday, June 07, 2005 3:15 PM > > Subject: RE: [Speechsc] MRCPv2 clarification > > > > Anyway, the majority of vendors will be implementing hotword using > a separate resource because it does imply a concurrent recognition > on the same media stream. I just think we need to clarify that > when a single recognition resource is used for hotword or normal > mode, that they cannot both be used concurrently. The statement at > the beginning of section 9 is not clear in that respect. > > > > Pierre > > > > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Tuesday, June 07, 2005 10:15 AM > To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E- > mail) > Subject: RE: [Speechsc] MRCPv2 clarification > > > > This was not not imply parallel recognition. If I remember right > this wording was added specifically accomodate some recognition > resources that may not be capable of both normal and hot word > recognition. Some vendors might have implemented them as 2 separate > resources. > > > > If you are refering to the statement to return failure when the > recognizer is in the RECOGNIZING state, this was also why we have > created Cancel-If-Queue header to allow a RECOGNIZE command to > cancel an active RECOGNIZE command and go active. > > Anyway, this text describing queing/cancelling/stopping of requests > is being clarified based on Dave's request and I had sent a text > proposal to do that. That would streamline this and make it > consistent. > > > > Sarvi > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Tuesday, June 07, 2005 5:41 AM > To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) > Subject: Re: [Speechsc] MRCPv2 clarification > > ... which is what my response was going to be until I read: > > > > "or implementations where a > single recognition resource does not support both modes, they > can be > implemented as separate resources and allocated to the same SIP > session with different MRCP session identifiers and share the RTP > audio feed. " > > > > This loosely implies to me that the intent is for parallel hotword > and normal recognition. > > > > While MRCP should of course allow you to do this (forking media to > perform simultaneous recognitions), we should probably clarify , to > avoid confusion, that a single speechrecog is not intended to > support both modes concurrently. > > > > - Dave > > ----- Original Message ----- > > From: Reifenrath, Klaus > > To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) > > Sent: Tuesday, June 07, 2005 1:29 PM > > Subject: RE: [Speechsc] MRCPv2 clarification > > > > Hi Pierre, > > > > "both" does not mean in parallel. But you can use the same resource > to do a "normal" recognition and later use the same resource to > perform a recognition in hotword mode. > > > > Regards, > > Klaus > > > > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Dienstag, 7. Juni 2005 14:12 > To: IETF SPEECHSC (E-mail) > Subject: [Speechsc] MRCPv2 clarification > > Section 9 of the MRCPv2 specification includes the following > sentence: "The recognition resource may support recognition in the > normal or hotword modes or both." I'm not sure the same > recognition resource can support "both" because the state machinery > does not allow two concurrent recognition requests to be active, as > also stated in section 9.9 "If the resource is in the recognizing > state, the RECOGNIZE request MUST respond with a failure status" > > > It is probably safer/simpler to assume hotword recognition will be > done by a separate recognition resource. The mention of "both" > should then be removed from the spec. > > > > Pierre > > > > > > _______________________________________________ > 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 14:43:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfj2a-0003oM-DT; Tue, 07 Jun 2005 14:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfj2Z-0003oH-Dx for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 14:43: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 OAA20564 for ; Tue, 7 Jun 2005 14:43:05 -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 1DfjNf-0001vI-PJ for speechsc@ietf.org; Tue, 07 Jun 2005 15:04:56 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 11:42:57 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="275523521:sNHT209874520" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j57Igqlw019170; Tue, 7 Jun 2005 11:42:52 -0700 (PDT) Received: from [128.107.165.82] (dhcp-128-107-165-82.cisco.com [128.107.165.82]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j57IV0Vr024904; Tue, 7 Jun 2005 11:31:00 -0700 In-Reply-To: <6677B3346233B94EBB11C060935101200B770713@vtg-um-e2k1.sj21ad.cisco.com> References: <6677B3346233B94EBB11C060935101200B770713@vtg-um-e2k1.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <64DFDE91-C3B8-47EB-9889-DB5599F2A73D@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] RECORD method Date: Tue, 7 Jun 2005 14:42:52 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118169060.711812"; x:"432200"; a:"rsa-sha1"; b:"nofws:1599"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ThTXdOo9rfjGkdTamA6Gmd3vWwsGrx+C62j8cHnpjjQVug+K/hLR2SfdnR3ahxTy3GMSynGr" "/0ow4qIoND9/vh3Z5+yZ3s02cYjdAeDBo3/h/ZqsVi+lsWSXha9UWqBrhIy5ajgNXxKhLUUohUK" "r6CsVR1J7boYv7i3Kn1o6PUQ="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] RECORD method"; c:"Date: Tue, 7 Jun 2005 14:42:52 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 On Jun 7, 2005, at 2:32 PM, Shanmugham, Saravanan wrote: > I think we want to allow for HTTP as well. So, "MUST HTTPS and SHOULD > HTTP" would be fine with me. > But then the recordings are transferred in an insecure manner, so encouraging HTTP is not what we want to do. I don't think this is a practical issue though, because it's very difficult to imagine an implementation that can do HTTPS and not HTTP. > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran > Sent: Tuesday, June 07, 2005 8:29 AM > To: speechsc@ietf.org ((((E-mail)))) > Subject: [Speechsc] RECORD method > > the text says: > > "The RECORD request places the recorder resource in the > Recording state. Depending on the headers specified in the > RECORD method the resource may start recording the audio > immediately or wait for the end pointing functionality to > detect speech in the audio. It then saves the audio to the > URI supplied in the recording-uri header. If the > recording-uri is not specified, the server MUST capture > the media onto a local disk and return a URI pointing to > the recorded audio in the RECORD-COMPLETE event. The > server MUST support HTTP and file URI schemes." > > Sorry, but a file: URI won't work - it's not generally > usable between systems. Because of this and the secuirty > issues, the last sentence probably ought to be: > > "The server MUST support the HTTPS URI scheme and MAY > support other schemes. Note that due to the sensitive > nature of voice recordings, any other URI schemes > supported by the server SHOULD employ integrity and > confidentiality on the data transfer (e.g. FTPS)." > > I changed the text, so let me know if this is going to > cause heartburn. > > dave. > > > _______________________________________________ > 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 Tue Jun 07 14:49:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfj8Y-0005UJ-Bn; Tue, 07 Jun 2005 14:49:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfj8W-0005R6-LJ; Tue, 07 Jun 2005 14:49:16 -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 OAA21158; Tue, 7 Jun 2005 14:49:14 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfjTZ-00023x-CS; Tue, 07 Jun 2005 15:11:05 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j57Imr9q649780; Tue, 7 Jun 2005 14:48:53 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j57ImqC7185510; Tue, 7 Jun 2005 12:48:52 -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 j57ImqP6020753; Tue, 7 Jun 2005 12:48:52 -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 j57Imq95020742; Tue, 7 Jun 2005 12:48:52 -0600 In-Reply-To: <6677B3346233B94EBB11C060935101200B770713@vtg-um-e2k1.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] RECORD method X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Tue, 7 Jun 2005 14:48:50 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/07/2005 12:48:51, Serialize complete at 06/07/2005 12:48:51 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: speechsc@ietf.org, "David R. Oran" , speechsc-bounces@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 only comment I have is to keep the wording consistent throughput the specification. I would be careful in the deviation of terminology across sections. For example in section: 8.5. Synthesizer Message Body Synthesizer Speech Data Lexicon Data .. .. ... All media servers MUST support the HTTP uri access mechanism. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" Sent by: speechsc-bounces@ietf.org 06/07/2005 02:32 PM To "David R. Oran" , cc Subject RE: [Speechsc] RECORD method I think we want to allow for HTTP as well. So, "MUST HTTPS and SHOULD HTTP" would be fine with me. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Tuesday, June 07, 2005 8:29 AM To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] RECORD method the text says: "The RECORD request places the recorder resource in the Recording state. Depending on the headers specified in the RECORD method the resource may start recording the audio immediately or wait for the end pointing functionality to detect speech in the audio. It then saves the audio to the URI supplied in the recording-uri header. If the recording-uri is not specified, the server MUST capture the media onto a local disk and return a URI pointing to the recorded audio in the RECORD-COMPLETE event. The server MUST support HTTP and file URI schemes." Sorry, but a file: URI won't work - it's not generally usable between systems. Because of this and the secuirty issues, the last sentence probably ought to be: "The server MUST support the HTTPS URI scheme and MAY support other schemes. Note that due to the sensitive nature of voice recordings, any other URI schemes supported by the server SHOULD employ integrity and confidentiality on the data transfer (e.g. FTPS)." I changed the text, so let me know if this is going to cause heartburn. dave. _______________________________________________ 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 Tue Jun 07 14:53:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjCr-00068o-KK; Tue, 07 Jun 2005 14:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjCn-000687-Va; Tue, 07 Jun 2005 14:53: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 OAA21459; Tue, 7 Jun 2005 14:53:40 -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 1DfjXu-0002An-HY; Tue, 07 Jun 2005 15:15:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 11:53:32 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="275528553:sNHT30636148" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j57IrQbw006632; Tue, 7 Jun 2005 11:53:27 -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] RECORD method Date: Tue, 7 Jun 2005 11:55:31 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B770732@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] RECORD method Thread-Index: AcVrkgtKYpX9t9/aRwaKrop5OVHdzAAABT9Q From: "Shanmugham, Saravanan" To: "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "David R. Oran" , speechsc-bounces@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 You are refering to the capability of the Media servers capability to access another webserver(HTTP client capability). This thread is about the Media server being capable of recording the audio locally and providing HTTP server access to that recorder content. Sarvi -----Original Message----- From: Brett Gavagni [mailto:gavagni@us.ibm.com]=20 Sent: Tuesday, June 07, 2005 11:49 AM To: Shanmugham, Saravanan Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org Subject: RE: [Speechsc] RECORD method =20 The only comment I have is to keep the wording consistent=20 throughput the specification. I would be careful in the=20 deviation of terminology across sections.=20 =20 For example in section: 8.5. Synthesizer Message Body=20 =20 Synthesizer Speech Data Lexicon Data .. .. ... All media servers MUST support the=20 HTTP uri access mechanism.=20 =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 "Shanmugham, Saravanan" Sent by:=20 speechsc-bounces@ietf.org 06/07/2005 02:32 PM =20 To "David R. Oran" , cc =20 Subject RE: [Speechsc] RECORD method =20 =20 =20 =20 =20 =20 I think we want to allow for HTTP as well. So, "MUST=20 HTTPS and SHOULD HTTP" would be fine with me. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Tuesday, June 07, 2005 8:29 AM To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] RECORD method =20 the text says: =20 "The RECORD request places the recorder resource in the=20 Recording state. Depending on the headers specified in the=20 RECORD method the resource may start recording the audio=20 immediately or wait for the end pointing functionality to=20 detect speech in the audio. It then saves the audio to the=20 URI supplied in the recording-uri header. If the=20 recording-uri is not specified, the server MUST capture=20 the media onto a local disk and return a URI pointing to=20 the recorded audio in the RECORD-COMPLETE event. The=20 server MUST support HTTP and file URI schemes." =20 Sorry, but a file: URI won't work - it's not generally=20 usable between systems. Because of this and the secuirty=20 issues, the last sentence probably ought to be: =20 "The server MUST support the HTTPS URI scheme and MAY=20 support other schemes. Note that due to the sensitive=20 nature of voice recordings, any other URI schemes=20 supported by the server SHOULD employ integrity and=20 confidentiality on the data transfer (e.g. FTPS)." =20 I changed the text, so let me know if this is going to=20 cause heartburn. =20 dave. =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =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 Tue Jun 07 15:04:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjNH-00086o-0B; Tue, 07 Jun 2005 15:04:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjNE-00086e-Uf for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 15:04: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 PAA22366 for ; Tue, 7 Jun 2005 15:04:27 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfjiE-0002OS-Sq for speechsc@ietf.org; Tue, 07 Jun 2005 15:26:18 -0400 Received: from daburkewxp (unknown [10.0.0.140]) by mail.voxpilot.com (Postfix) with ESMTP id 3215A214041; Tue, 7 Jun 2005 19:03:52 +0000 (GMT) Message-ID: <0d6501c56b93$a5892400$a800000a@db01.voxpilot.com> From: "Dave Burke" To: "David R. Oran" , "Shanmugham, Saravanan" References: <6677B3346233B94EBB11C060935101200B77060B@vtg-um-e2k1.sj21ad.cisco.com> <3F04928F-6B5D-46DE-A662-F21FF096E83A@cisco.com> Subject: Re: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 20:03:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , Pierre Forgues , "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 Better again - works for me. ----- Original Message ----- From: "David R. Oran" To: "Shanmugham, Saravanan" Cc: "IETF SPEECHSC (E-mail)" ; "Pierre Forgues" ; "Reifenrath, Klaus" ; "Dave Burke" Sent: Tuesday, June 07, 2005 7:34 PM Subject: Re: [Speechsc] MRCPv2 clarification > Since I have the editing token at the moment, I decided to just deal with > this now. I tweaked the text slightly to fit in better with the rest of > the paragraph, so it now reads: > > "The "speechrecog" can recognize regular speech as well as DTMF digits > and hence SHOULD support grammars describing either speech or DTMF. The > recognition resource may support recognition in the normal or hotword > modes or both (although note that a single speechrecog resource does not > perform normal and hotword mode recognitions simultaneously). For > implementations where a single recognition resource does not support both > modes, or simultaneous normal and hotword recognition is desired, the two > modes can be invoked through separate resources and allocated to the same > SIP dialog with different MRCP session identifiers and share the RTP > audio feed." > > On Jun 7, 2005, at 10:54 AM, Shanmugham, Saravanan wrote: > >> thats sounds fine with me. >> >> Sarvi >> >> From: Pierre Forgues [mailto:forgues@nuance.com] >> Sent: Tuesday, June 07, 2005 7:26 AM >> To: Dave Burke; Shanmugham, Saravanan; Reifenrath, Klaus; IETF SPEECHSC >> (E-mail) >> Subject: RE: [Speechsc] MRCPv2 clarification >> >> That would suit me fine. Thanks. /Pierre >> >> >> >> From: Dave Burke [mailto:david.burke@voxpilot.com] >> Sent: Tuesday, June 07, 2005 10:26 AM >> To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF >> SPEECHSC (E-mail) >> Subject: Re: [Speechsc] MRCPv2 clarification >> >> >> >> How about adding the clarification in parenthesis: >> >> >> >> "The recognition resource may support recognition in the normal or >> hotword modes or both (although note that a single speechrecog >> resource does not perform normal and hotword mode recognitions in >> parallel)". >> >> >> >> Dave >> >> ----- Original Message ----- >> >> From: Pierre Forgues >> >> To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF >> SPEECHSC (E-mail) >> >> Sent: Tuesday, June 07, 2005 3:15 PM >> >> Subject: RE: [Speechsc] MRCPv2 clarification >> >> >> >> Anyway, the majority of vendors will be implementing hotword using a >> separate resource because it does imply a concurrent recognition on the >> same media stream. I just think we need to clarify that when a single >> recognition resource is used for hotword or normal mode, that they >> cannot both be used concurrently. The statement at the beginning of >> section 9 is not clear in that respect. >> >> >> >> Pierre >> >> >> >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >> Sent: Tuesday, June 07, 2005 10:15 AM >> To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E- >> mail) >> Subject: RE: [Speechsc] MRCPv2 clarification >> >> >> >> This was not not imply parallel recognition. If I remember right this >> wording was added specifically accomodate some recognition resources >> that may not be capable of both normal and hot word recognition. Some >> vendors might have implemented them as 2 separate resources. >> >> >> >> If you are refering to the statement to return failure when the >> recognizer is in the RECOGNIZING state, this was also why we have >> created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an >> active RECOGNIZE command and go active. >> >> Anyway, this text describing queing/cancelling/stopping of requests is >> being clarified based on Dave's request and I had sent a text proposal >> to do that. That would streamline this and make it consistent. >> >> >> >> Sarvi >> >> >> >> From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On >> Behalf Of Dave Burke >> Sent: Tuesday, June 07, 2005 5:41 AM >> To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) >> Subject: Re: [Speechsc] MRCPv2 clarification >> >> ... which is what my response was going to be until I read: >> >> >> >> "or implementations where a >> single recognition resource does not support both modes, they can be >> implemented as separate resources and allocated to the same SIP >> session with different MRCP session identifiers and share the RTP >> audio feed. " >> >> >> >> This loosely implies to me that the intent is for parallel hotword and >> normal recognition. >> >> >> >> While MRCP should of course allow you to do this (forking media to >> perform simultaneous recognitions), we should probably clarify , to >> avoid confusion, that a single speechrecog is not intended to support >> both modes concurrently. >> >> >> >> - Dave >> >> ----- Original Message ----- >> >> From: Reifenrath, Klaus >> >> To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) >> >> Sent: Tuesday, June 07, 2005 1:29 PM >> >> Subject: RE: [Speechsc] MRCPv2 clarification >> >> >> >> Hi Pierre, >> >> >> >> "both" does not mean in parallel. But you can use the same resource to >> do a "normal" recognition and later use the same resource to perform a >> recognition in hotword mode. >> >> >> >> Regards, >> >> Klaus >> >> >> >> From: Pierre Forgues [mailto:forgues@nuance.com] >> Sent: Dienstag, 7. Juni 2005 14:12 >> To: IETF SPEECHSC (E-mail) >> Subject: [Speechsc] MRCPv2 clarification >> >> Section 9 of the MRCPv2 specification includes the following sentence: >> "The recognition resource may support recognition in the normal or >> hotword modes or both." I'm not sure the same recognition resource can >> support "both" because the state machinery does not allow two concurrent >> recognition requests to be active, as also stated in section 9.9 "If the >> resource is in the recognizing state, the RECOGNIZE request MUST respond >> with a failure status" >> >> >> It is probably safer/simpler to assume hotword recognition will be done >> by a separate recognition resource. The mention of "both" should then >> be removed from the spec. >> >> >> >> Pierre >> >> >> >> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 Tue Jun 07 15:07:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjQC-0008P2-6q; Tue, 07 Jun 2005 15:07:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjQB-0008Ox-JJ for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 15:07:31 -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 PAA22728 for ; Tue, 7 Jun 2005 15:07:29 -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 1DfjlI-0002SY-AV for speechsc@ietf.org; Tue, 07 Jun 2005 15:29:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 12:07:22 -0700 X-IronPort-AV: i="3.93,179,1115017200"; d="scan'208"; a="275535792:sNHT29943142" Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j57J7Jlq020255; Tue, 7 Jun 2005 12:07:20 -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] Managing big grammars Date: Tue, 7 Jun 2005 12:09:22 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B77073C@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcViN/7/+LgJIrsRRSSKgsjWxzIA7QJWv9Vw From: "Shanmugham, Saravanan" To: "Corby Anderson" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Sorry for the late reply. The way I think this should be addressed is to have support for compiled grammars as URI. All Large or Huge grammars are going to be URI referenced and never embedded in a DEFINE grammar.=20 This means that the URI could point to compiled grammar file. Another way is to use the chache capability. When you access a grammar through HTTP is to cache it. In general instead of caching of the XML grammar you could decide to cache the compiled version instead. This would mean that you might do an initial DEFINE-GRAMMAR to force a compile of the grammar and future references to that grammar URI would hit the cache and hence the compiled version. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Thursday, May 26, 2005 2:11 PM To: Speechsc@ietf.org Subject: [Speechsc] Managing big grammars =20 What are folks' thoughts on how we could manage big=20 grammars with MRCP? =20 There are two usage cases that I'm interested in: a Large=20 Grammar that takes several seconds to compile, and a Jumbo=20 Grammar that takes many many minutes to compile. A Large=20 Grammar might contain several hundred or thousand entries.=20 A Jumbo Grammar might contain hundreds of thousands of entries. =20 For a Jumbo Grammar, there's no way that a user can wait=20 for a grammar to be uploaded and compiled via the=20 DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large=20 needs to be pre-compiled so that the DEFINE-GRAMMAR or=20 RECOGNIZE method can simply load the grammar binary. =20 For a Large Grammar, it might be okay to make one user=20 wait a few seconds for the grammar to compile -- but it=20 would be a big win if that compiled grammar were stored=20 with a known name so that /subsequent/ uses of the same=20 grammar don't have to pay the same compilation penalty. =20 Our current speech recognition vendor's api provides=20 methods for checking for the existence of a dynamic=20 grammar, and for compiling a new grammar (named as the=20 client specifies). The api also provides a powerful and=20 flexible way to manage these stored grammars. Is there=20 some MRCP-friendly way for dealing with these types of=20 grammars? If not, then is one being considered? =20 Corby Anderson Tellme Networks, Inc. =20 =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 Tue Jun 07 15:15:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjXY-0001Jm-Rj; Tue, 07 Jun 2005 15:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjXX-0001Jg-Hd for speechsc@megatron.ietf.org; Tue, 07 Jun 2005 15:15: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 PAA23844 for ; Tue, 7 Jun 2005 15:15:05 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfjsc-0002d5-5B for speechsc@ietf.org; Tue, 07 Jun 2005 15:36:56 -0400 Received: from postcard.nuance.com ([10.3.6.20]:20332) by letter.nuance.com with esmtp id 1DfjXL-000576-JM; Tue, 07 Jun 2005 12:14:55 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 7 Jun 2005 15:13:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 clarification Date: Tue, 7 Jun 2005 15:13:12 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802CFBD0F@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] MRCPv2 clarification Thread-Index: AcVrj2rKtJ7ierRZRLCYXcKGyN/5TQABX6KQ From: "Pierre Forgues" To: "David R. Oran" , "Shanmugham, Saravanan" X-OriginalArrivalTime: 07 Jun 2005 19:13:14.0037 (UTC) FILETIME=[F3D96650:01C56B94] X-FromHost: postcard.nuance.com [10.3.6.20]:20332 Lines: 226 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , "Reifenrath, Klaus" , Dave Burke 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 Couldn't have said it better myself. Thanks! /Pierre -----Original Message----- From: David R. Oran [mailto:oran@cisco.com]=20 Sent: Tuesday, June 07, 2005 2:35 PM To: Shanmugham, Saravanan Cc: Pierre Forgues; Dave Burke; Reifenrath, Klaus; IETF SPEECHSC (E-mail) Subject: Re: [Speechsc] MRCPv2 clarification Since I have the editing token at the moment, I decided to just deal =20 with this now. I tweaked the text slightly to fit in better with the =20 rest of the paragraph, so it now reads: "The "speechrecog" can recognize regular speech as well as DTMF =20 digits and hence SHOULD support grammars describing either speech or =20 DTMF. The recognition resource may support recognition in the normal =20 or hotword modes or both (although note that a single speechrecog =20 resource does not perform normal and hotword mode recognitions =20 simultaneously). For implementations where a single recognition =20 resource does not support both modes, or simultaneous normal and =20 hotword recognition is desired, the two modes can be invoked through =20 separate resources and allocated to the same SIP dialog with =20 different MRCP session identifiers and share the RTP audio feed." On Jun 7, 2005, at 10:54 AM, Shanmugham, Saravanan wrote: > thats sounds fine with me. > > Sarvi > > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Tuesday, June 07, 2005 7:26 AM > To: Dave Burke; Shanmugham, Saravanan; Reifenrath, Klaus; IETF =20 > SPEECHSC (E-mail) > Subject: RE: [Speechsc] MRCPv2 clarification > > That would suit me fine. Thanks. /Pierre > > > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 07, 2005 10:26 AM > To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF =20 > SPEECHSC (E-mail) > Subject: Re: [Speechsc] MRCPv2 clarification > > > > How about adding the clarification in parenthesis: > > > > "The recognition resource may support recognition in the normal or =20 > hotword modes or both (although note that a single speechrecog =20 > resource does not perform normal and hotword mode recognitions in =20 > parallel)". > > > > Dave > > ----- Original Message ----- > > From: Pierre Forgues > > To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF =20 > SPEECHSC (E-mail) > > Sent: Tuesday, June 07, 2005 3:15 PM > > Subject: RE: [Speechsc] MRCPv2 clarification > > > > Anyway, the majority of vendors will be implementing hotword using =20 > a separate resource because it does imply a concurrent recognition =20 > on the same media stream. I just think we need to clarify that =20 > when a single recognition resource is used for hotword or normal =20 > mode, that they cannot both be used concurrently. The statement at =20 > the beginning of section 9 is not clear in that respect. > > > > Pierre > > > > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Tuesday, June 07, 2005 10:15 AM > To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E-=20 > mail) > Subject: RE: [Speechsc] MRCPv2 clarification > > > > This was not not imply parallel recognition. If I remember right =20 > this wording was added specifically accomodate some recognition =20 > resources that may not be capable of both normal and hot word =20 > recognition. Some vendors might have implemented them as 2 separate =20 > resources. > > > > If you are refering to the statement to return failure when the =20 > recognizer is in the RECOGNIZING state, this was also why we have =20 > created Cancel-If-Queue header to allow a RECOGNIZE command to =20 > cancel an active RECOGNIZE command and go active. > > Anyway, this text describing queing/cancelling/stopping of requests =20 > is being clarified based on Dave's request and I had sent a text =20 > proposal to do that. That would streamline this and make it =20 > consistent. > > > > Sarvi > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] =20 > On Behalf Of Dave Burke > Sent: Tuesday, June 07, 2005 5:41 AM > To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail) > Subject: Re: [Speechsc] MRCPv2 clarification > > ... which is what my response was going to be until I read: > > > > "or implementations where a > single recognition resource does not support both modes, they =20 > can be > implemented as separate resources and allocated to the same SIP > session with different MRCP session identifiers and share the RTP > audio feed. " > > > > This loosely implies to me that the intent is for parallel hotword =20 > and normal recognition. > > > > While MRCP should of course allow you to do this (forking media to =20 > perform simultaneous recognitions), we should probably clarify , to =20 > avoid confusion, that a single speechrecog is not intended to =20 > support both modes concurrently. > > > > - Dave > > ----- Original Message ----- > > From: Reifenrath, Klaus > > To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail) > > Sent: Tuesday, June 07, 2005 1:29 PM > > Subject: RE: [Speechsc] MRCPv2 clarification > > > > Hi Pierre, > > > > "both" does not mean in parallel. But you can use the same resource =20 > to do a "normal" recognition and later use the same resource to =20 > perform a recognition in hotword mode. > > > > Regards, > > Klaus > > > > From: Pierre Forgues [mailto:forgues@nuance.com] > Sent: Dienstag, 7. Juni 2005 14:12 > To: IETF SPEECHSC (E-mail) > Subject: [Speechsc] MRCPv2 clarification > > Section 9 of the MRCPv2 specification includes the following =20 > sentence: "The recognition resource may support recognition in the =20 > normal or hotword modes or both." I'm not sure the same =20 > recognition resource can support "both" because the state machinery =20 > does not allow two concurrent recognition requests to be active, as =20 > also stated in section 9.9 "If the resource is in the recognizing =20 > state, the RECOGNIZE request MUST respond with a failure status" > > > It is probably safer/simpler to assume hotword recognition will be =20 > done by a separate recognition resource. The mention of "both" =20 > should then be removed from the spec. > > > > Pierre > > > > > > _______________________________________________ > 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 > =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 07 15:23:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfjfp-00031B-5o; Tue, 07 Jun 2005 15:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfjfn-000313-Qx; Tue, 07 Jun 2005 15:23:39 -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 PAA24938; Tue, 7 Jun 2005 15:23:35 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfk0q-0002qo-EK; Tue, 07 Jun 2005 15:45:26 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j57JNImD192334; Tue, 7 Jun 2005 15:23:18 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j57JNHC7102106; Tue, 7 Jun 2005 13:23:17 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j57JNHZN000974; Tue, 7 Jun 2005 13:23:17 -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 j57JNHZf000967; Tue, 7 Jun 2005 13:23:17 -0600 In-Reply-To: <6677B3346233B94EBB11C060935101200B770732@vtg-um-e2k1.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] RECORD method X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Tue, 7 Jun 2005 15:23:15 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/07/2005 13:23:16, Serialize complete at 06/07/2005 13:23:16 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: speechsc@ietf.org, "David R. Oran" , speechsc-bounces@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, I'm requesting consistent wording throughout the sections of the specification. The specification becomes increasingly convoluted with protocol requirements that vary or are inconsistent in different sections. One could argue that the MRCP client and server implementation could coexist at the same logical network address and the security overhead implications/requirements are redundant in particular isolated scenarios. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 06/07/2005 02:55 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" , , Subject RE: [Speechsc] RECORD method You are refering to the capability of the Media servers capability to access another webserver(HTTP client capability). This thread is about the Media server being capable of recording the audio locally and providing HTTP server access to that recorder content. Sarvi -----Original Message----- From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Tuesday, June 07, 2005 11:49 AM To: Shanmugham, Saravanan Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org Subject: RE: [Speechsc] RECORD method The only comment I have is to keep the wording consistent throughout the specification. I would be careful in the deviation of terminology across sections. For example in section: 8.5. Synthesizer Message Body Synthesizer Speech Data Lexicon Data .. .. ... All media servers MUST support the HTTP uri access mechanism. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" Sent by: speechsc-bounces@ietf.org 06/07/2005 02:32 PM To "David R. Oran" , cc Subject RE: [Speechsc] RECORD method I think we want to allow for HTTP as well. So, "MUST HTTPS and SHOULD HTTP" would be fine with me. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Tuesday, June 07, 2005 8:29 AM To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] RECORD method the text says: "The RECORD request places the recorder resource in the Recording state. Depending on the headers specified in the RECORD method the resource may start recording the audio immediately or wait for the end pointing functionality to detect speech in the audio. It then saves the audio to the URI supplied in the recording-uri header. If the recording-uri is not specified, the server MUST capture the media onto a local disk and return a URI pointing to the recorded audio in the RECORD-COMPLETE event. The server MUST support HTTP and file URI schemes." Sorry, but a file: URI won't work - it's not generally usable between systems. Because of this and the secuirty issues, the last sentence probably ought to be: "The server MUST support the HTTPS URI scheme and MAY support other schemes. Note that due to the sensitive nature of voice recordings, any other URI schemes supported by the server SHOULD employ integrity and confidentiality on the data transfer (e.g. FTPS)." I changed the text, so let me know if this is going to cause heartburn. dave. _______________________________________________ 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 Tue Jun 07 16:23:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfkbj-00041t-KT; Tue, 07 Jun 2005 16:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfkbh-00041T-Jt; Tue, 07 Jun 2005 16:23: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 QAA06190; Tue, 7 Jun 2005 16:23:27 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfkwn-0006ZW-Sk; Tue, 07 Jun 2005 16:45:18 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j57KNFmD528074; Tue, 7 Jun 2005 16:23:16 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j57KNF67238572; Tue, 7 Jun 2005 14:23:15 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j57KNFmp017847; Tue, 7 Jun 2005 14:23:15 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j57KNFuX017842; Tue, 7 Jun 2005 14:23:15 -0600 In-Reply-To: <879605B8-AD23-49C7-8AC9-831B1B03F99E@cisco.com> To: "David R. Oran" MIME-Version: 1.0 Subject: Re: [Speechsc] "Race" condition between RECOGNIZE.request and media X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Tue, 7 Jun 2005 16:23:13 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/07/2005 14:23:15, Serialize complete at 06/07/2005 14:23:15 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" , speechsc-bounces@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 would vote to leave the wording, or at a minimum keep the following line. This statement can be quite helpful in mitigating potential client/server interoperability issues. "The recognizer should expect the media to start flowing when it receives the recognize request, but should not buffer anything it receives beforehand." Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "David R. Oran" Sent by: speechsc-bounces@ietf.org 06/07/2005 09:53 AM To "speechsc@ietf.org ((((E-mail))))" cc Subject [Speechsc] "Race" condition between RECOGNIZE.request and media The text says: "Note that since the audio and the messages are carried over separate communication paths there may be a race condition between the start of the flow of audio and the receipt of the RECOGNIZE method. For example, if an audio flow is started by the client at the same time as the RECOGNIZE method is sent, either the audio or the RECOGNIZE can arrive at the recognizer first. As another example, the client may chose to continuously send audio to the Server and signal the Server to recognize using the RECOGNIZE method. A number of mechanisms exist to resolve this condition and the mechanism chosen is left to the implementers of recognition resource. The recognizer should expect the media to start flowing when it receives the recognize request, but should not buffer anything it receives beforehand." Either this race condition doesn't matter, in which case we should either just nuke this paragraph or take out the should/should not guidance at the end, or it does matter, in which case this material is wholly inadequate. If the synchronization of the control and media channels matters, then we really do need to fix the protocol. Luckily, this is relatively easy to do: a) recommend that servers with recognizers buffer at least an RTT worth of media. b) include an NTP timestamp of where in the the input media recognition should start in a RECOGNIZE request header. c) define an error to cover the "lost media" case. My gut tells me that for recognition none of this is necessary and we should just nuke the paragraph above as making implementers think about something they can only screw up if they work too hard at it. _______________________________________________ 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 Tue Jun 07 17:43:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dflqg-00081B-J0; Tue, 07 Jun 2005 17:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dflqc-0007xq-Hl; Tue, 07 Jun 2005 17:43:00 -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 RAA16164; Tue, 7 Jun 2005 17:42:55 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfmBk-0001Uj-KM; Tue, 07 Jun 2005 18:04:48 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j57LgoKO015568; Tue, 7 Jun 2005 16:42:51 -0500 (CDT) Received: from [135.104.32.232] (bass.research.bell-labs.com [135.104.32.232]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j57LgoP21919; Tue, 7 Jun 2005 17:42:50 -0400 (EDT) Message-ID: <42A614DA.6040106@research.bell-labs.com> Date: Tue, 07 Jun 2005 17:42:50 -0400 From: Qiru Zhou Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: Brett Gavagni Subject: Re: [Speechsc] "Race" condition between RECOGNIZE.request and media References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070803080606090506010105" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" , speechsc-bounces@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qzhou@research.bell-labs.com 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 This is a multi-part message in MIME format. --------------070803080606090506010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To me, this line implies that RECOGNIZE is the trigger signal to let recognizer to start listening (buffer and do recognition). It is not clear to me why the recognizer need to buffer audio before the RECOGNIZE message and it is ambiguous to do that (how early and how much data). A particular implementation may choose to do something like that for signal processing purpose I guess but it is the implementation detail. So I'd vote keep the line below and nuke the rest. Therefore, no race condition exist. -- Qiru Brett Gavagni wrote: > I would vote to leave the wording, or at a minimum keep the following > line. This statement can be quite helpful in mitigating potential > client/server interoperability issues. > > "The recognizer should expect the media to start flowing when it receives > the > recognize request, but should not buffer anything it receives beforehand." > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "David R. Oran" > Sent by: speechsc-bounces@ietf.org > 06/07/2005 09:53 AM > > To > "speechsc@ietf.org ((((E-mail))))" > cc > > Subject > [Speechsc] "Race" condition between RECOGNIZE.request and media > > > > > > > The text says: > > "Note that since the audio and the messages are carried over separate > communication paths there may be a race condition between the start > of the flow of audio and the receipt of the RECOGNIZE method. For > example, if an audio flow is started by the client at the same time > as the RECOGNIZE method is sent, either the audio or the RECOGNIZE > can arrive at the recognizer first. As another example, the client > may chose to continuously send audio to the Server and signal the > Server to recognize using the RECOGNIZE method. A number of > mechanisms exist to resolve this condition and the mechanism chosen > is left to the implementers of recognition resource. The recognizer > should expect the media to start flowing when it receives the > recognize request, but should not buffer anything it receives > beforehand." > > Either this race condition doesn't matter, in which case we should > either just nuke this paragraph or take out the should/should not > guidance at the end, or it does matter, in which case this material > is wholly inadequate. > > If the synchronization of the control and media channels matters, > then we really do need to fix the protocol. Luckily, this is > relatively easy to do: > > a) recommend that servers with recognizers buffer at least an RTT > worth of media. > b) include an NTP timestamp of where in the the input media > recognition should start in a RECOGNIZE request header. > c) define an error to cover the "lost media" case. > > My gut tells me that for recognition none of this is necessary and we > should just nuke the paragraph above as making implementers think > about something they can only screw up if they work too hard at it. > > _______________________________________________ > 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 > --------------070803080606090506010105 Content-Type: text/x-vcard; charset=utf-8; name="qzhou.vcf" Content-Disposition: attachment; filename="qzhou.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Qiru Zhou n:Zhou;Qiru org:;Converged Networks and Services Research Laboratory email;internet:W:\qzhou\Thunderbird\qzhou_BL.txt title:MTS tel;work:+1 908 582 4562 tel;fax:+1 908 582 7308 x-mozilla-html:FALSE version:2.1 end:vcard --------------070803080606090506010105 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 --------------070803080606090506010105-- From speechsc-bounces@ietf.org Tue Jun 07 17:44:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflsJ-0008QW-R9; Tue, 07 Jun 2005 17:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflsI-0008QM-0G; Tue, 07 Jun 2005 17:44:42 -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 RAA16257; Tue, 7 Jun 2005 17:44:39 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfmDQ-0001WT-48; Tue, 07 Jun 2005 18:06:32 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j57Lic0f014849; Tue, 7 Jun 2005 16:44:39 -0500 (CDT) Received: from [135.104.32.232] (bass.research.bell-labs.com [135.104.32.232]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j57LicP22717; Tue, 7 Jun 2005 17:44:38 -0400 (EDT) Message-ID: <42A61546.2000600@research.bell-labs.com> Date: Tue, 07 Jun 2005 17:44:38 -0400 From: Qiru Zhou Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: Brett Gavagni Subject: Re: [Speechsc] "Race" condition between RECOGNIZE.request and media References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070203080102030805090102" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" , speechsc-bounces@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qzhou@research.bell-labs.com 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 This is a multi-part message in MIME format. --------------070203080102030805090102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To me, this line implies that RECOGNIZE is the trigger signal to let recognizer to start listening (buffer and do recognition). It is not clear to me why the recognizer need to buffer audio before the RECOGNIZE message and it is ambiguous to do that (how early and how much data to buffer). A particular implementation may choose to do something like that for signal processing purpose I guess but it is the implementation detail. So I'd vote keep the line below and nuke the rest. -- Qiru Brett Gavagni wrote: > I would vote to leave the wording, or at a minimum keep the following > line. This statement can be quite helpful in mitigating potential > client/server interoperability issues. > > "The recognizer should expect the media to start flowing when it receives > the > recognize request, but should not buffer anything it receives beforehand." > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "David R. Oran" > Sent by: speechsc-bounces@ietf.org > 06/07/2005 09:53 AM > > To > "speechsc@ietf.org ((((E-mail))))" > cc > > Subject > [Speechsc] "Race" condition between RECOGNIZE.request and media > > > > > > > The text says: > > "Note that since the audio and the messages are carried over separate > communication paths there may be a race condition between the start > of the flow of audio and the receipt of the RECOGNIZE method. For > example, if an audio flow is started by the client at the same time > as the RECOGNIZE method is sent, either the audio or the RECOGNIZE > can arrive at the recognizer first. As another example, the client > may chose to continuously send audio to the Server and signal the > Server to recognize using the RECOGNIZE method. A number of > mechanisms exist to resolve this condition and the mechanism chosen > is left to the implementers of recognition resource. The recognizer > should expect the media to start flowing when it receives the > recognize request, but should not buffer anything it receives > beforehand." > > Either this race condition doesn't matter, in which case we should > either just nuke this paragraph or take out the should/should not > guidance at the end, or it does matter, in which case this material > is wholly inadequate. > > If the synchronization of the control and media channels matters, > then we really do need to fix the protocol. Luckily, this is > relatively easy to do: > > a) recommend that servers with recognizers buffer at least an RTT > worth of media. > b) include an NTP timestamp of where in the the input media > recognition should start in a RECOGNIZE request header. > c) define an error to cover the "lost media" case. > > My gut tells me that for recognition none of this is necessary and we > should just nuke the paragraph above as making implementers think > about something they can only screw up if they work too hard at it. > > _______________________________________________ > 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 > --------------070203080102030805090102 Content-Type: text/x-vcard; charset=utf-8; name="qzhou.vcf" Content-Disposition: attachment; filename="qzhou.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Qiru Zhou n:Zhou;Qiru org:;Converged Networks and Services Research Laboratory email;internet:W:\qzhou\Thunderbird\qzhou_BL.txt title:MTS tel;work:+1 908 582 4562 tel;fax:+1 908 582 7308 x-mozilla-html:FALSE version:2.1 end:vcard --------------070203080102030805090102 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 --------------070203080102030805090102-- From speechsc-bounces@ietf.org Tue Jun 07 23:06:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfqty-0008Ez-Mv; Tue, 07 Jun 2005 23:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfqtu-0008Eb-ET; Tue, 07 Jun 2005 23:06: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 XAA13439; Tue, 7 Jun 2005 23:06:39 -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 1DfrF4-0008Ig-0N; Tue, 07 Jun 2005 23:28:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2005 20:06:31 -0700 X-IronPort-AV: i="3.93,180,1115017200"; d="scan'208"; a="275738554:sNHT32367660" 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 j5836Qbw029569; Tue, 7 Jun 2005 20:06:27 -0700 (PDT) Received: from [10.42.4.67] (sjc-vpn7-70.cisco.com [10.21.144.70]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j582sXKZ027994; Tue, 7 Jun 2005 19:54:33 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A22068D-4F80-45B2-95AE-3B1EB70440F7@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] RECORD method Date: Tue, 7 Jun 2005 23:06:26 -0400 To: Brett Gavagni X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118199273.551591"; x:"432200"; a:"rsa-sha1"; b:"nofws:3823"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"mCXds+jBqxg8KnZUwQl2hhRgAjP+/wVX2oSvIv5G2q+n3ow8GhKUBQns5oABu554biS+6mjs" "HIwkJ+RjNlJ2BN35qNQKOkxM4Vvvoc+EcTGeaIo49ZC7ktbqU/a81aSMBizVY3vtrMyxxVGso2t" "57B7hhnEbyaPanWLyGXTC6Pg="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] RECORD method"; c:"Date: Tue, 7 Jun 2005 23:06:26 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , speechsc-bounces@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'm trying in my chair review and editing to rationalize the wording in as many places as I find. Doing this without unintentionally changing the technical content is something which I have to be conservative about though. the example of why HTTP some places and HTTPS other places is an case of where I am reluctant to change anything, because a server with only a speech synthesis engine and no recorder might never need HTTPS, whereas for security reasons HTTPS is mandatory for recorders. I'll let you folks be the judge of success once we get the edited draft out (within a week if all goes well) Dave. On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: > Hi, > > I'm requesting consistent wording throughout the sections of the > specification. > > The specification becomes increasingly convoluted with protocol > requirements that vary or are inconsistent in different sections. > > One could argue that the MRCP client and server implementation could > coexist at the same logical network address and the security overhead > implications/requirements are redundant in particular isolated > scenarios. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Shanmugham, Saravanan" > 06/07/2005 02:55 PM > > To > Brett Gavagni/West Palm Beach/IBM@IBMUS > cc > "David R. Oran" , , > > Subject > RE: [Speechsc] RECORD method > > > > > > > You are refering to the capability of the Media servers capability to > access another webserver(HTTP client capability). > > This thread is about the Media server being capable of recording the > audio locally and providing HTTP server access to that recorder > content. > > Sarvi > > -----Original Message----- > From: Brett Gavagni [mailto:gavagni@us.ibm.com] > Sent: Tuesday, June 07, 2005 11:49 AM > To: Shanmugham, Saravanan > Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org > Subject: RE: [Speechsc] RECORD method > > The only comment I have is to keep the wording consistent > throughout the specification. I would be careful in the > deviation of terminology across sections. > > For example in section: 8.5. Synthesizer Message Body > > Synthesizer Speech Data > Lexicon Data > .. > .. > ... > All media servers MUST support the > HTTP uri access mechanism. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Shanmugham, Saravanan" Sent by: > speechsc-bounces@ietf.org > 06/07/2005 02:32 PM > > To > "David R. Oran" , cc > > Subject > RE: [Speechsc] RECORD method > > > > > > > I think we want to allow for HTTP as well. So, "MUST > HTTPS and SHOULD HTTP" would be fine with me. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. > Oran > Sent: Tuesday, June 07, 2005 8:29 AM > To: speechsc@ietf.org ((((E-mail)))) > Subject: [Speechsc] RECORD method > > the text says: > > "The RECORD request places the recorder resource in the > Recording state. Depending on the headers specified in the > RECORD method the resource may start recording the audio > immediately or wait for the end pointing functionality to > detect speech in the audio. It then saves the audio to the > URI supplied in the recording-uri header. If the > recording-uri is not specified, the server MUST capture > the media onto a local disk and return a URI pointing to > the recorded audio in the RECORD-COMPLETE event. The > server MUST support HTTP and file URI schemes." > > Sorry, but a file: URI won't work - it's not generally > usable between systems. Because of this and the secuirty > issues, the last sentence probably ought to be: > > "The server MUST support the HTTPS URI scheme and MAY > support other schemes. Note that due to the sensitive > nature of voice recordings, any other URI schemes > supported by the server SHOULD employ integrity and > confidentiality on the data transfer (e.g. FTPS)." > > I changed the text, so let me know if this is going to > cause heartburn. > > dave. > > > _______________________________________________ > 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 Jun 08 07:56:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzAV-0004aI-Rk; Wed, 08 Jun 2005 07:56:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzAS-0004ZU-EG for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 07:56: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 HAA18943 for ; Wed, 8 Jun 2005 07:56:16 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfzVe-0001bz-6K for speechsc@ietf.org; Wed, 08 Jun 2005 08:18:15 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 8 Jun 2005 07:56:05 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'qzhou@research.bell-labs.com'" , Brett Gavagni , "'oran@cisco.com'" Subject: RE: [Speechsc] "Race" condition between RECOGNIZE.request and med ia Date: Wed, 8 Jun 2005 07:56:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 also vote for removing the old and fuzzy MRCPv1 text "Note that since the audio and the messages are carried over separate communication paths there may be a race condition between the start of the flow of audio and the receipt of the RECOGNIZE method. For example, if an audio flow is started by the client at the same time as the RECOGNIZE method is sent, either the audio or the RECOGNIZE can arrive at the recognizer first. As another example, the client may chose to continuously send audio to the Server and signal the Server to recognize using the RECOGNIZE method. A number of mechanisms exist to resolve this condition and the mechanism chosen is left to the implementers of recognition resource." BUT I agree with Brett, we should keep the last sentence (that was not in the MRCPv1 spec): "The recognizer should expect the media to start flowing when it receives the recognize request, but should not buffer anything it receives beforehand." BTW: Shouldn't the 'should' be a 'SHOULD' in the last sentence? Klaus -----Original Message----- From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] Sent: Dienstag, 7. Juni 2005 23:45 To: Brett Gavagni Cc: speechsc@ietf.org ((((E-mail)))); speechsc-bounces@ietf.org Subject: Re: [Speechsc] "Race" condition between RECOGNIZE.request and media To me, this line implies that RECOGNIZE is the trigger signal to let recognizer to start listening (buffer and do recognition). It is not clear to me why the recognizer need to buffer audio before the RECOGNIZE message and it is ambiguous to do that (how early and how much data to buffer). A particular implementation may choose to do something like that for signal processing purpose I guess but it is the implementation detail. So I'd vote keep the line below and nuke the rest. -- Qiru Brett Gavagni wrote: > I would vote to leave the wording, or at a minimum keep the following > line. This statement can be quite helpful in mitigating potential > client/server interoperability issues. > > "The recognizer should expect the media to start flowing when it > receives the recognize request, but should not buffer anything it > receives beforehand." > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "David R. Oran" > Sent by: speechsc-bounces@ietf.org > 06/07/2005 09:53 AM > > To > "speechsc@ietf.org ((((E-mail))))" cc > > Subject > [Speechsc] "Race" condition between RECOGNIZE.request and media > > > > > > > The text says: > > "Note that since the audio and the messages are carried over separate > communication paths there may be a race condition between the start of > the flow of audio and the receipt of the RECOGNIZE method. For > example, if an audio flow is started by the client at the same time as > the RECOGNIZE method is sent, either the audio or the RECOGNIZE can > arrive at the recognizer first. As another example, the client may > chose to continuously send audio to the Server and signal the Server > to recognize using the RECOGNIZE method. A number of mechanisms exist > to resolve this condition and the mechanism chosen is left to the > implementers of recognition resource. The recognizer should expect the > media to start flowing when it receives the recognize request, but > should not buffer anything it receives beforehand." > > Either this race condition doesn't matter, in which case we should > either just nuke this paragraph or take out the should/should not > guidance at the end, or it does matter, in which case this material is > wholly inadequate. > > If the synchronization of the control and media channels matters, then > we really do need to fix the protocol. Luckily, this is relatively > easy to do: > > a) recommend that servers with recognizers buffer at least an RTT > worth of media. > b) include an NTP timestamp of where in the the input media > recognition should start in a RECOGNIZE request header. > c) define an error to cover the "lost media" case. > > My gut tells me that for recognition none of this is necessary and we > should just nuke the paragraph above as making implementers think > about something they can only screw up if they work too hard at it. > > _______________________________________________ > 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 Jun 08 08:04:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzHw-0005rP-Jk; Wed, 08 Jun 2005 08:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzHv-0005rH-Hx; Wed, 08 Jun 2005 08:04:03 -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 IAA19895; Wed, 8 Jun 2005 08:04:02 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfzdB-0001rA-5c; Wed, 08 Jun 2005 08:26:01 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 8 Jun 2005 08:03:54 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , Brett Gavagni Subject: RE: [Speechsc] RECORD method Date: Wed, 8 Jun 2005 08:03:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , speechsc-bounces@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 There are use cases where the speech synthesis engine need to speak secret data, in which cases HTTPS would also be required for servers that only have speech synthesis resources. Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Mittwoch, 8. Juni 2005 05:06 To: Brett Gavagni Cc: speechsc@ietf.org; Shanmugham, Saravanan; speechsc-bounces@ietf.org Subject: Re: [Speechsc] RECORD method I'm trying in my chair review and editing to rationalize the wording in as many places as I find. Doing this without unintentionally changing the technical content is something which I have to be conservative about though. the example of why HTTP some places and HTTPS other places is an case of where I am reluctant to change anything, because a server with only a speech synthesis engine and no recorder might never need HTTPS, whereas for security reasons HTTPS is mandatory for recorders. I'll let you folks be the judge of success once we get the edited draft out (within a week if all goes well) Dave. On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: > Hi, > > I'm requesting consistent wording throughout the sections of the > specification. > > The specification becomes increasingly convoluted with protocol > requirements that vary or are inconsistent in different sections. > > One could argue that the MRCP client and server implementation could > coexist at the same logical network address and the security overhead > implications/requirements are redundant in particular isolated > scenarios. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Shanmugham, Saravanan" > 06/07/2005 02:55 PM > > To > Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" > , , > Subject > RE: [Speechsc] RECORD method > > > > > > > You are refering to the capability of the Media servers capability to > access another webserver(HTTP client capability). > > This thread is about the Media server being capable of recording the > audio locally and providing HTTP server access to that recorder > content. > > Sarvi > > -----Original Message----- > From: Brett Gavagni [mailto:gavagni@us.ibm.com] > Sent: Tuesday, June 07, 2005 11:49 AM > To: Shanmugham, Saravanan > Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org > Subject: RE: [Speechsc] RECORD method > > The only comment I have is to keep the wording consistent > throughout the specification. I would be careful in the > deviation of terminology across sections. > > For example in section: 8.5. Synthesizer Message Body > > Synthesizer Speech Data > Lexicon Data > .. > .. > ... > All media servers MUST support the > HTTP uri access mechanism. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Shanmugham, Saravanan" Sent by: > speechsc-bounces@ietf.org > 06/07/2005 02:32 PM > > To > "David R. Oran" , cc > > Subject > RE: [Speechsc] RECORD method > > > > > > > I think we want to allow for HTTP as well. So, "MUST > HTTPS and SHOULD HTTP" would be fine with me. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. > Oran > Sent: Tuesday, June 07, 2005 8:29 AM > To: speechsc@ietf.org ((((E-mail)))) > Subject: [Speechsc] RECORD method > > the text says: > > "The RECORD request places the recorder resource in the > Recording state. Depending on the headers specified in the > RECORD method the resource may start recording the audio > immediately or wait for the end pointing functionality to > detect speech in the audio. It then saves the audio to the > URI supplied in the recording-uri header. If the > recording-uri is not specified, the server MUST capture > the media onto a local disk and return a URI pointing to > the recorded audio in the RECORD-COMPLETE event. The > server MUST support HTTP and file URI schemes." > > Sorry, but a file: URI won't work - it's not generally > usable between systems. Because of this and the secuirty > issues, the last sentence probably ought to be: > > "The server MUST support the HTTPS URI scheme and MAY > support other schemes. Note that due to the sensitive > nature of voice recordings, any other URI schemes > supported by the server SHOULD employ integrity and > confidentiality on the data transfer (e.g. FTPS)." > > I changed the text, so let me know if this is going to > cause heartburn. > > dave. > > > _______________________________________________ > 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 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 08 08:28:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzfR-0001I0-Vq; Wed, 08 Jun 2005 08:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzfQ-0001Hv-Dg for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 08:28:20 -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 IAA21712 for ; Wed, 8 Jun 2005 08:28:19 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg00f-0002Qz-9B for Speechsc@ietf.org; Wed, 08 Jun 2005 08:50:18 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 8 Jun 2005 08:28:09 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Shanmugham, Saravanan'" , Corby Anderson Subject: RE: [Speechsc] Managing big grammars Date: Wed, 8 Jun 2005 08:28:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 agree. BUT unfortunately there is no MRCPv2 interface to just compile a grammar. So grammar compilation needs to be done with vendor specific tools or APIs. We could add a new method (allowed only in idle state): COMPILE-GRAMMAR that requires the header field Compiled-Grammar-URI that specifies the location of the compiled grammar (like Personal-Grammar-URI). Is it too late to add this simple optional method? Klaus -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Dienstag, 7. Juni 2005 21:09 To: Corby Anderson; Speechsc@ietf.org Subject: RE: [Speechsc] Managing big grammars Sorry for the late reply. The way I think this should be addressed is to have support for compiled grammars as URI. All Large or Huge grammars are going to be URI referenced and never embedded in a DEFINE grammar. This means that the URI could point to compiled grammar file. Another way is to use the chache capability. When you access a grammar through HTTP is to cache it. In general instead of caching of the XML grammar you could decide to cache the compiled version instead. This would mean that you might do an initial DEFINE-GRAMMAR to force a compile of the grammar and future references to that grammar URI would hit the cache and hence the compiled version. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Thursday, May 26, 2005 2:11 PM To: Speechsc@ietf.org Subject: [Speechsc] Managing big grammars What are folks' thoughts on how we could manage big grammars with MRCP? There are two usage cases that I'm interested in: a Large Grammar that takes several seconds to compile, and a Jumbo Grammar that takes many many minutes to compile. A Large Grammar might contain several hundred or thousand entries. A Jumbo Grammar might contain hundreds of thousands of entries. For a Jumbo Grammar, there's no way that a user can wait for a grammar to be uploaded and compiled via the DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large needs to be pre-compiled so that the DEFINE-GRAMMAR or RECOGNIZE method can simply load the grammar binary. For a Large Grammar, it might be okay to make one user wait a few seconds for the grammar to compile -- but it would be a big win if that compiled grammar were stored with a known name so that /subsequent/ uses of the same grammar don't have to pay the same compilation penalty. Our current speech recognition vendor's api provides methods for checking for the existence of a dynamic grammar, and for compiling a new grammar (named as the client specifies). The api also provides a powerful and flexible way to manage these stored grammars. Is there some MRCP-friendly way for dealing with these types of grammars? If not, then is one being considered? Corby Anderson Tellme Networks, Inc. _______________________________________________ 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 Jun 08 08:31:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfzi3-0001Th-7E; Wed, 08 Jun 2005 08:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfzhz-0001Tb-Jo for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 08:31: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 IAA21916 for ; Wed, 8 Jun 2005 08:30:58 -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 1Dg03E-0002V7-05 for speechsc@ietf.org; Wed, 08 Jun 2005 08:52:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2005 05:30:47 -0700 X-IronPort-AV: i="3.93,182,1115017200"; d="scan'208"; a="275898945:sNHT36198656" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j58CUilq027424; Wed, 8 Jun 2005 05:30:45 -0700 (PDT) Received: from [10.42.4.67] (sjc-vpn2-520.cisco.com [10.21.114.8]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j58CIk05030506; Wed, 8 Jun 2005 05:18:47 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E318AD0-D07B-4BCC-B431-5F2C6B0D824B@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] "Race" condition between RECOGNIZE.request and med ia Date: Wed, 8 Jun 2005 08:30:41 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118233127.642113"; x:"432200"; a:"rsa-sha1"; b:"nofws:4899"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"TiWTl7t7ba/kxRgh/ri8Ah9W4iE2VlraqbNe61ZWfEg5rx0hByz9rOhQpz9O4+ib3r45eBGy" "4L81FxxVw6MoLTRoQ9073aUkz1uCUObIASshqD+G7eCfBQztwpbJW1CYULewHlaNDS2Z26S3QuC" "EXwcaowQB9HnlXJKA5kjnqQ8="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] =22Race=22 condition between RECOGNIZE.reque" "st and med ia"; c:"Date: Wed, 8 Jun 2005 08:30:41 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: "'speechsc@ietf.org'" , "'qzhou@research.bell-labs.com'" 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 On Jun 8, 2005, at 7:56 AM, Reifenrath, Klaus wrote: > I also vote for removing the old and fuzzy MRCPv1 text > "Note that since the audio and the messages are carried over separate > communication paths there may be a race condition between the start of > the flow of audio and the receipt of the RECOGNIZE method. For > example, if an audio flow is started by the client at the same time as > the RECOGNIZE method is sent, either the audio or the RECOGNIZE can > arrive at the recognizer first. As another example, the client may > chose to continuously send audio to the Server and signal the Server > to recognize using the RECOGNIZE method. A number of mechanisms exist > to resolve this condition and the mechanism chosen is left to the > implementers of recognition resource." > > BUT I agree with Brett, we should keep the last sentence (that was > not in > the MRCPv1 spec): > "The recognizer should expect the media to start flowing when it > receives the recognize request, but should not buffer anything it > receives beforehand." > Ok, I think we have consensus on this. > BTW: Shouldn't the 'should' be a 'SHOULD' in the last sentence? > I don't think so. My concern is that implementers take this literally and try to dump an active jitter buffer when they receive the RECOGNIZE, which is unnecessary and probalby the wrong thing to do. If in fact the client starts sending audio at the exact moment it issues the RECOGNIZE, it is in fact likely that a few media packets will in fact arrive before the RECOGNIZE, because of the differential QoS the media likely has. There is also the possibility of a lost control packet and TCP retransmission. So, I think the point is that we want semantics that do not require extra server machinery to deal with the cases where the media and control channels become mis-synchronized. I think the above wording is ok, but if we want to capture this point accurately, an alternative wording might be: "The recognizer should expect the media to start flowing when it receives the recognize request, but need not take special action to buffer anything it receives beforehand to process media which arrives before the MRCPv2 control channel message." Dave. > Klaus > > > -----Original Message----- > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > Sent: Dienstag, 7. Juni 2005 23:45 > To: Brett Gavagni > Cc: speechsc@ietf.org ((((E-mail)))); speechsc-bounces@ietf.org > Subject: Re: [Speechsc] "Race" condition between RECOGNIZE.request > and media > > To me, this line implies that RECOGNIZE is the trigger signal to let > recognizer to start listening (buffer and do recognition). It is > not clear > to me why the recognizer need to buffer audio before the RECOGNIZE > message > and it is ambiguous to do that (how early and how much data to > buffer). A > particular implementation may choose to do something like that for > signal > processing purpose I guess but it is the implementation detail. So > I'd vote > keep the line below and nuke the rest. > > -- Qiru > > Brett Gavagni wrote: > >> I would vote to leave the wording, or at a minimum keep the following >> line. This statement can be quite helpful in mitigating potential >> client/server interoperability issues. >> >> "The recognizer should expect the media to start flowing when it >> receives the recognize request, but should not buffer anything it >> receives beforehand." >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "David R. Oran" >> Sent by: speechsc-bounces@ietf.org >> 06/07/2005 09:53 AM >> >> To >> "speechsc@ietf.org ((((E-mail))))" cc >> >> Subject >> [Speechsc] "Race" condition between RECOGNIZE.request and media >> >> >> >> >> >> >> The text says: >> >> "Note that since the audio and the messages are carried over separate >> communication paths there may be a race condition between the >> start of >> the flow of audio and the receipt of the RECOGNIZE method. For >> example, if an audio flow is started by the client at the same >> time as >> the RECOGNIZE method is sent, either the audio or the RECOGNIZE can >> arrive at the recognizer first. As another example, the client may >> chose to continuously send audio to the Server and signal the Server >> to recognize using the RECOGNIZE method. A number of mechanisms exist >> to resolve this condition and the mechanism chosen is left to the >> implementers of recognition resource. The recognizer should expect >> the >> media to start flowing when it receives the recognize request, but >> should not buffer anything it receives beforehand." >> >> Either this race condition doesn't matter, in which case we should >> either just nuke this paragraph or take out the should/should not >> guidance at the end, or it does matter, in which case this >> material is >> wholly inadequate. >> >> If the synchronization of the control and media channels matters, >> then >> we really do need to fix the protocol. Luckily, this is relatively >> easy to do: >> >> a) recommend that servers with recognizers buffer at least an RTT >> worth of media. >> b) include an NTP timestamp of where in the the input media >> recognition should start in a RECOGNIZE request header. >> c) define an error to cover the "lost media" case. >> >> My gut tells me that for recognition none of this is necessary and we >> should just nuke the paragraph above as making implementers think >> about something they can only screw up if they work too hard at it. >> >> _______________________________________________ >> 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 Jun 08 08:34:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzlD-0002PN-I4; Wed, 08 Jun 2005 08:34:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfzlC-0002OY-5o; Wed, 08 Jun 2005 08:34:18 -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 IAA22307; Wed, 8 Jun 2005 08:34:16 -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 1Dg06R-0002cY-6c; Wed, 08 Jun 2005 08:56:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2005 05:34:07 -0700 X-IronPort-AV: i="3.93,182,1115017200"; d="scan'208"; a="275900125:sNHT34173608" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j58CY4lq028586; Wed, 8 Jun 2005 05:34:04 -0700 (PDT) Received: from [10.42.4.67] (sjc-vpn2-520.cisco.com [10.21.114.8]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j58CM6gl030524; Wed, 8 Jun 2005 05:22:07 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] RECORD method Date: Wed, 8 Jun 2005 08:34:01 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118233327.680845"; x:"432200"; a:"rsa-sha1"; b:"nofws:4814"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"N0KpoQktpiDSByz3B5VGsTfQ9RmTaoDnd4hHKR7gqC9xLKNIcAdr2/nOmv3F5JJZ605kwSBF" "ciWM9qdjq1HMgepBQ6rRUabgKJtCbtqKgJPIlx7SvQVX1MYOL5D/ZwcQz4kavPLVuC4S7uMyv47" "ycpWMgg9IOjEgUJTDKUKyfjk="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] RECORD method"; c:"Date: Wed, 8 Jun 2005 08:34:01 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , speechsc-bounces@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 On Jun 8, 2005, at 8:03 AM, Reifenrath, Klaus wrote: > There are use cases where the speech synthesis engine need to speak > secret > data, in which cases HTTPS would also be required for servers that > only have > speech synthesis resources. > The input text is usually in the MRCP messages, which does in fact require TLS, and the output media gets protected with SRTP. Are you positing the case where the text to be spoken is obtained with content indirection? In that case i agree with you and I've already updated the spec to require HTTPS for indirected content. > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Mittwoch, 8. Juni 2005 05:06 > To: Brett Gavagni > Cc: speechsc@ietf.org; Shanmugham, Saravanan; speechsc- > bounces@ietf.org > Subject: Re: [Speechsc] RECORD method > > I'm trying in my chair review and editing to rationalize the > wording in as > many places as I find. Doing this without unintentionally changing the > technical content is something which I have to be conservative > about though. > the example of why HTTP some places and HTTPS other places is an > case of > where I am reluctant to change anything, because a server with only > a speech > synthesis engine and no recorder might never need HTTPS, whereas for > security reasons HTTPS is mandatory for recorders. > > I'll let you folks be the judge of success once we get the edited > draft out > (within a week if all goes well) > > Dave. > > On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: > > >> Hi, >> >> I'm requesting consistent wording throughout the sections of the >> specification. >> >> The specification becomes increasingly convoluted with protocol >> requirements that vary or are inconsistent in different sections. >> >> One could argue that the MRCP client and server implementation could >> coexist at the same logical network address and the security overhead >> implications/requirements are redundant in particular isolated >> scenarios. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "Shanmugham, Saravanan" >> 06/07/2005 02:55 PM >> >> To >> Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" >> , , >> Subject >> RE: [Speechsc] RECORD method >> >> >> >> >> >> >> You are refering to the capability of the Media servers capability to >> access another webserver(HTTP client capability). >> >> This thread is about the Media server being capable of recording the >> audio locally and providing HTTP server access to that recorder >> content. >> >> Sarvi >> >> -----Original Message----- >> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >> Sent: Tuesday, June 07, 2005 11:49 AM >> To: Shanmugham, Saravanan >> Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org >> Subject: RE: [Speechsc] RECORD method >> >> The only comment I have is to keep the wording consistent >> throughout the specification. I would be careful in the >> deviation of terminology across sections. >> >> For example in section: 8.5. Synthesizer Message Body >> >> Synthesizer Speech Data >> Lexicon Data >> .. >> .. >> ... >> All media servers MUST support the >> HTTP uri access mechanism. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "Shanmugham, Saravanan" Sent by: >> speechsc-bounces@ietf.org >> 06/07/2005 02:32 PM >> >> To >> "David R. Oran" , cc >> >> Subject >> RE: [Speechsc] RECORD method >> >> >> >> >> >> >> I think we want to allow for HTTP as well. So, "MUST >> HTTPS and SHOULD HTTP" would be fine with me. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. >> Oran >> Sent: Tuesday, June 07, 2005 8:29 AM >> To: speechsc@ietf.org ((((E-mail)))) >> Subject: [Speechsc] RECORD method >> >> the text says: >> >> "The RECORD request places the recorder resource in the >> Recording state. Depending on the headers specified in the >> RECORD method the resource may start recording the audio >> immediately or wait for the end pointing functionality to >> detect speech in the audio. It then saves the audio to the >> URI supplied in the recording-uri header. If the >> recording-uri is not specified, the server MUST capture >> the media onto a local disk and return a URI pointing to >> the recorded audio in the RECORD-COMPLETE event. The >> server MUST support HTTP and file URI schemes." >> >> Sorry, but a file: URI won't work - it's not generally >> usable between systems. Because of this and the secuirty >> issues, the last sentence probably ought to be: >> >> "The server MUST support the HTTPS URI scheme and MAY >> support other schemes. Note that due to the sensitive >> nature of voice recordings, any other URI schemes >> supported by the server SHOULD employ integrity and >> confidentiality on the data transfer (e.g. FTPS)." >> >> I changed the text, so let me know if this is going to >> cause heartburn. >> >> dave. >> >> >> _______________________________________________ >> 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 08 08:41:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfzru-0003Mv-2m; Wed, 08 Jun 2005 08:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfzrp-0003Mn-Vb for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 08:41: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 IAA22871 for ; Wed, 8 Jun 2005 08:41:08 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg0D4-0002nC-Dr for speechsc@ietf.org; Wed, 08 Jun 2005 09:03:08 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 08 Jun 2005 18:15:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,182,1115017200"; d="scan'208"; a="38328701:sNHT26562872" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j58I9UrA015788; Wed, 8 Jun 2005 18:09:33 GMT Received: from [10.42.4.67] (sjc-vpn2-520.cisco.com [10.21.114.8]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j58CSqTe030560; Wed, 8 Jun 2005 05:28:52 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E6B9218-7608-467C-B6EE-E2689FC2BF81@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Managing big grammars Date: Wed, 8 Jun 2005 08:40:44 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118233732.715300"; x:"432200"; a:"rsa-sha1"; b:"nofws:3542"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"izDwspsDKPzIl4ZR0jWA+NEQY/lSG4JYyWfZ5gLvKAp/nyw7U5N4lw6uZ6CORBVhfEQ7kZ39" "L/shHd0ZeDjYP/8+IH3wgip96FiwnX9+6aiq6ikrdENFohPVomgTVZ/o5/a1r5rZIkvSvc9Dgr7" "B0/V3zPjS6NOeuZIh0tXpe5I="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Managing big grammars"; c:"Date: Wed, 8 Jun 2005 08:40:44 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: Speechsc@ietf.org, "'Shanmugham, Saravanan'" 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 On Jun 8, 2005, at 8:28 AM, Reifenrath, Klaus wrote: > I agree. > > BUT unfortunately there is no MRCPv2 interface to just compile a > grammar. So > grammar compilation needs to be done with vendor specific tools or > APIs. > We could add a new method (allowed only in idle state): > COMPILE-GRAMMAR > that requires the header field > Compiled-Grammar-URI > that specifies the location of the compiled grammar (like > Personal-Grammar-URI). > Is it too late to add this simple optional method? > I don't see why we need this given we have DEFINE_GRAMMAR. If we simply allow DEFINE_GRAMMAR to take compiled grammars as well as XML grammars as Sarvi suggested, isn't this adequate? I also think Sarvi's caching idea is a good thing for implementations to do, and while it doesn't affect the protocol it might be worth pointing out this optimization in the spec. By the way, for NLSML we could have a hack which allowed a compiled version of the grammar to be embedded in the XML, thus avoiding the need for alternate URI forms, questions about wire encoding, and having to invent yet another vendor-extension mechanism since I assume compiled grammars are implementation-specific. Might be worth suggesting something like this for EMMA too... Dave. > Klaus > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Dienstag, 7. Juni 2005 21:09 > To: Corby Anderson; Speechsc@ietf.org > Subject: RE: [Speechsc] Managing big grammars > > Sorry for the late reply. The way I think this should be addressed > is to > have support for compiled grammars as URI. All Large or Huge > grammars are > going to be URI referenced and never embedded in a DEFINE grammar. > This means that the URI could point to compiled grammar file. > > Another way is to use the chache capability. When you access a grammar > through HTTP is to cache it. In general instead of caching of the XML > grammar you could decide to cache the compiled version instead. > This would > mean that you might do an initial DEFINE-GRAMMAR to force a compile > of the > grammar and future references to that grammar URI would hit the > cache and > hence the compiled version. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson > Sent: Thursday, May 26, 2005 2:11 PM > To: Speechsc@ietf.org > Subject: [Speechsc] Managing big grammars > > What are folks' thoughts on how we could manage big > grammars with MRCP? > > There are two usage cases that I'm interested in: a Large > Grammar that takes several seconds to compile, and a Jumbo > Grammar that takes many many minutes to compile. A Large > Grammar might contain several hundred or thousand entries. > A Jumbo Grammar might contain hundreds of thousands of entries. > > For a Jumbo Grammar, there's no way that a user can wait > for a grammar to be uploaded and compiled via the > DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large > needs to be pre-compiled so that the DEFINE-GRAMMAR or > RECOGNIZE method can simply load the grammar binary. > > For a Large Grammar, it might be okay to make one user > wait a few seconds for the grammar to compile -- but it > would be a big win if that compiled grammar were stored > with a known name so that /subsequent/ uses of the same > grammar don't have to pay the same compilation penalty. > > Our current speech recognition vendor's api provides > methods for checking for the existence of a dynamic > grammar, and for compiling a new grammar (named as the > client specifies). The api also provides a powerful and > flexible way to manage these stored grammars. Is there > some MRCP-friendly way for dealing with these types of > grammars? If not, then is one being considered? > > Corby Anderson > Tellme Networks, Inc. > > > _______________________________________________ > 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 08 09:01:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0Bn-0006e2-BQ; Wed, 08 Jun 2005 09:01:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0BU-0006bq-E1 for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 09:01:28 -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 JAA25113 for ; Wed, 8 Jun 2005 09:01:26 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg0Wk-0003OZ-Lj for Speechsc@ietf.org; Wed, 08 Jun 2005 09:23:27 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 8 Jun 2005 09:01:12 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , Corby Anderson Subject: RE: [Speechsc] Managing big grammars Date: Wed, 8 Jun 2005 09:01:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Speechsc@ietf.org, "'Shanmugham, Saravanan'" 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 am confused. Where does NLSM or EMMA fit in here? Both standards define the recognition result format. Caching solves the problem only partly, because cached grammars are not permanent and cannot be shared between different servers. Hence only a COMPILE-GRAMMAR method solves the use case of Corby. Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Mittwoch, 8. Juni 2005 14:41 To: Reifenrath, Klaus Cc: 'Shanmugham, Saravanan'; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars On Jun 8, 2005, at 8:28 AM, Reifenrath, Klaus wrote: > I agree. > > BUT unfortunately there is no MRCPv2 interface to just compile a > grammar. So grammar compilation needs to be done with vendor specific > tools or APIs. > We could add a new method (allowed only in idle state): > COMPILE-GRAMMAR > that requires the header field > Compiled-Grammar-URI > that specifies the location of the compiled grammar (like > Personal-Grammar-URI). > Is it too late to add this simple optional method? > I don't see why we need this given we have DEFINE_GRAMMAR. If we simply allow DEFINE_GRAMMAR to take compiled grammars as well as XML grammars as Sarvi suggested, isn't this adequate? I also think Sarvi's caching idea is a good thing for implementations to do, and while it doesn't affect the protocol it might be worth pointing out this optimization in the spec. By the way, for NLSML we could have a hack which allowed a compiled version of the grammar to be embedded in the XML, thus avoiding the need for alternate URI forms, questions about wire encoding, and having to invent yet another vendor-extension mechanism since I assume compiled grammars are implementation-specific. Might be worth suggesting something like this for EMMA too... Dave. > Klaus > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Dienstag, 7. Juni 2005 21:09 > To: Corby Anderson; Speechsc@ietf.org > Subject: RE: [Speechsc] Managing big grammars > > Sorry for the late reply. The way I think this should be addressed is > to have support for compiled grammars as URI. All Large or Huge > grammars are going to be URI referenced and never embedded in a DEFINE > grammar. > This means that the URI could point to compiled grammar file. > > Another way is to use the chache capability. When you access a grammar > through HTTP is to cache it. In general instead of caching of the XML > grammar you could decide to cache the compiled version instead. > This would > mean that you might do an initial DEFINE-GRAMMAR to force a compile of > the grammar and future references to that grammar URI would hit the > cache and hence the compiled version. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson > Sent: Thursday, May 26, 2005 2:11 PM > To: Speechsc@ietf.org > Subject: [Speechsc] Managing big grammars > > What are folks' thoughts on how we could manage big > grammars with MRCP? > > There are two usage cases that I'm interested in: a Large > Grammar that takes several seconds to compile, and a Jumbo > Grammar that takes many many minutes to compile. A Large > Grammar might contain several hundred or thousand entries. > A Jumbo Grammar might contain hundreds of thousands of entries. > > For a Jumbo Grammar, there's no way that a user can wait > for a grammar to be uploaded and compiled via the > DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large > needs to be pre-compiled so that the DEFINE-GRAMMAR or > RECOGNIZE method can simply load the grammar binary. > > For a Large Grammar, it might be okay to make one user > wait a few seconds for the grammar to compile -- but it > would be a big win if that compiled grammar were stored > with a known name so that /subsequent/ uses of the same > grammar don't have to pay the same compilation penalty. > > Our current speech recognition vendor's api provides > methods for checking for the existence of a dynamic > grammar, and for compiling a new grammar (named as the > client specifies). The api also provides a powerful and > flexible way to manage these stored grammars. Is there > some MRCP-friendly way for dealing with these types of > grammars? If not, then is one being considered? > > Corby Anderson > Tellme Networks, Inc. > > > _______________________________________________ > 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 08 09:07:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0Hi-0008Au-L4; Wed, 08 Jun 2005 09:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0He-0008Aj-Jv; Wed, 08 Jun 2005 09:07:52 -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 JAA25617; Wed, 8 Jun 2005 09:07:49 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg0cu-0003Zu-S1; Wed, 08 Jun 2005 09:29:49 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 8 Jun 2005 09:07:38 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" Subject: RE: [Speechsc] RECORD method Date: Wed, 8 Jun 2005 09:07:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , speechsc-bounces@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 had the use case in mind, where the MRCPv2 server has to fetch SSML documents. Is this what you call "indirected" content? Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Mittwoch, 8. Juni 2005 14:34 To: Reifenrath, Klaus Cc: Brett Gavagni; speechsc@ietf.org; Shanmugham, Saravanan; speechsc-bounces@ietf.org Subject: Re: [Speechsc] RECORD method On Jun 8, 2005, at 8:03 AM, Reifenrath, Klaus wrote: > There are use cases where the speech synthesis engine need to speak > secret data, in which cases HTTPS would also be required for servers > that only have speech synthesis resources. > The input text is usually in the MRCP messages, which does in fact require TLS, and the output media gets protected with SRTP. Are you positing the case where the text to be spoken is obtained with content indirection? In that case i agree with you and I've already updated the spec to require HTTPS for indirected content. > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Mittwoch, 8. Juni 2005 05:06 > To: Brett Gavagni > Cc: speechsc@ietf.org; Shanmugham, Saravanan; speechsc- > bounces@ietf.org > Subject: Re: [Speechsc] RECORD method > > I'm trying in my chair review and editing to rationalize the > wording in as > many places as I find. Doing this without unintentionally changing the > technical content is something which I have to be conservative > about though. > the example of why HTTP some places and HTTPS other places is an > case of > where I am reluctant to change anything, because a server with only > a speech > synthesis engine and no recorder might never need HTTPS, whereas for > security reasons HTTPS is mandatory for recorders. > > I'll let you folks be the judge of success once we get the edited > draft out > (within a week if all goes well) > > Dave. > > On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: > > >> Hi, >> >> I'm requesting consistent wording throughout the sections of the >> specification. >> >> The specification becomes increasingly convoluted with protocol >> requirements that vary or are inconsistent in different sections. >> >> One could argue that the MRCP client and server implementation could >> coexist at the same logical network address and the security overhead >> implications/requirements are redundant in particular isolated >> scenarios. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "Shanmugham, Saravanan" >> 06/07/2005 02:55 PM >> >> To >> Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" >> , , >> Subject >> RE: [Speechsc] RECORD method >> >> >> >> >> >> >> You are refering to the capability of the Media servers capability to >> access another webserver(HTTP client capability). >> >> This thread is about the Media server being capable of recording the >> audio locally and providing HTTP server access to that recorder >> content. >> >> Sarvi >> >> -----Original Message----- >> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >> Sent: Tuesday, June 07, 2005 11:49 AM >> To: Shanmugham, Saravanan >> Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org >> Subject: RE: [Speechsc] RECORD method >> >> The only comment I have is to keep the wording consistent >> throughout the specification. I would be careful in the >> deviation of terminology across sections. >> >> For example in section: 8.5. Synthesizer Message Body >> >> Synthesizer Speech Data >> Lexicon Data >> .. >> .. >> ... >> All media servers MUST support the >> HTTP uri access mechanism. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "Shanmugham, Saravanan" Sent by: >> speechsc-bounces@ietf.org >> 06/07/2005 02:32 PM >> >> To >> "David R. Oran" , cc >> >> Subject >> RE: [Speechsc] RECORD method >> >> >> >> >> >> >> I think we want to allow for HTTP as well. So, "MUST >> HTTPS and SHOULD HTTP" would be fine with me. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. >> Oran >> Sent: Tuesday, June 07, 2005 8:29 AM >> To: speechsc@ietf.org ((((E-mail)))) >> Subject: [Speechsc] RECORD method >> >> the text says: >> >> "The RECORD request places the recorder resource in the >> Recording state. Depending on the headers specified in the >> RECORD method the resource may start recording the audio >> immediately or wait for the end pointing functionality to >> detect speech in the audio. It then saves the audio to the >> URI supplied in the recording-uri header. If the >> recording-uri is not specified, the server MUST capture >> the media onto a local disk and return a URI pointing to >> the recorded audio in the RECORD-COMPLETE event. The >> server MUST support HTTP and file URI schemes." >> >> Sorry, but a file: URI won't work - it's not generally >> usable between systems. Because of this and the secuirty >> issues, the last sentence probably ought to be: >> >> "The server MUST support the HTTPS URI scheme and MAY >> support other schemes. Note that due to the sensitive >> nature of voice recordings, any other URI schemes >> supported by the server SHOULD employ integrity and >> confidentiality on the data transfer (e.g. FTPS)." >> >> I changed the text, so let me know if this is going to >> cause heartburn. >> >> dave. >> >> >> _______________________________________________ >> 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 08 09:14:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0OT-00010Y-EV; Wed, 08 Jun 2005 09:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0OS-00010Q-HG for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 09:14:52 -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 JAA26026 for ; Wed, 8 Jun 2005 09:14:50 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg0ji-0003hR-Vf for speechsc@ietf.org; Wed, 08 Jun 2005 09:36:51 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 8 Jun 2005 09:14:43 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , "speechsc@ietf.org ((((E-mail))))" Subject: RE: [Speechsc] Personal grammars Date: Wed, 8 Jun 2005 09:14:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi Dave, the reason for this is, that some ASR engines simply cannot add voice enrolled grammars to an arbitrary grammar. Regards, Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Dienstag, 7. Juni 2005 16:18 To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] Personal grammars The text on phrase enrollment says: "The Personal-Grammar-URI, which specifies the grammar to contain the new enrolled phrase, is created if it does not exist. Also, the personal grammar may ONLY contain phrases added via a phrase enrollment session." What's the reason for this restriction? What bad would happen if we got rid of it, especially as the protocol has no mechanisms to enforce this or for the client to generate an error when it happens. (still doing the chair review...hang in there). Dave. _______________________________________________ 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 Jun 08 09:29:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0cz-0003dF-QQ; Wed, 08 Jun 2005 09:29:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0cy-0003d4-Bh; Wed, 08 Jun 2005 09:29:52 -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 JAA27149; Wed, 8 Jun 2005 09:29:50 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg0yD-0003x0-Co; Wed, 08 Jun 2005 09:51:51 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Jun 2005 06:29:41 -0700 X-IronPort-AV: i="3.93,183,1115017200"; d="scan'208"; a="641943876:sNHT40498572" 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 j58DTObw005213; Wed, 8 Jun 2005 06:29:24 -0700 (PDT) Received: from [10.42.4.67] (sjc-vpn2-520.cisco.com [10.21.114.8]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j58DHQMD030775; Wed, 8 Jun 2005 06:17:27 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <083E60FB-468A-41ED-B9F0-C0F2C1071E65@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] RECORD method Date: Wed, 8 Jun 2005 09:29:21 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118236647.473937"; x:"432200"; a:"rsa-sha1"; b:"nofws:5560"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HnsiUrGaPicJ2bFBYJ7xDxVgfU+EnNIPBIhD6FW1CCP8INE1TnKCZ63YY9qAOtTuutdCkpD5" "3w4l94TZCRZb4JM0D08vcrUtprx3HPSRdGDjsu9qB/WSWz6k31y3e7KG+EarjZz5V3EiMhNb393" "N27rBsfU26UktqY3QEvi6Cng="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] RECORD method"; c:"Date: Wed, 8 Jun 2005 09:29:21 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , speechsc-bounces@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 On Jun 8, 2005, at 9:07 AM, Reifenrath, Klaus wrote: > I had the use case in mind, where the MRCPv2 server has to fetch SSML > documents. Is this what you call "indirected" content? > Yes. > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Mittwoch, 8. Juni 2005 14:34 > To: Reifenrath, Klaus > Cc: Brett Gavagni; speechsc@ietf.org; Shanmugham, Saravanan; > speechsc-bounces@ietf.org > Subject: Re: [Speechsc] RECORD method > > > On Jun 8, 2005, at 8:03 AM, Reifenrath, Klaus wrote: > > >> There are use cases where the speech synthesis engine need to speak >> secret data, in which cases HTTPS would also be required for servers >> that only have speech synthesis resources. >> >> > The input text is usually in the MRCP messages, which does in fact > require > TLS, and the output media gets protected with SRTP. Are you > positing the > case where the text to be spoken is obtained with content > indirection? In > that case i agree with you and I've already updated the spec to > require > HTTPS for indirected content. > > >> Klaus >> >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Mittwoch, 8. Juni 2005 05:06 >> To: Brett Gavagni >> Cc: speechsc@ietf.org; Shanmugham, Saravanan; speechsc- >> bounces@ietf.org >> Subject: Re: [Speechsc] RECORD method >> >> I'm trying in my chair review and editing to rationalize the >> wording in as >> many places as I find. Doing this without unintentionally changing >> the >> technical content is something which I have to be conservative >> about though. >> the example of why HTTP some places and HTTPS other places is an >> case of >> where I am reluctant to change anything, because a server with only >> a speech >> synthesis engine and no recorder might never need HTTPS, whereas for >> security reasons HTTPS is mandatory for recorders. >> >> I'll let you folks be the judge of success once we get the edited >> draft out >> (within a week if all goes well) >> >> Dave. >> >> On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: >> >> >> >>> Hi, >>> >>> I'm requesting consistent wording throughout the sections of the >>> specification. >>> >>> The specification becomes increasingly convoluted with protocol >>> requirements that vary or are inconsistent in different sections. >>> >>> One could argue that the MRCP client and server implementation could >>> coexist at the same logical network address and the security >>> overhead >>> implications/requirements are redundant in particular isolated >>> scenarios. >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> gavagni@us.ibm.com >>> >>> >>> >>> >>> "Shanmugham, Saravanan" >>> 06/07/2005 02:55 PM >>> >>> To >>> Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" >>> , , >>> Subject >>> RE: [Speechsc] RECORD method >>> >>> >>> >>> >>> >>> >>> You are refering to the capability of the Media servers >>> capability to >>> access another webserver(HTTP client capability). >>> >>> This thread is about the Media server being capable of recording the >>> audio locally and providing HTTP server access to that recorder >>> content. >>> >>> Sarvi >>> >>> -----Original Message----- >>> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >>> Sent: Tuesday, June 07, 2005 11:49 AM >>> To: Shanmugham, Saravanan >>> Cc: David R. Oran; speechsc@ietf.org; speechsc-bounces@ietf.org >>> Subject: RE: [Speechsc] RECORD method >>> >>> The only comment I have is to keep the wording consistent >>> throughout the specification. I would be careful in the >>> deviation of terminology across sections. >>> >>> For example in section: 8.5. Synthesizer Message Body >>> >>> Synthesizer Speech Data >>> Lexicon Data >>> .. >>> .. >>> ... >>> All media servers MUST support the >>> HTTP uri access mechanism. >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> gavagni@us.ibm.com >>> >>> >>> >>> >>> "Shanmugham, Saravanan" Sent by: >>> speechsc-bounces@ietf.org >>> 06/07/2005 02:32 PM >>> >>> To >>> "David R. Oran" , cc >>> >>> Subject >>> RE: [Speechsc] RECORD method >>> >>> >>> >>> >>> >>> >>> I think we want to allow for HTTP as well. So, "MUST >>> HTTPS and SHOULD HTTP" would be fine with me. >>> >>> Sarvi >>> >>> -----Original Message----- >>> From: speechsc-bounces@ietf.org >>> [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. >>> Oran >>> Sent: Tuesday, June 07, 2005 8:29 AM >>> To: speechsc@ietf.org ((((E-mail)))) >>> Subject: [Speechsc] RECORD method >>> >>> the text says: >>> >>> "The RECORD request places the recorder resource in the >>> Recording state. Depending on the headers specified in the >>> RECORD method the resource may start recording the audio >>> immediately or wait for the end pointing functionality to >>> detect speech in the audio. It then saves the audio to the >>> URI supplied in the recording-uri header. If the >>> recording-uri is not specified, the server MUST capture >>> the media onto a local disk and return a URI pointing to >>> the recorded audio in the RECORD-COMPLETE event. The >>> server MUST support HTTP and file URI schemes." >>> >>> Sorry, but a file: URI won't work - it's not generally >>> usable between systems. Because of this and the secuirty >>> issues, the last sentence probably ought to be: >>> >>> "The server MUST support the HTTPS URI scheme and MAY >>> support other schemes. Note that due to the sensitive >>> nature of voice recordings, any other URI schemes >>> supported by the server SHOULD employ integrity and >>> confidentiality on the data transfer (e.g. FTPS)." >>> >>> I changed the text, so let me know if this is going to >>> cause heartburn. >>> >>> dave. >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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 Jun 08 09:32:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0fF-00048I-1Z; Wed, 08 Jun 2005 09:32:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0fC-00047j-Rb for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 09:32: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 JAA27296 for ; Wed, 8 Jun 2005 09:32: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 1Dg10S-00040D-DO for speechsc@ietf.org; Wed, 08 Jun 2005 09:54:09 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2005 06:31:46 -0700 X-IronPort-AV: i="3.93,183,1115017200"; d="scan'208"; a="275916629:sNHT38687447882" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j58DVilq027017; Wed, 8 Jun 2005 06:31:44 -0700 (PDT) Received: from [10.42.4.67] (sjc-vpn2-520.cisco.com [10.21.114.8]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j58DJlsA030798; Wed, 8 Jun 2005 06:19:47 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6ACED942-04D1-415D-B407-0B60F39BE192@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Personal grammars Date: Wed, 8 Jun 2005 09:31:42 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118236787.689692"; x:"432200"; a:"rsa-sha1"; b:"nofws:1144"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"L/X1Rp1PWwxaPcazbiojhG2uA1MwrUYScdgFnwTxUZNYkCNpnLCEqjGKJqjfNezZZrQCkExH" "i3L1yytK0bx09Oo+Rqf5RU7KrKUfkLA7e24tpSRfJOAmHRQqF5lkeIucnkQ0k7TwJF6RYki9QEn" "FP1WMXQmZ0BT9XN5ZOHsRCzI="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Personal grammars"; c:"Date: Wed, 8 Jun 2005 09:31:42 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" 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 On Jun 8, 2005, at 9:14 AM, Reifenrath, Klaus wrote: > Hi Dave, > > the reason for this is, that some ASR engines simply cannot add voice > enrolled grammars to an arbitrary grammar. > well, we have a lot of things that only work if your engine supports it, so I guess my question is why prohibit engines that can do this from having combined grammars. this isn't a big deal - i happy to leave things as they are if on balance the restriction is not onerous for anybody. Dave. > Regards, > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Dienstag, 7. Juni 2005 16:18 > To: speechsc@ietf.org ((((E-mail)))) > Subject: [Speechsc] Personal grammars > > The text on phrase enrollment says: > > "The Personal-Grammar-URI, which specifies the grammar to contain > the new > enrolled phrase, is created if it does not exist. Also, the > personal grammar > may ONLY contain phrases added via a phrase enrollment session." > > What's the reason for this restriction? > > What bad would happen if we got rid of it, especially as the > protocol has no > mechanisms to enforce this or for the client to generate an error > when it > happens. > > (still doing the chair review...hang in there). > > Dave. > > _______________________________________________ > 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 Jun 08 12:39:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg3aE-0002as-M7; Wed, 08 Jun 2005 12:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg3aC-0002XP-Fi for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 12:39: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 MAA15448 for ; Wed, 8 Jun 2005 12:39:09 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg3vU-0000YK-Ac for speechsc@ietf.org; Wed, 08 Jun 2005 13:01:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2005 09:39:02 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j58Gd0bw027674; Wed, 8 Jun 2005 09:39:00 -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] Managing big grammars Date: Wed, 8 Jun 2005 09:41:03 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B77095E@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVsKnqG9tsQXUF+Stij3Qey4/umugAHbGiw From: "Shanmugham, Saravanan" To: "Reifenrath, Klaus" , "David R. Oran" , "Corby Anderson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 =20 -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Wednesday, June 08, 2005 6:01 AM To: 'David R. Oran'; Corby Anderson Cc: Shanmugham, Saravanan; Speechsc@ietf.org Subject: RE: [Speechsc] Managing big grammars =20 I am confused. Where does NLSM or EMMA fit in here? Both=20 standards define the recognition result format. Caching solves the problem only partly, because cached=20 Sarvi>> The advantage is that it is almost self optimizing. And how often you want a grammar to be stored in cache is going to be based on the Caching parameters U use for that grammar URI grammars are not permanent and cannot be shared between=20 different servers. Hence only a COMPILE-GRAMMAR method=20 Sarvi>> I am not sure how a COMPILE-GRAMMAR method is going to address sharing grammars across MRCP servers. Sarvi solves the use case of Corby. =20 Klaus=20 =20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Mittwoch, 8. Juni 2005 14:41 To: Reifenrath, Klaus Cc: 'Shanmugham, Saravanan'; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 =20 On Jun 8, 2005, at 8:28 AM, Reifenrath, Klaus wrote: =20 > I agree. > > BUT unfortunately there is no MRCPv2 interface to just compile a=20 > grammar. So grammar compilation needs to be done with=20 vendor specific=20 > tools or APIs. > We could add a new method (allowed only in idle state): > COMPILE-GRAMMAR > that requires the header field > Compiled-Grammar-URI > that specifies the location of the compiled grammar (like=20 > Personal-Grammar-URI). > Is it too late to add this simple optional method? > I don't see why we need this given we have DEFINE_GRAMMAR.=20 If we simply allow DEFINE_GRAMMAR to take compiled grammars as well as=20 XML grammars as Sarvi suggested, isn't this adequate? =20 I also think Sarvi's caching idea is a good thing for=20 implementations to do, and while it doesn't affect the protocol it might be worth=20 pointing out this optimization in the spec. =20 By the way, for NLSML we could have a hack which allowed a=20 compiled version of the grammar to be embedded in the XML, thus avoiding=20 the need for alternate URI forms, questions about wire encoding, and=20 having to invent yet another vendor-extension mechanism since I assume compiled=20 grammars are implementation-specific. =20 Might be worth suggesting something like this for EMMA too... =20 Dave. > Klaus > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Dienstag, 7. Juni 2005 21:09 > To: Corby Anderson; Speechsc@ietf.org > Subject: RE: [Speechsc] Managing big grammars > > Sorry for the late reply. The way I think this should=20 be addressed is=20 > to have support for compiled grammars as URI. All Large or Huge=20 > grammars are going to be URI referenced and never=20 embedded in a DEFINE=20 > grammar. > This means that the URI could point to compiled grammar file. > > Another way is to use the chache capability. When you=20 access a grammar=20 > through HTTP is to cache it. In general instead of=20 caching of the XML=20 > grammar you could decide to cache the compiled version instead. > This would > mean that you might do an initial DEFINE-GRAMMAR to=20 force a compile of=20 > the grammar and future references to that grammar URI=20 would hit the=20 > cache and hence the compiled version. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Corby Anderson > Sent: Thursday, May 26, 2005 2:11 PM > To: Speechsc@ietf.org > Subject: [Speechsc] Managing big grammars > > What are folks' thoughts on how we could manage big > grammars with MRCP? > > There are two usage cases that I'm interested in: a Large > Grammar that takes several seconds to compile, and a Jumbo > Grammar that takes many many minutes to compile. A Large > Grammar might contain several hundred or thousand entries. > A Jumbo Grammar might contain hundreds of=20 thousands of entries. > > For a Jumbo Grammar, there's no way that a user can wait > for a grammar to be uploaded and compiled via the > DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large > needs to be pre-compiled so that the DEFINE-GRAMMAR or > RECOGNIZE method can simply load the grammar binary. > > For a Large Grammar, it might be okay to make one user > wait a few seconds for the grammar to compile -- but it > would be a big win if that compiled grammar were stored > with a known name so that /subsequent/ uses of the same > grammar don't have to pay the same compilation penalty. > > Our current speech recognition vendor's api provides > methods for checking for the existence of a dynamic > grammar, and for compiling a new grammar (named as the > client specifies). The api also provides a powerful and > flexible way to manage these stored grammars. Is there > some MRCP-friendly way for dealing with these types of > grammars? If not, then is one being considered? > > Corby Anderson > Tellme Networks, Inc. > > > _______________________________________________ > 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 > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 08 16:04:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6me-0000Gr-OE; Wed, 08 Jun 2005 16:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6mc-0000GL-Be; Wed, 08 Jun 2005 16:04:14 -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 QAA03966; Wed, 8 Jun 2005 16:04:11 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg77u-0005mT-RX; Wed, 08 Jun 2005 16:26:15 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2005 13:04:03 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j58K3xlq004337; Wed, 8 Jun 2005 13:04:00 -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] RECORD method Date: Wed, 8 Jun 2005 13:06:03 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B770A15@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] RECORD method Thread-Index: AcVsLm0oNkgGN65GTU2GD4HBwQ3jwAAGkKCg From: "Shanmugham, Saravanan" To: "David R. Oran" , "Reifenrath, Klaus" X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, speechsc-bounces@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 don't believe supporting HTTP and HTTPS on the MRCP server would be a big problem. Both when it acts as a HTTP server for cases like recording or as a HTTP client for fetching grammar/SSML. So I am fine saying it's a MUST to support HTTP and HTTPS client and server capability on the MRCP server. Sarvi=20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com]=20 Sent: Wednesday, June 08, 2005 6:29 AM To: Reifenrath, Klaus Cc: speechsc@ietf.org; Shanmugham, Saravanan;=20 speechsc-bounces@ietf.org Subject: Re: [Speechsc] RECORD method =20 =20 On Jun 8, 2005, at 9:07 AM, Reifenrath, Klaus wrote: =20 > I had the use case in mind, where the MRCPv2 server has=20 to fetch SSML=20 > documents. Is this what you call "indirected" content? > Yes. =20 > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Mittwoch, 8. Juni 2005 14:34 > To: Reifenrath, Klaus > Cc: Brett Gavagni; speechsc@ietf.org; Shanmugham, Saravanan;=20 > speechsc-bounces@ietf.org > Subject: Re: [Speechsc] RECORD method > > > On Jun 8, 2005, at 8:03 AM, Reifenrath, Klaus wrote: > > >> There are use cases where the speech synthesis engine=20 need to speak=20 >> secret data, in which cases HTTPS would also be=20 required for servers=20 >> that only have speech synthesis resources. >> >> > The input text is usually in the MRCP messages, which=20 does in fact=20 > require TLS, and the output media gets protected with=20 SRTP. Are you=20 > positing the case where the text to be spoken is=20 obtained with content=20 > indirection? In that case i agree with you and I've=20 already updated=20 > the spec to require HTTPS for indirected content. > > >> Klaus >> >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Mittwoch, 8. Juni 2005 05:06 >> To: Brett Gavagni >> Cc: speechsc@ietf.org; Shanmugham, Saravanan; speechsc-=20 >> bounces@ietf.org >> Subject: Re: [Speechsc] RECORD method >> >> I'm trying in my chair review and editing to=20 rationalize the wording=20 >> in as many places as I find. Doing this without unintentionally=20 >> changing the technical content is something which I have to be=20 >> conservative about though. >> the example of why HTTP some places and HTTPS other=20 places is an case=20 >> of where I am reluctant to change anything, because a=20 server with=20 >> only a speech synthesis engine and no recorder might never need=20 >> HTTPS, whereas for security reasons HTTPS is mandatory=20 for recorders. >> >> I'll let you folks be the judge of success once we get=20 the edited=20 >> draft out (within a week if all goes well) >> >> Dave. >> >> On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: >> >> >> >>> Hi, >>> >>> I'm requesting consistent wording throughout the=20 sections of the=20 >>> specification. >>> >>> The specification becomes increasingly convoluted with=20 protocol=20 >>> requirements that vary or are inconsistent in=20 different sections. >>> >>> One could argue that the MRCP client and server=20 implementation could=20 >>> coexist at the same logical network address and the security=20 >>> overhead implications/requirements are redundant in particular=20 >>> isolated scenarios. >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> gavagni@us.ibm.com >>> >>> >>> >>> >>> "Shanmugham, Saravanan" >>> 06/07/2005 02:55 PM >>> >>> To >>> Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" >>> , ,=20 =20 >>> Subject >>> RE: [Speechsc] RECORD method >>> >>> >>> >>> >>> >>> >>> You are refering to the capability of the Media=20 servers capability=20 >>> to access another webserver(HTTP client capability). >>> >>> This thread is about the Media server being capable of=20 recording the=20 >>> audio locally and providing HTTP server access to that=20 recorder=20 >>> content. >>> >>> Sarvi >>> >>> -----Original Message----- >>> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >>> Sent: Tuesday, June 07, 2005 11:49 AM >>> To: Shanmugham, Saravanan >>> Cc: David R. Oran; speechsc@ietf.org;=20 speechsc-bounces@ietf.org >>> Subject: RE: [Speechsc] RECORD method >>> >>> The only comment I have is to keep the wording consistent >>> throughout the specification. I would be careful in the >>> deviation of terminology across sections. >>> >>> For example in section: 8.5. Synthesizer Message Body >>> >>> Synthesizer Speech Data >>> Lexicon Data >>> .. >>> .. >>> ... >>> All media servers MUST support the >>> HTTP uri access mechanism. >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> gavagni@us.ibm.com >>> >>> >>> >>> >>> "Shanmugham, Saravanan" Sent by: >>> speechsc-bounces@ietf.org >>> 06/07/2005 02:32 PM >>> >>> To >>> "David R. Oran" , cc >>> >>> Subject >>> RE: [Speechsc] RECORD method >>> >>> >>> >>> >>> >>> >>> I think we want to allow for HTTP as well. So, "MUST >>> HTTPS and SHOULD HTTP" would be fine with me. >>> >>> Sarvi >>> >>> -----Original Message----- >>> From: speechsc-bounces@ietf.org >>> [mailto:speechsc-bounces@ietf.org] On Behalf=20 Of David R. >>> Oran >>> Sent: Tuesday, June 07, 2005 8:29 AM >>> To: speechsc@ietf.org ((((E-mail)))) >>> Subject: [Speechsc] RECORD method >>> >>> the text says: >>> >>> "The RECORD request places the recorder=20 resource in the >>> Recording state. Depending on the headers=20 specified in the >>> RECORD method the resource may start=20 recording the audio >>> immediately or wait for the end pointing=20 functionality to >>> detect speech in the audio. It then saves=20 the audio to the >>> URI supplied in the recording-uri header. If the >>> recording-uri is not specified, the server=20 MUST capture >>> the media onto a local disk and return a URI=20 pointing to >>> the recorded audio in the RECORD-COMPLETE event. The >>> server MUST support HTTP and file URI schemes." >>> >>> Sorry, but a file: URI won't work - it's not=20 generally >>> usable between systems. Because of this and=20 the secuirty >>> issues, the last sentence probably ought to be: >>> >>> "The server MUST support the HTTPS URI scheme and MAY >>> support other schemes. Note that due to the sensitive >>> nature of voice recordings, any other URI schemes >>> supported by the server SHOULD employ integrity and >>> confidentiality on the data transfer (e.g. FTPS)." >>> >>> I changed the text, so let me know if this=20 is going to >>> cause heartburn. >>> >>> dave. >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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 Wed Jun 08 16:38:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7Jc-0007Io-BX; Wed, 08 Jun 2005 16:38:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7Jb-0007Ij-3G for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 16:38:19 -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 QAA16023 for ; Wed, 8 Jun 2005 16:38:16 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg7ev-0001Ly-Bh for Speechsc@ietf.org; Wed, 08 Jun 2005 17:00:21 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id B059F350D for ; Wed, 8 Jun 2005 13:38:09 -0700 (PDT) Received: from [172.20.51.142] (dhcp172-51-142.corp.tellme.com [172.20.51.142]) by mail02.corp.tellme.com (Postfix) with ESMTP id 862C33507 for ; Wed, 8 Jun 2005 13:38:09 -0700 (PDT) Message-ID: <42A75731.6030406@tellme.com> Date: Wed, 08 Jun 2005 13:38:09 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org One feature that I'd like a COMPILE-GRAMMAR method to provide is the ability to specify common back-end storage (like Sarvi mentioned) so that compiling a Large Grammar one time could make it available to other MRCP servers via the Compiled-Grammar-URI that Klaus suggested. It would be especially useful to us if the *client* could specify the URI where the grammar should be stored. This would permit clients to use grammar names that are meaningful to the client. (The example for Personal-Grammar-URI seems like the grammar name is specified by the client, but it's worth spelling out.) To round out the utility of a feature like this, we'd need some way to determine if a grammar had already been compiled. Since we're talking about URIs, the client could just do a HEAD on the grammar to see if it exists -- but does the client always have access to back-end resources in this way? If not, then a QUERY-GRAMMAR method which takes a Compiled-Grammar-URI header could provide this capability. Corby Anderson Tellme Networks, Inc. Reifenrath, Klaus wrote: >I agree. > >BUT unfortunately there is no MRCPv2 interface to just compile a grammar. So >grammar compilation needs to be done with vendor specific tools or APIs. >We could add a new method (allowed only in idle state): >COMPILE-GRAMMAR >that requires the header field >Compiled-Grammar-URI >that specifies the location of the compiled grammar (like >Personal-Grammar-URI). >Is it too late to add this simple optional method? > >Klaus > >-----Original Message----- >From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >Sent: Dienstag, 7. Juni 2005 21:09 >To: Corby Anderson; Speechsc@ietf.org >Subject: RE: [Speechsc] Managing big grammars > > Sorry for the late reply. The way I think this should be addressed is to >have support for compiled grammars as URI. All Large or Huge grammars are >going to be URI referenced and never embedded in a DEFINE grammar. >This means that the URI could point to compiled grammar file. > >Another way is to use the chache capability. When you access a grammar >through HTTP is to cache it. In general instead of caching of the XML >grammar you could decide to cache the compiled version instead. This would >mean that you might do an initial DEFINE-GRAMMAR to force a compile of the >grammar and future references to that grammar URI would hit the cache and >hence the compiled version. > >Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson > Sent: Thursday, May 26, 2005 2:11 PM > To: Speechsc@ietf.org > Subject: [Speechsc] Managing big grammars > > What are folks' thoughts on how we could manage big > grammars with MRCP? > > There are two usage cases that I'm interested in: a Large > Grammar that takes several seconds to compile, and a Jumbo > Grammar that takes many many minutes to compile. A Large > Grammar might contain several hundred or thousand entries. > A Jumbo Grammar might contain hundreds of thousands of entries. > > For a Jumbo Grammar, there's no way that a user can wait > for a grammar to be uploaded and compiled via the > DEFINE-GRAMMAR or RECOGNIZE methods. A grammar that large > needs to be pre-compiled so that the DEFINE-GRAMMAR or > RECOGNIZE method can simply load the grammar binary. > > For a Large Grammar, it might be okay to make one user > wait a few seconds for the grammar to compile -- but it > would be a big win if that compiled grammar were stored > with a known name so that /subsequent/ uses of the same > grammar don't have to pay the same compilation penalty. > > Our current speech recognition vendor's api provides > methods for checking for the existence of a dynamic > grammar, and for compiling a new grammar (named as the > client specifies). The api also provides a powerful and > flexible way to manage these stored grammars. Is there > some MRCP-friendly way for dealing with these types of > grammars? If not, then is one being considered? > > Corby Anderson > Tellme Networks, Inc. > > > _______________________________________________ > 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 Jun 08 17:18:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7wG-0007QY-Hq; Wed, 08 Jun 2005 17:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg7wD-0007NS-MR for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 17:18:13 -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 RAA18634 for ; Wed, 8 Jun 2005 17:18:11 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg8H3-0002KH-Tq for Speechsc@ietf.org; Wed, 08 Jun 2005 17:39:46 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j58LHKJp007865; Wed, 8 Jun 2005 16:17:20 -0500 (CDT) Received: from [135.104.32.232] (bass.research.bell-labs.com [135.104.32.232]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j58LHK928404; Wed, 8 Jun 2005 17:17:20 -0400 (EDT) Message-ID: <42A76060.3090907@research.bell-labs.com> Date: Wed, 08 Jun 2005 17:17:20 -0400 From: Qiru Zhou Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: Corby Anderson Subject: Re: [Speechsc] Managing big grammars References: <42A75731.6030406@tellme.com> In-Reply-To: <42A75731.6030406@tellme.com> Content-Type: multipart/mixed; boundary="------------080006030502010202040904" X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qzhou@research.bell-labs.com 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 This is a multi-part message in MIME format. --------------080006030502010202040904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think the problem here is there is no standard for compiled grammar format. This is a vendor implementation specific which is not inter-operable across different vendors. I agree that pre-compiled large grammars can improve system response and processing efficiency. But I don't know if this should be the part of standard. Same for cache, it is an implementation specific issue. Another practice on this issue is to pre load and archive large grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). -- Qiru Corby Anderson wrote: > One feature that I'd like a COMPILE-GRAMMAR method to provide is the > ability to specify common back-end storage (like Sarvi mentioned) so > that compiling a Large Grammar one time could make it available to other > MRCP servers via the Compiled-Grammar-URI that Klaus suggested. It > would be especially useful to us if the *client* could specify the URI > where the grammar should be stored. This would permit clients to use > grammar names that are meaningful to the client. (The example for > Personal-Grammar-URI seems like the grammar name is specified by the > client, but it's worth spelling out.) > > To round out the utility of a feature like this, we'd need some way to > determine if a grammar had already been compiled. Since we're talking > about URIs, the client could just do a HEAD on the grammar to see if it > exists -- but does the client always have access to back-end resources > in this way? If not, then a QUERY-GRAMMAR method which takes a > Compiled-Grammar-URI header could provide this capability. > > Corby Anderson > Tellme Networks, Inc. > > > Reifenrath, Klaus wrote: > >> I agree. >> BUT unfortunately there is no MRCPv2 interface to just compile a >> grammar. So >> grammar compilation needs to be done with vendor specific tools or APIs. >> We could add a new method (allowed only in idle state): >> COMPILE-GRAMMAR >> that requires the header field >> Compiled-Grammar-URI >> that specifies the location of the compiled grammar (like >> Personal-Grammar-URI). >> Is it too late to add this simple optional method? >> >> Klaus >> >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Dienstag, >> 7. Juni 2005 21:09 >> To: Corby Anderson; Speechsc@ietf.org >> Subject: RE: [Speechsc] Managing big grammars >> >> Sorry for the late reply. The way I think this should be addressed is to >> have support for compiled grammars as URI. All Large or Huge grammars are >> going to be URI referenced and never embedded in a DEFINE grammar. >> This means that the URI could point to compiled grammar file. >> >> Another way is to use the chache capability. When you access a grammar >> through HTTP is to cache it. In general instead of caching of the XML >> grammar you could decide to cache the compiled version instead. This >> would >> mean that you might do an initial DEFINE-GRAMMAR to force a compile of >> the >> grammar and future references to that grammar URI would hit the cache and >> hence the compiled version. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM >> To: Speechsc@ietf.org >> Subject: [Speechsc] Managing big grammars >> What are folks' thoughts on how we could manage big >> grammars with MRCP? >> There are two usage cases that I'm interested in: a Large >> Grammar that takes several seconds to compile, and a Jumbo Grammar >> that takes many many minutes to compile. A Large Grammar might >> contain several hundred or thousand entries. A Jumbo Grammar >> might contain hundreds of thousands of entries. >> For a Jumbo Grammar, there's no way that a user can wait >> for a grammar to be uploaded and compiled via the DEFINE-GRAMMAR >> or RECOGNIZE methods. A grammar that large needs to be >> pre-compiled so that the DEFINE-GRAMMAR or RECOGNIZE method can >> simply load the grammar binary. >> For a Large Grammar, it might be okay to make one user >> wait a few seconds for the grammar to compile -- but it would be a >> big win if that compiled grammar were stored with a known name so >> that /subsequent/ uses of the same grammar don't have to pay the >> same compilation penalty. >> Our current speech recognition vendor's api provides >> methods for checking for the existence of a dynamic grammar, and >> for compiling a new grammar (named as the client specifies). The >> api also provides a powerful and flexible way to manage these >> stored grammars. Is there some MRCP-friendly way for dealing with >> these types of grammars? If not, then is one being considered? >> Corby Anderson >> Tellme Networks, Inc. >> _______________________________________________ >> 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 --------------080006030502010202040904 Content-Type: text/x-vcard; charset=utf-8; name="qzhou.vcf" Content-Disposition: attachment; filename="qzhou.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Qiru Zhou n:Zhou;Qiru org:;Converged Networks and Services Research Laboratory email;internet:W:\qzhou\Thunderbird\qzhou_BL.txt title:MTS tel;work:+1 908 582 4562 tel;fax:+1 908 582 7308 x-mozilla-html:FALSE version:2.1 end:vcard --------------080006030502010202040904 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 --------------080006030502010202040904-- From speechsc-bounces@ietf.org Wed Jun 08 17:53:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg8UJ-0006ZY-6g; Wed, 08 Jun 2005 17:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg8UH-0006ZI-6f for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 17:53:25 -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 RAA21062 for ; Wed, 8 Jun 2005 17:53:22 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg8p7-0003MK-LC for speechsc@ietf.org; Wed, 08 Jun 2005 18:14:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2005 14:52:29 -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 j58LqPbw021345; Wed, 8 Jun 2005 14:52:25 -0700 (PDT) Received: from [10.32.131.153] ([10.32.131.153]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j58LeTaF002539; Wed, 8 Jun 2005 14:40:29 -0700 In-Reply-To: <6677B3346233B94EBB11C060935101200B770A15@vtg-um-e2k1.sj21ad.cisco.com> References: <6677B3346233B94EBB11C060935101200B770A15@vtg-um-e2k1.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E203145-FD71-47F1-AE46-46A396ADD94A@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] RECORD method Date: Wed, 8 Jun 2005 17:52:24 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118266829.537149"; x:"432200"; a:"rsa-sha1"; b:"nofws:6591"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"E+ViEaEqKhsF4NZJixTLmLuxMvsxifTWv/Rm3f7BMEdK1UjbuP0QP6Nfdkn4B9v2Il9lUG/S" "Uqa3K8XADaP1npaf4oNoUiCHuR05f3Y/AidAh0D4/Aeli41aaab8SnpTQY+4vlZ8N2lV/jA5mco" "KdSAsMRwJWekDFlK3ssNdDso="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] RECORD method"; c:"Date: Wed, 8 Jun 2005 17:52:24 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Content-Transfer-Encoding: 7bit Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" 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 On Jun 8, 2005, at 4:06 PM, Shanmugham, Saravanan wrote: > I don't believe supporting HTTP and HTTPS on the MRCP server would > be a > big problem. > Both when it acts as a HTTP server for cases like recording or as a > HTTP > client for fetching grammar/SSML. > > So I am fine saying it's a MUST to support HTTP and HTTPS client and > server capability on the MRCP server. > This works for me as long as it's the WG consensus. I'll hold off making this change until we hear from other folks. Dave. > Sarvi > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, June 08, 2005 6:29 AM > To: Reifenrath, Klaus > Cc: speechsc@ietf.org; Shanmugham, Saravanan; > speechsc-bounces@ietf.org > Subject: Re: [Speechsc] RECORD method > > > On Jun 8, 2005, at 9:07 AM, Reifenrath, Klaus wrote: > > >> I had the use case in mind, where the MRCPv2 server has >> > to fetch SSML > >> documents. Is this what you call "indirected" content? >> >> > Yes. > > >> Klaus >> >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Mittwoch, 8. Juni 2005 14:34 >> To: Reifenrath, Klaus >> Cc: Brett Gavagni; speechsc@ietf.org; Shanmugham, Saravanan; >> speechsc-bounces@ietf.org >> Subject: Re: [Speechsc] RECORD method >> >> >> On Jun 8, 2005, at 8:03 AM, Reifenrath, Klaus wrote: >> >> >> >>> There are use cases where the speech synthesis engine >>> > need to speak > >>> secret data, in which cases HTTPS would also be >>> > required for servers > >>> that only have speech synthesis resources. >>> >>> >>> >> The input text is usually in the MRCP messages, which >> > does in fact > >> require TLS, and the output media gets protected with >> > SRTP. Are you > >> positing the case where the text to be spoken is >> > obtained with content > >> indirection? In that case i agree with you and I've >> > already updated > >> the spec to require HTTPS for indirected content. >> >> >> >>> Klaus >>> >>> -----Original Message----- >>> From: David R. Oran [mailto:oran@cisco.com] >>> Sent: Mittwoch, 8. Juni 2005 05:06 >>> To: Brett Gavagni >>> Cc: speechsc@ietf.org; Shanmugham, Saravanan; speechsc- >>> bounces@ietf.org >>> Subject: Re: [Speechsc] RECORD method >>> >>> I'm trying in my chair review and editing to >>> > rationalize the wording > >>> in as many places as I find. Doing this without unintentionally >>> changing the technical content is something which I have to be >>> conservative about though. >>> the example of why HTTP some places and HTTPS other >>> > places is an case > >>> of where I am reluctant to change anything, because a >>> > server with > >>> only a speech synthesis engine and no recorder might never need >>> HTTPS, whereas for security reasons HTTPS is mandatory >>> > for recorders. > >>> >>> I'll let you folks be the judge of success once we get >>> > the edited > >>> draft out (within a week if all goes well) >>> >>> Dave. >>> >>> On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote: >>> >>> >>> >>> >>>> Hi, >>>> >>>> I'm requesting consistent wording throughout the >>>> > sections of the > >>>> specification. >>>> >>>> The specification becomes increasingly convoluted with >>>> > protocol > >>>> requirements that vary or are inconsistent in >>>> > different sections. > >>>> >>>> One could argue that the MRCP client and server >>>> > implementation could > >>>> coexist at the same logical network address and the security >>>> overhead implications/requirements are redundant in particular >>>> isolated scenarios. >>>> >>>> Thanks, >>>> >>>> Brett Gavagni >>>> WebSphere Voice Server Development >>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>> gavagni@us.ibm.com >>>> >>>> >>>> >>>> >>>> "Shanmugham, Saravanan" >>>> 06/07/2005 02:55 PM >>>> >>>> To >>>> Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran" >>>> , , >>>> > > >>>> Subject >>>> RE: [Speechsc] RECORD method >>>> >>>> >>>> >>>> >>>> >>>> >>>> You are refering to the capability of the Media >>>> > servers capability > >>>> to access another webserver(HTTP client capability). >>>> >>>> This thread is about the Media server being capable of >>>> > recording the > >>>> audio locally and providing HTTP server access to that >>>> > recorder > >>>> content. >>>> >>>> Sarvi >>>> >>>> -----Original Message----- >>>> From: Brett Gavagni [mailto:gavagni@us.ibm.com] >>>> Sent: Tuesday, June 07, 2005 11:49 AM >>>> To: Shanmugham, Saravanan >>>> Cc: David R. Oran; speechsc@ietf.org; >>>> > speechsc-bounces@ietf.org > >>>> Subject: RE: [Speechsc] RECORD method >>>> >>>> The only comment I have is to keep the wording consistent >>>> throughout the specification. I would be careful in the >>>> deviation of terminology across sections. >>>> >>>> For example in section: 8.5. Synthesizer Message Body >>>> >>>> Synthesizer Speech Data >>>> Lexicon Data >>>> .. >>>> .. >>>> ... >>>> All media servers MUST support the >>>> HTTP uri access mechanism. >>>> >>>> Thanks, >>>> >>>> Brett Gavagni >>>> WebSphere Voice Server Development >>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>> gavagni@us.ibm.com >>>> >>>> >>>> >>>> >>>> "Shanmugham, Saravanan" Sent by: >>>> speechsc-bounces@ietf.org >>>> 06/07/2005 02:32 PM >>>> >>>> To >>>> "David R. Oran" , cc >>>> >>>> Subject >>>> RE: [Speechsc] RECORD method >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think we want to allow for HTTP as well. So, "MUST >>>> HTTPS and SHOULD HTTP" would be fine with me. >>>> >>>> Sarvi >>>> >>>> -----Original Message----- >>>> From: speechsc-bounces@ietf.org >>>> [mailto:speechsc-bounces@ietf.org] On Behalf >>>> > Of David R. > >>>> Oran >>>> Sent: Tuesday, June 07, 2005 8:29 AM >>>> To: speechsc@ietf.org ((((E-mail)))) >>>> Subject: [Speechsc] RECORD method >>>> >>>> the text says: >>>> >>>> "The RECORD request places the recorder >>>> > resource in the > >>>> Recording state. Depending on the headers >>>> > specified in the > >>>> RECORD method the resource may start >>>> > recording the audio > >>>> immediately or wait for the end pointing >>>> > functionality to > >>>> detect speech in the audio. It then saves >>>> > the audio to the > >>>> URI supplied in the recording-uri header. If the >>>> recording-uri is not specified, the server >>>> > MUST capture > >>>> the media onto a local disk and return a URI >>>> > pointing to > >>>> the recorded audio in the RECORD-COMPLETE event. The >>>> server MUST support HTTP and file URI schemes." >>>> >>>> Sorry, but a file: URI won't work - it's not >>>> > generally > >>>> usable between systems. Because of this and >>>> > the secuirty > >>>> issues, the last sentence probably ought to be: >>>> >>>> "The server MUST support the HTTPS URI scheme and MAY >>>> support other schemes. Note that due to the sensitive >>>> nature of voice recordings, any other URI schemes >>>> supported by the server SHOULD employ integrity and >>>> confidentiality on the data transfer (e.g. FTPS)." >>>> >>>> I changed the text, so let me know if this >>>> > is going to > >>>> cause heartburn. >>>> >>>> dave. >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >> >> _______________________________________________ >> 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 Jun 08 21:30:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgBsG-0000a2-Fz; Wed, 08 Jun 2005 21:30:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgBsF-0000Zx-Or for speechsc@megatron.ietf.org; Wed, 08 Jun 2005 21:30:23 -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 VAA13228 for ; Wed, 8 Jun 2005 21:30:21 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgCD5-0005Ts-V4 for speechsc@ietf.org; Wed, 08 Jun 2005 21:51:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2005 18:29:42 -0700 Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j591Tclq009072; Wed, 8 Jun 2005 18:29:39 -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] "Race" condition between RECOGNIZE.request and med ia Date: Wed, 8 Jun 2005 18:31:43 -0700 Message-ID: <6677B3346233B94EBB11C060935101200B770B03@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Speechsc] "Race" condition between RECOGNIZE.request and med ia Thread-Index: AcVsJomC25ljhc5/QmKv0+ePH7v5ewAa1nig From: "Shanmugham, Saravanan" To: "David R. Oran" , "Reifenrath, Klaus" X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, qzhou@research.bell-labs.com 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 Done't we want to specifically disallow using data buffered before the RECOGNIZE method is received by the resource. The problem is some one is going to implement some amount of buffering at the input. If someone set this to be large you could be recognizing data from something that was spoken well before the recognize.=20 That's what we are trying to avoid by this paragraph. I think I like Dave's proposal, that the recognizer use at most a fixed length/in time of data that is already in the buffer when the RECOGNIZE method is received by the recognizer. Limiting it to 1 or 2 RTT sounds reasonable. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Wednesday, June 08, 2005 5:31 AM To: Reifenrath, Klaus Cc: 'speechsc@ietf.org'; 'qzhou@research.bell-labs.com' Subject: Re: [Speechsc] "Race" condition between=20 RECOGNIZE.request and med ia =20 =20 On Jun 8, 2005, at 7:56 AM, Reifenrath, Klaus wrote: =20 > I also vote for removing the old and fuzzy MRCPv1 text=20 "Note that=20 > since the audio and the messages are carried over separate=20 > communication paths there may be a race condition=20 between the start of=20 > the flow of audio and the receipt of the RECOGNIZE method. For=20 > example, if an audio flow is started by the client at=20 the same time as=20 > the RECOGNIZE method is sent, either the audio or the=20 RECOGNIZE can=20 > arrive at the recognizer first. As another example, the=20 client may=20 > chose to continuously send audio to the Server and=20 signal the Server=20 > to recognize using the RECOGNIZE method. A number of=20 mechanisms exist=20 > to resolve this condition and the mechanism chosen is=20 left to the=20 > implementers of recognition resource." > > BUT I agree with Brett, we should keep the last sentence=20 (that was not=20 > in the MRCPv1 spec): > "The recognizer should expect the media to start flowing when it=20 > receives the recognize request, but should not buffer=20 anything it=20 > receives beforehand." > Ok, I think we have consensus on this. =20 > BTW: Shouldn't the 'should' be a 'SHOULD' in the last sentence? > I don't think so. My concern is that implementers take=20 this literally and try to dump an active jitter buffer=20 when they receive the RECOGNIZE, which is unnecessary and=20 probalby the wrong thing to do. =20 If in fact the client starts sending audio at the exact=20 moment it issues the RECOGNIZE, it is in fact likely that=20 a few media packets will in fact arrive before the=20 RECOGNIZE, because of the differential QoS the media=20 likely has. There is also the possibility of a lost=20 control packet and TCP retransmission. =20 So, I think the point is that we want semantics that do=20 not require extra server machinery to deal with the cases=20 where the media and control channels become mis-synchronized. =20 I think the above wording is ok, but if we want to capture=20 this point accurately, an alternative wording might be: =20 "The recognizer should expect the media to start flowing=20 when it receives the recognize request, but need not take=20 special action to buffer anything it receives beforehand=20 to process media which arrives before the MRCPv2 control=20 channel message." =20 Dave. =20 > Klaus > > > -----Original Message----- > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > Sent: Dienstag, 7. Juni 2005 23:45 > To: Brett Gavagni > Cc: speechsc@ietf.org ((((E-mail)))); speechsc-bounces@ietf.org > Subject: Re: [Speechsc] "Race" condition between=20 RECOGNIZE.request =20 > and media > > To me, this line implies that RECOGNIZE is the trigger=20 signal to let > recognizer to start listening (buffer and do=20 recognition). It is =20 > not clear > to me why the recognizer need to buffer audio before the=20 RECOGNIZE =20 > message > and it is ambiguous to do that (how early and how much data to =20 > buffer). A > particular implementation may choose to do something=20 like that for =20 > signal > processing purpose I guess but it is the implementation=20 detail. So =20 > I'd vote > keep the line below and nuke the rest. > > -- Qiru > > Brett Gavagni wrote: > >> I would vote to leave the wording, or at a minimum keep=20 the following >> line. This statement can be quite helpful in mitigating=20 potential >> client/server interoperability issues. >> >> "The recognizer should expect the media to start flowing when it >> receives the recognize request, but should not buffer=20 anything it >> receives beforehand." >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "David R. Oran" >> Sent by: speechsc-bounces@ietf.org >> 06/07/2005 09:53 AM >> >> To >> "speechsc@ietf.org ((((E-mail))))" cc >> >> Subject >> [Speechsc] "Race" condition between RECOGNIZE.request and media >> >> >> >> >> >> >> The text says: >> >> "Note that since the audio and the messages are carried=20 over separate >> communication paths there may be a race condition between the =20 >> start of >> the flow of audio and the receipt of the RECOGNIZE method. For >> example, if an audio flow is started by the client at the same =20 >> time as >> the RECOGNIZE method is sent, either the audio or the=20 RECOGNIZE can >> arrive at the recognizer first. As another example, the=20 client may >> chose to continuously send audio to the Server and=20 signal the Server >> to recognize using the RECOGNIZE method. A number of=20 mechanisms exist >> to resolve this condition and the mechanism chosen is=20 left to the >> implementers of recognition resource. The recognizer=20 should expect =20 >> the >> media to start flowing when it receives the recognize=20 request, but >> should not buffer anything it receives beforehand." >> >> Either this race condition doesn't matter, in which=20 case we should >> either just nuke this paragraph or take out the=20 should/should not >> guidance at the end, or it does matter, in which case this =20 >> material is >> wholly inadequate. >> >> If the synchronization of the control and media=20 channels matters, =20 >> then >> we really do need to fix the protocol. Luckily, this is=20 relatively >> easy to do: >> >> a) recommend that servers with recognizers buffer at=20 least an RTT >> worth of media. >> b) include an NTP timestamp of where in the the input media >> recognition should start in a RECOGNIZE request header. >> c) define an error to cover the "lost media" case. >> >> My gut tells me that for recognition none of this is=20 necessary and we >> should just nuke the paragraph above as making=20 implementers think >> about something they can only screw up if they work too=20 hard at it. >> >> _______________________________________________ >> 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 >> > =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 Jun 09 01:46:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgFrm-00061T-UT; Thu, 09 Jun 2005 01:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgFri-00061J-GB for speechsc@megatron.ietf.org; Thu, 09 Jun 2005 01:46:08 -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 BAA02830 for ; Thu, 9 Jun 2005 01:46:05 -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 1DgGCc-00010J-KQ for speechsc@ietf.org; Thu, 09 Jun 2005 02:07:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2005 22:45:11 -0700 X-IronPort-AV: i="3.93,184,1115017200"; d="scan'208"; a="276326082:sNHT27377368" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j595j8lq003793 for ; Wed, 8 Jun 2005 22:45:08 -0700 (PDT) Received: from [10.42.7.184] (rtp-vpn2-774.cisco.com [10.82.243.6]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j595X7pX004991 for ; Wed, 8 Jun 2005 22:33:08 -0700 Resent-Message-Id: <9D30FB94-672E-42A7-A37C-7C26BE377CAA@cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Resent-Date: Wed, 8 Jun 2005 20:08:50 -0400 Message-Id: <63A4544C-22BA-417A-A4C3-E190C992BAC3@cisco.com> Content-Transfer-Encoding: 7bit Resent-To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Resent-From: "David R. Oran" Date: Thu, 2 Jun 2005 14:00:37 -0400 To: Saravanan Shanmugham , Dan Burnett , "Eric W. Burger" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118295188.903916"; x:"432200"; a:"rsa-sha1"; b:"nofws:299"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"oHgbxnuHFEKzUzbjwiSGyGNN6eQHB3t0urVBT6dSo1vTsdRBJjBPt4yr6jm3i523EeelzbC/" "tNmnHpVdZ1x7k2/VJz5P+EP1myZ1q2ndu3zsZLkkyC7B4+48xiYUqMlbOcx2fSjzjRyLZsYC7rD" "rOiv0nyKsa8cxnul2GUE7axs="; c:"From: =22David R. Oran=22 "; c:"Subject: save-waveform"; c:"Date: Thu, 2 Jun 2005 14:00:37 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.7 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Speechsc] save-waveform 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 Do implementers have to take the name "save-waveform" literally? If so, we need to say that only raw uncompressed audio is acceptable in the stored format. I suspect we don't mean that. We could change the header name, or explain that the captured media is just required to not be lossy compared to the input that the recognizer received. What's your pleasure? _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 09 05:03:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgIwd-0002Se-PH; Thu, 09 Jun 2005 05:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgIwb-0002SP-1f for speechsc@megatron.ietf.org; Thu, 09 Jun 2005 05:03:23 -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 FAA05078 for ; Thu, 9 Jun 2005 05:03:18 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([198.71.67.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgJHW-0000Q2-Qk for Speechsc@ietf.org; Thu, 09 Jun 2005 05:25:00 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Thu, 9 Jun 2005 05:02:40 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'qzhou@research.bell-labs.com'" , Corby Anderson Subject: RE: [Speechsc] Managing big grammars Date: Thu, 9 Jun 2005 05:02:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 do not think that a standard for compiled grammar is required, because the client does not need to process the compiled grammar. It only passes the URI to the engine. In networks with MRCP servers from different vendors the client (only) need to take care, that the grammar is compiled by an MRCP server of the same vendor that will be used for recognition. Note: There exists no standard for voice enrolled grammars. Hence we have the same situation (no standard, client need to choose same vendor for enrolment and recognition) for enrolment. Klaus -----Original Message----- From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] Sent: Mittwoch, 8. Juni 2005 23:17 To: Corby Anderson Cc: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars I think the problem here is there is no standard for compiled grammar format. This is a vendor implementation specific which is not inter-operable across different vendors. I agree that pre-compiled large grammars can improve system response and processing efficiency. But I don't know if this should be the part of standard. Same for cache, it is an implementation specific issue. Another practice on this issue is to pre load and archive large grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). -- Qiru Corby Anderson wrote: > One feature that I'd like a COMPILE-GRAMMAR method to provide is the > ability to specify common back-end storage (like Sarvi mentioned) so > that compiling a Large Grammar one time could make it available to > other MRCP servers via the Compiled-Grammar-URI that Klaus suggested. > It would be especially useful to us if the *client* could specify the > URI where the grammar should be stored. This would permit clients to > use grammar names that are meaningful to the client. (The example for > Personal-Grammar-URI seems like the grammar name is specified by the > client, but it's worth spelling out.) > > To round out the utility of a feature like this, we'd need some way to > determine if a grammar had already been compiled. Since we're talking > about URIs, the client could just do a HEAD on the grammar to see if > it exists -- but does the client always have access to back-end > resources in this way? If not, then a QUERY-GRAMMAR method which > takes a Compiled-Grammar-URI header could provide this capability. > > Corby Anderson > Tellme Networks, Inc. > > > Reifenrath, Klaus wrote: > >> I agree. >> BUT unfortunately there is no MRCPv2 interface to just compile a >> grammar. So grammar compilation needs to be done with vendor specific >> tools or APIs. >> We could add a new method (allowed only in idle state): >> COMPILE-GRAMMAR >> that requires the header field >> Compiled-Grammar-URI >> that specifies the location of the compiled grammar (like >> Personal-Grammar-URI). >> Is it too late to add this simple optional method? >> >> Klaus >> >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Dienstag, >> 7. Juni 2005 21:09 >> To: Corby Anderson; Speechsc@ietf.org >> Subject: RE: [Speechsc] Managing big grammars >> >> Sorry for the late reply. The way I think this should be addressed is >> to have support for compiled grammars as URI. All Large or Huge >> grammars are going to be URI referenced and never embedded in a DEFINE grammar. >> This means that the URI could point to compiled grammar file. >> >> Another way is to use the chache capability. When you access a >> grammar through HTTP is to cache it. In general instead of caching of >> the XML grammar you could decide to cache the compiled version >> instead. This would mean that you might do an initial DEFINE-GRAMMAR >> to force a compile of the grammar and future references to that >> grammar URI would hit the cache and hence the compiled version. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM >> To: Speechsc@ietf.org >> Subject: [Speechsc] Managing big grammars >> What are folks' thoughts on how we could manage big >> grammars with MRCP? >> There are two usage cases that I'm interested in: a Large >> Grammar that takes several seconds to compile, and a Jumbo Grammar >> that takes many many minutes to compile. A Large Grammar might >> contain several hundred or thousand entries. A Jumbo Grammar >> might contain hundreds of thousands of entries. >> For a Jumbo Grammar, there's no way that a user can wait >> for a grammar to be uploaded and compiled via the DEFINE-GRAMMAR >> or RECOGNIZE methods. A grammar that large needs to be >> pre-compiled so that the DEFINE-GRAMMAR or RECOGNIZE method can >> simply load the grammar binary. >> For a Large Grammar, it might be okay to make one user >> wait a few seconds for the grammar to compile -- but it would be a >> big win if that compiled grammar were stored with a known name so >> that /subsequent/ uses of the same grammar don't have to pay the >> same compilation penalty. >> Our current speech recognition vendor's api provides >> methods for checking for the existence of a dynamic grammar, and >> for compiling a new grammar (named as the client specifies). The >> api also provides a powerful and flexible way to manage these >> stored grammars. Is there some MRCP-friendly way for dealing with >> these types of grammars? If not, then is one being considered? >> Corby Anderson >> Tellme Networks, Inc. >> _______________________________________________ >> 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 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 09 05:47:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgJcz-0001w5-0K; Thu, 09 Jun 2005 05:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgJcw-0001vs-SG for speechsc@megatron.ietf.org; Thu, 09 Jun 2005 05:47: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 FAA07366 for ; Thu, 9 Jun 2005 05:47:04 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgJxp-0001WZ-UW for speechsc@ietf.org; Thu, 09 Jun 2005 06:08:46 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2005 02:46:08 -0700 X-IronPort-AV: i="3.93,184,1115017200"; d="scan'208"; a="642260497:sNHT27925436" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j599k5lw005720 for ; Thu, 9 Jun 2005 02:46:05 -0700 (PDT) Received: from [10.42.7.184] (rtp-vpn2-774.cisco.com [10.82.243.6]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j599Y4qI005890 for ; Thu, 9 Jun 2005 02:34:04 -0700 Resent-Message-Id: <057701c56cd6$15971070$0a01a8c0@db01.voxpilot.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Resent-Date: Thu, 9 Jun 2005 05:46:01 -0400 Message-Id: Content-Transfer-Encoding: 7bit Resent-To: "speechsc@ietf.org ((((E-mail))))" From: "Dave Burke" Subject: Re: [Speechsc] save-waveform Resent-From: "David R. Oran" Date: Thu, 9 Jun 2005 10:31:58 +0100 To: "David R. Oran" , "Saravanan Shanmugham" , "Dan Burnett" , "Eric W. Burger" X-Mailer: Apple Mail (2.730) IIM-VERIFY: s:"n"; v:"n"; r:"0"; h:"imail.cisco.com"; X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Not sure how I missed this before but I thought there was a Save- Waveform-Type (a la Media-Type with RECORD) to specify what format to record the utterance in. Taking the VoiceXML parochial view, we need to specify the format to implement http://www.w3.org/TR/2004/WD-voicexml21-20040728/#sec- reco_reco-type. Can suggest the text (given I let the worms out). Dave ----- Original Message ----- From: "David R. Oran" To: "Saravanan Shanmugham" ; "Dan Burnett" ; "Eric W. Burger" Sent: Thursday, June 02, 2005 7:00 PM Subject: [Speechsc] save-waveform > Do implementers have to take the name "save-waveform" literally? > If so, we need to say that only raw uncompressed audio is > acceptable in the stored format. I suspect we don't mean that. > > We could change the header name, or explain that the captured > media is just required to not be lossy compared to the input that > the recognizer received. > > What's your pleasure? > > _______________________________________________ > 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 Thu Jun 09 17:17:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgUOf-0008Fc-My; Thu, 09 Jun 2005 17:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgUOd-0008FX-AI for speechsc@megatron.ietf.org; Thu, 09 Jun 2005 17:17:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20753 for ; Thu, 9 Jun 2005 17:17:00 -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 1DgUkA-0004EZ-Be for speechsc@ietf.org; Thu, 09 Jun 2005 17:39:18 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2005 14:16:52 -0700 X-IronPort-AV: i="3.93,187,1115017200"; d="scan'208"; a="276692893:sNHT30970580" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j59LGnbw002039; Thu, 9 Jun 2005 14:16:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Thu, 9 Jun 2005 14:16:48 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C019D5C@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVscGIfD/8uIVTPSkmZ12efoFBCegAvUc9A From: "Shanmugham, Saravanan" To: , "Corby Anderson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 agree, the issue is that there is no standard for compilation and compiled grammar format. I am not sure a COMPILE-GRAMMAR method is the solution to this.=20 The aim of compilation is to accelarate customer response when dealing with large-grammars. A few ways to achieve the above, like I mentioned earlier are, 1. The MRCP server could implement an optimization for large grammars that leverages the grammar caching mechanism and its capabilities. That is when they cache a grammar URI, they also store the compiled version of the grammar. They could do this in a vendor specific compiled format. Large grammars are usually not dynamic and hence the caching mechanims should work reasonably well for this. 2. Have the MRCP client point to pre-compiled-grammars so that when the MRCP server goes and fetches it the large-grammar is already compiled. There is the problem of making sure the compiled grammar(vendor-specific) matches the specific recognition engine used. This is difficult to manage in a multivendor deployment. 3. Compile and store the grammars on the MRCP server ahead of time during deployments. And then refer to these compiled grammars on the MRCP server. This would have its own limitations, but would be workable in many cases/deployments. We could add the text for the first above bullet into the MRCPv2 specification if no one has any objects to it. Thanks, -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Qiru Zhou Sent: Wednesday, June 08, 2005 2:17 PM To: Corby Anderson Cc: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I think the problem here is there is no standard for=20 compiled grammar format. This is a vendor implementation=20 specific which is not inter-operable across different=20 vendors. I agree that pre-compiled large grammars can=20 improve system response and processing efficiency. But I=20 don't know if this should be the part of standard. Same=20 for cache, it is an implementation specific issue. Another=20 practice on this issue is to pre load and archive large=20 grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). =20 -- Qiru =20 Corby Anderson wrote: > One feature that I'd like a COMPILE-GRAMMAR method to=20 provide is the=20 > ability to specify common back-end storage (like Sarvi=20 mentioned) so=20 > that compiling a Large Grammar one time could make it=20 available to=20 > other MRCP servers via the Compiled-Grammar-URI that=20 Klaus suggested. =20 > It would be especially useful to us if the *client*=20 could specify the=20 > URI where the grammar should be stored. This would=20 permit clients to=20 > use grammar names that are meaningful to the client. =20 (The example for=20 > Personal-Grammar-URI seems like the grammar name is=20 specified by the=20 > client, but it's worth spelling out.) >=20 > To round out the utility of a feature like this, we'd=20 need some way to=20 > determine if a grammar had already been compiled. Since=20 we're talking=20 > about URIs, the client could just do a HEAD on the=20 grammar to see if=20 > it exists -- but does the client always have access to back-end=20 > resources in this way? If not, then a QUERY-GRAMMAR=20 method which=20 > takes a Compiled-Grammar-URI header could provide this=20 capability. >=20 > Corby Anderson > Tellme Networks, Inc. >=20 >=20 > Reifenrath, Klaus wrote: >=20 >> I agree. >> BUT unfortunately there is no MRCPv2 interface to just=20 compile a=20 >> grammar. So grammar compilation needs to be done with=20 vendor specific=20 >> tools or APIs. >> We could add a new method (allowed only in idle state): >> COMPILE-GRAMMAR >> that requires the header field >> Compiled-Grammar-URI >> that specifies the location of the compiled grammar (like=20 >> Personal-Grammar-URI). >> Is it too late to add this simple optional method? >> >> Klaus >> >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Dienstag,=20 >> 7. Juni 2005 21:09 >> To: Corby Anderson; Speechsc@ietf.org >> Subject: RE: [Speechsc] Managing big grammars >> >> Sorry for the late reply. The way I think this should=20 be addressed is=20 >> to have support for compiled grammars as URI. All Large or Huge=20 >> grammars are going to be URI referenced and never=20 embedded in a DEFINE grammar. >> This means that the URI could point to compiled grammar file. >> >> Another way is to use the chache capability. When you access a=20 >> grammar through HTTP is to cache it. In general instead=20 of caching of=20 >> the XML grammar you could decide to cache the compiled version=20 >> instead. This would mean that you might do an initial=20 DEFINE-GRAMMAR=20 >> to force a compile of the grammar and future references to that=20 >> grammar URI would hit the cache and hence the compiled version. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org =20 >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM >> To: Speechsc@ietf.org >> Subject: [Speechsc] Managing big grammars >> What are folks' thoughts on how we could manage big =20 >> grammars with MRCP? >> There are two usage cases that I'm interested=20 in: a Large =20 >> Grammar that takes several seconds to compile, and a=20 Jumbo Grammar=20 >> that takes many many minutes to compile. A Large =20 Grammar might=20 >> contain several hundred or thousand entries. A=20 Jumbo Grammar=20 >> might contain hundreds of thousands of entries. >> For a Jumbo Grammar, there's no way that a user=20 can wait =20 >> for a grammar to be uploaded and compiled via the =20 DEFINE-GRAMMAR=20 >> or RECOGNIZE methods. A grammar that large needs to be=20 >> pre-compiled so that the DEFINE-GRAMMAR or =20 RECOGNIZE method can=20 >> simply load the grammar binary. >> For a Large Grammar, it might be okay to make=20 one user =20 >> wait a few seconds for the grammar to compile -- but it=20 would be a=20 >> big win if that compiled grammar were stored with a=20 known name so=20 >> that /subsequent/ uses of the same grammar don't=20 have to pay the=20 >> same compilation penalty. >> Our current speech recognition vendor's api=20 provides =20 >> methods for checking for the existence of a dynamic =20 grammar, and=20 >> for compiling a new grammar (named as the client=20 specifies). The=20 >> api also provides a powerful and flexible way to=20 manage these=20 >> stored grammars. Is there some MRCP-friendly way=20 for dealing with=20 >> these types of grammars? If not, then is one being=20 considered? >> Corby Anderson >> Tellme Networks, Inc. >> _______________________________________________ >> 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 >> >=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 Fri Jun 10 14:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgobz-0001B0-Rp; Fri, 10 Jun 2005 14:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgobx-0001Av-Nw for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 14:52:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19673 for ; Fri, 10 Jun 2005 14:52:07 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgoxf-00052o-DW for Speechsc@ietf.org; Fri, 10 Jun 2005 15:14:36 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id 3B3503511 for ; Fri, 10 Jun 2005 11:51:36 -0700 (PDT) Received: from [172.20.51.104] (dhcp172-51-104.corp.tellme.com [172.20.51.104]) by mail02.corp.tellme.com (Postfix) with ESMTP id 032893507 for ; Fri, 10 Jun 2005 11:51:36 -0700 (PDT) Message-ID: <42A9E137.7070606@tellme.com> Date: Fri, 10 Jun 2005 11:51:35 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars References: <03772D1EC8DE624A863058C75874A75C019D5C@vtg-um-e2k6.sj21ad.cisco.com> In-Reply-To: <03772D1EC8DE624A863058C75874A75C019D5C@vtg-um-e2k6.sj21ad.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e 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="===============2125187463==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============2125187463== Content-Type: multipart/alternative; boundary="------------050200070902030206080402" This is a multi-part message in MIME format. --------------050200070902030206080402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Option #1 seems like a step in the right direction, but having multi-server re-use would make it even more useful. Option #1 as worded implies that /each /MRCP server would have to compile grammar "X" the first time it's used; I'm suggesting that we try and make one MRCP server's compilation efforts useful to other MRCP servers (as long as they're the same vendor). The use case I have in mind is a "farm" of recognition servers -- and when we compile one of these Large grammars (grammar "X"), it would be great to store it in some common storage area so that other MRCP servers could check for its existence and load the binary. It isn't necessary to have a standard compiled grammar format -- it's just necessary to have a standard way to reference them. In a server farm environment containing multiple vendors' MRCP servers, wouldn't the client know (or couldn't it discover during session setup) which kind of server it was connecting to and so adjust the query/compile uri accordingly? I envision something along the lines of: MRCP/2.0 82 QUERY-GRAMMAR 123456 Compiled-Grammar-URI: http://grammar-resource//query?name= MRCP/2.0 507 COMPILE-GRAMMAR 123654 Compiled-Grammar-URI: http://grammar-resource//store?name= Content-type: application/srgs+xml Content-Length: 176 I agree, the issue is that there is no standard for compilation and >compiled grammar format. I am not sure a COMPILE-GRAMMAR method is the >solution to this. > >The aim of compilation is to accelarate customer response when dealing >with large-grammars. >A few ways to achieve the above, like I mentioned earlier are, > 1. The MRCP server could implement an optimization for large grammars >that leverages the grammar caching mechanism and its capabilities. That >is when they cache a grammar URI, they also store the compiled version >of the grammar. They could do this in a vendor specific compiled format. >Large grammars are usually not dynamic and hence the caching mechanims >should work reasonably well for this. > 2. Have the MRCP client point to pre-compiled-grammars so that when >the MRCP server goes and fetches it the large-grammar is already >compiled. There is the problem of making sure the compiled >grammar(vendor-specific) matches the specific recognition engine used. >This is difficult to manage in a multivendor deployment. > 3. Compile and store the grammars on the MRCP server ahead of time >during deployments. And then refer to these compiled grammars on the >MRCP server. This would have its own limitations, but would be workable >in many cases/deployments. > > >We could add the text for the first above bullet into the MRCPv2 >specification if no one has any objects to it. > >Thanks, > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Qiru Zhou > Sent: Wednesday, June 08, 2005 2:17 PM > To: Corby Anderson > Cc: Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > I think the problem here is there is no standard for > compiled grammar format. This is a vendor implementation > specific which is not inter-operable across different > vendors. I agree that pre-compiled large grammars can > improve system response and processing efficiency. But I > don't know if this should be the part of standard. Same > for cache, it is an implementation specific issue. Another > practice on this issue is to pre load and archive large > grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). > > -- Qiru > > Corby Anderson wrote: > > One feature that I'd like a COMPILE-GRAMMAR method to > provide is the > > ability to specify common back-end storage (like Sarvi > mentioned) so > > that compiling a Large Grammar one time could make it > available to > > other MRCP servers via the Compiled-Grammar-URI that > Klaus suggested. > > It would be especially useful to us if the *client* > could specify the > > URI where the grammar should be stored. This would > permit clients to > > use grammar names that are meaningful to the client. > (The example for > > Personal-Grammar-URI seems like the grammar name is > specified by the > > client, but it's worth spelling out.) > > > > To round out the utility of a feature like this, we'd > need some way to > > determine if a grammar had already been compiled. Since > we're talking > > about URIs, the client could just do a HEAD on the > grammar to see if > > it exists -- but does the client always have access to back-end > > resources in this way? If not, then a QUERY-GRAMMAR > method which > > takes a Compiled-Grammar-URI header could provide this > capability. > > > > Corby Anderson > > Tellme Networks, Inc. > > > > > > Reifenrath, Klaus wrote: > > > >> I agree. > >> BUT unfortunately there is no MRCPv2 interface to just > compile a > >> grammar. So grammar compilation needs to be done with > vendor specific > >> tools or APIs. > >> We could add a new method (allowed only in idle state): > >> COMPILE-GRAMMAR > >> that requires the header field > >> Compiled-Grammar-URI > >> that specifies the location of the compiled grammar (like > >> Personal-Grammar-URI). > >> Is it too late to add this simple optional method? > >> > >> Klaus > >> > >> -----Original Message----- > >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Dienstag, > >> 7. Juni 2005 21:09 > >> To: Corby Anderson; Speechsc@ietf.org > >> Subject: RE: [Speechsc] Managing big grammars > >> > >> Sorry for the late reply. The way I think this should > be addressed is > >> to have support for compiled grammars as URI. All Large or Huge > >> grammars are going to be URI referenced and never > embedded in a DEFINE grammar. > >> This means that the URI could point to compiled grammar file. > >> > >> Another way is to use the chache capability. When you access a > >> grammar through HTTP is to cache it. In general instead > of caching of > >> the XML grammar you could decide to cache the compiled version > >> instead. This would mean that you might do an initial > DEFINE-GRAMMAR > >> to force a compile of the grammar and future references to that > >> grammar URI would hit the cache and hence the compiled version. > >> > >> Sarvi > >> > >> -----Original Message----- > >> From: speechsc-bounces@ietf.org > >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson > >> Sent: Thursday, May 26, 2005 2:11 PM > >> To: Speechsc@ietf.org > >> Subject: [Speechsc] Managing big grammars > >> What are folks' thoughts on how we could manage big > >> grammars with MRCP? > >> There are two usage cases that I'm interested > in: a Large > >> Grammar that takes several seconds to compile, and a > Jumbo Grammar > >> that takes many many minutes to compile. A Large > Grammar might > >> contain several hundred or thousand entries. A > Jumbo Grammar > >> might contain hundreds of thousands of entries. > >> For a Jumbo Grammar, there's no way that a user > can wait > >> for a grammar to be uploaded and compiled via the > DEFINE-GRAMMAR > >> or RECOGNIZE methods. A grammar that large needs to be > >> pre-compiled so that the DEFINE-GRAMMAR or > RECOGNIZE method can > >> simply load the grammar binary. > >> For a Large Grammar, it might be okay to make > one user > >> wait a few seconds for the grammar to compile -- but it > would be a > >> big win if that compiled grammar were stored with a > known name so > >> that /subsequent/ uses of the same grammar don't > have to pay the > >> same compilation penalty. > >> Our current speech recognition vendor's api > provides > >> methods for checking for the existence of a dynamic > grammar, and > >> for compiling a new grammar (named as the client > specifies). The > >> api also provides a powerful and flexible way to > manage these > >> stored grammars. Is there some MRCP-friendly way > for dealing with > >> these types of grammars? If not, then is one being > considered? > >> Corby Anderson > >> Tellme Networks, Inc. > >> _______________________________________________ > >> 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 > > > --------------050200070902030206080402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Option #1 seems like a step in the right direction, but having multi-server re-use would make it even more useful. Option #1 as worded implies that each MRCP server would have to compile grammar "X" the first time it's used;  I'm suggesting that we try and make one MRCP server's compilation efforts useful to other MRCP servers (as long as they're the same vendor).  The use case I have in mind is a "farm" of recognition servers -- and when we compile one of these Large grammars (grammar "X"), it would be great to store it in some common storage area so that other MRCP servers could check for its existence and load the binary. 
It isn't necessary to have a standard compiled grammar format -- it's just necessary to have a standard way to reference them.  In a server farm environment containing multiple vendors' MRCP servers, wouldn't the client know (or couldn't it discover during session setup) which kind of server it was connecting to and so adjust the query/compile uri accordingly?  I envision something along the lines of:

MRCP/2.0 82 QUERY-GRAMMAR 123456
Compiled-Grammar-URI: http://grammar-resource/<insert_vendor_here>/query?name=<grammar_name>


MRCP/2.0 507 COMPILE-GRAMMAR 123654
Compiled-Grammar-URI: http://grammar-resource/<insert_vendor_here>/store?name=<grammar_name>
Content-type: application/srgs+xml
Content-Length: 176

<?xml version="1.0" (etc.)

Where the "grammar-resource" would be simple and general enough to be implemented by either the client or the vendor.

Corby Anderson
Tellme Networks, Inc.

Shanmugham, Saravanan wrote: 
I agree, the issue is that there is no standard for compilation and
compiled grammar format.  I am not sure a COMPILE-GRAMMAR method is the
solution to this. 

The aim of compilation is to accelarate customer response when dealing
with large-grammars.
A few ways to achieve the above, like I mentioned earlier are,
   1. The MRCP server could implement an optimization for large grammars
that leverages the grammar caching mechanism and its capabilities. That
is when they cache a grammar URI, they also store the compiled version
of the grammar. They could do this in a vendor specific compiled format.
Large grammars are usually not dynamic and hence the caching mechanims
should work reasonably well for this.
   2. Have the MRCP client point to pre-compiled-grammars so that when
the MRCP server goes and fetches it the large-grammar is already
compiled. There is the problem of making sure the compiled
grammar(vendor-specific) matches the specific recognition engine used.
This is difficult to manage in a multivendor deployment.
   3. Compile and store the grammars on the MRCP server ahead of time
during deployments. And then refer to these compiled grammars on the
MRCP server. This would have its own limitations, but would be workable
in many cases/deployments.


We could add the text for the first above bullet into the MRCPv2
specification if no one has any objects to it.

Thanks,

     -----Original Message-----
     From: speechsc-bounces@ietf.org 
     [mailto:speechsc-bounces@ietf.org] On Behalf Of Qiru Zhou
     Sent: Wednesday, June 08, 2005 2:17 PM
     To: Corby Anderson
     Cc: Speechsc@ietf.org
     Subject: Re: [Speechsc] Managing big grammars
     
     I think the problem here is there is no standard for 
     compiled grammar format. This is a vendor implementation 
     specific which is not inter-operable across different 
     vendors. I agree that pre-compiled large grammars can 
     improve system response and processing efficiency. But I 
     don't know if this should be the part of standard. Same 
     for cache, it is an implementation specific issue. Another 
     practice on this issue is to pre load and archive large 
     grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method).
     
     -- Qiru
     
     Corby Anderson wrote:
     > One feature that I'd like a COMPILE-GRAMMAR method to 
     provide is the 
     > ability to specify common back-end storage (like Sarvi 
     mentioned) so 
     > that compiling a Large Grammar one time could make it 
     available to 
     > other MRCP servers via the Compiled-Grammar-URI that 
     Klaus suggested.  
     > It would be especially useful to us if the *client* 
     could specify the 
     > URI where the grammar should be stored.  This would 
     permit clients to 
     > use grammar names that are meaningful to the client.  
     (The example for 
     > Personal-Grammar-URI seems like the grammar name is 
     specified by the 
     > client, but it's worth spelling out.)
     > 
     > To round out the utility of a feature like this, we'd 
     need some way to 
     > determine if a grammar had already been compiled.  Since 
     we're talking 
     > about URIs, the client could just do a HEAD on the 
     grammar to see if 
     > it exists -- but does the client always have access to back-end 
     > resources in this way?  If not, then a QUERY-GRAMMAR 
     method which 
     > takes a Compiled-Grammar-URI header could provide this 
     capability.
     > 
     > Corby Anderson
     > Tellme Networks, Inc.
     > 
     > 
     > Reifenrath, Klaus wrote:
     > 
     >> I agree.
     >> BUT unfortunately there is no MRCPv2 interface to just 
     compile a 
     >> grammar. So grammar compilation needs to be done with 
     vendor specific 
     >> tools or APIs.
     >> We could add a new method (allowed only in idle state):
     >> COMPILE-GRAMMAR
     >> that requires the header field
     >> Compiled-Grammar-URI
     >> that specifies the location of the compiled grammar (like 
     >> Personal-Grammar-URI).
     >> Is it too late to add this simple optional method?
     >>
     >> Klaus
     >>
     >> -----Original Message-----
     >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] 
     Sent: Dienstag, 
     >> 7. Juni 2005 21:09
     >> To: Corby Anderson; Speechsc@ietf.org
     >> Subject: RE: [Speechsc] Managing big grammars
     >>
     >> Sorry for the late reply. The way I think this should 
     be addressed is 
     >> to have support for compiled grammars as URI. All Large or Huge 
     >> grammars are going to be URI referenced and never 
     embedded in a DEFINE grammar.
     >> This means that the URI could point to compiled grammar file.
     >>
     >> Another way is to use the chache capability. When you access a 
     >> grammar through HTTP is to cache it. In general instead 
     of caching of 
     >> the XML grammar you could decide to cache the compiled version 
     >> instead. This would mean that you might do an initial 
     DEFINE-GRAMMAR 
     >> to force a compile of the grammar and future references to that 
     >> grammar URI would hit the cache and hence the compiled version.
     >>
     >> Sarvi
     >>
     >>     -----Original Message-----
     >>     From: speechsc-bounces@ietf.org     
     >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson
     >>     Sent: Thursday, May 26, 2005 2:11 PM
     >>     To: Speechsc@ietf.org
     >>     Subject: [Speechsc] Managing big grammars
     >>         What are folks' thoughts on how we could manage big     
     >> grammars with MRCP?
     >>         There are two usage cases that I'm interested 
     in: a Large     
     >> Grammar that takes several seconds to compile, and a 
     Jumbo     Grammar 
     >> that takes many many minutes to compile.  A Large     
     Grammar might 
     >> contain several hundred or thousand entries.      A 
     Jumbo Grammar 
     >> might contain hundreds of thousands of entries.
     >>         For a Jumbo Grammar, there's no way that a user 
     can wait     
     >> for a grammar to be uploaded and compiled via the     
     DEFINE-GRAMMAR 
     >> or RECOGNIZE methods.  A grammar that large     needs to be 
     >> pre-compiled so that the DEFINE-GRAMMAR or     
     RECOGNIZE method can 
     >> simply load the grammar binary.
     >>         For a Large Grammar, it might be okay to make 
     one user     
     >> wait a few seconds for the grammar to compile -- but it 
         would be a 
     >> big win if that compiled grammar were stored     with a 
     known name so 
     >> that /subsequent/ uses of the same     grammar don't 
     have to pay the 
     >> same compilation penalty.
     >>         Our current speech recognition vendor's api 
     provides     
     >> methods for checking for the existence of a dynamic     
     grammar, and 
     >> for compiling a new grammar (named as the     client 
     specifies). The 
     >> api also provides a powerful and     flexible way to 
     manage these 
     >> stored grammars.  Is there     some MRCP-friendly way 
     for dealing with 
     >> these types of     grammars?  If not, then is one being 
     considered?
     >>         Corby Anderson
     >>     Tellme Networks, Inc.
     >>             _______________________________________________
     >>     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
--------------050200070902030206080402-- --===============2125187463== 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 --===============2125187463==-- From speechsc-bounces@ietf.org Fri Jun 10 17:03:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgqex-0005bU-Gb; Fri, 10 Jun 2005 17:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgqew-0005bM-B3 for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 17:03:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12773 for ; Fri, 10 Jun 2005 17:03:19 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgr0f-0005W3-8p for speechsc@ietf.org; Fri, 10 Jun 2005 17:25:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2005 14:03:12 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5AL30lw025297 for ; Fri, 10 Jun 2005 14:03:00 -0700 (PDT) Received: from [10.32.131.153] ([10.32.131.153]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j5AKp4Qs020297 for ; Fri, 10 Jun 2005 13:51:04 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <784E6B6E-B696-4ADF-8F70-8D55F610BBB6@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Fri, 10 Jun 2005 17:03:07 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118436664.941170"; x:"432200"; a:"rsa-sha1"; b:"nofws:1133"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"YOo5OE5DPMqS3mfc5eewWmANrCRpYmnSxVCuhgG4wTqtIlwiDmDKjdRuzrWTZzQhWQqC4A73" "kP/Rar/b1X7+xl3tI6AVfCbV1XV1JYNKDdMOpXuWqmlPd38FaKepCoI23xtnIR7bHqFuAZmniw8" "2v4hdx04tlRw7O0X2lTQIS44="; c:"From: =22David R. Oran=22 "; c:"Subject: Security-level header in speaker verification methods"; c:"Date: Fri, 10 Jun 2005 17:03:07 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Security-level header in speaker verification 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This header is unfortunately named and will likely cause confusion and dismay among the security community, because it does not have any useful relationship to anything they would recognize as a security level. To refresh your cache, the header is described by the following text: "The Security-Level header determines the range of verification scores in which a decision of 'accepted' may be declared. This header MAY occur in SET-PARAMS, GET-PARAMS and START-SESSION methods. It can be "high" (highest security level), "medium-high", "medium" (normal security level), "medium-low", or "low" (low security level). The default value is platform specific." In addition, the terms "high", medium-high", etc. for the values are semantic-free in practice and quantized in a completely arbitrary way. I propose we rename this header to be "confidence-level" and use the same 0-1 range we do with this header for other operations like recognition. The description text would then read: "The confidence-threshold, when used on a verification resource through a SET-PARAMS, GET-PARAMS and START-SESSION method, determines the minumum verification score for which a verification decision of "accepted" may be declared by the server. See section xxx for a description of the use of this header with the recognizer resource." Objections? Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 10 18:01:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgrZL-0008Qn-7K; Fri, 10 Jun 2005 18:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgrZJ-0008QS-Bd for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 18:01:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16925 for ; Fri, 10 Jun 2005 18:01:34 -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 1Dgrv3-0000Ea-PW for speechsc@ietf.org; Fri, 10 Jun 2005 18:24:06 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2005 15:01:10 -0700 X-IronPort-AV: i="3.93,191,1115017200"; d="scan'208"; a="277186610:sNHT1215628978" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5AM13lw004981 for ; Fri, 10 Jun 2005 15:01:03 -0700 (PDT) Received: from [10.32.131.153] ([10.32.131.153]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j5ALn2c2020842 for ; Fri, 10 Jun 2005 14:49:03 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <3BABE624-14AB-492B-B9FE-AB5D322304AE@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Fri, 10 Jun 2005 18:01:06 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118440143.60286"; x:"432200"; a:"rsa-sha1"; b:"nofws:620"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"T6aZ0ZGAzp2WsS/hwTZM/Hcz76xszKCHAc8Pjtzjk3KoPtRpEr++DaTLRPg9eq+v8KRe06zj" "7aSBAuCzKHqmLU15gaHXiccXFUVeC9ZWLiTXutuQSubcPw8kLfoIT8SRGFscgTCUyIiBXilTh9j" "EpB3y1ePSCqVnOrDag5/XPVw="; c:"From: =22David R. Oran=22 "; c:"Subject: =22Device=22 in verification results"; c:"Date: Fri, 10 Jun 2005 18:01:06 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Speechsc] "Device" in verification results 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 "
This element is found within the incremental or cumulative element within the verification results. Its value indicates the apparent type of device used by the caller as determined by verification. It can have the values of "cellular-phone", "electret-phone", "carbon- button-phone" and "unknown".
Is this for real? who wants it? Can I have a bunch more values like: "darth vader environ-suit" "chipmonk vocoder" and a bunch more useful elements in the verificaiton results, like: "apparent sex" "likely sexual orientation" "has an upper respiratory infection" "is too close to the mic and will never survive the first round of "American Idol". _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 10 18:29:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgs0N-0007nj-Fm; Fri, 10 Jun 2005 18:29:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgs0M-0007ne-1I for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 18:29:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20423 for ; Fri, 10 Jun 2005 18:29:28 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgsM2-0001mE-Ns for speechsc@ietf.org; Fri, 10 Jun 2005 18:52:00 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5AMTGVB028479 for ; Fri, 10 Jun 2005 18:29:16 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5AMTGAR203116 for ; Fri, 10 Jun 2005 18:29:16 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5AMTGtb011278 for ; Fri, 10 Jun 2005 18:29:16 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5AMTGYD011273; Fri, 10 Jun 2005 18:29:16 -0400 In-Reply-To: <3BABE624-14AB-492B-B9FE-AB5D322304AE@cisco.com> Importance: Normal Subject: Re: [Speechsc] "Device" in verification results To: "David R. Oran" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Ran Zilca Date: Fri, 10 Jun 2005 18:29:12 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/10/2005 18:29:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" 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 If a device type is detected by the verification resource then it is useful to return it. For example the recognition resource may be able to use it to improve accuracy, or the application may apply different user accept/reject strategies depending on the detected device (say using different thresholds based on device). Unlike other auxilary information that may be returned from the verification resource (e.g. gender) the values of "device" are not as well-defined. I agree that the values in the spec seem technology/vendor specific and should probably be replaced. However, there's an advantage in having standard values (increases the chances of interoperability across platforms/implementations). I propose maintaining the "Device" return element, and in the spec requiring that an implementation MUST be able to return a value of "unknown", and MAY be able to return "landline-phone" and "cellular-phone" (and perhaps a few more basic values). In addition the speech should allow for vendor specific values to be added... Ran Ran Zilca Senior Software Engineer IBM T. J. Watson Research Center 1101 Kitchawan Rd. Yorktown Heights, NY 10598 http://www.research.ibm.com/CBG Voice: (914) 945-3013 Fax: (914) 945-4490 "David R. Oran" @ietf.org on 06/10/2005 06:01:06 PM Sent by: speechsc-bounces@ietf.org To: "speechsc@ietf.org ((((E-mail))))" cc: Subject: [Speechsc] "Device" in verification results "
This element is found within the incremental or cumulative element within the verification results. Its value indicates the apparent type of device used by the caller as determined by verification. It can have the values of "cellular-phone", "electret-phone", "carbon- button-phone" and "unknown".
Is this for real? who wants it? Can I have a bunch more values like: "darth vader environ-suit" "chipmonk vocoder" and a bunch more useful elements in the verificaiton results, like: "apparent sex" "likely sexual orientation" "has an upper respiratory infection" "is too close to the mic and will never survive the first round of "American Idol". _______________________________________________ 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 Jun 10 18:31:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgs1r-00083o-0i; Fri, 10 Jun 2005 18:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgs1p-00083i-C7 for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 18:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20502 for ; Fri, 10 Jun 2005 18:31:00 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgsNX-0001p8-3R for speechsc@ietf.org; Fri, 10 Jun 2005 18:53:32 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2005 15:30:53 -0700 X-IronPort-AV: i="3.93,191,1115017200"; d="scan'208"; a="642825617:sNHT26479922" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5AMUplw026174 for ; Fri, 10 Jun 2005 15:30:51 -0700 (PDT) Received: from [10.32.131.153] ([10.32.131.153]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j5AMIjlQ021058 for ; Fri, 10 Jun 2005 15:18:45 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <8125A029-7373-4046-AD42-4ABB426B321B@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Fri, 10 Jun 2005 18:30:48 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118441925.449447"; x:"432200"; a:"rsa-sha1"; b:"nofws:315"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"aPcmo0IV7IZNHXmi5C/wJ1qM8WTVtDGj/BkC6OjyEeCp5GCEyYtoX1JydbAXaDB/+O6fUAhR" "d4lwij2bKTNcNZDNlYWCxY9UydKHWo8xYCzLNONwikYlxaTlCK2O7zlC79PFBMbvAQqAZNjL79Z" "Gec7pag1sdID8okxBf+QUKeI="; c:"From: =22David R. Oran=22 "; c:"Subject: Detail on Verify method"; c:"Date: Fri, 10 Jun 2005 18:30:48 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Speechsc] Detail on Verify method 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 text says: "When both a recognizer and verification resource share the same session, the VERIFY method MUST be called prior to calling the RECOGNIZE method on the recognizer resource. In such cases, server vendors will know that verification must be enabled for a subsequent call to RECOGNIZE." Why? Seems awfully convoluted and require special-case code in the client. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 10 18:48:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgsIW-0004oh-VL; Fri, 10 Jun 2005 18:48:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgsIU-0004oR-Oj; Fri, 10 Jun 2005 18:48:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22504; Fri, 10 Jun 2005 18:48:13 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgseC-0004Fr-W2; Fri, 10 Jun 2005 19:10:45 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j5AMlw2h416806; Fri, 10 Jun 2005 18:47:58 -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 j5AMlwfH119034; Fri, 10 Jun 2005 16:47:58 -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 j5AMlvGK004380; Fri, 10 Jun 2005 16:47:58 -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 j5AMlvWY004368; Fri, 10 Jun 2005 16:47:57 -0600 In-Reply-To: To: "Dave Burke" MIME-Version: 1.0 Subject: Re: [Speechsc] save-waveform X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Fri, 10 Jun 2005 18:47:56 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/10/2005 16:47:57, Serialize complete at 06/10/2005 16:47:57 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Eric W. Burger" , speechsc@ietf.org, Saravanan Shanmugham , "David R. Oran" , speechsc-bounces@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 vote for "media-type", keeping consistent with the RECORDER resource. A similar request was recently posted to the mailing list for RECOGNIZER SET-PARAMS and GET-PARAMS. [Speechsc] propose adding "media-type" header field in RECOGNIZE or SET-PARAMS/GET-PARAMS methods http://www1.ietf.org/mail-archive/web/speechsc/current/msg01228.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Dave Burke" Sent by: speechsc-bounces@ietf.org 06/09/2005 05:31 AM To "David R. Oran" , "Saravanan Shanmugham" , "Dan Burnett" , "Eric W. Burger" cc Subject Re: [Speechsc] save-waveform Not sure how I missed this before but I thought there was a Save- Waveform-Type (a la Media-Type with RECORD) to specify what format to record the utterance in. Taking the VoiceXML parochial view, we need to specify the format to implement http://www.w3.org/TR/2004/WD-voicexml21-20040728/#sec- reco_reco-type. Can suggest the text (given I let the worms out). Dave ----- Original Message ----- From: "David R. Oran" To: "Saravanan Shanmugham" ; "Dan Burnett" ; "Eric W. Burger" Sent: Thursday, June 02, 2005 7:00 PM Subject: [Speechsc] save-waveform > Do implementers have to take the name "save-waveform" literally? > If so, we need to say that only raw uncompressed audio is > acceptable in the stored format. I suspect we don't mean that. > > We could change the header name, or explain that the captured > media is just required to not be lossy compared to the input that > the recognizer received. > > What's your pleasure? > > _______________________________________________ > 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 Fri Jun 10 19:09:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgsdB-0002XR-TS; Fri, 10 Jun 2005 19:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgsdA-0002XJ-5a for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 19:09:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23518 for ; Fri, 10 Jun 2005 19:09:36 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgsyu-0007fz-Dc for speechsc@ietf.org; Fri, 10 Jun 2005 19:32:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 10 Jun 2005 16:09:30 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5AN9Obw025625; Fri, 10 Jun 2005 16:09:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Managing big grammars Date: Fri, 10 Jun 2005 16:09:25 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05B84A@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVt7bj8q/xgY2W6SI68T5BfFvNnCwAI41VQ From: "Shanmugham, Saravanan" To: "Corby Anderson" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 466662da679e1d2dece19de64e166a5b 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="===============1045590301==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1045590301== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56E11.72A44B2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56E11.72A44B2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would say that a common cache amoung a farm of MRCP servers to optimize compilations would be a nice server side optimization and shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Friday, June 10, 2005 11:52 AM To: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =09 =09 Option #1 seems like a step in the right direction, but having multi-server re-use would make it even more useful. Option #1 as worded implies that each MRCP server would have to compile grammar "X" the first time it's used; I'm suggesting that we try and make one MRCP server's compilation efforts useful to other MRCP servers (as long as they're the same vendor). The use case I have in mind is a "farm" of recognition servers -- and when we compile one of these Large grammars (grammar "X"), it would be great to store it in some common storage area so that other MRCP servers could check for its existence and load the binary. =20 It isn't necessary to have a standard compiled grammar format -- it's just necessary to have a standard way to reference them. In a server farm environment containing multiple vendors' MRCP servers, wouldn't the client know (or couldn't it discover during session setup) which kind of server it was connecting to and so adjust the query/compile uri accordingly? I envision something along the lines of: =09 =09 MRCP/2.0 82 QUERY-GRAMMAR 123456 Compiled-Grammar-URI: http://grammar-resource//query?name=3D =09 =09 MRCP/2.0 507 COMPILE-GRAMMAR 123654 Compiled-Grammar-URI: http://grammar-resource//store?name=3D Content-type: application/srgs+xml Content-Length: 176 =09 One feature that I'd like a COMPILE-GRAMMAR method to=20 provide is the=20 > ability to specify common back-end storage (like Sarvi=20 mentioned) so=20 > that compiling a Large Grammar one time could make it=20 available to=20 > other MRCP servers via the Compiled-Grammar-URI that=20 Klaus suggested. =20 > It would be especially useful to us if the *client*=20 could specify the=20 > URI where the grammar should be stored. This would=20 permit clients to=20 > use grammar names that are meaningful to the client. =20 (The example for=20 > Personal-Grammar-URI seems like the grammar name is=20 specified by the=20 > client, but it's worth spelling out.) >=20 > To round out the utility of a feature like this, we'd=20 need some way to=20 > determine if a grammar had already been compiled. Since=20 we're talking=20 > about URIs, the client could just do a HEAD on the=20 grammar to see if=20 > it exists -- but does the client always have access to back-end=20 > resources in this way? If not, then a QUERY-GRAMMAR=20 method which=20 > takes a Compiled-Grammar-URI header could provide this=20 capability. >=20 > Corby Anderson > Tellme Networks, Inc. >=20 >=20 > Reifenrath, Klaus wrote: >=20 >> I agree. >> BUT unfortunately there is no MRCPv2 interface to just=20 compile a=20 >> grammar. So grammar compilation needs to be done with=20 vendor specific=20 >> tools or APIs. >> We could add a new method (allowed only in idle state): >> COMPILE-GRAMMAR >> that requires the header field >> Compiled-Grammar-URI >> that specifies the location of the compiled grammar (like=20 >> Personal-Grammar-URI). >> Is it too late to add this simple optional method? >> >> Klaus >> >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Dienstag,=20 >> 7. Juni 2005 21:09 >> To: Corby Anderson; Speechsc@ietf.org >> Subject: RE: [Speechsc] Managing big grammars >> >> Sorry for the late reply. The way I think this should=20 be addressed is=20 >> to have support for compiled grammars as URI. All Large or Huge=20 >> grammars are going to be URI referenced and never=20 embedded in a DEFINE grammar. >> This means that the URI could point to compiled grammar file. >> >> Another way is to use the chache capability. When you access a=20 >> grammar through HTTP is to cache it. In general instead=20 of caching of=20 >> the XML grammar you could decide to cache the compiled version=20 >> instead. This would mean that you might do an initial=20 DEFINE-GRAMMAR=20 >> to force a compile of the grammar and future references to that=20 >> grammar URI would hit the cache and hence the compiled version. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org =20 >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM >> To: Speechsc@ietf.org >> Subject: [Speechsc] Managing big grammars >> What are folks' thoughts on how we could manage big =20 >> grammars with MRCP? >> There are two usage cases that I'm interested=20 in: a Large =20 >> Grammar that takes several seconds to compile, and a=20 Jumbo Grammar=20 >> that takes many many minutes to compile. A Large =20 Grammar might=20 >> contain several hundred or thousand entries. A=20 Jumbo Grammar=20 >> might contain hundreds of thousands of entries. >> For a Jumbo Grammar, there's no way that a user=20 can wait =20 >> for a grammar to be uploaded and compiled via the =20 DEFINE-GRAMMAR=20 >> or RECOGNIZE methods. A grammar that large needs to be=20 >> pre-compiled so that the DEFINE-GRAMMAR or =20 RECOGNIZE method can=20 >> simply load the grammar binary. >> For a Large Grammar, it might be okay to make=20 one user =20 >> wait a few seconds for the grammar to compile -- but it=20 would be a=20 >> big win if that compiled grammar were stored with a=20 known name so=20 >> that /subsequent/ uses of the same grammar don't=20 have to pay the=20 >> same compilation penalty. >> Our current speech recognition vendor's api=20 provides =20 >> methods for checking for the existence of a dynamic =20 grammar, and=20 >> for compiling a new grammar (named as the client=20 specifies). The=20 >> api also provides a powerful and flexible way to=20 manage these=20 >> stored grammars. Is there some MRCP-friendly way=20 for dealing with=20 >> these types of grammars? If not, then is one being=20 considered? >> Corby Anderson >> Tellme Networks, Inc. >> _______________________________________________ >> 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 >> >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 ------_=_NextPart_001_01C56E11.72A44B2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would say that a common cache amoung a farm = of MRCP=20 servers to optimize compilations would be a nice server side = optimization and=20 shouldn't affect the MRCP protocol.
 
my 2c.
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby=20 Anderson
Sent: Friday, June 10, 2005 11:52 AM
To:=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big=20 grammars

Option #1 seems like a step in the right direction, but = having=20 multi-server re-use would make it even more useful. Option #1 as = worded=20 implies that each MRCP server would have to compile grammar "X" = the=20 first time it's used;  I'm suggesting that we try and make one = MRCP=20 server's compilation efforts useful to other MRCP servers (as long as = they're=20 the same vendor).  The use case I have in mind is a "farm" of = recognition=20 servers -- and when we compile one of these Large grammars (grammar = "X"), it=20 would be great to store it in some common storage area so that other = MRCP=20 servers could check for its existence and load the binary.  =
It isn't=20 necessary to have a standard compiled grammar format -- it's just = necessary to=20 have a standard way to reference them.  In a server farm = environment=20 containing multiple vendors' MRCP servers, wouldn't the client know = (or=20 couldn't it discover during session setup) which kind of server it was = connecting to and so adjust the query/compile uri accordingly?  I = envision something along the lines of:

MRCP/2.0 82 QUERY-GRAMMAR 123456
Compiled-Grammar-URI: = http://grammar-resource/<insert_= vendor_here>/query?name=3D<grammar_name>


MRCP/2.0=20 507 COMPILE-GRAMMAR 123654
Compiled-Grammar-URI: http://grammar-resource/<insert_= vendor_here>/store?name=3D<grammar_name>
Content-type:=20 application/srgs+xml
Content-Length: 176

<?xml = version=3D"1.0"=20 (etc.)

Where the "grammar-resource" would be = simple and=20 general enough to be implemented by either the client or the=20 vendor.

Corby Anderson
Tellme Networks, = Inc.

Shanmugham,=20 Saravanan wrote:=20 
I agree, the issue is that there is no =
standard for compilation and
compiled grammar format.  I am not sure a COMPILE-GRAMMAR method is the
solution to this.=20

The aim of compilation is to accelarate customer response when dealing
with large-grammars.
A few ways to achieve the above, like I mentioned earlier are,
   1. The MRCP server could implement an optimization for large grammars
that leverages the grammar caching mechanism and its capabilities. That
is when they cache a grammar URI, they also store the compiled version
of the grammar. They could do this in a vendor specific compiled format.
Large grammars are usually not dynamic and hence the caching mechanims
should work reasonably well for this.
   2. Have the MRCP client point to pre-compiled-grammars so that when
the MRCP server goes and fetches it the large-grammar is already
compiled. There is the problem of making sure the compiled
grammar(vendor-specific) matches the specific recognition engine used.
This is difficult to manage in a multivendor deployment.
   3. Compile and store the grammars on the MRCP server ahead of time
during deployments. And then refer to these compiled grammars on the
MRCP server. This would have its own limitations, but would be workable
in many cases/deployments.


We could add the text for the first above bullet into the MRCPv2
specification if no one has any objects to it.

Thanks,

     -----Original Message-----
     From: speechsc-bounces@ietf.org=20
     [mailto:speechsc-bounces@ietf.or=
g] On Behalf Of Qiru Zhou
     Sent: Wednesday, June 08, 2005 2:17 PM
     To: Corby Anderson
     Cc: Speechsc@ietf.org
     Subject: Re: [Speechsc] Managing big grammars
    =20
     I think the problem here is there is no standard for=20
     compiled grammar format. This is a vendor implementation=20
     specific which is not inter-operable across different=20
     vendors. I agree that pre-compiled large grammars can=20
     improve system response and processing efficiency. But I=20
     don't know if this should be the part of standard. Same=20
     for cache, it is an implementation specific issue. Another=20
     practice on this issue is to pre load and archive large=20
     grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method).
    =20
     -- Qiru
    =20
     Corby Anderson wrote:
     > One feature that I'd like a COMPILE-GRAMMAR method to=20
     provide is the=20
     > ability to specify common back-end storage (like Sarvi=20
     mentioned) so=20
     > that compiling a Large Grammar one time could make it=20
     available to=20
     > other MRCP servers via the Compiled-Grammar-URI that=20
     Klaus suggested. =20
     > It would be especially useful to us if the *client*=20
     could specify the=20
     > URI where the grammar should be stored.  This would=20
     permit clients to=20
     > use grammar names that are meaningful to the client. =20
     (The example for=20
     > Personal-Grammar-URI seems like the grammar name is=20
     specified by the=20
     > client, but it's worth spelling out.)
     >=20
     > To round out the utility of a feature like this, we'd=20
     need some way to=20
     > determine if a grammar had already been compiled.  Since=20
     we're talking=20
     > about URIs, the client could just do a HEAD on the=20
     grammar to see if=20
     > it exists -- but does the client always have access to =
back-end=20
     > resources in this way?  If not, then a QUERY-GRAMMAR=20
     method which=20
     > takes a Compiled-Grammar-URI header could provide this=20
     capability.
     >=20
     > Corby Anderson
     > Tellme Networks, Inc.
     >=20
     >=20
     > Reifenrath, Klaus wrote:
     >=20
     >> I agree.
     >> BUT unfortunately there is no MRCPv2 interface to just=20
     compile a=20
     >> grammar. So grammar compilation needs to be done with=20
     vendor specific=20
     >> tools or APIs.
     >> We could add a new method (allowed only in idle state):
     >> COMPILE-GRAMMAR
     >> that requires the header field
     >> Compiled-Grammar-URI
     >> that specifies the location of the compiled grammar (like=20
     >> Personal-Grammar-URI).
     >> Is it too late to add this simple optional method?
     >>
     >> Klaus
     >>
     >> -----Original Message-----
     >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20
     Sent: Dienstag,=20
     >> 7. Juni 2005 21:09
     >> To: Corby Anderson; Speechsc@ietf.org
     >> Subject: RE: [Speechsc] Managing big grammars
     >>
     >> Sorry for the late reply. The way I think this should=20
     be addressed is=20
     >> to have support for compiled grammars as URI. All Large or =
Huge=20
     >> grammars are going to be URI referenced and never=20
     embedded in a DEFINE grammar.
     >> This means that the URI could point to compiled grammar =
file.
     >>
     >> Another way is to use the chache capability. When you =
access a=20
     >> grammar through HTTP is to cache it. In general instead=20
     of caching of=20
     >> the XML grammar you could decide to cache the compiled =
version=20
     >> instead. This would mean that you might do an initial=20
     DEFINE-GRAMMAR=20
     >> to force a compile of the grammar and future references to =
that=20
     >> grammar URI would hit the cache and hence the compiled =
version.
     >>
     >> Sarvi
     >>
     >>     -----Original Message-----
     >>     From: speechsc-bounces@ietf.org  =
  =20
     >> [mailto:speechsc-bounces@ietf.or=
g] On Behalf Of Corby Anderson
     >>     Sent: Thursday, May 26, 2005 2:11 PM
     >>     To: Speechsc@ietf.org
     >>     Subject: [Speechsc] Managing big grammars
     >>         What are folks' thoughts on how we could manage =
big    =20
     >> grammars with MRCP?
     >>         There are two usage cases that I'm interested=20
     in: a Large    =20
     >> Grammar that takes several seconds to compile, and a=20
     Jumbo     Grammar=20
     >> that takes many many minutes to compile.  A Large    =20
     Grammar might=20
     >> contain several hundred or thousand entries.      A=20
     Jumbo Grammar=20
     >> might contain hundreds of thousands of entries.
     >>         For a Jumbo Grammar, there's no way that a user=20
     can wait    =20
     >> for a grammar to be uploaded and compiled via the    =20
     DEFINE-GRAMMAR=20
     >> or RECOGNIZE methods.  A grammar that large     needs to =
be=20
     >> pre-compiled so that the DEFINE-GRAMMAR or    =20
     RECOGNIZE method can=20
     >> simply load the grammar binary.
     >>         For a Large Grammar, it might be okay to make=20
     one user    =20
     >> wait a few seconds for the grammar to compile -- but it=20
         would be a=20
     >> big win if that compiled grammar were stored     with a=20
     known name so=20
     >> that /subsequent/ uses of the same     grammar don't=20
     have to pay the=20
     >> same compilation penalty.
     >>         Our current speech recognition vendor's api=20
     provides    =20
     >> methods for checking for the existence of a dynamic    =20
     grammar, and=20
     >> for compiling a new grammar (named as the     client=20
     specifies). The=20
     >> api also provides a powerful and     flexible way to=20
     manage these=20
     >> stored grammars.  Is there     some MRCP-friendly way=20
     for dealing with=20
     >> these types of     grammars?  If not, then is one being=20
     considered?
     >>         Corby Anderson
     >>     Tellme Networks, Inc.
     >>             =
_______________________________________________
     >>     Speechsc mailing list
     >>     Speechsc@ietf.org
     >>     https://www1.iet=
f.org/mailman/listinfo/speechsc
     >>   =20
     >> _______________________________________________
     >> Speechsc mailing list
     >> Speechsc@ietf.org
     >> https://www1.iet=
f.org/mailman/listinfo/speechsc
     >> =20
     >>
     >=20
     > _______________________________________________
     > Speechsc mailing list
     > Speechsc@ietf.org
     > https://www1.iet=
f.org/mailman/listinfo/speechsc
    =20
------_=_NextPart_001_01C56E11.72A44B2C-- --===============1045590301== 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 --===============1045590301==-- From speechsc-bounces@ietf.org Fri Jun 10 19:45:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtBS-00043W-K1; Fri, 10 Jun 2005 19:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtBQ-00043G-Dh for speechsc@megatron.ietf.org; Fri, 10 Jun 2005 19:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25372 for ; Fri, 10 Jun 2005 19:45:00 -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 1DgtXB-0003FB-6f for speechsc@ietf.org; Fri, 10 Jun 2005 20:07:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2005 16:42:05 -0700 X-IronPort-AV: i="3.93,191,1115017200"; d="scan'208"; a="277217874:sNHT1480673024" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5ANg0lw003891; Fri, 10 Jun 2005 16:42:01 -0700 (PDT) Received: from [10.32.131.153] ([10.32.131.153]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j5ANTvTv021562; Fri, 10 Jun 2005 16:29:57 -0700 In-Reply-To: <03772D1EC8DE624A863058C75874A75C05B84A@vtg-um-e2k6.sj21ad.cisco.com> References: <03772D1EC8DE624A863058C75874A75C05B84A@vtg-um-e2k6.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3045782A-32BF-4824-8DDA-CFBC4049C6C3@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Managing big grammars Date: Fri, 10 Jun 2005 19:42:00 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118446197.277802"; x:"432200"; a:"rsa-sha1"; b:"nofws:7878"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VRVe5vAjx5Hds0Xt9vB36UWtVG/wemBKFGy7mYsxTRFY3YpdY1tuyTHPvPuNAMssAx/tlSeR" "8aPm5sU2ZbH3Ee9eG2F4bp7hthnrigYyqTTpW5dRFjOQOcu8t+Hw1UpU2aATGiYWFDofY7RR10Y" "lL3OeNJjIfZyPZ0JkbxTL39o="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Managing big grammars"; c:"Date: Fri, 10 Jun 2005 19:42:00 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 I agree with Sarvi - I have not heard a compelling argument for the need to extend the protocol for this. Dave. On Jun 10, 2005, at 7:09 PM, Shanmugham, Saravanan wrote: > I would say that a common cache amoung a farm of MRCP servers to > optimize compilations would be a nice server side optimization and > shouldn't affect the MRCP protocol. > > my 2c. > Sarvi > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Corby Anderson > Sent: Friday, June 10, 2005 11:52 AM > To: Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > Option #1 seems like a step in the right direction, but having > multi-server re-use would make it even more useful. Option #1 as > worded implies that each MRCP server would have to compile grammar > "X" the first time it's used; I'm suggesting that we try and make > one MRCP server's compilation efforts useful to other MRCP servers > (as long as they're the same vendor). The use case I have in mind > is a "farm" of recognition servers -- and when we compile one of > these Large grammars (grammar "X"), it would be great to store it > in some common storage area so that other MRCP servers could check > for its existence and load the binary. > It isn't necessary to have a standard compiled grammar format -- > it's just necessary to have a standard way to reference them. In a > server farm environment containing multiple vendors' MRCP servers, > wouldn't the client know (or couldn't it discover during session > setup) which kind of server it was connecting to and so adjust the > query/compile uri accordingly? I envision something along the > lines of: > > MRCP/2.0 82 QUERY-GRAMMAR 123456 > Compiled-Grammar-URI: http://grammar-resource// > query?name= > > > MRCP/2.0 507 COMPILE-GRAMMAR 123654 > Compiled-Grammar-URI: http://grammar-resource// > store?name= > Content-type: application/srgs+xml > Content-Length: 176 > > > Where the "grammar-resource" would be simple and general enough to > be implemented by either the client or the vendor. > > Corby Anderson > Tellme Networks, Inc. > > Shanmugham, Saravanan wrote: >> I agree, the issue is that there is no standard for compilation >> and compiled grammar format. I am not sure a COMPILE-GRAMMAR >> method is the solution to this. The aim of compilation is to >> accelarate customer response when dealing with large-grammars. A >> few ways to achieve the above, like I mentioned earlier are, 1. >> The MRCP server could implement an optimization for large grammars >> that leverages the grammar caching mechanism and its capabilities. >> That is when they cache a grammar URI, they also store the >> compiled version of the grammar. They could do this in a vendor >> specific compiled format. Large grammars are usually not dynamic >> and hence the caching mechanims should work reasonably well for >> this. 2. Have the MRCP client point to pre-compiled-grammars so >> that when the MRCP server goes and fetches it the large-grammar is >> already compiled. There is the problem of making sure the compiled >> grammar(vendor-specific) matches the specific recognition engine >> used. This is difficult to manage in a multivendor deployment. 3. >> Compile and store the grammars on the MRCP server ahead of time >> during deployments. And then refer to these compiled grammars on >> the MRCP server. This would have its own limitations, but would be >> workable in many cases/deployments. We could add the text for the >> first above bullet into the MRCPv2 specification if no one has any >> objects to it. Thanks, -----Original Message----- From: speechsc- >> bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of >> Qiru Zhou Sent: Wednesday, June 08, 2005 2:17 PM To: Corby >> Anderson Cc: Speechsc@ietf.org Subject: Re: [Speechsc] Managing >> big grammars I think the problem here is there is no standard for >> compiled grammar format. This is a vendor implementation specific >> which is not inter-operable across different vendors. I agree that >> pre-compiled large grammars can improve system response and >> processing efficiency. But I don't know if this should be the part >> of standard. Same for cache, it is an implementation specific >> issue. Another practice on this issue is to pre load and archive >> large grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). -- >> Qiru Corby Anderson wrote: > One feature that I'd like a COMPILE- >> GRAMMAR method to provide is the > ability to specify common back- >> end storage (like Sarvi mentioned) so > that compiling a Large >> Grammar one time could make it available to > other MRCP servers >> via the Compiled-Grammar-URI that Klaus suggested. > It would be >> especially useful to us if the *client* could specify the > URI >> where the grammar should be stored. This would permit clients to > >> use grammar names that are meaningful to the client. (The example >> for > Personal-Grammar-URI seems like the grammar name is >> specified by the > client, but it's worth spelling out.) > > To >> round out the utility of a feature like this, we'd need some way >> to > determine if a grammar had already been compiled. Since we're >> talking > about URIs, the client could just do a HEAD on the >> grammar to see if > it exists -- but does the client always have >> access to back-end > resources in this way? If not, then a QUERY- >> GRAMMAR method which > takes a Compiled-Grammar-URI header could >> provide this capability. > > Corby Anderson > Tellme Networks, >> Inc. > > > Reifenrath, Klaus wrote: > >> I agree. >> BUT >> unfortunately there is no MRCPv2 interface to just compile a >> >> grammar. So grammar compilation needs to be done with vendor >> specific >> tools or APIs. >> We could add a new method (allowed >> only in idle state): >> COMPILE-GRAMMAR >> that requires the >> header field >> Compiled-Grammar-URI >> that specifies the >> location of the compiled grammar (like >> Personal-Grammar-URI). >> >> Is it too late to add this simple optional method? >> >> Klaus >> >> >> -----Original Message----- >> From: Shanmugham, Saravanan >> [mailto:sarvi@cisco.com] Sent: Dienstag, >> 7. Juni 2005 21:09 >> >> To: Corby Anderson; Speechsc@ietf.org >> Subject: RE: [Speechsc] >> Managing big grammars >> >> Sorry for the late reply. The way I >> think this should be addressed is >> to have support for compiled >> grammars as URI. All Large or Huge >> grammars are going to be URI >> referenced and never embedded in a DEFINE grammar. >> This means >> that the URI could point to compiled grammar file. >> >> Another >> way is to use the chache capability. When you access a >> grammar >> through HTTP is to cache it. In general instead of caching of >> >> the XML grammar you could decide to cache the compiled version >> >> instead. This would mean that you might do an initial DEFINE- >> GRAMMAR >> to force a compile of the grammar and future references >> to that >> grammar URI would hit the cache and hence the compiled >> version. >> >> Sarvi >> >> -----Original Message----- >> From: >> speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On >> Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM >> >> To: Speechsc@ietf.org >> Subject: [Speechsc] Managing big >> grammars >> What are folks' thoughts on how we could manage big >> >> grammars with MRCP? >> There are two usage cases that I'm >> interested in: a Large >> Grammar that takes several seconds to >> compile, and a Jumbo Grammar >> that takes many many minutes to >> compile. A Large Grammar might >> contain several hundred or >> thousand entries. A Jumbo Grammar >> might contain hundreds of >> thousands of entries. >> For a Jumbo Grammar, there's no way that >> a user can wait >> for a grammar to be uploaded and compiled via >> the DEFINE-GRAMMAR >> or RECOGNIZE methods. A grammar that large >> needs to be >> pre-compiled so that the DEFINE-GRAMMAR or >> RECOGNIZE method can >> simply load the grammar binary. >> For a >> Large Grammar, it might be okay to make one user >> wait a few >> seconds for the grammar to compile -- but it would be a >> big win >> if that compiled grammar were stored with a known name so >> that / >> subsequent/ uses of the same grammar don't have to pay the >> same >> compilation penalty. >> Our current speech recognition vendor's >> api provides >> methods for checking for the existence of a >> dynamic grammar, and >> for compiling a new grammar (named as the >> client specifies). The >> api also provides a powerful and >> flexible way to manage these >> stored grammars. Is there some >> MRCP-friendly way for dealing with >> these types of grammars? If >> not, then is one being considered? >> Corby Anderson >> Tellme >> Networks, Inc. >> _______________________________________________ >> >> 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 > _______________________________________________ > 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 Sat Jun 11 11:42:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dh87o-0005mL-1W; Sat, 11 Jun 2005 11:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dh87l-0005lt-QT for speechsc@megatron.ietf.org; Sat, 11 Jun 2005 11:42:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21428 for ; Sat, 11 Jun 2005 11:42:15 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dh8Td-00078o-CH for Speechsc@ietf.org; Sat, 11 Jun 2005 12:04:55 -0400 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 9CB47214046; Sat, 11 Jun 2005 15:41:55 +0000 (GMT) Message-ID: <00b201c56e9c$191b4be0$8800000a@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Corby Anderson" , References: <03772D1EC8DE624A863058C75874A75C05B84A@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] Managing big grammars Date: Sat, 11 Jun 2005 16:41:55 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 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="===============1549337602==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1549337602== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01C56EA4.7A5AA560" This is a multi-part message in MIME format. ------=_NextPart_000_00AF_01C56EA4.7A5AA560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. Grammar compilation, caching, and sharing is a problem for the = MRCP server. Exposing this in the protocol puts unnecessary complexity = on the client. For example, the client needs to download grammars, = implement its own HTTP caching, checksum algorithms (some way of not = having to push huge data to the MRCP server to query) etc. So I vote for point 1 below and include in the text that an MRCP server = could also, as an optimisation, implement a centralised common cache = shared across multiple MRCP servers. Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars I would say that a common cache amoung a farm of MRCP servers to = optimize compilations would be a nice server side optimization and = shouldn't affect the MRCP protocol. my 2c. Sarvi -------------------------------------------------------------------------= --- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Corby Anderson Sent: Friday, June 10, 2005 11:52 AM To: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars Option #1 seems like a step in the right direction, but having = multi-server re-use would make it even more useful. Option #1 as worded = implies that each MRCP server would have to compile grammar "X" the = first time it's used; I'm suggesting that we try and make one MRCP = server's compilation efforts useful to other MRCP servers (as long as = they're the same vendor). The use case I have in mind is a "farm" of = recognition servers -- and when we compile one of these Large grammars = (grammar "X"), it would be great to store it in some common storage area = so that other MRCP servers could check for its existence and load the = binary. =20 It isn't necessary to have a standard compiled grammar format -- = it's just necessary to have a standard way to reference them. In a = server farm environment containing multiple vendors' MRCP servers, = wouldn't the client know (or couldn't it discover during session setup) = which kind of server it was connecting to and so adjust the = query/compile uri accordingly? I envision something along the lines of: MRCP/2.0 82 QUERY-GRAMMAR 123456 Compiled-Grammar-URI: = http://grammar-resource//query?name=3D MRCP/2.0 507 COMPILE-GRAMMAR 123654 Compiled-Grammar-URI: = http://grammar-resource//store?name=3D Content-type: application/srgs+xml Content-Length: 176 One feature that I'd like a COMPILE-GRAMMAR method to=20 provide is the=20 > ability to specify common back-end storage (like Sarvi=20 mentioned) so=20 > that compiling a Large Grammar one time could make it=20 available to=20 > other MRCP servers via the Compiled-Grammar-URI that=20 Klaus suggested. =20 > It would be especially useful to us if the *client*=20 could specify the=20 > URI where the grammar should be stored. This would=20 permit clients to=20 > use grammar names that are meaningful to the client. =20 (The example for=20 > Personal-Grammar-URI seems like the grammar name is=20 specified by the=20 > client, but it's worth spelling out.) >=20 > To round out the utility of a feature like this, we'd=20 need some way to=20 > determine if a grammar had already been compiled. Since=20 we're talking=20 > about URIs, the client could just do a HEAD on the=20 grammar to see if=20 > it exists -- but does the client always have access to back-end=20 > resources in this way? If not, then a QUERY-GRAMMAR=20 method which=20 > takes a Compiled-Grammar-URI header could provide this=20 capability. >=20 > Corby Anderson > Tellme Networks, Inc. >=20 >=20 > Reifenrath, Klaus wrote: >=20 >> I agree. >> BUT unfortunately there is no MRCPv2 interface to just=20 compile a=20 >> grammar. So grammar compilation needs to be done with=20 vendor specific=20 >> tools or APIs. >> We could add a new method (allowed only in idle state): >> COMPILE-GRAMMAR >> that requires the header field >> Compiled-Grammar-URI >> that specifies the location of the compiled grammar (like=20 >> Personal-Grammar-URI). >> Is it too late to add this simple optional method? >> >> Klaus >> >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Dienstag,=20 >> 7. Juni 2005 21:09 >> To: Corby Anderson; Speechsc@ietf.org >> Subject: RE: [Speechsc] Managing big grammars >> >> Sorry for the late reply. The way I think this should=20 be addressed is=20 >> to have support for compiled grammars as URI. All Large or Huge=20 >> grammars are going to be URI referenced and never=20 embedded in a DEFINE grammar. >> This means that the URI could point to compiled grammar file. >> >> Another way is to use the chache capability. When you access a=20 >> grammar through HTTP is to cache it. In general instead=20 of caching of=20 >> the XML grammar you could decide to cache the compiled version=20 >> instead. This would mean that you might do an initial=20 DEFINE-GRAMMAR=20 >> to force a compile of the grammar and future references to that=20 >> grammar URI would hit the cache and hence the compiled version. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org =20 >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson >> Sent: Thursday, May 26, 2005 2:11 PM >> To: Speechsc@ietf.org >> Subject: [Speechsc] Managing big grammars >> What are folks' thoughts on how we could manage big =20 >> grammars with MRCP? >> There are two usage cases that I'm interested=20 in: a Large =20 >> Grammar that takes several seconds to compile, and a=20 Jumbo Grammar=20 >> that takes many many minutes to compile. A Large =20 Grammar might=20 >> contain several hundred or thousand entries. A=20 Jumbo Grammar=20 >> might contain hundreds of thousands of entries. >> For a Jumbo Grammar, there's no way that a user=20 can wait =20 >> for a grammar to be uploaded and compiled via the =20 DEFINE-GRAMMAR=20 >> or RECOGNIZE methods. A grammar that large needs to be=20 >> pre-compiled so that the DEFINE-GRAMMAR or =20 RECOGNIZE method can=20 >> simply load the grammar binary. >> For a Large Grammar, it might be okay to make=20 one user =20 >> wait a few seconds for the grammar to compile -- but it=20 would be a=20 >> big win if that compiled grammar were stored with a=20 known name so=20 >> that /subsequent/ uses of the same grammar don't=20 have to pay the=20 >> same compilation penalty. >> Our current speech recognition vendor's api=20 provides =20 >> methods for checking for the existence of a dynamic =20 grammar, and=20 >> for compiling a new grammar (named as the client=20 specifies). The=20 >> api also provides a powerful and flexible way to=20 manage these=20 >> stored grammars. Is there some MRCP-friendly way=20 for dealing with=20 >> these types of grammars? If not, then is one being=20 considered? >> Corby Anderson >> Tellme Networks, Inc. >> _______________________________________________ >> 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 >> >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_00AF_01C56EA4.7A5AA560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree. Grammar compilation, caching, = and sharing=20 is a problem for the MRCP server. Exposing this in the protocol puts = unnecessary=20 complexity on the client. For example, the client needs to download = grammars,=20 implement its own HTTP caching, checksum algorithms (some way of not = having to=20 push huge data to the MRCP server to query) etc.
 
So I vote for point 1 below and include = in the text=20 that an MRCP server could also, as an optimisation, implement = a=20 centralised common cache shared across multiple MRCP = servers.
 
Dave
----- Original Message -----
From:=20 Shanmugham, = Saravanan
Sent: Saturday, June 11, 2005 = 12:09=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I would say that a common cache amoung a farm = of MRCP=20 servers to optimize compilations would be a nice server side = optimization and=20 shouldn't affect the MRCP protocol.
 
my 2c.
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby=20 Anderson
Sent: Friday, June 10, 2005 11:52 = AM
To: Speechsc@ietf.org
Subject: Re:=20 [Speechsc] Managing big grammars

Option #1 seems like a step in the right direction, but = having=20 multi-server re-use would make it even more useful. Option #1 as = worded=20 implies that each MRCP server would have to compile grammar = "X" the=20 first time it's used;  I'm suggesting that we try and make one = MRCP=20 server's compilation efforts useful to other MRCP servers (as long = as=20 they're the same vendor).  The use case I have in mind is a = "farm" of=20 recognition servers -- and when we compile one of these Large = grammars=20 (grammar "X"), it would be great to store it in some common storage = area so=20 that other MRCP servers could check for its existence and load the=20 binary. 
It isn't necessary to have a standard compiled = grammar=20 format -- it's just necessary to have a standard way to reference=20 them.  In a server farm environment containing multiple = vendors' MRCP=20 servers, wouldn't the client know (or couldn't it discover during = session=20 setup) which kind of server it was connecting to and so adjust the=20 query/compile uri accordingly?  I envision something along the = lines=20 of:

MRCP/2.0 82 QUERY-GRAMMAR = 123456
Compiled-Grammar-URI: http://grammar-resource/<insert_= vendor_here>/query?name=3D<grammar_name>


MRCP/2.0=20 507 COMPILE-GRAMMAR 123654
Compiled-Grammar-URI: http://grammar-resource/<insert_= vendor_here>/store?name=3D<grammar_name>
Content-type:=20 application/srgs+xml
Content-Length: 176

<?xml = version=3D"1.0"=20 (etc.)

Where the "grammar-resource" would be = simple and=20 general enough to be implemented by either the client or the=20 vendor.

Corby Anderson
Tellme Networks, = Inc.

Shanmugham,=20 Saravanan wrote:=20 
I agree, the issue is that there is no =
standard for compilation and
compiled grammar format.  I am not sure a COMPILE-GRAMMAR method is the
solution to this.=20

The aim of compilation is to accelarate customer response when dealing
with large-grammars.
A few ways to achieve the above, like I mentioned earlier are,
   1. The MRCP server could implement an optimization for large grammars
that leverages the grammar caching mechanism and its capabilities. That
is when they cache a grammar URI, they also store the compiled version
of the grammar. They could do this in a vendor specific compiled format.
Large grammars are usually not dynamic and hence the caching mechanims
should work reasonably well for this.
   2. Have the MRCP client point to pre-compiled-grammars so that when
the MRCP server goes and fetches it the large-grammar is already
compiled. There is the problem of making sure the compiled
grammar(vendor-specific) matches the specific recognition engine used.
This is difficult to manage in a multivendor deployment.
   3. Compile and store the grammars on the MRCP server ahead of time
during deployments. And then refer to these compiled grammars on the
MRCP server. This would have its own limitations, but would be workable
in many cases/deployments.


We could add the text for the first above bullet into the MRCPv2
specification if no one has any objects to it.

Thanks,

     -----Original Message-----
     From: speechsc-bounces@ietf.org=20
     [mailto:speechsc-bounces@ietf.or=
g] On Behalf Of Qiru Zhou
     Sent: Wednesday, June 08, 2005 2:17 PM
     To: Corby Anderson
     Cc: Speechsc@ietf.org
     Subject: Re: [Speechsc] Managing big grammars
    =20
     I think the problem here is there is no standard for=20
     compiled grammar format. This is a vendor implementation=20
     specific which is not inter-operable across different=20
     vendors. I agree that pre-compiled large grammars can=20
     improve system response and processing efficiency. But I=20
     don't know if this should be the part of standard. Same=20
     for cache, it is an implementation specific issue. Another=20
     practice on this issue is to pre load and archive large=20
     grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method).
    =20
     -- Qiru
    =20
     Corby Anderson wrote:
     > One feature that I'd like a COMPILE-GRAMMAR method to=20
     provide is the=20
     > ability to specify common back-end storage (like Sarvi=20
     mentioned) so=20
     > that compiling a Large Grammar one time could make it=20
     available to=20
     > other MRCP servers via the Compiled-Grammar-URI that=20
     Klaus suggested. =20
     > It would be especially useful to us if the *client*=20
     could specify the=20
     > URI where the grammar should be stored.  This would=20
     permit clients to=20
     > use grammar names that are meaningful to the client. =20
     (The example for=20
     > Personal-Grammar-URI seems like the grammar name is=20
     specified by the=20
     > client, but it's worth spelling out.)
     >=20
     > To round out the utility of a feature like this, we'd=20
     need some way to=20
     > determine if a grammar had already been compiled.  Since=20
     we're talking=20
     > about URIs, the client could just do a HEAD on the=20
     grammar to see if=20
     > it exists -- but does the client always have access to =
back-end=20
     > resources in this way?  If not, then a QUERY-GRAMMAR=20
     method which=20
     > takes a Compiled-Grammar-URI header could provide this=20
     capability.
     >=20
     > Corby Anderson
     > Tellme Networks, Inc.
     >=20
     >=20
     > Reifenrath, Klaus wrote:
     >=20
     >> I agree.
     >> BUT unfortunately there is no MRCPv2 interface to just=20
     compile a=20
     >> grammar. So grammar compilation needs to be done with=20
     vendor specific=20
     >> tools or APIs.
     >> We could add a new method (allowed only in idle state):
     >> COMPILE-GRAMMAR
     >> that requires the header field
     >> Compiled-Grammar-URI
     >> that specifies the location of the compiled grammar (like=20
     >> Personal-Grammar-URI).
     >> Is it too late to add this simple optional method?
     >>
     >> Klaus
     >>
     >> -----Original Message-----
     >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20
     Sent: Dienstag,=20
     >> 7. Juni 2005 21:09
     >> To: Corby Anderson; Speechsc@ietf.org
     >> Subject: RE: [Speechsc] Managing big grammars
     >>
     >> Sorry for the late reply. The way I think this should=20
     be addressed is=20
     >> to have support for compiled grammars as URI. All Large or =
Huge=20
     >> grammars are going to be URI referenced and never=20
     embedded in a DEFINE grammar.
     >> This means that the URI could point to compiled grammar =
file.
     >>
     >> Another way is to use the chache capability. When you =
access a=20
     >> grammar through HTTP is to cache it. In general instead=20
     of caching of=20
     >> the XML grammar you could decide to cache the compiled =
version=20
     >> instead. This would mean that you might do an initial=20
     DEFINE-GRAMMAR=20
     >> to force a compile of the grammar and future references to =
that=20
     >> grammar URI would hit the cache and hence the compiled =
version.
     >>
     >> Sarvi
     >>
     >>     -----Original Message-----
     >>     From: speechsc-bounces@ietf.org  =
  =20
     >> [mailto:speechsc-bounces@ietf.or=
g] On Behalf Of Corby Anderson
     >>     Sent: Thursday, May 26, 2005 2:11 PM
     >>     To: Speechsc@ietf.org
     >>     Subject: [Speechsc] Managing big grammars
     >>         What are folks' thoughts on how we could manage =
big    =20
     >> grammars with MRCP?
     >>         There are two usage cases that I'm interested=20
     in: a Large    =20
     >> Grammar that takes several seconds to compile, and a=20
     Jumbo     Grammar=20
     >> that takes many many minutes to compile.  A Large    =20
     Grammar might=20
     >> contain several hundred or thousand entries.      A=20
     Jumbo Grammar=20
     >> might contain hundreds of thousands of entries.
     >>         For a Jumbo Grammar, there's no way that a user=20
     can wait    =20
     >> for a grammar to be uploaded and compiled via the    =20
     DEFINE-GRAMMAR=20
     >> or RECOGNIZE methods.  A grammar that large     needs to =
be=20
     >> pre-compiled so that the DEFINE-GRAMMAR or    =20
     RECOGNIZE method can=20
     >> simply load the grammar binary.
     >>         For a Large Grammar, it might be okay to make=20
     one user    =20
     >> wait a few seconds for the grammar to compile -- but it=20
         would be a=20
     >> big win if that compiled grammar were stored     with a=20
     known name so=20
     >> that /subsequent/ uses of the same     grammar don't=20
     have to pay the=20
     >> same compilation penalty.
     >>         Our current speech recognition vendor's api=20
     provides    =20
     >> methods for checking for the existence of a dynamic    =20
     grammar, and=20
     >> for compiling a new grammar (named as the     client=20
     specifies). The=20
     >> api also provides a powerful and     flexible way to=20
     manage these=20
     >> stored grammars.  Is there     some MRCP-friendly way=20
     for dealing with=20
     >> these types of     grammars?  If not, then is one being=20
     considered?
     >>         Corby Anderson
     >>     Tellme Networks, Inc.
     >>             =
_______________________________________________
     >>     Speechsc mailing list
     >>     Speechsc@ietf.org
     >>     https://www1.iet=
f.org/mailman/listinfo/speechsc
     >>   =20
     >> _______________________________________________
     >> Speechsc mailing list
     >> Speechsc@ietf.org
     >> https://www1.iet=
f.org/mailman/listinfo/speechsc
     >> =20
     >>
     >=20
     > _______________________________________________
     > Speechsc mailing list
     > Speechsc@ietf.org
     > https://www1.iet=
f.org/mailman/listinfo/speechsc
    =20

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_00AF_01C56EA4.7A5AA560-- --===============1549337602== 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 --===============1549337602==-- From speechsc-bounces@ietf.org Sat Jun 11 16:41:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhCnN-0004L5-44; Sat, 11 Jun 2005 16:41:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhCnK-0004Iz-QV for speechsc@megatron.ietf.org; Sat, 11 Jun 2005 16:41:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12490 for ; Sat, 11 Jun 2005 16:41:28 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhD9E-0001Vd-J3 for Speechsc@ietf.org; Sat, 11 Jun 2005 17:04:11 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id A5049350B for ; Sat, 11 Jun 2005 13:41:01 -0700 (PDT) Received: from [172.20.122.3] (vpnpoolB-172-122-3.corp.tellme.com [172.20.122.3]) by mail02.corp.tellme.com (Postfix) with ESMTP id 810763507 for ; Sat, 11 Jun 2005 13:41:00 -0700 (PDT) Message-ID: <42AB4C5C.7070909@tellme.com> Date: Sat, 11 Jun 2005 13:41:00 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars References: <03772D1EC8DE624A863058C75874A75C05B84A@vtg-um-e2k6.sj21ad.cisco.com> <00b201c56e9c$191b4be0$8800000a@db01.voxpilot.com> In-Reply-To: <00b201c56e9c$191b4be0$8800000a@db01.voxpilot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: 7bit 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Thanks, all, for considering those features. I appreciate the time you spent discussing them -- especially since the spec is so close to completion. So let's quickly revisit the original two usage cases I was interested in (Large grammars that might be several thousand lines long and Jumbo grammars that might be hundreds of thousands of lines long). It sounds clear that the group's intent is for vendors to provide back-end tools for compiling, storing, and referring to Jumbo grammar binaries; so Sarvi's option #1 would only apply to the Large grammars. When the client wants to recognize with a Large grammar, it would have to upload the grammar source to the MRCP server (which may or may not cache it in source and/or binary form -- depending on how/if the vendor chooses to implement this optimization). Would it be appropriate to include a hint to the client that the MRCP server has cached the grammar? For example, if a Large grammar is uploaded with DEFINE-GRAMMAR, a header in the 200 response could indicate that this grammar is cached -- a client could use this information to avoid uploading that Large grammar again for future recognitions with that grammar on that MRCP server. The downside, of course, is that it raises cache management issues: how long do these things stay in cache, how can a client determine if a previously-cached grammar is still in the cache, etc. All of these are surmountable, but I don't have a feel for whether they belong in the spec or not. What does the group think? If a vendor chooses to implement Large grammar caching, should the spec cover supplying hints to the client so that the client doesn't have to upload the same (cached) grammar for subsequent recogntions? Even though this would be a vendor-optional feature, I think it would common enough that the spec would benefit from having a common mechanism to indicate whether a grammar is cached. Thanks, Corby Anderson Tellme Networks, Inc. Dave Burke wrote: > I agree. Grammar compilation, caching, and sharing is a problem for > the MRCP server. Exposing this in the protocol puts unnecessary > complexity on the client. For example, the client needs to download > grammars, implement its own HTTP caching, checksum algorithms (some > way of not having to push huge data to the MRCP server to query) etc. > > So I vote for point 1 below and include in the text that an MRCP > server could also, as an optimisation, implement a centralised common > cache shared across multiple MRCP servers. > > Dave > > ----- Original Message ----- > *From:* Shanmugham, Saravanan > *To:* Corby Anderson ; Speechsc@ietf.org > > *Sent:* Saturday, June 11, 2005 12:09 AM > *Subject:* RE: [Speechsc] Managing big grammars > > I would say that a common cache amoung a farm of MRCP servers to > optimize compilations would be a nice server side optimization and > shouldn't affect the MRCP protocol. > > my 2c. > Sarvi > > ------------------------------------------------------------------------ > *From:* speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] *On Behalf Of *Corby Anderson > *Sent:* Friday, June 10, 2005 11:52 AM > *To:* Speechsc@ietf.org > *Subject:* Re: [Speechsc] Managing big grammars > > Option #1 seems like a step in the right direction, but having > multi-server re-use would make it even more useful. Option #1 > as worded implies that /each /MRCP server would have to > compile grammar "X" the first time it's used; I'm suggesting > that we try and make one MRCP server's compilation efforts > useful to other MRCP servers (as long as they're the same > vendor). The use case I have in mind is a "farm" of > recognition servers -- and when we compile one of these Large > grammars (grammar "X"), it would be great to store it in some > common storage area so that other MRCP servers could check for > its existence and load the binary. > It isn't necessary to have a standard compiled grammar format > -- it's just necessary to have a standard way to reference > them. In a server farm environment containing multiple > vendors' MRCP servers, wouldn't the client know (or couldn't > it discover during session setup) which kind of server it was > connecting to and so adjust the query/compile uri > accordingly? I envision something along the lines of: > > MRCP/2.0 82 QUERY-GRAMMAR 123456 > Compiled-Grammar-URI: > http://grammar-resource//query?name= > > > MRCP/2.0 507 COMPILE-GRAMMAR 123654 > Compiled-Grammar-URI: > http://grammar-resource//store?name= > Content-type: application/srgs+xml > Content-Length: 176 > > > > Where the "grammar-resource" would be simple and general > enough to be implemented by either the client or the vendor. > > Corby Anderson > Tellme Networks, Inc. > > Shanmugham, Saravanan wrote: > >>I agree, the issue is that there is no standard for compilation and >>compiled grammar format. I am not sure a COMPILE-GRAMMAR method is the >>solution to this. >> >>The aim of compilation is to accelarate customer response when dealing >>with large-grammars. >>A few ways to achieve the above, like I mentioned earlier are, >> 1. The MRCP server could implement an optimization for large grammars >>that leverages the grammar caching mechanism and its capabilities. That >>is when they cache a grammar URI, they also store the compiled version >>of the grammar. They could do this in a vendor specific compiled format. >>Large grammars are usually not dynamic and hence the caching mechanims >>should work reasonably well for this. >> 2. Have the MRCP client point to pre-compiled-grammars so that when >>the MRCP server goes and fetches it the large-grammar is already >>compiled. There is the problem of making sure the compiled >>grammar(vendor-specific) matches the specific recognition engine used. >>This is difficult to manage in a multivendor deployment. >> 3. Compile and store the grammars on the MRCP server ahead of time >>during deployments. And then refer to these compiled grammars on the >>MRCP server. This would have its own limitations, but would be workable >>in many cases/deployments. >> >> >>We could add the text for the first above bullet into the MRCPv2 >>specification if no one has any objects to it. >> >>Thanks, >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Qiru Zhou >> Sent: Wednesday, June 08, 2005 2:17 PM >> To: Corby Anderson >> Cc: Speechsc@ietf.org >> Subject: Re: [Speechsc] Managing big grammars >> >> I think the problem here is there is no standard for >> compiled grammar format. This is a vendor implementation >> specific which is not inter-operable across different >> vendors. I agree that pre-compiled large grammars can >> improve system response and processing efficiency. But I >> don't know if this should be the part of standard. Same >> for cache, it is an implementation specific issue. Another >> practice on this issue is to pre load and archive large >> grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). >> >> -- Qiru >> >> Corby Anderson wrote: >> > One feature that I'd like a COMPILE-GRAMMAR method to >> provide is the >> > ability to specify common back-end storage (like Sarvi >> mentioned) so >> > that compiling a Large Grammar one time could make it >> available to >> > other MRCP servers via the Compiled-Grammar-URI that >> Klaus suggested. >> > It would be especially useful to us if the *client* >> could specify the >> > URI where the grammar should be stored. This would >> permit clients to >> > use grammar names that are meaningful to the client. >> (The example for >> > Personal-Grammar-URI seems like the grammar name is >> specified by the >> > client, but it's worth spelling out.) >> > >> > To round out the utility of a feature like this, we'd >> need some way to >> > determine if a grammar had already been compiled. Since >> we're talking >> > about URIs, the client could just do a HEAD on the >> grammar to see if >> > it exists -- but does the client always have access to back-end >> > resources in this way? If not, then a QUERY-GRAMMAR >> method which >> > takes a Compiled-Grammar-URI header could provide this >> capability. >> > >> > Corby Anderson >> > Tellme Networks, Inc. >> > >> > >> > Reifenrath, Klaus wrote: >> > >> >> I agree. >> >> BUT unfortunately there is no MRCPv2 interface to just >> compile a >> >> grammar. So grammar compilation needs to be done with >> vendor specific >> >> tools or APIs. >> >> We could add a new method (allowed only in idle state): >> >> COMPILE-GRAMMAR >> >> that requires the header field >> >> Compiled-Grammar-URI >> >> that specifies the location of the compiled grammar (like >> >> Personal-Grammar-URI). >> >> Is it too late to add this simple optional method? >> >> >> >> Klaus >> >> >> >> -----Original Message----- >> >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >> Sent: Dienstag, >> >> 7. Juni 2005 21:09 >> >> To: Corby Anderson; Speechsc@ietf.org >> >> Subject: RE: [Speechsc] Managing big grammars >> >> >> >> Sorry for the late reply. The way I think this should >> be addressed is >> >> to have support for compiled grammars as URI. All Large or Huge >> >> grammars are going to be URI referenced and never >> embedded in a DEFINE grammar. >> >> This means that the URI could point to compiled grammar file. >> >> >> >> Another way is to use the chache capability. When you access a >> >> grammar through HTTP is to cache it. In general instead >> of caching of >> >> the XML grammar you could decide to cache the compiled version >> >> instead. This would mean that you might do an initial >> DEFINE-GRAMMAR >> >> to force a compile of the grammar and future references to that >> >> grammar URI would hit the cache and hence the compiled version. >> >> >> >> Sarvi >> >> >> >> -----Original Message----- >> >> From: speechsc-bounces@ietf.org >> >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson >> >> Sent: Thursday, May 26, 2005 2:11 PM >> >> To: Speechsc@ietf.org >> >> Subject: [Speechsc] Managing big grammars >> >> What are folks' thoughts on how we could manage big >> >> grammars with MRCP? >> >> There are two usage cases that I'm interested >> in: a Large >> >> Grammar that takes several seconds to compile, and a >> Jumbo Grammar >> >> that takes many many minutes to compile. A Large >> Grammar might >> >> contain several hundred or thousand entries. A >> Jumbo Grammar >> >> might contain hundreds of thousands of entries. >> >> For a Jumbo Grammar, there's no way that a user >> can wait >> >> for a grammar to be uploaded and compiled via the >> DEFINE-GRAMMAR >> >> or RECOGNIZE methods. A grammar that large needs to be >> >> pre-compiled so that the DEFINE-GRAMMAR or >> RECOGNIZE method can >> >> simply load the grammar binary. >> >> For a Large Grammar, it might be okay to make >> one user >> >> wait a few seconds for the grammar to compile -- but it >> would be a >> >> big win if that compiled grammar were stored with a >> known name so >> >> that /subsequent/ uses of the same grammar don't >> have to pay the >> >> same compilation penalty. >> >> Our current speech recognition vendor's api >> provides >> >> methods for checking for the existence of a dynamic >> grammar, and >> >> for compiling a new grammar (named as the client >> specifies). The >> >> api also provides a powerful and flexible way to >> manage these >> >> stored grammars. Is there some MRCP-friendly way >> for dealing with >> >> these types of grammars? If not, then is one being >> considered? >> >> Corby Anderson >> >> Tellme Networks, Inc. >> >> _______________________________________________ >> >> 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 >> >> >> > ------------------------------------------------------------------------ > _______________________________________________ > 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 Sat Jun 11 20:41:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhGXp-00022C-NZ; Sat, 11 Jun 2005 20:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhGXo-00021R-0n for speechsc@megatron.ietf.org; Sat, 11 Jun 2005 20:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25522 for ; Sat, 11 Jun 2005 20:41:42 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhGtm-0002CE-4L for Speechsc@ietf.org; Sat, 11 Jun 2005 21:04:26 -0400 X-SEF-Processed: 5_0_0_713__2005_06_11_19_40_19 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Sat, 11 Jun 2005 19:40:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Managing big grammars Date: Sat, 11 Jun 2005 19:41:25 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524C2@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVunEBEsT/cM5HsRoyDEfPcaOkHIwAQk8uw From: "Wyss, Felix" To: "Dave Burke" , "Shanmugham, Saravanan" , "Corby Anderson" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab 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="===============0699690137==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0699690137== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56EE7.76C81A04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56EE7.76C81A04 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree. Predictability is *very* critical for an application using ASR. It must be able to make sure that when a recognition operation is started, there is no latency while the ASR server compiles and/or loads a large precompiled grammar into memory. The DEFINE-GRAMMAR command is scoped to a channel, which means by the time the application has a channel (i.e. a caller is in the system), it is unacceptable to block for more than fraction of a second while the grammars are being compiled and/or loaded. Otherwise, the first caller after a grammar is changed encounters delays and has a poor user experience or even hangs up. Somebody may say: well, just make a "priming" call after modifying the grammar to ensure the grammar is cached. However, that is not very practical for automatically generated grammars; but worse yet, in large systems there are commonly several load-balanced ASR severs and it will be rather hard to ensure each of them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large grammars that may change frequently, possibly several times a day, such as company directory grammars that are generated from a database, can be registered as "preloaded grammars". This means, our platform ensures the grammar is compiled, distributed to all ASR servers, and loaded into their caches after a new version of that grammar has been generated. Each preloaded grammar has a name associated, which is referenced through a special URI. The application logic only knows that URI and not the actual URI/filename of the underlying grammar data. The subsystem managing the preloaded grammars ensures that the preloaded grammar URI resolves to the previous version of the grammar until the new grammar is loaded and ready on all ASR servers. Thus, all callers that call into the system while the grammar is being generated, compiled, and loaded on the servers will get the previous version. This ensures that there is no delay for the first caller after a change. We can do this as we are using the native APIs provided by the ASR engine vendors we support and layer a sophisticated framework and API on top of it. =20 =20 It would be nice if MRCP provided some support for schemes like that, without having to open dummy channels to register grammars and pray the MRCP server doesn't evict them too early. An MRCP client has to be able to guarantee that when a call comes through the system, everything is ready and it won't experience any delay. As it stands now the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem for the MRCP server. Exposing this in the protocol puts unnecessary complexity on the client. For example, the client needs to download grammars, implement its own HTTP caching, checksum algorithms (some way of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP server could also, as an optimisation, implement a centralised common cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan =20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to optimize compilations would be a nice server side optimization and shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------_=_NextPart_001_01C56EE7.76C81A04 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I disagree.  Predictability is = *very* critical for an application = using ASR.  It must be able to make sure that when a recognition operation is = started, there is no latency while the ASR server compiles and/or loads a large = precompiled grammar into memory.  The DEFINE-GRAMMAR command is scoped to a = channel, which means by the time the application has a channel (i.e. a caller is = in the system), it is unacceptable to block for more than fraction of a second = while the grammars are being compiled and/or loaded.  Otherwise, the first = caller after a grammar is changed encounters delays and has a poor user = experience or even hangs up.  Somebody may say: well, just make a = “priming” call after modifying the grammar to ensure the grammar is cached. =  However, that is not very practical for automatically generated grammars; but worse = yet, in large systems there are commonly several load-balanced ASR severs and it will = be rather hard to ensure each of them is touched at least once. =  

 

The way we solve this on our = platform is as follows: Large grammars that may change frequently, possibly several = times a day, such as company directory grammars that are generated from a = database, can be registered as “preloaded grammars”.  This means, our = platform ensures the grammar is compiled, distributed to all ASR servers, and = loaded into their caches after a new version of that grammar has been = generated.  Each preloaded grammar has a name associated, which is referenced = through a special URI.  The application logic only knows that URI and not the = actual URI/filename of the underlying grammar data.  The subsystem = managing the preloaded grammars ensures that the preloaded grammar URI resolves to = the previous version of the grammar until the new grammar is loaded and ready on all = ASR servers.  Thus, all callers that call into the system while the grammar is = being generated, compiled, and loaded on the servers will get the previous version. =  This ensures that there is no delay for the first caller after a change. =  We can do this as we are using the native APIs provided by the ASR engine = vendors we support and layer a sophisticated framework and API on top of = it. 

 

It would be nice if MRCP provided = some support for schemes like that, without having to open dummy channels to register grammars and pray the MRCP server doesn’t evict them too = early.  An MRCP client has to be able to guarantee that when a call comes through = the system, everything is ready and it won’t experience any delay. =  As it stands now the MRCP protocol does not appear to provide support for = this.

 

Thanks,

=

Felix

 

From: speechsc-bounces@ietf.org = [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave = Burke
Sent: Saturday, June 11, = 2005 10:42
To: Shanmugham, = Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big grammars

 

I agree. Grammar compilation, caching, and = sharing is a problem for the MRCP server. Exposing this in the protocol puts = unnecessary complexity on the client. For example, the client needs to download = grammars, implement its own HTTP caching, checksum algorithms (some way of not = having to push huge data to the MRCP server to query) = etc.

 

So I vote for point 1 below and include in the = text that an MRCP server could also, as an optimisation, implement = a centralised common cache shared across multiple MRCP = servers.

 

Dave

----- Original Message ----- =

Sent: Saturday, June 11, 2005 12:09 AM

Subject: RE: [Speechsc] Managing big grammars

 

I would say that a common cache = amoung a farm of MRCP servers to optimize compilations would be a nice server = side optimization and shouldn't affect the MRCP = protocol.

 

my 2c.

Sarvi

------_=_NextPart_001_01C56EE7.76C81A04-- --===============0699690137== 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 --===============0699690137==-- From speechsc-bounces@ietf.org Sun Jun 12 01:29:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhL2L-0000p0-67; Sun, 12 Jun 2005 01:29:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhL2H-0000nA-5l for speechsc@megatron.ietf.org; Sun, 12 Jun 2005 01:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06700 for ; Sun, 12 Jun 2005 01:29:28 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhLOH-0003Kl-AC for speechsc@ietf.org; Sun, 12 Jun 2005 01:52:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Jun 2005 22:29:19 -0700 X-IronPort-AV: i="3.93,191,1115017200"; d="scan'208"; a="643128728:sNHT35115844" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5C5TGlq025867; Sat, 11 Jun 2005 22:29:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Sat, 11 Jun 2005 22:29:15 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05B88C@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVuxiTa9OUcvNDsTma/HmjfdtPAYQASHJMg From: "Shanmugham, Saravanan" To: "Corby Anderson" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I am not sure I get this. There is already support for this.=20 There is a bunch of caching related headers that already defined, and they are based on HTTP.=20 So when the client does a DEFINE-GRAMMAR for large grammar, the ideal way is to refer to it using a HTTP URI, so that the MRCP server is expected to go download and possibly compile it.=20 When you do this, the server is expected to maintain a cache of downloaded documents. The caching behaviour for these documents is controlled by the MRCP client by setting the appropriate cache control parameters in the DEFINE-GRAMMAR request.=20 This controls how long the MRCP server is expected to cache such documents. Also, since these large grammars are accessed by the MRCP server through a HTTP client, the webserver serving these large documents can also specify the caching properties of the documents it serves. The MRCP server and HTTP client and cache are supposed to honor this. Nthis should cover all of your large grammar requirements below. Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Saturday, June 11, 2005 1:41 PM To: Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 Thanks, all, for considering those features. I appreciate=20 the time you spent discussing them -- especially since the=20 spec is so close to completion. =20 So let's quickly revisit the original two usage cases I=20 was interested in (Large grammars that might be several=20 thousand lines long and Jumbo grammars that might be=20 hundreds of thousands of lines long). It sounds clear=20 that the group's intent is for vendors to provide back-end=20 tools for compiling, storing, and referring to Jumbo=20 grammar binaries; so Sarvi's option #1 would only apply to=20 the Large grammars. When the client wants to recognize=20 with a Large grammar, it would have to upload the grammar=20 source to the MRCP server (which may or may not cache it=20 in source and/or binary form -- depending on how/if the=20 vendor chooses to implement this optimization). Would it=20 be appropriate to include a hint to the client that the=20 MRCP server has cached the grammar? For example, if a=20 Large grammar is uploaded with DEFINE-GRAMMAR, a header in=20 the 200 response could indicate that this grammar is=20 cached -- a client could use this information to avoid=20 uploading that Large grammar again for future recognitions=20 with that grammar on that MRCP server. =20 The downside, of course, is that it raises cache=20 management issues: how long do these things stay in cache,=20 how can a client determine if a previously-cached grammar=20 is still in the cache, etc. All of these are=20 surmountable, but I don't have a feel for whether they=20 belong in the spec or not. =20 What does the group think? If a vendor chooses to=20 implement Large grammar caching, should the spec cover=20 supplying hints to the client so that the client doesn't=20 have to upload the same (cached) grammar for subsequent=20 recogntions? Even though this would be a vendor-optional=20 feature, I think it would common enough that the spec=20 would benefit from having a common mechanism to indicate=20 whether a grammar is cached. =20 Thanks, Corby Anderson Tellme Networks, Inc. =20 Dave Burke wrote: =20 > I agree. Grammar compilation, caching, and sharing is a=20 problem for=20 > the MRCP server. Exposing this in the protocol puts unnecessary=20 > complexity on the client. For example, the client needs=20 to download=20 > grammars, implement its own HTTP caching, checksum=20 algorithms (some=20 > way of not having to push huge data to the MRCP server=20 to query) etc. > =20 > So I vote for point 1 below and include in the text that an MRCP=20 > server could also, as an optimisation, implement a=20 centralised common=20 > cache shared across multiple MRCP servers. > =20 > Dave > > ----- Original Message ----- > *From:* Shanmugham, Saravanan > *To:* Corby Anderson ;=20 Speechsc@ietf.org > > *Sent:* Saturday, June 11, 2005 12:09 AM > *Subject:* RE: [Speechsc] Managing big grammars > > I would say that a common cache amoung a farm of=20 MRCP servers to > optimize compilations would be a nice server side=20 optimization and > shouldn't affect the MRCP protocol. > =20 > my 2c. > Sarvi > > =20 ----------------------------------------------------------- ------------- > *From:* speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] *On Behalf Of=20 *Corby Anderson > *Sent:* Friday, June 10, 2005 11:52 AM > *To:* Speechsc@ietf.org > *Subject:* Re: [Speechsc] Managing big grammars > > Option #1 seems like a step in the right=20 direction, but having > multi-server re-use would make it even more=20 useful. Option #1 > as worded implies that /each /MRCP server would have to > compile grammar "X" the first time it's used; =20 I'm suggesting > that we try and make one MRCP server's=20 compilation efforts > useful to other MRCP servers (as long as they're the same > vendor). The use case I have in mind is a "farm" of > recognition servers -- and when we compile one=20 of these Large > grammars (grammar "X"), it would be great to=20 store it in some > common storage area so that other MRCP servers=20 could check for > its existence and load the binary.=20 > It isn't necessary to have a standard compiled=20 grammar format > -- it's just necessary to have a standard way to=20 reference > them. In a server farm environment containing multiple > vendors' MRCP servers, wouldn't the client know=20 (or couldn't > it discover during session setup) which kind of=20 server it was > connecting to and so adjust the query/compile uri > accordingly? I envision something along the lines of: > > MRCP/2.0 82 QUERY-GRAMMAR 123456 > Compiled-Grammar-URI: > =20 >=20 http://grammar-resource//query?name=3D > > > MRCP/2.0 507 COMPILE-GRAMMAR 123654 > Compiled-Grammar-URI: > =20 http://grammar-resource//store?name=3D > Content-type: application/srgs+xml > Content-Length: 176 > > > > Where the "grammar-resource" would be simple and general > enough to be implemented by either the client or=20 the vendor. > > Corby Anderson > Tellme Networks, Inc. > > Shanmugham, Saravanan wrote: > >>I agree, the issue is that there is no standard for=20 compilation and=20 >>compiled grammar format. I am not sure a=20 COMPILE-GRAMMAR method is=20 >>the solution to this. >> >>The aim of compilation is to accelarate customer=20 response when dealing=20 >>with large-grammars. >>A few ways to achieve the above, like I mentioned earlier are, >> 1. The MRCP server could implement an optimization for large=20 >>grammars that leverages the grammar caching mechanism and its=20 >>capabilities. That is when they cache a grammar URI,=20 they also store=20 >>the compiled version of the grammar. They could do this=20 in a vendor specific compiled format. >>Large grammars are usually not dynamic and hence the=20 caching mechanims=20 >>should work reasonably well for this. >> 2. Have the MRCP client point to=20 pre-compiled-grammars so that when=20 >>the MRCP server goes and fetches it the large-grammar is already=20 >>compiled. There is the problem of making sure the compiled >>grammar(vendor-specific) matches the specific=20 recognition engine used. >>This is difficult to manage in a multivendor deployment. >> 3. Compile and store the grammars on the MRCP server=20 ahead of time=20 >>during deployments. And then refer to these compiled=20 grammars on the=20 >>MRCP server. This would have its own limitations, but would be=20 >>workable in many cases/deployments. >> >> >>We could add the text for the first above bullet into the MRCPv2=20 >>specification if no one has any objects to it. >> >>Thanks, >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org=20 >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Qiru Zhou >> Sent: Wednesday, June 08, 2005 2:17 PM >> To: Corby Anderson >> Cc: Speechsc@ietf.org >> Subject: Re: [Speechsc] Managing big grammars >> =20 >> I think the problem here is there is no standard for=20 >> compiled grammar format. This is a vendor implementation=20 >> specific which is not inter-operable across different=20 >> vendors. I agree that pre-compiled large grammars can=20 >> improve system response and processing efficiency. But I=20 >> don't know if this should be the part of standard. Same=20 >> for cache, it is an implementation specific issue. Another=20 >> practice on this issue is to pre load and archive large=20 >> grammar in recognizer (i.e., add ARCHIVE-GRAMMAR method). >> =20 >> -- Qiru >> =20 >> Corby Anderson wrote: >> > One feature that I'd like a COMPILE-GRAMMAR method to=20 >> provide is the=20 >> > ability to specify common back-end storage (like Sarvi=20 >> mentioned) so=20 >> > that compiling a Large Grammar one time could make it=20 >> available to=20 >> > other MRCP servers via the Compiled-Grammar-URI that=20 >> Klaus suggested. =20 >> > It would be especially useful to us if the *client*=20 >> could specify the=20 >> > URI where the grammar should be stored. This would=20 >> permit clients to=20 >> > use grammar names that are meaningful to the client. =20 >> (The example for=20 >> > Personal-Grammar-URI seems like the grammar name is=20 >> specified by the=20 >> > client, but it's worth spelling out.) >> >=20 >> > To round out the utility of a feature like this, we'd=20 >> need some way to=20 >> > determine if a grammar had already been compiled. Since=20 >> we're talking=20 >> > about URIs, the client could just do a HEAD on the=20 >> grammar to see if=20 >> > it exists -- but does the client always have=20 access to back-end=20 >> > resources in this way? If not, then a QUERY-GRAMMAR=20 >> method which=20 >> > takes a Compiled-Grammar-URI header could provide this=20 >> capability. >> >=20 >> > Corby Anderson >> > Tellme Networks, Inc. >> >=20 >> >=20 >> > Reifenrath, Klaus wrote: >> >=20 >> >> I agree. >> >> BUT unfortunately there is no MRCPv2 interface to just=20 >> compile a=20 >> >> grammar. So grammar compilation needs to be done with=20 >> vendor specific=20 >> >> tools or APIs. >> >> We could add a new method (allowed only in idle state): >> >> COMPILE-GRAMMAR >> >> that requires the header field >> >> Compiled-Grammar-URI >> >> that specifies the location of the compiled=20 grammar (like=20 >> >> Personal-Grammar-URI). >> >> Is it too late to add this simple optional method? >> >> >> >> Klaus >> >> >> >> -----Original Message----- >> >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 >> Sent: Dienstag,=20 >> >> 7. Juni 2005 21:09 >> >> To: Corby Anderson; Speechsc@ietf.org >> >> Subject: RE: [Speechsc] Managing big grammars >> >> >> >> Sorry for the late reply. The way I think this should=20 >> be addressed is=20 >> >> to have support for compiled grammars as URI.=20 All Large or Huge=20 >> >> grammars are going to be URI referenced and never=20 >> embedded in a DEFINE grammar. >> >> This means that the URI could point to compiled=20 grammar file. >> >> >> >> Another way is to use the chache capability.=20 When you access a=20 >> >> grammar through HTTP is to cache it. In general instead=20 >> of caching of=20 >> >> the XML grammar you could decide to cache the=20 compiled version=20 >> >> instead. This would mean that you might do an initial=20 >> DEFINE-GRAMMAR=20 >> >> to force a compile of the grammar and future=20 references to that=20 >> >> grammar URI would hit the cache and hence the=20 compiled version. >> >> >> >> Sarvi >> >> >> >> -----Original Message----- >> >> From: speechsc-bounces@ietf.org =20 >> >> [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Corby Anderson >> >> Sent: Thursday, May 26, 2005 2:11 PM >> >> To: Speechsc@ietf.org >> >> Subject: [Speechsc] Managing big grammars >> >> What are folks' thoughts on how we could=20 manage big =20 >> >> grammars with MRCP? >> >> There are two usage cases that I'm interested=20 >> in: a Large =20 >> >> Grammar that takes several seconds to compile, and a=20 >> Jumbo Grammar=20 >> >> that takes many many minutes to compile. A Large =20 >> Grammar might=20 >> >> contain several hundred or thousand entries. A=20 >> Jumbo Grammar=20 >> >> might contain hundreds of thousands of entries. >> >> For a Jumbo Grammar, there's no way that a user=20 >> can wait =20 >> >> for a grammar to be uploaded and compiled via the =20 >> DEFINE-GRAMMAR=20 >> >> or RECOGNIZE methods. A grammar that large =20 needs to be=20 >> >> pre-compiled so that the DEFINE-GRAMMAR or =20 >> RECOGNIZE method can=20 >> >> simply load the grammar binary. >> >> For a Large Grammar, it might be okay to make=20 >> one user =20 >> >> wait a few seconds for the grammar to compile -- but it=20 >> would be a=20 >> >> big win if that compiled grammar were stored with a=20 >> known name so=20 >> >> that /subsequent/ uses of the same grammar don't=20 >> have to pay the=20 >> >> same compilation penalty. >> >> Our current speech recognition vendor's api=20 >> provides =20 >> >> methods for checking for the existence of a dynamic =20 >> grammar, and=20 >> >> for compiling a new grammar (named as the client=20 >> specifies). The=20 >> >> api also provides a powerful and flexible way to=20 >> manage these=20 >> >> stored grammars. Is there some MRCP-friendly way=20 >> for dealing with=20 >> >> these types of grammars? If not, then is one being=20 >> considered? >> >> Corby Anderson >> >> Tellme Networks, Inc. >> >> =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 >> >> >> >=20 >> > _______________________________________________ >> > Speechsc mailing list >> > Speechsc@ietf.org >> > https://www1.ietf.org/mailman/listinfo/speechsc >> =20 >> =20 >> > =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 Sun Jun 12 15:11:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhXsF-0000pi-H4; Sun, 12 Jun 2005 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhXsD-0000pd-3e for speechsc@megatron.ietf.org; Sun, 12 Jun 2005 15:11:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28980 for ; Sun, 12 Jun 2005 15:11:54 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhYEJ-0008QG-EQ for Speechsc@ietf.org; Sun, 12 Jun 2005 15:34:49 -0400 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id BA15F214042; Sun, 12 Jun 2005 19:11:34 +0000 (GMT) Message-ID: <01c501c56f82$8c239160$8800000a@db01.voxpilot.com> From: "Dave Burke" To: "Wyss, Felix" , "Shanmugham, Saravanan" , "Corby Anderson" , References: <8F9F1C6AA1D6834EACC379C8821533A6011524C2@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Managing big grammars Date: Sun, 12 Jun 2005 20:11:32 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 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="===============0687904240==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0687904240== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C2_01C56F8A.ECFB0150" This is a multi-part message in MIME format. ------=_NextPart_000_01C2_01C56F8A.ECFB0150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There is no doubt that grammar compilation and loading must be hidden = from the caller experience. What is in doubt is whether the MRCP = protocol needs to expose such control.=20 The grammar loading problem is not dissimilar to cache seeding in the = Web world. Taking your use-case, I would implement this in MRCP as a = two-step process: (1) Make the large grammar available through HTTP and date-stamp the = URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the = HTTP response header Cache-Control: max-age to a value larger than the = grammar change period. (2) When a new grammar is required, open an MRCP channel to each of the = MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. = http://example.com/large_grammar_13June2005.grxml. Update the = application to point at the new grammar. [For a mid-size grammar where loading latency is negligible, and = assuming a centrally located compiled grammar cache, step (2) might only = require a DEFINE-GRAMMAR to one MRCP server]. You are correct that the current MRCPv2 draft scopes the DEFINE-GRAMMAR = to a channel and this is a concern. However, this is resolved with = Sarvi's suggested text change. Dave ----- Original Message -----=20 From: Wyss, Felix=20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; = Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars I disagree. Predictability is *very* critical for an application = using ASR. It must be able to make sure that when a recognition = operation is started, there is no latency while the ASR server compiles = and/or loads a large precompiled grammar into memory. The = DEFINE-GRAMMAR command is scoped to a channel, which means by the time = the application has a channel (i.e. a caller is in the system), it is = unacceptable to block for more than fraction of a second while the = grammars are being compiled and/or loaded. Otherwise, the first caller = after a grammar is changed encounters delays and has a poor user = experience or even hangs up. Somebody may say: well, just make a = "priming" call after modifying the grammar to ensure the grammar is = cached. However, that is not very practical for automatically generated = grammars; but worse yet, in large systems there are commonly several = load-balanced ASR severs and it will be rather hard to ensure each of = them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large grammars = that may change frequently, possibly several times a day, such as = company directory grammars that are generated from a database, can be = registered as "preloaded grammars". This means, our platform ensures = the grammar is compiled, distributed to all ASR servers, and loaded into = their caches after a new version of that grammar has been generated. = Each preloaded grammar has a name associated, which is referenced = through a special URI. The application logic only knows that URI and = not the actual URI/filename of the underlying grammar data. The = subsystem managing the preloaded grammars ensures that the preloaded = grammar URI resolves to the previous version of the grammar until the = new grammar is loaded and ready on all ASR servers. Thus, all callers = that call into the system while the grammar is being generated, = compiled, and loaded on the servers will get the previous version. This = ensures that there is no delay for the first caller after a change. We = can do this as we are using the native APIs provided by the ASR engine = vendors we support and layer a sophisticated framework and API on top of = it. =20 =20 It would be nice if MRCP provided some support for schemes like that, = without having to open dummy channels to register grammars and pray the = MRCP server doesn't evict them too early. An MRCP client has to be able = to guarantee that when a call comes through the system, everything is = ready and it won't experience any delay. As it stands now the MRCP = protocol does not appear to provide support for this. =20 Thanks, Felix =20 -------------------------------------------------------------------------= ----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On = Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem for = the MRCP server. Exposing this in the protocol puts unnecessary = complexity on the client. For example, the client needs to download = grammars, implement its own HTTP caching, checksum algorithms (some way = of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP = server could also, as an optimisation, implement a centralised common = cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to = optimize compilations would be a nice server side optimization and = shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------=_NextPart_000_01C2_01C56F8A.ECFB0150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There is no doubt that grammar = compilation and=20 loading must be hidden from the caller experience. What is in doubt is whether the MRCP protocol needs to expose = such=20 control.
 
The grammar loading = problem is not=20 dissimilar to cache seeding in the Web world. Taking your use-case, I = would=20 implement this in MRCP as a two-step process:
 
(1) Make the large grammar available = through HTTP=20 and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml.=20 Set the HTTP response header Cache-Control: max-age to a value larger = than the=20 grammar change period.
 
(2) When a new grammar is required, = open an MRCP=20 channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR with the = relevant=20 URI e.g. http://example= .com/large_grammar_13June2005.grxml.=20 Update the application to point at the new grammar.
 
[For a mid-size grammar where loading = latency is=20 negligible, and assuming a centrally located compiled grammar cache, = step (2)=20 might only require a DEFINE-GRAMMAR to one MRCP server].
 
You are correct that the current MRCPv2 = draft=20 scopes the DEFINE-GRAMMAR to a channel and this is a = concern. However, this=20 is resolved with Sarvi's suggested text change.
 
Dave
----- Original Message -----
From:=20 Wyss, = Felix
To: Dave Burke ; Shanmugham, = Saravanan=20 ; Corby = Anderson=20 ; Speechsc@ietf.org
Sent: Sunday, June 12, 2005 = 1:41 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I = disagree. =20 Predictability is *very*=20 critical for an application using ASR.  It must be able to make = sure that=20 when a recognition operation is started, there is no latency while the = ASR=20 server compiles and/or loads a large precompiled grammar into memory.=20  The DEFINE-GRAMMAR command is scoped to a channel, which means = by the=20 time the application has a channel (i.e. a caller is in the system), = it is=20 unacceptable to block for more than fraction of a second while the = grammars=20 are being compiled and/or loaded.  Otherwise, the first caller = after a=20 grammar is changed encounters delays and has a poor user experience or = even=20 hangs up.  Somebody may say: well, just make a =93priming=94 call = after=20 modifying the grammar to ensure the grammar is cached.  However, = that is=20 not very practical for automatically generated grammars; but worse = yet, in=20 large systems there are commonly several load-balanced ASR severs and = it will=20 be rather hard to ensure each of them is touched at least once.=20  

 

The way we = solve this=20 on our platform is as follows: Large grammars that may change = frequently,=20 possibly several times a day, such as company directory grammars that = are=20 generated from a database, can be registered as =93preloaded = grammars=94.=20  This means, our platform ensures the grammar is compiled, = distributed to=20 all ASR servers, and loaded into their caches after a new version of = that=20 grammar has been generated.  Each preloaded grammar has a name=20 associated, which is referenced through a special URI.  The = application=20 logic only knows that URI and not the actual URI/filename of the = underlying=20 grammar data.  The subsystem managing the preloaded grammars = ensures that=20 the preloaded grammar URI resolves to the previous version of the = grammar=20 until the new grammar is loaded and ready on all ASR servers. =  Thus, all=20 callers that call into the system while the grammar is being = generated,=20 compiled, and loaded on the servers will get the previous version. =  This=20 ensures that there is no delay for the first caller after a change. =  We=20 can do this as we are using the native APIs provided by the ASR engine = vendors=20 we support and layer a sophisticated framework and API on top of = it. =20

 

It would be = nice if=20 MRCP provided some support for schemes like that, without having to = open dummy=20 channels to register grammars and pray the MRCP server doesn=92t evict = them too=20 early.  An MRCP client has to be able to guarantee that when a = call comes=20 through the system, everything is ready and it won=92t experience any = delay.=20  As it stands now the MRCP protocol does not appear to provide = support=20 for this.

 

Thanks,

Felix

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave = Burke
Sent: Saturday, June 11, 2005=20 10:42
To: = Shanmugham,=20 Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big=20 grammars

 

I agree. Grammar = compilation,=20 caching, and sharing is a problem for the MRCP server. Exposing this = in the=20 protocol puts unnecessary complexity on the client. For example, the = client=20 needs to download grammars, implement its own HTTP caching, checksum=20 algorithms (some way of not having to push huge data to the MRCP = server to=20 query) etc.

 

So I vote for point 1 = below and=20 include in the text that an MRCP server could also, as an=20 optimisation, implement a centralised common cache shared across = multiple=20 MRCP servers.

 

Dave

----- Original Message = -----=20

From: Shanmugham,=20 Saravanan

To: Corby = Anderson ;=20 Speechsc@ietf.org=20

Sent:=20 Saturday, June 11, 2005 12:09 AM

Subject: RE:=20 [Speechsc] Managing big grammars

 

I would = say that a=20 common cache amoung a farm of MRCP servers to optimize compilations = would be=20 a nice server side optimization and shouldn't affect the MRCP=20 protocol.

 

my=20 2c.

Sarvi

------=_NextPart_000_01C2_01C56F8A.ECFB0150-- --===============0687904240== 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 --===============0687904240==-- From speechsc-bounces@ietf.org Sun Jun 12 19:24:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhbog-0005TO-1y; Sun, 12 Jun 2005 19:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhbof-0005TG-1v for speechsc@megatron.ietf.org; Sun, 12 Jun 2005 19:24:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19364 for ; Sun, 12 Jun 2005 19:24:29 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhcAm-0000qr-S7 for Speechsc@ietf.org; Sun, 12 Jun 2005 19:47:27 -0400 X-SEF-Processed: 5_0_0_713__2005_06_12_18_23_12 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Sun, 12 Jun 2005 18:23:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Managing big grammars Date: Sun, 12 Jun 2005 18:24:14 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524C3@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVvgoxBKTbieo2dRaaXFwf6WkzIDgAGyWPA From: "Wyss, Felix" To: "Dave Burke" , "Shanmugham, Saravanan" , "Corby Anderson" , X-Spam-Score: 0.3 (/) X-Scan-Signature: af7c9eab0f208726cc6b32d194122b96 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="===============1298322552==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1298322552== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56FA5.D87D579E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56FA5.D87D579E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [inline] =20 Felix =20 ________________________________ From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Sunday, June 12, 2005 14:12 To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 There is no doubt that grammar compilation and loading must be hidden from the caller experience. What is in doubt is whether the MRCP protocol needs to expose such control.=20 [Wyss, Felix] I believe it is critical that the MRCP standard mandates behavior that is deterministic and consistent on all conforming MRCP server implementations. As it stands now, I am not convinced this is the case with respect to grammar management. =20 =20 The grammar loading problem is not dissimilar to cache seeding in the Web world. Taking your use-case, I would implement this in MRCP as a two-step process: =20 (1) Make the large grammar available through HTTP and date-stamp the URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the HTTP response header Cache-Control: max-age to a value larger than the grammar change period. [Wyss, Felix] This may work in some cases but it is not deterministic. The HTTP protocol does not mandate that clients honor the cache control headers. They are primarily a hint to avoid unnecessary fetches. Unless there is some way to lock the grammar in memory through the MRCP protocol, the MRCP server's HTTP client or compiled grammar cache may decided to evict a large grammar that has not been used for a while (e.g. overnight). In my opinion, forcing the application to rely on the MRCP server's grammar cache behavior is a hack as it will be vendor specific. =20 =20 (2) When a new grammar is required, open an MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. http://example.com/large_grammar_13June2005.grxml. Update the application to point at the new grammar. [Wyss, Felix] That too is really just a hack. I can imagine that there will be load-balancing proxies for MRCP servers. The client may thus not reliably know how many actual ASR servers there are or even be able to individually address them. =20 =20 [For a mid-size grammar where loading latency is negligible, and assuming a centrally located compiled grammar cache, step (2) might only require a DEFINE-GRAMMAR to one MRCP server]. =20 You are correct that the current MRCPv2 draft scopes the DEFINE-GRAMMAR to a channel and this is a concern. However, this is resolved with Sarvi's suggested text change. [Wyss, Felix] Where is that documented? I didn't see it in the latest version I could find (draft-ietf-speechsc-mrcpv2-06.txt). =20 =20 Dave ----- Original Message -----=20 From: Wyss, Felix =20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars =20 I disagree. Predictability is *very* critical for an application using ASR. It must be able to make sure that when a recognition operation is started, there is no latency while the ASR server compiles and/or loads a large precompiled grammar into memory. The DEFINE-GRAMMAR command is scoped to a channel, which means by the time the application has a channel (i.e. a caller is in the system), it is unacceptable to block for more than fraction of a second while the grammars are being compiled and/or loaded. Otherwise, the first caller after a grammar is changed encounters delays and has a poor user experience or even hangs up. Somebody may say: well, just make a "priming" call after modifying the grammar to ensure the grammar is cached. However, that is not very practical for automatically generated grammars; but worse yet, in large systems there are commonly several load-balanced ASR severs and it will be rather hard to ensure each of them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large grammars that may change frequently, possibly several times a day, such as company directory grammars that are generated from a database, can be registered as "preloaded grammars". This means, our platform ensures the grammar is compiled, distributed to all ASR servers, and loaded into their caches after a new version of that grammar has been generated. Each preloaded grammar has a name associated, which is referenced through a special URI. The application logic only knows that URI and not the actual URI/filename of the underlying grammar data. The subsystem managing the preloaded grammars ensures that the preloaded grammar URI resolves to the previous version of the grammar until the new grammar is loaded and ready on all ASR servers. Thus, all callers that call into the system while the grammar is being generated, compiled, and loaded on the servers will get the previous version. This ensures that there is no delay for the first caller after a change. We can do this as we are using the native APIs provided by the ASR engine vendors we support and layer a sophisticated framework and API on top of it. =20 =20 It would be nice if MRCP provided some support for schemes like that, without having to open dummy channels to register grammars and pray the MRCP server doesn't evict them too early. An MRCP client has to be able to guarantee that when a call comes through the system, everything is ready and it won't experience any delay. As it stands now the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 =09 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem for the MRCP server. Exposing this in the protocol puts unnecessary complexity on the client. For example, the client needs to download grammars, implement its own HTTP caching, checksum algorithms (some way of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP server could also, as an optimisation, implement a centralised common cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan =20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to optimize compilations would be a nice server side optimization and shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------_=_NextPart_001_01C56FA5.D87D579E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[inline]

 

Felix

 

From: Dave Burke [mailto:david.burke@voxpilot.com]
Sent: Sunday, June 12, = 2005 14:12
To: Wyss, Felix; = Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big grammars

 

There is no doubt that = grammar compilation and loading must be hidden from the caller experience. What = is in doubt is whether the MRCP protocol needs to expose such control. =

[Wyss, Felix] I believe it is critical that the MRCP standard mandates behavior that is deterministic and consistent on all conforming MRCP server implementations.  As it stands now, I am not convinced this is the case with respect to grammar management. =  

 

The grammar loading problem is not dissimilar to cache seeding in the Web world. Taking = your use-case, I would implement this in MRCP as a two-step = process:

 

(1) Make the large grammar = available through HTTP and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml. Set the HTTP response header Cache-Control: max-age to a value larger = than the grammar change period.

 [Wyss, Felix] This may = work in some cases but it is not deterministic.  The HTTP protocol does not mandate that clients honor the cache control headers.  They are = primarily a hint to avoid unnecessary fetches.  Unless there is some way to = lock the grammar in memory through the MRCP protocol, the MRCP server’s = HTTP client or compiled grammar cache may decided to evict a large grammar = that has not been used for a while (e.g. overnight).  In my opinion, forcing = the application to rely on the MRCP server’s grammar cache behavior is a hack as = it will be vendor specific.  

 

(2) When a new grammar is = required, open an MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR = with the relevant URI e.g. http://example= .com/large_grammar_13June2005.grxml. Update the application to point at the new = grammar.

[Wyss, Felix] That too is really just a hack.  I = can imagine that there will be load-balancing proxies for MRCP servers. =  The client may thus not reliably know how many actual ASR servers there are = or even be able to individually address them.  

 

[For a mid-size grammar where loading latency is negligible, and assuming a centrally located compiled grammar cache, step (2) might only require a DEFINE-GRAMMAR to one MRCP server].

 

You are correct that the = current MRCPv2 draft scopes the DEFINE-GRAMMAR to a channel and this is a concern. However, this is resolved with Sarvi's suggested text = change.

[Wyss, Felix] Where is that documented?  I = didn’t see it in the latest version I could find = (draft-ietf-speechsc-mrcpv2-06.txt). =  

 

Dave

----- Original Message ----- =

Sent: Sunday, June 12, 2005 1:41 = AM

Subject: RE: [Speechsc] Managing big = grammars

 

I disagree.  Predictability is = *very* critical for an application = using ASR.  It must be able to make sure that when a recognition = operation is started, there is no latency while the ASR server compiles and/or loads = a large precompiled grammar into memory.  The DEFINE-GRAMMAR command is = scoped to a channel, which means by the time the application has a channel (i.e. a = caller is in the system), it is unacceptable to block for more than fraction of = a second while the grammars are being compiled and/or loaded.  Otherwise, = the first caller after a grammar is changed encounters delays and has a poor user experience or even hangs up.  Somebody may say: well, just make a “priming” call after modifying the grammar to ensure the = grammar is cached.  However, that is not very practical for automatically = generated grammars; but worse yet, in large systems there are commonly several load-balanced ASR severs and it will be rather hard to ensure each of = them is touched at least once.  

 

The way we solve this on our = platform is as follows: Large grammars that may change frequently, possibly several = times a day, such as company directory grammars that are generated from a = database, can be registered as “preloaded grammars”.  This means, our platform ensures the grammar is compiled, distributed to all ASR = servers, and loaded into their caches after a new version of that grammar has been generated.  Each preloaded grammar has a name associated, which is referenced through a special URI.  The application logic only knows = that URI and not the actual URI/filename of the underlying grammar data. =  The subsystem managing the preloaded grammars ensures that the preloaded = grammar URI resolves to the previous version of the grammar until the new = grammar is loaded and ready on all ASR servers.  Thus, all callers that call = into the system while the grammar is being generated, compiled, and loaded on the servers will get the previous version.  This ensures that there is = no delay for the first caller after a change.  We can do this as we = are using the native APIs provided by the ASR engine vendors we support and layer = a sophisticated framework and API on top of it.  =

 

It would be nice if MRCP provided = some support for schemes like that, without having to open dummy channels to register grammars and pray the MRCP server doesn’t evict them too = early.  An MRCP client has to be able to guarantee that when a call comes = through the system, everything is ready and it won’t experience any delay.  As it stands now the MRCP protocol does not appear to provide = support for this.

 

Thanks,

=

Felix

 

From: speechsc-bounces@ietf.org = [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave = Burke
Sent: Saturday, June 11, = 2005 10:42
To: Shanmugham, = Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big grammars

 

I agree. Grammar compilation, caching, and = sharing is a problem for the MRCP server. Exposing this in the protocol puts = unnecessary complexity on the client. For example, the client needs to download = grammars, implement its own HTTP caching, checksum algorithms (some way of not = having to push huge data to the MRCP server to query) = etc.

 

So I vote for point 1 below and include in the = text that an MRCP server could also, as an optimisation, implement = a centralised common cache shared across multiple MRCP = servers.

 

Dave

----- Original Message ----- =

Sent: Saturday, June 11, 2005 12:09 AM

Subject: RE: [Speechsc] Managing big grammars

 

I would say that a common cache = amoung a farm of MRCP servers to optimize compilations would be a nice server = side optimization and shouldn't affect the MRCP = protocol.

 

my 2c.

Sarvi

------_=_NextPart_001_01C56FA5.D87D579E-- --===============1298322552== 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 --===============1298322552==-- From speechsc-bounces@ietf.org Mon Jun 13 06:14:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhlxU-0007X0-Sz; Mon, 13 Jun 2005 06:14:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhlx9-0007T4-OK for speechsc@megatron.ietf.org; Mon, 13 Jun 2005 06:14:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26381 for ; Mon, 13 Jun 2005 06:13:54 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhmJG-00057E-1b for Speechsc@ietf.org; Mon, 13 Jun 2005 06:36:57 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id E91E0214042; Mon, 13 Jun 2005 10:13:26 +0000 (GMT) Message-ID: <0c6201c57000$8a1bdd40$8800000a@db01.voxpilot.com> From: "Dave Burke" To: "Wyss, Felix" , "Shanmugham, Saravanan" , "Corby Anderson" , References: <8F9F1C6AA1D6834EACC379C8821533A6011524C3@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Managing big grammars Date: Mon, 13 Jun 2005 11:13:26 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: 03798b51c5f8a7e89d7f7972440c2a03 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="===============0621510160==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0621510160== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C5F_01C57008.EB9E8150" This is a multi-part message in MIME format. ------=_NextPart_000_0C5F_01C57008.EB9E8150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline with DB> -- Dave ----- Original Message -----=20 From: Wyss, Felix=20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; = Speechsc@ietf.org=20 Sent: Monday, June 13, 2005 12:24 AM Subject: RE: [Speechsc] Managing big grammars [inline] =20 Felix =20 -------------------------------------------------------------------------= ----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Sunday, June 12, 2005 14:12 To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; = Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 There is no doubt that grammar compilation and loading must be hidden = from the caller experience. What is in doubt is whether the MRCP = protocol needs to expose such control.=20 [Wyss, Felix] I believe it is critical that the MRCP standard mandates = behavior that is deterministic and consistent on all conforming MRCP = server implementations. As it stands now, I am not convinced this is = the case with respect to grammar management. =20 DB> I agree that the MRCP standard should not be silent on = _optimisations_ for large grammars so that we achieve consistent = behavior across implementations. I just don't agree that additional MRCP = client control is necessary, warranted, nor solves the problem. =20 The grammar loading problem is not dissimilar to cache seeding in the = Web world. Taking your use-case, I would implement this in MRCP as a = two-step process: =20 (1) Make the large grammar available through HTTP and date-stamp the = URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the = HTTP response header Cache-Control: max-age to a value larger than the = grammar change period. [Wyss, Felix] This may work in some cases but it is not = deterministic. The HTTP protocol does not mandate that clients honor = the cache control headers. They are primarily a hint to avoid = unnecessary fetches. Unless there is some way to lock the grammar in = memory through the MRCP protocol, the MRCP server's HTTP client or = compiled grammar cache may decided to evict a large grammar that has not = been used for a while (e.g. overnight). In my opinion, forcing the = application to rely on the MRCP server's grammar cache behavior is a = hack as it will be vendor specific. =20 DB> I would not consider using HTTP standard caching mechanisms a = hack. An MRCP server that supports large grammars would be ill advised = not honor HTTP caching headers. Moreover, an MRCP server that supports = large grammars would be ill advised to implement an aggressive LRU = approach you describe (rather one would imagine pruning would only = happen at cache overflow). =20 (2) When a new grammar is required, open an MRCP channel to each of = the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. = http://example.com/large_grammar_13June2005.grxml. Update the = application to point at the new grammar. [Wyss, Felix] That too is really just a hack. I can imagine that = there will be load-balancing proxies for MRCP servers. The client may = thus not reliably know how many actual ASR servers there are or even be = able to individually address them. =20 DB> The case of "pinging" each server only applies to the case when = loading the previously compiled grammar from a central location into = memory incurs significant latency. This is the "jumbo" as opposed to = "large" case. Adding verbs to the MRCP client to control grammar = compilation (as discussed in this thread) does not alleviate this = problem. This is a problem for the MRCP server to optimise - not the = client to control. There are solutions that can work here (e.g. when a = DEFINE-GRAMMAR occurs on any MRCP server, compile and cache in a central = location and send a multicast message to inform other servers to = reload).=20 =20 [For a mid-size grammar where loading latency is negligible, and = assuming a centrally located compiled grammar cache, step (2) might only = require a DEFINE-GRAMMAR to one MRCP server]. =20 You are correct that the current MRCPv2 draft scopes the = DEFINE-GRAMMAR to a channel and this is a concern. However, this is = resolved with Sarvi's suggested text change. [Wyss, Felix] Where is that documented? I didn't see it in the latest = version I could find (draft-ietf-speechsc-mrcpv2-06.txt). =20 DB> In this thread.=20 =20 Dave ----- Original Message -----=20 From: Wyss, Felix=20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; = Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars =20 I disagree. Predictability is *very* critical for an application = using ASR. It must be able to make sure that when a recognition = operation is started, there is no latency while the ASR server compiles = and/or loads a large precompiled grammar into memory. The = DEFINE-GRAMMAR command is scoped to a channel, which means by the time = the application has a channel (i.e. a caller is in the system), it is = unacceptable to block for more than fraction of a second while the = grammars are being compiled and/or loaded. Otherwise, the first caller = after a grammar is changed encounters delays and has a poor user = experience or even hangs up. Somebody may say: well, just make a = "priming" call after modifying the grammar to ensure the grammar is = cached. However, that is not very practical for automatically generated = grammars; but worse yet, in large systems there are commonly several = load-balanced ASR severs and it will be rather hard to ensure each of = them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large grammars = that may change frequently, possibly several times a day, such as = company directory grammars that are generated from a database, can be = registered as "preloaded grammars". This means, our platform ensures = the grammar is compiled, distributed to all ASR servers, and loaded into = their caches after a new version of that grammar has been generated. = Each preloaded grammar has a name associated, which is referenced = through a special URI. The application logic only knows that URI and = not the actual URI/filename of the underlying grammar data. The = subsystem managing the preloaded grammars ensures that the preloaded = grammar URI resolves to the previous version of the grammar until the = new grammar is loaded and ready on all ASR servers. Thus, all callers = that call into the system while the grammar is being generated, = compiled, and loaded on the servers will get the previous version. This = ensures that there is no delay for the first caller after a change. We = can do this as we are using the native APIs provided by the ASR engine = vendors we support and layer a sophisticated framework and API on top of = it. =20 =20 It would be nice if MRCP provided some support for schemes like = that, without having to open dummy channels to register grammars and = pray the MRCP server doesn't evict them too early. An MRCP client has = to be able to guarantee that when a call comes through the system, = everything is ready and it won't experience any delay. As it stands now = the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 -------------------------------------------------------------------------= --- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem for = the MRCP server. Exposing this in the protocol puts unnecessary = complexity on the client. For example, the client needs to download = grammars, implement its own HTTP caching, checksum algorithms (some way = of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP = server could also, as an optimisation, implement a centralised common = cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to = optimize compilations would be a nice server side optimization and = shouldn't affect the MRCP protocol. =20 my 2c. Sarvi -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_0C5F_01C57008.EB9E8150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Inline with DB>
 
-- Dave
----- Original Message -----
From:=20 Wyss, = Felix
To: Dave Burke ; Shanmugham, = Saravanan=20 ; Corby = Anderson=20 ; Speechsc@ietf.org
Sent: Monday, June 13, 2005 = 12:24=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

[inline]

 

Felix

 

From: = Dave Burke=20 [mailto:david.burke@voxpilot.com]
Sent: Sunday, June 12, 2005=20 14:12
To: Wyss, = Felix;=20 Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big=20 grammars

 

There = is no=20 doubt that grammar compilation and loading must be hidden from the = caller=20 experience. What is in doubt is whether the MRCP protocol needs to = expose such=20 control.

[Wyss,=20 Felix] I believe it is critical that the MRCP standard mandates = behavior that=20 is deterministic and consistent on all conforming MRCP server=20 implementations.  As it stands now, I am not convinced this is = the case=20 with respect to grammar = management.  

 

DB>=20 I agree that the MRCP standard should not be silent on _optimisations_ = for=20 large grammars so that we achieve consistent behavior across = implementations.=20 I just don't agree that additional MRCP client control is necessary,=20 warranted, nor solves the problem.

 

The grammar=20 loading problem is not dissimilar to cache seeding in the Web = world.=20 Taking your use-case, I would implement this in MRCP as a two-step=20 process:

 

(1) = Make the=20 large grammar available through HTTP and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml.=20 Set the HTTP response header Cache-Control: max-age to a value larger = than the=20 grammar change period.

 [Wyss,=20 Felix] This may work in some cases but it is not deterministic. =  The HTTP=20 protocol does not mandate that clients honor the cache control = headers. =20 They are primarily a hint to avoid unnecessary fetches.  Unless = there is=20 some way to lock the grammar in memory through the MRCP protocol, the = MRCP=20 server=92s HTTP client or compiled grammar cache may decided to evict = a large=20 grammar that has not been used for a while (e.g. overnight).  In = my=20 opinion, forcing the application to rely on the MRCP server=92s = grammar cache=20 behavior is a hack as it will be vendor=20 specific.  

 

DB>=20 I would not consider using HTTP standard caching mechanisms a hack. An = MRCP=20 server that supports large grammars would=20 be ill advised not honor HTTP caching headers. Moreover, an MRCP = server=20 that supports large grammars would be ill advised to implement an=20 aggressive LRU approach you describe (rather one would imagine = pruning=20 would only happen at cache overflow).

 

(2) = When a new=20 grammar is required, open an MRCP channel to each of the MRCP servers. = Issue a=20 DEFINE-GRAMMAR with the relevant URI e.g. http://example= .com/large_grammar_13June2005.grxml.=20 Update the application to point at the new=20 grammar.

[Wyss,=20 Felix] That too is really just a hack.  I can imagine that there = will be=20 load-balancing proxies for MRCP servers.  The client may thus not = reliably know how many actual ASR servers there are or even be able to = individually address them.  

 

DB>=20 The case of "pinging" each server only applies to the case when = loading the=20 previously compiled grammar from a central location into = memory incurs=20 significant latency. This is the "jumbo" as opposed to "large" case. = Adding=20 verbs to the MRCP client to control grammar compilation (as discussed = in this=20 thread) does not alleviate this problem. This is a problem for the = MRCP server=20 to optimise - not the client to control. There are solutions that = can=20 work here (e.g.=20 when a DEFINE-GRAMMAR occurs on any MRCP server, compile and cache in = a=20 central location and send a multicast message to inform other servers = to=20 reload).

 

[For = a mid-size=20 grammar where loading latency is negligible, and assuming a centrally = located=20 compiled grammar cache, step (2) might only require a DEFINE-GRAMMAR = to one=20 MRCP server].

 

You = are correct=20 that the current MRCPv2 draft scopes the DEFINE-GRAMMAR to a channel = and this=20 is a concern. However, this is resolved with Sarvi's suggested = text=20 change.

[Wyss,=20 Felix] Where is that documented?  I didn=92t see it in the latest = version I=20 could find=20 = (draft-ietf-speechsc-mrcpv2-06.txt).  

 

DB>=20 In this thread.

 

Dave

-----=20 Original Message -----

From: Wyss, = Felix=20

To: Dave=20 Burke ; Shanmugham, Saravanan ; Corby = Anderson ;=20 Speechsc@ietf.org=20

Sent: = Sunday, June=20 12, 2005 1:41 AM

Subject: = RE:=20 [Speechsc] Managing big grammars

 

I = disagree. =20 Predictability is *very*=20 critical for an application using ASR.  It must be able to make = sure=20 that when a recognition operation is started, there is no latency = while the=20 ASR server compiles and/or loads a large precompiled grammar into = memory.=20  The DEFINE-GRAMMAR command is scoped to a channel, which means = by the=20 time the application has a channel (i.e. a caller is in the system), = it is=20 unacceptable to block for more than fraction of a second while the = grammars=20 are being compiled and/or loaded.  Otherwise, the first caller = after a=20 grammar is changed encounters delays and has a poor user experience = or even=20 hangs up.  Somebody may say: well, just make a =93priming=94 = call after=20 modifying the grammar to ensure the grammar is cached. =  However, that=20 is not very practical for automatically generated grammars; but = worse yet,=20 in large systems there are commonly several load-balanced ASR severs = and it=20 will be rather hard to ensure each of them is touched at least once. =  

 

The way = we solve=20 this on our platform is as follows: Large grammars that may change=20 frequently, possibly several times a day, such as company directory = grammars=20 that are generated from a database, can be registered as = =93preloaded=20 grammars=94.  This means, our platform ensures the grammar is = compiled,=20 distributed to all ASR servers, and loaded into their caches after a = new=20 version of that grammar has been generated.  Each preloaded = grammar has=20 a name associated, which is referenced through a special URI.  = The=20 application logic only knows that URI and not the actual = URI/filename of the=20 underlying grammar data.  The subsystem managing the preloaded = grammars=20 ensures that the preloaded grammar URI resolves to the previous = version of=20 the grammar until the new grammar is loaded and ready on all ASR = servers.=20  Thus, all callers that call into the system while the grammar = is being=20 generated, compiled, and loaded on the servers will get the previous = version.  This ensures that there is no delay for the first = caller=20 after a change.  We can do this as we are using the native APIs = provided by the ASR engine vendors we support and layer a = sophisticated=20 framework and API on top of it. 

 

It would = be nice if=20 MRCP provided some support for schemes like that, without having to = open=20 dummy channels to register grammars and pray the MRCP server = doesn=92t evict=20 them too early.  An MRCP client has to be able to guarantee = that when a=20 call comes through the system, everything is ready and it won=92t = experience=20 any delay.  As it stands now the MRCP protocol does not appear = to=20 provide support for this.

 

Thanks,

Felix

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave = Burke
Sent: Saturday, June 11, 2005 = 10:42
To: = Shanmugham,=20 Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big=20 grammars

 

I agree. Grammar = compilation,=20 caching, and sharing is a problem for the MRCP server. Exposing this = in the=20 protocol puts unnecessary complexity on the client. For example, the = client=20 needs to download grammars, implement its own HTTP caching, checksum = algorithms (some way of not having to push huge data to the MRCP = server to=20 query) etc.

 

So I vote for point 1 = below and=20 include in the text that an MRCP server could also, as an=20 optimisation, implement a centralised common cache shared = across=20 multiple MRCP servers.

 

Dave

----- Original = Message -----=20

From: Shanmugham,=20 Saravanan

To: Corby = Anderson ;=20 Speechsc@ietf.org=20

Sent:=20 Saturday, June 11, 2005 12:09 = AM

Subject: RE:=20 [Speechsc] Managing big = grammars

 

I would = say that=20 a common cache amoung a farm of MRCP servers to optimize = compilations=20 would be a nice server side optimization and shouldn't affect the = MRCP=20 protocol.

 

my=20 2c.

Sarvi

=

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_0C5F_01C57008.EB9E8150-- --===============0621510160== 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 --===============0621510160==-- From speechsc-bounces@ietf.org Tue Jun 14 02:58:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di5Nj-0001Xn-U8; Tue, 14 Jun 2005 02:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di5Nh-0001WW-A2 for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 02:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15468 for ; Tue, 14 Jun 2005 02:58:39 -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 1Di5k5-0007Ec-JK for speechsc@ietf.org; Tue, 14 Jun 2005 03:21:52 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 23:58:29 -0700 X-IronPort-AV: i="3.93,196,1115017200"; d="scan'208,217"; a="278381133:sNHT52213796" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5E6wQbw029286; Mon, 13 Jun 2005 23:58:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Managing big grammars Date: Mon, 13 Jun 2005 23:58:25 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05B9CD@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVvgraiCd4Ezv4hSiGMV8WwgSp5TQAWvX2A From: "Shanmugham, Saravanan" To: "Dave Burke" , "Wyss, Felix" , "Corby Anderson" , X-Spam-Score: 0.7 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f 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="===============0468054311==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0468054311== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570AE.76220A4C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C570AE.76220A4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I dont understand why the RUL has to encode and date and time into it. Lets say we are refering to large_grammar.grxml =20 When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. The MRCP server is expected to go download this URI and compile it. The caching behaviour of this URI and how long it lives in the cache is dependent on what is returned by the HTTP GET operation that brought the grammar into the MRCP server. In addition, the behaviour is also governed by Cache -Control parameters that the client can specify for the DEFINE-GRAMMAR that would take precedence over what was returned by the HTTP GET operation. This means that the MRCP client can force the MRCP server to ignore the cache parameters it got from the grammar webserver. =20 So, for the large_grammar.grxml, if the webserver returned a large max-age value the grammar and its compiled version in the cache of the MRCP server should not get timedout. For any future requests for that grammar, MRCP server should go do fetch of the document, compare the max-age of the fetched coument and make sure the webserver says that the document in the cache is not out-of-date. As long as the grammar document in the cache is not out of date, you don't need to compile it again and you are fine. If the propoerty of the large_grammar.grxml on the webserver had changed then the MRCP server would be expected to refresh the cache and compile the newly downloaded grammar. =20 =20 Am I missing something here. =20 Sarvi=20 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Sunday, June 12, 2005 12:12 PM To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =09 =09 There is no doubt that grammar compilation and loading must be hidden from the caller experience. What is in doubt is whether the MRCP protocol needs to expose such control.=20 =20 The grammar loading problem is not dissimilar to cache seeding in the Web world. Taking your use-case, I would implement this in MRCP as a two-step process: =20 (1) Make the large grammar available through HTTP and date-stamp the URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the HTTP response header Cache-Control: max-age to a value larger than the grammar change period. =20 (2) When a new grammar is required, open an MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. http://example.com/large_grammar_13June2005.grxml. Update the application to point at the new grammar. =20 [For a mid-size grammar where loading latency is negligible, and assuming a centrally located compiled grammar cache, step (2) might only require a DEFINE-GRAMMAR to one MRCP server]. =20 You are correct that the current MRCPv2 draft scopes the DEFINE-GRAMMAR to a channel and this is a concern. However, this is resolved with Sarvi's suggested text change. =20 Dave ----- Original Message -----=20 From: Wyss, Felix =20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars I disagree. Predictability is *very* critical for an application using ASR. It must be able to make sure that when a recognition operation is started, there is no latency while the ASR server compiles and/or loads a large precompiled grammar into memory. The DEFINE-GRAMMAR command is scoped to a channel, which means by the time the application has a channel (i.e. a caller is in the system), it is unacceptable to block for more than fraction of a second while the grammars are being compiled and/or loaded. Otherwise, the first caller after a grammar is changed encounters delays and has a poor user experience or even hangs up. Somebody may say: well, just make a "priming" call after modifying the grammar to ensure the grammar is cached. However, that is not very practical for automatically generated grammars; but worse yet, in large systems there are commonly several load-balanced ASR severs and it will be rather hard to ensure each of them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large grammars that may change frequently, possibly several times a day, such as company directory grammars that are generated from a database, can be registered as "preloaded grammars". This means, our platform ensures the grammar is compiled, distributed to all ASR servers, and loaded into their caches after a new version of that grammar has been generated. Each preloaded grammar has a name associated, which is referenced through a special URI. The application logic only knows that URI and not the actual URI/filename of the underlying grammar data. The subsystem managing the preloaded grammars ensures that the preloaded grammar URI resolves to the previous version of the grammar until the new grammar is loaded and ready on all ASR servers. Thus, all callers that call into the system while the grammar is being generated, compiled, and loaded on the servers will get the previous version. This ensures that there is no delay for the first caller after a change. We can do this as we are using the native APIs provided by the ASR engine vendors we support and layer a sophisticated framework and API on top of it. =20 =20 It would be nice if MRCP provided some support for schemes like that, without having to open dummy channels to register grammars and pray the MRCP server doesn't evict them too early. An MRCP client has to be able to guarantee that when a call comes through the system, everything is ready and it won't experience any delay. As it stands now the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 =09 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem for the MRCP server. Exposing this in the protocol puts unnecessary complexity on the client. For example, the client needs to download grammars, implement its own HTTP caching, checksum algorithms (some way of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP server could also, as an optimisation, implement a centralised common cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan =20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to optimize compilations would be a nice server side optimization and shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------_=_NextPart_001_01C570AE.76220A4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I dont understand why the RUL has to encode = and date=20 and time into it. Lets say we are refering to=20 large_grammar.grxml
 
When a client does a DEFINE-GRAMMAR on the = MRCP server=20 with this URI. The MRCP server is expected to go download this URI and = compile=20 it. The caching behaviour of this URI and how long it lives in the cache = is=20 dependent on what is returned by the HTTP GET operation that brought the = grammar=20 into the MRCP server. In addition, the behaviour is also governed by = Cache=20 -Control parameters that the client can specify for the DEFINE-GRAMMAR = that=20 would take precedence over what was returned by the HTTP GET operation. = This=20 means that the MRCP client can force the MRCP server to ignore the cache = parameters it got from the grammar webserver.
 
So, for the large_grammar.grxml, if the = webserver=20 returned a large max-age value the grammar and its compiled version in = the cache=20 of the MRCP server should not get timedout. For any future requests for = that=20 grammar, MRCP server should go do fetch of the document, compare the = max-age of=20 the fetched coument and make sure the webserver says that the document = in the=20 cache is not out-of-date. As long as the grammar document in the cache = is not=20 out of date, you don't need to compile it again and you are fine. If the = propoerty of the large_grammar.grxml on the webserver had changed then = the MRCP=20 server would be expected to refresh the cache and compile the newly = downloaded=20 grammar.
 
 
Am I missing something = here.
 
Sarvi 

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Sunday, June 12, 2005 12:12 PM
To: = Wyss,=20 Felix; Shanmugham, Saravanan; Corby Anderson;=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big=20 grammars

There is no doubt that grammar = compilation and=20 loading must be hidden from the caller experience. What is in doubt is whether the MRCP protocol needs to expose = such=20 control.
 
The grammar loading = problem is not=20 dissimilar to cache seeding in the Web world. Taking your use-case, I = would=20 implement this in MRCP as a two-step process:
 
(1) Make the large grammar available = through HTTP=20 and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml.=20 Set the HTTP response header Cache-Control: max-age to a value larger = than the=20 grammar change period.
 
(2) When a new grammar is required, = open an MRCP=20 channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR with the = relevant=20 URI e.g. http://example= .com/large_grammar_13June2005.grxml.=20 Update the application to point at the new grammar.
 
[For a mid-size grammar where loading = latency is=20 negligible, and assuming a centrally located compiled grammar cache, = step (2)=20 might only require a DEFINE-GRAMMAR to one MRCP server].
 
You are correct that the current = MRCPv2 draft=20 scopes the DEFINE-GRAMMAR to a channel and this is a = concern. However,=20 this is resolved with Sarvi's suggested text change.
 
Dave
----- Original Message -----
From:=20 Wyss, = Felix=20
To: Dave Burke ; Shanmugham,=20 Saravanan ; Corby Anderson ; Speechsc@ietf.org
Sent: Sunday, June 12, 2005 = 1:41=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I = disagree. =20 Predictability is *very*=20 critical for an application using ASR.  It must be able to make = sure=20 that when a recognition operation is started, there is no latency = while the=20 ASR server compiles and/or loads a large precompiled grammar into = memory.=20  The DEFINE-GRAMMAR command is scoped to a channel, which means = by the=20 time the application has a channel (i.e. a caller is in the system), = it is=20 unacceptable to block for more than fraction of a second while the = grammars=20 are being compiled and/or loaded.  Otherwise, the first caller = after a=20 grammar is changed encounters delays and has a poor user experience = or even=20 hangs up.  Somebody may say: well, just make a = “priming” call after=20 modifying the grammar to ensure the grammar is cached. =  However, that=20 is not very practical for automatically generated grammars; but = worse yet,=20 in large systems there are commonly several load-balanced ASR severs = and it=20 will be rather hard to ensure each of them is touched at least once. =  

 

The way = we solve=20 this on our platform is as follows: Large grammars that may change=20 frequently, possibly several times a day, such as company directory = grammars=20 that are generated from a database, can be registered as = “preloaded=20 grammars”.  This means, our platform ensures the grammar = is compiled,=20 distributed to all ASR servers, and loaded into their caches after a = new=20 version of that grammar has been generated.  Each preloaded = grammar has=20 a name associated, which is referenced through a special URI.  = The=20 application logic only knows that URI and not the actual = URI/filename of the=20 underlying grammar data.  The subsystem managing the preloaded = grammars=20 ensures that the preloaded grammar URI resolves to the previous = version of=20 the grammar until the new grammar is loaded and ready on all ASR = servers.=20  Thus, all callers that call into the system while the grammar = is being=20 generated, compiled, and loaded on the servers will get the previous = version.  This ensures that there is no delay for the first = caller=20 after a change.  We can do this as we are using the native APIs = provided by the ASR engine vendors we support and layer a = sophisticated=20 framework and API on top of it. 

 

It would = be nice if=20 MRCP provided some support for schemes like that, without having to = open=20 dummy channels to register grammars and pray the MRCP server = doesn’t evict=20 them too early.  An MRCP client has to be able to guarantee = that when a=20 call comes through the system, everything is ready and it = won’t experience=20 any delay.  As it stands now the MRCP protocol does not appear = to=20 provide support for this.

 

Thanks,

Felix

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave = Burke
Sent: Saturday, June 11, 2005 = 10:42
To: = Shanmugham,=20 Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big=20 grammars

 

I agree. Grammar = compilation,=20 caching, and sharing is a problem for the MRCP server. Exposing this = in the=20 protocol puts unnecessary complexity on the client. For example, the = client=20 needs to download grammars, implement its own HTTP caching, checksum = algorithms (some way of not having to push huge data to the MRCP = server to=20 query) etc.

 

So I vote for point 1 = below and=20 include in the text that an MRCP server could also, as an=20 optimisation, implement a centralised common cache shared = across=20 multiple MRCP servers.

 

Dave

----- Original = Message -----=20

From: Shanmugham,=20 Saravanan

To: Corby = Anderson ;=20 Speechsc@ietf.org=20

Sent:=20 Saturday, June 11, 2005 12:09 = AM

Subject: RE:=20 [Speechsc] Managing big = grammars

 

I would = say that=20 a common cache amoung a farm of MRCP servers to optimize = compilations=20 would be a nice server side optimization and shouldn't affect the = MRCP=20 protocol.

 

my=20 2c.

Sarvi

------_=_NextPart_001_01C570AE.76220A4C-- --===============0468054311== 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 --===============0468054311==-- From speechsc-bounces@ietf.org Tue Jun 14 06:16:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di8TR-0001Wx-Eg; Tue, 14 Jun 2005 06:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di8TP-0001Ws-Hb for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 06:16:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29970 for ; Tue, 14 Jun 2005 06:16:44 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di8pq-0007pC-5s for Speechsc@ietf.org; Tue, 14 Jun 2005 06:40:00 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 458052140ED; Tue, 14 Jun 2005 10:16:19 +0000 (GMT) Message-ID: <00d501c570ca$1b80ae90$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Wyss, Felix" , "Corby Anderson" , References: <03772D1EC8DE624A863058C75874A75C05B9CD@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 11:16:19 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: a8403cbbf1773e27474a13192645c46f 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="===============0816427797==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0816427797== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D2_01C570D2.7D250B70" This is a multi-part message in MIME format. ------=_NextPart_000_00D2_01C570D2.7D250B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's not that the URL needs a specific date or time, just that it has a = unique name. This is simply so that you can ensure the new grammar is = downloaded, compiled, and loaded ahead of any calls. Once compiled and = loaded, the application grammar URIs can be updated to reference the new = grammar. This way you avoid the danger that a bunch of calls, which = arrive at the same time as the DEFINE-GRAMMAR is happening, experience = delays. Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Tuesday, June 14, 2005 7:58 AM Subject: RE: [Speechsc] Managing big grammars I dont understand why the RUL has to encode and date and time into it. = Lets say we are refering to large_grammar.grxml When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. = The MRCP server is expected to go download this URI and compile it. The = caching behaviour of this URI and how long it lives in the cache is = dependent on what is returned by the HTTP GET operation that brought the = grammar into the MRCP server. In addition, the behaviour is also = governed by Cache -Control parameters that the client can specify for = the DEFINE-GRAMMAR that would take precedence over what was returned by = the HTTP GET operation. This means that the MRCP client can force the = MRCP server to ignore the cache parameters it got from the grammar = webserver. So, for the large_grammar.grxml, if the webserver returned a large = max-age value the grammar and its compiled version in the cache of the = MRCP server should not get timedout. For any future requests for that = grammar, MRCP server should go do fetch of the document, compare the = max-age of the fetched coument and make sure the webserver says that the = document in the cache is not out-of-date. As long as the grammar = document in the cache is not out of date, you don't need to compile it = again and you are fine. If the propoerty of the large_grammar.grxml on = the webserver had changed then the MRCP server would be expected to = refresh the cache and compile the newly downloaded grammar. Am I missing something here. Sarvi=20 -------------------------------------------------------------------------= --- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave Burke Sent: Sunday, June 12, 2005 12:12 PM To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; = Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars There is no doubt that grammar compilation and loading must be = hidden from the caller experience. What is in doubt is whether the MRCP = protocol needs to expose such control.=20 The grammar loading problem is not dissimilar to cache seeding in = the Web world. Taking your use-case, I would implement this in MRCP as a = two-step process: (1) Make the large grammar available through HTTP and date-stamp the = URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the = HTTP response header Cache-Control: max-age to a value larger than the = grammar change period. (2) When a new grammar is required, open an MRCP channel to each of = the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. = http://example.com/large_grammar_13June2005.grxml. Update the = application to point at the new grammar. [For a mid-size grammar where loading latency is negligible, and = assuming a centrally located compiled grammar cache, step (2) might only = require a DEFINE-GRAMMAR to one MRCP server]. You are correct that the current MRCPv2 draft scopes the = DEFINE-GRAMMAR to a channel and this is a concern. However, this is = resolved with Sarvi's suggested text change. Dave ----- Original Message -----=20 From: Wyss, Felix=20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; = Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars I disagree. Predictability is *very* critical for an application = using ASR. It must be able to make sure that when a recognition = operation is started, there is no latency while the ASR server compiles = and/or loads a large precompiled grammar into memory. The = DEFINE-GRAMMAR command is scoped to a channel, which means by the time = the application has a channel (i.e. a caller is in the system), it is = unacceptable to block for more than fraction of a second while the = grammars are being compiled and/or loaded. Otherwise, the first caller = after a grammar is changed encounters delays and has a poor user = experience or even hangs up. Somebody may say: well, just make a = "priming" call after modifying the grammar to ensure the grammar is = cached. However, that is not very practical for automatically generated = grammars; but worse yet, in large systems there are commonly several = load-balanced ASR severs and it will be rather hard to ensure each of = them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large = grammars that may change frequently, possibly several times a day, such = as company directory grammars that are generated from a database, can be = registered as "preloaded grammars". This means, our platform ensures = the grammar is compiled, distributed to all ASR servers, and loaded into = their caches after a new version of that grammar has been generated. = Each preloaded grammar has a name associated, which is referenced = through a special URI. The application logic only knows that URI and = not the actual URI/filename of the underlying grammar data. The = subsystem managing the preloaded grammars ensures that the preloaded = grammar URI resolves to the previous version of the grammar until the = new grammar is loaded and ready on all ASR servers. Thus, all callers = that call into the system while the grammar is being generated, = compiled, and loaded on the servers will get the previous version. This = ensures that there is no delay for the first caller after a change. We = can do this as we are using the native APIs provided by the ASR engine = vendors we support and layer a sophisticated framework and API on top of = it. =20 =20 It would be nice if MRCP provided some support for schemes like = that, without having to open dummy channels to register grammars and = pray the MRCP server doesn't evict them too early. An MRCP client has = to be able to guarantee that when a call comes through the system, = everything is ready and it won't experience any delay. As it stands now = the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 -------------------------------------------------------------------------= - From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem = for the MRCP server. Exposing this in the protocol puts unnecessary = complexity on the client. For example, the client needs to download = grammars, implement its own HTTP caching, checksum algorithms (some way = of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP = server could also, as an optimisation, implement a centralised common = cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to = optimize compilations would be a nice server side optimization and = shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------=_NextPart_000_00D2_01C570D2.7D250B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It's not that the URL needs a specific = date or=20 time, just that it has a unique name. This is simply so that you can = ensure the=20 new grammar is downloaded, compiled, and loaded ahead of any calls. Once = compiled and loaded, the application grammar URIs can be updated to = reference=20 the new grammar. This way you avoid the danger that a bunch of calls, = which=20 arrive at the same time as the DEFINE-GRAMMAR is happening, experience=20 delays.
 
Dave
----- Original Message -----
From:=20 Shanmugham, = Saravanan
To: Dave Burke ; Wyss, = Felix ; Corby = Anderson ; Speechsc@ietf.org=20
Sent: Tuesday, June 14, 2005 = 7:58=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I dont understand why the RUL has to encode = and date=20 and time into it. Lets say we are refering to=20 large_grammar.grxml
 
When a client does a DEFINE-GRAMMAR on the = MRCP=20 server with this URI. The MRCP server is expected to go download this = URI and=20 compile it. The caching behaviour of this URI and how long it lives in = the=20 cache is dependent on what is returned by the HTTP GET operation that = brought=20 the grammar into the MRCP server. In addition, the behaviour is also = governed=20 by Cache -Control parameters that the client can specify for the=20 DEFINE-GRAMMAR that would take precedence over what was returned by = the HTTP=20 GET operation. This means that the MRCP client can force the MRCP = server to=20 ignore the cache parameters it got from the grammar=20 webserver.
 
So, for the large_grammar.grxml, if the = webserver=20 returned a large max-age value the grammar and its compiled version in = the=20 cache of the MRCP server should not get timedout. For any future = requests for=20 that grammar, MRCP server should go do fetch of the document, compare = the=20 max-age of the fetched coument and make sure the webserver says that = the=20 document in the cache is not out-of-date. As long as the grammar = document in=20 the cache is not out of date, you don't need to compile it again and = you are=20 fine. If the propoerty of the large_grammar.grxml on the webserver had = changed=20 then the MRCP server would be expected to refresh the cache and = compile the=20 newly downloaded grammar.
 
 
Am I missing something = here.
 
Sarvi 

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Sunday, June 12, 2005 12:12 PM
To: = Wyss,=20 Felix; Shanmugham, Saravanan; Corby Anderson;=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big=20 grammars

There is no doubt that grammar = compilation and=20 loading must be hidden from the caller experience. What is in doubt is whether the MRCP protocol needs to = expose such=20 control.
 
The grammar loading = problem is not=20 dissimilar to cache seeding in the Web world. Taking your use-case, = I would=20 implement this in MRCP as a two-step process:
 
(1) Make the large grammar = available through=20 HTTP and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml.=20 Set the HTTP response header Cache-Control: max-age to a value = larger than=20 the grammar change period.
 
(2) When a new grammar is required, = open an=20 MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR = with the=20 relevant URI e.g. http://example= .com/large_grammar_13June2005.grxml.=20 Update the application to point at the new grammar.
 
[For a mid-size grammar where = loading latency=20 is negligible, and assuming a centrally located compiled grammar = cache, step=20 (2) might only require a DEFINE-GRAMMAR to one MRCP = server].
 
You are correct that the current = MRCPv2 draft=20 scopes the DEFINE-GRAMMAR to a channel and this is a = concern. However,=20 this is resolved with Sarvi's suggested text change.
 
Dave
----- Original Message ----- =
From:=20 Wyss, = Felix=20
To: Dave Burke ; Shanmugham,=20 Saravanan ; Corby Anderson ; Speechsc@ietf.org
Sent: Sunday, June 12, 2005 = 1:41=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I = disagree. =20 Predictability is *very*=20 critical for an application using ASR.  It must be able to = make sure=20 that when a recognition operation is started, there is no latency = while=20 the ASR server compiles and/or loads a large precompiled grammar = into=20 memory.  The DEFINE-GRAMMAR command is scoped to a channel, = which=20 means by the time the application has a channel (i.e. a caller is = in the=20 system), it is unacceptable to block for more than fraction of a = second=20 while the grammars are being compiled and/or loaded. =  Otherwise, the=20 first caller after a grammar is changed encounters delays and has = a poor=20 user experience or even hangs up.  Somebody may say: well, = just make=20 a =93priming=94 call after modifying the grammar to ensure the = grammar is=20 cached.  However, that is not very practical for = automatically=20 generated grammars; but worse yet, in large systems there are = commonly=20 several load-balanced ASR severs and it will be rather hard to = ensure each=20 of them is touched at least once. =  

 

The way = we solve=20 this on our platform is as follows: Large grammars that may change = frequently, possibly several times a day, such as company = directory=20 grammars that are generated from a database, can be registered as=20 =93preloaded grammars=94.  This means, our platform ensures = the grammar=20 is compiled, distributed to all ASR servers, and loaded into their = caches=20 after a new version of that grammar has been generated.  Each = preloaded grammar has a name associated, which is referenced = through a=20 special URI.  The application logic only knows that URI and = not the=20 actual URI/filename of the underlying grammar data.  The = subsystem=20 managing the preloaded grammars ensures that the preloaded grammar = URI=20 resolves to the previous version of the grammar until the new = grammar is=20 loaded and ready on all ASR servers.  Thus, all callers that = call=20 into the system while the grammar is being generated, compiled, = and loaded=20 on the servers will get the previous version.  This ensures = that=20 there is no delay for the first caller after a change.  We = can do=20 this as we are using the native APIs provided by the ASR engine = vendors we=20 support and layer a sophisticated framework and API on top of = it. =20

 

It = would be nice=20 if MRCP provided some support for schemes like that, without = having to=20 open dummy channels to register grammars and pray the MRCP server = doesn=92t=20 evict them too early.  An MRCP client has to be able to = guarantee=20 that when a call comes through the system, everything is ready and = it=20 won=92t experience any delay.  As it stands now the MRCP = protocol does=20 not appear to provide support for = this.

 

Thanks,

Felix

 

From: = speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave = Burke
Sent: Saturday, June 11, = 2005=20 10:42
To: = Shanmugham,=20 Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big=20 grammars

 

I agree. Grammar = compilation,=20 caching, and sharing is a problem for the MRCP server. Exposing = this in=20 the protocol puts unnecessary complexity on the client. For = example, the=20 client needs to download grammars, implement its own HTTP caching, = checksum algorithms (some way of not having to push huge data to = the MRCP=20 server to query) etc.

 

So I vote for point = 1 below=20 and include in the text that an MRCP server could also, as an = optimisation, implement a centralised common cache shared = across=20 multiple MRCP servers.

 

Dave

----- Original = Message -----=20

From: Shanmugham,=20 Saravanan

To: Corby = Anderson=20 ; Speechsc@ietf.org=20

Sent:=20 Saturday, June 11, 2005 12:09 = AM

Subject: RE:=20 [Speechsc] Managing big = grammars

 

I = would say=20 that a common cache amoung a farm of MRCP servers to optimize=20 compilations would be a nice server side optimization and = shouldn't=20 affect the MRCP protocol.

 

my=20 2c.

Sarvi

------=_NextPart_000_00D2_01C570D2.7D250B70-- --===============0816427797== 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 --===============0816427797==-- From speechsc-bounces@ietf.org Tue Jun 14 07:04:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9Dh-0000ZX-SY; Tue, 14 Jun 2005 07:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9Dg-0000ZS-0v for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 07:04:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03166 for ; Tue, 14 Jun 2005 07:04:33 -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 1Di9a8-0001OM-Gx for speechsc@ietf.org; Tue, 14 Jun 2005 07:27:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 04:04:25 -0700 X-IronPort-AV: i="3.93,197,1115017200"; d="scan'208,217"; a="278445357:sNHT54896786" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5EB4Nlq002062; Tue, 14 Jun 2005 04:04:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 04:04:21 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05B9D8@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVwyiiJx1PrUzv3QmuZXT8M7ld+iQABdsYw From: "Shanmugham, Saravanan" To: "Dave Burke" , "Wyss, Felix" , "Corby Anderson" , X-Spam-Score: 0.7 (/) X-Scan-Signature: 142968907492cd6b805bce4edf0aec7b 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="===============2138994288==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============2138994288== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570D0.D21D74B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C570D0.D21D74B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable cool. That makes sense. The way I though this problem would have been addressed, is the MRCP caching system to be smart. That is everytime there is a request a grammar for a grammar URI. the MRCP server would do a fetch to check if the document has changed. If it has, then it would download and compile the grammar. While this happenning existing calls that were using the older compiled grammar continue to use it. Once this is ready, the previous version of the grammar is allowed to expire-out. =20 Would this not address your scenario and avoid having to do this work around you are suggesting? =20 Sarvi=20 ________________________________ From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, June 14, 2005 3:16 AM To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =09 =09 It's not that the URL needs a specific date or time, just that it has a unique name. This is simply so that you can ensure the new grammar is downloaded, compiled, and loaded ahead of any calls. Once compiled and loaded, the application grammar URIs can be updated to reference the new grammar. This way you avoid the danger that a bunch of calls, which arrive at the same time as the DEFINE-GRAMMAR is happening, experience delays. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan =20 To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Tuesday, June 14, 2005 7:58 AM Subject: RE: [Speechsc] Managing big grammars I dont understand why the RUL has to encode and date and time into it. Lets say we are refering to large_grammar.grxml =20 When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. The MRCP server is expected to go download this URI and compile it. The caching behaviour of this URI and how long it lives in the cache is dependent on what is returned by the HTTP GET operation that brought the grammar into the MRCP server. In addition, the behaviour is also governed by Cache -Control parameters that the client can specify for the DEFINE-GRAMMAR that would take precedence over what was returned by the HTTP GET operation. This means that the MRCP client can force the MRCP server to ignore the cache parameters it got from the grammar webserver. =20 So, for the large_grammar.grxml, if the webserver returned a large max-age value the grammar and its compiled version in the cache of the MRCP server should not get timedout. For any future requests for that grammar, MRCP server should go do fetch of the document, compare the max-age of the fetched coument and make sure the webserver says that the document in the cache is not out-of-date. As long as the grammar document in the cache is not out of date, you don't need to compile it again and you are fine. If the propoerty of the large_grammar.grxml on the webserver had changed then the MRCP server would be expected to refresh the cache and compile the newly downloaded grammar. =20 =20 Am I missing something here. =20 Sarvi=20 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Sunday, June 12, 2005 12:12 PM To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =09 =09 There is no doubt that grammar compilation and loading must be hidden from the caller experience. What is in doubt is whether the MRCP protocol needs to expose such control.=20 =20 The grammar loading problem is not dissimilar to cache seeding in the Web world. Taking your use-case, I would implement this in MRCP as a two-step process: =20 (1) Make the large grammar available through HTTP and date-stamp the URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the HTTP response header Cache-Control: max-age to a value larger than the grammar change period. =20 (2) When a new grammar is required, open an MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. http://example.com/large_grammar_13June2005.grxml. Update the application to point at the new grammar. =20 [For a mid-size grammar where loading latency is negligible, and assuming a centrally located compiled grammar cache, step (2) might only require a DEFINE-GRAMMAR to one MRCP server]. =20 You are correct that the current MRCPv2 draft scopes the DEFINE-GRAMMAR to a channel and this is a concern. However, this is resolved with Sarvi's suggested text change. =20 Dave ----- Original Message -----=20 From: Wyss, Felix =20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars I disagree. Predictability is *very* critical for an application using ASR. It must be able to make sure that when a recognition operation is started, there is no latency while the ASR server compiles and/or loads a large precompiled grammar into memory. The DEFINE-GRAMMAR command is scoped to a channel, which means by the time the application has a channel (i.e. a caller is in the system), it is unacceptable to block for more than fraction of a second while the grammars are being compiled and/or loaded. Otherwise, the first caller after a grammar is changed encounters delays and has a poor user experience or even hangs up. Somebody may say: well, just make a "priming" call after modifying the grammar to ensure the grammar is cached. However, that is not very practical for automatically generated grammars; but worse yet, in large systems there are commonly several load-balanced ASR severs and it will be rather hard to ensure each of them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large grammars that may change frequently, possibly several times a day, such as company directory grammars that are generated from a database, can be registered as "preloaded grammars". This means, our platform ensures the grammar is compiled, distributed to all ASR servers, and loaded into their caches after a new version of that grammar has been generated. Each preloaded grammar has a name associated, which is referenced through a special URI. The application logic only knows that URI and not the actual URI/filename of the underlying grammar data. The subsystem managing the preloaded grammars ensures that the preloaded grammar URI resolves to the previous version of the grammar until the new grammar is loaded and ready on all ASR servers. Thus, all callers that call into the system while the grammar is being generated, compiled, and loaded on the servers will get the previous version. This ensures that there is no delay for the first caller after a change. We can do this as we are using the native APIs provided by the ASR engine vendors we support and layer a sophisticated framework and API on top of it. =20 =20 It would be nice if MRCP provided some support for schemes like that, without having to open dummy channels to register grammars and pray the MRCP server doesn't evict them too early. An MRCP client has to be able to guarantee that when a call comes through the system, everything is ready and it won't experience any delay. As it stands now the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 =09 ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a problem for the MRCP server. Exposing this in the protocol puts unnecessary complexity on the client. For example, the client needs to download grammars, implement its own HTTP caching, checksum algorithms (some way of not having to push huge data to the MRCP server to query) etc. =20 So I vote for point 1 below and include in the text that an MRCP server could also, as an optimisation, implement a centralised common cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan =20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP servers to optimize compilations would be a nice server side optimization and shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------_=_NextPart_001_01C570D0.D21D74B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
cool. That makes sense.
The way I though this problem would have been = addressed, is=20 the MRCP caching system to be smart.
That is everytime there is a request a grammar = for a=20 grammar URI. the MRCP server would do a fetch to check if the document = has=20 changed. If it has, then it would download and compile the = grammar.=20 While this happenning existing calls that were using the older = compiled grammar continue to use it. Once this is ready, the=20 previous version of the grammar is allowed=20 to expire-out.
 
Would this not address your scenario and avoid = having to do=20 this work around you are suggesting?
 
Sarvi 

From: Dave Burke=20 [mailto:david.burke@voxpilot.com]
Sent: Tuesday, June 14, = 2005 3:16=20 AM
To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson;=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big=20 grammars

It's not that the URL needs a = specific date or=20 time, just that it has a unique name. This is simply so that you can = ensure=20 the new grammar is downloaded, compiled, and loaded ahead of any = calls. Once=20 compiled and loaded, the application grammar URIs can be updated to = reference=20 the new grammar. This way you avoid the danger that a bunch of calls, = which=20 arrive at the same time as the DEFINE-GRAMMAR is happening, experience = delays.
 
Dave
----- Original Message -----
From:=20 Shanmugham,=20 Saravanan
To: Dave Burke ; Wyss, = Felix ; Corby = Anderson ;=20 Speechsc@ietf.org
Sent: Tuesday, June 14, 2005 = 7:58=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I dont understand why the RUL has to = encode and=20 date and time into it. Lets say we are refering to=20 large_grammar.grxml
 
When a client does a DEFINE-GRAMMAR on = the MRCP=20 server with this URI. The MRCP server is expected to go download = this URI=20 and compile it. The caching behaviour of this URI and how long it = lives in=20 the cache is dependent on what is returned by the HTTP GET operation = that=20 brought the grammar into the MRCP server. In addition, the behaviour = is also=20 governed by Cache -Control parameters that the client can specify = for the=20 DEFINE-GRAMMAR that would take precedence over what was returned by = the HTTP=20 GET operation. This means that the MRCP client can force the MRCP = server to=20 ignore the cache parameters it got from the grammar=20 webserver.
 
So, for the large_grammar.grxml, if the = webserver=20 returned a large max-age value the grammar and its compiled version = in the=20 cache of the MRCP server should not get timedout. For any future = requests=20 for that grammar, MRCP server should go do fetch of the document, = compare=20 the max-age of the fetched coument and make sure the webserver says = that the=20 document in the cache is not out-of-date. As long as the grammar = document in=20 the cache is not out of date, you don't need to compile it again and = you are=20 fine. If the propoerty of the large_grammar.grxml on the webserver = had=20 changed then the MRCP server would be expected to refresh the cache = and=20 compile the newly downloaded grammar.
 
 
Am I missing something = here.
 
Sarvi 

From: = speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Sunday, June 12, 2005 12:12 PM
To: = Wyss,=20 Felix; Shanmugham, Saravanan; Corby Anderson;=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big=20 grammars

There is no doubt that grammar = compilation=20 and loading must be hidden from the caller experience. = What is in doubt is whether the MRCP = protocol needs to=20 expose such control.
 
The grammar loading = problem is not=20 dissimilar to cache seeding in the Web world. Taking your = use-case, I=20 would implement this in MRCP as a two-step process:
 
(1) Make the large grammar = available through=20 HTTP and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml.=20 Set the HTTP response header Cache-Control: max-age to a value = larger than=20 the grammar change period.
 
(2) When a new grammar is = required, open an=20 MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR = with the=20 relevant URI e.g. http://example= .com/large_grammar_13June2005.grxml.=20 Update the application to point at the new grammar.
 
[For a mid-size grammar where = loading latency=20 is negligible, and assuming a centrally located compiled grammar = cache,=20 step (2) might only require a DEFINE-GRAMMAR to one MRCP=20 server].
 
You are correct that the current = MRCPv2 draft=20 scopes the DEFINE-GRAMMAR to a channel and this is a=20 concern. However, this is resolved with Sarvi's suggested = text=20 change.
 
Dave
----- Original Message ----- =
From:=20 Wyss, = Felix=20
To: Dave Burke ; Shanmugham,=20 Saravanan ; Corby Anderson ; Speechsc@ietf.org
Sent: Sunday, June 12, = 2005 1:41=20 AM
Subject: RE: [Speechsc] = Managing=20 big grammars

I=20 disagree.  Predictability is *very* critical for an = application=20 using ASR.  It must be able to make sure that when a = recognition=20 operation is started, there is no latency while the ASR server = compiles=20 and/or loads a large precompiled grammar into memory.  The=20 DEFINE-GRAMMAR command is scoped to a channel, which means by = the time=20 the application has a channel (i.e. a caller is in the system), = it is=20 unacceptable to block for more than fraction of a second while = the=20 grammars are being compiled and/or loaded.  Otherwise, the = first=20 caller after a grammar is changed encounters delays and has a = poor user=20 experience or even hangs up.  Somebody may say: well, just = make a=20 “priming” call after modifying the grammar to ensure = the grammar is=20 cached.  However, that is not very practical for = automatically=20 generated grammars; but worse yet, in large systems there are = commonly=20 several load-balanced ASR severs and it will be rather hard to = ensure=20 each of them is touched at least once.=20  

 

The = way we=20 solve this on our platform is as follows: Large grammars that = may change=20 frequently, possibly several times a day, such as company = directory=20 grammars that are generated from a database, can be registered = as=20 “preloaded grammars”.  This means, our platform = ensures the grammar=20 is compiled, distributed to all ASR servers, and loaded into = their=20 caches after a new version of that grammar has been = generated. =20 Each preloaded grammar has a name associated, which is = referenced=20 through a special URI.  The application logic only knows = that URI=20 and not the actual URI/filename of the underlying grammar data.=20  The subsystem managing the preloaded grammars ensures that = the=20 preloaded grammar URI resolves to the previous version of the = grammar=20 until the new grammar is loaded and ready on all ASR servers.=20  Thus, all callers that call into the system while the = grammar is=20 being generated, compiled, and loaded on the servers will get = the=20 previous version.  This ensures that there is no delay for = the=20 first caller after a change.  We can do this as we are = using the=20 native APIs provided by the ASR engine vendors we support and = layer a=20 sophisticated framework and API on top of it. =20

 

It = would be=20 nice if MRCP provided some support for schemes like that, = without having=20 to open dummy channels to register grammars and pray the MRCP = server=20 doesn’t evict them too early.  An MRCP client has to = be able to=20 guarantee that when a call comes through the system, everything = is ready=20 and it won’t experience any delay.  As it stands now = the MRCP=20 protocol does not appear to provide support for=20 this.

 

Thanks,

Felix

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave = Burke
Sent: Saturday, June 11, = 2005=20 10:42
To: = Shanmugham,=20 Saravanan; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing=20 big grammars

 

I agree. Grammar=20 compilation, caching, and sharing is a problem for the MRCP = server.=20 Exposing this in the protocol puts unnecessary complexity on the = client.=20 For example, the client needs to download grammars, implement = its own=20 HTTP caching, checksum algorithms (some way of not having to = push huge=20 data to the MRCP server to query)=20 etc.

 

So I vote for = point 1 below=20 and include in the text that an MRCP server could also, as = an=20 optimisation, implement a centralised common cache shared = across=20 multiple MRCP servers.

 

Dave

----- Original = Message=20 -----

Sent:=20 Saturday, June 11, 2005 12:09 = AM

Subject:=20 RE: [Speechsc] Managing big=20 grammars

 

I = would say=20 that a common cache amoung a farm of MRCP servers to optimize=20 compilations would be a nice server side optimization and = shouldn't=20 affect the MRCP protocol.

 

my=20 2c.

Sarvi

------_=_NextPart_001_01C570D0.D21D74B8-- --===============2138994288== 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 --===============2138994288==-- From speechsc-bounces@ietf.org Tue Jun 14 08:16:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiALZ-0004G1-Fs; Tue, 14 Jun 2005 08:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiALX-0004Fw-Iy for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 08:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08393 for ; Tue, 14 Jun 2005 08:16:46 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiAhy-0004ie-Eh for Speechsc@ietf.org; Tue, 14 Jun 2005 08:40:01 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 81253214042; Tue, 14 Jun 2005 12:16:25 +0000 (GMT) Message-ID: <015c01c570da$dfdc5ef0$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "Wyss, Felix" , "Corby Anderson" , References: <03772D1EC8DE624A863058C75874A75C05B9D8@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 13:16:20 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 40dcdfec62eed13950fa8e354a820e1d 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="===============0449043488==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0449043488== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0159_01C570E3.418CF0D0" This is a multi-part message in MIME format. ------=_NextPart_000_0159_01C570E3.418CF0D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That optimisation would be nice alright and is not restricted by HTTP = (see note from RFC 2616 below).=20 It seems like we have got some good optimisation suggestions (read: = informative) that could go into the spec to address large grammars. If = memory serves, they are: 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or = RECOGNIZE to be used over multiple MRCP sessions 2. An MRCP server may cache the compiled version of a grammar 3. An MRCP server may cache grammars centrally to allow other = servers take advantage of the cache 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform other = MRCP servers to reload the new grammar into memory 5. An MRCP server may choose to return a stale response while a new = grammar is being downloaded, compiled, and cached -- Dave >From RFC 2616: In some cases, the operator of a cache MAY choose to configure it to return stale responses even when not requested by clients. This decision ought not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header) enabling the client software to alert the user that there might be a potential problem. ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Tuesday, June 14, 2005 12:04 PM Subject: RE: [Speechsc] Managing big grammars cool. That makes sense. The way I though this problem would have been addressed, is the MRCP = caching system to be smart. That is everytime there is a request a grammar for a grammar URI. the = MRCP server would do a fetch to check if the document has changed. If it = has, then it would download and compile the grammar. While this = happenning existing calls that were using the older compiled grammar = continue to use it. Once this is ready, the previous version of the = grammar is allowed to expire-out. Would this not address your scenario and avoid having to do this work = around you are suggesting? Sarvi=20 -------------------------------------------------------------------------= --- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, June 14, 2005 3:16 AM To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; = Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars It's not that the URL needs a specific date or time, just that it = has a unique name. This is simply so that you can ensure the new grammar = is downloaded, compiled, and loaded ahead of any calls. Once compiled = and loaded, the application grammar URIs can be updated to reference the = new grammar. This way you avoid the danger that a bunch of calls, which = arrive at the same time as the DEFINE-GRAMMAR is happening, experience = delays. Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org=20 Sent: Tuesday, June 14, 2005 7:58 AM Subject: RE: [Speechsc] Managing big grammars I dont understand why the RUL has to encode and date and time into = it. Lets say we are refering to large_grammar.grxml When a client does a DEFINE-GRAMMAR on the MRCP server with this = URI. The MRCP server is expected to go download this URI and compile it. = The caching behaviour of this URI and how long it lives in the cache is = dependent on what is returned by the HTTP GET operation that brought the = grammar into the MRCP server. In addition, the behaviour is also = governed by Cache -Control parameters that the client can specify for = the DEFINE-GRAMMAR that would take precedence over what was returned by = the HTTP GET operation. This means that the MRCP client can force the = MRCP server to ignore the cache parameters it got from the grammar = webserver. So, for the large_grammar.grxml, if the webserver returned a large = max-age value the grammar and its compiled version in the cache of the = MRCP server should not get timedout. For any future requests for that = grammar, MRCP server should go do fetch of the document, compare the = max-age of the fetched coument and make sure the webserver says that the = document in the cache is not out-of-date. As long as the grammar = document in the cache is not out of date, you don't need to compile it = again and you are fine. If the propoerty of the large_grammar.grxml on = the webserver had changed then the MRCP server would be expected to = refresh the cache and compile the newly downloaded grammar. Am I missing something here. Sarvi=20 ------------------------------------------------------------------------ From: speechsc-bounces@ietf.org = [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Sunday, June 12, 2005 12:12 PM To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; = Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars There is no doubt that grammar compilation and loading must be = hidden from the caller experience. What is in doubt is whether the MRCP = protocol needs to expose such control.=20 The grammar loading problem is not dissimilar to cache seeding = in the Web world. Taking your use-case, I would implement this in MRCP = as a two-step process: (1) Make the large grammar available through HTTP and date-stamp = the URI, e.g. http://example.com/large_grammar_12June2005.grxml. Set the = HTTP response header Cache-Control: max-age to a value larger than the = grammar change period. (2) When a new grammar is required, open an MRCP channel to each = of the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. = http://example.com/large_grammar_13June2005.grxml. Update the = application to point at the new grammar. [For a mid-size grammar where loading latency is negligible, and = assuming a centrally located compiled grammar cache, step (2) might only = require a DEFINE-GRAMMAR to one MRCP server]. You are correct that the current MRCPv2 draft scopes the = DEFINE-GRAMMAR to a channel and this is a concern. However, this is = resolved with Sarvi's suggested text change. Dave ----- Original Message -----=20 From: Wyss, Felix=20 To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; = Speechsc@ietf.org=20 Sent: Sunday, June 12, 2005 1:41 AM Subject: RE: [Speechsc] Managing big grammars I disagree. Predictability is *very* critical for an = application using ASR. It must be able to make sure that when a = recognition operation is started, there is no latency while the ASR = server compiles and/or loads a large precompiled grammar into memory. = The DEFINE-GRAMMAR command is scoped to a channel, which means by the = time the application has a channel (i.e. a caller is in the system), it = is unacceptable to block for more than fraction of a second while the = grammars are being compiled and/or loaded. Otherwise, the first caller = after a grammar is changed encounters delays and has a poor user = experience or even hangs up. Somebody may say: well, just make a = "priming" call after modifying the grammar to ensure the grammar is = cached. However, that is not very practical for automatically generated = grammars; but worse yet, in large systems there are commonly several = load-balanced ASR severs and it will be rather hard to ensure each of = them is touched at least once. =20 =20 The way we solve this on our platform is as follows: Large = grammars that may change frequently, possibly several times a day, such = as company directory grammars that are generated from a database, can be = registered as "preloaded grammars". This means, our platform ensures = the grammar is compiled, distributed to all ASR servers, and loaded into = their caches after a new version of that grammar has been generated. = Each preloaded grammar has a name associated, which is referenced = through a special URI. The application logic only knows that URI and = not the actual URI/filename of the underlying grammar data. The = subsystem managing the preloaded grammars ensures that the preloaded = grammar URI resolves to the previous version of the grammar until the = new grammar is loaded and ready on all ASR servers. Thus, all callers = that call into the system while the grammar is being generated, = compiled, and loaded on the servers will get the previous version. This = ensures that there is no delay for the first caller after a change. We = can do this as we are using the native APIs provided by the ASR engine = vendors we support and layer a sophisticated framework and API on top of = it. =20 =20 It would be nice if MRCP provided some support for schemes = like that, without having to open dummy channels to register grammars = and pray the MRCP server doesn't evict them too early. An MRCP client = has to be able to guarantee that when a call comes through the system, = everything is ready and it won't experience any delay. As it stands now = the MRCP protocol does not appear to provide support for this. =20 Thanks, Felix =20 ---------------------------------------------------------------------- From: speechsc-bounces@ietf.org = [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Saturday, June 11, 2005 10:42 To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 I agree. Grammar compilation, caching, and sharing is a = problem for the MRCP server. Exposing this in the protocol puts = unnecessary complexity on the client. For example, the client needs to = download grammars, implement its own HTTP caching, checksum algorithms = (some way of not having to push huge data to the MRCP server to query) = etc. =20 So I vote for point 1 below and include in the text that an = MRCP server could also, as an optimisation, implement a centralised = common cache shared across multiple MRCP servers. =20 Dave ----- Original Message -----=20 From: Shanmugham, Saravanan=20 To: Corby Anderson ; Speechsc@ietf.org=20 Sent: Saturday, June 11, 2005 12:09 AM Subject: RE: [Speechsc] Managing big grammars =20 I would say that a common cache amoung a farm of MRCP = servers to optimize compilations would be a nice server side = optimization and shouldn't affect the MRCP protocol. =20 my 2c. Sarvi ------=_NextPart_000_0159_01C570E3.418CF0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That optimisation would be nice alright = and is not=20 restricted by HTTP (see note from RFC 2616 below).
 
It seems like we have got some good = optimisation=20 suggestions (read: informative) that could go into the spec to = address=20 large grammars. If memory serves, = they=20 are:
    1. An MRCP = server may cache=20 grammars used in DEFINE-GRAMMAR or RECOGNIZE to be used over multiple = MRCP=20 sessions
    2. An MRCP server = may cache the=20 compiled version of a grammar
    3. An MRCP = server may cache=20 grammars centrally to allow other servers take advantage of the=20 cache
    4. An MRCP server, = in response=20 to a DEFINE-GRAMMAR, may inform other MRCP servers to reload the new = grammar=20 into memory
    5. An MRCP = server may=20 choose to return a stale response while a new grammar is being = downloaded,=20 compiled, and cached
 
-- Dave
 
From RFC 2616:
 
   In some cases, the = operator of a cache=20 MAY choose to configure it to
   return stale responses = even when=20 not requested by clients. This
   decision ought not be = made=20 lightly, but may be necessary for reasons
   of = availability or=20 performance, especially when the cache is poorly
   = connected to=20 the origin server. Whenever a cache returns a stale
   = response, it=20 MUST mark it as such (using a Warning header) enabling
   = the=20 client software to alert the user that there might be a=20 potential
   problem.
 
 
----- Original Message -----
From:=20 Shanmugham, = Saravanan
To: Dave Burke ; Wyss, = Felix ; Corby = Anderson ; Speechsc@ietf.org=20
Sent: Tuesday, June 14, 2005 = 12:04=20 PM
Subject: RE: [Speechsc] = Managing big=20 grammars

cool. That makes sense.
The way I though this problem would have been = addressed,=20 is the MRCP caching system to be smart.
That is everytime there is a request a = grammar for a=20 grammar URI. the MRCP server would do a fetch to check if the document = has=20 changed. If it has, then it would download and compile the = grammar.=20 While this happenning existing calls that were using the = older=20 compiled grammar continue to use it. Once this is ready, the=20 previous version of the grammar is allowed=20 to expire-out.
 
Would this not address your scenario and = avoid having to=20 do this work around you are suggesting?
 
Sarvi 

From: Dave Burke=20 [mailto:david.burke@voxpilot.com]
Sent: Tuesday, June 14, = 2005=20 3:16 AM
To: Shanmugham, Saravanan; Wyss, Felix; Corby = Anderson;=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big=20 grammars

It's not that the URL needs a = specific date or=20 time, just that it has a unique name. This is simply so that you can = ensure=20 the new grammar is downloaded, compiled, and loaded ahead of any = calls. Once=20 compiled and loaded, the application grammar URIs can be updated to=20 reference the new grammar. This way you avoid the danger that a = bunch of=20 calls, which arrive at the same time as the DEFINE-GRAMMAR is = happening,=20 experience delays.
 
Dave
----- Original Message ----- =
From:=20 Shanmugham,=20 Saravanan
To: Dave Burke ; Wyss, = Felix ; Corby = Anderson ;=20 Speechsc@ietf.org
Sent: Tuesday, June 14, = 2005 7:58=20 AM
Subject: RE: [Speechsc] = Managing big=20 grammars

I dont understand why the RUL has to = encode and=20 date and time into it. Lets say we are refering to=20 large_grammar.grxml
 
When a client does a DEFINE-GRAMMAR on = the MRCP=20 server with this URI. The MRCP server is expected to go download = this URI=20 and compile it. The caching behaviour of this URI and how long it = lives in=20 the cache is dependent on what is returned by the HTTP GET = operation that=20 brought the grammar into the MRCP server. In addition, the = behaviour is=20 also governed by Cache -Control parameters that the client can = specify for=20 the DEFINE-GRAMMAR that would take precedence over what was = returned by=20 the HTTP GET operation. This means that the MRCP client can force = the MRCP=20 server to ignore the cache parameters it got from the grammar=20 webserver.
 
So, for the large_grammar.grxml, if the = webserver=20 returned a large max-age value the grammar and its compiled = version in the=20 cache of the MRCP server should not get timedout. For any future = requests=20 for that grammar, MRCP server should go do fetch of the document, = compare=20 the max-age of the fetched coument and make sure the webserver = says that=20 the document in the cache is not out-of-date. As long as the = grammar=20 document in the cache is not out of date, you don't need to = compile it=20 again and you are fine. If the propoerty of the = large_grammar.grxml on the=20 webserver had changed then the MRCP server would be expected to = refresh=20 the cache and compile the newly downloaded = grammar.
 
 
Am I missing something = here.
 
Sarvi 

From: = speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Sunday, June 12, 2005 12:12 = PM
To: Wyss,=20 Felix; Shanmugham, Saravanan; Corby Anderson;=20 Speechsc@ietf.org
Subject: Re: [Speechsc] Managing big = grammars

There is no doubt that grammar = compilation=20 and loading must be hidden from the caller experience. = What is in doubt is whether the MRCP = protocol needs to=20 expose such control.
 
The grammar loading = problem is=20 not dissimilar to cache seeding in the Web world. Taking your = use-case,=20 I would implement this in MRCP as a two-step = process:
 
(1) Make the large grammar = available=20 through HTTP and date-stamp the URI, e.g. http://example= .com/large_grammar_12June2005.grxml.=20 Set the HTTP response header Cache-Control: max-age to a value = larger=20 than the grammar change period.
 
(2) When a new grammar is = required, open an=20 MRCP channel to each of the MRCP servers. Issue a DEFINE-GRAMMAR = with=20 the relevant URI e.g. http://example= .com/large_grammar_13June2005.grxml.=20 Update the application to point at the new grammar.
 
[For a mid-size grammar where = loading=20 latency is negligible, and assuming a centrally located compiled = grammar=20 cache, step (2) might only require a DEFINE-GRAMMAR to one MRCP=20 server].
 
You are correct that the = current MRCPv2=20 draft scopes the DEFINE-GRAMMAR to a channel and this is a=20 concern. However, this is resolved with Sarvi's suggested = text=20 change.
 
Dave
----- Original Message ----- =
From:=20 Wyss, Felix=20
To: Dave Burke ; Shanmugham,=20 Saravanan ; Corby Anderson ; Speechsc@ietf.org
Sent: Sunday, June 12, = 2005 1:41=20 AM
Subject: RE: [Speechsc] = Managing=20 big grammars

I=20 disagree.  Predictability is *very* critical for an = application=20 using ASR.  It must be able to make sure that when a = recognition=20 operation is started, there is no latency while the ASR server = compiles and/or loads a large precompiled grammar into memory. =  The DEFINE-GRAMMAR command is scoped to a channel, which = means=20 by the time the application has a channel (i.e. a caller is in = the=20 system), it is unacceptable to block for more than fraction of = a=20 second while the grammars are being compiled and/or loaded.=20  Otherwise, the first caller after a grammar is changed=20 encounters delays and has a poor user experience or even hangs = up.=20  Somebody may say: well, just make a =93priming=94 call = after=20 modifying the grammar to ensure the grammar is cached. =  However,=20 that is not very practical for automatically generated = grammars; but=20 worse yet, in large systems there are commonly several = load-balanced=20 ASR severs and it will be rather hard to ensure each of them = is=20 touched at least once.  

 

The = way we=20 solve this on our platform is as follows: Large grammars that = may=20 change frequently, possibly several times a day, such as = company=20 directory grammars that are generated from a database, can be=20 registered as =93preloaded grammars=94.  This means, our = platform=20 ensures the grammar is compiled, distributed to all ASR = servers, and=20 loaded into their caches after a new version of that grammar = has been=20 generated.  Each preloaded grammar has a name associated, = which=20 is referenced through a special URI.  The application = logic only=20 knows that URI and not the actual URI/filename of the = underlying=20 grammar data.  The subsystem managing the preloaded = grammars=20 ensures that the preloaded grammar URI resolves to the = previous=20 version of the grammar until the new grammar is loaded and = ready on=20 all ASR servers.  Thus, all callers that call into the = system=20 while the grammar is being generated, compiled, and loaded on = the=20 servers will get the previous version.  This ensures that = there=20 is no delay for the first caller after a change.  We can = do this=20 as we are using the native APIs provided by the ASR engine = vendors we=20 support and layer a sophisticated framework and API on top of=20 it. 

 

It = would be=20 nice if MRCP provided some support for schemes like that, = without=20 having to open dummy channels to register grammars and pray = the MRCP=20 server doesn=92t evict them too early.  An MRCP client = has to be=20 able to guarantee that when a call comes through the system,=20 everything is ready and it won=92t experience any delay. =  As it=20 stands now the MRCP protocol does not appear to provide = support for=20 this.

 

Thanks,

Felix

 

From:=20 speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] = On Behalf Of Dave=20 Burke
Sent: = Saturday,=20 June 11, 2005 10:42
To: Shanmugham, = Saravanan; Corby=20 Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing=20 big grammars

 

I agree. Grammar = compilation, caching, and sharing is a problem for the MRCP = server.=20 Exposing this in the protocol puts unnecessary complexity on = the=20 client. For example, the client needs to download grammars, = implement=20 its own HTTP caching, checksum algorithms (some way of not = having to=20 push huge data to the MRCP server to query)=20 etc.

 

So I vote for = point 1=20 below and include in the text that an MRCP server = could also, as=20 an optimisation, implement a centralised common cache = shared=20 across multiple MRCP = servers.

 

Dave

----- Original = Message=20 -----

Sent:=20 Saturday, June 11, 2005 12:09 = AM

Subject:=20 RE: [Speechsc] Managing big=20 grammars

 

I = would say=20 that a common cache amoung a farm of MRCP servers to = optimize=20 compilations would be a nice server side optimization and = shouldn't=20 affect the MRCP protocol.

 

my=20 2c.

Sarvi

------=_NextPart_000_0159_01C570E3.418CF0D0-- --===============0449043488== 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 --===============0449043488==-- From speechsc-bounces@ietf.org Tue Jun 14 08:23:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiASF-00057U-Cj; Tue, 14 Jun 2005 08:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiASD-00057P-4L for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 08:23:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08870 for ; Tue, 14 Jun 2005 08:23:40 -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 1DiAoe-00050d-UK for speechsc@ietf.org; Tue, 14 Jun 2005 08:46:55 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 05:23:11 -0700 X-IronPort-AV: i="3.93,197,1115017200"; d="scan'208"; a="278468988:sNHT2928552366" 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 j5ECN5bw022363; Tue, 14 Jun 2005 05:23:06 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5ECAmrA010222; Tue, 14 Jun 2005 05:10:49 -0700 In-Reply-To: <00d501c570ca$1b80ae90$cb00000a@db01.voxpilot.com> References: <03772D1EC8DE624A863058C75874A75C05B9CD@vtg-um-e2k6.sj21ad.cisco.com> <00d501c570ca$1b80ae90$cb00000a@db01.voxpilot.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: "David R. Oran" Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 08:23:05 -0400 To: Dave Burke X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118751050.240183"; x:"432200"; a:"rsa-sha1"; b:"nofws:7374"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"MavZHOcoF2t1uHygs6dWKpfwGDU+jaWIIN6eYmNDsX03lXmiGr8i3QjCXRglk9OVgOKMR2nz" "InPifG+GCsfl06jT+1q5m6PU6pI0b0Ei08lj0Y7WQoBpDlJ6yMxByhHFbQZztTcc6Ttk2MsHpKD" "WxwNXhL1T1h7vV0rXP2ftU+w="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Managing big grammars"; c:"Date: Tue, 14 Jun 2005 08:23:05 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 On Jun 14, 2005, at 6:16 AM, Dave Burke wrote: > It's not that the URL needs a specific date or time, just that it =20 > has a unique name. This is simply so that you can ensure the new =20 > grammar is downloaded, compiled, and loaded ahead of any calls. =20 > Once compiled and loaded, the application grammar URIs can be =20 > updated to reference the new grammar. This way you avoid the danger =20= > that a bunch of calls, which arrive at the same time as the DEFINE-=20 > GRAMMAR is happening, experience delays. > I'm lost - so what happens if the call arrives during this =20 hypothetical COMPILE-GRAMMAR extension? How's that any different? There are LOTS of things that might hold up a call. Setting up a TLS =20 connection can sometimes take a few seconds to do all the PK =20 operations if the server is busy and you don't have PK crypto =20 acceleration hardware. A server might be taken out of service and you =20= have to load-balance. The source grammar might have gotten replaced =20 due to tuning or a bug. If you don't want to have any delays, wait until all your setup is =20 done before enabling your input ports... > Dave > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 7:58 AM > Subject: RE: [Speechsc] Managing big grammars > > I dont understand why the RUL has to encode and date and time into =20 > it. Lets say we are refering to large_grammar.grxml > > When a client does a DEFINE-GRAMMAR on the MRCP server with this =20 > URI. The MRCP server is expected to go download this URI and =20 > compile it. The caching behaviour of this URI and how long it lives =20= > in the cache is dependent on what is returned by the HTTP GET =20 > operation that brought the grammar into the MRCP server. In =20 > addition, the behaviour is also governed by Cache -Control =20 > parameters that the client can specify for the DEFINE-GRAMMAR that =20 > would take precedence over what was returned by the HTTP GET =20 > operation. This means that the MRCP client can force the MRCP =20 > server to ignore the cache parameters it got from the grammar =20 > webserver. > > So, for the large_grammar.grxml, if the webserver returned a large =20 > max-age value the grammar and its compiled version in the cache of =20 > the MRCP server should not get timedout. For any future requests =20 > for that grammar, MRCP server should go do fetch of the document, =20 > compare the max-age of the fetched coument and make sure the =20 > webserver says that the document in the cache is not out-of-date. =20 > As long as the grammar document in the cache is not out of date, =20 > you don't need to compile it again and you are fine. If the =20 > propoerty of the large_grammar.grxml on the webserver had changed =20 > then the MRCP server would be expected to refresh the cache and =20 > compile the newly downloaded grammar. > > > Am I missing something here. > > Sarvi > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] =20 > On Behalf Of Dave Burke > Sent: Sunday, June 12, 2005 12:12 PM > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; =20 > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > There is no doubt that grammar compilation and loading must be =20 > hidden from the caller experience. What is in doubt is whether the =20 > MRCP protocol needs to expose such control. > > The grammar loading problem is not dissimilar to cache seeding in =20 > the Web world. Taking your use-case, I would implement this in MRCP =20= > as a two-step process: > > (1) Make the large grammar available through HTTP and date-stamp =20 > the URI, e.g. http://example.com/large_grammar_12June2005.grxml. =20 > Set the HTTP response header Cache-Control: max-age to a value =20 > larger than the grammar change period. > > (2) When a new grammar is required, open an MRCP channel to each of =20= > the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. =20= > http://example.com/large_grammar_13June2005.grxml. Update the =20 > application to point at the new grammar. > > [For a mid-size grammar where loading latency is negligible, and =20 > assuming a centrally located compiled grammar cache, step (2) might =20= > only require a DEFINE-GRAMMAR to one MRCP server]. > > You are correct that the current MRCPv2 draft scopes the DEFINE-=20 > GRAMMAR to a channel and this is a concern. However, this is =20 > resolved with Sarvi's suggested text change. > > Dave > ----- Original Message ----- > From: Wyss, Felix > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; =20 > Speechsc@ietf.org > Sent: Sunday, June 12, 2005 1:41 AM > Subject: RE: [Speechsc] Managing big grammars > > I disagree. Predictability is *very* critical for an application =20 > using ASR. It must be able to make sure that when a recognition =20 > operation is started, there is no latency while the ASR server =20 > compiles and/or loads a large precompiled grammar into memory. The =20= > DEFINE-GRAMMAR command is scoped to a channel, which means by the =20 > time the application has a channel (i.e. a caller is in the =20 > system), it is unacceptable to block for more than fraction of a =20 > second while the grammars are being compiled and/or loaded. =20 > Otherwise, the first caller after a grammar is changed encounters =20 > delays and has a poor user experience or even hangs up. Somebody =20 > may say: well, just make a =93priming=94 call after modifying the =20 > grammar to ensure the grammar is cached. However, that is not very =20= > practical for automatically generated grammars; but worse yet, in =20 > large systems there are commonly several load-balanced ASR severs =20 > and it will be rather hard to ensure each of them is touched at =20 > least once. > > > > The way we solve this on our platform is as follows: Large grammars =20= > that may change frequently, possibly several times a day, such as =20 > company directory grammars that are generated from a database, can =20 > be registered as =93preloaded grammars=94. This means, our platform =20= > ensures the grammar is compiled, distributed to all ASR servers, =20 > and loaded into their caches after a new version of that grammar =20 > has been generated. Each preloaded grammar has a name associated, =20 > which is referenced through a special URI. The application logic =20 > only knows that URI and not the actual URI/filename of the =20 > underlying grammar data. The subsystem managing the preloaded =20 > grammars ensures that the preloaded grammar URI resolves to the =20 > previous version of the grammar until the new grammar is loaded and =20= > ready on all ASR servers. Thus, all callers that call into the =20 > system while the grammar is being generated, compiled, and loaded =20 > on the servers will get the previous version. This ensures that =20 > there is no delay for the first caller after a change. We can do =20 > this as we are using the native APIs provided by the ASR engine =20 > vendors we support and layer a sophisticated framework and API on =20 > top of it. > > > > It would be nice if MRCP provided some support for schemes like =20 > that, without having to open dummy channels to register grammars =20 > and pray the MRCP server doesn=92t evict them too early. An MRCP =20 > client has to be able to guarantee that when a call comes through =20 > the system, everything is ready and it won=92t experience any delay. =20= > As it stands now the MRCP protocol does not appear to provide =20 > support for this. > > > > Thanks, > > Felix > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] =20 > On Behalf Of Dave Burke > Sent: Saturday, June 11, 2005 10:42 > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > > > I agree. Grammar compilation, caching, and sharing is a problem for =20= > the MRCP server. Exposing this in the protocol puts unnecessary =20 > complexity on the client. For example, the client needs to download =20= > grammars, implement its own HTTP caching, checksum algorithms (some =20= > way of not having to push huge data to the MRCP server to query) etc. > > > > So I vote for point 1 below and include in the text that an MRCP =20 > server could also, as an optimisation, implement a centralised =20 > common cache shared across multiple MRCP servers. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Corby Anderson ; Speechsc@ietf.org > > Sent: Saturday, June 11, 2005 12:09 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I would say that a common cache amoung a farm of MRCP servers to =20 > optimize compilations would be a nice server side optimization and =20 > shouldn't affect the MRCP protocol. > > > > my 2c. > > Sarvi > > _______________________________________________ > 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 Tue Jun 14 08:31:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAa1-0006jo-1L; Tue, 14 Jun 2005 08:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAZz-0006jj-SK for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 08:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09424 for ; Tue, 14 Jun 2005 08:31:42 -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 1DiAwT-0005NU-JR for speechsc@ietf.org; Tue, 14 Jun 2005 08:54:58 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 05:31:34 -0700 X-IronPort-AV: i="3.93,197,1115017200"; d="scan'208"; a="278471545:sNHT78141222" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5ECVTlw015246; Tue, 14 Jun 2005 05:31:29 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5ECJAMj010255; Tue, 14 Jun 2005 05:19:11 -0700 In-Reply-To: <015c01c570da$dfdc5ef0$cb00000a@db01.voxpilot.com> References: <03772D1EC8DE624A863058C75874A75C05B9D8@vtg-um-e2k6.sj21ad.cisco.com> <015c01c570da$dfdc5ef0$cb00000a@db01.voxpilot.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: "David R. Oran" Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 08:31:27 -0400 To: Dave Burke X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118751552.707713"; x:"432200"; a:"rsa-sha1"; b:"nofws:9437"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"eTiduvWEO9ToSfkLaxMkmOJQakoY3MMSYMvMO5hmHQAPNLpgbDyrrWc+0b8f2ON4tHV62uA8" "sgyGfHiMXuQupk77OvhWWr3NM9gDaHl5cZPoK+mpplZHS3LT0cBUMLSDohX9d6ak4fomF8uFP5b" "6VK07wZ3w/m3+tGLtWcjjfwM="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Managing big grammars"; c:"Date: Tue, 14 Jun 2005 08:31:27 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 like Dave's formulation. If there are no objections, I'm going to =20 craft this into a sub-section on "Grammar Caching" under the section =20= on "Grammar Data". On looking where to put this, I noticed that the =20 description is under 9.5.1 "recognizer Grammar Data" which is under =20 "Recognizer message body". Some of that material isn't really about =20 message body (since it talks about ow indirect content is handled), =20 so I'm going to re-jigger things a bit to improve the flow and move =20 the parts about indirect content to the new earlier section. Speak now if you don't like this, because I'm going to do this later =20 today... On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: > That optimisation would be nice alright and is not restricted by =20 > HTTP (see note from RFC 2616 below). > > It seems like we have got some good optimisation suggestions (read: =20= > informative) that could go into the spec to address large grammars. =20= > If memory serves, they are: > 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or =20 > RECOGNIZE to be used over multiple MRCP sessions > 2. An MRCP server may cache the compiled version of a grammar > 3. An MRCP server may cache grammars centrally to allow other =20 > servers take advantage of the cache > 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform =20 > other MRCP servers to reload the new grammar into memory > 5. An MRCP server may choose to return a stale response while a =20= > new grammar is being downloaded, compiled, and cached > > -- Dave > > =46rom RFC 2616: > > In some cases, the operator of a cache MAY choose to configure =20 > it to > return stale responses even when not requested by clients. This > decision ought not be made lightly, but may be necessary for =20 > reasons > of availability or performance, especially when the cache is poorly > connected to the origin server. Whenever a cache returns a stale > response, it MUST mark it as such (using a Warning header) enabling > the client software to alert the user that there might be a =20 > potential > problem. > > > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 12:04 PM > Subject: RE: [Speechsc] Managing big grammars > > cool. That makes sense. > The way I though this problem would have been addressed, is the =20 > MRCP caching system to be smart. > That is everytime there is a request a grammar for a grammar URI. =20 > the MRCP server would do a fetch to check if the document has =20 > changed. If it has, then it would download and compile the grammar. =20= > While this happenning existing calls that were using the older =20 > compiled grammar continue to use it. Once this is ready, the =20 > previous version of the grammar is allowed to expire-out. > > Would this not address your scenario and avoid having to do this =20 > work around you are suggesting? > > Sarvi > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 14, 2005 3:16 AM > To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; =20 > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > It's not that the URL needs a specific date or time, just that it =20 > has a unique name. This is simply so that you can ensure the new =20 > grammar is downloaded, compiled, and loaded ahead of any calls. =20 > Once compiled and loaded, the application grammar URIs can be =20 > updated to reference the new grammar. This way you avoid the danger =20= > that a bunch of calls, which arrive at the same time as the DEFINE-=20 > GRAMMAR is happening, experience delays. > > Dave > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 7:58 AM > Subject: RE: [Speechsc] Managing big grammars > > I dont understand why the RUL has to encode and date and time into =20 > it. Lets say we are refering to large_grammar.grxml > > When a client does a DEFINE-GRAMMAR on the MRCP server with this =20 > URI. The MRCP server is expected to go download this URI and =20 > compile it. The caching behaviour of this URI and how long it lives =20= > in the cache is dependent on what is returned by the HTTP GET =20 > operation that brought the grammar into the MRCP server. In =20 > addition, the behaviour is also governed by Cache -Control =20 > parameters that the client can specify for the DEFINE-GRAMMAR that =20 > would take precedence over what was returned by the HTTP GET =20 > operation. This means that the MRCP client can force the MRCP =20 > server to ignore the cache parameters it got from the grammar =20 > webserver. > > So, for the large_grammar.grxml, if the webserver returned a large =20 > max-age value the grammar and its compiled version in the cache of =20 > the MRCP server should not get timedout. For any future requests =20 > for that grammar, MRCP server should go do fetch of the document, =20 > compare the max-age of the fetched coument and make sure the =20 > webserver says that the document in the cache is not out-of-date. =20 > As long as the grammar document in the cache is not out of date, =20 > you don't need to compile it again and you are fine. If the =20 > propoerty of the large_grammar.grxml on the webserver had changed =20 > then the MRCP server would be expected to refresh the cache and =20 > compile the newly downloaded grammar. > > > Am I missing something here. > > Sarvi > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] =20 > On Behalf Of Dave Burke > Sent: Sunday, June 12, 2005 12:12 PM > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; =20 > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > There is no doubt that grammar compilation and loading must be =20 > hidden from the caller experience. What is in doubt is whether the =20 > MRCP protocol needs to expose such control. > > The grammar loading problem is not dissimilar to cache seeding in =20 > the Web world. Taking your use-case, I would implement this in MRCP =20= > as a two-step process: > > (1) Make the large grammar available through HTTP and date-stamp =20 > the URI, e.g. http://example.com/large_grammar_12June2005.grxml. =20 > Set the HTTP response header Cache-Control: max-age to a value =20 > larger than the grammar change period. > > (2) When a new grammar is required, open an MRCP channel to each of =20= > the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. =20= > http://example.com/large_grammar_13June2005.grxml. Update the =20 > application to point at the new grammar. > > [For a mid-size grammar where loading latency is negligible, and =20 > assuming a centrally located compiled grammar cache, step (2) might =20= > only require a DEFINE-GRAMMAR to one MRCP server]. > > You are correct that the current MRCPv2 draft scopes the DEFINE-=20 > GRAMMAR to a channel and this is a concern. However, this is =20 > resolved with Sarvi's suggested text change. > > Dave > ----- Original Message ----- > From: Wyss, Felix > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; =20 > Speechsc@ietf.org > Sent: Sunday, June 12, 2005 1:41 AM > Subject: RE: [Speechsc] Managing big grammars > > I disagree. Predictability is *very* critical for an application =20 > using ASR. It must be able to make sure that when a recognition =20 > operation is started, there is no latency while the ASR server =20 > compiles and/or loads a large precompiled grammar into memory. The =20= > DEFINE-GRAMMAR command is scoped to a channel, which means by the =20 > time the application has a channel (i.e. a caller is in the =20 > system), it is unacceptable to block for more than fraction of a =20 > second while the grammars are being compiled and/or loaded. =20 > Otherwise, the first caller after a grammar is changed encounters =20 > delays and has a poor user experience or even hangs up. Somebody =20 > may say: well, just make a =93priming=94 call after modifying the =20 > grammar to ensure the grammar is cached. However, that is not very =20= > practical for automatically generated grammars; but worse yet, in =20 > large systems there are commonly several load-balanced ASR severs =20 > and it will be rather hard to ensure each of them is touched at =20 > least once. > > > > The way we solve this on our platform is as follows: Large grammars =20= > that may change frequently, possibly several times a day, such as =20 > company directory grammars that are generated from a database, can =20 > be registered as =93preloaded grammars=94. This means, our platform =20= > ensures the grammar is compiled, distributed to all ASR servers, =20 > and loaded into their caches after a new version of that grammar =20 > has been generated. Each preloaded grammar has a name associated, =20 > which is referenced through a special URI. The application logic =20 > only knows that URI and not the actual URI/filename of the =20 > underlying grammar data. The subsystem managing the preloaded =20 > grammars ensures that the preloaded grammar URI resolves to the =20 > previous version of the grammar until the new grammar is loaded and =20= > ready on all ASR servers. Thus, all callers that call into the =20 > system while the grammar is being generated, compiled, and loaded =20 > on the servers will get the previous version. This ensures that =20 > there is no delay for the first caller after a change. We can do =20 > this as we are using the native APIs provided by the ASR engine =20 > vendors we support and layer a sophisticated framework and API on =20 > top of it. > > > > It would be nice if MRCP provided some support for schemes like =20 > that, without having to open dummy channels to register grammars =20 > and pray the MRCP server doesn=92t evict them too early. An MRCP =20 > client has to be able to guarantee that when a call comes through =20 > the system, everything is ready and it won=92t experience any delay. =20= > As it stands now the MRCP protocol does not appear to provide =20 > support for this. > > > > Thanks, > > Felix > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] =20 > On Behalf Of Dave Burke > Sent: Saturday, June 11, 2005 10:42 > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > > > I agree. Grammar compilation, caching, and sharing is a problem for =20= > the MRCP server. Exposing this in the protocol puts unnecessary =20 > complexity on the client. For example, the client needs to download =20= > grammars, implement its own HTTP caching, checksum algorithms (some =20= > way of not having to push huge data to the MRCP server to query) etc. > > > > So I vote for point 1 below and include in the text that an MRCP =20 > server could also, as an optimisation, implement a centralised =20 > common cache shared across multiple MRCP servers. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Corby Anderson ; Speechsc@ietf.org > > Sent: Saturday, June 11, 2005 12:09 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I would say that a common cache amoung a farm of MRCP servers to =20 > optimize compilations would be a nice server side optimization and =20 > shouldn't affect the MRCP protocol. > > > > my 2c. > > Sarvi > > _______________________________________________ > 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 Tue Jun 14 09:08:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiB9v-0004Je-0f; Tue, 14 Jun 2005 09:08:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiB9s-0004J4-Fy for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 09:08:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15444 for ; Tue, 14 Jun 2005 09:08:47 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiBWI-0007Xq-Fr for Speechsc@ietf.org; Tue, 14 Jun 2005 09:32:01 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_08_07_17 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 08:07:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 08:08:27 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524CB@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVw2uaS8PPkngE0QAaVx6D5pfsC7QAAX8CQ From: "Wyss, Felix" To: "Dave Burke" , "Shanmugham, Saravanan" , "Corby Anderson" , X-Spam-Score: 0.3 (/) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f 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="===============2022567230==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============2022567230== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570E2.27639647" This is a multi-part message in MIME format. ------_=_NextPart_001_01C570E2.27639647 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Using a stale grammar for calls arriving while the new version is fetched and compiled would be acceptable, provided: 1) There is a flag in the DEFINE-GRAMMAR request to control this behavior. I can think of three possible options: a. Ensure grammar is always up-to date according to the HTTP server's caching headers ("accuracy over latency") b. Allow stale grammars to be used ("latency over accuracy"), but block when grammar is not in the cache at all c. Like b, but fail immediately if grammar is not already in the cache; that way, the application can fallback to something else instead of spuriously blocking. 2) DEFINE-GRAMMAR returns a header or result-code indicating whether a stale grammar is being used=20 3) If a DEFINE-GRAMMAR causes a stale grammar to be used, that grammar must be used for the whole duration of that call or until the next DEFINE-GRAMMAR is issued for it (i.e. the grammar won't unpredictably change between recognitions just because a newer version became ready in the meantime). =20 4) All standard conforming MRCP servers MUST implement the caching behavior this way (i.e. it is not optional or up to the vendor like in RFC 2616). =20 =20 Of course, this still requires the application to ping the servers to update their caches; otherwise some calls may get very stale grammars. =20 =20 Felix =20 ________________________________ From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, June 14, 2005 07:16 To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; Speechsc@ietf.org Subject: Re: [Speechsc] Managing big grammars =20 That optimisation would be nice alright and is not restricted by HTTP (see note from RFC 2616 below).=20 =20 It seems like we have got some good optimisation suggestions (read: informative) that could go into the spec to address large grammars. If memory serves, they are: 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or RECOGNIZE to be used over multiple MRCP sessions 2. An MRCP server may cache the compiled version of a grammar 3. An MRCP server may cache grammars centrally to allow other servers take advantage of the cache 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform other MRCP servers to reload the new grammar into memory 5. An MRCP server may choose to return a stale response while a new grammar is being downloaded, compiled, and cached =20 -- Dave =20 >From RFC 2616: =20 In some cases, the operator of a cache MAY choose to configure it to return stale responses even when not requested by clients. This decision ought not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header) enabling the client software to alert the user that there might be a potential problem. =20 =20 ------_=_NextPart_001_01C570E2.27639647 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Using a stale grammar for calls = arriving while the new version is fetched and compiled would be acceptable, = provided:

  1) There is a flag in the DEFINE-GRAMMAR request to control this behavior.  I can think of = three possible options:

    a. Ensure = grammar is always up-to date according to the HTTP server’s caching headers = (“accuracy over latency”)

    b. Allow stale = grammars to be used (“latency over accuracy”), but block when grammar = is not in the cache at all

    c. Like b, but = fail immediately if grammar is not already in the cache; that way, the application can = fallback to something else instead of spuriously = blocking.

  2) DEFINE-GRAMMAR returns a = header or result-code indicating whether a stale grammar is being used =

  3) If a DEFINE-GRAMMAR = causes a stale grammar to be used, that grammar must be used for the whole = duration of that call or until the next DEFINE-GRAMMAR is issued for it (i.e. the grammar = won’t unpredictably change between recognitions just because a newer version = became ready in the meantime). 

  4) All standard conforming = MRCP servers MUST implement the caching behavior this way (i.e. it is not optional or = up to the vendor like in RFC 2616). 

 

Of course, this still requires the application to ping the servers to update their caches; otherwise some = calls may get very stale grammars. 

 

Felix

 

From: Dave Burke [mailto:david.burke@voxpilot.com]
Sent: Tuesday, June 14, = 2005 07:16
To: Shanmugham, = Saravanan; Wyss, Felix; Corby Anderson; Speechsc@ietf.org
Subject: Re: [Speechsc] = Managing big grammars

 

That optimisation would be = nice alright and is not restricted by HTTP (see note from RFC 2616 = below).

 

It seems like we have got = some good optimisation suggestions (read: informative) that could go into the = spec to address large grammars. If memory serves, they = are:

    1. An = MRCP server may cache grammars used in DEFINE-GRAMMAR or RECOGNIZE to be used = over multiple MRCP sessions

    2. An MRCP = server may cache the compiled version of a grammar

    3. An = MRCP server may cache grammars centrally to allow other servers take = advantage of the cache

    4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform other MRCP servers = to reload the new grammar into memory

    5. An = MRCP server may choose to return a stale response while a new grammar is = being downloaded, compiled, and cached

 

-- Dave

 

From RFC = 2616:

 

   In some cases, = the operator of a cache MAY choose to configure it to
   return stale responses even when not requested by clients. = This
   decision ought not be made lightly, but may be necessary = for reasons
   of availability or performance, especially when the cache = is poorly
   connected to the origin server. Whenever a cache returns a = stale
   response, it MUST mark it as such (using a Warning header) enabling
   the client software to alert the user that there might be a potential
   problem.

 

 

------_=_NextPart_001_01C570E2.27639647-- --===============2022567230== 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 --===============2022567230==-- From speechsc-bounces@ietf.org Tue Jun 14 10:34:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiCUc-0001uE-1q; Tue, 14 Jun 2005 10:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiCUa-0001u9-W5 for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 10:34:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22831 for ; Tue, 14 Jun 2005 10:34:15 -0400 (EDT) Received: from [199.4.160.64] (helo=pb-exchcon2.scansoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiCqj-0004fs-EJ for Speechsc@ietf.org; Tue, 14 Jun 2005 10:57:32 -0400 Received: by pb-exchcon2.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 14 Jun 2005 10:33:09 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , Dave Burke Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 08:51:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 Is 4) a realistic scenario? It would require that the MRCP server know each other, which results in a configuration nightmare. And what happens if one of them is down just at that moment... Slight reformulation of 2): An MRCP server may cache a compiled version of a grammar Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Dienstag, 14. Juni 2005 14:31 To: Dave Burke Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix Subject: Re: [Speechsc] Managing big grammars I like Dave's formulation. If there are no objections, I'm going to craft this into a sub-section on "Grammar Caching" under the section on "Grammar Data". On looking where to put this, I noticed that the description is under 9.5.1 "recognizer Grammar Data" which is under "Recognizer message body". Some of that material isn't really about message body (since it talks about ow indirect content is handled), so I'm going to re-jigger things a bit to improve the flow and move the parts about indirect content to the new earlier section. Speak now if you don't like this, because I'm going to do this later today... On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: > That optimisation would be nice alright and is not restricted by HTTP > (see note from RFC 2616 below). > > It seems like we have got some good optimisation suggestions (read: > informative) that could go into the spec to address large grammars. > If memory serves, they are: > 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or > RECOGNIZE to be used over multiple MRCP sessions > 2. An MRCP server may cache the compiled version of a grammar > 3. An MRCP server may cache grammars centrally to allow other > servers take advantage of the cache > 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform > other MRCP servers to reload the new grammar into memory > 5. An MRCP server may choose to return a stale response while a > new grammar is being downloaded, compiled, and cached > > -- Dave > > From RFC 2616: > > In some cases, the operator of a cache MAY choose to configure it > to > return stale responses even when not requested by clients. This > decision ought not be made lightly, but may be necessary for > reasons > of availability or performance, especially when the cache is poorly > connected to the origin server. Whenever a cache returns a stale > response, it MUST mark it as such (using a Warning header) enabling > the client software to alert the user that there might be a > potential > problem. > > > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 12:04 PM > Subject: RE: [Speechsc] Managing big grammars > > cool. That makes sense. > The way I though this problem would have been addressed, is the MRCP > caching system to be smart. > That is everytime there is a request a grammar for a grammar URI. > the MRCP server would do a fetch to check if the document has changed. > If it has, then it would download and compile the grammar. > While this happenning existing calls that were using the older > compiled grammar continue to use it. Once this is ready, the previous > version of the grammar is allowed to expire-out. > > Would this not address your scenario and avoid having to do this work > around you are suggesting? > > Sarvi > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 14, 2005 3:16 AM > To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > It's not that the URL needs a specific date or time, just that it has > a unique name. This is simply so that you can ensure the new grammar > is downloaded, compiled, and loaded ahead of any calls. > Once compiled and loaded, the application grammar URIs can be updated > to reference the new grammar. This way you avoid the danger that a > bunch of calls, which arrive at the same time as the DEFINE- GRAMMAR > is happening, experience delays. > > Dave > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 7:58 AM > Subject: RE: [Speechsc] Managing big grammars > > I dont understand why the RUL has to encode and date and time into it. > Lets say we are refering to large_grammar.grxml > > When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. > The MRCP server is expected to go download this URI and compile it. > The caching behaviour of this URI and how long it lives in the cache > is dependent on what is returned by the HTTP GET operation that > brought the grammar into the MRCP server. In addition, the behaviour > is also governed by Cache -Control parameters that the client can > specify for the DEFINE-GRAMMAR that would take precedence over what > was returned by the HTTP GET operation. This means that the MRCP > client can force the MRCP server to ignore the cache parameters it got > from the grammar webserver. > > So, for the large_grammar.grxml, if the webserver returned a large > max-age value the grammar and its compiled version in the cache of the > MRCP server should not get timedout. For any future requests for that > grammar, MRCP server should go do fetch of the document, compare the > max-age of the fetched coument and make sure the webserver says that > the document in the cache is not out-of-date. > As long as the grammar document in the cache is not out of date, you > don't need to compile it again and you are fine. If the propoerty of > the large_grammar.grxml on the webserver had changed then the MRCP > server would be expected to refresh the cache and compile the newly > downloaded grammar. > > > Am I missing something here. > > Sarvi > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Sunday, June 12, 2005 12:12 PM > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > There is no doubt that grammar compilation and loading must be hidden > from the caller experience. What is in doubt is whether the MRCP > protocol needs to expose such control. > > The grammar loading problem is not dissimilar to cache seeding in the > Web world. Taking your use-case, I would implement this in MRCP as a > two-step process: > > (1) Make the large grammar available through HTTP and date-stamp the > URI, e.g. http://example.com/large_grammar_12June2005.grxml. > Set the HTTP response header Cache-Control: max-age to a value larger > than the grammar change period. > > (2) When a new grammar is required, open an MRCP channel to each of > the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. > http://example.com/large_grammar_13June2005.grxml. Update the > application to point at the new grammar. > > [For a mid-size grammar where loading latency is negligible, and > assuming a centrally located compiled grammar cache, step (2) might > only require a DEFINE-GRAMMAR to one MRCP server]. > > You are correct that the current MRCPv2 draft scopes the DEFINE- > GRAMMAR to a channel and this is a concern. However, this is resolved > with Sarvi's suggested text change. > > Dave > ----- Original Message ----- > From: Wyss, Felix > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; > Speechsc@ietf.org > Sent: Sunday, June 12, 2005 1:41 AM > Subject: RE: [Speechsc] Managing big grammars > > I disagree. Predictability is *very* critical for an application > using ASR. It must be able to make sure that when a recognition > operation is started, there is no latency while the ASR server > compiles and/or loads a large precompiled grammar into memory. The > DEFINE-GRAMMAR command is scoped to a channel, which means by the time > the application has a channel (i.e. a caller is in the system), it is > unacceptable to block for more than fraction of a > second while the grammars are being compiled and/or loaded. > Otherwise, the first caller after a grammar is changed encounters > delays and has a poor user experience or even hangs up. Somebody may > say: well, just make a "priming" call after modifying the grammar to > ensure the grammar is cached. However, that is not very practical for > automatically generated grammars; but worse yet, in large systems > there are commonly several load-balanced ASR severs and it will be > rather hard to ensure each of them is touched at least once. > > > > The way we solve this on our platform is as follows: Large grammars > that may change frequently, possibly several times a day, such as > company directory grammars that are generated from a database, can be > registered as "preloaded grammars". This means, our platform ensures > the grammar is compiled, distributed to all ASR servers, and loaded > into their caches after a new version of that grammar has been > generated. Each preloaded grammar has a name associated, which is > referenced through a special URI. The application logic only knows > that URI and not the actual URI/filename of the underlying grammar > data. The subsystem managing the preloaded grammars ensures that the > preloaded grammar URI resolves to the previous version of the grammar > until the new grammar is loaded and ready on all ASR servers. Thus, > all callers that call into the system while the grammar is being > generated, compiled, and loaded on the servers will get the previous > version. This ensures that there is no delay for the first caller > after a change. We can do this as we are using the native APIs > provided by the ASR engine vendors we support and layer a > sophisticated framework and API on top of it. > > > > It would be nice if MRCP provided some support for schemes like that, > without having to open dummy channels to register grammars and pray > the MRCP server doesn't evict them too early. An MRCP client has to > be able to guarantee that when a call comes through > the system, everything is ready and it won't experience any delay. > As it stands now the MRCP protocol does not appear to provide support > for this. > > > > Thanks, > > Felix > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Saturday, June 11, 2005 10:42 > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > > > I agree. Grammar compilation, caching, and sharing is a problem for > the MRCP server. Exposing this in the protocol puts unnecessary > complexity on the client. For example, the client needs to download > grammars, implement its own HTTP caching, checksum algorithms (some > way of not having to push huge data to the MRCP server to query) etc. > > > > So I vote for point 1 below and include in the text that an MRCP > server could also, as an optimisation, implement a centralised > common cache shared across multiple MRCP servers. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Corby Anderson ; Speechsc@ietf.org > > Sent: Saturday, June 11, 2005 12:09 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I would say that a common cache amoung a farm of MRCP servers to > optimize compilations would be a nice server side optimization and > shouldn't affect the MRCP protocol. > > > > my 2c. > > Sarvi > > _______________________________________________ > 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 Tue Jun 14 10:52:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiClo-0004xG-34; Tue, 14 Jun 2005 10:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiCll-0004wq-7u for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 10:52:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23953 for ; Tue, 14 Jun 2005 10:51:59 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiD8F-0005pI-MJ for Speechsc@ietf.org; Tue, 14 Jun 2005 11:15:17 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id C9BEF2140F4; Tue, 14 Jun 2005 14:51:47 +0000 (GMT) Message-ID: <022501c570f0$9e3a9af0$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Reifenrath, Klaus" , "'David R. Oran'" References: Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 15:51:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: 7bit Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 For 4) I was thinking of a broadcast idea. Each MRCP server just needs to know the (default) multicast address. Each MRCP server (via IGMP) learns of a new grammar to potentially load if any one server is asked to DEFINE-GRAMMAR. With a well-chosen IP address e.g. in 239.0.0.0 - 239.255.255.255 range, there is no configuration. If a server is down, it's got to load the grammar when first required on restart. Assuming 1-3 this shouldn't be so bad. - Dave ----- Original Message ----- From: "Reifenrath, Klaus" To: "'David R. Oran'" ; "Dave Burke" Cc: ; "Shanmugham, Saravanan" ; "Wyss, Felix" Sent: Tuesday, June 14, 2005 1:51 PM Subject: RE: [Speechsc] Managing big grammars > Is 4) a realistic scenario? It would require that the MRCP server know > each > other, which results in a configuration nightmare. And what happens if one > of them is down just at that moment... > > Slight reformulation of 2): > An MRCP server may cache a compiled version of a grammar > > Klaus > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Dienstag, 14. Juni 2005 14:31 > To: Dave Burke > Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix > Subject: Re: [Speechsc] Managing big grammars > > I like Dave's formulation. If there are no objections, I'm going to craft > this into a sub-section on "Grammar Caching" under the section on > "Grammar > Data". On looking where to put this, I noticed that the description is > under > 9.5.1 "recognizer Grammar Data" which is under "Recognizer message body". > Some of that material isn't really about message body (since it talks > about > ow indirect content is handled), so I'm going to re-jigger things a bit to > improve the flow and move the parts about indirect content to the new > earlier section. > > Speak now if you don't like this, because I'm going to do this later > today... > > On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: > >> That optimisation would be nice alright and is not restricted by HTTP >> (see note from RFC 2616 below). >> >> It seems like we have got some good optimisation suggestions (read: >> informative) that could go into the spec to address large grammars. >> If memory serves, they are: >> 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or >> RECOGNIZE to be used over multiple MRCP sessions >> 2. An MRCP server may cache the compiled version of a grammar >> 3. An MRCP server may cache grammars centrally to allow other >> servers take advantage of the cache >> 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform >> other MRCP servers to reload the new grammar into memory >> 5. An MRCP server may choose to return a stale response while a >> new grammar is being downloaded, compiled, and cached >> >> -- Dave >> >> From RFC 2616: >> >> In some cases, the operator of a cache MAY choose to configure it >> to >> return stale responses even when not requested by clients. This >> decision ought not be made lightly, but may be necessary for >> reasons >> of availability or performance, especially when the cache is poorly >> connected to the origin server. Whenever a cache returns a stale >> response, it MUST mark it as such (using a Warning header) enabling >> the client software to alert the user that there might be a >> potential >> problem. >> >> >> ----- Original Message ----- >> From: Shanmugham, Saravanan >> To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org >> Sent: Tuesday, June 14, 2005 12:04 PM >> Subject: RE: [Speechsc] Managing big grammars >> >> cool. That makes sense. >> The way I though this problem would have been addressed, is the MRCP >> caching system to be smart. >> That is everytime there is a request a grammar for a grammar URI. >> the MRCP server would do a fetch to check if the document has changed. >> If it has, then it would download and compile the grammar. >> While this happenning existing calls that were using the older >> compiled grammar continue to use it. Once this is ready, the previous >> version of the grammar is allowed to expire-out. >> >> Would this not address your scenario and avoid having to do this work >> around you are suggesting? >> >> Sarvi >> >> From: Dave Burke [mailto:david.burke@voxpilot.com] >> Sent: Tuesday, June 14, 2005 3:16 AM >> To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; >> Speechsc@ietf.org >> Subject: Re: [Speechsc] Managing big grammars >> >> It's not that the URL needs a specific date or time, just that it has >> a unique name. This is simply so that you can ensure the new grammar >> is downloaded, compiled, and loaded ahead of any calls. >> Once compiled and loaded, the application grammar URIs can be updated >> to reference the new grammar. This way you avoid the danger that a >> bunch of calls, which arrive at the same time as the DEFINE- GRAMMAR >> is happening, experience delays. >> >> Dave >> ----- Original Message ----- >> From: Shanmugham, Saravanan >> To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org >> Sent: Tuesday, June 14, 2005 7:58 AM >> Subject: RE: [Speechsc] Managing big grammars >> >> I dont understand why the RUL has to encode and date and time into it. >> Lets say we are refering to large_grammar.grxml >> >> When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. >> The MRCP server is expected to go download this URI and compile it. >> The caching behaviour of this URI and how long it lives in the cache >> is dependent on what is returned by the HTTP GET operation that >> brought the grammar into the MRCP server. In addition, the behaviour >> is also governed by Cache -Control parameters that the client can >> specify for the DEFINE-GRAMMAR that would take precedence over what >> was returned by the HTTP GET operation. This means that the MRCP >> client can force the MRCP server to ignore the cache parameters it got >> from the grammar webserver. >> >> So, for the large_grammar.grxml, if the webserver returned a large >> max-age value the grammar and its compiled version in the cache of the >> MRCP server should not get timedout. For any future requests for that >> grammar, MRCP server should go do fetch of the document, compare the >> max-age of the fetched coument and make sure the webserver says that >> the document in the cache is not out-of-date. >> As long as the grammar document in the cache is not out of date, you >> don't need to compile it again and you are fine. If the propoerty of >> the large_grammar.grxml on the webserver had changed then the MRCP >> server would be expected to refresh the cache and compile the newly >> downloaded grammar. >> >> >> Am I missing something here. >> >> Sarvi >> >> From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] >> On Behalf Of Dave Burke >> Sent: Sunday, June 12, 2005 12:12 PM >> To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; >> Speechsc@ietf.org >> Subject: Re: [Speechsc] Managing big grammars >> >> There is no doubt that grammar compilation and loading must be hidden >> from the caller experience. What is in doubt is whether the MRCP >> protocol needs to expose such control. >> >> The grammar loading problem is not dissimilar to cache seeding in the >> Web world. Taking your use-case, I would implement this in MRCP as a >> two-step process: >> >> (1) Make the large grammar available through HTTP and date-stamp the >> URI, e.g. http://example.com/large_grammar_12June2005.grxml. >> Set the HTTP response header Cache-Control: max-age to a value larger >> than the grammar change period. >> >> (2) When a new grammar is required, open an MRCP channel to each of >> the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. >> http://example.com/large_grammar_13June2005.grxml. Update the >> application to point at the new grammar. >> >> [For a mid-size grammar where loading latency is negligible, and >> assuming a centrally located compiled grammar cache, step (2) might >> only require a DEFINE-GRAMMAR to one MRCP server]. >> >> You are correct that the current MRCPv2 draft scopes the DEFINE- >> GRAMMAR to a channel and this is a concern. However, this is resolved >> with Sarvi's suggested text change. >> >> Dave >> ----- Original Message ----- >> From: Wyss, Felix >> To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; >> Speechsc@ietf.org >> Sent: Sunday, June 12, 2005 1:41 AM >> Subject: RE: [Speechsc] Managing big grammars >> >> I disagree. Predictability is *very* critical for an application >> using ASR. It must be able to make sure that when a recognition >> operation is started, there is no latency while the ASR server >> compiles and/or loads a large precompiled grammar into memory. The >> DEFINE-GRAMMAR command is scoped to a channel, which means by the time >> the application has a channel (i.e. a caller is in the system), it is >> unacceptable to block for more than fraction of a >> second while the grammars are being compiled and/or loaded. >> Otherwise, the first caller after a grammar is changed encounters >> delays and has a poor user experience or even hangs up. Somebody may >> say: well, just make a "priming" call after modifying the grammar to >> ensure the grammar is cached. However, that is not very practical for >> automatically generated grammars; but worse yet, in large systems >> there are commonly several load-balanced ASR severs and it will be >> rather hard to ensure each of them is touched at least once. >> >> >> >> The way we solve this on our platform is as follows: Large grammars >> that may change frequently, possibly several times a day, such as >> company directory grammars that are generated from a database, can be >> registered as "preloaded grammars". This means, our platform ensures >> the grammar is compiled, distributed to all ASR servers, and loaded >> into their caches after a new version of that grammar has been >> generated. Each preloaded grammar has a name associated, which is >> referenced through a special URI. The application logic only knows >> that URI and not the actual URI/filename of the underlying grammar >> data. The subsystem managing the preloaded grammars ensures that the >> preloaded grammar URI resolves to the previous version of the grammar >> until the new grammar is loaded and ready on all ASR servers. Thus, >> all callers that call into the system while the grammar is being >> generated, compiled, and loaded on the servers will get the previous >> version. This ensures that there is no delay for the first caller >> after a change. We can do this as we are using the native APIs >> provided by the ASR engine vendors we support and layer a >> sophisticated framework and API on top of it. >> >> >> >> It would be nice if MRCP provided some support for schemes like that, >> without having to open dummy channels to register grammars and pray >> the MRCP server doesn't evict them too early. An MRCP client has to >> be able to guarantee that when a call comes through >> the system, everything is ready and it won't experience any delay. >> As it stands now the MRCP protocol does not appear to provide support >> for this. >> >> >> >> Thanks, >> >> Felix >> >> >> >> From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] >> On Behalf Of Dave Burke >> Sent: Saturday, June 11, 2005 10:42 >> To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org >> Subject: Re: [Speechsc] Managing big grammars >> >> >> >> I agree. Grammar compilation, caching, and sharing is a problem for >> the MRCP server. Exposing this in the protocol puts unnecessary >> complexity on the client. For example, the client needs to download >> grammars, implement its own HTTP caching, checksum algorithms (some >> way of not having to push huge data to the MRCP server to query) etc. >> >> >> >> So I vote for point 1 below and include in the text that an MRCP >> server could also, as an optimisation, implement a centralised >> common cache shared across multiple MRCP servers. >> >> >> >> Dave >> >> ----- Original Message ----- >> >> From: Shanmugham, Saravanan >> >> To: Corby Anderson ; Speechsc@ietf.org >> >> Sent: Saturday, June 11, 2005 12:09 AM >> >> Subject: RE: [Speechsc] Managing big grammars >> >> >> >> I would say that a common cache amoung a farm of MRCP servers to >> optimize compilations would be a nice server side optimization and >> shouldn't affect the MRCP protocol. >> >> >> >> my 2c. >> >> Sarvi >> >> _______________________________________________ >> 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 14 11:09:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD2r-0007nc-II; Tue, 14 Jun 2005 11:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD2p-0007my-GX for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 11:09:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24744 for ; Tue, 14 Jun 2005 11:09:37 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDPK-0006rS-4m for Speechsc@ietf.org; Tue, 14 Jun 2005 11:32:55 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_10_08_19 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 10:08:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Jun 2005 10:09:25 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B33901786CBC@i3mail1.i3domain.inin.com> Thread-Topic: Problem with draft-6 RECOGNIZE command and test/uri-list content type Thread-Index: AcVw8w9HBZ0ErNGeQkyfea5dOvDlCQ== From: "Bennett, Patrick" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-list content type 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="===============0094383654==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0094383654== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570F3.0D95DFC4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C570F3.0D95DFC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable According to the latest draft on page 89: =20 ...The RECOGNIZE method MUST carry the grammars that need to be=20 activated for that RECOGNIZE method, in its message body. The=20 grammars that need to be activated can be specified in one of 3=20 ways. The grammar content could be specified as a mime-content in=20 the message body. It could be a simple list of grammar URIs=20 specified in a mime-content of type text/uri-list, in which case the=20 order of the URI refer to the precedence order of the grammars=20 during the recognize. ... =20 The problem here is the statement "in which case the order of the URI refer to the precedence order of the grammars during the recognize." Well, what is the EXACT precedence? Shouldn't each of the grammars be considered as equally weighted alternatives? Ideally, all must be weighted equally unless a specific weight parameter was specified with each URI. As currently specified, this part of the specification is basically worthless. No MRCP client would ever send multiple URIs to an MRCP server via a uri-list since the weighting applied to each grammar is completely undefined. This really needs to be corrected. =20 Patrick Bennett ------_=_NextPart_001_01C570F3.0D95DFC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

According to the latest draft on page = 89:

 

   …The RECOGNIZE method MUST carry = the grammars that need to be

   activated for that RECOGNIZE method, in = its message body. The

   grammars that need to be activated can = be specified in one of 3

   ways. The grammar content could be = specified as a mime-content in

   the message body. It could be a simple = list of grammar URIs

   specified in a mime-content of type = text/uri-list, in which case the

   order of the URI refer to the precedence = order of the grammars

   during the recognize. = …

 

The problem here is the statement “in which = case the order of the URI refer to the precedence order of the grammars during the = recognize.”

Well, what is the EXACT precedence? =  Shouldn’t each of the grammars be considered as equally weighted alternatives?  = Ideally, all must be weighted equally unless a specific weight parameter was specified = with each URI.

As currently specified, this part of the = specification is basically worthless.  No MRCP client would ever send multiple URIs to an MRCP = server via a uri-list since the weighting applied to each grammar is completely = undefined.

This really needs to be corrected.

 

Patrick Bennett

------_=_NextPart_001_01C570F3.0D95DFC4-- --===============0094383654== 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 --===============0094383654==-- From speechsc-bounces@ietf.org Tue Jun 14 11:25:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDHz-00040M-FI; Tue, 14 Jun 2005 11:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDHx-00040E-Qh for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 11:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27017 for ; Tue, 14 Jun 2005 11:25:15 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDeS-00084v-N8 for Speechsc@ietf.org; Tue, 14 Jun 2005 11:48:33 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 0C6BA214042; Tue, 14 Jun 2005 15:25:11 +0000 (GMT) Message-ID: <029d01c570f5$40b2b840$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Bennett, Patrick" , References: <260A0A30F9017945932CC4F7B911B33901786CBC@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type Date: Tue, 14 Jun 2005 16:25:10 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.5 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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="===============0100253595==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0100253595== Content-Type: multipart/alternative; boundary="----=_NextPart_000_029A_01C570FD.A2665760" This is a multi-part message in MIME format. ------=_NextPart_000_029A_01C570FD.A2665760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The precedence is not related to weighting. The text here covers the = case if you had two grammars say gram1.grxml and gram2.grxml both of = which recognise the token "speech" but return a different semantic = interpretation. If gram2.grxml follows gram1.grxml in the uri-list then = it is gram1.grxml that is matched and it is gram1.grxml's semantic = interpretation result that is returned in the NLSML. This is also required for VoiceXML 2.x behaviour (see = http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). Dave ----- Original Message -----=20 From: Bennett, Patrick=20 To: Speechsc@ietf.org=20 Sent: Tuesday, June 14, 2005 4:09 PM Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and = test/uri-listcontent type According to the latest draft on page 89: .The RECOGNIZE method MUST carry the grammars that need to be=20 activated for that RECOGNIZE method, in its message body. The=20 grammars that need to be activated can be specified in one of 3=20 ways. The grammar content could be specified as a mime-content in=20 the message body. It could be a simple list of grammar URIs=20 specified in a mime-content of type text/uri-list, in which case = the=20 order of the URI refer to the precedence order of the grammars=20 during the recognize. . The problem here is the statement "in which case the order of the URI = refer to the precedence order of the grammars during the recognize." Well, what is the EXACT precedence? Shouldn't each of the grammars be = considered as equally weighted alternatives? Ideally, all must be = weighted equally unless a specific weight parameter was specified with = each URI. As currently specified, this part of the specification is basically = worthless. No MRCP client would ever send multiple URIs to an MRCP = server via a uri-list since the weighting applied to each grammar is = completely undefined. This really needs to be corrected. Patrick Bennett -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_029A_01C570FD.A2665760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The precedence is not related to = weighting. The=20 text here covers the case if you had two grammars say gram1.grxml and=20 gram2.grxml both of which recognise the token "speech" but return a = different=20 semantic interpretation. If gram2.grxml follows gram1.grxml in the = uri-list then=20 it is gram1.grxml that is matched and it is gram1.grxml's semantic=20 interpretation result that is returned in the NLSML.
 
This is also required for VoiceXML=20 2.x behaviour (see http= ://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4).
 
Dave
----- Original Message -----
From:=20 Bennett, Patrick
Sent: Tuesday, June 14, 2005 = 4:09=20 PM
Subject: [Speechsc] Problem = with draft-6=20 RECOGNIZE command and test/uri-listcontent type

According to the latest = draft on=20 page 89:

 

   =85The = RECOGNIZE method=20 MUST carry the grammars that need to be

   activated = for that=20 RECOGNIZE method, in its message body. The

   grammars = that need to=20 be activated can be specified in one of 3

   ways. The = grammar=20 content could be specified as a mime-content in

   the message = body. It=20 could be a simple list of grammar URIs

   specified = in a=20 mime-content of type text/uri-list, in which case the =

   order of = the URI=20 refer to the precedence order of the grammars

   during the = recognize.=20 =85

 

The problem here is the = statement=20 =93in which case the order of the URI refer to the precedence order of = the=20 grammars during the recognize.=94

Well, what is the EXACT=20 precedence?  Shouldn=92t each of the grammars be considered as = equally=20 weighted alternatives?  Ideally, all must be weighted equally = unless a=20 specific weight parameter was specified with each = URI.

As currently specified, = this part=20 of the specification is basically worthless.  No MRCP client = would ever=20 send multiple URIs to an MRCP server via a uri-list since the = weighting=20 applied to each grammar is completely undefined.

This really needs to be=20 corrected.

 

Patrick=20 Bennett

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_029A_01C570FD.A2665760-- --===============0100253595== 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 --===============0100253595==-- From speechsc-bounces@ietf.org Tue Jun 14 12:01:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDqb-0002OG-0z; Tue, 14 Jun 2005 12:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDqZ-0002O9-Cs for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29624 for ; Tue, 14 Jun 2005 12:01:00 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiED3-0001r5-Qa for Speechsc@ietf.org; Tue, 14 Jun 2005 12:24:19 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_10_59_43 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 10:59:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type Date: Tue, 14 Jun 2005 11:00:53 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B33901786CBF@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type Thread-Index: AcVw9UHousEtkbW4Qaq3do0m7nu7PwAAwuJw From: "Bennett, Patrick" To: "Dave Burke" , X-Spam-Score: 0.3 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df 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="===============1327939439==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1327939439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570FA.3DE85637" This is a multi-part message in MIME format. ------_=_NextPart_001_01C570FA.3DE85637 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the MRCP spec is indeed referring to what you say, then it definitely needs re-worded. It is far from clear from the specification that this is a precedence of how in-grammar ambiguities are resolved. If in fact the MRCP spec wants to mirror VoiceXML's definition (which IMO is also poorly defined) then it needs to specifically reference it. =20 ________________________________ From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Tuesday, June 14, 2005 10:25 AM To: Bennett, Patrick; Speechsc@ietf.org Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type =20 The precedence is not related to weighting. The text here covers the case if you had two grammars say gram1.grxml and gram2.grxml both of which recognise the token "speech" but return a different semantic interpretation. If gram2.grxml follows gram1.grxml in the uri-list then it is gram1.grxml that is matched and it is gram1.grxml's semantic interpretation result that is returned in the NLSML. =20 This is also required for VoiceXML 2.x behaviour (see http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). =20 Dave ----- Original Message -----=20 From: Bennett, Patrick =20 To: Speechsc@ietf.org=20 Sent: Tuesday, June 14, 2005 4:09 PM Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type =20 According to the latest draft on page 89: =20 ...The RECOGNIZE method MUST carry the grammars that need to be=20 activated for that RECOGNIZE method, in its message body. The grammars that need to be activated can be specified in one of 3=20 ways. The grammar content could be specified as a mime-content in=20 the message body. It could be a simple list of grammar URIs=20 specified in a mime-content of type text/uri-list, in which case the=20 order of the URI refer to the precedence order of the grammars=20 during the recognize. ... =20 The problem here is the statement "in which case the order of the URI refer to the precedence order of the grammars during the recognize." Well, what is the EXACT precedence? Shouldn't each of the grammars be considered as equally weighted alternatives? Ideally, all must be weighted equally unless a specific weight parameter was specified with each URI. As currently specified, this part of the specification is basically worthless. No MRCP client would ever send multiple URIs to an MRCP server via a uri-list since the weighting applied to each grammar is completely undefined. This really needs to be corrected. =20 Patrick Bennett =09 ________________________________ _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------_=_NextPart_001_01C570FA.3DE85637 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the MRCP spec is indeed = referring to what you say, then it definitely needs re-worded.  It is far from = clear from the specification that this is a precedence of how in-grammar = ambiguities are resolved.  If in fact the MRCP spec wants to mirror = VoiceXML’s definition (which IMO is also poorly defined) then it needs to = specifically reference it.

 

From: Dave = Burke [mailto:david.burke@voxpilot.com]
Sent: Tuesday, June 14, = 2005 10:25 AM
To: Bennett, Patrick; Speechsc@ietf.org
Subject: Re: [Speechsc] = Problem with draft-6 RECOGNIZE command and test/uri-listcontent = type

 

The precedence is not related to weighting. The text = here covers the case if you had two grammars say gram1.grxml and gram2.grxml = both of which recognise the token "speech" but return a different = semantic interpretation. If gram2.grxml follows gram1.grxml in the uri-list then = it is gram1.grxml that is matched and it is gram1.grxml's semantic = interpretation result that is returned in the NLSML.

 

This is also required for VoiceXML 2.x behaviour = (see http= ://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4).

 

Dave

----- Original Message -----

Sent: = Tuesday, June 14, 2005 4:09 PM

Subject: = [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent = type

 

According to the latest draft on page = 89:

 

   …The RECOGNIZE method MUST carry = the grammars that need to be

   activated for that RECOGNIZE method, in = its message body. The

   grammars that need to be activated can = be specified in one of 3

   ways. The grammar content could be = specified as a mime-content in

   the message body. It could be a simple = list of grammar URIs

   specified in a mime-content of type text/uri-list, in which case the

   order of the URI refer to the precedence = order of the grammars

   during the recognize. = …

 

The problem here is the statement “in which = case the order of the URI refer to the precedence order of the grammars during = the recognize.”

Well, what is the EXACT precedence? =  Shouldn’t each of the grammars be considered as equally weighted = alternatives?  Ideally, all must be weighted equally unless a specific weight parameter = was specified with each URI.

As currently specified, this part of the = specification is basically worthless.  No MRCP client would ever send multiple URIs = to an MRCP server via a uri-list since the weighting applied to each grammar = is completely undefined.

This really needs to be corrected.

 

Patrick Bennett

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

------_=_NextPart_001_01C570FA.3DE85637-- --===============1327939439== 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 --===============1327939439==-- From speechsc-bounces@ietf.org Tue Jun 14 12:02:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDsC-0002Y8-3S; Tue, 14 Jun 2005 12:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiDsA-0002Y2-UX for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29838 for ; Tue, 14 Jun 2005 12:02:40 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEEg-00020z-ST for speechsc@ietf.org; Tue, 14 Jun 2005 12:25:59 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2005 09:02:33 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5EG2Plw008014; Tue, 14 Jun 2005 09:02:25 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5EFo9vm011971; Tue, 14 Jun 2005 08:50:10 -0700 In-Reply-To: <029d01c570f5$40b2b840$cb00000a@db01.voxpilot.com> References: <260A0A30F9017945932CC4F7B911B33901786CBC@i3mail1.i3domain.inin.com> <029d01c570f5$40b2b840$cb00000a@db01.voxpilot.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <1ABE3C8D-051F-4A62-9F59-8B35AA16B987@cisco.com> Content-Transfer-Encoding: quoted-printable From: "David R. Oran" Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type Date: Tue, 14 Jun 2005 12:02:26 -0400 To: Dave Burke X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118764211.327902"; x:"432200"; a:"rsa-sha1"; b:"nofws:3078"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"fTZ3BakHesZMq7emP9RC4rwaSczTgRybSwvkNqatfnKWI/ChudDhJUI7cWAmTHyVMzefTKFw" "dkt4P5CBk23gNa3FoihpGTZydPtu6RuL46W0R1SUlD43zRDdLvPn2fUI32yqzEF+f6AygTzwyxB" "xEGDaDZKBRfp+eOA8kKySHvU="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command and t" "est/uri-listcontent type"; c:"Date: Tue, 14 Jun 2005 12:02:26 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Bennett, Patrick" 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 agree with Dave, but I also believe the current text is quite =20 torturous and prone to misinterpretation. I had held off screwing =20 around with it because of my shaky understanding of the "one-of-rule-=20 id" stuff but now that I think I can get it right I've taken a whack =20 at it. This is what the in-progress version of the spec says: The RECOGNIZE request uses the message body to specify the grammars =20 applicable to the request. The active grammar(s) for the request can =20 be specified in one of 3 ways. 1. The grammer may be placed directly in the message body using MIME =20 content. If more than one grammar is included in the body, the order =20 of inclusion controls the corresponding precedence for the grammars =20 during recognition. 2. The body may contain a list of grammar URIs specified in a mime-=20 content of type text/uri-list. The order of the URIs determines the =20 corrensponding precedence for the grammars during recognition. 3. The active grammar among a set of grammars can specified using a =20 One-Of-Rule-Id-URI header in the message. This header (see Section =20 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific rule-id =20 contained in the grammar (or grammars) specified in the body of the =20 message. Are further adjustments needed? On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: > The precedence is not related to weighting. The text here covers =20 > the case if you had two grammars say gram1.grxml and gram2.grxml =20 > both of which recognise the token "speech" but return a different =20 > semantic interpretation. If gram2.grxml follows gram1.grxml in the =20 > uri-list then it is gram1.grxml that is matched and it is =20 > gram1.grxml's semantic interpretation result that is returned in =20 > the NLSML. > > This is also required for VoiceXML 2.x behaviour (see http://=20 > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > Dave > ----- Original Message ----- > From: Bennett, Patrick > To: Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 4:09 PM > Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/=20= > uri-listcontent type > > According to the latest draft on page 89: > > > =85The RECOGNIZE method MUST carry the grammars that need to be > > activated for that RECOGNIZE method, in its message body. The > > grammars that need to be activated can be specified in one of 3 > > ways. The grammar content could be specified as a mime-content in > > the message body. It could be a simple list of grammar URIs > > specified in a mime-content of type text/uri-list, in which case =20= > the > > order of the URI refer to the precedence order of the grammars > > during the recognize. =85 > > > The problem here is the statement =93in which case the order of the =20= > URI refer to the precedence order of the grammars during the =20 > recognize.=94 > > Well, what is the EXACT precedence? Shouldn=92t each of the grammars =20= > be considered as equally weighted alternatives? Ideally, all must =20 > be weighted equally unless a specific weight parameter was =20 > specified with each URI. > > As currently specified, this part of the specification is basically =20= > worthless. No MRCP client would ever send multiple URIs to an MRCP =20= > server via a uri-list since the weighting applied to each grammar =20 > is completely undefined. > > This really needs to be corrected. > > > Patrick Bennett > > > > _______________________________________________ > 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 Tue Jun 14 12:20:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE9e-0007MR-1i; Tue, 14 Jun 2005 12:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE9c-0007Lt-3a for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:20:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01540 for ; Tue, 14 Jun 2005 12:20:41 -0400 (EDT) Received: from [199.4.160.64] (helo=pb-exchcon2.scansoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEVo-00038o-3m for Speechsc@ietf.org; Tue, 14 Jun 2005 12:44:00 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 14 Jun 2005 11:47:10 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , Dave Burke Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 08:51:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 Is 4) a realistic scenario? It would require that the MRCP server know each other, which results in a configuration nightmare. And what happens if one of them is down just at that moment... Slight reformulation of 2): An MRCP server may cache a compiled version of a grammar Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Dienstag, 14. Juni 2005 14:31 To: Dave Burke Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix Subject: Re: [Speechsc] Managing big grammars I like Dave's formulation. If there are no objections, I'm going to craft this into a sub-section on "Grammar Caching" under the section on "Grammar Data". On looking where to put this, I noticed that the description is under 9.5.1 "recognizer Grammar Data" which is under "Recognizer message body". Some of that material isn't really about message body (since it talks about ow indirect content is handled), so I'm going to re-jigger things a bit to improve the flow and move the parts about indirect content to the new earlier section. Speak now if you don't like this, because I'm going to do this later today... On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: > That optimisation would be nice alright and is not restricted by HTTP > (see note from RFC 2616 below). > > It seems like we have got some good optimisation suggestions (read: > informative) that could go into the spec to address large grammars. > If memory serves, they are: > 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or > RECOGNIZE to be used over multiple MRCP sessions > 2. An MRCP server may cache the compiled version of a grammar > 3. An MRCP server may cache grammars centrally to allow other > servers take advantage of the cache > 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform > other MRCP servers to reload the new grammar into memory > 5. An MRCP server may choose to return a stale response while a > new grammar is being downloaded, compiled, and cached > > -- Dave > > From RFC 2616: > > In some cases, the operator of a cache MAY choose to configure it > to > return stale responses even when not requested by clients. This > decision ought not be made lightly, but may be necessary for > reasons > of availability or performance, especially when the cache is poorly > connected to the origin server. Whenever a cache returns a stale > response, it MUST mark it as such (using a Warning header) enabling > the client software to alert the user that there might be a > potential > problem. > > > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 12:04 PM > Subject: RE: [Speechsc] Managing big grammars > > cool. That makes sense. > The way I though this problem would have been addressed, is the MRCP > caching system to be smart. > That is everytime there is a request a grammar for a grammar URI. > the MRCP server would do a fetch to check if the document has changed. > If it has, then it would download and compile the grammar. > While this happenning existing calls that were using the older > compiled grammar continue to use it. Once this is ready, the previous > version of the grammar is allowed to expire-out. > > Would this not address your scenario and avoid having to do this work > around you are suggesting? > > Sarvi > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 14, 2005 3:16 AM > To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > It's not that the URL needs a specific date or time, just that it has > a unique name. This is simply so that you can ensure the new grammar > is downloaded, compiled, and loaded ahead of any calls. > Once compiled and loaded, the application grammar URIs can be updated > to reference the new grammar. This way you avoid the danger that a > bunch of calls, which arrive at the same time as the DEFINE- GRAMMAR > is happening, experience delays. > > Dave > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 7:58 AM > Subject: RE: [Speechsc] Managing big grammars > > I dont understand why the RUL has to encode and date and time into it. > Lets say we are refering to large_grammar.grxml > > When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. > The MRCP server is expected to go download this URI and compile it. > The caching behaviour of this URI and how long it lives in the cache > is dependent on what is returned by the HTTP GET operation that > brought the grammar into the MRCP server. In addition, the behaviour > is also governed by Cache -Control parameters that the client can > specify for the DEFINE-GRAMMAR that would take precedence over what > was returned by the HTTP GET operation. This means that the MRCP > client can force the MRCP server to ignore the cache parameters it got > from the grammar webserver. > > So, for the large_grammar.grxml, if the webserver returned a large > max-age value the grammar and its compiled version in the cache of the > MRCP server should not get timedout. For any future requests for that > grammar, MRCP server should go do fetch of the document, compare the > max-age of the fetched coument and make sure the webserver says that > the document in the cache is not out-of-date. > As long as the grammar document in the cache is not out of date, you > don't need to compile it again and you are fine. If the propoerty of > the large_grammar.grxml on the webserver had changed then the MRCP > server would be expected to refresh the cache and compile the newly > downloaded grammar. > > > Am I missing something here. > > Sarvi > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Sunday, June 12, 2005 12:12 PM > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > There is no doubt that grammar compilation and loading must be hidden > from the caller experience. What is in doubt is whether the MRCP > protocol needs to expose such control. > > The grammar loading problem is not dissimilar to cache seeding in the > Web world. Taking your use-case, I would implement this in MRCP as a > two-step process: > > (1) Make the large grammar available through HTTP and date-stamp the > URI, e.g. http://example.com/large_grammar_12June2005.grxml. > Set the HTTP response header Cache-Control: max-age to a value larger > than the grammar change period. > > (2) When a new grammar is required, open an MRCP channel to each of > the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. > http://example.com/large_grammar_13June2005.grxml. Update the > application to point at the new grammar. > > [For a mid-size grammar where loading latency is negligible, and > assuming a centrally located compiled grammar cache, step (2) might > only require a DEFINE-GRAMMAR to one MRCP server]. > > You are correct that the current MRCPv2 draft scopes the DEFINE- > GRAMMAR to a channel and this is a concern. However, this is resolved > with Sarvi's suggested text change. > > Dave > ----- Original Message ----- > From: Wyss, Felix > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; > Speechsc@ietf.org > Sent: Sunday, June 12, 2005 1:41 AM > Subject: RE: [Speechsc] Managing big grammars > > I disagree. Predictability is *very* critical for an application > using ASR. It must be able to make sure that when a recognition > operation is started, there is no latency while the ASR server > compiles and/or loads a large precompiled grammar into memory. The > DEFINE-GRAMMAR command is scoped to a channel, which means by the time > the application has a channel (i.e. a caller is in the system), it is > unacceptable to block for more than fraction of a > second while the grammars are being compiled and/or loaded. > Otherwise, the first caller after a grammar is changed encounters > delays and has a poor user experience or even hangs up. Somebody may > say: well, just make a "priming" call after modifying the grammar to > ensure the grammar is cached. However, that is not very practical for > automatically generated grammars; but worse yet, in large systems > there are commonly several load-balanced ASR severs and it will be > rather hard to ensure each of them is touched at least once. > > > > The way we solve this on our platform is as follows: Large grammars > that may change frequently, possibly several times a day, such as > company directory grammars that are generated from a database, can be > registered as "preloaded grammars". This means, our platform ensures > the grammar is compiled, distributed to all ASR servers, and loaded > into their caches after a new version of that grammar has been > generated. Each preloaded grammar has a name associated, which is > referenced through a special URI. The application logic only knows > that URI and not the actual URI/filename of the underlying grammar > data. The subsystem managing the preloaded grammars ensures that the > preloaded grammar URI resolves to the previous version of the grammar > until the new grammar is loaded and ready on all ASR servers. Thus, > all callers that call into the system while the grammar is being > generated, compiled, and loaded on the servers will get the previous > version. This ensures that there is no delay for the first caller > after a change. We can do this as we are using the native APIs > provided by the ASR engine vendors we support and layer a > sophisticated framework and API on top of it. > > > > It would be nice if MRCP provided some support for schemes like that, > without having to open dummy channels to register grammars and pray > the MRCP server doesn't evict them too early. An MRCP client has to > be able to guarantee that when a call comes through > the system, everything is ready and it won't experience any delay. > As it stands now the MRCP protocol does not appear to provide support > for this. > > > > Thanks, > > Felix > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Saturday, June 11, 2005 10:42 > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > > > I agree. Grammar compilation, caching, and sharing is a problem for > the MRCP server. Exposing this in the protocol puts unnecessary > complexity on the client. For example, the client needs to download > grammars, implement its own HTTP caching, checksum algorithms (some > way of not having to push huge data to the MRCP server to query) etc. > > > > So I vote for point 1 below and include in the text that an MRCP > server could also, as an optimisation, implement a centralised > common cache shared across multiple MRCP servers. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Corby Anderson ; Speechsc@ietf.org > > Sent: Saturday, June 11, 2005 12:09 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I would say that a common cache amoung a farm of MRCP servers to > optimize compilations would be a nice server side optimization and > shouldn't affect the MRCP protocol. > > > > my 2c. > > Sarvi > > _______________________________________________ > 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 Tue Jun 14 12:20:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE9m-0007N2-Hq; Tue, 14 Jun 2005 12:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiE9l-0007Mx-UR for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:20:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01543 for ; Tue, 14 Jun 2005 12:20:51 -0400 (EDT) Received: from [199.4.160.64] (helo=pb-exchcon2.scansoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEW9-00038o-9p for Speechsc@ietf.org; Tue, 14 Jun 2005 12:44:10 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 14 Jun 2005 11:54:53 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Bennett, Patrick'" , Speechsc@ietf.org Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE command and test/ur i-list content type Date: Tue, 14 Jun 2005 11:28:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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="===============1194081836==" 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. --===============1194081836== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570F5.AFFECEDC" 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_01C570F5.AFFECEDC Content-Type: text/plain We should add support of grammar weights (e.g. required by the weight attribute of the element of VoiceXML 2.0; http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.1.3 ) to MRCPv2. Klaus _____ From: Bennett, Patrick [mailto:Patrick.Bennett@inin.com] Sent: Dienstag, 14. Juni 2005 17:09 To: Speechsc@ietf.org Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-list content type According to the latest draft on page 89: ...The RECOGNIZE method MUST carry the grammars that need to be activated for that RECOGNIZE method, in its message body. The grammars that need to be activated can be specified in one of 3 ways. The grammar content could be specified as a mime-content in the message body. It could be a simple list of grammar URIs specified in a mime-content of type text/uri-list, in which case the order of the URI refer to the precedence order of the grammars during the recognize. ... The problem here is the statement "in which case the order of the URI refer to the precedence order of the grammars during the recognize." Well, what is the EXACT precedence? Shouldn't each of the grammars be considered as equally weighted alternatives? Ideally, all must be weighted equally unless a specific weight parameter was specified with each URI. As currently specified, this part of the specification is basically worthless. No MRCP client would ever send multiple URIs to an MRCP server via a uri-list since the weighting applied to each grammar is completely undefined. This really needs to be corrected. Patrick Bennett ------_=_NextPart_001_01C570F5.AFFECEDC Content-Type: text/html
We should add support of grammar weights (e.g. required by the weight attribute of the <grammar> element of VoiceXML 2.0; http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.1.3) to MRCPv2.
 
Klaus

From: Bennett, Patrick [mailto:Patrick.Bennett@inin.com]
Sent: Dienstag, 14. Juni 2005 17:09
To: Speechsc@ietf.org
Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-list content type

According to the latest draft on page 89:

 

   ...The RECOGNIZE method MUST carry the grammars that need to be

   activated for that RECOGNIZE method, in its message body. The

   grammars that need to be activated can be specified in one of 3

   ways. The grammar content could be specified as a mime-content in

   the message body. It could be a simple list of grammar URIs

   specified in a mime-content of type text/uri-list, in which case the

   order of the URI refer to the precedence order of the grammars

   during the recognize. ...

 

The problem here is the statement "in which case the order of the URI refer to the precedence order of the grammars during the recognize."

Well, what is the EXACT precedence?  Shouldn't each of the grammars be considered as equally weighted alternatives?  Ideally, all must be weighted equally unless a specific weight parameter was specified with each URI.

As currently specified, this part of the specification is basically worthless.  No MRCP client would ever send multiple URIs to an MRCP server via a uri-list since the weighting applied to each grammar is completely undefined.

This really needs to be corrected.

 

Patrick Bennett

------_=_NextPart_001_01C570F5.AFFECEDC-- --===============1194081836== 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 --===============1194081836==-- From speechsc-bounces@ietf.org Tue Jun 14 12:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEOm-000262-TQ; Tue, 14 Jun 2005 12:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEOk-00025x-TA for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02558 for ; Tue, 14 Jun 2005 12:36:20 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiElG-0004D0-RA for Speechsc@ietf.org; Tue, 14 Jun 2005 12:59:39 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_11_35_03 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 11:35:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 11:36:13 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B33901786CC4@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVw/Tmq1zUdWpz8QDyYmQ5M2ZIfXAAABMBQ From: "Bennett, Patrick" To: "Reifenrath, Klaus" , "David R. Oran" , "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 > An MRCP server may cache a compiled version of a grammar What good is this? The more MAYs you have in the specification, the more it becomes unusuable by clients. While server implementers certainly love MAYs (or to some extent even the SHOULDs) in RFC's (it lets them take shortcuts), implementors who actually have to USE the protocol, despise them. RFCs littered with 'may do x' are nothing more than general guidelines, not the strict protocol and behavioral specification which MRCP requires. If needs to be to be usable by carrier grade and scale implementors. This isn't possible when the MRCP servers MAY do something. I guess I could just say, the MRCP spec MAY be unusable for anything other a simple test system with trivial, *static* grammars with no more than a few concurrent sessions. =20 > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On > Behalf Of Reifenrath, Klaus > Sent: Tuesday, June 14, 2005 7:52 AM > To: 'David R. Oran'; Dave Burke > Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix > Subject: RE: [Speechsc] Managing big grammars >=20 > Is 4) a realistic scenario? It would require that the MRCP server know > each > other, which results in a configuration nightmare. And what happens if one > of them is down just at that moment... >=20 > Slight reformulation of 2): > An MRCP server may cache a compiled version of a grammar >=20 > Klaus >=20 > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Dienstag, 14. Juni 2005 14:31 > To: Dave Burke > Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix > Subject: Re: [Speechsc] Managing big grammars >=20 > I like Dave's formulation. If there are no objections, I'm going to craft > this into a sub-section on "Grammar Caching" under the section on > "Grammar > Data". On looking where to put this, I noticed that the description is > under > 9.5.1 "recognizer Grammar Data" which is under "Recognizer message body". > Some of that material isn't really about message body (since it talks > about > ow indirect content is handled), so I'm going to re-jigger things a bit to > improve the flow and move the parts about indirect content to the new > earlier section. >=20 > Speak now if you don't like this, because I'm going to do this later > today... >=20 > On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: >=20 > > That optimisation would be nice alright and is not restricted by HTTP > > (see note from RFC 2616 below). > > > > It seems like we have got some good optimisation suggestions (read: > > informative) that could go into the spec to address large grammars. > > If memory serves, they are: > > 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or > > RECOGNIZE to be used over multiple MRCP sessions > > 2. An MRCP server may cache the compiled version of a grammar > > 3. An MRCP server may cache grammars centrally to allow other > > servers take advantage of the cache > > 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform > > other MRCP servers to reload the new grammar into memory > > 5. An MRCP server may choose to return a stale response while a > > new grammar is being downloaded, compiled, and cached > > > > -- Dave > > > > From RFC 2616: > > > > In some cases, the operator of a cache MAY choose to configure it > > to > > return stale responses even when not requested by clients. This > > decision ought not be made lightly, but may be necessary for > > reasons > > of availability or performance, especially when the cache is poorly > > connected to the origin server. Whenever a cache returns a stale > > response, it MUST mark it as such (using a Warning header) enabling > > the client software to alert the user that there might be a > > potential > > problem. > > > > > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > > Sent: Tuesday, June 14, 2005 12:04 PM > > Subject: RE: [Speechsc] Managing big grammars > > > > cool. That makes sense. > > The way I though this problem would have been addressed, is the MRCP > > caching system to be smart. > > That is everytime there is a request a grammar for a grammar URI. > > the MRCP server would do a fetch to check if the document has changed. > > If it has, then it would download and compile the grammar. > > While this happenning existing calls that were using the older > > compiled grammar continue to use it. Once this is ready, the previous > > version of the grammar is allowed to expire-out. > > > > Would this not address your scenario and avoid having to do this work > > around you are suggesting? > > > > Sarvi > > > > From: Dave Burke [mailto:david.burke@voxpilot.com] > > Sent: Tuesday, June 14, 2005 3:16 AM > > To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; > > Speechsc@ietf.org > > Subject: Re: [Speechsc] Managing big grammars > > > > It's not that the URL needs a specific date or time, just that it has > > a unique name. This is simply so that you can ensure the new grammar > > is downloaded, compiled, and loaded ahead of any calls. > > Once compiled and loaded, the application grammar URIs can be updated > > to reference the new grammar. This way you avoid the danger that a > > bunch of calls, which arrive at the same time as the DEFINE- GRAMMAR > > is happening, experience delays. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > > Sent: Tuesday, June 14, 2005 7:58 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I dont understand why the RUL has to encode and date and time into it. > > Lets say we are refering to large_grammar.grxml > > > > When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. > > The MRCP server is expected to go download this URI and compile it. > > The caching behaviour of this URI and how long it lives in the cache > > is dependent on what is returned by the HTTP GET operation that > > brought the grammar into the MRCP server. In addition, the behaviour > > is also governed by Cache -Control parameters that the client can > > specify for the DEFINE-GRAMMAR that would take precedence over what > > was returned by the HTTP GET operation. This means that the MRCP > > client can force the MRCP server to ignore the cache parameters it got > > from the grammar webserver. > > > > So, for the large_grammar.grxml, if the webserver returned a large > > max-age value the grammar and its compiled version in the cache of the > > MRCP server should not get timedout. For any future requests for that > > grammar, MRCP server should go do fetch of the document, compare the > > max-age of the fetched coument and make sure the webserver says that > > the document in the cache is not out-of-date. > > As long as the grammar document in the cache is not out of date, you > > don't need to compile it again and you are fine. If the propoerty of > > the large_grammar.grxml on the webserver had changed then the MRCP > > server would be expected to refresh the cache and compile the newly > > downloaded grammar. > > > > > > Am I missing something here. > > > > Sarvi > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > > On Behalf Of Dave Burke > > Sent: Sunday, June 12, 2005 12:12 PM > > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; > > Speechsc@ietf.org > > Subject: Re: [Speechsc] Managing big grammars > > > > There is no doubt that grammar compilation and loading must be hidden > > from the caller experience. What is in doubt is whether the MRCP > > protocol needs to expose such control. > > > > The grammar loading problem is not dissimilar to cache seeding in the > > Web world. Taking your use-case, I would implement this in MRCP as a > > two-step process: > > > > (1) Make the large grammar available through HTTP and date-stamp the > > URI, e.g. http://example.com/large_grammar_12June2005.grxml. > > Set the HTTP response header Cache-Control: max-age to a value larger > > than the grammar change period. > > > > (2) When a new grammar is required, open an MRCP channel to each of > > the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. > > http://example.com/large_grammar_13June2005.grxml. Update the > > application to point at the new grammar. > > > > [For a mid-size grammar where loading latency is negligible, and > > assuming a centrally located compiled grammar cache, step (2) might > > only require a DEFINE-GRAMMAR to one MRCP server]. > > > > You are correct that the current MRCPv2 draft scopes the DEFINE- > > GRAMMAR to a channel and this is a concern. However, this is resolved > > with Sarvi's suggested text change. > > > > Dave > > ----- Original Message ----- > > From: Wyss, Felix > > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; > > Speechsc@ietf.org > > Sent: Sunday, June 12, 2005 1:41 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I disagree. Predictability is *very* critical for an application > > using ASR. It must be able to make sure that when a recognition > > operation is started, there is no latency while the ASR server > > compiles and/or loads a large precompiled grammar into memory. The > > DEFINE-GRAMMAR command is scoped to a channel, which means by the time > > the application has a channel (i.e. a caller is in the system), it is > > unacceptable to block for more than fraction of a > > second while the grammars are being compiled and/or loaded. > > Otherwise, the first caller after a grammar is changed encounters > > delays and has a poor user experience or even hangs up. Somebody may > > say: well, just make a "priming" call after modifying the grammar to > > ensure the grammar is cached. However, that is not very practical for > > automatically generated grammars; but worse yet, in large systems > > there are commonly several load-balanced ASR severs and it will be > > rather hard to ensure each of them is touched at least once. > > > > > > > > The way we solve this on our platform is as follows: Large grammars > > that may change frequently, possibly several times a day, such as > > company directory grammars that are generated from a database, can be > > registered as "preloaded grammars". This means, our platform ensures > > the grammar is compiled, distributed to all ASR servers, and loaded > > into their caches after a new version of that grammar has been > > generated. Each preloaded grammar has a name associated, which is > > referenced through a special URI. The application logic only knows > > that URI and not the actual URI/filename of the underlying grammar > > data. The subsystem managing the preloaded grammars ensures that the > > preloaded grammar URI resolves to the previous version of the grammar > > until the new grammar is loaded and ready on all ASR servers. Thus, > > all callers that call into the system while the grammar is being > > generated, compiled, and loaded on the servers will get the previous > > version. This ensures that there is no delay for the first caller > > after a change. We can do this as we are using the native APIs > > provided by the ASR engine vendors we support and layer a > > sophisticated framework and API on top of it. > > > > > > > > It would be nice if MRCP provided some support for schemes like that, > > without having to open dummy channels to register grammars and pray > > the MRCP server doesn't evict them too early. An MRCP client has to > > be able to guarantee that when a call comes through > > the system, everything is ready and it won't experience any delay. > > As it stands now the MRCP protocol does not appear to provide support > > for this. > > > > > > > > Thanks, > > > > Felix > > > > > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > > On Behalf Of Dave Burke > > Sent: Saturday, June 11, 2005 10:42 > > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > > Subject: Re: [Speechsc] Managing big grammars > > > > > > > > I agree. Grammar compilation, caching, and sharing is a problem for > > the MRCP server. Exposing this in the protocol puts unnecessary > > complexity on the client. For example, the client needs to download > > grammars, implement its own HTTP caching, checksum algorithms (some > > way of not having to push huge data to the MRCP server to query) etc. > > > > > > > > So I vote for point 1 below and include in the text that an MRCP > > server could also, as an optimisation, implement a centralised > > common cache shared across multiple MRCP servers. > > > > > > > > Dave > > > > ----- Original Message ----- > > > > From: Shanmugham, Saravanan > > > > To: Corby Anderson ; Speechsc@ietf.org > > > > Sent: Saturday, June 11, 2005 12:09 AM > > > > Subject: RE: [Speechsc] Managing big grammars > > > > > > > > I would say that a common cache amoung a farm of MRCP servers to > > optimize compilations would be a nice server side optimization and > > shouldn't affect the MRCP protocol. > > > > > > > > my 2c. > > > > Sarvi > > > > _______________________________________________ > > 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 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 14 12:41:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiETr-0002Ys-4E; Tue, 14 Jun 2005 12:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiETp-0002Yn-PM for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02862 for ; Tue, 14 Jun 2005 12:41:35 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiEqK-0004RQ-JI for Speechsc@ietf.org; Tue, 14 Jun 2005 13:04:54 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 7713F2140F4; Tue, 14 Jun 2005 16:41:19 +0000 (GMT) Message-ID: <039601c570ff$e3c9ed00$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "David R. Oran" References: <260A0A30F9017945932CC4F7B911B33901786CBC@i3mail1.i3domain.inin.com><029d01c570f5$40b2b840$cb00000a@db01.voxpilot.com> <1ABE3C8D-051F-4A62-9F59-8B35AA16B987@cisco.com> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command andtest/uri-listcontent type Date: Tue, 14 Jun 2005 17:41:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Bennett, Patrick" 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 To be clear, I think there are two issues: A. How to word the precedence when input matches more than one active=20 grammar? B. How to specify a weight for a complete grammar? (see=20 http://www1.ietf.org/mail-archive/web/speechsc/current/msg01023.html) For A, how about appending the sentence in 1. and 2. so that we get: ...the order of inclusion controls the corresponding precedence for the=20 grammars during recognition should the input match more than one active grammar. For B, which point 3 addresses, there are three options discussed: (i) Use the One-Of-Rule-Id-URI mechanism below (ii) Add an informative note that a grammar can be used to apply= =20 weights to grammars (One-Of-Rule-Id-URI is unnecessary ) (iii) Go with Jeff's idea of adding a new header to a MIME part=20 (http://www1.ietf.org/mail-archive/web/speechsc/current/msg01102.html) Sm= all=20 refinement though, the header should be called Content-Grammar-Weight to = fit=20 RFC2045's extension mechanism My preference is for (iii) over (ii) because if my MRCP client runs Voice= XML=20 then I'm going to have to handle cases when has a weight attrib= ute=20 and build up a grammar. This is just annoying complexity for the= =20 client. Dave ----- Original Message -----=20 From: "David R. Oran" To: "Dave Burke" Cc: ; "Bennett, Patrick" Sent: Tuesday, June 14, 2005 5:02 PM Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command=20 andtest/uri-listcontent type I agree with Dave, but I also believe the current text is quite torturous and prone to misinterpretation. I had held off screwing around with it because of my shaky understanding of the "one-of-rule- id" stuff but now that I think I can get it right I've taken a whack at it. This is what the in-progress version of the spec says: The RECOGNIZE request uses the message body to specify the grammars applicable to the request. The active grammar(s) for the request can be specified in one of 3 ways. 1. The grammer may be placed directly in the message body using MIME content. If more than one grammar is included in the body, the order of inclusion controls the corresponding precedence for the grammars during recognition. 2. The body may contain a list of grammar URIs specified in a mime- content of type text/uri-list. The order of the URIs determines the corrensponding precedence for the grammars during recognition. 3. The active grammar among a set of grammars can specified using a One-Of-Rule-Id-URI header in the message. This header (see Section 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific rule-id contained in the grammar (or grammars) specified in the body of the message. Are further adjustments needed? On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: > The precedence is not related to weighting. The text here covers the c= ase=20 > if you had two grammars say gram1.grxml and gram2.grxml both of which=20 > recognise the token "speech" but return a different semantic=20 > interpretation. If gram2.grxml follows gram1.grxml in the uri-list the= n=20 > it is gram1.grxml that is matched and it is gram1.grxml's semantic=20 > interpretation result that is returned in the NLSML. > > This is also required for VoiceXML 2.x behaviour (see http://=20 > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > Dave > ----- Original Message ----- > From: Bennett, Patrick > To: Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 4:09 PM > Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/=20 > uri-listcontent type > > According to the latest draft on page 89: > > > =85The RECOGNIZE method MUST carry the grammars that need to be > > activated for that RECOGNIZE method, in its message body. The > > grammars that need to be activated can be specified in one of 3 > > ways. The grammar content could be specified as a mime-content in > > the message body. It could be a simple list of grammar URIs > > specified in a mime-content of type text/uri-list, in which case th= e > > order of the URI refer to the precedence order of the grammars > > during the recognize. =85 > > > The problem here is the statement =93in which case the order of the UR= I=20 > refer to the precedence order of the grammars during the recognize.=94 > > Well, what is the EXACT precedence? Shouldn=92t each of the grammars = be=20 > considered as equally weighted alternatives? Ideally, all must be=20 > weighted equally unless a specific weight parameter was specified with= =20 > each URI. > > As currently specified, this part of the specification is basically=20 > worthless. No MRCP client would ever send multiple URIs to an MRCP=20 > server via a uri-list since the weighting applied to each grammar is=20 > completely undefined. > > This really needs to be corrected. > > > Patrick Bennett > > > > _______________________________________________ > 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 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 14 12:53:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEfN-0004vJ-NC; Tue, 14 Jun 2005 12:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiEfL-0004vE-1k for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 12:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03491 for ; Tue, 14 Jun 2005 12:53:28 -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 1DiF1q-000591-OJ for speechsc@ietf.org; Tue, 14 Jun 2005 13:16:47 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 09:53:10 -0700 X-IronPort-AV: i="3.93,198,1115017200"; d="scan'208"; a="278587937:sNHT1299310532" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5EGr7lq028428; Tue, 14 Jun 2005 09:53:07 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5EGejjd012537; Tue, 14 Jun 2005 09:40:46 -0700 In-Reply-To: <260A0A30F9017945932CC4F7B911B33901786CC4@i3mail1.i3domain.inin.com> References: <260A0A30F9017945932CC4F7B911B33901786CC4@i3mail1.i3domain.inin.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74F60CB3-95CD-42F0-9F93-D8B93028BD8F@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 12:53:03 -0400 To: "Bennett, Patrick" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118767248.176663"; x:"432200"; a:"rsa-sha1"; b:"nofws:12634"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"YyhiJE9EILxGrkK+FvQo5x6e0iq1sGRTaNaPBH4pWhU5d5UURAuva3bNt6YHKqCcYzXKFQBt" "j3BX1BZT4lN7I+UgjJ5P1BrhVRg4VJWdScen+QcKLqPNs2Ejf1vmmlNhBANET1t96hyyt6Xckq+" "dFF5rdztgfn4fHz4hQ6dsG5w="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Managing big grammars"; c:"Date: Tue, 14 Jun 2005 12:53:03 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Content-Transfer-Encoding: 7bit Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , Dave Burke , "Wyss, Felix" , "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 On Jun 14, 2005, at 12:36 PM, Bennett, Patrick wrote: >> An MRCP server may cache a compiled version of a grammar >> > > What good is this? The more MAYs you have in the specification, the > more it becomes unusuable by clients. While server implementers > certainly love MAYs (or to some extent even the SHOULDs) in RFC's (it > lets them take shortcuts), implementors who actually have to USE the > protocol, despise them. RFCs littered with 'may do x' are nothing > more > than general guidelines, not the strict protocol and behavioral > specification which MRCP requires. > IETF protocol specifications are about simplicity, interoperability, robustness, and flexibility, and we generally weigh our specifications toward those goals over goals of vertically integrated solutions which operate within tight and predictable bounds. Nothing in the HTTP specification, for example, says anything about how dynamic web content is computed, or how servers implement content caching. If you are a system-builder you need to ensure that the components you select (e.g. MRCPv2 servers) meet the performance requirements for your applications. The current MRCPv2 design, as elaborated on by Sarvi, allows a client to ascertain to a limited degree whether a server is going to perform adequately (through the cache control parameters), but not to force a server to use any particular means to do so. I think this is the right tradeoff. You're certainly entitled to disagree. > If needs to be to be usable by carrier grade and scale implementors. > This isn't possible when the MRCP servers MAY do something. > I agree in the case where the results are semantically different and it is impossible for the client to ascertain what the server does, but not in cases where the alternative behaviors are explicitly there for flexibility and to avoid over-specification. > I guess I could just say, the MRCP spec MAY be unusable for anything > other a simple test system with trivial, *static* grammars with no > more > than a few concurrent sessions. > I think we have deployed experience with MRCPv1 (which says even less on the subject) that contradicts this observation. > >> -----Original Message----- >> From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On >> Behalf Of Reifenrath, Klaus >> Sent: Tuesday, June 14, 2005 7:52 AM >> To: 'David R. Oran'; Dave Burke >> Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix >> Subject: RE: [Speechsc] Managing big grammars >> >> Is 4) a realistic scenario? It would require that the MRCP server >> know >> each >> other, which results in a configuration nightmare. And what >> happens if >> > one > >> of them is down just at that moment... >> >> Slight reformulation of 2): >> An MRCP server may cache a compiled version of a grammar >> >> Klaus >> >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Dienstag, 14. Juni 2005 14:31 >> To: Dave Burke >> Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix >> Subject: Re: [Speechsc] Managing big grammars >> >> I like Dave's formulation. If there are no objections, I'm going to >> > craft > >> this into a sub-section on "Grammar Caching" under the section on >> "Grammar >> Data". On looking where to put this, I noticed that the >> description is >> under >> 9.5.1 "recognizer Grammar Data" which is under "Recognizer message >> > body". > >> Some of that material isn't really about message body (since it talks >> about >> ow indirect content is handled), so I'm going to re-jigger things a >> > bit to > >> improve the flow and move the parts about indirect content to the new >> earlier section. >> >> Speak now if you don't like this, because I'm going to do this later >> today... >> >> On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: >> >> >>> That optimisation would be nice alright and is not restricted by >>> > HTTP > >>> (see note from RFC 2616 below). >>> >>> It seems like we have got some good optimisation suggestions (read: >>> informative) that could go into the spec to address large grammars. >>> If memory serves, they are: >>> 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or >>> RECOGNIZE to be used over multiple MRCP sessions >>> 2. An MRCP server may cache the compiled version of a grammar >>> 3. An MRCP server may cache grammars centrally to allow other >>> servers take advantage of the cache >>> 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform >>> other MRCP servers to reload the new grammar into memory >>> 5. An MRCP server may choose to return a stale response while a >>> new grammar is being downloaded, compiled, and cached >>> >>> -- Dave >>> >>> From RFC 2616: >>> >>> In some cases, the operator of a cache MAY choose to configure it >>> to >>> return stale responses even when not requested by clients. This >>> decision ought not be made lightly, but may be necessary for >>> reasons >>> of availability or performance, especially when the cache is >>> > poorly > >>> connected to the origin server. Whenever a cache returns a stale >>> response, it MUST mark it as such (using a Warning header) >>> > enabling > >>> the client software to alert the user that there might be a >>> potential >>> problem. >>> >>> >>> ----- Original Message ----- >>> From: Shanmugham, Saravanan >>> To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org >>> Sent: Tuesday, June 14, 2005 12:04 PM >>> Subject: RE: [Speechsc] Managing big grammars >>> >>> cool. That makes sense. >>> The way I though this problem would have been addressed, is the MRCP >>> caching system to be smart. >>> That is everytime there is a request a grammar for a grammar URI. >>> the MRCP server would do a fetch to check if the document has >>> > changed. > >>> If it has, then it would download and compile the grammar. >>> While this happenning existing calls that were using the older >>> compiled grammar continue to use it. Once this is ready, the >>> > previous > >>> version of the grammar is allowed to expire-out. >>> >>> Would this not address your scenario and avoid having to do this >>> > work > >>> around you are suggesting? >>> >>> Sarvi >>> >>> From: Dave Burke [mailto:david.burke@voxpilot.com] >>> Sent: Tuesday, June 14, 2005 3:16 AM >>> To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; >>> Speechsc@ietf.org >>> Subject: Re: [Speechsc] Managing big grammars >>> >>> It's not that the URL needs a specific date or time, just that it >>> > has > >>> a unique name. This is simply so that you can ensure the new grammar >>> is downloaded, compiled, and loaded ahead of any calls. >>> Once compiled and loaded, the application grammar URIs can be >>> > updated > >>> to reference the new grammar. This way you avoid the danger that a >>> bunch of calls, which arrive at the same time as the DEFINE- GRAMMAR >>> is happening, experience delays. >>> >>> Dave >>> ----- Original Message ----- >>> From: Shanmugham, Saravanan >>> To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org >>> Sent: Tuesday, June 14, 2005 7:58 AM >>> Subject: RE: [Speechsc] Managing big grammars >>> >>> I dont understand why the RUL has to encode and date and time into >>> > it. > >>> Lets say we are refering to large_grammar.grxml >>> >>> When a client does a DEFINE-GRAMMAR on the MRCP server with this >>> > URI. > >>> The MRCP server is expected to go download this URI and compile it. >>> The caching behaviour of this URI and how long it lives in the cache >>> is dependent on what is returned by the HTTP GET operation that >>> brought the grammar into the MRCP server. In addition, the behaviour >>> is also governed by Cache -Control parameters that the client can >>> specify for the DEFINE-GRAMMAR that would take precedence over what >>> was returned by the HTTP GET operation. This means that the MRCP >>> client can force the MRCP server to ignore the cache parameters it >>> > got > >>> from the grammar webserver. >>> >>> So, for the large_grammar.grxml, if the webserver returned a large >>> max-age value the grammar and its compiled version in the cache of >>> > the > >>> MRCP server should not get timedout. For any future requests for >>> > that > >>> grammar, MRCP server should go do fetch of the document, compare the >>> max-age of the fetched coument and make sure the webserver says that >>> the document in the cache is not out-of-date. >>> As long as the grammar document in the cache is not out of date, you >>> don't need to compile it again and you are fine. If the propoerty of >>> the large_grammar.grxml on the webserver had changed then the MRCP >>> server would be expected to refresh the cache and compile the newly >>> downloaded grammar. >>> >>> >>> Am I missing something here. >>> >>> Sarvi >>> >>> From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] >>> On Behalf Of Dave Burke >>> Sent: Sunday, June 12, 2005 12:12 PM >>> To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; >>> Speechsc@ietf.org >>> Subject: Re: [Speechsc] Managing big grammars >>> >>> There is no doubt that grammar compilation and loading must be >>> > hidden > >>> from the caller experience. What is in doubt is whether the MRCP >>> protocol needs to expose such control. >>> >>> The grammar loading problem is not dissimilar to cache seeding in >>> > the > >>> Web world. Taking your use-case, I would implement this in MRCP as a >>> two-step process: >>> >>> (1) Make the large grammar available through HTTP and date-stamp the >>> URI, e.g. http://example.com/large_grammar_12June2005.grxml. >>> Set the HTTP response header Cache-Control: max-age to a value >>> > larger > >>> than the grammar change period. >>> >>> (2) When a new grammar is required, open an MRCP channel to each of >>> the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. >>> http://example.com/large_grammar_13June2005.grxml. Update the >>> application to point at the new grammar. >>> >>> [For a mid-size grammar where loading latency is negligible, and >>> assuming a centrally located compiled grammar cache, step (2) might >>> only require a DEFINE-GRAMMAR to one MRCP server]. >>> >>> You are correct that the current MRCPv2 draft scopes the DEFINE- >>> GRAMMAR to a channel and this is a concern. However, this is >>> > resolved > >>> with Sarvi's suggested text change. >>> >>> Dave >>> ----- Original Message ----- >>> From: Wyss, Felix >>> To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; >>> Speechsc@ietf.org >>> Sent: Sunday, June 12, 2005 1:41 AM >>> Subject: RE: [Speechsc] Managing big grammars >>> >>> I disagree. Predictability is *very* critical for an application >>> using ASR. It must be able to make sure that when a recognition >>> operation is started, there is no latency while the ASR server >>> compiles and/or loads a large precompiled grammar into memory. The >>> DEFINE-GRAMMAR command is scoped to a channel, which means by the >>> > time > >>> the application has a channel (i.e. a caller is in the system), it >>> > is > >>> unacceptable to block for more than fraction of a >>> second while the grammars are being compiled and/or loaded. >>> Otherwise, the first caller after a grammar is changed encounters >>> delays and has a poor user experience or even hangs up. Somebody >>> > may > >>> say: well, just make a "priming" call after modifying the grammar to >>> ensure the grammar is cached. However, that is not very practical >>> > for > >>> automatically generated grammars; but worse yet, in large systems >>> there are commonly several load-balanced ASR severs and it will be >>> rather hard to ensure each of them is touched at least once. >>> >>> >>> >>> The way we solve this on our platform is as follows: Large grammars >>> that may change frequently, possibly several times a day, such as >>> company directory grammars that are generated from a database, can >>> > be > >>> registered as "preloaded grammars". This means, our platform >>> > ensures > >>> the grammar is compiled, distributed to all ASR servers, and loaded >>> into their caches after a new version of that grammar has been >>> generated. Each preloaded grammar has a name associated, which is >>> referenced through a special URI. The application logic only knows >>> that URI and not the actual URI/filename of the underlying grammar >>> data. The subsystem managing the preloaded grammars ensures that >>> > the > >>> preloaded grammar URI resolves to the previous version of the >>> > grammar > >>> until the new grammar is loaded and ready on all ASR servers. Thus, >>> all callers that call into the system while the grammar is being >>> generated, compiled, and loaded on the servers will get the previous >>> version. This ensures that there is no delay for the first caller >>> after a change. We can do this as we are using the native APIs >>> provided by the ASR engine vendors we support and layer a >>> sophisticated framework and API on top of it. >>> >>> >>> >>> It would be nice if MRCP provided some support for schemes like >>> > that, > >>> without having to open dummy channels to register grammars and pray >>> the MRCP server doesn't evict them too early. An MRCP client has to >>> be able to guarantee that when a call comes through >>> the system, everything is ready and it won't experience any delay. >>> As it stands now the MRCP protocol does not appear to provide >>> > support > >>> for this. >>> >>> >>> >>> Thanks, >>> >>> Felix >>> >>> >>> >>> From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] >>> On Behalf Of Dave Burke >>> Sent: Saturday, June 11, 2005 10:42 >>> To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org >>> Subject: Re: [Speechsc] Managing big grammars >>> >>> >>> >>> I agree. Grammar compilation, caching, and sharing is a problem for >>> the MRCP server. Exposing this in the protocol puts unnecessary >>> complexity on the client. For example, the client needs to download >>> grammars, implement its own HTTP caching, checksum algorithms (some >>> way of not having to push huge data to the MRCP server to query) >>> > etc. > >>> >>> >>> >>> So I vote for point 1 below and include in the text that an MRCP >>> server could also, as an optimisation, implement a centralised >>> common cache shared across multiple MRCP servers. >>> >>> >>> >>> Dave >>> >>> ----- Original Message ----- >>> >>> From: Shanmugham, Saravanan >>> >>> To: Corby Anderson ; Speechsc@ietf.org >>> >>> Sent: Saturday, June 11, 2005 12:09 AM >>> >>> Subject: RE: [Speechsc] Managing big grammars >>> >>> >>> >>> I would say that a common cache amoung a farm of MRCP servers to >>> optimize compilations would be a nice server side optimization and >>> shouldn't affect the MRCP protocol. >>> >>> >>> >>> my 2c. >>> >>> Sarvi >>> >>> _______________________________________________ >>> 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 > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 14 13:50:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiFYu-0006RI-HS; Tue, 14 Jun 2005 13:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiFYs-0006RD-JZ for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 13:50:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08695 for ; Tue, 14 Jun 2005 13:50:53 -0400 (EDT) Received: from [199.4.160.64] (helo=pb-exchcon2.scansoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiFv5-0000LP-7c for Speechsc@ietf.org; Tue, 14 Jun 2005 14:14:11 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 14 Jun 2005 12:57:55 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , Dave Burke Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 08:51:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" 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 Is 4) a realistic scenario? It would require that the MRCP server know each other, which results in a configuration nightmare. And what happens if one of them is down just at that moment... Slight reformulation of 2): An MRCP server may cache a compiled version of a grammar Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Dienstag, 14. Juni 2005 14:31 To: Dave Burke Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix Subject: Re: [Speechsc] Managing big grammars I like Dave's formulation. If there are no objections, I'm going to craft this into a sub-section on "Grammar Caching" under the section on "Grammar Data". On looking where to put this, I noticed that the description is under 9.5.1 "recognizer Grammar Data" which is under "Recognizer message body". Some of that material isn't really about message body (since it talks about ow indirect content is handled), so I'm going to re-jigger things a bit to improve the flow and move the parts about indirect content to the new earlier section. Speak now if you don't like this, because I'm going to do this later today... On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: > That optimisation would be nice alright and is not restricted by HTTP > (see note from RFC 2616 below). > > It seems like we have got some good optimisation suggestions (read: > informative) that could go into the spec to address large grammars. > If memory serves, they are: > 1. An MRCP server may cache grammars used in DEFINE-GRAMMAR or > RECOGNIZE to be used over multiple MRCP sessions > 2. An MRCP server may cache the compiled version of a grammar > 3. An MRCP server may cache grammars centrally to allow other > servers take advantage of the cache > 4. An MRCP server, in response to a DEFINE-GRAMMAR, may inform > other MRCP servers to reload the new grammar into memory > 5. An MRCP server may choose to return a stale response while a > new grammar is being downloaded, compiled, and cached > > -- Dave > > From RFC 2616: > > In some cases, the operator of a cache MAY choose to configure it > to > return stale responses even when not requested by clients. This > decision ought not be made lightly, but may be necessary for > reasons > of availability or performance, especially when the cache is poorly > connected to the origin server. Whenever a cache returns a stale > response, it MUST mark it as such (using a Warning header) enabling > the client software to alert the user that there might be a > potential > problem. > > > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 12:04 PM > Subject: RE: [Speechsc] Managing big grammars > > cool. That makes sense. > The way I though this problem would have been addressed, is the MRCP > caching system to be smart. > That is everytime there is a request a grammar for a grammar URI. > the MRCP server would do a fetch to check if the document has changed. > If it has, then it would download and compile the grammar. > While this happenning existing calls that were using the older > compiled grammar continue to use it. Once this is ready, the previous > version of the grammar is allowed to expire-out. > > Would this not address your scenario and avoid having to do this work > around you are suggesting? > > Sarvi > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 14, 2005 3:16 AM > To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson; > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > It's not that the URL needs a specific date or time, just that it has > a unique name. This is simply so that you can ensure the new grammar > is downloaded, compiled, and loaded ahead of any calls. > Once compiled and loaded, the application grammar URIs can be updated > to reference the new grammar. This way you avoid the danger that a > bunch of calls, which arrive at the same time as the DEFINE- GRAMMAR > is happening, experience delays. > > Dave > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 7:58 AM > Subject: RE: [Speechsc] Managing big grammars > > I dont understand why the RUL has to encode and date and time into it. > Lets say we are refering to large_grammar.grxml > > When a client does a DEFINE-GRAMMAR on the MRCP server with this URI. > The MRCP server is expected to go download this URI and compile it. > The caching behaviour of this URI and how long it lives in the cache > is dependent on what is returned by the HTTP GET operation that > brought the grammar into the MRCP server. In addition, the behaviour > is also governed by Cache -Control parameters that the client can > specify for the DEFINE-GRAMMAR that would take precedence over what > was returned by the HTTP GET operation. This means that the MRCP > client can force the MRCP server to ignore the cache parameters it got > from the grammar webserver. > > So, for the large_grammar.grxml, if the webserver returned a large > max-age value the grammar and its compiled version in the cache of the > MRCP server should not get timedout. For any future requests for that > grammar, MRCP server should go do fetch of the document, compare the > max-age of the fetched coument and make sure the webserver says that > the document in the cache is not out-of-date. > As long as the grammar document in the cache is not out of date, you > don't need to compile it again and you are fine. If the propoerty of > the large_grammar.grxml on the webserver had changed then the MRCP > server would be expected to refresh the cache and compile the newly > downloaded grammar. > > > Am I missing something here. > > Sarvi > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Sunday, June 12, 2005 12:12 PM > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson; > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > There is no doubt that grammar compilation and loading must be hidden > from the caller experience. What is in doubt is whether the MRCP > protocol needs to expose such control. > > The grammar loading problem is not dissimilar to cache seeding in the > Web world. Taking your use-case, I would implement this in MRCP as a > two-step process: > > (1) Make the large grammar available through HTTP and date-stamp the > URI, e.g. http://example.com/large_grammar_12June2005.grxml. > Set the HTTP response header Cache-Control: max-age to a value larger > than the grammar change period. > > (2) When a new grammar is required, open an MRCP channel to each of > the MRCP servers. Issue a DEFINE-GRAMMAR with the relevant URI e.g. > http://example.com/large_grammar_13June2005.grxml. Update the > application to point at the new grammar. > > [For a mid-size grammar where loading latency is negligible, and > assuming a centrally located compiled grammar cache, step (2) might > only require a DEFINE-GRAMMAR to one MRCP server]. > > You are correct that the current MRCPv2 draft scopes the DEFINE- > GRAMMAR to a channel and this is a concern. However, this is resolved > with Sarvi's suggested text change. > > Dave > ----- Original Message ----- > From: Wyss, Felix > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ; > Speechsc@ietf.org > Sent: Sunday, June 12, 2005 1:41 AM > Subject: RE: [Speechsc] Managing big grammars > > I disagree. Predictability is *very* critical for an application > using ASR. It must be able to make sure that when a recognition > operation is started, there is no latency while the ASR server > compiles and/or loads a large precompiled grammar into memory. The > DEFINE-GRAMMAR command is scoped to a channel, which means by the time > the application has a channel (i.e. a caller is in the system), it is > unacceptable to block for more than fraction of a > second while the grammars are being compiled and/or loaded. > Otherwise, the first caller after a grammar is changed encounters > delays and has a poor user experience or even hangs up. Somebody may > say: well, just make a "priming" call after modifying the grammar to > ensure the grammar is cached. However, that is not very practical for > automatically generated grammars; but worse yet, in large systems > there are commonly several load-balanced ASR severs and it will be > rather hard to ensure each of them is touched at least once. > > > > The way we solve this on our platform is as follows: Large grammars > that may change frequently, possibly several times a day, such as > company directory grammars that are generated from a database, can be > registered as "preloaded grammars". This means, our platform ensures > the grammar is compiled, distributed to all ASR servers, and loaded > into their caches after a new version of that grammar has been > generated. Each preloaded grammar has a name associated, which is > referenced through a special URI. The application logic only knows > that URI and not the actual URI/filename of the underlying grammar > data. The subsystem managing the preloaded grammars ensures that the > preloaded grammar URI resolves to the previous version of the grammar > until the new grammar is loaded and ready on all ASR servers. Thus, > all callers that call into the system while the grammar is being > generated, compiled, and loaded on the servers will get the previous > version. This ensures that there is no delay for the first caller > after a change. We can do this as we are using the native APIs > provided by the ASR engine vendors we support and layer a > sophisticated framework and API on top of it. > > > > It would be nice if MRCP provided some support for schemes like that, > without having to open dummy channels to register grammars and pray > the MRCP server doesn't evict them too early. An MRCP client has to > be able to guarantee that when a call comes through > the system, everything is ready and it won't experience any delay. > As it stands now the MRCP protocol does not appear to provide support > for this. > > > > Thanks, > > Felix > > > > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Saturday, June 11, 2005 10:42 > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > > > I agree. Grammar compilation, caching, and sharing is a problem for > the MRCP server. Exposing this in the protocol puts unnecessary > complexity on the client. For example, the client needs to download > grammars, implement its own HTTP caching, checksum algorithms (some > way of not having to push huge data to the MRCP server to query) etc. > > > > So I vote for point 1 below and include in the text that an MRCP > server could also, as an optimisation, implement a centralised > common cache shared across multiple MRCP servers. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Corby Anderson ; Speechsc@ietf.org > > Sent: Saturday, June 11, 2005 12:09 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I would say that a common cache amoung a farm of MRCP servers to > optimize compilations would be a nice server side optimization and > shouldn't affect the MRCP protocol. > > > > my 2c. > > Sarvi > > _______________________________________________ > 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 Tue Jun 14 13:51:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiFZ3-0006SB-Bz; Tue, 14 Jun 2005 13:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiFZ2-0006S5-9T for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 13:51:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08721 for ; Tue, 14 Jun 2005 13:51:03 -0400 (EDT) Received: from [199.4.160.64] (helo=pb-exchcon2.scansoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiFvQ-0000LP-DH for Speechsc@ietf.org; Tue, 14 Jun 2005 14:14:21 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Tue, 14 Jun 2005 13:02:38 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Bennett, Patrick'" , Speechsc@ietf.org Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE command and test/ur i-list content type Date: Tue, 14 Jun 2005 11:28:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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="===============1470834583==" 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. --===============1470834583== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570F5.AFFECEDC" 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_01C570F5.AFFECEDC Content-Type: text/plain We should add support of grammar weights (e.g. required by the weight attribute of the element of VoiceXML 2.0; http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.1.3 ) to MRCPv2. Klaus _____ From: Bennett, Patrick [mailto:Patrick.Bennett@inin.com] Sent: Dienstag, 14. Juni 2005 17:09 To: Speechsc@ietf.org Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-list content type According to the latest draft on page 89: ...The RECOGNIZE method MUST carry the grammars that need to be activated for that RECOGNIZE method, in its message body. The grammars that need to be activated can be specified in one of 3 ways. The grammar content could be specified as a mime-content in the message body. It could be a simple list of grammar URIs specified in a mime-content of type text/uri-list, in which case the order of the URI refer to the precedence order of the grammars during the recognize. ... The problem here is the statement "in which case the order of the URI refer to the precedence order of the grammars during the recognize." Well, what is the EXACT precedence? Shouldn't each of the grammars be considered as equally weighted alternatives? Ideally, all must be weighted equally unless a specific weight parameter was specified with each URI. As currently specified, this part of the specification is basically worthless. No MRCP client would ever send multiple URIs to an MRCP server via a uri-list since the weighting applied to each grammar is completely undefined. This really needs to be corrected. Patrick Bennett ------_=_NextPart_001_01C570F5.AFFECEDC Content-Type: text/html
We should add support of grammar weights (e.g. required by the weight attribute of the <grammar> element of VoiceXML 2.0; http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.1.3) to MRCPv2.
 
Klaus

From: Bennett, Patrick [mailto:Patrick.Bennett@inin.com]
Sent: Dienstag, 14. Juni 2005 17:09
To: Speechsc@ietf.org
Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-list content type

According to the latest draft on page 89:

 

   ...The RECOGNIZE method MUST carry the grammars that need to be

   activated for that RECOGNIZE method, in its message body. The

   grammars that need to be activated can be specified in one of 3

   ways. The grammar content could be specified as a mime-content in

   the message body. It could be a simple list of grammar URIs

   specified in a mime-content of type text/uri-list, in which case the

   order of the URI refer to the precedence order of the grammars

   during the recognize. ...

 

The problem here is the statement "in which case the order of the URI refer to the precedence order of the grammars during the recognize."

Well, what is the EXACT precedence?  Shouldn't each of the grammars be considered as equally weighted alternatives?  Ideally, all must be weighted equally unless a specific weight parameter was specified with each URI.

As currently specified, this part of the specification is basically worthless.  No MRCP client would ever send multiple URIs to an MRCP server via a uri-list since the weighting applied to each grammar is completely undefined.

This really needs to be corrected.

 

Patrick Bennett

------_=_NextPart_001_01C570F5.AFFECEDC-- --===============1470834583== 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 --===============1470834583==-- From speechsc-bounces@ietf.org Tue Jun 14 15:15:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiGsu-0006E6-JM; Tue, 14 Jun 2005 15:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiGsq-0006Dd-CT for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 15:15:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20970 for ; Tue, 14 Jun 2005 15:15:34 -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 1DiHFL-0000Fg-H0 for speechsc@ietf.org; Tue, 14 Jun 2005 15:38:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 12:15:24 -0700 X-IronPort-AV: i="3.93,198,1115017200"; d="scan'208"; a="278645727:sNHT35551310" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5EJFGbw018700; Tue, 14 Jun 2005 12:15:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 12:15:12 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05BA4A@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVxCedJ7dqXD3RTTDmHS3pjoQ+9tQACzYbw From: "Shanmugham, Saravanan" To: "Reifenrath, Klaus" , "David R. Oran" , "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Wyss, Felix" 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 think all this is saying is that a MRCPv2 vendor could desing their system such they can deploy a cluster of them with a common compiled cache and a internal mechanism to announce to each other of a change. Those internal mechanisms are many and are outside the scope of this specification. SArvi -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, June 14, 2005 5:52 AM To: 'David R. Oran'; Dave Burke Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix Subject: RE: [Speechsc] Managing big grammars =20 Is 4) a realistic scenario? It would require that the MRCP=20 server know each other, which results in a configuration=20 nightmare. And what happens if one of them is down just at=20 that moment...=20 =20 Slight reformulation of 2): An MRCP server may cache a compiled version of a grammar =20 Klaus =20 -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Dienstag, 14. Juni 2005 14:31 To: Dave Burke Cc: Speechsc@ietf.org; Shanmugham, Saravanan; Wyss, Felix Subject: Re: [Speechsc] Managing big grammars =20 I like Dave's formulation. If there are no objections, I'm=20 going to craft this into a sub-section on "Grammar=20 Caching" under the section on "Grammar Data". On looking=20 where to put this, I noticed that the description is under 9.5.1 "recognizer Grammar Data" which is under "Recognizer=20 message body". Some of that material isn't really about message body=20 (since it talks about ow indirect content is handled), so=20 I'm going to re-jigger things a bit to improve the flow=20 and move the parts about indirect content to the new=20 earlier section. =20 Speak now if you don't like this, because I'm going to do=20 this later today... =20 On Jun 14, 2005, at 8:16 AM, Dave Burke wrote: =20 > That optimisation would be nice alright and is not=20 restricted by HTTP=20 > (see note from RFC 2616 below). > > It seems like we have got some good optimisation=20 suggestions (read: =20 > informative) that could go into the spec to address=20 large grammars. =20 > If memory serves, they are: > 1. An MRCP server may cache grammars used in=20 DEFINE-GRAMMAR or=20 > RECOGNIZE to be used over multiple MRCP sessions > 2. An MRCP server may cache the compiled version of a grammar > 3. An MRCP server may cache grammars centrally to=20 allow other=20 > servers take advantage of the cache > 4. An MRCP server, in response to a DEFINE-GRAMMAR,=20 may inform=20 > other MRCP servers to reload the new grammar into memory > 5. An MRCP server may choose to return a stale=20 response while a=20 > new grammar is being downloaded, compiled, and cached > > -- Dave > > From RFC 2616: > > In some cases, the operator of a cache MAY choose to=20 configure it=20 > to > return stale responses even when not requested by=20 clients. This > decision ought not be made lightly, but may be necessary for=20 > reasons > of availability or performance, especially when the=20 cache is poorly > connected to the origin server. Whenever a cache=20 returns a stale > response, it MUST mark it as such (using a Warning=20 header) enabling > the client software to alert the user that there might be a=20 > potential > problem. > > > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 12:04 PM > Subject: RE: [Speechsc] Managing big grammars > > cool. That makes sense. > The way I though this problem would have been addressed,=20 is the MRCP=20 > caching system to be smart. > That is everytime there is a request a grammar for a=20 grammar URI. =20 > the MRCP server would do a fetch to check if the=20 document has changed.=20 > If it has, then it would download and compile the grammar. > While this happenning existing calls that were using the older=20 > compiled grammar continue to use it. Once this is ready,=20 the previous=20 > version of the grammar is allowed to expire-out. > > Would this not address your scenario and avoid having to=20 do this work=20 > around you are suggesting? > > Sarvi > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Tuesday, June 14, 2005 3:16 AM > To: Shanmugham, Saravanan; Wyss, Felix; Corby Anderson;=20 > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > It's not that the URL needs a specific date or time,=20 just that it has=20 > a unique name. This is simply so that you can ensure the=20 new grammar=20 > is downloaded, compiled, and loaded ahead of any calls. > Once compiled and loaded, the application grammar URIs=20 can be updated=20 > to reference the new grammar. This way you avoid the=20 danger that a=20 > bunch of calls, which arrive at the same time as the=20 DEFINE- GRAMMAR=20 > is happening, experience delays. > > Dave > ----- Original Message ----- > From: Shanmugham, Saravanan > To: Dave Burke ; Wyss, Felix ; Corby Anderson ; Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 7:58 AM > Subject: RE: [Speechsc] Managing big grammars > > I dont understand why the RUL has to encode and date and=20 time into it.=20 > Lets say we are refering to large_grammar.grxml > > When a client does a DEFINE-GRAMMAR on the MRCP server=20 with this URI.=20 > The MRCP server is expected to go download this URI and=20 compile it.=20 > The caching behaviour of this URI and how long it lives=20 in the cache=20 > is dependent on what is returned by the HTTP GET operation that=20 > brought the grammar into the MRCP server. In addition,=20 the behaviour=20 > is also governed by Cache -Control parameters that the=20 client can=20 > specify for the DEFINE-GRAMMAR that would take=20 precedence over what=20 > was returned by the HTTP GET operation. This means that the MRCP=20 > client can force the MRCP server to ignore the cache=20 parameters it got=20 > from the grammar webserver. > > So, for the large_grammar.grxml, if the webserver=20 returned a large=20 > max-age value the grammar and its compiled version in=20 the cache of the=20 > MRCP server should not get timedout. For any future=20 requests for that=20 > grammar, MRCP server should go do fetch of the document,=20 compare the=20 > max-age of the fetched coument and make sure the=20 webserver says that=20 > the document in the cache is not out-of-date. > As long as the grammar document in the cache is not out=20 of date, you=20 > don't need to compile it again and you are fine. If the=20 propoerty of=20 > the large_grammar.grxml on the webserver had changed=20 then the MRCP=20 > server would be expected to refresh the cache and=20 compile the newly=20 > downloaded grammar. > > > Am I missing something here. > > Sarvi > > From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Sunday, June 12, 2005 12:12 PM > To: Wyss, Felix; Shanmugham, Saravanan; Corby Anderson;=20 > Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > There is no doubt that grammar compilation and loading=20 must be hidden=20 > from the caller experience. What is in doubt is whether the MRCP=20 > protocol needs to expose such control. > > The grammar loading problem is not dissimilar to cache=20 seeding in the=20 > Web world. Taking your use-case, I would implement this=20 in MRCP as a=20 > two-step process: > > (1) Make the large grammar available through HTTP and=20 date-stamp the=20 > URI, e.g. http://example.com/large_grammar_12June2005.grxml. > Set the HTTP response header Cache-Control: max-age to a=20 value larger=20 > than the grammar change period. > > (2) When a new grammar is required, open an MRCP channel=20 to each of=20 > the MRCP servers. Issue a DEFINE-GRAMMAR with the=20 relevant URI e.g. > http://example.com/large_grammar_13June2005.grxml. Update the=20 > application to point at the new grammar. > > [For a mid-size grammar where loading latency is negligible, and=20 > assuming a centrally located compiled grammar cache,=20 step (2) might=20 > only require a DEFINE-GRAMMAR to one MRCP server]. > > You are correct that the current MRCPv2 draft scopes the DEFINE-=20 > GRAMMAR to a channel and this is a concern. However,=20 this is resolved=20 > with Sarvi's suggested text change. > > Dave > ----- Original Message ----- > From: Wyss, Felix > To: Dave Burke ; Shanmugham, Saravanan ; Corby Anderson ;=20 > Speechsc@ietf.org > Sent: Sunday, June 12, 2005 1:41 AM > Subject: RE: [Speechsc] Managing big grammars > > I disagree. Predictability is *very* critical for an=20 application=20 > using ASR. It must be able to make sure that when a recognition=20 > operation is started, there is no latency while the ASR server=20 > compiles and/or loads a large precompiled grammar into=20 memory. The=20 > DEFINE-GRAMMAR command is scoped to a channel, which=20 means by the time=20 > the application has a channel (i.e. a caller is in the=20 system), it is=20 > unacceptable to block for more than fraction of a > second while the grammars are being compiled and/or loaded. =20 > Otherwise, the first caller after a grammar is changed=20 encounters=20 > delays and has a poor user experience or even hangs up. =20 Somebody may > say: well, just make a "priming" call after modifying=20 the grammar to=20 > ensure the grammar is cached. However, that is not very=20 practical for=20 > automatically generated grammars; but worse yet, in=20 large systems=20 > there are commonly several load-balanced ASR severs and=20 it will be=20 > rather hard to ensure each of them is touched at least once. > > > > The way we solve this on our platform is as follows:=20 Large grammars=20 > that may change frequently, possibly several times a=20 day, such as=20 > company directory grammars that are generated from a=20 database, can be=20 > registered as "preloaded grammars". This means, our=20 platform ensures=20 > the grammar is compiled, distributed to all ASR servers,=20 and loaded=20 > into their caches after a new version of that grammar has been=20 > generated. Each preloaded grammar has a name=20 associated, which is=20 > referenced through a special URI. The application logic=20 only knows=20 > that URI and not the actual URI/filename of the=20 underlying grammar=20 > data. The subsystem managing the preloaded grammars=20 ensures that the=20 > preloaded grammar URI resolves to the previous version=20 of the grammar=20 > until the new grammar is loaded and ready on all ASR=20 servers. Thus,=20 > all callers that call into the system while the grammar is being=20 > generated, compiled, and loaded on the servers will get=20 the previous=20 > version. This ensures that there is no delay for the=20 first caller=20 > after a change. We can do this as we are using the native APIs=20 > provided by the ASR engine vendors we support and layer a=20 > sophisticated framework and API on top of it. > > > > It would be nice if MRCP provided some support for=20 schemes like that,=20 > without having to open dummy channels to register=20 grammars and pray=20 > the MRCP server doesn't evict them too early. An MRCP=20 client has to=20 > be able to guarantee that when a call comes through > the system, everything is ready and it won't experience=20 any delay. =20 > As it stands now the MRCP protocol does not appear to=20 provide support=20 > for this. > > > > Thanks, > > Felix > > > > From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] > On Behalf Of Dave Burke > Sent: Saturday, June 11, 2005 10:42 > To: Shanmugham, Saravanan; Corby Anderson; Speechsc@ietf.org > Subject: Re: [Speechsc] Managing big grammars > > > > I agree. Grammar compilation, caching, and sharing is a=20 problem for=20 > the MRCP server. Exposing this in the protocol puts unnecessary=20 > complexity on the client. For example, the client needs=20 to download=20 > grammars, implement its own HTTP caching, checksum=20 algorithms (some=20 > way of not having to push huge data to the MRCP server=20 to query) etc. > > > > So I vote for point 1 below and include in the text that an MRCP=20 > server could also, as an optimisation, implement a=20 centralised common=20 > cache shared across multiple MRCP servers. > > > > Dave > > ----- Original Message ----- > > From: Shanmugham, Saravanan > > To: Corby Anderson ; Speechsc@ietf.org > > Sent: Saturday, June 11, 2005 12:09 AM > > Subject: RE: [Speechsc] Managing big grammars > > > > I would say that a common cache amoung a farm of MRCP=20 servers to =20 > optimize compilations would be a nice server side=20 optimization and =20 > shouldn't affect the MRCP protocol. > > > > my 2c. > > Sarvi > > _______________________________________________ > 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 Tue Jun 14 15:24:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH1R-0007v0-6P; Tue, 14 Jun 2005 15:24:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH1Q-0007uv-96 for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 15:24:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22391 for ; Tue, 14 Jun 2005 15:24:26 -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 1DiHNv-00012s-Pu for speechsc@ietf.org; Tue, 14 Jun 2005 15:47:46 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 12:24:17 -0700 X-IronPort-AV: i="3.93,198,1115017200"; d="scan'208"; a="278650511:sNHT31609288" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5EJO9lw028304; Tue, 14 Jun 2005 12:24:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type Date: Tue, 14 Jun 2005 12:24:06 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05BA51@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type Thread-Index: AcVxACu0vIo2u1TcSt28+ttPpTh5BQAFgZww From: "Shanmugham, Saravanan" To: "Dave Burke" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Bennett, Patrick" 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 am fine with Option iii, but the we would be trying to extend MIME headers which I am not sure if its extenisble or what the procedure to define new MIME-headers are. Could find any good examples. So I chose the next best thing which was to use a rule id approach. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 14, 2005 9:41 AM To: David R. Oran Cc: Speechsc@ietf.org; Bennett, Patrick Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE=20 commandandtest/uri-listcontent type =20 To be clear, I think there are two issues: A. How to word the precedence when input matches more than=20 one active grammar? B. How to specify a weight for a complete grammar? (see http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1023.html) =20 For A, how about appending the sentence in 1. and 2. so=20 that we get: =20 ...the order of inclusion controls the corresponding=20 precedence for the grammars during recognition should the=20 input match more than one active grammar. =20 For B, which point 3 addresses, there are three options discussed: (i) Use the One-Of-Rule-Id-URI mechanism below (ii) Add an informative note that a grammar can=20 be used to apply weights to grammars (One-Of-Rule-Id-URI=20 is unnecessary ) (iii) Go with Jeff's idea of adding a new header to a MIME part (http://www1.ietf.org/mail-archive/web/speechsc/current/msg 01102.html) Small refinement though, the header should be=20 called Content-Grammar-Weight to fit RFC2045's extension mechanism =20 My preference is for (iii) over (ii) because if my MRCP=20 client runs VoiceXML then I'm going to have to handle=20 cases when has a weight attribute and build up a=20 grammar. This is just annoying complexity for the client. =20 Dave =20 =20 ----- Original Message ----- From: "David R. Oran" To: "Dave Burke" Cc: ; "Bennett, Patrick"=20 Sent: Tuesday, June 14, 2005 5:02 PM Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE=20 command andtest/uri-listcontent type =20 =20 I agree with Dave, but I also believe the current text is=20 quite torturous and prone to misinterpretation. I had held=20 off screwing around with it because of my shaky=20 understanding of the "one-of-rule- id" stuff but now that=20 I think I can get it right I've taken a whack at it. =20 This is what the in-progress version of the spec says: =20 The RECOGNIZE request uses the message body to specify the=20 grammars applicable to the request. The active grammar(s)=20 for the request can be specified in one of 3 ways. =20 1. The grammer may be placed directly in the message body=20 using MIME content. If more than one grammar is included=20 in the body, the order of inclusion controls the=20 corresponding precedence for the grammars during recognition. 2. The body may contain a list of grammar URIs specified=20 in a mime- content of type text/uri-list. The order of the=20 URIs determines the corrensponding precedence for the=20 grammars during recognition. 3. The active grammar among a set of grammars can=20 specified using a One-Of-Rule-Id-URI header in the=20 message. This header (see Section 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific =20 rule-id contained in the grammar (or grammars) specified=20 in the body of the message. =20 Are further adjustments needed? =20 =20 On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: =20 > The precedence is not related to weighting. The text=20 here covers the=20 > case if you had two grammars say gram1.grxml and=20 gram2.grxml both of=20 > which recognise the token "speech" but return a=20 different semantic=20 > interpretation. If gram2.grxml follows gram1.grxml in=20 the uri-list=20 > then it is gram1.grxml that is matched and it is gram1.grxml's=20 > semantic interpretation result that is returned in the NLSML. > > This is also required for VoiceXML 2.x behaviour (see http://=20 > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > Dave > ----- Original Message ----- > From: Bennett, Patrick > To: Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 4:09 PM > Subject: [Speechsc] Problem with draft-6 RECOGNIZE=20 command and test/=20 > uri-listcontent type > > According to the latest draft on page 89: > > > ...The RECOGNIZE method MUST carry the grammars that need to be > > activated for that RECOGNIZE method, in its message body. The > > grammars that need to be activated can be specified=20 in one of 3 > > ways. The grammar content could be specified as a=20 mime-content in > > the message body. It could be a simple list of grammar URIs > > specified in a mime-content of type text/uri-list, in=20 which case =20 > the > > order of the URI refer to the precedence order of the grammars > > during the recognize. ... > > > The problem here is the statement "in which case the=20 order of the URI=20 > refer to the precedence order of the grammars during=20 the recognize." > > Well, what is the EXACT precedence? Shouldn't each of=20 the grammars =20 > be considered as equally weighted alternatives? =20 Ideally, all must be=20 > weighted equally unless a specific weight parameter was =20 specified=20 > with each URI. > > As currently specified, this part of the specification=20 is basically=20 > worthless. No MRCP client would ever send multiple URIs=20 to an MRCP=20 > server via a uri-list since the weighting applied to=20 each grammar is=20 > completely undefined. > > This really needs to be corrected. > > > Patrick Bennett > > > > _______________________________________________ > 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 > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =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 Tue Jun 14 15:30:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH7V-0000Yi-Nt; Tue, 14 Jun 2005 15:30:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH7V-0000YZ-0g for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 15:30:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23201 for ; Tue, 14 Jun 2005 15:30:43 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHU2-0001bh-P7 for Speechsc@ietf.org; Tue, 14 Jun 2005 15:54:03 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_14_29_25 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 14:29:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 14:30:35 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B33901786CCB@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVxAZNV63POc8zeS6SSwvN975rXYAADHFYw From: "Bennett, Patrick" To: "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , Dave Burke , "Wyss, Felix" , "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 [responses inline] > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 14, 2005 11:53 AM > To: Bennett, Patrick > Cc: Reifenrath, Klaus; Dave Burke; Speechsc@ietf.org; Shanmugham, > Saravanan; Wyss, Felix > Subject: Re: [Speechsc] Managing big grammars >=20 > > >=20 ... >=20 > If you are a system-builder you need to ensure that the components > you select (e.g. MRCPv2 servers) meet the performance requirements > for your applications.=20 [Bennett, Patrick] Ah, but there's the rub! I don't select the MRCP server. The customer does! If they pick vendor Z for their system because it's an "MRCPv2" server (and we list MRCPv2 as one of our supported server types), and that vendor implemented the bare minimum of MRCP (while staying completely within the 'spec'), that customer wouldn't be too happy. I couldn't blame it on the vendor either. They'd be within the spec. What's the point of a standard client protocol if servers can't be equally interchanged and provide equal (not least common-denominitor) functionality? > The current MRCPv2 design, as elaborated on by > Sarvi, allows a client to ascertain to a limited degree whether a > server is going to perform adequately (through the cache control > parameters), but not to force a server to use any particular means to > do so. I think this is the right tradeoff. You're certainly entitled > to disagree. [Bennett, Patrick] I guess we'll agree to disagree then. If the server 'may' pay attention to these parameters, it really doesn't mean a whole lot. > > If needs to be to be usable by carrier grade and scale implementors. > > This isn't possible when the MRCP servers MAY do something. > > > I agree in the case where the results are semantically different and > it is impossible for the client to ascertain what the server does, > but not in cases where the alternative behaviors are explicitly there > for flexibility and to avoid over-specification. [Bennett, Patrick] As currently defined, DEFINE-GRAMMAR is well, pretty much completely undefined. I don't mean to be too aggressive here (writing an RFC is extremely difficult!), but c'mon. Here is effectively, the entire definition of DEFINE-GRAMMAR:=20 "The DEFINE-GRAMMAR method, from the client to the server, provides a grammar and tells the server to define, download if needed and compile the=20 grammar." The rest just defines when it can be called. By the spec, every grammar would have to be defined for every single session, every single time, and there would be *no* way of knowing if a specific grammar would be (re)compiled (it might be a grammar that takes 20 minutes just to compile!) for any given session. Technically, it MAY take 20 minutes to compile for every single caller since the server MAY not pay attention to anything I requested [even ignoring the huge problem of no global grammar contexts]. Even if the server MAY have cached the result and the caching is spread across sessions, you still have to have some way of priming the cache. But of course, you can't (by the spec) prime the cache from a different session. You'd have to define the grammar in the context of an active call! What happens for the first caller into an automated attendant application as the system he uses takes an indeterminate amount of time to compile the speech grammar before it even allows recognition! Does the customer have to force a dummy call into the system each time a dynamic grammar generation process runs? =20 > > I guess I could just say, the MRCP spec MAY be unusable for anything > > other a simple test system with trivial, *static* grammars with no > > more > > than a few concurrent sessions. > > > I think we have deployed experience with MRCPv1 (which says even less > on the subject) that contradicts this observation. [Bennett, Patrick] I guess I'll have to take your word for it, but I doubt those successful (large-scale, right?) deployments can work with any drop in MRCPv1 server. If these servers were as you said selected to "...meet the performance requirements for your applications..." then what was the point of MRCP? The implementer might as well have used the speech vendor's own proprietary API! I doubt they could truly drop in another vendor's MRCP server. Basically, we (Interactive Intelligence, Inc.) as a part of implementing our own vendor-agnostic speech recognition framework succeeded in creating an extremely scalable and robust system. In the near future, we plan on adding support for MRCP servers in addition to the vendors we already support. Unfortunately, as defined, MRCP would be a huge step backwards for us compared to functionality we already have. The vendors we currently support have well defined means for precompiling grammars which we can take advantage of and cache appropriately across large numbers of servers. One of our concerns is that some vendors (e.g. Nuance) have suggested that they're going to drop their existing APIs and start supporting MRCP only. This is why a poorly defined MRCP spec is particularly troubling for us.=20 Patrick Bennett _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 14 15:32:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH9H-00010g-0i; Tue, 14 Jun 2005 15:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH9F-0000y3-J5 for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 15:32:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23385 for ; Tue, 14 Jun 2005 15:32:32 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHVn-0001ey-DR for Speechsc@ietf.org; Tue, 14 Jun 2005 15:55:51 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_14_31_15 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 14:31:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type Date: Tue, 14 Jun 2005 14:32:24 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B33901786CCC@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZE command and test/uri-listcontent type Thread-Index: AcVw+nsM8q8kx/zVS4+p5uqOyWx6vwAHSjwQ From: "Bennett, Patrick" To: "David R. Oran" , "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Yes, #2 definitely needs to mention what the precedence applies to. It is far too confusing as currently worded. I read it as implying grammar weighting. If it's meant to conform to VoiceXML behavior, it needs to specifically reference it. > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 14, 2005 11:02 AM > To: Dave Burke > Cc: Bennett, Patrick; Speechsc@ietf.org > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command and > test/uri-listcontent type >=20 > I agree with Dave, but I also believe the current text is quite > torturous and prone to misinterpretation. I had held off screwing > around with it because of my shaky understanding of the "one-of-rule- > id" stuff but now that I think I can get it right I've taken a whack > at it. >=20 > This is what the in-progress version of the spec says: >=20 > The RECOGNIZE request uses the message body to specify the grammars > applicable to the request. The active grammar(s) for the request can > be specified in one of 3 ways. >=20 > 1. The grammer may be placed directly in the message body using MIME > content. If more than one grammar is included in the body, the order > of inclusion controls the corresponding precedence for the grammars > during recognition. > 2. The body may contain a list of grammar URIs specified in a mime- > content of type text/uri-list. The order of the URIs determines the > corrensponding precedence for the grammars during recognition. > 3. The active grammar among a set of grammars can specified using a > One-Of-Rule-Id-URI header in the message. This header (see Section > 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific rule-id > contained in the grammar (or grammars) specified in the body of the > message. >=20 > Are further adjustments needed? >=20 >=20 > On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: >=20 > > The precedence is not related to weighting. The text here covers > > the case if you had two grammars say gram1.grxml and gram2.grxml > > both of which recognise the token "speech" but return a different > > semantic interpretation. If gram2.grxml follows gram1.grxml in the > > uri-list then it is gram1.grxml that is matched and it is > > gram1.grxml's semantic interpretation result that is returned in > > the NLSML. > > > > This is also required for VoiceXML 2.x behaviour (see http:// > > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > > > Dave > > ----- Original Message ----- > > From: Bennett, Patrick > > To: Speechsc@ietf.org > > Sent: Tuesday, June 14, 2005 4:09 PM > > Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/ > > uri-listcontent type > > > > According to the latest draft on page 89: > > > > > > ...The RECOGNIZE method MUST carry the grammars that need to be > > > > activated for that RECOGNIZE method, in its message body. The > > > > grammars that need to be activated can be specified in one of 3 > > > > ways. The grammar content could be specified as a mime-content in > > > > the message body. It could be a simple list of grammar URIs > > > > specified in a mime-content of type text/uri-list, in which case > > the > > > > order of the URI refer to the precedence order of the grammars > > > > during the recognize. ... > > > > > > The problem here is the statement "in which case the order of the > > URI refer to the precedence order of the grammars during the > > recognize." > > > > Well, what is the EXACT precedence? Shouldn't each of the grammars > > be considered as equally weighted alternatives? Ideally, all must > > be weighted equally unless a specific weight parameter was > > specified with each URI. > > > > As currently specified, this part of the specification is basically > > worthless. No MRCP client would ever send multiple URIs to an MRCP > > server via a uri-list since the weighting applied to each grammar > > is completely undefined. > > > > This really needs to be corrected. > > > > > > Patrick Bennett > > > > > > > > _______________________________________________ > > 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 Tue Jun 14 16:16:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHk2-0008DL-D9; Tue, 14 Jun 2005 16:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHk0-0008DG-Iv for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 16:10:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26634 for ; Tue, 14 Jun 2005 16:10:30 -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 1DiI6X-0004mO-Vx for speechsc@ietf.org; Tue, 14 Jun 2005 16:33:51 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2005 13:10:22 -0700 X-IronPort-AV: i="3.93,198,1115017200"; d="scan'208"; a="278671040:sNHT37844366" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5EKAElq014157; Tue, 14 Jun 2005 13:10:15 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5EJvroN014461; Tue, 14 Jun 2005 12:57:53 -0700 In-Reply-To: <260A0A30F9017945932CC4F7B911B33901786CCB@i3mail1.i3domain.inin.com> References: <260A0A30F9017945932CC4F7B911B33901786CCB@i3mail1.i3domain.inin.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <999795B7-0FC8-49C3-A711-CAB1A9646E1F@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 16:10:11 -0400 To: "Bennett, Patrick" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118779075.57374"; x:"432200"; a:"rsa-sha1"; b:"nofws:7751"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"bHar1zR36JPcdfeMFeFV+SsZbv72S6pSrhU30UYuz3ol18JVOPutGysTKg5feEqe0u0kOE+i" "BPX4TIZwRDn5Ly5MGRfch3Hx19KyKNF/Y+Okf1sPu9STTBI6ZNBE/Q2wmiYLVxHqc8uR7TEjsiB" "JD6QP6irKDyKgwLlZ8VxD8bs="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Managing big grammars"; c:"Date: Tue, 14 Jun 2005 16:10:11 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , Dave Burke , "Wyss, Felix" , "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 On Jun 14, 2005, at 3:30 PM, Bennett, Patrick wrote: > [responses inline] > > >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Tuesday, June 14, 2005 11:53 AM >> To: Bennett, Patrick >> Cc: Reifenrath, Klaus; Dave Burke; Speechsc@ietf.org; Shanmugham, >> Saravanan; Wyss, Felix >> Subject: Re: [Speechsc] Managing big grammars >> >> >> >> >> > ... > >> >> If you are a system-builder you need to ensure that the components >> you select (e.g. MRCPv2 servers) meet the performance requirements >> for your applications. >> > > [Bennett, Patrick] Ah, but there's the rub! I don't select the MRCP > server. The customer does! If they pick vendor Z for their system > because it's an "MRCPv2" server (and we list MRCPv2 as one of our > supported server types), and that vendor implemented the bare > minimum of > MRCP (while staying completely within the 'spec'), that customer > wouldn't be too happy. > I couldn't blame it on the vendor either. They'd be within the spec. > > What's the point of a standard client protocol if servers can't be > equally interchanged and provide equal (not least common-denominitor) > functionality? > Well, I suspect my company would be less than pleased if all IP routers could be equally interchangeable simply by conforming to RFC795 and friends. :-) Distributed systems are distributed for a reason. If you want a system which meets specific timing and robustness constraints I don't think you can look to the protocol specifications to provide that. I understand that some other standardization bodies approach the problem differently (e.g. ITU with SS7) and specify both the protocols and the system engineering as part of the same documents. There are plusses and minuses to that. The IETF and the W3C tend to eschew any attempt to creep over the line into system engineering as part of the protocol definitions. > >> The current MRCPv2 design, as elaborated on by >> Sarvi, allows a client to ascertain to a limited degree whether a >> server is going to perform adequately (through the cache control >> parameters), but not to force a server to use any particular means to >> do so. I think this is the right tradeoff. You're certainly entitled >> to disagree. >> > > [Bennett, Patrick] I guess we'll agree to disagree then. If the > server > 'may' pay attention to these parameters, it really doesn't mean a > whole > lot. > > >>> If needs to be to be usable by carrier grade and scale implementors. >>> This isn't possible when the MRCP servers MAY do something. >>> >>> >> I agree in the case where the results are semantically different and >> it is impossible for the client to ascertain what the server does, >> but not in cases where the alternative behaviors are explicitly there >> for flexibility and to avoid over-specification. >> > > [Bennett, Patrick] As currently defined, DEFINE-GRAMMAR is well, > pretty > much completely undefined. I don't mean to be too aggressive here > (writing an RFC is extremely difficult!), but c'mon. Here is > effectively, the entire definition of DEFINE-GRAMMAR: > "The DEFINE-GRAMMAR method, from the client to the server, > provides a > grammar and tells the server to define, download if needed and > compile > the > grammar." well, it's "defined" just fine, it's just that the definition doesn't appear to do what you want. It's a tradeoff about what level of internal server operation to expose to the client. You're arguing for exposing a lot, but I don't see a whole lot of support for this position from other WG members, at least not yet. If you persuade folks that more explicit control by clients is necessary we'll adjust the specification accordingly. > The rest just defines when it can be called. By the spec, every > grammar > would have to be defined for every single session, every single time, > and there would be *no* way of knowing if a specific grammar would be > (re)compiled (it might be a grammar that takes 20 minutes just to > compile!) for any given session. That's right. If you want to be certain that all the state is in place before you fire off a RECOGNIZE request, the client can wait to enable input calls/sessions from users until it gets back COMPLETE responses for all the grammars it thinks will need to be active for the recognizer resource it is talking to. It can further set the cache timeouts long enough to have high assurance those grammars don't get kicked out, and re-do the DEFINE before the cache timers run out. I don't see how this is more onerous than exposing the various grammar formats and states to the client. For example, there's nothing which says that the server, even with a compiled grammar, can't have really stupid precedence handling and spend seconds juggling the grammar subset for a particular request in order to do the semantic matching properly. > Technically, it MAY take 20 minutes to > compile for every single caller since the server MAY not pay attention > to anything I requested [even ignoring the huge problem of no global > grammar contexts]. > I'm not sure what you mean by global grammar contexts, so I can't comment on that part. I certainly do think that a system which takes 20 minutes and recompiles grammars for every RECOGNIZE session is pretty stupidly implemented, just like a JAVA system which doesn't cache compiled JAVA code and recompiles it every time a method is invoked would be pretty stupid. It might even cause a plane to crash if you tried this in an avionics system. > Even if the server MAY have cached the result and the caching is > spread > across sessions, you still have to have some way of priming the cache. I think this is what DEFINE-GRAMMAR does. Why do you think it doesn't? > But of course, you can't (by the spec) prime the cache from a > different > session. You'd have to define the grammar in the context of an active > call! What in the specification says anything about MRCPv2 sessions being bound to calls? > What happens for the first caller into an automated attendant > application as the system he uses takes an indeterminate amount of > time > to compile the speech grammar before it even allows recognition! Does > the customer have to force a dummy call into the system each time a > dynamic grammar generation process runs? > Only if they have a client which waits for an incoming call before it does anything to prime the server state. > >>> I guess I could just say, the MRCP spec MAY be unusable for anything >>> other a simple test system with trivial, *static* grammars with no >>> more >>> than a few concurrent sessions. >>> >>> >> I think we have deployed experience with MRCPv1 (which says even less >> on the subject) that contradicts this observation. >> > > [Bennett, Patrick] I guess I'll have to take your word for it, but I > doubt those successful (large-scale, right?) deployments can work with > any drop in MRCPv1 server. If these servers were as you said selected > to "...meet the performance requirements for your applications..." > then > what was the point of MRCP? Interoperability. > The implementer might as well have used the > speech vendor's own proprietary API! I doubt they could truly drop in > another vendor's MRCP server. > They could if they used MRCP and the set of acceptable MRCP server implementations was non-null. > Basically, we (Interactive Intelligence, Inc.) as a part of > implementing > our own vendor-agnostic speech recognition framework succeeded in > creating an extremely scalable and robust system. In the near future, > we plan on adding support for MRCP servers in addition to the > vendors we > already support. > Unfortunately, as defined, MRCP would be a huge step backwards for us > compared to functionality we already have. New interoperable protocols are, for better or worse, usually a step backward from highly optimized proprietary solutions. Interoperability by any regime other than blind superset (with its attendant complexity explosion) doesn't come for free. > The vendors we currently > support have well defined means for precompiling grammars which we can > take advantage of and cache appropriately across large numbers of > servers. How can you cache a compiled grammar if you have a mix of servers from different vendors? I don't see how MRCPv2 prevents you from getting the same behavior, assuming the server implementors compile grammars as a side-effect of fetch, and clients ensure the fetch happens before the instant recognition is needed (by using DEFINE- GRAMMAR, for example). Would it help if we inserted a SHOULD strength requirement that servers compile grammars when fetched and not respond to the associated MRCPv2 request until the compilation is finished? > One of our concerns is that some vendors (e.g. Nuance) have suggested > that they're going to drop their existing APIs and start supporting > MRCP > only. This is why a poorly defined MRCP spec is particularly > troubling > for us. > I agree that if MRCPv2 is poorly defined/designed it would be troubling, and for all of us - not just for you. Where I think there's still some lack of consensus is over the adequacy of the existing MRCPv2 machinery. As WG co-chair I'm responsible for both the consensus process and for the technical quality of the specification. So I take this discussion very seriously. > Patrick Bennett > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Jun 14 17:25:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIuz-0001a2-IA; Tue, 14 Jun 2005 17:25:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIux-0001Z1-QK for speechsc@megatron.ietf.org; Tue, 14 Jun 2005 17:25:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07498 for ; Tue, 14 Jun 2005 17:25:53 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiJHW-0003Dv-9K for Speechsc@ietf.org; Tue, 14 Jun 2005 17:49:14 -0400 X-SEF-Processed: 5_0_0_713__2005_06_14_16_24_36 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Tue, 14 Jun 2005 16:24:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Tue, 14 Jun 2005 16:25:40 -0500 Message-ID: <260A0A30F9017945932CC4F7B911B33901786CD1@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVxHRhOrCaG8w2nQ4GQ/c+wmjSNxAAAFOrA From: "Bennett, Patrick" To: "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , Dave Burke , "Wyss, Felix" , "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 Ok, the message thread is starting to get a little cluttered, so I'll just pull out individual statements to respond to them if that's ok. If there's something I didn't respond to that you felt I should have, feel free to drop it back in on future replies. > >What's the point of a standard client protocol if servers can't be > > equally interchanged and provide equal (not least common-denominator) > > functionality? > > > Well, I suspect my company would be less than pleased if all IP > routers could be equally interchangeable simply by conforming to > RFC795 and friends. :-) [Bennett, Patrick] Well, I'm sure many (not at Cisco ;>) would disagree, but I understand what you're saying. Unfortunately, since server implementers are the primary forces behind MRCP at this point, it's possible to question the motives of leaving so many holes in the specification. If you can't drop in another server and get at least as much functionality as any other server then I think the specification is a failure. Of course, what that minimum level of functionality is, well, that's where it gets tricky. :) > Distributed systems are distributed for a reason. If you want a > system which meets specific timing and robustness constraints I don't > think you can look to the protocol specifications to provide that. [Bennett, Patrick] No, I just expect for deterministic behavior to be part of the specification. I disagree with the large number of 'optional' features in the spec which are crucial to a speech system that handles more than a couple of users. > >...By the spec, every > > grammar > > would have to be defined for every single session, every single time, > > and there would be *no* way of knowing if a specific grammar would be > > (re)compiled (it might be a grammar that takes 20 minutes just to > > compile!) for any given session. > That's right. If you want to be certain that all the state is in > place before you fire off a RECOGNIZE request, the client can wait to > enable input calls/sessions from users until it gets back COMPLETE > responses for all the grammars it thinks will need to be active for > the recognizer resource it is talking to.=20 > It can further set the > cache timeouts long enough to have high assurance those grammars > don't get kicked out, and re-do the DEFINE before the cache timers > run out.=20 [Bennett, Patrick] Not possible. The MRCP spec specifically allows the cache information to be ignored. It's entirely optional. Even if the implementor says they adhere to the HTTP 1.1 cache specs, those are optional too. Do you see what I'm saying? I keep seeing messages saying 'well, no reasonable implementation would do that..' - well, why wouldn't they!? The specification doesn't mandate anything of the sort. If the spec thought it was important, it would specifically state the importance of it, why it was necessary, and why it was a MUST requirement for server implementers. >I don't see how this is more onerous than exposing the > various grammar formats and states to the client. For example, > there's nothing which says that the server, even with a compiled > grammar, can't have really stupid precedence handling and spend > seconds juggling the grammar subset for a particular request in order > to do the semantic matching properly. [Bennett, Patrick] That's another issue. I think the MRCP spec is broken there as well. If two grammars match against the same speech utterances, that's an intentional grammar ambiguity and both results should be returned for the client application to process. > > Technically, it MAY take 20 minutes to > > compile for every single caller since the server MAY not pay attention > > to anything I requested [even ignoring the huge problem of no global > > grammar contexts]. > > > I'm not sure what you mean by global grammar contexts, so I can't > comment on that part.=20 [Bennett, Patrick] Just that there is no way to compile large grammar X such that it would be guaranteed to be cached and *instantly* available to *all* subsequent sessions on a particular MRCP server. Grammars have to be defined for each individual session and it must be assumed that each session is completely unique in terms of prior state, as there are no hard caching requirements (caching isn't required at all) nor cross-session grammar knowledge. > I certainly do think that a system which takes > 20 minutes and recompiles grammars for every RECOGNIZE session is > pretty stupidly implemented,=20 [Bennett, Patrick] Exactly. The MRCP spec allows for this. As an ISV providing a platform in which speech applications can be developed using multiple speech vendors (we allow multiple speech engines to be used simultaneously actually), when we add MRCP as one of the available speech integrations, we have to worry about specs that allow vendor X, Y, or Z to behave *completely* differently. Particularly with regard to something as important as speech grammars. If everyone can agree that no reasonable implementation should behave this way, then what argument can anyone possibly have for it being optional? > > Even if the server MAY have cached the result and the caching is > > spread > > across sessions, you still have to have some way of priming the cache. > I think this is what DEFINE-GRAMMAR does. Why do you think it doesn't? [Bennett, Patrick] Because all it does is define a grammar for the current session to use. It doesn't define a grammar that could be used by other sessions (with no delay). >=20 > > But of course, you can't (by the spec) prime the cache from a > > different > > session. You'd have to define the grammar in the context of an active > > call! > What in the specification says anything about MRCPv2 sessions being > bound to calls? [Bennett, Patrick] Nothing - I interjected my own term. Typically, speech vendors have license restrictions on how their speech 'ports' may be used [so you can't set up a pool of x resources that handle >x simultaneous users/callers]. A 'call' is thus associated in our system (assuming there are no failures) with a speech session at initiation time and stays with that session for the duration of the call or until the application developer explicitly releases the speech context. Thus, the ability to reference grammars in a larger context is necessary (we compile the grammars separately from recognition sessions and cache the vendor-specific results on distributed servers). >=20 > > What happens for the first caller into an automated attendant > > application as the system he uses takes an indeterminate amount of > > time > > to compile the speech grammar before it even allows recognition! Does > > the customer have to force a dummy call into the system each time a > > dynamic grammar generation process runs? > > > Only if they have a client which waits for an incoming call before it > does anything to prime the server state. [Bennett, Patrick] It's not that simple. You're thinking in terms of a static application. Our customers frequently create highly dynamic systems, with grammars that are composed (or determined) on the fly based on caller identification or input. Since we are able to maintain unique cached state across multiple servers, if caller Y happens to try to use a grammar that caller X just used (which it compiled asynchronously), we are able to guarantee that the grammar doesn't have to be referenced or recompiled. Even if different sessions compose a brand new grammar if the contents of the grammar are the same, we detect that, and use the existing precompiled version. =20 With MRCP, none of this is currently possible. There is nothing in MRCP that specifies how grammars are kept or cached (remember, caching is completely optional! :>), nor whether that cache crosses session boundaries.=20 > > The vendors we currently > > support have well defined means for precompiling grammars which we can > > take advantage of and cache appropriately across large numbers of > > servers. > How can you cache a compiled grammar if you have a mix of servers > from different vendors?=20 [Bennett, Patrick] It's complicated, but we do it. We automatically translate SRGS (ABNF or XML form) grammars to the vendor's own formats as well. So, assuming developers (if you want to call them that) on our system use SRGS for their grammars (and SISR for the semantic tags), then their applications (we call them handlers) can automatically work against any vendor's system we support. Some customers are even looking at using us because they can use vendor X which supports language X well, and vendor Y for their language Y support. =20 > I don't see how MRCPv2 prevents you from > getting the same behavior, assuming the server implementors compile > grammars as a side-effect of fetch, and clients ensure the fetch > happens before the instant recognition is needed (by using DEFINE- > GRAMMAR, for example).=20 [Bennett, Patrick] Not possible. The MRCP server may have to compile the grammar, and it may be a very large one. Even a modest grammar, if it takes more than a couple of seconds to compile is a problem since a user might be waiting at that point. > Would it help if we inserted a SHOULD strength > requirement that servers compile grammars when fetched and not > respond to the associated MRCPv2 request until the compilation is > finished? [Bennett, Patrick] My colleague Felix Wyss wrote the following in an earlier in a thread about caching: Using a stale grammar for calls arriving while the new version is fetched and compiled would be acceptable, provided: 1) There is a flag in the DEFINE-GRAMMAR request to control this behavior. I can think of three possible options: a. Ensure grammar is always up-to date according to the HTTP server's caching headers ("accuracy over latency") b. Allow stale grammars to be used ("latency over accuracy"), but block when grammar is not in the cache at all c. Like b, but fail immediately if grammar is not already in the cache; that way, the application can fallback to something else instead of spuriously blocking. 2) DEFINE-GRAMMAR returns a header or result-code indicating whether a stale grammar is being used=20 3) If a DEFINE-GRAMMAR causes a stale grammar to be used, that grammar must be used for the whole duration of that call or until the next DEFINE-GRAMMAR is issued for it (i.e. the grammar won't unpredictably change between recognitions just because a newer version became ready in the meantime). =20 4) All standard conforming MRCP servers MUST implement the caching behavior this way (i.e. it is not optional or up to the vendor like in RFC 2616). =20 Of course, this still requires the application to ping the servers to update their caches; otherwise some calls may get very stale grammars. =20 > As WG co-chair I'm responsible for both the consensus process and for > the technical quality of the specification. So I take this discussion > very seriously. [Bennett, Patrick] I'm extremely relieved to hear that you are. :) Cheers... Patrick Bennett _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 05:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiTpT-0002Wc-3A; Wed, 15 Jun 2005 05:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiTpR-0002WX-M2 for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 05:04:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24134 for ; Wed, 15 Jun 2005 05:04:55 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiUC3-0000y6-JF for speechsc@ietf.org; Wed, 15 Jun 2005 05:28:23 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 4EB1A214042; Wed, 15 Jun 2005 09:04:43 +0000 (GMT) Message-ID: <04df01c57189$4537f300$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Shanmugham, Saravanan" , "David R. Oran" References: <03772D1EC8DE624A863058C75874A75C05BA51@vtg-um-e2k6.sj21ad.cisco.com> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 10:04:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Bennett, Patrick" 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 did some quick research into extending MIME headers and noted the following: - RFC2045 allows new Content-* extensions - No IANA considerations apply - Seems like new headers introduced in the past have had their own RFC (e.g. RFC2912 and RFC3803). We would be defining a new MIME header inside the MRCP specification... A slicker approach could be to request to the author of the I-D that defines the application/srgs+xml media type (http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes-02.txt) to add an optional parameter called 'weight' so we could use something like: Content-Type: application/srgs+xml;weight=0.75 The values could take on the VoiceXML definition, which I believe has the right amount of generality. I defer to more experienced IETFeers on whether either of these approaches appear tenable. Dave ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "David R. Oran" Cc: ; "Bennett, Patrick" Sent: Tuesday, June 14, 2005 8:24 PM Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type I am fine with Option iii, but the we would be trying to extend MIME headers which I am not sure if its extenisble or what the procedure to define new MIME-headers are. Could find any good examples. So I chose the next best thing which was to use a rule id approach. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 14, 2005 9:41 AM To: David R. Oran Cc: Speechsc@ietf.org; Bennett, Patrick Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type To be clear, I think there are two issues: A. How to word the precedence when input matches more than one active grammar? B. How to specify a weight for a complete grammar? (see http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1023.html) For A, how about appending the sentence in 1. and 2. so that we get: ...the order of inclusion controls the corresponding precedence for the grammars during recognition should the input match more than one active grammar. For B, which point 3 addresses, there are three options discussed: (i) Use the One-Of-Rule-Id-URI mechanism below (ii) Add an informative note that a grammar can be used to apply weights to grammars (One-Of-Rule-Id-URI is unnecessary ) (iii) Go with Jeff's idea of adding a new header to a MIME part (http://www1.ietf.org/mail-archive/web/speechsc/current/msg 01102.html) Small refinement though, the header should be called Content-Grammar-Weight to fit RFC2045's extension mechanism My preference is for (iii) over (ii) because if my MRCP client runs VoiceXML then I'm going to have to handle cases when has a weight attribute and build up a grammar. This is just annoying complexity for the client. Dave ----- Original Message ----- From: "David R. Oran" To: "Dave Burke" Cc: ; "Bennett, Patrick" Sent: Tuesday, June 14, 2005 5:02 PM Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command andtest/uri-listcontent type I agree with Dave, but I also believe the current text is quite torturous and prone to misinterpretation. I had held off screwing around with it because of my shaky understanding of the "one-of-rule- id" stuff but now that I think I can get it right I've taken a whack at it. This is what the in-progress version of the spec says: The RECOGNIZE request uses the message body to specify the grammars applicable to the request. The active grammar(s) for the request can be specified in one of 3 ways. 1. The grammer may be placed directly in the message body using MIME content. If more than one grammar is included in the body, the order of inclusion controls the corresponding precedence for the grammars during recognition. 2. The body may contain a list of grammar URIs specified in a mime- content of type text/uri-list. The order of the URIs determines the corrensponding precedence for the grammars during recognition. 3. The active grammar among a set of grammars can specified using a One-Of-Rule-Id-URI header in the message. This header (see Section 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific rule-id contained in the grammar (or grammars) specified in the body of the message. Are further adjustments needed? On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: > The precedence is not related to weighting. The text here covers the > case if you had two grammars say gram1.grxml and gram2.grxml both of > which recognise the token "speech" but return a different semantic > interpretation. If gram2.grxml follows gram1.grxml in the uri-list > then it is gram1.grxml that is matched and it is gram1.grxml's > semantic interpretation result that is returned in the NLSML. > > This is also required for VoiceXML 2.x behaviour (see http:// > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > Dave > ----- Original Message ----- > From: Bennett, Patrick > To: Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 4:09 PM > Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/ > uri-listcontent type > > According to the latest draft on page 89: > > > ...The RECOGNIZE method MUST carry the grammars that need to be > > activated for that RECOGNIZE method, in its message body. The > > grammars that need to be activated can be specified in one of 3 > > ways. The grammar content could be specified as a mime-content in > > the message body. It could be a simple list of grammar URIs > > specified in a mime-content of type text/uri-list, in which case > the > > order of the URI refer to the precedence order of the grammars > > during the recognize. ... > > > The problem here is the statement "in which case the order of the URI > refer to the precedence order of the grammars during the recognize." > > Well, what is the EXACT precedence? Shouldn't each of the grammars > be considered as equally weighted alternatives? Ideally, all must be > weighted equally unless a specific weight parameter was specified > with each URI. > > As currently specified, this part of the specification is basically > worthless. No MRCP client would ever send multiple URIs to an MRCP > server via a uri-list since the weighting applied to each grammar is > completely undefined. > > This really needs to be corrected. > > > Patrick Bennett > > > > _______________________________________________ > 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 _______________________________________________ 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 Jun 15 05:57:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUeC-0003qB-7a; Wed, 15 Jun 2005 05:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUeB-0003q3-0x for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 05:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27563 for ; Wed, 15 Jun 2005 05:57:20 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiV0p-0003yy-5d for Speechsc@ietf.org; Wed, 15 Jun 2005 06:20:48 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 46CB82140EE; Wed, 15 Jun 2005 09:57:15 +0000 (GMT) Message-ID: <053201c57190$9cd6cf80$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Bennett, Patrick" , "David R. Oran" References: <260A0A30F9017945932CC4F7B911B33901786CD1@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Managing big grammars Date: Wed, 15 Jun 2005 10:57:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Content-Transfer-Encoding: 7bit Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "Wyss, Felix" , "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 Here's my 4 cents (that's 1 cent per point): 1. If the MRCP server temporarily uses stale content in an effort to avoid latency then it is reasonable that the DEFINE-GRAMMAR/RECOGNISE complete response/event includes a warning. RFC2616 would suggest we return something like: Warning: 110 10.0.0.1 Response is stale 2. Allowing DEFINE-GRAMMAR or RECOGNIZE to prefer reduced latency over accuracy seems fine. I'd posit that the default action is to prefer reduced latency. To enforce accuracy (e.g. as one might want during development and testing of an application), a Cache-Control: max-stale=0 could be used. I can't convince myself that we need an option to fail if a resource is not in the cache. 3. Disallowing a grammar in an MRCP session to change outside of that session's invocation DEFINE-GRAMMAR or RECOGNIZE (due to a revalidation in a different MRCP session) seems perfectly reasonable. 4. Given that latencies are much more detrimental to VUIs than GUIs, it seems reasonable to make caching a SHOULD. Fancy optimisations such as a centralised cache and informing other servers in a cluster to reload seem like they ought to remain MAYs. Going for SHOULD over MUST seems reasonable to me to allow dtmfrecog and low-end speechrecogs. Ref. David's comment about protocol engineering encroaching on system engineering. -- Dave ----- Original Message ----- From: "Bennett, Patrick" To: "David R. Oran" Cc: "Reifenrath, Klaus" ; "Dave Burke" ; ; "Shanmugham, Saravanan" ; "Wyss, Felix" Sent: Tuesday, June 14, 2005 10:25 PM Subject: RE: [Speechsc] Managing big grammars Ok, the message thread is starting to get a little cluttered, so I'll just pull out individual statements to respond to them if that's ok. If there's something I didn't respond to that you felt I should have, feel free to drop it back in on future replies. > >What's the point of a standard client protocol if servers can't be > > equally interchanged and provide equal (not least common-denominator) > > functionality? > > > Well, I suspect my company would be less than pleased if all IP > routers could be equally interchangeable simply by conforming to > RFC795 and friends. :-) [Bennett, Patrick] Well, I'm sure many (not at Cisco ;>) would disagree, but I understand what you're saying. Unfortunately, since server implementers are the primary forces behind MRCP at this point, it's possible to question the motives of leaving so many holes in the specification. If you can't drop in another server and get at least as much functionality as any other server then I think the specification is a failure. Of course, what that minimum level of functionality is, well, that's where it gets tricky. :) > Distributed systems are distributed for a reason. If you want a > system which meets specific timing and robustness constraints I don't > think you can look to the protocol specifications to provide that. [Bennett, Patrick] No, I just expect for deterministic behavior to be part of the specification. I disagree with the large number of 'optional' features in the spec which are crucial to a speech system that handles more than a couple of users. > >...By the spec, every > > grammar > > would have to be defined for every single session, every single time, > > and there would be *no* way of knowing if a specific grammar would be > > (re)compiled (it might be a grammar that takes 20 minutes just to > > compile!) for any given session. > That's right. If you want to be certain that all the state is in > place before you fire off a RECOGNIZE request, the client can wait to > enable input calls/sessions from users until it gets back COMPLETE > responses for all the grammars it thinks will need to be active for > the recognizer resource it is talking to. > It can further set the > cache timeouts long enough to have high assurance those grammars > don't get kicked out, and re-do the DEFINE before the cache timers > run out. [Bennett, Patrick] Not possible. The MRCP spec specifically allows the cache information to be ignored. It's entirely optional. Even if the implementor says they adhere to the HTTP 1.1 cache specs, those are optional too. Do you see what I'm saying? I keep seeing messages saying 'well, no reasonable implementation would do that..' - well, why wouldn't they!? The specification doesn't mandate anything of the sort. If the spec thought it was important, it would specifically state the importance of it, why it was necessary, and why it was a MUST requirement for server implementers. >I don't see how this is more onerous than exposing the > various grammar formats and states to the client. For example, > there's nothing which says that the server, even with a compiled > grammar, can't have really stupid precedence handling and spend > seconds juggling the grammar subset for a particular request in order > to do the semantic matching properly. [Bennett, Patrick] That's another issue. I think the MRCP spec is broken there as well. If two grammars match against the same speech utterances, that's an intentional grammar ambiguity and both results should be returned for the client application to process. > > Technically, it MAY take 20 minutes to > > compile for every single caller since the server MAY not pay attention > > to anything I requested [even ignoring the huge problem of no global > > grammar contexts]. > > > I'm not sure what you mean by global grammar contexts, so I can't > comment on that part. [Bennett, Patrick] Just that there is no way to compile large grammar X such that it would be guaranteed to be cached and *instantly* available to *all* subsequent sessions on a particular MRCP server. Grammars have to be defined for each individual session and it must be assumed that each session is completely unique in terms of prior state, as there are no hard caching requirements (caching isn't required at all) nor cross-session grammar knowledge. > I certainly do think that a system which takes > 20 minutes and recompiles grammars for every RECOGNIZE session is > pretty stupidly implemented, [Bennett, Patrick] Exactly. The MRCP spec allows for this. As an ISV providing a platform in which speech applications can be developed using multiple speech vendors (we allow multiple speech engines to be used simultaneously actually), when we add MRCP as one of the available speech integrations, we have to worry about specs that allow vendor X, Y, or Z to behave *completely* differently. Particularly with regard to something as important as speech grammars. If everyone can agree that no reasonable implementation should behave this way, then what argument can anyone possibly have for it being optional? > > Even if the server MAY have cached the result and the caching is > > spread > > across sessions, you still have to have some way of priming the cache. > I think this is what DEFINE-GRAMMAR does. Why do you think it doesn't? [Bennett, Patrick] Because all it does is define a grammar for the current session to use. It doesn't define a grammar that could be used by other sessions (with no delay). > > > But of course, you can't (by the spec) prime the cache from a > > different > > session. You'd have to define the grammar in the context of an active > > call! > What in the specification says anything about MRCPv2 sessions being > bound to calls? [Bennett, Patrick] Nothing - I interjected my own term. Typically, speech vendors have license restrictions on how their speech 'ports' may be used [so you can't set up a pool of x resources that handle >x simultaneous users/callers]. A 'call' is thus associated in our system (assuming there are no failures) with a speech session at initiation time and stays with that session for the duration of the call or until the application developer explicitly releases the speech context. Thus, the ability to reference grammars in a larger context is necessary (we compile the grammars separately from recognition sessions and cache the vendor-specific results on distributed servers). > > > What happens for the first caller into an automated attendant > > application as the system he uses takes an indeterminate amount of > > time > > to compile the speech grammar before it even allows recognition! Does > > the customer have to force a dummy call into the system each time a > > dynamic grammar generation process runs? > > > Only if they have a client which waits for an incoming call before it > does anything to prime the server state. [Bennett, Patrick] It's not that simple. You're thinking in terms of a static application. Our customers frequently create highly dynamic systems, with grammars that are composed (or determined) on the fly based on caller identification or input. Since we are able to maintain unique cached state across multiple servers, if caller Y happens to try to use a grammar that caller X just used (which it compiled asynchronously), we are able to guarantee that the grammar doesn't have to be referenced or recompiled. Even if different sessions compose a brand new grammar if the contents of the grammar are the same, we detect that, and use the existing precompiled version. With MRCP, none of this is currently possible. There is nothing in MRCP that specifies how grammars are kept or cached (remember, caching is completely optional! :>), nor whether that cache crosses session boundaries. > > The vendors we currently > > support have well defined means for precompiling grammars which we can > > take advantage of and cache appropriately across large numbers of > > servers. > How can you cache a compiled grammar if you have a mix of servers > from different vendors? [Bennett, Patrick] It's complicated, but we do it. We automatically translate SRGS (ABNF or XML form) grammars to the vendor's own formats as well. So, assuming developers (if you want to call them that) on our system use SRGS for their grammars (and SISR for the semantic tags), then their applications (we call them handlers) can automatically work against any vendor's system we support. Some customers are even looking at using us because they can use vendor X which supports language X well, and vendor Y for their language Y support. > I don't see how MRCPv2 prevents you from > getting the same behavior, assuming the server implementors compile > grammars as a side-effect of fetch, and clients ensure the fetch > happens before the instant recognition is needed (by using DEFINE- > GRAMMAR, for example). [Bennett, Patrick] Not possible. The MRCP server may have to compile the grammar, and it may be a very large one. Even a modest grammar, if it takes more than a couple of seconds to compile is a problem since a user might be waiting at that point. > Would it help if we inserted a SHOULD strength > requirement that servers compile grammars when fetched and not > respond to the associated MRCPv2 request until the compilation is > finished? [Bennett, Patrick] My colleague Felix Wyss wrote the following in an earlier in a thread about caching: Using a stale grammar for calls arriving while the new version is fetched and compiled would be acceptable, provided: 1) There is a flag in the DEFINE-GRAMMAR request to control this behavior. I can think of three possible options: a. Ensure grammar is always up-to date according to the HTTP server's caching headers ("accuracy over latency") b. Allow stale grammars to be used ("latency over accuracy"), but block when grammar is not in the cache at all c. Like b, but fail immediately if grammar is not already in the cache; that way, the application can fallback to something else instead of spuriously blocking. 2) DEFINE-GRAMMAR returns a header or result-code indicating whether a stale grammar is being used 3) If a DEFINE-GRAMMAR causes a stale grammar to be used, that grammar must be used for the whole duration of that call or until the next DEFINE-GRAMMAR is issued for it (i.e. the grammar won't unpredictably change between recognitions just because a newer version became ready in the meantime). 4) All standard conforming MRCP servers MUST implement the caching behavior this way (i.e. it is not optional or up to the vendor like in RFC 2616). Of course, this still requires the application to ping the servers to update their caches; otherwise some calls may get very stale grammars. > As WG co-chair I'm responsible for both the consensus process and for > the technical quality of the specification. So I take this discussion > very seriously. [Bennett, Patrick] I'm extremely relieved to hear that you are. :) Cheers... Patrick Bennett _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 08:07:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWgR-0005HP-9d; Wed, 15 Jun 2005 08:07:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWgQ-0005HK-8Y for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 08:07:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07800 for ; Wed, 15 Jun 2005 08:07:49 -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 1DiX35-0003Lo-Vo for speechsc@ietf.org; Wed, 15 Jun 2005 08:31:17 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 05:07:39 -0700 X-IronPort-AV: i="3.93,200,1115017200"; d="scan'208"; a="278959304:sNHT32131316" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FC7Wlw003021 for ; Wed, 15 Jun 2005 05:07:32 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FBtEm8019461 for ; Wed, 15 Jun 2005 04:55:15 -0700 Mime-Version: 1.0 (Apple Message framework v730) References: <03772D1EC8DE624A863058C75874A75C05BAE2@vtg-um-e2k6.sj21ad.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Date: Wed, 15 Jun 2005 08:07:35 -0400 To: "speechsc@ietf.org ((((E-mail))))" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118836515.488332"; x:"432200"; a:"rsa-sha1"; b:"nofws:1460"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"OKzxCNN2xPpRoebXRJ6mosSvLDyDAgpS6TP38kqhFwdRS2vRHJKdz95iSKjgYoM3s30TbLjI" "rg77aWE2A+st2jEE5cM6aYtw19Zbeluma61Ue/uXlB4Gs+U0TUIrdDDKmZmlz7IlBG5DJsEzk99" "XbstR1cgVNKber95XpTIy3Nw="; c:"From: =22David R. Oran=22 "; c:"Subject: Widening a private discussion on hotword mode"; c:"Date: Wed, 15 Jun 2005 08:07:35 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Widening a private discussion on hotword mode 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 This started with a query to Sarvi, but based on the exchange it appears worthwhile to entertain a technical change to the specification. Comments pro and con please. Dave. Begin forwarded message: > From: "Shanmugham, Saravanan" > Date: June 14, 2005 10:06:50 PM EDT > To: "David R. Oran" , "Eric Burger" > , "Dan Burnett" > Subject: RE: Query on hotword mode > > > This is what was intended. But I agree that your suggestion is easier > on the client and more appropriate on the for hotwords. > I remember proposing this during the MRCPv1 extensions for this, but > dropped out of the discussion. > > I think you should propose it to the wider audience. > > If you forward this thread to the alias, I can send a proposal for > change in text in the response and seee if anyone has an issue with > this. > > > Sarvi > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 14, 2005 1:43 PM > To: Shanmugham, Saravanan; Eric Burger; Dan Burnett > Subject: Query on hotword mode > > The definition of hotword mode says: > > "Hotword mode is where the recognizer looks for a match > against specific speech grammar or DTMF sequence and > ignores speech or DTMF that does not match. It neither > times out nor generates a no-match. > The recognition completes only for a successful match of > grammar or if the client cancels the request." > > It seems weird that you have to "re-prime" a hotword > recognizer each time it detects a match, rather than let > it continue recognizing and just generating > Recognition-complete events until you tell it to stop by > canceling the operation or issuing a new RECOGNIZE. > > Is this what was intended? > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 10:15:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYan-0006y5-Aj; Wed, 15 Jun 2005 10:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYaj-0006xj-4C for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 10:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18701 for ; Wed, 15 Jun 2005 10:10:03 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiYxP-0002CS-LM for Speechsc@ietf.org; Wed, 15 Jun 2005 10:33:33 -0400 X-SEF-Processed: 5_0_0_713__2005_06_15_09_08_41 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Wed, 15 Jun 2005 09:08:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Wed, 15 Jun 2005 09:09:51 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524D1@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVxkJ32z15nn2uSR8WcbNAVPaYxcAAH53OA From: "Wyss, Felix" To: "Dave Burke" , "Bennett, Patrick" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: Speechsc@ietf.org, "Shanmugham, Saravanan" , "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 > 1. If the MRCP server temporarily uses stale content in an effort to avoid > latency then it is reasonable that the DEFINE-GRAMMAR/RECOGNISE complete > response/event includes a warning. RFC2616 would suggest we return > something > like: >=20 > Warning: 110 10.0.0.1 Response is stale [Felix I. Wyss] I'm fine with that > 2. Allowing DEFINE-GRAMMAR or RECOGNIZE to prefer reduced latency over > accuracy seems fine. I'd posit that the default action is to prefer > reduced > latency. To enforce accuracy (e.g. as one might want during development > and > testing of an application), a Cache-Control: max-stale=3D0 could be used. I > can't convince myself that we need an option to fail if a resource is not > in the cache. [Felix I. Wyss] Using max-stale=3D0 on the DEFINE-GRAMMAR request seems reasonable to me. =20 Without an the ability to have DEFINE-GRAMMAR fail immediately if an item is not in the cache (i.e. probing the cache), clients will have to use timeouts in their MRCP stack if they want to enforce an upper bound on grammar registration latency and provide automatic fallback. It just seems it'd be really easy for the server to provide this information. =20 >=20 > 3. Disallowing a grammar in an MRCP session to change outside of that > session's invocation DEFINE-GRAMMAR or RECOGNIZE (due to a revalidation in > a different MRCP session) seems perfectly reasonable. [Felix I. Wyss] It's a MUST then, right? >=20 > 4. Given that latencies are much more detrimental to VUIs than GUIs, it > seems reasonable to make caching a SHOULD. Fancy optimisations such as a > centralised cache and informing other servers in a cluster to reload seem > like they ought to remain MAYs. Going for SHOULD over MUST seems > reasonable > to me to allow dtmfrecog and low-end speechrecogs. Ref. David's comment > about protocol engineering encroaching on system engineering. [Felix I. Wyss] I can live with that. =20 I recommend that there be a discussion on grammar registration latency and caching strategies in the specification to ensure implementers (both servers and clients) are aware of the issues. =20 Felix _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 10:31:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYv4-0003h9-43; Wed, 15 Jun 2005 10:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYv3-0003h4-3P for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 10:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21130 for ; Wed, 15 Jun 2005 10:31:03 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiZHk-0003fS-Q0 for speechsc@ietf.org; Wed, 15 Jun 2005 10:54:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 07:30:55 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FEUjlw012734; Wed, 15 Jun 2005 07:30:45 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 07:30:50 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05BB1D@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type Thread-Index: AcVxiU9O3qNS2P9IQpiZyKC9ZS4mOAALWm4g From: "Shanmugham, Saravanan" To: "Dave Burke" , "David R. Oran" X-Spam-Score: 2.0 (++) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 =20 -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Wednesday, June 15, 2005 2:05 AM To: Shanmugham, Saravanan; David R. Oran Cc: speechsc@ietf.org; Bennett, Patrick Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE=20 commandandtest/uri-listcontent type =20 I did some quick research into extending MIME headers and noted the following: - RFC2045 allows new Content-* extensions - No IANA considerations apply - Seems like new headers introduced in the past have=20 had their own RFC (e.g. RFC2912 and RFC3803). =20 We would be defining a new MIME header inside the MRCP=20 specification... =20 A slicker approach could be to request to the author of=20 the I-D that defines the application/srgs+xml media type (http://www.ietf.org/internet-drafts/draft-froumentin-voice -mediatypes-02.txt) to add an optional parameter called 'weight' so we could=20 use something like: =20 Content-Type: application/srgs+xml;weight=3D0.75 =20 The values could take on the VoiceXML definition, which I=20 believe has the right amount of generality. I like this idea.=20 Sarvi =20 I defer to more experienced IETFeers on whether either of=20 these approaches appear tenable. =20 Dave =20 ----- Original Message ----- From: "Shanmugham, Saravanan" To: "Dave Burke" ; "David R. Oran" Cc: ; "Bennett, Patrick"=20 Sent: Tuesday, June 14, 2005 8:24 PM Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE=20 commandandtest/uri-listcontent type =20 =20 I am fine with Option iii, but the we would be trying to=20 extend MIME headers which I am not sure if its extenisble or what the=20 procedure to define new MIME-headers are. Could find any good examples. =20 So I chose the next best thing which was to use a rule id approach. =20 Sarvi =20 -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Tuesday, June 14, 2005 9:41 AM To: David R. Oran Cc: Speechsc@ietf.org; Bennett, Patrick Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type =20 To be clear, I think there are two issues: A. How to word the precedence when input matches more than one active grammar? B. How to specify a weight for a complete grammar? (see http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 1023.html) =20 For A, how about appending the sentence in 1. and 2. so that we get: =20 ...the order of inclusion controls the corresponding precedence for the grammars during recognition should the input match more than one active grammar. =20 For B, which point 3 addresses, there are three=20 options discussed: (i) Use the One-Of-Rule-Id-URI mechanism below (ii) Add an informative note that a grammar can be used to apply weights to grammars (One-Of-Rule-Id-URI is unnecessary ) (iii) Go with Jeff's idea of adding a new header to a=20 MIME part (http://www1.ietf.org/mail-archive/web/speechsc/current/msg 01102.html) Small refinement though, the header should be called Content-Grammar-Weight to fit RFC2045's=20 extension mechanism =20 My preference is for (iii) over (ii) because if my MRCP client runs VoiceXML then I'm going to have to handle cases when has a weight attribute and build up a grammar. This is just annoying complexity=20 for the client. =20 Dave =20 =20 ----- Original Message ----- From: "David R. Oran" To: "Dave Burke" Cc: ; "Bennett, Patrick" Sent: Tuesday, June 14, 2005 5:02 PM Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE command andtest/uri-listcontent type =20 =20 I agree with Dave, but I also believe the current text is quite torturous and prone to misinterpretation. I had held off screwing around with it because of my shaky understanding of the "one-of-rule- id" stuff but now that I think I can get it right I've taken a whack at it. =20 This is what the in-progress version of the spec says: =20 The RECOGNIZE request uses the message body to specify the grammars applicable to the request. The active grammar(s) for the request can be specified in one of 3 ways. =20 1. The grammer may be placed directly in the message body using MIME content. If more than one grammar is included in the body, the order of inclusion controls the corresponding precedence for the grammars during recognition. 2. The body may contain a list of grammar URIs specified in a mime- content of type text/uri-list. The order of the URIs determines the corrensponding precedence for the grammars during recognition. 3. The active grammar among a set of grammars can specified using a One-Of-Rule-Id-URI header in the message. This header (see Section 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific rule-id contained in the grammar (or grammars) specified in the body of the message. =20 Are further adjustments needed? =20 =20 On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: =20 > The precedence is not related to weighting. The text here covers the > case if you had two grammars say gram1.grxml and gram2.grxml both of > which recognise the token "speech" but return a different semantic > interpretation. If gram2.grxml follows gram1.grxml in the uri-list > then it is gram1.grxml that is matched and it is =20 gram1.grxml's > semantic interpretation result that is returned in =20 the NLSML. > > This is also required for VoiceXML 2.x behaviour=20 (see http:// > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > Dave > ----- Original Message ----- > From: Bennett, Patrick > To: Speechsc@ietf.org > Sent: Tuesday, June 14, 2005 4:09 PM > Subject: [Speechsc] Problem with draft-6 RECOGNIZE command and test/ > uri-listcontent type > > According to the latest draft on page 89: > > > ...The RECOGNIZE method MUST carry the grammars=20 that need to be > > activated for that RECOGNIZE method, in its=20 message body. The > > grammars that need to be activated can be specified in one of 3 > > ways. The grammar content could be specified as a mime-content in > > the message body. It could be a simple list of=20 grammar URIs > > specified in a mime-content of type text/uri-list, in which case > the > > order of the URI refer to the precedence order=20 of the grammars > > during the recognize. ... > > > The problem here is the statement "in which case the order of the URI > refer to the precedence order of the grammars during the recognize." > > Well, what is the EXACT precedence? Shouldn't each of the grammars > be considered as equally weighted alternatives? Ideally, all must be > weighted equally unless a specific weight parameter was specified > with each URI. > > As currently specified, this part of the specification is basically > worthless. No MRCP client would ever send multiple URIs to an MRCP > server via a uri-list since the weighting applied to each grammar is > completely undefined. > > This really needs to be corrected. > > > Patrick Bennett > > > > _______________________________________________ > 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 > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =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 Wed Jun 15 10:33:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYxX-00041r-GZ; Wed, 15 Jun 2005 10:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiYxV-00041m-I2 for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 10:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21403 for ; Wed, 15 Jun 2005 10:33:35 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiZKD-0003p7-Ha for speechsc@ietf.org; Wed, 15 Jun 2005 10:57:05 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 07:33:28 -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 j5FEXQbw012608 for ; Wed, 15 Jun 2005 07:33:26 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FEL2pK020452 for ; Wed, 15 Jun 2005 07:21:03 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <4F4AB041-9E7B-4EAD-A0DE-A43F108C7AFB@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Wed, 15 Jun 2005 10:33:23 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118845263.870454"; x:"432200"; a:"rsa-sha1"; b:"nofws:1762"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"WMc5Xac+hVTr31IBOGG60MXjkKk/Y3q0DB17puWa0NYKJla3PYIIZUhcAxYzskfii7mFVYTq" "xy8HwL66OlGbB6hH9zCRNTAnijtJ8j+xMu1rczZYk5OydF48r4+wmkeTnENOculuKEnOePyhvVT" "k0cQMsQo7csuaQS0MAC3ZeKc="; c:"From: =22David R. Oran=22 "; c:"Subject: Server capabilities"; c:"Date: Wed, 15 Jun 2005 10:33:23 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [Speechsc] Server capabilities 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 This message was prompted by one aspect of the discussion on the list about large grammars, which is how a client can figure out in advance just what a server can and can't do, so it isn't "unpleasantly surprised" at the instant it issues a method. The current specification walks a fine line between giving flexibility to server implementers and giving clients a sufficient degree of control over server behavior. For example we have things like multiple jump-length units which a server may or may not support, server-specific default values for confidence-threshold and speed-vs-accuracy, and a bunch of others. There is some for this support, including: 1) through SDP and SIP OPTIONS the client can discover what resources the server supports and what media formats it can process. 2) through GET-PARAMS on a particular session with a resource the client can discover any implementation-specific server default values for MRCPv2 protocol headers. My question to the WG is what, if anything do we need beyond these? Here's a small list of candidates. Feel free to comment and/or propose your own: a) we may want/need a way for the server to determine what audio formats a client supports for the purposes of returning captured audio. Right now we don't even have a way for the client to tell the server what format it wants audio returned in, so we at least have to remedy that omission. b) we may want a way for a client to learn the current list of "instantly available" grammars the server has handy and which are in some way "guaranteed" to persist for a while. c) we may want a form of GET-PARAMS which fetches session-independent server information. One way to do this is to define a MRCPv2-frag content type (like we have with sipfrag). That way a SIP OPTIONs to an MRCPv2 server can return an MRCP-specific body with all that interesting information about server capabilities. I don't want this to necessary turn into a free-for-all, because we really do want to reach closure on the spec and get it to last call. My target for finishing my chair review and editing is the end of this week. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 10:37:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZ0p-00050A-8w; Wed, 15 Jun 2005 10:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZ0o-000505-8u for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 10:37:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21920 for ; Wed, 15 Jun 2005 10:37:00 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiZNV-00044x-UV for speechsc@ietf.org; Wed, 15 Jun 2005 11:00:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 07:36: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 j5FEalbw014328 for ; Wed, 15 Jun 2005 07:36:48 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FEONlK020477 for ; Wed, 15 Jun 2005 07:24:24 -0700 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <03772D1EC8DE624A863058C75874A75C05BB1D@vtg-um-e2k6.sj21ad.cisco.com> References: <03772D1EC8DE624A863058C75874A75C05BB1D@vtg-um-e2k6.sj21ad.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE commandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 10:36:44 -0400 To: "speechsc@ietf.org ((((E-mail))))" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118845465.572846"; x:"432200"; a:"rsa-sha1"; b:"nofws:6867"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"jJyQ7/5nB1unmE9vak+dNORWGw6eaIle6ScBmVlYsaaUHMpS0cyCWKyPXjRmONdJ1UydJryv" "8Nk3D4uZMZs7b/rhPtJDTM1zPmSFLrf+nHLcgmZ0bWaRvdBhAU60+VOzKIKcFROS4y160pMDdh4" "UCTSXQbXKfeDa4j4aH3wLvaQ="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE commandandtes" "t/uri-listcontent type"; c:"Date: Wed, 15 Jun 2005 10:36:44 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 2.0 (++) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Content-Transfer-Encoding: 7bit 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 sent a query to Max to see if he was amenable to adding a weight parameter to the srgs mime registration. I'll let the WG know the status as soon as I hear back. Dave. On Jun 15, 2005, at 10:30 AM, Shanmugham, Saravanan wrote: > > > -----Original Message----- > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Wednesday, June 15, 2005 2:05 AM > To: Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type > > I did some quick research into extending MIME headers and > noted the > following: > - RFC2045 allows new Content-* extensions > - No IANA considerations apply > - Seems like new headers introduced in the past have > had their own RFC (e.g. RFC2912 and RFC3803). > > We would be defining a new MIME header inside the MRCP > specification... > > A slicker approach could be to request to the author of > the I-D that defines the application/srgs+xml media type > (http://www.ietf.org/internet-drafts/draft-froumentin-voice > -mediatypes-02.txt) > to add an optional parameter called 'weight' so we could > use something like: > > Content-Type: application/srgs+xml;weight=0.75 > > The values could take on the VoiceXML definition, which I > believe has the right amount of generality. > > I like this idea. > > Sarvi > > I defer to more experienced IETFeers on whether either of > these approaches appear tenable. > > Dave > > ----- Original Message ----- > From: "Shanmugham, Saravanan" > To: "Dave Burke" ; "David R. Oran" > > Cc: ; "Bennett, Patrick" > > Sent: Tuesday, June 14, 2005 8:24 PM > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type > > > I am fine with Option iii, but the we would be trying to > extend MIME > headers which I am not sure if its extenisble or what the > procedure to > define new MIME-headers are. Could find any good examples. > > So I chose the next best thing which was to use a > rule id > approach. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke > Sent: Tuesday, June 14, 2005 9:41 AM > To: David R. Oran > Cc: Speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type > > To be clear, I think there are two issues: > A. How to word the precedence when input matches more than > one active grammar? > B. How to specify a weight for a complete grammar? (see > http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 > 1023.html) > > For A, how about appending the sentence in 1. and 2. so > that we get: > > ...the order of inclusion controls the corresponding > precedence for the grammars during recognition should the > input match more than one active grammar. > > For B, which point 3 addresses, there are three > options discussed: > (i) Use the One-Of-Rule-Id-URI mechanism below > (ii) Add an informative note that a grammar can > be used to apply weights to grammars (One-Of-Rule-Id-URI > is unnecessary ) > (iii) Go with Jeff's idea of adding a new header to a > MIME part > (http://www1.ietf.org/mail-archive/web/speechsc/current/msg > 01102.html) Small refinement though, the header should be > called Content-Grammar-Weight to fit RFC2045's > extension mechanism > > My preference is for (iii) over (ii) because if my MRCP > client runs VoiceXML then I'm going to have to handle > cases when has a weight attribute and build up a > grammar. This is just annoying complexity > for the client. > > Dave > > > ----- Original Message ----- > From: "David R. Oran" > To: "Dave Burke" > Cc: ; "Bennett, Patrick" > > Sent: Tuesday, June 14, 2005 5:02 PM > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > command andtest/uri-listcontent type > > > I agree with Dave, but I also believe the current text is > quite torturous and prone to misinterpretation. I had held > off screwing around with it because of my shaky > understanding of the "one-of-rule- id" stuff but now that > I think I can get it right I've taken a whack at it. > > This is what the in-progress version of the spec says: > > The RECOGNIZE request uses the message body to specify the > grammars applicable to the request. The active grammar(s) > for the request can be specified in one of 3 ways. > > 1. The grammer may be placed directly in the message body > using MIME content. If more than one grammar is included > in the body, the order of inclusion controls the > corresponding precedence for the grammars during > recognition. > 2. The body may contain a list of grammar URIs specified > in a mime- content of type text/uri-list. The order of the > URIs determines the corrensponding precedence for the > grammars during recognition. > 3. The active grammar among a set of grammars can > specified using a One-Of-Rule-Id-URI header in the > message. This header (see Section > 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific > rule-id contained in the grammar (or grammars) specified > in the body of the message. > > Are further adjustments needed? > > > On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: > > >> The precedence is not related to weighting. The text >> > here covers the > >> case if you had two grammars say gram1.grxml and >> > gram2.grxml both of > >> which recognise the token "speech" but return a >> > different semantic > >> interpretation. If gram2.grxml follows gram1.grxml in >> > the uri-list > >> then it is gram1.grxml that is matched and it is >> > gram1.grxml's > >> semantic interpretation result that is returned in >> > the NLSML. > >> >> This is also required for VoiceXML 2.x behaviour >> > (see http:// > >> www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). >> >> Dave >> ----- Original Message ----- >> From: Bennett, Patrick >> To: Speechsc@ietf.org >> Sent: Tuesday, June 14, 2005 4:09 PM >> Subject: [Speechsc] Problem with draft-6 RECOGNIZE >> > command and test/ > >> uri-listcontent type >> >> According to the latest draft on page 89: >> >> >> ...The RECOGNIZE method MUST carry the grammars >> > that need to > be > >> >> activated for that RECOGNIZE method, in its >> > message body. The > >> >> grammars that need to be activated can be specified >> > in one of 3 > >> >> ways. The grammar content could be specified as a >> > mime-content in > >> >> the message body. It could be a simple list of >> > grammar URIs > >> >> specified in a mime-content of type text/uri-list, in >> > which case > >> the >> >> order of the URI refer to the precedence order >> > of the grammars > >> >> during the recognize. ... >> >> >> The problem here is the statement "in which case the >> > order of the URI > >> refer to the precedence order of the grammars during >> > the recognize." > >> >> Well, what is the EXACT precedence? Shouldn't each of >> > the grammars > >> be considered as equally weighted alternatives? >> > Ideally, all must be > >> weighted equally unless a specific weight parameter was >> > specified > >> with each URI. >> >> As currently specified, this part of the specification >> > is basically > >> worthless. No MRCP client would ever send multiple URIs >> > to an MRCP > >> server via a uri-list since the weighting applied to >> > each grammar is > >> completely undefined. >> >> This really needs to be corrected. >> >> >> Patrick Bennett >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 Jun 15 11:21:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZhT-0006x9-7h; Wed, 15 Jun 2005 11:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZhQ-0006uS-Rh; Wed, 15 Jun 2005 11:21:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25983; Wed, 15 Jun 2005 11:20:58 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dia43-0006wr-Tl; Wed, 15 Jun 2005 11:44:29 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j5FFKj2h350790; Wed, 15 Jun 2005 11:20:45 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5FFKi0E127862; Wed, 15 Jun 2005 09:20:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j5FFKi6N014916; Wed, 15 Jun 2005 09:20: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 j5FFKiOb014912; Wed, 15 Jun 2005 09:20:44 -0600 In-Reply-To: To: "David R. Oran" MIME-Version: 1.0 Subject: Re: [Speechsc] Widening a private discussion on hotword mode X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 15 Jun 2005 11:20:42 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/15/2005 09:20:44, Serialize complete at 06/15/2005 09:20:44 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" , speechsc-bounces@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 suggestion sounds like adding convolution to the Recognizer resource state machine, by altering it to require multiple RECOGNITION-COMPLETE events. I would like to ensure that the thread we had a month ago on hotword is addressed, as I never got a final response/consensus. [Speechsc] MRCPv2 Hotword Mode Recognition clarification http://www.ietf.org/mail-archive/web/speechsc/current/msg01239.html I would vote to keep the current Recognizer state machine consistent for both recognition modes, and to modify the wording w.r.t timers as proposed in the thread identified above. I would think that for most scenarios, a hotword recognition match would typically require application execution changes such that a new grammar set is loaded and re-recognition is required. For this reason I don't believe that the specification should be modified to workaround an exception case. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "David R. Oran" Sent by: speechsc-bounces@ietf.org 06/15/2005 08:07 AM To "speechsc@ietf.org ((((E-mail))))" cc Subject [Speechsc] Widening a private discussion on hotword mode This started with a query to Sarvi, but based on the exchange it appears worthwhile to entertain a technical change to the specification. Comments pro and con please. Dave. Begin forwarded message: > From: "Shanmugham, Saravanan" > Date: June 14, 2005 10:06:50 PM EDT > To: "David R. Oran" , "Eric Burger" > , "Dan Burnett" > Subject: RE: Query on hotword mode > > > This is what was intended. But I agree that your suggestion is easier > on the client and more appropriate on the for hotwords. > I remember proposing this during the MRCPv1 extensions for this, but > dropped out of the discussion. > > I think you should propose it to the wider audience. > > If you forward this thread to the alias, I can send a proposal for > change in text in the response and seee if anyone has an issue with > this. > > > Sarvi > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 14, 2005 1:43 PM > To: Shanmugham, Saravanan; Eric Burger; Dan Burnett > Subject: Query on hotword mode > > The definition of hotword mode says: > > "Hotword mode is where the recognizer looks for a match > against specific speech grammar or DTMF sequence and > ignores speech or DTMF that does not match. It neither > times out nor generates a no-match. > The recognition completes only for a successful match of > grammar or if the client cancels the request." > > It seems weird that you have to "re-prime" a hotword > recognizer each time it detects a match, rather than let > it continue recognizing and just generating > Recognition-complete events until you tell it to stop by > canceling the operation or issuing a new RECOGNIZE. > > Is this what was intended? > > _______________________________________________ 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 Jun 15 11:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZky-0007Zm-Nc; Wed, 15 Jun 2005 11:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZkx-0007Zh-3A for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 11:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26142 for ; Wed, 15 Jun 2005 11:24:40 -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 1Dia7e-00077M-JU for speechsc@ietf.org; Wed, 15 Jun 2005 11:48:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 08:24:06 -0700 X-IronPort-AV: i="3.93,201,1115017200"; d="scan'208"; a="279025156:sNHT10182408158" 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 j5FFO2bw015145 for ; Wed, 15 Jun 2005 08:24:02 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FFBf5o020840 for ; Wed, 15 Jun 2005 08:11:41 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <9D3DCB56-D4A5-48E4-8C4B-6660183E2932@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Wed, 15 Jun 2005 11:24:02 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118848302.148374"; x:"432200"; a:"rsa-sha1"; b:"nofws:1448"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"VcNEgY/SmFptCjadgBz4UU8e5gdoXeIQmbqa/2DXW+2HORh7KegbRuiNrXZlghIdR2x9HZls" "xEMRngUeKpGKlShaV1LHTXOsW6omRcHsuTz0Gd/kGsPIo4Cgkn4oIo00IYNfVqYD3KzyhS1Ez2/" "rvvmPoY2TWe/E5rmewcf8N6U="; c:"From: =22David R. Oran=22 "; c:"Subject: new-audio-channel"; c:"Date: Wed, 15 Jun 2005 11:24:02 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Speechsc] new-audio-channel 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 Sorry to keep barraging the WG with these editing points - I'm really getting close to the end of the chair review of the spec. This query concerns the "new-audio-channel" header on RECOGNIZE requests. 1. Shouldn't this be called "audio-source-changed"? It might not be strictly speaking "new". And it may not be the channel that changed (e.g. My MRCPv2 client might be on an IP phone and the user switches from speakerphone to headset). 2. Do we need to say anything about whether servers ought to have separate resource state on one session from different SSRCs of a single media session? The client may not even know this is happening. 3. The current text says MUST in a few places that seem restrictive and unenforceable: "This header MAY be specified in a RECOGNIZE request and allows the client to tell the server that, from this point on, further input audio comes from a different audio source, channel or speaker. If the recognition resource had collected any input statistics or adaptation state, it MUST discard the state and start fresh for this RECOGNIZE request. Note that if there are multiple resources on the same SIP dialog that may be collecting or using this data, the client MUST declare a new audio channel for all these resources. This helps in a numbe of use case, including where the client wishes to reuse an open recognition session with an existing media session for multiple telephone calls." The first MUST is too restrictive because some adaptations may be independent of the source or channel. The second MUST is too restrictive because the client may not even be aware of the change, and the server can't depend on the client detection working deterministically. I thinks both of these ought to be SHOULDs. Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 11:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZqA-0008Ea-35; Wed, 15 Jun 2005 11:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZq7-0008E7-UI for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 11:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26457 for ; Wed, 15 Jun 2005 11:30:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiaCq-0007RU-A9 for speechsc@ietf.org; Wed, 15 Jun 2005 11:53:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 08:29:54 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5FFTplq026616; Wed, 15 Jun 2005 08:29:51 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FFHR2A020875; Wed, 15 Jun 2005 08:17:28 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Widening a private discussion on hotword mode Date: Wed, 15 Jun 2005 11:29:49 -0400 To: Brett Gavagni X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118848648.855196"; x:"432200"; a:"rsa-sha1"; b:"nofws:2914"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"YbwsEHKIk2rqlzJiI4lVc3w98gMHiy2rqZ1ujP9vAa7mUEwsA7VIkVgMkvsRoGZlhL9My6k1" "rIEgY3L2bbNbBcEsYE+HOu2E0Ukp3o3doI8FlgGdTGTprh0s+g1evkVGFvTyBnHdfWcohW/XeZF" "YBVXjPjc28Szx2dUlTqdBBG8="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Widening a private discussion on hotword mod" "e"; c:"Date: Wed, 15 Jun 2005 11:29:49 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" 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 Thanks, I'll make sure we get the timer issue dealt with on this editing pass. Sarvi's on the hook to resolve it. Dave. On Jun 15, 2005, at 11:20 AM, Brett Gavagni wrote: > The suggestion sounds like adding convolution to the Recognizer > resource > state machine, by altering it to require multiple RECOGNITION-COMPLETE > events. > > I would like to ensure that the thread we had a month ago on > hotword is > addressed, as I never got a final response/consensus. > > [Speechsc] MRCPv2 Hotword Mode Recognition clarification > http://www.ietf.org/mail-archive/web/speechsc/current/msg01239.html > > I would vote to keep the current Recognizer state machine > consistent for > both recognition modes, and to modify the wording w.r.t timers as > proposed > in the thread identified above. > > I would think that for most scenarios, a hotword recognition match > would > typically require application execution changes such that a new > grammar > set is loaded and re-recognition is required. For this reason I don't > believe that the specification should be modified to workaround an > exception case. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "David R. Oran" > Sent by: speechsc-bounces@ietf.org > 06/15/2005 08:07 AM > > To > "speechsc@ietf.org ((((E-mail))))" > cc > > Subject > [Speechsc] Widening a private discussion on hotword mode > > > > > > > This started with a query to Sarvi, but based on the exchange it > appears worthwhile to entertain a technical change to the > specification. > > Comments pro and con please. > > Dave. > > Begin forwarded message: > > >> From: "Shanmugham, Saravanan" >> Date: June 14, 2005 10:06:50 PM EDT >> To: "David R. Oran" , "Eric Burger" >> , "Dan Burnett" >> Subject: RE: Query on hotword mode >> >> >> This is what was intended. But I agree that your suggestion is >> easier >> on the client and more appropriate on the for hotwords. >> I remember proposing this during the MRCPv1 extensions for this, but >> dropped out of the discussion. >> >> I think you should propose it to the wider audience. >> >> If you forward this thread to the alias, I can send a proposal for >> change in text in the response and seee if anyone has an issue with >> this. >> >> >> Sarvi >> >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Tuesday, June 14, 2005 1:43 PM >> To: Shanmugham, Saravanan; Eric Burger; Dan Burnett >> Subject: Query on hotword mode >> >> The definition of hotword mode says: >> >> "Hotword mode is where the recognizer looks for a match >> against specific speech grammar or DTMF sequence and >> ignores speech or DTMF that does not match. It neither >> times out nor generates a no-match. >> The recognition completes only for a successful match of >> grammar or if the client cancels the request." >> >> It seems weird that you have to "re-prime" a hotword >> recognizer each time it detects a match, rather than let >> it continue recognizing and just generating >> Recognition-complete events until you tell it to stop by >> canceling the operation or issuing a new RECOGNIZE. >> >> Is this what was intended? >> >> >> > > _______________________________________________ > 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 Jun 15 12:53:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dib8f-0007z1-Ap; Wed, 15 Jun 2005 12:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dib8d-0007yq-Gz for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 12:53:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03023 for ; Wed, 15 Jun 2005 12:53:12 -0400 (EDT) Received: from [199.4.160.64] (helo=pb-exchcon2.scansoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DibVH-0003yn-QT for speechsc@ietf.org; Wed, 15 Jun 2005 13:16:45 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Wed, 15 Jun 2005 12:52:29 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , "speechsc@ietf.org ((((E-mail))))" Subject: RE: [Speechsc] Server capabilities Date: Wed, 15 Jun 2005 12:44:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org >From my point of view it is even more important to enable the client to request the right MRCP that has defined capabilities (installed languages, "instantly available" grammars, support of some optional MRCP method, ...). In earlier threads and F2F meetings we discussed preference based SIP routing. But this unfortunately never made it into the spec. Your option c) seems to be one step in this direction. Regards, Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Mittwoch, 15. Juni 2005 16:33 To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] Server capabilities This message was prompted by one aspect of the discussion on the list about large grammars, which is how a client can figure out in advance just what a server can and can't do, so it isn't "unpleasantly surprised" at the instant it issues a method. The current specification walks a fine line between giving flexibility to server implementers and giving clients a sufficient degree of control over server behavior. For example we have things like multiple jump-length units which a server may or may not support, server-specific default values for confidence-threshold and speed-vs-accuracy, and a bunch of others. There is some for this support, including: 1) through SDP and SIP OPTIONS the client can discover what resources the server supports and what media formats it can process. 2) through GET-PARAMS on a particular session with a resource the client can discover any implementation-specific server default values for MRCPv2 protocol headers. My question to the WG is what, if anything do we need beyond these? Here's a small list of candidates. Feel free to comment and/or propose your own: a) we may want/need a way for the server to determine what audio formats a client supports for the purposes of returning captured audio. Right now we don't even have a way for the client to tell the server what format it wants audio returned in, so we at least have to remedy that omission. b) we may want a way for a client to learn the current list of "instantly available" grammars the server has handy and which are in some way "guaranteed" to persist for a while. c) we may want a form of GET-PARAMS which fetches session-independent server information. One way to do this is to define a MRCPv2-frag content type (like we have with sipfrag). That way a SIP OPTIONs to an MRCPv2 server can return an MRCP-specific body with all that interesting information about server capabilities. I don't want this to necessary turn into a free-for-all, because we really do want to reach closure on the spec and get it to last call. My target for finishing my chair review and editing is the end of this week. _______________________________________________ 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 Jun 15 13:18:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibXQ-0003bv-O3; Wed, 15 Jun 2005 13:18:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibXQ-0003bo-8F for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 13:18:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04955 for ; Wed, 15 Jun 2005 13:18:49 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dibu9-0005Xe-Gw for speechsc@ietf.org; Wed, 15 Jun 2005 13:42:21 -0400 Received: from postcard.nuance.com ([10.3.6.20]:40267) by letter.nuance.com with esmtp id 1DibXC-00087o-Aa; Wed, 15 Jun 2005 10:18:38 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Jun 2005 13:16:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Widening a private discussion on hotword mode Date: Wed, 15 Jun 2005 13:16:38 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802DF12C4@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Widening a private discussion on hotword mode Thread-Index: AcVxosjtdu15W4srSZS2agVJtxLdqQACNCKg From: "Pierre Forgues" To: "David R. Oran" , X-OriginalArrivalTime: 15 Jun 2005 17:16:39.0744 (UTC) FILETIME=[FE3AFC00:01C571CD] X-FromHost: postcard.nuance.com [10.3.6.20]:40267 Lines: 81 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org It is not too much of an issue to "re-prime" the recognizer on the hotword resource once it reports a recognition. This is also consistent with the state machinery for a regular recognition. Finally, I can think of no realistic VoiceXML application that could handle this. If people still want to pursue this then it might be useful to setup a separate discussion on this. Pierre -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Wednesday, June 15, 2005 8:08 AM To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] Widening a private discussion on hotword mode This started with a query to Sarvi, but based on the exchange it =20 appears worthwhile to entertain a technical change to the specification. Comments pro and con please. Dave. Begin forwarded message: > From: "Shanmugham, Saravanan" > Date: June 14, 2005 10:06:50 PM EDT > To: "David R. Oran" , "Eric Burger" =20 > , "Dan Burnett" > Subject: RE: Query on hotword mode > > > This is what was intended. But I agree that your suggestion is easier > on the client and more appropriate on the for hotwords. > I remember proposing this during the MRCPv1 extensions for this, but > dropped out of the discussion. > > I think you should propose it to the wider audience. > > If you forward this thread to the alias, I can send a proposal for > change in text in the response and seee if anyone has an issue with > this. > > > Sarvi > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 14, 2005 1:43 PM > To: Shanmugham, Saravanan; Eric Burger; Dan Burnett > Subject: Query on hotword mode > > The definition of hotword mode says: > > "Hotword mode is where the recognizer looks for a match > against specific speech grammar or DTMF sequence and > ignores speech or DTMF that does not match. It neither > times out nor generates a no-match. > The recognition completes only for a successful match of > grammar or if the client cancels the request." > > It seems weird that you have to "re-prime" a hotword > recognizer each time it detects a match, rather than let > it continue recognizing and just generating > Recognition-complete events until you tell it to stop by > canceling the operation or issuing a new RECOGNIZE. > > Is this what was intended? > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 14:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DicY2-0006uU-Ei; Wed, 15 Jun 2005 14:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DicY1-0006uP-Rq for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 14:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12406 for ; Wed, 15 Jun 2005 14:23:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dicuk-0001KY-Mu for speechsc@ietf.org; Wed, 15 Jun 2005 14:47:04 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 11:23:19 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FIN8m0007364; Wed, 15 Jun 2005 11:23:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Widening a private discussion on hotword mode Date: Wed, 15 Jun 2005 11:23:10 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05BB86@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Widening a private discussion on hotword mode Thread-Index: AcVxv95OK3IwE6MdTl+e7JJhz16V4QAF0T2Q From: "Shanmugham, Saravanan" To: "David R. Oran" , "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 Sure. I fine with just addressing the timeout issue and leave it at that. Will get back to you with a proposal. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Wednesday, June 15, 2005 8:30 AM To: Brett Gavagni Cc: speechsc@ietf.org ((((E-mail)))) Subject: Re: [Speechsc] Widening a private discussion on=20 hotword mode =20 Thanks, I'll make sure we get the timer issue dealt with=20 on this editing pass. Sarvi's on the hook to resolve it. =20 Dave. =20 On Jun 15, 2005, at 11:20 AM, Brett Gavagni wrote: =20 > The suggestion sounds like adding convolution to the Recognizer=20 > resource state machine, by altering it to require multiple=20 > RECOGNITION-COMPLETE events. > > I would like to ensure that the thread we had a month=20 ago on hotword=20 > is addressed, as I never got a final response/consensus. > > [Speechsc] MRCPv2 Hotword Mode Recognition clarification=20 >=20 http://www.ietf.org/mail-archive/web/speechsc/current/msg01239.html > > I would vote to keep the current Recognizer state=20 machine consistent=20 > for both recognition modes, and to modify the wording=20 w.r.t timers as=20 > proposed in the thread identified above. > > I would think that for most scenarios, a hotword=20 recognition match=20 > would typically require application execution changes=20 such that a new=20 > grammar set is loaded and re-recognition is required.=20 For this reason=20 > I don't believe that the specification should be modified to=20 > workaround an exception case. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "David R. Oran" > Sent by: speechsc-bounces@ietf.org > 06/15/2005 08:07 AM > > To > "speechsc@ietf.org ((((E-mail))))" cc > > Subject > [Speechsc] Widening a private discussion on hotword mode > > > > > > > This started with a query to Sarvi, but based on the exchange it=20 > appears worthwhile to entertain a technical change to the=20 > specification. > > Comments pro and con please. > > Dave. > > Begin forwarded message: > > >> From: "Shanmugham, Saravanan" >> Date: June 14, 2005 10:06:50 PM EDT >> To: "David R. Oran" , "Eric Burger" >> , "Dan Burnett"=20 >> Subject: RE: Query on hotword mode >> >> >> This is what was intended. But I agree that your suggestion is=20 >> easier on the client and more appropriate on the for hotwords. >> I remember proposing this during the MRCPv1 extensions=20 for this, but=20 >> dropped out of the discussion. >> >> I think you should propose it to the wider audience. >> >> If you forward this thread to the alias, I can send a=20 proposal for=20 >> change in text in the response and seee if anyone has=20 an issue with=20 >> this. >> >> >> Sarvi >> >> -----Original Message----- >> From: David R. Oran [mailto:oran@cisco.com] >> Sent: Tuesday, June 14, 2005 1:43 PM >> To: Shanmugham, Saravanan; Eric Burger; Dan Burnett >> Subject: Query on hotword mode >> >> The definition of hotword mode says: >> >> "Hotword mode is where the recognizer looks for a match >> against specific speech grammar or DTMF sequence and >> ignores speech or DTMF that does not match. It neither >> times out nor generates a no-match. >> The recognition completes only for a successful match of >> grammar or if the client cancels the request." >> >> It seems weird that you have to "re-prime" a hotword >> recognizer each time it detects a match, rather than let >> it continue recognizing and just generating >> Recognition-complete events until you tell it to stop by >> canceling the operation or issuing a new RECOGNIZE. >> >> Is this what was intended? >> >> >> > > _______________________________________________ > 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 Wed Jun 15 14:36:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dicl1-0000d8-Oo; Wed, 15 Jun 2005 14:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dicl1-0000d3-1T for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 14:36:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13176 for ; Wed, 15 Jun 2005 14:36:54 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Did7h-00021W-Tx for speechsc@ietf.org; Wed, 15 Jun 2005 15:00:26 -0400 X-SEF-Processed: 5_0_0_713__2005_06_15_13_35_35 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Wed, 15 Jun 2005 13:35:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 13:36:42 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524D2@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVxiWWYpkvgFljQTq6XShz4Llj6rwANxgzg From: "Wyss, Felix" To: "Dave Burke" , "Shanmugham, Saravanan" , "David R. Oran" X-Spam-Score: 2.0 (++) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 think that's a terrible abuse of the MIME types! The weight parameter controls the weight with which the grammar is considered in a particular recognition operation. That has *absolutely nothing* to do with the type of the grammar. Using a MIME-type parameter for this would be akin to controlling the text size of an HTML page through its MIME type. I personally don't really have a problem with using an inline "one-of" grammar. However, if that's considered too much hassle for the clients, what about introducing a content type text/grammar-refs for the RECOGNIZE command? Each line of the body would be a URI enclosed in angle brackets, followed by a colon and a list of parameters. For example:=20 =20 Channel-Identifier: 123456789012345@speechrecog=20 N-Best-List-Length: 3=20 Content-Type: text/grammar-refs=20 Content-Length: xxx =20 :weight=3D0.85 :weight=3D0.75 Felix > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On > Behalf Of Dave Burke > Sent: Wednesday, June 15, 2005 04:05 > To: Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type >=20 > I did some quick research into extending MIME headers and noted the > following: > - RFC2045 allows new Content-* extensions > - No IANA considerations apply > - Seems like new headers introduced in the past have had their own RFC > (e.g. RFC2912 and RFC3803). >=20 > We would be defining a new MIME header inside the MRCP specification... >=20 > A slicker approach could be to request to the author of the I-D that > defines > the application/srgs+xml media type > (http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes- > 02.txt) > to add an optional parameter called 'weight' so we could use something > like: >=20 > Content-Type: application/srgs+xml;weight=3D0.75 >=20 > The values could take on the VoiceXML definition, which I believe has the > right amount of generality. >=20 > I defer to more experienced IETFeers on whether either of these approaches > appear tenable. >=20 > Dave >=20 > ----- Original Message ----- > From: "Shanmugham, Saravanan" > To: "Dave Burke" ; "David R. Oran" > > Cc: ; "Bennett, Patrick" > Sent: Tuesday, June 14, 2005 8:24 PM > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type >=20 >=20 > I am fine with Option iii, but the we would be trying to extend MIME > headers which I am not sure if its extenisble or what the procedure to > define new MIME-headers are. Could find any good examples. >=20 > So I chose the next best thing which was to use a rule id > approach. >=20 > Sarvi >=20 > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke > Sent: Tuesday, June 14, 2005 9:41 AM > To: David R. Oran > Cc: Speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type >=20 > To be clear, I think there are two issues: > A. How to word the precedence when input matches more than > one active grammar? > B. How to specify a weight for a complete grammar? (see > http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 > 1023.html) >=20 > For A, how about appending the sentence in 1. and 2. so > that we get: >=20 > ...the order of inclusion controls the corresponding > precedence for the grammars during recognition should the > input match more than one active grammar. >=20 > For B, which point 3 addresses, there are three options discussed: > (i) Use the One-Of-Rule-Id-URI mechanism below > (ii) Add an informative note that a grammar can > be used to apply weights to grammars (One-Of-Rule-Id-URI > is unnecessary ) > (iii) Go with Jeff's idea of adding a new header to a MIME part > (http://www1.ietf.org/mail-archive/web/speechsc/current/msg > 01102.html) Small refinement though, the header should be > called Content-Grammar-Weight to fit RFC2045's extension mechanism >=20 > My preference is for (iii) over (ii) because if my MRCP > client runs VoiceXML then I'm going to have to handle > cases when has a weight attribute and build up a > grammar. This is just annoying complexity for the client. >=20 > Dave >=20 >=20 > ----- Original Message ----- > From: "David R. Oran" > To: "Dave Burke" > Cc: ; "Bennett, Patrick" > > Sent: Tuesday, June 14, 2005 5:02 PM > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > command andtest/uri-listcontent type >=20 >=20 > I agree with Dave, but I also believe the current text is > quite torturous and prone to misinterpretation. I had held > off screwing around with it because of my shaky > understanding of the "one-of-rule- id" stuff but now that > I think I can get it right I've taken a whack at it. >=20 > This is what the in-progress version of the spec says: >=20 > The RECOGNIZE request uses the message body to specify the > grammars applicable to the request. The active grammar(s) > for the request can be specified in one of 3 ways. >=20 > 1. The grammer may be placed directly in the message body > using MIME content. If more than one grammar is included > in the body, the order of inclusion controls the > corresponding precedence for the grammars during recognition. > 2. The body may contain a list of grammar URIs specified > in a mime- content of type text/uri-list. The order of the > URIs determines the corrensponding precedence for the > grammars during recognition. > 3. The active grammar among a set of grammars can > specified using a One-Of-Rule-Id-URI header in the > message. This header (see Section > 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific > rule-id contained in the grammar (or grammars) specified > in the body of the message. >=20 > Are further adjustments needed? >=20 >=20 > On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: >=20 > > The precedence is not related to weighting. The text > here covers the > > case if you had two grammars say gram1.grxml and > gram2.grxml both of > > which recognise the token "speech" but return a > different semantic > > interpretation. If gram2.grxml follows gram1.grxml in > the uri-list > > then it is gram1.grxml that is matched and it is gram1.grxml's > > semantic interpretation result that is returned in the NLSML. > > > > This is also required for VoiceXML 2.x behaviour (see http:// > > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > > > Dave > > ----- Original Message ----- > > From: Bennett, Patrick > > To: Speechsc@ietf.org > > Sent: Tuesday, June 14, 2005 4:09 PM > > Subject: [Speechsc] Problem with draft-6 RECOGNIZE > command and test/ > > uri-listcontent type > > > > According to the latest draft on page 89: > > > > > > ...The RECOGNIZE method MUST carry the grammars that need to > be > > > > activated for that RECOGNIZE method, in its message body. The > > > > grammars that need to be activated can be specified > in one of 3 > > > > ways. The grammar content could be specified as a > mime-content in > > > > the message body. It could be a simple list of grammar URIs > > > > specified in a mime-content of type text/uri-list, in > which case > > the > > > > order of the URI refer to the precedence order of the grammars > > > > during the recognize. ... > > > > > > The problem here is the statement "in which case the > order of the URI > > refer to the precedence order of the grammars during > the recognize." > > > > Well, what is the EXACT precedence? Shouldn't each of > the grammars > > be considered as equally weighted alternatives? > Ideally, all must be > > weighted equally unless a specific weight parameter was > specified > > with each URI. > > > > As currently specified, this part of the specification > is basically > > worthless. No MRCP client would ever send multiple URIs > to an MRCP > > server via a uri-list since the weighting applied to > each grammar is > > completely undefined. > > > > This really needs to be corrected. > > > > > > Patrick Bennett > > > > > > > > _______________________________________________ > > 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 > > >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 >=20 >=20 > _______________________________________________ > 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 Jun 15 14:49:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DicxW-0003Hu-TZ; Wed, 15 Jun 2005 14:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DicxW-0003Hp-24 for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 14:49:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14277 for ; Wed, 15 Jun 2005 14:49:52 -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 1DidKG-0002o0-9K for speechsc@ietf.org; Wed, 15 Jun 2005 15:13:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 11:49:45 -0700 X-IronPort-AV: i="3.93,201,1115017200"; d="scan'208"; a="279143260:sNHT67697046" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FInebw005815; Wed, 15 Jun 2005 11:49:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] new-audio-channel Date: Wed, 15 Jun 2005 11:49:40 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05BB95@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] new-audio-channel Thread-Index: AcVxvr0m9r7+Hf5fTwCAl8DgXLYBywAGVvrQ From: "Shanmugham, Saravanan" To: "David R. Oran" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Comments inline.=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of David R. Oran Sent: Wednesday, June 15, 2005 8:24 AM To: speechsc@ietf.org ((((E-mail)))) Subject: [Speechsc] new-audio-channel =20 Sorry to keep barraging the WG with these editing points -=20 I'm really getting close to the end of the chair review of=20 the spec. =20 This query concerns the "new-audio-channel" header on=20 RECOGNIZE requests. =20 1. Shouldn't this be called "audio-source-changed"? It=20 might not be strictly speaking "new". And it may not be=20 the channel that changed (e.g. My MRCPv2 client might be=20 on an IP phone and the user switches from speakerphone to headset). =20 2. Do we need to say anything about whether servers ought=20 to have separate resource state on one session from=20 different SSRCs of a single media session? The client may=20 not even know this is happening. =20 3. The current text says MUST in a few places that seem=20 restrictive and unenforceable: =20 "This header MAY be specified in a RECOGNIZE request and=20 allows the client to tell the server that, from this point=20 on, further input audio comes from a different audio=20 source, channel or speaker. If the recognition resource=20 had collected any input statistics or adaptation state, it=20 MUST discard the state and start fresh for this RECOGNIZE=20 request. Note that if there are multiple resources on the=20 same SIP dialog that may be collecting or using this data,=20 the client MUST declare a new audio channel for all these=20 resources. This helps in a numbe of use case, including=20 where the client wishes to reuse an open recognition=20 session with an existing media session for multiple=20 telephone calls." =20 The first MUST is too restrictive because some adaptations=20 may be independent of the source or channel. The first MUST is important for a functionaility standpoint i.e the server MUST recognize this is a new channel and and do what is necessary.=20 But I think what you are getting at is that its interpretation i.e. what a resource must do to get ready for this change in audio source should be left to the server implementation and technology behind the server. If that is correct, I am not sure=20 How to word this differently. How about, =20 "The recognition resource MUST do what is appropriate for the specific recognition technology, which includes but is not limited to discarding any collected input statistics or adaptation state before starting the RECOGNIZE request. =20 The second MUST is too restrictive because the client may=20 not even be aware of the change, and the server can't=20 depend on the client detection working deterministically. Here too the must is to cover cases where one audio pipe is shared between, say the recognition resource and a verification resource. They both may have a common front end or some common statistics that may be collecting. When a RECOGNIZE to recognition resource has this header it tells the system that the input source has changed, which means that noise and other statistics that were collected until that point are of no use anymore. That will automatically have to be the case for the verification resource as well even if the VERIFY command sometime later did not send a new-audio-channel header in it. Infact it shouldn't have to if the media channel is shared between the resources.=20 How about the following text instead of the current text with the MUST. "Note that if there are multiple resources that are sharing a media pipe and are collecting or using this data, and the client issues this header to one of the resources, the reset operation applies to all resources that use the shared media stream." Sarvi =20 I thinks both of these ought to be SHOULDs. =20 Dave. =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 Wed Jun 15 14:53:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Did18-0003se-TX; Wed, 15 Jun 2005 14:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Did17-0003sX-U1 for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 14:53:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14631 for ; Wed, 15 Jun 2005 14:53:36 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidNr-000388-Qk for speechsc@ietf.org; Wed, 15 Jun 2005 15:17:08 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 11:53:28 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FIrMlw003461; Wed, 15 Jun 2005 11:53:22 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 11:53:23 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C05BB99@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVxiWWYpkvgFljQTq6XShz4Llj6rwANxgzgAAatcaA= From: "Shanmugham, Saravanan" To: "Wyss, Felix" , "Dave Burke" , "David R. Oran" X-Spam-Score: 2.0 (++) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 am fine with the idea.=20 Would you be able to propose a content-type registration section for this content-type.=20 We could add it to the current list of registrations and retire the one-of header. Sarvi=20 -----Original Message----- From: Wyss, Felix [mailto:FelixW@inin.com]=20 Sent: Wednesday, June 15, 2005 11:37 AM To: Dave Burke; Shanmugham, Saravanan; David R. Oran Cc: speechsc@ietf.org; Bennett, Patrick Subject: RE: [Speechsc] Problem with draft-6=20 RECOGNIZEcommandandtest/uri-listcontent type =20 I think that's a terrible abuse of the MIME types! The=20 weight parameter controls the weight with which the=20 grammar is considered in a particular recognition=20 operation. That has *absolutely nothing* to do with the=20 type of the grammar. Using a MIME-type parameter for this=20 would be akin to controlling the text size of an HTML page=20 through its MIME type. =20 I personally don't really have a problem with using an=20 inline "one-of" grammar. However, if that's considered too much hassle=20 for the clients, what about introducing a content type=20 text/grammar-refs for the RECOGNIZE command? Each line of=20 the body would be a URI enclosed in angle brackets,=20 followed by a colon and a list of parameters. For example:=20 =20 Channel-Identifier: 123456789012345@speechrecog N-Best-List-Length: 3 Content-Type: text/grammar-refs Content-Length: xxx =20 :weight=3D0.85 :weight=3D0.75 =20 =20 Felix =20 > -----Original Message----- > From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On=20 > Behalf Of Dave Burke > Sent: Wednesday, June 15, 2005 04:05 > To: Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type >=20 > I did some quick research into extending MIME headers=20 and noted the > following: > - RFC2045 allows new Content-* extensions > - No IANA considerations apply > - Seems like new headers introduced in the past have=20 had their own RFC > (e.g. RFC2912 and RFC3803). >=20 > We would be defining a new MIME header inside the MRCP specification... >=20 > A slicker approach could be to request to the author of=20 the I-D that=20 > defines the application/srgs+xml media type > (http://www.ietf.org/internet-drafts/draft-froumentin-voice -mediatypes- > 02.txt) > to add an optional parameter called 'weight' so we could=20 use something > like: >=20 > Content-Type: application/srgs+xml;weight=3D0.75 >=20 > The values could take on the VoiceXML definition, which=20 I believe has the > right amount of generality. >=20 > I defer to more experienced IETFeers on whether either of these approaches > appear tenable. >=20 > Dave >=20 > ----- Original Message ----- > From: "Shanmugham, Saravanan" > To: "Dave Burke" ; "David R. Oran" > > Cc: ; "Bennett, Patrick"=20 > Sent: Tuesday, June 14, 2005 8:24 PM > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE=20 > commandandtest/uri-listcontent type >=20 >=20 > I am fine with Option iii, but the we would be trying to=20 extend MIME=20 > headers which I am not sure if its extenisble or what=20 the procedure to=20 > define new MIME-headers are. Could find any good examples. >=20 > So I chose the next best thing which was to use a=20 rule id=20 > approach. >=20 > Sarvi >=20 > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke > Sent: Tuesday, June 14, 2005 9:41 AM > To: David R. Oran > Cc: Speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type >=20 > To be clear, I think there are two issues: > A. How to word the precedence when input matches more than > one active grammar? > B. How to specify a weight for a complete grammar? (see > http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 > 1023.html) >=20 > For A, how about appending the sentence in 1. and 2. so > that we get: >=20 > ...the order of inclusion controls the corresponding > precedence for the grammars during recognition should the > input match more than one active grammar. >=20 > For B, which point 3 addresses, there are three options discussed: > (i) Use the One-Of-Rule-Id-URI mechanism below > (ii) Add an informative note that a grammar can > be used to apply weights to grammars (One-Of-Rule-Id-URI > is unnecessary ) > (iii) Go with Jeff's idea of adding a new header to=20 a MIME part > (http://www1.ietf.org/mail-archive/web/speechsc/current/msg > 01102.html) Small refinement though, the header should be > called Content-Grammar-Weight to fit RFC2045's extension mechanism >=20 > My preference is for (iii) over (ii) because if my MRCP > client runs VoiceXML then I'm going to have to handle > cases when has a weight attribute and build up a > grammar. This is just annoying complexity for the client. >=20 > Dave >=20 >=20 > ----- Original Message ----- > From: "David R. Oran" > To: "Dave Burke" > Cc: ; "Bennett, Patrick" > > Sent: Tuesday, June 14, 2005 5:02 PM > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > command andtest/uri-listcontent type >=20 >=20 > I agree with Dave, but I also believe the current text is > quite torturous and prone to misinterpretation. I had held > off screwing around with it because of my shaky > understanding of the "one-of-rule- id" stuff but now that > I think I can get it right I've taken a whack at it. >=20 > This is what the in-progress version of the spec says: >=20 > The RECOGNIZE request uses the message body to specify the > grammars applicable to the request. The active grammar(s) > for the request can be specified in one of 3 ways. >=20 > 1. The grammer may be placed directly in the message body > using MIME content. If more than one grammar is included > in the body, the order of inclusion controls the > corresponding precedence for the grammars during=20 recognition. > 2. The body may contain a list of grammar URIs specified > in a mime- content of type text/uri-list. The order of the > URIs determines the corrensponding precedence for the > grammars during recognition. > 3. The active grammar among a set of grammars can > specified using a One-Of-Rule-Id-URI header in the > message. This header (see Section > 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific > rule-id contained in the grammar (or grammars) specified > in the body of the message. >=20 > Are further adjustments needed? >=20 >=20 > On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: >=20 > > The precedence is not related to weighting. The text > here covers the > > case if you had two grammars say gram1.grxml and > gram2.grxml both of > > which recognise the token "speech" but return a > different semantic > > interpretation. If gram2.grxml follows gram1.grxml in > the uri-list > > then it is gram1.grxml that is matched and it is =20 gram1.grxml's > > semantic interpretation result that is returned=20 in the NLSML. > > > > This is also required for VoiceXML 2.x behaviour=20 (see http:// > > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > > > Dave > > ----- Original Message ----- > > From: Bennett, Patrick > > To: Speechsc@ietf.org > > Sent: Tuesday, June 14, 2005 4:09 PM > > Subject: [Speechsc] Problem with draft-6 RECOGNIZE > command and test/ > > uri-listcontent type > > > > According to the latest draft on page 89: > > > > > > ...The RECOGNIZE method MUST carry the=20 grammars that need to > be > > > > activated for that RECOGNIZE method, in its=20 message body. The > > > > grammars that need to be activated can be specified > in one of 3 > > > > ways. The grammar content could be specified as a > mime-content in > > > > the message body. It could be a simple list of=20 grammar URIs > > > > specified in a mime-content of type text/uri-list, in > which case > > the > > > > order of the URI refer to the precedence order of the grammars > > > > during the recognize. ... > > > > > > The problem here is the statement "in which case the > order of the URI > > refer to the precedence order of the grammars during > the recognize." > > > > Well, what is the EXACT precedence? Shouldn't each of > the grammars > > be considered as equally weighted alternatives? > Ideally, all must be > > weighted equally unless a specific weight parameter was > specified > > with each URI. > > > > As currently specified, this part of the specification > is basically > > worthless. No MRCP client would ever send multiple URIs > to an MRCP > > server via a uri-list since the weighting applied to > each grammar is > > completely undefined. > > > > This really needs to be corrected. > > > > > > Patrick Bennett > > > > > > > > _______________________________________________ > > 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 > > >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 >=20 >=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 Wed Jun 15 15:20:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidQl-000213-Fr; Wed, 15 Jun 2005 15:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidQk-00020y-Tg for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 15:20:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18487 for ; Wed, 15 Jun 2005 15:20:05 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidnU-0004tE-9i for Speechsc@ietf.org; Wed, 15 Jun 2005 15:43:37 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id A29A8350A for ; Wed, 15 Jun 2005 12:19:42 -0700 (PDT) Received: from [172.20.51.121] (dhcp172-51-121.corp.tellme.com [172.20.51.121]) by mail02.corp.tellme.com (Postfix) with ESMTP id 790F43507 for ; Wed, 15 Jun 2005 12:19:42 -0700 (PDT) Message-ID: <42B07F4E.40404@tellme.com> Date: Wed, 15 Jun 2005 12:19:42 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Speechsc@ietf.org Subject: Re: [Speechsc] Server capabilities References: <4F4AB041-9E7B-4EAD-A0DE-A43F108C7AFB@cisco.com> In-Reply-To: <4F4AB041-9E7B-4EAD-A0DE-A43F108C7AFB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I'm very much in favor of b). In the "managing big grammars" thread we were considering about permitting URIs to reference binary grammars as well as source grammars (was that ever codified?). How about having some way for the server to indicate what vendor/version it is. For heterogenous MRCP server environments, this would allow clients to give the right grammar binary URIs to the right servers. Corby Anderson Tellme Networks, Inc. David R. Oran wrote: > This message was prompted by one aspect of the discussion on the list > about large grammars, which is how a client can figure out in advance > just what a server can and can't do, so it isn't "unpleasantly > surprised" at the instant it issues a method. > > The current specification walks a fine line between giving > flexibility to server implementers and giving clients a sufficient > degree of control over server behavior. For example we have things > like multiple jump-length units which a server may or may not > support, server-specific default values for confidence-threshold and > speed-vs-accuracy, and a bunch of others. > > There is some for this support, including: > 1) through SDP and SIP OPTIONS the client can discover what resources > the server supports and what media formats it can process. > 2) through GET-PARAMS on a particular session with a resource the > client can discover any implementation-specific server default values > for MRCPv2 protocol headers. > > My question to the WG is what, if anything do we need beyond these? > > Here's a small list of candidates. Feel free to comment and/or > propose your own: > > a) we may want/need a way for the server to determine what audio > formats a client supports for the purposes of returning captured > audio. Right now we don't even have a way for the client to tell the > server what format it wants audio returned in, so we at least have to > remedy that omission. > > b) we may want a way for a client to learn the current list of > "instantly available" grammars the server has handy and which are in > some way "guaranteed" to persist for a while. > > c) we may want a form of GET-PARAMS which fetches session-independent > server information. One way to do this is to define a MRCPv2-frag > content type (like we have with sipfrag). That way a SIP OPTIONs to > an MRCPv2 server can return an MRCP-specific body with all that > interesting information about server capabilities. > > > I don't want this to necessary turn into a free-for-all, because we > really do want to reach closure on the spec and get it to last call. > My target for finishing my chair review and editing is the end of > this week. > > > _______________________________________________ > 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 Jun 15 15:34:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Didf5-0004MD-PV; Wed, 15 Jun 2005 15:34:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Didf0-0004M7-5Y for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 15:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19906 for ; Wed, 15 Jun 2005 15:34:48 -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 1Die1k-0005og-Ac for speechsc@ietf.org; Wed, 15 Jun 2005 15:58:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 12:34:40 -0700 X-IronPort-AV: i="3.93,201,1115017200"; d="scan'208"; a="279164316:sNHT35468428" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5FJYblq019371; Wed, 15 Jun 2005 12:34:38 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FJMC6T023129; Wed, 15 Jun 2005 12:22:13 -0700 In-Reply-To: <03772D1EC8DE624A863058C75874A75C05BB99@vtg-um-e2k6.sj21ad.cisco.com> References: <03772D1EC8DE624A863058C75874A75C05BB99@vtg-um-e2k6.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 15:34:33 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118863334.394355"; x:"432200"; a:"rsa-sha1"; b:"nofws:8627"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"OKYT1KwvrcLB3igTTxyCYNgUP/uL6K98f2v3ft9JtrY/nvYzTEA42zGDJSFPXE2vCtcxHmDs" "TV+oj/dobLNhHhFm7d6ZQ/w2zbWATNfptEc48Eq9M12iHIBcd3vGSui161HlJCuZDWhseBR+rGQ" "OSFOkdg9hrsint6m31AWSawI="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest" "/uri-listcontent type"; c:"Date: Wed, 15 Jun 2005 15:34:33 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Wyss, Felix" , "Bennett, Patrick" , Dave Burke 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'm cool with this too. Let's give a bit more time to see if anyone violently objects. Don't wait to supply text though! On Jun 15, 2005, at 2:53 PM, Shanmugham, Saravanan wrote: > I am fine with the idea. > Would you be able to propose a content-type registration section for > this content-type. > We could add it to the current list of registrations and retire the > one-of header. > > Sarvi > > -----Original Message----- > From: Wyss, Felix [mailto:FelixW@inin.com] > Sent: Wednesday, June 15, 2005 11:37 AM > To: Dave Burke; Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 > RECOGNIZEcommandandtest/uri-listcontent type > > I think that's a terrible abuse of the MIME types! The > weight parameter controls the weight with which the > grammar is considered in a particular recognition > operation. That has *absolutely nothing* to do with the > type of the grammar. Using a MIME-type parameter for this > would be akin to controlling the text size of an HTML page > through its MIME type. > > I personally don't really have a problem with using an > inline "one-of" > grammar. However, if that's considered too much hassle > for the clients, what about introducing a content type > text/grammar-refs for the RECOGNIZE command? Each line of > the body would be a URI enclosed in angle brackets, > followed by a colon and a list of parameters. For > example: > > Channel-Identifier: 123456789012345@speechrecog > N-Best-List-Length: 3 > Content-Type: text/grammar-refs > Content-Length: xxx > > > :weight=0.85 > :weight=0.75 > > > Felix > > >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> > [mailto:speechsc-bounces@ietf.org] On > >> Behalf Of Dave Burke >> Sent: Wednesday, June 15, 2005 04:05 >> To: Shanmugham, Saravanan; David R. Oran >> Cc: speechsc@ietf.org; Bennett, Patrick >> Subject: Re: [Speechsc] Problem with draft-6 >> > RECOGNIZEcommandandtest/uri- > >> listcontent type >> >> I did some quick research into extending MIME headers >> > and noted the > >> following: >> - RFC2045 allows new Content-* extensions >> - No IANA considerations apply >> - Seems like new headers introduced in the past have >> > had their own > RFC > >> (e.g. RFC2912 and RFC3803). >> >> We would be defining a new MIME header inside the MRCP >> > specification... > >> >> A slicker approach could be to request to the author of >> > the I-D that > >> defines the application/srgs+xml media type >> >> > (http://www.ietf.org/internet-drafts/draft-froumentin-voice > -mediatypes- > >> 02.txt) >> to add an optional parameter called 'weight' so we could >> > use something > >> like: >> >> Content-Type: application/srgs+xml;weight=0.75 >> >> The values could take on the VoiceXML definition, which >> > I believe has > the > >> right amount of generality. >> >> I defer to more experienced IETFeers on whether either of these >> > approaches > >> appear tenable. >> >> Dave >> >> ----- Original Message ----- >> From: "Shanmugham, Saravanan" >> To: "Dave Burke" ; "David R. Oran" >> >> Cc: ; "Bennett, Patrick" >> > > >> Sent: Tuesday, June 14, 2005 8:24 PM >> Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE >> commandandtest/uri-listcontent type >> >> >> I am fine with Option iii, but the we would be trying to >> > extend MIME > >> headers which I am not sure if its extenisble or what >> > the procedure to > >> define new MIME-headers are. Could find any good examples. >> >> So I chose the next best thing which was to use a >> > rule id > >> approach. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke >> Sent: Tuesday, June 14, 2005 9:41 AM >> To: David R. Oran >> Cc: Speechsc@ietf.org; Bennett, Patrick >> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE >> commandandtest/uri-listcontent type >> >> To be clear, I think there are two issues: >> A. How to word the precedence when input matches more than >> one active grammar? >> B. How to specify a weight for a complete grammar? (see >> http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 >> 1023.html) >> >> For A, how about appending the sentence in 1. and 2. so >> that we get: >> >> ...the order of inclusion controls the corresponding >> precedence for the grammars during recognition should the >> input match more than one active grammar. >> >> For B, which point 3 addresses, there are three options >> > discussed: > >> (i) Use the One-Of-Rule-Id-URI mechanism below >> (ii) Add an informative note that a grammar can >> be used to apply weights to grammars (One-Of-Rule-Id-URI >> is unnecessary ) >> (iii) Go with Jeff's idea of adding a new header to >> > a MIME part > >> (http://www1.ietf.org/mail-archive/web/speechsc/current/msg >> 01102.html) Small refinement though, the header should be >> called Content-Grammar-Weight to fit RFC2045's extension >> > mechanism > >> >> My preference is for (iii) over (ii) because if my MRCP >> client runs VoiceXML then I'm going to have to handle >> cases when has a weight attribute and build up a >> grammar. This is just annoying complexity for the >> > client. > >> >> Dave >> >> >> ----- Original Message ----- >> From: "David R. Oran" >> To: "Dave Burke" >> Cc: ; "Bennett, Patrick" >> >> Sent: Tuesday, June 14, 2005 5:02 PM >> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE >> command andtest/uri-listcontent type >> >> >> I agree with Dave, but I also believe the current text is >> quite torturous and prone to misinterpretation. I had held >> off screwing around with it because of my shaky >> understanding of the "one-of-rule- id" stuff but now that >> I think I can get it right I've taken a whack at it. >> >> This is what the in-progress version of the spec says: >> >> The RECOGNIZE request uses the message body to specify the >> grammars applicable to the request. The active grammar(s) >> for the request can be specified in one of 3 ways. >> >> 1. The grammer may be placed directly in the message body >> using MIME content. If more than one grammar is included >> in the body, the order of inclusion controls the >> corresponding precedence for the grammars during >> > recognition. > >> 2. The body may contain a list of grammar URIs specified >> in a mime- content of type text/uri-list. The order of the >> URIs determines the corrensponding precedence for the >> grammars during recognition. >> 3. The active grammar among a set of grammars can >> specified using a One-Of-Rule-Id-URI header in the >> message. This header (see Section >> 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific >> rule-id contained in the grammar (or grammars) specified >> in the body of the message. >> >> Are further adjustments needed? >> >> >> On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: >> >> >>> The precedence is not related to weighting. The text >>> >> here covers the >> >>> case if you had two grammars say gram1.grxml and >>> >> gram2.grxml both of >> >>> which recognise the token "speech" but return a >>> >> different semantic >> >>> interpretation. If gram2.grxml follows gram1.grxml in >>> >> the uri-list >> >>> then it is gram1.grxml that is matched and it is >>> > gram1.grxml's > >>> semantic interpretation result that is returned >>> > in the NLSML. > >>> >>> This is also required for VoiceXML 2.x behaviour >>> > (see http:// > >>> www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). >>> >>> Dave >>> ----- Original Message ----- >>> From: Bennett, Patrick >>> To: Speechsc@ietf.org >>> Sent: Tuesday, June 14, 2005 4:09 PM >>> Subject: [Speechsc] Problem with draft-6 RECOGNIZE >>> >> command and test/ >> >>> uri-listcontent type >>> >>> According to the latest draft on page 89: >>> >>> >>> ...The RECOGNIZE method MUST carry the >>> > grammars that need to > >> be >> >>> >>> activated for that RECOGNIZE method, in its >>> > message body. > The > >>> >>> grammars that need to be activated can be specified >>> >> in one of 3 >> >>> >>> ways. The grammar content could be specified as a >>> >> mime-content in >> >>> >>> the message body. It could be a simple list of >>> > grammar URIs > >>> >>> specified in a mime-content of type text/uri-list, in >>> >> which case >> >>> the >>> >>> order of the URI refer to the precedence order of the >>> > grammars > >>> >>> during the recognize. ... >>> >>> >>> The problem here is the statement "in which case the >>> >> order of the URI >> >>> refer to the precedence order of the grammars during >>> >> the recognize." >> >>> >>> Well, what is the EXACT precedence? Shouldn't each of >>> >> the grammars >> >>> be considered as equally weighted alternatives? >>> >> Ideally, all must be >> >>> weighted equally unless a specific weight parameter was >>> >> specified >> >>> with each URI. >>> >>> As currently specified, this part of the specification >>> >> is basically >> >>> worthless. No MRCP client would ever send multiple URIs >>> >> to an MRCP >> >>> server via a uri-list since the weighting applied to >>> >> each grammar is >> >>> completely undefined. >>> >>> This really needs to be corrected. >>> >>> >>> Patrick Bennett >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 Jun 15 15:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Didnm-0006uE-Ka; Wed, 15 Jun 2005 15:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Didnl-0006u8-GJ for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 15:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20557 for ; Wed, 15 Jun 2005 15:43:51 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DieAU-0006SV-8G for speechsc@ietf.org; Wed, 15 Jun 2005 16:07:24 -0400 X-SEF-Processed: 5_0_0_713__2005_06_15_14_42_30 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Wed, 15 Jun 2005 14:42:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 14:43:42 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524D5@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVxiWWYpkvgFljQTq6XShz4Llj6rwANxgzgAAatcaAAAcCn0A== From: "Wyss, Felix" To: "Shanmugham, Saravanan" , "Dave Burke" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 give it a try. By when do you need it? Felix > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, June 15, 2005 13:53 > To: Wyss, Felix; Dave Burke; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type >=20 > I am fine with the idea. > Would you be able to propose a content-type registration section for > this content-type. > We could add it to the current list of registrations and retire the > one-of header. >=20 > Sarvi >=20 > -----Original Message----- > From: Wyss, Felix [mailto:FelixW@inin.com] > Sent: Wednesday, June 15, 2005 11:37 AM > To: Dave Burke; Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 > RECOGNIZEcommandandtest/uri-listcontent type >=20 > I think that's a terrible abuse of the MIME types! The > weight parameter controls the weight with which the > grammar is considered in a particular recognition > operation. That has *absolutely nothing* to do with the > type of the grammar. Using a MIME-type parameter for this > would be akin to controlling the text size of an HTML page > through its MIME type. >=20 > I personally don't really have a problem with using an > inline "one-of" > grammar. However, if that's considered too much hassle > for the clients, what about introducing a content type > text/grammar-refs for the RECOGNIZE command? Each line of > the body would be a URI enclosed in angle brackets, > followed by a colon and a list of parameters. For > example: >=20 > Channel-Identifier: 123456789012345@speechrecog > N-Best-List-Length: 3 > Content-Type: text/grammar-refs > Content-Length: xxx >=20 > > :weight=3D0.85 > :weight=3D0.75 >=20 >=20 > Felix >=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 15:49:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidtR-0007Ds-Hu; Wed, 15 Jun 2005 15:49:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidtO-0007Dk-Uh for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 15:49:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20870 for ; Wed, 15 Jun 2005 15:49:41 -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 1DieG9-0006lp-NP for speechsc@ietf.org; Wed, 15 Jun 2005 16:13:14 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2005 12:49:32 -0700 X-IronPort-AV: i="3.93,201,1115017200"; d="scan'208"; a="279171394:sNHT1575301664" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FJnSlw011875; Wed, 15 Jun 2005 12:49:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Server capabilities Date: Wed, 15 Jun 2005 12:49:25 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C0ACCB3@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Server capabilities Thread-Index: AcVx39fxai1AEoKoQPGwvIUpcV87iQAAwfgg From: "Shanmugham, Saravanan" To: "Corby Anderson" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable 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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This comment is only relating to your suggestion to use option b to address resolving binary grammar uri. I think the right way to do this would be to define a file format for this binary across vendors and use it. This wouldn't have to be very complex, at a minimum agree on standard header for the beginning of this file that identifies vendor and format version number and the rest of the binary file could be vendor specific.=20 No need to address this through the MRCP specification. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Corby Anderson Sent: Wednesday, June 15, 2005 12:20 PM To: Speechsc@ietf.org Subject: Re: [Speechsc] Server capabilities =20 I'm very much in favor of b). =20 In the "managing big grammars" thread we were considering=20 about permitting URIs to reference binary grammars as well=20 as source grammars (was that ever codified?). How about=20 having some way for the server to indicate what=20 vendor/version it is. For heterogenous MRCP server=20 environments, this would allow clients to give the right=20 grammar binary URIs to the right servers. =20 Corby Anderson Tellme Networks, Inc. =20 David R. Oran wrote: =20 > This message was prompted by one aspect of the=20 discussion on the list=20 > about large grammars, which is how a client can figure=20 out in advance=20 > just what a server can and can't do, so it isn't "unpleasantly=20 > surprised" at the instant it issues a method. > > The current specification walks a fine line between=20 giving flexibility=20 > to server implementers and giving clients a sufficient degree of=20 > control over server behavior. For example we have things=20 like multiple=20 > jump-length units which a server may or may not support,=20 > server-specific default values for confidence-threshold and=20 > speed-vs-accuracy, and a bunch of others. > > There is some for this support, including: > 1) through SDP and SIP OPTIONS the client can discover=20 what resources=20 > the server supports and what media formats it can process. > 2) through GET-PARAMS on a particular session with a=20 resource the=20 > client can discover any implementation-specific server=20 default values=20 > for MRCPv2 protocol headers. > > My question to the WG is what, if anything do we need=20 beyond these? > > Here's a small list of candidates. Feel free to comment=20 and/or propose=20 > your own: > > a) we may want/need a way for the server to determine what audio=20 > formats a client supports for the purposes of returning captured=20 > audio. Right now we don't even have a way for the client=20 to tell the=20 > server what format it wants audio returned in, so we at=20 least have to=20 > remedy that omission. > > b) we may want a way for a client to learn the current list of=20 > "instantly available" grammars the server has handy and=20 which are in=20 > some way "guaranteed" to persist for a while. > > c) we may want a form of GET-PARAMS which fetches=20 session-independent=20 > server information. One way to do this is to define a=20 MRCPv2-frag=20 > content type (like we have with sipfrag). That way a SIP=20 OPTIONs to an=20 > MRCPv2 server can return an MRCP-specific body with all that=20 > interesting information about server capabilities. > > > I don't want this to necessary turn into a free-for-all,=20 because we=20 > really do want to reach closure on the spec and get it=20 to last call. > My target for finishing my chair review and editing is=20 the end of this=20 > week. > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc =20 =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 Wed Jun 15 15:51:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diduv-0007Wi-1p; Wed, 15 Jun 2005 15:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diduu-0007Wd-3I for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 15:51:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20965 for ; Wed, 15 Jun 2005 15:51:14 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DieHd-0006uS-U7 for speechsc@ietf.org; Wed, 15 Jun 2005 16:14:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2005 12:51:06 -0700 X-IronPort-AV: i="3.93,201,1115017200"; d="scan'208"; a="643838711:sNHT29872908" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FJp2bw022386; Wed, 15 Jun 2005 12:51:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 12:51:01 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C0ACCB6@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVxiWWYpkvgFljQTq6XShz4Llj6rwANxgzgAAatcaAAAcCn0AAATgVQ From: "Shanmugham, Saravanan" To: "Wyss, Felix" , "Dave Burke" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 We are trying to get the spec into last call quickly. So in the next week or 2 would be nice. Sarvi=20 -----Original Message----- From: Wyss, Felix [mailto:FelixW@inin.com]=20 Sent: Wednesday, June 15, 2005 12:44 PM To: Shanmugham, Saravanan; Dave Burke; David R. Oran Cc: speechsc@ietf.org; Bennett, Patrick Subject: RE: [Speechsc] Problem with draft-6=20 RECOGNIZEcommandandtest/uri-listcontent type =20 I'll give it a try. By when do you need it? =20 Felix =20 > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, June 15, 2005 13:53 > To: Wyss, Felix; Dave Burke; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type >=20 > I am fine with the idea. > Would you be able to propose a content-type registration=20 section for=20 > this content-type. > We could add it to the current list of registrations and=20 retire the=20 > one-of header. >=20 > Sarvi >=20 > -----Original Message----- > From: Wyss, Felix [mailto:FelixW@inin.com] > Sent: Wednesday, June 15, 2005 11:37 AM > To: Dave Burke; Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 > RECOGNIZEcommandandtest/uri-listcontent type >=20 > I think that's a terrible abuse of the MIME types! The > weight parameter controls the weight with which the > grammar is considered in a particular recognition > operation. That has *absolutely nothing* to do with the > type of the grammar. Using a MIME-type parameter for this > would be akin to controlling the text size of an HTML page > through its MIME type. >=20 > I personally don't really have a problem with using an > inline "one-of" > grammar. However, if that's considered too much hassle > for the clients, what about introducing a content type > text/grammar-refs for the RECOGNIZE command? Each line of > the body would be a URI enclosed in angle brackets, > followed by a colon and a list of parameters. For > example: >=20 > Channel-Identifier: 123456789012345@speechrecog > N-Best-List-Length: 3 > Content-Type: text/grammar-refs > Content-Length: xxx >=20 > > :weight=3D0.85 > :weight=3D0.75 >=20 >=20 > Felix >=20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 16:36:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiecF-0006kD-Fi; Wed, 15 Jun 2005 16:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiecE-0006jd-07 for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 16:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00534 for ; Wed, 15 Jun 2005 16:35:56 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dieyn-0003Hp-II for speechsc@ietf.org; Wed, 15 Jun 2005 16:59:30 -0400 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 73901214042; Wed, 15 Jun 2005 20:34:44 +0000 (GMT) Message-ID: <00b501c571e9$b7208e90$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Wyss, Felix" , "Shanmugham, Saravanan" , "David R. Oran" References: <8F9F1C6AA1D6834EACC379C8821533A6011524D2@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Wed, 15 Jun 2005 21:34:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Bennett, Patrick" 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 Sounds good. Dave ----- Original Message ----- From: "Wyss, Felix" To: "Dave Burke" ; "Shanmugham, Saravanan" ; "David R. Oran" Cc: ; "Bennett, Patrick" Sent: Wednesday, June 15, 2005 7:36 PM Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type I think that's a terrible abuse of the MIME types! The weight parameter controls the weight with which the grammar is considered in a particular recognition operation. That has *absolutely nothing* to do with the type of the grammar. Using a MIME-type parameter for this would be akin to controlling the text size of an HTML page through its MIME type. I personally don't really have a problem with using an inline "one-of" grammar. However, if that's considered too much hassle for the clients, what about introducing a content type text/grammar-refs for the RECOGNIZE command? Each line of the body would be a URI enclosed in angle brackets, followed by a colon and a list of parameters. For example: Channel-Identifier: 123456789012345@speechrecog N-Best-List-Length: 3 Content-Type: text/grammar-refs Content-Length: xxx :weight=0.85 :weight=0.75 Felix > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On > Behalf Of Dave Burke > Sent: Wednesday, June 15, 2005 04:05 > To: Shanmugham, Saravanan; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type > > I did some quick research into extending MIME headers and noted the > following: > - RFC2045 allows new Content-* extensions > - No IANA considerations apply > - Seems like new headers introduced in the past have had their own RFC > (e.g. RFC2912 and RFC3803). > > We would be defining a new MIME header inside the MRCP specification... > > A slicker approach could be to request to the author of the I-D that > defines > the application/srgs+xml media type > (http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes- > 02.txt) > to add an optional parameter called 'weight' so we could use something > like: > > Content-Type: application/srgs+xml;weight=0.75 > > The values could take on the VoiceXML definition, which I believe has the > right amount of generality. > > I defer to more experienced IETFeers on whether either of these approaches > appear tenable. > > Dave > > ----- Original Message ----- > From: "Shanmugham, Saravanan" > To: "Dave Burke" ; "David R. Oran" > > Cc: ; "Bennett, Patrick" > Sent: Tuesday, June 14, 2005 8:24 PM > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type > > > I am fine with Option iii, but the we would be trying to extend MIME > headers which I am not sure if its extenisble or what the procedure to > define new MIME-headers are. Could find any good examples. > > So I chose the next best thing which was to use a rule id > approach. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke > Sent: Tuesday, June 14, 2005 9:41 AM > To: David R. Oran > Cc: Speechsc@ietf.org; Bennett, Patrick > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > commandandtest/uri-listcontent type > > To be clear, I think there are two issues: > A. How to word the precedence when input matches more than > one active grammar? > B. How to specify a weight for a complete grammar? (see > http://www1.ietf.org/mail-archive/web/speechsc/current/msg0 > 1023.html) > > For A, how about appending the sentence in 1. and 2. so > that we get: > > ...the order of inclusion controls the corresponding > precedence for the grammars during recognition should the > input match more than one active grammar. > > For B, which point 3 addresses, there are three options discussed: > (i) Use the One-Of-Rule-Id-URI mechanism below > (ii) Add an informative note that a grammar can > be used to apply weights to grammars (One-Of-Rule-Id-URI > is unnecessary ) > (iii) Go with Jeff's idea of adding a new header to a MIME part > (http://www1.ietf.org/mail-archive/web/speechsc/current/msg > 01102.html) Small refinement though, the header should be > called Content-Grammar-Weight to fit RFC2045's extension mechanism > > My preference is for (iii) over (ii) because if my MRCP > client runs VoiceXML then I'm going to have to handle > cases when has a weight attribute and build up a > grammar. This is just annoying complexity for the client. > > Dave > > > ----- Original Message ----- > From: "David R. Oran" > To: "Dave Burke" > Cc: ; "Bennett, Patrick" > > Sent: Tuesday, June 14, 2005 5:02 PM > Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZE > command andtest/uri-listcontent type > > > I agree with Dave, but I also believe the current text is > quite torturous and prone to misinterpretation. I had held > off screwing around with it because of my shaky > understanding of the "one-of-rule- id" stuff but now that > I think I can get it right I've taken a whack at it. > > This is what the in-progress version of the spec says: > > The RECOGNIZE request uses the message body to specify the > grammars applicable to the request. The active grammar(s) > for the request can be specified in one of 3 ways. > > 1. The grammer may be placed directly in the message body > using MIME content. If more than one grammar is included > in the body, the order of inclusion controls the > corresponding precedence for the grammars during recognition. > 2. The body may contain a list of grammar URIs specified > in a mime- content of type text/uri-list. The order of the > URIs determines the corrensponding precedence for the > grammars during recognition. > 3. The active grammar among a set of grammars can > specified using a One-Of-Rule-Id-URI header in the > message. This header (see Section > 9.4.24 (One-Of-Rule-Id-URI)) refers to a specific > rule-id contained in the grammar (or grammars) specified > in the body of the message. > > Are further adjustments needed? > > > On Jun 14, 2005, at 11:25 AM, Dave Burke wrote: > > > The precedence is not related to weighting. The text > here covers the > > case if you had two grammars say gram1.grxml and > gram2.grxml both of > > which recognise the token "speech" but return a > different semantic > > interpretation. If gram2.grxml follows gram1.grxml in > the uri-list > > then it is gram1.grxml that is matched and it is gram1.grxml's > > semantic interpretation result that is returned in the NLSML. > > > > This is also required for VoiceXML 2.x behaviour (see http:// > > www.w3.org/TR/2004/REC-voicexml20-20040316/#dml3.1.4). > > > > Dave > > ----- Original Message ----- > > From: Bennett, Patrick > > To: Speechsc@ietf.org > > Sent: Tuesday, June 14, 2005 4:09 PM > > Subject: [Speechsc] Problem with draft-6 RECOGNIZE > command and test/ > > uri-listcontent type > > > > According to the latest draft on page 89: > > > > > > ...The RECOGNIZE method MUST carry the grammars that need to > be > > > > activated for that RECOGNIZE method, in its message body. The > > > > grammars that need to be activated can be specified > in one of 3 > > > > ways. The grammar content could be specified as a > mime-content in > > > > the message body. It could be a simple list of grammar URIs > > > > specified in a mime-content of type text/uri-list, in > which case > > the > > > > order of the URI refer to the precedence order of the grammars > > > > during the recognize. ... > > > > > > The problem here is the statement "in which case the > order of the URI > > refer to the precedence order of the grammars during > the recognize." > > > > Well, what is the EXACT precedence? Shouldn't each of > the grammars > > be considered as equally weighted alternatives? > Ideally, all must be > > weighted equally unless a specific weight parameter was > specified > > with each URI. > > > > As currently specified, this part of the specification > is basically > > worthless. No MRCP client would ever send multiple URIs > to an MRCP > > server via a uri-list since the weighting applied to > each grammar is > > completely undefined. > > > > This really needs to be corrected. > > > > > > Patrick Bennett > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 Jun 15 16:54:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dieu6-0004KT-0H; Wed, 15 Jun 2005 16:54:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dieu0-0004Gj-Li for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 16:54:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05855 for ; Wed, 15 Jun 2005 16:54:22 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DifGg-0005ox-7U for speechsc@ietf.org; Wed, 15 Jun 2005 17:17:56 -0400 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 4DDB1214042; Wed, 15 Jun 2005 20:53:40 +0000 (GMT) Message-ID: <00de01c571ec$5d965140$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Wyss, Felix" , "Bennett, Patrick" , "David R. Oran" References: <8F9F1C6AA1D6834EACC379C8821533A6011524D1@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Managing big grammars Date: Wed, 15 Jun 2005 21:53:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , "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 Inline. Dave ----- Original Message ----- From: "Wyss, Felix" To: "Dave Burke" ; "Bennett, Patrick" ; "David R. Oran" Cc: "Reifenrath, Klaus" ; ; "Shanmugham, Saravanan" Sent: Wednesday, June 15, 2005 3:09 PM Subject: RE: [Speechsc] Managing big grammars > 1. If the MRCP server temporarily uses stale content in an effort to avoid > latency then it is reasonable that the DEFINE-GRAMMAR/RECOGNISE complete > response/event includes a warning. RFC2616 would suggest we return > something > like: > > Warning: 110 10.0.0.1 Response is stale [Felix I. Wyss] I'm fine with that > 2. Allowing DEFINE-GRAMMAR or RECOGNIZE to prefer reduced latency over > accuracy seems fine. I'd posit that the default action is to prefer > reduced > latency. To enforce accuracy (e.g. as one might want during development > and > testing of an application), a Cache-Control: max-stale=0 could be used. I > can't convince myself that we need an option to fail if a resource is not > in the cache. [Felix I. Wyss] Using max-stale=0 on the DEFINE-GRAMMAR request seems reasonable to me. Without an the ability to have DEFINE-GRAMMAR fail immediately if an item is not in the cache (i.e. probing the cache), clients will have to use timeouts in their MRCP stack if they want to enforce an upper bound on grammar registration latency and provide automatic fallback. It just seems it'd be really easy for the server to provide this information. [Dave B] . If you invoke DEFINE-GRAMMAR with some kind of header to indicate fail if the object is not in the cache, is the MRCP server to go fetch it anyway for future use? Should this mechanism fail if the grammar is an intermediate cache somewhere between the MRCP server and HTTP origin server? > > 3. Disallowing a grammar in an MRCP session to change outside of that > session's invocation DEFINE-GRAMMAR or RECOGNIZE (due to a revalidation in > a different MRCP session) seems perfectly reasonable. [Felix I. Wyss] It's a MUST then, right? [Dave B] I agree that the spec MUST not allow weird things to happen! > > 4. Given that latencies are much more detrimental to VUIs than GUIs, it > seems reasonable to make caching a SHOULD. Fancy optimisations such as a > centralised cache and informing other servers in a cluster to reload seem > like they ought to remain MAYs. Going for SHOULD over MUST seems > reasonable > to me to allow dtmfrecog and low-end speechrecogs. Ref. David's comment > about protocol engineering encroaching on system engineering. [Felix I. Wyss] I can live with that. I recommend that there be a discussion on grammar registration latency and caching strategies in the specification to ensure implementers (both servers and clients) are aware of the issues. Felix _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 15 17:29:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifSP-0004cX-9z; Wed, 15 Jun 2005 17:29:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifSN-0004cS-Dq for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 17:29:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08016 for ; Wed, 15 Jun 2005 17:29:53 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Difp6-0007q4-Ua for speechsc@ietf.org; Wed, 15 Jun 2005 17:53:27 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2005 14:29:43 -0700 X-IronPort-AV: i="3.93,201,1115017200"; d="scan'208"; a="643873539:sNHT28073192" 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 j5FLTfbw005755 for ; Wed, 15 Jun 2005 14:29:41 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FLHGTq024125 for ; Wed, 15 Jun 2005 14:17:17 -0700 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <784E6B6E-B696-4ADF-8F70-8D55F610BBB6@cisco.com> References: <784E6B6E-B696-4ADF-8F70-8D55F610BBB6@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Security-level header in speaker verification methods Date: Wed, 15 Jun 2005 17:29:39 -0400 To: "speechsc@ietf.org ((((E-mail))))" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118870237.751809"; x:"432200"; a:"rsa-sha1"; b:"nofws:1411"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ULBJG9K2vXr3S/Hzd4NkgBq48M7jdjFuKyLUKqSTdKobgn8JCYaWCpmHMpPX1/rtiW+3w18z" "3rbjNeqMDwWx9xRsti4K8RGjG9y4RcNMEpf/JKL85ayXspQSZtVk/ZXwiaNk89bb+oPRu2dADn9" "30ASX1cfRuYGxCsqAZalm8KE="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Security-level header in speaker verificatio" "n methods"; c:"Date: Wed, 15 Jun 2005 17:29:39 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit 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 have not heard any objections to this proposal, so I am going to make this change. On Jun 10, 2005, at 5:03 PM, David R. Oran wrote: > This header is unfortunately named and will likely cause confusion > and dismay among the security community, because it does not have > any useful relationship to anything they would recognize as a > security level. > > To refresh your cache, the header is described by the following text: > > "The Security-Level header determines the range of verification > scores in which a decision of 'accepted' may be declared. This > header MAY occur in SET-PARAMS, GET-PARAMS and START-SESSION > methods. It can be "high" (highest security level), "medium-high", > "medium" (normal security level), "medium-low", or "low" (low > security level). The default value is platform specific." > > In addition, the terms "high", medium-high", etc. for the values > are semantic-free in practice and quantized in a completely > arbitrary way. > > I propose we rename this header to be "confidence-level" and use > the same 0-1 range we do with this header for other operations like > recognition. > > The description text would then read: > > > "The confidence-threshold, when used on a verification resource > through a SET-PARAMS, GET-PARAMS and START-SESSION method, > determines the minumum verification score for which a verification > decision of "accepted" may be declared by the server. See section > xxx for a description of the use of this header with the recognizer > resource." > > Objections? > > Dave. > > _______________________________________________ > 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 Jun 15 18:17:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dig9y-00061o-A3; Wed, 15 Jun 2005 18:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dig9v-00061b-VS for speechsc@megatron.ietf.org; Wed, 15 Jun 2005 18:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11070 for ; Wed, 15 Jun 2005 18:14:53 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DigWe-0001py-Oh for speechsc@ietf.org; Wed, 15 Jun 2005 18:38:28 -0400 X-SEF-Processed: 5_0_0_713__2005_06_15_17_12_44 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Wed, 15 Jun 2005 17:12:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Managing big grammars Date: Wed, 15 Jun 2005 17:13:53 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524D7@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Managing big grammars Thread-Index: AcVx7G2Ox8883aL3RDSghlVVI66iZAAAHD+g From: "Wyss, Felix" To: "Dave Burke" , "Bennett, Patrick" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Shanmugham, Saravanan" , "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 [inline] > [Dave B] . If you invoke DEFINE-GRAMMAR with some kind of > header to indicate fail if the object is not in the cache, is the MRCP > server to go fetch it anyway for future use? Should this mechanism > fail if the grammar is an intermediate cache somewhere between the > MRCP server and HTTP origin server? [Felix I. Wyss] Looking at this from an application's perspective, I think the criteria should be: A "cache probing" DEFINE-GRAMMAR should fail if the server cannot guarantee that an immediately following recognition with that grammar will not incur noticeable delays (e.g. >0.5s). In practice I presume that will probably mean that the server has to have the compiled version of the grammar already cached. =20 I would say the command does not cause the grammar to be fetched if it is not in the cache. Felix=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 16 04:25:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dipgr-0004ow-Sq; Thu, 16 Jun 2005 04:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dipgq-0004oo-19 for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 04:25:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25290 for ; Thu, 16 Jun 2005 04:25:26 -0400 (EDT) Received: from pb-exchcon2.scansoft.com ([199.4.160.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diq3g-0001kE-HH for speechsc@ietf.org; Thu, 16 Jun 2005 04:49:09 -0400 Received: by pb-exchcon2.pb.scansoft.com with Internet Mail Service (5.5.2658.27) id ; Thu, 16 Jun 2005 04:25:20 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'David R. Oran'" , "speechsc@ietf.org ((((E-mail))))" Subject: RE: [Speechsc] Security-level header in speaker verification meth ods Date: Thu, 16 Jun 2005 04:18:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.27) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "'forgues@nuance.com'" 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 Dave, the term "confidence" should be applied to the likelihood a result is correct, not to the result itself. Otherwise the semantic of "confidence" would differ between ASR and SV. This would be very confusing, specially for servers that do ASR and SV in parallel with the same engine. A preferable name would be "min-verification-score", which goes well with your proposed text. Regards, Klaus -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Mittwoch, 15. Juni 2005 23:30 To: speechsc@ietf.org ((((E-mail)))) Subject: Re: [Speechsc] Security-level header in speaker verification methods I have not heard any objections to this proposal, so I am going to make this change. On Jun 10, 2005, at 5:03 PM, David R. Oran wrote: > This header is unfortunately named and will likely cause confusion and > dismay among the security community, because it does not have any > useful relationship to anything they would recognize as a security > level. > > To refresh your cache, the header is described by the following text: > > "The Security-Level header determines the range of verification scores > in which a decision of 'accepted' may be declared. This header MAY > occur in SET-PARAMS, GET-PARAMS and START-SESSION methods. It can be > "high" (highest security level), "medium-high", "medium" (normal > security level), "medium-low", or "low" (low security level). The > default value is platform specific." > > In addition, the terms "high", medium-high", etc. for the values are > semantic-free in practice and quantized in a completely arbitrary way. > > I propose we rename this header to be "confidence-level" and use the > same 0-1 range we do with this header for other operations like > recognition. > > The description text would then read: > > > "The confidence-threshold, when used on a verification resource > through a SET-PARAMS, GET-PARAMS and START-SESSION method, determines > the minumum verification score for which a verification decision of > "accepted" may be declared by the server. See section xxx for a > description of the use of this header with the recognizer resource." > > Objections? > > Dave. > > _______________________________________________ > 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 Thu Jun 16 08:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitAq-0005SY-TE; Thu, 16 Jun 2005 08:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitAp-0005ST-65 for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 08:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11686 for ; Thu, 16 Jun 2005 08:08:38 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DitXh-0001vb-K7 for speechsc@ietf.org; Thu, 16 Jun 2005 08:32:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Jun 2005 05:08:32 -0700 X-IronPort-AV: i="3.93,204,1115017200"; d="scan'208"; a="644009424:sNHT27719058" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GC8R7l029205 for ; Thu, 16 Jun 2005 05:08:27 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5GBu4bP028396 for ; Thu, 16 Jun 2005 04:56:04 -0700 Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <9C39EC67-4228-4CAD-A417-B29659201EEC@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: "David R. Oran" Date: Thu, 16 Jun 2005 08:08:28 -0400 X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118922964.846797"; x:"432200"; a:"rsa-sha1"; b:"nofws:867"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"aE08Zvgi2B7+7vm2LkuwAbPkMOBxawUQMD5az6fVk37rSE196HpJkltE7sto9OTw+PQzEkBk" "BabToVsUo/R6qQ4Jw1w/Qrg+RVUuRwNPg4kNoIJm9oRgywR1OrVibCI0dfrwyoDpYFKRYZHyWvq" "0ER13qTLeOSp0OYNWp4IZe8Y="; c:"From: =22David R. Oran=22 "; c:"Subject: Small point on verification scores"; c:"Date: Thu, 16 Jun 2005 08:08:28 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Speechsc] Small point on verification scores 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 text says: "During verification, the higher the score the more likely it is that the speaker is the same one as the one who spoke the voiceprint utterances. During training, the higher the score the more likely the speaker is to have spoken all of the analyzed utterances. The value is a floating point between 0.0 and 1.0. If there are no such utterances the score is 0. It should be noted that though the value of the verification score is between 0.0 and 1.0 it SHOULD NOT be interpreted as a probability value." Ok, I'll bite. How can we say in the first sentence "the higher the score the more likely is is that the speaker is the same one who spoke the voiceprint utterances", and then say it should not be interpreted as a probability value? If not a probability, then...WHAT? Are you saying that verification servers can't even normalize their outputs to some credible statistical model? That sucks, but if it's really so flakey we should say: "it SHOULD NOT be interpreted as a probability value in the strict statistical sense." Comments? _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 16 08:14:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitGO-0006Ks-RH; Thu, 16 Jun 2005 08:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitGN-0006Kl-37 for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 08:14:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12211 for ; Thu, 16 Jun 2005 08:14:22 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DitdF-0002On-GC for speechsc@ietf.org; Thu, 16 Jun 2005 08:38:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2005 05:14:16 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5GCEETc013391; Thu, 16 Jun 2005 05:14:14 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5GC1lS6028461; Thu, 16 Jun 2005 05:01:47 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81552320-821E-4119-BFB8-E740EAFE1516@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Security-level header in speaker verification meth ods Date: Thu, 16 Jun 2005 08:14:12 -0400 To: "Reifenrath, Klaus" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118923308.310790"; x:"432200"; a:"rsa-sha1"; b:"nofws:2248"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"iRQEVbztdlQyoAzrDOfhB6A8LDAcNjNtg+SP60JI5h+QKqe/FwQXsap6tEkWV9tNdcls5AcU" "GUtLAMpZ5/qN8L3DEoYIpcWk/3126zmO89Am9wSgnEd2M8XtBR0PO/0AjqHPdes5b6HmEZ3cp6e" "1yP6MfNxjEGb59tPkzk2VjCU="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Security-level header in speaker verificatio" "n meth ods"; c:"Date: Thu, 16 Jun 2005 08:14:12 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" , "'forgues@nuance.com'" 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 On Jun 16, 2005, at 4:18 AM, Reifenrath, Klaus wrote: > Hi Dave, > > the term "confidence" should be applied to the likelihood a result is > correct, not to the result itself. Otherwise the semantic of > "confidence" > would differ between ASR and SV. This would be very confusing, > specially for > servers that do ASR and SV in parallel with the same engine. > A preferable name would be "min-verification-score", which goes > well with > your proposed text. > OK, that makes sense. I'll change the name and adjust the text. > Regards, > Klaus > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Mittwoch, 15. Juni 2005 23:30 > To: speechsc@ietf.org ((((E-mail)))) > Subject: Re: [Speechsc] Security-level header in speaker verification > methods > > I have not heard any objections to this proposal, so I am going to > make this > change. > > On Jun 10, 2005, at 5:03 PM, David R. Oran wrote: > > >> This header is unfortunately named and will likely cause confusion >> and >> dismay among the security community, because it does not have any >> useful relationship to anything they would recognize as a security >> level. >> >> To refresh your cache, the header is described by the following text: >> >> "The Security-Level header determines the range of verification >> scores >> in which a decision of 'accepted' may be declared. This header MAY >> occur in SET-PARAMS, GET-PARAMS and START-SESSION methods. It can be >> "high" (highest security level), "medium-high", "medium" (normal >> security level), "medium-low", or "low" (low security level). The >> default value is platform specific." >> >> In addition, the terms "high", medium-high", etc. for the values are >> semantic-free in practice and quantized in a completely arbitrary >> way. >> >> I propose we rename this header to be "confidence-level" and use the >> same 0-1 range we do with this header for other operations like >> recognition. >> >> The description text would then read: >> >> >> "The confidence-threshold, when used on a verification resource >> through a SET-PARAMS, GET-PARAMS and START-SESSION method, determines >> the minumum verification score for which a verification decision of >> "accepted" may be declared by the server. See section xxx for a >> description of the use of this header with the recognizer resource." >> >> Objections? >> >> Dave. >> >> _______________________________________________ >> 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 Thu Jun 16 09:20:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuIe-0004C2-O7; Thu, 16 Jun 2005 09:20:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuId-0004A4-1u for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 09:20:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18923 for ; Thu, 16 Jun 2005 09:20:44 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiufS-0007UI-Vv for speechsc@ietf.org; Thu, 16 Jun 2005 09:44:29 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5GDKX6f005132 for ; Thu, 16 Jun 2005 09:20:33 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5GDKXCk194972 for ; Thu, 16 Jun 2005 09:20:33 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5GDKWTf011950 for ; Thu, 16 Jun 2005 09:20:33 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5GDKWBi011915; Thu, 16 Jun 2005 09:20:32 -0400 In-Reply-To: <9C39EC67-4228-4CAD-A417-B29659201EEC@cisco.com> Importance: Normal Subject: Re: [Speechsc] Small point on verification scores To: "David R. Oran" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Ran Zilca Date: Thu, 16 Jun 2005 09:20:28 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/16/2005 09:20:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "speechsc@ietf.org \(\(\(\(E-mail\)\)\)\)" 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 Normalizing the score to fit in a predetermined range has practical advantages, but unfortunately it does not imply any probabilistic interpretation. I believe that associating reliable probabilities to scores is still an open research problem. Instead, vendors are more likely to provide users with offline tools that will analyze data and recommend score thresholds associated with desired errors (but the threshold values will not have a direct probabilistic meaning). To avoid further confusion I suggest to both adopt the new suggested wording and also change the score range to be [-1,1]. -- Ran Ran Zilca Senior Software Engineer IBM T. J. Watson Research Center 1101 Kitchawan Rd. Yorktown Heights, NY 10598 http://www.research.ibm.com/CBG Voice: (914) 945-3013 Fax: (914) 945-4490 "David R. Oran" @ietf.org on 06/16/2005 08:08:28 AM Sent by: speechsc-bounces@ietf.org To: "speechsc@ietf.org ((((E-mail))))" cc: Subject: [Speechsc] Small point on verification scores The text says: "During verification, the higher the score the more likely it is that the speaker is the same one as the one who spoke the voiceprint utterances. During training, the higher the score the more likely the speaker is to have spoken all of the analyzed utterances. The value is a floating point between 0.0 and 1.0. If there are no such utterances the score is 0. It should be noted that though the value of the verification score is between 0.0 and 1.0 it SHOULD NOT be interpreted as a probability value." Ok, I'll bite. How can we say in the first sentence "the higher the score the more likely is is that the speaker is the same one who spoke the voiceprint utterances", and then say it should not be interpreted as a probability value? If not a probability, then...WHAT? Are you saying that verification servers can't even normalize their outputs to some credible statistical model? That sucks, but if it's really so flakey we should say: "it SHOULD NOT be interpreted as a probability value in the strict statistical sense." Comments? _______________________________________________ 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 Thu Jun 16 09:30:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuS6-0006Vu-JZ; Thu, 16 Jun 2005 09:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuS5-0006Vk-63 for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 09:30:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19523 for ; Thu, 16 Jun 2005 09:30:32 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diuox-0007yy-5c for speechsc@ietf.org; Thu, 16 Jun 2005 09:54:17 -0400 Received: from postcard.nuance.com ([10.3.6.20]:54166) by letter.nuance.com with esmtp id 1DiuRh-0000jf-6i; Thu, 16 Jun 2005 06:30:13 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Jun 2005 09:28:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Small point on verification scores Date: Thu, 16 Jun 2005 09:28:13 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802DF13BB@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Small point on verification scores Thread-Index: AcVydiM4S4cgNrvLRESef92iCH+WUQAAPrHA From: "Pierre Forgues" To: "Ran Zilca" , "David R. Oran" X-OriginalArrivalTime: 16 Jun 2005 13:28:13.0282 (UTC) FILETIME=[3EF49C20:01C57277] X-FromHost: postcard.nuance.com [10.3.6.20]:54166 Lines: 96 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 agree with the proposed wording, but would rather stay with a range from 0.0 to 1.0. What is the rationale/value for changing this to a different range? Pierre -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Ran Zilca Sent: Thursday, June 16, 2005 9:20 AM To: David R. Oran Cc: speechsc@ietf.org ((((E-mail)))) Subject: Re: [Speechsc] Small point on verification scores Normalizing the score to fit in a predetermined range has practical advantages, but unfortunately it does not imply any probabilistic interpretation. I believe that associating reliable probabilities to scores is still an open research problem. Instead, vendors are more likely to provide users with offline tools that will analyze data and recommend score thresholds associated with desired errors (but the threshold values will not have a direct probabilistic meaning). To avoid further confusion I suggest to both adopt the new suggested wording and also change the score range to be [-1,1]. -- Ran Ran Zilca Senior Software Engineer IBM T. J. Watson Research Center 1101 Kitchawan Rd. Yorktown Heights, NY 10598 http://www.research.ibm.com/CBG Voice: (914) 945-3013 Fax: (914) 945-4490 "David R. Oran" @ietf.org on 06/16/2005 08:08:28 AM Sent by: speechsc-bounces@ietf.org To: "speechsc@ietf.org ((((E-mail))))" cc: Subject: [Speechsc] Small point on verification scores The text says: "During verification, the higher the score the more likely it is that the speaker is the same one as the one who spoke the voiceprint utterances. During training, the higher the score the more likely the speaker is to have spoken all of the analyzed utterances. The value is a floating point between 0.0 and 1.0. If there are no such utterances the score is 0. It should be noted that though the value of the verification score is between 0.0 and 1.0 it SHOULD NOT be interpreted as a probability value." Ok, I'll bite. How can we say in the first sentence "the higher the score the more likely is is that the speaker is the same one who spoke the voiceprint utterances", and then say it should not be interpreted as a probability value? If not a probability, then...WHAT? Are you saying that verification servers can't even normalize their outputs to some credible statistical model? That sucks, but if it's really so flakey we should say: "it SHOULD NOT be interpreted as a probability value in the strict statistical sense." Comments? _______________________________________________ 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 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 16 09:33:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuUl-0006tF-Rr; Thu, 16 Jun 2005 09:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiuUk-0006sc-88 for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 09:33:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19715 for ; Thu, 16 Jun 2005 09:33:13 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiurZ-00089R-Oi for speechsc@ietf.org; Thu, 16 Jun 2005 09:56:58 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5GDX56a026067 for ; Thu, 16 Jun 2005 09:33:05 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5GDX5Ck193736 for ; Thu, 16 Jun 2005 09:33:05 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5GDX5sn028595 for ; Thu, 16 Jun 2005 09:33:05 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5GDX4Xv028578; Thu, 16 Jun 2005 09:33:04 -0400 In-Reply-To: <7DE7C4EF3B7C8B4B82955191378290D802DF13BB@mtb1exch01.nuance.com> Importance: Normal Subject: RE: [Speechsc] Small point on verification scores To: "Pierre Forgues" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Ran Zilca Date: Thu, 16 Jun 2005 09:33:02 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/16/2005 09:33:04 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: speechsc@ietf.org, "David R. Oran" 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 Once a system is deployed people do not always read the "fine print" in the spec, and there is a concern that people will interpret the scores as probabilities based on the value range. Ran "Pierre Forgues" on 06/16/2005 09:28:13 AM To: Ran Zilca/Watson/IBM@IBMUS, "David R. Oran" cc: Subject: RE: [Speechsc] Small point on verification scores I agree with the proposed wording, but would rather stay with a range from 0.0 to 1.0. What is the rationale/value for changing this to a different range? Pierre -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Ran Zilca Sent: Thursday, June 16, 2005 9:20 AM To: David R. Oran Cc: speechsc@ietf.org ((((E-mail)))) Subject: Re: [Speechsc] Small point on verification scores Normalizing the score to fit in a predetermined range has practical advantages, but unfortunately it does not imply any probabilistic interpretation. I believe that associating reliable probabilities to scores is still an open research problem. Instead, vendors are more likely to provide users with offline tools that will analyze data and recommend score thresholds associated with desired errors (but the threshold values will not have a direct probabilistic meaning). To avoid further confusion I suggest to both adopt the new suggested wording and also change the score range to be [-1,1]. -- Ran Ran Zilca Senior Software Engineer IBM T. J. Watson Research Center 1101 Kitchawan Rd. Yorktown Heights, NY 10598 http://www.research.ibm.com/CBG Voice: (914) 945-3013 Fax: (914) 945-4490 "David R. Oran" @ietf.org on 06/16/2005 08:08:28 AM Sent by: speechsc-bounces@ietf.org To: "speechsc@ietf.org ((((E-mail))))" cc: Subject: [Speechsc] Small point on verification scores The text says: "During verification, the higher the score the more likely it is that the speaker is the same one as the one who spoke the voiceprint utterances. During training, the higher the score the more likely the speaker is to have spoken all of the analyzed utterances. The value is a floating point between 0.0 and 1.0. If there are no such utterances the score is 0. It should be noted that though the value of the verification score is between 0.0 and 1.0 it SHOULD NOT be interpreted as a probability value." Ok, I'll bite. How can we say in the first sentence "the higher the score the more likely is is that the speaker is the same one who spoke the voiceprint utterances", and then say it should not be interpreted as a probability value? If not a probability, then...WHAT? Are you saying that verification servers can't even normalize their outputs to some credible statistical model? That sucks, but if it's really so flakey we should say: "it SHOULD NOT be interpreted as a probability value in the strict statistical sense." Comments? _______________________________________________ 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 Thu Jun 16 09:41:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diuch-0000sc-Ep; Thu, 16 Jun 2005 09:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diucf-0000sX-Ub for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 09:41:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20595 for ; Thu, 16 Jun 2005 09:41:28 -0400 (EDT) Received: from letter.nuance.com ([207.107.210.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diuza-0000J7-6V for speechsc@ietf.org; Thu, 16 Jun 2005 10:05:14 -0400 Received: from postcard.nuance.com ([10.3.6.20]:54364) by letter.nuance.com with esmtp id 1DiucW-0000yg-0T; Thu, 16 Jun 2005 06:41:24 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 16 Jun 2005 09:39:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Small point on verification scores Date: Thu, 16 Jun 2005 09:39:22 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D802DF13C8@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] Small point on verification scores Thread-Index: AcVyd69vPtDTv/X+RXyjto1g68nusAAANrIg From: "Pierre Forgues" To: "Ran Zilca" X-OriginalArrivalTime: 16 Jun 2005 13:39:24.0081 (UTC) FILETIME=[CEC86A10:01C57278] X-FromHost: postcard.nuance.com [10.3.6.20]:54364 Lines: 133 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "David R. Oran" 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 Very well, I understand and agree with the [-1,1] range. This actually fits our model where -1 is considered an imposter, 0 is undecided and +1 is the true speaker. We should note that the VoiceXML work is considering mapping this to an integer from 0-100, but that is a different story. Pierre -----Original Message----- From: Ran Zilca [mailto:zilca@us.ibm.com]=20 Sent: Thursday, June 16, 2005 9:33 AM To: Pierre Forgues Cc: David R. Oran; speechsc@ietf.org Subject: RE: [Speechsc] Small point on verification scores Once a system is deployed people do not always read the "fine print" in the spec, and there is a concern that people will interpret the scores as probabilities based on the value range. Ran "Pierre Forgues" on 06/16/2005 09:28:13 AM To: Ran Zilca/Watson/IBM@IBMUS, "David R. Oran" cc: Subject: RE: [Speechsc] Small point on verification scores I agree with the proposed wording, but would rather stay with a range from 0.0 to 1.0. What is the rationale/value for changing this to a different range? Pierre -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Ran Zilca Sent: Thursday, June 16, 2005 9:20 AM To: David R. Oran Cc: speechsc@ietf.org ((((E-mail)))) Subject: Re: [Speechsc] Small point on verification scores Normalizing the score to fit in a predetermined range has practical advantages, but unfortunately it does not imply any probabilistic interpretation. I believe that associating reliable probabilities to scores is still an open research problem. Instead, vendors are more likely to provide users with offline tools that will analyze data and recommend score thresholds associated with desired errors (but the threshold values will not have a direct probabilistic meaning). To avoid further confusion I suggest to both adopt the new suggested wording and also change the score range to be [-1,1]. -- Ran Ran Zilca Senior Software Engineer IBM T. J. Watson Research Center 1101 Kitchawan Rd. Yorktown Heights, NY 10598 http://www.research.ibm.com/CBG Voice: (914) 945-3013 Fax: (914) 945-4490 "David R. Oran" @ietf.org on 06/16/2005 08:08:28 AM Sent by: speechsc-bounces@ietf.org To: "speechsc@ietf.org ((((E-mail))))" cc: Subject: [Speechsc] Small point on verification scores The text says: "During verification, the higher the score the more likely it is that the speaker is the same one as the one who spoke the voiceprint utterances. During training, the higher the score the more likely the speaker is to have spoken all of the analyzed utterances. The value is a floating point between 0.0 and 1.0. If there are no such utterances the score is 0. It should be noted that though the value of the verification score is between 0.0 and 1.0 it SHOULD NOT be interpreted as a probability value." Ok, I'll bite. How can we say in the first sentence "the higher the score the more likely is is that the speaker is the same one who spoke the voiceprint utterances", and then say it should not be interpreted as a probability value? If not a probability, then...WHAT? Are you saying that verification servers can't even normalize their outputs to some credible statistical model? That sucks, but if it's really so flakey we should say: "it SHOULD NOT be interpreted as a probability value in the strict statistical sense." Comments? _______________________________________________ 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 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Jun 16 09:51:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diuma-0003Hq-H9; Thu, 16 Jun 2005 09:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiumX-0003Hf-KZ for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 09:51:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21815 for ; Thu, 16 Jun 2005 09:51:40 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Div9R-0000xj-Rp for speechsc@ietf.org; Thu, 16 Jun 2005 10:15:26 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2005 06:51:34 -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 j5GDpSQ3019081; Thu, 16 Jun 2005 06:51:29 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5GDd1Jc028979; Thu, 16 Jun 2005 06:39:02 -0700 In-Reply-To: <7DE7C4EF3B7C8B4B82955191378290D802DF13C8@mtb1exch01.nuance.com> References: <7DE7C4EF3B7C8B4B82955191378290D802DF13C8@mtb1exch01.nuance.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FDD2726-B142-406C-A8F4-74FD9E8A9216@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Subject: Re: [Speechsc] Small point on verification scores Date: Thu, 16 Jun 2005 09:51:26 -0400 To: "Pierre Forgues" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118929143.4051"; x:"432200"; a:"rsa-sha1"; b:"nofws:3446"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"En02LIhUg7VbmK6EmKtVo8dTz7Gi8JuMghgmj3R9dFRgVEjJkQuwBMIR9elSE9rkr4ttqFxF" "BkibK4rBjjinkFTV32tP+COAqSPnTsZppo+tVC0pfAEiQHwssCftOyKmntKb7UEclmpwCtIFyvK" "++Wy7Mo03NvK5GcyVSKPdmqI="; c:"From: =22David R. Oran=22 "; c:"Subject: Re: [Speechsc] Small point on verification scores"; c:"Date: Thu, 16 Jun 2005 09:51:26 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, Ran Zilca 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 change this and the newly-renamed min-verification-score header to -1:1 range unless I hear objection with persuasive rationale. Dave. On Jun 16, 2005, at 9:39 AM, Pierre Forgues wrote: > Very well, I understand and agree with the [-1,1] range. This > actually > fits our model where -1 is considered an imposter, 0 is undecided > and +1 > is the true speaker. > > We should note that the VoiceXML work is considering mapping this > to an > integer from 0-100, but that is a different story. > > Pierre > > -----Original Message----- > From: Ran Zilca [mailto:zilca@us.ibm.com] > Sent: Thursday, June 16, 2005 9:33 AM > To: Pierre Forgues > Cc: David R. Oran; speechsc@ietf.org > Subject: RE: [Speechsc] Small point on verification scores > > Once a system is deployed people do not always read the "fine > print" in > the > spec, and there is a concern that people will interpret the scores as > probabilities based on the value range. > > Ran > > > "Pierre Forgues" on 06/16/2005 09:28:13 AM > > To: Ran Zilca/Watson/IBM@IBMUS, "David R. Oran" > cc: > Subject: RE: [Speechsc] Small point on verification scores > > > I agree with the proposed wording, but would rather stay with a range > from 0.0 to 1.0. What is the rationale/value for changing this to a > different range? > > Pierre > > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On > Behalf Of Ran Zilca > Sent: Thursday, June 16, 2005 9:20 AM > To: David R. Oran > Cc: speechsc@ietf.org ((((E-mail)))) > Subject: Re: [Speechsc] Small point on verification scores > > Normalizing the score to fit in a predetermined range has practical > advantages, but unfortunately it does not imply any probabilistic > interpretation. I believe that associating reliable probabilities to > scores > is still an open research problem. Instead, vendors are more likely to > provide users with offline tools that will analyze data and recommend > score > thresholds associated with desired errors (but the threshold values > will > not have a direct probabilistic meaning). > > To avoid further confusion I suggest to both adopt the new suggested > wording and also change the score range to be [-1,1]. > > -- Ran > > Ran Zilca > Senior Software Engineer > IBM T. J. Watson Research Center > 1101 Kitchawan Rd. > Yorktown Heights, NY 10598 > > http://www.research.ibm.com/CBG > > Voice: (914) 945-3013 > Fax: (914) 945-4490 > > > > > "David R. Oran" @ietf.org on 06/16/2005 08:08:28 AM > > Sent by: speechsc-bounces@ietf.org > > > To: "speechsc@ietf.org ((((E-mail))))" > cc: > Subject: [Speechsc] Small point on verification scores > > > The text says: > > "During verification, the higher the score the more likely > it is that the speaker is the same one as the one who > spoke the voiceprint utterances. During training, the > higher the score the more likely the speaker is to have > spoken all of the analyzed utterances. The value is a > floating point between 0.0 and 1.0. If there are no such > utterances the score is 0. It should be noted that though > the value of the verification score is between 0.0 and 1.0 > it SHOULD NOT be interpreted as a probability value." > > Ok, I'll bite. How can we say in the first sentence "the higher the > score the more likely is is that the speaker is > the same one who spoke the voiceprint utterances", and then say it > should not be interpreted as a probability value? If not a > probability, then...WHAT? > > Are you saying that verification servers can't even normalize their > outputs to some credible statistical model? > > That sucks, but if it's really so flakey we should say: > > "it SHOULD NOT be interpreted as a probability value in the strict > statistical sense." > > Comments? > > _______________________________________________ > 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 Thu Jun 16 23:24:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj7TF-0005jj-K5; Thu, 16 Jun 2005 23:24:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj7TD-0005je-W9 for speechsc@megatron.ietf.org; Thu, 16 Jun 2005 23:24:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12259 for ; Thu, 16 Jun 2005 23:24:33 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj7qB-00037j-0K for speechsc@ietf.org; Thu, 16 Jun 2005 23:48:24 -0400 X-SEF-Processed: 5_0_0_713__2005_06_16_22_22_53 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Thu, 16 Jun 2005 22:22:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Thu, 16 Jun 2005 22:24:04 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524EC@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVxiWWYpkvgFljQTq6XShz4Llj6rwANxgzgAAatcaAAQc/OQA== From: "Wyss, Felix" To: "Shanmugham, Saravanan" , "Dave Burke" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 Does this seem reasonable? =20 Felix ******************************************************* text/grammar-ref-list MIME type registration=20 =20 IANA is requested to register the following MIME type according to the process defined in RFC 2048.=20 To: ietf-types@iana.org=20 Subject: Registration of MIME media type text/grammar-ref-list MIME media type name: text=20 MIME subtype name: grammar-ref-list Required parameters:=20 None Optional parameters:=20 None=20 Encoding considerations: =20 Depending on the transfer protocol, a transfer encoding may be necessary to deal with very long lines. =20 Security considerations: =20 This media type contains URIs which may represent references to external resources. As these resources are assumed to be speech recognition grammars, similar considerations as for the media types "application/srgs" and "application/srgs+xml" [1] apply. =20 Interoperability considerations: =20 We make the assumption that '>' is not a valid character in a URI according to RFC2396. =20 Published specification: The RECOGNIZE method of the MRCP protocol performs a recognition operation that matches input against a set of grammars. When matching against more than one grammar, it is sometimes necessary to use different weights for the individual grammars. These weights are not a property of the grammar resource itself but qualify the reference to that grammar for the particular recognition operation initiated by the RECOGNIZE method.=20 The format of the proposed text/grammar-ref-list media type is as follows: body =3D *line line =3D (comment | reference) CRLF comment =3D "#" * reference =3D "<" uri ">" [parameters] [comment] parameters =3D ":" parameter *(";" parameter) parameter =3D name "=3D" value uri =3D name =3D value =3D =20 Note that MRCP currently only uses a 'weight' parameter, but there may be the need for additional parameters in the future (even vendor specific extensions). Names of vendor specific parameters SHOULD start with "x-". =20 Example: # Input for 'Form 1' # weight 1.0 is default :weight=3D"0.85" :weight=3D"0.75" Applications which use this media type: Media Resource Control Protocol (MRCP)=20 Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none [1] The W3C Speech Interface Framework Media Types: application/voicexml+xml, =20 application/ssml+xml, application/srgs, application/srgs+xml,=20 application/ccxml+xml and application/pls+xml;=20 http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes-02 .txt > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, June 15, 2005 13:53 > To: Wyss, Felix; Dave Burke; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type >=20 > I am fine with the idea. > Would you be able to propose a content-type registration section for > this content-type. > We could add it to the current list of registrations and retire the > one-of header. >=20 > Sarvi >=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 17 05:54:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjDYk-0000aP-PO; Fri, 17 Jun 2005 05:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjDYj-0000aK-Rj for speechsc@megatron.ietf.org; Fri, 17 Jun 2005 05:54:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00264 for ; Fri, 17 Jun 2005 05:54:42 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjDvn-0005rO-SC for speechsc@ietf.org; Fri, 17 Jun 2005 06:18:36 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id D99D4214041; Fri, 17 Jun 2005 09:54:28 +0000 (GMT) Message-ID: <005a01c57322$8d5271c0$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Wyss, Felix" , "Shanmugham, Saravanan" , "David R. Oran" References: <8F9F1C6AA1D6834EACC379C8821533A6011524EC@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Fri, 17 Jun 2005 10:54:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Bennett, Patrick" 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 Looks good. Just one or two queries/comments: - Why delimit the first parameter with ":" and the subsequent with ";". Simpler, more uniform to just use ";"? - Is a comments mechanism really needed? "#" is very common in URIs to identify fragments (especially in SRGS!) - Should we include weight in "Optional Parameters" (we either define it here or in MRCP spec)? - We'll also use session: URIs with the grammar-ref-list (to allow weights on previously DEFINE'd-GRAMMARs). Fits BNF in RFC2396 and below Dave ----- Original Message ----- From: "Wyss, Felix" To: "Shanmugham, Saravanan" ; "Dave Burke" ; "David R. Oran" Cc: ; "Bennett, Patrick" Sent: Friday, June 17, 2005 4:24 AM Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Does this seem reasonable? Felix ******************************************************* text/grammar-ref-list MIME type registration IANA is requested to register the following MIME type according to the process defined in RFC 2048. To: ietf-types@iana.org Subject: Registration of MIME media type text/grammar-ref-list MIME media type name: text MIME subtype name: grammar-ref-list Required parameters: None Optional parameters: None Encoding considerations: Depending on the transfer protocol, a transfer encoding may be necessary to deal with very long lines. Security considerations: This media type contains URIs which may represent references to external resources. As these resources are assumed to be speech recognition grammars, similar considerations as for the media types "application/srgs" and "application/srgs+xml" [1] apply. Interoperability considerations: We make the assumption that '>' is not a valid character in a URI according to RFC2396. Published specification: The RECOGNIZE method of the MRCP protocol performs a recognition operation that matches input against a set of grammars. When matching against more than one grammar, it is sometimes necessary to use different weights for the individual grammars. These weights are not a property of the grammar resource itself but qualify the reference to that grammar for the particular recognition operation initiated by the RECOGNIZE method. The format of the proposed text/grammar-ref-list media type is as follows: body = *line line = (comment | reference) CRLF comment = "#" * reference = "<" uri ">" [parameters] [comment] parameters = ":" parameter *(";" parameter) parameter = name "=" value uri = name = value = Note that MRCP currently only uses a 'weight' parameter, but there may be the need for additional parameters in the future (even vendor specific extensions). Names of vendor specific parameters SHOULD start with "x-". Example: # Input for 'Form 1' # weight 1.0 is default :weight="0.85" :weight="0.75" Applications which use this media type: Media Resource Control Protocol (MRCP) Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none [1] 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; http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes-02 .txt > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Wednesday, June 15, 2005 13:53 > To: Wyss, Felix; Dave Burke; David R. Oran > Cc: speechsc@ietf.org; Bennett, Patrick > Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri- > listcontent type > > I am fine with the idea. > Would you be able to propose a content-type registration section for > this content-type. > We could add it to the current list of registrations and retire the > one-of header. > > Sarvi > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 17 09:59:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHNW-0001j2-Rr; Fri, 17 Jun 2005 09:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHNV-0001it-0y for speechsc@megatron.ietf.org; Fri, 17 Jun 2005 09:59:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19050 for ; Fri, 17 Jun 2005 09:59:22 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjHka-0006Xp-So for speechsc@ietf.org; Fri, 17 Jun 2005 10:23:18 -0400 X-SEF-Processed: 5_0_0_713__2005_06_17_08_58_02 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Fri, 17 Jun 2005 08:58:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Date: Fri, 17 Jun 2005 08:59:14 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524ED@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6 RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVzIo+nWEHsF5UFTOaoZyBUULkw7QAHjGcA From: "Wyss, Felix" To: "Dave Burke" , "Shanmugham, Saravanan" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 [inline] >=20 > Looks good. Just one or two queries/comments: > - Why delimit the first parameter with ":" and the subsequent with > ";". > Simpler, more uniform to just use ";"? [Wyss, Felix] Oh, I just added this as syntactic sugar so it'd be similar to a header field. Technically, the ":" could be left out completely as the ">" already acts as a delimiter. Opinions? > - Is a comments mechanism really needed? "#" is very common in URIs to > identify fragments (especially in SRGS!) [Wyss, Felix] I use "<" and ">" to delimit the URIs. They are both not valid characters in URIs (i.e. they'd have to be escaped as %3c and %3e). =20 A fragment-only URI line would be as follows: <#SomeFragment>=20 This could thus not be misinterpreted as comment line (and vice-versa). I thought it'd be useful to be able to use comments, but I don't feel too strongly about it. =20 > - Should we include weight in "Optional Parameters" (we either define > it > here or in MRCP spec)? [Wyss, Felix] I assumed the "Optional Parameters" section of the registration requests applies to the MIME type itself, for example 'charset': text/grammar-ref-list;charset=3DUTF-8 I was actually debating whether to define 'charset' an optional parameter, but as URIs only comprise ASCII characters, I assumed it was not necessary. What do you think? =20 > - We'll also use session: URIs with the grammar-ref-list (to allow > weights on previously DEFINE'd-GRAMMARs). Fits BNF in RFC2396 and below [Wyss, Felix] Yes, of course. Any URI conforming to RFC2396 could be used in the grammar reference list; I just used HTTP as example. =20 Felix _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 17 09:59:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHNw-0001lO-BU; Fri, 17 Jun 2005 09:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHNv-0001lJ-7S for speechsc@megatron.ietf.org; Fri, 17 Jun 2005 09:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19092 for ; Fri, 17 Jun 2005 09:59:49 -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 1DjHl0-0006YQ-CH for speechsc@ietf.org; Fri, 17 Jun 2005 10:23:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 06:59:38 -0700 X-IronPort-AV: i="3.93,208,1115017200"; d="scan'208"; a="279974739:sNHT4422769450" 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 j5HDxXQ3003193 for ; Fri, 17 Jun 2005 06:59:34 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5HDl5NN005724 for ; Fri, 17 Jun 2005 06:47:06 -0700 Mime-Version: 1.0 (Apple Message framework v730) References: <03772D1EC8DE624A863058C75874A75C0ACD2A@vtg-um-e2k6.sj21ad.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4ABAC437-0EBE-40A4-9927-A53961E78275@cisco.com> Content-Transfer-Encoding: 7bit From: "David R. Oran" Date: Fri, 17 Jun 2005 09:59:28 -0400 To: "speechsc@ietf.org ((((E-mail))))" X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1119016026.343590"; x:"432200"; a:"rsa-sha1"; b:"nofws:896"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"BRcOr7a6wpup/GxaUXWuNsBYUzoS5u8W0pZ65ZJTsesDkP+hZi3KvvUrbX99acfL9Pl+gF4r" "3N6YfHT3xlVqCKsMDwroYdXC0vijSAwJoUiUNFoJEVfjRmp7l/y5L+OiQMk5Udrb/rfI+ZDHaFJ" "bslRUreE5N910ROPViXMFWxM="; c:"From: =22David R. Oran=22 "; c:"Subject: Fwd: DELETE-VOICEPRINT"; c:"Date: Fri, 17 Jun 2005 09:59:28 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Speechsc] Fwd: DELETE-VOICEPRINT 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 How does the WG feel about this? I probably applies to all operations like enrollment and training that modify voiceprints too. Begin forwarded message: > From: "Shanmugham, Saravanan" > Date: June 15, 2005 9:48:53 PM EDT > To: "David R. Oran" , "Eric Burger" > , "Dan Burnett" > Subject: RE: DELETE-VOICEPRINT > > > Yeah I think that makes sense. > > Sarvi > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Wednesday, June 15, 2005 3:57 PM > To: Shanmugham, Saravanan; Eric Burger; Dan Burnett > Subject: DELETE-VOICEPRINT > > The text says: > "The DELETE-VOICEPRINT method removes a voiceprint from a > repository. > This method MUST carry the Repository-URI and > Voiceprint-Identifier header fields. > > If the corresponding voiceprint does not exist, the > DELETE-VOICEPRINT method still returns a 200 status code." > > What if the client is not allowed to delete the > voiceprint? Do we need a separate "not allowed" error return? > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 17 10:15:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHd2-0004d3-4q; Fri, 17 Jun 2005 10:15:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHd0-0004cx-Vn for speechsc@megatron.ietf.org; Fri, 17 Jun 2005 10:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21120 for ; Fri, 17 Jun 2005 10:15:24 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjI06-0007cQ-LA for speechsc@ietf.org; Fri, 17 Jun 2005 10:39:20 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id F0487214041; Fri, 17 Jun 2005 14:15:11 +0000 (GMT) Message-ID: <008601c57346$f75401f0$cb00000a@db01.voxpilot.com> From: "Dave Burke" To: "Wyss, Felix" , "Shanmugham, Saravanan" , "David R. Oran" References: <8F9F1C6AA1D6834EACC379C8821533A6011524ED@i3mail1.i3domain.inin.com> Subject: Re: [Speechsc] Problem with draft-6RECOGNIZEcommandandtest/uri-listcontent type Date: Fri, 17 Jun 2005 15:15:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: speechsc@ietf.org, "Bennett, Patrick" 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 Inline. Cheers, Dave ----- Original Message ----- From: "Wyss, Felix" To: "Dave Burke" ; "Shanmugham, Saravanan" ; "David R. Oran" Cc: ; "Bennett, Patrick" Sent: Friday, June 17, 2005 2:59 PM Subject: RE: [Speechsc] Problem with draft-6RECOGNIZEcommandandtest/uri-listcontent type [inline] > > Looks good. Just one or two queries/comments: > - Why delimit the first parameter with ":" and the subsequent with > ";". > Simpler, more uniform to just use ";"? [Wyss, Felix] Oh, I just added this as syntactic sugar so it'd be similar to a header field. Technically, the ":" could be left out completely as the ">" already acts as a delimiter. Opinions? [Dave B] I like the following approach just because its familiar (SIP): ;weight=0.75 > - Is a comments mechanism really needed? "#" is very common in URIs to > identify fragments (especially in SRGS!) [Wyss, Felix] I use "<" and ">" to delimit the URIs. They are both not valid characters in URIs (i.e. they'd have to be escaped as %3c and %3e). A fragment-only URI line would be as follows: <#SomeFragment> This could thus not be misinterpreted as comment line (and vice-versa). I thought it'd be useful to be able to use comments, but I don't feel too strongly about it. [Dave B] I don't see any need for comments and am very mildly concerned there is potential for error here (a bad algorithm might truncate string to the '#' before extracting the URI from <.> and then the parameters) hence affecting interop. > - Should we include weight in "Optional Parameters" (we either define > it > here or in MRCP spec)? [Wyss, Felix] I assumed the "Optional Parameters" section of the registration requests applies to the MIME type itself, for example 'charset': text/grammar-ref-list;charset=UTF-8 I was actually debating whether to define 'charset' an optional parameter, but as URIs only comprise ASCII characters, I assumed it was not necessary. What do you think? [Dave B] Given RFC2396 doesn't address characters outside of ASCII, I'd keep the worms in the can and leave it out. > - We'll also use session: URIs with the grammar-ref-list (to allow > weights on previously DEFINE'd-GRAMMARs). Fits BNF in RFC2396 and below [Wyss, Felix] Yes, of course. Any URI conforming to RFC2396 could be used in the grammar reference list; I just used HTTP as example. Felix _______________________________________________ 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 Jun 17 10:45:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjI6R-00021P-6Q; Fri, 17 Jun 2005 10:45:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjI6O-00021H-6d for speechsc@megatron.ietf.org; Fri, 17 Jun 2005 10:45:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24379 for ; Fri, 17 Jun 2005 10:45:45 -0400 (EDT) Received: from i3smtp2.inin.com ([204.180.46.24] helo=inin.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjITU-0001Oj-KG for speechsc@ietf.org; Fri, 17 Jun 2005 11:09:42 -0400 X-SEF-Processed: 5_0_0_713__2005_06_17_09_44_26 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1 Received: from Unknown [172.16.1.161] by i3smtp2.inin.com - SurfControl E-mail Filter (5.0); Fri, 17 Jun 2005 09:44:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Problem with draft-6RECOGNIZEcommandandtest/uri-listcontent type Date: Fri, 17 Jun 2005 09:45:38 -0500 Message-ID: <8F9F1C6AA1D6834EACC379C8821533A6011524EE@i3mail1.i3domain.inin.com> Thread-Topic: [Speechsc] Problem with draft-6RECOGNIZEcommandandtest/uri-listcontent type Thread-Index: AcVzRvtn64pJQdJHTtKDU23tFWQqkQAAq3Rw From: "Wyss, Felix" To: "Dave Burke" , "Shanmugham, Saravanan" , "David R. Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: speechsc@ietf.org, "Bennett, Patrick" 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 [inline] > [Dave B] I like the following approach just because its familiar (SIP): > ;weight=3D0.75 [Wyss, Felix] OK, ";" it is.=20 > [Dave B] I don't see any need for comments and am very mildly > concerned there is potential for error here (a bad algorithm might > truncate string to the '#' before extracting the URI from <.> and then > the parameters) hence affecting interop. [Wyss, Felix] OK, I removed it. Here is the updated "Published Specification" section (I also added a "session:" URI to the example): Published specification: The RECOGNIZE method of the MRCP protocol performs a recognition operation that matches input against a set of grammars. When matching against more than one grammar, it is sometimes necessary to use different weights for the individual grammars. These weights are not a property of the grammar resource itself but qualify the reference to that grammar for the particular recognition operation initiated by the RECOGNIZE method.=20 The format of the proposed text/grammar-ref-list media type is as follows: body =3D *reference reference =3D "<" uri ">" parameters CRLF parameters =3D *(";" parameter) parameter =3D name "=3D" value uri =3D name =3D value =3D =20 Note that MRCP currently only uses a 'weight' parameter, but there may be the need for additional parameters in the future (even vendor specific extensions). Names of vendor specific parameters SHOULD start with "x-". =20 Example: ;weight=3D"0.85" ;weight=3D"0.9" ;weight=3D"0.75" Felix _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Jun 24 00:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfpO-0007Jm-6n; Fri, 24 Jun 2005 00:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfpM-0007J9-AY; Fri, 24 Jun 2005 00:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09049; Fri, 24 Jun 2005 00:30:01 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlgDn-0001s4-Rp; Fri, 24 Jun 2005 00:55:21 -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 j5O4RSdL002110; Fri, 24 Jun 2005 00:27:28 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jun 2005 00:22:34 -0400 Message-ID: From: Eric Burger To: lemonade@ietf.org, speechsc@ietf.org Date: Fri, 24 Jun 2005 00:22:33 -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: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Speechsc] FW: An interesting sub-note for all of you using the xml tool for drafts 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 > Carl Malamud wrote: > > Randall's method works, or you can do what the readme suggests: > > > > > > > > see: > > > > http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr > > A number of us, including the IETF Chair, have discovered > this experimentally. It's not illogical - if your source file > says you get exactly what you asked > for, i.e. the obsolete boilerplate. The id-nits tool will > warn you - it is well worth running that before submitting > *any* I-D, whether produced by xml2rfc or another method. > > See http://ietf.levkowetz.com/tools/idnits/idnits.pyht > > Brian _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Jun 27 09:40:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtqN-0004RQ-4J; Mon, 27 Jun 2005 09:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtqK-0004Qn-QA for speechsc@megatron.ietf.org; Mon, 27 Jun 2005 09:40:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21325 for ; Mon, 27 Jun 2005 09:40:05 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmuFS-0000he-QK for speechsc@ietf.org; Mon, 27 Jun 2005 10:06:08 -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 j5RDUXFi027003 for ; Mon, 27 Jun 2005 09:30:33 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jun 2005 09:25:37 -0400 Message-ID: From: Eric Burger To: speechsc@ietf.org Date: Mon, 27 Jun 2005 09:25: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: 7bac9cb154eb5790ae3b2913587a40de Subject: [Speechsc] Normal/Hotword/Both 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 There seemed to be consensus that if a 'speechrecog' resource was 'both', it could only be in one of 'normal' or 'hotword' mode at a given time. Is this a technology / semantic limitation or a licensing limitation? The reason I ask is the rationale given on the list seemed to revolve around licensing. If it is a licensing issue, I would offer the specification should allow "dual-mode." If it is a technology issue, never mind :) _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Jun 27 09:40:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtqN-0004Rp-CS; Mon, 27 Jun 2005 09:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtqK-0004Qo-Q8 for speechsc@megatron.ietf.org; Mon, 27 Jun 2005 09:40:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21328 for ; Mon, 27 Jun 2005 09:40:06 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmuFU-0000he-6u for speechsc@ietf.org; Mon, 27 Jun 2005 10:06:08 -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 j5RDUXFi027004 for ; Mon, 27 Jun 2005 09:30:33 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jun 2005 09:25:37 -0400 Message-ID: From: Eric Burger To: speechsc@ietf.org Date: Mon, 27 Jun 2005 09:25:35 -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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Speechsc] X- in grammar-ref-list 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 last round of ABNF specifying the text/grammar-ref-list looks good but for one exception. I would offer we keep the text saying additional parameters (other than weight) may happen. However, I would require parameters to be IANA-registered. I would specifically discourage the use of "x-". Registration is cheap (FCFS) and avoids the X- nightmare of e-mail. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc