Subject: [Speechsc] Issues around grammar lifetimes

From: "Carter, Jerry" <[email-masked]>
Date: Fri, 24 Mar 2006 11:24:36 -0500

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