Subject: RE: [Speechsc] RECORD method

From: "Reifenrath, Klaus" <[email-masked]>
Date: Wed, 8 Jun 2005 08:03:51 -0400

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. 

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; [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 08:34:01 -0400

> 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.