From mailman-bounces@ietf.org Fri Oct 1 08:07:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22159 for ; Fri, 1 Oct 2004 08:07:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMKM-0005gy-DO for speechsc-web-archive@ietf.org; Fri, 01 Oct 2004 08:15:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJwP-00066p-7B for speechsc-web-archive@ietf.org; Fri, 01 Oct 2004 05:43:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: speechsc-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:17:28 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for speechsc-web-archive@ietf.org: List Password // URL ---- -------- speechsc@ietf.org mHtT https://www1.ietf.org/mailman/options/speechsc/speechsc-web-archive%40ietf.org From speechsc-bounces@ietf.org Tue Oct 5 13:43:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19240 for ; Tue, 5 Oct 2004 13:43:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEtUT-0007L3-2w for speechsc-web-archive@ietf.org; Tue, 05 Oct 2004 13:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtBX-00051f-Vo; Tue, 05 Oct 2004 13:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEt6d-0004Ek-Bn for speechsc@megatron.ietf.org; Tue, 05 Oct 2004 13:28:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18237 for ; Tue, 5 Oct 2004 13:28:04 -0400 (EDT) Received: from mx1.scansoft.com ([198.71.64.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEtFy-00052r-0D for speechsc@ietf.org; Tue, 05 Oct 2004 13:37:46 -0400 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx1 with trend_isnt_name_B; Tue, 05 Oct 2004 13:34:41 -0400 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Oct 2004 13:27:33 -0400 Message-ID: From: "Reifenrath, Klaus" To: speechsc@ietf.org Subject: RE: [Speechsc] XML schema for verification result Date: Tue, 5 Oct 2004 13:27:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "'zilca@us.ibm.com'" , "'Sarvi Shanmugham'" , "'forgues@nuance.com'" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi group, aside from the discussion which schema we should use, I like to resolve the open issues concerning the verification result elements: According to the current spec the element is mandatory also for training results. What is the meaning of a verification score in the context of training (see 4))? What is your opinion on 2) and 3)? Regards, Klaus -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] Sent: Mittwoch, 21. Juli 2004 18:11 To: 'Sarvi Shanmugham'; Daniel Burnett Cc: speechsc@ietf.org Subject: [Speechsc] XML schema for verification result Hi Sarvi and Dan, I created a XML schema for the verification result. Like the RelaxNG schema of Dan it can be improved. I also adapted the sample results of Dan. Compared to Dan's proposal I changed the following: 1) Because of XML Schema limitations I need to distinguish between verification and training results. 2) The element is no longer child element of the element, because in case of multi-verification, the value of num-frames is the same for all voiceprints. 3) The and are child elements of the element. 4) For training results the is now optional. I also added a new optional parameter for training results: consistent. 5) The element has 2 mandatory attributes: repository-uri and identifier 6) Currently I included the element of NLSML, to allow validation of sample results with validation tools. But I still do not see the benefit of using NLSML for verification results, because a speaker verification engine is not a semantic interpretation component. Suggestions for improvement are welcome! Klaus <> <> _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Oct 6 07:35:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14014 for ; Wed, 6 Oct 2004 07:35:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAEF-0002uw-6d for speechsc-web-archive@ietf.org; Wed, 06 Oct 2004 07:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFA3z-0004ZR-Vu; Wed, 06 Oct 2004 07:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFA04-0003l9-Cz for speechsc@megatron.ietf.org; Wed, 06 Oct 2004 07:30:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13467 for ; Wed, 6 Oct 2004 07:30:26 -0400 (EDT) Received: from mx1.scansoft.com ([198.71.64.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFA9Y-0002eG-6M for speechsc@ietf.org; Wed, 06 Oct 2004 07:40:16 -0400 Received: from pb-exchcon.pb.scansoft.com ([10.1.4.73]) by mx1 with trend_isnt_name_B; Wed, 06 Oct 2004 07:37:04 -0400 Received: by pb-exchcon.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Oct 2004 07:29:55 -0400 Message-ID: From: "Reifenrath, Klaus" To: "'Eric Burger'" Subject: RE: [Speechsc] FW: Liaison statement from IETF SPEECHSC WG to W3C Multimedia Interaction WG Date: Wed, 6 Oct 2004 07:29:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: "'speechsc@ietf.org'" X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Hi Eric, what are the next steps? As you pointed out, the published NLSML is only close to what we use in MRCP today (even closer is the unpublished version of NLSML that is referenced in the current spec, which contains DTD and XML Schema), but the differences are not documented. Will you come up with a first version of "MRCP-NLSML" (for ASR and SV results) that can be reviewed by the group or are you waiting for a volunteer to do that? Klaus -----Original Message----- From: Eric Burger [mailto:eburger@brooktrout.com] Sent: Mittwoch, 29. September 2004 22:55 To: speechsc@ietf.org Subject: [Speechsc] FW: Liaison statement from IETF SPEECHSC WG to W3C Multimedia Int eraction WG Formal response from W3C. > -----Original Message----- > From: Deborah Dahl [mailto:dahl@conversational-technologies.com] > Sent: Wednesday, September 29, 2004 4:15 PM > To: 'Leslie Daigle'; 'Dave Raggett Dave Raggett' > Cc: 'Eric Burger'; 'Dave Oran'; 'Allison Mankin'; 'Peterson, Jon'; > statements@ietf.org; Martin Duerst; Max Froumentin; Philipp > Hoschka; Wu > Chou; johnston@research.att.com > Subject: RE: Liaison statement from IETF SPEECHSC WG to W3C Multimedia > Interaction WG > > > Leslie, > Thank you for the liason statement and for your interest in EMMA. > We have just published the third Working Draft of EMMA. Our > current plan is to publish a Last Call Working Draft in December, > and a Candidate Recommendation in June, 2005. We would be very > grateful for any comments or feedback you might have on the > current Working > Draft (http://www.w3.org/TR/emma/). This kind of feedback > should be very > useful in both helping us progress EMMA through the W3C Recommendation > process, > as well as in insuring that it becomes a useful and accepted > standard which > meets the requirements of the speech processing industry. The > overlapping > membership between the W3C Multimodal Interaction Working Group and > the MRCPv2 group should be helpful in facilitating > communication across > groups. > > Although NLSML had only reached a 1st WD status, it > has nonetheless proved a useful interim specification. We > hope that MRCPv2 can be revised to normatively reference > EMMA in preference to NLSML once EMMA reaches Candidate > Recommendation. > > Note that the W3C and the IETF have a formal liason process, so I > am copying Martin Duerst, who is responsible for this liason on the > W3C side, on this message. I am also copying Wu Chao and Michael > Johnston, the primary editors of EMMA. > > Best wishes on your work with MRCPv2, and looking forward to > continued interaction with your group. > > regards, > > Debbie Dahl > Chair, W3C Multimodal Interaction Working Group > > > > -----Original Message----- > > From: Leslie Daigle [mailto:leslie@thinkingcat.com] > > Sent: Tuesday, September 28, 2004 3:55 PM > > To: Deborah Dahl Deborah Dahl; Dave Raggett Dave Raggett > > Cc: Eric Burger; Dave Oran; Allison Mankin; Peterson, Jon; > > statements@ietf.org > > Subject: Liaison statement from IETF SPEECHSC WG to W3C > > Multimedia Interaction WG > > > > > > > > Please find below a liaison statement from the IETF SPEECHSC working > > group to the W3C Multimedia Interaction work group. > > > > Best, > > Leslie Daigle, > > IETF liaison to the W3C. > > > > ========== > > > > > > Title: SPEECHSC Requirements for W3C MMI Standards > > Source: IETF SPEECHSC Work Group > > To: W3C Multimedia Interaction Work Group > > > > Contact Persons: > > Name: Eric Burger > > Tel. Number: +1 603 890 7587 > > E-Mail: eburger@brooktrout.com > > Name: Dave Oran > > Tel. Number: +1 978 264 2048 > > E-Mail: oran@cisco.com > > > > > > 1. Overall Description: > > The speechsc Work Group is tasked with developing protocols > to support > > distributed media processing of audio streams. The focus of > > this working > > group is to develop protocols to support ASR, TTS, and SV. > > The working > > group will only focus on the secure distributed control of > > these servers. > > > > The full description of the SPEECSC Charter, including documents and > > milestones, can be found here: > > http://ietf.org/html.charters/speechsc-charter.html > > > > A supplemental work group web page can be found here: > > http://flyingfox.snowshore.com/i-d/speechsc > > > > > > 2. Background to Request > > The consensus of the SPEECHSC work group is that EMMA is > the preferred > > encoding for speech recognition results for MRCPv2 transport. > > > > It is our plan to require MRCPv2-conforming protocol > > endpoints to support > > EMMA (currently referenced at ). > > This will > > occur once EMMA reaches Candidate Recommendation status. > > However, it is our > > understanding that this will not happen until mid-2005. > > > > Because there is a demand for MRCPv2 today, we need a > > normative reference to > > a recognition markup. The consensus of the SPEECHSC work > > group is that > > NLSML (currently referenced at > > ) is closest > > to our needs. However, there is no normative (Candidate > > Recommendation or > > later) for NLSML. > > > > Until the W3C publishes EMMA as a Candidate Recommendation, > > MRCPv2 endpoints > > will be required to support a different markup. However, > once EMMA is > > published, it will be the default, required markup for > > returning recognition > > results. This markup will not be called NLSML. > > > > MRCPv2 will include a negotiation mechanism such that > > follow-on markups to > > EMMA will be automatically supported by the protocol. > > > > > > 3. Requests to W3C: > > A) Please keep us informed to the progress of EMMA. > > B) Please progress EMMA to Candidate Recommendation as fast > > as possible. > > C) It is our intention to reference the NLSML specification, > > per the W3C > > copyright rules specified in the NLSML specification, found at > > > > > > -- > > > > ------------------------------------------------------------------- > > "Reality: > > Yours to discover." > > -- ThinkingCat > > Leslie Daigle > > leslie@thinkingcat.com > > ------------------------------------------------------------------- > > > > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Fri Oct 8 08:59:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21029 for ; Fri, 8 Oct 2004 08:59:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFuUy-00064n-0o for speechsc-web-archive@ietf.org; Fri, 08 Oct 2004 09:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFuKC-0004cd-Ix; Fri, 08 Oct 2004 08:58:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFgiS-0005Dj-JN for speechsc@megatron.ietf.org; Thu, 07 Oct 2004 18:26:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05451 for ; Thu, 7 Oct 2004 18:26:25 -0400 (EDT) Received: from 206-169-193-40.gen.twtelecom.net ([206.169.193.40] helo=ProgressiveComputingLLC.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFgsF-0000np-3Q for speechsc@ietf.org; Thu, 07 Oct 2004 18:36:35 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speechsc] FW: Liaison statement from IETF SPEECHSC WG to W3CMultimedia Interaction WG X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 7 Oct 2004 15:25:47 -0700 Message-ID: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02213DFA@svr-exc.domain.com> Thread-Topic: [Speechsc] FW: Liaison statement from IETF SPEECHSC WG to W3CMultimedia Interaction WG thread-index: AcSrl3vhEoyR5tHpSMa96MiUBwyi1gBJLuMz From: "Thomas Gal" To: "Reifenrath, Klaus" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Fri, 08 Oct 2004 08:58:19 -0400 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1984642137==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 --===============1984642137== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBlbWFpbGVkIGRpYW5lIGFuZCBzaGUgZm9yd2FyZGVkIGl0IHRvIHRoZSBXM0MgbWFuYWdlbWVu dCBhIGNvdXBsZSB3ZWVrcyBhZ28gYW5kIEkndmUgbm90IGhlYXJkIGJhY2ssIGJ1dCBJIHJlYWxp emUgc29tZW9uZSBlbHNlIGhhZCBhbHJlYWR5IGRvbmUgdGhpcy4gSSdtIGhhcHB5IHRvIHB1bGwg aXQgb3V0IG9mIHRoZSBzcGVjIGFuZCB3b3JrIGl0IGludG8gb3VycyB3aXRoIG91ciBtYXRobWV0 aWNpYW4vZ3JhbW1hciBleHBlcnQgaWYgdGhpcyBpcyBkZXNpcmVkLg0KIA0KVG9tDQoNCgktLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBzcGVlY2hzYy1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBSZWlmZW5yYXRoLCBLbGF1cyANCglTZW50OiBXZWQgMTAvNi8yMDA0IDQ6 MjkgQU0gDQoJVG86ICdFcmljIEJ1cmdlcicgDQoJQ2M6ICdzcGVlY2hzY0BpZXRmLm9yZycgDQoJ U3ViamVjdDogUkU6IFtTcGVlY2hzY10gRlc6IExpYWlzb24gc3RhdGVtZW50IGZyb20gSUVURiBT UEVFQ0hTQyBXRyB0byBXM0NNdWx0aW1lZGlhIEludGVyYWN0aW9uIFdHDQoJDQoJDQoNCglIaSBF cmljLA0KCQ0KCXdoYXQgYXJlIHRoZSBuZXh0IHN0ZXBzPyBBcyB5b3UgcG9pbnRlZCBvdXQsIHRo ZSBwdWJsaXNoZWQgTkxTTUwgaXMgb25seQ0KCWNsb3NlIHRvIHdoYXQgd2UgdXNlIGluIE1SQ1Ag dG9kYXkgKGV2ZW4gY2xvc2VyIGlzIHRoZSB1bnB1Ymxpc2hlZCB2ZXJzaW9uDQoJb2YgTkxTTUwg dGhhdCBpcyByZWZlcmVuY2VkIGluIHRoZSBjdXJyZW50IHNwZWMsIHdoaWNoIGNvbnRhaW5zIERU RCBhbmQgWE1MDQoJU2NoZW1hKSwgYnV0IHRoZSBkaWZmZXJlbmNlcyBhcmUgbm90IGRvY3VtZW50 ZWQuDQoJDQoJV2lsbCB5b3UgY29tZSB1cCB3aXRoIGEgZmlyc3QgdmVyc2lvbiBvZiAiTVJDUC1O TFNNTCIgKGZvciBBU1IgYW5kIFNWDQoJcmVzdWx0cykgdGhhdCBjYW4gYmUgcmV2aWV3ZWQgYnkg dGhlIGdyb3VwIG9yIGFyZSB5b3Ugd2FpdGluZyBmb3IgYQ0KCXZvbHVudGVlciB0byBkbyB0aGF0 Pw0KCQ0KCUtsYXVzDQoJDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBFcmlj IEJ1cmdlciBbbWFpbHRvOmVidXJnZXJAYnJvb2t0cm91dC5jb21dDQoJU2VudDogTWl0dHdvY2gs IDI5LiBTZXB0ZW1iZXIgMjAwNCAyMjo1NQ0KCVRvOiBzcGVlY2hzY0BpZXRmLm9yZw0KCVN1Ympl Y3Q6IFtTcGVlY2hzY10gRlc6IExpYWlzb24gc3RhdGVtZW50IGZyb20gSUVURiBTUEVFQ0hTQyBX RyB0byBXM0MNCglNdWx0aW1lZGlhIEludCBlcmFjdGlvbiBXRw0KCQ0KCQ0KCUZvcm1hbCByZXNw b25zZSBmcm9tIFczQy4NCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9t OiBEZWJvcmFoIERhaGwgW21haWx0bzpkYWhsQGNvbnZlcnNhdGlvbmFsLXRlY2hub2xvZ2llcy5j b21dDQoJPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyOSwgMjAwNCA0OjE1IFBNDQoJPiBU bzogJ0xlc2xpZSBEYWlnbGUnOyAnRGF2ZSBSYWdnZXR0IERhdmUgUmFnZ2V0dCcNCgk+IENjOiAn RXJpYyBCdXJnZXInOyAnRGF2ZSBPcmFuJzsgJ0FsbGlzb24gTWFua2luJzsgJ1BldGVyc29uLCBK b24nOw0KCT4gc3RhdGVtZW50c0BpZXRmLm9yZzsgTWFydGluIER1ZXJzdDsgTWF4IEZyb3VtZW50 aW47IFBoaWxpcHANCgk+IEhvc2Noa2E7IFd1DQoJPiBDaG91OyBqb2huc3RvbkByZXNlYXJjaC5h dHQuY29tDQoJPiBTdWJqZWN0OiBSRTogTGlhaXNvbiBzdGF0ZW1lbnQgZnJvbSBJRVRGIFNQRUVD SFNDIFdHIHRvIFczQyBNdWx0aW1lZGlhDQoJPiBJbnRlcmFjdGlvbiBXRw0KCT4NCgk+DQoJPiBM ZXNsaWUsDQoJPiBUaGFuayB5b3UgZm9yIHRoZSBsaWFzb24gc3RhdGVtZW50IGFuZCBmb3IgeW91 ciBpbnRlcmVzdCBpbiBFTU1BLg0KCT4gV2UgaGF2ZSBqdXN0IHB1Ymxpc2hlZCB0aGUgdGhpcmQg V29ya2luZyBEcmFmdCBvZiBFTU1BLiBPdXINCgk+IGN1cnJlbnQgcGxhbiBpcyB0byBwdWJsaXNo IGEgTGFzdCBDYWxsIFdvcmtpbmcgRHJhZnQgaW4gRGVjZW1iZXIsDQoJPiBhbmQgYSBDYW5kaWRh dGUgUmVjb21tZW5kYXRpb24gaW4gSnVuZSwgMjAwNS4gV2Ugd291bGQgYmUgdmVyeQ0KCT4gZ3Jh dGVmdWwgZm9yIGFueSBjb21tZW50cyBvciBmZWVkYmFjayB5b3UgbWlnaHQgaGF2ZSBvbiB0aGUN Cgk+IGN1cnJlbnQgV29ya2luZw0KCT4gRHJhZnQgKGh0dHA6Ly93d3cudzMub3JnL1RSL2VtbWEv KS4gVGhpcyBraW5kIG9mIGZlZWRiYWNrDQoJPiBzaG91bGQgYmUgdmVyeQ0KCT4gdXNlZnVsIGlu IGJvdGggaGVscGluZyB1cyBwcm9ncmVzcyBFTU1BIHRocm91Z2ggdGhlIFczQyBSZWNvbW1lbmRh dGlvbg0KCT4gcHJvY2VzcywNCgk+IGFzIHdlbGwgYXMgaW4gaW5zdXJpbmcgdGhhdCBpdCBiZWNv bWVzIGEgdXNlZnVsIGFuZCBhY2NlcHRlZA0KCT4gc3RhbmRhcmQgd2hpY2gNCgk+IG1lZXRzIHRo ZSByZXF1aXJlbWVudHMgb2YgdGhlIHNwZWVjaCBwcm9jZXNzaW5nIGluZHVzdHJ5LiBUaGUNCgk+ IG92ZXJsYXBwaW5nDQoJPiBtZW1iZXJzaGlwIGJldHdlZW4gdGhlIFczQyBNdWx0aW1vZGFsIElu dGVyYWN0aW9uIFdvcmtpbmcgR3JvdXAgYW5kDQoJPiB0aGUgTVJDUHYyIGdyb3VwIHNob3VsZCBi ZSBoZWxwZnVsIGluIGZhY2lsaXRhdGluZw0KCT4gY29tbXVuaWNhdGlvbiBhY3Jvc3MNCgk+IGdy b3Vwcy4NCgk+DQoJPiBBbHRob3VnaCBOTFNNTCBoYWQgb25seSByZWFjaGVkIGEgMXN0IFdEIHN0 YXR1cywgaXQNCgk+IGhhcyBub25ldGhlbGVzcyBwcm92ZWQgYSB1c2VmdWwgaW50ZXJpbSBzcGVj aWZpY2F0aW9uLiBXZQ0KCT4gaG9wZSB0aGF0IE1SQ1B2MiBjYW4gYmUgcmV2aXNlZCB0byBub3Jt YXRpdmVseSByZWZlcmVuY2UNCgk+IEVNTUEgaW4gcHJlZmVyZW5jZSB0byBOTFNNTCBvbmNlIEVN TUEgcmVhY2hlcyBDYW5kaWRhdGUNCgk+IFJlY29tbWVuZGF0aW9uLg0KCT4NCgk+IE5vdGUgdGhh dCB0aGUgVzNDIGFuZCB0aGUgSUVURiBoYXZlIGEgZm9ybWFsIGxpYXNvbiBwcm9jZXNzLCBzbyBJ DQoJPiBhbSBjb3B5aW5nIE1hcnRpbiBEdWVyc3QsIHdobyBpcyByZXNwb25zaWJsZSBmb3IgdGhp cyBsaWFzb24gb24gdGhlDQoJPiBXM0Mgc2lkZSwgb24gdGhpcyBtZXNzYWdlLiBJIGFtIGFsc28g Y29weWluZyBXdSBDaGFvIGFuZCBNaWNoYWVsDQoJPiBKb2huc3RvbiwgdGhlIHByaW1hcnkgZWRp dG9ycyBvZiBFTU1BLg0KCT4NCgk+IEJlc3Qgd2lzaGVzIG9uIHlvdXIgd29yayB3aXRoIE1SQ1B2 MiwgYW5kIGxvb2tpbmcgZm9yd2FyZCB0bw0KCT4gY29udGludWVkIGludGVyYWN0aW9uIHdpdGgg eW91ciBncm91cC4NCgk+DQoJPiByZWdhcmRzLA0KCT4NCgk+IERlYmJpZSBEYWhsDQoJPiBDaGFp ciwgVzNDIE11bHRpbW9kYWwgSW50ZXJhY3Rpb24gV29ya2luZyBHcm91cA0KCT4NCgk+DQoJPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiA+IEZyb206IExlc2xpZSBEYWlnbGUgW21h aWx0bzpsZXNsaWVAdGhpbmtpbmdjYXQuY29tXQ0KCT4gPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1i ZXIgMjgsIDIwMDQgMzo1NSBQTQ0KCT4gPiBUbzogRGVib3JhaCBEYWhsIERlYm9yYWggRGFobDsg RGF2ZSBSYWdnZXR0IERhdmUgUmFnZ2V0dA0KCT4gPiBDYzogRXJpYyBCdXJnZXI7IERhdmUgT3Jh bjsgQWxsaXNvbiBNYW5raW47IFBldGVyc29uLCBKb247DQoJPiA+IHN0YXRlbWVudHNAaWV0Zi5v cmcNCgk+ID4gU3ViamVjdDogTGlhaXNvbiBzdGF0ZW1lbnQgZnJvbSBJRVRGIFNQRUVDSFNDIFdH IHRvIFczQw0KCT4gPiBNdWx0aW1lZGlhIEludGVyYWN0aW9uIFdHDQoJPiA+DQoJPiA+DQoJPiA+ DQoJPiA+IFBsZWFzZSBmaW5kIGJlbG93IGEgbGlhaXNvbiBzdGF0ZW1lbnQgZnJvbSB0aGUgSUVU RiBTUEVFQ0hTQyB3b3JraW5nDQoJPiA+IGdyb3VwIHRvIHRoZSBXM0MgTXVsdGltZWRpYSBJbnRl cmFjdGlvbiB3b3JrIGdyb3VwLg0KCT4gPg0KCT4gPiBCZXN0LA0KCT4gPiBMZXNsaWUgRGFpZ2xl LA0KCT4gPiBJRVRGIGxpYWlzb24gdG8gdGhlIFczQy4NCgk+ID4NCgk+ID4gPT09PT09PT09PQ0K CT4gPg0KCT4gPg0KCT4gPiBUaXRsZTogU1BFRUNIU0MgUmVxdWlyZW1lbnRzIGZvciBXM0MgTU1J IFN0YW5kYXJkcw0KCT4gPiBTb3VyY2U6IElFVEYgU1BFRUNIU0MgV29yayBHcm91cA0KCT4gPiBU bzogVzNDIE11bHRpbWVkaWEgSW50ZXJhY3Rpb24gV29yayBHcm91cA0KCT4gPg0KCT4gPiBDb250 YWN0IFBlcnNvbnM6DQoJPiA+IE5hbWU6ICAgICAgICBFcmljIEJ1cmdlcg0KCT4gPiBUZWwuIE51 bWJlcjogKzEgNjAzIDg5MCA3NTg3DQoJPiA+IEUtTWFpbDogICAgICBlYnVyZ2VyQGJyb29rdHJv dXQuY29tDQoJPiA+IE5hbWU6ICAgICAgICBEYXZlIE9yYW4NCgk+ID4gVGVsLiBOdW1iZXI6ICsx IDk3OCAyNjQgMjA0OA0KCT4gPiBFLU1haWw6ICAgICAgb3JhbkBjaXNjby5jb20NCgk+ID4NCgk+ ID4NCgk+ID4gMS4gT3ZlcmFsbCBEZXNjcmlwdGlvbjoNCgk+ID4gVGhlIHNwZWVjaHNjIFdvcmsg R3JvdXAgaXMgdGFza2VkIHdpdGggZGV2ZWxvcGluZyBwcm90b2NvbHMNCgk+IHRvIHN1cHBvcnQN Cgk+ID4gZGlzdHJpYnV0ZWQgbWVkaWEgcHJvY2Vzc2luZyBvZiBhdWRpbyBzdHJlYW1zLiAgVGhl IGZvY3VzIG9mDQoJPiA+IHRoaXMgd29ya2luZw0KCT4gPiBncm91cCBpcyB0byBkZXZlbG9wIHBy b3RvY29scyB0byBzdXBwb3J0IEFTUiwgVFRTLCBhbmQgU1YuIA0KCT4gPiBUaGUgd29ya2luZw0K CT4gPiBncm91cCB3aWxsIG9ubHkgZm9jdXMgb24gdGhlIHNlY3VyZSBkaXN0cmlidXRlZCBjb250 cm9sIG9mDQoJPiA+IHRoZXNlIHNlcnZlcnMuDQoJPiA+DQoJPiA+IFRoZSBmdWxsIGRlc2NyaXB0 aW9uIG9mIHRoZSBTUEVFQ1NDIENoYXJ0ZXIsIGluY2x1ZGluZyBkb2N1bWVudHMgYW5kDQoJPiA+ IG1pbGVzdG9uZXMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KCT4gPiBodHRwOi8vaWV0Zi5vcmcvaHRt bC5jaGFydGVycy9zcGVlY2hzYy1jaGFydGVyLmh0bWwNCgk+ID4NCgk+ID4gQSBzdXBwbGVtZW50 YWwgd29yayBncm91cCB3ZWIgcGFnZSBjYW4gYmUgZm91bmQgaGVyZToNCgk+ID4gaHR0cDovL2Zs eWluZ2ZveC5zbm93c2hvcmUuY29tL2ktZC9zcGVlY2hzYw0KCT4gPg0KCT4gPg0KCT4gPiAyLiBC YWNrZ3JvdW5kIHRvIFJlcXVlc3QNCgk+ID4gVGhlIGNvbnNlbnN1cyBvZiB0aGUgU1BFRUNIU0Mg d29yayBncm91cCBpcyB0aGF0IEVNTUEgaXMNCgk+IHRoZSBwcmVmZXJyZWQNCgk+ID4gZW5jb2Rp bmcgZm9yIHNwZWVjaCByZWNvZ25pdGlvbiByZXN1bHRzIGZvciBNUkNQdjIgdHJhbnNwb3J0Lg0K CT4gPg0KCT4gPiBJdCBpcyBvdXIgcGxhbiB0byByZXF1aXJlIE1SQ1B2Mi1jb25mb3JtaW5nIHBy b3RvY29sDQoJPiA+IGVuZHBvaW50cyB0byBzdXBwb3J0DQoJPiA+IEVNTUEgKGN1cnJlbnRseSBy ZWZlcmVuY2VkIGF0IDxodHRwOi8vd3d3LnczLm9yZy9UUi9lbW1hLz4pLiANCgk+ID4gVGhpcyB3 aWxsDQoJPiA+IG9jY3VyIG9uY2UgRU1NQSByZWFjaGVzIENhbmRpZGF0ZSBSZWNvbW1lbmRhdGlv biBzdGF0dXMuIA0KCT4gPiBIb3dldmVyLCBpdCBpcyBvdXINCgk+ID4gdW5kZXJzdGFuZGluZyB0 aGF0IHRoaXMgd2lsbCBub3QgaGFwcGVuIHVudGlsIG1pZC0yMDA1Lg0KCT4gPg0KCT4gPiBCZWNh dXNlIHRoZXJlIGlzIGEgZGVtYW5kIGZvciBNUkNQdjIgdG9kYXksIHdlIG5lZWQgYQ0KCT4gPiBu b3JtYXRpdmUgcmVmZXJlbmNlIHRvDQoJPiA+IGEgcmVjb2duaXRpb24gbWFya3VwLiAgVGhlIGNv bnNlbnN1cyBvZiB0aGUgU1BFRUNIU0Mgd29yaw0KCT4gPiBncm91cCBpcyB0aGF0DQoJPiA+IE5M U01MIChjdXJyZW50bHkgcmVmZXJlbmNlZCBhdA0KCT4gPiA8aHR0cDovL3d3dy53My5vcmcvVFIv bmwtc3BlYy8+KSBpcyBjbG9zZXN0DQoJPiA+IHRvIG91ciBuZWVkcy4gIEhvd2V2ZXIsIHRoZXJl IGlzIG5vIG5vcm1hdGl2ZSAoQ2FuZGlkYXRlDQoJPiA+IFJlY29tbWVuZGF0aW9uIG9yDQoJPiA+ IGxhdGVyKSBmb3IgTkxTTUwuDQoJPiA+DQoJPiA+IFVudGlsIHRoZSBXM0MgcHVibGlzaGVzIEVN TUEgYXMgYSBDYW5kaWRhdGUgUmVjb21tZW5kYXRpb24sDQoJPiA+IE1SQ1B2MiBlbmRwb2ludHMN Cgk+ID4gd2lsbCBiZSByZXF1aXJlZCB0byBzdXBwb3J0IGEgZGlmZmVyZW50IG1hcmt1cC4gIEhv d2V2ZXIsDQoJPiBvbmNlIEVNTUEgaXMNCgk+ID4gcHVibGlzaGVkLCBpdCB3aWxsIGJlIHRoZSBk ZWZhdWx0LCByZXF1aXJlZCBtYXJrdXAgZm9yDQoJPiA+IHJldHVybmluZyByZWNvZ25pdGlvbg0K CT4gPiByZXN1bHRzLiAgVGhpcyBtYXJrdXAgd2lsbCBub3QgYmUgY2FsbGVkIE5MU01MLg0KCT4g Pg0KCT4gPiBNUkNQdjIgd2lsbCBpbmNsdWRlIGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHN1Y2gg dGhhdA0KCT4gPiBmb2xsb3ctb24gbWFya3VwcyB0bw0KCT4gPiBFTU1BIHdpbGwgYmUgYXV0b21h dGljYWxseSBzdXBwb3J0ZWQgYnkgdGhlIHByb3RvY29sLg0KCT4gPg0KCT4gPg0KCT4gPiAzLiBS ZXF1ZXN0cyB0byBXM0M6DQoJPiA+IEEpIFBsZWFzZSBrZWVwIHVzIGluZm9ybWVkIHRvIHRoZSBw cm9ncmVzcyBvZiBFTU1BLg0KCT4gPiBCKSBQbGVhc2UgcHJvZ3Jlc3MgRU1NQSB0byBDYW5kaWRh dGUgUmVjb21tZW5kYXRpb24gYXMgZmFzdA0KCT4gPiBhcyBwb3NzaWJsZS4NCgk+ID4gQykgSXQg aXMgb3VyIGludGVudGlvbiB0byByZWZlcmVuY2UgdGhlIE5MU01MIHNwZWNpZmljYXRpb24sDQoJ PiA+IHBlciB0aGUgVzNDDQoJPiA+IGNvcHlyaWdodCBydWxlcyBzcGVjaWZpZWQgaW4gdGhlIE5M U01MIHNwZWNpZmljYXRpb24sIGZvdW5kIGF0DQoJPiA+IDxodHRwOi8vd3d3LnczLm9yZy9Db25z b3J0aXVtL0xlZ2FsL2NvcHlyaWdodC1kb2N1bWVudHMtMTk5OTA0MDU+DQoJPiA+DQoJPiA+IC0t DQoJPiA+DQoJPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgk+ID4gIlJlYWxpdHk6DQoJPiA+ICAgICAgIFlvdXJz IHRvIGRpc2NvdmVyLiINCgk+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0g VGhpbmtpbmdDYXQNCgk+ID4gTGVzbGllIERhaWdsZQ0KCT4gPiBsZXNsaWVAdGhpbmtpbmdjYXQu Y29tDQoJPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCgk+ID4NCgk+DQoJPg0KCQ0KCV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3BlZWNoc2MgbWFpbGluZyBsaXN0DQoJ U3BlZWNoc2NAaWV0Zi5vcmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcGVlY2hzYw0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJU3BlZWNoc2MgbWFpbGluZyBsaXN0DQoJU3BlZWNoc2NAaWV0Zi5vcmcNCglodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGVlY2hzYyANCg0K --===============1984642137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1984642137==-- From speechsc-bounces@ietf.org Fri Oct 8 09:16:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21888 for ; Fri, 8 Oct 2004 09:16:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFulP-0006MH-Bj for speechsc-web-archive@ietf.org; Fri, 08 Oct 2004 09:26:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFuTF-0006IC-3r; Fri, 08 Oct 2004 09:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFuQp-0005g2-DM for speechsc@megatron.ietf.org; Fri, 08 Oct 2004 09:05:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21246 for ; Fri, 8 Oct 2004 09:05:10 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFuaj-00069t-Ly for speechsc@ietf.org; Fri, 08 Oct 2004 09:15:27 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 08 Oct 2004 06:05:27 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i98D4ZEE015361 for ; Fri, 8 Oct 2004 06:04:35 -0700 (PDT) Received: from [10.32.245.151] (stealth-10-32-245-151.cisco.com [10.32.245.151]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with SMTP id AEX25292; Fri, 8 Oct 2004 06:04:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <9A04088E-192A-11D9-95AC-000A95C73842@cisco.com> To: "'speechsc@ietf.org'" From: David R Oran Date: Fri, 8 Oct 2004 09:04:34 -0400 X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Speechsc] Speechsc is not planning to meet at the November IETF 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="===============1521774538==" Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --===============1521774538== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-821874174" --Apple-Mail-8-821874174 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit After some deliberation, Eric and I are recommending that SPEECHSC not meet at IETF61 in Washington. MRCPv2 is rapidly getting to the point where we can issue a last call, and the remaining work concerns getting the document itself in good enough shape to be approved in a last call and pass muster with the IESG. While there are a few remaining open issues, it does not appear that any of them require high bandwidth face-to-face discussion. They are being dealt with adequately by email on the list (and a lot of work by the author and WG participants!). With a decent push, we should be able it issue a last call just around the time of IETF and I would encourage the WG participants to put our efforts into achieving that goal. If there are any objections to this course of action, please speak up now! Thanks, Dave & Eric SPEECHSC co-chairs. --Apple-Mail-8-821874174 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBZpBijWaEtlTdKuYRAl+6AKDPyjxzAvi5PhiugzJsHisXaOJSWwCfdRsS LE938n7/Wk7IylA8QwFEqfI= =9+7S -----END PGP SIGNATURE----- --Apple-Mail-8-821874174-- --===============1521774538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============1521774538==-- From speechsc-bounces@ietf.org Fri Oct 8 15:12:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25709 for ; Fri, 8 Oct 2004 15:12:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0Jt-0006av-Jc for speechsc-web-archive@ietf.org; Fri, 08 Oct 2004 15:22:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG06x-0006V7-5v; Fri, 08 Oct 2004 15:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzvw-0003OY-Rn for speechsc@megatron.ietf.org; Fri, 08 Oct 2004 14:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23188 for ; Fri, 8 Oct 2004 14:57:38 -0400 (EDT) Received: from [66.46.69.18] (helo=letter.nuance.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG05i-00066Z-Je for speechsc@ietf.org; Fri, 08 Oct 2004 15:07:57 -0400 Received: from postcard.nuance.com ([10.3.6.20]:40436) by letter.nuance.com with esmtp id 1CFzvs-0001Qm-K2; Fri, 08 Oct 2004 11:57:36 -0700 Received: from mtb1exch01.nuance.com ([10.3.2.6]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 14:54:38 -0400 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] XML schema for verification result Date: Fri, 8 Oct 2004 14:54:37 -0400 Message-ID: <7DE7C4EF3B7C8B4B82955191378290D801FF292E@mtb1exch01.nuance.com> Thread-Topic: [Speechsc] XML schema for verification result Thread-Index: AcSrAN5bwiqa1w/tT0ia6WZZfHVGjwCQlVuw From: "Pierre Forgues" To: "Reifenrath, Klaus" , X-OriginalArrivalTime: 08 Oct 2004 18:54:38.0573 (UTC) FILETIME=[430399D0:01C4AD68] X-FromHost: postcard.nuance.com [10.3.6.20]:40436 Lines: 80 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: Sarvi Shanmugham , zilca@us.ibm.com X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Klaus, We do not use in the context of training and would therefore not have an issue with this being optional. Also, we are OK for items 2 and 3 below. Pierre -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com]=20 Sent: Tuesday, October 05, 2004 1:27 PM To: speechsc@ietf.org Cc: 'Sarvi Shanmugham'; Pierre Forgues; 'zilca@us.ibm.com' Subject: RE: [Speechsc] XML schema for verification result Hi group, aside from the discussion which schema we should use, I like to resolve the open issues concerning the verification result elements: According to the current spec the element is mandatory also for training results. What is the meaning of a verification score in the context of training (see 4))? What is your opinion on 2) and 3)?=20 Regards, Klaus =20 -----Original Message----- From: Reifenrath, Klaus [mailto:Klaus.Reifenrath@Scansoft.com] Sent: Mittwoch, 21. Juli 2004 18:11 To: 'Sarvi Shanmugham'; Daniel Burnett Cc: speechsc@ietf.org Subject: [Speechsc] XML schema for verification result Hi Sarvi and Dan, I created a XML schema for the verification result. Like the RelaxNG schema of Dan it can be improved. I also adapted the sample results of Dan. Compared to Dan's proposal I changed the following: 1) Because of XML Schema limitations I need to distinguish between verification and training results.=20 2) The element is no longer child element of the element, because in case of multi-verification, the value of num-frames is the same for all voiceprints. 3) The and are child elements of the element. 4) For training results the is now optional. I also added a new optional parameter for training results: consistent. 5) The element has 2 mandatory attributes: repository-uri and identifier 6) Currently I included the element of NLSML, to allow validation of sample results with validation tools. But I still do not see the benefit of using NLSML for verification results, because a speaker verification engine is not a semantic interpretation component. Suggestions for improvement are welcome! Klaus <> <>=20 =20 =20 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Oct 11 15:09:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05342 for ; Mon, 11 Oct 2004 15:09:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5j4-0006sh-1W for speechsc-web-archive@ietf.org; Mon, 11 Oct 2004 15:20:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH5W7-0004Hc-Bg; Mon, 11 Oct 2004 15:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH5Qy-00071x-Kz for speechsc@megatron.ietf.org; Mon, 11 Oct 2004 15:02:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04319 for ; Mon, 11 Oct 2004 15:02:10 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5bX-0006g7-5X for speechsc@ietf.org; Mon, 11 Oct 2004 15:13:09 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9BJ1cSD462772 for ; Mon, 11 Oct 2004 15:01:38 -0400 Received: from d01ml605.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9BJ2rA9144762 for ; Mon, 11 Oct 2004 15:02:53 -0400 Importance: Normal X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 MIME-Version: 1.0 To: speechsc-admin@ietf.org, Message-ID: From: Ran Zilca Date: Mon, 11 Oct 2004 15:01:36 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 6.51HF632 | October 8, 2004) at 10/11/2004 15:01:38 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.5 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Speechsc] INTERMEDIATE-RECOG-RESULT 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi all, There was some correspondence going on some time ago about the possibility of adding a INTERMEDIATE-RECOG-RESULT method to the recognition resource. I enclosed what I have of this correspomdence below. There is a corresponding method for the verification resource, and there seems to be enough justification to have the same method for recognition. I realize that this sparks up some issues wrt transcription etc. However, in a finite state grammar system there could be plenty of scenarios where it will be useful for the application to get the intermediate text without waiting for the user to finish speaking. It seems to me that the v2 spec may not be complete without it. This could be an optional method. Any thoughts anyone? Thanks, -- Ran. -----Original Message----- From: Jeff Kusnitz [mailto:jk@us.ibm.com] Sent: Freitag, 16. April 2004 20:29 To: Reifenrath, Klaus Cc: 'speechsc@ietf.org'; speechsc-admin@ietf.org Subject: Re: [Speechsc] INTERMEDIATE-RECOG-RESULT It certainly seems reasonable. I assume the body of the INTERMEDIATE-RECOG-RESULT message would contain the intermediate results in NLSML (or EMMA) format? Klaus wrote on 04/15/2004 02:10:52 AM: > The mail of Ran Zilca on intermediate results for SV/SI reminded me of one > of the open questions (see minutes of last WG meeting): > Do we need an INTERMEDIATE-RECOG-RESULT? > > Intermediate results for ASR make sense as well. > Imagine a multimodal application where the caller can fill several input > fields: after > the recognizer recognized valid input for the first slot, the recognized > value could be visualized, as soon the recognizer recognized input for > another slot, this slot can be filled on the screen as well and so on. > Another use case for intermediate results would be e-mail/SMS dictation. > > Therefore I suggest to add an optional INTERMEDIATE-RECOG-RESULT event to > the speech recognizer resource. > > Klaus > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Oct 18 07:04:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05544 for ; Mon, 18 Oct 2004 07:04:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJVV4-0005dp-0E for speechsc-web-archive@ietf.org; Mon, 18 Oct 2004 07:16:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJVHf-0001XM-FI; Mon, 18 Oct 2004 07:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOYH-0006eJ-PQ for speechsc@megatron.ietf.org; Sun, 17 Oct 2004 23:51:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21701 for ; Sun, 17 Oct 2004 23:51:13 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJOk1-0006E0-07 for speechsc@ietf.org; Mon, 18 Oct 2004 00:03:35 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 17 Oct 2004 20:50:36 -0700 X-BrightmailFiltered: true Received: from vtg-um-e2k1.sj21ad.cisco.com (vtg-um-e2k1.cisco.com [171.70.93.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9I3oW7o026469 for ; Sun, 17 Oct 2004 20:50:32 -0700 (PDT) Received: from cisco.com ([10.82.241.102]) by vtg-um-e2k1.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 17 Oct 2004 20:50:13 -0700 Message-ID: <41733D60.2030502@cisco.com> Date: Sun, 17 Oct 2004 20:49:52 -0700 From: Sarvi Shanmugham Organization: Cisco Systems Inc. User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IETF SPEECHSC (E-mail)" Content-Type: multipart/mixed; boundary="------------070205000707050908050604" X-OriginalArrivalTime: 18 Oct 2004 03:50:13.0944 (UTC) FILETIME=[92E7D380:01C4B4C5] X-Spam-Score: 0.4 (/) X-Scan-Signature: 1b456073e3e172141079c035c35c129f X-Mailman-Approved-At: Mon, 18 Oct 2004 07:02:34 -0400 Subject: [Speechsc] MRCPv2 draft -05 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 X-Spam-Score: 0.4 (/) X-Scan-Signature: e5e1dbdf0592a45a17cf4f1433790e6d This is a multi-part message in MIME format. --------------070205000707050908050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I just submitted the -05 version of the mrcpv2 draft. Some of the changes in this draft are as following. 1. Address Magnus Westerlands comments. I will be responding to his email with the specific issues he raised that have not resulted in modification. 2. A lot of formatting cleanup work. 3. Issues resolved on the alias so far. 1. Server Error codes. 2. Verification result changes from klaus(needmoredata etc). 4. Included the NLSML text and DTD 5. Created a NLSML schema based on the DTD. 6. Formated the header summary into a table per Magnus's suggestion. 7. Ran the ABNF through the parser. 8. Behaviour of VERIFY-FROM-BUFFER when buffer is in use. 9. Editorial comments received so far. Pending: IANA Considerations section Pending: Convert the Verification and Enrollment Schema to W3C Schema(Not sure if this is needed or if we can leave it in its current schema format.) I can send the Word document with change tracking on. But am not sure if it is apropriate to be sending a word document to this mailing list. Let me know if it is ok and I can send it out. Thanks, Sarvi --------------070205000707050908050604 Content-Type: text/plain; name="draft-ietf-speechsc-mrcpv2-05.txt" Content-Disposition: inline; filename="draft-ietf-speechsc-mrcpv2-05.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force Saravanan Shanmugham Internet-Draft Cisco Systems Inc. draft-ietf-speechsc-mrcpv2-05 October 18, 2004 Expires: April 18, 2005 Media Resource Control Protocol Version 2(MRCPv2) Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt . The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html . This Internet-Draft will expire on April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a proposal for a Media Resource Control Protocol Version 2 (MRCPv2) and aims to meet the requirements specified in the SPEECHSC working group requirements document. It is based on the Media Resource Control Protocol (MRCP), also called S. Shanmugham, et. al. Page 1 MRCPv2 Protocol October, 2004 MRCPv1 developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks Inc. The MRCPv2 protocol will control media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers etc. over a network. This protocol depends on a session management protocol such as the Session Initiation Protocol (SIP) to establish a separate MRCPv2 control session between the client and the server. It also depends on SIP to establish the media pipe and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange can happen over the control session established above allowing the client to command and control the media processing resources that may exist on the media server. Table of Contents Status of this Memo..............................................1 Copyright Notice.................................................1 Abstract.........................................................1 Table of Contents................................................2 1. Introduction:...............................................4 2. Notational Convention.......................................5 3. Architecture:...............................................5 3.1. MRCPv2 Media Resources:....................................7 3.2. Server and Resource Addressing.............................8 4. MRCPv2 Protocol Basics......................................8 4.1. Connecting to the Server...................................8 4.2. Managing Resource Control Channels.........................8 4.3. Media Streams and RTP Ports...............................15 4.4. MRCPv2 Message Transport..................................16 4.5. Resource Types............................................17 5. MRCPv2 Specification.......................................17 5.1. Request...................................................18 5.2. Response..................................................19 5.3. Event.....................................................20 6. MRCP Generic Features......................................21 6.1. Generic Message Headers...................................21 6.2. SET-PARAMS................................................30 6.3. GET-PARAMS................................................30 7. Resource Discovery.........................................31 8. Speech Synthesizer Resource................................32 8.1. Synthesizer State Machine.................................33 8.2. Synthesizer Methods.......................................33 8.3. Synthesizer Events........................................34 8.4. Synthesizer Header Fields.................................34 8.5. Synthesizer Message Body..................................40 8.6. SPEAK.....................................................43 8.7. STOP......................................................44 8.8. BARGE-IN-OCCURRED.........................................45 S Shanmugham IETF-Draft Page 2 MRCPv2 Protocol October, 2004 8.9. PAUSE.....................................................47 8.10. RESUME....................................................48 8.11. CONTROL...................................................49 8.12. SPEAK-COMPLETE............................................50 8.13. SPEECH-MARKER.............................................51 8.14. DEFINE-LEXICON............................................52 9. Speech Recognizer Resource.................................53 9.1. Recognizer State Machine..................................54 9.2. Recognizer Methods........................................54 9.3. Recognizer Events.........................................55 9.4. Recognizer Header Fields..................................55 9.5. Recognizer Message Body...................................69 9.6. DEFINE-GRAMMAR............................................83 9.7. RECOGNIZE.................................................87 9.8. STOP......................................................89 9.9. GET-RESULT................................................90 9.10. START-OF-SPEECH...........................................91 9.11. START-INPUT-TIMERS........................................92 9.12. RECOGNITION-COMPLETE......................................92 9.13. START-PHRASE-ENROLLMENT...................................94 9.14. ENROLLMENT-ROLLBACK.......................................95 9.15. END-PHRASE-ENROLLMENT.....................................96 9.16. MODIFY-PHRASE.............................................96 9.17. DELETE-PHRASE.............................................97 9.18. INTERPRET.................................................97 9.19. INTERPRETATION-COMPLETE...................................98 9.20. DTMF Detection...........................................100 10. Recorder Resource.........................................100 10.1. Recorder State Machine...................................100 10.2. Recorder Methods.........................................100 10.3. Recorder Events..........................................100 10.4. Recorder Header Fields...................................101 10.5. Recorder Message Body....................................105 10.6. RECORD...................................................105 10.7. STOP.....................................................106 10.8. RECORD-COMPLETE..........................................107 10.9. START-INPUT-TIMERS.......................................107 11. Speaker Verification and Identification...................109 11.1. Speaker Verification State Machine.......................110 11.2. Speaker Verification Methods.............................110 11.3. Verification Events......................................111 11.4. Verification Header Fields...............................111 11.5. Verification Result Elements.............................119 11.6. START-SESSION............................................123 11.7. END-SESSION..............................................124 11.8. QUERY-VOICEPRINT.........................................124 11.9. DELETE-VOICEPRINT........................................125 11.10. VERIFY..................................................126 11.11. VERIFY-FROM-BUFFER......................................126 11.12. VERIFY-ROLLBACK.........................................129 11.13. STOP....................................................130 S Shanmugham IETF-Draft Page 3 MRCPv2 Protocol October, 2004 11.14. START-INPUT-TIMERS......................................131 11.15. VERIFICATION-COMPLETE...................................131 11.16. START-OF-SPEECH.........................................132 11.17. CLEAR-BUFFER............................................132 11.18. GET-INTERMEDIATE-RESULT.................................132 12. Security Considerations...................................133 13. Examples:.................................................133 14. Reference Documents.......................................145 15. Appendix..................................................146 15.1. ABNF Message Definitions.................................146 15.2. XML Schema and DTD.......................................161 Full Copyright Statement.......................................168 Intellectual Property..........................................169 Contributors...................................................169 Acknowledgements...............................................170 Editors' Addresses.............................................170 1. Introduction: The MRCPv2 protocol is designed for a client device to control media processing resources on the network allowing to process and audio/video stream. Some of these media processing resources could be speech recognition, speech synthesis engines, speaker verification or speaker identification engines. This allows a vendor to implement distributed Interactive Voice Response platforms such as VoiceXML [7] browsers. The protocol requirements of SPEECHSC require that the protocol is capable of reaching a media processing server and setting up communication channels to the media resources, to send/recieve control messages and media streams to/from the server. The Session Initiation Protocol (SIP) protocol described in [4] meets these requirements and is used to setup and tear down media and control pipes to the server. In addition, the SIP re-INVITE can be used to change the characteristics of these media and control pipes mid- session. The MRCPv2 protocol hence is designed to leverage and build upon a session management protocols such as Session Initiation Protocol (SIP) and Session Description Protocol (SDP). SDP is used to describe the parameters of the media pipe associated with that session. It is mandatory to support SIP as the session level protocol to ensure interoperability. Other protocols can be used at the session level by prior agreement. The MRCPv2 protocol depends on SIP and SDP to create the session, and setup the media channels to the server. It also depends on SIP and SDP to establish MRCPv2 control channels between the client and the server for each media processing resource required for that session. The MRCPv2 protocol exchange between the client and the media resource can then happen on that control channel. The MRCPv2 S Shanmugham IETF-Draft Page 4 MRCPv2 Protocol October, 2004 protocol exchange happening on this control channel does not change the state of the SIP session, the media or other parameters of the session SIP initiated. It merely controls and affects the state of the media processing resource associated with that MRCPv2 channel. The MRCPv2 protocol defines the messages to control the different media processing resources and the state machines required to guide their operation. It also describes how these messages are carried over a transport layer such as TCP, SCTP or TLS. 2. Notational Convention The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[9]. Since many of the definitions and syntax are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [1]). All the mechanisms specified in this document are described in both prose and an augmented Backus-Naur form (ABNF). It is described in detail in RFC 2234 [3]. The complete message format in ABNF form is provided in Appendix section 12.1 and is the normative format definition. Media Resource An entity on the MRCP Server that can be controlled through the MRCP protocol MRCP Server Aggregate of one or more "Media Resource" entities on a Server, exposed through the MRCP protocol.("Server" for short) MRCP Client An entity controlling one or more Media Resources through the MRCP protocol. ("Client" for short) 3. Architecture: The system consists of a client that requires the generation of media streams or requires the processing of media streams and a media resource server that has the resources or engines to process or generate these streams. The client establishes a session using SIP and SDP with the server to use its media processing resources. A SIP URI refers to the MRCPv2 server. S Shanmugham IETF-Draft Page 5 MRCPv2 Protocol October, 2004 The session management protocol (SIP) will use SDP with the offer/answer model described RFC 3264 to describe and setup the MRCPv2 control channels. Separate MRCPv2 control channels are need for controlling the different media processing resources associated with that session. Within a SIP session, the individual resource control channels for the different resources are added or removed through the SDP offer/answer model and the SIP re-INVITE dialog. The server, through the SDP exchange, provides the client with a unique channel identifier and a port number(TCP or SCTP). The client MAY then open a new TCP connection with the server using this port number. Multiple MRCPv2 channels can share a TCP connection between the client and the server. All MRCPv2 messages exchanged between the client and the server will also carry the specified channel identifier that MUST be unique among all MRCPv2 control channels that are active on that server. The client can use this channel to control the media processing resource associated with that channel. The session management protocol (SIP) will also establish media pipes between the client (or source/sink of media) and the MRCP server using SDP m-lines. A media pipe maybe shared by one or more media processing resources under that SIP session or each media processing resource may have its own media pipe. MRCPv2 client MRCPv2 Media Resource Server |--------------------| |-----------------------------| ||------------------|| ||---------------------------|| || Application Layer|| || TTS | ASR | SV | SI || ||------------------|| ||Engine|Engine|Engine|Engine|| ||Media Resource API|| ||---------------------------|| ||------------------|| || Media Resource Management || || SIP | MRCPv2 || ||---------------------------|| ||Stack | || || SIP | MRCPv2 || || | || || Stack | || ||------------------|| ||---------------------------|| || TCP/IP Stack ||----MRCPv2---|| TCP/IP Stack || || || || || ||------------------||-----SIP-----||---------------------------|| |--------------------| |-----------------------------| | / SIP / | / |-------------------| RTP | | / | Media Source/Sink |-------------/ | | |-------------------| Fig 1: Architectural Diagram S Shanmugham IETF-Draft Page 6 MRCPv2 Protocol October, 2004 MRCPv2 Media Resource Types: The MRCP server may offer one or more of the following media processing resources to its clients. Basic Synthesizer A speech synthesizer resource with very limited capabilities, that can be achieved through the playing out concatenated audio file clips. The speech data is described as SSML data but with limited support for its elements. It MUST support ,