Subject: Re: [speechsc] Record-URI mechanism

From: Dan Burnett <[email-masked]>
Date: Thu, 31 Aug 2006 14:26:13 -0700 (PDT)

Actually, you have only quoted part of the text from
10.4.7.  Here's the full paragraph:

<begin>
When a recorder method contains this header the server
must capture the audio and store it. If the header is
empty, the server MUST store the content locally and
generate a URI that points to it. This URI is then
returned in the STOP response or the RECORD-COMPLETE
events. If the header in the RECORD method specifies a
URI, the server MUST attempt to capture and store the
audio at that location. If this header is not
specified in the RECORD request, the server MUST
capture the audio and send it in the STOP response or
the RECORD-COMPLETE event as a message body. In this
case, the response carrying the audio content would
have this header with a cid value pointing to the
Content-ID in the message body.
<end>

In other words, 10.4.7 permits both approaches -- if
you want a generated URI you specify the header with
an empty value.  If you want it in the body you don't
specify the header at all.

Thus, to make 10.6 consistent with this I suggest we
replace
"It then saves the audio to the URI supplied in the
recording-uri header. If the recording-uri is not
specified, the server captures the media anywhere it
finds convenient and returns a URI pointing to the
recorded audio in the RECORD-COMPLETE event."
 with
"The audio is then made available to the client as
specified by Record-URI."

I am making this clarification in draft -11 but will
undo it if there are concerns raised that require
discussion.

-- dan

--- Dave Burke <[email-masked]> wrote:

> In 10.6, the spec says:
> 
>    If the recording-uri is not specified [in
> RECORD], the server captures the media
>    anywhere it finds convenient and returns a URI
> pointing to the
>    recorded audio in the RECORD-COMPLETE event.
> 
> However, 10.4.7 apparently conflicts with this and
> says:
> 
>    If this header is not specified in the RECORD
> request, the server
>    MUST capture the audio and send it in the "STOP"
> response or the
>    RECORD-COMPLETE event as a message body.  In this
> case, the response
>    carrying the audio content would have this header
> with a cid value
>    pointing to the Content-ID in the message body.
> 
> Which is it? I prefer it to be the former (i.e. no
> data in the message body). It's easy to implement
> (very likely the MRCP client has a HTTP client
> somewheres, optimised for streaming and allowing
> caching for repeated playback), it doesn't burden
> the control channel with potentially very large
> audio data, and besides, the MRCP client might not
> even want the data in the case of verification on
> the server.
> 
> Dave
> 
> 
> > _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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