Subject: RE: [Speechsc] RECORD method

From: "Reifenrath, Klaus" <[email-masked]>
Date: Wed, 8 Jun 2005 09:07:36 -0400

I had the use case in mind, where the MRCPv2 server has to fetch SSML
documents. Is this what you call "indirected" content?

Klaus 

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Mittwoch, 8. Juni 2005 14:34
To: Reifenrath, Klaus
Cc: Brett Gavagni; [email-masked]; Shanmugham, Saravanan;
[email-masked]
Subject: Re: [Speechsc] RECORD method

On Jun 8, 2005, at 8:03 AM, Reifenrath, Klaus wrote:

> There are use cases where the speech synthesis engine need to speak 
> secret data, in which cases HTTPS would also be required for servers 
> that only have speech synthesis resources.
>
The input text is usually in the MRCP messages, which does in fact require
TLS, and the output media gets protected with SRTP. Are you positing the
case where the text to be spoken is obtained with content indirection? In
that case i agree with you and I've already updated the spec to require
HTTPS for indirected content.

> Klaus
>
> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Mittwoch, 8. Juni 2005 05:06
> To: Brett Gavagni
> Cc: [email-masked]; Shanmugham, Saravanan; speechsc- 
> [email-masked]
> Subject: Re: [Speechsc] RECORD method
>
> I'm trying in my chair review and editing to rationalize the  
> wording in as
> many places as I find. Doing this without unintentionally changing the
> technical content is something which I have to be conservative  
> about though.
> the example of why HTTP some places and HTTPS other places is an  
> case of
> where I am reluctant to change anything, because a server with only  
> a speech
> synthesis engine and no recorder might never need HTTPS, whereas for
> security reasons HTTPS is mandatory for recorders.
>
> I'll let you folks be the judge of success once we get the edited  
> draft out
> (within a week if all goes well)
>
> Dave.
>
> On Jun 7, 2005, at 3:23 PM, Brett Gavagni wrote:
>
>
>> Hi,
>>
>> I'm requesting consistent wording throughout the sections of the
>> specification.
>>
>> The specification becomes increasingly convoluted with protocol
>> requirements that vary or are inconsistent in different sections.
>>
>> One could argue that the MRCP client and server implementation could
>> coexist at the same logical network address and the security overhead
>> implications/requirements are redundant in particular isolated
>> scenarios.
>>
>> Thanks,
>>
>> Brett Gavagni
>> WebSphere Voice Server Development
>> http://www-306.ibm.com/software/pervasive/voice_server/
>> [email-masked]
>>
>>
>>
>>
>> "Shanmugham, Saravanan" <[email-masked]>
>> 06/07/2005 02:55 PM
>>
>> To
>> Brett Gavagni/West Palm Beach/IBM@IBMUS cc "David R. Oran"
>> <[email-masked]>, <[email-masked]>, <[email-masked]>
>> Subject
>> RE: [Speechsc] RECORD method
>>
>>
>>
>>
>>
>>
>> You are refering to the capability of the Media servers capability to
>> access another webserver(HTTP client capability).
>>
>> This thread is about the Media server being capable of recording the
>> audio locally and providing HTTP server access to that recorder
>> content.
>>
>> Sarvi
>>
>>      -----Original Message-----
>>      From: Brett Gavagni [mailto:[email-masked]]
>>      Sent: Tuesday, June 07, 2005 11:49 AM
>>      To: Shanmugham, Saravanan
>>      Cc: David R. Oran; [email-masked]; [email-masked]
>>      Subject: RE: [Speechsc] RECORD method
>>
>>      The only comment I have is to keep the wording consistent
>>      throughout the specification. I would be careful in the
>>      deviation of terminology across sections.
>>
>>      For example in section: 8.5. Synthesizer Message Body
>>
>>      Synthesizer Speech Data
>>      Lexicon Data
>>      ..
>>      ..
>>      ...
>>      All media servers MUST support the
>>         HTTP uri access mechanism.
>>
>>      Thanks,
>>
>>      Brett Gavagni
>>      WebSphere Voice Server Development
>>      http://www-306.ibm.com/software/pervasive/voice_server/
>>      [email-masked]
>>
>>
>>
>>
>>      "Shanmugham, Saravanan" <[email-masked]> Sent by:
>>      [email-masked]
>>      06/07/2005 02:32 PM
>>
>>      To
>>      "David R. Oran" <[email-masked]>, <[email-masked]> cc
>>
>>      Subject
>>      RE: [Speechsc] RECORD method
>>
>>
>>
>>
>>
>>
>>       I think we want to allow for HTTP as well. So, "MUST
>>      HTTPS and SHOULD HTTP" would be fine with me.
>>
>>      Sarvi
>>
>>           -----Original Message-----
>>           From: [email-masked]
>>           [mailto:[email-masked]] On Behalf Of David R.
>> Oran
>>           Sent: Tuesday, June 07, 2005 8:29 AM
>>           To: [email-masked] ((((E-mail))))
>>           Subject: [Speechsc] RECORD method
>>
>>           the text says:
>>
>>           "The RECORD request places the recorder resource in the
>>           Recording state. Depending on the headers specified in the
>>           RECORD method the resource may start recording the audio
>>           immediately or wait for the end pointing functionality to
>>           detect speech in the audio. It then saves the audio to the
>>           URI supplied in the recording-uri header. If the
>>           recording-uri is not specified, the server MUST capture
>>           the media onto a local disk and return a URI pointing to
>>           the recorded audio in the RECORD-COMPLETE event. The
>>           server MUST support HTTP and file URI schemes."
>>
>>           Sorry, but a file: URI won't work - it's not generally
>>           usable between systems. Because of this and the secuirty
>>           issues, the last sentence probably ought to be:
>>
>>           "The server MUST support the HTTPS URI scheme and MAY
>>           support other schemes. Note that due to the sensitive
>>           nature of voice recordings, any other URI schemes
>>           supported by the server SHOULD employ integrity and
>>           confidentiality on the data transfer (e.g. FTPS)."
>>
>>           I changed the text, so let me know if this is going to
>>           cause heartburn.
>>
>>           dave.
>>
>>
>>           _______________________________________________
>>           Speechsc mailing list
>>           [email-masked]
>>           https://www1.ietf.org/mailman/listinfo/speechsc
>>
>>
>>      _______________________________________________
>>      Speechsc mailing list
>>      [email-masked]
>>      https://www1.ietf.org/mailman/listinfo/speechsc
>>
>>
>>
>
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
>

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 8 Jun 2005 09:29:21 -0400

> documents. Is this what you call "indirected" content?
Yes.