Subject: Re: [speechsc] Record-URI mechanism

From: "Dave Burke" <[email-masked]>
Date: Fri, 1 Sep 2006 12:18:00 +0100

OK - that works. I think I must have tripped over the phrase "if the header 
is empty" and wrongly assumed an inconsistency... A minor improvement could 
be instead to write "if the header is present but specified with no value".

Dave

----- Original Message ----- 
From: "Dan Burnett" <[email-masked]>
To: "Dave Burke" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 31, 2006 10:26 PM
Subject: Re: [speechsc] Record-URI mechanism

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

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

---

From: Dan Burnett <[email-masked]>
Date: Fri, 1 Sep 2006 11:22:05 -0700 (PDT)

Agreed.  I have applied your suggested change to -11.

-- dan