Subject: Re: [Speechsc] Re: I-DACTION:draft-melanchuk-speechsc-serverloc-00.txt

From: Corby Anderson <[email-masked]>
Date: Tue, 07 Mar 2006 10:25:41 -0800

Knowing where grammars are located is a big issue.  We have a large 
distributed network of recognition resources, with so many grammars that 
we cannot load all grammars into every recognizer -- this means that we 
have to segment our network into sets of recognition resources, each 
knowing some different grammars.  As such, the clients must have a way 
to find a recognition resource that has the grammars needed to satisfy 
the request.

Corby Anderson
Tellme Networks, Inc.

Tim Melanchuk wrote:
> hi dave,
>
> thanks for your comments and suggestions.
>
> dave oran has suggested that "speechsc" may also be an
> appropriate prefix instead of a protocol specific prefix.
> it is starting to look like many of the tags are not protocol
> specific so i am considering switch to something like
> "speechsc" instead of "mrcpv2".
>
> comments on this proposal form the list would be apreciated.
> i'm not sure what to do with respect to grammars. there
> was considerable discussion  on the list about pre-loaded
> grammars and how a client could either request, or know before
> hand that there would be no significant delay for a grammar.
> is this still an issue and is there an alternative solution?
>
> cheers,
> timm
>
> On 1/4/06, *Dave Burke* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Nice to see the capabilities/prefs suggestion turn into a concrete
>     proposal!
>      
>     Some of the feature tags I was thinking about when suggesting this
>     are based on bad interoperability experiences seen in practice. I
>     would offer the following feature tags are very important - second
>     only to identifying the media resource types:
>         - mrcpv2.speechrecog.grammartypes - specifies the grammar
>     types supported
>         - mrcpv2.speechrecog.sitagformat - specifies the semantic
>     interpretation tag format *
>         - mrcpv2.speechrecog.recoresults - specifies format used for
>     recognition results (i.e. NLSML or EMMA)
>         - mrcpv2.speechrecog.languages - specifies the languages
>     supported (actually this applies to multiple resource types)
>      
>     Other comments:
>      1. mrcpv2.speechrecog.grammars is not practical (a server is
>     going to have a very large cache!)
>      2. I think putting the version number in the feature tag may not
>     turn out prudent (will MRCPv2.2 / v3 use mrcpv2 feature tags?)
>      3. I like the hierarchical structure suggested in feature tags
>      
>     (*) For historical reasons, the application/srgs and
>     application/srgs+xml MIME types do not imply the tag-format.
>     Today, there is one SI standard in development (W3C SISR -
>     Candidate Rec available soon) and at least two well known
>     proprietary SI formats. Real speech grammars need SI and,
>     IMO, it's easily the biggest problem affecting true VoiceXML
>     application portability today.
>      
>     Dave
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
>   
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc