From speechsc-bounces@ietf.org Thu Feb 09 05:15:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78pt-0007Me-Cd; Thu, 09 Feb 2006 05:15:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78pr-0007Ja-BE for speechsc@megatron.ietf.org; Thu, 09 Feb 2006 05:15:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05961 for ; Thu, 9 Feb 2006 05:13:51 -0500 (EST) Received: from fw01.db01.voxpilot.com ([212.17.54.82] helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F792a-0000vk-DU for speechsc@ietf.org; Thu, 09 Feb 2006 05:28:47 -0500 Received: from daburkewxp (dsl-34-34.dsl.netsource.ie [213.79.34.34]) by mail.voxpilot.com (Postfix) with ESMTP id BCDE32140ED; Thu, 9 Feb 2006 10:15:16 +0000 (GMT) Message-ID: <019e01c62d61$baf083c0$6700000a@db01.voxpilot.com> From: "Dave Burke" To: "Andrew Wahbe" , "IETF SPEECHSC (E-mail)" References: <43A9D0FC.1080103@voicegenie.com> Subject: Re: [speechsc] Requests for Clarification Date: Thu, 9 Feb 2006 10:15:18 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: speechsc-bounces@ietf.org Errors-To: speechsc-bounces@ietf.org This is good constructive criticism IMO. Minor comments inline. Dave ----- Original Message ----- From: "Andrew Wahbe" To: "IETF SPEECHSC (E-mail)" Sent: Wednesday, December 21, 2005 10:02 PM Subject: [speechsc] Requests for Clarification > The VoiceXML Forum MRCP Liaison Committee is currently evaluating the > latest MRCP v2 draft to (a) evaluate the compatibility between MRCP v2 > and VoiceXML and (b) generate test assertions for MRCP v2 based VoiceXML > browsers and MRCP v2 based media resources. We are currently examining > the Speech Synthesis portion of the specification and have raised issues > with the specification in prior emails to the SpeechSC list (See > http://www.ietf.org/mail-archive/web/speechsc/current/msg01605.html > http://www.ietf.org/mail-archive/web/speechsc/current/msg01606.html > and http://www.ietf.org/mail-archive/web/speechsc/current/msg01607.html ). > > These issues (and the responses to them) have been discussed by the MRCP > Liaison Committee and we would like to make the following requests and > suggestions: > > 1) The relationship between the Fetch Hint header and the Audio Fetch > Hint header should be clarified. More specifically, it should be stated > that, when specified, the Audio Fetch Hint header overrides the Fetch > Hint header for audio files only. > 2) It should be clarified that SPEAK completion code 003 "uri-failure" > only applies to fetched SSML files and that failure to fetch (or > process) an audio file will not result in aborting the SPEAK request. > This does mean, however, that there is no way to communicate the failure > to fetch (or process) the audio file to the MRCP client. While SSML > requires that the processor "notify the hosting environment" when such a > failure occurs, the members of the committee agree that logging this > event at the MRCP server is sufficient. It may be advisable for the MRCP > specification to suggest that these events should be logged in some way. > We would also like to suggest that future versions of MRCP consider > adding an event (e.g. "Audio-Exception") to notify the MRCP client that > such a failure has occurred without aborting the SPEAK request. > > 3) The definition of the Basic Synthesizer resources is a bit vague and > should be clarified. Its not entirely clear from the description in the > spec how it is supposed to work. The general consensus in the Committee > is that this resource can be used for audio only prompts. It is supposed > to accept a subset of SSML that only includes