Subject: RE: [Speechsc] RECORD method

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 7 Jun 2005 11:55:31 -0700

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

---

From: Brett Gavagni <[email-masked]>
Date: Tue, 7 Jun 2005 15:23:15 -0400

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 

"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

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. 

     Synthesizer Speech Data
     Lexicon Data
     ..
     ..
     ...
 
     Thanks,
 
     Brett Gavagni

 
 
     To
 
     Subject

 
 
     Sarvi
 
          -----Original Message-----
 
          the text says:

 

          dave.

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 7 Jun 2005 23:06:26 -0400

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.