Subject: [Speechsc] Vendor-Specific-Parameters

From: Jeff Kusnitz <[email-masked]>
Date: Thu, 15 Jan 2004 14:02:02 -0800

As currently defined in both the v1 and the v2 specifications, is allowed 
in only SET-PARAMS/GET-PARAMS requests and responses.  Is this 
intentional?  I can think of instances where I'd like to use this header 
on other requests (SPEAK, RECOGNIZE, DEFINE-GRAMMAR, etc).  I realize I 
can work around this limitation by calling SET-PARAMS before my 
SPEAK/RECOGNIZE/etc request with the appropriate vendor-specific-parameter 
value, and then calling GET-PARAMS afterwards, but that requires three 
request/responses, rather than one.

Thanks,
Jeff

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

---

From: David Oran <[email-masked]>
Date: Fri, 16 Jan 2004 14:10:02 -0500

--On Thursday, January 15, 2004 2:02 PM -0800 Jeff Kusnitz <[email-masked]> 
wrote:

> SPEAK/RECOGNIZE/etc request with the appropriate
> vendor-specific-parameter  value, and then calling GET-PARAMS afterwards,
> but that requires three  request/responses, rather than one.
>
the tradeoff seems to be the extra round trip versus the need to deal with 
extra failure modes of all the other commands on which this could be 
piggy-backed. One optimization that makes sense to me is to piggyback the 
param values that would be returned on GET-PARAMS onto the response to the 
SET-PARAMS request.

If the parameters are "sticky" (not clear from teh spec that they are but I 
would assume so) then the extra round trip isn't terribly painful and it 
avoids the extra complexity of figuring out how to handle error cases on 
each request.

I don't feel strongly about this, though. Sarvi and others, what do you 
think?

Dave.

---

From: Jeff Kusnitz <[email-masked]>
Date: Mon, 19 Jan 2004 13:46:38 -0800

You bring up an interesting point on the stickiness..  In a couple of 
places, a distinction is made between values sent on a SET-PARAMS request 
vs other.  For example, in cache-control (5.4.11), it says this:

        If the directives are sent on a SET-PARAMS method, it 
        SHOULD apply for all requests for documents the media server may 
        make in that session. If the directives are sent on any other 
        messages they MUST only apply to document requests the media
        server needs to make for that method.

And similarly, in voice-parameters (7.4.5):

        These header fields MAY BE sent in SET-PARAMS/GET-PARAMS request
        to define/get default values for the entire session or MAY BE
        sent in the SPEAK request to define default values for that
        speak request.  Further more these attributes can be part of the
        speech text marked up in SML. 

I had assumed (oopsie?) that this would be applicable in all places - a 
value set via SET-PARAMS is retained for the duration of a session, while 
a value set on some other request was valid only for that request.  It 
seemed fairly natural as well, but perhaps it should be spelled out in the 
SET-PARAMS sections?

Jeff