From speechsc-bounces@ietf.org Tue Oct 04 11:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMok1-0001xx-9T; Tue, 04 Oct 2005 11:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMojz-0001xI-Kf for speechsc@megatron.ietf.org; Tue, 04 Oct 2005 11:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02370 for ; Tue, 4 Oct 2005 11:30:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMosg-0006ED-EH for speechsc@ietf.org; Tue, 04 Oct 2005 11:39:03 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2005 08:29:53 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="663355752:sNHT24027606" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j94FTp4u005418 for ; Tue, 4 Oct 2005 08:29:51 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j94FfB0J013989 for ; Tue, 4 Oct 2005 08:41:12 -0700 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <800D6B9F-0712-4B92-B2C2-BEBF3FAD1B7B@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "speechsc@ietf.org ((((E-mail))))" From: David R Oran Date: Tue, 4 Oct 2005 11:29:49 -0400 X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=691; t=1128440472; x=1128872672; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Speechsc=20at=20IETF=2064=20in=20Vancouver, =20November=206-11| From:David=20R=20Oran=20| Date:Tue,=204=20Oct=202005=2011=3A29=3A49=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=K87CXobBxheyV3WO77RszASXuiNYyb/L3Nzd3pgeKxrb/xNg++us1MS0woRunfp+pO0CRNkn X9T7RDXsd+0XubEKz6i4T3U6rtQcP+XAJkldjyXajBP125wXzs03QqG6OcOluM023vXCtTsfK0B nOvyKsVQaXYWkmjdgomjG9iA= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Speechsc at IETF 64 in Vancouver, November 6-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: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Folks, We WILL have a Speechsc meeting at the November IETF. Eric and I had hoped that the MRCPv2 spec would be in or through last call by now, but we have some niggling issues and workload that have held the authors up. In order to make a final push to close down the issues, we thought it prudent to have the high-bandwidth face-to-face interaction that an IETF meeting affords. Our expectation is that we can use this opportunity to finalize the spec, damp out any creeping featurism, and get the spec to the IESG for review and approval. We also hope to use some time at the meeting to initiate a discussion of "what next" for the WG. If you have specific agenda items you'd like to see addressed at the meeting, please send them to Eric and me. Thanks, and looking forward to seeing many of you in Vancouver. Best regards, Dave. (co-chair). _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 12 10:15:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhNx-00029h-9U; Wed, 12 Oct 2005 10:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhNv-00029c-Q8 for speechsc@megatron.ietf.org; Wed, 12 Oct 2005 10:15:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23142 for ; Wed, 12 Oct 2005 10:15:09 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPhYE-0003NO-5R for speechsc@ietf.org; Wed, 12 Oct 2005 10:25:52 -0400 Received: from ATLANTIS.Brooktrout.com (oceans12.brooktrout.com [204.176.75.122]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9CECGYR014450 for ; Wed, 12 Oct 2005 10:12:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2005 10:11:51 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647014DA533@ATLANTIS.Brooktrout.com> Thread-Topic: Proposed Agenda Thread-Index: AcXPNuRfUnPZnslhQriKQ6XINJ57eA== From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [Speechsc] Proposed Agenda X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Date & Time Subject to Change: THURSDAY, November 10, 2005 1510-1610 Afternoon Session II TSV speechsc Speech Services Control WG 1510 Agenda Bashing 1515 Discuss Open Issues 1610 Close Reading list: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-07.txt (Expect -08 shortly) Any discussion on the agenda? _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Oct 17 16:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERc1W-0006TH-TW; Mon, 17 Oct 2005 16:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERc1T-0006R3-9h for speechsc@megatron.ietf.org; Mon, 17 Oct 2005 16:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01807 for ; Mon, 17 Oct 2005 16:55:46 -0400 (EDT) Received: from [204.176.205.6] (helo=salvelinus.brooktrout.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERcCn-0002GB-2x for speechsc@ietf.org; Mon, 17 Oct 2005 17:07:41 -0400 Received: from ATLANTIS.Brooktrout.com (oceans12.brooktrout.com [204.176.75.122]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9HKpblp010480; Mon, 17 Oct 2005 16:51:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Mon, 17 Oct 2005 16:51:37 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470158B811@ATLANTIS.Brooktrout.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXBF7LZUgDMECDISG+EWsriadeA8ADQ3H0wA7eFaSA= From: "Eric Burger" To: "Shanmugham, Saravanan" , "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org My logic, which may be flawed, is that we want to be able to achieve these objectives. o Ensure the trivial ability to negotiate other result formats, such as EMMA. o Ensure the server knows what format the client wants. o Ensure the client knows the server supports the format the client wants, before it is "too late". I would offer that using SET-PARAMS is "too late", in that the client and server has already spent the effort to establish the RTP sessions. It would be a pity to then tear it all down when the client finds out the server does not support the format of choice. One can negotiating the format at session establishment time with SDP (a=3Dresultformat:application/emma-xml) or with SIP (Allow/Accept). I would offer that it is easier to implement, and makes MRCPv2 (SIP) proxies easier if we do the negotiation at the SIP level. For example, if a client wants results in EMMA, a MRCPv2 proxy can route the request to a server that supports EMMA by inspecting the SIP headers, rather than having to dive in to the SDP. While the preceding paragraph indicates my preference for using the SIP negotiation mechanism, there still is the case where both the client and server support NLSML and EMMA. ++++ THE QUESTION ++++ Is there a realistic use case where the client, in any given session, would want to use multiple result formats? That is, something like, "RECOGNIZE this and give me the result in EMMA" and then later issue something like, "RECOGNIZE that and give me the result in NLSML"? If so, then we would *also* need a per-recognition / SET-PARAMS header for the result type. -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:36 PM To: Brett Gavagni; Jerry Carter Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo Subject: RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotation markuplanguagesupport? Would something like the HTTP "Accept" header address these and other similar concerns. The RECOGNIZE request can then carry this header in it to specify an alternative to NLSML. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Saturday, September 24, 2005 7:51 AM To: Jerry Carter Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo Subject: Re: [Speechsc] EMMA: Extensible=20 MultiModalAnnotation markuplanguagesupport? =20 Hi, =20 I agree that the ability for a client to request the=20 format of the recognizer result data content would be useful. =20 I would prefer to see this function defined in a=20 consistent manner with the current draft specification; by=20 a client request to enable a session parameter via a=20 header (ie. "Result-Data-Type") in a SET-PARAMS or=20 RECOGNIZE request, rather than an attribute used for=20 RECOGNIZER session negotiation/update. The server should=20 then respond with an accept or reject response as it does=20 today for other client requested parameter values.=20 Currently, the draft specification doesn't expose the MRCP=20 resource configurable parameters in the SDP. =20 I don't think that enabling platform-specific formats=20 facilitates the adoption of a standard specification for=20 speech resources. I believe that the specification should=20 continue to address the required supported formats and=20 require new draft iterations including the updated=20 specifications. The updated draft iterations would=20 continue to assist with potential client/server=20 interoperability issues. =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 Jerry Carter Sent by: speechsc-bounces@ietf.org 09/23/2005 11:42 PM =20 To Baggia Paolo cc "IETF SPEECHSC=20 \(E-mail\)" Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation=20 markuplanguagesupport? =20 =20 =20 =20 =20 =20 I agree that minor changes made today will prevent the need for an=20 amended document in the very near future. Providing for content=20 negotiation solves both the EMMA issue and allows for future or=20 platform-specific return formats without requiring that the=20 specification be iterated. =20 Of the two suggestions, I prefer the SDP extension as the=20 return format=20 is analogous to other SIP media type negotiations. =20 =20 On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > the last answers and discussions in this thread seems to confirm > that the direction of MRCPv2 is to allow the use of EMMA when > it will become a W3C Recommendation. Some text should be added > in the future release to say that. > This is fine from us point of view, but a mechanism for asking > a different result format is not present in the current draft. > > We think to add that mechanism will allow a smooth transition > from the current situation: always result in=20 "application/nlsml+xml", > to a future one with results in EMMA. > > Would it be possible to consider this "negotiation" of the output > result in the next draft? > > There are different options to implement it: > a) to extend SDP to leave taht outside of MRCPv2 core protocol > E.g. > a=3DrecogResultFormat:application/nlsml+xml > if present it sets the recognition result for a whole MRCP > session. > > b) to add a new recognizer header to set the result format > for that specific recognition turn. > > What do you think? > > We are aware the draft is near to be closed, but we think this > will help the passage from NLSML to EMMA. > > Regards, > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Oct 17 19:35:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReVS-0003eC-3O; Mon, 17 Oct 2005 19:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EReVQ-0003do-WB for speechsc@megatron.ietf.org; Mon, 17 Oct 2005 19:35:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15921 for ; Mon, 17 Oct 2005 19:34:52 -0400 (EDT) Received: from mail02.corp.tellme.com ([209.157.157.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERegq-0008QP-D7 for Speechsc@ietf.org; Mon, 17 Oct 2005 19:46:49 -0400 Received: from mail02.corp.tellme.com (localhost [127.0.0.1]) by localhost.corp.tellme.com (Postfix) with ESMTP id A9E1A350E for ; Mon, 17 Oct 2005 16:34:41 -0700 (PDT) Received: from [209.157.157.204] (dhcp157-204.corp.tellme.com [209.157.157.204]) by mail02.corp.tellme.com (Postfix) with ESMTP id 8350B3507 for ; Mon, 17 Oct 2005 16:34:41 -0700 (PDT) Message-ID: <43543511.5080407@tellme.com> Date: Mon, 17 Oct 2005 16:34:41 -0700 From: Corby Anderson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Speechsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Speechsc] N-Best-List-Length results and NLSML X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I have a question about how multiple results for a recognition are returned. The N-Best-List-Length in section 9.4.4 specifies that the recognition resource will sent multiple matches (if available). My question is how this is represented in NLSML. The recognition system that I'm familiar with is Nuance's; where a recognition response may return multiple results, and each result may have multiple interpretations. Is there a similar (but differently-named) hierarchy in NLSML? Or are NLSML results simply a 1-d array of elements with no distinction between what Nuance calls a "result" and an "interpretation?" Thanks Corby Anderson Tellme Networks, Inc. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Oct 18 20:57:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2Gp-000259-IX; Tue, 18 Oct 2005 20:57:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES2Gm-00024z-FC for speechsc@megatron.ietf.org; Tue, 18 Oct 2005 20:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10603 for ; Tue, 18 Oct 2005 20:57:19 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES2SO-0001Ue-QZ for speechsc@ietf.org; Tue, 18 Oct 2005 21:09:30 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2005 17:57:17 -0700 X-IronPort-AV: i="3.97,229,1125903600"; d="scan'208"; a="221414797:sNHT27984546" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9J0vFUw007218; Tue, 18 Oct 2005 17:57:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Tue, 18 Oct 2005 17:57:13 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C676FCF@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXBF7LZUgDMECDISG+EWsriadeA8ADQ3H0wA7eFaSAAQ4S2IA== From: "Shanmugham, Saravanan" To: "Eric Burger" , "Brett Gavagni" X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I suggest that we do both.=20 The SIP Alow/Accept header during MRCP session setup for server discovery and routing. We then add support for the Accept header in MRCPv2 messages. I suspect this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. And can be used in the case where the client or the server can do both. What do you think. Sarvi=20 -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Monday, October 17, 2005 1:52 PM To: Shanmugham, Saravanan; Brett Gavagni Cc: IETF SPEECHSC (E-mail) Subject: Question on negotiating EMMA (was RE: [Speechsc]=20 EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 My logic, which may be flawed, is that we want to be able=20 to achieve these objectives. o Ensure the trivial ability to negotiate other result formats, such as EMMA. o Ensure the server knows what format the client wants. o Ensure the client knows the server supports the format the client wants, before it is "too late". =20 I would offer that using SET-PARAMS is "too late", in that=20 the client and server has already spent the effort to=20 establish the RTP sessions. It would be a pity to then tear it all down when the=20 client finds out the server does not support the format of choice. =20 One can negotiating the format at session establishment=20 time with SDP (a=3Dresultformat:application/emma-xml) or with SIP=20 (Allow/Accept). I would offer that it is easier to=20 implement, and makes MRCPv2 (SIP) proxies easier if we do=20 the negotiation at the SIP level. For example, if a=20 client wants results in EMMA, a MRCPv2 proxy can route the=20 request to a server that supports EMMA by inspecting the=20 SIP headers, rather than having to dive in to the SDP. =20 While the preceding paragraph indicates my preference for=20 using the SIP negotiation mechanism, there still is the=20 case where both the client and server support NLSML and EMMA. =20 ++++ THE QUESTION ++++ Is there a realistic use case where the client, in any=20 given session, would want to use multiple result formats? =20 That is, something like, "RECOGNIZE this and give me the=20 result in EMMA" and then later issue something like,=20 "RECOGNIZE that and give me the result in NLSML"? =20 If so, then we would *also* need a per-recognition /=20 SET-PARAMS header for the result type. =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:36 PM To: Brett Gavagni; Jerry Carter Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo Subject: RE: [Speechsc] EMMA:=20 ExtensibleMultiModalAnnotation markuplanguagesupport? =20 Would something like the HTTP "Accept" header address=20 these and other similar concerns. The RECOGNIZE request can then carry this header in it to=20 specify an alternative to NLSML. =20 Sarvi=20 =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Saturday, September 24, 2005 7:51 AM To: Jerry Carter Cc: IETF SPEECHSC (E-mail);=20 speechsc-bounces@ietf.org; Baggia Paolo Subject: Re: [Speechsc] EMMA: Extensible=20 MultiModalAnnotation markuplanguagesupport? =20 Hi, =20 I agree that the ability for a client to request the=20 format of the recognizer result data content would be useful. =20 I would prefer to see this function defined in a=20 consistent manner with the current draft specification; by=20 a client request to enable a session parameter via a=20 header (ie. "Result-Data-Type") in a SET-PARAMS or=20 RECOGNIZE request, rather than an attribute used for=20 RECOGNIZER session negotiation/update. The server should=20 then respond with an accept or reject response as it does=20 today for other client requested parameter values.=20 Currently, the draft specification doesn't expose the MRCP=20 resource configurable parameters in the SDP. =20 I don't think that enabling platform-specific formats=20 facilitates the adoption of a standard specification for=20 speech resources. I believe that the specification should=20 continue to address the required supported formats and=20 require new draft iterations including the updated=20 specifications. The updated draft iterations would=20 continue to assist with potential client/server=20 interoperability issues. =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 Jerry Carter Sent by: speechsc-bounces@ietf.org 09/23/2005 11:42 PM =20 To Baggia Paolo cc "IETF SPEECHSC=20 \(E-mail\)" Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation=20 markuplanguagesupport? =20 =20 =20 =20 =20 =20 I agree that minor changes made today will prevent=20 the need for an=20 amended document in the very near future. Providing=20 for content=20 negotiation solves both the EMMA issue and allows for=20 future or=20 platform-specific return formats without requiring that the=20 specification be iterated. =20 Of the two suggestions, I prefer the SDP extension as the=20 return format=20 is analogous to other SIP media type negotiations. =20 =20 On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > the last answers and discussions in this thread=20 seems to confirm > that the direction of MRCPv2 is to allow the use of=20 EMMA when > it will become a W3C Recommendation. Some text=20 should be added > in the future release to say that. > This is fine from us point of view, but a mechanism=20 for asking > a different result format is not present in the=20 current draft. > > We think to add that mechanism will allow a smooth=20 transition > from the current situation: always result in=20 "application/nlsml+xml", > to a future one with results in EMMA. > > Would it be possible to consider this "negotiation"=20 of the output > result in the next draft? > > There are different options to implement it: > a) to extend SDP to leave taht outside of MRCPv2=20 core protocol > E.g. > a=3DrecogResultFormat:application/nlsml+xml > if present it sets the recognition result for a whole MRCP > session. > > b) to add a new recognizer header to set the result format > for that specific recognition turn. > > What do you think? > > We are aware the draft is near to be closed, but we=20 think this > will help the passage from NLSML to EMMA. > > Regards, > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Tue Oct 18 22:50:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES422-00009O-0q; Tue, 18 Oct 2005 22:50:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES41y-00007P-Me for speechsc@megatron.ietf.org; Tue, 18 Oct 2005 22:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14991 for ; Tue, 18 Oct 2005 22:50:10 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES4Dc-0003nr-Nu for speechsc@ietf.org; Tue, 18 Oct 2005 23:02:21 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9J2mmox008488; Tue, 18 Oct 2005 22:48:48 -0400 (EDT) Content-class: urn:content-classes:message Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) MIME-Version: 1.0 Date: Tue, 18 Oct 2005 22:48:48 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664762103E@ATLANTIS.Brooktrout.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXBF7LZUgDMECDISG+EWsriadeA8ADQ3H0wA7eFaSAAQ4S2IAAEFPVu From: "Eric Burger" To: "Shanmugham, Saravanan" , "Brett Gavagni" X-Spam-Score: 0.8 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1078012126==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1078012126== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D457.A1474C20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D457.A1474C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fine with me, so long as server can reject and client can handle = situation where I ask for only NLSML in SIP negotiation and then I ask = for EMMA and the server doesn't handle it. -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Tue Oct 18 20:57:20 2005 To: Eric Burger; Brett Gavagni Cc: IETF SPEECHSC (E-mail) Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: = ExtensibleMultiModalAnnotationmarkuplanguagesupport?) I suggest that we do both.=20 The SIP Alow/Accept header during MRCP session setup for server discovery and routing. We then add support for the Accept header in MRCPv2 messages. I suspect this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. And can be used in the case where the client or the server can do both. What do you think. Sarvi=20 -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com]=20 Sent: Monday, October 17, 2005 1:52 PM To: Shanmugham, Saravanan; Brett Gavagni Cc: IETF SPEECHSC (E-mail) Subject: Question on negotiating EMMA (was RE: [Speechsc]=20 EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 My logic, which may be flawed, is that we want to be able=20 to achieve these objectives. o Ensure the trivial ability to negotiate other result formats, such as EMMA. o Ensure the server knows what format the client wants. o Ensure the client knows the server supports the format the client wants, before it is "too late". =20 I would offer that using SET-PARAMS is "too late", in that=20 the client and server has already spent the effort to=20 establish the RTP sessions. It would be a pity to then tear it all down when the=20 client finds out the server does not support the format of choice. =20 One can negotiating the format at session establishment=20 time with SDP (a=3Dresultformat:application/emma-xml) or with SIP=20 (Allow/Accept). I would offer that it is easier to=20 implement, and makes MRCPv2 (SIP) proxies easier if we do=20 the negotiation at the SIP level. For example, if a=20 client wants results in EMMA, a MRCPv2 proxy can route the=20 request to a server that supports EMMA by inspecting the=20 SIP headers, rather than having to dive in to the SDP. =20 While the preceding paragraph indicates my preference for=20 using the SIP negotiation mechanism, there still is the=20 case where both the client and server support NLSML and EMMA. =20 ++++ THE QUESTION ++++ Is there a realistic use case where the client, in any=20 given session, would want to use multiple result formats? =20 That is, something like, "RECOGNIZE this and give me the=20 result in EMMA" and then later issue something like,=20 "RECOGNIZE that and give me the result in NLSML"? =20 If so, then we would *also* need a per-recognition /=20 SET-PARAMS header for the result type. =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:36 PM To: Brett Gavagni; Jerry Carter Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo Subject: RE: [Speechsc] EMMA:=20 ExtensibleMultiModalAnnotation markuplanguagesupport? =20 Would something like the HTTP "Accept" header address=20 these and other similar concerns. The RECOGNIZE request can then carry this header in it to=20 specify an alternative to NLSML. =20 Sarvi=20 =20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Saturday, September 24, 2005 7:51 AM To: Jerry Carter Cc: IETF SPEECHSC (E-mail);=20 speechsc-bounces@ietf.org; Baggia Paolo Subject: Re: [Speechsc] EMMA: Extensible=20 MultiModalAnnotation markuplanguagesupport? =20 Hi, =20 I agree that the ability for a client to request the=20 format of the recognizer result data content would be useful. =20 I would prefer to see this function defined in a=20 consistent manner with the current draft specification; by=20 a client request to enable a session parameter via a=20 header (ie. "Result-Data-Type") in a SET-PARAMS or=20 RECOGNIZE request, rather than an attribute used for=20 RECOGNIZER session negotiation/update. The server should=20 then respond with an accept or reject response as it does=20 today for other client requested parameter values.=20 Currently, the draft specification doesn't expose the MRCP=20 resource configurable parameters in the SDP. =20 I don't think that enabling platform-specific formats=20 facilitates the adoption of a standard specification for=20 speech resources. I believe that the specification should=20 continue to address the required supported formats and=20 require new draft iterations including the updated=20 specifications. The updated draft iterations would=20 continue to assist with potential client/server=20 interoperability issues. =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 =20 =20 Jerry Carter Sent by: speechsc-bounces@ietf.org 09/23/2005 11:42 PM =20 To Baggia Paolo cc "IETF SPEECHSC=20 \(E-mail\)" Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation=20 markuplanguagesupport? =20 =20 =20 =20 =20 =20 I agree that minor changes made today will prevent=20 the need for an=20 amended document in the very near future. Providing=20 for content=20 negotiation solves both the EMMA issue and allows for=20 future or=20 platform-specific return formats without requiring that the=20 specification be iterated. =20 Of the two suggestions, I prefer the SDP extension as the=20 return format=20 is analogous to other SIP media type negotiations. =20 =20 On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > the last answers and discussions in this thread=20 seems to confirm > that the direction of MRCPv2 is to allow the use of=20 EMMA when > it will become a W3C Recommendation. Some text=20 should be added > in the future release to say that. > This is fine from us point of view, but a mechanism=20 for asking > a different result format is not present in the=20 current draft. > > We think to add that mechanism will allow a smooth=20 transition > from the current situation: always result in=20 "application/nlsml+xml", > to a future one with results in EMMA. > > Would it be possible to consider this "negotiation"=20 of the output > result in the next draft? > > There are different options to implement it: > a) to extend SDP to leave taht outside of MRCPv2=20 core protocol > E.g. > a=3DrecogResultFormat:application/nlsml+xml > if present it sets the recognition result for a whole MRCP > session. > > b) to add a new recognizer header to set the result format > for that specific recognition turn. > > What do you think? > > We are aware the draft is near to be closed, but we=20 think this > will help the passage from NLSML to EMMA. > > Regards, > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 ------_=_NextPart_001_01C5D457.A1474C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: = ExtensibleMultiModalAnnotationmarkuplanguagesupport?)

Fine with me, so long as server can reject and client = can handle situation where I ask for only NLSML in SIP negotiation and = then I ask for EMMA and the server doesn't handle it.

 -----Original Message-----
From:   Shanmugham, Saravanan [mailto:sarvi@cisco.com]
Sent:   Tue Oct 18 20:57:20 2005
To:     Eric Burger; Brett Gavagni
Cc:     IETF SPEECHSC (E-mail)
Subject:        RE: Question on = negotiating EMMA (was RE: [Speechsc] EMMA: = ExtensibleMultiModalAnnotationmarkuplanguagesupport?)

I suggest that we do both.
The SIP Alow/Accept header during MRCP session setup for server
discovery and routing.
We then add support for the Accept header in MRCPv2 messages. I = suspect
this will be initially only used for = RECOGNIZE/SET-PARAMS/GET-PARAMS.
And can be used in the case where the client or the server can do = both.

What do you think.

Sarvi

     -----Original Message-----
     From: Eric Burger [mailto:eburger@brooktrout.com]=
     Sent: Monday, October 17, 2005 1:52 PM
     To: Shanmugham, Saravanan; Brett Gavagni
     Cc: IETF SPEECHSC (E-mail)
     Subject: Question on negotiating EMMA (was RE: = [Speechsc]
     EMMA: = ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
    
     My logic, which may be flawed, is that we want = to be able
     to achieve these objectives.
       o  Ensure the trivial ability = to negotiate other result
          formats, such as = EMMA.
       o  Ensure the server knows = what format the client wants.
       o  Ensure the client knows the = server supports the format
          the client wants, = before it is "too late".
    
     I would offer that using SET-PARAMS is = "too late", in that
     the client and server has already spent the = effort to
     establish the RTP sessions.
     It would be a pity to then tear it all down = when the
     client finds out the server does not support = the format of choice.
    
     One can negotiating the format at session = establishment
     time with SDP
     (a=3Dresultformat:application/emma-xml) or with = SIP
     (Allow/Accept).  I would offer that it is = easier to
     implement, and makes MRCPv2 (SIP) proxies = easier if we do
     the negotiation at the SIP level.  For = example, if a
     client wants results in EMMA, a MRCPv2 proxy = can route the
     request to a server that supports EMMA by = inspecting the
     SIP headers, rather than having to dive in to = the SDP.
    
     While the preceding paragraph indicates my = preference for
     using the SIP negotiation mechanism, there = still is the
     case where both the client and server support = NLSML and EMMA.
    
     ++++ THE QUESTION ++++
     Is there a realistic use case where the client, = in any
     given session, would want to use multiple = result formats? 
     That is, something like, "RECOGNIZE this = and give me the
     result in EMMA" and then later issue = something like,
     "RECOGNIZE that and give me the result in = NLSML"?
    
     If so, then we would *also* need a = per-recognition /
     SET-PARAMS header for the result type.
    
     -----Original Message-----
     From: speechsc-bounces@ietf.org
     [mailto:speechsc-bounces@ietf.or= g] On Behalf Of
     Shanmugham, Saravanan
     Sent: Wednesday, September 28, 2005 2:36 PM
     To: Brett Gavagni; Jerry Carter
     Cc: IETF SPEECHSC (E-mail); = speechsc-bounces@ietf.org; Baggia Paolo
     Subject: RE: [Speechsc] EMMA:
     ExtensibleMultiModalAnnotation = markuplanguagesupport?
    
     Would something like the HTTP = "Accept" header address
     these and other similar concerns.
     The RECOGNIZE request can then carry this = header in it to
     specify an alternative to NLSML.
    
     Sarvi
    
          -----Original = Message-----
          From: = speechsc-bounces@ietf.org
          [mailto:speechsc-bounces@ietf.or= g] On Behalf Of Brett Gavagni
          Sent: Saturday, = September 24, 2005 7:51 AM
          To: Jerry = Carter
          Cc: IETF SPEECHSC = (E-mail);
     speechsc-bounces@ietf.org; Baggia Paolo
          Subject: Re: = [Speechsc] EMMA: Extensible
          = MultiModalAnnotation markuplanguagesupport?
         
          Hi,
         
          I agree that the = ability for a client to request the
          format of the = recognizer result data content would be useful.
         
          I would prefer to = see this function defined in a
          consistent manner = with the current draft specification; by
          a client request = to enable a session parameter via a
          header (ie. = "Result-Data-Type") in a SET-PARAMS or
          RECOGNIZE = request, rather than an attribute used for
          RECOGNIZER = session negotiation/update. The server should
          then respond with = an accept or reject response as it does
          today for other = client requested parameter values.
          Currently, the = draft specification doesn't expose the MRCP
          resource = configurable parameters in the SDP.
         
          I don't think = that enabling platform-specific formats
          facilitates the = adoption of a standard specification for
          speech resources. = I  believe that the specification should
          continue to = address the required supported formats and
          require new draft = iterations including the updated
          specifications. = The updated draft iterations would
          continue to = assist with potential client/server
          interoperability = issues.
         
          Thanks,
         
          Brett Gavagni
          WebSphere Voice = Server Development
          http://w= ww-306.ibm.com/software/pervasive/voice_server/
          = gavagni@us.ibm.com
         
         
         
         
          Jerry Carter = <jerry@jerrycarter.org>
          Sent by: = speechsc-bounces@ietf.org
          09/23/2005 11:42 = PM
         
          To
          Baggia Paolo = <Paolo.Baggia@LOQUENDO.COM> cc "IETF SPEECHSC
          \(E-mail\)" = <speechsc@ietf.org> Subject
          Re: [Speechsc] = EMMA: Extensible MultiModal Annotation
          = markuplanguagesupport?
         
         
         
         
         
         
          I agree that = minor changes made today will prevent
     the need for an
          amended document = in the very near future.  Providing
     for content
          negotiation = solves both the EMMA issue and allows for
     future or
          platform-specific = return formats without requiring that the
          specification be = iterated.
         
          Of the two = suggestions, I prefer the SDP extension as the
          return format
          is analogous to = other SIP media type negotiations.
         
         
          On Sep 23, 2005, = at 4:55 AM, Baggia Paolo wrote:
          > the last = answers and discussions in this thread
     seems to confirm
          > that the = direction of MRCPv2 is to allow the use of
     EMMA when
          > it will = become a W3C Recommendation. Some text
     should be added
          > in the = future release to say that.
          > This is fine = from us point of view, but a mechanism
     for asking
          > a different = result format is not present in the
     current draft.
          >
          > We think to = add that mechanism will allow a smooth
     transition
          > from the = current situation: always result in
          = "application/nlsml+xml",
          > to a future = one with results in EMMA.
          >
          > Would it be = possible to consider this "negotiation"
     of the output
          > result in = the next draft?
          >
          > There are = different options to implement it:
          > a) to extend = SDP to leave taht outside of MRCPv2
     core protocol
          > E.g.
          > = a=3DrecogResultFormat:application/nlsml+xml
          > if present = it sets the recognition result for a whole MRCP
          > session.
          >
          > b) to add a = new recognizer header to set the result format
          = >    for that specific recognition turn.
          >
          > What do you = think?
          >
          > We are aware = the draft is near to be closed, but we
     think this
          > will help = the passage from NLSML to EMMA.
          >
          > Regards,
          > Paolo = Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo)
         
         
          = _______________________________________________
          Speechsc mailing = list
          = Speechsc@ietf.org
          https://www1.iet= f.org/mailman/listinfo/speechsc
         
         
         
          = _______________________________________________
          Speechsc mailing = list
          = Speechsc@ietf.org
          https://www1.iet= f.org/mailman/listinfo/speechsc
         
    
     = _______________________________________________
     Speechsc mailing list
     Speechsc@ietf.org
     https://www1.iet= f.org/mailman/listinfo/speechsc
    

------_=_NextPart_001_01C5D457.A1474C20-- --===============1078012126== 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 --===============1078012126==-- From speechsc-bounces@ietf.org Wed Oct 19 06:31:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBDo-00005k-FH; Wed, 19 Oct 2005 06:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBDm-00005R-Az for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 06:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05682 for ; Wed, 19 Oct 2005 06:30:47 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESBPQ-0006kd-IJ for speechsc@ietf.org; Wed, 19 Oct 2005 06:43:03 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j9JAUg1R030617 for ; Wed, 19 Oct 2005 06:30:42 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9JAUgb5527872 for ; Wed, 19 Oct 2005 04:30:42 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j9JAUf0D013179 for ; Wed, 19 Oct 2005 04:30:41 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j9JAUf5p013173; Wed, 19 Oct 2005 04:30:41 -0600 In-Reply-To: <330A23D8336C0346B5C1A5BB1966664762103E@ATLANTIS.Brooktrout.com> To: "Eric Burger" MIME-Version: 1.0 Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 19 Oct 2005 06:31:53 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 10/19/2005 04:31:54, Serialize complete at 10/19/2005 04:31:54 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I not too thrilled with the implication of leaking more MRCP Application parameters into SDP, which could be possibly considered outside the scope of resource session establishment,. This could potentially end up complicating interoperability scenarios. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Eric Burger" 10/18/2005 10:48 PM To "Shanmugham, Saravanan" , Brett Gavagni/West Palm Beach/IBM@IBMUS cc "IETF SPEECHSC \(E-mail\)" Subject RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Fine with me, so long as server can reject and client can handle situation where I ask for only NLSML in SIP negotiation and then I ask for EMMA and the server doesn't handle it. -----Original Message----- From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Tue Oct 18 20:57:20 2005 To: Eric Burger; Brett Gavagni Cc: IETF SPEECHSC (E-mail) Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) I suggest that we do both. The SIP Alow/Accept header during MRCP session setup for server discovery and routing. We then add support for the Accept header in MRCPv2 messages. I suspect this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. And can be used in the case where the client or the server can do both. What do you think. Sarvi -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com] Sent: Monday, October 17, 2005 1:52 PM To: Shanmugham, Saravanan; Brett Gavagni Cc: IETF SPEECHSC (E-mail) Subject: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) My logic, which may be flawed, is that we want to be able to achieve these objectives. o Ensure the trivial ability to negotiate other result formats, such as EMMA. o Ensure the server knows what format the client wants. o Ensure the client knows the server supports the format the client wants, before it is "too late". I would offer that using SET-PARAMS is "too late", in that the client and server has already spent the effort to establish the RTP sessions. It would be a pity to then tear it all down when the client finds out the server does not support the format of choice. One can negotiating the format at session establishment time with SDP (a=resultformat:application/emma-xml) or with SIP (Allow/Accept). I would offer that it is easier to implement, and makes MRCPv2 (SIP) proxies easier if we do the negotiation at the SIP level. For example, if a client wants results in EMMA, a MRCPv2 proxy can route the request to a server that supports EMMA by inspecting the SIP headers, rather than having to dive in to the SDP. While the preceding paragraph indicates my preference for using the SIP negotiation mechanism, there still is the case where both the client and server support NLSML and EMMA. ++++ THE QUESTION ++++ Is there a realistic use case where the client, in any given session, would want to use multiple result formats? That is, something like, "RECOGNIZE this and give me the result in EMMA" and then later issue something like, "RECOGNIZE that and give me the result in NLSML"? If so, then we would *also* need a per-recognition / SET-PARAMS header for the result type. -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:36 PM To: Brett Gavagni; Jerry Carter Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo Subject: RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotation markuplanguagesupport? Would something like the HTTP "Accept" header address these and other similar concerns. The RECOGNIZE request can then carry this header in it to specify an alternative to NLSML. Sarvi -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Saturday, September 24, 2005 7:51 AM To: Jerry Carter Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo Subject: Re: [Speechsc] EMMA: Extensible MultiModalAnnotation markuplanguagesupport? Hi, I agree that the ability for a client to request the format of the recognizer result data content would be useful. I would prefer to see this function defined in a consistent manner with the current draft specification; by a client request to enable a session parameter via a header (ie. "Result-Data-Type") in a SET-PARAMS or RECOGNIZE request, rather than an attribute used for RECOGNIZER session negotiation/update. The server should then respond with an accept or reject response as it does today for other client requested parameter values. Currently, the draft specification doesn't expose the MRCP resource configurable parameters in the SDP. I don't think that enabling platform-specific formats facilitates the adoption of a standard specification for speech resources. I believe that the specification should continue to address the required supported formats and require new draft iterations including the updated specifications. The updated draft iterations would continue to assist with potential client/server interoperability issues. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com Jerry Carter Sent by: speechsc-bounces@ietf.org 09/23/2005 11:42 PM To Baggia Paolo cc "IETF SPEECHSC \(E-mail\)" Subject Re: [Speechsc] EMMA: Extensible MultiModal Annotation markuplanguagesupport? I agree that minor changes made today will prevent the need for an amended document in the very near future. Providing for content negotiation solves both the EMMA issue and allows for future or platform-specific return formats without requiring that the specification be iterated. Of the two suggestions, I prefer the SDP extension as the return format is analogous to other SIP media type negotiations. On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > the last answers and discussions in this thread seems to confirm > that the direction of MRCPv2 is to allow the use of EMMA when > it will become a W3C Recommendation. Some text should be added > in the future release to say that. > This is fine from us point of view, but a mechanism for asking > a different result format is not present in the current draft. > > We think to add that mechanism will allow a smooth transition > from the current situation: always result in "application/nlsml+xml", > to a future one with results in EMMA. > > Would it be possible to consider this "negotiation" of the output > result in the next draft? > > There are different options to implement it: > a) to extend SDP to leave taht outside of MRCPv2 core protocol > E.g. > a=recogResultFormat:application/nlsml+xml > if present it sets the recognition result for a whole MRCP > session. > > b) to add a new recognizer header to set the result format > for that specific recognition turn. > > What do you think? > > We are aware the draft is near to be closed, but we think this > will help the passage from NLSML to EMMA. > > Regards, > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 07:54:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCWd-0001V2-BK; Wed, 19 Oct 2005 07:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESCWZ-0001Pg-ET for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 07:54:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09400 for ; Wed, 19 Oct 2005 07:54:18 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESCiD-0000UI-N5 for speechsc@ietf.org; Wed, 19 Oct 2005 08:06:35 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IOL00C8DVQ7R0@dns2.cselt.it> for speechsc@ietf.org; Wed, 19 Oct 2005 13:54:07 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 13:51:48 +0200 Date: Wed, 19 Oct 2005 13:54:06 +0200 From: Baggia Paolo Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) To: Eric Burger , "Shanmugham, Saravanan" , Brett Gavagni Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Importance: normal Priority: normal Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) thread-index: AcXBF7LZUgDMECDISG+EWsriadeA8ADQ3H0wA7eFaSAAQ4S2IAAEFPVuABLc00A= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 19 Oct 2005 11:51:48.0562 (UTC) FILETIME=[7CA12320:01C5D4A3] X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: "IETF SPEECHSC \(E-mail\)" , Baggia Paolo 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="===============2077276362==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============2077276362== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C5D4A3.CF166909" Content-transfer-encoding: 7bit Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D4A3.CF166909 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric, =20 I'd like to answer first to the precise question you raised below. =20 The use case is real, but the matter is between NLSML and EMMA, but between a raw result and a detailed result. I can see very well an application that uses a certain level of information in all the normal ASR turns, but in some specific one the detail need to be more precise. So the client might ask to return results in a different format then the normal one. =20 Other people are working to give a more thorough answer on the whole concern. =20 Paolo -----Original Message----- From: Eric Burger [ mailto:eburger@brooktrout.com] Sent: Monday, October 17, 2005 1:52 PM To: Shanmugham, Saravanan; Brett Gavagni Cc: IETF SPEECHSC (E-mail) Subject: Question on negotiating EMMA (was RE: [Speechsc] EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 ++++ THE QUESTION ++++ Is there a realistic use case where the client, in any given session, would want to use multiple result formats?=20 That is, something like, "RECOGNIZE this and give me the result in EMMA" and then later issue something like, "RECOGNIZE that and give me the result in NLSML"? =20 If so, then we would *also* need a per-recognition / SET-PARAMS header for the result type. =20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C5D4A3.CF166909 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: = ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
Eric,
 
I'd=20 like to answer first to the precise question you=20 raised
below.
 
The=20 use case is real, but the matter is between NLSML
and=20 EMMA, but between a raw result and a detailed = result.
I can=20 see very well an application that uses a certain = level
of=20 information in all the normal ASR turns, but in some
specific one the detail need to be more = precise. So=20 the
client=20 might ask to return results in a different format
then=20 the normal one.
 
Other=20 people are working to give a more thorough answer
on the=20 whole concern.
 
Paolo
     -----Original=20 Message-----
     From: Eric Burger [mailto:eburger@brooktrout.com]=
    =20 Sent: Monday, October 17, 2005 1:52 PM
     To:=20 Shanmugham, Saravanan; Brett Gavagni
     Cc: = IETF=20 SPEECHSC (E-mail)
     Subject: Question on = negotiating=20 EMMA (was RE: [Speechsc]
     EMMA:=20 ExtensibleMultiModalAnnotationmarkuplanguagesupport?)
  &nbs= p;     
    =20 ++++ THE QUESTION ++++
     Is there a realistic = use case=20 where the client, in any
     given session, = would want=20 to use multiple result formats? 
     That = is,=20 something like, "RECOGNIZE this and give me = the
    =20 result in EMMA" and then later issue something = like,
    =20 "RECOGNIZE that and give me the result in=20 NLSML"?
    
     If so, = then we=20 would *also* need a per-recognition /
     = SET-PARAMS=20 header for the result=20 type.
    

Gruppo = Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= CONFIDENTIALITY NOTICE
This message and its attachments are addressed = solely to the persons
above and may contain confidential information. = If you have received
the message in error, be informed that any use = of the content hereof
is prohibited. Please return it immediately to = the sender and delete
the message. Should you have any questions, = please send an e_mail to
MailAdmin@tilab.com. Thank = you
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C5D4A3.CF166909-- --===============2077276362== 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 --===============2077276362==-- From speechsc-bounces@ietf.org Wed Oct 19 08:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDP6-00035F-Ow; Wed, 19 Oct 2005 08:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDP2-00034N-Ds for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 08:50:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13795 for ; Wed, 19 Oct 2005 08:50:34 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDal-0002Lk-30 for speechsc@ietf.org; Wed, 19 Oct 2005 09:02:52 -0400 Received: from daburkewxp (unknown [10.0.0.202]) by mail.voxpilot.com (Postfix) with ESMTP id BC989214041; Wed, 19 Oct 2005 12:50:28 +0000 (GMT) Message-ID: <01ec01c5d4ab$abbfff70$ca00000a@db01.voxpilot.com> From: "Dave Burke" To: "Eric Burger" , "Brett Gavagni" References: Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 13:50:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I have to side with Brett here. The reality is that there are plenty of things that the client may find out about the server "too late". Here are the ones that will undoubtedly happen in practice: - a given language not supported - a given semantic interpretation format within the SRGS s not supported - speech enrollment not supported In practice, a client will know the vendor of the speech resource servers identified by a SIP URI and will know what to expect; network administrators will know not to load balance / failover a hetergeonous vendor set. It seems much cleaner to use Accept on the RECOGNIZE request so the server knows the format(s) to use for the RECOGNITION-COMPLETE final response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. Dave ----- Original Message ----- From: "Brett Gavagni" To: "Eric Burger" Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, Saravanan" Sent: Wednesday, October 19, 2005 11:31 AM Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >I not too thrilled with the implication of leaking more MRCP Application > parameters into SDP, which could be possibly considered outside the scope > of resource session establishment,. This could potentially end up > complicating interoperability scenarios. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Eric Burger" > 10/18/2005 10:48 PM > > To > "Shanmugham, Saravanan" , Brett Gavagni/West Palm > Beach/IBM@IBMUS > cc > "IETF SPEECHSC \(E-mail\)" > Subject > RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > > > > > Fine with me, so long as server can reject and client can handle situation > where I ask for only NLSML in SIP negotiation and then I ask for EMMA and > the server doesn't handle it. > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Tue Oct 18 20:57:20 2005 > To: Eric Burger; Brett Gavagni > Cc: IETF SPEECHSC (E-mail) > Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > I suggest that we do both. > The SIP Alow/Accept header during MRCP session setup for server > discovery and routing. > We then add support for the Accept header in MRCPv2 messages. I suspect > this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. > And can be used in the case where the client or the server can do both. > > What do you think. > > Sarvi > > -----Original Message----- > From: Eric Burger [mailto:eburger@brooktrout.com] > Sent: Monday, October 17, 2005 1:52 PM > To: Shanmugham, Saravanan; Brett Gavagni > Cc: IETF SPEECHSC (E-mail) > Subject: Question on negotiating EMMA (was RE: [Speechsc] > EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > My logic, which may be flawed, is that we want to be able > to achieve these objectives. > o Ensure the trivial ability to negotiate other result > formats, such as EMMA. > o Ensure the server knows what format the client wants. > o Ensure the client knows the server supports the format > the client wants, before it is "too late". > > I would offer that using SET-PARAMS is "too late", in that > the client and server has already spent the effort to > establish the RTP sessions. > It would be a pity to then tear it all down when the > client finds out the server does not support the format of choice. > > One can negotiating the format at session establishment > time with SDP > (a=resultformat:application/emma-xml) or with SIP > (Allow/Accept). I would offer that it is easier to > implement, and makes MRCPv2 (SIP) proxies easier if we do > the negotiation at the SIP level. For example, if a > client wants results in EMMA, a MRCPv2 proxy can route the > request to a server that supports EMMA by inspecting the > SIP headers, rather than having to dive in to the SDP. > > While the preceding paragraph indicates my preference for > using the SIP negotiation mechanism, there still is the > case where both the client and server support NLSML and EMMA. > > ++++ THE QUESTION ++++ > Is there a realistic use case where the client, in any > given session, would want to use multiple result formats? > That is, something like, "RECOGNIZE this and give me the > result in EMMA" and then later issue something like, > "RECOGNIZE that and give me the result in NLSML"? > > If so, then we would *also* need a per-recognition / > SET-PARAMS header for the result type. > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Shanmugham, Saravanan > Sent: Wednesday, September 28, 2005 2:36 PM > To: Brett Gavagni; Jerry Carter > Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo > Subject: RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotation markuplanguagesupport? > > Would something like the HTTP "Accept" header address > these and other similar concerns. > The RECOGNIZE request can then carry this header in it to > specify an alternative to NLSML. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni > Sent: Saturday, September 24, 2005 7:51 AM > To: Jerry Carter > Cc: IETF SPEECHSC (E-mail); > speechsc-bounces@ietf.org; Baggia Paolo > Subject: Re: [Speechsc] EMMA: Extensible > MultiModalAnnotation markuplanguagesupport? > > Hi, > > I agree that the ability for a client to request the > format of the recognizer result data content would be useful. > > I would prefer to see this function defined in a > consistent manner with the current draft specification; by > a client request to enable a session parameter via a > header (ie. "Result-Data-Type") in a SET-PARAMS or > RECOGNIZE request, rather than an attribute used for > RECOGNIZER session negotiation/update. The server should > then respond with an accept or reject response as it does > today for other client requested parameter values. > Currently, the draft specification doesn't expose the MRCP > resource configurable parameters in the SDP. > > I don't think that enabling platform-specific formats > facilitates the adoption of a standard specification for > speech resources. I believe that the specification should > continue to address the required supported formats and > require new draft iterations including the updated > specifications. The updated draft iterations would > continue to assist with potential client/server > interoperability issues. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > Jerry Carter > Sent by: speechsc-bounces@ietf.org > 09/23/2005 11:42 PM > > To > Baggia Paolo cc "IETF SPEECHSC > \(E-mail\)" Subject > Re: [Speechsc] EMMA: Extensible MultiModal Annotation > markuplanguagesupport? > > > > > > > I agree that minor changes made today will prevent > the need for an > amended document in the very near future. Providing > for content > negotiation solves both the EMMA issue and allows for > future or > platform-specific return formats without requiring that the > specification be iterated. > > Of the two suggestions, I prefer the SDP extension as the > return format > is analogous to other SIP media type negotiations. > > > On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > > the last answers and discussions in this thread > seems to confirm > > that the direction of MRCPv2 is to allow the use of > EMMA when > > it will become a W3C Recommendation. Some text > should be added > > in the future release to say that. > > This is fine from us point of view, but a mechanism > for asking > > a different result format is not present in the > current draft. > > > > We think to add that mechanism will allow a smooth > transition > > from the current situation: always result in > "application/nlsml+xml", > > to a future one with results in EMMA. > > > > Would it be possible to consider this "negotiation" > of the output > > result in the next draft? > > > > There are different options to implement it: > > a) to extend SDP to leave taht outside of MRCPv2 > core protocol > > E.g. > > a=recogResultFormat:application/nlsml+xml > > if present it sets the recognition result for a whole MRCP > > session. > > > > b) to add a new recognizer header to set the result format > > for that specific recognition turn. > > > > What do you think? > > > > We are aware the draft is near to be closed, but we > think this > > will help the passage from NLSML to EMMA. > > > > Regards, > > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 09:12:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDkU-00058l-Ov; Wed, 19 Oct 2005 09:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDkR-00058d-Ax for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 09:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15612 for ; Wed, 19 Oct 2005 09:12:41 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDwB-00033V-17 for speechsc@ietf.org; Wed, 19 Oct 2005 09:24:59 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IOL00H07ZD0D2@dns2.cselt.it> for speechsc@ietf.org; Wed, 19 Oct 2005 15:12:36 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 15:10:17 +0200 Date: Wed, 19 Oct 2005 15:12:36 +0200 From: Baggia Paolo Subject: RE: Question on negotiating EMMA (was RE: [Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) To: Dave Burke , Eric Burger , Brett Gavagni Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) thread-index: AcXUq9sVyd5D11B3SHysrHyM2doZkAAAoNtw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 19 Oct 2005 13:10:17.0921 (UTC) FILETIME=[73A04B10:01C5D4AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" , Baggia Paolo X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org I hope do not say a stupid thing, but the problem was to negotiate a format for the whole session without having to ask it each single RECOGNIZE (or INTERPRET). Whilst the use case I was circulating was about the case when you need to change result format in the middle of a session for a specific RECOGNIZE or INTERPRET (for adding information to the results if possible). Paolo. -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org]On Behalf Of Dave Burke Sent: Wednesday, October 19, 2005 2:50 PM To: Eric Burger; Brett Gavagni Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan Subject: Re: Question on negotiating EMMA (was RE: [Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) I have to side with Brett here. The reality is that there are plenty of things that the client may find = out=20 about the server "too late". Here are the ones that will undoubtedly = happen=20 in practice: - a given language not supported - a given semantic interpretation format within the SRGS s not=20 supported - speech enrollment not supported In practice, a client will know the vendor of the speech resource = servers=20 identified by a SIP URI and will know what to expect; network = administrators=20 will know not to load balance / failover a hetergeonous vendor set. It seems much cleaner to use Accept on the RECOGNIZE request so the = server=20 knows the format(s) to use for the RECOGNITION-COMPLETE final response.=20 SET-OPTIONs/GET-OPTIONs can be used for stickyness. Dave ----- Original Message -----=20 From: "Brett Gavagni" To: "Eric Burger" Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, = Saravanan"=20 Sent: Wednesday, October 19, 2005 11:31 AM Subject: RE: Question on negotiating EMMA (was RE: [Speechsc]=20 EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >I not too thrilled with the implication of leaking more MRCP = Application > parameters into SDP, which could be possibly considered outside the = scope > of resource session establishment,. This could potentially end up > complicating interoperability scenarios. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Eric Burger" > 10/18/2005 10:48 PM > > To > "Shanmugham, Saravanan" , Brett Gavagni/West Palm > Beach/IBM@IBMUS > cc > "IETF SPEECHSC \(E-mail\)" > Subject > RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > > > > > Fine with me, so long as server can reject and client can handle = situation > where I ask for only NLSML in SIP negotiation and then I ask for EMMA = and > the server doesn't handle it. > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Tue Oct 18 20:57:20 2005 > To: Eric Burger; Brett Gavagni > Cc: IETF SPEECHSC (E-mail) > Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] = EMMA: > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > I suggest that we do both. > The SIP Alow/Accept header during MRCP session setup for server > discovery and routing. > We then add support for the Accept header in MRCPv2 messages. I = suspect > this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. > And can be used in the case where the client or the server can do = both. > > What do you think. > > Sarvi > > -----Original Message----- > From: Eric Burger [mailto:eburger@brooktrout.com] > Sent: Monday, October 17, 2005 1:52 PM > To: Shanmugham, Saravanan; Brett Gavagni > Cc: IETF SPEECHSC (E-mail) > Subject: Question on negotiating EMMA (was RE: [Speechsc] > EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > My logic, which may be flawed, is that we want to be able > to achieve these objectives. > o Ensure the trivial ability to negotiate other result > formats, such as EMMA. > o Ensure the server knows what format the client wants. > o Ensure the client knows the server supports the format > the client wants, before it is "too late". > > I would offer that using SET-PARAMS is "too late", in that > the client and server has already spent the effort to > establish the RTP sessions. > It would be a pity to then tear it all down when the > client finds out the server does not support the format of choice. > > One can negotiating the format at session establishment > time with SDP > (a=3Dresultformat:application/emma-xml) or with SIP > (Allow/Accept). I would offer that it is easier to > implement, and makes MRCPv2 (SIP) proxies easier if we do > the negotiation at the SIP level. For example, if a > client wants results in EMMA, a MRCPv2 proxy can route the > request to a server that supports EMMA by inspecting the > SIP headers, rather than having to dive in to the SDP. > > While the preceding paragraph indicates my preference for > using the SIP negotiation mechanism, there still is the > case where both the client and server support NLSML and EMMA. > > ++++ THE QUESTION ++++ > Is there a realistic use case where the client, in any > given session, would want to use multiple result formats? > That is, something like, "RECOGNIZE this and give me the > result in EMMA" and then later issue something like, > "RECOGNIZE that and give me the result in NLSML"? > > If so, then we would *also* need a per-recognition / > SET-PARAMS header for the result type. > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Shanmugham, Saravanan > Sent: Wednesday, September 28, 2005 2:36 PM > To: Brett Gavagni; Jerry Carter > Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia = Paolo > Subject: RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotation markuplanguagesupport? > > Would something like the HTTP "Accept" header address > these and other similar concerns. > The RECOGNIZE request can then carry this header in it to > specify an alternative to NLSML. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni > Sent: Saturday, September 24, 2005 7:51 AM > To: Jerry Carter > Cc: IETF SPEECHSC (E-mail); > speechsc-bounces@ietf.org; Baggia Paolo > Subject: Re: [Speechsc] EMMA: Extensible > MultiModalAnnotation markuplanguagesupport? > > Hi, > > I agree that the ability for a client to request the > format of the recognizer result data content would be useful. > > I would prefer to see this function defined in a > consistent manner with the current draft specification; by > a client request to enable a session parameter via a > header (ie. "Result-Data-Type") in a SET-PARAMS or > RECOGNIZE request, rather than an attribute used for > RECOGNIZER session negotiation/update. The server should > then respond with an accept or reject response as it does > today for other client requested parameter values. > Currently, the draft specification doesn't expose the MRCP > resource configurable parameters in the SDP. > > I don't think that enabling platform-specific formats > facilitates the adoption of a standard specification for > speech resources. I believe that the specification should > continue to address the required supported formats and > require new draft iterations including the updated > specifications. The updated draft iterations would > continue to assist with potential client/server > interoperability issues. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > Jerry Carter > Sent by: speechsc-bounces@ietf.org > 09/23/2005 11:42 PM > > To > Baggia Paolo cc "IETF SPEECHSC > \(E-mail\)" Subject > Re: [Speechsc] EMMA: Extensible MultiModal Annotation > markuplanguagesupport? > > > > > > > I agree that minor changes made today will prevent > the need for an > amended document in the very near future. Providing > for content > negotiation solves both the EMMA issue and allows for > future or > platform-specific return formats without requiring that the > specification be iterated. > > Of the two suggestions, I prefer the SDP extension as the > return format > is analogous to other SIP media type negotiations. > > > On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > > the last answers and discussions in this thread > seems to confirm > > that the direction of MRCPv2 is to allow the use of > EMMA when > > it will become a W3C Recommendation. Some text > should be added > > in the future release to say that. > > This is fine from us point of view, but a mechanism > for asking > > a different result format is not present in the > current draft. > > > > We think to add that mechanism will allow a smooth > transition > > from the current situation: always result in > "application/nlsml+xml", > > to a future one with results in EMMA. > > > > Would it be possible to consider this "negotiation" > of the output > > result in the next draft? > > > > There are different options to implement it: > > a) to extend SDP to leave taht outside of MRCPv2 > core protocol > > E.g. > > a=3DrecogResultFormat:application/nlsml+xml > > if present it sets the recognition result for a whole MRCP > > session. > > > > b) to add a new recognizer header to set the result format > > for that specific recognition turn. > > > > What do you think? > > > > We are aware the draft is near to be closed, but we > think this > > will help the passage from NLSML to EMMA. > > > > Regards, > > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo = (Loquendo) > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 09:39:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEAO-000164-Tv; Wed, 19 Oct 2005 09:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEAL-00014G-CJ for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 09:39:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18040 for ; Wed, 19 Oct 2005 09:39:27 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESEM2-0003xN-2B for speechsc@ietf.org; Wed, 19 Oct 2005 09:51:42 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IOM00I1F0LOLU@dns2.cselt.it> for speechsc@ietf.org; Wed, 19 Oct 2005 15:39:24 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 15:37:05 +0200 Date: Wed, 19 Oct 2005 15:38:59 +0200 From: Bergallo Patrizio Subject: RE: Question on negotiating EMMA (was RE:[Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) To: "IETF SPEECHSC (E-mail)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Question on negotiating EMMA (was RE:[Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) thread-index: AcXUq9sVyd5D11B3SHysrHyM2doZkAAAoNtwAACtdLA= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 19 Oct 2005 13:37:05.0296 (UTC) FILETIME=[31B24100:01C5D4B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Content-Transfer-Encoding: quoted-printable X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Regarding the "command level" approach, I think that, on Paolo's use case basis, it useful to use Accept header also on GET-RESULT and INTERPRET methods.=20 Moreover, if this header will be allowed also in GET-PARAM and SET-PARAM methods, maybe it should have a less generic name, say something like accept-recog-result-format (or something more concise...). About the "session setup level" approach, I kindly ask your opinion about two concerns: 1) using SIP Accept header seems to be more "proxy oriented". But this kind of philosophy should be adopted also for more important "routing" information, like resource type, that now are contained only in the SDP stuff 2) looking at the SIP Accept definition (from HTTP), it seems that in the SIP context it is used to specify the response format of the INVITE command, (default sdp, if omitted), so it is quite strange for me to "multiplex" the recog result format too. Patrizio Bergallo, Loquendo. > -----Original Message----- > From: speechsc-bounces@ietf.org=20 > [mailto:speechsc-bounces@ietf.org] On Behalf Of Baggia Paolo > Sent: Wednesday, October 19, 2005 3:13 PM > To: Dave Burke; Eric Burger; Brett Gavagni > Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan; Baggia Paolo > Subject: RE: Question on negotiating EMMA (was=20 > RE:[Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguage > support?) >=20 >=20 > I hope do not say a stupid thing, but the problem > was to negotiate a format for the whole session > without having to ask it each single RECOGNIZE > (or INTERPRET). >=20 > Whilst the use case I was circulating was about > the case when you need to change result format > in the middle of a session for a specific RECOGNIZE > or INTERPRET (for adding information to the results > if possible). >=20 > Paolo. >=20 > -----Original Message----- > From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org]On > Behalf Of Dave Burke > Sent: Wednesday, October 19, 2005 2:50 PM > To: Eric Burger; Brett Gavagni > Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan > Subject: Re: Question on negotiating EMMA (was RE: > [Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >=20 >=20 > I have to side with Brett here. >=20 > The reality is that there are plenty of things that the=20 > client may find out=20 > about the server "too late". Here are the ones that will=20 > undoubtedly happen=20 > in practice: > - a given language not supported > - a given semantic interpretation format within the SRGS=20 > s not=20 > supported > - speech enrollment not supported >=20 > In practice, a client will know the vendor of the speech=20 > resource servers=20 > identified by a SIP URI and will know what to expect; network=20 > administrators=20 > will know not to load balance / failover a hetergeonous vendor set. >=20 > It seems much cleaner to use Accept on the RECOGNIZE request=20 > so the server=20 > knows the format(s) to use for the RECOGNITION-COMPLETE final=20 > response.=20 > SET-OPTIONs/GET-OPTIONs can be used for stickyness. >=20 > Dave >=20 > ----- Original Message -----=20 > From: "Brett Gavagni" > To: "Eric Burger" > Cc: "IETF SPEECHSC (E-mail)" ;=20 > "Shanmugham, Saravanan"=20 > > Sent: Wednesday, October 19, 2005 11:31 AM > Subject: RE: Question on negotiating EMMA (was RE: [Speechsc]=20 > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >=20 >=20 > >I not too thrilled with the implication of leaking more MRCP=20 > >Application parameters into SDP, which could be possibly=20 > considered=20 > >outside the scope of resource session establishment,. This could=20 > >potentially end up complicating interoperability scenarios. > > > > Thanks, > > > > Brett Gavagni > > WebSphere Voice Server Development=20 > > http://www-306.ibm.com/software/pervasive/voice_server/ > > gavagni@us.ibm.com > > > > > > > > > > "Eric Burger" > > 10/18/2005 10:48 PM > > > > To > > "Shanmugham, Saravanan" , Brett Gavagni/West Palm=20 > > Beach/IBM@IBMUS cc > > "IETF SPEECHSC \(E-mail\)" > > Subject > > RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > > > > > > > > > > > > Fine with me, so long as server can reject and client can handle=20 > > situation where I ask for only NLSML in SIP negotiation and=20 > then I ask=20 > > for EMMA and the server doesn't handle it. > > > > -----Original Message----- > > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > > Sent: Tue Oct 18 20:57:20 2005 > > To: Eric Burger; Brett Gavagni > > Cc: IETF SPEECHSC (E-mail) > > Subject: RE: Question on negotiating EMMA (was RE:=20 > [Speechsc] EMMA: > > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > > I suggest that we do both. > > The SIP Alow/Accept header during MRCP session setup for server=20 > > discovery and routing. We then add support for the Accept header in=20 > > MRCPv2 messages. I suspect this will be initially only used for=20 > > RECOGNIZE/SET-PARAMS/GET-PARAMS. And can be used in the=20 > case where the=20 > > client or the server can do both. > > > > What do you think. > > > > Sarvi > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@brooktrout.com] > > Sent: Monday, October 17, 2005 1:52 PM > > To: Shanmugham, Saravanan; Brett Gavagni > > Cc: IETF SPEECHSC (E-mail) > > Subject: Question on negotiating EMMA (was RE: [Speechsc] > > EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > > My logic, which may be flawed, is that we want to be able > > to achieve these objectives. > > o Ensure the trivial ability to negotiate other result > > formats, such as EMMA. > > o Ensure the server knows what format the client wants. > > o Ensure the client knows the server supports the format > > the client wants, before it is "too late". > > > > I would offer that using SET-PARAMS is "too late", in that > > the client and server has already spent the effort to > > establish the RTP sessions. > > It would be a pity to then tear it all down when the > > client finds out the server does not support the format=20 > of choice. > > > > One can negotiating the format at session establishment > > time with SDP > > (a=3Dresultformat:application/emma-xml) or with SIP > > (Allow/Accept). I would offer that it is easier to > > implement, and makes MRCPv2 (SIP) proxies easier if we do > > the negotiation at the SIP level. For example, if a > > client wants results in EMMA, a MRCPv2 proxy can route the > > request to a server that supports EMMA by inspecting the > > SIP headers, rather than having to dive in to the SDP. > > > > While the preceding paragraph indicates my preference for > > using the SIP negotiation mechanism, there still is the > > case where both the client and server support NLSML and EMMA. > > > > ++++ THE QUESTION ++++ > > Is there a realistic use case where the client, in any > > given session, would want to use multiple result formats? > > That is, something like, "RECOGNIZE this and give me the > > result in EMMA" and then later issue something like, > > "RECOGNIZE that and give me the result in NLSML"? > > > > If so, then we would *also* need a per-recognition / > > SET-PARAMS header for the result type. > > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of > > Shanmugham, Saravanan > > Sent: Wednesday, September 28, 2005 2:36 PM > > To: Brett Gavagni; Jerry Carter > > Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org;=20 > Baggia Paolo > > Subject: RE: [Speechsc] EMMA: > > ExtensibleMultiModalAnnotation markuplanguagesupport? > > > > Would something like the HTTP "Accept" header address > > these and other similar concerns. > > The RECOGNIZE request can then carry this header in it to > > specify an alternative to NLSML. > > > > Sarvi > > > > -----Original Message----- > > From: speechsc-bounces@ietf.org > > [mailto:speechsc-bounces@ietf.org] On Behalf Of=20 > Brett Gavagni > > Sent: Saturday, September 24, 2005 7:51 AM > > To: Jerry Carter > > Cc: IETF SPEECHSC (E-mail); > > speechsc-bounces@ietf.org; Baggia Paolo > > Subject: Re: [Speechsc] EMMA: Extensible > > MultiModalAnnotation markuplanguagesupport? > > > > Hi, > > > > I agree that the ability for a client to request the > > format of the recognizer result data content would=20 > be useful. > > > > I would prefer to see this function defined in a > > consistent manner with the current draft specification; by > > a client request to enable a session parameter via a > > header (ie. "Result-Data-Type") in a SET-PARAMS or > > RECOGNIZE request, rather than an attribute used for > > RECOGNIZER session negotiation/update. The server should > > then respond with an accept or reject response as it does > > today for other client requested parameter values. > > Currently, the draft specification doesn't expose the MRCP > > resource configurable parameters in the SDP. > > > > I don't think that enabling platform-specific formats > > facilitates the adoption of a standard specification for > > speech resources. I believe that the specification should > > continue to address the required supported formats and > > require new draft iterations including the updated > > specifications. The updated draft iterations would > > continue to assist with potential client/server > > interoperability issues. > > > > Thanks, > > > > Brett Gavagni > > WebSphere Voice Server Development > > http://www-306.ibm.com/software/pervasive/voice_server/ > > gavagni@us.ibm.com > > > > > > > > > > Jerry Carter > > Sent by: speechsc-bounces@ietf.org > > 09/23/2005 11:42 PM > > > > To > > Baggia Paolo cc "IETF SPEECHSC > > \(E-mail\)" Subject > > Re: [Speechsc] EMMA: Extensible MultiModal Annotation > > markuplanguagesupport? > > > > > > > > > > > > > > I agree that minor changes made today will prevent > > the need for an > > amended document in the very near future. Providing > > for content > > negotiation solves both the EMMA issue and allows for > > future or > > platform-specific return formats without requiring that the > > specification be iterated. > > > > Of the two suggestions, I prefer the SDP extension as the > > return format > > is analogous to other SIP media type negotiations. > > > > > > On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > > > the last answers and discussions in this thread > > seems to confirm > > > that the direction of MRCPv2 is to allow the use of > > EMMA when > > > it will become a W3C Recommendation. Some text > > should be added > > > in the future release to say that. > > > This is fine from us point of view, but a mechanism > > for asking > > > a different result format is not present in the > > current draft. > > > > > > We think to add that mechanism will allow a smooth > > transition > > > from the current situation: always result in > > "application/nlsml+xml", > > > to a future one with results in EMMA. > > > > > > Would it be possible to consider this "negotiation" > > of the output > > > result in the next draft? > > > > > > There are different options to implement it: > > > a) to extend SDP to leave taht outside of MRCPv2 > > core protocol > > > E.g. > > > a=3DrecogResultFormat:application/nlsml+xml > > > if present it sets the recognition result for a=20 > whole MRCP > > > session. > > > > > > b) to add a new recognizer header to set the=20 > result format > > > for that specific recognition turn. > > > > > > What do you think? > > > > > > We are aware the draft is near to be closed, but we > > think this > > > will help the passage from NLSML to EMMA. > > > > > > Regards, > > > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo=20 > > (Loquendo) > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org > > https://www1.ietf.org/mailman/listinfo/speechsc > > > > > > > > _______________________________________________ > > Speechsc mailing list > > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc > >=20 >=20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the=20 > persons above and may contain confidential information. If=20 > you have received the message in error, be informed that any=20 > use of the content hereof is prohibited. Please return it=20 > immediately to the sender and delete the message. Should you=20 > have any questions, please send an e_mail to=20 > MailAdmin@tilab.com. Thank you=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 10:58:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFOJ-0007Wv-Nz; Wed, 19 Oct 2005 10:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFOD-0007St-Tp for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 10:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21740 for ; Wed, 19 Oct 2005 10:57:53 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESFZv-0005z9-LD for speechsc@ietf.org; Wed, 19 Oct 2005 11:10:10 -0400 Received: from [205.150.90.65] (parrot.voicegenie.com [205.150.90.65]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j9JEvR719127; Wed, 19 Oct 2005 10:57:27 -0400 (EDT) Message-ID: <43565ED8.6050906@voicegenie.com> Date: Wed, 19 Oct 2005 10:57:28 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Burke Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) References: <01ec01c5d4ab$abbfff70$ca00000a@db01.voxpilot.com> In-Reply-To: <01ec01c5d4ab$abbfff70$ca00000a@db01.voxpilot.com> Content-Type: multipart/mixed; boundary="------------040409010601090606090902" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" , Eric Burger X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------040409010601090606090902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The question is whether you want the client to know which homogeneous set to use, or if you want a proxy to do it for you. If you want a proxy to be able to do this for you then you want it in the SDP (or perhaps a SIP header but I'd prefer SDP) wouldn't you? Also note that things like the required language(s) can change over the course of one call. You could update your SDP and ReInvite in this case (and the proxy would find an appropriate server) or (if it is client driven) you could switch over to another homogeneous set. I thought that advertising your needs and capabilities in session establishment so that you could be connected to a compatible server was a big part of the point in using SIP here. If we resort to saying that "network administrators should know how to load balance this properly", can't we also say that "network administrators should configure everything to use the same codec" etc? Having said that, I think that one could still argue that the emma vs nlsml support is a stretch for session establishment... its some of the other examples you gave that I have issue with. I hope we don't rule these out. I haven't brought this up earlier because I seem to remember someone saying that this sort of thing could be the subject of another separate RFC (SDP to describe MRCP resource capabilities). Andrew Dave Burke wrote: > I have to side with Brett here. > > The reality is that there are plenty of things that the client may > find out about the server "too late". Here are the ones that will > undoubtedly happen in practice: > - a given language not supported > - a given semantic interpretation format within the SRGS s not > supported > - speech enrollment not supported > > In practice, a client will know the vendor of the speech resource > servers identified by a SIP URI and will know what to expect; network > administrators will know not to load balance / failover a hetergeonous > vendor set. > > It seems much cleaner to use Accept on the RECOGNIZE request so the > server knows the format(s) to use for the RECOGNITION-COMPLETE final > response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. > > Dave > > ----- Original Message ----- From: "Brett Gavagni" > To: "Eric Burger" > Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, > Saravanan" > Sent: Wednesday, October 19, 2005 11:31 AM > Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > >> I not too thrilled with the implication of leaking more MRCP Application >> parameters into SDP, which could be possibly considered outside the >> scope >> of resource session establishment,. This could potentially end up >> complicating interoperability scenarios. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> "Eric Burger" >> 10/18/2005 10:48 PM >> >> To >> "Shanmugham, Saravanan" , Brett Gavagni/West Palm >> Beach/IBM@IBMUS >> cc >> "IETF SPEECHSC \(E-mail\)" >> Subject >> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: >> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >> >> >> >> >> >> >> Fine with me, so long as server can reject and client can handle >> situation >> where I ask for only NLSML in SIP negotiation and then I ask for EMMA >> and >> the server doesn't handle it. >> >> -----Original Message----- >> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >> Sent: Tue Oct 18 20:57:20 2005 >> To: Eric Burger; Brett Gavagni >> Cc: IETF SPEECHSC (E-mail) >> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >> EMMA: >> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >> >> I suggest that we do both. >> The SIP Alow/Accept header during MRCP session setup for server >> discovery and routing. >> We then add support for the Accept header in MRCPv2 messages. I suspect >> this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. >> And can be used in the case where the client or the server can do both. >> >> What do you think. >> >> Sarvi >> >> -----Original Message----- >> From: Eric Burger [mailto:eburger@brooktrout.com] >> Sent: Monday, October 17, 2005 1:52 PM >> To: Shanmugham, Saravanan; Brett Gavagni >> Cc: IETF SPEECHSC (E-mail) >> Subject: Question on negotiating EMMA (was RE: [Speechsc] >> EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >> >> My logic, which may be flawed, is that we want to be able >> to achieve these objectives. >> o Ensure the trivial ability to negotiate other result >> formats, such as EMMA. >> o Ensure the server knows what format the client wants. >> o Ensure the client knows the server supports the format >> the client wants, before it is "too late". >> >> I would offer that using SET-PARAMS is "too late", in that >> the client and server has already spent the effort to >> establish the RTP sessions. >> It would be a pity to then tear it all down when the >> client finds out the server does not support the format of choice. >> >> One can negotiating the format at session establishment >> time with SDP >> (a=resultformat:application/emma-xml) or with SIP >> (Allow/Accept). I would offer that it is easier to >> implement, and makes MRCPv2 (SIP) proxies easier if we do >> the negotiation at the SIP level. For example, if a >> client wants results in EMMA, a MRCPv2 proxy can route the >> request to a server that supports EMMA by inspecting the >> SIP headers, rather than having to dive in to the SDP. >> >> While the preceding paragraph indicates my preference for >> using the SIP negotiation mechanism, there still is the >> case where both the client and server support NLSML and EMMA. >> >> ++++ THE QUESTION ++++ >> Is there a realistic use case where the client, in any >> given session, would want to use multiple result formats? >> That is, something like, "RECOGNIZE this and give me the >> result in EMMA" and then later issue something like, >> "RECOGNIZE that and give me the result in NLSML"? >> >> If so, then we would *also* need a per-recognition / >> SET-PARAMS header for the result type. >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of >> Shanmugham, Saravanan >> Sent: Wednesday, September 28, 2005 2:36 PM >> To: Brett Gavagni; Jerry Carter >> Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo >> Subject: RE: [Speechsc] EMMA: >> ExtensibleMultiModalAnnotation markuplanguagesupport? >> >> Would something like the HTTP "Accept" header address >> these and other similar concerns. >> The RECOGNIZE request can then carry this header in it to >> specify an alternative to NLSML. >> >> Sarvi >> >> -----Original Message----- >> From: speechsc-bounces@ietf.org >> [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni >> Sent: Saturday, September 24, 2005 7:51 AM >> To: Jerry Carter >> Cc: IETF SPEECHSC (E-mail); >> speechsc-bounces@ietf.org; Baggia Paolo >> Subject: Re: [Speechsc] EMMA: Extensible >> MultiModalAnnotation markuplanguagesupport? >> >> Hi, >> >> I agree that the ability for a client to request the >> format of the recognizer result data content would be useful. >> >> I would prefer to see this function defined in a >> consistent manner with the current draft specification; by >> a client request to enable a session parameter via a >> header (ie. "Result-Data-Type") in a SET-PARAMS or >> RECOGNIZE request, rather than an attribute used for >> RECOGNIZER session negotiation/update. The server should >> then respond with an accept or reject response as it does >> today for other client requested parameter values. >> Currently, the draft specification doesn't expose the MRCP >> resource configurable parameters in the SDP. >> >> I don't think that enabling platform-specific formats >> facilitates the adoption of a standard specification for >> speech resources. I believe that the specification should >> continue to address the required supported formats and >> require new draft iterations including the updated >> specifications. The updated draft iterations would >> continue to assist with potential client/server >> interoperability issues. >> >> Thanks, >> >> Brett Gavagni >> WebSphere Voice Server Development >> http://www-306.ibm.com/software/pervasive/voice_server/ >> gavagni@us.ibm.com >> >> >> >> >> Jerry Carter >> Sent by: speechsc-bounces@ietf.org >> 09/23/2005 11:42 PM >> >> To >> Baggia Paolo cc "IETF SPEECHSC >> \(E-mail\)" Subject >> Re: [Speechsc] EMMA: Extensible MultiModal Annotation >> markuplanguagesupport? >> >> >> >> >> >> >> I agree that minor changes made today will prevent >> the need for an >> amended document in the very near future. Providing >> for content >> negotiation solves both the EMMA issue and allows for >> future or >> platform-specific return formats without requiring that the >> specification be iterated. >> >> Of the two suggestions, I prefer the SDP extension as the >> return format >> is analogous to other SIP media type negotiations. >> >> >> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: >> > the last answers and discussions in this thread >> seems to confirm >> > that the direction of MRCPv2 is to allow the use of >> EMMA when >> > it will become a W3C Recommendation. Some text >> should be added >> > in the future release to say that. >> > This is fine from us point of view, but a mechanism >> for asking >> > a different result format is not present in the >> current draft. >> > >> > We think to add that mechanism will allow a smooth >> transition >> > from the current situation: always result in >> "application/nlsml+xml", >> > to a future one with results in EMMA. >> > >> > Would it be possible to consider this "negotiation" >> of the output >> > result in the next draft? >> > >> > There are different options to implement it: >> > a) to extend SDP to leave taht outside of MRCPv2 >> core protocol >> > E.g. >> > a=recogResultFormat:application/nlsml+xml >> > if present it sets the recognition result for a whole MRCP >> > session. >> > >> > b) to add a new recognizer header to set the result format >> > for that specific recognition turn. >> > >> > What do you think? >> > >> > We are aware the draft is near to be closed, but we >> think this >> > will help the passage from NLSML to EMMA. >> > >> > Regards, >> > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > --------------040409010601090606090902 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------040409010601090606090902 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 --------------040409010601090606090902-- From speechsc-bounces@ietf.org Wed Oct 19 11:18:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFi9-0007S0-2m; Wed, 19 Oct 2005 11:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFi5-0007Re-Nh for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 11:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22626 for ; Wed, 19 Oct 2005 11:18:25 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESFtq-0006WF-Db for speechsc@ietf.org; Wed, 19 Oct 2005 11:30:43 -0400 Received: from [205.150.90.65] (parrot.voicegenie.com [205.150.90.65]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j9JFIL720087; Wed, 19 Oct 2005 11:18:21 -0400 (EDT) Message-ID: <435663BD.2000508@voicegenie.com> Date: Wed, 19 Oct 2005 11:18:21 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Wahbe Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) References: <01ec01c5d4ab$abbfff70$ca00000a@db01.voxpilot.com> <43565ED8.6050906@voicegenie.com> In-Reply-To: <43565ED8.6050906@voicegenie.com> Content-Type: multipart/mixed; boundary="------------070203040706030201040703" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" , Eric Burger , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------070203040706030201040703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On reading my own response I realized that a re-invite wouldn't work with a proxy. oops. (please hold back your comments ;-). I don't think this changes my point though. Andrew Andrew Wahbe wrote: > The question is whether you want the client to know which homogeneous > set to use, or if you want a proxy to do it for you. If you want a > proxy to be able to do this for you then you want it in the SDP (or > perhaps a SIP header but I'd prefer SDP) wouldn't you? > > Also note that things like the required language(s) can change over > the course of one call. You could update your SDP and ReInvite in this > case (and the proxy would find an appropriate server) or (if it is > client driven) you could switch over to another homogeneous set. > > I thought that advertising your needs and capabilities in session > establishment so that you could be connected to a compatible server > was a big part of the point in using SIP here. If we resort to saying > that "network administrators should know how to load balance this > properly", can't we also say that "network administrators should > configure everything to use the same codec" etc? > > Having said that, I think that one could still argue that the emma vs > nlsml support is a stretch for session establishment... its some of > the other examples you gave that I have issue with. I hope we don't > rule these out. I haven't brought this up earlier because I seem to > remember someone saying that this sort of thing could be the subject > of another separate RFC (SDP to describe MRCP resource capabilities). > > Andrew > > Dave Burke wrote: > >> I have to side with Brett here. >> >> The reality is that there are plenty of things that the client may >> find out about the server "too late". Here are the ones that will >> undoubtedly happen in practice: >> - a given language not supported >> - a given semantic interpretation format within the SRGS s >> not supported >> - speech enrollment not supported >> >> In practice, a client will know the vendor of the speech resource >> servers identified by a SIP URI and will know what to expect; network >> administrators will know not to load balance / failover a >> hetergeonous vendor set. >> >> It seems much cleaner to use Accept on the RECOGNIZE request so the >> server knows the format(s) to use for the RECOGNITION-COMPLETE final >> response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. >> >> Dave >> >> ----- Original Message ----- From: "Brett Gavagni" >> To: "Eric Burger" >> Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, >> Saravanan" >> Sent: Wednesday, October 19, 2005 11:31 AM >> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >> EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >> >> >>> I not too thrilled with the implication of leaking more MRCP >>> Application >>> parameters into SDP, which could be possibly considered outside the >>> scope >>> of resource session establishment,. This could potentially end up >>> complicating interoperability scenarios. >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> gavagni@us.ibm.com >>> >>> >>> >>> >>> "Eric Burger" >>> 10/18/2005 10:48 PM >>> >>> To >>> "Shanmugham, Saravanan" , Brett Gavagni/West Palm >>> Beach/IBM@IBMUS >>> cc >>> "IETF SPEECHSC \(E-mail\)" >>> Subject >>> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: >>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>> >>> >>> >>> >>> >>> >>> Fine with me, so long as server can reject and client can handle >>> situation >>> where I ask for only NLSML in SIP negotiation and then I ask for >>> EMMA and >>> the server doesn't handle it. >>> >>> -----Original Message----- >>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >>> Sent: Tue Oct 18 20:57:20 2005 >>> To: Eric Burger; Brett Gavagni >>> Cc: IETF SPEECHSC (E-mail) >>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >>> EMMA: >>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>> >>> I suggest that we do both. >>> The SIP Alow/Accept header during MRCP session setup for server >>> discovery and routing. >>> We then add support for the Accept header in MRCPv2 messages. I suspect >>> this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. >>> And can be used in the case where the client or the server can do both. >>> >>> What do you think. >>> >>> Sarvi >>> >>> -----Original Message----- >>> From: Eric Burger [mailto:eburger@brooktrout.com] >>> Sent: Monday, October 17, 2005 1:52 PM >>> To: Shanmugham, Saravanan; Brett Gavagni >>> Cc: IETF SPEECHSC (E-mail) >>> Subject: Question on negotiating EMMA (was RE: [Speechsc] >>> EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>> >>> My logic, which may be flawed, is that we want to be able >>> to achieve these objectives. >>> o Ensure the trivial ability to negotiate other result >>> formats, such as EMMA. >>> o Ensure the server knows what format the client wants. >>> o Ensure the client knows the server supports the format >>> the client wants, before it is "too late". >>> >>> I would offer that using SET-PARAMS is "too late", in that >>> the client and server has already spent the effort to >>> establish the RTP sessions. >>> It would be a pity to then tear it all down when the >>> client finds out the server does not support the format of choice. >>> >>> One can negotiating the format at session establishment >>> time with SDP >>> (a=resultformat:application/emma-xml) or with SIP >>> (Allow/Accept). I would offer that it is easier to >>> implement, and makes MRCPv2 (SIP) proxies easier if we do >>> the negotiation at the SIP level. For example, if a >>> client wants results in EMMA, a MRCPv2 proxy can route the >>> request to a server that supports EMMA by inspecting the >>> SIP headers, rather than having to dive in to the SDP. >>> >>> While the preceding paragraph indicates my preference for >>> using the SIP negotiation mechanism, there still is the >>> case where both the client and server support NLSML and EMMA. >>> >>> ++++ THE QUESTION ++++ >>> Is there a realistic use case where the client, in any >>> given session, would want to use multiple result formats? >>> That is, something like, "RECOGNIZE this and give me the >>> result in EMMA" and then later issue something like, >>> "RECOGNIZE that and give me the result in NLSML"? >>> >>> If so, then we would *also* need a per-recognition / >>> SET-PARAMS header for the result type. >>> >>> -----Original Message----- >>> From: speechsc-bounces@ietf.org >>> [mailto:speechsc-bounces@ietf.org] On Behalf Of >>> Shanmugham, Saravanan >>> Sent: Wednesday, September 28, 2005 2:36 PM >>> To: Brett Gavagni; Jerry Carter >>> Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo >>> Subject: RE: [Speechsc] EMMA: >>> ExtensibleMultiModalAnnotation markuplanguagesupport? >>> >>> Would something like the HTTP "Accept" header address >>> these and other similar concerns. >>> The RECOGNIZE request can then carry this header in it to >>> specify an alternative to NLSML. >>> >>> Sarvi >>> >>> -----Original Message----- >>> From: speechsc-bounces@ietf.org >>> [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni >>> Sent: Saturday, September 24, 2005 7:51 AM >>> To: Jerry Carter >>> Cc: IETF SPEECHSC (E-mail); >>> speechsc-bounces@ietf.org; Baggia Paolo >>> Subject: Re: [Speechsc] EMMA: Extensible >>> MultiModalAnnotation markuplanguagesupport? >>> >>> Hi, >>> >>> I agree that the ability for a client to request the >>> format of the recognizer result data content would be useful. >>> >>> I would prefer to see this function defined in a >>> consistent manner with the current draft specification; by >>> a client request to enable a session parameter via a >>> header (ie. "Result-Data-Type") in a SET-PARAMS or >>> RECOGNIZE request, rather than an attribute used for >>> RECOGNIZER session negotiation/update. The server should >>> then respond with an accept or reject response as it does >>> today for other client requested parameter values. >>> Currently, the draft specification doesn't expose the MRCP >>> resource configurable parameters in the SDP. >>> >>> I don't think that enabling platform-specific formats >>> facilitates the adoption of a standard specification for >>> speech resources. I believe that the specification should >>> continue to address the required supported formats and >>> require new draft iterations including the updated >>> specifications. The updated draft iterations would >>> continue to assist with potential client/server >>> interoperability issues. >>> >>> Thanks, >>> >>> Brett Gavagni >>> WebSphere Voice Server Development >>> http://www-306.ibm.com/software/pervasive/voice_server/ >>> gavagni@us.ibm.com >>> >>> >>> >>> >>> Jerry Carter >>> Sent by: speechsc-bounces@ietf.org >>> 09/23/2005 11:42 PM >>> >>> To >>> Baggia Paolo cc "IETF SPEECHSC >>> \(E-mail\)" Subject >>> Re: [Speechsc] EMMA: Extensible MultiModal Annotation >>> markuplanguagesupport? >>> >>> >>> >>> >>> >>> >>> I agree that minor changes made today will prevent >>> the need for an >>> amended document in the very near future. Providing >>> for content >>> negotiation solves both the EMMA issue and allows for >>> future or >>> platform-specific return formats without requiring that the >>> specification be iterated. >>> >>> Of the two suggestions, I prefer the SDP extension as the >>> return format >>> is analogous to other SIP media type negotiations. >>> >>> >>> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: >>> > the last answers and discussions in this thread >>> seems to confirm >>> > that the direction of MRCPv2 is to allow the use of >>> EMMA when >>> > it will become a W3C Recommendation. Some text >>> should be added >>> > in the future release to say that. >>> > This is fine from us point of view, but a mechanism >>> for asking >>> > a different result format is not present in the >>> current draft. >>> > >>> > We think to add that mechanism will allow a smooth >>> transition >>> > from the current situation: always result in >>> "application/nlsml+xml", >>> > to a future one with results in EMMA. >>> > >>> > Would it be possible to consider this "negotiation" >>> of the output >>> > result in the next draft? >>> > >>> > There are different options to implement it: >>> > a) to extend SDP to leave taht outside of MRCPv2 >>> core protocol >>> > E.g. >>> > a=recogResultFormat:application/nlsml+xml >>> > if present it sets the recognition result for a whole MRCP >>> > session. >>> > >>> > b) to add a new recognizer header to set the result format >>> > for that specific recognition turn. >>> > >>> > What do you think? >>> > >>> > We are aware the draft is near to be closed, but we >>> think this >>> > will help the passage from NLSML to EMMA. >>> > >>> > Regards, >>> > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >> >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > --------------070203040706030201040703 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------070203040706030201040703 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 --------------070203040706030201040703-- From speechsc-bounces@ietf.org Wed Oct 19 13:12:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHUX-00072p-BM; Wed, 19 Oct 2005 13:12:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHUU-000716-Lw for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 13:12:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29305 for ; Wed, 19 Oct 2005 13:12:29 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHgF-0001XD-1i for speechsc@ietf.org; Wed, 19 Oct 2005 13:24:48 -0400 Received: from daburkewxp (unknown [10.0.0.202]) by mail.voxpilot.com (Postfix) with ESMTP id 2B877214041; Wed, 19 Oct 2005 17:12:28 +0000 (GMT) Message-ID: <039c01c5d4d0$4539f740$ca00000a@db01.voxpilot.com> From: "Dave Burke" To: "Andrew Wahbe" References: <01ec01c5d4ab$abbfff70$ca00000a@db01.voxpilot.com> <43565ED8.6050906@voicegenie.com> <435663BD.2000508@voicegenie.com> Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 18:12: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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , "Shanmugham, Saravanan" , Eric Burger X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org There is certainly a general question of how an MRCP server advertises capabilities and how the client requests particular capabilities. I do, however, believe that MRCP's choice of SIP for discovery and rendevous will still prove wise. The mechanism for capability advertisement and specification might be best delegated to a separate draft at this point in MRCP's development. For now we've got DNS SRV (a given AOR can indicate a particular capability set e.g. vendorx.en.example.com). As far as mechanisms are considered, I'm still not keen on using SDP. A "pure" SIP proxy (as defined in RFC 3261) will not work by analysing SDP. Nor will registering an MRCP server capability set (since REGISTER does not contain SDP and it's Accept / Allow headers relate to the response to the REGISTER). That leaves headers: one framework that could be considered is based on RFC 3840/3841. For example, a speechrecog does a register: REGISTER sip:example.com To: asr@example.com Contact: ;language="en";reco-result-format="EMMA" An MRCP client looking for an ASR engine supporting EMMA and English places the following request to a proxy. INVITE sip:asr@example.com Accept-Contact: *;reco-result-format="EMMA";language="en" The OPTIONS method (already mentioned in MRCPv2) can also be used (it returns the Contact header with the feature parameters). Dave ----- Original Message ----- From: "Andrew Wahbe" To: "Andrew Wahbe" Cc: "Dave Burke" ; "IETF SPEECHSC (E-mail)" ; "Shanmugham, Saravanan" ; "Eric Burger" Sent: Wednesday, October 19, 2005 4:18 PM Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > On reading my own response I realized that a re-invite wouldn't work > with a proxy. oops. (please hold back your comments ;-). I don't think > this changes my point though. > > Andrew > > Andrew Wahbe wrote: > >> The question is whether you want the client to know which homogeneous >> set to use, or if you want a proxy to do it for you. If you want a >> proxy to be able to do this for you then you want it in the SDP (or >> perhaps a SIP header but I'd prefer SDP) wouldn't you? >> >> Also note that things like the required language(s) can change over >> the course of one call. You could update your SDP and ReInvite in this >> case (and the proxy would find an appropriate server) or (if it is >> client driven) you could switch over to another homogeneous set. >> >> I thought that advertising your needs and capabilities in session >> establishment so that you could be connected to a compatible server >> was a big part of the point in using SIP here. If we resort to saying >> that "network administrators should know how to load balance this >> properly", can't we also say that "network administrators should >> configure everything to use the same codec" etc? >> >> Having said that, I think that one could still argue that the emma vs >> nlsml support is a stretch for session establishment... its some of >> the other examples you gave that I have issue with. I hope we don't >> rule these out. I haven't brought this up earlier because I seem to >> remember someone saying that this sort of thing could be the subject >> of another separate RFC (SDP to describe MRCP resource capabilities). >> >> Andrew >> >> Dave Burke wrote: >> >>> I have to side with Brett here. >>> >>> The reality is that there are plenty of things that the client may >>> find out about the server "too late". Here are the ones that will >>> undoubtedly happen in practice: >>> - a given language not supported >>> - a given semantic interpretation format within the SRGS s >>> not supported >>> - speech enrollment not supported >>> >>> In practice, a client will know the vendor of the speech resource >>> servers identified by a SIP URI and will know what to expect; network >>> administrators will know not to load balance / failover a >>> hetergeonous vendor set. >>> >>> It seems much cleaner to use Accept on the RECOGNIZE request so the >>> server knows the format(s) to use for the RECOGNITION-COMPLETE final >>> response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. >>> >>> Dave >>> >>> ----- Original Message ----- From: "Brett Gavagni" >>> To: "Eric Burger" >>> Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, >>> Saravanan" >>> Sent: Wednesday, October 19, 2005 11:31 AM >>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >>> EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>> >>> >>>> I not too thrilled with the implication of leaking more MRCP >>>> Application >>>> parameters into SDP, which could be possibly considered outside the >>>> scope >>>> of resource session establishment,. This could potentially end up >>>> complicating interoperability scenarios. >>>> >>>> Thanks, >>>> >>>> Brett Gavagni >>>> WebSphere Voice Server Development >>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>> gavagni@us.ibm.com >>>> >>>> >>>> >>>> >>>> "Eric Burger" >>>> 10/18/2005 10:48 PM >>>> >>>> To >>>> "Shanmugham, Saravanan" , Brett Gavagni/West Palm >>>> Beach/IBM@IBMUS >>>> cc >>>> "IETF SPEECHSC \(E-mail\)" >>>> Subject >>>> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> >>>> >>>> >>>> >>>> >>>> Fine with me, so long as server can reject and client can handle >>>> situation >>>> where I ask for only NLSML in SIP negotiation and then I ask for >>>> EMMA and >>>> the server doesn't handle it. >>>> >>>> -----Original Message----- >>>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >>>> Sent: Tue Oct 18 20:57:20 2005 >>>> To: Eric Burger; Brett Gavagni >>>> Cc: IETF SPEECHSC (E-mail) >>>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >>>> EMMA: >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> I suggest that we do both. >>>> The SIP Alow/Accept header during MRCP session setup for server >>>> discovery and routing. >>>> We then add support for the Accept header in MRCPv2 messages. I suspect >>>> this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. >>>> And can be used in the case where the client or the server can do both. >>>> >>>> What do you think. >>>> >>>> Sarvi >>>> >>>> -----Original Message----- >>>> From: Eric Burger [mailto:eburger@brooktrout.com] >>>> Sent: Monday, October 17, 2005 1:52 PM >>>> To: Shanmugham, Saravanan; Brett Gavagni >>>> Cc: IETF SPEECHSC (E-mail) >>>> Subject: Question on negotiating EMMA (was RE: [Speechsc] >>>> EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> My logic, which may be flawed, is that we want to be able >>>> to achieve these objectives. >>>> o Ensure the trivial ability to negotiate other result >>>> formats, such as EMMA. >>>> o Ensure the server knows what format the client wants. >>>> o Ensure the client knows the server supports the format >>>> the client wants, before it is "too late". >>>> >>>> I would offer that using SET-PARAMS is "too late", in that >>>> the client and server has already spent the effort to >>>> establish the RTP sessions. >>>> It would be a pity to then tear it all down when the >>>> client finds out the server does not support the format of choice. >>>> >>>> One can negotiating the format at session establishment >>>> time with SDP >>>> (a=resultformat:application/emma-xml) or with SIP >>>> (Allow/Accept). I would offer that it is easier to >>>> implement, and makes MRCPv2 (SIP) proxies easier if we do >>>> the negotiation at the SIP level. For example, if a >>>> client wants results in EMMA, a MRCPv2 proxy can route the >>>> request to a server that supports EMMA by inspecting the >>>> SIP headers, rather than having to dive in to the SDP. >>>> >>>> While the preceding paragraph indicates my preference for >>>> using the SIP negotiation mechanism, there still is the >>>> case where both the client and server support NLSML and EMMA. >>>> >>>> ++++ THE QUESTION ++++ >>>> Is there a realistic use case where the client, in any >>>> given session, would want to use multiple result formats? >>>> That is, something like, "RECOGNIZE this and give me the >>>> result in EMMA" and then later issue something like, >>>> "RECOGNIZE that and give me the result in NLSML"? >>>> >>>> If so, then we would *also* need a per-recognition / >>>> SET-PARAMS header for the result type. >>>> >>>> -----Original Message----- >>>> From: speechsc-bounces@ietf.org >>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of >>>> Shanmugham, Saravanan >>>> Sent: Wednesday, September 28, 2005 2:36 PM >>>> To: Brett Gavagni; Jerry Carter >>>> Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo >>>> Subject: RE: [Speechsc] EMMA: >>>> ExtensibleMultiModalAnnotation markuplanguagesupport? >>>> >>>> Would something like the HTTP "Accept" header address >>>> these and other similar concerns. >>>> The RECOGNIZE request can then carry this header in it to >>>> specify an alternative to NLSML. >>>> >>>> Sarvi >>>> >>>> -----Original Message----- >>>> From: speechsc-bounces@ietf.org >>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni >>>> Sent: Saturday, September 24, 2005 7:51 AM >>>> To: Jerry Carter >>>> Cc: IETF SPEECHSC (E-mail); >>>> speechsc-bounces@ietf.org; Baggia Paolo >>>> Subject: Re: [Speechsc] EMMA: Extensible >>>> MultiModalAnnotation markuplanguagesupport? >>>> >>>> Hi, >>>> >>>> I agree that the ability for a client to request the >>>> format of the recognizer result data content would be useful. >>>> >>>> I would prefer to see this function defined in a >>>> consistent manner with the current draft specification; by >>>> a client request to enable a session parameter via a >>>> header (ie. "Result-Data-Type") in a SET-PARAMS or >>>> RECOGNIZE request, rather than an attribute used for >>>> RECOGNIZER session negotiation/update. The server should >>>> then respond with an accept or reject response as it does >>>> today for other client requested parameter values. >>>> Currently, the draft specification doesn't expose the MRCP >>>> resource configurable parameters in the SDP. >>>> >>>> I don't think that enabling platform-specific formats >>>> facilitates the adoption of a standard specification for >>>> speech resources. I believe that the specification should >>>> continue to address the required supported formats and >>>> require new draft iterations including the updated >>>> specifications. The updated draft iterations would >>>> continue to assist with potential client/server >>>> interoperability issues. >>>> >>>> Thanks, >>>> >>>> Brett Gavagni >>>> WebSphere Voice Server Development >>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>> gavagni@us.ibm.com >>>> >>>> >>>> >>>> >>>> Jerry Carter >>>> Sent by: speechsc-bounces@ietf.org >>>> 09/23/2005 11:42 PM >>>> >>>> To >>>> Baggia Paolo cc "IETF SPEECHSC >>>> \(E-mail\)" Subject >>>> Re: [Speechsc] EMMA: Extensible MultiModal Annotation >>>> markuplanguagesupport? >>>> >>>> >>>> >>>> >>>> >>>> >>>> I agree that minor changes made today will prevent >>>> the need for an >>>> amended document in the very near future. Providing >>>> for content >>>> negotiation solves both the EMMA issue and allows for >>>> future or >>>> platform-specific return formats without requiring that the >>>> specification be iterated. >>>> >>>> Of the two suggestions, I prefer the SDP extension as the >>>> return format >>>> is analogous to other SIP media type negotiations. >>>> >>>> >>>> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: >>>> > the last answers and discussions in this thread >>>> seems to confirm >>>> > that the direction of MRCPv2 is to allow the use of >>>> EMMA when >>>> > it will become a W3C Recommendation. Some text >>>> should be added >>>> > in the future release to say that. >>>> > This is fine from us point of view, but a mechanism >>>> for asking >>>> > a different result format is not present in the >>>> current draft. >>>> > >>>> > We think to add that mechanism will allow a smooth >>>> transition >>>> > from the current situation: always result in >>>> "application/nlsml+xml", >>>> > to a future one with results in EMMA. >>>> > >>>> > Would it be possible to consider this "negotiation" >>>> of the output >>>> > result in the next draft? >>>> > >>>> > There are different options to implement it: >>>> > a) to extend SDP to leave taht outside of MRCPv2 >>>> core protocol >>>> > E.g. >>>> > a=recogResultFormat:application/nlsml+xml >>>> > if present it sets the recognition result for a whole MRCP >>>> > session. >>>> > >>>> > b) to add a new recognizer header to set the result format >>>> > for that specific recognition turn. >>>> > >>>> > What do you think? >>>> > >>>> > We are aware the draft is near to be closed, but we >>>> think this >>>> > will help the passage from NLSML to EMMA. >>>> > >>>> > Regards, >>>> > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 13:31:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHme-0005si-H1; Wed, 19 Oct 2005 13:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHmd-0005sJ-Kz for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 13:31:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00151 for ; Wed, 19 Oct 2005 13:31:14 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHyN-00021w-Eq for speechsc@ietf.org; Wed, 19 Oct 2005 13:43:34 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2005 10:30:57 -0700 X-IronPort-AV: i="3.97,231,1125903600"; d="scan'208"; a="221687082:sNHT855447856" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9JHUsUw006701; Wed, 19 Oct 2005 10:30:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 10:30:53 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C67703F@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXU0F47WmfPx0agR6alHID1xnH0iQAAUBTQ From: "Shanmugham, Saravanan" To: "Dave Burke" , "Andrew Wahbe" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Discovery for MRCPv2 capabilities in general is through SIP options as described in Section 7 of the draft.=20 =20 On the topic of EMMA/NLSML. After reading some of the emails. I am rethinking my previous acceptance of Eric's SIP Accept idea. I think his alternate suggestion of making it part of the SDP for the session makes more sense for the following reasons. 1. It works well with the above discovery mechanism which describe capabilities through SDP. 2. It works for routing as such a proxy can take look at the SDP to make this decision.=20 3. A routing proxy would any way have to look at the SDP for other things such as resource type. 4. It also allows this to be negotiated during Session Setup through the INVITE offer answer model. I would also suggest that we still add the Accept Header similar to HTTP into MRCP messages to be used in messages like, SET-PARAMS, GET-PARAMS, RECOGNIZE, INTERPRET as well. This allows us to change format for individual requests or the session as necessry if the resource supports more than one format. Sarvi -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Wednesday, October 19, 2005 10:12 AM To: Andrew Wahbe Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan; Eric Burger Subject: Re: Question on negotiating EMMA (was RE:=20 [Speechsc]=20 EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 There is certainly a general question of how an MRCP=20 server advertises capabilities and how the client requests=20 particular capabilities. I do, however, believe that=20 MRCP's choice of SIP for discovery and rendevous will=20 still prove wise. The mechanism for capability=20 advertisement and specification might be best delegated to=20 a separate draft at this point in MRCP's development. For=20 now we've got DNS SRV (a given AOR can indicate a=20 particular capability set e.g. vendorx.en.example.com). =20 As far as mechanisms are considered, I'm still not keen on=20 using SDP. A "pure" SIP proxy (as defined in RFC 3261)=20 will not work by analysing SDP.=20 Nor will registering an MRCP server capability set (since=20 REGISTER does not contain SDP and it's Accept / Allow=20 headers relate to the response to the REGISTER). That=20 leaves headers: one framework that could be considered is=20 based on RFC 3840/3841. For example, a speechrecog does a register: =20 REGISTER sip:example.com To: asr@example.com Contact: ;language=3D"en";reco-result-format=3D"EMMA" =20 An MRCP client looking for an ASR engine supporting EMMA=20 and English places the following request to a proxy. =20 INVITE sip:asr@example.com Accept-Contact: *;reco-result-format=3D"EMMA";language=3D"en" =20 The OPTIONS method (already mentioned in MRCPv2) can also=20 be used (it returns the Contact header with the feature=20 parameters). =20 Dave =20 ----- Original Message ----- From: "Andrew Wahbe" To: "Andrew Wahbe" Cc: "Dave Burke" ; "IETF=20 SPEECHSC (E-mail)"=20 ; "Shanmugham, Saravanan"=20 ; "Eric Burger" Sent: Wednesday, October 19, 2005 4:18 PM Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 =20 > On reading my own response I realized that a re-invite=20 wouldn't work=20 > with a proxy. oops. (please hold back your comments ;-).=20 I don't think=20 > this changes my point though. > > Andrew > > Andrew Wahbe wrote: > >> The question is whether you want the client to know=20 which homogeneous=20 >> set to use, or if you want a proxy to do it for you. If=20 you want a=20 >> proxy to be able to do this for you then you want it in=20 the SDP (or=20 >> perhaps a SIP header but I'd prefer SDP) wouldn't you? >> >> Also note that things like the required language(s) can=20 change over=20 >> the course of one call. You could update your SDP and=20 ReInvite in=20 >> this case (and the proxy would find an appropriate=20 server) or (if it=20 >> is client driven) you could switch over to another=20 homogeneous set. >> >> I thought that advertising your needs and capabilities=20 in session=20 >> establishment so that you could be connected to a =20 compatible server=20 >> was a big part of the point in using SIP here. If we=20 resort to saying=20 >> that "network administrators should know how to load=20 balance this=20 >> properly", can't we also say that "network=20 administrators should=20 >> configure everything to use the same codec" etc? >> >> Having said that, I think that one could still argue=20 that the emma vs=20 >> nlsml support is a stretch for session establishment...=20 its some of=20 >> the other examples you gave that I have issue with. I=20 hope we don't=20 >> rule these out. I haven't brought this up earlier=20 because I seem to=20 >> remember someone saying that this sort of thing could=20 be the subject=20 >> of another separate RFC (SDP to describe MRCP resource=20 capabilities). >> >> Andrew >> >> Dave Burke wrote: >> >>> I have to side with Brett here. >>> >>> The reality is that there are plenty of things that=20 the client may=20 >>> find out about the server "too late". Here are the=20 ones that will=20 >>> undoubtedly happen in practice: >>> - a given language not supported >>> - a given semantic interpretation format within the=20 SRGS s=20 >>> not supported >>> - speech enrollment not supported >>> >>> In practice, a client will know the vendor of the=20 speech resource=20 >>> servers identified by a SIP URI and will know what to expect;=20 >>> network administrators will know not to load balance /=20 failover a=20 >>> hetergeonous vendor set. >>> >>> It seems much cleaner to use Accept on the RECOGNIZE=20 request so the=20 >>> server knows the format(s) to use for the=20 RECOGNITION-COMPLETE final=20 >>> response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. >>> >>> Dave >>> >>> ----- Original Message ----- From: "Brett Gavagni"=20 >>> >>> To: "Eric Burger" >>> Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham,=20 >>> Saravanan" >>> Sent: Wednesday, October 19, 2005 11:31 AM >>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >>> EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>> >>> >>>> I not too thrilled with the implication of leaking more MRCP=20 >>>> Application parameters into SDP, which could be possibly=20 >>>> considered outside the scope of resource session=20 establishment,.=20 >>>> This could potentially end up complicating interoperability=20 >>>> scenarios. >>>> >>>> Thanks, >>>> >>>> Brett Gavagni >>>> WebSphere Voice Server Development >>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>> gavagni@us.ibm.com >>>> >>>> >>>> >>>> >>>> "Eric Burger" >>>> 10/18/2005 10:48 PM >>>> >>>> To >>>> "Shanmugham, Saravanan" , Brett=20 Gavagni/West Palm=20 >>>> Beach/IBM@IBMUS cc "IETF SPEECHSC \(E-mail\)"=20 =20 >>>> Subject >>>> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> >>>> >>>> >>>> >>>> >>>> Fine with me, so long as server can reject and client=20 can handle=20 >>>> situation where I ask for only NLSML in SIP=20 negotiation and then I=20 >>>> ask for EMMA and the server doesn't handle it. >>>> >>>> -----Original Message----- >>>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >>>> Sent: Tue Oct 18 20:57:20 2005 >>>> To: Eric Burger; Brett Gavagni >>>> Cc: IETF SPEECHSC (E-mail) >>>> Subject: RE: Question on negotiating EMMA (was=20 RE: [Speechsc] >>>> EMMA: >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> I suggest that we do both. >>>> The SIP Alow/Accept header during MRCP session setup=20 for server=20 >>>> discovery and routing. >>>> We then add support for the Accept header in MRCPv2=20 messages. I=20 >>>> suspect this will be initially only used for=20 RECOGNIZE/SET-PARAMS/GET-PARAMS. >>>> And can be used in the case where the client or the=20 server can do both. >>>> >>>> What do you think. >>>> >>>> Sarvi >>>> >>>> -----Original Message----- >>>> From: Eric Burger [mailto:eburger@brooktrout.com] >>>> Sent: Monday, October 17, 2005 1:52 PM >>>> To: Shanmugham, Saravanan; Brett Gavagni >>>> Cc: IETF SPEECHSC (E-mail) >>>> Subject: Question on negotiating EMMA (was RE: [Speechsc] >>>> EMMA:=20 ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> My logic, which may be flawed, is that we want to be able >>>> to achieve these objectives. >>>> o Ensure the trivial ability to negotiate other result >>>> formats, such as EMMA. >>>> o Ensure the server knows what format the client wants. >>>> o Ensure the client knows the server supports=20 the format >>>> the client wants, before it is "too late". >>>> >>>> I would offer that using SET-PARAMS is "too late", in that >>>> the client and server has already spent the effort to >>>> establish the RTP sessions. >>>> It would be a pity to then tear it all down when the >>>> client finds out the server does not support the=20 format of choice. >>>> >>>> One can negotiating the format at session establishment >>>> time with SDP >>>> (a=3Dresultformat:application/emma-xml) or with SIP >>>> (Allow/Accept). I would offer that it is easier to >>>> implement, and makes MRCPv2 (SIP) proxies easier if we do >>>> the negotiation at the SIP level. For example, if a >>>> client wants results in EMMA, a MRCPv2 proxy can route the >>>> request to a server that supports EMMA by inspecting the >>>> SIP headers, rather than having to dive in to the SDP. >>>> >>>> While the preceding paragraph indicates my preference for >>>> using the SIP negotiation mechanism, there still is the >>>> case where both the client and server support=20 NLSML and EMMA. >>>> >>>> ++++ THE QUESTION ++++ >>>> Is there a realistic use case where the client, in any >>>> given session, would want to use multiple result formats? >>>> That is, something like, "RECOGNIZE this and give me the >>>> result in EMMA" and then later issue something like, >>>> "RECOGNIZE that and give me the result in NLSML"? >>>> >>>> If so, then we would *also* need a per-recognition / >>>> SET-PARAMS header for the result type. >>>> >>>> -----Original Message----- >>>> From: speechsc-bounces@ietf.org >>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of >>>> Shanmugham, Saravanan >>>> Sent: Wednesday, September 28, 2005 2:36 PM >>>> To: Brett Gavagni; Jerry Carter >>>> Cc: IETF SPEECHSC (E-mail);=20 speechsc-bounces@ietf.org; Baggia Paolo >>>> Subject: RE: [Speechsc] EMMA: >>>> ExtensibleMultiModalAnnotation markuplanguagesupport? >>>> >>>> Would something like the HTTP "Accept" header address >>>> these and other similar concerns. >>>> The RECOGNIZE request can then carry this header in it to >>>> specify an alternative to NLSML. >>>> >>>> Sarvi >>>> >>>> -----Original Message----- >>>> From: speechsc-bounces@ietf.org >>>> [mailto:speechsc-bounces@ietf.org] On Behalf=20 Of Brett Gavagni >>>> Sent: Saturday, September 24, 2005 7:51 AM >>>> To: Jerry Carter >>>> Cc: IETF SPEECHSC (E-mail); >>>> speechsc-bounces@ietf.org; Baggia Paolo >>>> Subject: Re: [Speechsc] EMMA: Extensible >>>> MultiModalAnnotation markuplanguagesupport? >>>> >>>> Hi, >>>> >>>> I agree that the ability for a client to request the >>>> format of the recognizer result data content=20 would be useful. >>>> >>>> I would prefer to see this function defined in a >>>> consistent manner with the current draft=20 specification; by >>>> a client request to enable a session parameter via a >>>> header (ie. "Result-Data-Type") in a SET-PARAMS or >>>> RECOGNIZE request, rather than an attribute used for >>>> RECOGNIZER session negotiation/update. The=20 server should >>>> then respond with an accept or reject=20 response as it does >>>> today for other client requested parameter values. >>>> Currently, the draft specification doesn't=20 expose the MRCP >>>> resource configurable parameters in the SDP. >>>> >>>> I don't think that enabling platform-specific formats >>>> facilitates the adoption of a standard=20 specification for >>>> speech resources. I believe that the=20 specification should >>>> continue to address the required supported=20 formats and >>>> require new draft iterations including the updated >>>> specifications. The updated draft iterations would >>>> continue to assist with potential client/server >>>> interoperability issues. >>>> >>>> Thanks, >>>> >>>> Brett Gavagni >>>> WebSphere Voice Server Development >>>> =20 http://www-306.ibm.com/software/pervasive/voice_server/ >>>> gavagni@us.ibm.com >>>> >>>> >>>> >>>> >>>> Jerry Carter >>>> Sent by: speechsc-bounces@ietf.org >>>> 09/23/2005 11:42 PM >>>> >>>> To >>>> Baggia Paolo cc=20 "IETF SPEECHSC >>>> \(E-mail\)" Subject >>>> Re: [Speechsc] EMMA: Extensible MultiModal Annotation >>>> markuplanguagesupport? >>>> >>>> >>>> >>>> >>>> >>>> >>>> I agree that minor changes made today will prevent >>>> the need for an >>>> amended document in the very near future. Providing >>>> for content >>>> negotiation solves both the EMMA issue and allows for >>>> future or >>>> platform-specific return formats without=20 requiring that the >>>> specification be iterated. >>>> >>>> Of the two suggestions, I prefer the SDP=20 extension as the >>>> return format >>>> is analogous to other SIP media type negotiations. >>>> >>>> >>>> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: >>>> > the last answers and discussions in this thread >>>> seems to confirm >>>> > that the direction of MRCPv2 is to allow the use of >>>> EMMA when >>>> > it will become a W3C Recommendation. Some text >>>> should be added >>>> > in the future release to say that. >>>> > This is fine from us point of view, but a mechanism >>>> for asking >>>> > a different result format is not present in the >>>> current draft. >>>> > >>>> > We think to add that mechanism will allow a smooth >>>> transition >>>> > from the current situation: always result in >>>> "application/nlsml+xml", >>>> > to a future one with results in EMMA. >>>> > >>>> > Would it be possible to consider this "negotiation" >>>> of the output >>>> > result in the next draft? >>>> > >>>> > There are different options to implement it: >>>> > a) to extend SDP to leave taht outside of MRCPv2 >>>> core protocol >>>> > E.g. >>>> > a=3DrecogResultFormat:application/nlsml+xml >>>> > if present it sets the recognition result=20 for a whole MRCP >>>> > session. >>>> > >>>> > b) to add a new recognizer header to set=20 the result format >>>> > for that specific recognition turn. >>>> > >>>> > What do you think? >>>> > >>>> > We are aware the draft is near to be closed, but we >>>> think this >>>> > will help the passage from NLSML to EMMA. >>>> > >>>> > Regards, >>>> > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo=20 >>>> (Loquendo) >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>> >>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>_______________________________________________ >>Speechsc mailing list >>Speechsc@ietf.org >>https://www1.ietf.org/mailman/listinfo/speechsc >> >> >=20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 14:10:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIOd-0006gW-HZ; Wed, 19 Oct 2005 14:10:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIOa-0006gO-NA for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 14:10:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03036 for ; Wed, 19 Oct 2005 14:10:26 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESIaM-0003Qo-Uy for speechsc@ietf.org; Wed, 19 Oct 2005 14:22:47 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9JI6asE023177; Wed, 19 Oct 2005 14:06:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 14:06:08 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647015F0CB6@ATLANTIS.Brooktrout.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXUq7JFQsmdT4PWQw6bzp0gw/pHrgAK9xKg From: "Eric Burger" To: "Dave Burke" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org We may all agree. SDP is the wrong place for this. However, SIP is the right place for such negotiations. I would offer, in comment to one of the suggestions below, that the client cannot determine server capabilities from a URI. -----Original Message----- From: Dave Burke [mailto:david.burke@voxpilot.com]=20 Sent: Wednesday, October 19, 2005 8:50 AM To: Eric Burger; Brett Gavagni Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) I have to side with Brett here. The reality is that there are plenty of things that the client may find out=20 about the server "too late". Here are the ones that will undoubtedly happen=20 in practice: - a given language not supported - a given semantic interpretation format within the SRGS s not=20 supported - speech enrollment not supported In practice, a client will know the vendor of the speech resource servers=20 identified by a SIP URI and will know what to expect; network administrators=20 will know not to load balance / failover a hetergeonous vendor set. It seems much cleaner to use Accept on the RECOGNIZE request so the server=20 knows the format(s) to use for the RECOGNITION-COMPLETE final response.=20 SET-OPTIONs/GET-OPTIONs can be used for stickyness. Dave ----- Original Message -----=20 From: "Brett Gavagni" To: "Eric Burger" Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, Saravanan"=20 Sent: Wednesday, October 19, 2005 11:31 AM Subject: RE: Question on negotiating EMMA (was RE: [Speechsc]=20 EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >I not too thrilled with the implication of leaking more MRCP Application > parameters into SDP, which could be possibly considered outside the scope > of resource session establishment,. This could potentially end up > complicating interoperability scenarios. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > "Eric Burger" > 10/18/2005 10:48 PM > > To > "Shanmugham, Saravanan" , Brett Gavagni/West Palm > Beach/IBM@IBMUS > cc > "IETF SPEECHSC \(E-mail\)" > Subject > RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > > > > > Fine with me, so long as server can reject and client can handle situation > where I ask for only NLSML in SIP negotiation and then I ask for EMMA and > the server doesn't handle it. > > -----Original Message----- > From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > Sent: Tue Oct 18 20:57:20 2005 > To: Eric Burger; Brett Gavagni > Cc: IETF SPEECHSC (E-mail) > Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > I suggest that we do both. > The SIP Alow/Accept header during MRCP session setup for server > discovery and routing. > We then add support for the Accept header in MRCPv2 messages. I suspect > this will be initially only used for RECOGNIZE/SET-PARAMS/GET-PARAMS. > And can be used in the case where the client or the server can do both. > > What do you think. > > Sarvi > > -----Original Message----- > From: Eric Burger [mailto:eburger@brooktrout.com] > Sent: Monday, October 17, 2005 1:52 PM > To: Shanmugham, Saravanan; Brett Gavagni > Cc: IETF SPEECHSC (E-mail) > Subject: Question on negotiating EMMA (was RE: [Speechsc] > EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > My logic, which may be flawed, is that we want to be able > to achieve these objectives. > o Ensure the trivial ability to negotiate other result > formats, such as EMMA. > o Ensure the server knows what format the client wants. > o Ensure the client knows the server supports the format > the client wants, before it is "too late". > > I would offer that using SET-PARAMS is "too late", in that > the client and server has already spent the effort to > establish the RTP sessions. > It would be a pity to then tear it all down when the > client finds out the server does not support the format of choice. > > One can negotiating the format at session establishment > time with SDP > (a=3Dresultformat:application/emma-xml) or with SIP > (Allow/Accept). I would offer that it is easier to > implement, and makes MRCPv2 (SIP) proxies easier if we do > the negotiation at the SIP level. For example, if a > client wants results in EMMA, a MRCPv2 proxy can route the > request to a server that supports EMMA by inspecting the > SIP headers, rather than having to dive in to the SDP. > > While the preceding paragraph indicates my preference for > using the SIP negotiation mechanism, there still is the > case where both the client and server support NLSML and EMMA. > > ++++ THE QUESTION ++++ > Is there a realistic use case where the client, in any > given session, would want to use multiple result formats? > That is, something like, "RECOGNIZE this and give me the > result in EMMA" and then later issue something like, > "RECOGNIZE that and give me the result in NLSML"? > > If so, then we would *also* need a per-recognition / > SET-PARAMS header for the result type. > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of > Shanmugham, Saravanan > Sent: Wednesday, September 28, 2005 2:36 PM > To: Brett Gavagni; Jerry Carter > Cc: IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org; Baggia Paolo > Subject: RE: [Speechsc] EMMA: > ExtensibleMultiModalAnnotation markuplanguagesupport? > > Would something like the HTTP "Accept" header address > these and other similar concerns. > The RECOGNIZE request can then carry this header in it to > specify an alternative to NLSML. > > Sarvi > > -----Original Message----- > From: speechsc-bounces@ietf.org > [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni > Sent: Saturday, September 24, 2005 7:51 AM > To: Jerry Carter > Cc: IETF SPEECHSC (E-mail); > speechsc-bounces@ietf.org; Baggia Paolo > Subject: Re: [Speechsc] EMMA: Extensible > MultiModalAnnotation markuplanguagesupport? > > Hi, > > I agree that the ability for a client to request the > format of the recognizer result data content would be useful. > > I would prefer to see this function defined in a > consistent manner with the current draft specification; by > a client request to enable a session parameter via a > header (ie. "Result-Data-Type") in a SET-PARAMS or > RECOGNIZE request, rather than an attribute used for > RECOGNIZER session negotiation/update. The server should > then respond with an accept or reject response as it does > today for other client requested parameter values. > Currently, the draft specification doesn't expose the MRCP > resource configurable parameters in the SDP. > > I don't think that enabling platform-specific formats > facilitates the adoption of a standard specification for > speech resources. I believe that the specification should > continue to address the required supported formats and > require new draft iterations including the updated > specifications. The updated draft iterations would > continue to assist with potential client/server > interoperability issues. > > Thanks, > > Brett Gavagni > WebSphere Voice Server Development > http://www-306.ibm.com/software/pervasive/voice_server/ > gavagni@us.ibm.com > > > > > Jerry Carter > Sent by: speechsc-bounces@ietf.org > 09/23/2005 11:42 PM > > To > Baggia Paolo cc "IETF SPEECHSC > \(E-mail\)" Subject > Re: [Speechsc] EMMA: Extensible MultiModal Annotation > markuplanguagesupport? > > > > > > > I agree that minor changes made today will prevent > the need for an > amended document in the very near future. Providing > for content > negotiation solves both the EMMA issue and allows for > future or > platform-specific return formats without requiring that the > specification be iterated. > > Of the two suggestions, I prefer the SDP extension as the > return format > is analogous to other SIP media type negotiations. > > > On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > > the last answers and discussions in this thread > seems to confirm > > that the direction of MRCPv2 is to allow the use of > EMMA when > > it will become a W3C Recommendation. Some text > should be added > > in the future release to say that. > > This is fine from us point of view, but a mechanism > for asking > > a different result format is not present in the > current draft. > > > > We think to add that mechanism will allow a smooth > transition > > from the current situation: always result in > "application/nlsml+xml", > > to a future one with results in EMMA. > > > > Would it be possible to consider this "negotiation" > of the output > > result in the next draft? > > > > There are different options to implement it: > > a) to extend SDP to leave taht outside of MRCPv2 > core protocol > > E.g. > > a=3DrecogResultFormat:application/nlsml+xml > > if present it sets the recognition result for a whole MRCP > > session. > > > > b) to add a new recognizer header to set the result format > > for that specific recognition turn. > > > > What do you think? > > > > We are aware the draft is near to be closed, but we > think this > > will help the passage from NLSML to EMMA. > > > > Regards, > > Paolo Baggia, Vittorio Manzone, Patrizio Bergallo (Loquendo) > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc >=20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 14:15:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIT7-00088q-64; Wed, 19 Oct 2005 14:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESIT5-000872-Pi for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 14:15:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03343 for ; Wed, 19 Oct 2005 14:15:06 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESIer-0003bA-Cx for speechsc@ietf.org; Wed, 19 Oct 2005 14:27:26 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j9JIApsE023442 for ; Wed, 19 Oct 2005 14:10:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 14:10:24 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647015F0CC9@ATLANTIS.Brooktrout.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXBF7LZUgDMECDISG+EWsriadeA8ADQ3H0wA7eFaSAAQ4S2IAAEFPVuABLc00AADUwGkA== From: "Eric Burger" To: "IETF SPEECHSC \(E-mail\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org With this input, I would offer that if we support this feature, it needs = to be specifiable on a per-method basis. ________________________________________ From: Baggia Paolo [mailto:Paolo.Baggia@LOQUENDO.COM]=20 Sent: Wednesday, October 19, 2005 7:54 AM To: Eric Burger; Shanmugham, Saravanan; Brett Gavagni Cc: IETF SPEECHSC (E-mail); Baggia Paolo Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] = EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Eric, =A0 I'd like to answer first to the precise question you raised below. =A0 The use case is real, but the matter is between NLSML and EMMA, but between a raw result and a detailed result. I can see very well an application that uses a certain level of information in all the normal ASR turns, but in some specific one the detail need to be more precise. So the client might ask to return results in a different format then the normal one. =A0 Other people are working to give a more thorough answer on the whole concern. =A0 Paolo =A0=A0=A0=A0 -----Original Message----- =A0=A0=A0=A0 From: Eric Burger [mailto:eburger@brooktrout.com] =A0=A0=A0=A0 Sent: Monday, October 17, 2005 1:52 PM =A0=A0=A0=A0 To: Shanmugham, Saravanan; Brett Gavagni =A0=A0=A0=A0 Cc: IETF SPEECHSC (E-mail) =A0=A0=A0=A0 Subject: Question on negotiating EMMA (was RE: [Speechsc] =A0=A0=A0=A0 EMMA: ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0 ++++ THE QUESTION ++++ =A0=A0=A0=A0 Is there a realistic use case where the client, in any =A0=A0=A0=A0 given session, would want to use multiple result = formats?=A0 =A0=A0=A0=A0 That is, something like, "RECOGNIZE this and give me the =A0=A0=A0=A0 result in EMMA" and then later issue something like, =A0=A0=A0=A0 "RECOGNIZE that and give me the result in NLSML"? =A0=A0=A0=A0 =A0=A0=A0=A0 If so, then we would *also* need a per-recognition / =A0=A0=A0=A0 SET-PARAMS header for the result type. =A0=A0=A0=A0 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 15:32:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJfR-0003Gg-3p; Wed, 19 Oct 2005 15:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJfO-0003EO-Hz for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 15:32:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08509 for ; Wed, 19 Oct 2005 15:31:52 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESJrB-00065a-9i for speechsc@ietf.org; Wed, 19 Oct 2005 15:44:14 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2005 12:31:52 -0700 X-IronPort-AV: i="3.97,231,1125903600"; d="scan'208"; a="667598339:sNHT36312968" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9JJVnub003383; Wed, 19 Oct 2005 12:31:50 -0700 (PDT) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9JJg9BO019702; Wed, 19 Oct 2005 12:42:10 -0700 In-Reply-To: <03772D1EC8DE624A863058C75874A75C67703F@vtg-um-e2k6.sj21ad.cisco.com> References: <03772D1EC8DE624A863058C75874A75C67703F@vtg-um-e2k6.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5848429E-B5A8-4793-B33F-BE4DC0A99998@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 15:31:40 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=14618; t=1129750934; x=1130183134; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20Question=20on=20negotiating=20EMMA=20(was=20RE=3A=09[Speechsc]=0 9EMMA=3AExtensibleMultiModalAnnotationmarkuplanguagesupport?)| From:David=20R=20Oran=20| Date:Wed,=2019=20Oct=202005=2015=3A31=3A40=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=bpGty5ra0x7qSJ4y7mqy3p4sw2RtKHtAvE2m0VnjrWy73YWrpZb5P5yg8ryRBumbkP3Z8JHd 9D8Az7GBAlGJNLGLWWzF4D1j48Gnt8Y/uxK2qkPj/BuTDPl3nJbjAw2AZYrgMRQWJvlywfNXpw/ m41zdjiZbTsLusTp7O48V1vw= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger , Andrew Wahbe , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On Oct 19, 2005, at 1:30 PM, Shanmugham, Saravanan wrote: > Discovery for MRCPv2 capabilities in general is through SIP options as > described in Section 7 of the draft. > > On the topic of EMMA/NLSML. > > After reading some of the emails. I am rethinking my previous > acceptance > of Eric's SIP Accept idea. > > I think his alternate suggestion of making it part of the SDP for the > session makes more sense for the following reasons. > > 1. It works well with the above discovery mechanism which describe > capabilities through SDP. > 2. It works for routing as such a proxy can take look at the SDP to > make this decision. Really? What if it's SMIME encrypted. i would council against putting anythng needed for deciding which server to contact or how to route the request into the SDP. > 3. A routing proxy would any way have to look at the SDP for other > things such as resource type. If so, we've probably made a design error and should have it in SIP caller prefs instead. > 4. It also allows this to be negotiated during Session Setup > through > the INVITE offer answer model. > That is true. > I would also suggest that we still add the Accept Header similar to > HTTP > into MRCP messages to be used in messages like, SET-PARAMS, GET- > PARAMS, > RECOGNIZE, INTERPRET as well. This allows us to change format for > individual requests or the session as necessry if the resource > supports > more than one format. > > Sarvi > > > > -----Original Message----- > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Wednesday, October 19, 2005 10:12 AM > To: Andrew Wahbe > Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan; Eric Burger > Subject: Re: Question on negotiating EMMA (was RE: > [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > There is certainly a general question of how an MRCP > server advertises capabilities and how the client requests > particular capabilities. I do, however, believe that > MRCP's choice of SIP for discovery and rendevous will > still prove wise. The mechanism for capability > advertisement and specification might be best delegated to > a separate draft at this point in MRCP's development. For > now we've got DNS SRV (a given AOR can indicate a > particular capability set e.g. vendorx.en.example.com). > > As far as mechanisms are considered, I'm still not keen on > using SDP. A "pure" SIP proxy (as defined in RFC 3261) > will not work by analysing SDP. > Nor will registering an MRCP server capability set (since > REGISTER does not contain SDP and it's Accept / Allow > headers relate to the response to the REGISTER). That > leaves headers: one framework that could be considered is > based on RFC 3840/3841. For example, a speechrecog does a > register: > > REGISTER sip:example.com > To: asr@example.com > Contact: ;language="en";reco-result-format="EMMA" > > An MRCP client looking for an ASR engine supporting EMMA > and English places the following request to a proxy. > > INVITE sip:asr@example.com > Accept-Contact: *;reco-result-format="EMMA";language="en" > > The OPTIONS method (already mentioned in MRCPv2) can also > be used (it returns the Contact header with the feature > parameters). > > Dave > > ----- Original Message ----- > From: "Andrew Wahbe" > To: "Andrew Wahbe" > Cc: "Dave Burke" ; "IETF > SPEECHSC (E-mail)" > ; "Shanmugham, Saravanan" > ; "Eric Burger" > Sent: Wednesday, October 19, 2005 4:18 PM > Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > >> On reading my own response I realized that a re-invite >> > wouldn't work > >> with a proxy. oops. (please hold back your comments ;-). >> > I don't think > >> this changes my point though. >> >> Andrew >> >> Andrew Wahbe wrote: >> >> >>> The question is whether you want the client to know >>> > which homogeneous > >>> set to use, or if you want a proxy to do it for you. If >>> > you want a > >>> proxy to be able to do this for you then you want it in >>> > the SDP (or > >>> perhaps a SIP header but I'd prefer SDP) wouldn't you? >>> >>> Also note that things like the required language(s) can >>> > change over > >>> the course of one call. You could update your SDP and >>> > ReInvite in > >>> this case (and the proxy would find an appropriate >>> > server) or (if it > >>> is client driven) you could switch over to another >>> > homogeneous set. > >>> >>> I thought that advertising your needs and capabilities >>> > in session > >>> establishment so that you could be connected to a >>> > compatible server > >>> was a big part of the point in using SIP here. If we >>> > resort to saying > >>> that "network administrators should know how to load >>> > balance this > >>> properly", can't we also say that "network >>> > administrators should > >>> configure everything to use the same codec" etc? >>> >>> Having said that, I think that one could still argue >>> > that the emma vs > >>> nlsml support is a stretch for session establishment... >>> > its some of > >>> the other examples you gave that I have issue with. I >>> > hope we don't > >>> rule these out. I haven't brought this up earlier >>> > because I seem to > >>> remember someone saying that this sort of thing could >>> > be the subject > >>> of another separate RFC (SDP to describe MRCP resource >>> > capabilities). > >>> >>> Andrew >>> >>> Dave Burke wrote: >>> >>> >>>> I have to side with Brett here. >>>> >>>> The reality is that there are plenty of things that >>>> > the client may > >>>> find out about the server "too late". Here are the >>>> > ones that will > >>>> undoubtedly happen in practice: >>>> - a given language not supported >>>> - a given semantic interpretation format within the >>>> > SRGS s > >>>> not supported >>>> - speech enrollment not supported >>>> >>>> In practice, a client will know the vendor of the >>>> > speech resource > >>>> servers identified by a SIP URI and will know what to expect; >>>> network administrators will know not to load balance / >>>> > failover a > >>>> hetergeonous vendor set. >>>> >>>> It seems much cleaner to use Accept on the RECOGNIZE >>>> > request so the > >>>> server knows the format(s) to use for the >>>> > RECOGNITION-COMPLETE final > >>>> response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. >>>> >>>> Dave >>>> >>>> ----- Original Message ----- From: "Brett Gavagni" >>>> >>>> To: "Eric Burger" >>>> Cc: "IETF SPEECHSC (E-mail)" ; "Shanmugham, >>>> Saravanan" >>>> Sent: Wednesday, October 19, 2005 11:31 AM >>>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >>>> EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> >>>> >>>>> I not too thrilled with the implication of leaking more MRCP >>>>> Application parameters into SDP, which could be possibly >>>>> considered outside the scope of resource session >>>>> > establishment,. > >>>>> This could potentially end up complicating interoperability >>>>> scenarios. >>>>> >>>>> Thanks, >>>>> >>>>> Brett Gavagni >>>>> WebSphere Voice Server Development >>>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>>> gavagni@us.ibm.com >>>>> >>>>> >>>>> >>>>> >>>>> "Eric Burger" >>>>> 10/18/2005 10:48 PM >>>>> >>>>> To >>>>> "Shanmugham, Saravanan" , Brett >>>>> > Gavagni/West Palm > >>>>> Beach/IBM@IBMUS cc "IETF SPEECHSC \(E-mail\)" >>>>> > > >>>>> Subject >>>>> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: >>>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Fine with me, so long as server can reject and client >>>>> > can handle > >>>>> situation where I ask for only NLSML in SIP >>>>> > negotiation and then I > >>>>> ask for EMMA and the server doesn't handle it. >>>>> >>>>> -----Original Message----- >>>>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >>>>> Sent: Tue Oct 18 20:57:20 2005 >>>>> To: Eric Burger; Brett Gavagni >>>>> Cc: IETF SPEECHSC (E-mail) >>>>> Subject: RE: Question on negotiating EMMA (was >>>>> > RE: [Speechsc] > >>>>> EMMA: >>>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>>> >>>>> I suggest that we do both. >>>>> The SIP Alow/Accept header during MRCP session setup >>>>> > for server > >>>>> discovery and routing. >>>>> We then add support for the Accept header in MRCPv2 >>>>> > messages. I > >>>>> suspect this will be initially only used for >>>>> > RECOGNIZE/SET-PARAMS/GET-PARAMS. > >>>>> And can be used in the case where the client or the >>>>> > server can do both. > >>>>> >>>>> What do you think. >>>>> >>>>> Sarvi >>>>> >>>>> -----Original Message----- >>>>> From: Eric Burger [mailto:eburger@brooktrout.com] >>>>> Sent: Monday, October 17, 2005 1:52 PM >>>>> To: Shanmugham, Saravanan; Brett Gavagni >>>>> Cc: IETF SPEECHSC (E-mail) >>>>> Subject: Question on negotiating EMMA (was RE: [Speechsc] >>>>> EMMA: >>>>> > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>>> >>>>> My logic, which may be flawed, is that we want to be able >>>>> to achieve these objectives. >>>>> o Ensure the trivial ability to negotiate other result >>>>> formats, such as EMMA. >>>>> o Ensure the server knows what format the client wants. >>>>> o Ensure the client knows the server supports >>>>> > the format > >>>>> the client wants, before it is "too late". >>>>> >>>>> I would offer that using SET-PARAMS is "too late", in that >>>>> the client and server has already spent the effort to >>>>> establish the RTP sessions. >>>>> It would be a pity to then tear it all down when the >>>>> client finds out the server does not support the >>>>> > format of choice. > >>>>> >>>>> One can negotiating the format at session establishment >>>>> time with SDP >>>>> (a=resultformat:application/emma-xml) or with SIP >>>>> (Allow/Accept). I would offer that it is easier to >>>>> implement, and makes MRCPv2 (SIP) proxies easier if we do >>>>> the negotiation at the SIP level. For example, if a >>>>> client wants results in EMMA, a MRCPv2 proxy can route the >>>>> request to a server that supports EMMA by inspecting the >>>>> SIP headers, rather than having to dive in to the SDP. >>>>> >>>>> While the preceding paragraph indicates my preference for >>>>> using the SIP negotiation mechanism, there still is the >>>>> case where both the client and server support >>>>> > NLSML and EMMA. > >>>>> >>>>> ++++ THE QUESTION ++++ >>>>> Is there a realistic use case where the client, in any >>>>> given session, would want to use multiple result formats? >>>>> That is, something like, "RECOGNIZE this and give me the >>>>> result in EMMA" and then later issue something like, >>>>> "RECOGNIZE that and give me the result in NLSML"? >>>>> >>>>> If so, then we would *also* need a per-recognition / >>>>> SET-PARAMS header for the result type. >>>>> >>>>> -----Original Message----- >>>>> From: speechsc-bounces@ietf.org >>>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of >>>>> Shanmugham, Saravanan >>>>> Sent: Wednesday, September 28, 2005 2:36 PM >>>>> To: Brett Gavagni; Jerry Carter >>>>> Cc: IETF SPEECHSC (E-mail); >>>>> > speechsc-bounces@ietf.org; Baggia Paolo > >>>>> Subject: RE: [Speechsc] EMMA: >>>>> ExtensibleMultiModalAnnotation markuplanguagesupport? >>>>> >>>>> Would something like the HTTP "Accept" header address >>>>> these and other similar concerns. >>>>> The RECOGNIZE request can then carry this header in it to >>>>> specify an alternative to NLSML. >>>>> >>>>> Sarvi >>>>> >>>>> -----Original Message----- >>>>> From: speechsc-bounces@ietf.org >>>>> [mailto:speechsc-bounces@ietf.org] On Behalf >>>>> > Of Brett Gavagni > >>>>> Sent: Saturday, September 24, 2005 7:51 AM >>>>> To: Jerry Carter >>>>> Cc: IETF SPEECHSC (E-mail); >>>>> speechsc-bounces@ietf.org; Baggia Paolo >>>>> Subject: Re: [Speechsc] EMMA: Extensible >>>>> MultiModalAnnotation markuplanguagesupport? >>>>> >>>>> Hi, >>>>> >>>>> I agree that the ability for a client to request the >>>>> format of the recognizer result data content >>>>> > would be useful. > >>>>> >>>>> I would prefer to see this function defined in a >>>>> consistent manner with the current draft >>>>> > specification; by > >>>>> a client request to enable a session parameter via a >>>>> header (ie. "Result-Data-Type") in a SET-PARAMS or >>>>> RECOGNIZE request, rather than an attribute used for >>>>> RECOGNIZER session negotiation/update. The >>>>> > server should > >>>>> then respond with an accept or reject >>>>> > response as it does > >>>>> today for other client requested parameter values. >>>>> Currently, the draft specification doesn't >>>>> > expose the MRCP > >>>>> resource configurable parameters in the SDP. >>>>> >>>>> I don't think that enabling platform-specific formats >>>>> facilitates the adoption of a standard >>>>> > specification for > >>>>> speech resources. I believe that the >>>>> > specification should > >>>>> continue to address the required supported >>>>> > formats and > >>>>> require new draft iterations including the updated >>>>> specifications. The updated draft iterations would >>>>> continue to assist with potential client/server >>>>> interoperability issues. >>>>> >>>>> Thanks, >>>>> >>>>> Brett Gavagni >>>>> WebSphere Voice Server Development >>>>> >>>>> > http://www-306.ibm.com/software/pervasive/voice_server/ > >>>>> gavagni@us.ibm.com >>>>> >>>>> >>>>> >>>>> >>>>> Jerry Carter >>>>> Sent by: speechsc-bounces@ietf.org >>>>> 09/23/2005 11:42 PM >>>>> >>>>> To >>>>> Baggia Paolo cc >>>>> > "IETF SPEECHSC > >>>>> \(E-mail\)" Subject >>>>> Re: [Speechsc] EMMA: Extensible MultiModal Annotation >>>>> markuplanguagesupport? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I agree that minor changes made today will prevent >>>>> the need for an >>>>> amended document in the very near future. Providing >>>>> for content >>>>> negotiation solves both the EMMA issue and allows for >>>>> future or >>>>> platform-specific return formats without >>>>> > requiring that the > >>>>> specification be iterated. >>>>> >>>>> Of the two suggestions, I prefer the SDP >>>>> > extension as the > >>>>> return format >>>>> is analogous to other SIP media type negotiations. >>>>> >>>>> >>>>> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: >>>>> >>>>>> the last answers and discussions in this thread >>>>>> >>>>> seems to confirm >>>>> >>>>>> that the direction of MRCPv2 is to allow the use of >>>>>> >>>>> EMMA when >>>>> >>>>>> it will become a W3C Recommendation. Some text >>>>>> >>>>> should be added >>>>> >>>>>> in the future release to say that. >>>>>> This is fine from us point of view, but a mechanism >>>>>> >>>>> for asking >>>>> >>>>>> a different result format is not present in the >>>>>> >>>>> current draft. >>>>> >>>>>> >>>>>> We think to add that mechanism will allow a smooth >>>>>> >>>>> transition >>>>> >>>>>> from the current situation: always result in >>>>>> >>>>> "application/nlsml+xml", >>>>> >>>>>> to a future one with results in EMMA. >>>>>> >>>>>> Would it be possible to consider this "negotiation" >>>>>> >>>>> of the output >>>>> >>>>>> result in the next draft? >>>>>> >>>>>> There are different options to implement it: >>>>>> a) to extend SDP to leave taht outside of MRCPv2 >>>>>> >>>>> core protocol >>>>> >>>>>> E.g. >>>>>> a=recogResultFormat:application/nlsml+xml >>>>>> if present it sets the recognition result >>>>>> > for a whole MRCP > >>>>>> session. >>>>>> >>>>>> b) to add a new recognizer header to set >>>>>> > the result format > >>>>>> for that specific recognition turn. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> We are aware the draft is near to be closed, but we >>>>>> >>>>> think this >>>>> >>>>>> will help the passage from NLSML to EMMA. >>>>>> >>>>>> Regards, >>>>>> Paolo Baggia, Vittorio Manzone, Patrizio Bergallo >>>>>> >>>>> (Loquendo) >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >> >> > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 19 15:53:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJzz-0003QG-JV; Wed, 19 Oct 2005 15:53:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJzx-0003Q8-Pp for speechsc@megatron.ietf.org; Wed, 19 Oct 2005 15:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09813 for ; Wed, 19 Oct 2005 15:53:07 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESKBk-0006t7-EF for speechsc@ietf.org; Wed, 19 Oct 2005 16:05:29 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2005 12:53:08 -0700 X-IronPort-AV: i="3.97,231,1125903600"; d="scan'208"; a="667603175:sNHT43997978" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9JJr4Jh000410; Wed, 19 Oct 2005 12:53:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 12:53:03 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C6770B9@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXU48h3UCNsFX9kSE+tv4ELYTnnOgAAmFBA From: "Shanmugham, Saravanan" To: "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger , Andrew Wahbe , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org -----Original Message----- From: David R Oran [mailto:oran@cisco.com]=20 Sent: Wednesday, October 19, 2005 12:32 PM To: Shanmugham, Saravanan Cc: Dave Burke; Andrew Wahbe; IETF SPEECHSC (E-mail); Eric Burger Subject: Re: Question on negotiating EMMA (was RE:=20 [Speechsc]=20 EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 =20 On Oct 19, 2005, at 1:30 PM, Shanmugham, Saravanan wrote: =20 > Discovery for MRCPv2 capabilities in general is through=20 SIP options as=20 > described in Section 7 of the draft. > > On the topic of EMMA/NLSML. > > After reading some of the emails. I am rethinking my previous=20 > acceptance of Eric's SIP Accept idea. > > I think his alternate suggestion of making it part of=20 the SDP for the=20 > session makes more sense for the following reasons. > > 1. It works well with the above discovery mechanism=20 which describe=20 > capabilities through SDP. > 2. It works for routing as such a proxy can take look=20 at the SDP to=20 > make this decision. Really? What if it's SMIME encrypted. i would council=20 against putting anythng needed for deciding which server=20 to contact or how to route the request into the SDP. =20 > 3. A routing proxy would any way have to look at the=20 SDP for other=20 > things such as resource type. If so, we've probably made a design error and should have=20 it in SIP caller prefs instead. Today the SDP contains the information as to what resource-type control channels are to be established. This is need to establish control channels to specific reources. That seems to be the right thing to do. The question is should we also rely on this piece of information in the SDP for routing of the INVITE. =20 Sarvi =20 > 4. It also allows this to be negotiated during Session Setup=20 > through the INVITE offer answer model. > That is true. =20 > I would also suggest that we still add the Accept Header=20 similar to=20 > HTTP into MRCP messages to be used in messages like,=20 SET-PARAMS, GET-=20 > PARAMS, RECOGNIZE, INTERPRET as well. This allows us to=20 change format=20 > for individual requests or the session as necessry if=20 the resource=20 > supports more than one format. > > Sarvi > > > > -----Original Message----- > From: Dave Burke [mailto:david.burke@voxpilot.com] > Sent: Wednesday, October 19, 2005 10:12 AM > To: Andrew Wahbe > Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan;=20 Eric Burger > Subject: Re: Question on negotiating EMMA (was RE: > [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > There is certainly a general question of how an MRCP > server advertises capabilities and how the client requests > particular capabilities. I do, however, believe that > MRCP's choice of SIP for discovery and rendevous will > still prove wise. The mechanism for capability > advertisement and specification might be best delegated to > a separate draft at this point in MRCP's development. For > now we've got DNS SRV (a given AOR can indicate a > particular capability set e.g. vendorx.en.example.com). > > As far as mechanisms are considered, I'm still not keen on > using SDP. A "pure" SIP proxy (as defined in RFC 3261) > will not work by analysing SDP. > Nor will registering an MRCP server capability set (since > REGISTER does not contain SDP and it's Accept / Allow > headers relate to the response to the REGISTER). That > leaves headers: one framework that could be considered is > based on RFC 3840/3841. For example, a speechrecog does a > register: > > REGISTER sip:example.com > To: asr@example.com > Contact:=20 ;language=3D"en";reco-result-format=3D"EMMA" > > An MRCP client looking for an ASR engine supporting EMMA > and English places the following request to a proxy. > > INVITE sip:asr@example.com > Accept-Contact: = *;reco-result-format=3D"EMMA";language=3D"en" > > The OPTIONS method (already mentioned in MRCPv2) can also > be used (it returns the Contact header with the feature > parameters). > > Dave > > ----- Original Message ----- > From: "Andrew Wahbe" > To: "Andrew Wahbe" > Cc: "Dave Burke" ; "IETF > SPEECHSC (E-mail)" > ; "Shanmugham, Saravanan" > ; "Eric Burger" > Sent: Wednesday, October 19, 2005 4:18 PM > Subject: Re: Question on negotiating EMMA (was RE:=20 [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > >> On reading my own response I realized that a re-invite >> > wouldn't work > >> with a proxy. oops. (please hold back your comments ;-). >> > I don't think > >> this changes my point though. >> >> Andrew >> >> Andrew Wahbe wrote: >> >> >>> The question is whether you want the client to know >>> > which homogeneous > >>> set to use, or if you want a proxy to do it for you. If >>> > you want a > >>> proxy to be able to do this for you then you want it in >>> > the SDP (or > >>> perhaps a SIP header but I'd prefer SDP) wouldn't you? >>> >>> Also note that things like the required language(s) can >>> > change over > >>> the course of one call. You could update your SDP and >>> > ReInvite in > >>> this case (and the proxy would find an appropriate >>> > server) or (if it > >>> is client driven) you could switch over to another >>> > homogeneous set. > >>> >>> I thought that advertising your needs and capabilities >>> > in session > >>> establishment so that you could be connected to a >>> > compatible server > >>> was a big part of the point in using SIP here. If we >>> > resort to saying > >>> that "network administrators should know how to load >>> > balance this > >>> properly", can't we also say that "network >>> > administrators should > >>> configure everything to use the same codec" etc? >>> >>> Having said that, I think that one could still argue >>> > that the emma vs > >>> nlsml support is a stretch for session establishment... >>> > its some of > >>> the other examples you gave that I have issue with. I >>> > hope we don't > >>> rule these out. I haven't brought this up earlier >>> > because I seem to > >>> remember someone saying that this sort of thing could >>> > be the subject > >>> of another separate RFC (SDP to describe MRCP resource >>> > capabilities). > >>> >>> Andrew >>> >>> Dave Burke wrote: >>> >>> >>>> I have to side with Brett here. >>>> >>>> The reality is that there are plenty of things that >>>> > the client may > >>>> find out about the server "too late". Here are the >>>> > ones that will > >>>> undoubtedly happen in practice: >>>> - a given language not supported >>>> - a given semantic interpretation format within the >>>> > SRGS s > >>>> not supported >>>> - speech enrollment not supported >>>> >>>> In practice, a client will know the vendor of the >>>> > speech resource > >>>> servers identified by a SIP URI and will know what to expect;=20 >>>> network administrators will know not to load balance / >>>> > failover a > >>>> hetergeonous vendor set. >>>> >>>> It seems much cleaner to use Accept on the RECOGNIZE >>>> > request so the > >>>> server knows the format(s) to use for the >>>> > RECOGNITION-COMPLETE final > >>>> response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. >>>> >>>> Dave >>>> >>>> ----- Original Message ----- From: "Brett Gavagni" >>>> >>>> To: "Eric Burger" >>>> Cc: "IETF SPEECHSC (E-mail)" ;=20 "Shanmugham,=20 >>>> Saravanan" >>>> Sent: Wednesday, October 19, 2005 11:31 AM >>>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] >>>> EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>> >>>> >>>> >>>>> I not too thrilled with the implication of leaking more MRCP=20 >>>>> Application parameters into SDP, which could be possibly=20 >>>>> considered outside the scope of resource session >>>>> > establishment,. > >>>>> This could potentially end up complicating interoperability=20 >>>>> scenarios. >>>>> >>>>> Thanks, >>>>> >>>>> Brett Gavagni >>>>> WebSphere Voice Server Development=20 >>>>> http://www-306.ibm.com/software/pervasive/voice_server/ >>>>> gavagni@us.ibm.com >>>>> >>>>> >>>>> >>>>> >>>>> "Eric Burger" >>>>> 10/18/2005 10:48 PM >>>>> >>>>> To >>>>> "Shanmugham, Saravanan" , Brett >>>>> > Gavagni/West Palm > >>>>> Beach/IBM@IBMUS cc "IETF SPEECHSC \(E-mail\)" >>>>> > > >>>>> Subject >>>>> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: >>>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Fine with me, so long as server can reject and client >>>>> > can handle > >>>>> situation where I ask for only NLSML in SIP >>>>> > negotiation and then I > >>>>> ask for EMMA and the server doesn't handle it. >>>>> >>>>> -----Original Message----- >>>>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] >>>>> Sent: Tue Oct 18 20:57:20 2005 >>>>> To: Eric Burger; Brett Gavagni >>>>> Cc: IETF SPEECHSC (E-mail) >>>>> Subject: RE: Question on negotiating EMMA (was >>>>> > RE: [Speechsc] > >>>>> EMMA: >>>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) >>>>> >>>>> I suggest that we do both. >>>>> The SIP Alow/Accept header during MRCP session setup >>>>> > for server > >>>>> discovery and routing. >>>>> We then add support for the Accept header in MRCPv2 >>>>> > messages. I > >>>>> suspect this will be initially only used for >>>>> > RECOGNIZE/SET-PARAMS/GET-PARAMS. > >>>>> And can be used in the case where the client or the >>>>> > server can do both. > >>>>> >>>>> What do you think. >>>>> >>>>> Sarvi >>>>> >>>>> -----Original Message----- >>>>> From: Eric Burger [mailto:eburger@brooktrout.com] >>>>> Sent: Monday, October 17, 2005 1:52 PM >>>>> To: Shanmugham, Saravanan; Brett Gavagni >>>>> Cc: IETF SPEECHSC (E-mail) >>>>> Subject: Question on negotiating EMMA (was RE: [Speechsc] >>>>> EMMA: >>>>> > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>>> >>>>> My logic, which may be flawed, is that we want to be able >>>>> to achieve these objectives. >>>>> o Ensure the trivial ability to negotiate other result >>>>> formats, such as EMMA. >>>>> o Ensure the server knows what format the=20 client wants. >>>>> o Ensure the client knows the server supports >>>>> > the format > >>>>> the client wants, before it is "too late". >>>>> >>>>> I would offer that using SET-PARAMS is "too=20 late", in that >>>>> the client and server has already spent the effort to >>>>> establish the RTP sessions. >>>>> It would be a pity to then tear it all down when the >>>>> client finds out the server does not support the >>>>> > format of choice. > >>>>> >>>>> One can negotiating the format at session establishment >>>>> time with SDP >>>>> (a=3Dresultformat:application/emma-xml) or with SIP >>>>> (Allow/Accept). I would offer that it is easier to >>>>> implement, and makes MRCPv2 (SIP) proxies easier if we do >>>>> the negotiation at the SIP level. For example, if a >>>>> client wants results in EMMA, a MRCPv2 proxy can=20 route the >>>>> request to a server that supports EMMA by inspecting the >>>>> SIP headers, rather than having to dive in to the SDP. >>>>> >>>>> While the preceding paragraph indicates my preference for >>>>> using the SIP negotiation mechanism, there still is the >>>>> case where both the client and server support >>>>> > NLSML and EMMA. > >>>>> >>>>> ++++ THE QUESTION ++++ >>>>> Is there a realistic use case where the client, in any >>>>> given session, would want to use multiple result formats? >>>>> That is, something like, "RECOGNIZE this and give me the >>>>> result in EMMA" and then later issue something like, >>>>> "RECOGNIZE that and give me the result in NLSML"? >>>>> >>>>> If so, then we would *also* need a per-recognition / >>>>> SET-PARAMS header for the result type. >>>>> >>>>> -----Original Message----- >>>>> From: speechsc-bounces@ietf.org >>>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of >>>>> Shanmugham, Saravanan >>>>> Sent: Wednesday, September 28, 2005 2:36 PM >>>>> To: Brett Gavagni; Jerry Carter >>>>> Cc: IETF SPEECHSC (E-mail); >>>>> > speechsc-bounces@ietf.org; Baggia Paolo > >>>>> Subject: RE: [Speechsc] EMMA: >>>>> ExtensibleMultiModalAnnotation markuplanguagesupport? >>>>> >>>>> Would something like the HTTP "Accept" header address >>>>> these and other similar concerns. >>>>> The RECOGNIZE request can then carry this header in it to >>>>> specify an alternative to NLSML. >>>>> >>>>> Sarvi >>>>> >>>>> -----Original Message----- >>>>> From: speechsc-bounces@ietf.org >>>>> [mailto:speechsc-bounces@ietf.org] On Behalf >>>>> > Of Brett Gavagni > >>>>> Sent: Saturday, September 24, 2005 7:51 AM >>>>> To: Jerry Carter >>>>> Cc: IETF SPEECHSC (E-mail); >>>>> speechsc-bounces@ietf.org; Baggia Paolo >>>>> Subject: Re: [Speechsc] EMMA: Extensible >>>>> MultiModalAnnotation markuplanguagesupport? >>>>> >>>>> Hi, >>>>> >>>>> I agree that the ability for a client to request the >>>>> format of the recognizer result data content >>>>> > would be useful. > >>>>> >>>>> I would prefer to see this function defined in a >>>>> consistent manner with the current draft >>>>> > specification; by > >>>>> a client request to enable a session parameter via a >>>>> header (ie. "Result-Data-Type") in a SET-PARAMS or >>>>> RECOGNIZE request, rather than an attribute used for >>>>> RECOGNIZER session negotiation/update. The >>>>> > server should > >>>>> then respond with an accept or reject >>>>> > response as it does > >>>>> today for other client requested parameter values. >>>>> Currently, the draft specification doesn't >>>>> > expose the MRCP > >>>>> resource configurable parameters in the SDP. >>>>> >>>>> I don't think that enabling=20 platform-specific formats >>>>> facilitates the adoption of a standard >>>>> > specification for > >>>>> speech resources. I believe that the >>>>> > specification should > >>>>> continue to address the required supported >>>>> > formats and > >>>>> require new draft iterations including the updated >>>>> specifications. The updated draft iterations would >>>>> continue to assist with potential client/server >>>>> interoperability issues. >>>>> >>>>> Thanks, >>>>> >>>>> Brett Gavagni >>>>> WebSphere Voice Server Development >>>>> >>>>> > http://www-306.ibm.com/software/pervasive/voice_server/ > >>>>> gavagni@us.ibm.com >>>>> >>>>> >>>>> >>>>> >>>>> Jerry Carter >>>>> Sent by: speechsc-bounces@ietf.org >>>>> 09/23/2005 11:42 PM >>>>> >>>>> To >>>>> Baggia Paolo cc >>>>> > "IETF SPEECHSC > >>>>> \(E-mail\)" Subject >>>>> Re: [Speechsc] EMMA: Extensible MultiModal=20 Annotation >>>>> markuplanguagesupport? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I agree that minor changes made today will prevent >>>>> the need for an >>>>> amended document in the very near future. Providing >>>>> for content >>>>> negotiation solves both the EMMA issue and=20 allows for >>>>> future or >>>>> platform-specific return formats without >>>>> > requiring that the > >>>>> specification be iterated. >>>>> >>>>> Of the two suggestions, I prefer the SDP >>>>> > extension as the > >>>>> return format >>>>> is analogous to other SIP media type negotiations. >>>>> >>>>> >>>>> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: >>>>> >>>>>> the last answers and discussions in this thread >>>>>> >>>>> seems to confirm >>>>> >>>>>> that the direction of MRCPv2 is to allow the use of >>>>>> >>>>> EMMA when >>>>> >>>>>> it will become a W3C Recommendation. Some text >>>>>> >>>>> should be added >>>>> >>>>>> in the future release to say that. >>>>>> This is fine from us point of view, but a mechanism >>>>>> >>>>> for asking >>>>> >>>>>> a different result format is not present in the >>>>>> >>>>> current draft. >>>>> >>>>>> >>>>>> We think to add that mechanism will allow a smooth >>>>>> >>>>> transition >>>>> >>>>>> from the current situation: always result in >>>>>> >>>>> "application/nlsml+xml", >>>>> >>>>>> to a future one with results in EMMA. >>>>>> >>>>>> Would it be possible to consider this "negotiation" >>>>>> >>>>> of the output >>>>> >>>>>> result in the next draft? >>>>>> >>>>>> There are different options to implement it: >>>>>> a) to extend SDP to leave taht outside of MRCPv2 >>>>>> >>>>> core protocol >>>>> >>>>>> E.g. >>>>>> a=3DrecogResultFormat:application/nlsml+xml >>>>>> if present it sets the recognition result >>>>>> > for a whole MRCP > >>>>>> session. >>>>>> >>>>>> b) to add a new recognizer header to set >>>>>> > the result format > >>>>>> for that specific recognition turn. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> We are aware the draft is near to be closed, but we >>>>>> >>>>> think this >>>>> >>>>>> will help the passage from NLSML to EMMA. >>>>>> >>>>>> Regards, >>>>>> Paolo Baggia, Vittorio Manzone, Patrizio Bergallo >>>>>> >>>>> (Loquendo) >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speechsc mailing list >>>>> Speechsc@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Speechsc mailing list >>>> Speechsc@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speechsc >>>> >>>> >>>> >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speechsc >>> >>> >>> >> >> > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Oct 20 02:26:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTsn-0007eP-Ig; Thu, 20 Oct 2005 02:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTsj-0007eE-GT for speechsc@megatron.ietf.org; Thu, 20 Oct 2005 02:26:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14774 for ; Thu, 20 Oct 2005 02:26:15 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESU4X-0002Ja-Fs for speechsc@ietf.org; Thu, 20 Oct 2005 02:38:42 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0ION00H2TB7MOZ@dns1.cselt.it> for speechsc@ietf.org; Thu, 20 Oct 2005 08:26:10 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 08:26:09 +0200 Date: Thu, 20 Oct 2005 08:25:44 +0200 From: Bergallo Patrizio Subject: RE: Question on negotiating EMMA (was RE: [Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) To: "Shanmugham, Saravanan" , Dave Burke , Andrew Wahbe Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXU0F47WmfPx0agR6alHID1xnH0iQAAUBTQABs+MIA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 20 Oct 2005 06:26:10.0005 (UTC) FILETIME=[2927B050:01C5D53F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org > I would also suggest that we still add the Accept Header=20 > similar to HTTP into MRCP messages to be used in messages=20 > like, SET-PARAMS, GET-PARAMS, RECOGNIZE, INTERPRET as well.=20 > This allows us to change format for individual requests or=20 > the session as necessry if the resource supports more than one format. >=20 > Sarvi I think that the Accept Header is useful in the GET-RESULT message too. Do you agree? Patrizio. >=20 >=20 >=20 > -----Original Message----- > From: Dave Burke [mailto:david.burke@voxpilot.com]=20 > Sent: Wednesday, October 19, 2005 10:12 AM > To: Andrew Wahbe > Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan; Eric Burger > Subject: Re: Question on negotiating EMMA (was RE:=20 > [Speechsc]=20 > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > =20 > There is certainly a general question of how an MRCP=20 > server advertises capabilities and how the client requests=20 > particular capabilities. I do, however, believe that=20 > MRCP's choice of SIP for discovery and rendevous will=20 > still prove wise. The mechanism for capability=20 > advertisement and specification might be best delegated to=20 > a separate draft at this point in MRCP's development. For=20 > now we've got DNS SRV (a given AOR can indicate a=20 > particular capability set e.g. vendorx.en.example.com). > =20 > As far as mechanisms are considered, I'm still not keen on=20 > using SDP. A "pure" SIP proxy (as defined in RFC 3261)=20 > will not work by analysing SDP.=20 > Nor will registering an MRCP server capability set (since=20 > REGISTER does not contain SDP and it's Accept / Allow=20 > headers relate to the response to the REGISTER). That=20 > leaves headers: one framework that could be considered is=20 > based on RFC 3840/3841. For example, a speechrecog does=20 > a register: > =20 > REGISTER sip:example.com > To: asr@example.com > Contact: = ;language=3D"en";reco-result-format=3D"EMMA" > =20 > An MRCP client looking for an ASR engine supporting EMMA=20 > and English places the following request to a proxy. > =20 > INVITE sip:asr@example.com > Accept-Contact: *;reco-result-format=3D"EMMA";language=3D"en" > =20 > The OPTIONS method (already mentioned in MRCPv2) can also=20 > be used (it returns the Contact header with the feature=20 > parameters). > =20 > Dave > =20 > ----- Original Message ----- > From: "Andrew Wahbe" > To: "Andrew Wahbe" > Cc: "Dave Burke" ; "IETF=20 > SPEECHSC (E-mail)"=20 > ; "Shanmugham, Saravanan"=20 > ; "Eric Burger" > Sent: Wednesday, October 19, 2005 4:18 PM > Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > =20 > =20 > > On reading my own response I realized that a re-invite=20 > wouldn't work=20 > > with a proxy. oops. (please hold back your comments ;-).=20 > I don't think=20 > > this changes my point though. > > > > Andrew > > > > Andrew Wahbe wrote: > > > >> The question is whether you want the client to know=20 > which homogeneous=20 > >> set to use, or if you want a proxy to do it for you. If=20 > you want a=20 > >> proxy to be able to do this for you then you want it in=20 > the SDP (or=20 > >> perhaps a SIP header but I'd prefer SDP) wouldn't you? > >> > >> Also note that things like the required language(s) can=20 > change over=20 > >> the course of one call. You could update your SDP and=20 > ReInvite in=20 > >> this case (and the proxy would find an appropriate=20 > server) or (if it=20 > >> is client driven) you could switch over to another=20 > homogeneous set. > >> > >> I thought that advertising your needs and capabilities=20 > in session=20 > >> establishment so that you could be connected to a =20 > compatible server=20 > >> was a big part of the point in using SIP here. If we=20 > resort to saying=20 > >> that "network administrators should know how to load=20 > balance this=20 > >> properly", can't we also say that "network=20 > administrators should=20 > >> configure everything to use the same codec" etc? > >> > >> Having said that, I think that one could still argue=20 > that the emma vs=20 > >> nlsml support is a stretch for session establishment...=20 > its some of=20 > >> the other examples you gave that I have issue with. I=20 > hope we don't=20 > >> rule these out. I haven't brought this up earlier=20 > because I seem to=20 > >> remember someone saying that this sort of thing could=20 > be the subject=20 > >> of another separate RFC (SDP to describe MRCP resource=20 > capabilities). > >> > >> Andrew > >> > >> Dave Burke wrote: > >> > >>> I have to side with Brett here. > >>> > >>> The reality is that there are plenty of things that=20 > the client may=20 > >>> find out about the server "too late". Here are the=20 > ones that will=20 > >>> undoubtedly happen in practice: > >>> - a given language not supported > >>> - a given semantic interpretation format within the=20 > SRGS s=20 > >>> not supported > >>> - speech enrollment not supported > >>> > >>> In practice, a client will know the vendor of the=20 > speech resource=20 > >>> servers identified by a SIP URI and will know what=20 > to expect;=20 > >>> network administrators will know not to load balance /=20 > failover a=20 > >>> hetergeonous vendor set. > >>> > >>> It seems much cleaner to use Accept on the RECOGNIZE=20 > request so the=20 > >>> server knows the format(s) to use for the=20 > RECOGNITION-COMPLETE final=20 > >>> response. SET-OPTIONs/GET-OPTIONs can be used for stickyness. > >>> > >>> Dave > >>> > >>> ----- Original Message ----- From: "Brett Gavagni"=20 > >>> > >>> To: "Eric Burger" > >>> Cc: "IETF SPEECHSC (E-mail)" ;=20 > "Shanmugham,=20 > >>> Saravanan" > >>> Sent: Wednesday, October 19, 2005 11:31 AM > >>> Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] > >>> EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>> > >>> > >>>> I not too thrilled with the implication of leaking=20 > more MRCP=20 > >>>> Application parameters into SDP, which could be possibly=20 > >>>> considered outside the scope of resource session=20 > establishment,.=20 > >>>> This could potentially end up complicating interoperability=20 > >>>> scenarios. > >>>> > >>>> Thanks, > >>>> > >>>> Brett Gavagni > >>>> WebSphere Voice Server Development > >>>> http://www-306.ibm.com/software/pervasive/voice_server/ > >>>> gavagni@us.ibm.com > >>>> > >>>> > >>>> > >>>> > >>>> "Eric Burger" > >>>> 10/18/2005 10:48 PM > >>>> > >>>> To > >>>> "Shanmugham, Saravanan" , Brett=20 > Gavagni/West Palm=20 > >>>> Beach/IBM@IBMUS cc "IETF SPEECHSC \(E-mail\)"=20 > =20 > >>>> Subject > >>>> RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA: > >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Fine with me, so long as server can reject and client=20 > can handle=20 > >>>> situation where I ask for only NLSML in SIP=20 > negotiation and then I=20 > >>>> ask for EMMA and the server doesn't handle it. > >>>> > >>>> -----Original Message----- > >>>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > >>>> Sent: Tue Oct 18 20:57:20 2005 > >>>> To: Eric Burger; Brett Gavagni > >>>> Cc: IETF SPEECHSC (E-mail) > >>>> Subject: RE: Question on negotiating EMMA (was=20 > RE: [Speechsc] > >>>> EMMA: > >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>> > >>>> I suggest that we do both. > >>>> The SIP Alow/Accept header during MRCP session setup=20 > for server=20 > >>>> discovery and routing. > >>>> We then add support for the Accept header in MRCPv2=20 > messages. I=20 > >>>> suspect this will be initially only used for=20 > RECOGNIZE/SET-PARAMS/GET-PARAMS. > >>>> And can be used in the case where the client or the=20 > server can do both. > >>>> > >>>> What do you think. > >>>> > >>>> Sarvi > >>>> > >>>> -----Original Message----- > >>>> From: Eric Burger [mailto:eburger@brooktrout.com] > >>>> Sent: Monday, October 17, 2005 1:52 PM > >>>> To: Shanmugham, Saravanan; Brett Gavagni > >>>> Cc: IETF SPEECHSC (E-mail) > >>>> Subject: Question on negotiating EMMA (was RE:=20 > [Speechsc] > >>>> EMMA:=20 > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>> > >>>> My logic, which may be flawed, is that we want=20 > to be able > >>>> to achieve these objectives. > >>>> o Ensure the trivial ability to negotiate=20 > other result > >>>> formats, such as EMMA. > >>>> o Ensure the server knows what format the=20 > client wants. > >>>> o Ensure the client knows the server supports=20 > the format > >>>> the client wants, before it is "too late". > >>>> > >>>> I would offer that using SET-PARAMS is "too=20 > late", in that > >>>> the client and server has already spent the effort to > >>>> establish the RTP sessions. > >>>> It would be a pity to then tear it all down when the > >>>> client finds out the server does not support the=20 > format of choice. > >>>> > >>>> One can negotiating the format at session establishment > >>>> time with SDP > >>>> (a=3Dresultformat:application/emma-xml) or with SIP > >>>> (Allow/Accept). I would offer that it is easier to > >>>> implement, and makes MRCPv2 (SIP) proxies=20 > easier if we do > >>>> the negotiation at the SIP level. For example, if a > >>>> client wants results in EMMA, a MRCPv2 proxy=20 > can route the > >>>> request to a server that supports EMMA by inspecting the > >>>> SIP headers, rather than having to dive in to the SDP. > >>>> > >>>> While the preceding paragraph indicates my=20 > preference for > >>>> using the SIP negotiation mechanism, there still is the > >>>> case where both the client and server support=20 > NLSML and EMMA. > >>>> > >>>> ++++ THE QUESTION ++++ > >>>> Is there a realistic use case where the client, in any > >>>> given session, would want to use multiple=20 > result formats? > >>>> That is, something like, "RECOGNIZE this and give me the > >>>> result in EMMA" and then later issue something like, > >>>> "RECOGNIZE that and give me the result in NLSML"? > >>>> > >>>> If so, then we would *also* need a per-recognition / > >>>> SET-PARAMS header for the result type. > >>>> > >>>> -----Original Message----- > >>>> From: speechsc-bounces@ietf.org > >>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of > >>>> Shanmugham, Saravanan > >>>> Sent: Wednesday, September 28, 2005 2:36 PM > >>>> To: Brett Gavagni; Jerry Carter > >>>> Cc: IETF SPEECHSC (E-mail);=20 > speechsc-bounces@ietf.org; Baggia Paolo > >>>> Subject: RE: [Speechsc] EMMA: > >>>> ExtensibleMultiModalAnnotation markuplanguagesupport? > >>>> > >>>> Would something like the HTTP "Accept" header address > >>>> these and other similar concerns. > >>>> The RECOGNIZE request can then carry this=20 > header in it to > >>>> specify an alternative to NLSML. > >>>> > >>>> Sarvi > >>>> > >>>> -----Original Message----- > >>>> From: speechsc-bounces@ietf.org > >>>> [mailto:speechsc-bounces@ietf.org] On Behalf=20 > Of Brett Gavagni > >>>> Sent: Saturday, September 24, 2005 7:51 AM > >>>> To: Jerry Carter > >>>> Cc: IETF SPEECHSC (E-mail); > >>>> speechsc-bounces@ietf.org; Baggia Paolo > >>>> Subject: Re: [Speechsc] EMMA: Extensible > >>>> MultiModalAnnotation markuplanguagesupport? > >>>> > >>>> Hi, > >>>> > >>>> I agree that the ability for a client to=20 > request the > >>>> format of the recognizer result data content=20 > would be useful. > >>>> > >>>> I would prefer to see this function defined in a > >>>> consistent manner with the current draft=20 > specification; by > >>>> a client request to enable a session=20 > parameter via a > >>>> header (ie. "Result-Data-Type") in a SET-PARAMS or > >>>> RECOGNIZE request, rather than an=20 > attribute used for > >>>> RECOGNIZER session negotiation/update. The=20 > server should > >>>> then respond with an accept or reject=20 > response as it does > >>>> today for other client requested parameter values. > >>>> Currently, the draft specification doesn't=20 > expose the MRCP > >>>> resource configurable parameters in the SDP. > >>>> > >>>> I don't think that enabling=20 > platform-specific formats > >>>> facilitates the adoption of a standard=20 > specification for > >>>> speech resources. I believe that the=20 > specification should > >>>> continue to address the required supported=20 > formats and > >>>> require new draft iterations including the updated > >>>> specifications. The updated draft iterations would > >>>> continue to assist with potential client/server > >>>> interoperability issues. > >>>> > >>>> Thanks, > >>>> > >>>> Brett Gavagni > >>>> WebSphere Voice Server Development > >>>> =20 > http://www-306.ibm.com/software/pervasive/voice_server/ > >>>> gavagni@us.ibm.com > >>>> > >>>> > >>>> > >>>> > >>>> Jerry Carter > >>>> Sent by: speechsc-bounces@ietf.org > >>>> 09/23/2005 11:42 PM > >>>> > >>>> To > >>>> Baggia Paolo cc=20 > "IETF SPEECHSC > >>>> \(E-mail\)" Subject > >>>> Re: [Speechsc] EMMA: Extensible MultiModal=20 > Annotation > >>>> markuplanguagesupport? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> I agree that minor changes made today will prevent > >>>> the need for an > >>>> amended document in the very near future. =20 > Providing > >>>> for content > >>>> negotiation solves both the EMMA issue and=20 > allows for > >>>> future or > >>>> platform-specific return formats without=20 > requiring that the > >>>> specification be iterated. > >>>> > >>>> Of the two suggestions, I prefer the SDP=20 > extension as the > >>>> return format > >>>> is analogous to other SIP media type negotiations. > >>>> > >>>> > >>>> On Sep 23, 2005, at 4:55 AM, Baggia Paolo wrote: > >>>> > the last answers and discussions in this thread > >>>> seems to confirm > >>>> > that the direction of MRCPv2 is to allow=20 > the use of > >>>> EMMA when > >>>> > it will become a W3C Recommendation. Some text > >>>> should be added > >>>> > in the future release to say that. > >>>> > This is fine from us point of view, but=20 > a mechanism > >>>> for asking > >>>> > a different result format is not present in the > >>>> current draft. > >>>> > > >>>> > We think to add that mechanism will=20 > allow a smooth > >>>> transition > >>>> > from the current situation: always result in > >>>> "application/nlsml+xml", > >>>> > to a future one with results in EMMA. > >>>> > > >>>> > Would it be possible to consider this=20 > "negotiation" > >>>> of the output > >>>> > result in the next draft? > >>>> > > >>>> > There are different options to implement it: > >>>> > a) to extend SDP to leave taht outside of MRCPv2 > >>>> core protocol > >>>> > E.g. > >>>> > a=3DrecogResultFormat:application/nlsml+xml > >>>> > if present it sets the recognition result=20 > for a whole MRCP > >>>> > session. > >>>> > > >>>> > b) to add a new recognizer header to set=20 > the result format > >>>> > for that specific recognition turn. > >>>> > > >>>> > What do you think? > >>>> > > >>>> > We are aware the draft is near to be=20 > closed, but we > >>>> think this > >>>> > will help the passage from NLSML to EMMA. > >>>> > > >>>> > Regards, > >>>> > Paolo Baggia, Vittorio Manzone, Patrizio=20 > Bergallo=20 > >>>> (Loquendo) > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Speechsc mailing list > >>> Speechsc@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/speechsc > >>> > >>> > >>_______________________________________________ > >>Speechsc mailing list > >>Speechsc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/speechsc > >> > >> > >=20 > =20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Oct 20 02:34:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESU0F-0002Qg-Sr; Thu, 20 Oct 2005 02:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESU0E-0002Qb-43 for speechsc@megatron.ietf.org; Thu, 20 Oct 2005 02:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15040 for ; Thu, 20 Oct 2005 02:34:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESUC5-0002VY-Ev for speechsc@ietf.org; Thu, 20 Oct 2005 02:46:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 19 Oct 2005 23:34:03 -0700 X-IronPort-AV: i="3.97,235,1125903600"; d="scan'208"; a="354418491:sNHT32741476" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9K6XxUw001281; Wed, 19 Oct 2005 23:34:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE:[Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Wed, 19 Oct 2005 23:33:56 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C677162@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: Question on negotiating EMMA (was RE:[Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXU0F47WmfPx0agR6alHID1xnH0iQAAUBTQABs+MIAAAGh9MA== From: "Shanmugham, Saravanan" To: "Bergallo Patrizio" , "Dave Burke" , "Andrew Wahbe" X-Spam-Score: 0.0 (/) X-Scan-Signature: f45ea05559815d24dd3d462564224830 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Yup.=20 -----Original Message----- From: Bergallo Patrizio [mailto:Patrizio.Bergallo@LOQUENDO.COM]=20 Sent: Wednesday, October 19, 2005 11:26 PM To: Shanmugham, Saravanan; Dave Burke; Andrew Wahbe Cc: IETF SPEECHSC (E-mail); Eric Burger Subject: RE: Question on negotiating EMMA (was=20 RE:[Speechsc]EMMA:ExtensibleMultiModalAnnotationmarkuplangu agesupport?) =20 > I would also suggest that we still add the Accept Header=20 similar to=20 > HTTP into MRCP messages to be used in messages like, SET-PARAMS,=20 > GET-PARAMS, RECOGNIZE, INTERPRET as well. > This allows us to change format for individual requests=20 or the session=20 > as necessry if the resource supports more than one format. >=20 > Sarvi =20 I think that the Accept Header is useful in the GET-RESULT=20 message too. Do you agree? =20 Patrizio. =20 >=20 >=20 >=20 > -----Original Message----- > From: Dave Burke [mailto:david.burke@voxpilot.com]=20 > Sent: Wednesday, October 19, 2005 10:12 AM > To: Andrew Wahbe > Cc: IETF SPEECHSC (E-mail); Shanmugham, Saravanan;=20 Eric Burger > Subject: Re: Question on negotiating EMMA (was RE:=20 > [Speechsc]=20 > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > =20 > There is certainly a general question of how an MRCP=20 > server advertises capabilities and how the client requests=20 > particular capabilities. I do, however, believe that=20 > MRCP's choice of SIP for discovery and rendevous will=20 > still prove wise. The mechanism for capability=20 > advertisement and specification might be best delegated to=20 > a separate draft at this point in MRCP's development. For=20 > now we've got DNS SRV (a given AOR can indicate a=20 > particular capability set e.g. vendorx.en.example.com). > =20 > As far as mechanisms are considered, I'm still not keen on=20 > using SDP. A "pure" SIP proxy (as defined in RFC 3261)=20 > will not work by analysing SDP.=20 > Nor will registering an MRCP server capability set (since=20 > REGISTER does not contain SDP and it's Accept / Allow=20 > headers relate to the response to the REGISTER). That=20 > leaves headers: one framework that could be considered is=20 > based on RFC 3840/3841. For example, a speechrecog does a=20 > register: > =20 > REGISTER sip:example.com > To: asr@example.com > Contact:=20 ;language=3D"en";reco-result-format=3D"EMMA" > =20 > An MRCP client looking for an ASR engine supporting EMMA=20 > and English places the following request to a proxy. > =20 > INVITE sip:asr@example.com > Accept-Contact: = *;reco-result-format=3D"EMMA";language=3D"en" > =20 > The OPTIONS method (already mentioned in MRCPv2) can also=20 > be used (it returns the Contact header with the feature=20 > parameters). > =20 > Dave > =20 > ----- Original Message ----- > From: "Andrew Wahbe" > To: "Andrew Wahbe" > Cc: "Dave Burke" ; "IETF=20 > SPEECHSC (E-mail)"=20 > ; "Shanmugham, Saravanan"=20 > ; "Eric Burger" > Sent: Wednesday, October 19, 2005 4:18 PM > Subject: Re: Question on negotiating EMMA (was RE:=20 [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > =20 > =20 > > On reading my own response I realized that a re-invite=20 > wouldn't work=20 > > with a proxy. oops. (please hold back your comments ;-).=20 > I don't think=20 > > this changes my point though. > > > > Andrew > > > > Andrew Wahbe wrote: > > > >> The question is whether you want the client to know=20 > which homogeneous=20 > >> set to use, or if you want a proxy to do it for you. If=20 > you want a=20 > >> proxy to be able to do this for you then you want it in=20 > the SDP (or=20 > >> perhaps a SIP header but I'd prefer SDP) wouldn't you? > >> > >> Also note that things like the required language(s) can=20 > change over=20 > >> the course of one call. You could update your SDP and=20 > ReInvite in=20 > >> this case (and the proxy would find an appropriate=20 > server) or (if it=20 > >> is client driven) you could switch over to another=20 > homogeneous set. > >> > >> I thought that advertising your needs and capabilities=20 > in session=20 > >> establishment so that you could be connected to a =20 > compatible server=20 > >> was a big part of the point in using SIP here. If we=20 > resort to saying=20 > >> that "network administrators should know how to load=20 > balance this=20 > >> properly", can't we also say that "network=20 > administrators should=20 > >> configure everything to use the same codec" etc? > >> > >> Having said that, I think that one could still argue=20 > that the emma vs=20 > >> nlsml support is a stretch for session establishment...=20 > its some of=20 > >> the other examples you gave that I have issue with. I=20 > hope we don't=20 > >> rule these out. I haven't brought this up earlier=20 > because I seem to=20 > >> remember someone saying that this sort of thing could=20 > be the subject=20 > >> of another separate RFC (SDP to describe MRCP resource=20 > capabilities). > >> > >> Andrew > >> > >> Dave Burke wrote: > >> > >>> I have to side with Brett here. > >>> > >>> The reality is that there are plenty of things that=20 > the client may=20 > >>> find out about the server "too late". Here are the=20 > ones that will=20 > >>> undoubtedly happen in practice: > >>> - a given language not supported > >>> - a given semantic interpretation format within the=20 > SRGS s=20 > >>> not supported > >>> - speech enrollment not supported > >>> > >>> In practice, a client will know the vendor of the=20 > speech resource=20 > >>> servers identified by a SIP URI and will know=20 what to expect; > >>> network administrators will know not to load balance /=20 > failover a=20 > >>> hetergeonous vendor set. > >>> > >>> It seems much cleaner to use Accept on the RECOGNIZE=20 > request so the=20 > >>> server knows the format(s) to use for the=20 > RECOGNITION-COMPLETE final=20 > >>> response. SET-OPTIONs/GET-OPTIONs can be used=20 for stickyness. > >>> > >>> Dave > >>> > >>> ----- Original Message ----- From: "Brett Gavagni"=20 > >>> > >>> To: "Eric Burger" > >>> Cc: "IETF SPEECHSC (E-mail)" ;=20 > "Shanmugham, > >>> Saravanan" > >>> Sent: Wednesday, October 19, 2005 11:31 AM > >>> Subject: RE: Question on negotiating EMMA (was=20 RE: [Speechsc] > >>>=20 EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>> > >>> > >>>> I not too thrilled with the implication of=20 leaking more MRCP > >>>> Application parameters into SDP, which could=20 be possibly=20 > >>>> considered outside the scope of resource session=20 > establishment,.=20 > >>>> This could potentially end up complicating=20 interoperability=20 > >>>> scenarios. > >>>> > >>>> Thanks, > >>>> > >>>> Brett Gavagni > >>>> WebSphere Voice Server Development > >>>> http://www-306.ibm.com/software/pervasive/voice_server/ > >>>> gavagni@us.ibm.com > >>>> > >>>> > >>>> > >>>> > >>>> "Eric Burger" > >>>> 10/18/2005 10:48 PM > >>>> > >>>> To > >>>> "Shanmugham, Saravanan" , Brett=20 > Gavagni/West Palm=20 > >>>> Beach/IBM@IBMUS cc "IETF SPEECHSC \(E-mail\)"=20 > =20 > >>>> Subject > >>>> RE: Question on negotiating EMMA (was RE:=20 [Speechsc] EMMA: > >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Fine with me, so long as server can reject and client=20 > can handle=20 > >>>> situation where I ask for only NLSML in SIP=20 > negotiation and then I=20 > >>>> ask for EMMA and the server doesn't handle it. > >>>> > >>>> -----Original Message----- > >>>> From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] > >>>> Sent: Tue Oct 18 20:57:20 2005 > >>>> To: Eric Burger; Brett Gavagni > >>>> Cc: IETF SPEECHSC (E-mail) > >>>> Subject: RE: Question on negotiating EMMA (was=20 > RE: [Speechsc] > >>>> EMMA: > >>>> ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>> > >>>> I suggest that we do both. > >>>> The SIP Alow/Accept header during MRCP session setup=20 > for server=20 > >>>> discovery and routing. > >>>> We then add support for the Accept header in MRCPv2=20 > messages. I=20 > >>>> suspect this will be initially only used for=20 > RECOGNIZE/SET-PARAMS/GET-PARAMS. > >>>> And can be used in the case where the client or the=20 > server can do both. > >>>> > >>>> What do you think. > >>>> > >>>> Sarvi > >>>> > >>>> -----Original Message----- > >>>> From: Eric Burger [mailto:eburger@brooktrout.com] > >>>> Sent: Monday, October 17, 2005 1:52 PM > >>>> To: Shanmugham, Saravanan; Brett Gavagni > >>>> Cc: IETF SPEECHSC (E-mail) > >>>> Subject: Question on negotiating EMMA (was RE:=20 > [Speechsc] > >>>> EMMA:=20 > ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > >>>> > >>>> My logic, which may be flawed, is that we want=20 > to be able > >>>> to achieve these objectives. > >>>> o Ensure the trivial ability to negotiate=20 > other result > >>>> formats, such as EMMA. > >>>> o Ensure the server knows what format the=20 > client wants. > >>>> o Ensure the client knows the server supports=20 > the format > >>>> the client wants, before it is "too late". > >>>> > >>>> I would offer that using SET-PARAMS is "too=20 > late", in that > >>>> the client and server has already spent=20 the effort to > >>>> establish the RTP sessions. > >>>> It would be a pity to then tear it all=20 down when the > >>>> client finds out the server does not support the=20 > format of choice. > >>>> > >>>> One can negotiating the format at session=20 establishment > >>>> time with SDP > >>>> (a=3Dresultformat:application/emma-xml) or with SIP > >>>> (Allow/Accept). I would offer that it is easier to > >>>> implement, and makes MRCPv2 (SIP) proxies=20 > easier if we do > >>>> the negotiation at the SIP level. For=20 example, if a > >>>> client wants results in EMMA, a MRCPv2 proxy=20 > can route the > >>>> request to a server that supports EMMA by=20 inspecting the > >>>> SIP headers, rather than having to dive in=20 to the SDP. > >>>> > >>>> While the preceding paragraph indicates my=20 > preference for > >>>> using the SIP negotiation mechanism, there=20 still is the > >>>> case where both the client and server support=20 > NLSML and EMMA. > >>>> > >>>> ++++ THE QUESTION ++++ > >>>> Is there a realistic use case where the=20 client, in any > >>>> given session, would want to use multiple=20 > result formats? > >>>> That is, something like, "RECOGNIZE this=20 and give me the > >>>> result in EMMA" and then later issue=20 something like, > >>>> "RECOGNIZE that and give me the result in NLSML"? > >>>> > >>>> If so, then we would *also* need a=20 per-recognition / > >>>> SET-PARAMS header for the result type. > >>>> > >>>> -----Original Message----- > >>>> From: speechsc-bounces@ietf.org > >>>> [mailto:speechsc-bounces@ietf.org] On Behalf Of > >>>> Shanmugham, Saravanan > >>>> Sent: Wednesday, September 28, 2005 2:36 PM > >>>> To: Brett Gavagni; Jerry Carter > >>>> Cc: IETF SPEECHSC (E-mail);=20 > speechsc-bounces@ietf.org; Baggia Paolo > >>>> Subject: RE: [Speechsc] EMMA: > >>>> ExtensibleMultiModalAnnotation=20 markuplanguagesupport? > >>>> > >>>> Would something like the HTTP "Accept"=20 header address > >>>> these and other similar concerns. > >>>> The RECOGNIZE request can then carry this=20 > header in it to > >>>> specify an alternative to NLSML. > >>>> > >>>> Sarvi > >>>> > >>>> -----Original Message----- > >>>> From: speechsc-bounces@ietf.org > >>>> [mailto:speechsc-bounces@ietf.org] On Behalf=20 > Of Brett Gavagni > >>>> Sent: Saturday, September 24, 2005 7:51 AM > >>>> To: Jerry Carter > >>>> Cc: IETF SPEECHSC (E-mail); > >>>> speechsc-bounces@ietf.org; Baggia Paolo > >>>> Subject: Re: [Speechsc] EMMA: Extensible > >>>> MultiModalAnnotation markuplanguagesupport? > >>>> > >>>> Hi, > >>>> > >>>> I agree that the ability for a client to=20 > request the > >>>> format of the recognizer result data content=20 > would be useful. > >>>> > >>>> I would prefer to see this function=20 defined in a > >>>> consistent manner with the current draft=20 > specification; by > >>>> a client request to enable a session=20 > parameter via a > >>>> header (ie. "Result-Data-Type") in a=20 SET-PARAMS or > >>>> RECOGNIZE request, rather than an=20 > attribute used for > >>>> RECOGNIZER session negotiation/update. The=20 > server should > >>>> then respond with an accept or reject=20 > response as it does > >>>> today for other client requested=20 parameter values. > >>>> Currently, the draft specification doesn't=20 > expose the MRCP > >>>> resource configurable parameters in the SDP. > >>>> > >>>> I don't think that enabling=20 > platform-specific formats > >>>> facilitates the adoption of a standard=20 > specification for > >>>> speech resources. I believe that the=20 > specification should > >>>> continue to address the required supported=20 > formats and > >>>> require new draft iterations=20 including the updated > >>>> specifications. The updated draft=20 iterations would > >>>> continue to assist with potential=20 client/server > >>>> interoperability issues. > >>>> > >>>> Thanks, > >>>> > >>>> Brett Gavagni > >>>> WebSphere Voice Server Development > >>>> =20 > http://www-306.ibm.com/software/pervasive/voice_server/ > >>>> gavagni@us.ibm.com > >>>> > >>>> > >>>> > >>>> > >>>> Jerry Carter > >>>> Sent by: speechsc-bounces@ietf.org > >>>> 09/23/2005 11:42 PM > >>>> > >>>> To > >>>> Baggia Paolo cc=20 > "IETF SPEECHSC > >>>> \(E-mail\)" Subject > >>>> Re: [Speechsc] EMMA: Extensible MultiModal=20 > Annotation > >>>> markuplanguagesupport? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> I agree that minor changes made today=20 will prevent > >>>> the need for an > >>>> amended document in the very near future. =20 > Providing > >>>> for content > >>>> negotiation solves both the EMMA issue and=20 > allows for > >>>> future or > >>>> platform-specific return formats without=20 > requiring that the > >>>> specification be iterated. > >>>> > >>>> Of the two suggestions, I prefer the SDP=20 > extension as the > >>>> return format > >>>> is analogous to other SIP media type=20 negotiations. > >>>> > >>>> > >>>> On Sep 23, 2005, at 4:55 AM, Baggia=20 Paolo wrote: > >>>> > the last answers and discussions in=20 this thread > >>>> seems to confirm > >>>> > that the direction of MRCPv2 is to allow=20 > the use of > >>>> EMMA when > >>>> > it will become a W3C=20 Recommendation. Some text > >>>> should be added > >>>> > in the future release to say that. > >>>> > This is fine from us point of view, but=20 > a mechanism > >>>> for asking > >>>> > a different result format is not=20 present in the > >>>> current draft. > >>>> > > >>>> > We think to add that mechanism will=20 > allow a smooth > >>>> transition > >>>> > from the current situation: always result in > >>>> "application/nlsml+xml", > >>>> > to a future one with results in EMMA. > >>>> > > >>>> > Would it be possible to consider this=20 > "negotiation" > >>>> of the output > >>>> > result in the next draft? > >>>> > > >>>> > There are different options to implement it: > >>>> > a) to extend SDP to leave taht=20 outside of MRCPv2 > >>>> core protocol > >>>> > E.g. > >>>> > a=3DrecogResultFormat:application/nlsml+xml > >>>> > if present it sets the recognition result=20 > for a whole MRCP > >>>> > session. > >>>> > > >>>> > b) to add a new recognizer header to set=20 > the result format > >>>> > for that specific recognition turn. > >>>> > > >>>> > What do you think? > >>>> > > >>>> > We are aware the draft is near to be=20 > closed, but we > >>>> think this > >>>> > will help the passage from NLSML to EMMA. > >>>> > > >>>> > Regards, > >>>> > Paolo Baggia, Vittorio Manzone, Patrizio=20 > Bergallo=20 > >>>> (Loquendo) > >>>> > >>>> > >>>> =20 _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> =20 https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>>> > >>>> > >>>> =20 _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> =20 https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speechsc mailing list > >>>> Speechsc@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speechsc > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Speechsc mailing list > >>> Speechsc@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/speechsc > >>> > >>> > >>_______________________________________________ > >>Speechsc mailing list > >>Speechsc@ietf.org > >>https://www1.ietf.org/mailman/listinfo/speechsc > >> > >> > > > =20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc >=20 =20 =20 Gruppo Telecom Italia - Direzione e coordinamento di=20 Telecom Italia S.p.A. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to=20 the persons above and may contain confidential=20 information. If you have received the message in error, be=20 informed that any use of the content hereof is prohibited.=20 Please return it immediately to the sender and delete the=20 message. Should you have any questions, please send an=20 e_mail to MailAdmin@tilab.com. Thank you=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Oct 20 08:57:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZzO-0000Kj-67; Thu, 20 Oct 2005 08:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZzM-0000IZ-6l for speechsc@megatron.ietf.org; Thu, 20 Oct 2005 08:57:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08983 for ; Thu, 20 Oct 2005 08:57:34 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESaBH-0007RD-Q8 for speechsc@ietf.org; Thu, 20 Oct 2005 09:10:05 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2005 05:57:34 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9KCvUub018704; Thu, 20 Oct 2005 05:57:31 -0700 (PDT) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9KD7pba026647; Thu, 20 Oct 2005 06:07:51 -0700 In-Reply-To: <03772D1EC8DE624A863058C75874A75C6770B9@vtg-um-e2k6.sj21ad.cisco.com> References: <03772D1EC8DE624A863058C75874A75C6770B9@vtg-um-e2k6.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06DF2B0F-48D1-4807-91D3-28511E4FAB91@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Thu, 20 Oct 2005 08:57:27 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=1056; t=1129813672; x=1130245872; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20Question=20on=20negotiating=20EMMA=20(was=20RE=3A=09[Speechsc]=0 9EMMA=3AExtensibleMultiModalAnnotationmarkuplanguagesupport?)| From:David=20R=20Oran=20| Date:Thu,=2020=20Oct=202005=2008=3A57=3A27=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=J6fBLfr1RA5Y5vd+bYzpB4pL0CuedKkU13fRQBqVuqGxf2Bx+DtjDvrdS2epArnkS3ChTJPx qVeqBVzai/C0exlofC69MHsoXOoHZX9uS49MPNGY0TAZse7CbHGGAJpozXxxknANiFNHd/YCiWs 0M51FoQLQRa/dKtPcNl8tkgY= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger , Andrew Wahbe , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On Oct 19, 2005, at 3:53 PM, Shanmugham, Saravanan wrote: [snip] >> capabilities through SDP. >> 2. It works for routing as such a proxy can take look >> > at the SDP to > >> make this decision. >> > Really? What if it's SMIME encrypted. i would council > against putting anythng needed for deciding which server > to contact or how to route the request into the SDP. > > >> 3. A routing proxy would any way have to look at the >> > SDP for other > >> things such as resource type. >> > If so, we've probably made a design error and should have > it in SIP caller prefs instead. > Today the SDP contains the information as to what resource-type > control > channels are to be established. This is need to establish control > channels to specific reources. That seems to be the right thing to do. > Of course, for the purposes of end-to-end negotiation of what media streams/channels get enables and how they map to MRCP sessions, that is exactly the job of SDP. > The question is should we also rely on this piece of information in > the > SDP for routing of the INVITE. > I'm saying no, because that confounds request routing with session parameter negotiation. We have lots of example in SIP, RTSP, and elsewhere of needed slightly different constructs for the two purposes. Dave. > Sarvi > [snip] > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Oct 20 12:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdMN-0004T5-HX; Thu, 20 Oct 2005 12:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdML-0004S3-PW for speechsc@megatron.ietf.org; Thu, 20 Oct 2005 12:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28032 for ; Thu, 20 Oct 2005 12:33:32 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESdYJ-0008Hj-6W for speechsc@ietf.org; Thu, 20 Oct 2005 12:46:04 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 09:33:32 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="354632559:sNHT26218720" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KGXS94015507; Thu, 20 Oct 2005 09:33:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Thu, 20 Oct 2005 09:33:24 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C677199@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Thread-Index: AcXVddvFyDoGTGBvTUG9E/c7+8tiagAFQyuw From: "Shanmugham, Saravanan" To: "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger , Andrew Wahbe , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Sounds good. I was going through SIP endpoint capabilities RFC 3840.=20 I think we could try to plug into that and add some feature-token values of our own to meet MRCPv2 needs like feature-types, mime-types supported, etc. What do you think. =20 Sarvi -----Original Message----- From: David R Oran [mailto:oran@cisco.com]=20 Sent: Thursday, October 20, 2005 5:57 AM To: Shanmugham, Saravanan Cc: Dave Burke; Andrew Wahbe; IETF SPEECHSC (E-mail); Eric Burger Subject: Re: Question on negotiating EMMA (was RE:=20 [Speechsc]=20 EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) =20 =20 On Oct 19, 2005, at 3:53 PM, Shanmugham, Saravanan wrote: =20 [snip] >> capabilities through SDP. >> 2. It works for routing as such a proxy can take look >> > at the SDP to > >> make this decision. >> > Really? What if it's SMIME encrypted. i would council > against putting anythng needed for deciding which server > to contact or how to route the request into the SDP. > > >> 3. A routing proxy would any way have to look at the >> > SDP for other > >> things such as resource type. >> > If so, we've probably made a design error and should have > it in SIP caller prefs instead. > Today the SDP contains the information as to what resource-type=20 > control channels are to be established. This is need to=20 establish=20 > control channels to specific reources. That seems to be=20 the right=20 > thing to do. > Of course, for the purposes of end-to-end negotiation of=20 what media streams/channels get enables and how they map=20 to MRCP sessions, that is exactly the job of SDP. =20 > The question is should we also rely on this piece of=20 information in=20 > the SDP for routing of the INVITE. > I'm saying no, because that confounds request routing with=20 session parameter negotiation. We have lots of example in=20 SIP, RTSP, and elsewhere of needed slightly different=20 constructs for the two purposes. =20 Dave. =20 > Sarvi > [snip] > > =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Oct 20 13:51:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeZC-0001yB-1s; Thu, 20 Oct 2005 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeZA-0001y6-KA for speechsc@megatron.ietf.org; Thu, 20 Oct 2005 13:51:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03186 for ; Thu, 20 Oct 2005 13:50:50 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESel8-0002WI-Pr for speechsc@ietf.org; Thu, 20 Oct 2005 14:03:24 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2005 10:50:50 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="354676563:sNHT28087152" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KHol94005259; Thu, 20 Oct 2005 10:50:47 -0700 (PDT) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9KI13vZ029573; Thu, 20 Oct 2005 11:01:07 -0700 In-Reply-To: <03772D1EC8DE624A863058C75874A75C677199@vtg-um-e2k6.sj21ad.cisco.com> References: <03772D1EC8DE624A863058C75874A75C677199@vtg-um-e2k6.sj21ad.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: Question on negotiating EMMA (was RE: [Speechsc] EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) Date: Thu, 20 Oct 2005 13:50:37 -0400 To: "Shanmugham, Saravanan" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=1723; t=1129831268; x=1130263468; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Re=3A=20Question=20on=20negotiating=20EMMA=20(was=20RE=3A=09[Speechsc]=0 9EMMA=3AExtensibleMultiModalAnnotationmarkuplanguagesupport?)| From:David=20R=20Oran=20| Date:Thu,=2020=20Oct=202005=2013=3A50=3A37=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=HYh73F35PtdE4ISDP3pTRF2Ls7Uqjkc0kOVnLyKD8DVIsY89jY2fXsuyH7tJ9JwTuTmPkWD4 KResqahX3rnOIicaRcTIF4S1RvIaTVzwRLZ5X5/QOXEzxZJQB09AGMBcHEhYvF0poeboomSexSx pr3FtWu43odV9zv2GZPWPCus= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" , Eric Burger , Andrew Wahbe , Dave Burke X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org On Oct 20, 2005, at 12:33 PM, Shanmugham, Saravanan wrote: > Sounds good. > I was going through SIP endpoint capabilities RFC 3840. > I think we could try to plug into that and add some feature-token > values > of our own to meet MRCPv2 needs like feature-types, mime-types > supported, etc. > > What do you think. > Works for me, Dave. > Sarvi > > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Thursday, October 20, 2005 5:57 AM > To: Shanmugham, Saravanan > Cc: Dave Burke; Andrew Wahbe; IETF SPEECHSC (E-mail); Eric Burger > Subject: Re: Question on negotiating EMMA (was RE: > [Speechsc] > EMMA:ExtensibleMultiModalAnnotationmarkuplanguagesupport?) > > > On Oct 19, 2005, at 3:53 PM, Shanmugham, Saravanan wrote: > > [snip] > >>> capabilities through SDP. >>> 2. It works for routing as such a proxy can take look >>> >>> >> at the SDP to >> >> >>> make this decision. >>> >>> >> Really? What if it's SMIME encrypted. i would council >> against putting anythng needed for deciding which server >> to contact or how to route the request into the SDP. >> >> >> >>> 3. A routing proxy would any way have to look at the >>> >>> >> SDP for other >> >> >>> things such as resource type. >>> >>> >> If so, we've probably made a design error and should have >> it in SIP caller prefs instead. >> Today the SDP contains the information as to what resource-type >> control channels are to be established. This is need to >> > establish > >> control channels to specific reources. That seems to be >> > the right > >> thing to do. >> >> > Of course, for the purposes of end-to-end negotiation of > what media streams/channels get enables and how they map > to MRCP sessions, that is exactly the job of SDP. > > >> The question is should we also rely on this piece of >> > information in > >> the SDP for routing of the INVITE. >> >> > I'm saying no, because that confounds request routing with > session parameter negotiation. We have lots of example in > SIP, RTSP, and elsewhere of needed slightly different > constructs for the two purposes. > > Dave. > > >> Sarvi >> >> > [snip] > >> >> >> > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Sat Oct 22 10:20:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETKEk-0003As-P5; Sat, 22 Oct 2005 10:20:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETKEj-00039u-VA for speechsc@megatron.ietf.org; Sat, 22 Oct 2005 10:20:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13925 for ; Sat, 22 Oct 2005 10:20:30 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETKR5-0000w6-K1 for speechsc@ietf.org; Sat, 22 Oct 2005 10:33:28 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2005 07:20:31 -0700 X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="355439833:sNHT24432678" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9MEKTJh009755 for ; Sat, 22 Oct 2005 07:20:30 -0700 (PDT) Received: from [10.32.245.153] (stealth-10-32-245-153.cisco.com [10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9MEUhHE013086 for ; Sat, 22 Oct 2005 07:30:43 -0700 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "IETF SPEECHSC ((E-mail))" From: David R Oran Date: Sat, 22 Oct 2005 10:20:27 -0400 X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=445; t=1129991443; x=1130423643; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=oran@cisco.com; z=Subject:Speechsc=20WG=20Meeting=20slot=20at=20IETF-64| From:David=20R=20Oran=20| Date:Sat,=2022=20Oct=202005=2010=3A20=3A27=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=iDkbTrL47B5j/yIcuubaBk0OMcRNgD9LtvkxeobD9Ki7KZExniSSu2P0v00QH+TZpPhf0TAB MV6GFRtgCKsWYJMULdwWZkn+ck72flSV4kGNAgFXcV8Go7MKMXIdvNFBpgJuFC/DWjNEJ2I1UO9 V9ydnNMzx08ZjfEwjn7EOFgo= Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Speechsc] Speechsc WG Meeting slot at IETF-64 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org From the DRAFT agenda: THURSDAY, November 10, 2005 1510-1610 Afternoon Session II TSV speechsc Speech Services Control WG Note that this is STILL SUBJECT TO CHANGE to don't complain if it does. Please make every effort to come if you have a stake in the technical quality of the spec - this will be our last opportunity for high- bandwidth discussion of the few open issues before we close them and WG start last call. (We will of course formally close issues via the mailing list and using the issue tracker) Your vigilant co-chair, Dave. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 26 18:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu6L-0000dl-Ln; Wed, 26 Oct 2005 18:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu5s-0000Sf-L2; Wed, 26 Oct 2005 18:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02298; Wed, 26 Oct 2005 18:49:48 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuJ6-0008Gk-5x; Wed, 26 Oct 2005 19:03:45 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5p-0005Zh-Lg; Wed, 26 Oct 2005 18:50:01 -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: Wed, 26 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: speechsc@ietf.org Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-mrcpv2-08.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: , Sender: speechsc-bounces@ietf.org 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) : S. Shanmugham Filename : draft-ietf-speechsc-mrcpv2-08.txt Pages : 196 Date : 2005-10-26 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-08.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-08.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-08.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: <2005-10-26164323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-mrcpv2-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-mrcpv2-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26164323.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 Thu Oct 27 08:37:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV70Q-0000rv-Tl; Thu, 27 Oct 2005 08:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV70P-0000pF-6c for speechsc@megatron.ietf.org; Thu, 27 Oct 2005 08:37:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26263 for ; Thu, 27 Oct 2005 08:36:59 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV7Dk-0000an-RJ for speechsc@ietf.org; Thu, 27 Oct 2005 08:51:06 -0400 Received: from chimaera (pcp08627966pcs.plmthm01.pa.comcast.net[68.32.43.67]) by comcast.net (sccrmhc11) with SMTP id <2005102712365701100c23eqe>; Thu, 27 Oct 2005 12:36:57 +0000 From: "Deborah Dahl" To: "'IETF SPEECHSC \(E-mail\)'" Date: Thu, 27 Oct 2005 08:36:33 -0400 Message-ID: <00ab01c5daf3$1b4aeb50$3a7ba8c0@chimaera> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <004201c406cd$a1b2f9e0$3a7ba8c0@chimaera> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Speechsc] EMMA Last Call Working Draft X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Many of you may already be aware of this publication, but I'm sending this announcement to the list to help insure that it reaches the widest possible audience. The W3C Multimodal Interaction Working Group is pleased to announce the publication of the 16 September 2005 Last Call Working Draft of the EMMA (Extensible MultiModal Annotation) Specification: http://www.w3.org/TR/emma/ Description (from the abstract) This document is part of a set of specifications for multimodal systems, and provides details of an XML markup language for containing and annotating the interpretation of user input. Examples of interpretation of user input are a transcription into words of a raw signal, for instance derived from speech, pen or keystroke input, a set of attribute/value pairs describing their meaning, or a set of attribute/value pairs describing a gesture. The interpretation of the user's input is expected to be generated by signal interpretation processes, such as speech and ink recognition, semantic interpreters, and other types of processors for use by components that act on the user's inputs such as interaction managers. Comments should be sent to www-multimodal@w3.org. best regards, Debbie Dahl Chair, W3C Multimodal Interaction Working Group _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Oct 27 22:45:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKFV-00056b-P7; Thu, 27 Oct 2005 22:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKFU-00056W-4v for speechsc@megatron.ietf.org; Thu, 27 Oct 2005 22:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13443 for ; Thu, 27 Oct 2005 22:45:27 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVKSw-0004VC-Ld for speechsc@ietf.org; Thu, 27 Oct 2005 22:59:40 -0400 Received: from [205.150.90.240] (vpnrange.voicegenie.com [205.150.90.240]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j9S2jOm03423 for ; Thu, 27 Oct 2005 22:45:24 -0400 (EDT) Message-ID: <436190C3.2040908@voicegenie.com> Date: Thu, 27 Oct 2005 22:45:23 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IETF SPEECHSC (E-mail)" Subject: [speechsc] VoiceXML maxspeech timeout not implementable with MRCPv2 Content-Type: multipart/mixed; boundary="------------070208070101090801090300" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------070208070101090801090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Actually, this is something I've raised before with the 07 draft (see http://www1.ietf.org/mail-archive/web/speechsc/current/msg01510.html) but is still not fixed in 08. I don't see a way to implement the VoiceXML maxspeech timeout with the current recognition completion cause codes. The semantics of the Recognition Timer match those of VoiceXML maxspeech timeout. There are currently 2 cause codes related to this timer: 003 recognition-timeout: RECOGNIZE in hotword mode completed without a match due to a recognition-timeout 008 success-maxtime: RECOGNIZE request terminated because speech was too long but whatever was spoken till that point was a full match. But what should be thrown in a non-hotword recognition when the timer fires and there is no match? It can't be 001 no-match; the VoiceXML interpreter will not be able to distinguish a "nomatch" from "maxspeech" in this case. Let's take a step back. If we really want to describe what happened, then I think we need to communicate to the client 1) why the recognition was stopped and 2) if the result a no-match, a partial match, or a complete match when it stopped. 1) The recognition can stop for the following reasons (the related cause codes in parens): no-input timeout (002) complete timeout (000) incomplete timeout (001 013) recognition timeout (003 and 008) speech too early (007) cancelled (011) various errors (004, 005, 006, 009, 010, 012) 2) The result is irrelevant for no-input, speech too early, cancelled, and the errors. This leaves complete timeout, incomplete timeout, and recognition timeout. By the definition of complete timeout, this is always a complete match (000). Also by definition, incomplete timeout could result in a no match (001) or a partial match (013) -- though VoiceXML will likely throw nomatch for either. So we are left with recognition timeout. It could be a complete match (008 by the definition in section 9.4.11) or a partial match (008 by the definition in section 9.4.7), or a no-match... well if it was a hotword recognition we have 003; for the normal case, we have nothing. So hopefully I have clarified my earlier point that Recognition Complete Cause codes 003 and 008 need revisiting. Sorry to be so long winded but I think it's important that VoiceXML be implementable using MRCPv2; it is a very common use case for the specification. Before proposing a solution, I would like to again ask why we need to have a special cause code for recognition-timeout in the hotword case. The answer to this question is here: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01501.html But I still don't see why you need a special completion cause to say that the timer expired in hotword mode. The client knows what mode the recognition is in. You just need to tell it that the timer fired. What the client does need to know is if there is a valid result for it to process. Thus I propose that 003 be rewritten as follows: 003 recognition-timeout: RECOGNIZE in hotword mode completed without a match due to a recognition-timeout This will bring it back in line with the earlier Scansoft & Nuance proposal (well now it just a Nuance proposal) from a year and a half ago: http://www1.ietf.org/mail-archive/web/speechsc/current/msg00560.html Andrew --------------070208070101090801090300 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------070208070101090801090300 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 --------------070208070101090801090300-- From speechsc-bounces@ietf.org Thu Oct 27 23:29:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKvg-0005fO-3m; Thu, 27 Oct 2005 23:29:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKvd-0005eM-QX for speechsc@megatron.ietf.org; Thu, 27 Oct 2005 23:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15827 for ; Thu, 27 Oct 2005 23:29:00 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVL96-0005lE-7d for speechsc@ietf.org; Thu, 27 Oct 2005 23:43:13 -0400 Received: from [205.150.90.240] (vpnrange.voicegenie.com [205.150.90.240]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j9S3T4m04266; Thu, 27 Oct 2005 23:29:04 -0400 (EDT) Message-ID: <43619B00.3050401@voicegenie.com> Date: Thu, 27 Oct 2005 23:29:04 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Wahbe Subject: Re: [speechsc] VoiceXML maxspeech timeout not implementable with MRCPv2 References: <436190C3.2040908@voicegenie.com> In-Reply-To: <436190C3.2040908@voicegenie.com> Content-Type: multipart/mixed; boundary="------------000808020906010106090404" X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------000808020906010106090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I just noticed that my completion cause code analysis was wrong in one case: - between drafts 06 and 07 it seems the definition of Speech Incomplete Timeout (Section 9.4.16) was changed so that "partial-match" (013) was returned when it fired instead of "no-match" (001). So I guess what we are saying is that another way of terminating recognition is that the speech is just not matching the grammar at all and that is what yeilds no-match (001). (Though I could have sworn that a recognizer waits until you were done talking even if the utterance wasn't matching at all and that incomplete timeout was used in that case. Anyone care to clarify?) Anyways, I don't think this changes my real point below. Andrew Andrew Wahbe wrote: > Actually, this is something I've raised before with the 07 draft (see > http://www1.ietf.org/mail-archive/web/speechsc/current/msg01510.html) > but is still not fixed in 08. > > I don't see a way to implement the VoiceXML maxspeech timeout with the > current recognition completion cause codes. The semantics of the > Recognition Timer match those of VoiceXML maxspeech timeout. There are > currently 2 cause codes related to this timer: > > 003 recognition-timeout: RECOGNIZE in hotword mode completed without a > match due to a recognition-timeout > > 008 success-maxtime: RECOGNIZE request terminated because speech was > too long but whatever was spoken till that point was a full match. > > But what should be thrown in a non-hotword recognition when the timer > fires and there is no match? It can't be 001 no-match; the VoiceXML > interpreter will not be able to distinguish a "nomatch" from > "maxspeech" in this case. > > Let's take a step back. If we really want to describe what happened, > then I think we need to communicate to the client 1) why the > recognition was stopped and 2) if the result a no-match, a partial > match, or a complete match when it stopped. > > 1) The recognition can stop for the following reasons (the related > cause codes in parens): > > no-input timeout (002) > complete timeout (000) > incomplete timeout (001 013) > recognition timeout (003 and 008) > speech too early (007) > cancelled (011) > various errors (004, 005, 006, 009, 010, 012) > > 2) The result is irrelevant for no-input, speech too early, cancelled, > and the errors. This leaves complete timeout, incomplete timeout, and > recognition timeout. By the definition of complete timeout, this is > always a complete match (000). Also by definition, incomplete timeout > could result in a no match (001) or a partial match (013) -- though > VoiceXML will likely throw nomatch for either. > > So we are left with recognition timeout. It could be a complete match > (008 by the definition in section 9.4.11) or a partial match (008 by > the definition in section 9.4.7), or a no-match... well if it was a > hotword recognition we have 003; for the normal case, we have nothing. > > So hopefully I have clarified my earlier point that Recognition > Complete Cause codes 003 and 008 need revisiting. Sorry to be so long > winded but I think it's important that VoiceXML be implementable using > MRCPv2; it is a very common use case for the specification. > > Before proposing a solution, I would like to again ask why we need to > have a special cause code for recognition-timeout in the hotword case. > The answer to this question is here: > http://www1.ietf.org/mail-archive/web/speechsc/current/msg01501.html > > But I still don't see why you need a special completion cause to say > that the timer expired in hotword mode. The client knows what mode the > recognition is in. You just need to tell it that the timer fired. > > What the client does need to know is if there is a valid result for it > to process. Thus I propose that 003 be rewritten as follows: > > 003 recognition-timeout: RECOGNIZE in hotword mode completed without a > match due to a recognition-timeout > > This will bring it back in line with the earlier Scansoft & Nuance > proposal (well now it just a Nuance proposal) from a year and a half ago: > http://www1.ietf.org/mail-archive/web/speechsc/current/msg00560.html > > Andrew > >_______________________________________________ >Speechsc mailing list >Speechsc@ietf.org >https://www1.ietf.org/mailman/listinfo/speechsc > > --------------000808020906010106090404 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------000808020906010106090404 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 --------------000808020906010106090404-- From speechsc-bounces@ietf.org Thu Oct 27 23:33:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKzl-0000FW-6Y; Thu, 27 Oct 2005 23:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKzj-0000CH-SP for speechsc@megatron.ietf.org; Thu, 27 Oct 2005 23:33:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16029 for ; Thu, 27 Oct 2005 23:33:15 -0400 (EDT) Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVLDE-0005rm-0A for speechsc@ietf.org; Thu, 27 Oct 2005 23:47:28 -0400 Received: from [205.150.90.240] (vpnrange.voicegenie.com [205.150.90.240]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id j9S3XKm04357 for ; Thu, 27 Oct 2005 23:33:20 -0400 (EDT) Message-ID: <43619C00.4040209@voicegenie.com> Date: Thu, 27 Oct 2005 23:33:20 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IETF SPEECHSC (E-mail)" Subject: Re: [speechsc] VoiceXML maxspeech timeout not implementable with MRCPv2 References: <436190C3.2040908@voicegenie.com> <43619B00.3050401@voicegenie.com> In-Reply-To: <43619B00.3050401@voicegenie.com> Content-Type: multipart/mixed; boundary="------------030103050305090308020300" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------030103050305090308020300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Man I should stop writing emails so late at night: My new proposed text for 003 wasn't changed at all. This is what I am proposing: 003 recognition-timeout: RECOGNIZE completed without a match due to a recognition-timeout Andrew Andrew Wahbe wrote: > I just noticed that my completion cause code analysis was wrong in one > case: > > - between drafts 06 and 07 it seems the definition of Speech > Incomplete Timeout (Section 9.4.16) was changed so that > "partial-match" (013) was returned when it fired instead of "no-match" > (001). > > So I guess what we are saying is that another way of terminating > recognition is that the speech is just not matching the grammar at all > and that is what yeilds no-match (001). (Though I could have sworn > that a recognizer waits until you were done talking even if the > utterance wasn't matching at all and that incomplete timeout was used > in that case. Anyone care to clarify?) > > Anyways, I don't think this changes my real point below. > > Andrew > > Andrew Wahbe wrote: > >> Actually, this is something I've raised before with the 07 draft (see >> http://www1.ietf.org/mail-archive/web/speechsc/current/msg01510.html) >> but is still not fixed in 08. >> >> I don't see a way to implement the VoiceXML maxspeech timeout with >> the current recognition completion cause codes. The semantics of the >> Recognition Timer match those of VoiceXML maxspeech timeout. There >> are currently 2 cause codes related to this timer: >> >> 003 recognition-timeout: RECOGNIZE in hotword mode completed without >> a match due to a recognition-timeout >> >> 008 success-maxtime: RECOGNIZE request terminated because speech was >> too long but whatever was spoken till that point was a full match. >> >> But what should be thrown in a non-hotword recognition when the timer >> fires and there is no match? It can't be 001 no-match; the VoiceXML >> interpreter will not be able to distinguish a "nomatch" from >> "maxspeech" in this case. >> >> Let's take a step back. If we really want to describe what happened, >> then I think we need to communicate to the client 1) why the >> recognition was stopped and 2) if the result a no-match, a partial >> match, or a complete match when it stopped. >> >> 1) The recognition can stop for the following reasons (the related >> cause codes in parens): >> >> no-input timeout (002) >> complete timeout (000) >> incomplete timeout (001 013) >> recognition timeout (003 and 008) >> speech too early (007) >> cancelled (011) >> various errors (004, 005, 006, 009, 010, 012) >> >> 2) The result is irrelevant for no-input, speech too early, >> cancelled, and the errors. This leaves complete timeout, incomplete >> timeout, and recognition timeout. By the definition of complete >> timeout, this is always a complete match (000). Also by definition, >> incomplete timeout could result in a no match (001) or a partial >> match (013) -- though VoiceXML will likely throw nomatch for either. >> >> So we are left with recognition timeout. It could be a complete match >> (008 by the definition in section 9.4.11) or a partial match (008 by >> the definition in section 9.4.7), or a no-match... well if it was a >> hotword recognition we have 003; for the normal case, we have nothing. >> >> So hopefully I have clarified my earlier point that Recognition >> Complete Cause codes 003 and 008 need revisiting. Sorry to be so long >> winded but I think it's important that VoiceXML be implementable >> using MRCPv2; it is a very common use case for the specification. >> >> Before proposing a solution, I would like to again ask why we need to >> have a special cause code for recognition-timeout in the hotword >> case. The answer to this question is here: >> http://www1.ietf.org/mail-archive/web/speechsc/current/msg01501.html >> >> But I still don't see why you need a special completion cause to say >> that the timer expired in hotword mode. The client knows what mode >> the recognition is in. You just need to tell it that the timer fired. >> >> What the client does need to know is if there is a valid result for >> it to process. Thus I propose that 003 be rewritten as follows: >> >> 003 recognition-timeout: RECOGNIZE in hotword mode completed without >> a match due to a recognition-timeout >> >> This will bring it back in line with the earlier Scansoft & Nuance >> proposal (well now it just a Nuance proposal) from a year and a half >> ago: >> http://www1.ietf.org/mail-archive/web/speechsc/current/msg00560.html >> >> Andrew >> >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www1.ietf.org/mailman/listinfo/speechsc >> >> --------------030103050305090308020300 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Disposition: attachment; filename="awahbe.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------030103050305090308020300 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 --------------030103050305090308020300--