From speechsc-bounces@ietf.org Tue Aug 15 14:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3vh-0007mS-H9; Tue, 15 Aug 2006 14:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3vg-0007mM-VL for speechsc@ietf.org; Tue, 15 Aug 2006 14:46:20 -0400 Received: from web32901.mail.mud.yahoo.com ([209.191.69.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GD3vf-0006UJ-Ea for speechsc@ietf.org; Tue, 15 Aug 2006 14:46:20 -0400 Received: (qmail 93977 invoked by uid 60001); 15 Aug 2006 18:46:18 -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=E/LMYbU255cHo9V/Mdu9RdUpLTo7JnP7OQPKhZp0p7GKz5cr+PnnUnR/EhkrTFBMyWdSWcUlU31C9aqAv3lupLeln+RdpERkTe5xLSqVzZLf+bVmtUftVHAm0cZSI141enOVdlLUJqpwuIscVIRnv6Rlsc75Gwo+UrEpboRlIrQ= ; Message-ID: <20060815184618.93975.qmail@web32901.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32901.mail.mud.yahoo.com via HTTP; Tue, 15 Aug 2006 11:46:18 PDT Date: Tue, 15 Aug 2006 11:46:18 -0700 (PDT) From: Dan Burnett Subject: RE: [speechsc] uri-list not defined for Lexicon-Search-Order To: speechsc@ietf.org In-Reply-To: <330A23D8336C0346B5C1A5BB1966664702E02844@ATLANTIS.Brooktrout.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: a492040269d440726bfd84680622cee7 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 According to RFC1630, the following characters are considered "reserved" for special use: = | ; | / | # | ? | : | space The < and > are, however, considered "punctuation" and are neither permitted in URIs nor reserved for special use. Thus, we should use < and > as URI boundary markers. As for the character(s) used to separate multiple bounded URIs, I believe it's largely a matter of personal preference. In my opinion there are three advantages to using spaces for this separator: 1) It is slightly more readable than using ';', 2) It is consistent with HTML 4.01, as Jerry points out, and 3) It permits us to use ';' later as a character for adding annotations to each URI if we should decide we need it, eg., ";extrastuff ". Obviously this could go the other way around, too, but I find this hierarchy (; tighter binding than space) easier to read. The only advantage I see to using ';' as the separator for the bounded URIs is that the BNF in section 15 already uses it, but since we have to add the < and > characters anyway, this shouldn't be any more difficult for implementers to change. I will use the following BNF unless I hear further objections: lexicon-search-order = "Lexicon-Search-Order" ":" "<" absoluteURI ">" *[" " "<" absoluteURI ">"] CRLF -- dan --- "Burger, Eric" wrote: > Imap-channel is long dead and forgotten. Even if it > is by Dr. Burger, > it's wrong ;) > > -- > Dr. Eric Burger, Ph.D. > [Really!] > > -----Original Message----- > From: Carter, Jerry [mailto:jerry.carter@nuance.com] > > Sent: Thursday, May 11, 2006 10:03 AM > To: Shanmugham, Saravanan; Dave Burke; > speechsc@ietf.org > Subject: RE: [speechsc] uri-list not defined for > Lexicon-Search-Order > > Where? > > The 'uri-list' in HTML 4.01 is space separated. [1] > Eric Berger's lemonade specification used a space > separated list. [2] > > [1] http://www.w3.org/TR/html4/struct/objects.html > [2] > http://www3.ietf.org/proceedings/03jul/I-D/draft-ietf-lemonade-imap-chan > nel- > 00.txt > > > > -----Original Message----- > > From: Shanmugham, Saravanan > [mailto:sarvi@cisco.com] > > Sent: Thursday, May 11, 2006 9:42 AM > > To: Dave Burke; speechsc@ietf.org > > Subject: RE: [speechsc] uri-list not defined for > Lexicon-Search-Order > > > > I like the angle brackets idea considering it is a > standard used in a > > lot of places to mark URI and or a list of URI. > > > > Thx, > > Sarvi > > > > -----Original Message----- > > From: Dave Burke > [mailto:david.burke@voxpilot.com] > > Sent: Thursday, May 11, 2006 2:32 AM > > To: Shanmugham, Saravanan; speechsc@ietf.org > > Subject: Re: [speechsc] uri-list not defined > for > > Lexicon-Search-Order > > > > Problem with the ";" delimiter is that it > could (and > > actually very likely) will be part of the > URI. For example, > > > > http://example.com/file1.xml;jsessionid=1 > > http://example.com/file2.xml;jsessionid=2 > > > > would result in > > > > Lexicon-Search-Order: > > > http://example.com/file1.xml;jsessionid=1;http://example.co > > m/file2.xml;jsessionid=2 > > > > thus causing parsing problems. Was thinking > we could do > > something like (i.e. > > using angle brackets around the URIs): > > > > lexicon-search-order = > "Lexicon-Search-Order" ":" > > "<" absoluteURI > ">" *[";<" > > absoluteURI ">" ] CRLF Dave > > > > > > ----- Original Message ----- > > From: "Shanmugham, Saravanan" > > > To: "Dave Burke" ; > > > Sent: Wednesday, May 10, 2006 7:26 PM > > Subject: RE: [speechsc] uri-list not defined > for > > Lexicon-Search-Order > > > > > > The ABNF specified under the header > definition is not upto-date > and > > needs to be fixed. > > The normative ABNF in section 15 is defined > as follows. > > > > lexicon-search-order = > "Lexicon-Search-Order" ":" > > absoluteURI > *[";" absoluteURI] CRLF > > > > Lets have the header section corrected to > reflect this > definition. > > > > Sarvi > > > > -----Original Message----- > > From: Dave Burke > [mailto:david.burke@voxpilot.com] > > Sent: Monday, May 08, 2006 4:02 AM > > To: speechsc@ietf.org > > Subject: [speechsc] uri-list not defined > for > > Lexicon-Search-Order > > > > ABNF says we've got uri-list as the > value of > > Lexicon-Search-Order but this is not > defined (sure we've > > got a MIME type text/uri-list but that's > a different thing). > > > > Not sure that a comma delimited list > makes sense here > > since a comma is a reserved character > for URIs > > (RFC2396)... unless the URIs are > enclosed in angle > brackets... > > > > Dave > > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ 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 Aug 15 17:04:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD64j-0007nd-FA; Tue, 15 Aug 2006 17:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD64i-0007nY-7P for speechsc@ietf.org; Tue, 15 Aug 2006 17:03:48 -0400 Received: from web32913.mail.mud.yahoo.com ([209.191.69.113]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GD64c-0001Mh-T0 for speechsc@ietf.org; Tue, 15 Aug 2006 17:03:48 -0400 Received: (qmail 95033 invoked by uid 60001); 15 Aug 2006 21:03:42 -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=uZ1fDunuowZWCc3/iZVViT2ky1CQsphtHn5QnGqT7J1HfupuRFBrILFHiPgeAYhwi43K1Fd1tB+8kWr1C7EjKJ6udIc5xWLcntQYcYuRinAxTkLE8j4AE89wlb2466sqmGCx3DURKMtGDqBZQf0loMWc/YvNA3jChh6lhoaV/Lo= ; Message-ID: <20060815210342.95031.qmail@web32913.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32913.mail.mud.yahoo.com via HTTP; Tue, 15 Aug 2006 14:03:42 PDT Date: Tue, 15 Aug 2006 14:03:42 -0700 (PDT) From: Dan Burnett Subject: Re: [speechsc] Fix status code response in 8.4.1 / 8.4.16 To: Dave Burke , speechsc@ietf.org In-Reply-To: <01c101c6728e$df454860$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: 93238566e09e6e262849b4f805833007 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 Now tracked as issue 100 at http://www.softarmor.com/roundup/speechsc/. -- Dan --- Dave Burke wrote: > If a unit for Jump-Size is not supported, I think > the response should use status code 409 Unsupported > header value and not 404 as is described in 8.4.1. > Similarly for Speak-Length in 8.4.16 > > 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 Wed Aug 16 07:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJVe-0006zD-VP; Wed, 16 Aug 2006 07:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJVd-0006z3-JQ for speechsc@ietf.org; Wed, 16 Aug 2006 07:24:29 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDJVb-0005Yk-HJ for speechsc@ietf.org; Wed, 16 Aug 2006 07:24:29 -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 <0J43000NG91C2S@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 16 Aug 2006 19:24:48 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J43002RN91BIZ@szxga01-in.huawei.com> for speechsc@ietf.org; Wed, 16 Aug 2006 19:24:48 +0800 (CST) Received: from HTIPL20760 ([10.18.5.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J43009AM9GBR2@szxml04-in.huawei.com> for speechsc@ietf.org; Wed, 16 Aug 2006 19:33:49 +0800 (CST) Date: Wed, 16 Aug 2006 16:51:45 +0530 From: sreekanth Subject: Re: [Speechsc] query regarding multiple resources in a MRCP clientsession To: "Reifenrath, Klaus, VF-Group" Message-id: <002201c6c126$290ffef0$4a05120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal References: <21FBFFD8B2486242AB9A09E20A7E9C44B21A8C@gpsmx05.gps.internal.vodafone.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: speechsc@ietf.org, sarvi@cisco.com 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="===============0894369285==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0894369285== Content-type: multipart/alternative; boundary="Boundary_(ID_HfNR9ICBbDes+6q41VYUfA)" This is a multi-part message in MIME format. --Boundary_(ID_HfNR9ICBbDes+6q41VYUfA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT 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 --Boundary_(ID_HfNR9ICBbDes+6q41VYUfA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
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 <sip:mresources@server.example.com>

From:sarvi <sip:sarvi@example.com>;tag=1928301774

Call-ID:a84b4c76e66710

CSeq:314163 INVITE

Contact:<sip:sarvi@example.com>

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 -----
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
--Boundary_(ID_HfNR9ICBbDes+6q41VYUfA)-- --===============0894369285== 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 --===============0894369285==-- From speechsc-bounces@ietf.org Wed Aug 16 07:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJtx-0005qD-Go; Wed, 16 Aug 2006 07:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDJtv-0005q4-VF for speechsc@ietf.org; Wed, 16 Aug 2006 07:49:35 -0400 Received: from web32914.mail.mud.yahoo.com ([209.191.69.114]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDJtu-0007ow-LK for speechsc@ietf.org; Wed, 16 Aug 2006 07:49:35 -0400 Received: (qmail 67833 invoked by uid 60001); 16 Aug 2006 11:49:24 -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=jclRxiFPhnKQ94R+9piNtAzFh7QHWMspe+cbEUTJG97maG+3IO2LYagFogfH8g7jHX09hhysj0JQRlKB1P8s7F/tREWn93CTA1zrWg7IdVgehKpDO4Lf854I0bGfO/BLll1DvAfC27hfH16juq/hJ0CwRlAlIsdQGfQzm07Zzz8= ; Message-ID: <20060816114924.67831.qmail@web32914.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32914.mail.mud.yahoo.com via HTTP; Wed, 16 Aug 2006 04:49:24 PDT Date: Wed, 16 Aug 2006 04:49:24 -0700 (PDT) From: Dan Burnett Subject: Re: [speechsc] Fix Speak-Length ABNF To: Dave Burke , speechsc@ietf.org In-Reply-To: <01b601c6728e$dbbfa410$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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Fixed in spec draft -11. I had to add some new productions since the existing ones were shared with Jump-Size. Also, I modified the text "The value MUST be a positive integer." to "If numeric, the value MUST be a positive integer." to match the permitted values. -- dan --- Dave Burke wrote: > Currently, the ABNF allows a sign yet the prose says > it strictly positive. Presumably no sign at all? > > 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 Wed Aug 16 08:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKRU-0008HZ-Sk; Wed, 16 Aug 2006 08:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKRT-0008HU-Hw for speechsc@ietf.org; Wed, 16 Aug 2006 08:24:15 -0400 Received: from web32903.mail.mud.yahoo.com ([209.191.69.80]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDKRR-0003kB-5I for speechsc@ietf.org; Wed, 16 Aug 2006 08:24:15 -0400 Received: (qmail 78659 invoked by uid 60001); 16 Aug 2006 12:17: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=d4aQ7J3B8UG9KnByGDzb9OzMf1D5I0YP6sDpELjEGQwVQsPe0kpGatTvZOUD1KOlSSmb8C9FFREry71lA3ktfLK77Iwqrx8ha5dGEXQt3F7rJGFUd2y/04Dp/V5Q4+abvXv+x5fVuO9D1xR8/RJIfSrjNzM3PFa+EjeOekP8dHg= ; Message-ID: <20060816121730.78657.qmail@web32903.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32903.mail.mud.yahoo.com via HTTP; Wed, 16 Aug 2006 05:17:30 PDT Date: Wed, 16 Aug 2006 05:17:30 -0700 (PDT) From: Dan Burnett Subject: Re: [speechsc] Clarification on speechsynth and speechrecog part of same session To: Dave Burke , speechsc@ietf.org In-Reply-To: <01d101c6728e$e555b640$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: cab78e1e39c4b328567edb48482b6a69 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 Applied to spec draft -11. -- dan --- Dave Burke wrote: > In 8.4.2 it says: > > If the recognizer or signal detector resource is > on the same server > as the synthesizer, the server SHOULD recognize > their interactions by > their common MRCPv2 channel identifier (ignoring > the portion after > "@" which is the resource type) and work with > both to provide kill- > on-barge-in support. > > My understanding was that the server can determine a > speechrecog and speechsynth should work in concert > simply by virtue of the fact that they were set up > in the same SIP dialog and hence part of the same > session. The paragraph in 8.4.2 anyways moot because > the server assigns the channel identifiers. Suggest > something like: > > If the recognizer or signal detector resource is > on the same server > as the synthesizer and are part of the same > session, the server > SHOULD work with both to provide kill-on-barge-in > support. > > 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 Thu Aug 17 07:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDfgW-0006rh-Ti; Thu, 17 Aug 2006 07:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDfgU-0006rc-Ue for speechsc@ietf.org; Thu, 17 Aug 2006 07:05:10 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDfgT-0002gz-5J for speechsc@ietf.org; Thu, 17 Aug 2006 07:05:10 -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 <0J4500GR238LKA@szxga03-in.huawei.com> for speechsc@ietf.org; Thu, 17 Aug 2006 19:14:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J450072Q38LY6@szxga03-in.huawei.com> for speechsc@ietf.org; Thu, 17 Aug 2006 19:14:45 +0800 (CST) Received: from HTIPL20760 ([10.18.5.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4500JH93BDGI@szxml04-in.huawei.com> for speechsc@ietf.org; Thu, 17 Aug 2006 19:16:27 +0800 (CST) Date: Thu, 17 Aug 2006 16:34:15 +0530 From: sreekanth To: speechsc@ietf.org Message-id: <006201c6c1ec$e1422950$4a05120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 1.6 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sarvi@cisco.com Subject: [Speechsc] (no subject) 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="===============1201004276==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1201004276== Content-type: multipart/alternative; boundary="Boundary_(ID_PHu/rPMGpfmAVYQYzfZspw)" This is a multi-part message in MIME format. --Boundary_(ID_PHu/rPMGpfmAVYQYzfZspw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT What will happen if the recording was not success or if the client does not provide the RECORD-URI and the server has no memory to store the data locally.. Is it ok that server can sent RECORD-URI header with Null value in the above case. The following is from MRCPv2 spec... "If the recording was a success the "STOP" response MUST contain a Record-URI header pointing to the recorded audio content or to a MIME part in the body of the "STOP" response containing the recorded audio." Any comments on this will be highy appreciated.. 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_PHu/rPMGpfmAVYQYzfZspw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
What will happen if the recording was not success or if the client does not provide the RECORD-URI and the server has no memory to store the data locally.. 
 
 Is it ok that server can sent RECORD-URI header with Null value in the above case.

The following is from MRCPv2 spec...
"If the recording was a success the "STOP" response MUST contain a Record-URI header pointing to the recorded audio
content or to a MIME part in the body of the "STOP" response containing the recorded audio."
 
Any comments on this will be highy appreciated..

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_PHu/rPMGpfmAVYQYzfZspw)-- --===============1201004276== 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 --===============1201004276==-- From speechsc-bounces@ietf.org Fri Aug 18 10:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5Zs-00028m-6R; Fri, 18 Aug 2006 10:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5Zr-00028c-9B for speechsc@ietf.org; Fri, 18 Aug 2006 10:44:03 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE5Zq-0003YD-07 for speechsc@ietf.org; Fri, 18 Aug 2006 10:44:03 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7IEhxan026400 for ; Fri, 18 Aug 2006 10:43:59 -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 k7IEhxQZ283336 for ; Fri, 18 Aug 2006 08:43:59 -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 k7IEhxs7010209 for ; Fri, 18 Aug 2006 08:43:59 -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 k7IEhxMp010203 for ; Fri, 18 Aug 2006 08:43:59 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Brett Gavagni Date: Fri, 18 Aug 2006 10:43:56 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 08/18/2006 08:43:59, Serialize complete at 08/18/2006 08:43:59 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speechsc] Input-Waveform-URI clarification request X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org I would like to propose adding some clarification wording to section 9.4.10. Input-Waveform-URI: Something along the lines of: When the synthesizer and recognizer resources are part of the same MRCPv2 session, the client may encounter unexpected results with active "SPEAK" requests that have kill-on-barge-in enabled. 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 Sun Aug 20 15:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEt5V-0005qB-05; Sun, 20 Aug 2006 15:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEt5T-0005o0-BB for speechsc@ietf.org; Sun, 20 Aug 2006 15:35:59 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEt5Q-0001LQ-S4 for speechsc@ietf.org; Sun, 20 Aug 2006 15:35:59 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 15:36:14 -0400 Received: from 10.128.41.3 ([10.128.41.3]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Sun, 20 Aug 2006 19:36:13 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 20 Aug 2006 15:26:45 -0400 From: Eric Burger To: IETF SPEECHSC Message-ID: Thread-Topic: MRCPv2 Publication Timetable Thread-Index: AcbEjpKQ0QcoozCBEduxFQAWy5cvmw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Aug 2006 19:36:14.0383 (UTC) FILETIME=[E5F1BBF0:01C6C48F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Speechsc] MRCPv2 Publication Timetable 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 a work group, we are making great progress towards publication of MRCPv2 as a Proposed Standard. While there is still moderate list traffic, it is mostly clarifications and resolutions. We, as chairs, have noticed quite a few vendors talking about their "MRCPv2 Products." Rather than whack them on the head, our plan is to give them something tangible to claim. To this end, it is our expectation that we will have a new MRCPv2 draft shortly. We will immediately start a Work Group Last Call (WGLC) on the document. WGLC comments that we will entertain are ones for which :- - The Internet Will Melt if we don't fix X - No one (and we mean NO ONE) can use MRCPv2 if we don't include X - No one (and we mean NO ONE) can use MRCPv2 if we do include X At this point in time, we do not expect any X's. Yes, there are a lot of open feature requests; see . We do NOT expect MRCPv2 to be perfect. We do expect it to be useful. Our expectation is that WGLC will complete well before October. Publication of MRCPv2 is by no means the last word on MRCP. PLEASE review RFC2026. MRCPv2 is a Proposed Standard. We EXPECT it to get better over time. Consider this from RFC20206: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. There will be plenty of opportunity, if there is community interest, to bring MRCPv2 to Draft Standard. That is where we bring in independent interoperability reports, drop optional features that one or fewer implementations implement, add features that we realize we really could not do without, etc. So, again, unless your comment on the next draft of MRCPv2 does not fit into The Sky Is Falling category, be sure to put it into the tracker, at . We will note editorial comments, like "you spelt spelled as spelt," as such and will fix as many as possible during AUTH48. See for what AUTH48 is about. Thank you all for your participation!!! _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Aug 23 05:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpS6-0003eu-Qc; Wed, 23 Aug 2006 05:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpS5-0003ej-En for speechsc@ietf.org; Wed, 23 Aug 2006 05:55:13 -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 1GFnEK-0003u8-E9 for speechsc@ietf.org; Wed, 23 Aug 2006 03:32:52 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFml9-0007Zv-Vn for speechsc@ietf.org; Wed, 23 Aug 2006 03:02:57 -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 <0J4F000TGVUQ42@szxga03-in.huawei.com> for speechsc@ietf.org; Wed, 23 Aug 2006 15:08:50 +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 <0J4F005UGVUPU0@szxga03-in.huawei.com> for speechsc@ietf.org; Wed, 23 Aug 2006 15:08:50 +0800 (CST) Received: from srilakshmi ([10.18.5.95]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F00INPVJSRY@szxml03-in.huawei.com> for speechsc@ietf.org; Wed, 23 Aug 2006 15:02:19 +0800 (CST) Date: Wed, 23 Aug 2006 12:28:19 +0530 From: Srilakshmi To: speechsc@ietf.org, 'Dave Burke' Message-id: <003101c6c681$84746820$5f05120a@srilakshmi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbGgYP2Xye78yL/T6+rjXoLIbt8Dw== X-Spam-Score: -1.2 (-) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: Subject: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification 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="===============1651990001==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1651990001== Content-type: multipart/alternative; boundary="Boundary_(ID_fs2YF+CqfTHYdbuxE6v58Q)" This is a multi-part message in MIME format. --Boundary_(ID_fs2YF+CqfTHYdbuxE6v58Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, In section 11 of draft10 The following two statements are contradicting each other. 11.4.20. Abort-Verification This header MUST be sent in a "STOP" request to indicate whether or not to abort a VERIFY method in progress. 11.13. STOP The "STOP" method can carry a "Abort-Verification" header which specifies if the verification result until that point should be discarded or returned. If this header is not present or if the value is "true", the verification result is discarded and the "STOP" response does not contain any result data. If the header is present and its value is "false", the "STOP" response SHOULD contain a "Completion-Cause" header and carry the Verification result data in its body. Please provide some clarification regarding this issue. Regards, Srilakshmi K. --Boundary_(ID_fs2YF+CqfTHYdbuxE6v58Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

Hi,

 

In section 11 of draft10

 

The following two statements are contradicting each other.

 

11.4.20.  Abort-Verification

 

   This header MUST be sent in a "STOP" request to indicate whether or

   not to abort a VERIFY method in progress. 

 

11.13.  STOP

   The "STOP" method can carry a "Abort-Verification" header which

   specifies if the verification result until that point should be

   discarded or returned.  If this header is not present or if the value

   is "true", the verification result is discarded and the "STOP"

   response does not contain any result data.  If the header is present

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

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

   its body.

 

Please provide some clarification regarding this issue.

 

Regards,

Srilakshmi K.

--Boundary_(ID_fs2YF+CqfTHYdbuxE6v58Q)-- --===============1651990001== 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 --===============1651990001==-- From speechsc-bounces@ietf.org Wed Aug 23 06:18:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpnu-0004nD-RA; Wed, 23 Aug 2006 06:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpnt-0004n7-Ig for speechsc@ietf.org; Wed, 23 Aug 2006 06:17:45 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFpnq-00074E-Gl for speechsc@ietf.org; Wed, 23 Aug 2006 06:17:45 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G00LS95C0K5@szxga02-in.huawei.com> for speechsc@ietf.org; Wed, 23 Aug 2006 18:33:36 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G00AT95BZPL@szxga02-in.huawei.com> for speechsc@ietf.org; Wed, 23 Aug 2006 18:33:36 +0800 (CST) Received: from SAGAR ([10.18.5.155]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4G005RP52D26@szxml04-in.huawei.com> for speechsc@ietf.org; Wed, 23 Aug 2006 18:27:54 +0800 (CST) Date: Wed, 23 Aug 2006 15:45:40 +0530 From: Manjunatha Subject: RE: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification In-reply-to: <003101c6c681$84746820$5f05120a@srilakshmi> To: 'Srilakshmi' , speechsc@ietf.org, 'Dave Burke' Message-id: <000601c6c69d$166cec00$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: AcbGgYP2Xye78yL/T6+rjXoLIbt8DwAGrz0g X-Spam-Score: 0.2 (/) X-Scan-Signature: eb4c5242518af073df6fe45f0d1cde3e Cc: 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="===============0246932349==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0246932349== Content-type: multipart/alternative; boundary="Boundary_(ID_3S5cUrvsuvmT5GCRGiCpWg)" This is a multi-part message in MIME format. --Boundary_(ID_3S5cUrvsuvmT5GCRGiCpWg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT According to draft. Abort-Verification = true .....In Stop method and Abort-Verification method is absent in the Stop method is one and the same.. This is wrong. according to my understanding.. So pls give some clarification which is correct...? Regards, Manjunatha N O _____ From: Srilakshmi [mailto:ksrilakshmi@huawei.com] Sent: Wednesday, August 23, 2006 12:28 PM To: speechsc@ietf.org; 'Dave Burke' Subject: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification Hi, In section 11 of draft10 The following two statements are contradicting each other. 11.4.20. Abort-Verification This header MUST be sent in a "STOP" request to indicate whether or not to abort a VERIFY method in progress. 11.13. STOP The "STOP" method can carry a "Abort-Verification" header which specifies if the verification result until that point should be discarded or returned. If this header is not present or if the value is "true", the verification result is discarded and the "STOP" response does not contain any result data. If the header is present and its value is "false", the "STOP" response SHOULD contain a "Completion-Cause" header and carry the Verification result data in its body. Please provide some clarification regarding this issue. Regards, Srilakshmi K. --Boundary_(ID_3S5cUrvsuvmT5GCRGiCpWg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

According to draft…

 

Abort-Verification = true ………..In Stop method and

Abort-Verification method is absent in the Stop method is one and the same..

This is wrong… according to my understanding..

 

So pls give some clarification which is correct…..?

 

 

Regards,

Manjunatha N O

 

 

From: Srilakshmi [mailto:ksrilakshmi@huawei.com]
Sent: Wednesday, August 23, 2006 12:28 PM
To: speechsc@ietf.org; 'Dave Burke'
Subject: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification

 

 

Hi,

 

In section 11 of draft10

 

The following two statements are contradicting each other.

 

11.4.20.  Abort-Verification

 

   This header MUST be sent in a "STOP" request to indicate whether or

   not to abort a VERIFY method in progress. 

 

11.13.  STOP

   The "STOP" method can carry a "Abort-Verification" header which

   specifies if the verification result until that point should be

   discarded or returned.  If this header is not present or if the value

   is "true", the verification result is discarded and the "STOP"

   response does not contain any result data.  If the header is present

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

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

   its body.

 

Please provide some clarification regarding this issue.

 

Regards,

Srilakshmi K.

--Boundary_(ID_3S5cUrvsuvmT5GCRGiCpWg)-- --===============0246932349== 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 --===============0246932349==-- From speechsc-bounces@ietf.org Wed Aug 30 11:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIS05-0003ri-6q; Wed, 30 Aug 2006 11:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIS04-0003rd-AX for speechsc@ietf.org; Wed, 30 Aug 2006 11:29:08 -0400 Received: from web32902.mail.mud.yahoo.com ([209.191.69.79]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIS01-0003hY-SR for speechsc@ietf.org; Wed, 30 Aug 2006 11:29:08 -0400 Received: (qmail 244 invoked by uid 60001); 30 Aug 2006 15:29: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=xXJ/8vKuBl7RXxjqPEJfsxplZAK0Bh7QYkk1/kBDcmwUo7VR98qTC7Ju9X6gzB5DVeCK29TxD5cCiHSVnCslEHKjUrYPrLmovOpE3XBvqIPBXihKo+M73uuzpB3XQypyO6vQZXJTPofp86LD2OULPXtk1fUJqXEk9rQw+2hTKoU= ; Message-ID: <20060830152905.242.qmail@web32902.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32902.mail.mud.yahoo.com via HTTP; Wed, 30 Aug 2006 08:29:05 PDT Date: Wed, 30 Aug 2006 08:29:05 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] Handling grammar definition errors To: "Carter, Jerry" , 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: 932cba6e0228cc603da43d861a7e09d8 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 now tracked via issues 101, 102, and 103 at http://www.softarmor.com/roundup/speechsc/. -- Dan Burnett --- "Carter, Jerry" wrote: > It is worthwhile to review the reporting and > handling of invalid grammars. > Consider a recognize containing two invalid URIs and > referencing two invalid > grammars. The message and responses might look > something like this: > > > > C->S:MRCP/2.0 RECOGNIZE 543260 > > Channel-Identifier:32AECB23433801@speechrecog > > Content-Type:text/uri-list > > Content-Length:??? > > > > session:http://www.example.com/bad_uri_404.gxml > > session:http://www.example.com/bad_uri_408.gxml > > session:http://www.example.com/bad_grammar1.gxml > > session:http://www.example.com/bad_grammar2.gxml > > > > S->C:MRCP/2.0 543260 407 IN-PROGRESS > > Channel-Identifier:32AECB23433801@speechrecog > > Completion-Cause:009 uri resolution problem > > Failed-URI-Cause:404 > > > Failed-URI:http://www.example.com/bad_uri_404.gxml > > > > S->C:MRCP/2.0 543260 407 IN-PROGRESS > > Channel-Identifier:32AECB23433801@speechrecog > > Completion-Cause:009 uri resolution problem > > Failed-URI-Cause:408 > > > Failed-URI:http://www.example.com/bad_uri_408.gxml > > > > S->C:MRCP/2.0 543260 407 COMPLETE > > Channel-Identifier:32AECB23433801@speechrecog > > Completion-Cause:005 grammar violates schema > > > Failed-URI:http://www.example.com/bad_grammar1.gxml > > > Failed-URI:http://www.example.com/bad_grammar2.gxml > > > > (1) Is there any benefit to having separate > 'Failed-URI-Cause' and > 'Failed-URI' messages? These should be combined. > Then, the messages for > the first two errors could also be merged. > > > > S->C:MRCP/2.0 543260 407 IN-PROGRESS > > Channel-Identifier:32AECB23433801@speechrecog > > Completion-Cause:009 uri resolution problem > > > Failed-URI:http://www.example.com/bad_uri_404.gxml > 404 > > > Failed-URI:http://www.example.com/bad_uri_408.gxml > 408 > > > > (2) The specification does not dictate today whether > a client must process > all the grammars before RECOGNIZE / DEFINE-GRAMMAR > are complete. The MRCP > specification should say this: RECOGNIZE MAY > terminate after the first error > but DEFINE-GRAMMAR SHOULD attempt to process the > entire list of grammars. > > > > (3) What is the difference between 004 > (grammar-load-failure) and 005 > (grammar-compilation-failure)? Would a client ever > care? If the answer is > no, then 004 should be retained and 005 eliminated > since load is required > and compilation is an implementation detail. > > > > (4) More failure examples in the specification would > be helpful. > > > > > > > > > _______________________________________________ > 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 Aug 31 06:10:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIjV1-0004wv-5j; Thu, 31 Aug 2006 06:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIjUz-0004wq-Td for speechsc@ietf.org; Thu, 31 Aug 2006 06:10:13 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIjUx-00060q-Sw for speechsc@ietf.org; Thu, 31 Aug 2006 06:10:13 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4U00MXIY2OKM@szxga02-in.huawei.com> for speechsc@ietf.org; Thu, 31 Aug 2006 18:20:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4U00364Y2NK7@szxga02-in.huawei.com> for speechsc@ietf.org; Thu, 31 Aug 2006 18:20:48 +0800 (CST) Received: from srilakshmi ([10.18.5.95]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4U0088GXT341@szxml04-in.huawei.com> for speechsc@ietf.org; Thu, 31 Aug 2006 18:15:07 +0800 (CST) Date: Thu, 31 Aug 2006 15:32:45 +0530 From: Srilakshmi Subject: FW: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification To: speechsc@ietf.org Message-id: <000301c6cce4$9b667230$5f05120a@srilakshmi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_igO0PxHGia1ApZCRTtGOqw)" Thread-index: AcbGgYP2Xye78yL/T6+rjXoLIbt8DwGYiRJA X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 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. --Boundary_(ID_igO0PxHGia1ApZCRTtGOqw) Content-type: multipart/alternative; boundary="Boundary_(ID_r+Ij5x8BmVoDbc/NyRC6Tw)" --Boundary_(ID_r+Ij5x8BmVoDbc/NyRC6Tw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Please provide some clarification whether Abort-Verification is a mandatory header/optional header in STOP method of SI-SV. There are two contradicting statements in the draft. Regards, Srilakshmi K. _____ From: Srilakshmi [mailto:ksrilakshmi@huawei.com] Sent: Wednesday, August 23, 2006 12:28 PM To: speechsc@ietf.org; 'Dave Burke' Subject: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification Hi, In section 11 of draft10 The following two statements are contradicting each other. 11.4.20. Abort-Verification This header MUST be sent in a "STOP" request to indicate whether or not to abort a VERIFY method in progress. 11.13. STOP The "STOP" method can carry a "Abort-Verification" header which specifies if the verification result until that point should be discarded or returned. If this header is not present or if the value is "true", the verification result is discarded and the "STOP" response does not contain any result data. If the header is present and its value is "false", the "STOP" response SHOULD contain a "Completion-Cause" header and carry the Verification result data in its body. Please provide some clarification regarding this issue. Regards, Srilakshmi K. --Boundary_(ID_r+Ij5x8BmVoDbc/NyRC6Tw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Please provide some clarification whether Abort-Verification is a mandatory header/optional header in STOP method of SI-SV.

There are two contradicting statements in the draft.

 

Regards,

Srilakshmi K.

 

From: Srilakshmi [mailto:ksrilakshmi@huawei.com]
Sent: Wednesday, August 23, 2006 12:28 PM
To: speechsc@ietf.org; 'Dave Burke'
Subject: [Speechsc] Clarification regarding Abort-Verification header in Speaker verification and Identification

 

 

Hi,

 

In section 11 of draft10

 

The following two statements are contradicting each other.

 

11.4.20.  Abort-Verification

 

   This header MUST be sent in a "STOP" request to indicate whether or

   not to abort a VERIFY method in progress. 

 

11.13.  STOP

   The "STOP" method can carry a "Abort-Verification" header which

   specifies if the verification result until that point should be

   discarded or returned.  If this header is not present or if the value

   is "true", the verification result is discarded and the "STOP"

   response does not contain any result data.  If the header is present

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

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

   its body.

 

Please provide some clarification regarding this issue.

 

Regards,

Srilakshmi K.

--Boundary_(ID_r+Ij5x8BmVoDbc/NyRC6Tw)-- --Boundary_(ID_igO0PxHGia1ApZCRTtGOqw) Content-type: text/plain; name=ATT00064.pl Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00064.pl _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --Boundary_(ID_igO0PxHGia1ApZCRTtGOqw) 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 --Boundary_(ID_igO0PxHGia1ApZCRTtGOqw)-- From speechsc-bounces@ietf.org Thu Aug 31 13:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIptw-0002jt-1v; Thu, 31 Aug 2006 13:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIptu-0002it-VM for speechsc@ietf.org; Thu, 31 Aug 2006 13:00:22 -0400 Received: from web32908.mail.mud.yahoo.com ([209.191.69.108]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIptt-0001W1-L6 for speechsc@ietf.org; Thu, 31 Aug 2006 13:00:22 -0400 Received: (qmail 88647 invoked by uid 60001); 31 Aug 2006 17:00:21 -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=Ud4THreyR2HXw/TkPufSQ+R/S+F0Lk5T81ABYyS77S3lyekRu/yVxjiL+5pROK7gndKrHnjLUvqJr7hE0ru1w8WoW2EVSEAPeHM/tE0qNtmDpPdRs/Swrlj2am4ljFc28kiKNPEZQo40jNnfPnkMAERcW547Uqk3ed0aqDVFwgQ= ; Message-ID: <20060831170021.88645.qmail@web32908.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32908.mail.mud.yahoo.com via HTTP; Thu, 31 Aug 2006 10:00:21 PDT Date: Thu, 31 Aug 2006 10:00:21 -0700 (PDT) From: Dan Burnett Subject: RE: [speechsc] Example in 4.2 does not follow offer/answer rules To: "Shanmugham, Saravanan" , Andrew Wahbe , "IETF SPEECHSC \(E-mail\)" In-Reply-To: <03772D1EC8DE624A863058C75874A75CF000D7@vtg-um-e2k6.sj21ad.cisco.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: 92df29fa99cf13e554b84c8374345c17 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 Corrected in specification draft -11. -- Dan --- "Shanmugham, Saravanan" wrote: > That was the intent. This is bug and will be fixed. > I just checked section 14.1 where there is a full > example, and there the > recognizer is added at the end conforming to the > offer/answer model. > > Sarvi > > -----Original Message----- > From: Andrew Wahbe > [mailto:awahbe@voicegenie.com] > Sent: Thursday, May 11, 2006 11:27 AM > To: IETF SPEECHSC (E-mail) > Subject: [speechsc] Example in 4.2 does not > follow > offer/answer rules > > The multi-step example in Section 4.2 that > shows a > synthesis-only session established that is then > "upgraded" > to include a recognizer doesn't seem to follow > the > offer/answer rules defined in RFC 3264. > > From Section 8.1 in RFC 3264: > > New media streams are created by new > additional media > descriptions > below the existing ones, or by reusing the > "slot" used by an old > media stream which had been disabled by > setting its > port to zero. > Reusing its slot means that the new media > description > replaces the > old one, but retains its positioning > relative to other media > descriptions in the SDP. New media > descriptions MUST > appear below > any existing media sections. > > The example adds the new control m-line for the > recognizer > between the two existing m-lines. I believe > that it should > be added at the bottom. > > Andrew > > > _______________________________________________ > 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 Aug 31 17:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GItjo-0000g6-SP; Thu, 31 Aug 2006 17:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GItjC-00007x-6g for speechsc@ietf.org; Thu, 31 Aug 2006 17:05:34 -0400 Received: from web32905.mail.mud.yahoo.com ([209.191.69.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GItcA-0003az-6m for speechsc@ietf.org; Thu, 31 Aug 2006 16:58:20 -0400 Received: (qmail 33319 invoked by uid 60001); 31 Aug 2006 20:58:17 -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=RJ9eIZHJYd0o2JdsoGjnwaNgtuoBZrnDyaE8KS8yU3QTnZWSgbnKblPcIRbE3gRs/B26oNgBZtQ2YMZwM7Yi0HIoNYcpxc+L1SUWgE6/8E2Dl8YWwwgDWygDlRQi/msJSuuwvd+vKGxcw/Pnai0HDDMvK+xDdMSylcEzFeVFhaU= ; Message-ID: <20060831205817.33317.qmail@web32905.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32905.mail.mud.yahoo.com via HTTP; Thu, 31 Aug 2006 13:58:17 PDT Date: Thu, 31 Aug 2006 13:58:17 -0700 (PDT) From: Dan Burnett Subject: RE: [speechsc] Record resource STOP issues To: "Shanmugham, Saravanan" , Dave Burke , speechsc@ietf.org In-Reply-To: <03772D1EC8DE624A863058C75874A75CF0024F@vtg-um-e2k6.sj21ad.cisco.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: fb6060cb60c0cea16e3f7219e40a0a81 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 In draft -11 I have now corrected the typo, added the Active-Request-Id-List header to the STOP response (along with appropriate text in the description of the STOP method), and removed the Completion-Cause header from the STOP response in the STOP example. -- dan --- "Shanmugham, Saravanan" wrote: > comments inline. > > I also noticed another typo in 10.4.7 Record URI - > I currently reads > "This URI is then returned in the "STOP" response of > the RECORD-COMPLETE > events." > It should read, > "This URI is then returned in the "STOP" response or > the RECORD-COMPLETE > events." > Sarvi > > > ________________________________ > > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Saturday, May 13, 2006 10:03 AM > To: speechsc@ietf.org > Subject: [speechsc] Record resource STOP issues > > > Two issues related to the recorder resource: > > 1. The Active-Request-Id-List is not specified in > the STOP > response making this inconsistent with the other > resources. This should > be added. > [Sarvi>>] This is a bug. It should contain an > Active-Request-Id-List header with the request id of > the RECORD method. > > 2. In the STOP example, it shows a Completion-Cause > in the > response. Is this header allowed here? In its > defence, the recorder > resource differs from other resources in that it is > not really an abort > - more of an early finish. Also, the value of "000 > success" is not > defined (in fact there is no "00x stopped" cause). > [Sarvi>>] This is a bug too. The STOP message > should not contain > the Completion-Cause header. If it was stopped, not > sure a > Completion-Cause would make sense. becuase the > client knows that it > stopped the recording. > > 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 Thu Aug 31 17:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIu3E-0008PO-6q; Thu, 31 Aug 2006 17:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIu3C-0008PJ-Ov for speechsc@ietf.org; Thu, 31 Aug 2006 17:26:14 -0400 Received: from web32905.mail.mud.yahoo.com ([209.191.69.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIu3B-0007Bt-Ct for speechsc@ietf.org; Thu, 31 Aug 2006 17:26:14 -0400 Received: (qmail 49867 invoked by uid 60001); 31 Aug 2006 21:26:13 -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=s+HEuEoOzgq/8ds4xHzxUuYd34zPMa5ImRPQfHkxOh+WaU+dcf8Njmcq6XS2GHbNBQP6zJDQYuRXMi0dlR1AwSF87TkAEm5MvIzj8fEBPqcOMmiHlaEZBVhm+gRt5du+oQtPUouu6tn5wRYDZh5eP9E0nj4Ovr1zyqKy6byWeZ8= ; Message-ID: <20060831212613.49864.qmail@web32905.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32905.mail.mud.yahoo.com via HTTP; Thu, 31 Aug 2006 14:26:13 PDT Date: Thu, 31 Aug 2006 14:26:13 -0700 (PDT) From: Dan Burnett Subject: Re: [speechsc] Record-URI mechanism To: Dave Burke , speechsc@ietf.org In-Reply-To: <068f01c67752$d0cedf80$6700000a@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: 10ba05e7e8a9aa6adb025f426bef3a30 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 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