From speechsc-bounces@ietf.org Thu Mar 01 12:00:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMod7-00083Q-7O; Thu, 01 Mar 2007 11:59:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQmd-0007cd-E7 for speechsc@ietf.org; Wed, 28 Feb 2007 10:31:59 -0500 Received: from bay0-omc3-s25.bay0.hotmail.com ([65.54.246.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMQma-0003qN-42 for speechsc@ietf.org; Wed, 28 Feb 2007 10:31:59 -0500 Received: from hotmail.com ([65.55.135.114]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 28 Feb 2007 07:31:55 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Feb 2007 07:31:55 -0800 Message-ID: Received: from 65.55.135.123 by by130fd.bay130.hotmail.msn.com with HTTP; Wed, 28 Feb 2007 15:31:52 GMT X-Originating-IP: [211.160.80.57] X-Originating-Email: [sorrylala@hotmail.com] X-Sender: sorrylala@hotmail.com From: "lala lala" To: speechsc@ietf.org Bcc: Date: Wed, 28 Feb 2007 15:31:52 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 28 Feb 2007 15:31:55.0357 (UTC) FILETIME=[93CBE0D0:01C75B4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Thu, 01 Mar 2007 11:59:44 -0500 Subject: [Speechsc] a problem with mrcpv2 for the media control 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: , Errors-To: speechsc-bounces@ietf.org hi,I have a problem with mrcpv2.I don't know if one sip session should create more than one speechsynth resource channel.The draft of mrcpv2 has a lot of examples which use one sip session to establish one speechsynth resource channel and then add a speechrecog channel.If the mrcpv2 server can create different channel id just like 1@speechsynth 、2@speechsynth by one sip session.Or each sip session can only create one channel for each resource.Thanks very much! _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Mar 05 09:25:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOE7T-0003l8-MJ; Mon, 05 Mar 2007 09:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOE7S-0003l3-OW for speechsc@ietf.org; Mon, 05 Mar 2007 09:24:54 -0500 Received: from web52701.mail.yahoo.com ([206.190.48.224]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOE7N-0003qk-Bm for speechsc@ietf.org; Mon, 05 Mar 2007 09:24:54 -0500 Received: (qmail 97504 invoked by uid 60001); 5 Mar 2007 14:24:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Oxe8ujKb9CnBN2Ega1/fWrwhFWXlfDAaOEZUoE+fd/CCvdFKo2hFYWxzHTR8tK3n4A4Y9aj/EblE3ejPisgyI+rc+Eb9wOK/6aFcBfHPn8zcZDbn+p88yDEpmnolvNrIgFl2mbh2D6zs15G8f7q5B1r41Ix7YCtqAfabVrbhqcU=; X-YMail-OSG: cAP_iBUVM1m86KAJ3BUfEBjaHtK0ivA4LlNIPgUjcje.JHmZTs4OqOvAuSst8zZqWjllMY_vBL2qKj39tpZh2ET9B3xm55yrFQBd1ipUlJW3CWL920xKTkXL7gE2IaH6NtMd3tWZyt01OqbpjxPXP5cMgw-- Received: from [195.69.162.137] by web52701.mail.yahoo.com via HTTP; Mon, 05 Mar 2007 06:24:42 PST X-Mailer: YahooMailRC/468.1 YahooMailWebService/0.6.132.8 Date: Mon, 5 Mar 2007 06:24:42 -0800 (PST) From: Arsen Chaloyan To: speechsc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <418214.96867.qm@web52701.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Speechsc] MRCP v2, section 8.10. RESUME 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: , Errors-To: speechsc-bounces@ietf.org Snip from the specification (section 8.10. RESUME)=0A=0AIf a "SPEAK" reques= t was active the server MUST return an active-request-id-list header with t= he request-id of the "SPEAK" request that was resumed.=0A=0AI guess, "was a= ctive"should be replaced with "was paused" =0A=0AIf a "SPEAK" request was = paused the server MUST return an=0Aactive-request-id-list header with the r= equest-id of the "SPEAK"=0Arequest that was resumed.=0A=0A=0A=0AThanks,=0AA= rsen.=0A=0A=0A=0A=0A=0A =0A________________________________________________= ____________________________________=0ANeed Mail bonding?=0AGo to the Yahoo= ! Mail Q&A for great tips from Yahoo! Answers users.=0Ahttp://answers.yahoo= .com/dir/?link=3Dlist&sid=3D396546091 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Mar 05 09:40:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEMF-0004rR-KJ; Mon, 05 Mar 2007 09:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEME-0004lO-3D for speechsc@ietf.org; Mon, 05 Mar 2007 09:40:10 -0500 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEMC-0000RK-Rh for speechsc@ietf.org; Mon, 05 Mar 2007 09:40:10 -0500 Received: from unknown (HELO bn-exchbh2.nuance.com) ([10.1.4.197]) by mx2.nuance.com with ESMTP; 05 Mar 2007 09:39:57 -0500 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,250,1170651600"; d="scan'208"; a="46963885:sNHT34321385" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh2.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 09:40:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] MRCP v2, section 8.10. RESUME Date: Mon, 5 Mar 2007 09:40:00 -0500 Message-ID: <2AB5541EB33172459EE430FFB66B1EE90323B1C0@BN-EXCH01.nuance.com> In-Reply-To: <418214.96867.qm@web52701.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] MRCP v2, section 8.10. RESUME Thread-Index: AcdfMmURUIxZZGncQyypoPYZl3rCjgAAaUAw From: "Daniel C. Burnett" To: "Arsen Chaloyan" , X-OriginalArrivalTime: 05 Mar 2007 14:40:02.0484 (UTC) FILETIME=[2871E740:01C75F34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: speechsc-bounces@ietf.org Good catch. It won't make it into draft -12, unfortunately, since I just sent that. I'll mark it for editorial correction the next time I rev the document. Dan Burnett -----Original Message----- From: Arsen Chaloyan [mailto:achaloyan@yahoo.com]=20 Sent: Monday, March 05, 2007 9:25 AM To: speechsc@ietf.org Subject: [Speechsc] MRCP v2, section 8.10. RESUME Snip from the specification (section 8.10. RESUME) If a "SPEAK" request was active the server MUST return an active-request-id-list header with the request-id of the "SPEAK" request that was resumed. I guess, "was active"should be replaced with "was paused" =20 If a "SPEAK" request was paused the server MUST return an active-request-id-list header with the request-id of the "SPEAK" request that was resumed. Thanks, Arsen. =20 ________________________________________________________________________ ____________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=3Dlist&sid=3D396546091 _______________________________________________ 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 Mon Mar 05 09:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEUa-0002Nf-68; Mon, 05 Mar 2007 09:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEUY-0002Kl-9l for speechsc@ietf.org; Mon, 05 Mar 2007 09:48:46 -0500 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEUT-0003P5-Te for speechsc@ietf.org; Mon, 05 Mar 2007 09:48:46 -0500 Received: from unknown (HELO bn-exchbh1.nuance.com) ([10.1.4.190]) by mx2.nuance.com with ESMTP; 05 Mar 2007 09:48:38 -0500 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,251,1170651600"; d="scan'208"; a="46966523:sNHT48182974" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh1.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 09:48:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Whitespace in ABNF Date: Mon, 5 Mar 2007 09:48:40 -0500 Message-ID: <2AB5541EB33172459EE430FFB66B1EE90323B24F@BN-EXCH01.nuance.com> In-Reply-To: <003601c75ab2$5a570780$1300a8c0@Codalogic> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] Whitespace in ABNF Thread-Index: Acdave96NLQsWHX3Sami4DclbE5dPAEduqig From: "Daniel C. Burnett" To: "Pete Cordell" , X-OriginalArrivalTime: 05 Mar 2007 14:48:43.0045 (UTC) FILETIME=[5EB93550:01C75F35] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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: , Errors-To: speechsc-bounces@ietf.org Pete, There is no implicit whitespace, or at least there shouldn't be. Where no whitespace is listed as being permitted, it's not permitted. However, I agree with you that the permitted use of whitespace is inconsistent across headers. At this point I would prefer to leave them as-is unless we get complaints from the IESG or unless they cause insurmountable implementation issues. Thanks, Dan Burnett -----Original Message----- From: Pete Cordell [mailto:pete@tech-know-ware.com]=20 Sent: Tuesday, February 27, 2007 4:01 PM To: speechsc@ietf.org Subject: [Speechsc] Whitespace in ABNF I must admit I've only scanned SPEECHSC, but one thing I noticed with the=20 ABNF is that some times the white space seems implicit, and some times it=20 seems explicit. For example: portlist =3D portnum *("," *LWS portnum) seems explicit about mentioning where whitespace is allowed, whereas: cookie2 =3D attribute "=3D" value *(";" cookie-av2) (in the same section) presumably allows implied whitespace. Also, content-encoding =3D "Content-Encoding" ":" *WSP content-coding *(*WSP "," *WSP content-coding *WSP ) CRLF and: cache-control =3D "Cache-Control" ":" [*WSP cache-directive *( *WSP "," *WSP cache-directive *WSP )] CRLF seem quite explicit about whitespace (btw - should the WSPs be LWSs?), but: active-request-id-list =3D "Active-Request-Id-List" ":" request-id *("," request-id) CRLF seems implicit. If you're polishing up the text, would it be worth doing the same to the ABNF? Also, while I found text that said leading and trailing whitespace in field=20 content could be removed, and intervening whitespace collapsed, I didn't find anything that said LWS can go between any token (although I might have=20 missed it). Regards, Pete. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ----- Original Message -----=20 From: "Eric Burger" To: Sent: Monday, February 26, 2007 3:45 AM Subject: [Speechsc] MRCPv2 Status > You may be wondering why we've gone silent for a few months. In=20 > preparation > of the IESG Shepherding write-up, quite a few typographical errors, many=20 > of > which had protocol implications, were found. There were enough to the > point > where it was clear that the document would never pass IESG muster. > > In addition, many, many, many protocol elements were listed as SHOULD's. > Upon close examination, many are really MUST's, and a bunch are MAY's. > This > is a very important distinction in that interoperability of protocols tend > to be directly proportional to the ratio of MUST:SHOULD. That is, the > fewer > SHOULDs, the more interoperable the protocol is. > > The litmus test is that every SHOULD clause has to have an UNLESS clause > that explains why the clause is a SHOUD and not a MUST (or MAY). A > construction that ends up "A MRCPv2 server SHOULD do foo unless it does=20 > not > fell like it" really means that foo is a MAY. Likewise, "A MRCPv2 client > SHOULD do bar," where there is no clear reason bar should ever not be=20 > done, > really means that bar is a MUST. > > The editors are going through a final scrubbing of the document and will=20 > be > producing a new draft before the Prague draft deadline. We will do=20 > another > Work Group Last Call (WGLC) on that document before redoing the IESG > Shepherd document and passing it to the IESG. > > As before, we will NOT entertain WGLC comments that will extend the > protocol. We will save that for work group re-chartering, if that is what > the IESG and work group wishes to do at that time. > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > _______________________________________________ > 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 Fri Mar 09 04:04:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb1C-0000OF-GK; Fri, 09 Mar 2007 04:04:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZJ-0007A0-QM; Thu, 08 Mar 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZJ-00025F-5y; Thu, 08 Mar 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1D43A2AD00; Thu, 8 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYo-0007Fd-RY; Thu, 08 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-12.txt 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: , Errors-To: speechsc-bounces@ietf.org --NextPart 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 : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : D. Burnett, S. Shanmugham Filename : draft-ietf-speechsc-mrcpv2-12.txt Pages : 206 Date : 2007-3-8 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-12.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-mrcpv2-12.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-mrcpv2-12.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 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8112755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-mrcpv2-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8112755.I-D@ietf.org> --OtherAccess-- --NextPart 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-- From speechsc-bounces@ietf.org Fri Mar 09 07:06:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPdrw-0001L6-Rc; Fri, 09 Mar 2007 07:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPdrv-0001L1-I5 for speechsc@ietf.org; Fri, 09 Mar 2007 07:06:43 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPdrt-0005xP-Uw for speechsc@ietf.org; Fri, 09 Mar 2007 07:06:43 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEM009UHXLVPB@szxga03-in.huawei.com> for speechsc@ietf.org; Fri, 09 Mar 2007 20:05:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JEM00HVFXLU93@szxga03-in.huawei.com> for speechsc@ietf.org; Fri, 09 Mar 2007 20:05:55 +0800 (CST) Received: from HTIPL20760 ([10.18.4.165]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JEM00J7OXLSUP@szxml03-in.huawei.com> for speechsc@ietf.org; Fri, 09 Mar 2007 20:05:54 +0800 (CST) Date: Fri, 09 Mar 2007 17:35:49 +0530 From: sreekanth To: Pete Cordell Message-id: <003401c76243$47dfd210$a504120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: speechsc@ietf.org, "Saravanan Shanmugham \(sarvi\)" Subject: [Speechsc] Query in the Handling of List Type headers X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sreekanth List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1520876786==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1520876786== Content-type: multipart/alternative; boundary="Boundary_(ID_p4h+6efLeXNbFyaU0AS1zg)" This is a multi-part message in MIME format. --Boundary_(ID_p4h+6efLeXNbFyaU0AS1zg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi , The section 6.2. Generic Message Headers of the draft explains the handling of List type headers.. Multiple headers with the same name MAY be present in a message if and only if the entire value for that header is defined as a comma-separated list [i.e., #(values)]. There are some headers like Lexicon-Search-Order, Vendor-Specific-Parameters, Voice-Name which are Non-Singleton or List type headers, but are not COMMA seperated.. Is it correct for the MRCP implementation to send message with Multiple Lexicon-Search-Order headers?? Pls clarify on this.. Thanking you in advance.. Sreekanth This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_p4h+6efLeXNbFyaU0AS1zg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi ,
 
The section 6.2. Generic Message Headers of the draft explains the handling of List type headers..

Multiple headers with the same name MAY be present in a message if and only if the entire value for that header is defined as a comma-separated list [i.e., #(values)].

There are some headers like Lexicon-Search-Order, Vendor-Specific-Parameters, Voice-Name which are Non-Singleton or List type headers, but are not COMMA seperated..

Is it correct for the MRCP implementation to send message with Multiple Lexicon-Search-Order headers??

Pls clarify on this..

Thanking you in advance..

Sreekanth

 

 

 
 
 
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 
 
--Boundary_(ID_p4h+6efLeXNbFyaU0AS1zg)-- --===============1520876786== 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 --===============1520876786==-- From speechsc-bounces@ietf.org Fri Mar 09 08:59:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPfd6-0004sN-LB; Fri, 09 Mar 2007 08:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPfd3-0004p8-VQ for speechsc@ietf.org; Fri, 09 Mar 2007 08:59:29 -0500 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPfc9-0004Zj-FI for speechsc@ietf.org; Fri, 09 Mar 2007 08:58:34 -0500 Received: from unknown (HELO bn-exchbh2.nuance.com) ([10.1.4.197]) by mx2.nuance.com with ESMTP; 09 Mar 2007 08:58:33 -0500 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,267,1170651600"; d="scan'208,217"; a="48024447:sNHT78296477" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh2.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 08:58:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Mar 2007 08:58:31 -0500 Message-ID: <2AB5541EB33172459EE430FFB66B1EE9034BD7E7@BN-EXCH01.nuance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: difference list coming Thread-Index: AcdiUwVmnhtvVL6JSmC3SA8e6KyzHA== From: "Daniel C. Burnett" To: X-OriginalArrivalTime: 09 Mar 2007 13:58:36.0675 (UTC) FILETIME=[08708D30:01C76253] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Speechsc] difference list coming 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="===============0954938692==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0954938692== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76253.083B20B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76253.083B20B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday I sent to this list a list of differences between -11 and -12, but it was long enough that the IETF mailer put it on hold until it's approved by the moderator. It should appear on the list whenever the moderator approves it. =20 If for some reason it is still not on the list by next Wednesday, I will re-send in a compressed (Zipped) format. =20 -- dan =20 ------_=_NextPart_001_01C76253.083B20B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On Wednesday I sent to this list a list of = differences between -11 and -12, but it was long enough that the IETF mailer put it = on hold until it’s approved by the moderator.  It should appear on = the list whenever the moderator approves it.

 

If for some reason it is still not on the list by = next Wednesday, I will re-send in a compressed (Zipped) = format.

 

-- dan

 

------_=_NextPart_001_01C76253.083B20B8-- --===============0954938692== 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 --===============0954938692==-- From speechsc-bounces@ietf.org Sun Mar 11 19:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfy-000877-0N; Sun, 11 Mar 2007 19:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfw-00086x-OG for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:04 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXfv-0005jX-AD for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:04 -0400 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfx43009891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Mar 2007 16:42:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfwlr020187; Sun, 11 Mar 2007 15:41:58 -0800 Received: from 172.24.28.185 ([172.24.28.185]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2007 23:41:58 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Mar 2007 09:41:29 -0400 Subject: Re: [Speechsc] MRCP v2, section 8.10. RESUME From: Eric Burger To: Daniel Burnett , Message-ID: Thread-Topic: [Speechsc] MRCP v2, section 8.10. RESUME Thread-Index: AcdfMmURUIxZZGncQyypoPYZl3rCjgAAaUAwAMtXV4I= In-Reply-To: <2AB5541EB33172459EE430FFB66B1EE90323B1C0@BN-EXCH01.nuance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: speechsc-bounces@ietf.org Right now the plan is not to do a -13, but to submit RFC Editor notes. For example, here we would just tell the RFC Editor to fix the wording for us. On 3/5/07 8:40 AM, "Daniel C. Burnett" wrote: > Good catch. It won't make it into draft -12, unfortunately, since I > just sent that. I'll mark it for editorial correction the next time I > rev the document. > > Dan Burnett > > -----Original Message----- > From: Arsen Chaloyan [mailto:achaloyan@yahoo.com] > Sent: Monday, March 05, 2007 9:25 AM > To: speechsc@ietf.org > Subject: [Speechsc] MRCP v2, section 8.10. RESUME > > Snip from the specification (section 8.10. RESUME) > > If a "SPEAK" request was active the server MUST return an > active-request-id-list header with the request-id of the "SPEAK" request > that was resumed. > > I guess, "was active"should be replaced with "was paused" > > If a "SPEAK" request was paused the server MUST return an > active-request-id-list header with the request-id of the "SPEAK" > request that was resumed. > > > > Thanks, > Arsen. > > > > > > > ________________________________________________________________________ > ____________ > Need Mail bonding? > Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. > http://answers.yahoo.com/dir/?link=list&sid=396546091 > > _______________________________________________ > 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 _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sun Mar 11 19:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfz-00087u-9F; Sun, 11 Mar 2007 19:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfy-00087R-Ni for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:06 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXfu-0005j7-8K for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:06 -0400 Received: from usremr01.bea.com (usremr01.bea.com [10.160.29.91]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfuP8027644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 11 Mar 2007 16:41:56 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfsFA020182 for ; Sun, 11 Mar 2007 15:41:55 -0800 Received: from 172.24.28.185 ([172.24.28.185]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2007 23:41:54 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Mar 2007 08:47:12 -0400 From: Eric Burger To: "speechsc@ietf.org" Message-ID: Thread-Topic: WGLC MRCPv2-12 Thread-Index: AcdiWdIbELj6rM5NEdu71QAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.7 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Speechsc] WGLC MRCPv2-12 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: , Errors-To: speechsc-bounces@ietf.org Due to the size of the MRCPv2 document (weighing in at 206 pages), and the fact that IETF 68 is in a week, work group last call for MRCPv2 will close on 30 March 2007. Please send your comments to the list. If you read the document and find nothing to comment on, please send that to the list, too. PLEASE pay close attention to the RFC 2119 language (MAY, SHOULD, and MUST). Previous versions had SHOULD for virtually every normative statement. This version moved many of the SHOULD's into MUST's; a few of the SHOULD's into MAY's; and a handful of SHOULD's stayed as SHOULD's, but with clarifying text, explaining the circumstances where it is acceptable to NOT execute the normative statement. ALSO, check section 4.2. This changes the acceptable SDP. As mentioned on the list, the -11 version (and prior) had illegal SDP. The -12 version corrects this. Update your implementations accordingly! If you have an implementation of MRCPv2, please tell us if it is a client or a server (or you have done both), and who you have interoperated with. If disclosing who you interoperated with gives your company conniptions, feel free to say something like "my client interoperated with three different servers." The new text is at: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-12.txt Diffs from -11 to -12 are at: http://www.standardstrack.com/ietf/speechsc/drafts/diff-11-12.pdf http://www.standardstrack.com/ietf/speechsc/drafts/diff-11-12.doc By the way, the supplemental web site has moved to: http://www.standardstrack.com/ietf/speechsc _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sun Mar 11 19:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfy-000877-0N; Sun, 11 Mar 2007 19:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfw-00086x-OG for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:04 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXfv-0005jX-AD for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:04 -0400 Received: from usremr01.bea.com (mailrelay.bea.com [10.160.29.91]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfx43009891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 11 Mar 2007 16:42:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfwlr020187; Sun, 11 Mar 2007 15:41:58 -0800 Received: from 172.24.28.185 ([172.24.28.185]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2007 23:41:58 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Mar 2007 09:41:29 -0400 Subject: Re: [Speechsc] MRCP v2, section 8.10. RESUME From: Eric Burger To: Daniel Burnett , Message-ID: Thread-Topic: [Speechsc] MRCP v2, section 8.10. RESUME Thread-Index: AcdfMmURUIxZZGncQyypoPYZl3rCjgAAaUAwAMtXV4I= In-Reply-To: <2AB5541EB33172459EE430FFB66B1EE90323B1C0@BN-EXCH01.nuance.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: speechsc-bounces@ietf.org Right now the plan is not to do a -13, but to submit RFC Editor notes. For example, here we would just tell the RFC Editor to fix the wording for us. On 3/5/07 8:40 AM, "Daniel C. Burnett" wrote: > Good catch. It won't make it into draft -12, unfortunately, since I > just sent that. I'll mark it for editorial correction the next time I > rev the document. > > Dan Burnett > > -----Original Message----- > From: Arsen Chaloyan [mailto:achaloyan@yahoo.com] > Sent: Monday, March 05, 2007 9:25 AM > To: speechsc@ietf.org > Subject: [Speechsc] MRCP v2, section 8.10. RESUME > > Snip from the specification (section 8.10. RESUME) > > If a "SPEAK" request was active the server MUST return an > active-request-id-list header with the request-id of the "SPEAK" request > that was resumed. > > I guess, "was active"should be replaced with "was paused" > > If a "SPEAK" request was paused the server MUST return an > active-request-id-list header with the request-id of the "SPEAK" > request that was resumed. > > > > Thanks, > Arsen. > > > > > > > ________________________________________________________________________ > ____________ > Need Mail bonding? > Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. > http://answers.yahoo.com/dir/?link=list&sid=396546091 > > _______________________________________________ > 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 _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sun Mar 11 19:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfz-00087u-9F; Sun, 11 Mar 2007 19:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQXfy-00087R-Ni for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:06 -0400 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQXfu-0005j7-8K for speechsc@ietf.org; Sun, 11 Mar 2007 19:42:06 -0400 Received: from usremr01.bea.com (usremr01.bea.com [10.160.29.91]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfuP8027644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 11 Mar 2007 16:41:56 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2BNfsFA020182 for ; Sun, 11 Mar 2007 15:41:55 -0800 Received: from 172.24.28.185 ([172.24.28.185]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 11 Mar 2007 23:41:54 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Mar 2007 08:47:12 -0400 From: Eric Burger To: "speechsc@ietf.org" Message-ID: Thread-Topic: WGLC MRCPv2-12 Thread-Index: AcdiWdIbELj6rM5NEdu71QAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.161433 X-Spam-Score: 0.7 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Speechsc] WGLC MRCPv2-12 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: , Errors-To: speechsc-bounces@ietf.org Due to the size of the MRCPv2 document (weighing in at 206 pages), and the fact that IETF 68 is in a week, work group last call for MRCPv2 will close on 30 March 2007. Please send your comments to the list. If you read the document and find nothing to comment on, please send that to the list, too. PLEASE pay close attention to the RFC 2119 language (MAY, SHOULD, and MUST). Previous versions had SHOULD for virtually every normative statement. This version moved many of the SHOULD's into MUST's; a few of the SHOULD's into MAY's; and a handful of SHOULD's stayed as SHOULD's, but with clarifying text, explaining the circumstances where it is acceptable to NOT execute the normative statement. ALSO, check section 4.2. This changes the acceptable SDP. As mentioned on the list, the -11 version (and prior) had illegal SDP. The -12 version corrects this. Update your implementations accordingly! If you have an implementation of MRCPv2, please tell us if it is a client or a server (or you have done both), and who you have interoperated with. If disclosing who you interoperated with gives your company conniptions, feel free to say something like "my client interoperated with three different servers." The new text is at: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-12.txt Diffs from -11 to -12 are at: http://www.standardstrack.com/ietf/speechsc/drafts/diff-11-12.pdf http://www.standardstrack.com/ietf/speechsc/drafts/diff-11-12.doc By the way, the supplemental web site has moved to: http://www.standardstrack.com/ietf/speechsc _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Mar 12 01:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQcxt-0000RQ-JM; Mon, 12 Mar 2007 01:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQcxr-0000RF-KG for speechsc@ietf.org; Mon, 12 Mar 2007 01:20:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQcxq-0002IA-0Y for speechsc@ietf.org; Mon, 12 Mar 2007 01:20:55 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JER004NUYPF0J@szxga03-in.huawei.com> for speechsc@ietf.org; Mon, 12 Mar 2007 13:17:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JER00227YPF4B@szxga03-in.huawei.com> for speechsc@ietf.org; Mon, 12 Mar 2007 13:17:39 +0800 (CST) Received: from HTIPL20760 ([10.18.4.165]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JER00295YPC1G@szxml04-in.huawei.com> for speechsc@ietf.org; Mon, 12 Mar 2007 13:17:39 +0800 (CST) Date: Mon, 12 Mar 2007 10:47:34 +0530 From: sreekanth To: Pete Cordell Message-id: <001b01c76465$bf111230$a504120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: speechsc@ietf.org, "Saravanan Shanmugham \(sarvi\)" Subject: [Speechsc] Re: Query in the Handling of List Type headers X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sreekanth List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0437927430==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0437927430== Content-type: multipart/alternative; boundary="Boundary_(ID_EIvkTkj50zTC71QjEBBCXQ)" This is a multi-part message in MIME format. --Boundary_(ID_EIvkTkj50zTC71QjEBBCXQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi , I am resending the same mail which has been posted before after removing the boilerplate at the end.. Pls consider this and reply. The section 6.2. Generic Message Headers of the draft explains the handling of List type headers.. Multiple headers with the same name MAY be present in a message if and only if the entire value for that header is defined as a comma-separated list [i.e., #(values)]. There are some headers like Lexicon-Search-Order, Vendor-Specific-Parameters, Voice-Name which are Non-Singleton or List type headers, but are not COMMA seperated.. Is it correct for the MRCP implementation to send message with Multiple Lexicon-Search-Order headers?? Pls clarify on this.. Thanking you in advance.. Sreekanth --Boundary_(ID_EIvkTkj50zTC71QjEBBCXQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi ,
 
I am resending the same mail which has been posted before after removing the boilerplate at the end.. Pls consider this and reply.
 
 
The section 6.2. Generic Message Headers of the draft explains the handling of List type headers..

Multiple headers with the same name MAY be present in a message if and only if the entire value for that header is defined as a comma-separated list [i.e., #(values)].

There are some headers like Lexicon-Search-Order, Vendor-Specific-Parameters, Voice-Name which are Non-Singleton or List type headers, but are not COMMA seperated..

Is it correct for the MRCP implementation to send message with Multiple Lexicon-Search-Order headers??

Pls clarify on this..

Thanking you in advance..

Sreekanth

 
 
 
 
 
--Boundary_(ID_EIvkTkj50zTC71QjEBBCXQ)-- --===============0437927430== 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 --===============0437927430==-- From speechsc-bounces@ietf.org Wed Mar 14 08:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSr2-0008Px-V0; Wed, 14 Mar 2007 08:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSr1-0008Pb-VN for speechsc@ietf.org; Wed, 14 Mar 2007 08:45:19 -0400 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRSr0-0002O7-Fk for speechsc@ietf.org; Wed, 14 Mar 2007 08:45:19 -0400 Received: from unknown (HELO bn-exchbh1.nuance.com) ([10.1.4.190]) by mx2.nuance.com with ESMTP; 14 Mar 2007 08:45:16 -0400 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,283,1170651600"; d="scan'208,217"; a="49127798:sNHT62684720" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh1.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 08:45:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] Re: Query in the Handling of List Type headers Date: Wed, 14 Mar 2007 08:45:14 -0400 Message-ID: <2AB5541EB33172459EE430FFB66B1EE90368E70D@BN-EXCH01.nuance.com> In-Reply-To: <001b01c76465$bf111230$a504120a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] Re: Query in the Handling of List Type headers Thread-Index: AcdkZop/HJzQ+0r1TBGlqKYKwuXL2wBz6q9A From: "Daniel C. Burnett" To: "sreekanth" X-OriginalArrivalTime: 14 Mar 2007 12:45:15.0992 (UTC) FILETIME=[9D7E5D80:01C76636] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0089389156==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0089389156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76636.9C3EA7EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76636.9C3EA7EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As you point out, the specification only permits multiple copies of the header if the value for the header is a comma-separated list, so the answer is no - it is not legal to have multiple Lexicon-Search-Order headers. In a future version of MRCP it may be worthwhile to make the behavior (and possibly syntax) of all list-valued headers consistent. =20 -- dan =20 ________________________________ From: sreekanth [mailto:sreekanthm@huawei.com]=20 Sent: Monday, March 12, 2007 1:18 AM To: Pete Cordell Cc: speechsc@ietf.org; Saravanan Shanmugham (sarvi) Subject: [Speechsc] Re: Query in the Handling of List Type headers =20 Hi , =20 I am resending the same mail which has been posted before after removing the boilerplate at the end.. Pls consider this and reply. =20 =20 The section 6.2. Generic Message Headers of the draft explains the handling of List type headers.. Multiple headers with the same name MAY be present in a message if and only if the entire value for that header is defined as a comma-separated list [i.e., #(values)]. There are some headers like Lexicon-Search-Order, Vendor-Specific-Parameters, Voice-Name which are Non-Singleton or List type headers, but are not COMMA seperated.. Is it correct for the MRCP implementation to send message with Multiple Lexicon-Search-Order headers?? Pls clarify on this.. Thanking you in advance.. Sreekanth =20 =20 =20 =20 =20 ------_=_NextPart_001_01C76636.9C3EA7EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As you point out, the specification = only permits multiple copies of the header if the value for the header is a comma-separated list, so the answer is no – it is not legal to = have multiple Lexicon-Search-Order headers.

In a future version of MRCP it may = be worthwhile to make the behavior (and possibly syntax) of all list-valued headers consistent.

 

-- dan

 

From: = sreekanth [mailto:sreekanthm@huawei.com]
Sent: Monday, March 12, = 2007 1:18 AM
To: Pete Cordell
Cc: speechsc@ietf.org; = Saravanan Shanmugham (sarvi)
Subject: [Speechsc] Re: = Query in the Handling of List Type headers

 

Hi ,

 

I am resending the same mail which has been posted = before after removing the boilerplate at the end.. Pls consider this and = reply.

 

 

The section 6.2. Generic Message = Headers of the draft explains = the handling of List type headers..

Multiple headers with the same name MAY be present in a message if and only if = the entire value for that header is defined as a comma-separated list [i.e., #(values)].

There are some headers like Lexicon-Search-Order, Vendor-Specific-Parameters, = Voice-Name which are Non-Singleton or List type headers, but are not COMMA = seperated..

Is it correct for the MRCP implementation to send message with Multiple Lexicon-Search-Order headers??

Pls clarify on this..

Thanking you in advance..

Sreekanth<= /font>

 

 

 

 

 

------_=_NextPart_001_01C76636.9C3EA7EC-- --===============0089389156== 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 --===============0089389156==-- From speechsc-bounces@ietf.org Wed Mar 14 09:03:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRT8C-00022Y-OD; Wed, 14 Mar 2007 09:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRT1p-0006Vh-P7 for speechsc@ietf.org; Wed, 14 Mar 2007 08:56:29 -0400 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRT1l-0004JF-J9 for speechsc@ietf.org; Wed, 14 Mar 2007 08:56:29 -0400 Received: from unknown (HELO bn-exchbh2.nuance.com) ([10.1.4.197]) by mx2.nuance.com with ESMTP; 14 Mar 2007 08:56:25 -0400 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,283,1170651600"; d="scan'208,217"; a="49129301:sNHT121133992" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh2.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 08:56:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Mar 2007 08:56:23 -0400 Message-ID: <2AB5541EB33172459EE430FFB66B1EE90368E78C@BN-EXCH01.nuance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: change list for forthcoming draft -12 Thread-Index: AcdgXhJZY/zN034KTquk0Krp6vxpjAF2gkaA From: "Daniel C. Burnett" To: X-OriginalArrivalTime: 14 Mar 2007 12:56:25.0003 (UTC) FILETIME=[2C4157B0:01C76638] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2395cfc0572e9e3ffde8fd30fbc4b33e X-Mailman-Approved-At: Wed, 14 Mar 2007 09:03:01 -0400 Subject: [Speechsc] FW: change list for forthcoming draft -12 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="===============0974631798==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0974631798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76638.2C35A96E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76638.2C35A96E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending. =20 ________________________________ From: Daniel C. Burnett=20 Sent: Tuesday, March 06, 2007 9:13 PM To: speechsc@ietf.org Subject: change list for forthcoming draft -12 =20 Group, =20 I've sent in draft -12 for publication. It should be published sometime this week. This is the list of changes since draft -11. There were also some minor editorial fixes (typos, formatting) that are not listed below. =20 -- Dan Burnett =20 =20 6.2.9: "Content encoding is defined . . ." -> "Content-coding is defined . . ." 6.2.11: "It is interpreted . . ." -> "Otherwise, it is interpreted . . ." 6.2.11: Appended this to the end of the section: " When a message having no use for a message body contains one, i.e. the Content-Length is non-zero, the receiver MAY ignore the content of the message body." =20 4.2: Changed "The format field of the m-line is not used and MUST be left empty." to 'The format field of the m-line is not used by this protocol. However, to enable proper generic SDP parsing, it MUST have the arbitrarily-selected value of "1".' =20 Changed all MRCPv2 m-lines in the document to include a format value of "1". =20 Replaced all instances of '126.16.64.4' with '192.168.64.4'. Replaced all instances of '224.2.17.12' with '10.2.17.12' in the client and '10.2.17.11' in the server. =20 Changed channel-id production from '1*HEXDIG "@" 1*VCHAR' to '1*VCHAR "@" 1*VCHAR' to match what we decided when we changed the text in section 6.2.1. Also removed word "hexadecimal" from section 4.2. =20 10.1: Added START-INPUT-TIMERS to state machine. =20 10.5: Replaced 'The "STOP" response or the RECORD-COMPLETE event MAY contain a message body carrying the captured audio. This happens if the RECORD request did not have a Record-Uri header.' =20 with=20 =20 'If the RECORD request did not have a Record-Uri header, the "STOP" response or the RECORD-COMPLETE event MUST contain a message body carrying the captured audio.' =20 10.6: Replaced "The audio is then made available to the client as specified by Record-URI." =20 with =20 "The audio is then made available to the client either in the message body or as specified by Record-URI." =20 10.6: Added "If the type specified in the Media-Type header is not supported, the server MUST respond with a status code of 409, "Unsupported Header Value", with the Media-Type header in its response." =20 10.10: Added "The recorder resource also MUST send a proxy-sync-id header with a unique value for this event." and added the header to the associated example. =20 =20 =20 In addition, I reviewed every "should" or "SHOULD" in the document and have made the following changes: =20 3.1: Speech Synthesizer A full capability speech synthesis resource capable of rendering speech from text. Such a synthesizer SHOULD have full SSML [25] support. (MUST) =20 Recorder A resource capable of recording audio and saving it to a URI. A recorder SHOULD provide some end-pointing capabilities for suppressing silence at the beginning and end of a recording, and MAY also suppress silence in the middle of a recording. (SHOULD->MUST) =20 4.2: All servers MUST support TLS, SHOULD support TCP without TLS, and MAY support SCTP. (reword: "All servers MUST support TLS. Servers MAY support TCP without TLS in physically secure environments.") =20 4.4: All MRCPv2 servers MUST support TLS, SHOULD support TCP and MAY support SCTP. (reword: "All servers MUST support TLS. Servers MAY support TCP without TLS in physically secure environments.") =20 5.2: If the server receives duplicate or out-of-order requests the server should reject the request with a response code of XXX. (MUST; XXX->410) =20 6.1.1: If one or more of the headers being set has an unsupported value, the server SHOULD reject the request with a 409 Unsupported Header Value, except as described in the next paragraph. (MUST) =20 6.1.2: The "GET-PARAMS" method, from the client to the server, asks the MRCPv2 resource for its current session parameters, such as voice characteristics and prosody on synthesizers, recognition-timer on recognizers, etc. The client SHOULD indicate the list of parameters it wants to read from the server by sending a set of empty header fields. (reword: "... recognizers, etc. For every empty header field the client sends in the request, the server MUST include the corresponding headers and their values in the response.") =20 6.1.2: If no parameter headers are specified by the client then the server SHOULD return all the settable parameters and their values in the corresponding headers of the response, including vendor-specific parameters. (MUST) =20 6.2.2: The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value that is specific to the resource type that is being controlled. (MUST) =20 6.2.3: In a request, this header indicates the list of request-ids that the request should apply to. (reword: "... list of request-ids to which the request applies.") =20 6.2.3: In the case of such terminated requests, the server SHOULD NOT send any "SPEAK"-COMPLETE or RECOGNITION-COMPLETE events. (reword: "After sending the STOP response, the server MUST NOT send any SPEAK-COMPLETE or RECOGNITION-COMPLETE events for the terminated requests.") =20 6.2.10: The server MAY use this header to optimize certain operations. When providing this header the entity being sent should not have been modified from what was retrieved from the content- location URI. (reword: "This header is provided for optimization purposes only. The receiver of this header MAY assume that the entity being sent is identical to what would have been retrieved or might already have been retrieved from the content-location URI.") =20 6.2.14: The MRCPv2 server SHOULD provide a mechanism to subset its output logs so that system administrators can examine or extract only the log file portion during which the logging tag was set to a certain value. (MAY) =20 6.2.15: The MRCPv2 client should be able to push its stored cookies to the MRCPv2 server and get new cookies that the MRCPv2 server stored back to the MRCPv2 client. (reword: "To enable the MRCPv2 client to push its stored cookies to the MRCPv2 server and get new cookies from the MRCPv2 server stored back to the MRCPv2 client, ") - connects with following sentence. =20 6.2.15: Since the type of cookie header is dictated by the HTTP origin server, MRCPv2 clients and servers SHOULD support both the set-cookie and set-cookie2 entity header fields. (reword: "To ensure support for the type of cookie header dictated by the HTTP origin server, MRCPv2 clients and servers MUST support both the set-cookie and set-cookie2 entity header fields.") =20 6.2.15: An MRCPv2 client or server SHOULD calculate the age of the cookie according to the age calculation rules in the HTTP/1.1 specification [6] and append the "Age" attribute accordingly. (MUST) =20 7: Server resources may be discovered and their capabilities learned by clients through standard SIP machinery. The client can issue a SIP OPTIONS transaction to a server, which has the effect of requesting the capabilities of the server. The server SHOULD respond to such a request with an SDP-encoded description of its capabilities according to RFC3264 [7]. (MUST) =20 7: There should be one "resource" attribute for each media resource that the server supports with the resource type identifier as its value. =20 (MUST) =20 8.4.1: This header MAY also be specified in a "SPEAK" request to indicate an offset into the speech markup that the "SPEAK" request should start speaking from. (reword: "This header MAY also be specified in a "SPEAK" request as a desired offset into the synthesized speech. In this case, the synthesizer MUST begin speaking from this amount of time into the speech markup. Note that an offset that extends beyond the end of the produced speech will result in audio of length zero.") =20 8.4.1: If the synthesizer resource does not support a unit or the operation, the resource SHOULD respond with a status code of 409 "Unsupported Header Value". (MUST) =20 8.4.2: If the recognizer or signal detector resource is on the same server as the synthesizer and are part of the same session, the server SHOULD work with both to provide kill-on-barge-in support. (remove paragraph and, after the next paragraph, add "If the recognizer or signal detector resource is on the same server as the synthesizer and both are part of the same session, the server MAY work with both to provide internal notification to the synthesizer so that audio may be stopped without having to wait for the client's BARGE-IN-OCCURRED event.") =20 8.4.2: If this header is not specified in a "SPEAK" request or explicitly set by a "SET-PARAMS", the server SHOULD default to "true". (reword: '..., the default value for this header is "true".') =20 8.4.5: Clients SHOULD NOT interpret the completion reason text. Instead it is RECOMMENDED that the reason be recorded in client logs and otherwise made available for debugging and instrumentation purposes. (reword: "The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients are NOT REQUIRED to interpret the completion reason text.") =20 8.4.6: If the synthesizer resource does not support this operation, it SHOULD reject the request with a status of "Unsupported". (reword: '... MUST reject the request with a status of 403 "Unsupported Header".') =20 8.4.7: If the synthesizer resource does not support this operation, it should respond back to the client with a status of unsupported. (reword: "... MUST respond back to the client with a status of 403 "Unsupported Header".') =20 8.4.8: This header SHOULD be part of the SPEECH-MARKER event and contain the marker tag value. (MUST) =20 8.4.8: This header SHOULD also be returned in responses to STOP, CONTROL, and BARGE-IN-OCCURRED methods, in the "SPEAK-COMPLETE" event, and in an IN-PROGRESS SPEAK response. (MUST) =20 8.4.8: In these messages the marker tag SHOULD be the last embedded marker encountered or a null string if no marker has yet been encountered. (MUST) =20 8.4.10: A value of "prefetch" indicates the content may be downloaded when the request is received, whereas "safe" indicates that content should only be downloaded when actually referenced. (reword: 'A value of "prefetch" indicates the content MAY be downloaded when the request is received, whereas "safe" indicates that content MUST NOT be downloaded until actually referenced.') =20 8.4.12: When a synthesizer method needs a synthesizer to fetch or access a URI and the access fails, the server SHOULD provide the failed URI in this header in the method response. (add "unless there are multiple URI failures, in which case one of the failed URIs MUST be provided in this header in the method response.") =20 8.4.13: When a synthesizer method needs a synthesizer to fetch or access a URI and the access fails the server SHOULD provide the URI specific or protocol specific response code in the method response through this header. (MUST. Also change "response code" to "response code for the URI in the Failed-URI header".) =20 8.4.14: When a CONTROL request to jump backward is issued to a currently speaking synthesizer resource, and the target jump point is before the start of the current "SPEAK" request, the current "SPEAK" request MUST restart from the beginning of its speech data and the response to the CONTROL request SHOULD contain this header indicating a restart. (MUST) =20 8.4.15: If a server does not support the specified unit, the resource SHOULD respond with a status code of 409 "Unsupported Header Value". (MUST) =20 8.6: If caching is implemented, this URI fetching MUST conform to the cache control hints and parameter headers associated with the method in deciding whether it should be fetched from cache or from the external server. (should -> "is to") =20 8.8: If a "SPEAK" request is active with kill-on-barge-in enabled, and the BARGE-IN-OCCURRED event is received, the synthesizer SHOULD immediately stop streaming out audio. (MUST) =20 8.9: If a PAUSE method is issued on a session when a "SPEAK" is not active the server SHOULD respond with a status of 402 "Method not valid in this state". (MUST) =20 8.9: If a PAUSE method is issued on a session when a "SPEAK" is active and paused the server SHOULD respond with a status of 200 "Success". (MUST) =20 8.10: If a RESUME request is issued on a session with no active "SPEAK" request, the server SHOULD respond with a status of 402 "Method not valid in this state". (MUST) =20 8.10: If a RESUME request is issued on a session with an active "SPEAK" request that is speaking (i.e., not paused) the server SHOULD respond with a status of 200 "Success". (MUST) =20 9: The "speechrecog" resource type can recognize regular speech as well as DTMF digits and hence SHOULD support grammars describing either speech or DTMF. (MUST) =20 9.4.8: Otherwise, the URI generated by the server SHOULD be unambiguous across the server and all its recognition sessions. (MUST) =20 9.4.8: The content associated with the URI SHOULD be available to the client until the MRCPv2 session terminates. (MUST) =20 9.4.8: Otherwise, the URI generated by the server SHOULD be unambiguous across the server and all its recognition sessions. (MUST) =20 9.4.8: The content associated with the URI SHOULD be available to the client until the MRCPv2 session terminates. (MUST) =20 9.4.12: Clients SHOULD NOT interpret the completion reason text. Instead it is RECOMMENDED that the reason be recorded in client logs and otherwise made available for debugging and instrumentation purposes. (reword: "The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients are NOT REQUIRED to interpret the completion reason text.") =20 9.4.13: This Content-ID SHOULD match the Content-ID that came with the context data during the "GET-PARAMS" operation. (MUST) =20 9.4.14: The recognizer should not start the timers until the client sends a START-INPUT-TIMERS request to the recognizer. (MUST NOT) =20 9.4.15: The speech-complete- timeout value applies when the recognizer currently has a complete match against an active grammar, and specifies how long the recognizer should wait for more input before declaring a match. (MUST) =20 9.4.20: When a recognizer needs to fetch or access a URI and the access fails the server SHOULD provide the failed URI in this header in the method response. (add "unless there are multiple URI failures, in which case one of the failed URIs MUST be provided in this header in the method response.") =20 9.4.21: When a recognizer method needs a recognizer to fetch or access a URI and the access fails the server SHOULD provide the URI specific or protocol specific response code through this header in the method response. (MUST. Also change "response code" to "response code for the URI in the Failed-URI header".) =20 9.4.26: This header specifies what mode the RECOGNIZE method should operate in.=20 (should->will) =20 9.4.27: This header specifies what should happen if the client attempts to invoke another RECOGNIZE method when this RECOGNIZE request is already in progress for the resource. (should->will) =20 9.4.28: It specifies the maximum length of an utterance (in seconds) that should be considered for Hotword recognition. (should->will) =20 9.4.29: It specifies the minimum length of an utterance (in seconds) that should be considered for Hotword recognition. (should->will) =20 9.5: When one or more grammars are specified using the DEFINE-GRAMMAR method, the server SHOULD attempt to fetch, compile and optimize the grammar before returning a response to the DEFINE-GRAMMAR method. (MUST) =20 9.5.1: These grammars MAY be in one of the following standard grammar specification formats: o W3C's XML-based Speech Grammar Markup Format (SRGS) [26] o Sun's Java Speech Grammar Format [32] All MRCPv2 servers MUST support the XML form (MIME-type application/ srgs+xml) of SRGS and SHOULD support the ABNF form (MIME-type application/srgs). (Reword: "All MRCPv2 servers MUST accept grammars in the XML form (MIME-type application/ srgs+xml) of the W3C's XML-based Speech Grammar Markup Format (SRGS) [26] and MAY accept grammars in other formats. Examples include but are not limited to: o the ABNF form (MIME-type application/srgs) of SRGS o Sun's Java Speech Grammar Format [32]" ) =20 9.5.4: The Content-ID value should also be specified in the recognizer-context- block header in the "GET-PARAMS" response. (MUST) =20 9.5.4: The "SET-PARAMS" request wishing to provide this vendor-specific data should send it in the message body as a MIME-entity with the same Content-ID that it received from the "GET-PARAMS". (MUST) =20 9.5.4: The Content-ID should also be sent in the recognizer-context-block header of the "SET-PARAMS" message. (MUST) =20 9.5.4: Each speech recognition implementation choosing to use this mechanism to hand off recognizer context data among servers should distinguish its implementation-specific block of data from other implementations by choosing a unique Content-ID that is recognizable among the participating servers and unlikely to collide with values chosen by another implementation. (MUST; also remove "unique".) =20 9.6.3.4 (simple text content): MRCPv2 clients SHOULD be prepared to receive such markup but are not required to act on it. (change to MUST and NOT REQUIRED, respectively) =20 9.9: This means that the recognizer is active and that the client should expect further events with this request-id. ("client MUST be prepared to receive further ...") =20 9.9: The recognizer SHOULD expect the media to start flowing when it receives the recognize request, but SHOULD NOT buffer anything it receives beforehand. (SHOULD -> "can") (SHOULD NOT -> MUST NOT) =20 9.12: The recognizer resource also SHOULD send a proxy-sync-id header with a unique value for this event. (MUST) =20 9.12: This event SHOULD be generated by the server irrespective of whether the synthesizer and recognizer are on the same server or not. (MUST) =20 9.13: If not, the recognizer resource SHOULD NOT start the timers until the client sends a START-INPUT-TIMERS method to the recognizer. (MUST NOT) =20 9.15: If the client has specified Save-Best-Waveform as true, then the response after ending the phrase enrollment session SHOULD contain the location/URI of a recording of the best repetition of the learned phrase. (MUST) =20 9.16: This method should be invoked when the caller provides undesirable input such as non-speech noises, side- speech, commands, utterance from the RECOGNIZE grammar, etc. (reword: "The client can invoke this method when ...") =20 9.17: It should be called when successive calls to RECOGNIZE have succeeded and Num-Repetitions-Still-Needed has been returned as 0 in the RECOGNITION-COMPLETE event to commit the new phrase in the grammar. Alternatively, it can be called by specifying the Abort-Phrase-Enrollment header to abort the phrase enrollment session. (reword: "To commit the new phrase in the grammar, the client MAY call this method once successive calls to RECOGNIZE have succeeded and Num-Repetitions-Still-Needed has been returned as 0 in the RECOGNITION-COMPLETE event. Alternatively, the client can abort the phrase enrollment session by calling this method with the Abort-Phrase-Enrollment header.") =20 9.17: If the client has specified Save-Best-Waveform as true in the START- PHRASE-ENROLLMENT request, then the response SHOULD contain the location/URI of a recording of the best repetition of the learned phrase. (MUST) =20 10: A recorder SHOULD provide some end-pointing capabilities for suppressing silence at the beginning and end of a recording, and MAY also suppress silence in the middle of a recording. If such suppression is done, the recorder MUST maintain timing metadata to indicate the actual time stamps of the recorded media. (MUST) =20 10.4.4: Clients SHOULD NOT interpret the completion reason text. Instead it is RECOMMENDED that the reason be=20 =20 recorded in client logs and otherwise made available for debugging and instrumentation purposes. (reword: "The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients are NOT REQUIRED to interpret the completion reason text.") =20 10.4.5: When a recorder method needs to post the audio to an URI and access to the URI fails, the server SHOULD provide the failed URI in this header in the method response. (MUST) =20 10.4.6: When a recorder method needs to post the audio to an URI and access to the URI fails, the server SHOULD provide the URI specific or protocol specific response code through this header in the method response. (MUST) =20 10.4.12: When recorder is started this header specifies if the recorder should start capturing immediately (false) or wait for the end-pointing functionality to detect speech (true) before it starts capturing. (reword: "If false, the recorder MUST start capturing immediately when started. If true, the recorder MUST wait for the end-pointing functionality to detect speech before it starts capturing.") =20 11.4.3: Acceptable values indicate whether the verification session should train a voiceprint ("train") or verify/identify using an existing voiceprint ("verify"). (should -> will) =20 11.4.7: The verification resource SHOULD NOT declare a verification 'accepted' unless the Num-Min-Verification- Phrases utterances are available.=20 (reword: "... MUST NOT declare a verification 'accepted' unless Num-Min-Verification-Phrases valid utterances have been received.") =20 11.4.12: The URI value of the header MUST be NULL if there was some error condition preventing the server from recording. Otherwise, the URI generated by the server SHOULD be globally unique across the server and all its verification sessions. (MUST) =20 11.4.12: The content SHOULD be available via the URI until the verification session ends.=20 (MUST) =20 11.4.17: Clients SHOULD NOT interpret the completion reason text. Instead it is RECOMMENDED that the reason be recorded in client logs and otherwise made available for debugging and instrumentation purposes. (reword: "The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients are NOT REQUIRED to interpret the completion reason text.") =20 11.4.21: The verification resource SHOULD NOT start the timers until the client sends a START-INPUT- TIMERS request to the resource. (MUST NOT) =20 11.5.2.9: Note that the value of the verification score SHOULD NOT be interpreted as a probability value in the strict statistical sense. (reword: "Note that the verification score is not a probability value.") =20 11.6: By default, the voiceprint model SHOULD NOT be adapted with data from a verification session. (MUST NOT) =20 11.6: The server SHOULD return 402 (Method not valid in this state) for all other operations, such as VERIFY, or QUERY-VOICEPRINT. (reword: 'The server MUST return 402 "Method not valid in this state" for all other verification operations.') =20 11.13: If the header is present and its value is "false", the "STOP" response SHOULD contain a "Completion-Cause" header and carry the Verification result data in its body. (MUST) =20 12.2: To ensure control channel protection, MRCPv2 clients and servers MUST support TLS and SHOULD utilize it by default. (append "unless alternative control channel protection is used") =20 ------_=_NextPart_001_01C76638.2C35A96E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending.<= /p>

 

From: = Daniel C. Burnett
Sent: Tuesday, March 06, = 2007 9:13 PM
To: speechsc@ietf.org
Subject: change list for forthcoming draft -12

 

Group,

 

I've sent in draft -12 for publication.  It = should be published sometime this week.

This is the list of changes since draft -11.  = There were also some minor editorial fixes (typos, formatting) that are not = listed below.

 

-- Dan Burnett

 

 

6.2.9: "Content encoding is defined . . ." = -> "Content-coding is defined . . ."

6.2.11: "It is interpreted . . ." -> "Otherwise, it is interpreted . . = ."

6.2.11: Appended this to the end of the section: = " When a message having no use for a message body contains one, i.e. the Content-Length is non-zero, the receiver MAY ignore the content of the = message body."

 

4.2: Changed "The format field of the m-line is = not used and MUST be left empty."

 to

 'The format field of the m-line is not used by = this protocol.  However, to enable proper generic SDP parsing, it MUST = have the arbitrarily-selected value of = "1".'

 

Changed all MRCPv2 m-lines in the document to include = a format value of "1".

 

Replaced all instances of '126.16.64.4' with = '192.168.64.4'.

Replaced all instances of '224.2.17.12' with = '10.2.17.12' in the client and '10.2.17.11' in the server.

 

Changed channel-id production from '1*HEXDIG = "@" 1*VCHAR' to '1*VCHAR "@" 1*VCHAR' to match what we decided = when we changed the text in section 6.2.1.  Also removed word "hexadecimal" from section 4.2.

 

10.1: Added START-INPUT-TIMERS to state = machine.

 

10.5: Replaced 'The "STOP" response or the RECORD-COMPLETE event MAY contain a message body carrying the captured = audio. This happens if the RECORD request did not have a Record-Uri = header.'

 

with

 

     'If the RECORD request did = not have a Record-Uri header, the "STOP" response or the = RECORD-COMPLETE event MUST contain a message body carrying the captured = audio.'

 

10.6: Replaced "The audio is then made available = to the client as specified by Record-URI."

 

with

 

"The audio is then made available to the client = either in the message body or as specified by = Record-URI."

 

10.6: Added "If the type specified in the = Media-Type header is not supported, the server MUST respond with a status code of = 409, "Unsupported Header Value", with the Media-Type header in its response."

 

10.10: Added "The recorder resource also MUST = send a proxy-sync-id header with a unique value for this event." and added = the header to the associated example.

 

 

 

In addition, I reviewed every "should" or "SHOULD" in the document and have made the following = changes:

 

3.1:

Speech Synthesizer

         =          A full capability speech synthesis resource capable = of

         =          rendering speech from text.  Such a synthesizer = SHOULD

         =          have full SSML [25] support.

(MUST)

 

Recorder

         =          A resource capable of recording audio and saving it = to

         =          a URI.  A recorder SHOULD provide some = end-pointing

         =          capabilities for suppressing silence at the = beginning

         =          and end of a recording, and MAY also suppress = silence

         =          in the middle of a recording.

(SHOULD->MUST)

 

4.2:

All servers MUST support TLS, SHOULD support TCP = without TLS, and MAY support SCTP.

(reword: "All servers MUST support TLS. Servers = MAY support TCP without TLS in physically secure = environments.")

 

4.4:

All MRCPv2 servers MUST support TLS, SHOULD support = TCP and MAY support SCTP.

(reword: "All servers MUST support TLS. Servers = MAY support TCP without TLS in physically secure = environments.")

 

5.2: If the server receives duplicate or out-of-order requests

   the server should reject the request = with a response code of XXX.

(MUST; XXX->410)

 

6.1.1: If one or more of the headers being set has an unsupported value,

      the server SHOULD = reject the request with a 409 Unsupported Header

      Value, except as = described in the next paragraph.

(MUST)

 

6.1.2: The "GET-PARAMS" method, from the = client to the server, asks the

   MRCPv2 resource for its current session parameters, such as voice

   characteristics and prosody on = synthesizers, recognition-timer on

   recognizers, etc.  The client = SHOULD indicate the list of parameters

   it wants to read from the server by = sending a set of empty header

   fields.

(reword: "... recognizers, etc.  For every = empty header field the client sends

in the request, the server MUST include the = corresponding headers and their values

in the response.")

 

6.1.2: If no parameter headers are specified by the = client then the

   server SHOULD return all the settable parameters and their values in

   the corresponding headers of the = response, including vendor-specific

   parameters.

(MUST)

 

6.2.2: The Accept header field follows the syntax = defined in [H14.1].  The

   semantics are also identical, with the exception that if no Accept

   header field is present, the server = SHOULD assume a default value

   that is specific to the resource type = that is being controlled.

(MUST)

 

6.2.3: In a request, this header indicates the list = of request-ids that the

   request should apply = to.

(reword: "... list of request-ids to which the = request applies.")

 

6.2.3: In the case of = such

   terminated requests, the server SHOULD = NOT send any "SPEAK"-COMPLETE

   or RECOGNITION-COMPLETE = events.

(reword: "After sending the STOP response, the = server MUST NOT send any SPEAK-COMPLETE or = RECOGNITION-COMPLETE

 events for the terminated = requests.")

 

6.2.10: The server MAY use this header to optimize = certain

   operations.  When providing this = header the entity being sent should

   not have been modified from what was = retrieved from the content-

   location = URI.

(reword: "This header is provided for = optimization purposes only.  The receiver of this header MAY = assume

 that the entity being sent is identical to what = would have been retrieved or might already have = been

 retrieved from the content-location = URI.")

 

6.2.14: The MRCPv2 server SHOULD provide a mechanism = to subset its

   output logs so that system = administrators can examine or extract only

   the log file portion during which the = logging tag was set to a

   certain = value.

(MAY)

 

6.2.15: The MRCPv2 = client

   should be able to push its stored = cookies to the MRCPv2 server and

   get new cookies that the MRCPv2 server = stored back to the MRCPv2

   client.

(reword: "To enable the MRCPv2 client to push = its stored cookies to the MRCPv2 server and

   get new cookies from the MRCPv2 server = stored back to the MRCPv2

   client, ") - connects with = following sentence.

 

6.2.15: Since the type of cookie = header

   is dictated by the HTTP origin server, = MRCPv2 clients and servers

   SHOULD support both the set-cookie and set-cookie2 entity header

   fields.

(reword: "To ensure support for the type of = cookie header dictated by the

HTTP origin server, MRCPv2 clients and = servers

   MUST support both the set-cookie and set-cookie2 entity header

   = fields.")

 

6.2.15: An MRCPv2 client or server SHOULD calculate = the age of the cookie

   according to the age calculation rules = in the HTTP/1.1 specification

   [6] and append the "Age" = attribute accordingly.

(MUST)

 

7: Server resources may be discovered and their = capabilities learned by

   clients through standard SIP = machinery.  The client can issue a SIP

   OPTIONS transaction to a server, which = has the effect of requesting

   the capabilities of the server.  = The server SHOULD respond to such a

   request with an SDP-encoded description = of its capabilities according

   to RFC3264 = [7].

(MUST)

 

7: There should be one = "resource"

   attribute for each media resource that = the server supports with the

   resource type identifier as its value.     

(MUST)

 

8.4.1: This header MAY also be specified in a = "SPEAK" request to indicate an

   offset into the speech markup that the "SPEAK" request should start

   speaking = from.

(reword: "This header MAY also be specified in a "SPEAK" request as a desired offset into the synthesized = speech.

 In this case, the synthesizer MUST begin = speaking from this amount of time into the speech markup.  = Note

 that an offset that extends beyond the end of = the produced speech will result in audio of length = zero.")

 

8.4.1: If the = synthesizer

   resource does not support a unit or the operation, the resource

   SHOULD respond with a status code of 409 "Unsupported Header Value".

(MUST)

 

8.4.2: If the recognizer or signal detector resource = is on the same server

   as the synthesizer and are part of the = same session, the server

   SHOULD work with both to provide kill-on-barge-in support.

(remove paragraph and, after the next paragraph, = add

"If the recognizer or signal detector resource = is on the same server

as the synthesizer and both are part of the same = session, the server MAY

work with both to provide internal notification to = the

synthesizer so that audio may be stopped without = having to wait for the

client's BARGE-IN-OCCURRED = event.")

 

8.4.2: If this header is

   not specified in a "SPEAK" = request or explicitly set by a

   "SET-PARAMS", the server = SHOULD default to "true".

(reword: '..., the default value for this header is "true".')

 

8.4.5: Clients SHOULD NOT interpret the completion = reason text.  Instead it

   is RECOMMENDED that the reason be = recorded in client logs and

   otherwise made available for debugging = and instrumentation purposes.

(reword: "The completion reason text is provided = for client use in logs

 and for debugging and instrumentation = purposes.  Clients are NOT REQUIRED to interpret the

 completion reason = text.")

 

8.4.6: If the synthesizer resource does not support = this operation, it

   SHOULD reject the request with a status = of "Unsupported".

(reword: '... MUST reject the request with a status = of 403 "Unsupported Header".')

 

8.4.7: If the synthesizer resource does not support = this

   operation, it should respond back to the = client with a status of

   = unsupported.

(reword: "... MUST respond back to the client = with a status of 403 "Unsupported = Header".')

 

8.4.8: This header SHOULD be part of = the

   SPEECH-MARKER event and contain the = marker tag value.

(MUST)

 

8.4.8: This header SHOULD also be returned in = responses to STOP, CONTROL,

   and BARGE-IN-OCCURRED methods, in the "SPEAK-COMPLETE" event, and in

   an IN-PROGRESS SPEAK = response.

(MUST)

 

8.4.8: In these messages the marker = tag

   SHOULD be the last embedded marker = encountered or a null string if no

   marker has yet been = encountered.

(MUST)

 

8.4.10: A value of

   "prefetch" indicates the = content may be downloaded when the request

   is received, whereas "safe" = indicates that content should only be

   downloaded when actually = referenced.

(reword: 'A value of

   "prefetch" indicates the = content MAY be downloaded when the request

   is received, whereas "safe" = indicates that content MUST NOT be

   downloaded until actually = referenced.')

 

8.4.12: When a synthesizer method needs a synthesizer = to fetch or access a

   URI and the access fails, the server = SHOULD provide the failed URI in

   this header in the method = response.

(add "unless there are multiple URI failures, in = which case one of the

failed URIs MUST be provided in this header in the = method response.")

 

8.4.13: When a synthesizer method needs a synthesizer = to fetch or access a

   URI and the access fails the server = SHOULD provide the URI specific

   or protocol specific response code in = the method response through

   this = header.

(MUST.  Also change "response code" to "response code for the URI in the = Failed-URI

header".)

 

8.4.14: When a CONTROL request to jump backward is = issued to a currently

   speaking synthesizer resource, and the = target jump point is before

   the start of the current = "SPEAK" request, the current "SPEAK" = request

   MUST restart from the beginning of its = speech data and the response

   to the CONTROL request SHOULD contain = this header indicating a

   restart.

(MUST)

 

8.4.15: If a server does = not

   support the specified unit, the resource = SHOULD respond with a status

   code of 409 "Unsupported Header Value".

(MUST)

 

8.6: If caching is implemented, this = URI

   fetching MUST conform to the cache = control hints and parameter

   headers associated with the method in = deciding whether it should be

   fetched from cache or from the external = server.

(should -> "is = to")

 

8.8: If a "SPEAK" request is active with kill-on-barge-in enabled, and the

   BARGE-IN-OCCURRED event is received, the synthesizer SHOULD

   immediately stop streaming out = audio.

(MUST)

 

8.9: If a

   PAUSE method is issued on a session when = a "SPEAK" is not active the

   server SHOULD respond with a status of = 402 "Method not valid in this

   = state".

(MUST)

 

8.9: If a PAUSE method is issued on a session when a "SPEAK" is

   active and paused the server SHOULD = respond with a status of 200

   = "Success".

(MUST)

 

8.10: If a RESUME request = is

   issued on a session with no active "SPEAK" request, the server = SHOULD

   respond with a status of 402 = "Method not valid in this state".

(MUST)

 

8.10: If a

   RESUME request is issued on a session = with an active "SPEAK" request

   that is speaking (i.e., not paused) the = server SHOULD respond with a

   status of 200 = "Success".

(MUST)

 

9: The "speechrecog" resource type can = recognize regular speech

   as well as DTMF digits and hence SHOULD = support grammars describing

   either speech or = DTMF.

(MUST)

 

9.4.8: Otherwise, the URI generated by the server = SHOULD be unambiguous

   across the server and all its = recognition sessions.

(MUST)

 

9.4.8: The content

   associated with the URI SHOULD be = available to the client until the

   MRCPv2 session = terminates.

(MUST)

 

9.4.8: Otherwise, the URI generated by = the

   server SHOULD be unambiguous across the = server and all its

   recognition = sessions.

(MUST)

 

9.4.8: The content associated with the URI SHOULD = be

   available to the client until the MRCPv2 session terminates.

(MUST)

 

9.4.12: Clients SHOULD NOT interpret the completion = reason text.  Instead it

   is RECOMMENDED that the reason be = recorded in client logs and

   otherwise made available for debugging = and instrumentation purposes.

(reword: "The completion reason text is provided = for client use in logs

 and for debugging and instrumentation = purposes.  Clients are NOT REQUIRED to interpret the

 completion reason = text.")

 

9.4.13: This Content-ID SHOULD = match

   the Content-ID that came with the = context data during the

   "GET-PARAMS" = operation.

(MUST)

 

9.4.14: The recognizer should not start the timers = until

   the client sends a START-INPUT-TIMERS = request to the recognizer.

(MUST NOT)

 

9.4.15: The = speech-complete-

   timeout value applies when the = recognizer currently has a complete

   match against an active grammar, and = specifies how long the

   recognizer should wait for more input = before declaring a match.

(MUST)

 

9.4.20: When a recognizer needs to fetch or access a = URI and the access fails

   the server SHOULD provide the failed URI = in this header in the method

   response.

(add "unless there are multiple URI failures, in = which case one of the

failed URIs MUST be provided in this header in the = method response.")

 

9.4.21: When a recognizer method needs a recognizer = to fetch or access a URI

   and the access fails the server SHOULD = provide the URI specific or

   protocol specific response code through = this header in the method

   response.

(MUST.  Also change "response code" to "response code for the URI in the = Failed-URI

header".)

 

9.4.26: This header specifies what mode the RECOGNIZE = method should operate

   in.

(should->will)

 

9.4.27: This header specifies what should happen if = the client attempts to

   invoke another RECOGNIZE method when = this RECOGNIZE request is

   already in progress for the = resource.

(should->will)

 

9.4.28: It

   specifies the maximum length of an = utterance (in seconds) that should

   be considered for Hotword = recognition.

(should->will)

 

9.4.29: It

   specifies the minimum length of an = utterance (in seconds) that should

   be considered for Hotword = recognition.

(should->will)

 

9.5: When one or more

   grammars are specified using the = DEFINE-GRAMMAR method, the server

   SHOULD attempt to fetch, compile and = optimize the grammar before

   returning a response to the = DEFINE-GRAMMAR method.

(MUST)

 

9.5.1: These grammars MAY be in one of the following standard

   grammar specification = formats:

   o  W3C's XML-based Speech Grammar = Markup Format (SRGS) [26]

   o  Sun's Java Speech Grammar Format = [32]

   All MRCPv2 servers MUST support the XML = form (MIME-type application/

   srgs+xml) of SRGS and SHOULD support the = ABNF form (MIME-type

   = application/srgs).

(Reword:

"All MRCPv2 servers MUST accept grammars in the = XML form (MIME-type application/

   srgs+xml) of the W3C's XML-based Speech = Grammar Markup Format (SRGS) [26] and MAY

accept grammars in other formats.  Examples = include but are not limited to:

  o the ABNF form (MIME-type application/srgs) = of SRGS

  o Sun's Java Speech Grammar Format = [32]"

)

 

9.5.4: The

   Content-ID value should also be = specified in the recognizer-context-

   block header in the = "GET-PARAMS" response.

(MUST)

 

9.5.4: The "SET-PARAMS" = request

   wishing to provide this vendor-specific = data should send it in the

   message body as a MIME-entity with the = same Content-ID that it

   received from the = "GET-PARAMS".

(MUST)

 

9.5.4: The Content-ID should also be = sent

   in the recognizer-context-block header = of the "SET-PARAMS" message.

(MUST)

 

9.5.4: Each speech recognition implementation = choosing to use this mechanism

   to hand off recognizer context data = among servers should distinguish

   its implementation-specific block of = data from other implementations

   by choosing a unique Content-ID that is recognizable among the

   participating servers and unlikely to = collide with values chosen by

   another = implementation.

(MUST; also remove = "unique".)

 

9.6.3.4 (simple text content): MRCPv2 clients = SHOULD

       be prepared to = receive such markup but are not required to act on

       = it.

(change to MUST and NOT REQUIRED, = respectively)

 

9.9: This means that the recognizer is active and = that the client should

   expect further events with this = request-id.

("client MUST be prepared to receive further = ...")

 

9.9: The recognizer

   SHOULD expect the media to start flowing = when it receives the

   recognize request, but SHOULD NOT buffer anything it receives

   beforehand.

(SHOULD -> = "can")

(SHOULD NOT -> MUST = NOT)

 

9.12: The recognizer resource = also

   SHOULD send a proxy-sync-id header with = a unique value for this

   event.

(MUST)

 

9.12: This event SHOULD be generated by the server irrespective of whether

   the synthesizer and recognizer are on = the same server or not.

(MUST)

 

9.13: If not, the recognizer resource SHOULD NOT = start the timers

   until the client sends a = START-INPUT-TIMERS method to the recognizer.

(MUST NOT)

 

9.15: If the client has specified Save-Best-Waveform = as true, then the

   response after ending the phrase = enrollment session SHOULD contain

   the location/URI of a recording of the = best repetition of the learned

   phrase.

(MUST)

 

9.16: This method should be invoked when = the

   caller provides undesirable input such = as non-speech noises, side-

   speech, commands, utterance from the = RECOGNIZE grammar, etc.

(reword: "The client can invoke this method when ...")

 

9.17: It should be called when successive calls = to

   RECOGNIZE have succeeded and Num-Repetitions-Still-Needed has been

   returned as 0 in the = RECOGNITION-COMPLETE event to commit the new

   phrase in the grammar.  = Alternatively, it can be called by specifying

   the Abort-Phrase-Enrollment header to = abort the phrase enrollment session.

(reword: "To commit the new phrase in the = grammar, the client MAY call this method

once successive calls to RECOGNIZE have succeeded and Num-Repetitions-Still-Needed

has been returned as 0 in the RECOGNITION-COMPLETE event.  Alternatively, the client

can abort the phrase enrollment session by calling = this method with the Abort-Phrase-Enrollment = header.")

 

9.17: If the client has specified Save-Best-Waveform = as true in the START-

   PHRASE-ENROLLMENT request, then the = response SHOULD contain the

   location/URI of a recording of the best repetition of the learned

   phrase.

(MUST)

 

10: A recorder SHOULD provide some end-pointing = capabilities for

   suppressing silence at the beginning and = end of a recording, and MAY

   also suppress silence in the middle of a recording.  If such

   suppression is done, the recorder MUST = maintain timing metadata to

   indicate the actual time stamps of the = recorded media.

(MUST)

 

10.4.4: Clients SHOULD NOT interpret the completion = reason text.  Instead it is RECOMMENDED that the reason be =

 

recorded in client logs and otherwise made available = for debugging and instrumentation purposes.

(reword: "The completion reason text is provided = for client use in logs

 and for debugging and instrumentation = purposes.  Clients are NOT REQUIRED to interpret the

 completion reason = text.")

 

10.4.5: When a recorder method needs to post the = audio to an URI and access

   to the URI fails, the server SHOULD = provide the failed URI in this

   header in the method = response.

(MUST)

 

10.4.6: When a recorder method needs to post the = audio to an URI and access

   to the URI fails, the server SHOULD = provide the URI specific or

   protocol specific response code through = this header in the method

   response.

(MUST)

 

10.4.12: When recorder is started this header = specifies if the recorder should

   start capturing immediately (false) or = wait for the end-pointing

   functionality to detect speech (true) = before it starts capturing.

(reword: "If false, the recorder MUST start = capturing immediately when started.  If true, the recorder MUST wait for the = end-pointing functionality to detect speech before it starts = capturing.")

 

11.4.3: Acceptable values indicate = whether

   the verification session should train a voiceprint ("train") or

   verify/identify using an existing = voiceprint ("verify").

(should -> will)

 

11.4.7: The verification resource SHOULD = NOT

   declare a verification 'accepted' unless = the Num-Min-Verification-

   Phrases utterances are available. =

(reword: "... MUST NOT declare a verification 'accepted' unless Num-Min-Verification-Phrases valid utterances have = been received.")

 

11.4.12: The URI value = of

   the header MUST be NULL if there was = some error condition preventing

   the server from recording.  = Otherwise, the URI generated by the

   server SHOULD be globally unique across = the server and all its

   verification = sessions.

(MUST)

 

11.4.12: The content SHOULD be available via the = URI

   until the verification session ends. =

(MUST)

 

11.4.17: Clients SHOULD NOT interpret the completion = reason text.  Instead it

   is RECOMMENDED that the reason be = recorded in client logs and

   otherwise made available for debugging = and instrumentation purposes.

(reword: "The completion reason text is provided = for client use in logs

 and for debugging and instrumentation = purposes.  Clients are NOT REQUIRED to interpret the

 completion reason = text.")

 

11.4.21: The verification = resource

   SHOULD NOT start the timers until the = client sends a START-INPUT-

   TIMERS request to the = resource.

(MUST NOT)

 

11.5.2.9: Note that the value of the = verification

   score SHOULD NOT be interpreted as a probability value in the strict

   statistical = sense.

(reword: "Note that the verification score is = not a probability value.")

 

11.6: By default, the voiceprint model SHOULD NOT = be

   adapted with data from a verification = session.

(MUST NOT)

 

11.6: The server SHOULD return = 402

   (Method not valid in this state) for all = other operations, such as

   VERIFY, or = QUERY-VOICEPRINT.

(reword: 'The server MUST return 402 "Method not = valid in this state"

 for all other verification = operations.')

 

11.13: If the header is = present

   and its value is "false", the "STOP" response SHOULD contain a

   "Completion-Cause" header and = carry the Verification result data in

   its body.

(MUST)

 

12.2: To ensure control channel = protection,

   MRCPv2 clients and servers MUST support = TLS and SHOULD utilize it by

   default.

(append "unless alternative control channel = protection is used")

 

------_=_NextPart_001_01C76638.2C35A96E-- --===============0974631798== 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 --===============0974631798==-- From speechsc-bounces@ietf.org Fri Mar 16 06:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSA5b-0000sk-Qw; Fri, 16 Mar 2007 06:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSA5b-0000sf-6i for speechsc@ietf.org; Fri, 16 Mar 2007 06:55:15 -0400 Received: from usremg01.bea.com ([66.248.192.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSA5Z-00062C-Nk for speechsc@ietf.org; Fri, 16 Mar 2007 06:55:15 -0400 Received: from usremr02.bea.com (usremr02.bea.com [10.160.29.92]) by usremg01.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2GAtBRl028296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Mar 2007 03:55:12 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l2GAtAqU004808 for ; Fri, 16 Mar 2007 03:55:10 -0700 Received: from 172.24.28.31 ([172.24.28.31]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Mar 2007 10:55:10 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 16 Mar 2007 06:55:09 -0400 Subject: Re: [Speechsc] WGLC MRCPv2-12 From: Eric Burger To: "speechsc@ietf.org" Message-ID: Thread-Topic: [Speechsc] WGLC MRCPv2-12 Thread-Index: AcdiWdIbELj6rM5NEdu71QAWy4mm/wFX74h+ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.21.151434 X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: speechsc-bounces@ietf.org Just a reminder, WGLC closes in two weeks. On 3/9/07 8:47 AM, "Eric Burger" wrote: > Due to the size of the MRCPv2 document (weighing in at 206 pages), and the > fact that IETF 68 is in a week, work group last call for MRCPv2 will close > on 30 March 2007. > > Please send your comments to the list. If you read the document and find > nothing to comment on, please send that to the list, too. > > PLEASE pay close attention to the RFC 2119 language (MAY, SHOULD, and MUST). > Previous versions had SHOULD for virtually every normative statement. This > version moved many of the SHOULD's into MUST's; a few of the SHOULD's into > MAY's; and a handful of SHOULD's stayed as SHOULD's, but with clarifying > text, explaining the circumstances where it is acceptable to NOT execute the > normative statement. > > ALSO, check section 4.2. This changes the acceptable SDP. As mentioned on > the list, the -11 version (and prior) had illegal SDP. The -12 version > corrects this. Update your implementations accordingly! > > If you have an implementation of MRCPv2, please tell us if it is a client or > a server (or you have done both), and who you have interoperated with. If > disclosing who you interoperated with gives your company conniptions, feel > free to say something like "my client interoperated with three different > servers." > > The new text is at: > http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-12.txt > > Diffs from -11 to -12 are at: > http://www.standardstrack.com/ietf/speechsc/drafts/diff-11-12.pdf > http://www.standardstrack.com/ietf/speechsc/drafts/diff-11-12.doc > > By the way, the supplemental web site has moved to: > http://www.standardstrack.com/ietf/speechsc > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Mar 19 14:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMPr-0000j4-Ts; Mon, 19 Mar 2007 14:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMO1-0008WN-Of for speechsc@ietf.org; Mon, 19 Mar 2007 14:15:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMEj-0003B5-N9 for speechsc@ietf.org; Mon, 19 Mar 2007 14:05:49 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 24D1620A15; Mon, 19 Mar 2007 19:05:37 +0100 (CET) X-AuditID: c1b4fb3c-a7ce9bb0000073d5-03-45fed0f1e239 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13731208E8; Mon, 19 Mar 2007 19:05:37 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 19:05:36 +0100 Received: from [153.88.15.185] ([153.88.15.185]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 19:05:36 +0100 Message-ID: <45FED0F0.7010302@ericsson.com> Date: Mon, 19 Mar 2007 19:05:36 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Daniel C. Burnett" Subject: Re: [Speechsc] Whitespace in ABNF References: <2AB5541EB33172459EE430FFB66B1EE90323B24F@BN-EXCH01.nuance.com> In-Reply-To: <2AB5541EB33172459EE430FFB66B1EE90323B24F@BN-EXCH01.nuance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 18:05:36.0618 (UTC) FILETIME=[31F1E4A0:01C76A51] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: speechsc-bounces@ietf.org Daniel C. Burnett skrev: > Pete, > > There is no implicit whitespace, or at least there shouldn't be. Where > no whitespace is listed as being permitted, it's not permitted. > > However, I agree with you that the permitted use of whitespace is > inconsistent across headers. > > At this point I would prefer to leave them as-is unless we get > complaints from the IESG or unless they cause insurmountable > implementation issues. > Talking from the RTSP experience. If you are inconsistent what will happens is that people will not follow the ABNF and instead trying to be consistent resulting in that everyone needs to try to have parsers beyond the syntax specification. Thus resulting in serious issues with extensibility. I would recommend that you actually clean this up. Despite it being a dam boring work both for editor and reviewers. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Mar 27 10:00:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWCDF-00048N-A7; Tue, 27 Mar 2007 09:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWCDE-000483-Fa for speechsc@ietf.org; Tue, 27 Mar 2007 09:59:48 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWCDD-00056o-2A for speechsc@ietf.org; Tue, 27 Mar 2007 09:59:48 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2RDxaAX008482 for ; Tue, 27 Mar 2007 06:59:44 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2RDxZ0c017623 for ; Tue, 27 Mar 2007 06:59:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Date: Tue, 27 Mar 2007 06:59:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: WGLC MRCPv2 Thread-Index: AcdweCoJtq8h2eoQRQiukyYQIsSjWA== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Speechsc] Reminder: WGLC MRCPv2 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: , Errors-To: speechsc-bounces@ietf.org Last call closes this week on 30 March. Please send comments, even if only, "whatever, we already interoperate with X clients" or "brilliant work" or "this is lousy because ..." or "260 pages - you must be nuts!" -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Tue Mar 27 11:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDaA-0000vv-JB; Tue, 27 Mar 2007 11:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDa8-0000vj-LG for speechsc@ietf.org; Tue, 27 Mar 2007 11:27:32 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDa2-00054D-0F for speechsc@ietf.org; Tue, 27 Mar 2007 11:27:32 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 17:27:22 +0200 Received: from PTPEVS106BA020.idc.cww.telecomitalia.it ([156.54.241.224]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 17:27:22 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Reminder: WGLC MRCPv2 Date: Tue, 27 Mar 2007 17:27:20 +0200 Message-ID: <01C0B9926BC410459FE9AACE49B81502F3D9FC@PTPEVS106BA020.idc.cww.telecomitalia.it> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] Reminder: WGLC MRCPv2 thread-index: AcdweCoJtq8h2eoQRQiukyYQIsSjWAAC84pw From: "Bergallo Patrizio" To: X-OriginalArrivalTime: 27 Mar 2007 15:27:22.0085 (UTC) FILETIME=[6A112150:01C77084] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: speechsc-bounces@ietf.org Loquendo has approved the latest draft of MRCPv2-12; the protocol is now = complete, mature and ready for subsequent standardization stages. Loquendo has implemented a server (Loquendo Speech Suite) for ASR, TTS = and SIV resources based on MRCPv2 protocol, which interoperates with = Loquendo's client within the Loquendo VoxNauta 7.0 platform.=20 Loquendo's MRCPv2 server has been successfully integrated by many = vendors into their platforms using proprietary clients; for instance it = has completed MRCPv2 testing with: - Cisco IOS VoiceXML Browser, release 12.4 (6th) T, - Aspect for the Aspect Customer Self Service, - Aculab for the Prosody family of media processing platforms, - Envox Worldwide for the Envox 7 Communications Development Platform, - eurovoice for the eurovoice objects 3.0,=20 as well as other integrations with different vendors that are still in = an early stage of development. Patrizio Bergallo & Paolo Baggia, Loquendo. -----Original Message----- From: Eric Burger [mailto:eburger@bea.com]=20 Sent: marted=EC 27 marzo 2007 16.00 To: speechsc@ietf.org Subject: [Speechsc] Reminder: WGLC MRCPv2 Last call closes this week on 30 March. Please send comments, even if only, "whatever, we already interoperate = with X clients" or "brilliant work" or "this is lousy because ..." or = "260 pages - you must be nuts!" -- Sent from my wireless e-mail device. Sorry if terse. We all need = lemonade: see for what = lemonade is. Notice: This email message, together with any attachments, may contain = information of BEA Systems, Inc., its subsidiaries and affiliated = entities, that may be confidential, proprietary, copyrighted and/or = legally privileged, and is intended solely for the use of the individual = or entity named in this message. If you are not the intended recipient, = and have received this message in error, please immediately return this = by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please send an e_mail to = webmaster@telecomitalia.it. Thank = youwww.loquendo.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Tue Mar 27 15:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHax-0008IA-6U; Tue, 27 Mar 2007 15:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHaw-0008I2-4t for speechsc@ietf.org; Tue, 27 Mar 2007 15:44:38 -0400 Received: from g2.genesyslab.com ([198.49.180.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWHau-0002Ii-Bw for speechsc@ietf.org; Tue, 27 Mar 2007 15:44:38 -0400 Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 12:44:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [speechsc] MRCPv2 WGLC Date: Tue, 27 Mar 2007 12:44:46 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74A1D5EB@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speechsc] MRCPv2 WGLC Thread-Index: AcdwqF9/yJfX/SggSeel7eypROKQnw== From: "Andrew Wahbe" To: X-OriginalArrivalTime: 27 Mar 2007 19:44:33.0583 (UTC) FILETIME=[57F4DBF0:01C770A8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be 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="===============0746581329==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0746581329== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C770A8.579BD3F9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C770A8.579BD3F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Voice Extensible Markup Language (VoiceXML) is a markup language for creating voice user interfaces that use automatic speech recognition (ASR) and text-to-speech synthesis (TTS). VoiceXML 2.0 has been published by the World Wide Web Consortium (W3C) as a "Recommendation" - essentially, a Web standard. The VoiceXML 2.1 specification adds new innovative features to VoiceXML 2.0 while maintaining backwards compatibility; this specification is currently in the final phases of the W3C process leading to Recommendation status. The W3C Voice Browser working group is also currently working on a new version of VoiceXML - VoiceXML 3.0. =20 The VoiceXML Forum is an industry organization formed to create and promote VoiceXML. With the backing and contributions of its diverse membership, including key industry leaders, the VoiceXML Forum has successfully driven market acceptance of VoiceXML through a wide array of speech-enabled applications. The VoiceXML Forum feels that MRCP v2 is a key technology for enabling the continued success and adoption of VoiceXML. This protocol is very important to the VoiceXML community as it can be used by VoiceXML platforms to interoperate with 3rd party speech engines without depending on vendor-specific interfaces and protocols. The net effect is wider and better interoperability between the VoiceXML platforms and speech engines on the market, providing significant flexibility and choice to those deploying VoiceXML-based systems.=20 =20 The VoiceXML Forum has formed the MRCP Liaison Committee to evangelize and support MRCP v2 within the industry. This committee also aims to offer educational sessions on MRCP v2 and will explore the creation of certification and/or interoperability testing resources for MRCP v2-based products. Additionally, the team aims to ensure that VoiceXML Forum members are aware of this evolving standard and have the necessary information to provide feedback to the IETF on specification drafts. =20 For over a year, the MRCP Liaison Committee has been analyzing and reviewing the MRCP v2 specification to ensure that VoiceXML-compliant platforms can be implemented using MRCP v2 to access and control media resources for ASR, TTS, DTMF recognition and speech-triggered recording. The committee finds that with draft 12, MRCP v2 is a comprehensive, mature specification that is very well suited for this purpose. However, one issue remains in the area of hotword mode speech recognition. =20 The specification contains a contradiction in sections 9.9 (the "For the Hotword mode recognition" sub-section) and 9.4.7 (it explicitly defines different behavior for the recognition timer than 9.9) related to the behavior of timers in hotword mode speech recognition. The MRCP Liaison Committee has proposed a clarification of the behavior of timers in hotword mode recognition that is compatible with VoiceXML.=20 =20 This is in the SpeechSC issue tracker as issue 88: http://www.softarmor.com/roundup/speechsc/issue88. The original request to fix this was made here: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01733.html (Follow the Thread Next links to see the discussion on this.) There were a couple requests to fix this in the response to the last WGLC: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01990.html http://www1.ietf.org/mail-archive/web/speechsc/current/msg01992.html and it seemed that this would be done based on: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01999.html=20 =20 The MRCP Liaison Committee would like to encourage the IETF SpeechSC work group to address this issue. Note that even if the full set of recommended changes is not accepted, at a minimum the contradiction between sections 9.9 and 9.4.7 should be resolved before moving the specification forward.=20 =20 Regards, =20 Andrew Wahbe VoiceXML Forum MRCP Liaison Committee ------_=_NextPart_001_01C770A8.579BD3F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Voice Extensible Markup Language = (VoiceXML) is a markup language for creating voice user interfaces that use automatic = speech recognition (ASR) and text-to-speech synthesis (TTS). VoiceXML 2.0 has = been published by the World Wide Web Consortium (W3C) as a = “Recommendation” – essentially, a Web standard. The VoiceXML 2.1 specification adds = new innovative features to VoiceXML 2.0 while maintaining backwards = compatibility; this specification is currently in the final phases of the W3C process = leading to Recommendation status. The W3C Voice Browser working group is also = currently working on a new version of VoiceXML – VoiceXML = 3.0.

 

The VoiceXML Forum is an industry = organization formed to create and promote VoiceXML. With the backing and = contributions of its diverse membership, including key industry leaders, the VoiceXML = Forum has successfully driven market acceptance of VoiceXML through a wide array = of speech-enabled applications. The VoiceXML Forum feels that MRCP v2 is a = key technology for enabling the continued success and adoption of VoiceXML. = This protocol is very important to the VoiceXML community as it can be used = by VoiceXML platforms to interoperate with 3rd party speech engines without depending on vendor-specific interfaces and protocols. The net effect is = wider and better interoperability between the VoiceXML platforms and speech = engines on the market, providing significant flexibility and choice to those = deploying VoiceXML-based systems.

 

The VoiceXML Forum has formed the MRCP = Liaison Committee to evangelize and support MRCP v2 within the industry. This = committee also aims to offer educational sessions on MRCP v2 and will explore the creation of certification and/or interoperability testing resources for = MRCP v2-based products. Additionally, the team aims to ensure that VoiceXML Forum = members are aware of this evolving standard and have the necessary information to = provide feedback to the IETF on specification = drafts.

 

For over a year, the MRCP Liaison Committee = has been analyzing and reviewing the MRCP v2 specification to ensure that = VoiceXML-compliant platforms can be implemented using MRCP v2 to access and control media resources for ASR, TTS, DTMF recognition and speech-triggered recording. = The committee finds that with draft 12, MRCP v2 is a comprehensive, mature specification that is very well suited for this purpose. However, one = issue remains in the area of hotword mode speech = recognition.

 

The specification contains a contradiction in = sections 9.9 (the “For the Hotword mode recognition” sub-section) and = 9.4.7 (it explicitly defines different behavior for the recognition timer than = 9.9) related to the behavior of timers in hotword mode speech recognition. = The MRCP Liaison Committee has proposed a clarification of the behavior of timers = in hotword mode recognition that is compatible with VoiceXML. =

 

This is in the SpeechSC issue tracker as = issue 88: http://www.so= ftarmor.com/roundup/speechsc/issue88. The original request to fix this was made here: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01733.htm= l (Follow the Thread Next links to see the discussion on this.) There were = a couple requests to fix this in the response to the last WGLC: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01990.htm= l http://www1.ietf.org/mail-archive/web/speechsc/current/msg01992.htm= l and it seemed that this would be done based on: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01999.htm= l

 

The MRCP Liaison Committee would like to = encourage the IETF SpeechSC work group to address this issue. Note that even if = the full set of recommended changes is not accepted, at a minimum the = contradiction between sections 9.9 and 9.4.7 should be resolved before moving the specification forward.

 

Regards,

 

Andrew = Wahbe

VoiceXML Forum MRCP Liaison = Committee

------_=_NextPart_001_01C770A8.579BD3F9-- --===============0746581329== 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 Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============0746581329==-- From speechsc-bounces@ietf.org Wed Mar 28 02:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRnP-00011B-BI; Wed, 28 Mar 2007 02:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRnO-000116-IR for speechsc@ietf.org; Wed, 28 Mar 2007 02:38:10 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWRnK-0004QU-Uh for speechsc@ietf.org; Wed, 28 Mar 2007 02:38:10 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFL00D2GOULVS@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 28 Mar 2007 14:32:45 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFL00EUAOUJ5N@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 28 Mar 2007 14:32:44 +0800 (CST) Received: from srilakshmi ([10.18.4.173]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFL00G6VOUF9E@szxml03-in.huawei.com> for speechsc@ietf.org; Wed, 28 Mar 2007 14:32:43 +0800 (CST) Date: Wed, 28 Mar 2007 12:02:38 +0530 From: Srilakshmi Subject: RE:[Speechsc] WGLC MRCPv2-12 To: 'Eric Burger' Message-id: <000001c77102$e215eef0$ad04120a@srilakshmi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdxAuFQKtf1ZgVhQ3KC/+qJwLDC2A== X-Spam-Score: 0.0 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1172998548==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1172998548== Content-type: multipart/alternative; boundary="Boundary_(ID_EqmFZ7we7AnCdNSm9rvWtw)" This is a multi-part message in MIME format. --Boundary_(ID_EqmFZ7we7AnCdNSm9rvWtw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, What should the MRCPv2 server behavior be if it receives STOP without abort-verification header for a VERIFY request? Should it respond with 406 mandatory header missing or process the request? There are two contradicting statements in draft. Snippets from draft 12: 11.4.20. Abort-Verification This header MUST be sent in a "STOP" request to indicate whether or not to abort a VERIFY method in progress. 11.13. STOP .. .. The "STOP" method can carry a "Abort-Verification" header which specifies if the verification result until that point should be discarded or returned. If this header is not present or if the value is "true", the verification result is discarded and the "STOP" response does not contain any result data. If the header is present and its value is "false", the "STOP" response SHOULD contain a "Completion-Cause" header and carry the Verification result data in its body. Example in this section does not have Abort-Verification header in STOP request. Snippet from draft The following example assumes a voiceprint identity has already been established. C->S: MRCP/2.0 123 VERIFY 314177 Channel-Identifier:32AECB23433801@speakverify Verification-Mode:verify S->C: MRCP/2.0 49 314177 200 IN-PROGRESS Channel-Identifier:32AECB23433801@speakverify C->S: MRCP/2.0 49 STOP 314178 Channel-Identifier:32AECB23433801@speakverify S->C: MRCP/2.0 123 314178 200 COMPLETE Channel-Identifier:32AECB23433801@speakverify Active-Request-Id-List:314177 Please provide some clarification regarding this issue. Regards, Srilakshmi K. --Boundary_(ID_EqmFZ7we7AnCdNSm9rvWtw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

What should the MRCPv2 server behavior be if it receives STOP without abort-verification header for a VERIFY request? Should it respond with 406 mandatory header missing or process the request?

 

There are two contradicting statements in draft.

 

Snippets from draft 12:

 

11.4.20. Abort-Verification

    This header MUST be sent in a "STOP" request to indicate whether or not to abort a VERIFY method in progress. 

 

11.13. STOP

….

….

   The "STOP" method can carry a "Abort-Verification" header which specifies if the verification result until that point should be discarded or returned. If this header is not present or if the value is "true", the verification result is discarded and the "STOP" response does not contain any result data. If the header is present and its value is "false", the "STOP" response SHOULD contain a "Completion-Cause" header and carry the Verification result data in its body.

 

Example in this section does not have Abort-Verification header in STOP request.

 

Snippet from draft

 

The following example assumes a voiceprint identity has already been established.

 

   C->S:  MRCP/2.0 123 VERIFY 314177

          Channel-Identifier:32AECB23433801@speakverify

          Verification-Mode:verify

 

   S->C:  MRCP/2.0 49 314177 200 IN-PROGRESS

          Channel-Identifier:32AECB23433801@speakverify

 

   C->S:  MRCP/2.0 49 STOP 314178

          Channel-Identifier:32AECB23433801@speakverify

 

   S->C:  MRCP/2.0 123 314178 200 COMPLETE

          Channel-Identifier:32AECB23433801@speakverify

          Active-Request-Id-List:314177

 

Please provide some clarification regarding this issue.

 

Regards,

Srilakshmi K.

 

--Boundary_(ID_EqmFZ7we7AnCdNSm9rvWtw)-- --===============1172998548== 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 Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1172998548==-- From speechsc-bounces@ietf.org Wed Mar 28 02:48:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRxB-0006gO-7u; Wed, 28 Mar 2007 02:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWRx9-0006gE-Pm for speechsc@ietf.org; Wed, 28 Mar 2007 02:48:15 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWRx5-0006uW-NQ for speechsc@ietf.org; Wed, 28 Mar 2007 02:48:15 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFL00DIHPJ1VS@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 28 Mar 2007 14:47:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFL00EFFPJ05N@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 28 Mar 2007 14:47:25 +0800 (CST) Received: from srilakshmi ([10.18.4.173]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFL0001MPIW9V@szxml04-in.huawei.com> for speechsc@ietf.org; Wed, 28 Mar 2007 14:47:24 +0800 (CST) Date: Wed, 28 Mar 2007 12:17:20 +0530 From: Srilakshmi To: 'Eric Burger' Message-id: <000501c77104$ef6d15e0$ad04120a@srilakshmi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdxBO7G1WQ7N3LKS6yVcfg0vTLA0A== X-Spam-Score: 0.2 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: speechsc@ietf.org Subject: [Speechsc] Small correction in section 11.6 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="===============1661470643==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1661470643== Content-type: multipart/alternative; boundary="Boundary_(ID_tVEMclqJocq35oZO84ETfg)" This is a multi-part message in MIME format. --Boundary_(ID_tVEMclqJocq35oZO84ETfg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, In the example provided in section 11.6 for START-SESSION In the START-SESSION request sent, one of the headers is given as Voiceprint-Mode. It should be Verification-Mode. Snippet from the draft 12: C->S: MRCP/2.0 123 START-SESSION 314161 Channel-Identifier:32AECB23433801@speakverify Repository-URI:http://www.example.com/voiceprintdbase/ Voiceprint-Mode:verify Voiceprint-Identifier:johnsmith.voiceprint Adapt-Model:true Regards, Srilakshmi K. --Boundary_(ID_tVEMclqJocq35oZO84ETfg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

In the example provided in section 11.6 for START-SESSION

In the START-SESSION request sent, one of the headers is given as Voiceprint-Mode. It should be Verification-Mode.

 

Snippet from the draft 12:

C->S:  MRCP/2.0 123 START-SESSION 314161

          Channel-Identifier:32AECB23433801@speakverify

          Repository-URI:http://www.example.com/voiceprintdbase/

          Voiceprint-Mode:verify

          Voiceprint-Identifier:johnsmith.voiceprint

          Adapt-Model:true

 

Regards,

Srilakshmi K.

--Boundary_(ID_tVEMclqJocq35oZO84ETfg)-- --===============1661470643== 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 Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1661470643==-- From speechsc-bounces@ietf.org Wed Mar 28 03:05:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWSE5-0005bn-M9; Wed, 28 Mar 2007 03:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWSE4-0005bb-CR for speechsc@ietf.org; Wed, 28 Mar 2007 03:05:44 -0400 Received: from two.mindstorm.cz ([217.11.242.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWSE3-0002jG-0s for speechsc@ietf.org; Wed, 28 Mar 2007 03:05:44 -0400 Received: from localhost (localhost [127.0.0.1]) by two.mindstorm.cz (Postfix) with ESMTP id 35A3B403707E for ; Wed, 28 Mar 2007 09:05:25 +0200 (CEST) Received: from two.mindstorm.cz ([127.0.0.1]) by localhost (two.mindstorm.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27375-03 for ; Wed, 28 Mar 2007 09:05:21 +0200 (CEST) Received: from [10.0.0.3] (faster06.westcom.cz [81.19.10.86]) by two.mindstorm.cz (Postfix) with ESMTP id 666EF4054A15 for ; Wed, 28 Mar 2007 09:05:21 +0200 (CEST) Message-ID: <460A13A5.30502@optimsys.cz> Date: Wed, 28 Mar 2007 09:05:09 +0200 From: Petr Kuba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: speechsc@ietf.org Subject: Re: [Speechsc] Reminder: WGLC MRCPv2 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mindstorm.cz X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: speechsc-bounces@ietf.org OptimSys has implemented an MRCPv2 client in its OptimTalk VoiceXML/CCXML platform for ASR and TTS resources. The client has been successfully integrated and tested with two MRCPv2 servers from different vendors. -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz Eric Burger wrote: > Last call closes this week on 30 March. > > Please send comments, even if only, "whatever, we already interoperate with X clients" or "brilliant work" or "this is lousy because ..." or "260 pages - you must be nuts!" > > -- > Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Mar 28 08:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWXRa-0001GW-5V; Wed, 28 Mar 2007 08:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWXRZ-0001GF-Ev for speechsc@ietf.org; Wed, 28 Mar 2007 08:40:01 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWXRT-0001Rw-Qc for speechsc@ietf.org; Wed, 28 Mar 2007 08:40:01 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 14:39:53 +0200 Received: from PTPEVS106BA020.idc.cww.telecomitalia.it ([156.54.241.224]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 14:39:50 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Reminder: WGLC MRCPv2 Date: Wed, 28 Mar 2007 14:39:50 +0200 Message-ID: <6B0BEC95E14FFF43822F1E730EF5C256013AD7FC@PTPEVS106BA020.idc.cww.telecomitalia.it> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] Reminder: WGLC MRCPv2 thread-index: AcdweCoJtq8h2eoQRQiukyYQIsSjWAAvekYw References: From: "Manzone Vittorio" To: X-OriginalArrivalTime: 28 Mar 2007 12:39:50.0301 (UTC) FILETIME=[2D265CD0:01C77136] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: speechsc-bounces@ietf.org With publication of draft 12, I believe that MRCPv2 has reached a = maturity level which allows it to further proceed in the standardization = process. I have been working on implementing MRCPv2 and I found it sound and = complete to exploit speech technologies in a variety of application = contexts. Vittorio Manzone +39 011 2913470 vittorio.manzone@loquendo.com -----Original Message----- From: Eric Burger [mailto:eburger@bea.com]=20 Sent: marted=EC 27 marzo 2007 16.00 To: speechsc@ietf.org Subject: [Speechsc] Reminder: WGLC MRCPv2 Last call closes this week on 30 March. Please send comments, even if only, "whatever, we already interoperate = with X clients" or "brilliant work" or "this is lousy because ..." or = "260 pages - you must be nuts!" -- Sent from my wireless e-mail device. Sorry if terse. We all need = lemonade: see for what = lemonade is. Notice: This email message, together with any attachments, may contain = information of BEA Systems, Inc., its subsidiaries and affiliated = entities, that may be confidential, proprietary, copyrighted and/or = legally privileged, and is intended solely for the use of the individual = or entity named in this message. If you are not the intended recipient, = and have received this message in error, please immediately return this = by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please send an e_mail to = webmaster@telecomitalia.it. Thank = youwww.loquendo.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Mar 28 19:39:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhjO-0000L4-C3; Wed, 28 Mar 2007 19:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhjM-0000HA-RC for speechsc@ietf.org; Wed, 28 Mar 2007 19:39:04 -0400 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhjL-00030U-JB for speechsc@ietf.org; Wed, 28 Mar 2007 19:39:04 -0400 Received: from unknown (HELO bn-exchbh2.nuance.com) ([10.1.4.197]) by mx2.nuance.com with ESMTP; 28 Mar 2007 19:39:03 -0400 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,342,1170651600"; d="scan'208"; a="52663364:sNHT40892600" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh2.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 19:39:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Reminder: WGLC MRCPv2 Date: Wed, 28 Mar 2007 19:32:08 -0400 Message-ID: <2AB5541EB33172459EE430FFB66B1EE903F0A4C4@BN-EXCH01.nuance.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] Reminder: WGLC MRCPv2 Thread-Index: AcdweCoJtq8h2eoQRQiukyYQIsSjWAA8q2xQ References: From: "Rob Kassel" To: X-OriginalArrivalTime: 28 Mar 2007 23:39:03.0285 (UTC) FILETIME=[4490C250:01C77192] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: speechsc-bounces@ietf.org Nuance Communications currently offers two generally available server products that support MRCPv2 as defined in the draft specification. Both have been successfully tested for interoperability with multiple MRCPv2 clients developed by other parties. Based on these efforts we believe MRCPv2 provides an excellent foundation for constructing high-performance speech processing systems. Respectfully yours, ROB Rob Kassel Senior Manager Nuance Communications, Inc.=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Tuesday, March 27, 2007 10:00 AM > To: speechsc@ietf.org > Subject: [Speechsc] Reminder: WGLC MRCPv2 >=20 > Last call closes this week on 30 March. >=20 > Please send comments, even if only, "whatever, we already=20 > interoperate with X clients" or "brilliant work" or "this is=20 > lousy because ..." or "260 pages - you must be nuts!" >=20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> >=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Fri Mar 30 08:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGDB-0007L9-Mc; Fri, 30 Mar 2007 08:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwUr-0003Dr-4s for speechsc@ietf.org; Thu, 29 Mar 2007 11:25:05 -0400 Received: from smtp1.enomia.com ([64.128.160.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwUn-0007oL-RQ for speechsc@ietf.org; Thu, 29 Mar 2007 11:25:05 -0400 Received: from MAIL26.myITlive.com ([10.160.16.51]) by smtp1.enomia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 11:24:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Mar 2007 11:24:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Loquendo MRCP implementation Thread-Index: AcdyFmXsKbyXH/d7QZeC89fHbbPFbw== From: "Sanjeev Sawai" To: X-OriginalArrivalTime: 29 Mar 2007 15:24:56.0515 (UTC) FILETIME=[68206930:01C77216] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Fri, 30 Mar 2007 08:28:08 -0400 Subject: [Speechsc] Loquendo MRCP implementation 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="===============1205279598==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1205279598== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77216.6780D266" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77216.6780D266 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have tested the Envox Communications Development Platform 7 with Loquendo ASR and TTS using MRCP v2 and found that their implementation works well and is compliant with the specification. =20 Sanjeev Sawai VP Research and Development Envox Worldwide 2000 West Park Drive Westborough, MA 01581 USA +1 508 871 7612 +1 508 366 0009 fax ssawai@envox.com =20 www.envox.com =20 =20 =20 ------_=_NextPart_001_01C77216.6780D266 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We = have tested the=20 Envox Communications Development Platform 7 with Loquendo ASR and TTS = using MRCP=20 v2 and found that their implementation works well and is compliant with = the=20 specification.
 
Sanjeev Sawai
VP Research and = Development
Envox = Worldwide
2000 West Park = Drive
Westborough, MA = 01581
USA
+1 508 871 = 7612
+1 508 366 0009 = fax
 
 
------_=_NextPart_001_01C77216.6780D266-- --===============1205279598== 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 Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1205279598==-- From speechsc-bounces@ietf.org Fri Mar 30 10:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXI5E-0000wb-Kq; Fri, 30 Mar 2007 10:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXI5D-0000lP-Bg for speechsc@ietf.org; Fri, 30 Mar 2007 10:28:03 -0400 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXI59-0003TF-It for speechsc@ietf.org; Fri, 30 Mar 2007 10:28:03 -0400 Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 2717A87347 for ; Fri, 30 Mar 2007 15:27:59 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2007 15:27:58 +0100 Message-ID: <00D42150952F70458C66072322F7FE25012EFEA3@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC MRCPv2 Thread-Index: Acdy150bjLlCbcdwSHiQpIAXY30fKg== From: "Jo Taylor" To: X-ST-MF-Message-Resent: 3/30/2007 15:27 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Dati Roberto , David R Oran , Bergallo Patrizio Subject: [Speechsc] WGLC MRCPv2 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: , Errors-To: speechsc-bounces@ietf.org "Being a technology provider for VoIP telephony solutions, Aculab appreciates that Loquendo have chosen to adopt the new MRCPv2 standard. Integration with Loquendo's high performance voice engines using the new MRCPv2 protocol brings many benefits to our joint customers, including faster time to market and reduced solution development costs. MRCPv2 will continue to experience an overwhelming adoption by the industry - its functionality addresses the current market needs." Herman Abel Product Manager Aculab, UK Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1= 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Fri Mar 30 10:29:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXI65-0002cP-PC; Fri, 30 Mar 2007 10:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXI63-0002cA-S4 for speechsc@ietf.org; Fri, 30 Mar 2007 10:28:55 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXI5w-0003Zw-1x for speechsc@ietf.org; Fri, 30 Mar 2007 10:28:55 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 16:28:44 +0200 Received: from PTPEVS106BA020.idc.cww.telecomitalia.it ([156.54.241.224]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 16:28:43 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: R: [Speechsc] Reminder: WGLC MRCPv2 - On behalf of Martin Sheer Date: Fri, 30 Mar 2007 16:28:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: R: [Speechsc] Reminder: WGLC MRCPv2 - On behalf of Martin Sheer thread-index: AcdyCSUig01ngpYNTPqlBjDkfr4eiAAyVGmgAACH6XAAAL4zcA== X-Priority: 1 Priority: Urgent Importance: high From: "Baggia Paolo" To: X-OriginalArrivalTime: 30 Mar 2007 14:28:43.0966 (UTC) FILETIME=[B85805E0:01C772D7] X-Spam-Score: 1.3 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: David R Oran , "Burger, Eric" 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: , Errors-To: speechsc-bounces@ietf.org Resend as requested. Regards, Martin. > -- > From: Martin G. Steer > Sent: 28 March 2007 12:10 > To: 'speechsc@ietf.org' > Subject: [Speechsc] Reminder: WGLC MRCPv2 > > I, Martin George Steer - Managing Director of eurovoice limited -=20 > hereby confirm that integration, testing and live deployment of our=20 > product, eurovoice objects 3.0, with Loquendo's Speech Suite server is > now complete. This integration is based on the latest draft of=20 > MRCPv2-1. I therefore believe the MRCPv2 standard is now complete,=20 > mature and ready for the formalities of standardization. > > > > Regards, > Martin Steer, CEng, BSc, MIEE > Director, eurovoice limited > http://www.eurovoice.co.uk Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please send an e_mail to = webmaster@telecomitalia.it. Thank = youwww.loquendo.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Fri Mar 30 12:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJks-0003yX-Uo; Fri, 30 Mar 2007 12:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJkr-0003y5-VH for speechsc@ietf.org; Fri, 30 Mar 2007 12:15:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJiv-0007GT-RS for speechsc@ietf.org; Fri, 30 Mar 2007 12:13:17 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 13E522065C; Fri, 30 Mar 2007 18:13:01 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-eb-460d370c06ed Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F1257204EA; Fri, 30 Mar 2007 18:13:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 18:13:00 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 18:13:00 +0200 Message-ID: <460D3708.90109@ericsson.com> Date: Fri, 30 Mar 2007 18:12:56 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Speechsc] WGLC MRCPv2-12 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2007 16:13:00.0170 (UTC) FILETIME=[4954FEA0:01C772E6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: speechsc-bounces@ietf.org Hi, I have just started reading the latest version of MRCPv2 (12). So far only come to section 5. So I am just starting. I promised Eric I would review it now during WGLC rather than stick you guys with my comments during IESG evaluation. I will try to complete my review during Monday or Tuesday. However until then something for you to discuss: In section 4.2 you define behavior for using the comedia a=connection attribute with the TCP/MRCPv2 protocol. Based on the text and example (add recognizer example starting on page 16) it seems that you try to allow that multiple m= lines reuses the same TCP connection. However it is far from obvious that comedia (RFC 4145) support this behavior. It doesn't talk about any relation between multiple m= lines and their TCP connections. I would recommend discussing this with MMUSIC. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc>