From mailnull@www1.ietf.org Fri Nov 1 15:26:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02889 for ; Fri, 1 Nov 2002 15:26:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1KSGZ01643 for speechsc-archive@odin.ietf.org; Fri, 1 Nov 2002 15:28:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1KSGv01640 for ; Fri, 1 Nov 2002 15:28:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02886 for ; Fri, 1 Nov 2002 15:25:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1KS7v01624; Fri, 1 Nov 2002 15:28:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1K35v32426 for ; Fri, 1 Nov 2002 15:03:05 -0500 Received: from ahuumrelay3.ams.ops.eu.uu.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01260; Fri, 1 Nov 2002 15:00:28 -0500 (EST) Received: from weasel.hq.eloquant.com (www3.eloquant.com [212.157.35.18]) by ahuumrelay3.ams.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id gA1K2ln02315; Fri, 1 Nov 2002 20:02:48 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 99D693B6CB; Fri, 1 Nov 2002 15:01:12 -0500 (EST) Reply-To: From: "Brian Wyld" To: Cc: , "'Speechsc (E-mail)'" , Date: Fri, 1 Nov 2002 21:01:14 +0100 Message-ID: <01ac01c281e1$6f447fa0$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01AD_01C281E9.D108E7A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <003501c27e11$3b6d5540$8300010a@hq.eloquant.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Speechsc] speechsc WG Internet Draft submission : draft-ietf-speechsc-protocol-eval-01.txt - Update to version 01 for protocol evaluation document Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_01AD_01C281E9.D108E7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Attached is an update of the speechsc protocol evaluation draft for submission as Internet draft. Thanks for processing this update. A+ Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] ------=_NextPart_000_01AD_01C281E9.D108E7A0 Content-Type: text/plain; name="draft-ietf-speechsc-protocol-eval-01.txt" Content-Disposition: attachment; filename="draft-ietf-speechsc-protocol-eval-01.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= Internet Draft B. Wyld=20 Document: draft-speechsc-protocol-eval.txt Editor=20 Expires: April 2003 Eloquant=20 Version 01 November 2002=20 =20 SPEECHSC Protocol Evaluation=20 =20 Status of this Memo =20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed at =20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html. =20 =20 Abstract =20 =20 This document is the Protocol Evaluation Document for the SPEECHSC=20 Working Group. Section 3 provides the summary of the individual=20 protocol comparisons (in the sections 4-N following) against the=20 SPEECHSC requirements [1].=20 =20 Table of Contents=20 =20 1. Overview...................................................2=20 2. Protocol Proposals.........................................2=20 3. Protocol Evaluation Summaries..............................3=20 3.1. Protocol X............................................3=20 4. Protocol =93Beep=94 Complience Evaluation (Jerry = Carter).......4=20 4.1. General notes:........................................4=20 4.2. Analysis of General Requirements......................4=20 4.3. Analysis of TTS requirements..........................5=20 4.4. Analysis of ASR requirements..........................6=20 4.5. Analysis of Speaker Identification and Verification=20 Requirements..................................................7=20 4.6. Analysis of Duplexing and Parallel Operation=20 Requirements..................................................7=20 4.7. Analysis of additional considerations (non-normative).7=20 4.8. Analysis of Security considerations...................8=20 5. Protocol =93SIP=94 Complience Evaluation (Rajiv = Dharmadhikari).8=20 5.1. Introduction..........................................8=20 5.2. Analysis of General Requirements......................8=20 5.3. Analysis of TTS requirements..........................9=20 5.4. Analysis of ASR requirements.........................10=20 5.5. Analysis of Speaker Identification and Verification=20 Requirements.................................................10=20 5.6. Analysis of Duplexing and Parallel Operation=20 Requirements.................................................11=20 =20 =20 Wyld Expires =96 April 2003 [Page 1] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 5.7. Analysis of additional considerations (non-normative)11=20 5.8. Analysis of Security considerations..................11=20 5.9. Other Criteria.......................................11=20 6. Protocol =93RTSP=94 Complience Evaluation (Brian = Wyld)........12=20 6.1. General Introduction.................................12=20 6.2. Analysis of General Requirements.....................13=20 6.3. Analysis of TTS requirements.........................13=20 6.4. Analysis of ASR requirements.........................14=20 6.5. Analysis of Speaker Identification and Verification=20 Requirements.................................................14=20 6.6. Analysis of Duplexing and Parallel Operation=20 Requirements.................................................15=20 6.7. Analysis of additional considerations (non-normative)15=20 6.8. Analysis of Security considerations..................15=20 7. Protocol =93MRCP=94 Complience Evaluation (Sarvi = Shanmugham)..15=20 7.1. General..............................................15=20 7.2. Analysis of General Requirements.....................16=20 7.3. Analysis of TTS requirements.........................17=20 7.4. Analysis of ASR requirements.........................18=20 7.5. Analysis of Speaker Identification and Verification=20 Requirements.................................................19=20 7.6. Analysis of Duplexing and Parallel Operation=20 Requirements.................................................19=20 7.7. Analysis of additional considerations (non-normative)20=20 7.8. Analysis of Security considerations..................20=20 8. Protocol =93Web Services=94 Complience Evaluation (Stephane H.=20 Maes) =0D 20=20 8.1. General Notes:.......................................20=20 8.2. Analysis of General Requirements.....................21=20 8.3. Analysis of TTS requirements.........................23=20 8.4. Analysis of ASR requirements.........................24=20 8.5. Analysis of Speaker Identification and Verification=20 Requirements.................................................25=20 8.6. Analysis of Duplexing and Parallel Operation=20 Requirements.................................................25=20 8.7. Analysis of additional considerations (non-normative)26=20 8.8. Analysis of Security considerations..................26=20 9. Security Considerations...................................27=20 10. References................................................27=20 =20 1. =0D Overview =20 =20 This document provides the template for the content for the=20 SPEECHSC Protocol Evaluation document. =20 =20 This section will contain an overview of the process.=20 =20 Section 2 contains a list of the proposed protocols submitted to=20 WG.=20 =20 Section 3 provides a summary of the proposed protocols against the=20 Requirements and framework. =20 =20 Sections 4 and following provide the individual protocol=20 comparisons against the SPEECHSC requirements [1]. =20 =20 2. =0D Protocol Proposals=20 =20 This section contains a list of the existing protocols submitted to=20 the SPEECHSC WG for consideration by the deadline. =20 =20 =20 Wyld Expires =96 April 2003 [Page 2] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 1. BEEP=20 2. SIP=20 3. RTSP=20 4. MRCP (initial submission)=20 5. Web Services=20 =20 =20 Each protocol section contains a review of the protocol=92s level of = compliance to each of the SPEECHSC Requirements [1] as derived from=20 the proposed protocol documents. The following key will be used to=20 identify the level of compliancy of each of the individual=20 protocols:=20 =20 T =3D Total Complience. Meets the requirement fully.=20 P =3D Partial Compliance. Meets some aspect of the requirement.=20 P+ =3D Complience possible. Could meet the requirement with = =93natural=94=20 evolution of the protocol. =20 F =3D Failed Compliance. Does not meet the requirement. =20 =20 3. =0D Protocol Evaluation Summaries =20 =20 To provide standalone completeness for this document, this section=20 contains a summary of each of the protocol comparisons. The=20 comparisons should explicitly reference the requirements as defined=20 in [1]. =20 =20 TBD : This section will be completed once agreement is reached on=20 the specific protocol analysis sections.=20 =0A= 3.1. Protocol X=20 =0A= 3.1.1. Protocol x Architectural Model as compared to the=20 SPEECHSC Architectural Framework=20 =20 This section would contain a description of the key aspects of the=20 architectural model of protocol X and a comparison of this model=20 against the SPEECHSC framework, highlighting the pros/cons of the=20 applicability of protocol x to SPEECHSC.=20 =0A= 3.1.2. SPEECHSC requirements met by protocol X.=20 =20 This section contains a description of the SPEECHSC requirements=20 met by protocol X.=20 =0A= 3.1.3. SPEECHSC requirements partially met by protocol X.=20 =20 This section contains a description of the SPEECHSC requirements=20 partially met by protocol X. [Note: ideally, there would be few or=20 NONE of these provided the SPEECHSC requirements have been defined=20 at the appropriate level]. =20 =0A= 3.1.4. SPEECHSC requirements can be met by protocol X=20 with =93natural=94 evolutions.=20 =20 This section contains a description of the SPEECHSC requirements=20 not currently met by protocol X but that could be met assuming some=20 evolutions. [Note: the definition of =93natural=94 evolution will no = doubt be for discussion]. =20 =20 =20 Wyld Expires =96 April 2003 [Page 3] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 3.1.5. SPEECHSC requirements NOT met by protocol X. =20 =20 This section contains a description of the SPEECHSC requirements=20 that are NOT met by protocol X. [Note: an important aspect to=20 highlight in the individual protocol comparisons would be the work=20 required to extend protocol X to be able to support this=20 requirement.]=20 =20 4. =0D Protocol =93Beep=94 Complience Evaluation (Jerry = Carter)=20 =0A= 4.1. General notes:=20 =20 The BEEP protocol provides a general framework for establishing =20 connections, defining new channels, negotiating security, and=20 performing user authentication. Protocols build on beep must define=20 a profile detailing how connections are established and must define=20 a set of messages which will be delivered using BEEP. The protocol=20 is peer-to-peer although client-server style requests could be=20 easily handled.=20 =20 The following sub-sections compare each individual requirement=20 against the protocol.=20 =0A= 4.2. Analysis of General Requirements=20 =0A= 4.2.1. Reuse existing protocols [5.1]=20 =20 T: Beep is a published protocol, listed as RFC 3080=20 (http://www.ietf.org/rfc/rfc3080.txt).=20 =0A= 4.2.2. Maintain Existing Protocol Integrity [5.2]=20 =20 P: BEEP assumes that protocols, such as SpeechSC, will add=20 messages.=20 =20 Supporting multiple clients using TCP may require some effort.=20 =0A= 4.2.3. Avoid Duplicating Existing Protocols [5.3]=20 =20 T: Building SpeechSC over BEEP would allow the specification to=20 focus on managing the ASR, media server, and SI/SV resources and=20 the possible interactions between them. The operations for=20 establishing connections and defining new channels would be handled=20 by BEEP.=20 =0A= 4.2.4. Protocol efficiency [5.4]=20 =20 P+: BEEP imposes a small overhead (roughly 40 bytes per message).=20 It provides a mechanism for supporting multiple communication=20 channels over a single port. If grouping of requests is desired,=20 this would need to be handled by grouping the SpeechSC messages.=20 =0A= 4.2.5. Explicit invocation of services [5.5]=20 =20 T: Though it is primarily a peer-to-peer protocol, BEEP may act as=20 a traditional client server protocol.=20 =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 4] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 4.2.6. Server Location and Load Balancing [5.6]=20 =20 P+: This functionality is not provided by BEEP. This would need to=20 be added as an extension.=20 =0A= 4.2.7. Simultaneous services [5.7]=20 =20 T: Multiple channels providing different services is possible. Each=20 service is simply a message type which is passed to the server=20 using BEEP.=20 =0A= 4.2.8. Multiple media sessions [5.8]=20 =20 F: BEEP assumes a 1:1 using TCP/IP.=20 =0A= 4.3. Analysis of TTS requirements=20 =0A= 4.3.1. Requesting Text Playback [6.1]=20 P+: A medial playback resource would be defined as a new BEEP=20 profile.=20 To initiate an media playback session, the client would need to ask=20 for this profile as part of the message which opens a new=20 channel.=20 =0A= 4.3.2. Text Formats [6.2]=20 =20 T: BEEP allows arbitrary data blocks of octets to be passed.=20 Messages must specify a length and must end with a specific=20 sequence of characters. Plain text, SSML, URIs, or other content=20 could be passed within BEEP messages.=20 =0A= 4.3.3. Plain text [6.2.1]=20 =20 T: See =20 =0A= 4.3.4. SSML [6.2.2]=20 =20 T: See =20 =0A= 4.3.5. Text in Control Channel [6.2.3]=20 =20 T: See =20 =0A= 4.3.6. Document Type Indication [6.2.4]=20 =20 T: BEEP provides for 'Content-Type' specification in the message=20 header. This may be used to determine the media type of the=20 message.=20 =0A= 4.3.7. Control Channel [6.3]=20 =20 T: A second channel might be created to pass control information.=20 The BEEP protocol dictates that the requests for each channel must=20 be handled in the order in which they are received. Separate=20 channels operate independently and may service request with=20 different priorities (though the BEEP specification does not=20 provide a mechanism for assigning priorities).=20 =20 =20 Wyld Expires =96 April 2003 [Page 5] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 4.3.8. Playback Controls [6.4]=20 =20 T: See 6.3. These messages would presumably be transmitted over the=20 control channel.=20 =0A= 4.3.9. Session Parameters [6.5]=20 =20 T: See 6.2. Session parameters are presumably content delivered=20 within a message.=20 =0A= 4.3.10. =0D Speech Markers [6.6]=20 =20 T: Speech markers might be delivered on a separate channel (as in=20 6.3). =20 Alternatively, BEEP is a peer-to-peer protocol so events might be=20 sent on the channel used to receive requests.=20 =0A= 4.4. Analysis of ASR requirements=20 =0A= 4.4.1. Requesting Automatic Speech Recognition [7.1]=20 =20 P+: An ASR resource would be defined as a new BEEP profile. To=20 initiate an ASR session, the client would need to ask for this=20 profile as part of the message which opens a new channel.=20 =0A= 4.4.2. XML [7.2]=20 =20 T: See response for 6.2.=20 =0A= 4.4.3. Grammar Specification [7.3.1]=20 =20 T: See response for 6.2.=20 =0A= 4.4.4. Explicit Indication of Grammar Format [7.3.2]=20 =20 T: See response for 6.2.4.=20 =0A= 4.4.5. Grammar Sharing [7.3.3]=20 =20 P+: Channels in BEEP are independent. If content is to be shared,=20 this would need to be added, preferably using messages to define=20 what content is to be shared and a corresponding identity. The=20 retrieval and actual sharing would need to be implemented by the=20 server.=20 =0A= 4.4.6. Session Parameters [7.4]=20 =20 T: See response for 6.2. Session parameters are presumably content=20 delivered within a message.=20 =0A= 4.4.7. Input Capture [7.5]=20 =20 P+: BEEP does not provide a mechanism for storing requests. Storing=20 of input could be added by the server.=20 =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 6] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 4.5. Analysis of Speaker Identification and Verification=20 Requirements=20 =0A= 4.5.1. Requesting SI/SV [8.1]=20 =20 P+: An SI/SV resource would be defined as a new BEEP profile. To=20 initiate an SI/SV session, the client would need to ask for this=20 profile as part of the message which opens a new channel.=20 =0A= 4.5.2. Identifiers for SI/SV [8.2]=20 =20 T: This could be handled in the 'Content-Type' or by other means.=20 Supported formats might be negotiated in a fashion similar to=20 security negotiation.=20 =0A= 4.5.3. State for multiple utterances [8.3]=20 =20 P+: BEEP has a concept of sequence. State would need to be added by=20 the client. This should be easy if a channel is used for multiple=20 utterances.=20 =0A= 4.5.4. Input Capture [8.4]=20 =20 P+: BEEP does not provide a mechanism for storing requests. Storing=20 of input could be added by the server.=20 =0A= 4.5.5. SI/SV functional extensibility [8.5]=20 =20 T: Extensions could be added as additional messages.=20 =0A= 4.6. Analysis of Duplexing and Parallel Operation Requirements=20 =0A= 4.6.1. Duplexing and Parallel Operation Requirements [9]=20 =20 P+: Parallel operations may be obtained using multiple channels. A=20 message on one channel could potentially interrupt activity=20 happening on the second. BEEP is very flexible allowing the server=20 to implement whatever behavior is desired.=20 =0A= 4.6.2. Full Duplex operation [9.1.1]=20 =20 T: BEEP is a peer-to-peer protocol allowing full duplex=20 communication on a single channel or parallel communication on=20 multiple channels.=20 =0A= 4.6.3. Multiple services in parallel [9.1.2]=20 =20 P+: Multiple services may be run on separate channels. Merging or=20 T-ing of RTP must be implemented by the server.=20 =0A= 4.6.4. Combination of services=20 TBD=20 =0A= 4.7. Analysis of additional considerations (non-normative)=20 TBD=20 =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 7] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 4.8. Analysis of Security considerations=20 =0A= 4.8.1. Security Considerations [11]=20 =20 P+: BEEP offers a mechanism for managing security and user=20 authentication. =20 SpeechSC requires managing multiple data streams and some form of=20 unified authentication / security might be a goal. If so, BEEP=20 security should be revisited with this in mind.=20 =20 =20 5. =0D Protocol =93SIP=94 Complience Evaluation (Rajiv = Dharmadhikari)=20 =0A= 5.1. Introduction=20 SIP is a protocol for initiating, modifying, and terminating=20 multimedia sessions. The protocol is considered an IETF standard=20 and its specifications can be found in [2]. The following sections=20 provides a general statement with regards to the applicability of=20 SIP as the control protocol for SPEECHSC. =20 =20 =0A= 5.1.1. SIP General Applicability=20 SIP is a pretty mature, well understood, and frequently used =20 session establishment protocol. It has gone through multiple=20 revisions in the IETF standard process. There are number of=20 commercial and public domain implementations of SIP that are=20 available. Because of its close resemblance to HTTP and being a=20 text based protocol, there are large number of SIP application=20 developers available. =20 =20 =0A= 5.1.2. SIP Use in VOIP environment=20 SIP is already being used to establish and redirect RTP streams=20 from various end points. The SPEECHSC requires a protocol for=20 controlling ASR, TTS and SV resources. When these resources are=20 deployed in a VOIP network that requires them to process media=20 carried in RTP, the SIP protocol is used in lot of deployments.=20 Rather than inventing a new control protocol and introducing=20 operational aspects of the new protocol, SIP can be reused for=20 controlling SPEECHSC resources. =20 =20 =0A= 5.2. Analysis of General Requirements=20 =0A= 5.2.1. Reuse existing protocols [5.1]=20 T: SIP is an existing, widely used, and mature protocol defined in=20 [2].=20 =0A= 5.2.2. Maintain Existing Protocol Integrity [5.2]=20 T: Existing SIP methods and header fields will not be changed when=20 SIP is used to control SPEECHSC resources. In case, if extensions=20 are required, SIP allows carriage of custom payload in the body.=20 This payload is understood only by UAs and it does not impact=20 protocol integrity.=20 =20 =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 8] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 5.2.3. Avoid Duplicating Existing Protocols [5.3]=20 T: Lot of the requirements for SPEECHSC operation can easily be=20 satisfied by SIP, e.g. establishing RTP streams or redirecting=20 them. Without SIP, new SPEECHSC protocol will have to duplicate lot=20 of session management functionality.=20 =20 =0A= 5.2.4. Protocol efficiency [5.4]=20 T: SIP is a very light weight protocol when run over TCP or UDP. It=20 leverages efficiency available in TCP and UDP protocols that have=20 been around for over 20 years.=20 =0A= 5.2.5. Explicit invocation of services [5.5]=20 T: SIP URI mechanism allows invocation of different services.=20 =0A= 5.2.6. Server Location and Load Balancing [5.6]=20 P+: SIP employs standard DNS name resolution for locating=20 resources. SIP itself does not provide load balancing features.=20 Application level load balancers can be used to load balance SIP=20 requests.=20 =20 =0A= 5.2.7. Simultaneous services [5.7]=20 T: SIP allows simultaneous invocation of different services. SIP=20 allows forking or splitting the same media stream to different end=20 points as defined in [2].=20 =20 =0A= 5.2.8. Multiple media sessions [5.8]=20 T: SIP uses SDP to describe RTP stream characteristics. This allows=20 the control of direction of RTP stream such as bi-directional or=20 uni-directional. SIP allows a UA to establish sessions with=20 multiple UAs for the same session.=20 =0A= 5.3. Analysis of TTS requirements=20 =0A= 5.3.1. Requesting Text Playback [6.1]=20 P+: SIP does not provide primitives for text playback. New SIP URI=20 can be defined to invoke TTS features. =20 =0A= 5.3.2. Text Formats [6.2]=20 T: SIP message body can carry TTS text or reference to the TTS=20 text. =20 =20 =0A= 5.3.3. Plain text [6.2.1]=20 T: =20 =0A= 5.3.4. SSML [6.2.2]=20 T:=20 =0A= 5.3.5. Text in Control Channel [6.2.3]=20 T :=20 =0A= 5.3.6. Document Type Indication [6.2.4]=20 T:=20 =20 =20 Wyld Expires =96 April 2003 [Page 9] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 5.3.7. Control Channel [6.3]=20 T: Separate SIP URI can be defined for control channel. =20 =0A= 5.3.8. Playback Controls [6.4]=20 P+: See 5.3.1=20 =0A= 5.3.9. Session Parameters [6.5]=20 P+: Session parameters can be passed in body part of SIP or can be=20 modified by using mid call methods of SIP.=20 =0A= 5.3.10. =0D Speech Markers [6.6]=20 =20 T: Speech markers can be delivered using a separate control=20 channel. See 5.3.7.=20 =0A= 5.4. Analysis of ASR requirements=20 =0A= 5.4.1. Requesting Automatic Speech Recognition [7.1]=20 T: New SIP URI can be defined to address ASR services and=20 requesting ASR resources.=20 =0A= 5.4.2. XML [7.2]=20 T: SIP message body can carry XML.=20 =0A= 5.4.3. Grammar Specification [7.3.1]=20 P+: With proper definition, SIP message body can carry XML grammars=20 or references to the XML grammars.=20 =20 =0A= 5.4.4. Explicit Indication of Grammar Format [7.3.2]=20 P+: See 5.4.3.=20 =0A= 5.4.5. Grammar Sharing [7.3.3]=20 TBD=20 =0A= 5.4.6. Session Parameters [7.4]=20 T: Session parameters can be passed in body part of SIP or can be=20 modified by using mid call methods of SIP.=20 =0A= 5.4.7. Input Capture [7.5]=20 T: SIP SUBSCRIBE/NOTIFY mechanism can be used initiate input=20 capture and receive the result. =20 =20 =0A= 5.5. Analysis of Speaker Identification and Verification=20 Requirements=20 =0A= 5.5.1. Requesting SI/SV [8.1]=20 T: New SIP URI can be defined for SI/SV.=20 =0A= 5.5.2. Identifiers for SI/SV [8.2]=20 T: See 5.5.1.=20 =0A= 5.5.3. State for multiple utterances [8.3]=20 TBD=20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 10] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 5.5.4. Input Capture [8.4]=20 T: SIP SUBSCRIBE/NOTIFY mechanism can be used initiate input=20 capture and receive the result.=20 =0A= 5.5.5. SI/SV functional extensibility [8.5]=20 T: SIP can easily be extended by adding new methods and header=20 fields without impacting the operation of existing methods. The new=20 methods and headers will only be understood by the SPEECHSC=20 entities. If above is not acceptable, SIP message body of an=20 existing primitive can be used to define new semantics that is=20 understood only by SPEECHSC entities.=20 =0A= 5.6. Analysis of Duplexing and Parallel Operation Requirements=20 =0A= 5.6.1. Duplexing and Parallel Operation Requirements [9]=20 T: SPEECHSC resource is a SIP UA that can handle session requests=20 from different UAs.=20 =0A= 5.6.2. Full Duplex operation [9.1.1]=20 T: Each SIP UA consists of a UAC and a UAS. This allows for full=20 duplex operation.=20 =0A= 5.6.3. Multiple services in parallel [9.1.2]=20 T: SIP allows simultaneous invocation of different services. SIP=20 allows forking or splitting the same media stream to different end=20 points as defined in [2].=20 =20 =0A= 5.6.4. Combination of services=20 T: See 5.6.3. SIP UA can invoke different services and combine the=20 results.=20 =0A= 5.7. Analysis of additional considerations (non-normative)=20 TBD=20 =0A= 5.8. Analysis of Security considerations=20 =0A= 5.8.1. Security Considerations [11]=20 T: SIP protocol employs different authentication schemes that are=20 widely used in IP based protocols.=20 =0A= 5.9. Other Criteria=20 The following criteria were also defined by the evaluator of SIP.=20 =0A= 5.9.1. Ability to establish session between SPEECHSC client=20 and SPEECHSC resource=20 T: SIP User Agent can establish a session with another SIP User=20 Agent.=20 =0A= 5.9.2. Ability to terminate session by either SPEECHSC=20 client or SPEECHSC resource=20 T: SIP User Agent can terminate a session with another SIP User=20 Agent.=20 =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 11] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 5.9.3. Support reliable sequencing and delivery between=20 SPEECHSC client and SPEECHSC resource=20 P: SIP can be run over TCP or UDP. When run over TCP, this=20 requirement is easily satisfied. When run over UDP, SIP User Agent=20 is required to implement logic to ensure reliable sequencing and=20 delivery. =20 =0A= 5.9.4. Ability for SPEECHSC client to coordinate SPEECHSC=20 resources on different machines for a single session=20 T: SPEECHSC client can use SIP to establish SIP sessions with=20 different machines.=20 =0A= 5.9.5. Ability for SPEECHSC resource to handle multiple=20 SPEECHSC clients=20 T: SPEECHSC resource is a SIP UA that can handle session requests=20 from different UAs.=20 =0A= 5.9.6. The SPEECHSC resource should be able to generate=20 asynchronous events or unsolicited messages=20 T: SIP allows asynchronous events or unsolicited messages to be=20 generated using SUBSCRIBE/NOTIFY mechanism.=20 =0A= 5.9.7. The SPEECHSC client and resource should have ability=20 for authenticating each other=20 T: SIP protocol employs different authentication schemes that are=20 widely used in IP based protocols.=20 =0A= 5.9.8. Ability to determine success or failure from both=20 SPEECHSC client and SPEECHSC resource side=20 T: The protocol has following response codes: 200 for success, 3xx,=20 4xx, and 5xx for failure.=20 =0A= 5.9.9. Support for versioning between SPEECHSC client and=20 SPEECHSC resource=20 P+: This will require an additional header or element in the =20 body of SIP message for versioning. The current version field is=20 intended for SIP protocol version. =20 =20 =20 6. =0D Protocol =93RTSP=94 Complience Evaluation (Brian = Wyld)=20 =0A= 6.1. General Introduction=20 RTSP is an existing protocol, orientated towards audio playback and=20 recording. As such, it has support for RTP session control, with=20 SDP used for session description, and a message set allowing=20 operation as a player/recorder with audio =93VCR=94 controls.=20 =20 To use RTSP for speechsc, two options present themselves:=20 - new =93operations=94 (like PLAY) would be defined with their own=20 specific state machines after a session is created. Note that=20 this could be seen as the merge of the MRCP proposed protocol=20 operations into the RTSP protocol directly.=20 - The existing operations could be =91extended=92 to describe = speechsc=20 operations eg PLAY would both be applicable for play of a audio=20 file and for synthesis of a TTS text. =20 =20 In the second case new headers would be defined to allow definition=20 of the text or of its location. The current PLAY state machine is=20 =20 =20 Wyld Expires =96 April 2003 [Page 12] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 exactly as required for TTS operation. Although by analogy RECORD=20 could initiate an ASR session, with headers giving the grammer=20 source or references, it=92s state machine does not seem as=20 compatible, still less for SV/SI. Defining new messages/state=20 machines would be better for these operations.=20 =20 The following analysis assumes that TTS operation is merged with=20 the current PLAY semantics, while ASR/SV/SI create new messages and=20 state operations.=20 =20 The following sub-sections compare each individual requirement=20 against the protocol.=20 =0A= 6.2. Analysis of General Requirements=20 =0A= 6.2.1. Reuse existing protocols [5.1]=20 T: RTSP/RTP/SDP would be reused.=20 =0A= 6.2.2. Maintain Existing Protocol Integrity [5.2]=20 T: The extensions to RTSP to allow speechsc use would be in the=20 spirit of the protocol, and would not break existing servers or=20 clients.=20 =0A= 6.2.3. Avoid Duplicating Existing Protocols [5.3]=20 T: Using RTSP would not recreate it.=20 =0A= 6.2.4. Protocol efficiency [5.4]=20 T: RTSP is a text based protocol, but is relatively succinct as=20 messages are specific to their operation.=20 =0A= 6.2.5. Explicit invocation of services [5.5]=20 T: RTSP service invocation is sufficient.=20 =0A= 6.2.6. Server Location and Load Balancing [5.6]=20 F: RTSP does not address this topic; however it can be used with=20 other IETF protocols such as SLP or UDDI to do so.=20 =0A= 6.2.7. Simultaneous services [5.7]=20 T: RTSP allows simultaneous invocation of services on the same or=20 different control channel.=20 =0A= 6.2.8. Multiple media sessions [5.8]=20 T: RTSP allows multiple media sessions.=20 =0A= 6.3. Analysis of TTS requirements=20 =0A= 6.3.1. Requesting Text Playback [6.1]=20 P+: by extension of the RTSP PLAY message semantics=20 =0A= 6.3.2. Text Formats [6.2]=20 P+: Text can be defined as all text types. =20 =0A= 6.3.3. Plain text [6.2.1]=20 T: Plain text may be carried directly in the message payload.=20 =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 13] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 6.3.4. SSML [6.2.2]=20 T: Text may be in any format.=20 =0A= 6.3.5. Text in Control Channel [6.2.3]=20 T: Text may be attached to the control messages.=20 =0A= 6.3.6. Document Type Indication [6.2.4]=20 T : Via the Content-Type header=20 =0A= 6.3.7. Control Channel [6.3]=20 T: RTSP sessions may use a private or shared TCP connection.=20 =0A= 6.3.8. Playback Controls [6.4]=20 T: RTSP defines playback control messages and a state machine.=20 =0A= 6.3.9. Session Parameters [6.5]=20 T: RTSP defines operations for session parameter control.=20 =0A= 6.3.10. =0D Speech Markers [6.6]=20 P+: Markers may be inserted in the text, but to provide the=20 required asynchronous events when a marker is synthesized will=20 require use specific ANNOUNCE type messages for server->client=20 notification.=20 =0A= 6.4. Analysis of ASR requirements=20 =0A= 6.4.1. Requesting Automatic Speech Recognition [7.1]=20 P+: by addition of a message and state machine.=20 =0A= 6.4.2. XML [7.2]=20 P+: Text can be defined as all text types.=20 =0A= 6.4.3. Grammar Specification [7.3.1]=20 P+: Text can be defined as all text types.=20 =0A= 6.4.4. Explicit Indication of Grammar Format [7.3.2]=20 T : Via the Content-Type headers=20 =0A= 6.4.5. Grammar Sharing [7.3.3]=20 F: TBD=20 =0A= 6.4.6. Session Parameters [7.4]=20 T: RTSP defines operations for session parameter control.=20 =0A= 6.4.7. Input Capture [7.5]=20 P+: addition of a header to the initiation message.=20 =0A= 6.5. Analysis of Speaker Identification and Verification=20 Requirements=20 =0A= 6.5.1. Requesting SI/SV [8.1]=20 P+: by addition of a message and state machine.=20 =0A= 6.5.2. Identifiers for SI/SV [8.2]=20 P+: by addition of specific headers.=20 =20 =20 Wyld Expires =96 April 2003 [Page 14] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 6.5.3. State for multiple utterances [8.3]=20 TBD=20 =0A= 6.5.4. Input Capture [8.4]=20 P+: addition of a header to the initiation message.=20 =0A= 6.5.5. SI/SV functional extensibility [8.5]=20 TBD=20 =0A= 6.6. Analysis of Duplexing and Parallel Operation Requirements=20 =0A= 6.6.1. Duplexing and Parallel Operation Requirements [9]=20 T: RTSP allows session setup that should fulfill these=20 requirements.=20 =0A= 6.6.2. Full Duplex operation [9.1.1]=20 T: RTSP can create a full duplex session.=20 =0A= 6.6.3. Multiple services in parallel [9.1.2]=20 T: RTSP can request multiple operations of the same type on the=20 same session.=20 =0A= 6.6.4. Combination of services=20 T: RTSP can request multiple operations of different types on the=20 same session.=20 =0A= 6.7. Analysis of additional considerations (non-normative)=20 TBD=20 =0A= 6.8. Analysis of Security considerations=20 =0A= 6.8.1. Security Considerations [11]=20 F: RTSP provides no specific security functionality at all, but=20 depends on other IETF security protocols (as it uses TCP) to pre- validate and protect the sessions.=20 =20 7. =0D Protocol =93MRCP=94 Complience Evaluation (Sarvi = Shanmugham)=20 =0A= 7.1. General =20 =0A= 7.1.1. MRCP Framework and General Applicability=20 =20 The overall MRCP framework, the components involved and their=20 distribution and relationship to each other meet the framework=20 specified by SPEECHSC. The primary advantage of MRCP is that it is=20 a text based protocol designed to meet most of the requirements of=20 SPEECHSC pertaining to speech recognition and Text to speech.=20 Though Speaker Recognition (SR) and Speaker Verification (SV) are=20 not supported in its current form, MRCP was explicitly designed to=20 be extendable for such needs. The core MRCP definition only deals=20 with the control of the ASR or TTS resource and the commands and=20 responses needed to achieve it.=20 =20 There are multiple interoperable implementations of MRCP and hence=20 is a proven technology. It leverages existing W3C XML standards for=20 exchange of data between the client and the server resource. For=20 =20 =20 Wyld Expires =96 April 2003 [Page 15] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 Example, its uses the W3C XML grammar format (GRXML) along with W3C=20 semantic attachments and Natural Language Semantic Markup Language=20 to exchange data with speech recognition resource. The W3C Speech=20 Markup Language is used when dealing with Text to speech engines.=20 =20 It was designed to work as a tunneled protocol, over RTSP or SIP.=20 Hence it depends on the carrier protocol to establish a control and=20 a media path between the client and the ASR or TTS server resource.=20 Hence it gets most of the security and media pipe management=20 operations for free. Once these are established, MRCP commands and=20 responses are tunneled over, controlling the ASR or TTS resource on=20 the server. =20 =0A= 7.1.2. MRCP can be evolved=20 =20 Though MRCP directly meets many of the needs of SPEECHSC. The=20 notion that it is a tunneled protocol disallows its independent=20 operation. Further more the tunneled aspect is also a less=20 efficient protocol design. =20 =20 But these can be addressed and the core MRCP messages can be=20 evolved to either become standalone protocol by itself or=20 extensions to an existing protocol such as SIP or RTSP. To make=20 this a standalone protocol and allow MRCP to operate by itself, new=20 session and media management messages need to be defined to allow=20 it to operate independently. To evolve MRCP as extensions to SIP or=20 RTSP would also be relatively simple since it is also a text based=20 protocol with message format and headers very similar to them. In=20 this protocol evaluation, the compliance evaluates MRCP from the=20 perspective of evolution in one of these forms.=20 =20 The following sub-sections compare each individual requirement=20 against the protocol.=20 =0A= 7.2. Analysis of General Requirements=20 =0A= 7.2.1. Reuse existing protocols [5.1]=20 T: If RTSP or SIP is extended with MRCP, it will be reusing an=20 existing protocol. If MRCP was extended to become a standalone=20 protocol, it wouldn=92t.=20 =0A= 7.2.2. Maintain Existing Protocol Integrity [5.2]=20 T: If RTSP or SIP is extended with MRCP, it can be done in a way=20 that maintains the integrity of the protocol.=20 =0A= 7.2.3. Avoid Duplicating Existing Protocols [5.3]=20 T: If RTSP or SIP is extended with MRCP, it would be meet this=20 requirement. If MRCP was extended to become a standalone protocol,=20 it wouldn=92t.=20 =0A= 7.2.4. Protocol efficiency [5.4]=20 P: MRCP as it exists is sub-optimal due to its tunneling. On the=20 other hand, if it were extended as standalone protocol or with RTSP=20 or SIP, it would meet this requirement.=20 =0A= 7.2.5. Explicit invocation of services [5.5]=20 T:=20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 16] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 7.2.6. Server Location and Load Balancing [5.6]=20 T:If MRCP were extended as a standalone protocol it could designed=20 to meet this requirement. If MRCP was used to extend SIP or RTSP,=20 it would automatically inherit their capability this area and hence=20 would meet this requirement.=20 =0A= 7.2.7. Simultaneous services [5.7]=20 T: MRCP as it exists does meet this requirement already. It could=20 continue to do so even if it is extended in wither of the ways=20 suggested here.=20 =0A= 7.2.8. Multiple media sessions [5.8]=20 P+: MRCP shares a single 2 way media pipe between ASR and TTS=20 today. Considering it supports only 2 resources and they treat=20 media in different directions it currently doesn=92t meet this=20 requirement completely. Again, SI or SV was added to MRCP as it=20 exists, a standalone protocol or as an extension to RTSP/SIP, it=20 could be designed to meet this requirement.=20 =0A= 7.3. Analysis of TTS requirements=20 =0A= 7.3.1. Requesting Text Playback [6.1]=20 T: MRCP has the SPEAK method for the client to request the TTS=20 resource to playback text as an audio stream.=20 =0A= 7.3.2. Text Formats [6.2]=20 T: When the client requests the TTS resource to playback a text=20 stream it can provide the content in the following formats and=20 through the following mechanism.=20 =20 1. Plain text=20 2. W3C XML based Speech Markup Language (SSML)=20 3. This content to be spoken can be provided by value directly=20 through the control path. =20 4. It also supports passing the content by reference. This is=20 achieved having an audio tag inside the SSML markup text.=20 This URL is then fetched and played on the RTP stream in=20 sequence with the rest of the text according to the SSML=20 specification.=20 When the client sends plain text, SSML or another format of speech=20 text the content is coded as a mime-type. Hence the server knows=20 what format the speech content is coded in, and does not have to=20 figure it out from the content.=20 =0A= 7.3.3. Plain text [6.2.1]=20 T: see above=20 =0A= 7.3.4. SSML [6.2.2]=20 T: see above=20 =0A= 7.3.5. Text in Control Channel [6.2.3]=20 T : see above=20 =0A= 7.3.6. Document Type Indication [6.2.4]=20 T: see above=20 =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 17] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 7.3.7. Control Channel [6.3]=20 T: In MRCP, this Reset-Audio-Channel header defined for the ASR=20 resource allows the recognizer to re-initialize the audio=20 characteristics that it has learnt till then. This allows a=20 recognizer resource to be used for multiple recognition sessions.=20 It can be used for short single utterance recognitions as well.=20 This is by applying the Reset-Audio-Channel header to every=20 recognition. I suspect the performance may not be as good, due to=20 the lack of line characteristics, but this is a recognizer issue.=20 =0A= 7.3.8. Playback Controls [6.4]=20 T: MRCP supports the CONTROL method with the Jump-Target header can=20 used to achieve, jumping in time or to an exact or relative=20 location. It supports jumping in paragraphs, sentences, words and=20 to specific markers that may be embedded in the speech content. The=20 CONTROL method can be used with the Voice and Prosody parameters,=20 derived from SSML, and can address the speed of speech or=20 increasing/decreasing the volume. It also supports the PAUSE/RESUME=20 methods to pause or resume a current SPEAK request.=20 =0A= 7.3.9. Session Parameters [6.5]=20 T: As mentioned the previous section, MRCP supports voice and=20 prosody parameters which are directly derived from the W3C SSML=20 specification. These headers can be sent using the SET-PARAMS=20 method and applied as a default for the entire session. They can=20 also be applied in SPEAK requests to apply per usage or in the=20 CONTROL message to change the parameters of an active SPEAK=20 request.=20 =0A= 7.3.10. =0D Speech Markers [6.6]=20 T: Specifying speech markers in the content is supported through=20 SSML. The CONTROL message can then be used to jump to specific=20 marker points in the text. Also, when the TTS resource reaches=20 specific markers in the text, the server would generate the SPEECH- MARKER method to the client.=20 =0A= 7.4. Analysis of ASR requirements=20 =0A= 7.4.1. Requesting Automatic Speech Recognition [7.1]=20 T: The client uses the RECOGNIZE method in MRCP to request the=20 recognition resource to process the audio stream in the pipe. The=20 RECOGNIZE method also specifies parameters and grammars the=20 recognizer should match against.=20 =0A= 7.4.2. XML [7.2]=20 T: Similar to the TTS resource in MRCP, ASR also uses XML data to=20 exchange information between the client and the recognition=20 resource. It supports the W3C GRXML to pass grammars from the=20 client to the server. When the server is done recognizing, it uses=20 the W3C Natural Language Semantic Markup Language (NLSML) to pass=20 the results back to the client. It supports other grammar formats=20 as well, as long as the server allows it. This is possible since,=20 it uses mime-types to package this data and hence the format type=20 is specified.=20 =0A= 7.4.3. Grammar Specification [7.3.1]=20 P+: MRCP supports specifying the grammar both by value and by=20 reference. The RECOGNIZE method can carry with it grammar content=20 =20 =20 Wyld Expires =96 April 2003 [Page 18] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 and/or a URI referring to the grammar content. Since MRCP supports=20 referring a grammar, the referred grammar could be located on the=20 server itself. With respect to sharing of grammars, the grammars=20 defined/compiled through the DEFINE-GRAMMAR primitive are not=20 sharable across sessions on the same server. This needs to be=20 addressed to meet this set of requirements in full.=20 =0A= 7.4.4. Explicit Indication of Grammar Format [7.3.2]=20 P+: see above=20 =0A= 7.4.5. Grammar Sharing [7.3.3]=20 TBD=20 =0A= 7.4.6. Session Parameters [7.4]=20 T: This requirement as defined is already fully met since MRCP is=20 the referred standard for compliance.=20 =0A= 7.4.7. Input Capture [7.5]=20 T: This is achieved by setting the Waveform-url header in the=20 RECOGNIZE method. This tells the server to record the audio of the=20 recognition and will return a URI to the client in the completion=20 event, which can be used to retrieve or play back the audio.=20 =0A= 7.5. Analysis of Speaker Identification and Verification=20 Requirements=20 =0A= 7.5.1. Requesting SI/SV [8.1]=20 F: not supported=20 =0A= 7.5.2. Identifiers for SI/SV [8.2]=20 F: not supported=20 =0A= 7.5.3. State for multiple utterances [8.3]=20 F: not supported=20 =0A= 7.5.4. Input Capture [8.4]=20 F: not supported=20 =0A= 7.5.5. SI/SV functional extensibility [8.5]=20 F: not supported=20 =0A= 7.6. Analysis of Duplexing and Parallel Operation Requirements=20 =0A= 7.6.1. Duplexing and Parallel Operation Requirements [9]=20 =0A= 7.6.2. Full Duplex operation [9.1.1]=20 T: MRCP supports having the ASR and TTS engines on the same server.=20 When in this mode they use a single full-duplex audio stream to=20 both recognize audio and generate a TTS voice stream.=20 =20 =0A= 7.6.3. Multiple services in parallel [9.1.2]=20 F: MRCP doesn=92t support SI or SV.=20 =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 19] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 7.6.4. Combination of services=20 F: MRCP assumes that the recognizer to be a combined unit and does=20 not support separating of sub-components like semantic analyzers.=20 =0A= 7.7. Analysis of additional considerations (non-normative)=20 T: Since MRCP works with SIP or RTSP, it uses SDP for session=20 description and can work with other transport schemes like ATM etc.=20 It uses standard codecs and can work with specialized codecs like=20 DSR.=20 =0A= 7.8. Analysis of Security considerations=20 =0A= 7.8.1. Security Considerations [11]=20 T: Since MRCP works with RTSP, it inherits the security=20 considerations of SIP or RTSP.=20 =20 =20 8. =0D Protocol =93Web Services=94 Complience Evaluation = (Stephane H.=20 Maes)=20 =0A= 8.1. General Notes:=20 Speech engines (speech recognition, speaker, recognition, speech =20 synthesis, recorders and playback, NL parsers, and any other speech=20 processing engines (e.g. speech detection, barge-in detection etc) =20 etc...) as well as audio sub-systems (audio input and output =20 sub-systems) can be considered as web services that can be =20 described and asynchronously programmed via WSDL (on top of SOAP), =20 combined in a flow described via WSFL, discovered via UDDI and =20 asynchronously controlled via SOAP that also enables =20 asynchronous exchanges between the engines.=20 =20 This solution presents the advantage to provide flexibility, =20 scalability and extensibility while reusing an existing framework =20 that fits the evolution of the web: web services and XML protocols=20 [WS1]=20 =20 According to the web services framework, speech engines (audio =20 sub-systems, engines, speech processors) can be defined as web=20 services=20 that are characterized by an interface that consists of some of the = following ports:=20 - "control in" port(s): It sets the engine context, i.e. all=20 the=20 settings required for a speech engine to run. It may include =20 addresses where to get or send the streamed audio or results.=20 - "control out" port(s): It produces the non-audio engine=20 output=20 (i.e. results and events). It may also involve some session =20 control exchanges.=20 - "audio in" port(s): It receives streamed input data. =20 - "audio out" port(s): It produces streamed output data. =20 =20 Audio sub-systems can also be treated as web services that can =20 produce streamed data or play incoming streamed data as specified=20 by=20 the control parameters.=20 =20 The "control in" or "control out" messages can be out-of-band or =20 =20 =20 Wyld Expires =96 April 2003 [Page 20] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 sent or received interleaved with "audio in or out" data. This can =20 be determined in the context (setup) of the web services. =20 =20 Speech engines and audio sub-systems are pre-programmed as web =20 services and composed into more advanced services. Once programmed =20 by the application / controller, audio-sub-systems and engines=20 await=20 an incoming event (established audio session, etc...) to execute=20 the=20 speech processing that they have been programmed to do and send the = results as programmed. =20 =20 Speech engines as web services are typically programmed to handle =20 completely a particular speech processing task, including handling =20 of possible errors. For example, as speech engine is programmed to =20 perform recognition of the next incoming utterance with a=20 particular=20 grammar, to send result to a NL parser and to contact a particular =20 error recovery process if particular errors occur.=20 =20 The following sub-sections compare each individual requirement=20 against the protocol.=20 =0A= 8.2. Analysis of General Requirements=20 =0A= 8.2.1. Reuse existing protocols [5.1]=20 T: Web services are is a class of protocols (framework) widely=20 studied and developed across numerous standard bodies like W3C,=20 OASIS, WS-I, Liberty, Parlay and adapted to numerous deployment=20 environments issues at IETF, OMA, 3GPP, 3GPP2, JCP, etc=85 As an=20 entry point, we recommend consulting the work at W3C [WS1].=20 =20 =0A= 8.2.2. Maintain Existing Protocol Integrity [5.2]=20 T: Web services is an XML-based framework that is by definition=20 extensible to support appropriate syntax and semantics. =20 =20 Web services are bound on underlying transport protocols. Numerous=20 such binding have been specified. Others are in development. By=20 handling at SPEECHSC at the level of the =20 Web services framework, the integrity is maintained for:=20 - underlying transport protocols (to which the web service are=20 bound (e.g. SOAP)=20 - web service framework=20 =20 This does not prevent introducing bindings to new protocols if=20 needed. For example, binding to SIP or BEEP could be advantageous=20 for mobile deployments.=20 =20 =0A= 8.2.3. Avoid Duplicating Existing Protocols [5.3]=20 T: By definition, the web service framework can be specified to=20 remote control any web service. Specified syntax can be limited to=20 avoid duplicating remote control functionalities offered by other=20 protocols. =20 =20 At the same time, the extensibility inherent to the framework=20 guarantees that it is possible to specify (standard) or define=20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 21] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 (application specific) remote control for other entities beyond the=20 current scope of SPEECHSC. =20 =20 In that context and in view of unifying the remote control=20 framework exposed to an application developer or a system=20 integrator, it may be of interest to provide remote control syntax=20 for special entities like prompt player etc=85=20 =20 =0A= 8.2.4. Protocol efficiency [5.4]=20 P+ to P: Web services are by definition more verbose protocols.=20 Hence, at this stage this does not qualify work a T mark. =20 =20 However work is in progress (e.g. OMA, JCP) to optimize the=20 exchanges to handle:=20 - Client with limited resources=20 - Constrained bandwidth=20 These rely on protocol compression and optimization, caching and=20 gateways. =20 =20 As such the protocols qualify as P+.=20 =20 In addition, based on the qualification of efficiency provided in=20 [WS8], the web service framework proposed for SPEECHSC and=20 described in [WS1] relies indeed on known efficient techniques:=20 - Asynchronous pre-programming of the engines as web services to=20 reduce exchanges and avoid racing conditions=20 - Possibility to piggy back on response message if transported on=20 optimized protocols like SIP or BEEP. =20 - state caching in the engines that are considered as stand-alone,=20 pre-packaged and pre-programmed engines.=20 - etc=85=20 =20 =0A= 8.2.5. Explicit invocation of services [5.5]=20 T: Web service is typically used in a client-server environment.=20 Solutions exist for peer to peer (service to service) etc=85 =20 =20 Web services have been deigned to support clients and servers at=20 least one of which is operating directly on behalf of the user=20 requesting the service.=20 =20 In addition, work on-going at OMA and JCP addresses some of these=20 issues in mobile environment with the introduction of possible web=20 service gateways. =20 =20 =0A= 8.2.6. Server Location and Load Balancing [5.6]=20 T: Web services are widely developed for e-business applications.=20 Numerous tools and mechanisms have been provided for service=20 discovery ad advertisement. In addition, numerous offerings provide=20 routing and load balancing capabilities as part of the web=20 application server used to deploy the web service. =20 =20 Note that web services do not specify server location or load=20 balancing; but they are deployed on systems that provide such=20 functionalities. As web services are expected to be widely used in=20 the future and central to most e-business offerings, it is to=20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 22] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 expect that such tools will become even more pervasive and=20 efficient.=20 =20 =0A= 8.2.7. Simultaneous services [5.7]=20 Web services allow control (interface) and composition of web=20 services at will (e.g. WSFL).=20 =0A= 8.2.8. Multiple media sessions [5.8]=20 T: The framework proposed does not pre-supposes how many ports or=20 streams are associated to the engine. Different inbound and=20 outbound can be used at will=20 =0A= 8.3. Analysis of TTS requirements=20 =0A= 8.3.1. Requesting Text Playback [6.1]=20 T: (supported =96 syntax to be defined; which is consistent with the = web service framework)=20 =20 As described, TTS engines can be pre-programmed as web services to=20 perform TTS on incoming text. This is simply a matter of agreeing=20 on the control syntax to do so. The text to play back can be part=20 of the control instructions transmitted in SOAP to the TTS engine.=20 =0A= 8.3.2. Text Formats [6.2]=20 T: Exchanged format for text can be any MIME type; including plain=20 text.=20 =0A= 8.3.3. Plain text [6.2.1]=20 T: Exchanged format for text can be any MIME type; including plain=20 text.=20 =0A= 8.3.4. SSML [6.2.2]=20 T: Exchanged format for text can be any MIME type; including XML=20 and hence SSML=20 =0A= 8.3.5. Text in Control Channel [6.2.3]=20 TBD=20 =0A= 8.3.6. Document Type Indication [6.2.4]=20 T: SOAP and the web service framework built on SOAP rely on XML and=20 MIME type to identify media types. This is at the core of data=20 exchange in SOAP.=20 =20 =0A= 8.3.7. Control Channel [6.3]=20 T: As proposed above, SOAP [WS2] and WSDL [WS3] support the remote=20 control of the web services (engines or media processing entity).=20 =0A= 8.3.8. Playback Controls [6.4]=20 T: (supported =96 syntax to be defined; which is consistent with the = web service framework)=20 =20 This is simply a matter of agreeing on the control syntax to do so=20 as part of the control instructions transmitted in SOAP to the TTS=20 engine.=20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 23] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 8.3.9. Session Parameters [6.5]=20 T: Session parameters are presumably content delivered as part of=20 the control instructions transmitted in SOAP to the TTS engine.=20 =20 =0A= 8.3.10. =0D Speech Markers [6.6]=20 T: Speech markers are presumably content delivered as part of the=20 control instructions transmitted in SOAP to the TTS engine.=20 [NDLR : how are the marker events returned to the client end?]=20 =0A= 8.4. Analysis of ASR requirements=20 =0A= 8.4.1. Requesting Automatic Speech Recognition [7.1]=20 T: (supported =96 syntax to be defined; which is consistent with the = web service framework)=20 =20 As described, ASR engines can be pre-programmed as web services to=20 perform speech recognition on incoming audio. This is simply a=20 matter of agreeing on the control syntax to do so. The instructions=20 and parameters (including data files like grammars etc=85) can be=20 part of the control instructions transmitted in SOAP to the ASR=20 engine. =20 =20 Results can be part of the web service messaging as supported by=20 the web service framework.=20 =0A= 8.4.2. XML [7.2]=20 T: Exchanged format for message can be any MIME type; including XML=20 and hence XML for controlling the ASR.=20 =0A= 8.4.3. Grammar Specification [7.3.1]=20 T: Grammar specification can be part of the messages to control the=20 ASR. This includes any MIME type; including XML for passing=20 grammars by values, other MIME format including binary and URI for=20 passing grammars by reference.=20 =0A= 8.4.4. Explicit Indication of Grammar Format [7.3.2]=20 T: SOAP and the web service framework built on SOAP rely on XML and=20 MIME type to identify media types. This is at the core of data=20 exchange in SOAP.=20 =0A= 8.4.5. Grammar Sharing [7.3.3]=20 T: The framework described supports pre-programming of the engines=20 per utterance, per session or in an unlimited manner. This way=20 grammar sharing can easily be achieved and controlled by an=20 external controller, application etc=85=20 =0A= 8.4.6. Session Parameters [7.4]=20 T: Session parameters are presumably content delivered as part of=20 the control instructions transmitted in SOAP to the ASR engine.=20 =0A= 8.4.7. Input Capture [7.5]=20 T: (supported =96 syntax to be defined; which is consistent with the = web service framework)=20 =20 As described, ASR engines can be pre-programmed as web services to=20 perform speech recognition on incoming audio. This is simply a=20 =20 =20 Wyld Expires =96 April 2003 [Page 24] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 matter of agreeing on the control syntax to do so. The instructions=20 and parameters (including data files like grammars etc=85) can be=20 part of the control instructions transmitted in SOAP to the ASR=20 engine. This cab include the syntax and instructions to capture the=20 audio.=20 =0A= 8.5. Analysis of Speaker Identification and Verification=20 Requirements=20 =0A= 8.5.1. Requesting SI/SV [8.1]=20 T: (supported =96 syntax to be defined; which is consistent with the = web service framework)=20 =20 As described, SI or SV engines can be pre-programmed as web=20 services to perform speaker recognition on incoming audio. This is=20 simply a matter of agreeing on the control syntax to do so. The=20 instructions and parameters (including data files like voice=20 prints, etc=85) can be part of the control instructions transmitted=20 in SOAP to the SI or SV engine. =20 =20 Results can be part of the web service messaging as supported by=20 the web service framework.=20 =0A= 8.5.2. Identifiers for SI/SV [8.2]=20 T: This can be part of the control message.=20 =0A= 8.5.3. State for multiple utterances [8.3]=20 T: This can be achieved by appropriately programming the SI or SV=20 engine across multiple utterances. This is simply a matter of=20 agreeing on the control syntax to do so. The framework described in=20 section 1 support spanning multiple utterances.=20 =0A= 8.5.4. Input Capture [8.4]=20 T: (supported =96 syntax to be defined; which is consistent with the = web service framework)=20 =20 As described, SI or SV engines can be pre-programmed as web=20 services to perform speaker recognition on incoming audio. This is=20 simply a matter of agreeing on the control syntax to do so. The=20 instructions and parameters (including data files like grammars=20 etc=85) can be part of the control instructions transmitted in SOAP=20 to the ASR engine. This can include the syntax and instructions to=20 capture the audio.=20 =0A= 8.5.5. SI/SV functional extensibility [8.5]=20 T: By definition a web service framework and XML are extensible to=20 new functionality and describe how extensibility is achieved.=20 =0A= 8.6. Analysis of Duplexing and Parallel Operation Requirements=20 =0A= 8.6.1. Duplexing and Parallel Operation Requirements [9]=20 T: As explained, web services allow control (interface) and=20 composition of web services at will (e.g. WSFL). Also, it does not=20 pre-supposes how many ports or streams are associated to the=20 engine. Different inbound and outbound can be used at will; in full=20 duplex or even between engines as supported by WSFL [WS4] and WSXl=20 [WS7].=20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 25] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 8.6.2. Full Duplex operation [9.1.1]=20 T:=20 =0A= 8.6.3. Multiple services in parallel [9.1.2]=20 T:=20 =0A= 8.6.4. Combination of services=20 T: As explained, web services allow control (interface) and=20 composition of web services at will (e.g. WSFL) into complex=20 parallel, serial or coordinated combinations as supported by WSFL=20 [WS4] and WSXl [WS7].=20 =0A= 8.7. Analysis of additional considerations (non-normative)=20 The framework proposed supports:=20 - Use of SDP to describe sessions and streams for the streamed=20 channels =20 - Time stamps could be transmitted as part of the control messages=20 at the web service level or in band (e.g. with dynamic payload=20 switch or within the payload).=20 - The framework is compatible with any encoding scheme. This is=20 illustrated by the work on SRF (Speech Recognition Framework)=20 driven at 3GPP that supports conventional and DSR optimized codecs=20 and possible exchange of speech meta-information (e.g. data that=20 may be required to facilitate and enhance the server-side=20 processing of the input speech and facilitate the dialog management=20 in an automated voice service. These may include keypad events=20 over-riding spoken input, notification that the UE is in hands-free=20 mode, client-side collected information (speech/no-speech, barge- in), etc=85.).=20 - SOAP over SIP or BEEP to support the framework described in=20 section 1 can also support VCR controls.=20 - real-time messaging between engine and control is supported=20 within the framework (e.g. via SOAP or XML events). The framework=20 also support exchange between engines (same process; see also WSXL=20 [WS7]).=20 =20 Although non-normative, the web service framework described=20 probably deserves marks of P+ to T.=20 =20 =0A= 8.8. Analysis of Security considerations=20 =0A= 8.8.1. Security Considerations [11]=20 Web services are evolving to provide security, authentication,=20 encryption, trust management and privacy . Details can be found for=20 example in [WS9] and explained in [WS10]. This is now an OASIS=20 activity [WS11].=20 =20 This framework would enable SPEECHSC to employ the security=20 mechanism provided bu WS-Security for the remote control aspects.=20 Exchanged media can rely on security mechanism at the transport /=20 streaming level.=20 =20 The web service framework described probably deserves marks of P+=20 to T.=20 =20 =20 =0A= =20 =20 Wyld Expires =96 April 2003 [Page 26] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 9. =0D Security Considerations =20 =20 Security considerations for the SPEECHSC protocol are covered by=20 the comparison against the specific Security requirements in the=20 SPEECHSC requirements document [1]. =20 =20 10. References =20 [1] E. Burger, =93Requirements for Distributed Control of ASR, SR = and=20 TTS Resources" draft-ietf-speechsc-reqts-00.txt, July 31, 2002.=20 =20 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.=20 Peterson, R. Sparks, M. Handley, E.Schooler, SIP: Session=20 Initiation Protocol, RFC3265, June 2002. (Obsoletes RFC2543)=20 =20 [WS1] W3C Web Services, http://www.w3c.org/2002/ws/=20 [WS2] Simple Object Access Protocol (SOAP)=20 http://www.w3c.org/2002/ws/=20 [WS3] Web Services Description Language (WSDL 1.1), W3C Note 15=20 March =20 2001, http://www.w3.org/TR/wsdl.=20 [WS4] Leymann, F., Web Service Flow Language, WSFL 1.0, May 2001, =20 http://www- 4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf=20 [WS5] UDDI, http://www.uddi.org/specification.html =20 [WS6] W3C Voice Activity, http://www.w3c.org/Voice/ =20 [WS7] WSXL - Web Service eXperience Language submitted to OASIS=20 WSIA =20 and WSRP - WSXL - Web Service eXperience Language submitted=20 to =20 OASIS WSIA and WSRP=20 [WS8] Requirements for Distributed Control of ASR, SI/SV and TTS=20 Resources, =20 draft-ietf-speechsc-reqts-01.txt=20 [WS9] Security in a Web Services World: A Proposed Architecture and=20 Roadmap, =20 April 7, 2002, Version 1.0, http://www.verisign.com/wss/wss.pdf=20 [WS10] Kapil Apshankar, WS-Security, Security for Web Services,=20 http://www.webservicesarchitect.com/content/articles/apshankar04.as p=20 [WS11] OASIS Web Services Security TC, http://www.oasis- open.org/committees/wss/=20 =20 Author=92s Address=20 =20 Brian Wyld =20 Eloquant SA=20 ZA Malvaisin Phone: +33 476 77 46 92 =20 Le Versoud, France Email: brian.wyld@eloquant.com =20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2002). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain=20 it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 =20 =20 Wyld Expires =96 April 2003 [Page 27] = =0C =0A= =0A= SPEECHSC Protocol Evaluation Template November 2002=20 =20 =20 are included on all such copies and derivative works. However,=20 this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English. The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its successors or=20 assigns. This document and the information contained=20 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,=20 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT=20 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20 PARTICULAR PURPOSE."=20 =20 =20 =20 =20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 28] =0C ------=_NextPart_000_01AD_01C281E9.D108E7A0-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Nov 4 14:58:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03361 for ; Mon, 4 Nov 2002 14:58:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4K0C719532 for speechsc-archive@odin.ietf.org; Mon, 4 Nov 2002 15:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4K0Cv19529 for ; Mon, 4 Nov 2002 15:00:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03335 for ; Mon, 4 Nov 2002 14:57:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4K06v19515; Mon, 4 Nov 2002 15:00:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Jw0v19403 for ; Mon, 4 Nov 2002 14:58:00 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03245 for ; Mon, 4 Nov 2002 14:55:27 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA4JvfxF006684; Mon, 4 Nov 2002 11:57:41 -0800 (PST) Received: from cisco.com (dhcp-128-107-139-102.cisco.com [128.107.139.102]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR00815; Mon, 4 Nov 2002 11:51:11 -0800 (PST) Message-ID: <3DC6D0CB.2BDA485F@cisco.com> Date: Mon, 04 Nov 2002 11:55:55 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brian.wyld@eloquant.com, "Speechsc (E-mail)" Subject: Re: [Speechsc] Updated version (v0.2) for speechsc WG Internet Draft submission protocol evaluation document References: <003501c27e11$3b6d5540$8300010a@hq.eloquant.com> Content-Type: multipart/mixed; boundary="------------3F481D11D43508A4B8BB0868" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------3F481D11D43508A4B8BB0868 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit some comments/questions on the document. Comment 1: My evaluations of MRCP were for the most part, how the protocol already met the requirements. And hence when it came to dealing with issues like SI/SV, they were classified as not supported. After reading some of the evaluations(such as web services), which pretty much does not directly meet most of the requirements. But seems to discuss mostly about how it can evolve with the additon of a NEW set of messaging to meet the requirements. If this is indeed to basis of protocol evaluation and considering MRCP was originally designed to be extensible for these exact needs. Even preliminary methods and formats for these resources were defined but not refined/implemented/tested due to priorities. The MRCP protocol evaluation would be (T) in most of the SI/SV requirements. Other comments: Based on the above, the following sections will change in meeting the requirments. In all the following sections, texts already provided, addresses how MRCP could be evolved to meet the needs in FULL, if it does' not already meet it in full. 7.2.4. Protocol efficiency [5.4] - would become T 7.2.8. Multiple media sessions [5.8] - would become T 7.4.3. Grammar Specification [7.3.1] - would become T 7.4.4. Explicit Indication of Grammar Format [7.3.2] - should be T already without any needed changes. 7.4.5. Grammar Sharing [7.3.3] - This again would be T. since the DEFINE-GRAMMAR method could be extended to define grammars that cna be shared across sessions, and URI mechanism used to identify, define and refer to such grammars. 7.5. Analysis of Speaker Identification and Verification Requirements - This whole section would then be T, since this can be achieved by additon new methods to address these needs, and since MRCP was designed with these future extensions in mind. 7.6.3. Multiple services in parallel [9.1.2] - T if 7.5 is extensions are added. thx, Sarvi Brian Wyld wrote: > Hi, > > Sorry, but attached is an UPDATE to the draft I just submitted to take > account of last minute additions. This draft is v0.2. I have also re-created > the .txt to be in US Letter size format as per most IETF docs.... > > I hope this version can be the legitimate Internet Draft for speechsc > protocol evaluation. Please ignore the previous version. > > Thanks > > Brian > > [Brian Wyld] [brian.wyld@eloquant.com] > [Directeur General R&D] > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > [advanced solutions for telecoms and IT services] > > ------------------------------------------------------------------------ > Name: draft-speechsc-protocol-eval-v02.txt > draft-speechsc-protocol-eval-v02.txt Type: Plain Text (text/plain) > Encoding: quoted-printable --------------3F481D11D43508A4B8BB0868 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------3F481D11D43508A4B8BB0868-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Nov 4 15:39:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05359 for ; Mon, 4 Nov 2002 15:39:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4KfD622547 for speechsc-archive@odin.ietf.org; Mon, 4 Nov 2002 15:41:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KfDv22544 for ; Mon, 4 Nov 2002 15:41:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05322 for ; Mon, 4 Nov 2002 15:38:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Kf6v22535; Mon, 4 Nov 2002 15:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Ketv22521 for ; Mon, 4 Nov 2002 15:40:55 -0500 Received: from mfe2.prod.danger.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05318 for ; Mon, 4 Nov 2002 15:38:21 -0500 (EST) Received: from [10.12.5.251] (HELO localhost) by mfe2.prod.danger.com (CommuniGate Pro SMTP 4.0b6) with SMTP id 492633; Mon, 04 Nov 2002 12:40:48 -0800 Message-ID: <1036442448.17309658@r5.dngr.org> Content-Type: text/plain; charset="us-ascii"; format="flowed" Subject: Re: [Speechsc] Updated version (v0.2) for speechsc WG Internet Draft submission protocol evaluation document From: "Stephane H. Maes" Reply-To: "Stephane H. Maes" X-Mailer: Danger Service Date: Mon, 4 Nov 2002 12:38:06 -0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: "Sarvi Shanmugham" , brian.wyld@eloquant.com, "Speechsc (E-mail)" Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sarvi, I will comment in more details later. I believe that different protocol proposals have to be considered differently whne mapped on the requirements. The web service proposal is at a different level than Sip or Beep for example to which it could be bound. Such fuzziness of the boundary may be frustrating; but it is inherent to the nature of SPEECHSC that is also fuzzy between low and more app level (engine APIs). As such, web services have indeed this inherent capability to provide any API, support combination and composition etc and to be essentially bound to any underlying transport. Yes syntax is to be defined; but that remains the only major work that needs to be done ... All this remains within the confines of the web service framework. Can you do the same with SIP or BEEP? Yes; but you need to produce a new release of the spec or carry lots of info with mechaniss designed only for limited extensions. And by the way, of course web service have no sythax to control speech engines. So we could have given failed across the board. But that's not the point of the excercise; at least I hope so... Web services is a framework that can be applied unchanged (+/-) to support speechsc... And yes syntax has to be defined. Honnestky that' comon practice and the work of a few months at the level of a standard working group. With MRCP, I do no know how to position it either. It is a syntax on top of another protocol. As defined it does not meet the requirements. But I understand that the argument that maybe only syntax needs to be defined to satisfy this. So you are rigth to make these updates as MRCP is anyway a draft and can therefore support that. Again the evaluation based on the requirementas is may not yet be enough to decide and pick an approach. Other design points may have to be taken into account to progress. I agree with you that whatever is the point of view taken; it is frustrating when considered from another angle. We will have to decide what would best help progress. Thanks Stephane On Mon, 4 Nov 2002 3:03PM -0500, Sarvi Shanmugham wrote: > some comments/questions on the document. > > Comment 1: > My evaluations of MRCP were for the most part, how the protocol already > met the > requirements. And hence when it came to dealing with issues like > SI/SV, they were > classified as not supported. > > After reading some of the evaluations(such as web services), which > pretty much does not > directly meet most of the requirements. But seems to discuss mostly > about how it can > evolve with the additon of a NEW set of messaging to meet the > requirements. > > If this is indeed to basis of protocol evaluation and considering MRCP > was originally > designed to be extensible for these exact needs. Even preliminary > methods and formats > for these resources were defined but not refined/implemented/tested due > to priorities. > The MRCP protocol evaluation would be (T) in most of the SI/SV > requirements. > > Other comments: > Based on the above, the following sections will change in meeting the > requirments. > In all the following sections, texts already provided, addresses how > MRCP could be > evolved to meet the needs in FULL, if it does' not already meet it in > full. > > 7.2.4. Protocol efficiency [5.4] - would become T > > 7.2.8. Multiple media sessions [5.8] - would become T > > 7.4.3. Grammar Specification [7.3.1] - would become T > > 7.4.4. Explicit Indication of Grammar Format [7.3.2] - should be T > already without any > needed changes. > > 7.4.5. Grammar Sharing [7.3.3] - This again would be T. since the > DEFINE-GRAMMAR method > could be extended to define grammars that cna be shared across > sessions, and URI > mechanism used to identify, define and refer to such grammars. > > 7.5. Analysis of Speaker Identification and Verification Requirements - > This whole > section would then be T, since this can be achieved by additon new > methods to address > these needs, and since MRCP was designed with these future extensions > in mind. > > 7.6.3. Multiple services in parallel [9.1.2] - T if 7.5 is extensions > are added. > > thx, > Sarvi > > > > Brian Wyld wrote: > >> Hi, >> >> Sorry, but attached is an UPDATE to the draft I just submitted to >> take >> account of last minute additions. This draft is v0.2. I have also >> re-created >> the .txt to be in US Letter size format as per most IETF docs.... >> >> I hope this version can be the legitimate Internet Draft for speechsc >> protocol evaluation. Please ignore the previous version. >> >> Thanks >> >> Brian >> >> [Brian Wyld] [brian.wyld@eloquant.com] >> [Directeur General R&D] >> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] >> [advanced solutions for telecoms and IT services] >> >> >> ------------------------------------------------------------------------ >> Name: >> draft-speechsc-protocol-eval-v02.txt >> draft-speechsc-protocol-eval-v02.txt Type: Plain Text >> (text/plain) >> Encoding: quoted-printable ___ Stephane H. Maes, PhD, Director of Architecture, Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-203-798-6948 e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN) _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Nov 4 15:54:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06085 for ; Mon, 4 Nov 2002 15:54:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4KuAr23072 for speechsc-archive@odin.ietf.org; Mon, 4 Nov 2002 15:56:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KuAv23069 for ; Mon, 4 Nov 2002 15:56:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06057 for ; Mon, 4 Nov 2002 15:53:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Ku3v23061; Mon, 4 Nov 2002 15:56:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KtSv23037 for ; Mon, 4 Nov 2002 15:55:28 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06045 for ; Mon, 4 Nov 2002 15:52:55 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA4KtFgM014735; Mon, 4 Nov 2002 12:55:15 -0800 (PST) Received: from cisco.com (dhcp-128-107-139-102.cisco.com [128.107.139.102]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR03425; Mon, 4 Nov 2002 12:50:35 -0800 (PST) Message-ID: <3DC6DEB7.9931CE30@cisco.com> Date: Mon, 04 Nov 2002 12:55:20 -0800 From: Sarvi Shanmugham Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stephane H. Maes" CC: brian.wyld@eloquant.com, "Speechsc (E-mail)" Subject: Re: [Speechsc] Updated version (v0.2) for speechsc WG Internet Draft submission protocol evaluation document References: <1036442448.17309658@r5.dngr.org> Content-Type: multipart/mixed; boundary="------------57243E34E333931866613885" Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------57243E34E333931866613885 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Stephane, I was in no way claiming that your analysis of web services is wrong. But like you mention, since my evaluation of MRCP is based on the notion that the current MRCP spec will be extended in one of the 3 ways proposed, I think the following changes are appropriate. So I was just making these changes to make the evaluation consistent with the Webservices evalution. Sarvi "Stephane H. Maes" wrote: > Sarvi, > > I will comment in more details later. > > I believe that different protocol proposals have to be considered > differently whne mapped on the requirements. > > The web service proposal is at a different level than Sip or Beep for > example to which it could be bound. > > Such fuzziness of the boundary may be frustrating; but it is inherent to > the nature of SPEECHSC that is also fuzzy between low and more app level > (engine APIs). > > As such, web services have indeed this inherent capability to provide > any API, support combination and composition etc and to be essentially > bound to any underlying transport. > > Yes syntax is to be defined; but that remains the only major work that > needs to be done ... > All this remains within the confines of the web service framework. Can > you do the same with SIP or BEEP? Yes; but you need to produce a new > release of the spec or carry lots of info with mechaniss designed only > for limited extensions. > > And by the way, of course web service have no sythax to control speech > engines. So we could have given failed across the board. But that's not > the point of the excercise; at least I hope so... Web services is a > framework that can be applied unchanged (+/-) to support speechsc... And > yes syntax has to be defined. Honnestky that' comon practice and the > work of a few months at the level of a standard working group. > > With MRCP, I do no know how to position it either. It is a syntax on top > of another protocol. As defined it does not meet the requirements. But I > understand that the argument that maybe only syntax needs to be defined > to satisfy this. So you are rigth to make these updates as MRCP is > anyway a draft and can therefore support that. > > Again the evaluation based on the requirementas is may not yet be enough > to decide and pick an approach. Other design points may have to be taken > into account to progress. > > I agree with you that whatever is the point of view taken; it is > frustrating when considered from another angle. We will have to decide > what would best help progress. > > Thanks > > Stephane > > On Mon, 4 Nov 2002 3:03PM -0500, Sarvi Shanmugham wrote: > > some comments/questions on the document. > > > > Comment 1: > > My evaluations of MRCP were for the most part, how the protocol already > > met the > > requirements. And hence when it came to dealing with issues like > > SI/SV, they were > > classified as not supported. > > > > After reading some of the evaluations(such as web services), which > > pretty much does not > > directly meet most of the requirements. But seems to discuss mostly > > about how it can > > evolve with the additon of a NEW set of messaging to meet the > > requirements. > > > > If this is indeed to basis of protocol evaluation and considering MRCP > > was originally > > designed to be extensible for these exact needs. Even preliminary > > methods and formats > > for these resources were defined but not refined/implemented/tested due > > to priorities. > > The MRCP protocol evaluation would be (T) in most of the SI/SV > > requirements. > > > > Other comments: > > Based on the above, the following sections will change in meeting the > > requirments. > > In all the following sections, texts already provided, addresses how > > MRCP could be > > evolved to meet the needs in FULL, if it does' not already meet it in > > full. > > > > 7.2.4. Protocol efficiency [5.4] - would become T > > > > 7.2.8. Multiple media sessions [5.8] - would become T > > > > 7.4.3. Grammar Specification [7.3.1] - would become T > > > > 7.4.4. Explicit Indication of Grammar Format [7.3.2] - should be T > > already without any > > needed changes. > > > > 7.4.5. Grammar Sharing [7.3.3] - This again would be T. since the > > DEFINE-GRAMMAR method > > could be extended to define grammars that cna be shared across > > sessions, and URI > > mechanism used to identify, define and refer to such grammars. > > > > 7.5. Analysis of Speaker Identification and Verification Requirements - > > This whole > > section would then be T, since this can be achieved by additon new > > methods to address > > these needs, and since MRCP was designed with these future extensions > > in mind. > > > > 7.6.3. Multiple services in parallel [9.1.2] - T if 7.5 is extensions > > are added. > > > > thx, > > Sarvi > > > > > > > > Brian Wyld wrote: > > > >> Hi, > >> > >> Sorry, but attached is an UPDATE to the draft I just submitted to > >> take > >> account of last minute additions. This draft is v0.2. I have also > >> re-created > >> the .txt to be in US Letter size format as per most IETF docs.... > >> > >> I hope this version can be the legitimate Internet Draft for speechsc > >> protocol evaluation. Please ignore the previous version. > >> > >> Thanks > >> > >> Brian > >> > >> [Brian Wyld] [brian.wyld@eloquant.com] > >> [Directeur General R&D] > >> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] > >> [advanced solutions for telecoms and IT services] > >> > >> > >> ------------------------------------------------------------------------ > >> Name: > >> draft-speechsc-protocol-eval-v02.txt > >> draft-speechsc-protocol-eval-v02.txt Type: Plain Text > >> (text/plain) > >> Encoding: quoted-printable > > ___ > Stephane H. Maes, PhD, > Director of Architecture, Mobile, Oracle Corporation. > Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-203-798-6948 > e-mail: stephane.maes@oracle.com > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN) --------------57243E34E333931866613885 Content-Type: text/x-vcard; charset=us-ascii; name="sarvi.vcf" Content-Description: Card for Sarvi Shanmugham Content-Disposition: attachment; filename="sarvi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shanmugham;Sarvi tel;work:408-527-4875 x-mozilla-html:TRUE org:Cisco Systems Inc;Voice Technology Group adr:;;;;;; version:2.1 email;internet:sarvi@cisco.com title:Technical Leader fn:Sarvi Shanmugham end:vcard --------------57243E34E333931866613885-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Nov 4 16:00:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06472 for ; Mon, 4 Nov 2002 16:00:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4L2P823419 for speechsc-archive@odin.ietf.org; Mon, 4 Nov 2002 16:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4L2Pv23416 for ; Mon, 4 Nov 2002 16:02:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06416 for ; Mon, 4 Nov 2002 15:59:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4L2Mv23406; Mon, 4 Nov 2002 16:02:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4L1jv23350 for ; Mon, 4 Nov 2002 16:01:45 -0500 Received: from mfe2.prod.danger.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06335 for ; Mon, 4 Nov 2002 15:59:11 -0500 (EST) Received: from [10.12.5.251] (HELO localhost) by mfe2.prod.danger.com (CommuniGate Pro SMTP 4.0b6) with SMTP id 493235; Mon, 04 Nov 2002 13:01:38 -0800 Message-ID: <1036443698.24698DB7@r5.dngr.org> Content-Type: text/plain; charset="us-ascii"; format="flowed" In-Reply-To: <3DC6DEB7.9931CE30@cisco.com> Subject: Re: [Speechsc] Updated version (v0.2) for speechsc WG Internet Draft submission protocol evaluation document From: "Stephane H. Maes" References: <1036442448.17309658@r5.dngr.org> <3DC6DEB7.9931CE30@cisco.com> Reply-To: "Stephane H. Maes" X-Mailer: Danger Service Date: Mon, 4 Nov 2002 13:01:08 -0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: "Sarvi Shanmugham" Cc: brian.wyld@eloquant.com, "Speechsc (E-mail)" Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I did not assume that you were... Don't worry. I think that you pointed out a challenge in using this to make any type of progress. Thanks Stephane On Mon, 4 Nov 2002 3:56PM -0500, Sarvi Shanmugham wrote: > Hi Stephane, > I was in no way claiming that your analysis of web services is > wrong. > > But like you mention, since my evaluation of MRCP is based on the > notion that > the current MRCP spec will be extended in one of the 3 ways proposed, I > think > the following changes are appropriate. > > So I was just making these changes to make the evaluation consistent > with the > Webservices evalution. > > Sarvi > > "Stephane H. Maes" wrote: > >> Sarvi, >> >> I will comment in more details later. >> >> I believe that different protocol proposals have to be considered >> differently whne mapped on the requirements. >> >> The web service proposal is at a different level than Sip or Beep for >> example to which it could be bound. >> >> Such fuzziness of the boundary may be frustrating; but it is inherent >> to >> the nature of SPEECHSC that is also fuzzy between low and more app >> level >> (engine APIs). >> >> As such, web services have indeed this inherent capability to provide >> any API, support combination and composition etc and to be >> essentially >> bound to any underlying transport. >> >> Yes syntax is to be defined; but that remains the only major work >> that >> needs to be done ... >> All this remains within the confines of the web service framework. >> Can >> you do the same with SIP or BEEP? Yes; but you need to produce a new >> release of the spec or carry lots of info with mechaniss designed >> only >> for limited extensions. >> >> And by the way, of course web service have no sythax to control >> speech >> engines. So we could have given failed across the board. But that's >> not >> the point of the excercise; at least I hope so... Web services is a >> framework that can be applied unchanged (+/-) to support speechsc... >> And >> yes syntax has to be defined. Honnestky that' comon practice and the >> work of a few months at the level of a standard working group. >> >> With MRCP, I do no know how to position it either. It is a syntax on >> top >> of another protocol. As defined it does not meet the requirements. >> But I >> understand that the argument that maybe only syntax needs to be >> defined >> to satisfy this. So you are rigth to make these updates as MRCP is >> anyway a draft and can therefore support that. >> >> Again the evaluation based on the requirementas is may not yet be >> enough >> to decide and pick an approach. Other design points may have to be >> taken >> into account to progress. >> >> I agree with you that whatever is the point of view taken; it is >> frustrating when considered from another angle. We will have to >> decide >> what would best help progress. >> >> Thanks >> >> Stephane >> >> On Mon, 4 Nov 2002 3:03PM -0500, Sarvi Shanmugham wrote: >> > some comments/questions on the document. >> > >> > Comment 1: >> > My evaluations of MRCP were for the most part, how the protocol >> already >> > met the >> > requirements. And hence when it came to dealing with issues like >> > SI/SV, they were >> > classified as not supported. >> > >> > After reading some of the evaluations(such as web services), which >> > pretty much does not >> > directly meet most of the requirements. But seems to discuss >> mostly >> > about how it can >> > evolve with the additon of a NEW set of messaging to meet the >> > requirements. >> > >> > If this is indeed to basis of protocol evaluation and considering >> MRCP >> > was originally >> > designed to be extensible for these exact needs. Even preliminary >> > methods and formats >> > for these resources were defined but not refined/implemented/tested >> due >> > to priorities. >> > The MRCP protocol evaluation would be (T) in most of the SI/SV >> > requirements. >> > >> > Other comments: >> > Based on the above, the following sections will change in meeting >> the >> > requirments. >> > In all the following sections, texts already provided, addresses >> how >> > MRCP could be >> > evolved to meet the needs in FULL, if it does' not already meet it >> in >> > full. >> > >> > 7.2.4. Protocol efficiency [5.4] - would become T >> > >> > 7.2.8. Multiple media sessions [5.8] - would become T >> > >> > 7.4.3. Grammar Specification [7.3.1] - would become T >> > >> > 7.4.4. Explicit Indication of Grammar Format [7.3.2] - should be T >> > already without any >> > needed changes. >> > >> > 7.4.5. Grammar Sharing [7.3.3] - This again would be T. since the >> > DEFINE-GRAMMAR method >> > could be extended to define grammars that cna be shared across >> > sessions, and URI >> > mechanism used to identify, define and refer to such grammars. >> > >> > 7.5. Analysis of Speaker Identification and Verification >> Requirements - >> > This whole >> > section would then be T, since this can be achieved by additon new >> > methods to address >> > these needs, and since MRCP was designed with these future >> extensions >> > in mind. >> > >> > 7.6.3. Multiple services in parallel [9.1.2] - T if 7.5 is >> extensions >> > are added. >> > >> > thx, >> > Sarvi >> > >> > >> > >> > Brian Wyld wrote: >> > >> >> Hi, >> >> >> >> Sorry, but attached is an UPDATE to the draft I just submitted to >> >> take >> >> account of last minute additions. This draft is v0.2. I have also >> >> re-created >> >> the .txt to be in US Letter size format as per most IETF docs.... >> >> >> >> I hope this version can be the legitimate Internet Draft for >> speechsc >> >> protocol evaluation. Please ignore the previous version. >> >> >> >> Thanks >> >> >> >> Brian >> >> >> >> [Brian Wyld] [brian.wyld@eloquant.com] >> >> [Directeur General R&D] >> >> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] >> >> [advanced solutions for telecoms and IT services] >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> Name: >> >> draft-speechsc-protocol-eval-v02.txt >> >> draft-speechsc-protocol-eval-v02.txt Type: Plain Text >> >> (text/plain) >> >> Encoding: quoted-printable >> >> ___ >> Stephane H. Maes, PhD, >> Director of Architecture, Mobile, Oracle Corporation. >> Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-203-798-6948 >> e-mail: stephane.maes@oracle.com >> IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN) ___ Stephane H. Maes, PhD, Director of Architecture, Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax: +1-203-798-6948 e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN) _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Nov 5 07:34:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15431 for ; Tue, 5 Nov 2002 07:34:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5CaJb07082 for speechsc-archive@odin.ietf.org; Tue, 5 Nov 2002 07:36:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5CaJv07079 for ; Tue, 5 Nov 2002 07:36:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15399 for ; Tue, 5 Nov 2002 07:33:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5CaAv07064; Tue, 5 Nov 2002 07:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5CZ2v07028 for ; Tue, 5 Nov 2002 07:35:02 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15340 for ; Tue, 5 Nov 2002 07:32:33 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 5 Nov 2002 07:35:00 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D5552@zoe.office.snowshore.com> Thread-Topic: Introducing the ID tracker Thread-Index: AcKEUw+RWE9av4N9STGUHDi6qb3+ygAdCtsQ From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" , "IETF LEMONADE (E-mail)" , "Vpim Mail List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5CZ2v07029 Subject: [Speechsc] FW: Introducing the ID tracker Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Excellent news from Harald! This is an excellent tool; use it if you are wondering where your draft is. -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, November 04, 2002 4:44 PM Subject: Introducing the ID tracker Hello, The IESG is always trying to work better. We have gotten a number of comments from the community that it is sometimes very hard to find out what the IESG is doing to documents, why documents take a long time to process, who makes comments, what the comments are and so on, and that this is a significant source of frustration for the community. For the last year or so, the secretariat has been working on a tool to help us keep track of what documents are on our plate, what state they are in and who is responsible for them; we call it the "ID tracker". It's been in use for about 6 months now, and has definitely improved our ability to keep track. For several months, the "status of items" pages on the IESG web pages have been generated from this tool, showing the high-order bit of who we think is responsible. In order to help you know more about what we are doing, we've decided to open up a public view of the ID tracker itself. This will allow you to search for the documents you want to look at, and for each document see: - What its current state is - What the history of IESG processing is - AD and IESG comments on the document - For documents in IESG consideration for standards track, what the individual ADs have indicated as their opinion on the document, and if they think there are problems with it, what the comments are. The last point is a revision of previous IESG policy, based on the feedback from the Yokohama plenary; we are now telling you the names that go with each comment from the IESG members. The system is far from perfect - you can tell from the history of documents that we've been changing this as we go along - but we hope that it will be a useful tool for people to figure out what the IESG is doing with their documents, and for them to have an easier time talking to the relevant ADs in order to get what we all want out of the process - relevant, high quality standards for the Internet. The tool and its documentation is found at https://datatracker.ietf.org/public/pidtracker.cgi The link to it is also visible on the IESG Web page. Welcome! The IESG _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Nov 6 06:42:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13436 for ; Wed, 6 Nov 2002 06:42:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6BiH505323 for speechsc-archive@odin.ietf.org; Wed, 6 Nov 2002 06:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BiHv05320 for ; Wed, 6 Nov 2002 06:44:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13402 for ; Wed, 6 Nov 2002 06:41:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BiDv05296; Wed, 6 Nov 2002 06:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BYgv04097 for ; Wed, 6 Nov 2002 06:34:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12837; Wed, 6 Nov 2002 06:32:10 -0500 (EST) Message-Id: <200211061132.GAA12837@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: speechsc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Nov 2002 06:32:10 -0500 Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-protocol-eval-01.txt Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Speech Services Control Working Group of the IETF. Title : SPEECHSC Protocol Evaluation Author(s) : B. Wyld Filename : draft-ietf-speechsc-protocol-eval-01.txt Pages : 28 Date : 2002-11-5 This document is the Protocol Evaluation Document for the SPEECHSC Working Group. Section 3 provides the summary of the individual protocol comparisons (in the sections 4-N following) against the SPEECHSC requirements [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-protocol-eval-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speechsc-protocol-eval-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speechsc-protocol-eval-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-protocol-eval-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-protocol-eval-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193620.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Nov 6 10:50:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28172 for ; Wed, 6 Nov 2002 10:50:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6FqMu22884 for speechsc-archive@odin.ietf.org; Wed, 6 Nov 2002 10:52:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FqMv22881 for ; Wed, 6 Nov 2002 10:52:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28148 for ; Wed, 6 Nov 2002 10:49:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Fq9v22865; Wed, 6 Nov 2002 10:52:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FpGv22837 for ; Wed, 6 Nov 2002 10:51:16 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28073; Wed, 6 Nov 2002 10:48:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 6 Nov 2002 10:51:11 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097B30@zoe.office.snowshore.com> Thread-Topic: Draft Agenda for speechsc Thread-Index: AcKFoWP+Tu30HN79SI+o5aQsHo+mLAACU+WH From: "Eric Burger" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gA6FpGv22838 Subject: [Speechsc] speechsc Agenda Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Charter: http://www.ietf.org/html.charters/speechsc-charter.html List Archive: http://www1.ietf.org/mail-archive/working-groups/speechsc/current/maillist.html Supplemental page: http://flyingfox.snowshore.com/i-d THURSDAY, November 21, 2002 1530-1730 Afternoon Sessions II Consulate TSV speechsc Speech Services Control WG 3:30 5 min Agenda Bashing 3:35 10 min Requirements Document Status (chairs) 3:45 50 min Protocol Analysis Document Open Issues Beep (Jerry Carter) SIP (Rajiv Dharmadhikari) RTSP (Brian Wyld) [won't be in Atlanta] MRCP (Sarvi Shanmugham) Web Services (Stephane Maes) 4:35 30 min Next Steps, Design Team Fomation 5:05 25 min The Internet Standards Process and speechsc You are expected to have read the following late night reading material: Requirements Document: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-02.txt Protocol Evaluation Document: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-protocol-eval-01.txt Internet Standards Process: Instructions to RFC Authors: http://www.ietf.org/rfc/rfc2223.txt?number=2223 New Instructions to RFC Authors (draft): http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-03.txt The Internet Standards Process -- Revision 3: http://www.ietf.org/rfc/rfc2026.txt?number=2026 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Nov 7 15:46:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11507 for ; Thu, 7 Nov 2002 15:46:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7KmMJ18134 for speechsc-archive@odin.ietf.org; Thu, 7 Nov 2002 15:48:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KmMv18131 for ; Thu, 7 Nov 2002 15:48:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11489 for ; Thu, 7 Nov 2002 15:45:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KmEv18104; Thu, 7 Nov 2002 15:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KZ4v15519 for ; Thu, 7 Nov 2002 15:35:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [Speechsc] Note Well Statement Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Nov 18 15:40:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02747 for ; Mon, 18 Nov 2002 15:40:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIKguj17593 for speechsc-archive@odin.ietf.org; Mon, 18 Nov 2002 15:42:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKguv17590 for ; Mon, 18 Nov 2002 15:42:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02721 for ; Mon, 18 Nov 2002 15:40:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKgnv17581; Mon, 18 Nov 2002 15:42:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKbgv17360 for ; Mon, 18 Nov 2002 15:37:42 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02647 for ; Mon, 18 Nov 2002 15:34:59 -0500 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 18 Nov 2002 15:37:36 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D55E9@zoe.office.snowshore.com> Thread-Topic: Homework due Thursday thread-index: AcKPFzRT6kBkaxV4RGuNuKN6lYCy6A== From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAIKbgv17361 Subject: [Speechsc] Homework due Thursday Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit This is a reminder for people new to the IETF. Please disregard if this is not new to you. Presentations at the Work Group meeting revolve around open issues. We have only a limited amount of time. This means that we cannot have presentations of a tutorial nature (e.g., "this is what my draft is about" or "here are the features of protocol X"). Rather, the presentations address open issues (e.g., "this point had dissent on the list, here is why the draft is right / wrong"). Please be prepared for the meeting. Review the drafts: Requirements Document: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-02.txt Protocol Evaluation Document: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-protocol-eval-01.txt Also, it may be beneficial to review the discussion on the list: http://www1.ietf.org/mail-archive/working-groups/speechsc/current/maillist.html If you read and understand the following documents, you can leave the work group meeting early. However, if you are an "old hand", we would encourage you to stick around and give the new folks guidance. New Instructions to RFC Authors (draft): http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-03.txt The Internet Standards Process -- Revision 3: http://www.ietf.org/rfc/rfc2026.txt?number=2026 _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Nov 18 16:26:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02748 for ; Mon, 18 Nov 2002 15:40:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIKgug17608 for speechsc-archive@odin.ietf.org; Mon, 18 Nov 2002 15:42:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKguv17597 for ; Mon, 18 Nov 2002 15:42:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02723 for ; Mon, 18 Nov 2002 15:40:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKgjv17565; Mon, 18 Nov 2002 15:42:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKbfv17354 for ; Mon, 18 Nov 2002 15:37:41 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02645 for ; Mon, 18 Nov 2002 15:34:58 -0500 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 18 Nov 2002 15:37:35 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D55E7@zoe.office.snowshore.com> Thread-Topic: Scribe and Transcriber Call for Participation thread-index: AcKPFA4u8WueWqjtTWi71mtQUb+Z3A== From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAIKbfv17355 Subject: [Speechsc] Scribe and Transcriber Call for Participation Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit We need two volunteers for our meeting on Thursday. The first is a scribe. We would be happy to have two or three volunteers. We can split the load so you don't have to take notes for the entire meeting. The agenda is on line at http://www.ietf.org/ietf/02nov/speechsc.txt . If you are presenting open issues, you are probably NOT a candidate for being scribe. The second is a transcriber. All IETF WG sessions have a parallel Jabber (IRC) session. We need someone to write out what is going on in the session, as well as take questions from the Internet audience. You will need 802.11 access from your computer for this job. Again, we can take more than one person for this job. If you are presenting open issues, you are not a candidate for being transcriber. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Nov 19 04:48:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00307 for ; Tue, 19 Nov 2002 04:48:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ9oSh05281 for speechsc-archive@odin.ietf.org; Tue, 19 Nov 2002 04:50:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJ9oSv05278 for ; Tue, 19 Nov 2002 04:50:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00300 for ; Tue, 19 Nov 2002 04:47:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJ9oGv05261; Tue, 19 Nov 2002 04:50:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJ9nEv05189 for ; Tue, 19 Nov 2002 04:49:14 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00265 for ; Tue, 19 Nov 2002 04:46:24 -0500 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 19 Nov 2002 04:49:02 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D09751E@zoe.office.snowshore.com> Thread-Topic: text conferencing at the 55th IETF meeting in Atlanta thread-index: AcKPDa1H3P9lrRA4SEuvBXfm/CDLZAAlbrOw From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAJ9nEv05190 Subject: [Speechsc] FW: text conferencing at the 55th IETF meeting in Atlanta Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit For the remote, Internet audience, we have two choices for a live text feed of the proceedings. The first is Jabber and the second is SIP. Note the SIP implementation is an Alpha version. I have no idea if it works. If either tool is broken, contact jabber.com or iptel.org, respectively. We will not have MBONE access or an audio conference bridge. For Jabber, the conference room is "speechsc" at conference.ietf.jabber.com . The recording is at http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/speechsc/ . For SIP, check out http://www.iptel.org/ietf55/ . Our conference is speechsc. As a reminder, out meeting is in the Consulate room from 3:30pm - 5:30pm ET on Thursday November 21. -----Original Message----- From: Marshall Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] Sent: Monday, November 18, 2002 9:11 AM To: ietf@ietf.org Subject: text conferencing at the 55th IETF meeting in Atlanta Remote Access for the 55th IETF meeting in Atlanta: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms are hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ Enjoy! /mtr -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Monday, November 18, 2002 10:33 AM To: Marshall Rose; ietf@ietf.org Cc: serhelp@iptel.org Subject: Re: text conferencing at the 55th IETF meeting in Atlanta For those, who would like to use SIP for text conferencing, experimental operation of a SIP2Jabber gateway has been set up at iptel.org. See http://www.iptel.org/ietf55/ for guidelines how to join the IETF chat rooms. Better set your expectations low -- the gateway has not been tested with bigger user populations until now. -Jiri _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Nov 21 14:39:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17129 for ; Thu, 21 Nov 2002 14:39:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALJfLA09874 for speechsc-archive@odin.ietf.org; Thu, 21 Nov 2002 14:41:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALJfLv09871 for ; Thu, 21 Nov 2002 14:41:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17085 for ; Thu, 21 Nov 2002 14:38:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALJfCv09818; Thu, 21 Nov 2002 14:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALJYBv08896 for ; Thu, 21 Nov 2002 14:34:11 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16838 for ; Thu, 21 Nov 2002 14:31:26 -0500 (EST) Date: Thu, 21 Nov 2002 14:33:08 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D5660@zoe.office.snowshore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Slides for Today's Work Group Meeting Thread-Index: AcKRlL3iR8IR8nncSCGZIKK0Xg0jyA== X-Priority: 1 content-class: urn:content-classes:message Priority: Urgent X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Importance: high From: "Eric Burger" To: "IETF SPEECHSC (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gALJYBv08897 Subject: [Speechsc] Slides for Today's Work Group Meeting Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Posted to http://flyingfox.snowshore.com/i-d/speechsc/ Sorry, we only have PowerPoint right now. PostScript will come after the meeting. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Nov 21 14:51:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17758 for ; Thu, 21 Nov 2002 14:51:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALJsAM10602 for speechsc-archive@odin.ietf.org; Thu, 21 Nov 2002 14:54:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALJsAv10599 for ; Thu, 21 Nov 2002 14:54:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17731 for ; Thu, 21 Nov 2002 14:51:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALJs1v10564; Thu, 21 Nov 2002 14:54:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALJrGv10531 for ; Thu, 21 Nov 2002 14:53:16 -0500 Received: from crufty.research.bell-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17684 for ; Thu, 21 Nov 2002 14:50:32 -0500 (EST) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id gALJr9LI086591; Thu, 21 Nov 2002 14:53:09 -0500 (EST) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id gALJr2I12426; Thu, 21 Nov 2002 14:53:03 -0500 (EST) Received: from research.bell-labs.com ([135.104.20.80]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id OAA728063; Thu, 21 Nov 2002 14:53:02 -0500 (EST) Message-ID: <3DDD397F.4AEAF0D3@research.bell-labs.com> Date: Thu, 21 Nov 2002 14:52:31 -0500 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Eric Burger CC: "IETF SPEECHSC (E-mail)" Subject: Re: [Speechsc] Slides for Today's Work Group Meeting References: <4A3384433CE2AB46A63468CB207E209D5660@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The following slides are empty: Chairs Slides MRCP Analysis Slides Web Services Analysis Slides Internet Draft Tutorial, or I-D 101 -- Qiru Eric Burger wrote: > > Posted to http://flyingfox.snowshore.com/i-d/speechsc/ > > Sorry, we only have PowerPoint right now. PostScript will come after the meeting. > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Nov 22 14:06:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01525 for ; Fri, 22 Nov 2002 14:06:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAMJ8nG03174 for speechsc-archive@odin.ietf.org; Fri, 22 Nov 2002 14:08:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJ8mv03171 for ; Fri, 22 Nov 2002 14:08:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01500 for ; Fri, 22 Nov 2002 14:06:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJ8Ev03134; Fri, 22 Nov 2002 14:08:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJ7Iv03046 for ; Fri, 22 Nov 2002 14:07:18 -0500 Received: from e5.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01480 for ; Fri, 22 Nov 2002 14:04:32 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAMJ7D4s067254 for ; Fri, 22 Nov 2002 14:07:13 -0500 Received: from d27ml601.rchland.ibm.com (d27ml601.rchland.ibm.com [9.10.226.13]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAMJ7BEt113644 for ; Fri, 22 Nov 2002 14:07:11 -0500 From: Edward Epstein To: speechsc@ietf.org Message-ID: Date: Fri, 22 Nov 2002 13:07:10 -0600 X-MIMETrack: Serialize by Router on d27ml601/27/M/IBM(Release 6.0|September 26, 2002) at 11/22/2002 13:07:12 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Speechsc] Edward Epstein/Watson/IBM is out of the office. Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , I will be out of the office starting November 22, 2002 and will not return until December 2, 2002. I will respond to your message when I return. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sun Nov 24 15:10:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01647 for ; Sun, 24 Nov 2002 15:10:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAOKCXj10827 for speechsc-archive@odin.ietf.org; Sun, 24 Nov 2002 15:12:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOKCXv10824 for ; Sun, 24 Nov 2002 15:12:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01630 for ; Sun, 24 Nov 2002 15:09:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOKCPv10814; Sun, 24 Nov 2002 15:12:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAOKBIv10797 for ; Sun, 24 Nov 2002 15:11:18 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01626 for ; Sun, 24 Nov 2002 15:08:30 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 24 Nov 2002 20:10:51 UT Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Sun, 24 Nov 2002 20:11:13 +0000 From: "Neil Deason" To: Date: Sun, 24 Nov 2002 12:11:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 24 Nov 2002 20:11:14.0450 (UTC) FILETIME=[A3D1C720:01C293F5] Content-Transfer-Encoding: 7bit Subject: [Speechsc] SPEECHSC & usage of SIP Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi. I would like to offer a perspective on the use of SIP within the problem space being studied by the group. SIP is a protocol for initiating, modifying and terminating sessions. SIP is therefore not best suited as a general transport protocol for other protocols or a media resource control protocol. With that said the most appropriate use for SIP in this context would appear to be to set up the control session, which then runs the TBD SPEECHSC protocol. This has some attractive properties - it provides a natural association between the audio and control sessions and SIP is likely to be widely deployed in the networks where the SPEECHSC protocol is needed. At the WG meeting I mentioned a now expired Internet Draft which provided an example of a similar usage of SIP to set up SOAP sessions. This is not intended to say SOAP must be the SPEECHSC protocol. Though the thought of MRCP encoded in SOAP and set up through SIP might have some appeal here ;) Some important points to note about this draft - it has expired and is out of date. In particular the SIMPLE WG appears to have moved towards CPIM/TCP in preference to IMTP for message based sessions where SIP is concerned. Therefore the idea in this draft for using IMTP as the transport for SOAP messaging needs revision. However, the example usage part of how an audio/RTP session can be set up along side a control channel through SIP/SDP is still valid. http://www.ietf.org/internet-drafts/draft-deason-sipping-soap-sessions-0 0.txt hth, Neil. -- Neil Deason 3 Lagoon Drive ndeason@ubiquity.net Suite 345 Director of Technology Redwood City Ubiquity Software Corporation CA 94065 http://www.ubiquity.net USA _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc