Subject: Re: [Speechsc] Issues around grammar lifetimes

From: Dan Burnett <[email-masked]>
Date: Wed, 7 Jun 2006 14:23:02 -0700 (PDT)

This is tracked as issue 84 on
http://www.softarmor.com/roundup/speechsc

-- Dan Burnett

--- "Carter, Jerry" <[email-masked]> wrote:

> Typically, an MRCP client will issue multiple
> DEFINE-GRAMMAR messages
> eventually followed by a RECOGNIZE.  The MRCP client
> might reasonably expect
> that the defined grammars would be available when
> recognition is requested,
> but this does not appear to be guaranteed. 
> Furthermore, I do not see any
> notification mechanism for informing the client of
> which grammars are
> unavailable.
> 
>  
> 
>  
> 
> There does not appear to be any language in section
> 9 that describes grammar
> lifetimes.  There is language in the session URI
> description (section 13.7)
> that might relate
>  
>       The purpose
>       of this scheme is to permit access to the
> specific resource for
>       the lifetime of the session with the entity
> storing the resource.
>  
> but this is not a normative statement requiring
> availability for a session
> lifetime.  In practice a MRCP server has a finite
> cache and may support
> multiple parallel sessions.  It is unreasonable to
> require that the MRCP
> server provision a sufficiently large cache to store
> all grammars across all
> sessions, particularly if sessions are long and
> employ large dynamic
> grammars.  Such a requirement would render small
> footprint MRCP servers
> impossible.
>  
> If a grammar is flushed from the MRCP server's cache
> before RECOGNIZE, the
> notification mechanism is unclear.  Presumably a
> completion cause of
> 'grammar-load-failure' would be returned.  The
> server might want to return a
> list of URIs in the message but this would violate
> 9.4.12
>  
>    Clients SHOULD NOT interpret the completion
> reason text.  Instead it
>    is RECOMMENDED that the reason be recorded in
> client logs and
>    otherwise made available for debugging and
> instrumentation purposes.
>  
> and such an approach would need to be standardized. 
> Additionally, a
> developer would like some assurance _before_
> RECOGNIZE is invoked that all
> the loaded grammars are available.
>  
>  
> Because MRCP servers have finite memory and caches,
> it is not reasonable to
> require that grammars be available on a session
> indefinitely after a
> DEFINE-GRAMMAR.  We might instead require that
> grammars have guaranteed
> availability on a session only until the next call
> to RECOGNIZE; this also
> breaks for the same reason.
>  
>  
> Here is a solution that I believe works.
>  
> (1) An MRCP server SHOULD retain grammars on each
> session created by a
> DEFINE-GRAMMAR message until at least the next
> RECOGNIZE.  It MAY retain
> grammars for much longer.
>  
> (2) DEFINE-GRAMMAR should support redefining
> grammars by passing the IDs
> without supplying the grammar definition.  The
> text/grammar-ref-list media
> type might be appropriate for this purpose.
>  
> (3) A RECOGNIZE or a DEFINE-GRAMMAR returning a
> completion cause of either
> 'grammar-load-failure' or
> 'grammar-completion-failure' should include a CRLF
> separated list detailing the IDs which grammars did
> not load or compile.
>  
> (4) The text in 9.4.11 should support DEFINE-GRAMMAR
> returning
> 'grammar-load-failure' and
> 'grammar-completion-failure'.
>  
> -------------------------
>  
> Under this proposal, the client might do the
> following:
>  
> DEFINE-GRAMMAR documentLevel1 (new definition)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR formLevel1 (new definition)
> DEFINE-GRAMMAR fieldLevel1 (new definition)
> RECOGNIZE
>  
> DEFINE-GRAMMAR documentLevel1 documentLevel2
> formLevel1 (IDs only to
> reassert continued need)
> DEFINE-GRAMMAR fieldLevel2 (new definition)
> RECOGNIZE
>  
> -------------------------
>  
> Likewise, in the typical error case:
>  
> DEFINE-GRAMMAR documentLevel1 (new definition)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR formLevel1 (new definition)
> DEFINE-GRAMMAR fieldLevel1 (new definition)
> RECOGNIZE
>  
> <time passes during which documentLevel2 gets
> flushed from the server's
> cache>
>  
> DEFINE-GRAMMAR documentLevel1 documentLevel2
> formLevel1 (only to reassert
> continued need; an error is returned indicating that
> documentLevel2 could
> not load)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR fieldLevel2 (new definition)
> RECOGNIZE
>  
> -------------------------
>  
> Furthermore, if the client believes that the server
> has sufficient storage
> capabilities, the existing protocol may be followed.
>  
> DEFINE-GRAMMAR documentLevel1 (new definition)
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR formLevel1 (new definition)
> DEFINE-GRAMMAR fieldLevel1 (new definition)
> RECOGNIZE
>  
> <time passes, but grammars are not flushed>
>  
> DEFINE-GRAMMAR documentLevel2 (new definition)
> DEFINE-GRAMMAR fieldLevel2 (new definition)
> RECOGNIZE
>  
> Here the client is taking a chance that RECOGNIZE
> will fail because a
> grammar is not available, but finds that an
> acceptable risk.  Were RECOGNIZE
> to return with 'grammar-load-failure', the client
> would still be able to
> recover - though the user might experience some
> undesired latency. 
>  
>  
>  
> 
>  
> 
> > _______________________________________________
> 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