Subject: RE: [Speechsc] Server capabilities

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Thu, 4 Aug 2005 10:43:28 -0700

Here is a suggestion to address this issue.

The ability to discover the capabilities of an MRCP server is
substantial piece of work in my opnion. Something that need a draft of
its own. Its not a priority issue that should stop the MRCPv2 draft from
progressing. I would suggest that we defer this work to a separate draft
and allow us to finish this one. The current draft is pretty huge by
itself.
  I like the idea of using SIP OPTIONS along with necessary SDP
definitions that describe the capabilities of resources it supports.
These I believe can be defered to a separate draft without affecting
MRCPv2 very much. 
  This draft should also define mime-bodies that cover support for
certain headers and their possible values(like CONTROL method and the
different values supported for JumpSize etc). 
  It should also return a mime-body listing the grammars that are
provisioned permanently on the server.

What we not should do.
    I don't believe the installation of grammars that may be persistent
across sessions should be the job of MRCPv2. I believe this should be a
provisioning issue and addressed through SNMP or some other approach
that may be used to install the server, the different
resources/languages it supports etc.

Sarvi  

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of 
     Shanmugham, Saravanan
     Sent: Wednesday, June 15, 2005 12:49 PM
     To: Corby Anderson; [email-masked]
     Subject: RE: [Speechsc] Server capabilities
     
     This comment is only relating to your suggestion to use 
     option b to address resolving binary grammar uri.
     I think the right way to do this would be to define a file 
     format for this binary across vendors and use it. This 
     wouldn't have to be very complex, at a minimum agree on 
     standard header for the beginning of this file that 
     identifies vendor and format version number and the rest 
     of the binary file could be vendor specific. 
     
     No need to address this through the MRCP specification.
     
     Sarvi 
     
          -----Original Message-----
          From: [email-masked] 
          [mailto:[email-masked]] On Behalf Of Corby Anderson
          Sent: Wednesday, June 15, 2005 12:20 PM
          To: [email-masked]
          Subject: Re: [Speechsc] Server capabilities
          
          I'm very much in favor of b).
          
          In the "managing big grammars" thread we were considering 
          about permitting URIs to reference binary grammars as well 
          as source grammars (was that ever codified?).  How about 
          having some way for the server to indicate what 
          vendor/version it is.  For heterogenous MRCP server 
          environments, this would allow clients to give the right 
          grammar binary URIs to the right servers.
          
          Corby Anderson
          Tellme Networks, Inc.
          
          David R. Oran wrote:
          
          > 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
          > [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

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