From mailnull@www1.ietf.org Sun Oct 6 13:27:46 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 NAA20719 for ; Sun, 6 Oct 2002 13:27:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g96HTMS25743 for speechsc-archive@odin.ietf.org; Sun, 6 Oct 2002 13:29:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g96HTLv25740 for ; Sun, 6 Oct 2002 13:29:21 -0400 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 NAA20708 for ; Sun, 6 Oct 2002 13:27:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g96HTEv25732; Sun, 6 Oct 2002 13:29:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g96HSPv25718 for ; Sun, 6 Oct 2002 13:28:25 -0400 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 NAA20702 for ; Sun, 6 Oct 2002 13:26:16 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g96HSAaW014705 for ; Sun, 6 Oct 2002 10:28:11 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG11837; Sun, 6 Oct 2002 10:28:37 -0700 (PDT) Date: Sun, 06 Oct 2002 13:29:03 -0400 From: "David R. Oran" To: speechsc@ietf.org Message-ID: <883290494.1033910943@ORANLT.cisco.com> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========883300618==========" Subject: [Speechsc] Proposed resolutions for WGLC comments on diraft-ietf-speechsc-reqts-00.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: , --==========883300618========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Thanks to all who submitted comments on this draft during WGLC, and to the ensuing discussions, which were useful and productive. I apologize for the delay in getting this message out. I have no excuse beyond the usual "too much work". After reviewing all the comments and discussion, I believe we will have WG consensus on the requirements with some minor adjustments to the document. These are reflected in draft-ietf-speechsc-reqts-01, which I have submitted to the archive and should appear within a day or two. Below please find my proposed resolution to each of the issues raised during last call (also in the change log of the revised document). >From a process point of view, I believe we should do a "mini" repeat of WGLC since there are some changes. Therefore, please post any OBJECTIONS you have to the revised requirements document to the list by Friday, October 11. If there are no objections, I will ask the ADs to have the IESG consider the document for publication as an Informational RFC. Given the short time, I am violating the usual email etiquette and am attaching the full document because I don't have a convenient place to put up a temporary copy for fetching. It isn't inordinately large, and I apologize in advance. Thanks again to all of you who worked on helping to write, review, and discuss the requirements. Dave. Changes to draft-ietf-speechsc-reqts-00.txt based on WGLC comments: - Adopted Rajiv D.'s wording clarification to the TTS & ASR requirements to allow control to come from either a separate Application Server, or a combined server with a Media Processing entity. - Reorganized references into separate normative and informative sections as requested by Scott Bradner - Added numbering for requirements in sections that were not previously numbered. This necessitated a bit of text shuffling to group related requirements more closely together. - Added a paragraph to the introduction to emphasize the wide variety of applications of the speechsc framework and explicitly call out wireless mobile devices, IP phones, and PSTN VoIP gateways. - During WGLC, the use of the term "speaker recognition" to cover both speaker identification and speaker verification was questioned. In addition some WG participants felt that there should be separate requirements for each, while others argued that the differences, while affecting the structure of the application, did not affect the requirements for the protocol in any substantive way. There were views that the existing terminology was common in the industry and hence should not be changed, and sentiments for a variety of other solutions. The best compromise seemed to be to continue to group the requirements together, but point out where there may be subtle differences affecting applications. It also seemed prudent to keep the identification/verification distinction in the terminology, and hence the document uses the acronym SI/SV rather than SR when talking about both together. - added a requirement in section 5 for 1:N mapping of control to media channels, but pointed out that if SDP is used this comes for free. - Changed the input capture requirement from SHOULD to MUST, but made implementation by the server a SHOULD. - added a SHOULD requirement for protocol efficiency with re-use of transport connections as one of a set of examples. - noted in section 10 that while RTP is assumed, the framework applies to other media carriage schemes that can be described by SDP, as long as they have the right features. --==========883300618========== Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-speechsc-reqts-01.txt" Content-Disposition: attachment; filename="draft-ietf-speechsc-reqts-01.txt"; size=32568 Content-Transfer-Encoding: quoted-printable Network Working Group E. Burger=20 Internet Draft SnowShore Networks, Inc.=20 Document: draft-ietf-speechsc-reqts-01.txt D. Oran=20 Category: Informational Cisco Systems, Inc.=20 Expires April 2003 October 8, 2002=20 =20 =20 Requirements for Distributed Control of ASR, SI/SV and TTS Resources=20 =20 =20 Status of this Memo=20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =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. Internet-Drafts are draft documents valid for a maximum of=20 six 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 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 =20 1.=20 Abstract=20 =20 This document outlines the needs and requirements for a protocol to=20 control distributed speech processing of audio streams. By speech=20 processing, this document specifically means automatic speech=20 recognition, speaker recognition (which includes both speaker=20 identification and speaker verification) and text-to-speech. Other=20 IETF protocols, such as SIP and RTSP, address rendezvous and control=20 for generalized media streams. However, speech processing presents=20 additional requirements that none of the extant IETF protocols=20 address.=20 Discussion of this and related documents is on the speechsc mailing=20 list. To subscribe, send the message "subscribe speechsc" to=20 speechsc-request@ietf.org. The public archive is at=20 http://www.ietf.org/mail- archive/workinggroups/speechsc/current/maillist.html.=20 =20 =20 2.=20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2].=20 FORMATTING NOTE: Notes, such at this one, provide additional,=20 nonessential information that the reader may skip without missing=20 anything essential. The primary purpose of these non-essential=20 notes is to convey information about the rationale of this document,=20 =20 Burger & Oran Informational =3F Expires August 2002 1 =0C Distributed Media Control Requirements February 2002=20 =20 =20 or to place this document in the proper historical or evolutionary=20 context. Readers whose sole purpose is to construct a conformant=20 implementation may skip such information. However, it may be of use=20 to those who wish to understand why we made certain design choices.=20 OPEN ISSUES: This document highlights questions that are, as yet,=20 undecided as "OPEN ISSUES".=20 =20 3.=20 Introduction=20 =20 There are multiple IETF protocols for establishment and termination=20 of media sessions (SIP[5]), low-level media control (MGCP[6] and=20 MEGACO[7]), and media record and playback (RTSP[8]). This document=20 focuses on requirements for one or more protocols to support the=20 control of network elements that perform Automated Speech=20 Recognition (ASR), speaker identification or verification (SI/SV),=20 and rendering text into audio, a.k.a. Text-to-Speech (TTS). Many=20 multimedia applications can benefit from having automatic speech=20 recognition (ASR) and text-to-speech (TTS) processing available as a=20 distributed, network resource. This requirements document limits=20 its focus on the distributed control of ASR, SI/SV and TTS servers.=20 =20 There are a broad range of systems which can benefit from a unified=20 approach to control of TTS, ASR, and SI/SV. These include=20 environments such as VoIP gateways to the PSTN, IP Telephones, and=20 wireless mobile devices who obtain speech services via servers on=20 the network. =20 =20 To date, there are a number of proprietary ASR and TTS API's, as=20 well as two IETF drafts that address this problem [9] [10]. =20 However, there are serious deficiencies to the existing drafts. In=20 particular, they mix the semantics of existing protocols yet are=20 close enough to other protocols as to be confusing to the=20 implementer. =20 =20 This document sets forth requirements for protocols to support=20 distributed speech processing of audio streams. For simplicity, and=20 to remove confusion with existing protocol proposals, this document=20 presents the requirements as being for a "new protocol" that=20 addresses the distributed control of speech resources It refers to=20 such a protocol as "SPEECHSC", for Speech Services Control Protocol.=20 =20 Burger & Oran Informational =3F Expires August 2002 2 =0C Distributed Media Control Requirements February 2002=20 =20 =20 =20 4.=20 SPEECHSC Framework=20 =20 The following is the SPEECHSC framework for speech processing.=20 =20 +-------------+ =20 | Application | =20 | Server |\ =20 +-------------+ \ SPEECHSC=20 SIP or whatever / \=20 / \=20 +------------+ / \ +--------+ =20 | Media |/ SPEECHSC \---| ASR | =20 | Processing |-------------------------| and/or | =20 RTP | Entity | RTP | TTS | =20 =3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= | Server | =20 +------------+ +--------+ =20 =20 =20 The "Media Processing Entity" is a network element that processes=20 media. The "Application Server" is a network element that instructs=20 the Media Processing Entity on what transformations to make to the=20 media stream. The "ASR and/or TTS Server" is a network element that=20 either generates a RTP stream based on text input (TTS) or returns=20 speech recognition results in response to an RTP stream as input=20 (ASR). Either the Media Processing Entity or the Application Server=20 may control the ASR or TTS Server using SPEECHSC as a control=20 protocol.=20 =20 Physical embodiments of the entities can reside in one physical=20 instance per entity, or some combination of entities. For example,=20 a VoiceXML [11] Gateway may combine the ASR and TTS functions on the=20 same platform as the Media Processing Entity. Note that VoiceXML=20 Gateways themselves are outside the scope of this protocol.=20 Likewise, one can combine the Application Server and Media=20 Processing Entity, as would be the case in an interactive voice=20 response (IVR) platform.=20 =20 One can also decompose the Media Processing Entity into an entity=20 that controls media endpoints and entities that process media=20 directly. Such would be the case with a decomposed gateway using=20 MGCP or megaco. However, this decomposition is again orthogonal to=20 the scope of SPEECHSC.=20 =20 5.=20 General Requirements=20 =20 5.1.=20 Reuse Existing Protocols=20 =20 To the extent feasible, the SPEECHSC framework SHOULD use existing=20 protocols. =20 =20 5.2.=20 Maintain Existing Protocol Integrity=20 =20 =20 Burger & Oran Informational =3F Expires August 2002 3 =0C Distributed Media Control Requirements February 2002=20 =20 =20 In meeting requirement 5.1, the SPEECHSC framework MUST NOT redefine=20 the semantics of an existing protocol. Said differently, we will not=20 break existing protocols or cause backward compatibility problems.=20 =20 5.3.=20 Avoid Duplicating Existing Protocols=20 =20 To the extent feasible, SPEECHSC SHOULD NOT duplicate the=20 functionality of existing protocols. For example, SIP with msuri=20 [12] and RTSP already define how to request playback of audio. =20 The focus of SPEECHSC is new functionality not addressed by existing=20 protocols or extending existing protocols within the strictures of=20 requirement 5.2. Where an existing protocol can be gracefully=20 extended to support SPEECHSC requirements, such extensions are=20 acceptable alternatives for meeting the requirements.=20 =20 5.4.=20 Protocol efficiency=20 =20 The SPEECHSC framework SHOULD employ protocol elements known to=20 result in efficient operation. Techniques to be considered include:=20 - Re-use of transport connections across sessions=20 - Piggybacking of responses on requests in the reverse=20 direction=20 - Caching of state across requests=20 =20 5.5.=20 Explicit invocation of services=20 =20 The SPEECHSC framework MUST be compliant with the IAB OPES[5]=20 framework. The applicability of the SPEECHSC protocol will therefore=20 be specified as occurring between clients and servers at least one=20 of which is operating directly on behalf of the user requesting the=20 service.=20 =20 5.6.=20 Server Location and Load Balancing=20 =20 To the extent feasible, the SPEECHSC framework SHOULD exploit=20 existing schemes for performing service location and load balancing,=20 such as the Service Location Protocol[13] or DNS SRV records[14].=20 Where such facilities are not deemed adequate, the SPEECHSC=20 framework MAY define additional load balancing techniques.=20 =20 5.7.=20 Simultaneous services=20 =20 The SPEECHSC framework MUST permit multiple services to operate on a=20 single media stream so that either the same or different servers may=20 be performing speech recognition, speaker identification or=20 verification, etc. in parallel.=20 =20 5.8.=20 Multiple media sessions =20 =20 The SPEECHSC framework MUST allow a 1:N mapping between session and=20 RTP channels. For example, a single session may include an outbound=20 RTP channel for TTS, an inbound for ASR and a different inbound for=20 SI/SV (e.g. if processed by different elements on the Media Resource=20 =20 Burger & Oran Informational =3F Expires August 2002 4 =0C Distributed Media Control Requirements February 2002=20 =20 =20 Element). Note: All of these can be described via SDP, so if SDP is=20 utilized for media channel description, this requirement is met =3Ffor=20 free=3F.=20 =20 6.=20 TTS Requirements=20 =20 6.1.=20 Requesting Text Playback=20 =20 The SPEECHSC framework MUST allow a Media Processing Entity or=20 Application Server, using a control protocol, to request the TTS=20 Server to playback text as voice in an RTP stream.=20 =20 6.2.=20 Text Formats=20 =20 6.2.1.=20 Plain Text=20 =20 The TTS Server MUST support the reading of plain text. For reading=20 plain text, the language and voicing MAY be indicated via session=20 parameters. For finer control over such properties, use of SSML=20 rather than plain text provides the necessary capabilities.=20 =20 6.2.2.=20 SSML=20 =20 The TTS Server SHOULD support the reading of SSML [3] text.=20 =20 6.2.3.=20 Text in Control Channel=20 =20 The TTS Server MUST accept text over the SPEECHSC connection for=20 reading over the RTP connection. The server MUST accept text either=20 =3Fby value=3F (embedded in the protocol), or =3Fby reference=3F (by de- referencing a URI embedded in the protocol).=20 =20 6.2.4.=20 Document Type Indication=20 =20 The SPEECHSC framework MUST be capable of explicitly indicating the=20 document type of the text to be processed, as opposed to forcing the=20 server to infer the content by other means.=20 =20 6.3.=20 Control Channel=20 =20 The SPEECHSC framework MUST be capable of establishing the control=20 channel between the client and server on a per-session basis, where=20 a session is loosely defined to be associated with a single =3Fcall=3F=20 or =3Fdialog=3F. The protocol SHOULD be capable of maintaining a long- lived control channel for multiple sessions serially, and MAY be=20 capable of shorter time horizons as well, including as short as for=20 the processing of a single utterance.=20 =20 6.4.=20 Playback Controls=20 =20 The TTS Server SHOULD support, and the SPEECHSC framework MUST=20 support the specification of, "VCR Controls":=20 =20 Burger & Oran Informational =3F Expires August 2002 5 =0C Distributed Media Control Requirements February 2002=20 =20 =20 - The ability to jump in time to the location of a specific=20 marker.=20 - The ability to jump in time, forwards or backwards, by a=20 specified amount of time. Valid time units MUST include=20 seconds, words, paragraphs, sentences, and markers.=20 - The ability to increase and decrease playout speed.=20 - The ability to fast-forward and fast-rewind the audio, where=20 snippets of audio are played as the server moves forwards or=20 backwards in time.=20 - The ability to pause and resume playout.=20 - The ability to increase and decrease playout volume.=20 =20 6.5.=20 Session Parameters=20 =20 The SPEECHSC framework must support the specification of session=20 parameters, such as language, prosody and voicing.=20 =20 6.6.=20 Speech Markers=20 =20 The SPEECHSC framework MUST accommodate speech markers, with=20 capability at least as flexible as that provided in SSML[3]. The=20 framework MUST further provide an efficient mechanism for reporting=20 that a marker has been reached during playout.=20 =20 7.=20 ASR Requirements=20 =20 7.1.=20 Requesting Automatic Speech Recognition=20 =20 The SPEECHSC framework MUST allow a Media Processing Entity or=20 Application Server to request the ASR Server to perform automatic=20 speech recognition on an RTP stream, returning the results over=20 SPEECHSC.=20 =20 7.2.=20 XML=20 =20 The ASR Server MUST support the XML specification for speech=20 recognition [4].=20 =20 7.3.=20 Grammar Requirements=20 =20 7.3.1.=20 Grammar Specification=20 =20 The ASR Server MUST accept grammar specifications either =3Fby value=3F=20 (embedded in the protocol), or =3Fby reference=3F (by de-referencing a=20 URI embedded in the protocol). The latter MUST allow the indication=20 of a grammar already known to, or otherwise =3Fbuilt in=3F to the=20 server. Servers SHOULD be able to store and later retrieve by=20 reference large grammars which were originally supplied by the=20 client.=20 =20 7.3.2.=20 Explicit Indication of Grammar Format=20 =20 =20 Burger & Oran Informational =3F Expires August 2002 6 =0C Distributed Media Control Requirements February 2002=20 =20 =20 The SPEECHSC framework protocol MUST be able to explicitly convey=20 the grammar format in which the grammar is encoded and MUST be=20 extensible to allow for conveying new grammar formats as they are=20 defined. =20 =20 7.3.3.=20 Grammar Sharing=20 =20 The ASR Server SHOULD support sharing grammars across sessions. =20 This supports applications with large grammars for which it is=20 unrealistic to dynamically load. An example is a city-country=20 grammar for a weather service.=20 =20 7.4.=20 Session Parameters=20 =20 The SPEECHSC framework MUST accommodate at a minimum all of the=20 protocol parameters currently defined in MRCP[7]. In addition there=20 SHOULD be a capability to reset parameters within a session.=20 =20 7.5.=20 Input Capture=20 =20 The SPEECHSC framework MUST support a method directing the ASR=20 Server to capture the input media stream for later analysis and=20 tuning of the ASR engine. The ASR Server SHOULD support this=20 capability.=20 =20 8.=20 Speaker Identification and Verification Requirements=20 =20 8.1.=20 Requesting SI/SV=20 =20 The SPEECHSC framework MUST allow a Media Processing Entity to=20 request the SI/SV Server to perform speaker identification or=20 verification on an RTP stream, returning the results over SPEECHSC.=20 =20 8.2.=20 Identifiers for SI/SV=20 =20 The SPEECHSC framework MUST accommodate an identifier for each=20 verification resource and permit control of that resource by ID,=20 because voiceprint format and contents are vendor specific.=20 =20 8.3.=20 State for multiple utterances=20 =20 The SPEECHSC framework MUST work with SI/SV servers which maintain=20 state to handle multi-utterance verification.=20 =20 8.4.=20 Input Capture=20 =20 The SPEECHSC framework, and SI/SV Server MUST support a method for=20 capturing the input media stream for later analysis and tuning of=20 the SI/SV engine. The ASR Server SHOULD support this capability.=20 =20 =20 Burger & Oran Informational =3F Expires August 2002 7 =0C Distributed Media Control Requirements February 2002=20 =20 =20 8.5.=20 SI/SV functional extensibility=20 =20 The SPEECHSC framework SHOULD be extensible to additional functions=20 associated with SI/SV, such as prompting, utterance verification,=20 and retraining.=20 =20 9.=20 Duplexing and Parallel Operation Requirements=20 =20 One very important requirement for an interactive speech-driven=20 system is that user perception of the quality of the interaction=20 depends strongly on the ability of the user to interrupt a prompt or=20 rendered TTS with speech. Interrupting, or barging, the speech=20 output requires more than energy detection from the user's=20 direction. Many advanced systems halt the media towards the user by=20 employing the ASR engine to decide if an utterance is likely to be=20 real speech, as opposed to a cough, for example.=20 =20 9.1.1.=20 Full Duplex operation=20 =20 To achieve low latency between utterance detection and halting of=20 playback, many implementations combine the speaking and ASR=20 functions. The SPEECHSC framework MUST support such full-duplex=20 implementations. =20 =20 9.1.2.=20 Multiple services in parallel=20 =20 Good spoken user interfaces typically depend upon the ease with=20 which the user can accomplish his or her task. When making use of=20 Speaker Identification or Verification technologies, user interface=20 improvements often come from the combination of the different=20 technologies: simultaneous identity claim and verification (on the=20 same utterance), simultaneous knowledge and voice verification=20 (using ASR and verification simultaneously). Using ASR and=20 verification on the same utterance is in fact the only way to=20 support rolling or dynamically-generated challenge phrases (e.g.,=20 "say 51723"). The SPEECHSC framework MUST support such parallel=20 service implementations.=20 =20 10.=20 Additional Considerations (non-normative)=20 =20 The framework assumes that SDP will be used to describe media=20 sessions and streams. The framework further assumes RTP carriage of=20 media, however since SDP can be used to describe other media=20 transport schemes (e.g. ATM) these could be used if they provide the=20 necessary elements (e.g. explicit timestamps). =20 =20 The working group will not be defining distributed speech=20 recognition methods (DSR), as exemplified by the ETSI Aurora=20 project. The working group will not be recreating functionality=20 available in other protocols, such as SIP or SDP. =20 =20 TTS looks very much like playing back a file. Extending RTSP looks=20 promising for when one requires VCR controls or markers in the text=20 =20 Burger & Oran Informational =3F Expires August 2002 8 =0C Distributed Media Control Requirements February 2002=20 =20 =20 to be spoken. When one does not require VCR controls, SIP in a=20 framework such as Network Announcements [10] works directly without=20 modification.=20 =20 ASR has an entirely different set of characteristics. For barge-in=20 support, ASR requires real-time return of intermediate results. =20 Barring the discovery of a good reuse model for an existing=20 protocol, this will most likely become the focus of SPEECHSC. =20 =20 =20 11.=20 Security Considerations=20 =20 Protocols relating to speech processing must take security into=20 account. This is particularly important as popular uses for TTS=20 include reading financial information. Likewise, popular uses for=20 ASR include executing financial transactions and shopping.=20 =20 We envision that rather than providing application-specific security=20 mechanisms in SPEECHSC itself, the resulting protocol will employ=20 security machinery of either containing protocols or the transport=20 on which it runs. For example, we will consider solutions such as=20 using TLS for securing the control channel, and SRTP for securing=20 the media channel. Third-part dependencies necessitating transitive=20 trust will be minimized or explicitly dealt with through the=20 authentication and authorization aspects of the protocol design.=20 =20 In addition to the security machinery needed by the protocol itself,=20 there are considerations for the implementation and deployment of=20 the clients and servers themselves. For example, speaker verifica- tion and identification employs voiceprints whose privacy and=20 integrity must be maintained. While strictly speaking out of scope=20 of the protocol itself, such considerations will be carefully=20 considered and accommodated during protocol design, and will be=20 called out as part of the applicability statement accompanying the=20 protocol specification(s).=20 =20 =20 12.=20 Normative References=20 =20 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20 9, RFC 2026, October 1996.=20 =20 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997=20 =20 3 World Wide Web Consortium, "Speech Synthesis Markup Language=20 Specification for the Speech Interface Framework", W3C Working=20 Draft 5, ,=20 April 2002, work in progress=20 =20 =20 Burger & Oran Informational =3F Expires August 2002 9 =0C Distributed Media Control Requirements February 2002=20 =20 =20 4 World Wide Web Consortium, "Speech Recognition Grammar=20 Specification Version 1.0", W3C Candidate Recommendation,=20 , June=20 2002, work in progress=20 =20 5 Floyd, S., Daigle, L., =3FIAB Architectural and Policy=20 Considerations for Open Pluggable Edge Services,=3F RFC3238,=20 January 2002=20 =20 =20 13.=20 Informative References=20 =20 5 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,=20 Peterson, J., Sparks, R., Handley, H., Schooler, E., "SIP:=20 Session Initiation Protocol", RFC 3261, June 2002.=20 =20 6 Arango, M., Dugan, A., Elliott, I., Huitema, C., and Pickett, S.,=20 "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,=20 October 1999=20 =20 7 Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., and=20 Segers, J., "Megaco Protocol Version 1.0", RFC 3015, November=20 2000=20 =20 8 Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time Streaming=20 Protocol (RTSP)", RFC 2326, April 1998=20 =20 9 Shanmugham, S., Monaco, P., and B. Eberman, "MRCP: Media Resource=20 Control Protocol", draft-shanmugham-mrcp-02.txt, July 2002, work=20 in progress=20 =20 10 Robinson, F., Marquette, B., and R. Hernandez, "Using Media=20 Resource Control Protocol with SIP", draft-robinson-mrcp-sip- 00.txt, January 2002, work in progress=20 =20 11 World Wide Web Consortium, "Voice Extensible Markup Language=20 (VoiceXML) Version 2.0", W3C Working Draft,=20 ,=20 April 2002, work in progress=20 =20 12 Van Dyke, J., Burger, E., Spitzer, A., O'Connor, W., "Basic=20 Network Media Services with SIP", draft-burger-sipping-netann- 02.txt, June 2002, work in progress=20 =20 =20 13 Guttman, E., Perkins, C., Veizades, J., Day, M. , "Service=20 Location Protocol, Version 2,=3F RFC 2608, June 1999.=20 =20 14 Gulbrandson, A, Vixie, P., Esibov, L., =3FA DNS RR for specifying=20 the location of services (DNS SRV)=3F, RFC2782, February 2000.=20 =20 =20 =20 Burger & Oran Informational =3F Expires August 2002 10 =0C Distributed Media Control Requirements February 2002=20 =20 =20 14.=20 Acknowledgments=20 =20 Stephane Maes, Sarvi Shanmughan, Brian Eberman, Dan Burnett, and=20 Brian Wyld all made significant contributions of requirements and=20 proposed text for capturing them.=20 =20 =20 15.=20 Author's Addresses=20 =20 Eric W. Burger=20 SnowShore Networks, Inc.=20 Chelmsford, MA=20 USA=20 Email: eburger@snowshore.com=20 =20 David R. Oran=20 Cisco Systems, Inc.=20 Acton, MA=20 USA=20 Email: oran@cisco.com=20 =20 =20 16.=20 Change Log=20 =20 From version draft-burger-mrcp-reqts-00 to version draft-burger- speechsc-reqts-00:=20 - draft name changed per area director advice=20 - added speaker verification to the areas addressed, including=20 speaker verification requirements, per Dan Burnet=3Fs=20 presentation at the Minneapolis BoF (see minutes).=20 - based on mailing list discussion, added requirement to handle=20 both =3Fby value=3F and =3Fby reference=3F data. This is both for = TTS=20 to be played out and grammar(s) to be applied to ASR.=20 - Based on discussion at the BoF in Minneapolis, added a=20 requirement concerning the use of load balancing schemes,=20 including those based on SRVLOC, SRV.=20 - Added a requirement for OPES compliance, per a discussion=20 with Sally Floyd as IAB observer for the BoF.=20 =20 From version draft-burger-speechsc-reqts-00 to version draft-ietf- speechsc-reqts-00:=20 - Changed =3FSV=3F to =3FSR=3F and =3Fspeaker verification=3F to = =3Fspeaker=20 recognition=3F everywhere=20 - Replaced SRCP with SPEECHSC everywhere=20 - Minor edits including mailing list name change, temporary=20 notes removed, =20 - All agreements reached at the IETF 54 WG meeting, confirmed=20 by mailing list discussion, up through 8/10/02 have been=20 integrated=20 - Improved requirement on VCR controls as suggested by Dan=20 Burnett and Sarvi Shanmughan=20 - Text describing dual-mode requirements for ASR and SR by Dan=20 Burnett added.=20 =20 Burger & Oran Informational =3F Expires August 2002 11 =0C Distributed Media Control Requirements February 2002=20 =20 =20 - Suggested change to framework figure made by Rajiv=20 Dharmadhikari incorporated=20 - Updated references to most recent versions=20 =20 From version draft-ietf-speechsc-reqts-00 to version draft-ietf- speechsc-reqts-01.txt:=20 - Adopted Rajiv D.'s wording clarification to the TTS & ASR=20 requirements to allow control to come from either a separate=20 Application Server, or a combined server with a Media=20 Processing entity.=20 =20 - Reorganized references into separate normative and=20 informative sections as requested by Scott Bradner=20 =20 - Added numbering for requirements in sections that were not=20 previously numbered. This necessitated a bit of text=20 shuffling to group related requirements more closely=20 together.=20 =20 - Added a paragraph to the introduction to emphasize the wide=20 variety of applications of the speechsc framework and=20 explicitly call out wireless mobile devices, IP phones, and=20 PSTN VoIP gateways.=20 =20 - During WGLC, the use of the term "speaker recognition" to=20 cover both speaker identification and speaker verification=20 was questioned. In addition some WG participants felt that=20 there should be separate requirements for each, while others=20 argued that the differences, while affecting the structure of=20 the application, did not affect the requirements for the=20 protocol in any substantive way. There were views that the=20 existing terminology was common in the industry and hence=20 should not be changed, and sentiments for a variety of other=20 solutions. The best compromise seemed to be to continue to=20 group the requirements together, but point out where there=20 may be subtle differences affecting applications. It also=20 seemed prudent to keep the identification/verification=20 distinction in the terminology, and hence the document uses=20 the acronym SI/SV rather than SR when talking about both=20 together.=20 =20 - added a requirement in section 5 for 1:N mapping of control=20 to media channels, but pointed out that if SDP is used this=20 comes for free.=20 =20 - Changed the input capture requirement from SHOULD to MUST,=20 but made implementation by the server a SHOULD.=20 =20 - added a SHOULD requirement for protocol efficiency with re- use of transport connections as one of a set of examples.=20 =20 =20 Burger & Oran Informational =3F Expires August 2002 12 =0C Distributed Media Control Requirements February 2002=20 =20 =20 - noted in section 10 that while RTP is assumed, the framework=20 applies to other media carriage schemes that can be described=20 by SDP, as long as they have the right features.=20 =20 Burger & Oran Informational =3F Expires August 2002 13 =0C Distributed Media Control Requirements February 2002=20 =20 =20 =20 Full Copyright Statement=20 Copyright (C) The Internet Society (2002). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain 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 are=20 included on all such copies and derivative works. However, 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.=20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns. This=20 document and the information contained herein is provided on an "AS=20 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=20 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=20 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL=20 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY=20 OR FITNESS FOR A PARTICULAR PURPOSE.=20 Acknowledgement=20 The Internet Society currently provides funding for the RFC Editor=20 function.=20 =20 Burger & Oran Informational =3F Expires August 2002 14 =0C --==========883300618==========-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sun Oct 6 20:10:31 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 UAA24961 for ; Sun, 6 Oct 2002 20:10:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g970CAB07306 for speechsc-archive@odin.ietf.org; Sun, 6 Oct 2002 20:12:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g970CAv07303 for ; Sun, 6 Oct 2002 20:12:10 -0400 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 UAA24892 for ; Sun, 6 Oct 2002 20:10:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g970C8v07295; Sun, 6 Oct 2002 20:12:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g970Bgv07281 for ; Sun, 6 Oct 2002 20:11:42 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24872 for ; Sun, 6 Oct 2002 20:09:32 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g970Aqh3008221 for speechsc@ietf.org; Sun, 6 Oct 2002 20:10:52 -0400 (EDT) Date: Sun, 6 Oct 2002 20:10:52 -0400 (EDT) From: Scott Bradner Message-Id: <200210070010.g970Aqh3008221@newdev.harvard.edu> To: speechsc@ietf.org Subject: Re: [Speechsc] Proposed resolutions for WGLC comments on 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: , humm, should this WG be making requirements for servers or for the protocol to talk to servers? 6.2.1 Plain Text The TTS Server MUST support the reading of plain text. For reading plain text, the language and voicing MAY be indicated via session parameters. For finer control over such properties, use of SSML rather than plain text provides the necessary capabilities. Scott _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Oct 8 07:17: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 HAA06491 for ; Tue, 8 Oct 2002 07:17:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g98BIwd28982 for speechsc-archive@odin.ietf.org; Tue, 8 Oct 2002 07:18:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BIwv28979 for ; Tue, 8 Oct 2002 07:18:58 -0400 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 HAA06458 for ; Tue, 8 Oct 2002 07:16:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BIpv28959; Tue, 8 Oct 2002 07:18:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98BGfv28823 for ; Tue, 8 Oct 2002 07:16:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06345; Tue, 8 Oct 2002 07:14:33 -0400 (EDT) Message-Id: <200210081114.HAA06345@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: Tue, 08 Oct 2002 07:14:33 -0400 Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-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 : Requirements for Distributed Control of ASR, SI/SV and TTS Resources Author(s) : E. Burger, D. Oran Filename : draft-ietf-speechsc-reqts-01.txt Pages : 14 Date : 2002-10-7 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition, speaker recognition (which includes both speaker identification and speaker verification) and text-to-speech. Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. Discussion of this and related documents is on the speechsc mailing list. To subscribe, send the message 'subscribe speechsc' to speechsc-request@ietf.org. The public archive is at http://www.ietf.org/mail- archive/workinggroups/speechsc/current/maillist.html. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-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-reqts-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-reqts-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-10-7141346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-7141346.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Oct 10 16:38:45 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 QAA23271 for ; Thu, 10 Oct 2002 16:38:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9AKeR403402 for speechsc-archive@odin.ietf.org; Thu, 10 Oct 2002 16:40:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKeRv03399 for ; Thu, 10 Oct 2002 16:40:27 -0400 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 QAA23263 for ; Thu, 10 Oct 2002 16:38:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKeKv03376; Thu, 10 Oct 2002 16:40:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AKc2v03191 for ; Thu, 10 Oct 2002 16:38:02 -0400 Received: from flyingfox.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23144 for ; Thu, 10 Oct 2002 16:35:49 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g9AKbtB05025; Thu, 10 Oct 2002 16:37:56 -0400 (EDT) Reply-To: From: "Eric Burger" To: "Scott Bradner" , Subject: RE: [Speechsc] Proposed resolutions for WGLC comments on Date: Thu, 10 Oct 2002 16:37:54 -0400 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) In-Reply-To: <200210070010.g970Aqh3008221@newdev.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 Part of the problem is we are mixing the definition of what a TTS Server is with the protocol. How about: The protocol MUST support requesting a TTS Server to read plain text. For reading plain text, the application MAY indicate language and voicing via session parameters. For finer control over such properties, the application MAY use SSML. > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > Of Scott Bradner > Sent: Sunday, October 06, 2002 8:11 PM > To: speechsc@ietf.org > Subject: Re: [Speechsc] Proposed resolutions for WGLC comments on > > > > humm, should this WG be making requirements for servers or for > the protocol > to talk to servers? > > 6.2.1 Plain Text > The TTS Server MUST support the reading of plain text. For reading > plain text, the language and voicing MAY be indicated via session > parameters. For finer control over such properties, use of SSML > rather than plain text provides the necessary capabilities. > > Scott > _______________________________________________ > 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 Thu Oct 10 17:13: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 RAA24359 for ; Thu, 10 Oct 2002 17:13:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9ALF5Q05627 for speechsc-archive@odin.ietf.org; Thu, 10 Oct 2002 17:15:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ALF5v05624 for ; Thu, 10 Oct 2002 17:15:05 -0400 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 RAA24356 for ; Thu, 10 Oct 2002 17:12:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ALF3v05615; Thu, 10 Oct 2002 17:15:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ALEnv05595 for ; Thu, 10 Oct 2002 17:14:49 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24350 for ; Thu, 10 Oct 2002 17:12:36 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9ALEWIm010955; Thu, 10 Oct 2002 14:14:32 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH43875; Thu, 10 Oct 2002 14:14:54 -0700 (PDT) Date: Thu, 10 Oct 2002 17:15:31 -0400 From: "David R. Oran" To: eburger@snowshore.com, Scott Bradner , speechsc@ietf.org Subject: RE: [Speechsc] Proposed resolutions for WGLC comments on Message-ID: <1242478018.1034270131@ORANLT.cisco.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On Thursday, October 10, 2002 4:37 PM -0400 Eric Burger wrote: > Part of the problem is we are mixing the definition of what a TTS Server > is with the protocol. > > How about: > > The protocol MUST support requesting a TTS Server to read plain text. For > reading plain text, the application MAY indicate language and voicing via > session parameters. For finer control over such properties, the > application MAY use SSML. > I had a slightly different tack on fixing the problem: "6.2.1 Plain Text The SPEECHSC framework MAY assume that all TTS servers are capable of reading plain text. For reading plain text, framework MUST allow the language and voicing to be indicated via session parameters. For finer control over such properties, see 6.2.2 6.2.2 SSML The SPEECHSC framework MUST support TTS servers capable of reading SSML[3] text." For another example fix, here's a shot at the VCR controls: "The Speechsc framework MUST support VCR controls, and MUST allow for servers with varying capabilities to accommodate such controls" Which formulation to people like better? Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com >> -----Original Message----- >> From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf >> Of Scott Bradner >> Sent: Sunday, October 06, 2002 8:11 PM >> To: speechsc@ietf.org >> Subject: Re: [Speechsc] Proposed resolutions for WGLC comments on >> >> >> >> humm, should this WG be making requirements for servers or for >> the protocol >> to talk to servers? >> >> 6.2.1 Plain Text >> The TTS Server MUST support the reading of plain text. For reading >> plain text, the language and voicing MAY be indicated via session >> parameters. For finer control over such properties, use of SSML >> rather than plain text provides the necessary capabilities. >> >> Scott >> _______________________________________________ >> 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 Oct 11 01:12:24 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 BAA02420 for ; Fri, 11 Oct 2002 01:12:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9B5E9a26407 for speechsc-archive@odin.ietf.org; Fri, 11 Oct 2002 01:14:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B5E9v26404 for ; Fri, 11 Oct 2002 01:14:09 -0400 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 BAA02403 for ; Fri, 11 Oct 2002 01:11:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B5E6v26396; Fri, 11 Oct 2002 01:14:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B5DZv26381 for ; Fri, 11 Oct 2002 01:13:36 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02398 for ; Fri, 11 Oct 2002 01:11:19 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9B5CE2O000526; Fri, 11 Oct 2002 01:12:14 -0400 (EDT) Date: Fri, 11 Oct 2002 01:12:14 -0400 (EDT) From: Scott Bradner Message-Id: <200210110512.g9B5CE2O000526@newdev.harvard.edu> To: eburger@snowshore.com Subject: RE: [Speechsc] Proposed resolutions for WGLC comments on Cc: speechsc@ietf.org In-Reply-To: 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: , works for me --- From eburger@snowshore.com Thu Oct 10 16:37:31 2002 Reply-To: From: "Eric Burger" To: "Scott Bradner" , Subject: RE: [Speechsc] Proposed resolutions for WGLC comments on Date: Thu, 10 Oct 2002 16:37:54 -0400 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) In-Reply-To: <200210070010.g970Aqh3008221@newdev.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Part of the problem is we are mixing the definition of what a TTS Server is with the protocol. How about: The protocol MUST support requesting a TTS Server to read plain text. For reading plain text, the application MAY indicate language and voicing via session parameters. For finer control over such properties, the application MAY use SSML. > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf > Of Scott Bradner > Sent: Sunday, October 06, 2002 8:11 PM > To: speechsc@ietf.org > Subject: Re: [Speechsc] Proposed resolutions for WGLC comments on > > > > humm, should this WG be making requirements for servers or for > the protocol > to talk to servers? > > 6.2.1 Plain Text > The TTS Server MUST support the reading of plain text. For reading > plain text, the language and voicing MAY be indicated via session > parameters. For finer control over such properties, use of SSML > rather than plain text provides the necessary capabilities. > > Scott > _______________________________________________ > 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 Oct 11 01:16:20 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 BAA02472 for ; Fri, 11 Oct 2002 01:16:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9B5I5b26525 for speechsc-archive@odin.ietf.org; Fri, 11 Oct 2002 01:18:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B5I5v26522 for ; Fri, 11 Oct 2002 01:18:05 -0400 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 BAA02465 for ; Fri, 11 Oct 2002 01:15:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B5I1v26511; Fri, 11 Oct 2002 01:18:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B5I0v26497 for ; Fri, 11 Oct 2002 01:18:00 -0400 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02461 for ; Fri, 11 Oct 2002 01:15:44 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g9B5GRf1000542; Fri, 11 Oct 2002 01:16:27 -0400 (EDT) Date: Fri, 11 Oct 2002 01:16:27 -0400 (EDT) From: Scott Bradner Message-Id: <200210110516.g9B5GRf1000542@newdev.harvard.edu> To: eburger@snowshore.com, oran@cisco.com, sob@harvard.edu, speechsc@ietf.org Subject: RE: [Speechsc] Proposed resolutions for WGLC comments on In-Reply-To: <1242478018.1034270131@ORANLT.cisco.com> 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 works for me (also) --- From oran@cisco.com Thu Oct 10 17:14:07 2002 Date: Thu, 10 Oct 2002 17:15:31 -0400 From: "David R. Oran" To: eburger@snowshore.com, Scott Bradner , speechsc@ietf.org Subject: RE: [Speechsc] Proposed resolutions for WGLC comments on In-Reply-To: References: X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Thursday, October 10, 2002 4:37 PM -0400 Eric Burger wrote: > Part of the problem is we are mixing the definition of what a TTS Server > is with the protocol. > > How about: > > The protocol MUST support requesting a TTS Server to read plain text. For > reading plain text, the application MAY indicate language and voicing via > session parameters. For finer control over such properties, the > application MAY use SSML. > I had a slightly different tack on fixing the problem: "6.2.1 Plain Text The SPEECHSC framework MAY assume that all TTS servers are capable of reading plain text. For reading plain text, framework MUST allow the language and voicing to be indicated via session parameters. For finer control over such properties, see 6.2.2 6.2.2 SSML The SPEECHSC framework MUST support TTS servers capable of reading SSML[3] text." For another example fix, here's a shot at the VCR controls: "The Speechsc framework MUST support VCR controls, and MUST allow for servers with varying capabilities to accommodate such controls" Which formulation to people like better? Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com >> -----Original Message----- >> From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf >> Of Scott Bradner >> Sent: Sunday, October 06, 2002 8:11 PM >> To: speechsc@ietf.org >> Subject: Re: [Speechsc] Proposed resolutions for WGLC comments on >> >> >> >> humm, should this WG be making requirements for servers or for >> the protocol >> to talk to servers? >> >> 6.2.1 Plain Text >> The TTS Server MUST support the reading of plain text. For reading >> plain text, the language and voicing MAY be indicated via session >> parameters. For finer control over such properties, use of SSML >> rather than plain text provides the necessary capabilities. >> >> Scott >> _______________________________________________ >> 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 Oct 11 07:48:28 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 HAA17462 for ; Fri, 11 Oct 2002 07:48:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BBo6a20783 for speechsc-archive@odin.ietf.org; Fri, 11 Oct 2002 07:50:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBo5v20780 for ; Fri, 11 Oct 2002 07:50:05 -0400 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 HAA17450 for ; Fri, 11 Oct 2002 07:47:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBo3v20772; Fri, 11 Oct 2002 07:50:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBmhv20702 for ; Fri, 11 Oct 2002 07:48:43 -0400 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 HAA17428 for ; Fri, 11 Oct 2002 07:46:34 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9BBmWaW023700 for ; Fri, 11 Oct 2002 04:48:32 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH62011; Fri, 11 Oct 2002 04:49:02 -0700 (PDT) Date: Fri, 11 Oct 2002 07:49:18 -0400 From: "David R. Oran" To: speechsc@ietf.org Message-ID: <1294905245.1034322558@ORANLT.cisco.com> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today 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 Folks, a gentle reminder that today is the last day for our "mini WGLC repeat" on draft-ietf-speechsc-reqts-01.txt. If you have objections to any of the requirements, now is the time to voice them. So far, we have a comment from Scott Bradner to reword the requirements which mention servers to be clear that the requirements are on the framework/protocol and not the servers themselves. Some example changes have been posted and it appears nobody has a problem with such changes. If no objections are forthcoming, I will update the document over the weekend and send it to the IESG for processing toward Informational RFC. Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 11 17:02:41 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 RAA05246 for ; Fri, 11 Oct 2002 17:02:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BL4OE16932 for speechsc-archive@odin.ietf.org; Fri, 11 Oct 2002 17:04:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BL4Ov16929 for ; Fri, 11 Oct 2002 17:04:24 -0400 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 RAA05234 for ; Fri, 11 Oct 2002 17:02:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BL4Fv16901; Fri, 11 Oct 2002 17:04:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BL3Ov16860 for ; Fri, 11 Oct 2002 17:03:24 -0400 Received: from ns1.nuance.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05200 for ; Fri, 11 Oct 2002 17:01:10 -0400 (EDT) Received: from mpb1exbr01.nuance.com (mpb1exbr01.nuance.com [10.0.0.43]) by ns1.nuance.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9BL4OD15453; Fri, 11 Oct 2002 14:04:24 -0700 (PDT) Received: from mpb1exch01.nuance.com ([10.0.0.47]) by mpb1exbr01.nuance.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Oct 2002 14:00:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Speechsc] Reminder: please register any objections to sendingdraft-ietf-speechsc-reqts-01.txt to IESG by end of today Date: Fri, 11 Oct 2002 14:00:15 -0700 Message-ID: Thread-Topic: [Speechsc] Reminder: please register any objections to sendingdraft-ietf-speechsc-reqts-01.txt to IESG by end of today Thread-Index: AcJxHFyLeDQu8FnPSQmNug/Z0Q1pUwAS0OEg From: "Daniel Burnett" To: "David R. Oran" , X-OriginalArrivalTime: 11 Oct 2002 21:00:43.0058 (UTC) FILETIME=[43126920:01C27169] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9BL3Ov16861 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 Dave, The requirements look good. I have a few minor typo comments: o I believe that you can remove the question marks from the ?...? wherever they occur because we've agreed to the text inside. o I think the last sentence of 8.4 was left over from copying and should be removed. You should check it. o Section 12, reference 3: remove the "5" after "Working Draft". -- dan -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Friday, October 11, 2002 4:49 AM To: speechsc@ietf.org Subject: [Speechsc] Reminder: please register any objections to sendingdraft-ietf-speechsc-reqts-01.txt to IESG by end of today Folks, a gentle reminder that today is the last day for our "mini WGLC repeat" on draft-ietf-speechsc-reqts-01.txt. If you have objections to any of the requirements, now is the time to voice them. So far, we have a comment from Scott Bradner to reword the requirements which mention servers to be clear that the requirements are on the framework/protocol and not the servers themselves. Some example changes have been posted and it appears nobody has a problem with such changes. If no objections are forthcoming, I will update the document over the weekend and send it to the IESG for processing toward Informational RFC. Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 11 18:36: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 SAA06412 for ; Fri, 11 Oct 2002 18:36:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9BMcIF21324 for speechsc-archive@odin.ietf.org; Fri, 11 Oct 2002 18:38:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BMcIv21321 for ; Fri, 11 Oct 2002 18:38:18 -0400 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 SAA06408 for ; Fri, 11 Oct 2002 18:36:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BMc9v21309; Fri, 11 Oct 2002 18:38:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BMbvv21284 for ; Fri, 11 Oct 2002 18:37:57 -0400 Received: from inet-mail3.oracle.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06402 for ; Fri, 11 Oct 2002 18:35:41 -0400 (EDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9BMbnU01680 for ; Fri, 11 Oct 2002 15:37:49 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9BMbmI01668; Fri, 11 Oct 2002 15:37:48 -0700 (PDT) Received: from BRUSSELS (dhcp-4op5-4op6-west-144-25-174-206.us.oracle.com [144.25.174.206]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9BMblO15490; Fri, 11 Oct 2002 16:37:47 -0600 (MDT) Reply-To: From: "Stephane H. Maes" To: "'David R. Oran'" , Subject: RE: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today Date: Fri, 11 Oct 2002 18:37:39 -0400 Organization: Oracle Message-ID: <001b01c27176$cdd4a520$ceae1990@watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <1294905245.1034322558@ORANLT.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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 David, I think that the requirements are alright. However, I still would like as an item of interest (i.e. not a MUST) that we mention the capability to: - remote control and combine more complex flows of engines and in particular: - remote control of engines in serial combination - set of intermediate exchanges / coordination between engines (e.g. exchanges of partial results between engines in parallel). I think that we should capture this as an item of interest. This may be achieved by the current spec or become an objective for a later release. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of David R. Oran Sent: Friday, October 11, 2002 7:49 AM To: speechsc@ietf.org Subject: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today Folks, a gentle reminder that today is the last day for our "mini WGLC repeat" on draft-ietf-speechsc-reqts-01.txt. If you have objections to any of the requirements, now is the time to voice them. So far, we have a comment from Scott Bradner to reword the requirements which mention servers to be clear that the requirements are on the framework/protocol and not the servers themselves. Some example changes have been posted and it appears nobody has a problem with such changes. If no objections are forthcoming, I will update the document over the weekend and send it to the IESG for processing toward Informational RFC. Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 11 22:20:28 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 WAA09577 for ; Fri, 11 Oct 2002 22:20:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9C2MDv30323 for speechsc-archive@odin.ietf.org; Fri, 11 Oct 2002 22:22:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C2MDv30320 for ; Fri, 11 Oct 2002 22:22:13 -0400 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 WAA09574 for ; Fri, 11 Oct 2002 22:19:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C2M9v30312; Fri, 11 Oct 2002 22:22:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9C2M0v30298 for ; Fri, 11 Oct 2002 22:22:00 -0400 Received: from dirty.research.bell-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09568 for ; Fri, 11 Oct 2002 22:19:43 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g9C2LlhN075648; Fri, 11 Oct 2002 22:21:47 -0400 (EDT) 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 g9C2LfI74388; Fri, 11 Oct 2002 22:21:41 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id WAA3088027; Fri, 11 Oct 2002 22:21:40 -0400 (EDT) Message-ID: <3DA78734.19B173BB@research.bell-labs.com> Date: Fri, 11 Oct 2002 22:21:40 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: "David R. Oran" CC: speechsc@ietf.org Subject: Re: [Speechsc] Proposed resolutions for WGLC comments ondiraft-ietf-speechsc-reqts-00.txt References: <883290494.1033910943@ORANLT.cisco.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 In general, the requirements looks good, with few more comments: 5.5. Server Location and Load Balancing I'd like to see "performing service location and load balancing," to "supporting service location and load balancing,". Dave, this is what I mean from my last comments. 5.6 Simultaneous services Could we change the tittle to "5.6 Multiple services" since the text is talking about multiple services that may not be simultaneous. 6.2.1. Plain Text and 6.2.2. SSML Does this mean we have to support both free form plain text and SSML markup? Then we may need to redefine things that already defined in SSML to support basic synthesis features such as language selection, rate, etc. This will increase the implementation complexity and could leave some ambiguities for TTS text parsing. Why don't we just support SSML? It can be just as simple as: I don't speak Japanese. In requirement, we can say SPEECHSC MUST support SSML basics, and SHOULD support other SSML tags, etc. 7.2 XML I would like to use more precise text such as: 7.2. VoiceXML Speech Recognition Grammar Specification The ASR Server MUST support the VoiceXML speech recognition grammar specification (SRGS) for speech recognition [4]. Dave, my last comments concern was the requirement mentioned XML only. The SRGS also defined a ABNF format which is not XML at all. 7.3.3. Grammar Sharing Is there a need to define a protocol to say "share" or "don't share" when send a grammar to a speech server? If the grammar is public and the speech server should support archiving feature (i.e., "Servers SHOULD be able to store and later retrieve by reference large grammars" in 7.3.1), I think this implies sharing function already. 7.5. Input Capture I am a little concern about this seems ASR internal tuning feature. It is nice to have it, but in many countries it is illegal to record user's speech without user's explicit permission. If we define speech capture in protocol, we have to specify a protocol to force the permission request process. Unless the tuning is totally automatic and there is no chance that the recorded speech can be stored and copied for other uses (such as online adaptation). Should we put a legal notice here? 8.3. State for multiple utterances What is the state duration here? In a session, or cross sessions? -- Qiru -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of David R. Oran Sent: Friday, October 11, 2002 7:49 AM To: speechsc@ietf.org Subject: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today Folks, a gentle reminder that today is the last day for our "mini WGLC repeat" on draft-ietf-speechsc-reqts-01.txt. If you have objections to any of the requirements, now is the time to voice them. So far, we have a comment from Scott Bradner to reword the requirements which mention servers to be clear that the requirements are on the framework/protocol and not the servers themselves. Some example changes have been posted and it appears nobody has a problem with such changes. If no objections are forthcoming, I will update the document over the weekend and send it to the IESG for processing toward Informational RFC. Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sat Oct 12 15:34:32 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 PAA29608 for ; Sat, 12 Oct 2002 15:34:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9CJaEf12242 for speechsc-archive@odin.ietf.org; Sat, 12 Oct 2002 15:36:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJaDv12239 for ; Sat, 12 Oct 2002 15:36:13 -0400 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 PAA29602 for ; Sat, 12 Oct 2002 15:34:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJaAv12227; Sat, 12 Oct 2002 15:36:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJZMv12192 for ; Sat, 12 Oct 2002 15:35:22 -0400 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29590 for ; Sat, 12 Oct 2002 15:33:09 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9CJZGIm018352; Sat, 12 Oct 2002 12:35:16 -0700 (PDT) Received: from ORANLT.cisco.com ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH92339; Sat, 12 Oct 2002 12:35:39 -0700 (PDT) Date: Sat, 12 Oct 2002 15:36:19 -0400 From: "David R. Oran" To: stephane.maes@oracle.com, speechsc@ietf.org Subject: RE: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today Message-ID: <1409326404.1034436979@ORANLT.cisco.com> In-Reply-To: <001b01c27176$cdd4a520$ceae1990@watson.ibm.com> References: <001b01c27176$cdd4a520$ceae1990@watson.ibm.com> X-Mailer: Mulberry/3.0.0b6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On Friday, October 11, 2002 6:37 PM -0400 "Stephane H. Maes" wrote: > David, > > I think that the requirements are alright. > Great, thanks. > However, I still would like as an item of interest (i.e. not a MUST) > that we mention the capability to: > - remote control and combine more complex flows of engines and > in particular: > - remote control of engines in serial combination > - set of intermediate exchanges / coordination between > engines (e.g. exchanges of partial results between engines in parallel). > > I think that we should capture this as an item of interest. This may be > achieved by the current spec or become an objective for a later release. > In the (non) imortal words of the document authors/editors: PROVIDE TEXT PLEASE! Thanks, Dave. > > Thanks > > Stephane > > _____ > Stephane H. Maes, PhD, > Director of Architecture - Mobile, Oracle Corporation. > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > e-mail: stephane.maes@oracle.com > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf > Of David R. Oran > Sent: Friday, October 11, 2002 7:49 AM > To: speechsc@ietf.org > Subject: [Speechsc] Reminder: please register any objections to sending > draft-ietf-speechsc-reqts-01.txt to IESG by end of today > > > Folks, a gentle reminder that today is the last day for our "mini WGLC > repeat" on draft-ietf-speechsc-reqts-01.txt. > > If you have objections to any of the requirements, now is the time to > voice > them. > > So far, we have a comment from Scott Bradner to reword the requirements > which mention servers to be clear that the requirements are on the > framework/protocol and not the servers themselves. Some example changes > have been posted and it appears nobody has a problem with such changes. > > If no objections are forthcoming, I will update the document over the > weekend and send it to the IESG for processing toward Informational RFC. > > Dave. > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc > > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sat Oct 12 15:35: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 PAA29633 for ; Sat, 12 Oct 2002 15:35:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9CJb4K12390 for speechsc-archive@odin.ietf.org; Sat, 12 Oct 2002 15:37:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJb4v12379 for ; Sat, 12 Oct 2002 15:37:04 -0400 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 PAA29625 for ; Sat, 12 Oct 2002 15:34:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9CJb1v12291; Sat, 12 Oct 2002 15:37:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BIXFv08901 for ; Fri, 11 Oct 2002 14:33:15 -0400 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01526 for ; Fri, 11 Oct 2002 14:31:02 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44] (may be forged)) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id NAA02167 for ; Fri, 11 Oct 2002 13:44:13 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Fri, 11 Oct 2002 13:23:58 -0500 Received: from INTERVOICE-Message_Server by 172.16.16.64 with Novell_GroupWise; Fri, 11 Oct 2002 13:33:08 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 11 Oct 2002 13:32:56 -0500 From: "Skip Cave" To: Subject: Re: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-01.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9FC30874.066739D7" 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 MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_9FC30874.066739D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 5.3. Avoid Duplicating Existing Protocols=20 =20 To the extent feasible, SPEECHSC SHOULD NOT duplicate the=20 functionality of existing protocols. For example, SIP with msuri=20 [12] and RTSP already define how to request playback of audio. =20 The focus of SPEECHSC is new functionality not addressed by existing=20 protocols or extending existing protocols within the strictures of=20 requirement 5.2. Where an existing protocol can be gracefully=20 extended to support SPEECHSC requirements, such extensions are=20 acceptable alternatives for meeting the requirements.=20 As a corollary to this, SPEECHSC should not require a separate protocol to = perform one or two functions that could be easily added into the SPEECHSC p= rotocol (like redirecting media streams, or discovering capabilities). 6.3. Control Channel=20 =20 The SPEECHSC framework MUST be capable of establishing the control=20 channel between the client and server on a per-session basis, where=20 a session is loosely defined to be associated with a single ?call?=20 or ?dialog?. The protocol SHOULD be capable of maintaining a long- lived control channel for multiple sessions serially, and MAY be=20 capable of shorter time horizons as well, including as short as for=20 the processing of a single utterance.=20 SPEECHSC must not require the controlling element (application sercer, medi= a processing entity) to accept or originate media streams. Media streams ma= y source & sink from the controllED element (ASR, TTS, etc.) but these stre= ams may (or in many cases WON'T) originate or terminate in the SPEECHSC con= troller. Skip Cave Sr. Principal Engineer Intervoice Inc.=20 --=_9FC30874.066739D7 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
5.3.      Avoid Duplicating Existing = Protocols=20
   
   To the extent feasible, SPEECHSC = SHOULD=20 NOT duplicate the
   functionality of existing protocols.&nbs= p;=20 For example, SIP with msuri
   [12] and RTSP already define = how to=20 request playback of audio. 
   The focus of SPEECHSC is = new=20 functionality not addressed by existing
   protocols or = extending=20 existing protocols within the strictures of
   requirement = 5.2.=20 Where an existing protocol can be gracefully
   extended = to=20 support SPEECHSC requirements, such extensions are
   = acceptable=20 alternatives for meeting the requirements.
 
 
As a corollary to this, SPEECHSC should not require a separate = protocol to=20 perform one or two functions that could be easily added into the = SPEECHSC=20 protocol (like redirecting media streams, or discovering capabilities).
 
 
6.3.     Control Channel
   =20=
   The SPEECHSC framework MUST be capable of establishing = the=20 control
   channel between the client and server on a = per-session=20 basis, where
   a session is loosely defined to be associated= with=20 a single ?call?
   or ?dialog?. The protocol SHOULD be = capable of=20 maintaining a long-
   lived control channel for multiple = sessions=20 serially, and MAY be
   capable of shorter time horizons as = well,=20 including as short as for
   the processing of a single = utterance.=20
 
SPEECHSC must not require the controlling element (application = sercer,=20 media processing entity) to accept or originate media streams. Media = streams may=20 source & sink from the controllED element (ASR, TTS, etc.) but these = streams=20 may (or in many cases WON'T) originate or terminate in the SPEECHSC=20 controller.
 
 
Skip Cave
Sr. Principal Engineer
Intervoice Inc.
--=_9FC30874.066739D7-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Sun Oct 13 21:45:43 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 VAA27757 for ; Sun, 13 Oct 2002 21:45:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9E1lTK23777 for speechsc-archive@odin.ietf.org; Sun, 13 Oct 2002 21:47:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E1lTv23774 for ; Sun, 13 Oct 2002 21:47:29 -0400 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 VAA27752 for ; Sun, 13 Oct 2002 21:45:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E1lNv23766; Sun, 13 Oct 2002 21:47:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9E1kGv23743 for ; Sun, 13 Oct 2002 21:46:16 -0400 Received: from inet-mail2.oracle.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27738 for ; Sun, 13 Oct 2002 21:43:58 -0400 (EDT) Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9E1k6j15668 for ; Sun, 13 Oct 2002 18:46:06 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9E1k5f15652; Sun, 13 Oct 2002 18:46:05 -0700 (PDT) Received: from BRUSSELS (dhcp-amer-vpn-gw2-west-141-144-77-102.vpn.oracle.com [141.144.77.102]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9E1k0r29308; Sun, 13 Oct 2002 19:46:01 -0600 (MDT) Reply-To: From: "Stephane H. Maes" To: "'David R. Oran'" , Subject: RE: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today Date: Sun, 13 Oct 2002 21:45:48 -0400 Organization: Oracle Message-ID: <003601c27323$6d713320$29c7c70a@watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1409326404.1034436979@ORANLT.cisco.com> 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 David, Very well :) I suggest adding a section 9.1.3. Proposed text: _________ 9.1.3 Combination of services It is OPTIONALLY of interest that SPEECHSC supports more complex remote combination and controls of speech engines: - Combination in series of engines that may then act on the input or output of ASR, TTS or Speaker recognition engines. The control MAY then extend beyond such engines to include other audio input and output processing and natural language processing. - Intermediate exchanges and coordination between engines - Remote specification of flows between engines. These capabilities MAY benefit from service discovery mechanisms (e.g. engines, properties and states discovery). _________ Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Saturday, October 12, 2002 3:36 PM To: stephane.maes@oracle.com; speechsc@ietf.org Subject: RE: [Speechsc] Reminder: please register any objections to sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today --On Friday, October 11, 2002 6:37 PM -0400 "Stephane H. Maes" wrote: > David, > > I think that the requirements are alright. > Great, thanks. > However, I still would like as an item of interest (i.e. not a MUST) > that we mention the capability to: > - remote control and combine more complex flows of engines and in > particular: > - remote control of engines in serial combination > - set of intermediate exchanges / coordination between engines (e.g. > exchanges of partial results between engines in parallel). > > I think that we should capture this as an item of interest. This may > be achieved by the current spec or become an objective for a later > release. > In the (non) imortal words of the document authors/editors: PROVIDE TEXT PLEASE! Thanks, Dave. > > Thanks > > Stephane > > _____ > Stephane H. Maes, PhD, > Director of Architecture - Mobile, Oracle Corporation. > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > e-mail: stephane.maes@oracle.com > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On > Behalf Of David R. Oran > Sent: Friday, October 11, 2002 7:49 AM > To: speechsc@ietf.org > Subject: [Speechsc] Reminder: please register any objections to > sending draft-ietf-speechsc-reqts-01.txt to IESG by end of today > > > Folks, a gentle reminder that today is the last day for our "mini WGLC > repeat" on draft-ietf-speechsc-reqts-01.txt. > > If you have objections to any of the requirements, now is the time to > voice them. > > So far, we have a comment from Scott Bradner to reword the > requirements which mention servers to be clear that the requirements > are on the framework/protocol and not the servers themselves. Some > example changes have been posted and it appears nobody has a problem > with such changes. > > If no objections are forthcoming, I will update the document over the > weekend and send it to the IESG for processing toward Informational > RFC. > > Dave. > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc > > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Oct 16 18:41:35 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 SAA14162 for ; Wed, 16 Oct 2002 18:41:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GMhLt02762 for speechsc-archive@odin.ietf.org; Wed, 16 Oct 2002 18:43:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMhLv02759 for ; Wed, 16 Oct 2002 18:43:21 -0400 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 SAA14149 for ; Wed, 16 Oct 2002 18:41:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMhDv02750; Wed, 16 Oct 2002 18:43:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMg6v02722 for ; Wed, 16 Oct 2002 18:42:06 -0400 Received: from flyingfox.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14135 for ; Wed, 16 Oct 2002 18:39:48 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g9GMfxB04346 for ; Wed, 16 Oct 2002 18:41:59 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF SPEECHSC" Date: Wed, 16 Oct 2002 18:41:58 -0400 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Speechsc] Planning Meeting Agenda for 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: 7bit Content-Transfer-Encoding: 7bit It is time to start setting the agenda for the Atlanta meeting. If you want to discuss issues with drafts at the Atlanta meeting, please request a slot to do so, by sending mail to Dave or myself . As always the slots will be allocated for discussions according to what is outlined below. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues, and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it must be shown how the work falls within the existing charter; no time will be allocated for proposals that do not fit the current WG charter. The solution should only be sketched. The appropriate way of bringing new work to the working group is to post an Internet Draft, send a pointer to the draft to the mailing list and promote discussion on the list. Slots on the agenda should be used to discuss outstanding topics that haven't been settled on the mailing list. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for discussion/questions. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- THIS IS NOT A FINAL AGENDA, CHANGES MAY OCCUR BEFORE SCHEDULING CLOSES ON OCTOBER 29 at 1700 PM EDT -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- AS OF OCTOBER 15, 2002 DRAFT Agenda of the Fifty-fifth IETF November 17-21, 2002 THURSDAY, November 21, 2002 1530-1730 Afternoon Sessions II TSV speechsc Speech Services Control WG For the up-to-the minute agenda, see . _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Oct 16 19:12:19 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 TAA14645 for ; Wed, 16 Oct 2002 19:12:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9GNE6o04066 for speechsc-archive@odin.ietf.org; Wed, 16 Oct 2002 19:14:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GNE6v04063 for ; Wed, 16 Oct 2002 19:14:06 -0400 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 TAA14640 for ; Wed, 16 Oct 2002 19:11:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GNE3v04055; Wed, 16 Oct 2002 19:14:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GNDiv04039 for ; Wed, 16 Oct 2002 19:13:44 -0400 Received: from flyingfox.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14637 for ; Wed, 16 Oct 2002 19:11:26 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g9GNDbB05232 for ; Wed, 16 Oct 2002 19:13:37 -0400 (EDT) Reply-To: From: "Eric Burger" To: "IETF SPEECHSC" Date: Wed, 16 Oct 2002 19:13:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: High Content-Transfer-Encoding: 7bit Subject: [Speechsc] Protocol Analysis 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've spoken with Brian, and it seems that a lot of people that owe him chapters are a bit behind. We really need to get this document rolling. Remember, if there isn't an Internet Draft in the repository, it is really hard to discuss the issues in our session in Atlanta. It is true that all sustentative discussion happens on the list. However, we can make a lot of progress in our face-to-face meeting. The protocol analysis document is a gating milestone in the protocol work. If this document is late, the entire protocol delivery schedule slips. There are a lot of people waiting for the timely delivery of the finished product. If you signed up for a section, but now realize you won't be able to do the work, PLEASE contact Brian as soon as possible. Thanks. -- - Eric _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Oct 16 20:02:26 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 UAA15751 for ; Wed, 16 Oct 2002 20:02:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9H04Dl06019 for speechsc-archive@odin.ietf.org; Wed, 16 Oct 2002 20:04:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H04Dv06016 for ; Wed, 16 Oct 2002 20:04:13 -0400 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 UAA15738 for ; Wed, 16 Oct 2002 20:01:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H048v06006; Wed, 16 Oct 2002 20:04:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H03mv05991 for ; Wed, 16 Oct 2002 20:03:48 -0400 Received: from inet-mail1.oracle.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15715 for ; Wed, 16 Oct 2002 20:01:29 -0400 (EDT) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9H03d116834 for ; Wed, 16 Oct 2002 17:03:39 -0700 (PDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9H03cj16827; Wed, 16 Oct 2002 17:03:39 -0700 (PDT) Received: from BRUSSELS ([144.25.233.112]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9H03Yh13774; Wed, 16 Oct 2002 18:03:35 -0600 (MDT) Reply-To: From: "Stephane H. Maes" To: , "'IETF SPEECHSC'" , Subject: RE: [Speechsc] Protocol Analysis Document Date: Wed, 16 Oct 2002 20:03:25 -0400 Organization: Oracle Message-ID: <005a01c27570$a05f9200$29c7c70a@watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: 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 Eric / Brian, What are the timeline / deadline for these sections? I am not sure when the sections are due; hence my lack of immediate input... Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of Eric Burger Sent: Wednesday, October 16, 2002 7:14 PM To: IETF SPEECHSC Subject: [Speechsc] Protocol Analysis Document Importance: High I've spoken with Brian, and it seems that a lot of people that owe him chapters are a bit behind. We really need to get this document rolling. Remember, if there isn't an Internet Draft in the repository, it is really hard to discuss the issues in our session in Atlanta. It is true that all sustentative discussion happens on the list. However, we can make a lot of progress in our face-to-face meeting. The protocol analysis document is a gating milestone in the protocol work. If this document is late, the entire protocol delivery schedule slips. There are a lot of people waiting for the timely delivery of the finished product. If you signed up for a section, but now realize you won't be able to do the work, PLEASE contact Brian as soon as possible. Thanks. -- - Eric _______________________________________________ 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 Thu Oct 17 10:47:58 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 KAA13401 for ; Thu, 17 Oct 2002 10:47:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HEoCR28802 for speechsc-archive@odin.ietf.org; Thu, 17 Oct 2002 10:50:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HEoCv28799 for ; Thu, 17 Oct 2002 10:50:12 -0400 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 KAA13398 for ; Thu, 17 Oct 2002 10:47:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HEo7v28776; Thu, 17 Oct 2002 10:50:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HEPEv27021 for ; Thu, 17 Oct 2002 10:25:14 -0400 Received: from flyingfox.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12514 for ; Thu, 17 Oct 2002 10:22:59 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g9HEP8B23248; Thu, 17 Oct 2002 10:25:09 -0400 (EDT) Reply-To: From: "Eric Burger" To: Cc: "'IETF SPEECHSC'" , Subject: RE: [Speechsc] Protocol Analysis Document Date: Thu, 17 Oct 2002 10:25:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <005a01c27570$a05f9200$29c7c70a@watson.ibm.com> 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 They are due now. In I wrote: > Having a draft out by the end of September gives us 3 weeks > of list discussion and 1 week for revision. The key point is > to have the document available for discussion in Atlanta. > > Also note that we cannot update a new -00 document to -01 after 10/27. What this means is we are now down to just getting the document out on time. If you get your sections to Brian now, that will give him one week to stitch together the document in time for the HARD deadline of 10/27. > -----Original Message----- > From: Stephane H. Maes [mailto:stephane.maes@oracle.com] > Sent: Wednesday, October 16, 2002 8:03 PM > To: eburger@snowshore.com; 'IETF SPEECHSC'; brian.wyld@eloquant.com > Subject: RE: [Speechsc] Protocol Analysis Document > > > Eric / Brian, > > What are the timeline / deadline for these sections? > > I am not sure when the sections are due; hence my lack of immediate > input... > > Thanks > > Stephane [snip] _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Thu Oct 17 11:31:02 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 LAA14666 for ; Thu, 17 Oct 2002 11:31:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9HFXHf31611 for speechsc-archive@odin.ietf.org; Thu, 17 Oct 2002 11:33:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFXHv31608 for ; Thu, 17 Oct 2002 11:33:17 -0400 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 LAA14660 for ; Thu, 17 Oct 2002 11:31:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFXAv31600; Thu, 17 Oct 2002 11:33:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HFWRv31562 for ; Thu, 17 Oct 2002 11:32:27 -0400 Received: from dirty.research.bell-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14642 for ; Thu, 17 Oct 2002 11:30:12 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g9HFWOhN030139; Thu, 17 Oct 2002 11:32:24 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g9HFWHa15204; Thu, 17 Oct 2002 11:32:18 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id LAA3241534; Thu, 17 Oct 2002 11:32:17 -0400 (EDT) Message-ID: <3DAED800.90539F70@research.bell-labs.com> Date: Thu, 17 Oct 2002 11:32:17 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: eburger@snowshore.com CC: IETF SPEECHSC Subject: Re: [Speechsc] Protocol Analysis Document References: 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 Eric/Brian, I can help if needed. I don't have any signed chapter so far. -- Qiru Eric Burger wrote: > > I've spoken with Brian, and it seems that a lot of people that owe him > chapters are a bit behind. > > We really need to get this document rolling. Remember, if there isn't an > Internet Draft in the repository, it is really hard to discuss the issues in > our session in Atlanta. It is true that all sustentative discussion happens > on the list. However, we can make a lot of progress in our face-to-face > meeting. > > The protocol analysis document is a gating milestone in the protocol work. > If this document is late, the entire protocol delivery schedule slips. > There are a lot of people waiting for the timely delivery of the finished > product. > > If you signed up for a section, but now realize you won't be able to do the > work, PLEASE contact Brian as soon as > possible. > > Thanks. > > -- > - Eric > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 18 07:12:30 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 HAA21052 for ; Fri, 18 Oct 2002 07:12:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9IBEEu07659 for speechsc-archive@odin.ietf.org; Fri, 18 Oct 2002 07:14:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBEEv07656 for ; Fri, 18 Oct 2002 07:14:14 -0400 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 HAA21039 for ; Fri, 18 Oct 2002 07:11:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBE7v07646; Fri, 18 Oct 2002 07:14:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBD4v07622 for ; Fri, 18 Oct 2002 07:13:04 -0400 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 HAA21027 for ; Fri, 18 Oct 2002 07:10:48 -0400 (EDT) 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 g9IBCuH21627; Fri, 18 Oct 2002 11:12:56 GMT Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id 7AA883B6CA; Fri, 18 Oct 2002 07:11:44 -0400 (EDT) Reply-To: From: "Brian Wyld" To: , Cc: "'IETF SPEECHSC'" Subject: RE: [Speechsc] Protocol Analysis Document Date: Fri, 18 Oct 2002 13:11:30 +0200 Message-ID: <00b301c27697$1e7134b0$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3DAED800.90539F70@research.bell-labs.com> 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 Hi Qiru, Well, the assignation list was: > RTSP : Jiten Goel, Rajiv Dharmadhikari > SIP : Brian Marquette, Jiten Goel > Web Services : Stephane Maes > MRCP draft : Sarvi Shanmugham > BEEP : Brian Eberman Rajiv indicated he's still a 'go', but so far I haven't had commitment from the others. If you have a particular protocol in mind, let me know and I'll ask the current contributor to decide if they can do it or not rapidly.... 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] > -----Message d'origine----- > De : speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org]De la part > de Qiru Zhou > Envoye : Thursday, October 17, 2002 17:32 > A : eburger@snowshore.com > Cc : IETF SPEECHSC > Objet : Re: [Speechsc] Protocol Analysis Document > > > Eric/Brian, > > I can help if needed. I don't have any signed chapter so far. > > -- Qiru > > Eric Burger wrote: > > > > I've spoken with Brian, and it seems that a lot of people > that owe him > > chapters are a bit behind. > > > > We really need to get this document rolling. Remember, if > there isn't an > > Internet Draft in the repository, it is really hard to > discuss the issues in > > our session in Atlanta. It is true that all sustentative > discussion happens > > on the list. However, we can make a lot of progress in our > face-to-face > > meeting. > > > > The protocol analysis document is a gating milestone in the > protocol work. > > If this document is late, the entire protocol delivery > schedule slips. > > There are a lot of people waiting for the timely delivery > of the finished > > product. > > > > If you signed up for a section, but now realize you won't > be able to do the > > work, PLEASE contact Brian > as soon as > > possible. > > > > Thanks. > > > > -- > > - Eric > > > _______________________________________________ > 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 Oct 18 19:44: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 TAA12645 for ; Fri, 18 Oct 2002 19:44:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9INkDo18168 for speechsc-archive@odin.ietf.org; Fri, 18 Oct 2002 19:46:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INkDv18165 for ; Fri, 18 Oct 2002 19:46:13 -0400 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 TAA12634 for ; Fri, 18 Oct 2002 19:43:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INk6v18156; Fri, 18 Oct 2002 19:46:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9INjrv18115 for ; Fri, 18 Oct 2002 19:45:53 -0400 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 TAA12622 for ; Fri, 18 Oct 2002 19:43:32 -0400 (EDT) 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 g9INjiLI028842; Fri, 18 Oct 2002 19:45:44 -0400 (EDT) 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 g9INjbI81208; Fri, 18 Oct 2002 19:45:38 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id TAA3277113; Fri, 18 Oct 2002 19:45:37 -0400 (EDT) Message-ID: <3DB09D21.6B91F661@research.bell-labs.com> Date: Fri, 18 Oct 2002 19:45:37 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: brian.wyld@eloquant.com CC: eburger@snowshore.com, "'IETF SPEECHSC'" Subject: Re: [Speechsc] Protocol Analysis Document References: <00b301c27697$1e7134b0$8300010a@hq.eloquant.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 Brian, I am wondering where the VoiceXML interface is covered in the list. There was an obsoleted draft "draft-rosenberg-sip-vxml-01.txt" related VoiceXML to SIP. It was deleted from IETF site. I am interested in this since I am working with W3C VoiceXML WG as well. -- Qiru Brian Wyld wrote: > > Hi Qiru, > > Well, the assignation list was: > > RTSP : Jiten Goel, Rajiv Dharmadhikari > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > MRCP draft : Sarvi Shanmugham > > BEEP : Brian Eberman > > Rajiv indicated he's still a 'go', but so far I haven't had commitment from > the others. > > If you have a particular protocol in mind, let me know and I'll ask the > current contributor to decide if they can do it or not rapidly.... > > 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] > ============================================================================== Qiru Zhou (http://www.multimedia.bell-labs.com) Dialogue Systems Research Department, Bell Laboratories, Lucent Technologies 600 Mountain Avenue, 2D428, Murray Hill, NJ 07974, USA tel +1 908 582 4562 | fax +1 908 582 7308 | qzhou@research.bell-labs.com ============================================================================== _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 18 20:05:30 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 UAA12937 for ; Fri, 18 Oct 2002 20:05:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9J07LW19286 for speechsc-archive@odin.ietf.org; Fri, 18 Oct 2002 20:07:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J07Lv19283 for ; Fri, 18 Oct 2002 20:07:21 -0400 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 UAA12918 for ; Fri, 18 Oct 2002 20:04:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J07Gv19207; Fri, 18 Oct 2002 20:07:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J05wv18685 for ; Fri, 18 Oct 2002 20:05:58 -0400 Received: from inet-mail1.oracle.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12914 for ; Fri, 18 Oct 2002 20:03:36 -0400 (EDT) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9J05n109530 for ; Fri, 18 Oct 2002 17:05:49 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9J05mj09520 for ; Fri, 18 Oct 2002 17:05:48 -0700 (PDT) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9J05mR24713 for ; Fri, 18 Oct 2002 18:05:48 -0600 (MDT) Received: from BRUSSELS ([144.25.233.79]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9J05Sx24064; Fri, 18 Oct 2002 18:05:28 -0600 (MDT) Reply-To: From: "Stephane H. Maes" To: , Cc: , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Protocol Analysis Document Date: Fri, 18 Oct 2002 20:05:19 -0400 Organization: Oracle Message-ID: <000d01c27703$392c0a70$901f2382@watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <3DB09D21.6B91F661@research.bell-labs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Qiru, A priori, I would expect that VXML is fundamentally at a different level (up to a few tags). Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of Qiru Zhou Sent: Friday, October 18, 2002 7:46 PM To: brian.wyld@eloquant.com Cc: eburger@snowshore.com; 'IETF SPEECHSC' Subject: Re: [Speechsc] Protocol Analysis Document Brian, I am wondering where the VoiceXML interface is covered in the list. There was an obsoleted draft "draft-rosenberg-sip-vxml-01.txt" related VoiceXML to SIP. It was deleted from IETF site. I am interested in this since I am working with W3C VoiceXML WG as well. -- Qiru Brian Wyld wrote: > > Hi Qiru, > > Well, the assignation list was: > > RTSP : Jiten Goel, Rajiv Dharmadhikari > > SIP : Brian Marquette, Jiten Goel > > Web Services : Stephane Maes > > MRCP draft : Sarvi Shanmugham > > BEEP : Brian Eberman > > Rajiv indicated he's still a 'go', but so far I haven't had commitment > from the others. > > If you have a particular protocol in mind, let me know and I'll ask > the current contributor to decide if they can do it or not rapidly.... > > 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] > ======================================================================== ====== Qiru Zhou (http://www.multimedia.bell-labs.com) Dialogue Systems Research Department, Bell Laboratories, Lucent Technologies 600 Mountain Avenue, 2D428, Murray Hill, NJ 07974, USA tel +1 908 582 4562 | fax +1 908 582 7308 | qzhou@research.bell-labs.com ======================================================================== ====== _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 18 20: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 UAA13198 for ; Fri, 18 Oct 2002 20:26:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9J0S7Y19766 for speechsc-archive@odin.ietf.org; Fri, 18 Oct 2002 20:28:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J0S7v19763 for ; Fri, 18 Oct 2002 20:28:07 -0400 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 UAA13191 for ; Fri, 18 Oct 2002 20:25:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J0S3v19755; Fri, 18 Oct 2002 20:28:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J0Rpv19737 for ; Fri, 18 Oct 2002 20:27:51 -0400 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 UAA13183 for ; Fri, 18 Oct 2002 20:25:29 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g9J0RgLI029023; Fri, 18 Oct 2002 20:27:42 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g9J0RZa64873; Fri, 18 Oct 2002 20:27:35 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id UAA3258233; Fri, 18 Oct 2002 20:27:34 -0400 (EDT) Message-ID: <3DB0A6F6.80C2170B@research.bell-labs.com> Date: Fri, 18 Oct 2002 20:27:34 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: stephane.maes@oracle.com CC: brian.wyld@eloquant.com, eburger@snowshore.com, "'IETF SPEECHSC'" Subject: Re: [Speechsc] Protocol Analysis Document References: <000d01c27703$392c0a70$901f2382@watson.ibm.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 Stephane, Here VXML I referred are speech grammars, speech markup for TTS, and VXML properties that will change speech server behaviors. Apprently a speech server is a consumer of them. More precisely, they are some VoiceXML components (SRG, SSML, event returns, and VXML Properties) will interact with a speech server. Unless there is a translation layer to insulate entire VXML from a speech server. Which I'd like to avoid due to inefficiency. I agree the VXML interpreter per se, it is a several layer high up. But the above components will be up/down from/to the server. If you have a different model in mind, please let me know. -- Qiru "Stephane H. Maes" wrote: > > Qiru, > > A priori, I would expect that VXML is fundamentally at a different level > (up to a few tags). > > Stephane > > _____ > Stephane H. Maes, PhD, > Director of Architecture - Mobile, Oracle Corporation. > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > e-mail: stephane.maes@oracle.com > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > -----Original Message----- > From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf > Of Qiru Zhou > Sent: Friday, October 18, 2002 7:46 PM > To: brian.wyld@eloquant.com > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > Subject: Re: [Speechsc] Protocol Analysis Document > > Brian, > > I am wondering where the VoiceXML interface is covered in the list. > There was an obsoleted draft "draft-rosenberg-sip-vxml-01.txt" related > VoiceXML to SIP. It was deleted from IETF site. I am interested in this > since I am working with W3C VoiceXML WG as well. > > -- Qiru > > Brian Wyld wrote: > ? > ? Hi Qiru, > ? > ? Well, the assignation list was: > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > ? ? SIP : Brian Marquette, Jiten Goel > ? ? Web Services : Stephane Maes > ? ? MRCP draft : Sarvi Shanmugham > ? ? BEEP : Brian Eberman > ? > ? Rajiv indicated he's still a 'go', but so far I haven't had commitment > > ? from the others. > ? > ? If you have a particular protocol in mind, let me know and I'll ask > ? the current contributor to decide if they can do it or not rapidly.... > ? > ? 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] > ? _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 18 21:10: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 VAA13766 for ; Fri, 18 Oct 2002 21:10:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9J1CDZ21820 for speechsc-archive@odin.ietf.org; Fri, 18 Oct 2002 21:12:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J1CDv21817 for ; Fri, 18 Oct 2002 21:12:13 -0400 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 VAA13761 for ; Fri, 18 Oct 2002 21:09:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J1C8v21809; Fri, 18 Oct 2002 21:12:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J1Bhv21791 for ; Fri, 18 Oct 2002 21:11:43 -0400 Received: from mail-dub.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13758 for ; Fri, 18 Oct 2002 21:09:23 -0400 (EDT) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 19 Oct 2002 02:11:34 +0100 Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 19 Oct 2002 02:11:34 +0100 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 19 Oct 2002 02:11:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Speechsc] Protocol Analysis Document Date: Sat, 19 Oct 2002 02:11:34 +0100 Message-ID: <9584A4A864BD8548932F2F88EB30D1C6087F31F9@tvp-msg-01.europe.corp.microsoft.com> Thread-Topic: [Speechsc] Protocol Analysis Document Thread-Index: AcJ3BoOiCNP162qMQs6M31cPxykJwgAA9i2A From: "Stephen Potter" To: , Cc: , , "IETF SPEECHSC" X-OriginalArrivalTime: 19 Oct 2002 01:11:33.0856 (UTC) FILETIME=[76F02E00:01C2770C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9J1Biv21792 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 SRGS and SSML are not VoiceXML components. They may be used by VoiceXML interpreters, but they are not part of VoiceXML per se. (SRGS and SSML are also used by SALT interpreters, for example, along with XML result formats such as NLSML). I think this is an important point. The updated requirements document (rightly) has a broad scope for a variety of speech service scenarios and architectures, which go beyond VoiceXML and telephony. So it is in this context that I think we should be considering the following 'payload' features in terms of all the major scenarios (e.g. telephony/small-device/multimodal, VoiceXML/SALT/...): - SRGS - SSML - recognition results - all speech i/o events - all speech service configuration properties and ensure that we are targeting the right requirements and use cases. Please let me know if there is an action item I can help with here. Stephen > -----Original Message----- > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > Sent: Friday, October 18, 2002 5:28 PM > To: stephane.maes@oracle.com > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF SPEECHSC' > Subject: Re: [Speechsc] Protocol Analysis Document > > > Stephane, > > Here VXML I referred are speech grammars, speech markup for TTS, and > VXML properties that will change speech server behaviors. Apprently > a speech server is a consumer of them. More precisely, they are some > VoiceXML components (SRG, SSML, event returns, and VXML Properties) > will interact with a speech server. Unless there is a translation > layer to insulate entire VXML from a speech server. Which I'd like > to avoid due to inefficiency. > > I agree the VXML interpreter per se, it is a several layer high up. > But the above components will be up/down from/to the server. If you > have a different model in mind, please let me know. > > -- Qiru > > "Stephane H. Maes" wrote: > > > > Qiru, > > > > A priori, I would expect that VXML is fundamentally at a > different level > > (up to a few tags). > > > > Stephane > > > > _____ > > Stephane H. Maes, PhD, > > Director of Architecture - Mobile, Oracle Corporation. > > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > > e-mail: stephane.maes@oracle.com > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > > > -----Original Message----- > > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org] On Behalf > > Of Qiru Zhou > > > Sent: Friday, October 18, 2002 7:46 PM > > To: brian.wyld@eloquant.com > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > Brian, > > > > I am wondering where the VoiceXML interface is covered in the list. > > There was an obsoleted draft > "draft-rosenberg-sip-vxml-01.txt" related > > VoiceXML to SIP. It was deleted from IETF site. I am > interested in this > > since I am working with W3C VoiceXML WG as well. > > > > -- Qiru > > > > Brian Wyld wrote: > > ? > > ? Hi Qiru, > > ? > > ? Well, the assignation list was: > > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > > ? ? SIP : Brian Marquette, Jiten Goel > > ? ? Web Services : Stephane Maes > > ? ? MRCP draft : Sarvi Shanmugham > > ? ? BEEP : Brian Eberman > > ? > > ? Rajiv indicated he's still a 'go', but so far I haven't > had commitment > > > > ? from the others. > > ? > > ? If you have a particular protocol in mind, let me know > and I'll ask > > ? the current contributor to decide if they can do it or > not rapidly.... > > ? > > ? 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] > > ? > _______________________________________________ > 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 Oct 18 21:23:17 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 VAA13934 for ; Fri, 18 Oct 2002 21:23:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9J1P6P22061 for speechsc-archive@odin.ietf.org; Fri, 18 Oct 2002 21:25:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J1P6v22057 for ; Fri, 18 Oct 2002 21:25:06 -0400 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 VAA13931 for ; Fri, 18 Oct 2002 21:22:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J1P2v22047; Fri, 18 Oct 2002 21:25:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9J1O4v22026 for ; Fri, 18 Oct 2002 21:24:04 -0400 Received: from inet-mail4.oracle.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13928 for ; Fri, 18 Oct 2002 21:21:44 -0400 (EDT) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9J1NtO18439 for ; Fri, 18 Oct 2002 18:23:55 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9J1Nrk18421; Fri, 18 Oct 2002 18:23:53 -0700 (PDT) Received: from BRUSSELS ([144.25.233.79]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9J1NnO00790; Fri, 18 Oct 2002 19:23:49 -0600 (MDT) Reply-To: From: "Stephane H. Maes" To: "'Stephen Potter'" , Cc: , , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Protocol Analysis Document Date: Fri, 18 Oct 2002 21:23:37 -0400 Organization: Oracle Message-ID: <007c01c2770e$2ae4cb40$901f2382@watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6087F31F9@tvp-msg-01.europe.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 That is different from VXML on SIP etc... Carrying elements needed to control and program engines that are part of the W3C Voice activity work and used by VXML is of course the direction that we want to take. How we encapulate that (e.g. SRTP messages, versus SIP messages versus Web service wrapper etc..) is what we have to determine and hence the object of the present exercise. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org] On Behalf Of Stephen Potter Sent: Friday, October 18, 2002 9:12 PM To: qzhou@research.bell-labs.com; stephane.maes@oracle.com Cc: brian.wyld@eloquant.com; eburger@snowshore.com; IETF SPEECHSC Subject: RE: [Speechsc] Protocol Analysis Document SRGS and SSML are not VoiceXML components. They may be used by VoiceXML interpreters, but they are not part of VoiceXML per se. (SRGS and SSML are also used by SALT interpreters, for example, along with XML result formats such as NLSML). I think this is an important point. The updated requirements document (rightly) has a broad scope for a variety of speech service scenarios and architectures, which go beyond VoiceXML and telephony. So it is in this context that I think we should be considering the following 'payload' features in terms of all the major scenarios (e.g. telephony/small-device/multimodal, VoiceXML/SALT/...): - SRGS - SSML - recognition results - all speech i/o events - all speech service configuration properties and ensure that we are targeting the right requirements and use cases. Please let me know if there is an action item I can help with here. Stephen > -----Original Message----- > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > Sent: Friday, October 18, 2002 5:28 PM > To: stephane.maes@oracle.com > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF SPEECHSC' > Subject: Re: [Speechsc] Protocol Analysis Document > > > Stephane, > > Here VXML I referred are speech grammars, speech markup for TTS, and > VXML properties that will change speech server behaviors. Apprently a > speech server is a consumer of them. More precisely, they are some > VoiceXML components (SRG, SSML, event returns, and VXML Properties) > will interact with a speech server. Unless there is a translation > layer to insulate entire VXML from a speech server. Which I'd like to > avoid due to inefficiency. > > I agree the VXML interpreter per se, it is a several layer high up. > But the above components will be up/down from/to the server. If you > have a different model in mind, please let me know. > > -- Qiru > > "Stephane H. Maes" wrote: > > > > Qiru, > > > > A priori, I would expect that VXML is fundamentally at a > different level > > (up to a few tags). > > > > Stephane > > > > _____ > > Stephane H. Maes, PhD, > > Director of Architecture - Mobile, Oracle Corporation. > > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > > e-mail: stephane.maes@oracle.com > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > > > -----Original Message----- > > From: speechsc-admin@ietf.org > [mailto:speechsc-admin@ietf.org] On Behalf > > Of Qiru Zhou > > > Sent: Friday, October 18, 2002 7:46 PM > > To: brian.wyld@eloquant.com > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > Brian, > > > > I am wondering where the VoiceXML interface is covered in the list. > > There was an obsoleted draft > "draft-rosenberg-sip-vxml-01.txt" related > > VoiceXML to SIP. It was deleted from IETF site. I am > interested in this > > since I am working with W3C VoiceXML WG as well. > > > > -- Qiru > > > > Brian Wyld wrote: > > ? > > ? Hi Qiru, > > ? > > ? Well, the assignation list was: > > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > > ? ? SIP : Brian Marquette, Jiten Goel > > ? ? Web Services : Stephane Maes > > ? ? MRCP draft : Sarvi Shanmugham > > ? ? BEEP : Brian Eberman > > ? > > ? Rajiv indicated he's still a 'go', but so far I haven't > had commitment > > > > ? from the others. > > ? > > ? If you have a particular protocol in mind, let me know > and I'll ask > > ? the current contributor to decide if they can do it or > not rapidly.... > > ? > > ? 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] > > ? > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Oct 21 16:38:37 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 QAA14646 for ; Mon, 21 Oct 2002 16:38:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9LKeSt22487 for speechsc-archive@odin.ietf.org; Mon, 21 Oct 2002 16:40:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKeRv22484 for ; Mon, 21 Oct 2002 16:40:28 -0400 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 QAA14630 for ; Mon, 21 Oct 2002 16:38:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKeDv22442; Mon, 21 Oct 2002 16:40:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LKbdv22255 for ; Mon, 21 Oct 2002 16:37:39 -0400 Received: from flyingfox.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14461 for ; Mon, 21 Oct 2002 16:35:16 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g9LKbKB27647; Mon, 21 Oct 2002 16:37:20 -0400 (EDT) Reply-To: From: "Eric Burger" To: "Stephen Potter" , , Cc: , "IETF SPEECHSC" Subject: RE: [Speechsc] Protocol Analysis Document Date: Mon, 21 Oct 2002 16:37:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6087F31F9@tvp-msg-01.europe.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 requirements document definitely requires SSML for TTS. SRGS makes sense for ASR, too. As Stephen points out, we said this to *support* VoiceXML, SALT, etc. However, VoiceXML, SALT et. al. are things that *use* SpeechSC, not *are* SpeechSC. > -----Original Message----- > From: Stephen Potter [mailto:spotter@microsoft.com] > Sent: Friday, October 18, 2002 9:12 PM > To: qzhou@research.bell-labs.com; stephane.maes@oracle.com > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; IETF SPEECHSC > Subject: RE: [Speechsc] Protocol Analysis Document > > > SRGS and SSML are not VoiceXML components. They may be used by VoiceXML > interpreters, but they are not part of VoiceXML per se. (SRGS and SSML > are also used by SALT interpreters, for example, along with XML result > formats such as NLSML). > > I think this is an important point. The updated requirements document > (rightly) has a broad scope for a variety of speech service scenarios > and architectures, which go beyond VoiceXML and telephony. So it is in > this context that I think we should be considering the following > 'payload' features in terms of all the major scenarios (e.g. > telephony/small-device/multimodal, VoiceXML/SALT/...): > > - SRGS > - SSML > - recognition results > - all speech i/o events > - all speech service configuration properties > > and ensure that we are targeting the right requirements and use cases. > > Please let me know if there is an action item I can help with here. > > Stephen > > > > > -----Original Message----- > > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > > Sent: Friday, October 18, 2002 5:28 PM > > To: stephane.maes@oracle.com > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF SPEECHSC' > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > Stephane, > > > > Here VXML I referred are speech grammars, speech markup for TTS, and > > VXML properties that will change speech server behaviors. Apprently > > a speech server is a consumer of them. More precisely, they are some > > VoiceXML components (SRG, SSML, event returns, and VXML Properties) > > will interact with a speech server. Unless there is a translation > > layer to insulate entire VXML from a speech server. Which I'd like > > to avoid due to inefficiency. > > > > I agree the VXML interpreter per se, it is a several layer high up. > > But the above components will be up/down from/to the server. If you > > have a different model in mind, please let me know. > > > > -- Qiru > > > > "Stephane H. Maes" wrote: > > > > > > Qiru, > > > > > > A priori, I would expect that VXML is fundamentally at a > > different level > > > (up to a few tags). > > > > > > Stephane > > > > > > _____ > > > Stephane H. Maes, PhD, > > > Director of Architecture - Mobile, Oracle Corporation. > > > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > > > e-mail: stephane.maes@oracle.com > > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > > > > > > -----Original Message----- > > > From: speechsc-admin@ietf.org > > [mailto:speechsc-admin@ietf.org] On Behalf > > > Of Qiru Zhou > > > > > Sent: Friday, October 18, 2002 7:46 PM > > > To: brian.wyld@eloquant.com > > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > Brian, > > > > > > I am wondering where the VoiceXML interface is covered in the list. > > > There was an obsoleted draft > > "draft-rosenberg-sip-vxml-01.txt" related > > > VoiceXML to SIP. It was deleted from IETF site. I am > > interested in this > > > since I am working with W3C VoiceXML WG as well. > > > > > > -- Qiru > > > > > > Brian Wyld wrote: > > > ? > > > ? Hi Qiru, > > > ? > > > ? Well, the assignation list was: > > > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > > > ? ? SIP : Brian Marquette, Jiten Goel > > > ? ? Web Services : Stephane Maes > > > ? ? MRCP draft : Sarvi Shanmugham > > > ? ? BEEP : Brian Eberman > > > ? > > > ? Rajiv indicated he's still a 'go', but so far I haven't > > had commitment > > > > > > ? from the others. > > > ? > > > ? If you have a particular protocol in mind, let me know > > and I'll ask > > > ? the current contributor to decide if they can do it or > > not rapidly.... > > > ? > > > ? 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] > > > ? > > _______________________________________________ > > 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 Oct 25 12:09:04 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 MAA00055 for ; Fri, 25 Oct 2002 12:09:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PGAuZ13954 for speechsc-archive@odin.ietf.org; Fri, 25 Oct 2002 12:10:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGAtv13951 for ; Fri, 25 Oct 2002 12:10:55 -0400 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 MAA00043 for ; Fri, 25 Oct 2002 12:08:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PGAlv13911; Fri, 25 Oct 2002 12:10:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PG26v12532 for ; Fri, 25 Oct 2002 12:02:06 -0400 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 LAA29656 for ; Fri, 25 Oct 2002 11:59:44 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g9PG1wLI096810; Fri, 25 Oct 2002 12:01:58 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g9PG1qa31164; Fri, 25 Oct 2002 12:01:52 -0400 (EDT) Received: from research.bell-labs.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id MAA3480586; Fri, 25 Oct 2002 12:01:51 -0400 (EDT) Message-ID: <3DB96AEF.F72D698A@research.bell-labs.com> Date: Fri, 25 Oct 2002 12:01:51 -0400 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: eburger@snowshore.com CC: Stephen Potter , stephane.maes@oracle.com, brian.wyld@eloquant.com, IETF SPEECHSC Subject: Re: [Speechsc] Protocol Analysis Document References: 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 This is what I mean in previous messages (sorry if I didn't spell out clearly). The question is what level of VoiceXML or some other language (for example, SALT) functional support that SPEECHSC will provide. I never mean that SPEECHSC should *be*VXML. But I'd like to find out that how many VXML required functions that SPEECHSC can support and what it can not support. The reason I ask for VXML but not others is because it is emerging to be the application language of telco applications. -- Qiru Eric Burger wrote: > > The requirements document definitely requires SSML for TTS. SRGS makes > sense for ASR, too. > > As Stephen points out, we said this to *support* VoiceXML, SALT, etc. > However, VoiceXML, SALT et. al. are things that *use* SpeechSC, not *are* > SpeechSC. > > > -----Original Message----- > > From: Stephen Potter [mailto:spotter@microsoft.com] > > Sent: Friday, October 18, 2002 9:12 PM > > To: qzhou@research.bell-labs.com; stephane.maes@oracle.com > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; IETF SPEECHSC > > Subject: RE: [Speechsc] Protocol Analysis Document > > > > > > SRGS and SSML are not VoiceXML components. They may be used by VoiceXML > > interpreters, but they are not part of VoiceXML per se. (SRGS and SSML > > are also used by SALT interpreters, for example, along with XML result > > formats such as NLSML). > > > > I think this is an important point. The updated requirements document > > (rightly) has a broad scope for a variety of speech service scenarios > > and architectures, which go beyond VoiceXML and telephony. So it is in > > this context that I think we should be considering the following > > 'payload' features in terms of all the major scenarios (e.g. > > telephony/small-device/multimodal, VoiceXML/SALT/...): > > > > - SRGS > > - SSML > > - recognition results > > - all speech i/o events > > - all speech service configuration properties > > > > and ensure that we are targeting the right requirements and use cases. > > > > Please let me know if there is an action item I can help with here. > > > > Stephen > > > > > > > > > -----Original Message----- > > > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > > > Sent: Friday, October 18, 2002 5:28 PM > > > To: stephane.maes@oracle.com > > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF SPEECHSC' > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > > > > Stephane, > > > > > > Here VXML I referred are speech grammars, speech markup for TTS, and > > > VXML properties that will change speech server behaviors. Apprently > > > a speech server is a consumer of them. More precisely, they are some > > > VoiceXML components (SRG, SSML, event returns, and VXML Properties) > > > will interact with a speech server. Unless there is a translation > > > layer to insulate entire VXML from a speech server. Which I'd like > > > to avoid due to inefficiency. > > > > > > I agree the VXML interpreter per se, it is a several layer high up. > > > But the above components will be up/down from/to the server. If you > > > have a different model in mind, please let me know. > > > > > > -- Qiru > > > > > > "Stephane H. Maes" wrote: > > > > > > > > Qiru, > > > > > > > > A priori, I would expect that VXML is fundamentally at a > > > different level > > > > (up to a few tags). > > > > > > > > Stephane > > > > > > > > _____ > > > > Stephane H. Maes, PhD, > > > > Director of Architecture - Mobile, Oracle Corporation. > > > > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > > > > e-mail: stephane.maes@oracle.com > > > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > > > > > > > > > -----Original Message----- > > > > From: speechsc-admin@ietf.org > > > [mailto:speechsc-admin@ietf.org] On Behalf > > > > Of Qiru Zhou > > > > > > > Sent: Friday, October 18, 2002 7:46 PM > > > > To: brian.wyld@eloquant.com > > > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > > > Brian, > > > > > > > > I am wondering where the VoiceXML interface is covered in the list. > > > > There was an obsoleted draft > > > "draft-rosenberg-sip-vxml-01.txt" related > > > > VoiceXML to SIP. It was deleted from IETF site. I am > > > interested in this > > > > since I am working with W3C VoiceXML WG as well. > > > > > > > > -- Qiru > > > > > > > > Brian Wyld wrote: > > > > ? > > > > ? Hi Qiru, > > > > ? > > > > ? Well, the assignation list was: > > > > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > > > > ? ? SIP : Brian Marquette, Jiten Goel > > > > ? ? Web Services : Stephane Maes > > > > ? ? MRCP draft : Sarvi Shanmugham > > > > ? ? BEEP : Brian Eberman > > > > ? > > > > ? Rajiv indicated he's still a 'go', but so far I haven't > > > had commitment > > > > > > > > ? from the others. > > > > ? > > > > ? If you have a particular protocol in mind, let me know > > > and I'll ask > > > > ? the current contributor to decide if they can do it or > > > not rapidly.... > > > > ? > > > > ? 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] > > > > ? > > > _______________________________________________ > > > 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 Oct 25 13:30:31 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 NAA03399 for ; Fri, 25 Oct 2002 13:30:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PHWOD18462 for speechsc-archive@odin.ietf.org; Fri, 25 Oct 2002 13:32:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PHWNv18459 for ; Fri, 25 Oct 2002 13:32:23 -0400 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 NAA03381 for ; Fri, 25 Oct 2002 13:29:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PHWHv18450; Fri, 25 Oct 2002 13:32:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PHVSv18427 for ; Fri, 25 Oct 2002 13:31:28 -0400 Received: from mail2.intervoice-brite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03352 for ; Fri, 25 Oct 2002 13:29:02 -0400 (EDT) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44] (may be forged)) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id MAA01881 for ; Fri, 25 Oct 2002 12:42:58 -0500 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Fri, 25 Oct 2002 12:21:43 -0500 Received: from INTERVOICE-Message_Server by 172.16.16.64 with Novell_GroupWise; Fri, 25 Oct 2002 12:31:17 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 25 Oct 2002 12:30:53 -0500 From: "Skip Cave" To: Cc: , , , , Subject: Re: [Speechsc] Protocol Analysis Document Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_663AEFF5.A6C79F10" 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 MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_663AEFF5.A6C79F10 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I believe that the assumption is, that SpeechSC will support ALL of the = functionality defined in the VoiceXML spec, or at least all of the = VoiceXML functionality that has to do wth ASR, TTS, and verification. For = that matter, SpeechSC should also support all of the functionality defined = in the SALT spec. as well. Otherwise, the rationale for SpeechSC is = flawed.=20 After all, one of the primary reasons for SpeechSC, is to allow VoiceXML = and SALT browser systems to control ASR & TTS resources remotely over a = network. If SpeechSC does NOT allow VoiceXML & SALT browsers to control = these ASR & TTS resources to the full capabilities of the script languages,= the SpeechSC mission has failed.=20 Perhaps this ought to be spelled out in the spec... Skip =20 >>> Qiru Zhou 10/25/02 11:01AM >>> This is what I mean in previous messages (sorry if I didn't spell out clearly). The question is what level of VoiceXML or some other language (for example, SALT) functional support that SPEECHSC will provide. I never mean that SPEECHSC should *be*VXML. But I'd like to find out that how many VXML required functions that SPEECHSC can support and what it can not support. The reason I ask for VXML but not others is because it is = emerging to be the application language of telco applications. -- Qiru Eric Burger wrote: >=20 > The requirements document definitely requires SSML for TTS. SRGS makes > sense for ASR, too. >=20 > As Stephen points out, we said this to *support* VoiceXML, SALT, etc. > However, VoiceXML, SALT et. al. are things that *use* SpeechSC, not = *are* > SpeechSC. >=20 > > -----Original Message----- > > From: Stephen Potter [mailto:spotter@microsoft.com] > > Sent: Friday, October 18, 2002 9:12 PM > > To: qzhou@research.bell-labs.com; stephane.maes@oracle.com > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; IETF SPEECHSC > > Subject: RE: [Speechsc] Protocol Analysis Document > > > > > > SRGS and SSML are not VoiceXML components. They may be used by = VoiceXML > > interpreters, but they are not part of VoiceXML per se. (SRGS and SSML > > are also used by SALT interpreters, for example, along with XML result > > formats such as NLSML). > > > > I think this is an important point. The updated requirements document > > (rightly) has a broad scope for a variety of speech service scenarios > > and architectures, which go beyond VoiceXML and telephony. So it is in > > this context that I think we should be considering the following > > 'payload' features in terms of all the major scenarios (e.g. > > telephony/small-device/multimodal, VoiceXML/SALT/...): > > > > - SRGS > > - SSML > > - recognition results > > - all speech i/o events > > - all speech service configuration properties > > > > and ensure that we are targeting the right requirements and use cases. > > > > Please let me know if there is an action item I can help with here. > > > > Stephen > > > > > > > > > -----Original Message----- > > > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > > > Sent: Friday, October 18, 2002 5:28 PM > > > To: stephane.maes@oracle.com > > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF SPEECHSC' > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > > > > Stephane, > > > > > > Here VXML I referred are speech grammars, speech markup for TTS, and > > > VXML properties that will change speech server behaviors. Apprently > > > a speech server is a consumer of them. More precisely, they are some > > > VoiceXML components (SRG, SSML, event returns, and VXML Properties) > > > will interact with a speech server. Unless there is a translation > > > layer to insulate entire VXML from a speech server. Which I'd like > > > to avoid due to inefficiency. > > > > > > I agree the VXML interpreter per se, it is a several layer high up. > > > But the above components will be up/down from/to the server. If you > > > have a different model in mind, please let me know. > > > > > > -- Qiru > > > > > > "Stephane H. Maes" wrote: > > > > > > > > Qiru, > > > > > > > > A priori, I would expect that VXML is fundamentally at a > > > different level > > > > (up to a few tags). > > > > > > > > Stephane > > > > > > > > _____ > > > > Stephane H. Maes, PhD, > > > > Director of Architecture - Mobile, Oracle Corporation. > > > > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > > > > e-mail: stephane.maes@oracle.com > > > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > > > > > > > > > -----Original Message----- > > > > From: speechsc-admin@ietf.org > > > [mailto:speechsc-admin@ietf.org] On Behalf > > > > Of Qiru Zhou > > > > > > > Sent: Friday, October 18, 2002 7:46 PM > > > > To: brian.wyld@eloquant.com > > > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > > > Brian, > > > > > > > > I am wondering where the VoiceXML interface is covered in the = list. > > > > There was an obsoleted draft > > > "draft-rosenberg-sip-vxml-01.txt" related > > > > VoiceXML to SIP. It was deleted from IETF site. I am > > > interested in this > > > > since I am working with W3C VoiceXML WG as well. > > > > > > > > -- Qiru > > > > > > > > Brian Wyld wrote: > > > > ? > > > > ? Hi Qiru, > > > > ? > > > > ? Well, the assignation list was: > > > > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > > > > ? ? SIP : Brian Marquette, Jiten Goel > > > > ? ? Web Services : Stephane Maes > > > > ? ? MRCP draft : Sarvi Shanmugham > > > > ? ? BEEP : Brian Eberman > > > > ? > > > > ? Rajiv indicated he's still a 'go', but so far I haven't > > > had commitment > > > > > > > > ? from the others. > > > > ? > > > > ? If you have a particular protocol in mind, let me know > > > and I'll ask > > > > ? the current contributor to decide if they can do it or > > > not rapidly.... > > > > ? > > > > ? 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] > > > > ? > > > _______________________________________________ > > > 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 --=_663AEFF5.A6C79F10 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
I believe that the assumption is, that SpeechSC will = support=20 ALL of the functionality defined in the VoiceXML spec, or at least all of = the=20 VoiceXML functionality that has to do wth ASR, TTS, and verification. For = that=20 matter, SpeechSC should also support all of the functionality defined in = the=20 SALT spec. as well. Otherwise, the rationale for SpeechSC is flawed.=20
 
After all, one of the primary reasons for SpeechSC, is = to=20 allow VoiceXML and SALT browser systems to control ASR & TTS = resources=20 remotely over a network. If SpeechSC does NOT allow VoiceXML & SALT = browsers=20 to control these ASR & TTS resources to the full capabilities of the = script=20 languages, the SpeechSC mission has failed.
 
Perhaps this ought to be spelled out in the=20 spec...
 
Skip  

>>> Qiru Zhou=20 <qzhou@research.bell-labs.com> 10/25/02 11:01AM >>>
This = is=20 what I mean in previous messages (sorry if I didn't spell out
clearly). = The=20 question is what level of VoiceXML or some other language
(for example, = SALT)=20 functional support that SPEECHSC will provide. I
never mean that = SPEECHSC=20 should *be*VXML. But I'd like to find out that
how many VXML required=20= functions that SPEECHSC can support and what it can
not support. The = reason I=20 ask for VXML but not others is because it is emerging to be the application= =20 language of telco
applications.

-- Qiru

Eric Burger=20 wrote:
>
> The requirements document definitely requires SSML = for=20 TTS.  SRGS makes
> sense for ASR, too.
>
> As = Stephen=20 points out, we said this to *support* VoiceXML, SALT, etc.
> = However,=20 VoiceXML, SALT et. al. are things that *use* SpeechSC, not *are*
>=20= SpeechSC.
>
> > -----Original Message-----
> > = From:=20 Stephen Potter [mailto:spotter@microsoft.com]>=20 > Sent: Friday, October 18, 2002 9:12 PM
> > To:=20 qzhou@research.bell-labs.com; stephane.maes@oracle.com
> > Cc:=20 brian.wyld@eloquant.com; eburger@snowshore.com; IETF SPEECHSC
> = >=20 Subject: RE: [Speechsc] Protocol Analysis Document
> >
>=20 >
> > SRGS and SSML are not VoiceXML components. They may be = used by=20 VoiceXML
> > interpreters, but they are not part of VoiceXML per = se.=20 (SRGS and SSML
> > are also used by SALT interpreters, for = example,=20 along with XML result
> > formats such as NLSML).
> = >
>=20 > I think this is an important point. The updated requirements=20 document
> > (rightly) has a broad scope for a variety of = speech=20 service scenarios
> > and architectures, which go beyond VoiceXML = and=20 telephony. So it is in
> > this context that I think we should = be=20 considering the following
> > 'payload' features in terms of all = the=20 major scenarios (e.g.
> > telephony/small-device/multimodal,=20 VoiceXML/SALT/...):
> >
> > - SRGS
> > - = SSML
>=20 > - recognition results
> > - all speech i/o events
> = > -=20 all speech service configuration properties
> >
> > and = ensure=20 that we are targeting the right requirements and use cases.
> = >
>=20 > Please let me know if there is an action item I can help with = here.
>=20 >
> > Stephen
> >
> >
> >
> = >=20 > -----Original Message-----
> > > From: Qiru Zhou [mailto:qzhou@research.bell-la= bs.com]
>=20 > > Sent: Friday, October 18, 2002 5:28 PM
> > > To:=20 stephane.maes@oracle.com
> > > Cc: brian.wyld@eloquant.com;=20 eburger@snowshore.com; 'IETF SPEECHSC'
> > > Subject: Re: = [Speechsc]=20 Protocol Analysis Document
> > >
> > >
> = > >=20 Stephane,
> > >
> > > Here VXML I referred are = speech=20 grammars, speech markup for TTS, and
> > > VXML properties = that will=20 change speech server behaviors. Apprently
> > > a speech = server is a=20 consumer of them. More precisely, they are some
> > > = VoiceXML=20 components (SRG, SSML, event returns, and VXML Properties)
> > = >=20 will interact with a speech server. Unless there is a translation
> = >=20 > layer to insulate entire VXML from a speech server. Which I'd = like
>=20 > > to avoid due to inefficiency.
> > >
> > = > I=20 agree the VXML interpreter per se, it is a several layer high up.
> = >=20 > But the above components will be up/down from/to the server. If = you
>=20 > > have a different model in mind, please let me know.
> = >=20 >
> > > -- Qiru
> > >
> > > = "Stephane H.=20 Maes" wrote:
> > > >
> > > > Qiru,
> = >=20 > >
> > > > A priori, I would expect that VXML is=20 fundamentally at a
> > > different level
> > > = > (up=20 to a few tags).
> > > >
> > > > Stephane
&= gt;=20 > > >
> > > > _____
> > > > = Stephane H.=20 Maes, PhD,
> > > > Director of Architecture - Mobile, = Oracle=20 Corporation.
> > > > Ph: +1-203-300-7786 (mobile); Fax:=20 +1-203-798-6948.
> > > > e-mail: stephane.maes@oracle.com>=20 > > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN=20 Messenger)
> > > >
> > > >
> > > = >=20 -----Original Message-----
> > > > From:=20 speechsc-admin@ietf.org
> > > [mailto:speechsc-admin@ietf.org] On=20 Behalf
> > > > Of Qiru Zhou
> > > >
> = >=20 > Sent: Friday, October 18, 2002 7:46 PM
> > > > To:=20 brian.wyld@eloquant.com
> > > > Cc: eburger@snowshore.com; = 'IETF=20 SPEECHSC'
> > > > Subject: Re: [Speechsc] Protocol = Analysis=20 Document
> > > >
> > > > Brian,
> > = >=20 >
> > > > I am wondering where the VoiceXML interface = is=20 covered in the list.
> > > > There was an obsoleted = draft
>=20 > > "draft-rosenberg-sip-vxml-01.txt" related
> > > = >=20 VoiceXML to SIP. It was deleted from IETF site. I am
> > >=20 interested in this
> > > > since I am working with W3C = VoiceXML=20 WG as well.
> > > >
> > > > -- Qiru
> = >=20 > >
> > > > Brian Wyld wrote:
> > > = >=20 ?
> > > > ? Hi Qiru,
> > > > ?
> > = >=20 > ? Well, the assignation list was:
> > > > ? ? RTSP : = Jiten=20 Goel, Rajiv Dharmadhikari
> > > > ? ? SIP : Brian Marquette,= =20 Jiten Goel
> > > > ? ? Web Services : Stephane Maes
> = >=20 > > ? ? MRCP draft : Sarvi Shanmugham
> > > > ? ? = BEEP :=20 Brian Eberman
> > > > ?
> > > > ? Rajiv = indicated=20 he's still a 'go', but so far I haven't
> > > had commitment>=20 > > >
> > > > ? from the others.
> > > = >=20 ?
> > > > ? If you have a particular protocol in mind, let = me=20 know
> > > and I'll ask
> > > > ? the current=20= contributor to decide if they can do it or
> > > not=20 rapidly....
> > > > ?
> > > > ? thanks
>= ;=20 > > > ?
> > > > ? Brian
> > > > = ?
>=20 > > > ? [Brian Wyld] [brian.wyld@eloquant.com]
> > > = > ?=20 [Directeur General R?D]
> > > > ? [Eloquant SA] [+33 476 77 = 46=20 92] [www.eloquant.com]
> > > > ? [advanced solutions for = telecoms=20 and IT services]
> > > > ?
> > >=20 _______________________________________________
> > > = Speechsc=20 mailing list
> > > Speechsc@ietf.org
> > > https://www1.ietf.= org/mailman/listinfo/speechsc
>=20 > >
_______________________________________________
Speechsc = mailing=20 list
Speechsc@ietf.org
https://www1.ietf.= org/mailman/listinfo/speechsc
--=_663AEFF5.A6C79F10-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Fri Oct 25 14:25: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 OAA05616 for ; Fri, 25 Oct 2002 14:25:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9PIRBg21603 for speechsc-archive@odin.ietf.org; Fri, 25 Oct 2002 14:27:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PIRBv21600 for ; Fri, 25 Oct 2002 14:27:11 -0400 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 OAA05571 for ; Fri, 25 Oct 2002 14:24:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PIR5v21592; Fri, 25 Oct 2002 14:27:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PIQJv21560 for ; Fri, 25 Oct 2002 14:26:19 -0400 Received: from inet-mail3.oracle.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05525 for ; Fri, 25 Oct 2002 14:23:54 -0400 (EDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PIQCU06621 for ; Fri, 25 Oct 2002 11:26:12 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PIQBI06608; Fri, 25 Oct 2002 11:26:11 -0700 (PDT) Received: from BRUSSELS (dhcp-amer-vpn-rmdc-gw1-east-141-144-105-184.vpn.oracle.com [141.144.105.184]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PIQAZ27051; Fri, 25 Oct 2002 12:26:10 -0600 (MDT) Reply-To: From: "Stephane H. Maes" To: , "'IETF SPEECHSC'" Subject: RE: [Speechsc] Protocol Analysis Document Date: Fri, 25 Oct 2002 14:26:04 -0400 Organization: Oracle Message-ID: <00e701c27c53$fa90ab30$94fea8c0@watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3DB96AEF.F72D698A@research.bell-labs.com> 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 Qiru, Sorry I still do not understand this. I would expect that a VoiceXML browser) or other would controle remote engines though SPEECHSc and would not convey ANY VoiceXML syntax. It may exchange data files and results in format also used by W3C.For consistency, some of the SPEECHSC syntax may be similar to VoiceXML. But that should be all. Isn't it? Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. e-mail: stephane.maes@oracle.com IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] Sent: Friday, October 25, 2002 12:02 PM To: eburger@snowshore.com Cc: Stephen Potter; stephane.maes@oracle.com; brian.wyld@eloquant.com; IETF SPEECHSC Subject: Re: [Speechsc] Protocol Analysis Document This is what I mean in previous messages (sorry if I didn't spell out clearly). The question is what level of VoiceXML or some other language (for example, SALT) functional support that SPEECHSC will provide. I never mean that SPEECHSC should *be*VXML. But I'd like to find out that how many VXML required functions that SPEECHSC can support and what it can not support. The reason I ask for VXML but not others is because it is emerging to be the application language of telco applications. -- Qiru Eric Burger wrote: > > The requirements document definitely requires SSML for TTS. SRGS > makes sense for ASR, too. > > As Stephen points out, we said this to *support* VoiceXML, SALT, etc. > However, VoiceXML, SALT et. al. are things that *use* SpeechSC, not > *are* SpeechSC. > > > -----Original Message----- > > From: Stephen Potter [mailto:spotter@microsoft.com] > > Sent: Friday, October 18, 2002 9:12 PM > > To: qzhou@research.bell-labs.com; stephane.maes@oracle.com > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; IETF SPEECHSC > > Subject: RE: [Speechsc] Protocol Analysis Document > > > > > > SRGS and SSML are not VoiceXML components. They may be used by > > VoiceXML interpreters, but they are not part of VoiceXML per se. > > (SRGS and SSML are also used by SALT interpreters, for example, > > along with XML result formats such as NLSML). > > > > I think this is an important point. The updated requirements > > document > > (rightly) has a broad scope for a variety of speech service scenarios > > and architectures, which go beyond VoiceXML and telephony. So it is in > > this context that I think we should be considering the following > > 'payload' features in terms of all the major scenarios (e.g. > > telephony/small-device/multimodal, VoiceXML/SALT/...): > > > > - SRGS > > - SSML > > - recognition results > > - all speech i/o events > > - all speech service configuration properties > > > > and ensure that we are targeting the right requirements and use > > cases. > > > > Please let me know if there is an action item I can help with here. > > > > Stephen > > > > > > > > > -----Original Message----- > > > From: Qiru Zhou [mailto:qzhou@research.bell-labs.com] > > > Sent: Friday, October 18, 2002 5:28 PM > > > To: stephane.maes@oracle.com > > > Cc: brian.wyld@eloquant.com; eburger@snowshore.com; 'IETF > > > SPEECHSC' > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > > > > Stephane, > > > > > > Here VXML I referred are speech grammars, speech markup for TTS, > > > and VXML properties that will change speech server behaviors. > > > Apprently a speech server is a consumer of them. More precisely, > > > they are some VoiceXML components (SRG, SSML, event returns, and > > > VXML Properties) will interact with a speech server. Unless there > > > is a translation layer to insulate entire VXML from a speech > > > server. Which I'd like to avoid due to inefficiency. > > > > > > I agree the VXML interpreter per se, it is a several layer high > > > up. But the above components will be up/down from/to the server. > > > If you have a different model in mind, please let me know. > > > > > > -- Qiru > > > > > > "Stephane H. Maes" wrote: > > > > > > > > Qiru, > > > > > > > > A priori, I would expect that VXML is fundamentally at a > > > different level > > > > (up to a few tags). > > > > > > > > Stephane > > > > > > > > _____ > > > > Stephane H. Maes, PhD, > > > > Director of Architecture - Mobile, Oracle Corporation. > > > > Ph: +1-203-300-7786 (mobile); Fax: +1-203-798-6948. > > > > e-mail: stephane.maes@oracle.com > > > > IM: shmaes (AIM) or stephane_maes@hotmail.com (MSN Messenger) > > > > > > > > > > > > -----Original Message----- > > > > From: speechsc-admin@ietf.org > > > [mailto:speechsc-admin@ietf.org] On Behalf > > > > Of Qiru Zhou > > > > > > > Sent: Friday, October 18, 2002 7:46 PM > > > > To: brian.wyld@eloquant.com > > > > Cc: eburger@snowshore.com; 'IETF SPEECHSC' > > > > Subject: Re: [Speechsc] Protocol Analysis Document > > > > > > > > Brian, > > > > > > > > I am wondering where the VoiceXML interface is covered in the > > > > list. There was an obsoleted draft > > > "draft-rosenberg-sip-vxml-01.txt" related > > > > VoiceXML to SIP. It was deleted from IETF site. I am > > > interested in this > > > > since I am working with W3C VoiceXML WG as well. > > > > > > > > -- Qiru > > > > > > > > Brian Wyld wrote: > > > > ? > > > > ? Hi Qiru, > > > > ? > > > > ? Well, the assignation list was: > > > > ? ? RTSP : Jiten Goel, Rajiv Dharmadhikari > > > > ? ? SIP : Brian Marquette, Jiten Goel > > > > ? ? Web Services : Stephane Maes > > > > ? ? MRCP draft : Sarvi Shanmugham > > > > ? ? BEEP : Brian Eberman > > > > ? > > > > ? Rajiv indicated he's still a 'go', but so far I haven't > > > had commitment > > > > > > > > ? from the others. > > > > ? > > > > ? If you have a particular protocol in mind, let me know > > > and I'll ask > > > > ? the current contributor to decide if they can do it or > > > not rapidly.... > > > > ? > > > > ? 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] > > > > ? > > > _______________________________________________ > > > 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 Mon Oct 28 06:33:25 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 GAA03859 for ; Mon, 28 Oct 2002 06:33:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SBZHb17040 for speechsc-archive@odin.ietf.org; Mon, 28 Oct 2002 06:35: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 g9SBZHv17037 for ; Mon, 28 Oct 2002 06:35: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 GAA03803 for ; Mon, 28 Oct 2002 06:32:54 -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 g9SBZ9v17002; Mon, 28 Oct 2002 06:35: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 g9SBVdv16728 for ; Mon, 28 Oct 2002 06:31:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03553; Mon, 28 Oct 2002 06:29:16 -0500 (EST) Message-Id: <200210281129.GAA03553@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: Mon, 28 Oct 2002 06:29:16 -0500 Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-02.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 : Requirements for Distributed Control of ASR, SI/SV and TTS Resources Author(s) : E. Burger, D. Oran Filename : draft-ietf-speechsc-reqts-02.txt Pages : 14 Date : 2002-10-25 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition, speaker recognition (which includes both speaker identification and speaker verification) and text-to-speech. Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. Discussion of this and related documents is on the speechsc mailing list. To subscribe, send the message 'subscribe speechsc' to speechsc-request@ietf.org. The public archive is at http://www.ietf.org/mail- archive/workinggroups/speechsc/current/maillist.html. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-02.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-reqts-02.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-reqts-02.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-10-25112821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-reqts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-reqts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25112821.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Oct 28 08:37:28 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 IAA08542 for ; Mon, 28 Oct 2002 08:37:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SDdKv23706 for speechsc-archive@odin.ietf.org; Mon, 28 Oct 2002 08:39:20 -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 g9SDdJv23703 for ; Mon, 28 Oct 2002 08:39: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 IAA08527 for ; Mon, 28 Oct 2002 08:36:53 -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 g9SDdAv23693; Mon, 28 Oct 2002 08:39:11 -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 g9RNZ8v08360 for ; Sun, 27 Oct 2002 18:35:08 -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 SAA11621; Sun, 27 Oct 2002 18:32:36 -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 g9RNYlH03052; Sun, 27 Oct 2002 23:34:47 GMT Received: from polo (atalante.hq.eloquant.com [192.168.0.11]) by weasel.hq.eloquant.com (Postfix) with SMTP id 0F5593B6CA; Sun, 27 Oct 2002 18:33:18 -0500 (EST) Reply-To: From: "Brian Wyld" To: Cc: , , "Brian Wyld (E-mail)" , "Speechsc (E-mail)" Date: Mon, 28 Oct 2002 00:33:18 +0100 Message-ID: <003501c27e11$3b6d5540$8300010a@hq.eloquant.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0036_01C27E19.9D31BD40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Speechsc] Updated version (v0.2) for speechsc WG Internet Draft submission 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_0036_01C27E19.9D31BD40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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] ------=_NextPart_000_0036_01C27E19.9D31BD40 Content-Type: text/plain; name="draft-speechsc-protocol-eval-v02.txt" Content-Disposition: attachment; filename="draft-speechsc-protocol-eval-v02.txt" Content-Transfer-Encoding: quoted-printable =0A= Internet Draft B. Wyld=20 Document: draft-speechsc-protocol-eval.txt Editor=20 Expires: April 2003 Eloquant=20 Version 0.2 October 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 SPEECHSC Protocol Evaluation Template October 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)19=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...................................26=20 10. References................................................27=20 =20 1. 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. 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 SPEECHSC Protocol Evaluation Template October 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. 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 SPEECHSC Protocol Evaluation Template October 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. 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 SPEECHSC Protocol Evaluation Template October 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 SPEECHSC Protocol Evaluation Template October 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. 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 SPEECHSC Protocol Evaluation Template October 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 SPEECHSC Protocol Evaluation Template October 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. 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 SPEECHSC Protocol Evaluation Template October 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 TBD=20 =0A= 5.2.6. Server Location and Load Balancing [5.6]=20 T: SIP employs standard DNS name resolution for locating resources=20 =20 =0A= 5.2.7. Simultaneous services [5.7]=20 T: SIP allows forking or splitting the same media stream to=20 different end 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 TBD=20 =0A= 5.3.2. Text Formats [6.2]=20 T: With proper definition, SIP message body can carry TTS text or=20 reference to the TTS 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 TBD=20 =0A= 5.3.6. Document Type Indication [6.2.4]=20 T:=20 =0A= 5.3.7. Control Channel [6.3]=20 TBD=20 =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 9] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 5.3.8. Playback Controls [6.4]=20 TBD=20 =0A= 5.3.9. Session Parameters [6.5]=20 TBD=20 =0A= 5.3.10. Speech Markers [6.6]=20 =20 TBD=20 =0A= 5.4. Analysis of ASR requirements=20 =0A= 5.4.1. Requesting Automatic Speech Recognition [7.1]=20 TBD=20 =0A= 5.4.2. XML [7.2]=20 TBD=20 =0A= 5.4.3. Grammar Specification [7.3.1]=20 T: 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 TBD=20 =0A= 5.4.5. Grammar Sharing [7.3.3]=20 TBD=20 =0A= 5.4.6. Session Parameters [7.4]=20 TBD=20 =0A= 5.4.7. Input Capture [7.5]=20 TBD=20 =20 =0A= 5.5. Analysis of Speaker Identification and Verification=20 Requirements=20 =0A= 5.5.1. Requesting SI/SV [8.1]=20 TBD=20 =0A= 5.5.2. Identifiers for SI/SV [8.2]=20 TBD=20 =0A= 5.5.3. State for multiple utterances [8.3]=20 TBD=20 =0A= 5.5.4. Input Capture [8.4]=20 TBD=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 =20 =20 Wyld Expires =96 April 2003 [Page 10] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =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 TBD=20 =0A= 5.6.3. Multiple services in parallel [9.1.2]=20 TBD=20 =0A= 5.6.4. Combination of services=20 TBD=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= 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= =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 11] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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. 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 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 =20 =20 Wyld Expires =96 April 2003 [Page 12] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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= 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= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 13] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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. 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 =0A= 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= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 14] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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. 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 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 =20 =20 Wyld Expires =96 April 2003 [Page 15] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =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= 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= =0A= =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 16] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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= 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 =20 =20 Wyld Expires =96 April 2003 [Page 17] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =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. 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 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= =20 =20 Wyld Expires =96 April 2003 [Page 18] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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= 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 =20 =20 Wyld Expires =96 April 2003 [Page 19] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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. 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 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 =20 Wyld Expires =96 April 2003 [Page 20] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =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 (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= =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 21] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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 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= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 22] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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= 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. 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 =20 =20 Wyld Expires =96 April 2003 [Page 23] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =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 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= =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 24] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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= 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 =20 =20 Wyld Expires =96 April 2003 [Page 25] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =20 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 9. 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 =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 26] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =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 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 =20 =20 Wyld Expires =96 April 2003 [Page 27] = =0C SPEECHSC Protocol Evaluation Template October 2002=20 =20 =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= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =20 =20 Wyld Expires =96 April 2003 [Page 28] = =0C ------=_NextPart_000_0036_01C27E19.9D31BD40-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Mon Oct 28 13:07: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 NAA21553 for ; Mon, 28 Oct 2002 13:07:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9SI9GW07654 for speechsc-archive@odin.ietf.org; Mon, 28 Oct 2002 13:09: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 g9SI9Gv07651 for ; Mon, 28 Oct 2002 13:09: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 NAA21545 for ; Mon, 28 Oct 2002 13:06:51 -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 g9SI98v07643; Mon, 28 Oct 2002 13:09:08 -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 g9SI4Yv06929 for ; Mon, 28 Oct 2002 13:04:34 -0500 Received: from mail4.genesyslab.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21366; Mon, 28 Oct 2002 13:02:04 -0500 (EST) Received: from atlant.genesyslab.com (atlant.genesyslab.com [192.168.20.153]) by mail4.genesyslab.com (8.11.1/8.11.1) with ESMTP id g9SHxa579104; Mon, 28 Oct 2002 09:59:36 -0800 (PST) (envelope-from rajiv@telera.com) Received: from boxter.genesyslab.com (localhost [127.0.0.1]) by atlant.genesyslab.com (8.11.4/8.11.4) with ESMTP id g9SHxaI23929; Mon, 28 Oct 2002 09:59:36 -0800 (PST) Received: from teleramail.telera.com ([10.10.10.23]) by boxter.genesyslab.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Oct 2002 09:59:35 -0800 Received: by mail.telera.com with Internet Mail Service (5.5.2653.19) id <4WYF9CN3>; Mon, 28 Oct 2002 09:59:34 -0800 Message-ID: <78993285C0CAD3118B42009027E505BC05F1C209@mail.telera.com> From: Rajiv Dharmadhikari To: "'brian.wyld@eloquant.com'" , internet-drafts@ietf.org Cc: eburger@alum.mit.edu, eburger@snowshore.com, "Speechsc (E-mail)" Subject: RE: [Speechsc] Updated version (v0.2) for speechsc WG Internet Dr aft submission protocol evaluation document Date: Mon, 28 Oct 2002 09:59:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Oct 2002 17:59:35.0447 (UTC) FILETIME=[C67E5270:01C27EAB] 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: , My updates from yesterday did not make in the v0.2 of the document. So, I am starting discussion thread with comments on my section :-). Here are the updates to the SIP section. 5.3. Analysis of TTS requirements 5.3.1. Requesting Text Playback [6.1] P+: SIP does not provide primitives for text playback. New SIP URI can be defined to invoke TTS features. 5.3.2. Text Formats [6.2] T: SIP message body can carry TTS text or reference to the TTS text. SIP message body will need to have a field to identify the document type. 5.3.3. Plain text [6.2.1] T: See 5.3.2. 5.3.4. SSML [6.2.2] T: See 5.3.2. 5.3.5. Text in Control Channel [6.2.3] T : See 5.3.2. 5.3.6. Document Type Indication [6.2.4] T: See 5.3.2. 5.3.7. Control Channel [6.3] T: Separate SIP URI can be defined for control channel. 5.3.8. Playback Controls [6.4] P+: See 5.3.1 5.3.9. Session Parameters [6.5] P+: Session parameters can be passed in body part of SIP or can be modified by using mid call methods of SIP. 5.3.10. Speech Markers [6.6] T: Speech markers can be delivered using a separate control channel. See 5.3.7. 5.4. Analysis of ASR requirements 5.4.1. Requesting Automatic Speech Recognition [7.1] T: New SIP URI can be defined to address ASR services and requesting ASR resources. 5.4.2. XML [7.2] T: SIP message body can carry XML. 5.4.3. Grammar Specification [7.3.1] P+: With proper definition, SIP message body can carry XML grammars or references to the XML grammars. 5.4.4. Explicit Indication of Grammar Format [7.3.2] P+: See 5.4.3. 5.4.5. Grammar Sharing [7.3.3] TBD 5.4.6. Session Parameters [7.4] T: Session parameters can be passed in body part of SIP or can be modified by using mid call methods of SIP. 5.4.7. Input Capture [7.5] T: SIP SUBSCRIBE/NOTIFY mechanism can be used initiate input capture and receive the result. 5.5. Analysis of Speaker Identification and Verification Requirements 5.5.1. Requesting SI/SV [8.1] T: New SIP URI can be defined for SI/SV. 5.5.2. Identifiers for SI/SV [8.2] T: See 5.5.1. 5.5.3. State for multiple utterances [8.3] TBD 5.5.4. Input Capture [8.4] T: SIP SUBSCRIBE/NOTIFY mechanism can be used initiate input capture and receive the result. 5.5.5. SI/SV functional extensibility [8.5] T: SIP can easily be extended by adding new methods and header fields without impacting the operation of existing methods. The new methods and headers will only be understood by the SPEECHSC entities. If above is not acceptable, SIP message body of an existing primitive can be used to define new semantics that is understood only by SPEECHSC entities. 5.6. Analysis of Duplexing and Parallel Operation Requirements 5.6.1. Duplexing and Parallel Operation Requirements [9] T: SPEECHSC resource is a SIP UA that can handle session requests from different UAs. 5.6.2. Full Duplex operation [9.1.1] T: Each SIP UA consists of a UAC and a UAS. This allows for full duplex operation. 5.6.3. Multiple services in parallel [9.1.2] T: SIP allows simultaneous invocation of different services. SIP allows forking or splitting the same media stream to different end points as defined in [2]. 5.6.4. Combination of services T: See 5.6.3. SIP UA can invoke different services and combine the results. > -----Original Message----- > From: Brian Wyld [mailto:brian.wyld@eloquant.com] > Sent: Sunday, October 27, 2002 3:33 PM > To: internet-drafts@ietf.org > Cc: eburger@alum.mit.edu; eburger@snowshore.com; Brian Wyld (E-mail); > Speechsc (E-mail) > Subject: [Speechsc] Updated version (v0.2) for speechsc WG Internet > Draft submission protocol evaluation document > > > 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] > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Wed Oct 30 06:30: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 GAA09713 for ; Wed, 30 Oct 2002 06:30:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UBW2w27557 for speechsc-archive@odin.ietf.org; Wed, 30 Oct 2002 06:32:02 -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 g9UBW2v27554 for ; Wed, 30 Oct 2002 06:32:02 -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 GAA09673 for ; Wed, 30 Oct 2002 06:29: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 g9UBVpv27428; Wed, 30 Oct 2002 06:31:51 -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 g9UBMjv26807 for ; Wed, 30 Oct 2002 06:22:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09303; Wed, 30 Oct 2002 06:20:21 -0500 (EST) Message-Id: <200210301120.GAA09303@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, 30 Oct 2002 06:20:21 -0500 Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-protocol-eval-00.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-00.txt Pages : 28 Date : 2002-10-29 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-00.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-00.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-00.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-10-29130620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speechsc-protocol-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speechsc-protocol-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29130620.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc