From speechsc-bounces@ietf.org Fri Sep 01 01:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1YI-0005wF-0f; Fri, 01 Sep 2006 01:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ1YG-0005vo-JL for speechsc@ietf.org; Fri, 01 Sep 2006 01:26:48 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ1YA-0002B6-LW for speechsc@ietf.org; Fri, 01 Sep 2006 01:26:48 -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 <0J4W00BXNFKSSB@szxga03-in.huawei.com> for speechsc@ietf.org; Fri, 01 Sep 2006 13:36:29 +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 <0J4W00EOOFKR91@szxga03-in.huawei.com> for speechsc@ietf.org; Fri, 01 Sep 2006 13:36:28 +0800 (CST) Received: from HTIPL60805 ([10.18.5.155]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4W00DP7FA4O8@szxml03-in.huawei.com> for speechsc@ietf.org; Fri, 01 Sep 2006 13:30:08 +0800 (CST) Date: Fri, 01 Sep 2006 10:56:02 +0530 From: Manjunatha To: speechsc@ietf.org Message-id: <000601c6cd87$1df2faa0$9b05120a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbNhx1wDO8zkmA0SX6ZdNzke6OvLQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: 3c237f91aa624783c8cc693cdb4de0c7 Subject: [Speechsc] Clarification regarding Max-time header X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manjunathan@huawei.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0382746608==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0382746608== Content-type: multipart/alternative; boundary="Boundary_(ID_1IUTv6phUnYqUbscXK7tLg)" This is a multi-part message in MIME format. --Boundary_(ID_1IUTv6phUnYqUbscXK7tLg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Please provide some clarification about Max-time header 10.4.9. Max Time When recording is started this specifies the maximum length of the recording in milliseconds, calculated from the time the actual capture and store begins and is not necessarily the time the RECORD method is received. It specifies the duration before silence suppression, if any, has been applied by the recorder resource. After this time, the recording stops and the server MUST return a RECORD-COMPLETE event to the client having a request-state of "COMPLETE". This header MAY occur in RECORD, "SET-PARAMS" or "GET-PARAMS". The value for this header ranges from 0 to an implementation specific maximum value. A value of zero means infinity and hence the recording continues until one or more of the other stop conditions are met. The default value for this header is 0. Here why a value of zero means infinity..... It is confusing.in a normal understanding there will be no recoding if the value is ZERO .pls give some clarification Regards Manju --Boundary_(ID_1IUTv6phUnYqUbscXK7tLg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

   Please provide some clarification about Max-time header

 

10.4.9. Max Time

 

   When recording is started this specifies the maximum length of the

   recording in milliseconds, calculated from the time the actual

   capture and store begins and is not necessarily the time the RECORD

   method is received.  It specifies the duration before silence

   suppression, if any, has been applied by the recorder resource.

   After this time, the recording stops and the server MUST return a

   RECORD-COMPLETE event to the client having a request-state of

   "COMPLETE".  This header MAY occur in RECORD, "SET-PARAMS" or

   "GET-PARAMS".  The value for this header ranges from 0 to an

   implementation specific maximum value.  A value of zero means

   infinity and hence the recording continues until one or more of the

   other stop conditions are met.  The default value for this header is

   0.

 

      

    Here why a value of zero means infinity………….

    It is confusing…in a normal understanding there will be no recoding if the value is ZERO

    .pls give some clarification

 

 

Regards

 

Manju

--Boundary_(ID_1IUTv6phUnYqUbscXK7tLg)-- --===============0382746608== 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 --===============0382746608==-- From speechsc-bounces@ietf.org Fri Sep 01 08:27:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ87g-0008Ko-Iz; Fri, 01 Sep 2006 08:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ87e-0008K8-Rl for speechsc@ietf.org; Fri, 01 Sep 2006 08:27:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ7Fy-0006Ce-Cf for speechsc@ietf.org; Fri, 01 Sep 2006 07:32:18 -0400 Received: from [87.198.5.178] (helo=mail.voxpilot.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GJ72b-0007Gy-NS for speechsc@ietf.org; Fri, 01 Sep 2006 07:18:31 -0400 Received: by mail.voxpilot.com (Postfix, from userid 552) id 2831E2140F5; Fri, 1 Sep 2006 11:18:19 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on db01ms01 X-Spam-Status: No, score=-4.0 required=5.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from daburkewxp (unknown [10.0.0.102]) by mail.voxpilot.com (Postfix) with ESMTP id 97BCD214123; Fri, 1 Sep 2006 11:18:15 +0000 (GMT) Message-ID: <013c01c6cdb8$48e1c530$6600000a@db01.voxpilot.com> From: "Dave Burke" To: "Dan Burnett" , References: <20060831212613.49864.qmail@web32905.mail.mud.yahoo.com> Subject: Re: [speechsc] Record-URI mechanism Date: Fri, 1 Sep 2006 12:18:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -2.6 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 OK - that works. I think I must have tripped over the phrase "if the header is empty" and wrongly assumed an inconsistency... A minor improvement could be instead to write "if the header is present but specified with no value". Dave ----- Original Message ----- From: "Dan Burnett" To: "Dave Burke" ; Sent: Thursday, August 31, 2006 10:26 PM Subject: Re: [speechsc] Record-URI mechanism > Actually, you have only quoted part of the text from > 10.4.7. Here's the full paragraph: > > > When a recorder method contains this header the server > must capture the audio and store it. If the header is > empty, the server MUST store the content locally and > generate a URI that points to it. This URI is then > returned in the STOP response or the RECORD-COMPLETE > events. If the header in the RECORD method specifies a > URI, the server MUST attempt to capture and store the > audio at that location. If this header is not > specified in the RECORD request, the server MUST > capture the audio and send it in the STOP response or > the RECORD-COMPLETE event as a message body. In this > case, the response carrying the audio content would > have this header with a cid value pointing to the > Content-ID in the message body. > > > In other words, 10.4.7 permits both approaches -- if > you want a generated URI you specify the header with > an empty value. If you want it in the body you don't > specify the header at all. > > Thus, to make 10.6 consistent with this I suggest we > replace > "It then saves the audio to the URI supplied in the > recording-uri header. If the recording-uri is not > specified, the server captures the media anywhere it > finds convenient and returns a URI pointing to the > recorded audio in the RECORD-COMPLETE event." > with > "The audio is then made available to the client as > specified by Record-URI." > > I am making this clarification in draft -11 but will > undo it if there are concerns raised that require > discussion. > > -- dan > > --- Dave Burke wrote: > >> In 10.6, the spec says: >> >> If the recording-uri is not specified [in >> RECORD], the server captures the media >> anywhere it finds convenient and returns a URI >> pointing to the >> recorded audio in the RECORD-COMPLETE event. >> >> However, 10.4.7 apparently conflicts with this and >> says: >> >> If this header is not specified in the RECORD >> request, the server >> MUST capture the audio and send it in the "STOP" >> response or the >> RECORD-COMPLETE event as a message body. In this >> case, the response >> carrying the audio content would have this header >> with a cid value >> pointing to the Content-ID in the message body. >> >> Which is it? I prefer it to be the former (i.e. no >> data in the message body). It's easy to implement >> (very likely the MRCP client has a HTTP client >> somewheres, optimised for streaming and allowing >> caching for repeated playback), it doesn't burden >> the control channel with potentially very large >> audio data, and besides, the MRCP client might not >> even want the data in the case of verification on >> the server. >> >> Dave >> >> >> > _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Sep 01 14:22:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJDeb-00080M-DX; Fri, 01 Sep 2006 14:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJDea-0007wK-IV for speechsc@ietf.org; Fri, 01 Sep 2006 14:22:08 -0400 Received: from web32910.mail.mud.yahoo.com ([209.191.69.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJDeY-0000yI-6C for speechsc@ietf.org; Fri, 01 Sep 2006 14:22:08 -0400 Received: (qmail 18038 invoked by uid 60001); 1 Sep 2006 18:22:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=p9gSV9Qb7hKkbpIXhEWjyj8fAtPJJdwK5lUSfI1L0DWiGFosuk6RTJ/R74IaXtoPbdmmn5RjENe07wJN0MPvrwvotWLh6+y0BiKRyKBqWaKSFKx2OmUJtg8D6+YBJrktYf+aihqFziWMrZmJWbSuGAUmi7pOlwoQP7pC9AcP53Q= ; Message-ID: <20060901182205.18036.qmail@web32910.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32910.mail.mud.yahoo.com via HTTP; Fri, 01 Sep 2006 11:22:05 PDT Date: Fri, 1 Sep 2006 11:22:05 -0700 (PDT) From: Dan Burnett Subject: Re: [speechsc] Record-URI mechanism To: Dave Burke , speechsc@ietf.org In-Reply-To: <013c01c6cdb8$48e1c530$6600000a@db01.voxpilot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Agreed. I have applied your suggested change to -11. -- dan --- Dave Burke wrote: > OK - that works. I think I must have tripped over > the phrase "if the header > is empty" and wrongly assumed an inconsistency... A > minor improvement could > be instead to write "if the header is present but > specified with no value". > > Dave > > ----- Original Message ----- > From: "Dan Burnett" > To: "Dave Burke" ; > > Sent: Thursday, August 31, 2006 10:26 PM > Subject: Re: [speechsc] Record-URI mechanism > > > > Actually, you have only quoted part of the text > from > > 10.4.7. Here's the full paragraph: > > > > > > When a recorder method contains this header the > server > > must capture the audio and store it. If the header > is > > empty, the server MUST store the content locally > and > > generate a URI that points to it. This URI is then > > returned in the STOP response or the > RECORD-COMPLETE > > events. If the header in the RECORD method > specifies a > > URI, the server MUST attempt to capture and store > the > > audio at that location. If this header is not > > specified in the RECORD request, the server MUST > > capture the audio and send it in the STOP response > or > > the RECORD-COMPLETE event as a message body. In > this > > case, the response carrying the audio content > would > > have this header with a cid value pointing to the > > Content-ID in the message body. > > > > > > In other words, 10.4.7 permits both approaches -- > if > > you want a generated URI you specify the header > with > > an empty value. If you want it in the body you > don't > > specify the header at all. > > > > Thus, to make 10.6 consistent with this I suggest > we > > replace > > "It then saves the audio to the URI supplied in > the > > recording-uri header. If the recording-uri is not > > specified, the server captures the media anywhere > it > > finds convenient and returns a URI pointing to the > > recorded audio in the RECORD-COMPLETE event." > > with > > "The audio is then made available to the client as > > specified by Record-URI." > > > > I am making this clarification in draft -11 but > will > > undo it if there are concerns raised that require > > discussion. > > > > -- dan > > > > --- Dave Burke wrote: > > > >> In 10.6, the spec says: > >> > >> If the recording-uri is not specified [in > >> RECORD], the server captures the media > >> anywhere it finds convenient and returns a URI > >> pointing to the > >> recorded audio in the RECORD-COMPLETE event. > >> > >> However, 10.4.7 apparently conflicts with this > and > >> says: > >> > >> If this header is not specified in the RECORD > >> request, the server > >> MUST capture the audio and send it in the > "STOP" > >> response or the > >> RECORD-COMPLETE event as a message body. In > this > >> case, the response > >> carrying the audio content would have this > header > >> with a cid value > >> pointing to the Content-ID in the message > body. > >> > >> Which is it? I prefer it to be the former (i.e. > no > >> data in the message body). It's easy to implement > >> (very likely the MRCP client has a HTTP client > >> somewheres, optimised for streaming and allowing > >> caching for repeated playback), it doesn't burden > >> the control channel with potentially very large > >> audio data, and besides, the MRCP client might > not > >> even want the data in the case of verification on > >> the server. > >> > >> Dave > >> > >> > >> > _______________________________________________ > >> Speechsc mailing list > >> Speechsc@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speechsc > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sat Sep 02 07:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJTRb-0006JR-1D; Sat, 02 Sep 2006 07:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJTRZ-0006JI-Eo for speechsc@ietf.org; Sat, 02 Sep 2006 07:13:45 -0400 Received: from web32909.mail.mud.yahoo.com ([209.191.69.109]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GJTRY-0007co-2F for speechsc@ietf.org; Sat, 02 Sep 2006 07:13:45 -0400 Received: (qmail 82240 invoked by uid 60001); 2 Sep 2006 11:13:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=stwKkC1u8ndMZOx9Vu4bmraYAFe27hwfvjtiJTzRfYABcgvHXJis7rIIpeoV5iMTsJdvbgmZVBxnQIykKuBZFz8li2fSwkTfCad4mXTO9JSs8kva0e3KVtEF35itFRopVZovGH6tMdMobi/kqM8EsnLsLRC7htunXblkFwZ5dg4= ; Message-ID: <20060902111343.82238.qmail@web32909.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32909.mail.mud.yahoo.com via HTTP; Sat, 02 Sep 2006 04:13:43 PDT Date: Sat, 2 Sep 2006 04:13:43 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] element not defined in XML schemas To: Brett Gavagni , speechsc@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 Sorry for the late reply. This issue is, in another form, already in the issue tracker (http://www.softarmor.com/roundup/speechsc/issue66). -- dan --- Brett Gavagni wrote: > Hi, > > The element illustrated in various > examples of the draft-9 > is not defined in either of the Enrollment or > Verification XML Schemas: > > I'm also wondering the rationale for the > inconsistency with the lack of > usage of the element for normal speech > recognition results. > > Shanmugham & Burnett Expires June 10, 2006 > [Page 109] > > Internet-Draft MRCPv2 > December 2005 > > > S->C: MRCP/2.0 465 RECOGNITION-COMPLETE 543257 > COMPLETE > > Channel-Identifier:32AECB23433801@speechrecog > Completion-Cause:000 success > Content-Type:application/nlsml+xml > Content-Length:123 > > > > xmlns:mrcp="http://www.ietf.org/xml/ns/mrcpv2"> > /> > > 2 > 1 > > > 1 > > consistent > > > Jeff > Andre > > > m ay b r ow k er > > m ax r aa k ah > > > > > call > 10 > > > > > > > Shanmugham & Burnett Expires June 10, 2006 > [Page 136] > > Internet-Draft MRCPv2 > December 2005 > > > > xmlns:mrcp="http://www.ietf.org/xml/ns/mrcpv2"> > > > > true > > 50 > cellular-phone > female > accepted > 0.98514 > > > > 1000 > cellular-phone > female > accepted > > 0.91725 > > > > > 0.93410 > > > > > > 0.74209 > > > > > > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > (561) 862-2097 T/L (975) > gavagni@us.ibm.com > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Sep 05 09:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKaZP-00043u-6R; Tue, 05 Sep 2006 09:02:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKaZN-0003wL-RP for speechsc@ietf.org; Tue, 05 Sep 2006 09:02:25 -0400 Received: from web32905.mail.mud.yahoo.com ([209.191.69.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GKaZM-0002qw-Ek for speechsc@ietf.org; Tue, 05 Sep 2006 09:02:25 -0400 Received: (qmail 96299 invoked by uid 60001); 5 Sep 2006 13:02:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6qNWYKUUuZ/Tf8sKg34itVwB7ywXnLIRmDbu5WT9EJvr9oRsb+UkxxzeGfN8P5wxxnfGi8u8fYzCYdDEKVRemNpToAZhloR8vKCwblrugD5mrQLE8QTwTlgzn9KBv9xSCDus7qZbSOROQQCtSYhLP0GSM/hl2xnRjsdyxtRsv30= ; Message-ID: <20060905130208.96297.qmail@web32905.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32905.mail.mud.yahoo.com via HTTP; Tue, 05 Sep 2006 06:02:08 PDT Date: Tue, 5 Sep 2006 06:02:08 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] Confusable-Phrases-URI clarification request To: Brett Gavagni , speechsc@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 This thread is tracked via issue 104 at https://www.softarmor.com/roundup/speechsc/ (currently deferred as a new feature request). -- dan --- Brett Gavagni wrote: > Is there a specific testcase or rationale which > required the limitation > for the "Confusable-Phrases-URI" header to occur > only in a RECOGNIZE > request. > > It would seem that the "Confusable-Phrases-URI" > should be valid to occur > in a START-PHRASE-ENROLLMENT request. > > 9.4.45. Confusable-Phrases-URI > > This header specifies a grammar that defines > invalid phrases for > enrollment. For example, typical applications do > not allow an > enrolled phrase that is also a command word. > This header MAY occur > in RECOGNIZE requests that are part of an > enrollement session. > > confusable-phrases-uri = > "Confusable-Phrases-URI" ":" Uri CRLF > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Sep 06 09:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKxuV-0003W5-Mt; Wed, 06 Sep 2006 09:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKxuT-0003SO-CN for speechsc@ietf.org; Wed, 06 Sep 2006 09:57:45 -0400 Received: from mmail.voxeo.com ([66.193.54.99] helo=voxeo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKxg9-0003U0-KA for speechsc@ietf.org; Wed, 06 Sep 2006 09:43:02 -0400 Received: from [66.193.54.250] (account rj HELO [172.16.240.104]) by voxeo.com (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 11319034; Wed, 06 Sep 2006 09:41:44 -0400 In-Reply-To: <01C0B9926BC410459FE9AACE49B815023F55B7@PTPEVS106BA020.idc.cww.telecomitalia.it> References: <01C0B9926BC410459FE9AACE49B815023F55B7@PTPEVS106BA020.idc.cww.telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Auburn Subject: Re: [Speechsc] VoiceXML inputmodes property Date: Wed, 6 Sep 2006 09:42:39 -0400 To: Bergallo Patrizio X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Folks, Was this issue ever addressed? I agree with Patrizio that we need a better solution here. Thanks, RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Apr 3, 2006, at 10:27 AM, Bergallo Patrizio wrote: > > Hi, > some months ago there was a discussion on VoiceXML 'inputmodes' > property > implementability in MRCPv2 protocol (see > http://www1.ietf.org/mail-archive/web/speechsc/current/msg01497.html). > That thread was closed renaming 'START-OF-SPEECH' event in > 'START-OF-INPUT', adding 'input-type' header to it and clarifying > conditions under which START-OF-INPUT event has to be generated from > server. > > However, this solution seems not so good to us, for the following > reasons: > > - When both synthesis and recognition resources are involved in the > same > MRCPv2 session, START-OF-INPUT event generation causes internal SPEAK > interruption. If 'input-mode' header is not conform to inputmodes > property, VoiceXML client can only abort RECOGNIZE method and take > some > action (raise an error event? nomatch, noinput or others). On the > other > hand, even though only a RECOGNIZE is sent, a wrong grammar could be > matched (e.g. a DTFM grammar when the input mode was set to > "voice"); in > this case the VoiceXML interpreter could just recover the error > raising > e.g. a NO-MATCH event and reprompting the question to the user; an "a > priori" solution, allowing to ignore the not-requested modality, would > be much more effective. > > - In hotword recognition, START-OF-INPUT event is never generated, so > VoiceXML client receives RECOGNITION-COMPLETE event only, and if > result > is not conform to inputmodes property it can only raise an error event > (nomatch, noinput or others) > > - When external grammars are involved in VoiceXML pages, VoiceXML > client > might not to know whether they accept vocal or dtmf input: it cannot > activates grammars according to inputmode property. > > These are not conforming to VoiceXML specification: > > 6.3.6 Miscellaneous Properties > inputmodes > This property determines which input modality to use. The input > modes to > enable: dtmf and voice. On platforms that support both modes, > inputmodes > defaults to "dtmf voice". To disable speech recognition, set > inputmodes > to "dtmf". To disable DTMF, set it to "voice". One use for this > would be > to turn off speech recognition in noisy environments. Another would be > to conserve speech recognition resources by turning them off where the > input is always expected to be DTMF. This property does not control > the > activation of grammars. For instance, voice-only grammars may be > active > when the inputmode is restricted to DTMF. Those grammars would not be > matched, however, because the voice input modality is not active. > > For these reasons, we propose to add a new Recog-only header: > > Input Mode > > This header MAY be sent as part of the RECOGNIZE request in order to > determines which input modality to use. It can assume following > values: > "voice": dtmf input will be ignored from server > "dtmf": speech input will be ignored from server > "all": both dtmf and speech input will be analyzed from server. This > is > the default value if header is not specified > > input-mode = "Input-Mode" ":" modes CRLF > modes = "voice" / "dtmf" / "all" > > Alternatively, it is possible to reuse and extend the input type > header, > > in the following way: > > Input Type > > When the recognizer detects barge-inable input and generates a START- > OF-INPUT event, that event MUST carry this header field to specify > where the input that caused the barge-in was DTMF or speech. > > This header MAY also be sent as part of the RECOGNIZE request in > order to > determines which input modality to use. If its value is 'speech', > dtmf > input will be ignored from server. If its value is 'dtmf', speech > input will be ignored from server. If its value is 'all', both dtmf > and > speech input will be analyzed from server. If not specified, it > defaults > to 'all'. > > input-type = "Input-Type" ":" inputs CRLF > inputs = "speech" / "dtmf" / "all" > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ================================================ > 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 you > www.loquendo.com > ================================================ > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Sep 08 11:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLikJ-0004dt-Hl; Fri, 08 Sep 2006 11:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLikH-0004d4-Ss for speechsc@ietf.org; Fri, 08 Sep 2006 11:58:21 -0400 Received: from web32914.mail.mud.yahoo.com ([209.191.69.114]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLikF-0000zv-G9 for speechsc@ietf.org; Fri, 08 Sep 2006 11:58:21 -0400 Received: (qmail 49314 invoked by uid 60001); 8 Sep 2006 15:58:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XmF20Q941g8Z9qKeSYrCmJbtVyPOiiTzplgMZyqrNAGcfIHabdUvnME34YcFokqaT3GI1esFQli56/p7qbpisxSq3D7jt1UqpnWeMUqCT12UOXQLJual91QLq05ffnx9mHYUj+IRtDji/IOxiBGhFq4l6eK+FGuVtY5frdrN/Rg= ; Message-ID: <20060908155819.49312.qmail@web32914.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32914.mail.mud.yahoo.com via HTTP; Fri, 08 Sep 2006 08:58:18 PDT Date: Fri, 8 Sep 2006 08:58:18 -0700 (PDT) From: Dan Burnett Subject: RE: [Speechsc] What is the scope of MRCPv2 session To: santhana@huawei.com, "'IETF SPEECHSC \(E-mail\)'" In-Reply-To: <001d01c69149$c190cbd0$3305120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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 After carefully review your comments, Dave Oran's, and the text of draft -10, I think the key relevant text in 6.2.1 here is the following: "The unambiguous string (first part) MUST BE unique among the resource instances managed by the server and is common to all resource channels with that server established through a single SIP dialog." Since the example in section 4.2 uses a single SIP dialog to set up two resource channels with the same MRCP server, the prefix values must be the same. I have corrected the example to use the same prefix in the a=channel line for both resources. This correction will appear in draft -11. -- dan --- santhanakrishnan wrote: > Hi Oran, > > Thanks for your detailed explanation. It > clarifies enough of our > queries. > > But I would like to highlight the main source of > confusion again to you. > > > > Please refer the following section from the draft > > 6.2.1 > > All MRCPv2 requests, responses and events MUST > contain the Channel- > > Identifier header. The value is allocated by the > server when a > > control channel is added to the session and > communicated to the > > client by the "a=channel" attribute in the SDP > answer from the > > server. The header value consists of 2 parts > separated by the '@' > > symbol. The first part is an unambiguous string > identifying the > > MRCPv2 session. The second part is a string > token which specifies > > one of the media processing resource types listed > in Section 3.1. > > The unambiguous string (first part) MUST BE > unique among the resource > > instances managed by the server and is common to > all resource > > channels with that server established through a > single SIP dialog. > > > > Here it says the prefix (First part) identifies an > MRCPv2 session. > > > > But in the following example, the channel Id > returned by the Server > > for Synthesizer and Recognizer belonging to the same > MRCPv2 Session > > is shown with different prefix(First Part). > > > > S->C: SIP/2.0 200 OK > > Via:SIP/2.0/TCP > client.atlanta.example.com:5060; > > branch=z9hG4bK74bf9 > > To:MediaServer > > > ........................................ > > v=0 > > o=sarvi 2890844526 2890842809 IN IP4 > 126.16.64.4 > > s=- > > c=IN IP4 224.2.17.12 > > m=application 32416 TCP/MRCPv2 > > a=setup:passive > > a=connection:existing > > a=channel:32AECB234338@speechrecog > > a=cmid:1 > > m=application 32416 TCP/MRCPv2 > > a=setup:passive > > a=connection:existing > > a=channel:32AECB234339@speechsynth > > a=cmid:1 > > m=audio 48260 RTP/AVP 0 96 > > a=rtpmap:0 pcmu/8000 > > a=rtpmap:96 telephone-event/8000 > > a=fmtp:96 0-15 > > a=sendrecv > > a=mid:1 > > > > Here I wonder either the example or the draft > statement seems to be > incorrect. > > Please clarify on this. > > > > Regards, > > Santhanakrishnan; > > > > > > > > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Friday, June 16, 2006 2:37 AM > To: IETF SPEECHSC (E-mail) > Subject: Re: [Speechsc] What is the scope of MRCPv2 > session > > > > > > On Jun 13, 2006, at 5:01 AM, Burger, Eric wrote: > > > > > Do we need to tighten the language? Maybe > introduce a new term? > > > Pick two from the set {MRCPv2, SIP, control, media > control, > > > resource control, or something else descriptive of > your choice}. > > > > > > > > > > > Please follow-up to the list with your thoughts. > > > > > > > > Well, this all seems clear to me, but I can > certainly see how a > > newcomer would have his head spinning unless they > were already very > > conversant in SIP, SDP, and in the architectural > structure of MRCP. > > > > The relationships are (unless I'm REALLY confused). > > 1. SIP is used to establish and maintain a SIP > dialog with a SIP UA > > acting on behalf of an MRCP server. > > 2. Within that dialog, SDP offer-answer has been > used to negotiate > > one *or more* MRCP Sessions. Each of these is > described with a > > separate m= line in the SDP. In SDP terminology, > each constitutes a > > === message truncated ===> _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Sep 08 12:08:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiuA-0000SK-Rs; Fri, 08 Sep 2006 12:08:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLiu9-0000SF-Fx for speechsc@ietf.org; Fri, 08 Sep 2006 12:08:33 -0400 Received: from web32902.mail.mud.yahoo.com ([209.191.69.79]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLiu6-0001xt-SM for speechsc@ietf.org; Fri, 08 Sep 2006 12:08:33 -0400 Received: (qmail 14287 invoked by uid 60001); 8 Sep 2006 16:08:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R8IIcUSkVpWYgnAAfTht8yXrqi9DBDBipYwy7BiOt41+SwTCOSiV1urrhPDQ3ikIsZW2vWS4lzT+QOhk8swWexX+ftBp+1njIq+x7DqZvNATRlTEmJXFg9t0Zvb5ecqrqvEVzmJR9SjvDJt9+B2somJwNF6qekmOb3agZthZ7jI= ; Message-ID: <20060908160830.14285.qmail@web32902.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32902.mail.mud.yahoo.com via HTTP; Fri, 08 Sep 2006 09:08:30 PDT Date: Fri, 8 Sep 2006 09:08:30 -0700 (PDT) From: Dan Burnett Subject: RE: [Speechsc] What is the scope of MRCPv2 session To: santhana@huawei.com, "'IETF SPEECHSC \(E-mail\)'" In-Reply-To: <20060908155819.49312.qmail@web32914.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 I also updated the examples in 14.1 as well (both the a=channel lines and the Channel-Identifier values). -- dan --- Dan Burnett wrote: > After carefully review your comments, Dave Oran's, > and > the text of draft -10, I think the key relevant text > in 6.2.1 here is the following: > > "The unambiguous string (first part) MUST BE unique > among the resource instances managed by the server > and > is common to all resource channels with that server > established through a single SIP dialog." > > Since the example in section 4.2 uses a single SIP > dialog to set up two resource channels with the same > MRCP server, the prefix values must be the same. I > have corrected the example to use the same prefix in > the a=channel line for both resources. This > correction will appear in draft -11. > > -- dan > > > --- santhanakrishnan wrote: > > > Hi Oran, > > > > Thanks for your detailed explanation. It > > clarifies enough of our > > queries. > > > > But I would like to highlight the main source of > > confusion again to you. > > > > > > > > Please refer the following section from the draft > > > > 6.2.1 > > > > All MRCPv2 requests, responses and events MUST > > contain the Channel- > > > > Identifier header. The value is allocated by > the > > server when a > > > > control channel is added to the session and > > communicated to the > > > > client by the "a=channel" attribute in the SDP > > answer from the > > > > server. The header value consists of 2 parts > > separated by the '@' > > > > symbol. The first part is an unambiguous > string > > identifying the > > > > MRCPv2 session. The second part is a string > > token which specifies > > > > one of the media processing resource types > listed > > in Section 3.1. > > > > The unambiguous string (first part) MUST BE > > unique among the resource > > > > instances managed by the server and is common > to > > all resource > > > > channels with that server established through a > > single SIP dialog. > > > > > > > > Here it says the prefix (First part) identifies an > > MRCPv2 session. > > > > > > > > But in the following example, the channel Id > > returned by the Server > > > > for Synthesizer and Recognizer belonging to the > same > > MRCPv2 Session > > > > is shown with different prefix(First Part). > > > > > > > > S->C: SIP/2.0 200 OK > > > > Via:SIP/2.0/TCP > > client.atlanta.example.com:5060; > > > > branch=z9hG4bK74bf9 > > > > To:MediaServer > > > > > > ........................................ > > > > v=0 > > > > o=sarvi 2890844526 2890842809 IN IP4 > > 126.16.64.4 > > > > s=- > > > > c=IN IP4 224.2.17.12 > > > > m=application 32416 TCP/MRCPv2 > > > > a=setup:passive > > > > a=connection:existing > > > > a=channel:32AECB234338@speechrecog > > > > a=cmid:1 > > > > m=application 32416 TCP/MRCPv2 > > > > a=setup:passive > > > > a=connection:existing > > > > a=channel:32AECB234339@speechsynth > > > > a=cmid:1 > > > > m=audio 48260 RTP/AVP 0 96 > > > > a=rtpmap:0 pcmu/8000 > > > > a=rtpmap:96 telephone-event/8000 > > > > a=fmtp:96 0-15 > > > > a=sendrecv > > > > a=mid:1 > > > > > > > > Here I wonder either the example or the draft > > statement seems to be > > incorrect. > > > > Please clarify on this. > > > > > > > > Regards, > > > > Santhanakrishnan; > > > > > > > > > > > > > > > > -----Original Message----- > > From: David R Oran [mailto:oran@cisco.com] > > Sent: Friday, June 16, 2006 2:37 AM > > To: IETF SPEECHSC (E-mail) > > Subject: Re: [Speechsc] What is the scope of > MRCPv2 > > session > > > > > > > > > > > > On Jun 13, 2006, at 5:01 AM, Burger, Eric wrote: > > > > > > > > > Do we need to tighten the language? Maybe > > introduce a new term? > > > > > Pick two from the set {MRCPv2, SIP, control, > media > > control, > > > > > resource control, or something else descriptive > of > > your choice}. > > > > > > > > > > > > > > > > > > > Please follow-up to the list with your thoughts. > > > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Sep 08 14:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLl1s-0007DH-GZ; Fri, 08 Sep 2006 14:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLl1r-000793-N9 for speechsc@ietf.org; Fri, 08 Sep 2006 14:24:39 -0400 Received: from web32910.mail.mud.yahoo.com ([209.191.69.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLl1q-0006Wd-DB for speechsc@ietf.org; Fri, 08 Sep 2006 14:24:39 -0400 Received: (qmail 3745 invoked by uid 60001); 8 Sep 2006 18:24:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V9HJTyzYay+lFF/jReKD+ElpzLekb7HiokMjYx558AYS9xSz1ThZcSOZvBEvNR8AZ5/24HKUMkdEmHyWHEQbIRDdhs6emp876ewkvsGn2ntIimrKrLtAlGHg234+NETjt/ZVIBPuer31pBVmbUSCAkmkuUdMLTvDfkUG2pzYTxA= ; Message-ID: <20060908182437.3743.qmail@web32910.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32910.mail.mud.yahoo.com via HTTP; Fri, 08 Sep 2006 11:24:37 PDT Date: Fri, 8 Sep 2006 11:24:37 -0700 (PDT) From: Dan Burnett Subject: RE: [speechsc] SPEAK error and effect on queue To: speechsc@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 In draft -11 I have - Added the following text to section 8.6, paragraph 5: "If the current SPEAK fails, all SPEAK methods in the pending queue are cancelled and each generates a SPEAK-COMPLETE event with a Completion-Cause of "cancelled"." - Added a new SPEAK Completion-Cause of "007 cancelled". - Added to RECOGNIZE Completion-Cause table entry for "011 cancelled" the text: ", or a prior RECOGNIZE failed while this one was still in the queue." -- dan --- "Saravanan Shanmugham (sarvi)" wrote: > makes sense. I agree this should be done. > > Sarvi > > > ________________________________ > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Sunday, June 18, 2006 5:38 AM > To: speechsc@ietf.org > Subject: [speechsc] SPEAK error and effect on queue > > > The spec doesn't appear to specify what happens if > an > IN-PROGRESS SPEAK request terminates with an error > and there are N > requests behind it in the queue. With the speech > recogniser resource, > and assuming Cancel-If-Queue: false, the remaining > N requests terminate > with status "011 cancelled". I'm pretty sure the > intent is for the > speech synthesiser resource to do the same. If so, > this suggests a > clarification in para 5 in section 8.6 and a new > Completion-Cause of > "007 cancelled". > > Dave > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Sep 08 14:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLl8U-000186-GS; Fri, 08 Sep 2006 14:31:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLl8T-00017w-Ey for speechsc@ietf.org; Fri, 08 Sep 2006 14:31:29 -0400 Received: from web32904.mail.mud.yahoo.com ([209.191.69.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLl8R-0007ed-1q for speechsc@ietf.org; Fri, 08 Sep 2006 14:31:29 -0400 Received: (qmail 79414 invoked by uid 60001); 8 Sep 2006 18:31:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CXWsaCfJ0esEYZqivNv5vTs/CvoLiclOF2o3OONWg/vo9gL94uGLJ7zZBEGYEJPpJUXix0826BkVvL/41Jjkg/R8MP8kvbqRGDirwQY7mVZ+uxytbJHr58IxpAdMqt9AsxbdQSuf4mprNZ2dsve/nMMcHiQ3AM+BiV77DUbxoUM= ; Message-ID: <20060908183126.79412.qmail@web32904.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32904.mail.mud.yahoo.com via HTTP; Fri, 08 Sep 2006 11:31:26 PDT Date: Fri, 8 Sep 2006 11:31:26 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] query regarding multiple resources in a MRCP clientsession To: sreekanth In-Reply-To: <002201c6c126$290ffef0$4a05120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 The example has been corrected in the upcoming draft -11. See http://www1.ietf.org/mail-archive/web/speechsc/current/msg01968.html. -- dan --- sreekanth wrote: > Hi klaus, > > As per the MRCPv2 spec , it is not possible to > have two Recognition resources in a single MRCP > Session. > > "For implementations where a single recognition > resource does not support both modes, or > simultaneous normal and hotword recognition is > desired, the two modes can be invoked through > separate resources allocated to the same SIP dialog > (with different MRCP session identifiers) and share > the RTP audio feed." > > I have one more query regarding the channel > Identifier header. Suppose if a ASR and a TTS are > part of one SIP dialog, then the channel identifiers > for these control channels should have the same > intial unambiguous string part. But the following > example of the specification contradicts to this > understanding > The sample from draft 10 (page 168) is: > > S->C: > > SIP/2.0 200 OK > > To:MediaServer > > From:sarvi ;tag=1928301774 > > Call-ID:a84b4c76e66710 > > CSeq:314163 INVITE > > Contact: > > Content-Type:application/sdp > > Content-Length:131 > > v=0 > > o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 > > s=SDP Seminar > > i=A session for processing media > > c=IN IP4 224.2.17.12/127 > > m=application 32416 TCP/MRCPv2 > > a=channel:32AECB23433801@speechsynth > > a=cmid:1 > > m=audio 48260 RTP/AVP 0 > > a=rtpmap:0 pcmu/8000 > > a=sendonly > > a=mid:1 > > m=application 32416 TCP/MRCPv2 > > a=channel:32AECB23433802@speechrecog > > a=cmid:2 > > m=audio 48260 RTP/AVP 0 > > a=rtpmap:0 pcmu/8000 > > a=rtpmap:96 telephone-event/8000 > > a=fmtp:96 0-15 > > a=recvonly > > a=mid:2 > > > > Any clarifications on this will be highly > appreciated. > > > > > > > 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! > > > ----- Original Message ----- > From: Reifenrath, Klaus, VF-Group > To: sreekanth ; speechsc@ietf.org > Cc: sarvi@cisco.com > Sent: Monday, June 26, 2006 1:22 PM > Subject: RE: [Speechsc] query regarding multiple > resources in a MRCP clientsession > > > Hi Sreekanth, > > yes there are use-cases for that, e.g. to run a > hotword recognition session in parallel with a > "normal" recognition session. > > Regards, > Klaus > > > > ---------------------------------------------------------------------------- > From: sreekanth [mailto:sreekanthm@huawei.com] > Sent: Montag, 26. Juni 2006 07:30 > To: speechsc@ietf.org > Cc: sarvi@cisco.com > Subject: [Speechsc] query regarding multiple > resources in a MRCP clientsession > > > Hi, > > Is there any use case in having two resouces of > the same type(eg: two TTS) in a single MRCP > session???? > > Regards, > Sreekanth > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sun Sep 10 14:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMU65-0000vN-Ca; Sun, 10 Sep 2006 14:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMU63-0000r6-J5 for speechsc@ietf.org; Sun, 10 Sep 2006 14:31:59 -0400 Received: from [87.198.5.178] (helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMU60-0007CD-1Q for speechsc@ietf.org; Sun, 10 Sep 2006 14:31:57 -0400 Received: by mail.voxpilot.com (Postfix, from userid 552) id D9FC52140F1; Sun, 10 Sep 2006 18:31:38 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on db01ms01 X-Spam-Status: No, score=-4.3 required=5.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 496102140EE; Sun, 10 Sep 2006 18:31:35 +0000 (GMT) Message-ID: <047c01c6d507$51142580$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Dan Burnett" , , "'IETF SPEECHSC (E-mail)'" References: <20060908160830.14285.qmail@web32902.mail.mud.yahoo.com> Subject: Re: [Speechsc] What is the scope of MRCPv2 session Date: Sun, 10 Sep 2006 19:31:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 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 I'm fine with this clarification (i.e. that the text in 6.2.1 is indeed correct). Are we all agreed, however, that as a consequence, the client cannot allocate more than one instance of the same resource type within a given SIP dialog? (If this was allowed and the text in 6.2.1 applied, the channel identifier would be the same for both resources and it would be impossible to disambiguate messages from the two resources). To completely address this thread, there are two more adjustments needed: 1. The use-case of using two speechrecog resources (one in normal mode and the other in hotword) can only be realised using separate SIP dialogs. In section 9, change "same" to "separate": ... "the two modes can be invoked through separate resources allocated to the same SIP dialog" 2. What happens if the client attempts to establish two or more resources of the same type within a single SIP dialog? Presumably, 488 Not Acceptable Here? This error and the the restriction as a consequence of 6.2.1 should be called out. Dave ----- Original Message ----- From: "Dan Burnett" To: ; "'IETF SPEECHSC (E-mail)'" Sent: Friday, September 08, 2006 5:08 PM Subject: RE: [Speechsc] What is the scope of MRCPv2 session >I also updated the examples in 14.1 as well (both the > a=channel lines and the Channel-Identifier values). > > -- dan > > --- Dan Burnett wrote: > >> After carefully review your comments, Dave Oran's, >> and >> the text of draft -10, I think the key relevant text >> in 6.2.1 here is the following: >> >> "The unambiguous string (first part) MUST BE unique >> among the resource instances managed by the server >> and >> is common to all resource channels with that server >> established through a single SIP dialog." >> >> Since the example in section 4.2 uses a single SIP >> dialog to set up two resource channels with the same >> MRCP server, the prefix values must be the same. I >> have corrected the example to use the same prefix in >> the a=channel line for both resources. This >> correction will appear in draft -11. >> >> -- dan >> >> >> --- santhanakrishnan wrote: >> >> > Hi Oran, >> > >> > Thanks for your detailed explanation. It >> > clarifies enough of our >> > queries. >> > >> > But I would like to highlight the main source of >> > confusion again to you. >> > >> > >> > >> > Please refer the following section from the draft >> > >> > 6.2.1 >> > >> > All MRCPv2 requests, responses and events MUST >> > contain the Channel- >> > >> > Identifier header. The value is allocated by >> the >> > server when a >> > >> > control channel is added to the session and >> > communicated to the >> > >> > client by the "a=channel" attribute in the SDP >> > answer from the >> > >> > server. The header value consists of 2 parts >> > separated by the '@' >> > >> > symbol. The first part is an unambiguous >> string >> > identifying the >> > >> > MRCPv2 session. The second part is a string >> > token which specifies >> > >> > one of the media processing resource types >> listed >> > in Section 3.1. >> > >> > The unambiguous string (first part) MUST BE >> > unique among the resource >> > >> > instances managed by the server and is common >> to >> > all resource >> > >> > channels with that server established through a >> > single SIP dialog. >> > >> > >> > >> > Here it says the prefix (First part) identifies an >> > MRCPv2 session. >> > >> > >> > >> > But in the following example, the channel Id >> > returned by the Server >> > >> > for Synthesizer and Recognizer belonging to the >> same >> > MRCPv2 Session >> > >> > is shown with different prefix(First Part). >> > >> > >> > >> > S->C: SIP/2.0 200 OK >> > >> > Via:SIP/2.0/TCP >> > client.atlanta.example.com:5060; >> > >> > branch=z9hG4bK74bf9 >> > >> > To:MediaServer >> > >> > >> > ........................................ >> > >> > v=0 >> > >> > o=sarvi 2890844526 2890842809 IN IP4 >> > 126.16.64.4 >> > >> > s=- >> > >> > c=IN IP4 224.2.17.12 >> > >> > m=application 32416 TCP/MRCPv2 >> > >> > a=setup:passive >> > >> > a=connection:existing >> > >> > a=channel:32AECB234338@speechrecog >> > >> > a=cmid:1 >> > >> > m=application 32416 TCP/MRCPv2 >> > >> > a=setup:passive >> > >> > a=connection:existing >> > >> > a=channel:32AECB234339@speechsynth >> > >> > a=cmid:1 >> > >> > m=audio 48260 RTP/AVP 0 96 >> > >> > a=rtpmap:0 pcmu/8000 >> > >> > a=rtpmap:96 telephone-event/8000 >> > >> > a=fmtp:96 0-15 >> > >> > a=sendrecv >> > >> > a=mid:1 >> > >> > >> > >> > Here I wonder either the example or the draft >> > statement seems to be >> > incorrect. >> > >> > Please clarify on this. >> > >> > >> > >> > Regards, >> > >> > Santhanakrishnan; >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: David R Oran [mailto:oran@cisco.com] >> > Sent: Friday, June 16, 2006 2:37 AM >> > To: IETF SPEECHSC (E-mail) >> > Subject: Re: [Speechsc] What is the scope of >> MRCPv2 >> > session >> > >> > >> > >> > >> > >> > On Jun 13, 2006, at 5:01 AM, Burger, Eric wrote: >> > >> > >> > >> > > Do we need to tighten the language? Maybe >> > introduce a new term? >> > >> > > Pick two from the set {MRCPv2, SIP, control, >> media >> > control, >> > >> > > resource control, or something else descriptive >> of >> > your choice}. >> > >> > >> > >> > > >> > >> > > >> > >> > > Please follow-up to the list with your thoughts. >> > >> > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sun Sep 10 15:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMUln-00086g-EQ; Sun, 10 Sep 2006 15:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMUlk-00083T-HC for speechsc@ietf.org; Sun, 10 Sep 2006 15:15:04 -0400 Received: from [87.198.5.178] (helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMUj8-00059U-Fl for speechsc@ietf.org; Sun, 10 Sep 2006 15:12:25 -0400 Received: by mail.voxpilot.com (Postfix, from userid 552) id A49CA2140F3; Sun, 10 Sep 2006 19:12:21 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on db01ms01 X-Spam-Status: No, score=-4.3 required=5.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id 6C7312140EE; Sun, 10 Sep 2006 19:12:17 +0000 (GMT) Message-ID: <048601c6d50d$00b54a50$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "RJ Auburn" , "Bergallo Patrizio" References: <01C0B9926BC410459FE9AACE49B815023F55B7@PTPEVS106BA020.idc.cww.telecomitalia.it> Subject: Re: [Speechsc] VoiceXML inputmodes property Date: Sun, 10 Sep 2006 20:12:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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 As I recall, the thread was left with the assumption that a VoiceXML interpreter context would only activate the grammar types according to its inputmodes property. This addresses Patrizio's issues except for: 1. How does the VoiceXML interpreter know the grammar types without introspection? 2. How can a grammar be activated without input for that mode being activated? Certainly, 2 is a VoiceXML-oddity and in practice a rare edge case - I took the pragmatic view to just ignore it. That leaves 1 and there are some solutions e.g. perform a partial download of the grammar to check the mode attribute and cache that type subject to HTTP rules; or perform a HEAD and look for a custom parameter on the MIME type to indicate the mode; or download the entire grammar and use DEFINE-GRAMMAR or serve up via internal Webserver. Of course, none are particularly satisfying. I am certainly fine with adding an Input-Mode header field and removing the sentence in section 9 "By analyzing the grammars that are activated by...". In this case, note that the Input-Mode header is ignored for dtmfrecog resources and a value of dtmf for speechrecog resources not supporting DTMF results in a 404 Illegal Value for Header. Dave ----- Original Message ----- From: "RJ Auburn" To: "Bergallo Patrizio" Cc: Sent: Wednesday, September 06, 2006 2:42 PM Subject: Re: [Speechsc] VoiceXML inputmodes property > Folks, > > Was this issue ever addressed? I agree with Patrizio that we need a > better solution here. > > Thanks, > > RJ > --- > RJ Auburn > CTO, Voxeo Corporation > tel:+1-407-418-1800 > > > > On Apr 3, 2006, at 10:27 AM, Bergallo Patrizio wrote: > >> >> Hi, >> some months ago there was a discussion on VoiceXML 'inputmodes' property >> implementability in MRCPv2 protocol (see >> http://www1.ietf.org/mail-archive/web/speechsc/current/msg01497.html). >> That thread was closed renaming 'START-OF-SPEECH' event in >> 'START-OF-INPUT', adding 'input-type' header to it and clarifying >> conditions under which START-OF-INPUT event has to be generated from >> server. >> >> However, this solution seems not so good to us, for the following >> reasons: >> >> - When both synthesis and recognition resources are involved in the same >> MRCPv2 session, START-OF-INPUT event generation causes internal SPEAK >> interruption. If 'input-mode' header is not conform to inputmodes >> property, VoiceXML client can only abort RECOGNIZE method and take some >> action (raise an error event? nomatch, noinput or others). On the other >> hand, even though only a RECOGNIZE is sent, a wrong grammar could be >> matched (e.g. a DTFM grammar when the input mode was set to "voice"); in >> this case the VoiceXML interpreter could just recover the error raising >> e.g. a NO-MATCH event and reprompting the question to the user; an "a >> priori" solution, allowing to ignore the not-requested modality, would >> be much more effective. >> >> - In hotword recognition, START-OF-INPUT event is never generated, so >> VoiceXML client receives RECOGNITION-COMPLETE event only, and if result >> is not conform to inputmodes property it can only raise an error event >> (nomatch, noinput or others) >> >> - When external grammars are involved in VoiceXML pages, VoiceXML client >> might not to know whether they accept vocal or dtmf input: it cannot >> activates grammars according to inputmode property. >> >> These are not conforming to VoiceXML specification: >> >> 6.3.6 Miscellaneous Properties >> inputmodes >> This property determines which input modality to use. The input modes to >> enable: dtmf and voice. On platforms that support both modes, inputmodes >> defaults to "dtmf voice". To disable speech recognition, set inputmodes >> to "dtmf". To disable DTMF, set it to "voice". One use for this would be >> to turn off speech recognition in noisy environments. Another would be >> to conserve speech recognition resources by turning them off where the >> input is always expected to be DTMF. This property does not control the >> activation of grammars. For instance, voice-only grammars may be active >> when the inputmode is restricted to DTMF. Those grammars would not be >> matched, however, because the voice input modality is not active. >> >> For these reasons, we propose to add a new Recog-only header: >> >> Input Mode >> >> This header MAY be sent as part of the RECOGNIZE request in order to >> determines which input modality to use. It can assume following >> values: >> "voice": dtmf input will be ignored from server >> "dtmf": speech input will be ignored from server >> "all": both dtmf and speech input will be analyzed from server. This >> is >> the default value if header is not specified >> >> input-mode = "Input-Mode" ":" modes CRLF >> modes = "voice" / "dtmf" / "all" >> >> Alternatively, it is possible to reuse and extend the input type header, >> >> in the following way: >> >> Input Type >> >> When the recognizer detects barge-inable input and generates a START- >> OF-INPUT event, that event MUST carry this header field to specify >> where the input that caused the barge-in was DTMF or speech. >> >> This header MAY also be sent as part of the RECOGNIZE request in >> order to >> determines which input modality to use. If its value is 'speech', >> dtmf >> input will be ignored from server. If its value is 'dtmf', speech >> input will be ignored from server. If its value is 'all', both dtmf >> and >> speech input will be analyzed from server. If not specified, it >> defaults >> to 'all'. >> >> input-type = "Input-Type" ":" inputs CRLF >> inputs = "speech" / "dtmf" / "all" >> >> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia >> S.p.A. >> >> ================================================ >> 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 you >> www.loquendo.com >> ================================================ >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Sep 11 04:58:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMhcL-0007wy-4X; Mon, 11 Sep 2006 04:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMhcK-0007wt-Rt for speechsc@ietf.org; Mon, 11 Sep 2006 04:58:12 -0400 Received: from mmail.voxeo.com ([66.193.54.99] helo=voxeo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMhcJ-0003V1-CB for speechsc@ietf.org; Mon, 11 Sep 2006 04:58:12 -0400 Received: from [68.202.134.111] (account rj HELO [192.168.103.107]) by voxeo.com (CommuniGate Pro SMTP 5.0.8) with ESMTPSA id 11431297; Mon, 11 Sep 2006 04:56:30 -0400 In-Reply-To: <048601c6d50d$00b54a50$0a01a8c0@db01.voxpilot.com> References: <01C0B9926BC410459FE9AACE49B815023F55B7@PTPEVS106BA020.idc.cww.telecomitalia.it> <048601c6d50d$00b54a50$0a01a8c0@db01.voxpilot.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Auburn Subject: Re: [Speechsc] VoiceXML inputmodes property Date: Mon, 11 Sep 2006 04:57:40 -0400 To: Dave Burke X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: speechsc@ietf.org, Bergallo Patrizio 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 I would strongly like to add the Input-Mode header as there are all sorts of other problems that can arrive when you start the double download approach. RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Sep 10, 2006, at 15:12 PM, Dave Burke wrote: > As I recall, the thread was left with the assumption that a > VoiceXML interpreter context would only activate the grammar types > according to its inputmodes property. This addresses Patrizio's > issues except for: > 1. How does the VoiceXML interpreter know the grammar types without > introspection? > 2. How can a grammar be activated without input for that mode being > activated? > > Certainly, 2 is a VoiceXML-oddity and in practice a rare edge case > - I took the pragmatic view to just ignore it. That leaves 1 and > there are some solutions e.g. perform a partial download of the > grammar to check the mode attribute and cache that type subject to > HTTP rules; or perform a HEAD and look for a custom parameter on > the MIME type to indicate the mode; or download the entire grammar > and use DEFINE-GRAMMAR or serve up via internal Webserver. Of > course, none are particularly satisfying. > > I am certainly fine with adding an Input-Mode header field and > removing the sentence in section 9 "By analyzing the grammars that > are activated by...". In this case, note that the Input-Mode header > is ignored for dtmfrecog resources and a value of dtmf for > speechrecog resources not supporting DTMF results in a 404 Illegal > Value for Header. > > Dave > > ----- Original Message ----- From: "RJ Auburn" > To: "Bergallo Patrizio" > Cc: > Sent: Wednesday, September 06, 2006 2:42 PM > Subject: Re: [Speechsc] VoiceXML inputmodes property > > >> Folks, >> >> Was this issue ever addressed? I agree with Patrizio that we need >> a better solution here. >> >> Thanks, >> >> RJ >> --- >> RJ Auburn >> CTO, Voxeo Corporation >> tel:+1-407-418-1800 >> >> >> >> On Apr 3, 2006, at 10:27 AM, Bergallo Patrizio wrote: >> >>> >>> Hi, >>> some months ago there was a discussion on VoiceXML 'inputmodes' >>> property >>> implementability in MRCPv2 protocol (see >>> http://www1.ietf.org/mail-archive/web/speechsc/current/ >>> msg01497.html). >>> That thread was closed renaming 'START-OF-SPEECH' event in >>> 'START-OF-INPUT', adding 'input-type' header to it and clarifying >>> conditions under which START-OF-INPUT event has to be generated from >>> server. >>> >>> However, this solution seems not so good to us, for the following >>> reasons: >>> >>> - When both synthesis and recognition resources are involved in >>> the same >>> MRCPv2 session, START-OF-INPUT event generation causes internal >>> SPEAK >>> interruption. If 'input-mode' header is not conform to inputmodes >>> property, VoiceXML client can only abort RECOGNIZE method and >>> take some >>> action (raise an error event? nomatch, noinput or others). On >>> the other >>> hand, even though only a RECOGNIZE is sent, a wrong grammar could be >>> matched (e.g. a DTFM grammar when the input mode was set to >>> "voice"); in >>> this case the VoiceXML interpreter could just recover the error >>> raising >>> e.g. a NO-MATCH event and reprompting the question to the user; >>> an "a >>> priori" solution, allowing to ignore the not-requested modality, >>> would >>> be much more effective. >>> >>> - In hotword recognition, START-OF-INPUT event is never >>> generated, so >>> VoiceXML client receives RECOGNITION-COMPLETE event only, and if >>> result >>> is not conform to inputmodes property it can only raise an error >>> event >>> (nomatch, noinput or others) >>> >>> - When external grammars are involved in VoiceXML pages, >>> VoiceXML client >>> might not to know whether they accept vocal or dtmf input: it cannot >>> activates grammars according to inputmode property. >>> >>> These are not conforming to VoiceXML specification: >>> >>> 6.3.6 Miscellaneous Properties >>> inputmodes >>> This property determines which input modality to use. The input >>> modes to >>> enable: dtmf and voice. On platforms that support both modes, >>> inputmodes >>> defaults to "dtmf voice". To disable speech recognition, set >>> inputmodes >>> to "dtmf". To disable DTMF, set it to "voice". One use for this >>> would be >>> to turn off speech recognition in noisy environments. Another >>> would be >>> to conserve speech recognition resources by turning them off >>> where the >>> input is always expected to be DTMF. This property does not >>> control the >>> activation of grammars. For instance, voice-only grammars may be >>> active >>> when the inputmode is restricted to DTMF. Those grammars would >>> not be >>> matched, however, because the voice input modality is not active. >>> >>> For these reasons, we propose to add a new Recog-only header: >>> >>> Input Mode >>> >>> This header MAY be sent as part of the RECOGNIZE request in order to >>> determines which input modality to use. It can assume following >>> values: >>> "voice": dtmf input will be ignored from server >>> "dtmf": speech input will be ignored from server >>> "all": both dtmf and speech input will be analyzed from server. This >>> is >>> the default value if header is not specified >>> >>> input-mode = "Input-Mode" ":" modes CRLF >>> modes = "voice" / "dtmf" / "all" >>> >>> Alternatively, it is possible to reuse and extend the input type >>> header, >>> >>> in the following way: >>> >>> Input Type >>> >>> When the recognizer detects barge-inable input and generates a >>> START- >>> OF-INPUT event, that event MUST carry this header field to specify >>> where the input that caused the barge-in was DTMF or speech. >>> >>> This header MAY also be sent as part of the RECOGNIZE request in >>> order to >>> determines which input modality to use. If its value is 'speech', >>> dtmf >>> input will be ignored from server. If its value is 'dtmf', speech >>> input will be ignored from server. If its value is 'all', both dtmf >>> and >>> speech input will be analyzed from server. If not specified, it >>> defaults >>> to 'all'. >>> >>> input-type = "Input-Type" ":" inputs CRLF >>> inputs = "speech" / "dtmf" / "all" >>> >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom >>> Italia S.p.A. >>> >>> ================================================ >>> 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 you >>> www.loquendo.com >>> ================================================ >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Sep 11 09:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlad-0006TU-Iu; Mon, 11 Sep 2006 09:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlac-0006RL-0R for speechsc@ietf.org; Mon, 11 Sep 2006 09:12:42 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMlaa-00074H-8B for speechsc@ietf.org; Mon, 11 Sep 2006 09:12:41 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k8BDCb4r024170 for ; Mon, 11 Sep 2006 09:12:37 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8BDCbqZ191384 for ; Mon, 11 Sep 2006 07:12:37 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8BDCbck024510 for ; Mon, 11 Sep 2006 07:12:37 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8BDCb1f024507; Mon, 11 Sep 2006 07:12:37 -0600 In-Reply-To: To: RJ Auburn Subject: Re: [Speechsc] VoiceXML inputmodes property MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Brett Gavagni Date: Mon, 11 Sep 2006 09:12:35 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/11/2006 07:12:37, Serialize complete at 09/11/2006 07:12:37 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: speechsc@ietf.org, Bergallo Patrizio , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org I agree with RJ, as I'm also not an advocate of the double-dip download approach. =) We had a discussion a while back that listed a couple of other possible MRCP options of exploration to support the VoiceXML inputmodes property: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01240.html Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com RJ Auburn 09/11/2006 04:57 AM To Dave Burke cc speechsc@ietf.org, Bergallo Patrizio Subject Re: [Speechsc] VoiceXML inputmodes property I would strongly like to add the Input-Mode header as there are all sorts of other problems that can arrive when you start the double download approach. RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Sep 10, 2006, at 15:12 PM, Dave Burke wrote: > As I recall, the thread was left with the assumption that a > VoiceXML interpreter context would only activate the grammar types > according to its inputmodes property. This addresses Patrizio's > issues except for: > 1. How does the VoiceXML interpreter know the grammar types without > introspection? > 2. How can a grammar be activated without input for that mode being > activated? > > Certainly, 2 is a VoiceXML-oddity and in practice a rare edge case > - I took the pragmatic view to just ignore it. That leaves 1 and > there are some solutions e.g. perform a partial download of the > grammar to check the mode attribute and cache that type subject to > HTTP rules; or perform a HEAD and look for a custom parameter on > the MIME type to indicate the mode; or download the entire grammar > and use DEFINE-GRAMMAR or serve up via internal Webserver. Of > course, none are particularly satisfying. > > I am certainly fine with adding an Input-Mode header field and > removing the sentence in section 9 "By analyzing the grammars that > are activated by...". In this case, note that the Input-Mode header > is ignored for dtmfrecog resources and a value of dtmf for > speechrecog resources not supporting DTMF results in a 404 Illegal > Value for Header. > > Dave > > ----- Original Message ----- From: "RJ Auburn" > To: "Bergallo Patrizio" > Cc: > Sent: Wednesday, September 06, 2006 2:42 PM > Subject: Re: [Speechsc] VoiceXML inputmodes property > > >> Folks, >> >> Was this issue ever addressed? I agree with Patrizio that we need >> a better solution here. >> >> Thanks, >> >> RJ >> --- >> RJ Auburn >> CTO, Voxeo Corporation >> tel:+1-407-418-1800 >> >> >> >> On Apr 3, 2006, at 10:27 AM, Bergallo Patrizio wrote: >> >>> >>> Hi, >>> some months ago there was a discussion on VoiceXML 'inputmodes' >>> property >>> implementability in MRCPv2 protocol (see >>> http://www1.ietf.org/mail-archive/web/speechsc/current/ >>> msg01497.html). >>> That thread was closed renaming 'START-OF-SPEECH' event in >>> 'START-OF-INPUT', adding 'input-type' header to it and clarifying >>> conditions under which START-OF-INPUT event has to be generated from >>> server. >>> >>> However, this solution seems not so good to us, for the following >>> reasons: >>> >>> - When both synthesis and recognition resources are involved in >>> the same >>> MRCPv2 session, START-OF-INPUT event generation causes internal >>> SPEAK >>> interruption. If 'input-mode' header is not conform to inputmodes >>> property, VoiceXML client can only abort RECOGNIZE method and >>> take some >>> action (raise an error event? nomatch, noinput or others). On >>> the other >>> hand, even though only a RECOGNIZE is sent, a wrong grammar could be >>> matched (e.g. a DTFM grammar when the input mode was set to >>> "voice"); in >>> this case the VoiceXML interpreter could just recover the error >>> raising >>> e.g. a NO-MATCH event and reprompting the question to the user; >>> an "a >>> priori" solution, allowing to ignore the not-requested modality, >>> would >>> be much more effective. >>> >>> - In hotword recognition, START-OF-INPUT event is never >>> generated, so >>> VoiceXML client receives RECOGNITION-COMPLETE event only, and if >>> result >>> is not conform to inputmodes property it can only raise an error >>> event >>> (nomatch, noinput or others) >>> >>> - When external grammars are involved in VoiceXML pages, >>> VoiceXML client >>> might not to know whether they accept vocal or dtmf input: it cannot >>> activates grammars according to inputmode property. >>> >>> These are not conforming to VoiceXML specification: >>> >>> 6.3.6 Miscellaneous Properties >>> inputmodes >>> This property determines which input modality to use. The input >>> modes to >>> enable: dtmf and voice. On platforms that support both modes, >>> inputmodes >>> defaults to "dtmf voice". To disable speech recognition, set >>> inputmodes >>> to "dtmf". To disable DTMF, set it to "voice". One use for this >>> would be >>> to turn off speech recognition in noisy environments. Another >>> would be >>> to conserve speech recognition resources by turning them off >>> where the >>> input is always expected to be DTMF. This property does not >>> control the >>> activation of grammars. For instance, voice-only grammars may be >>> active >>> when the inputmode is restricted to DTMF. Those grammars would >>> not be >>> matched, however, because the voice input modality is not active. >>> >>> For these reasons, we propose to add a new Recog-only header: >>> >>> Input Mode >>> >>> This header MAY be sent as part of the RECOGNIZE request in order to >>> determines which input modality to use. It can assume following >>> values: >>> "voice": dtmf input will be ignored from server >>> "dtmf": speech input will be ignored from server >>> "all": both dtmf and speech input will be analyzed from server. This >>> is >>> the default value if header is not specified >>> >>> input-mode = "Input-Mode" ":" modes CRLF >>> modes = "voice" / "dtmf" / "all" >>> >>> Alternatively, it is possible to reuse and extend the input type >>> header, >>> >>> in the following way: >>> >>> Input Type >>> >>> When the recognizer detects barge-inable input and generates a >>> START- >>> OF-INPUT event, that event MUST carry this header field to specify >>> where the input that caused the barge-in was DTMF or speech. >>> >>> This header MAY also be sent as part of the RECOGNIZE request in >>> order to >>> determines which input modality to use. If its value is 'speech', >>> dtmf >>> input will be ignored from server. If its value is 'dtmf', speech >>> input will be ignored from server. If its value is 'all', both dtmf >>> and >>> speech input will be analyzed from server. If not specified, it >>> defaults >>> to 'all'. >>> >>> input-type = "Input-Type" ":" inputs CRLF >>> inputs = "speech" / "dtmf" / "all" >>> >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom >>> Italia S.p.A. >>> >>> ================================================ >>> 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 you >>> www.loquendo.com >>> ================================================ >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Sep 11 15:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrnE-0005h4-Af; Mon, 11 Sep 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMrnA-0005eh-LS for speechsc@ietf.org; Mon, 11 Sep 2006 15:50:04 -0400 Received: from web32912.mail.mud.yahoo.com ([209.191.69.112]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GMrZS-0000CG-Qi for speechsc@ietf.org; Mon, 11 Sep 2006 15:35:55 -0400 Received: (qmail 46779 invoked by uid 60001); 11 Sep 2006 19:35:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U1dbVrBmb2TQdhkMvlg1ecbxHXRwLaK9hi/sHljdjHV7qBvIgdJkfhgKTPsB4q5GgfUsW3UBhE2sFwl7bZw4nhvs26WHpaoDXGkjSiIF1jnowQWU0FLWZR0xUISFNIau3TmpOQWGQlajU9XnqjQQ+4XO5Z3Orwl3WCXPxgYeLbY= ; Message-ID: <20060911193554.46777.qmail@web32912.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32912.mail.mud.yahoo.com via HTTP; Mon, 11 Sep 2006 12:35:54 PDT Date: Mon, 11 Sep 2006 12:35:54 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] What is the scope of MRCPv2 session To: "'IETF SPEECHSC \(E-mail\)'" In-Reply-To: <047c01c6d507$51142580$0a01a8c0@db01.voxpilot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 Based on this email and others I have received personally, I believe there is dispute on this issue, even though the original requirements document does not specifically ask for multiple instances of each resource and, in fact, we have discussed precisely this topic in the past and agreed on the existing text. Note that Dave's use case #1 is achievable by using a separate MRCP server, so the first change is unnecessary. Nevertheless, in honor of the dispute (and the fact that I need to get a draft out this week) I will add this to the issue tracker. Future drafts beyond -11 can reconsider this issue if appropriate. I will add your suggested clarification (#2) to the issue tracker as well. It is nice to have but technically unnecessary since the client should know which resources it's using. In all interpretations the modified examples are legal, so I will leave the modifications. -- dan --- Dave Burke wrote: > I'm fine with this clarification (i.e. that the text > in 6.2.1 is indeed > correct). Are we all agreed, however, that as a > consequence, the client > cannot allocate more than one instance of the same > resource type within a > given SIP dialog? (If this was allowed and the text > in 6.2.1 applied, the > channel identifier would be the same for both > resources and it would be > impossible to disambiguate messages from the two > resources). > > To completely address this thread, there are two > more adjustments needed: > > 1. The use-case of using two speechrecog resources > (one in normal mode and > the other in hotword) can only be realised using > separate SIP dialogs. In > section 9, change "same" to "separate": > > ... "the two modes can be invoked through > separate resources > allocated to the same SIP dialog" > > 2. What happens if the client attempts to establish > two or more resources of > the same type within a single SIP dialog? > Presumably, 488 Not Acceptable > Here? This error and the the restriction as a > consequence of 6.2.1 should be > called out. > > Dave > > ----- Original Message ----- > From: "Dan Burnett" > To: ; "'IETF SPEECHSC > (E-mail)'" > Sent: Friday, September 08, 2006 5:08 PM > Subject: RE: [Speechsc] What is the scope of MRCPv2 > session > > > >I also updated the examples in 14.1 as well (both > the > > a=channel lines and the Channel-Identifier > values). > > > > -- dan > > > > --- Dan Burnett wrote: > > > >> After carefully review your comments, Dave > Oran's, > >> and > >> the text of draft -10, I think the key relevant > text > >> in 6.2.1 here is the following: > >> > >> "The unambiguous string (first part) MUST BE > unique > >> among the resource instances managed by the > server > >> and > >> is common to all resource channels with that > server > >> established through a single SIP dialog." > >> > >> Since the example in section 4.2 uses a single > SIP > >> dialog to set up two resource channels with the > same > >> MRCP server, the prefix values must be the same. > I > >> have corrected the example to use the same prefix > in > >> the a=channel line for both resources. This > >> correction will appear in draft -11. > >> > >> -- dan > >> > >> > >> --- santhanakrishnan wrote: > >> > >> > Hi Oran, > >> > > >> > Thanks for your detailed explanation. It > >> > clarifies enough of our > >> > queries. > >> > > >> > But I would like to highlight the main source > of > >> > confusion again to you. > >> > > >> > > >> > > >> > Please refer the following section from the > draft > >> > > >> > 6.2.1 > >> > > >> > All MRCPv2 requests, responses and events > MUST > >> > contain the Channel- > >> > > >> > Identifier header. The value is allocated > by > >> the > >> > server when a > >> > > >> > control channel is added to the session and > >> > communicated to the > >> > > >> > client by the "a=channel" attribute in the > SDP > >> > answer from the > >> > > >> > server. The header value consists of 2 > parts > >> > separated by the '@' > >> > > >> > symbol. The first part is an unambiguous > >> string > >> > identifying the > >> > > >> > MRCPv2 session. The second part is a string > >> > token which specifies > >> > > >> > one of the media processing resource types > >> listed > >> > in Section 3.1. > >> > > >> > The unambiguous string (first part) MUST BE > >> > unique among the resource > >> > > >> > instances managed by the server and is > common > >> to > >> > all resource > >> > > >> > channels with that server established > through a > >> > single SIP dialog. > >> > > >> > > >> > > >> > Here it says the prefix (First part) identifies > an > >> > MRCPv2 session. > >> > > >> > > >> > > >> > But in the following example, the channel Id > >> > returned by the Server > >> > > >> > for Synthesizer and Recognizer belonging to the > >> same > >> > MRCPv2 Session > >> > > >> > is shown with different prefix(First Part). > >> > > >> > > >> > > >> > S->C: SIP/2.0 200 OK > >> > > >> > Via:SIP/2.0/TCP > >> > client.atlanta.example.com:5060; > >> > > >> > branch=z9hG4bK74bf9 > >> > > >> > To:MediaServer > >> > > >> > > >> > ........................................ > >> > > >> > v=0 > >> > > >> > o=sarvi 2890844526 2890842809 IN IP4 > >> > 126.16.64.4 > >> > > >> > s=- > >> > > >> > c=IN IP4 224.2.17.12 > >> > > >> > m=application 32416 TCP/MRCPv2 > >> > > >> > a=setup:passive > >> > > >> > a=connection:existing > >> > > >> > a=channel:32AECB234338@speechrecog > >> > > >> > a=cmid:1 > >> > > >> > m=application 32416 TCP/MRCPv2 > >> > > >> > a=setup:passive > >> > > >> > a=connection:existing > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Sep 11 16:23:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsJ0-0007AJ-N6; Mon, 11 Sep 2006 16:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsIy-0007A9-Ph for speechsc@ietf.org; Mon, 11 Sep 2006 16:22:56 -0400 Received: from g2.genesyslab.com ([198.49.180.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMsIx-0006JP-9p for speechsc@ietf.org; Mon, 11 Sep 2006 16:22:56 -0400 Received: from GIMLI.us.int.genesyslab.com ([192.168.20.233]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 13:22:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [speechsc] Editorial comments on Section 10 Date: Mon, 11 Sep 2006 13:22:49 -0700 Message-ID: <911B89A9FD71E649AA624FF24790D76FC5536A@GIMLI.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speechsc] Editorial comments on Section 10 Thread-Index: AcbV4AzT8paadNb3SFeY8gYC7JvZAQ== From: "Andrew Wahbe" To: X-OriginalArrivalTime: 11 Sep 2006 20:22:50.0111 (UTC) FILETIME=[0D6A78F0:01C6D5E0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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="===============1046652148==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1046652148== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D5E0.0DD59C1E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D5E0.0DD59C1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The VoiceXML Forum's MRCP Liaison Committee would like to make the following editorial comments on Section 10 of the latest draft (10) of MRCP v2. * The START-INPUT-TIMERS method is not in the recorder state machine * The Sensitivity-Level header definition in 10.4.1 does not specify the range of the value (it should be 0.0 to 1.0 as for recognition). Also, it is specified as 1*DIGIT rather than as FLOAT. * 10.4.2 uses the name "RECORDER-COMPLETE event" instead of "RECORD-COMPLETE" event * In section 10.4.7, when discussing the Record URI, the sentence: "This URI is then returned in the "STOP" response of the RECORD-COMPLETE events." should be: "This URI is then returned in either the "STOP" response or the RECORD-COMPLETE event." * In Section 10.5, this is a weak statement: "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 Something like the following would be better: =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 * The first paragraph in section 10.6 should also mention the case where the audio is returned in the message body. =20 * The fourth paragraph in section 10.6 should mention what error is returned if the type specified in the Media-Type header is not supported. This would result in a 409 error with the media-type header contained in the response. Perhaps it should be clarified. VoiceXML platforms need to throw error.unsupported.format when the media type is not supported, so we need to be able to distinguish this case. The text in the second paragraph of 6.1.1 should include the 409 error and should perhaps be moved to another location that signifies that this behavior applies to all methods.=20 =20 * In Section 10.10, description of START-OF-INPUT should mention that the Proxy-Sync-Id header should be specified. The example should show this too. =20 =20 ------_=_NextPart_001_01C6D5E0.0DD59C1E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = VoiceXML Forum's=20 MRCP Liaison Committee would like to make the following editorial = comments on=20 Section 10 of the latest draft (10) of MRCP v2.

* The START-INPUT-TIMERS method is not in = the recorder state machine

* The Sensitivity-Level header definition = in 10.4.1=20 does not specify the range of the value (it should be 0.0 to 1.0 as for=20 recognition). Also, it is specified as 1*DIGIT rather than as = FLOAT.

* 10.4.2 uses the name "RECORDER-COMPLETE = event"=20 instead of "RECORD-COMPLETE" event

* In section 10.4.7, when = discussing=20 the Record URI,  the sentence: "This URI is then returned in the = "STOP"=20 response of the RECORD-COMPLETE events." should be: "This URI is then = returned=20 in either the "STOP" response or the=20 RECORD-COMPLETE event."

* In Section 10.5, this is a weak=20 statement:

     "The "STOP" = response or=20 the RECORD-COMPLETE event MAY contain a message body carrying the = captured=20 audio. This happens if the RECORD request did not have a Record-Uri=20 header."
 
Something like=20 the following would be better:
 
     "If the RECORD = request did=20 not have a Record-Uri header, the "STOP" response or the RECORD-COMPLETE = event=20 MUST contain a message body carrying the captured audio."
 
* The first paragraph in section 10.6 = should also=20 mention the case where the audio is returned in the message = body.
 
* The fourth paragraph in section 10.6 = should=20 mention what error is returned if the type specified in the Media-Type = header is=20 not supported. This would result = in a 409=20 error with the media-type header contained in the = response. Perhaps=20 it should be clarified. VoiceXML platforms need to throw=20 error.unsupported.format when the media type is not supported, so = we need=20 to be able to distinguish this case. = The text in=20 the second paragraph of 6.1.1 should include the 409 error and should = perhaps be=20 moved to another location that signifies that this behavior applies to = all=20 methods. 
 
* In Section 10.10, description of = START-OF-INPUT=20 should mention that the Proxy-Sync-Id header should be specified. The = example=20 should show this too.
 
 
------_=_NextPart_001_01C6D5E0.0DD59C1E-- --===============1046652148== 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 --===============1046652148==-- From speechsc-bounces@ietf.org Mon Sep 11 16:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsPv-0002WS-Pi; Mon, 11 Sep 2006 16:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsPu-0002WI-KH for speechsc@ietf.org; Mon, 11 Sep 2006 16:30:06 -0400 Received: from g2.genesyslab.com ([198.49.180.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMsPt-0007FD-B6 for speechsc@ietf.org; Mon, 11 Sep 2006 16:30:06 -0400 Received: from GIMLI.us.int.genesyslab.com ([192.168.20.233]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 13:30:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [speechsc] Recording without capture-on-speech Date: Mon, 11 Sep 2006 13:30:03 -0700 Message-ID: <911B89A9FD71E649AA624FF24790D76FC55373@GIMLI.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speechsc] Recording without capture-on-speech Thread-Index: AcbV4Q/Sz8yNMF1pQraXOuuPElpviA== From: "Andrew Wahbe" To: X-OriginalArrivalTime: 11 Sep 2006 20:30:04.0053 (UTC) FILETIME=[1010C450:01C6D5E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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="===============2002003765==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============2002003765== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D5E1.107F4C04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D5E1.107F4C04 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There should be clarification in Section 10 on what happens if a capture-on-speech header value of false is used. A lot of the text seems to assume that it is set to true, specifically in areas that relate to the input timer. For example, if capture-on-speech is false and start-input-timers is true, then is the input timer cancelled immediately? If capture-on-speech is false, does the START-OF-INPUT event occur immediately, regardless of if the input timer is set? Perhaps it is not sent at all? =20 =20 Andrew Wahbe VoiceXML Forum MRCP Liaison Committee =20 ------_=_NextPart_001_01C6D5E1.107F4C04 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There should be = clarification in Section 10 on what happens if a=20 capture-on-speech header value of false is used. A lot of the text seems to assume = that it=20 is set to true, specifically in areas that relate to the = input=20 timer. For example,=20 if capture-on-speech = is false=20 and start-input-timers is=20 true, then = is the input timer cancelled=20 immediately? If capture-on-speech = is false,=20 does the START-OF-INPUT event=20 occur immediately, regardless of if the input timer is set? Perhaps it is not sent at=20 all?
 
 
Andrew = Wahbe
VoiceXML Forum MRCP=20 Liaison Committee
 
------_=_NextPart_001_01C6D5E1.107F4C04-- --===============2002003765== 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 --===============2002003765==-- From speechsc-bounces@ietf.org Mon Sep 11 16:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsdy-0008UY-QK; Mon, 11 Sep 2006 16:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMsdx-0008Q6-EV for speechsc@ietf.org; Mon, 11 Sep 2006 16:44:37 -0400 Received: from g2.genesyslab.com ([198.49.180.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMsdw-0000QW-5M for speechsc@ietf.org; Mon, 11 Sep 2006 16:44:37 -0400 Received: from GIMLI.us.int.genesyslab.com ([192.168.20.233]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 13:44:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [speechsc] Indication of media type used in recording Date: Mon, 11 Sep 2006 13:44:34 -0700 Message-ID: <911B89A9FD71E649AA624FF24790D76FC5538F@GIMLI.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speechsc] Indication of media type used in recording Thread-Index: AcbV4xbTzhHPtIFxTeuHp04S/rE9oQ== From: "Andrew Wahbe" To: X-OriginalArrivalTime: 11 Sep 2006 20:44:34.0890 (UTC) FILETIME=[171FF2A0:01C6D5E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============0318204416==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0318204416== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D5E3.177B1A46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D5E3.177B1A46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the media-type for an utterance recording is not specified by the client during a recognition, shouldn't the media type used to record the audio be specified by the server in the STOP response or the RECOGNITION-COMPLETE event? Actually, it would probably be prudent to always specify it. The media-type header could be re-used for this.=20 =20 Note that we don't have this issue for the recorder resource as the media-type is required there. The media type is not required for the SI/SV resource though. Not sure why this is inconsistent. =20 Andrew Wahbe VoiceXML Forum MRCP Liaison Committee =20 =20 ------_=_NextPart_001_01C6D5E3.177B1A46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If the media-type for an utterance recording is not = specified=20 by the client during a = recognition,=20 shouldn't the media type used to record the audio be specified by the = server in=20 the STOP response or the RECOGNITION-COMPLETE event? Actually, it = would=20 probably be prudent to always specify it.=20 The media-type header could be re-used = for this.=20
 
Note = that we=20 don't have this issue for the recorder resource as the = media-type is=20 required there. The media type is not required for the SI/SV resource = though.=20 Not sure why this is inconsistent.
 
Andrew = Wahbe
VoiceXML Forum MRCP=20 Liaison Committee
 
 
------_=_NextPart_001_01C6D5E3.177B1A46-- --===============0318204416== 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 --===============0318204416==-- From speechsc-bounces@ietf.org Mon Sep 11 17:23:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtEz-0008BO-I8; Mon, 11 Sep 2006 17:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMtEy-00086v-4i for speechsc@ietf.org; Mon, 11 Sep 2006 17:22:52 -0400 Received: from g2.genesyslab.com ([198.49.180.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMtEw-00083G-R2 for speechsc@ietf.org; Mon, 11 Sep 2006 17:22:52 -0400 Received: from GIMLI.us.int.genesyslab.com ([192.168.20.233]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 14:22:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [speechsc] Lifetime of recorded resources Date: Mon, 11 Sep 2006 14:22:48 -0700 Message-ID: <911B89A9FD71E649AA624FF24790D76FC553CC@GIMLI.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [speechsc] Lifetime of recorded resources Thread-Index: AcbV6G5lmJ+AU8oHT5KWzNrEOd3O+Q== From: "Andrew Wahbe" To: X-OriginalArrivalTime: 11 Sep 2006 21:22:49.0917 (UTC) FILETIME=[6F1146D0:01C6D5E8] X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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="===============0393698417==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0393698417== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D5E8.6F07058E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D5E8.6F07058E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Similar to the issues discussed earlier concerning grammar lifetimes, there seems to be no way to indicate that recorded audio (either saved utterance waveforms or audio recorded with the recorder resource) is no longer needed by the client. While these resources can be cleaned up by the server on termination of a session, long running sessions could cause a server to run out of storage space. I would guess that in most cases, the resource could be purged once it had been fetched, but there is no way to know for sure and the current language requires that the resource be available until the end of the session. A quick fix may be for the server to support HTTP DELETE, but that may be too big a change at this stage in the process. =20 It would be beneficial to take a comprehensive look at resource storage to address these sorts of problems. While such an effort may not be feasible in the current MRCP v2 timeline, this is definitely a weak area in the specification that should be noted for revision in any future versions. =20 Andrew Wahbe VoiceXML Forum MRCP Liaison Committee ------_=_NextPart_001_01C6D5E8.6F07058E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Similar to the=20 issues discussed earlier concerning grammar lifetimes, there seems to be = no way=20 to indicate that recorded audio (either saved utterance = waveforms or=20 audio recorded with the recorder resource) is no longer needed by the = client.=20 While these resources can be cleaned up by the server on termination of = a=20 session, long running sessions could cause a server to run out of = storage space.=20 I would guess that in most cases, the resource could be purged once it = had been=20 fetched, but there is no way to know for sure and the current language = requires=20 that the resource be available until the end of the session. A quick fix = may be=20 for the server to support HTTP DELETE, but that may = be too big a=20 change at this stage in the process.
 
It = would be=20 beneficial to take a comprehensive look at = resource storage to=20 address these sorts of problems. While such an effort may not=20 be feasible in the current MRCP v2 timeline, this is = definitely a=20 weak area in the specification that should be noted for revision in = any=20 future versions.
 
Andrew = Wahbe
VoiceXML Forum MRCP=20 Liaison Committee
------_=_NextPart_001_01C6D5E8.6F07058E-- --===============0393698417== 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 --===============0393698417==-- From speechsc-bounces@ietf.org Thu Sep 14 21:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO2xw-00064r-Hv; Thu, 14 Sep 2006 21:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO2xv-00064m-VR for speechsc@ietf.org; Thu, 14 Sep 2006 21:58:03 -0400 Received: from web32904.mail.mud.yahoo.com ([209.191.69.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GO2xq-0006tA-Co for speechsc@ietf.org; Thu, 14 Sep 2006 21:58:03 -0400 Received: (qmail 82573 invoked by uid 60001); 15 Sep 2006 01:57:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=onxFyYtnJ0R0ZTo8M7B7dZXmbbF1DaKMR4294rnoFNRR8Eo6buMQGsLvFg/qaTpmpFKxJkHqQGrdmxOsFwW9CK8MyCT83NxE19UnRycHWtWrK92+0Y3zNLq0ODwHBr3dLJ22rRv/qTksAqg5O5JlvppvrqvfqyknXYTDb/9xcm8= ; Message-ID: <20060915015757.82571.qmail@web32904.mail.mud.yahoo.com> Received: from [70.219.105.221] by web32904.mail.mud.yahoo.com via HTTP; Thu, 14 Sep 2006 18:57:57 PDT Date: Thu, 14 Sep 2006 18:57:57 -0700 (PDT) From: Dan Burnett Subject: Re: [speechsc] The NLSML schema and namespaces To: Andrew Wahbe , "IETF SPEECHSC \(E-mail\)" In-Reply-To: <911B89A9FD71E649AA624FF24790D76F3A74E7@GIMLI.us.int.genesyslab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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 All changes applied to spec draft -11. -- dan --- Andrew Wahbe wrote: > I would like to raise a few issues with both the > NSLML schema and it's > use of namespaces. > > First, SRGS and SISR allow you to define a grammar > so that multiple > token sequences map to one string literal result. > For example, "yes", > "ya", "sure", "yes please", and "ok" could all > result in the string > literal result "yes". Thus, if you said "sure", the > string literal > interpretation result would be "yes". > > Unfortunately there doesn't seem to be a way to > specify string literals > in NLSML. You would think that the example above > could be expressed as > follows: > > > > > yes > sure > > > > However this isn't allowed by the NLSML schema in > the current MRCPv2 > draft. This could be allowed by changing the > type to allow > "mixed" contents (see the definition of ). > Also, we would need to > change the schema to allow to have no > child elements. > Applying these changes we get the following element > definition: > > > > > > > > > > Of course this allows for a mix of text and elements > (eg. yes > maybe ) which is probably not > desirable. XML schema has > no way to restrict this but the format we define > could specify it this > way (in the text of the spec). The alternative would > be to do what EMMA > does with the element. Either way > would be fine with me. > > The second issue is with the portion of > the instance element > definition. As currently defined, a schema validator > will try to > validate it's contents even if a schema is not > available. We should > probably relax this by adding a processContents > attribute of "lax". This > will cause the validator to only process the > contents if a schema is > available. > > Also, this currently allows any elements, including > those from the NLSML > namespace to be within an element. I'm > guessing that we > actually want to allow elements from other > namespaces, and to restrict > it to elements from other namespaces. E.g. you > shouldn't be able to do > this: > > > > > > > > > > > > > > However, this is ok: > > > > > > > > > > > > > > The final element definition for would > then be: > > > > processContents="lax"/> > > > > > Of course, this also raises the issue that all of > the examples in the > spec don't declare namespaces at all. It would > probably be a good idea > to do this properly. > So examples such as this: > > > > > > Andre Roy > > > may I speak to Andre Roy > > > > Become this: > > > xmlns:nl="http://www.ietf.org/xml/ns/mrcpv2" > xmlns="http://www.example.com/example" > > grammar="session:request1@form-level.store"> > > > > Andre Roy > > > may I speak to Andre Roy > > > > > Finally, it is not clear what the namespace of the > NSLML format is > supposed to be. The schema says this: > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > targetNamespace="http://www.ietf.org/xml/schema/mrcpv2" > > xmlns="http://www.ietf.org/xml/ns/mrcpv2" ... > > I have a feeling that > "http://www.ietf.org/xml/schema/mrcpv2" is > supposed to be the location of the schema and > "http://www.ietf.org/xml/ns/mrcpv2" is supposed to > be the namespace for > NLSML. If that is the case, then the schema should > be written this way: > xmlns:xs="http://www.w3.org/2001/XMLSchema" > > targetNamespace="http://www.ietf.org/xml/ns/mrcpv2" > > xmlns="http://www.ietf.org/xml/ns/mrcpv2" ... > > The schema location is not referenced in the schema > content at all. > Either way, the default namespace and the > targetNamespace should match > otherwise referencing the "confidenceinfo" > simpleType in the definitions > of the confidence attributes does not work properly. > Thanks, > > Andrew Wahbe > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Sep 14 23:13:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO48b-0001XJ-Rq; Thu, 14 Sep 2006 23:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO48a-0001XB-28 for speechsc@ietf.org; Thu, 14 Sep 2006 23:13:08 -0400 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO48Y-0006BO-N1 for speechsc@ietf.org; Thu, 14 Sep 2006 23:13:08 -0400 Received: from unknown (HELO bn-exchbh2.nuance.com) ([10.1.4.197]) by mx2.nuance.com with ESMTP; 14 Sep 2006 23:13:06 -0400 X-IronPort-AV: i="4.09,167,1157342400"; d="rtf'212?scan'212,208,217,212"; a="9794515:sNHT67044845" Received: from BN-EXCH01.nuance.com ([10.1.4.213]) by bn-exchbh2.nuance.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 23:13:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6D874.DCDA26EE" Date: Thu, 14 Sep 2006 23:12:44 -0400 Message-ID: <2AB5541EB33172459EE430FFB66B1EE9066DE8@BN-EXCH01.nuance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Change list for mrcpv2 draft -11 Thread-Index: AcbYdM/3YoJ6/VQtSHCaWo5jKawweA== From: "Daniel C. Burnett" To: X-OriginalArrivalTime: 15 Sep 2006 03:13:06.0392 (UTC) FILETIME=[DD1A1D80:01C6D874] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Subject: [Speechsc] Change list for mrcpv2 draft -11 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D874.DCDA26EE Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6D874.DCDA26EE" ------_=_NextPart_002_01C6D874.DCDA26EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Group, =20 I have just submitted draft -11 to the ietf for publication. There should be an email notification of publication within a few days. =20 I have attached a Rich Text File to this email detailing the changes from draft -10. If anyone has difficulty reading this file, let me know and I'll resend as straight text. =20 This draft includes many, but not all, of the changes largely agreed to over the past few months. Hopefully the document is cleaned up enough that we can quickly move forward to Last Call Working Draft. =20 Thanks, =20 Dan Burnett =20 ------_=_NextPart_002_01C6D874.DCDA26EE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Group,

 

I have just submitted draft -11 to the ietf for = publication.  There should be an email notification of publication within a few = days.

 

I have attached a Rich Text File to this email = detailing the changes from draft -10.  If anyone has difficulty reading this = file, let me know and I’ll resend as straight = text.

 

This draft includes many, but not all, of the changes largely agreed to over the past few months.  Hopefully the document = is cleaned up enough that we can quickly move forward to Last Call Working = Draft.

 

Thanks,

 

Dan Burnett

 

------_=_NextPart_002_01C6D874.DCDA26EE-- ------_=_NextPart_001_01C6D874.DCDA26EE Content-Type: application/rtf; name="MRCPv2-11-changes.rtf" Content-Transfer-Encoding: base64 Content-Description: MRCPv2-11-changes.rtf Content-Disposition: attachment; filename="MRCPv2-11-changes.rtf" e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYwXGZz d2lzc1xmcHJxMlxmY2hhcnNldDAgQXJpYWw7fXtcZjFcZnN3aXNzXGZjaGFyc2V0MCBBcmlhbDt9 fQ0Ke1wqXGdlbmVyYXRvciBNc2Z0ZWRpdCA1LjQxLjE1LjE1MDc7fVx2aWV3a2luZDRcdWMxXHBh cmRcZjBcZnMyMCAtIElzc3VlIDk0OiBNYWRlIHRoZSBmb2xsb3dpbmcgY2hhbmdlczpccGFyDQox KSBGb3IgdGhlIFN5bnRoZXNpemVyIHN0YXRlIG1hY2hpbmUgaW4gc2VjdGlvbiA4LjEsXHBhcg0K LSBkZWxldGVkIHRoZSBTUEVBSyBhdXRvLXRyYW5zaXRpb24gaW4gdGhlIFBhdXNlZCBTdGF0ZVxw YXINCi0gYWRkZWQgdGhlIFJFU1VNRSBhdXRvLXRyYW5zaXRpb24gaW4gdGhlIFNwZWFraW5nIFN0 YXRlXHBhcg0KLSBhZGRlZCB0aGUgQkFSR0UtSU4tT0NDVVJSRUQgYXV0by10cmFuc2l0aW9uIGlu IHRoZSBJZGxlIFN0YXRlXHBhcg0KXHBhcg0KMikgQWRkZWQgc2VjdGlvbiAyLjIgZXhwbGFpbmlu ZyB0aGF0IHRoZSBzdGF0ZSBtYWNoaW5lIGRpYWdyYW1zIHJlZmxlY3QgdGhlIHN0YXRlIG9mIHRo ZSByZWNvZ25pemVyIGJhc2VkIG9uIHRoZSBtZXRob2RzIHRoYXQgaGF2ZSBtb3ZlZCB0byBJTi1Q Uk9HUkVTUyBvciBDT01QTEVURSBzdGF0ZXMsIGFuZCB0aGF0IHNpbmNlIFBFTkRJTkcgcmVxdWVz dHMgZXNzZW50aWFsbHkgaGF2ZSBub3QgYWZmZWN0ZWQgdGhlIHJlc291cmNlIHlldCBhbmQgYXJl IGluIHF1ZXVlIHRvIGJlIHByb2Nlc3NlZCwgdGhleSBhcmUgbm90IHJlZmxlY3RlZCBpbiB0aGUg c3RhdGUtbWFjaGluZSBkaWFncmFtLlxmMVxwYXINClxwYXINCkluIDguNC43LCBjaGFuZ2VkICJj YW4gYmUgcGFydCBvZiB0aGUgc3BlZWNoIHRleHQgbWFya2VkIHVwIGluIFNNSUwiIHRvIGJlICJj YW4gYmUgcGFydCBvZiB0aGUgc3BlZWNoIHRleHQgbWFya2VkIHVwIGluIFNTTUwiLlxwYXINClxw YXINCi0gSXNzdWUgNTU6IFJlbW92ZWQgYWxsIHJlZmVyZW5jZXMgdG8gWGZvcm1zIGZyb20gdGhl IGRyYWZ0LiAgQXMgYSBjb3JvbGxhcnksIHJlbW92ZWQgYWxsIHgtbW9kZWwgYXR0cmlidXRlcyBh bmQgYWxsIHJlZmVyZW5jZXMgdG8gZGF0YSBtb2RlbHMuXHBhcg0KICAgIEFkZGVkIHRoZSBTSVNS IENSIHRvIHRoZSBsaXN0IG9mIE5vcm1hdGl2ZSByZWZlcmVuY2VzIGFuZCByZWZlcmVuY2VkIGl0 IGZyb20gOS41LjEuXHBhcg0KICAgIEFkZGVkIHRleHQgaW4gOS42LjMuMyB0aGF0IHdoZW4gdGhl IFNJU1IgZm9ybWF0IGlzIHVzZWQgdGhlIDxpbnN0YW5jZT4gY29udGVudCBpcyB0aGUgWE1MIHNl cmlhbGl6YXRpb24gb2YgdGhlIEVDTUFzY3JpcHQgcmVzdWx0LlxwYXINClxwYXINClxwYXINCi0g SXNzdWUgNzE6IE1vZGlmaWVkIDxkZWNpc2lvbj4gZGVzY3JpcHRpb24gdG8gZm9yYmlkIHRoZSBl bGVtZW50IGluIGEgdHJhaW5pbmcgcmVzdWx0IGFuZCBjbGFyaWZ5IHRoYXQgaXQgc2hvdWxkIG9u bHkgYmUgcHJlc2VudCBpbiBvbmUgdm9pY2VwcmludCB3aGVuIG11bHRpLXZlcmlmaWNhdGlvbiBp cyB1c2VkLiAoTmV3IHRleHQgaXMgIlRoaXMgZWxlbWVudCBNVVNUIGJlIHByZXNlbnQgd2l0aGlu IGVpdGhlciB0aGUgPGluY3JlbWVudGFsPiBvciA8Y3VtdWxhdGl2ZT4gZWxlbWVudCwgYnV0IG5v dCBib3RoLCB3aXRoaW4gdGhlIGZpcnN0IDx2b2ljZXByaW50PiBlbGVtZW50IHdoZW4gYW5kIG9u bHkgd2hlbiB0aGUgcmVzdWx0IGlzIGEgdmVyaWZpY2F0aW9uIHJlc3VsdCAoaS5lLiwgVmVyaWZp Y2F0aW9uLU1vZGUgaGVhZGVyIGhhcyBiZWVuIHNldCB0byAidmVyaWZ5IikuIEl0IGlzIG5vdCBw ZXJtaXR0ZWQgYW55d2hlcmUgZWxzZS4gSXRzIHZhbHVlIGluZGljYXRlcyB0aGUgdmVyaWZpY2F0 aW9uIGRlY2lzaW9uLiBJdCBjYW4gaGF2ZSB0aGUgdmFsdWVzIG9mICJhY2NlcHRlZCIsICJyZWpl Y3RlZCIgb3IgInVuZGVjaWRlZCIuIilccGFyDQpccGFyDQotIFVwZGF0ZWQgQk5GIGZvciBMZXhp Y29uLVNlYXJjaC1PcmRlciBpbiA4LjQuMTcgYW5kIDE1IHRvIGJlXHBhcg0KbGV4aWNvbi1zZWFy Y2gtb3JkZXIgPSAgICJMZXhpY29uLVNlYXJjaC1PcmRlciIgIjoiXHBhcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICI8IiBhYnNvbHV0ZVVSSSAiPiIgKlsiICIgIjwiIGFic29sdXRlVVJJICI+ Il0gQ1JMRlxwYXINClxwYXINCi0gSXNzdWUgMTAwOiBDbGFyaWZlZDpccGFyDQogIC0gSW4gc2Vj dGlvbiA1LjQsIHRoYXQgNDA0IGlzIGZvciBhIHN5bnRheCBlcnJvciBhbmQgdGhhdCA0MDkgaXMg Zm9yIGEgdmFsdWUgdGhhdCBpcyBzeW50YWN0aWNhbGx5IHZhbGlkIGJ1dCBleGNlZWRzIHBsYXRm b3JtIGNhcGFiaWxpdGllcyBvciBleHBlY3RhdGlvbnMuXHBhcg0KICAtIEluIHNlY3Rpb24gNi4x LjEsIHRoYXQgY29kZSA0MDkgaXMgYSBwb3NzaWJpbGl0eSBhcyB3ZWxsIGZvciB1bnN1cHBvcnRl ZCB2YWx1ZXMuXHBhcg0KICAtIEluIHNlY3Rpb24gOC40LjEgKEp1bXAtU2l6ZSksIHRoYXQgZXJy b3IgNDA0IHNob3VsZCBiZSBlcnJvciA0MDkuXHBhcg0KICAtIEluIHNlY3Rpb24gOC40LjE1IChT cGVhay1MZW5ndGgpLCB0aGF0IGVycm9yIDQwNCBzaG91bGQgYmUgZXJyb3IgNDA5LlxwYXINCiAg Tm90ZSB0aGF0IEkgaGF2ZSByZXRhaW5lZCB0aGUgIlNIT1VMRCIgc3RhdHVzIG9mIGVycm9yIDQw OSBhcyBpdCBvY2N1cnMgaW4gOC40LjEgKEp1bXAtU2l6ZSkgYW5kIDguNC4xNSAoU3BlYWstTGVu Z3RoKSBhbmQgbWFkZSB0aGF0IGNsZWFyIGluIDYuMS4xIGFzIHdlbGwuXHBhcg0KXHBhcg0KLSBN b2RpZmllZCBBQk5GIGZvciBTcGVhay1MZW5ndGggdG8gcmVxdWlyZSBvbmx5IG5vbi1uZWdhdGl2 ZSBpbnRlZ2Vycy4gIE5vdGUgdGhhdCB0aGlzIGNoYW5nZWQgdGhlIHByb2R1Y3Rpb25zIGZvciBK dW1wLVNpemUgYXMgd2VsbC4gIEFsc28sIGNsYXJpZmllZCBpbiBTcGVhay1MZW5ndGggZGVzY3Jp cHRpb24gdGhhdCB0aGUgdGV4dCAiVGhlIHZhbHVlIE1VU1QgYmUgYVxwYXINCnBvc2l0aXZlIGlu dGVnZXIuIiBzaG91bGQgYmUgIklmIG51bWVyaWMsIHRoZSB2YWx1ZSBNVVNUIGJlIGEgcG9zaXRp dmUgaW50ZWdlci4iIHRvIG1hdGNoIHRoZSBwZXJtaXR0ZWQgdmFsdWVzLlxwYXINClxwYXINCi0g SW4gOC40LjIsIGNoYW5nZWRccGFyDQogICAgSWYgdGhlIHJlY29nbml6ZXIgb3Igc2lnbmFsIGRl dGVjdG9yIHJlc291cmNlIGlzIG9uIHRoZSBzYW1lIHNlcnZlciBhcyB0aGUgc3ludGhlc2l6ZXIs IHRoZSBzZXJ2ZXIgU0hPVUxEIHJlY29nbml6ZSB0aGVpciBpbnRlcmFjdGlvbnMgYnkgdGhlaXIg Y29tbW9uIE1SQ1B2MiBjaGFubmVsIGlkZW50aWZpZXIgKGlnbm9yaW5nIHRoZSBwb3J0aW9uIGFm dGVyICJAIiB3aGljaCBpcyB0aGUgcmVzb3VyY2UgdHlwZSkgYW5kIHdvcmsgd2l0aCBib3RoIHRv IHByb3ZpZGUga2lsbC1vbi1iYXJnZS1pbiBzdXBwb3J0LlxwYXINCiBccGFyDQp0b1xwYXINClxw YXINCiAgIElmIHRoZSByZWNvZ25pemVyIG9yIHNpZ25hbCBkZXRlY3RvciByZXNvdXJjZSBpcyBv biB0aGUgc2FtZSBzZXJ2ZXIgYXMgdGhlIHN5bnRoZXNpemVyIGFuZCBhcmUgcGFydCBvZiB0aGUg c2FtZSBzZXNzaW9uLCB0aGUgc2VydmVyIFNIT1VMRCB3b3JrIHdpdGggYm90aCB0byBwcm92aWRl IGtpbGwtb24tYmFyZ2UtaW4gc3VwcG9ydC5ccGFyDQpccGFyDQpccGFyDQotIEluIHRoZSBleGFt cGxlcyBpbiBzZWN0aW9uIDQuMiwgbW92ZWQgdGhlIHJlY29nbml6ZXIgbSBhbmQgYSBsaW5lcyB0 byB0aGUgZW5kIGFzIHJlcXVpcmVkIGJ5IHRoZSBvZmZlci9hbnN3ZXIgcnVsZXMgaW4gc2VjdGlv biA4LjEgb2YgUkZDMzI2NC5ccGFyDQotIEluIHNlY3Rpb24gMTAuNywgY29ycmVjdGVkIHRoZSB0 eXBvLCBhZGRlZCB0aGUgQWN0aXZlLVJlcXVlc3QtSWQtTGlzdCBoZWFkZXIgdG8gdGhlIFNUT1Ag cmVzcG9uc2UgKGFsb25nIHdpdGggYXBwcm9wcmlhdGUgdGV4dCBpbiB0aGUgZGVzY3JpcHRpb24g b2YgdGhlIFNUT1AgbWV0aG9kKSwgYW5kIHJlbW92ZWQgdGhlIENvbXBsZXRpb24tQ2F1c2UgaGVh ZGVyIGZyb20gdGhlIFNUT1AgcmVzcG9uc2UgaW4gdGhlIFNUT1AgZXhhbXBsZS5ccGFyDQotIElu IHNlY3Rpb24gMTAuNiAoUkVDT1JEIG1ldGhvZCksIHJlcGxhY2VkICJJdCB0aGVuIHNhdmVzIHRo ZSBhdWRpbyB0byB0aGUgVVJJIHN1cHBsaWVkIGluIHRoZSByZWNvcmRpbmctdXJpIGhlYWRlci4g SWYgdGhlIHJlY29yZGluZy11cmkgaXMgbm90IHNwZWNpZmllZCwgdGhlIHNlcnZlciBjYXB0dXJl cyB0aGUgbWVkaWEgYW55d2hlcmUgaXQgZmluZHMgY29udmVuaWVudCBhbmQgcmV0dXJucyBhIFVS SSBwb2ludGluZyB0byB0aGUgcmVjb3JkZWQgYXVkaW8gaW4gdGhlIFJFQ09SRC1DT01QTEVURSBl dmVudC4iIHdpdGggIlRoZSBhdWRpbyBpcyB0aGVuIG1hZGUgYXZhaWxhYmxlIHRvIHRoZSBjbGll bnQgYXMgc3BlY2lmaWVkIGJ5IFJlY29yZC1VUkkuIiAgQWxzbywgaW4gMTAuNC43LCAiSWYgdGhl IGhlYWRlciBpcyBlbXB0eSIgaGFzIGJlZW4gY2hhbmdlZCB0byAiSWYgdGhlIGhlYWRlciBpcyBw cmVzZW50IGJ1dCBzcGVjaWZpZWQgd2l0aCBubyB2YWx1ZSIuXHBhcg0KLSBJbiB0aGUgZXhhbXBs ZXMgaW4gNC4yIGFuZCAxNC4xLCBjb3JyZWN0ZWQgdGhlIGE9Y2hhbm5lbCBsaW5lcyBmb3IgYm90 aCByZXNvdXJjZXMgdG8gaGF2ZSB0aGUgc2FtZSBwcmVmaXguICBBbHNvIHVwZGF0ZWQgYWxsIENo YW5uZWwtSWRlbnRpZmllciB2YWx1ZXMgaW4gdGhlIDE0LjEgZXhhbXBsZXMgdG8gdXNlIHRoZSBu ZXcgcHJlZml4IHZhbHVlLlxwYXINCi0gQWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHNlY3Rp b24gOC42LCBwYXJhZ3JhcGggNTogIklmIHRoZSBjdXJyZW50IFNQRUFLIGZhaWxzLCBhbGwgU1BF QUsgbWV0aG9kcyBpbiB0aGUgcGVuZGluZyBxdWV1ZSBhcmUgY2FuY2VsbGVkIGFuZCBlYWNoIGdl bmVyYXRlcyBhIFNQRUFLLUNPTVBMRVRFIGV2ZW50IHdpdGggYSBDb21wbGV0aW9uLUNhdXNlIG9m ICJjYW5jZWxsZWQiLiIgIEFkZGVkIGEgbmV3IFNQRUFLIENvbXBsZXRpb24tQ2F1c2Ugb2YgIjAw NyBjYW5jZWxsZWQiLiAgQWRkZWQgdG8gUkVDT0dOSVpFIENvbXBsZXRpb24tQ2F1c2UgdGFibGUg ZW50cnkgZm9yIDAxMSBjYW5jZWxsZWQgIiwgb3IgYSBwcmlvciBSRUNPR05JWkUgZmFpbGVkIHdo aWxlIHRoaXMgb25lIHdhcyBzdGlsbCBpbiB0aGUgcXVldWUuIlxwYXINClxwYXINCk5MU01MLXJl bGF0ZWQgZml4ZXM6XHBhcg0KLSBDb3JyZWN0ZWQgVVJJcyBpbiAxMy40IGFuZCAxMy41IChJQU5B IFNjaGVtYSBhbmQgbmFtZXNwYWNlIHJlZ2lzdHJhdGlvbnMpLlxwYXINCi0gTW92ZWQgTkxTTUwg RFRELCBTY2hlbWEsIGFuZCBOYW1lIHNwYWNlIElBTkEgcmVnaXN0cmF0aW9ucyB1bmRlciBzZWN0 aW9uIDEzLjIgKCJOTFNNTC1yZWxhdGVkIHJlZ2lzdHJhdGlvbnMiKSB3aGVyZSB0aGV5IGJlbG9u Zy5ccGFyDQotIENyZWF0ZWQgbmV3IHNlY3Rpb24gNi4zIGNhbGxlZCAiR2VuZXJpYyBSZXN1bHQg U3RydWN0dXJlIiB3aGljaCBjb250YWlucyB0aGUgZ2VuZXJpYyB0ZXh0IGFib3V0IHJlc3VsdHMg YW5kIE5MU01MIHN0cnVjdHVyZSBmcm9tIHNlY3Rpb24gOS42LiAgUmVuYW1lZCBzZWN0aW9uIDYg YWNjb3JkaW5nbHkuICBBZGp1c3RlZCB0aGUgdGV4dCBpbiA5LjUuMiwgOS41LjMsIDkuNiwgOS43 LCBhbmQgMTEuNSBhY2NvcmRpbmdseS4gIEFsc28gYWRkZWQgdGV4dCBzdWdnZXN0aW5nIGJyaWVm bHkgaG93IG5lZ290aWF0aW9uIGZvciByZXN1bHQgZm9ybWF0IHR5cGUgY291bGQgYmUgZG9uZS5c cGFyDQotIENyZWF0ZWQgbmV3IHNlY3Rpb24gMTEuNSB3aGljaCBpcyBhIHdyYXBwZXIgYXJvdW5k IHRoZSBvbGQgb25lIGZvciBjb25zaXN0ZW5jeSB3aXRoIHRoZSBvdGhlciByZXNvdXJjZXMuICBU aGUgb2xkIHNlY3Rpb24gMTEuNSBpcyBub3cgMTEuNS4yLlxwYXINClxwYXINCi0gSXNzdWUgODQ6 IFJld3JvdGUgaW5saW5lIGdyYW1tYXIgc2VjdGlvbiBvZiA5LjUuMSB0byBjbGFyaWZ5IHRoZSBs aWZldGltZSBvZiBzdG9yZWQgZ3JhbW1hcnMgYW5kIHdoZW4gYW5kIGhvdyB0aGV5IGNhbiBiZSBy ZWxlYXNlZC5ccGFyDQotIElzc3VlIDcwOiBVcGRhdGVkIHZlcmlmaWNhdGlvbiBzdGF0ZSBtYWNo aW5lIGRpYWdyYW0gYmFzZWQgb24gaW5wdXQgZnJvbSBEYXZlIEJ1cmtlIGFuZCBQYXRyaXppbyBC ZXJnYWxsby5ccGFyDQotIElzc3VlIDU3OiB2ZW5kb3ItYXYtcGFpci1uYW1lIGlzIG5vdyBwZXJt aXR0ZWQgdG8gYmUgVVRGQ0hBUi4gIFNhbWUgZm9yIExvZ2dpbmctVGFnLCBTcGVlY2gtTWFya2Vy LCBKdW1wLVNpemUsIFNwZWFrLUxlbmd0aCwgYW5kIFBocmFzZS1OTC5ccGFyDQotIElzc3VlIDYw OiB2b2ljZS1wYXJhbS12YWx1ZSBub3cgdXNlcyBVVEZDSEFSLlxwYXINCi0gSXNzdWUgNzk6IGFk ZGVkIHdvcmRpbmcgdG8gZXhwbGFpbiB3aGF0IHRoZSBleGFtcGxlcyBpbiAxMS41LjIgc2hvdy4g IEFsc28gY29ycmVjdGVkIHNvbWUgbWlzdGFrZXMgaW4gdGhlIGV4YW1wbGVzLlxwYXINCi0gSXNz dWUgNTg6IHJldmlzZWQgcmVjb3JkZXIgc2Vuc2l0aXZpdHktbGV2ZWwgKDEwLjQuMSkgdGV4dCBh bmQgQUJORiB0byBtYXRjaCB0aGF0IG9mIHJlY29nbml6ZXIgc2Vuc2l0aXZpdHktbGV2ZWwgKDku NC4yKS4gIFVwZGF0ZWQgZmluYWwgQUJORiB0byBtYXRjaC5ccGFyDQotIElzc3VlIDkwOiBleHBh bmRlZCB2b2ljZS1wYXJhbWV0ZXIgKHNlY3Rpb24gOC40LjYpIHRvIGJlIGFuIGV4cGxpY2l0IGxp c3Qgb2YgcGFyYW1ldGVycyB2b2ljZS1nZW5kZXIsIHZvaWNlLWFnZSwgdm9pY2UtdmFyaWFudCwg YW5kIHZvaWNlLW5hbWUuXHBhcg0KLSBJc3N1ZSA5NTogQ2hhbmdlZCBBQk5GIGZvciBTcGVlY2gt TWFya2VyIGhlYWRlciB0byBiZVxwYXINCiAgICAgIHNwZWVjaC1tYXJrZXIgICAgICAgPSAgICJT cGVlY2gtTWFya2VyIiAiOiJccGFyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAidGltZXN0YW1wPSIgW3RpbWUtc3RhbXAtdmFsdWVdXHBhcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgWyI7IiAxKihVVEZDSEFSIC8gMHgyMCldIENSTEZccGFy DQotIElzc3VlIDk2OiBDbGFyaWZpZWQgaW4gU3BlZWNoLU1hcmtlciBoZWFkZXIgdGV4dCAoOC40 LjgpIHRoYXQgdGhpcyBoZWFkZXIgaXMgdXNlZCBib3RoIHRvIHJldHVybiBtYXJrIGluZm9ybWF0 aW9uIGFuZCB0byByZXR1cm4gZ2VuZXJpY2FsbHkgdXNlZnVsIHRpbWVzdGFtcCBpbmZvLiAgQWRk ZWQgdGhlIGhlYWRlciB0byBCQVJHRS1JTi1PQ0NVUlJFRCBhbmQgSU4tUFJPR1JFU1MgU1BFQUsg cmVzcG9uc2VzLiAgVXBkYXRlZCBhbGwgcmVsZXZhbnQgZXhhbXBsZXMuXHBhcg0KLSBEZWxldGVk IHNlY3Rpb24gMTMuMyAoRFREIFJlZ2lzdHJhdGlvbikuICBXZSBubyBsb25nZXIgcHJvdmlkZSBh IERURCBmb3IgTkxTTUwsIHNvIHRoZXJlJ3Mgbm8gcG9pbnQgdHJ5aW5nIHRvIHJlZ2lzdGVyIG9u ZS5ccGFyDQotIE1hc3RlciBOTFNNTCBzY2hlbWEgbm93IGltcG9ydHMgRW5yb2xsbWVudCBhbmQg VmVyaWZpY2F0aW9uIHNjaGVtYXMgYXMgaW1wbGllZCBidXQgbmV2ZXIgY2xlYXJseSBkZWZpbmVk LlxwYXINCi0gQ2xhcmlmaWVkIGluIHNjaGVtYSBhbmQgaW4gSUFOQSByZWdpc3RyYXRpb25zIHRo YXQgdGhlIG5hbWVzcGFjZSBmb3IgTkxTTUwgY29udGVudCBpcyAiaHR0cDovL3d3dy5pZXRmLm9y Zy94bWwvbnMvbXJjcHYyIi5ccGFyDQotIEFkanVzdGVkIHRoZSBzY2hlbWEgZGVmaW5pdGlvbiBm b3IgPGluc3RhbmNlPiB0byBwZXJtaXQgbWl4ZWQgY29udGVudCBidXQgZm9yYmlkIHVzaW5nIE1D UlAgbmFtZXNwYWNlIGVsZW1lbnRzIGFzIGNvbnRlbnQuXHBhcg0KLSBBZGp1c3RlZCBhbGwgWE1M IGV4YW1wbGVzIHRvIHVzZSBwcm9wZXIgbmFtZXNwYWNpbmcuXHBhcg0KXHBhcg0KfQ0KAA== ------_=_NextPart_001_01C6D874.DCDA26EE 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_001_01C6D874.DCDA26EE-- From speechsc-bounces@ietf.org Fri Sep 15 15:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOJhb-0007W3-FR; Fri, 15 Sep 2006 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOJhM-0007R5-8c; Fri, 15 Sep 2006 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOJhK-0000zU-UQ; Fri, 15 Sep 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D574726E45; Fri, 15 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GOJhK-0007Pj-Nb; Fri, 15 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Sep 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-11.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-11.txt Pages : 206 Date : 2006-9-15 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-11.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-11.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-11.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: <2006-9-15140713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-mrcpv2-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-15140713.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 Sep 15 17:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOLQ9-0003Zb-Vm; Fri, 15 Sep 2006 17:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOLQ8-0003Wh-Np for speechsc@ietf.org; Fri, 15 Sep 2006 17:40:24 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOLQ8-0004ii-9H for speechsc@ietf.org; Fri, 15 Sep 2006 17:40:24 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 17:40:38 -0400 Received: from 10.128.41.57 ([10.128.41.57]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Sep 2006 21:40:37 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 15 Sep 2006 17:40:21 -0400 Subject: Re: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-11.txt From: Eric Burger To: IETF SPEECHSC Message-ID: Thread-Topic: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-11.txt Thread-Index: AcbZA0R018pV2sO0RnOpHRu9OMvhvgADEbAc In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 15 Sep 2006 21:40:38.0043 (UTC) FILETIME=[955F5EB0:01C6D90F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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="===============1399975138==" Errors-To: speechsc-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1399975138== Content-type: multipart/alternative; boundary="B_3241186822_1425508" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3241186822_1425508 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Please hold off =AD there is a problem with the file. Only the first 78 page= s are in the file. On 9/15/06 3:50 PM, "Internet-Drafts@ietf.org" wrote: > 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. >=20 > Title : Media Resource Control Protocol Version 2 (MRCP= v2) > Author(s) : D. Burnett, S. Shanmugham > Filename : draft-ietf-speechsc-mrcpv2-11.txt > Pages : 206 > Date : 2006-9-15 > =20 > 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-11.txt >=20 > 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. >=20 > 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-11.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-11.txt". > =20 > 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 read= ers > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 --B_3241186822_1425508 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-11.txt Pleas= e hold off – there is a problem with the file.  Only the first 78= pages are in the file.


On 9/15/06 3:50 PM, "Internet-Drafts@ietf.org" <Internet-Draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Inte= rnet-Drafts
directories.
This draft is a work item of the Speech Services Control Working Group of t= he IETF.

        Title    &nb= sp;      : Media Resource Control Protocol Ver= sion 2 (MRCPv2)
        Author(s)    = ;   : D. Burnett, S. Shanmugham
        Filename    =     : draft-ietf-speechsc-mrcpv2-11.txt
        Pages    &nb= sp;      : 206
        Date    &nbs= p;       : 2006-9-15
       
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 protoc= ol
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-11.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-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/i= etf/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-11.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 th= e response(s), you will need "munpack" or
        a MIME-compliant mail reade= r.  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 mes= sages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


 --B_3241186822_1425508-- --===============1399975138== 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 --===============1399975138==-- From speechsc-bounces@ietf.org Wed Sep 20 04:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxhH-0004pi-5a; Wed, 20 Sep 2006 04:44:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxhF-0004j5-Q7 for speechsc@ietf.org; Wed, 20 Sep 2006 04:44:45 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPxh2-0005xB-RL for speechsc@ietf.org; Wed, 20 Sep 2006 04:44:45 -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 <0J5V004GEUVY4P@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 20 Sep 2006 16:43:11 +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 <0J5V00HN5UVXNW@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 20 Sep 2006 16:43:10 +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 <0J5V002Y5UXUVC@szxml03-in.huawei.com> for speechsc@ietf.org; Wed, 20 Sep 2006 16:44:20 +0800 (CST) Date: Wed, 20 Sep 2006 14:09:16 +0530 From: sreekanth To: speechsc@ietf.org Message-id: <002801c6dc90$4244e310$a504120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sarvi@cisco.com Subject: [Speechsc] message body in GET-PARAMS.. 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="===============1928991565==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1928991565== Content-type: multipart/alternative; boundary="Boundary_(ID_WyPEvnjytvZM1ffHmH5cug)" This is a multi-part message in MIME format. --Boundary_(ID_WyPEvnjytvZM1ffHmH5cug) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, The table in draft-06(page 22) mentions that content headers like Content-Type, Content-Length, Content-Encoding etc are optional for GET-PARAMS method.. Is there is any use case of having message body in GET-PARAMS ? Please do clarify this.. Thanks&Regards, 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_WyPEvnjytvZM1ffHmH5cug) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
 
The table in draft-06(page 22) mentions that content headers like Content-Type, Content-Length, Content-Encoding etc are optional for GET-PARAMS method..
 
Is there is any use case of having message body in GET-PARAMS ?
 
Please do clarify this..
 
 
Thanks&Regards,
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_WyPEvnjytvZM1ffHmH5cug)-- --===============1928991565== 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 --===============1928991565==-- From speechsc-bounces@ietf.org Wed Sep 20 11:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ49Y-0001KJ-7N; Wed, 20 Sep 2006 11:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ49W-0001KD-IX for speechsc@ietf.org; Wed, 20 Sep 2006 11:38:22 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ49V-0000nu-6n for speechsc@ietf.org; Wed, 20 Sep 2006 11:38:22 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k8KFcKT4019066 for ; Wed, 20 Sep 2006 11:38:20 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8KFcK53255878 for ; Wed, 20 Sep 2006 09:38:20 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8KFcJaZ002082 for ; Wed, 20 Sep 2006 09:38:19 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8KFcJEG002070 for ; Wed, 20 Sep 2006 09:38:19 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Brett Gavagni Date: Wed, 20 Sep 2006 11:38:17 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/20/2006 09:38:19, Serialize complete at 09/20/2006 09:38:19 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Speechsc] NLSML clarification X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Hi, I'm hoping to solicit some feedback from the implementing community with a MRCP clarification request w.r.t. NLSML. More specifically, NLSML results containing a grammar URI with invalid XML characters. A MRCP client sends a RECOGNIZE request to a MRCP server identifying the grammars to define and enable. Example: C->S RECOGNIZE 2 MRCP/1.0 no-input-timeout: 7000 recognizer-start-timers: false speech-language: en-US content-type: text/uri-list content-length: 105 http://speechsc.ietf.org/srgs1.grxml http://speechsc.ietf.org/srgs?test1=test1&test2=test2 A RECOGNITION-COMPLETE is later returned by the MRCP server to the MRCP client matching the external grammar query URI (" http://speechsc.ietf.org/srgs?test1=test1&test2=test2"). The resulting generated NLSML using this URI reference is not well formed however, According to the MAY 30 2001 draft of the NLSML specification: The value is the grammar URI used by the dialog markup interpreter to specify the grammar. What is the common practice to avoid this condition? We see the following three options (outside of separate DEFINE-GRAMMAR): 1) MRCP server URL encodes offending XML chars (? &) 2) MRCP server XML encodes offending XML chars (? &) 3) MRCP client URL encodes offending XML chars Which of the following examples below (A or B) appears the most appropriate from MRCP server perspective? Example A: NLSML with a grammar attribute reference with the XML sensitive characters represented URI query string which transformed as the escaped octet values. S->C RECOGNITION-COMPLETE 2 COMPLETE MRCP/1.0 completion-cause: 000 success content-length: 457 content-type: application/x-nlsml; charset=UTF-8 Speech Example B: NLSML with a grammar attribute reference unaltered as specified by the MRCP client. S->C RECOGNITION-COMPLETE 2 COMPLETE MRCP/1.0 completion-cause: 000 success content-length: 457 content-type: application/x-nlsml; charset=UTF-8 Speech Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Sep 20 14:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6o7-0001Ix-Qf; Wed, 20 Sep 2006 14:28:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ6o6-0001Ig-LW for speechsc@ietf.org; Wed, 20 Sep 2006 14:28:26 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ6nw-0007MH-OR for speechsc@ietf.org; Wed, 20 Sep 2006 14:28:26 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k8KISFVj027136 for ; Wed, 20 Sep 2006 14:28:15 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8KISFRv374342 for ; Wed, 20 Sep 2006 12:28:15 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8KISFVn021757 for ; Wed, 20 Sep 2006 12:28:15 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8KISFJq021752; Wed, 20 Sep 2006 12:28:15 -0600 In-Reply-To: <002801c6dc90$4244e310$a504120a@china.huawei.com> To: sreekanth MIME-Version: 1.0 Subject: Re: [Speechsc] message body in GET-PARAMS.. X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Brett Gavagni Date: Wed, 20 Sep 2006 14:28:14 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/20/2006 12:28:15, Serialize complete at 09/20/2006 12:28:15 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: speechsc@ietf.org, sarvi@cisco.com X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Hi, I can't think of a specific non-proprietary use case offhand, for a MRCP server requiring a body on a GET-PARAMS request, as the message headers is what should be used as stated in draft-10 section: 6.1.2. GET-PARAMS The client SHOULD indicate the list of parameters it wants to read from the server by sending a set of empty header fields. However, a MRCP server response to a GET-PARAMS may contain a body as stated in draft-10 section: 9.5.4. Recognizer Context Block In the "GET-PARAMS" method, if an empty recognizer-context-block header is present, then the recognizer SHOULD return its vendor-specific context block, if any, in the message body as a MIME-entity with a specific Content-ID. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com sreekanth 09/20/2006 04:39 AM Please respond to sreekanth To speechsc@ietf.org cc sarvi@cisco.com Subject [Speechsc] message body in GET-PARAMS.. Hi, The table in draft-06(page 22) mentions that content headers like Content-Type, Content-Length, Content-Encoding etc are optional for GET-PARAMS method.. Is there is any use case of having message body in GET-PARAMS ? Please do clarify this.. Thanks&Regards, 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! _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Sep 21 11:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQj0-0007Eg-Gx; Thu, 21 Sep 2006 11:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNGf-0001qW-OL for speechsc@ietf.org; Thu, 21 Sep 2006 08:03:01 -0400 Received: from mail.eckoh.com ([81.20.37.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNGb-0005FD-EV for speechsc@ietf.org; Thu, 21 Sep 2006 08:03:01 -0400 Received: from mail.eckoh.fr ([192.168.100.100]) by mail.eckoh.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Sep 2006 13:02:29 +0100 Content-class: urn:content-classes:message Date: Thu, 21 Sep 2006 13:01:03 +0100 MIME-Version: 1.0 Message-ID: X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: Speechsc] NLSML clarification Thread-Index: AcbddZxK4l+39FfDSxOyvdp0fFXiiw== From: "Thierry-Michel Barral" To: X-OriginalArrivalTime: 21 Sep 2006 12:02:29.0363 (UTC) FILETIME=[CFC95C30:01C6DD75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Thu, 21 Sep 2006 11:44:28 -0400 Subject: [Speechsc] Speechsc] NLSML clarification X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0336696458==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0336696458== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD75.9CCD92D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD75.9CCD92D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Based on XML standard, the grammar attribute value can't have neither "<" nor "&" in it. Meaning example B won't be parseable with a XML parser. =20 Also, as the grammar attribute is an URI, the encoding is not a problem, there are enough tools to handle it, no worries. =20 /tmb ------_=_NextPart_001_01C6DD75.9CCD92D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Based = on XML=20 standard, the grammar attribute value can't have neither "<" nor = "&" in=20 it.
Meaning example B=20 won't be parseable with a XML parser.
 
Also, = as the grammar=20 attribute is an URI, the encoding is not a problem, there are enough = tools to=20 handle it, no worries.
 
/tmb
------_=_NextPart_001_01C6DD75.9CCD92D0-- --===============0336696458== 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 --===============0336696458==-- From speechsc-bounces@ietf.org Fri Sep 22 15:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQqNz-0000Ue-I8; Fri, 22 Sep 2006 15:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQqNx-0000UZ-Nx for speechsc@ietf.org; Fri, 22 Sep 2006 15:08:29 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQqNw-0007ex-HZ for speechsc@ietf.org; Fri, 22 Sep 2006 15:08:29 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:08:28 -0400 Received: from 10.128.41.61 ([10.128.41.61]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Sep 2006 19:08:27 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 22 Sep 2006 15:08:18 -0400 From: Eric Burger To: IETF SPEECHSC Message-ID: Thread-Topic: WGLC MRCPv2 Thread-Index: AcbeenZftTQYE0ptEdugygAWy5cvmw== X-Priority: 2 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Sep 2006 19:08:28.0778 (UTC) FILETIME=[7CCC54A0:01C6DE7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 This is notice that the Work Group Last Call on MRCPv2 begins today. Last call will end on Monday, 9 October 2006. http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-11.txt _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sat Sep 30 21:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTqAJ-0002AD-6a; Sat, 30 Sep 2006 21:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTqAH-0002A6-9F for speechsc@ietf.org; Sat, 30 Sep 2006 21:30:45 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTqAG-0002DM-2y for speechsc@ietf.org; Sat, 30 Sep 2006 21:30:45 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Sep 2006 21:30:43 -0400 Received: from 10.128.41.23 ([10.128.41.23]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 1 Oct 2006 01:30:42 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sat, 30 Sep 2006 15:46:41 -0400 From: Eric Burger To: IETF SPEECHSC Message-ID: Thread-Topic: Just a Reminder Thread-Index: AcbkySZfZRxwr1C8EduUqwAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Oct 2006 01:30:43.0977 (UTC) FILETIME=[368BF790:01C6E4F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Speechsc] Just a Reminder 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 WGLC for MRCPv2 closes October 9. I assume the total silence means, "Wow, we love this, since we've been picking it to death for the last 9 months. I'm just not saying anything because I'm only up to page 154 of XXX. However, I'll get my comments in, or at the very least, a statement that it looks good, by the 9th." For the W3C'ers out there, be aware that we do NOT vote on drafts. However, total silence tends to make folks nervous... Thanks, and get your comments or endorsements in soon! -- - Eric _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc