From speechsc-bounces@ietf.org Mon Sep 05 23:56:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUZ1-0002sM-6Z; Mon, 05 Sep 2005 23:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECUYz-0002sH-5N for speechsc@megatron.ietf.org; Mon, 05 Sep 2005 23:56: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 XAA19874 for ; Mon, 5 Sep 2005 23:55:58 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECUbr-0007lL-L9 for speechsc@ietf.org; Mon, 05 Sep 2005 23:59:01 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IMD001IYN9RXQ@szxga02-in.huawei.com> for speechsc@ietf.org; Tue, 06 Sep 2005 12:03:27 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IMD008N4N9R98@szxga02-in.huawei.com> for speechsc@ietf.org; Tue, 06 Sep 2005 12:03:27 +0800 (CST) Received: from a70042 ([10.70.101.190]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IMD00BK2N9JG6@szxml02-in.huawei.com> for speechsc@ietf.org; Tue, 06 Sep 2005 12:03:20 +0800 (CST) Date: Tue, 06 Sep 2005 11:56:38 +0800 From: "Ashok K. Rawat" To: speechsc@ietf.org Message-id: <000f01c5b296$fbdf4880$be65460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7BIT Subject: [Speechsc] Resource Management in Media servers X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Ashok K. Rawat" List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, Please let me know if there exists any unified resource management framework for Media Servers from different vendors. Is any work going on in this direction? thanks, -Ashok _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Sep 19 10:30:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMer-00087g-Uv; Mon, 19 Sep 2005 10:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMeq-00087T-9G for speechsc@megatron.ietf.org; Mon, 19 Sep 2005 10:30:12 -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 KAA24590 for ; Mon, 19 Sep 2005 10:30:09 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMkS-0000E2-Th for speechsc@ietf.org; Mon, 19 Sep 2005 10:36:02 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8JETxo8032267 for ; Mon, 19 Sep 2005 10:29:59 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8JETDr3476658 for ; Mon, 19 Sep 2005 08:29:13 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8JESgvN002250 for ; Mon, 19 Sep 2005 08:28:42 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j8JESgk4002246 for ; Mon, 19 Sep 2005 08:28:42 -0600 To: speechsc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Mon, 19 Sep 2005 10:29:22 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 09/19/2005 08:29:23, Serialize complete at 09/19/2005 08:29:23 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Speechsc] MRCPv2 Pronunciation support X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org How would an MRCP client query/determine that a list of words do not belong to the base dictionary for a SYNTHESIZER resource? How would the MRCP client retrieve the default generated pronunciation for a single word or list of words, especially when an in-line or externally referenced lexicon specified in a DEFINE-LEXICON request could define a large number of pronunciations? Finally, why doesn't the MRCPv2 specification reference the PLS draft as a standard for pronunciation support? Pronunciation Lexicon Specification (PLS) Version 1.0 - http://www.w3.org/TR/pronunciation-lexicon/ Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Sep 22 10:17:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRmC-0000md-FC; Thu, 22 Sep 2005 10:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRmB-0000mS-0v for speechsc@megatron.ietf.org; Thu, 22 Sep 2005 10:10: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 KAA02106 for ; Thu, 22 Sep 2005 10:10:12 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIRsN-00029D-Tn for speechsc@ietf.org; Thu, 22 Sep 2005 10:16:41 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IN800A91208TH@dns2.cselt.it> for speechsc@ietf.org; Thu, 22 Sep 2005 16:09:44 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 16:07:37 +0200 Date: Thu, 22 Sep 2005 16:09:43 +0200 From: Baggia Paolo To: speechsc@ietf.org 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: Voice-category header still in spec Thread-Index: AcW/f0eSJaXZgQfRTkO+8pJi3ElsZQ== Content-class: urn:content-classes:message X-OriginalArrivalTime: 22 Sep 2005 14:07:37.0687 (UTC) FILETIME=[FCBBAE70:01C5BF7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , Baggia Paolo Subject: [Speechsc] Voice-category header still in spec X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi,=20 revision -07 still contains some reference to Voice-Category header (see = pagg. 27, 28). All of them inside examples only. The Voice-Category header should be removed because it is no more = present in SSML 1.0, W3C Recommendation, 7 Sept. 2004 as described in=20 Section "8.4.6 Voice-Parameters" of MRVPv2 (pag. 45). Regards, Paolo Baggia, Vittorio Manzone, Patrizio Bergallo, Loquendo 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 Thu Sep 22 10:29:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIS59-0006hX-Rw; Thu, 22 Sep 2005 10:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIS57-0006gz-I1 for speechsc@megatron.ietf.org; Thu, 22 Sep 2005 10:29:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03728 for ; Thu, 22 Sep 2005 10:29:47 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EISBM-0002ds-Ur for speechsc@ietf.org; Thu, 22 Sep 2005 10:36:17 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IN800H062XF4X@dns1.cselt.it> for speechsc@ietf.org; Thu, 22 Sep 2005 16:29:39 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 16:29:39 +0200 Date: Thu, 22 Sep 2005 16:29:38 +0200 From: Baggia Paolo To: speechsc@ietf.org 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: Min-Verification-Score: clarification needed thread-index: AcW/ghADGpEoNWw9SteJdGGqT8y7bw== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 22 Sep 2005 14:29:39.0402 (UTC) FILETIME=[108962A0:01C5BF82] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , Baggia Paolo Subject: [Speechsc] Min-Verification-Score: clarification needed X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, comparing new verification-header Min-Verification-Score description = with Speechsc Forum discussion (see = http://www1.ietf.org/mail-archive/web/speechsc/current/msg01409.html and = http://www1.ietf.org/mail-archive/web/speechsc/current/msg01414.html). We think that header description contains some errors (see below) --- 1) old name in Section 11.4 In Section "11.4 Verification Header Fields" there is: "/ confidence-threshold" instead of "/ min-verification-score" --- 2) old names in Section 11.4.6 The section "11.4.6 Min-Verification-Score" reads: "The confidence-threshold header, when used ..." It should be: "The Min-Verification-Score header, when used ..." --- 3) Inconsistent values: Range -1:1 The current value of 0.0-1.0 seems to be not consistent with the resolution in: http://www1.ietf.org/mail-archive/web/speechsc/current/msg01414.html which states: >>> I will change this and the newly-renamed min-verification-score header = to -1:1 range unless I hear objection with persuasive rationale. <<< and the ABNF definition >> min-verification-score =3D "Min-Verification-Score" ":" [-] = Float-value CRLF --- 4) Inconsistent description Also the second part of the sentence: "This is a float value between 0.0-1.0 indicating the verification engine's confidence in the recognition." seems to be not aligned with the new definition that reads: "... determines the minumum verification score for which a verification decision of "accepted" may be declared by the server." We suggest either to remove: "indicating the verification engine's confidence in the recognition." or to re-phrase it. Paolo, Vittorio, Patrizio (Loquendo) 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 Sep 22 10:45:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISK9-0003R9-SM; Thu, 22 Sep 2005 10:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISK6-0003OC-OW for speechsc@megatron.ietf.org; Thu, 22 Sep 2005 10:45:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04703 for ; Thu, 22 Sep 2005 10:45:16 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EISQL-000326-AN for speechsc@ietf.org; Thu, 22 Sep 2005 10:51:46 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IN800D2O3N720@dns2.cselt.it> for speechsc@ietf.org; Thu, 22 Sep 2005 16:45:07 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 16:43:01 +0200 Date: Thu, 22 Sep 2005 16:45:06 +0200 From: Baggia Paolo To: speechsc@ietf.org 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: RECOGNIZE queueing: clarifications needed Thread-Index: AcW/hDkEM0/3NROmTQWn9HXsXJilfw== Content-class: urn:content-classes:message X-OriginalArrivalTime: 22 Sep 2005 14:43:01.0468 (UTC) FILETIME=[EE9AF1C0:01C5BF83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , Baggia Paolo Subject: [Speechsc] RECOGNIZE queueing: clarifications needed X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, There are some clarifications to be issued on Recognition queueing: --- 1) Remove sentence? In pag. 102, it is said that: "If the resource is already in the recognizing state, the server MUST respond with a failure status". This statement is in contraddiction with RECOGNIZE queueing mechanism, = see section 9.4.28 in pag. 79. -> Should the previuous sentence be removed from the spec? --- 2) Only a clarification: In post = http://www1.ietf.org/mail-archive/web/speechsc/current/msg01295.html = there=20 was a proposal for generalizing queueing methods:=20 - why has not been included in -07 revision?=20 - will it be included in next revision? --- 3) Pending old issue Vittorio already sent a message that is related to the same topic, see=20 issue 20 of the RoundUp issue tracking tool: https://www.softarmor.com/roundup/speechsc/issue20 Regards, Paolo Baggia, Vittorio Manzone, Patrizio Bergallo, Loquendo 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 Thu Sep 22 10:55:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISU5-0005lg-AM; Thu, 22 Sep 2005 10:55:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISU3-0005l6-MG for speechsc@megatron.ietf.org; Thu, 22 Sep 2005 10:55: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 KAA05109 for ; Thu, 22 Sep 2005 10:55:33 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EISaG-0003Es-BU for speechsc@ietf.org; Thu, 22 Sep 2005 11:02:03 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IN800I7N447BF@dns1.cselt.it> for speechsc@ietf.org; Thu, 22 Sep 2005 16:55:19 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 16:55:18 +0200 Date: Thu, 22 Sep 2005 16:55:18 +0200 From: Baggia Paolo To: speechsc@ietf.org 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: Voice Enrolled Grammars: clarification needed thread-index: AcW/haURqIKlKsqdT4OLT7Xcuajs3w== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 22 Sep 2005 14:55:18.0745 (UTC) FILETIME=[A60E7C90:01C5BF85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , Baggia Paolo Subject: [Speechsc] Voice Enrolled Grammars: clarification needed X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, In a RECOGNIZE request that was issued with the purpose of enrolling=20 a personal grammar,=20 - Should one or more grammars be specified in the RECOGNIZE body?=20 The Personal-Grammar-URI is the repository of the results of the grammar enrollment. It is not the recognition grammar.=20 - The following sentence in pag. 84 seems to prevent a RECOGNIZE request without a grammar specified. "A RECOGNIZE=20 request MUST completely specify the grammars to be active during the recognition operation".=20 In our opinion, this point should be clarified. Paolo, Vittorio, Patrizio (Loquendo) 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 Fri Sep 23 04:55:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjKt-00061k-Fv; Fri, 23 Sep 2005 04:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjKr-00061F-Lr for speechsc@megatron.ietf.org; Fri, 23 Sep 2005 04:55:13 -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 EAA01589 for ; Fri, 23 Sep 2005 04:55:11 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIjRF-0008Gc-Kx for speechsc@ietf.org; Fri, 23 Sep 2005 05:01:51 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IN900C2OI3QMY@dns2.cselt.it> for speechsc@ietf.org; Fri, 23 Sep 2005 10:55:02 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 10:52:55 +0200 Date: Fri, 23 Sep 2005 10:55:02 +0200 From: Baggia Paolo Subject: RE: [Speechsc] EMMA: Extensible MultiModal Annotation markuplanguagesupport? To: speechsc@ietf.org 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: RE: [Speechsc] EMMA: Extensible MultiModal Annotation markuplanguagesupport? Thread-Index: AcXAHHwhd4g/5XxYT7S6czcponfLSA== Content-class: urn:content-classes:message X-OriginalArrivalTime: 23 Sep 2005 08:52:55.0984 (UTC) FILETIME=[30C63300:01C5C01C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , 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 Hi, 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) -----Original Message----- From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org]On Behalf Of Shanmugham, Saravanan Sent: Wednesday, August 10, 2005 8:55 PM To: Brett Gavagni; Dave Burke Cc: speechsc@ietf.org; David R. Oran; speechsc-bounces@ietf.org; Jerry Carter; Reifenrath, Klaus Subject: RE: [Speechsc] EMMA: Extensible MultiModal Annotation markuplanguagesupport? Added to this list. The text proposed by Dave will be added to the next draft. Sarvi=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 Fri Sep 23 05:09:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjYI-0008Nl-AW; Fri, 23 Sep 2005 05:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjYG-0008Nd-IR for speechsc@megatron.ietf.org; Fri, 23 Sep 2005 05:09: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 FAA02021 for ; Fri, 23 Sep 2005 05:09:02 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIjee-00006h-Nt for speechsc@ietf.org; Fri, 23 Sep 2005 05:15:42 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IN90062SIQPQC@dns1.cselt.it> for speechsc@ietf.org; Fri, 23 Sep 2005 11:08:49 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Sep 2005 11:08:48 +0200 Date: Fri, 23 Sep 2005 11:08:48 +0200 From: Baggia Paolo To: speechsc@ietf.org 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: Recording Size and Duration: clarification needed thread-index: AcXAHmiFbjn4PjxoTyO/q9e4TsTz7A== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 23 Sep 2005 09:08:48.0875 (UTC) FILETIME=[68BDD3B0:01C5C01E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio , Baggia Paolo Subject: [Speechsc] Recording Size and Duration: clarification needed X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi Sarvi , we would like to know the status of the discussion on the question = raised=20 by Jenny see: https://www.softarmor.com/roundup/speechsc/issue35 on size and duration of audio recording. Your last response to the thread was saying: >>> [...] After a recognize the recorded audio/waveform is available as a URI. The request, I believe was for the server to send these 2 pieces of information in addition to the URI. We could address this by allowing these fields to be sent in the same header like the following. Waveform-URI:;size=3D743672= ; duration=3D2300 Thx, Sarvi <<< Will this be added to the next draft? Will it be added to Record-URI too? Paolo, Vittori, Patrizio (Loquendo) 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 Fri Sep 23 23:42:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ0wC-0006aN-ES; Fri, 23 Sep 2005 23:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ0w9-0006Zv-QL for speechsc@megatron.ietf.org; Fri, 23 Sep 2005 23:42:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01082 for ; Fri, 23 Sep 2005 23:42:50 -0400 (EDT) Received: from dsl092-077-144.bos1.dsl.speakeasy.net ([66.92.77.144] helo=jerrycarter.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJ12h-00031y-Fj for speechsc@ietf.org; Fri, 23 Sep 2005 23:49:40 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by jerrycarter.org (Postfix) with ESMTP id CBB49AD6C13; Fri, 23 Sep 2005 23:42:50 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74ec1829686ee0e377d2683b164bea9f@jerrycarter.org> Content-Transfer-Encoding: 7bit From: Jerry Carter Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markuplanguagesupport? Date: Fri, 23 Sep 2005 23:42:50 -0400 To: Baggia Paolo X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: "IETF SPEECHSC \(E-mail\)" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org 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 From speechsc-bounces@ietf.org Sat Sep 24 10:50:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJBM5-00045p-Cd; Sat, 24 Sep 2005 10:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJBM4-00045h-2q; Sat, 24 Sep 2005 10:50:20 -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 KAA09425; Sat, 24 Sep 2005 10:50:15 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJBSg-0008Tm-To; Sat, 24 Sep 2005 10:57:11 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8OEngIR027366; Sat, 24 Sep 2005 10:49:42 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8OEo82D533706; Sat, 24 Sep 2005 08:50:08 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8OEo77D030417; Sat, 24 Sep 2005 08:50:07 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j8OEo7aj030414; Sat, 24 Sep 2005 08:50:07 -0600 In-Reply-To: <74ec1829686ee0e377d2683b164bea9f@jerrycarter.org> To: Jerry Carter MIME-Version: 1.0 Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotation markuplanguagesupport? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Sat, 24 Sep 2005 10:50:52 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 09/24/2005 08:50:54, Serialize complete at 09/24/2005 08:50:54 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "IETF SPEECHSC \(E-mail\)" , speechsc-bounces@ietf.org, 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 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 From speechsc-bounces@ietf.org Mon Sep 26 05:30:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJpJr-0001YN-1L; Mon, 26 Sep 2005 05:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJpJq-0001Xs-3t for speechsc@megatron.ietf.org; Mon, 26 Sep 2005 05:30: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 FAA14131 for ; Mon, 26 Sep 2005 05:30:39 -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 1EJpQn-0006y1-F5 for speechsc@ietf.org; Mon, 26 Sep 2005 05:37:57 -0400 Received: from daburkewxp (unknown [10.0.0.203]) by mail.voxpilot.com (Postfix) with ESMTP id 335C4214041; Mon, 26 Sep 2005 09:30:24 +0000 (GMT) Message-ID: <011601c5c27c$ee8fec70$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: Subject: [speechsc] Limitation: Client side cache controls Date: Mon, 26 Sep 2005 10:30:28 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: 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: , Content-Type: multipart/mixed; boundary="===============1186797619==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1186797619== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0113_01C5C285.502BE4E0" This is a multi-part message in MIME format. ------=_NextPart_000_0113_01C5C285.502BE4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am wondering how to efficiently activate more than one grammar with = different client-side cache controls. Imagine a VoiceXML case: I could put these in a RECOGNIZE request with a text/uri-list body part = but I can only apply the Cache-Control: max-age header on the complete = RECOGNIZE request, which is scoped over the entire request (and not per = URI or indeed per body part). Three workarounds I see: (1) Do a DEFINE-GRAMMAR per grammar with the appropriate Cache-Control: = max-age (2) Redefine Cache-Control as a MIME-extension-field (naming it = Content-Cache-Control).=20 Then at least I can put a single entry text/uri-list in each body = part and use a single RECOGNIZE (3) Add a parameter to the URI e.g. ;max-age=3D0 ;max-age=3D100 Option (1) is chatty when the MRCP client needs to activate several = grammars (this is quite a common occurrence). Option (2) or Option (3) = is preferable (save for the fact that we're supposed to be done with v2 = of MRCP). Dave ------=_NextPart_000_0113_01C5C285.502BE4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am wondering how to = efficiently activate=20 more than one grammar with different client-side cache controls. Imagine = a=20 VoiceXML case:
 
<grammar src=3D"gram1.grxml"=20 maxage=3D"0"/>
<grammar src=3D"gram2.grxml=20 maxage=3D"100"/>
 
I could put these in a RECOGNIZE = request with=20 a text/uri-list body part but I can only apply the Cache-Control: = max-age=20 header on the complete RECOGNIZE request, which is scoped over the = entire=20 request (and not per URI or indeed per body = part).
 
Three workarounds I see:
 (1) Do a DEFINE-GRAMMAR per = grammar with the=20 appropriate Cache-Control: max-age
 (2) Redefine Cache-Control as a=20 MIME-extension-field (naming it Content-Cache-Control).
       = Then at least=20 I can put a single entry text/uri-list in each body part and use a = single=20 RECOGNIZE
(3) Add a parameter to the URI = e.g.
    =20 <gram1.grxml>;max-age=3D0
    =20 <gram2.grxml>;max-age=3D100
 
Option (1) is chatty when the MRCP = client needs to=20 activate several grammars (this is quite a common occurrence). Option = (2) or=20 Option (3) is preferable (save for the fact that we're supposed to be = done with=20 v2 of MRCP).
 
Dave
 
 
------=_NextPart_000_0113_01C5C285.502BE4E0-- --===============1186797619== 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 --===============1186797619==-- From speechsc-bounces@ietf.org Wed Sep 28 03:40:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKWYY-0000K6-2J; Wed, 28 Sep 2005 03:40:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKWYU-0000JZ-9t; Wed, 28 Sep 2005 03:40: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 DAA19358; Wed, 28 Sep 2005 03:40:40 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKWfr-0004AA-Up; Wed, 28 Sep 2005 03:48:21 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0INI00K2GNZ0NB@dns1.cselt.it>; Wed, 28 Sep 2005 09:40:12 +0200 (MEST) Received: from EXC01C.cselt.it ([163.162.4.217]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 09:40:12 +0200 Date: Wed, 28 Sep 2005 09:39:44 +0200 From: Baggia Paolo Subject: RE: [Speechsc] EMMA: Extensible MultiModal Annotationmarkuplanguagesupport? To: Brett Gavagni , Jerry Carter 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: [Speechsc] EMMA: Extensible MultiModal Annotationmarkuplanguagesupport? thread-index: AcXBF0oEI2U4xAo8S8WZ4QQYgA1+4wC55wJw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 28 Sep 2005 07:40:12.0153 (UTC) FILETIME=[DBCB2E90:01C5C3FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , speechsc-bounces@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi, My personal opinion is: a. mandate a precise format (and this has already been=20 done by including the nlsml spec inside MRCPv2) b. allow a well-defined mechanism to allow other formats to be negotiated (I see that this will happen in any case at least for special and critical uses of speech technologies). If we define (b) prevents to have proprietary extensions on top of MRCPv2. IN any case (a) will always be allow "client/server interoperability" and future revision of MRCPv2 could be done to "mandate" other formats, without having to touch the negotiation mechanism. Paolo. -----Original Message----- From: Brett Gavagni [mailto:gavagni@us.ibm.com] Sent: Saturday, September 24, 2005 4:51 PM To: Jerry Carter Cc: Baggia Paolo; IETF SPEECHSC (E-mail); speechsc-bounces@ietf.org Subject: Re: [Speechsc] EMMA: Extensible MultiModal Annotationmarkuplanguagesupport? Hi, I agree that the ability for a client to request the format of the=20 recognizer result data content would be useful. I would prefer to see this function defined in a consistent manner with=20 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=20 RECOGNIZE request, rather than an attribute used for RECOGNIZER session=20 negotiation/update. The server should then respond with an accept or=20 reject response as it does today for other client requested parameter=20 values. Currently, the draft specification doesn't expose the MRCP=20 resource configurable parameters in the SDP. I don't think that enabling platform-specific formats facilitates the=20 adoption of a standard specification for speech resources. I believe = that=20 the specification should continue to address the required supported=20 formats and require new draft iterations including the updated=20 specifications. The updated draft iterations would continue to assist = with=20 potential client/server interoperability issues. Thanks, Brett Gavagni=20 WebSphere Voice Server Development=20 http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com 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 Wed Sep 28 14:08:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgM4-00064F-P3; Wed, 28 Sep 2005 14:08:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgM1-00063d-6U for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:08: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 OAA26362 for ; Wed, 28 Sep 2005 14:08:28 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgTV-0005L0-HA for speechsc@ietf.org; Wed, 28 Sep 2005 14:16:14 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Sep 2005 11:08:19 -0700 Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8SI8CVt022397; Wed, 28 Sep 2005 11:08:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] MRCPv2 Pronunciation support Date: Wed, 28 Sep 2005 11:08:15 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C4A05D6@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] MRCPv2 Pronunciation support Thread-Index: AcW9JvpzxCNZv2YgTyarq5vEdeSFEAHLpDLw From: "Shanmugham, Saravanan" To: "Brett Gavagni" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org A couple of somments=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Brett Gavagni Sent: Monday, September 19, 2005 7:29 AM To: speechsc@ietf.org Subject: [Speechsc] MRCPv2 Pronunciation support =20 How would an MRCP client query/determine that a list of=20 words do not belong to the base dictionary for a=20 SYNTHESIZER resource? I think this should be addressed by gaining HTTP access to the default pronunciation lexicon document of the synthesizer. And hence would be accessed outside of MRCPv2.=20 The format of this document is outside the scope of the MRCP specification and should be left to the W3C. The PLS draft you are refering to being one of them. I can add a reference to it as a future possibility, since the PLS draft is still in working draft form. Sarvi =20 How would the MRCP client retrieve the default generated=20 pronunciation for a single word or list of words,=20 especially when an in-line or externally referenced=20 lexicon specified in a DEFINE-LEXICON request could define=20 a large number of pronunciations? =20 Finally, why doesn't the MRCPv2 specification reference=20 the PLS draft as a standard for pronunciation support? Pronunciation Lexicon Specification (PLS) Version 1.0 -=20 http://www.w3.org/TR/pronunciation-lexicon/ =20 Thanks, =20 Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Sep 28 14:18:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgPA-00075j-Vx; Wed, 28 Sep 2005 14:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgP7-000747-KT for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:11: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 OAA26576 for ; Wed, 28 Sep 2005 14:11:40 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgWc-0005QW-Ve for speechsc@ietf.org; Wed, 28 Sep 2005 14:19:27 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 28 Sep 2005 11:11:32 -0700 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 j8SIBRuk011574; Wed, 28 Sep 2005 11:11:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Voice-category header still in spec Date: Wed, 28 Sep 2005 11:11:28 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C4A05D8@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Voice-category header still in spec Thread-Index: AcW/f0eSJaXZgQfRTkO+8pJi3ElsZQE2LnCA From: "Shanmugham, Saravanan" To: "Baggia Paolo" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Will remove. Thx, Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Baggia Paolo Sent: Thursday, September 22, 2005 7:10 AM To: speechsc@ietf.org Cc: Manzone Vittorio; Bergallo Patrizio; Baggia Paolo Subject: [Speechsc] Voice-category header still in spec =20 Hi,=20 =20 revision -07 still contains some reference to=20 Voice-Category header (see pagg. 27, 28). All of them inside examples only. =20 The Voice-Category header should be removed because it is=20 no more present in SSML 1.0, W3C Recommendation, 7 Sept.=20 2004 as described in Section "8.4.6 Voice-Parameters" of=20 MRVPv2 (pag. 45). =20 Regards, Paolo Baggia, Vittorio Manzone, Patrizio Bergallo, Loquendo =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 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Sep 28 14:37:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgnd-00059o-Lx; Wed, 28 Sep 2005 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgnc-000578-5g for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:37: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 OAA27857 for ; Wed, 28 Sep 2005 14:36:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgv7-00065t-KK for speechsc@ietf.org; Wed, 28 Sep 2005 14:44:45 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2005 11:36:53 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="215543430:sNHT31842478" 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 j8SIZpuq017717; Wed, 28 Sep 2005 11:36:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Recording Size and Duration: clarification needed Date: Wed, 28 Sep 2005 11:36:48 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C4A05EA@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] Recording Size and Duration: clarification needed Thread-Index: AcXAHmiFbjn4PjxoTyO/q9e4TsTz7AEPSaIQ From: "Shanmugham, Saravanan" To: "Baggia Paolo" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: Manzone Vittorio , Bergallo Patrizio X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Yes. Sarvi=20 -----Original Message----- From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Baggia Paolo Sent: Friday, September 23, 2005 2:09 AM To: speechsc@ietf.org Cc: Manzone Vittorio; Bergallo Patrizio; Baggia Paolo Subject: [Speechsc] Recording Size and Duration:=20 clarification needed =20 Hi Sarvi , =20 we would like to know the status of the discussion on the=20 question raised by Jenny see:=20 https://www.softarmor.com/roundup/speechsc/issue35 on size=20 and duration of audio recording. =20 Your last response to the thread was saying: =20 >>> [...] After a recognize the recorded audio/waveform is available as a URI. The request, I=20 believe was for the server to send these 2 pieces of=20 information in addition to the URI. We could address this=20 by allowing these fields to be sent in the same header=20 like the following. =20 Waveform-URI: ;size=3D743672; duration=3D2300 =20 Thx, Sarvi <<< =20 Will this be added to the next draft? Will it be added to Record-URI too? =20 Paolo, Vittori, Patrizio (Loquendo) =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 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Sep 28 14:37:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgnf-0005Bk-0v; Wed, 28 Sep 2005 14:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgnb-00055f-Hu; Wed, 28 Sep 2005 14:37: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 OAA27853; Wed, 28 Sep 2005 14:36:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgv4-00065t-U2; Wed, 28 Sep 2005 14:44:45 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2005 11:36:48 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="215543408:sNHT34167392" 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 j8SIZpuk017717; Wed, 28 Sep 2005 11:35:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] EMMA: Extensible MultiModalAnnotation markuplanguagesupport? Date: Wed, 28 Sep 2005 11:35:50 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C4A05E9@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [Speechsc] EMMA: Extensible MultiModalAnnotation markuplanguagesupport? Thread-Index: AcXBF7LZUgDMECDISG+EWsriadeA8ADQ3H0w From: "Shanmugham, Saravanan" To: "Brett Gavagni" , "Jerry Carter" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: "IETF SPEECHSC \(E-mail\)" , speechsc-bounces@ietf.org, 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 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 From speechsc-bounces@ietf.org Wed Sep 28 14:39:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgpo-0005aA-6i; Wed, 28 Sep 2005 14:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgpn-0005a5-08 for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:39: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 OAA27923 for ; Wed, 28 Sep 2005 14:39:13 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKgxH-00068X-BY for speechsc@ietf.org; Wed, 28 Sep 2005 14:47:00 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2005 11:39:02 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208,217"; a="215544128:sNHT43606488" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8SIcuVt000682; Wed, 28 Sep 2005 11:38:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [speechsc] Limitation: Client side cache controls Date: Wed, 28 Sep 2005 11:38:58 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C4A05EC@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [speechsc] Limitation: Client side cache controls Thread-Index: AcXCfxKyHEbcmoysSbiwxOt1lNP1SQB3MBOA From: "Shanmugham, Saravanan" To: "Dave Burke" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0638616758==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0638616758== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C45B.E3D6E149" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C45B.E3D6E149 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I like option 3 best. If there are no objections to this. I will fold that in. =20 Sarvi ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, September 26, 2005 2:30 AM To: speechsc@ietf.org Subject: [speechsc] Limitation: Client side cache controls =09 =09 I am wondering how to efficiently activate more than one grammar with different client-side cache controls. Imagine a VoiceXML case: =20 =20 I could put these in a RECOGNIZE request with a text/uri-list body part but I can only apply the Cache-Control: max-age header on the complete RECOGNIZE request, which is scoped over the entire request (and not per URI or indeed per body part). =20 Three workarounds I see: (1) Do a DEFINE-GRAMMAR per grammar with the appropriate Cache-Control: max-age (2) Redefine Cache-Control as a MIME-extension-field (naming it Content-Cache-Control).=20 Then at least I can put a single entry text/uri-list in each body part and use a single RECOGNIZE (3) Add a parameter to the URI e.g. ;max-age=3D0 ;max-age=3D100 =20 Option (1) is chatty when the MRCP client needs to activate several grammars (this is quite a common occurrence). Option (2) or Option (3) is preferable (save for the fact that we're supposed to be done with v2 of MRCP). =20 Dave =20 =20 ------_=_NextPart_001_01C5C45B.E3D6E149 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I like option 3 best. If there are no = objections to this. I=20 will fold that in.
 
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Monday, September 26, 2005 2:30 AM
To: = speechsc@ietf.org
Subject: [speechsc] Limitation: Client = side cache=20 controls

I am wondering how to = efficiently activate=20 more than one grammar with different client-side cache controls. = Imagine a=20 VoiceXML case:
 
<grammar src=3D"gram1.grxml"=20 maxage=3D"0"/>
<grammar src=3D"gram2.grxml=20 maxage=3D"100"/>
 
I could put these in a RECOGNIZE = request with=20 a text/uri-list body part but I can only apply the Cache-Control: = max-age=20 header on the complete RECOGNIZE request, which is scoped over the = entire=20 request (and not per URI or indeed per body = part).
 
Three workarounds I see:
 (1) Do a DEFINE-GRAMMAR per = grammar with=20 the appropriate Cache-Control: max-age
 (2) Redefine Cache-Control as a = MIME-extension-field (naming it Content-Cache-Control).
       = Then at=20 least I can put a single entry text/uri-list in each body part and use = a=20 single RECOGNIZE
(3) Add a parameter to the URI = e.g.
    =20 <gram1.grxml>;max-age=3D0
    =20 <gram2.grxml>;max-age=3D100
 
Option (1) is chatty when the MRCP = client needs=20 to activate several grammars (this is quite a common occurrence). = Option (2)=20 or Option (3) is preferable (save for the fact that we're supposed to = be done=20 with v2 of MRCP).
 
Dave
 
 
------_=_NextPart_001_01C5C45B.E3D6E149-- --===============0638616758== 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 --===============0638616758==-- From speechsc-bounces@ietf.org Wed Sep 28 14:48:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgyq-0007pt-Aa; Wed, 28 Sep 2005 14:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgyp-0007pl-7X for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:48: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 OAA28523 for ; Wed, 28 Sep 2005 14:48:33 -0400 (EDT) Received: from mail.vocalocity.net ([38.116.10.177] helo=smtp.vocalocity.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKh6I-0006NX-E7 for speechsc@ietf.org; Wed, 28 Sep 2005 14:56:20 -0400 Received: by smtp.vocalocity.net (Postfix, from userid 9999) id 65DAE16CDE6; Wed, 28 Sep 2005 14:48:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [speechsc] Limitation: Client side cache controls Date: Wed, 28 Sep 2005 14:48:07 -0400 Message-ID: <92E86BBD06161E4299A56009516472EDA1D9E0@gates.vcorp.vocalocity.net> Thread-Topic: [speechsc] Limitation: Client side cache controls Thread-Index: AcXCfxKyHEbcmoysSbiwxOt1lNP1SQB3MBOAAAA+ijA= From: "Jeff Haynie" To: "Shanmugham, Saravanan" , "Dave Burke" , X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on revelation.vcorp.vocalocity.net X-Spam-Status: No, score=-5.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_50_60,HTML_MESSAGE autolearn=ham version=3.0.4 X-Spam-Score: 0.9 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0477266953==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0477266953== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C45D.2B310302" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C45D.2B310302 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The only question I would have is should we also define the others as well such as max-stale for consistency? And for that matter, should we just allow any of the Cache-Control directions from RFC2616[1], section 14.9 as valid parameters per URI or just stick with the one's defined in VoiceXML? I would be fine with either. =20 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:39 PM To: Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls I like option 3 best. If there are no objections to this. I will fold that in. =20 Sarvi ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, September 26, 2005 2:30 AM To: speechsc@ietf.org Subject: [speechsc] Limitation: Client side cache controls =09 =09 I am wondering how to efficiently activate more than one grammar with different client-side cache controls. Imagine a VoiceXML case: =20 =20 I could put these in a RECOGNIZE request with a text/uri-list body part but I can only apply the Cache-Control: max-age header on the complete RECOGNIZE request, which is scoped over the entire request (and not per URI or indeed per body part). =20 Three workarounds I see: (1) Do a DEFINE-GRAMMAR per grammar with the appropriate Cache-Control: max-age (2) Redefine Cache-Control as a MIME-extension-field (naming it Content-Cache-Control).=20 Then at least I can put a single entry text/uri-list in each body part and use a single RECOGNIZE (3) Add a parameter to the URI e.g. ;max-age=3D0 ;max-age=3D100 =20 Option (1) is chatty when the MRCP client needs to activate several grammars (this is quite a common occurrence). Option (2) or Option (3) is preferable (save for the fact that we're supposed to be done with v2 of MRCP). =20 Dave =20 =20 ------_=_NextPart_001_01C5C45D.2B310302 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The only question I would have is should we = also define the=20 others as well such as max-stale for consistency? And for that matter, = should we=20 just allow any of the Cache-Control directions from RFC2616[1], section = 14.9 as=20 valid parameters per URI or just stick with the one's defined in=20 VoiceXML?  I would be fine with either.
 
[1] http://ww= w.w3.org/Protocols/rfc2616/rfc2616-sec14.html

=
From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham,=20 Saravanan
Sent: Wednesday, September 28, 2005 2:39 = PM
To:=20 Dave Burke; speechsc@ietf.org
Subject: RE: [speechsc] = Limitation:=20 Client side cache controls

I like option 3 best. If there are no = objections to this. I=20 will fold that in.
 
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Monday, September 26, 2005 2:30 AM
To: = speechsc@ietf.org
Subject: [speechsc] Limitation: Client = side cache=20 controls

I am wondering how to = efficiently activate=20 more than one grammar with different client-side cache controls. = Imagine a=20 VoiceXML case:
 
<grammar src=3D"gram1.grxml"=20 maxage=3D"0"/>
<grammar src=3D"gram2.grxml=20 maxage=3D"100"/>
 
I could put these in a RECOGNIZE = request with=20 a text/uri-list body part but I can only apply the Cache-Control: = max-age=20 header on the complete RECOGNIZE request, which is scoped over the = entire=20 request (and not per URI or indeed per body = part).
 
Three workarounds I see:
 (1) Do a DEFINE-GRAMMAR per = grammar with=20 the appropriate Cache-Control: max-age
 (2) Redefine Cache-Control as a = MIME-extension-field (naming it Content-Cache-Control).
       = Then at=20 least I can put a single entry text/uri-list in each body part and use = a=20 single RECOGNIZE
(3) Add a parameter to the URI = e.g.
    =20 <gram1.grxml>;max-age=3D0
    =20 <gram2.grxml>;max-age=3D100
 
Option (1) is chatty when the MRCP = client needs=20 to activate several grammars (this is quite a common occurrence). = Option (2)=20 or Option (3) is preferable (save for the fact that we're supposed to = be done=20 with v2 of MRCP).
 
Dave
 
 
------_=_NextPart_001_01C5C45D.2B310302-- --===============0477266953== 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 --===============0477266953==-- From speechsc-bounces@ietf.org Wed Sep 28 14:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgzg-0007yG-Qd; Wed, 28 Sep 2005 14:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgzf-0007xn-Ai; Wed, 28 Sep 2005 14:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28559; Wed, 28 Sep 2005 14:49:21 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKh74-0006Os-PL; Wed, 28 Sep 2005 14:57:08 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8SImW0l026145; Wed, 28 Sep 2005 14:48:32 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8SInict454558; Wed, 28 Sep 2005 12:49:44 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j8SIn6d2001475; Wed, 28 Sep 2005 12:49:06 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j8SIn6EJ001465; Wed, 28 Sep 2005 12:49:06 -0600 In-Reply-To: <03772D1EC8DE624A863058C75874A75C4A05E9@vtg-um-e2k6.sj21ad.cisco.com> To: "Shanmugham, Saravanan" MIME-Version: 1.0 Subject: RE: [Speechsc] EMMA: Extensible MultiModalAnnotation markuplanguagesupport? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Brett Gavagni Date: Wed, 28 Sep 2005 14:49:55 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 09/28/2005 12:49:57, Serialize complete at 09/28/2005 12:49:57 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: "IETF SPEECHSC \(E-mail\)" , speechsc-bounces@ietf.org, Jerry Carter , 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 Sounds good to me. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Shanmugham, Saravanan" 09/28/2005 02:35 PM To Brett Gavagni/West Palm Beach/IBM@IBMUS, "Jerry Carter" cc "IETF SPEECHSC \(E-mail\)" , , "Baggia Paolo" Subject RE: [Speechsc] EMMA: Extensible MultiModalAnnotation 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 From speechsc-bounces@ietf.org Wed Sep 28 14:54:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKh50-0001Rj-Cd; Wed, 28 Sep 2005 14:54:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKh4z-0001Re-1O for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:54: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 OAA28746 for ; Wed, 28 Sep 2005 14:54:55 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKhCT-0006Vt-CZ for speechsc@ietf.org; Wed, 28 Sep 2005 15:02:43 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2005 11:54:46 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208,217"; a="215550511:sNHT46771280" Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com [171.70.93.77]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8SIsdVt004205; Wed, 28 Sep 2005 11:54:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [speechsc] Limitation: Client side cache controls Date: Wed, 28 Sep 2005 11:54:43 -0700 Message-ID: <03772D1EC8DE624A863058C75874A75C4A05F0@vtg-um-e2k6.sj21ad.cisco.com> Thread-Topic: [speechsc] Limitation: Client side cache controls Thread-Index: AcXCfxKyHEbcmoysSbiwxOt1lNP1SQB3MBOAAAA+ijAAAE3oIA== From: "Shanmugham, Saravanan" To: "Jeff Haynie" , "Dave Burke" , X-Spam-Score: 0.9 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1857078667==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1857078667== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C45E.16FDD391" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C45E.16FDD391 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Not all. I would be fine with just the subset of Cache-Control headers defined in the MRCPv2 specification. =20 =20 Sarvi ________________________________ From: Jeff Haynie [mailto:jhaynie@vocalocity.net]=20 Sent: Wednesday, September 28, 2005 11:48 AM To: Shanmugham, Saravanan; Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls =09 =09 The only question I would have is should we also define the others as well such as max-stale for consistency? And for that matter, should we just allow any of the Cache-Control directions from RFC2616[1], section 14.9 as valid parameters per URI or just stick with the one's defined in VoiceXML? I would be fine with either. =20 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:39 PM To: Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls =09 =09 I like option 3 best. If there are no objections to this. I will fold that in. =20 Sarvi ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, September 26, 2005 2:30 AM To: speechsc@ietf.org Subject: [speechsc] Limitation: Client side cache controls =09 =09 I am wondering how to efficiently activate more than one grammar with different client-side cache controls. Imagine a VoiceXML case: =20 =20 I could put these in a RECOGNIZE request with a text/uri-list body part but I can only apply the Cache-Control: max-age header on the complete RECOGNIZE request, which is scoped over the entire request (and not per URI or indeed per body part). =20 Three workarounds I see: (1) Do a DEFINE-GRAMMAR per grammar with the appropriate Cache-Control: max-age (2) Redefine Cache-Control as a MIME-extension-field (naming it Content-Cache-Control).=20 Then at least I can put a single entry text/uri-list in each body part and use a single RECOGNIZE (3) Add a parameter to the URI e.g. ;max-age=3D0 ;max-age=3D100 =20 Option (1) is chatty when the MRCP client needs to activate several grammars (this is quite a common occurrence). Option (2) or Option (3) is preferable (save for the fact that we're supposed to be done with v2 of MRCP). =20 Dave =20 =20 ------_=_NextPart_001_01C5C45E.16FDD391 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Not all. I would be fine with just the subset = of=20 Cache-Control headers defined in the MRCPv2 = specification.
 
 
Sarvi

From: Jeff Haynie=20 [mailto:jhaynie@vocalocity.net]
Sent: Wednesday, September = 28, 2005=20 11:48 AM
To: Shanmugham, Saravanan; Dave Burke;=20 speechsc@ietf.org
Subject: RE: [speechsc] Limitation: Client = side=20 cache controls

The only question I = would have is=20 should we also define the others as well such as max-stale for = consistency?=20 And for that matter, should we just allow any of the Cache-Control = directions=20 from RFC2616[1], section 14.9 as valid parameters per URI or just = stick=20 with the one's defined in VoiceXML?  I would be fine with=20 either.
 
[1] http://ww= w.w3.org/Protocols/rfc2616/rfc2616-sec14.html

=
From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham,=20 Saravanan
Sent: Wednesday, September 28, 2005 2:39 = PM
To:=20 Dave Burke; speechsc@ietf.org
Subject: RE: [speechsc] = Limitation:=20 Client side cache controls

I like option 3 best. If there are no = objections to this.=20 I will fold that in.
 
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Monday, September 26, 2005 2:30 = AM
To:=20 speechsc@ietf.org
Subject: [speechsc] Limitation: Client = side=20 cache controls

I am wondering how to = efficiently activate=20 more than one grammar with different client-side cache controls. = Imagine a=20 VoiceXML case:
 
<grammar src=3D"gram1.grxml"=20 maxage=3D"0"/>
<grammar src=3D"gram2.grxml=20 maxage=3D"100"/>
 
I could put these in a RECOGNIZE = request with=20 a text/uri-list body part but I can only apply the = Cache-Control:=20 max-age header on the complete RECOGNIZE request, which is scoped = over the=20 entire request (and not per URI or indeed per body=20 part).
 
Three workarounds I = see:
 (1) Do a DEFINE-GRAMMAR per = grammar with=20 the appropriate Cache-Control: max-age
 (2) Redefine Cache-Control as = a=20 MIME-extension-field (naming it Content-Cache-Control). =
       Then at=20 least I can put a single entry text/uri-list in each body part and = use a=20 single RECOGNIZE
(3) Add a parameter to the URI=20 e.g.
    =20 <gram1.grxml>;max-age=3D0
    =20 <gram2.grxml>;max-age=3D100
 
Option (1) is chatty when the MRCP = client needs=20 to activate several grammars (this is quite a common occurrence). = Option (2)=20 or Option (3) is preferable (save for the fact that we're supposed = to be=20 done with v2 of MRCP).
 
Dave
 
 
------_=_NextPart_001_01C5C45E.16FDD391-- --===============1857078667== 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 --===============1857078667==-- From speechsc-bounces@ietf.org Wed Sep 28 14:55:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKh5v-0001k0-Cu; Wed, 28 Sep 2005 14:55:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKh5t-0001jq-6w for speechsc@megatron.ietf.org; Wed, 28 Sep 2005 14:55: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 OAA28771 for ; Wed, 28 Sep 2005 14:55:51 -0400 (EDT) Received: from mail.vocalocity.net ([38.116.10.177] helo=smtp.vocalocity.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKhDO-0006X2-Lg for speechsc@ietf.org; Wed, 28 Sep 2005 15:03:39 -0400 Received: by smtp.vocalocity.net (Postfix, from userid 9999) id E669116CDE6; Wed, 28 Sep 2005 14:55:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [speechsc] Limitation: Client side cache controls Date: Wed, 28 Sep 2005 14:55:40 -0400 Message-ID: <92E86BBD06161E4299A56009516472EDA1D9E1@gates.vcorp.vocalocity.net> Thread-Topic: [speechsc] Limitation: Client side cache controls Thread-Index: AcXCfxKyHEbcmoysSbiwxOt1lNP1SQB3MBOAAAA+ijAAAE3oIAAACjsQ From: "Jeff Haynie" To: "Shanmugham, Saravanan" , "Jeff Haynie" , "Dave Burke" , X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on revelation.vcorp.vocalocity.net X-Spam-Status: No, score=-5.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE autolearn=ham version=3.0.4 X-Spam-Score: 0.9 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1493748716==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1493748716== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C45E.38CBA433" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C45E.38CBA433 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that makes perfect sense than. ________________________________ From: Shanmugham, Saravanan [mailto:sarvi@cisco.com]=20 Sent: Wednesday, September 28, 2005 2:55 PM To: Jeff Haynie; Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls Not all. I would be fine with just the subset of Cache-Control headers defined in the MRCPv2 specification. =20 =20 Sarvi ________________________________ From: Jeff Haynie [mailto:jhaynie@vocalocity.net]=20 Sent: Wednesday, September 28, 2005 11:48 AM To: Shanmugham, Saravanan; Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls =09 =09 The only question I would have is should we also define the others as well such as max-stale for consistency? And for that matter, should we just allow any of the Cache-Control directions from RFC2616[1], section 14.9 as valid parameters per URI or just stick with the one's defined in VoiceXML? I would be fine with either. =20 [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:39 PM To: Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls =09 =09 I like option 3 best. If there are no objections to this. I will fold that in. =20 Sarvi ________________________________ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, September 26, 2005 2:30 AM To: speechsc@ietf.org Subject: [speechsc] Limitation: Client side cache controls =09 =09 I am wondering how to efficiently activate more than one grammar with different client-side cache controls. Imagine a VoiceXML case: =20 =20 I could put these in a RECOGNIZE request with a text/uri-list body part but I can only apply the Cache-Control: max-age header on the complete RECOGNIZE request, which is scoped over the entire request (and not per URI or indeed per body part). =20 Three workarounds I see: (1) Do a DEFINE-GRAMMAR per grammar with the appropriate Cache-Control: max-age (2) Redefine Cache-Control as a MIME-extension-field (naming it Content-Cache-Control).=20 Then at least I can put a single entry text/uri-list in each body part and use a single RECOGNIZE (3) Add a parameter to the URI e.g. ;max-age=3D0 ;max-age=3D100 =20 Option (1) is chatty when the MRCP client needs to activate several grammars (this is quite a common occurrence). Option (2) or Option (3) is preferable (save for the fact that we're supposed to be done with v2 of MRCP). =20 Dave =20 =20 ------_=_NextPart_001_01C5C45E.38CBA433 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think that makes perfect sense=20 than.

From: Shanmugham, Saravanan=20 [mailto:sarvi@cisco.com]
Sent: Wednesday, September 28, 2005 = 2:55=20 PM
To: Jeff Haynie; Dave Burke; = speechsc@ietf.org
Subject:=20 RE: [speechsc] Limitation: Client side cache = controls

Not all. I would be fine with just the subset = of=20 Cache-Control headers defined in the MRCPv2 = specification.
 
 
Sarvi

From: Jeff Haynie=20 [mailto:jhaynie@vocalocity.net]
Sent: Wednesday, September = 28, 2005=20 11:48 AM
To: Shanmugham, Saravanan; Dave Burke;=20 speechsc@ietf.org
Subject: RE: [speechsc] Limitation: Client = side=20 cache controls

The only question I = would have is=20 should we also define the others as well such as max-stale for = consistency?=20 And for that matter, should we just allow any of the Cache-Control = directions=20 from RFC2616[1], section 14.9 as valid parameters per URI or just = stick=20 with the one's defined in VoiceXML?  I would be fine with=20 either.
 
[1] http://ww= w.w3.org/Protocols/rfc2616/rfc2616-sec14.html

=
From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham,=20 Saravanan
Sent: Wednesday, September 28, 2005 2:39 = PM
To:=20 Dave Burke; speechsc@ietf.org
Subject: RE: [speechsc] = Limitation:=20 Client side cache controls

I like option 3 best. If there are no = objections to this.=20 I will fold that in.
 
Sarvi

From: speechsc-bounces@ietf.org=20 [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave=20 Burke
Sent: Monday, September 26, 2005 2:30 = AM
To:=20 speechsc@ietf.org
Subject: [speechsc] Limitation: Client = side=20 cache controls

I am wondering how to = efficiently activate=20 more than one grammar with different client-side cache controls. = Imagine a=20 VoiceXML case:
 
<grammar src=3D"gram1.grxml"=20 maxage=3D"0"/>
<grammar src=3D"gram2.grxml=20 maxage=3D"100"/>
 
I could put these in a RECOGNIZE = request with=20 a text/uri-list body part but I can only apply the = Cache-Control:=20 max-age header on the complete RECOGNIZE request, which is scoped = over the=20 entire request (and not per URI or indeed per body=20 part).
 
Three workarounds I = see:
 (1) Do a DEFINE-GRAMMAR per = grammar with=20 the appropriate Cache-Control: max-age
 (2) Redefine Cache-Control as = a=20 MIME-extension-field (naming it Content-Cache-Control). =
       Then at=20 least I can put a single entry text/uri-list in each body part and = use a=20 single RECOGNIZE
(3) Add a parameter to the URI=20 e.g.
    =20 <gram1.grxml>;max-age=3D0
    =20 <gram2.grxml>;max-age=3D100
 
Option (1) is chatty when the MRCP = client needs=20 to activate several grammars (this is quite a common occurrence). = Option (2)=20 or Option (3) is preferable (save for the fact that we're supposed = to be=20 done with v2 of MRCP).
 
Dave
 
 
------_=_NextPart_001_01C5C45E.38CBA433-- --===============1493748716== 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 --===============1493748716==-- From speechsc-bounces@ietf.org Thu Sep 29 04:42:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKu0D-0001tm-Fs; Thu, 29 Sep 2005 04:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKu0B-0001th-Vf for speechsc@megatron.ietf.org; Thu, 29 Sep 2005 04:42:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26805 for ; Thu, 29 Sep 2005 04:42:49 -0400 (EDT) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKu7o-000329-Fu for speechsc@ietf.org; Thu, 29 Sep 2005 04:50:45 -0400 Received: from daburkewxp (unknown [10.0.0.202]) by mail.voxpilot.com (Postfix) with ESMTP id 9F757214041; Thu, 29 Sep 2005 08:42:39 +0000 (GMT) Message-ID: <0a4801c5c4d1$bff7e370$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: "Jeff Haynie" , "Shanmugham, Saravanan" , References: <92E86BBD06161E4299A56009516472EDA1D9E1@gates.vcorp.vocalocity.net> Subject: Re: [speechsc] Limitation: Client side cache controls Date: Thu, 29 Sep 2005 09:42:39 +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: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Agreed. Minor additional point: We should specify that parameters on the text/uri-list take precedence over the equivalent MRCP headers (applies to ;weight / Weight: also). Dave ----- Original Message ----- From: Jeff Haynie To: Shanmugham, Saravanan ; Jeff Haynie ; Dave Burke ; speechsc@ietf.org Sent: Wednesday, September 28, 2005 7:55 PM Subject: RE: [speechsc] Limitation: Client side cache controls I think that makes perfect sense than. From: Shanmugham, Saravanan [mailto:sarvi@cisco.com] Sent: Wednesday, September 28, 2005 2:55 PM To: Jeff Haynie; Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls Not all. I would be fine with just the subset of Cache-Control headers defined in the MRCPv2 specification. Sarvi From: Jeff Haynie [mailto:jhaynie@vocalocity.net] Sent: Wednesday, September 28, 2005 11:48 AM To: Shanmugham, Saravanan; Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls The only question I would have is should we also define the others as well such as max-stale for consistency? And for that matter, should we just allow any of the Cache-Control directions from RFC2616[1], section 14.9 as valid parameters per URI or just stick with the one's defined in VoiceXML? I would be fine with either. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Shanmugham, Saravanan Sent: Wednesday, September 28, 2005 2:39 PM To: Dave Burke; speechsc@ietf.org Subject: RE: [speechsc] Limitation: Client side cache controls I like option 3 best. If there are no objections to this. I will fold that in. Sarvi From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Dave Burke Sent: Monday, September 26, 2005 2:30 AM To: speechsc@ietf.org Subject: [speechsc] Limitation: Client side cache controls I am wondering how to efficiently activate more than one grammar with different client-side cache controls. Imagine a VoiceXML case: I could put these in a RECOGNIZE request with a text/uri-list body part but I can only apply the Cache-Control: max-age header on the complete RECOGNIZE request, which is scoped over the entire request (and not per URI or indeed per body part). Three workarounds I see: (1) Do a DEFINE-GRAMMAR per grammar with the appropriate Cache-Control: max-age (2) Redefine Cache-Control as a MIME-extension-field (naming it Content-Cache-Control). Then at least I can put a single entry text/uri-list in each body part and use a single RECOGNIZE (3) Add a parameter to the URI e.g. ;max-age=0 ;max-age=100 Option (1) is chatty when the MRCP client needs to activate several grammars (this is quite a common occurrence). Option (2) or Option (3) is preferable (save for the fact that we're supposed to be done with v2 of MRCP). Dave _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Thu Sep 29 04:57:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKuE8-0004iA-UN; Thu, 29 Sep 2005 04:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKuE7-0004i5-1u for speechsc@megatron.ietf.org; Thu, 29 Sep 2005 04:57: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 EAA27355 for ; Thu, 29 Sep 2005 04:57:12 -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 1EKuLi-0003NL-Kv for speechsc@ietf.org; Thu, 29 Sep 2005 05:05:08 -0400 Received: from daburkewxp (unknown [10.0.0.202]) by mail.voxpilot.com (Postfix) with ESMTP id A1ECC214041 for ; Thu, 29 Sep 2005 08:57:11 +0000 (GMT) Message-ID: <0a6d01c5c4d3$c7ad15c0$0a01a8c0@db01.voxpilot.com> From: "Dave Burke" To: Date: Thu, 29 Sep 2005 09:57:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Subject: [Speechsc] Section 6.2.11 (Cache-Control) bugs X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org Hi Sarvi, I had a closer look through section 6.2.11 and found some bugs / issues. Here is a list of them with proposed resolutions. ----------------------------------------------------------------------------------------------- A. Some subtleties with HTTP request max-age, max-stale, min-fresh: 1 max-age and min-fresh and max-stale can take a value of "not present". 2 max-stale value of "not present" is equivalent to max-stale=0 3 max-stale can take a value of "present but no value" We're not allowing for 1 in the BNF nor are we allowing for the GET-PARAMs results syntax when for value "not present". Suggest: cache-directive = "max-age" ["=" delta-seconds] / "max-stale" [ "=" delta-seconds ] / "min-fresh" ["=" delta-seconds] If a SET-PARAMS includes max-age or max-stale or min-fresh with no value, it should unset it (i.e. value of "not present"). There is no neat way to implement 3. So I suggest removing the sentence/feature for max-stale, i.e. delete "If no value is assigned to max-stale, then the client is willing to accept a stale response of any age." In practice, this behaviour can be obtained by setting max-stale to a high number. Some paradigms, e.g. VoiceXML, don't even support "no value". ----------------------------------------------------------------------------------------------- B. By default, max-age and min-fresh and max-stale should have no value (or optionally max-stale could be 0). This gives normal user-agent behaviour one expects. These defaults should be specified. ----------------------------------------------------------------------------------------------- C. I find the following text (6.2.11) problematic: "In particular, the "expires" and "cache-control" headers of the cached URI or document MUST be honored and take precedence over the Cache-Control defaults set by this header." The settings in MRCP for Cache-Control correspond to values used in the HTTP _request_ and are independent of the HTTP response and hence what is being termed the "headers of the cached URI". I recommend just deleting this sentence (which is anyway contradicting the last sentence in this section). ----------------------------------------------------------------------------------------------- D. The text for min-fresh talks about a "server" but here it means "HTTP server" and not MRCP server, which is very confusing indeed! Also, the last sentence appears inaccurate and superfluous. Suggested text improvment: "min-fresh: Indicates that the MRCP client is willing to allow the MRCP server to accept a HTTP server response with cached data whose expiration is no less than its current age plus the specified time in seconds. That is, the MRCP client wants the MRCP server to request a response from the HTTP server that will still be fresh for at least the specified number of seconds." ----------------------------------------------------------------------------------------------- E. Change: "The cache-control directives are used to define the default caching algorithms on the server for the session or request." to "The cache-control directives are used to override the default cache expirations on the MRCP server for the session or request." ----------------------------------------------------------------------------------------------- The rest of the section looks fine. Thanks and keep up the good work, Dave _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc