[Speechsc] Server capabilities

["David R. Oran" <oran at cisco.com>]

This message was prompted by one aspect of the discussion on the list  
about large grammars, which is how a client can figure out in advance  
just what a server can and can't do, so it isn't "unpleasantly  
surprised" at the instant it issues a method.

The current specification walks a fine line between giving  
flexibility to server implementers and giving clients a sufficient  
degree of control over server behavior. For example we have things  
like multiple jump-length units which a server may or may not  
support, server-specific default values for confidence-threshold and  
speed-vs-accuracy, and a bunch of others.

There is some for this support, including:
1) through SDP and SIP OPTIONS the client can discover what resources  
the server supports and what media formats it can process.
2) through GET-PARAMS on a particular session with a resource the  
client can discover any implementation-specific server default values  
for MRCPv2 protocol headers.

My question to the WG is what, if anything do we need beyond these?

Here's a small list of candidates. Feel free to comment and/or  
propose your own:

a) we may want/need a way for the server to determine what audio  
formats a client supports for the purposes of returning captured  
audio. Right now we don't even have a way for the client to tell the  
server what format it wants audio returned in, so we at least have to  
remedy that omission.

b) we may want a way for a client to learn the current list of  
"instantly available" grammars the server has handy and which are in  
some way "guaranteed" to persist for a while.

c) we may want a form of GET-PARAMS which fetches session-independent  
server information. One way to do this is to define a MRCPv2-frag  
content type (like we have with sipfrag). That way a SIP OPTIONs to  
an MRCPv2 server can return an MRCP-specific body with all that  
interesting information about server capabilities.

<chair hat>
I don't want this to necessary turn into a free-for-all, because we  
really do want to reach closure on the spec and get it to last call.  
My target for finishing my chair review and editing is the end of  
this week.
</chair hat>

_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc