From speechsc-bounces@ietf.org Mon Apr 02 11:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOcr-0001d5-Ft; Mon, 02 Apr 2007 11:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOcq-0001d0-Le for speechsc@ietf.org; Mon, 02 Apr 2007 11:39:20 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOci-0000uf-Pc for speechsc@ietf.org; Mon, 02 Apr 2007 11:39:20 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 425C020993; Mon, 2 Apr 2007 17:39:10 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-e7-4611239efc6c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 23DF52092B; Mon, 2 Apr 2007 17:39:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 17:39:09 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 17:39:09 +0200 Message-ID: <4611239D.2070702@ericsson.com> Date: Mon, 02 Apr 2007 17:39:09 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Speechsc] WGLC MRCPv2-12 - More comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2007 15:39:09.0234 (UTC) FILETIME=[0E0A0120:01C7753D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Hi, Here is the rest of the comments I have. I probably could find a few more if I read certain sections at all or in more detail. But there are a few issues here that you certainly should correct before going forward. 1. Section 4.3, Second paragraph: There is missing a empty line between the text and the ABNF. 2. Section 5.1, Third paragraph " If a message contains a message body, the message MUST contain content-headers indicating the MIME-type and encoding of the data in the message body." Shouldn't also the message body length header be indicated here as required. I know there is the message length value which allows inferring the message body-length. 3. Section 5.2: Is the request-id scoped by the channel ID or per TCP connection? I think the distinction is quite important if multiple MRCP resources share the TCP channel. 4. General comment: Usage of DIGIT fields without maximum specified sizes. I am a bit worried that you specify a lot of fields to use 1*DIGIT. The reason is that this makes for parsers complicated and may lead to some interoperability issues. How many of the implementations would for example accept a 4000 digit number as a request-ID on the request line? It is valid by syntax, but isn't this complicate things a bit to much. Comparing or verifying arbitrarily long strings of digit makes life more complicated. I would recommend that you specify something that fits into 32 or 64 bits of unsigned safely in the places where it makes sense. Considerations for handling large message also plays into this as there is a potential for doing attacks on the server using these. 5. Section 5.3: The mrcp-version field MUST contain the version of the MRCPv2 protocol running on the server. I think this should be clarified to: The version of the request if supported otherwise the highest version supported. 6. Section 5.3: Are you certain that no-ones needs to extend the possible request states? If not, I recommend that you add to the ABNF something that describes what syntax rules any future extension must follow. This can be seen as a general comment on the whole ABNF. All fields that are intended to be possible to extend should define extension syntax. Otherwise extending things without knowing what parsers handles without crashing/barfing makes life difficult. 7. Section 5.4, Code 503: Are you allowing proxies in the client to server communication? It doesn't seem like that and I would recommend against going there. Life gets much more complicated. Thus I wonder if this error message is needed. 8. Section 6.2: field-content should be defined in ABNF rather than using hand waving. And yes, I know it is an action of enumeration. However it is an very useful exercise. 9. Section 6.2: "Multiple headers with the same name MAY be present in a message if and only if the entire value for that header is defined as a comma- separated list [i.e., #(values)]." Do you have a good reason to allowing this? Are it is actually used or is it only cluttering up your parsers? If the later I would propose that you remove it. 10. Section 6.2.1, Is it intended to not allow any LWS in the Channel-Identifier header? LWS = Linear White Space 11. Section 6.2.3, Is it intended to not allow any LWS in this header, especially around the ","? 12. Section 6.2.6: First, why are you saying a "restricted set" of media types? Is it really MRCPv2 that supports them or rather that some of the resources supports some media types. Secondly I think you should try to use "Media Types" rather than MIME here. Basically I think the paragraph needs rewording to be clear that the Content-Type header used Media Types to describe what the body of the request or response is. 13. section 6.2.9: Which of the RFC 2616 listed content-encodings are required to be supported if any? And how does a client learns which are supported by the other entity? You seem to need at least Accept-Encoding [H.14.3] to allow the requestor to specify supported encodings for the response. However that doesn't work for requests with body. Maybe using the SDP negotiation channel to declare capabilities? 14. Section 6.2.13: Extensibility of the cache-control directives. 15. Section 6.2.15: I find it somewhat confusing that you use different ABNF between this section and Section 15, for example with "CommentURL". Maybe a bit more alignment or at least a clearer warning in the intro about that they may differ. 16. Section 8.4.9: This section has ABNF for the Timestamp header. However the descriptive text discusses only at the Speech-Marker header. Should the Timestamp header has its own subsection? Even if not it needs some text and a change of the grammar in the section. 17. Section 8.5.1: Second paragraph page 52: I am missing a normative reference to text/uri-list. 18. Section 8.5.1, Third paragraph page 52: Missing reference to the .wav format and "sun audio format". These are normative references and needs to be indicated which specification that applies. 19. Page 61: Pause Example: Both message length and Content-Length has the wrong value. According to my check the body is 609 bytes. This error seems to exist for several of the other examples in section 8. 20. Section 8.9 and Section 8.4.8. Why isn't speech marker used in PAUSE responses? 21. section 9.1: What effect does interpretation have on the state machine? 22. Section 9.4.5. At the end of the first paragraph there is an extra ".". 23. Section 9.4.8: Why is the Waveform URI quoted using < instead of "? 24. Section 9.5.1: Wrong Content length in example. Skipped sections 9.6, 10 and 11. 25. Section 12.4: How does one handle authentication information related to access of content over HTTP and HTTPS? Isn't the client in many case the one having the rights to use things and needs to transfer them temporarily to a MRCPv2 server? 26. Section 13.2.1 and 13.5: Has these media types been reviewed by the IETF Types list which is a requirement for publication? 27. Section 13.6: Has the URI been on review on uri-review@ietf.org? 28. Section 13. All the templates are hard to read due to lack of ":" between field explanation and value. The templates are also crushed together and the lack of blank lines makes it hard to separate things. 29. Section 14.1: I think one should consider changing the s= string in the example. 30. Section 14.1: First text comment: " The client requests the server to create synthesizer resource control channel to do speech synthesis. This also adds a media pipe to send the generated speech. Note that in this example, the client request the reuse of an existing MRCPv2 TCP pipe between the client and the server." What pre-existing TCP connection are we talking about here? If it exist prior to the invites then you better be more explicit about it? 31. Section 14.1: Content-Length header in examples does not match reality. 32. Section 15: Using Bill Fenners ABNF parser I do get a few missing definitions in addition to the ones from RFC 4234: ; accept UNDEFINED ; accept-charset UNDEFINED ; content-id UNDEFINED ; x20 UNDEFINED ; boolean UNDEFINED ; interpret-text UNDEFINED ; FLOAT UNDEFINED You should also consider if these are correct: ; cmid-attribute defined but not used ; generic-message defined but not used ; timestamp defined but not used I guess "generic-message" is just fine. But timestamp seems like a possible error. 33. Section 17.1: ID-nits find a few reference problems: * Downref: Normative reference to an Informational RFC: RFC 4313 (ref. '1') - Outdated reference: draft-ietf-mmusic-sdp-comedia has been published as RFC 4145 * Obsolete normative reference: RFC 2109 (ref. '15') - Outdated reference: draft-ietf-mmusic-sdescriptions has been published as RFC 4568 - Obsolete informational reference (is this intentional?): RFC 2833 (ref. '29') Please check them. Any you will need to move the requirements doc to the informational part of the list. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Apr 04 00:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxFd-0006Y9-08; Wed, 04 Apr 2007 00:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxFZ-0006Se-Q2 for speechsc@ietf.org; Wed, 04 Apr 2007 00:37:39 -0400 Received: from mx2.nuance.com ([198.71.73.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYxFX-0001aN-If for speechsc@ietf.org; Wed, 04 Apr 2007 00:37:37 -0400 Received: from unknown (HELO pb-appserver01.pb.scansoft.com) ([10.1.4.19]) by mx2.nuance.com with ESMTP; 04 Apr 2007 00:37:35 -0400 X-BrightmailFiltered: true X-IronPort-AV: i="4.14,367,1170651600"; d="scan'208"; a="54107433:sNHT27743506" Received: from [127.0.0.1] ([10.3.9.13]) by pb-appserver01.pb.scansoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Apr 2007 00:37:38 -0400 Message-ID: <46132B89.5060507@nuance.com> Date: Wed, 04 Apr 2007 00:37:29 -0400 From: David Copp User-Agent: Thunderbird 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: SPEECHSC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2007 04:37:38.0843 (UTC) FILETIME=[F98C76B0:01C77672] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Speechsc] MRCPv2-12 section 8.8 comments 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: , Errors-To: speechsc-bounces@ietf.org Hello, I am a member of Nuance's Platforms group and am writing an MRCPv2 integration guide. Section 8.8 "BARGE-IN-OCCURRED", middle paragraph, has a couple of minor problems: 1. It refers to BARGE-IN-OCCURRED as an event: If a "SPEAK" request is active with kill-on-barge-in enabled, and the BARGE-IN-OCCURRED event is received, the synthesizer MUST immediately stop streaming out audio. 2. It seems to say that BARGE-IN-OCCURRED behaves rather like STOP: [The synthesizer] MUST also terminate any speech requests queued behind the current active one, irrespective of whether they have barge-in enabled or not. If a barge-in-able "SPEAK" request was playing and it was terminated, the response MUST contain the an [sic] active-request-list header listing the request-ids of all "SPEAK" requests that were terminated. The server generates no "SPEAK-COMPLETE" events for these requests. This confuses the barge-in-able "SPEAK" request with pending "SPEAK" requests. The reader is left thinking that ALL of the "terminated" requests -- both the one that was barged-in upon and the ones behind it -- do not get a "SPEAK-COMPLETE" event, which is not true. A less confusing statement might be: [The synthesizer] MUST also terminate any "SPEAK" requests queued behind the current active one, irrespective of whether they have barge-in enabled or not. When queued "SPEAK" requests are terminated as a consequence of BARGE-IN-OCCURRED, the response MUST contain an active-request-list header listing request-ids of the queued "SPEAK" requests that were terminated. The server generates no "SPEAK-COMPLETE" events for these requests. Also note that in example 14.1, on page 173, the response to BARGE-IN-OCCURRED lists the request ID of the preceding RECOGNIZE request (543258) in the Active-Request-Id-List: S->C: MRCP/2.0 72 543259 200 COMPLETE Channel-Identifier:32AECB23433801@speechsynth Active-Request-Id-List:543258 Speech-Marker:timestamp=857206096314 It seems in this case the Active-Request-Id-List header must be removed from the response, since no queued "SPEAK" request was terminated. Cheers David Copp Platforms Group Nuance Communications Inc. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Thu Apr 05 16:24:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYUe-0005V9-EO; Thu, 05 Apr 2007 16:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYUd-0005Uq-PK for speechsc@ietf.org; Thu, 05 Apr 2007 16:23:39 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZYUc-0002ve-Bw for speechsc@ietf.org; Thu, 05 Apr 2007 16:23:39 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l35KNbe1025573 for ; Thu, 5 Apr 2007 16:23:37 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l35KNbPt129248 for ; Thu, 5 Apr 2007 14:23:37 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l35KNb7R020164 for ; Thu, 5 Apr 2007 14:23:37 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l35KNb4L020156 for ; Thu, 5 Apr 2007 14:23:37 -0600 In-Reply-To: To: MIME-Version: 1.0 Subject: Re: [Speechsc] Reminder: WGLC MRCPv2 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Brett Gavagni Date: Thu, 5 Apr 2007 16:23:35 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 04/05/2007 14:23:37, Serialize complete at 04/05/2007 14:23:37 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: speechsc-bounces@ietf.org IBM continues to contribute to the standardization activities of the MRCPv2 protocol, and supports the recommendation of the MRCPv2 protocol as a proposed IETF standard. IBM believes that the MRCPv2 protocol provides a robust set of interfaces for the development and integration of speech enabled solutions. Thanks, Brett Gavagni WebSphere Voice Server Development http://www-306.ibm.com/software/pervasive/voice_server/ gavagni@us.ibm.com "Eric Burger" 03/27/2007 09:59 AM To cc Subject [Speechsc] Reminder: WGLC MRCPv2 Last call closes this week on 30 March. Please send comments, even if only, "whatever, we already interoperate with X clients" or "brilliant work" or "this is lousy because ..." or "260 pages - you must be nuts!" -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Thu Apr 05 21:24:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdBp-000564-7g; Thu, 05 Apr 2007 21:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdBn-000524-JM for speechsc@ietf.org; Thu, 05 Apr 2007 21:24:31 -0400 Received: from mail.iflytek.com ([220.178.24.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdBk-00032c-Ud for speechsc@ietf.org; Thu, 05 Apr 2007 21:24:31 -0400 Received: from hjye ([192.168.77.74]) by mail.iflytek.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Apr 2007 09:27:36 +0800 From: "hjye" To: References: Subject: Reply: [Speechsc] Reminder: WGLC MRCPv2 Date: Fri, 6 Apr 2007 09:33:37 +0800 Message-ID: <000601c777eb$9989bff0$4a4da8c0@iflytek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 In-Reply-To: Thread-Index: AcdweCoJtq8h2eoQRQiukyYQIsSjWAHb30pA X-OriginalArrivalTime: 06 Apr 2007 01:27:36.0341 (UTC) FILETIME=[C1F43C50:01C777EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: speechsc-bounces@ietf.org iFLYTEK has implemented an commercial MRCPv2 server and client in recent days. The server and client has been successfully integrated and tested with = two MRCPv2 products from different vendors. ******************************************************* Speech Platform Department. AnHui USTC iFLYTEK Co., Ltd. iFLY Mansion, Huangshan Rd.616, Information Industry Base,=20 National High&New Tech Industrial Development District=20 Hefei, Anhui, China Phone:+86 551 5331851 8026 Mail=A3=BAhjye@iflytek.com ******************************************************* -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: marted=A8=AC 27 marzo 2007 16.00 To: speechsc@ietf.org Subject: [Speechsc] Reminder: WGLC MRCPv2 Last call closes this week on 30 March. Please send comments, even if only, "whatever, we already interoperate = with X clients" or "brilliant work" or "this is lousy because ..." or "260 = pages - you must be nuts!" -- Sent from my wireless e-mail device. Sorry if terse. We all need = lemonade: see for what lemonade is. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual = or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by = email and then delete it. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc>