Subject: RE: [Speechsc] Issues around grammar lifetimes

From: "Carter, Jerry" <[email-masked]>
Date: Mon, 1 May 2006 09:27:06 -0400

Sarvi:

Thanks for the detailed response.  I have given your proposal considerable
review and like a number of elements.  I believe that it is workable with
one small change: the client should be able to release a grammar by sending
the ID without a body.

This simplifies the client implementation.  As an example, consider a VXML
browser.  On a page transition, the browser might issue a DEFINE to release
grammars from the old page followed by a second DEFINE to load the grammars
for the new page.  Having the ability to send an empty grammar body removes
the requirement for the client to track old IDs.

Other comments are inline.

> -----Original Message-----
> From: Shanmugham, Saravanan [mailto:[email-masked]]
> Sent: Thursday, April 13, 2006 12:51 AM
> To: Carter, Jerry; David R Oran
> Cc: [email-masked]; Burger, Eric
> Subject: RE: [Speechsc] Issues around grammar lifetimes
> 
> Where I was going with my response was to propose clarifying the
> specification with some normative statements as follows.
> 
> 1. The MRCP server MUST load and compile all grammars specified through
> a DEFINE-GRAMMAR method.

The current language is 'SHOULD' which I believe is preferable to 'MUST'.
If a grammar referenced by DEFINE is uncachable, the implementation should
be permitted to defer load (and optional compile) until the grammar needs to
be used.

> 2. The server MUST store the inline grammar block associated with the
> "session:" URI through a DEFINE-GRAMMAR method on the server for the
> life of the session.

Mandating lifetime storage is an improvement over the current ambiguity but
based on implementation experience with MRCP v1 and v2, I continue to have
reservations that might be appropriately addressed AFTER a Proposed Standard
is published.

The addition of an explicit mechanism by which the client can release
grammars is a nice step forward.  The client has explicit and usually
session-specific knowledge of what grammars are immediately needed and
possibly of which will be necessary in the future.  Likewise, the server has
an explicit knowledge that spans possibly hundreds of sessions and may track
historical access patterns.  If the server runs out of space, who is best
positioned to decide which grammars to clear?  The current language
restricts the ability of the server to gracefully recover.

You make a distinction between server cache and session storage which may
simplify the language in the specification.  Theoretically, a MRCP server
could divide its finite resources into a common cache and individual session
storage spaces.  In practice, however, servers do not make any such
distinction.  Large servers typically handle dozens or hundreds of
simultaneous sessions for which grammars are frequently shared across
sessions.  These are stored in a common pool.  Whether or not grammars are
defined using the session mechanism is merely another input for the caching
algorithm.  A requirement for session-lifetimes requires an MRCP-specific
caching implementation.  Certainly this is not a deal breaker, but it does
impose an unfortunate cost on server implementations.

Again, for clarity, a mandated lifetime and an ability for the client to
release grammars are good steps forward.  Whether further steps are
necessary may be decided AFTER a Proposed Standard is published.

> 2.1 I am wondering if it would make sense also enforce the download and
> storage of external URI referenced by the inline-grammar for the life of
> the session: URI.

This should be unnecessary.  The MRCP specification should treat grammars as
single entities.  References within a grammar must be dealt with as required
by the grammar format.
 
> 3. If the "session:" URI is redefined within the session through a
> subsequent DEFINE-GRAMMAR, the inline grammar previously associated with
> the "session:" URI MUST be freed.

As I've noted above, this is a great addition to the specification that can
be improved by allowing a DEFINE with an empty body to explicitly clear a
previous ID.

> 4. The server MAY store the compiled version of this inline grammar
> block.

Implementation dependent; the MRCP v2 specification need not contain this
statement.

> 5. If there is no space on the server to store the inline grammar, the
> DEFINE-GRAMMAR should return a response status code of 411 - Resource
> unavailable.

I would prefer a more explicit error code for this case.  Resource
unavailable is often used 'out of licenses' and other situations.

> 6. The server MUST implement a cache for external grammars referenced
> through a URI.

What impact would this statement have?  So long as the grammar is available
by RECOGNIZE and follows the cache control rules, why should the MRCP
specification dictate this?

> 7. The MRCP server MUST cache either the downloaded grammar document or
> the compiled object of the downloaded grammar document, within the
> limits and enforcement of the cache control parameters associated with
> the session.

If this statement is just requiring that the cache control rules be
enforced, is there any reason to say this again? 
 
> This allows for a couple of things to be resolved. Separates Caching of
> grammars from definition/storage of grammars.
>   1. We leave caching of grammars under the control of the server with
> the client providing only cache control parameters already defined in
> MRCP.
>   2. The life of a defined-grammar, essentially the "session:" URI, is
> clearly defined.
>   3. If response to be seen by the client if there is no space to make
> such a definition is also clearly defined.
> 
> Thanks,
> Sarvi
> 
> 
>      -----Original Message-----
>      From: Carter, Jerry [mailto:[email-masked]]
>      Sent: Wednesday, April 12, 2006 6:55 PM
>      To: Shanmugham, Saravanan; David R Oran
>      Cc: [email-masked]; Burger, Eric
>      Subject: RE: [Speechsc] Issues around grammar lifetimes
> 
>      As I wrote in my original email, I don't see the language
>      in section 13.7 as making any normative statement
>      requiring availability for a session lifetime.  The
>      language signals intent but does not mandate.  And in this
>      case, I believe intent is the correct position for the
>      specification to take.
> 
>      If I read your response correctly, you seem to be
>      suggesting that MRCP servers are not, in practice, ever
>      resource constrained.  Such a view would be woefully
>      removed from the implementation realities.  My concern
>      stands whether one considers text grammars or compiled
>      forms, disk caches or memory storage, static or dynamic
>      content.  MRCP server implementations do on occasion need
>      to purge old grammars from storage.  If the purged
>      grammars are never again referred to by the client, there
>      are no problems.  But if the client does attempt to
>      reference a purged grammar, the MRCP v2 specification does
>      not appear to provide any notification mechanism.  That is
>      a significant deficiency of the specification.
> 
> 
>      As for your comments on grammar references and caching
>      semantics, that is a separate topic with orthogonal concerns.
> 
>      > -----Original Message-----
>      > From: Shanmugham, Saravanan [mailto:[email-masked]]
>      > Sent: Wednesday, April 12, 2006 7:19 PM
>      > To: Carter, Jerry; David R Oran
>      > Cc: [email-masked]; Burger, Eric
>      > Subject: RE: [Speechsc] Issues around grammar lifetimes
>      >
>      >
>      > The main purpose of the DEFINE-GRAMMAR was to give the
>      MRCP server an
>      > opportunity to define and compile inline-grammar blocks
>      that might be
>      > specified and reused multiple times in a RECOGNIZE. Such
>      grammars are
>      > associated with a "session:" URI and is expected to be
>      accessible for
>      > the life of the session. The "lifetime of the session" was
>      > specifically meant for such inline-grammar blocks. This
>      grammar SHOULD
>      > NOT be in "Cache" but in storage associated with the
>      session and are
>      > not "cachedout" though they could be redefined by another
>      > DEFINE-GRAMMAR operation which redefines the "session:"
>      URI with a
>      > new block of inline-grammar.
>      >
>      > Additionally, the DEFINE-GRAMMAR is alo expected to
>      fetch and compile
>      > external URI based grammars which gives the client to
>      make sure the
>      > grammar is accessible to the MRCP server and also
>      compilable. Once
>      > compiled such grammar are placed in the "Cache". Such
>      grammars may be
>      > cached out by other DEFINE-GRAMMAR/RECOGNIZE methods. The
>      > implementation and management of this cache is upto the
>      MRCP server.
>      > It could choose to cache only the grammar or a
>      compilation of the grammar.
>      >
>      > Also, note that for inline grammars associated with
>      "session:" URI
>      > refered in the first paragraph, the inline grammar block
>      could them
>      > selves have references to external grammar URI. The
>      server MUST store
>      > the grammar block associated with the "session:" URI for
>      the life of
>      > the session. But it is not a MUST for the server to
>      store all external
>      > URI grammars referenced from within the "session:"
>      inline grammar
>      > block. But note that all external grammar URI
>      references(even those
>      > embedded within inline grammar blocks assocaited with
>      "session:" URI)
>      > have to follow the Caching Parameters.
>      >
>      > Sarvi
>      >
>      >      -----Original Message-----
>      >      From: Carter, Jerry [mailto:[email-masked]]
>      >      Sent: Wednesday, April 12, 2006 8:14 AM
>      >      To: David R Oran
>      >      Cc: [email-masked]; Burger, Eric
>      >      Subject: RE: [Speechsc] Issues around grammar lifetimes
>      >
>      >      I'm not proposing that the client have control over
>      >      grammar lifetimes.  I am offering a notification and
>      >      recovery proposal with clarifying language describing
>      >      server behavior.
>      >
>      >      Adding two lines to the example,
>      >
>      >      DEFINE-GRAMMAR Large_1
>      >      DEFINE-GRAMMAR Large_2
>      >      DEFINE-GRAMMAR Small_3
>      >      RECOGNIZE (against Large_1, Large_2, Small_3)
>      >      DEFINE-GRAMMAR Large_4 RECOGNIZE (against Large_4)
>      >      DEFINE-GRAMMAR Large_5 RECOGNIZE (against Large_5)
>      >      DEFINE-GRAMMAR Large_6 RECOGNIZE (against Large_1,
>      >      Small_3, Large_6)  [FAILS] DEFINE-GRAMMAR Large_1
>      >      RECOGNIZE (against Large_1, Small_3, Large_6)  [SUCCEEDS]
>      >
>      >      if the client knows what grammars are unavailable,
>      >      recovery via re-DEFINE-GRAMMAR is possible.
>      >
>      >      As waiting until RECOGNIZE is usually too late, the
>      >      original email discusses use of DEFINE-GRAMMAR to signal
>      >      continued interest without passing the entire grammar
>      >      definition over the wire.
>      >
>      >      > -----Original Message-----
>      >      > From: David R Oran [mailto:[email-masked]]
>      >      > Sent: Wednesday, April 12, 2006 11:07 AM
>      >      > To: Carter, Jerry
>      >      > Cc: Burger, Eric; [email-masked]
>      >      > Subject: Re: [Speechsc] Issues around grammar lifetimes
>      >      >
>      >      > This strikes me as something that should not be exposed
>      >      to the client
>      >      > unless there is really strong reason to believe that the
>      >      client can do
>      >      > a better job of managing server resources than the
>      >      server can itself.
>      >      >
>      >      > Dave (chair hat off)
>      >      >
>      >      > On Apr 12, 2006, at 10:19 AM, Carter, Jerry wrote:
>      >      >
>      >      > > As I discussed, MRCP servers have finite resources
>      >      available.  When
>      >      > > an MRCP server is asked to track several large
>      >      grammars, it may be
>      >      > > necessary to purge older grammars from cache to
>      process new
>      >      > > requests.  Consider this
>      >      > > case:
>      >      > >
>      >      > > DEFINE-GRAMMAR Large_1
>      >      > > DEFINE-GRAMMAR Large_2
>      >      > > DEFINE-GRAMMAR Small_3
>      >      > > RECOGNIZE (against Large_1, Large_2, Small_3)
>      >      DEFINE-GRAMMAR Large_4
>      >      > > RECOGNIZE (against Large_4) DEFINE-GRAMMAR
>      Large_5 RECOGNIZE
>      >      > > (against Large_5) DEFINE-GRAMMAR Large_6 RECOGNIZE
>      >      (against Large_1,
>      >      > > Small_3, Large_6) << What happens?
>      >      > >
>      >      > > The session starts and recognition occurs against
>      >      several grammars.
>      >      > > The second recognition (perhaps a modal VXML dialog)
>      >      requires only a
>      >      > > single grammar.  Likewise, the third recognition
>      >      (perhaps another
>      >      > > modal VXML
>      >      > > dialog) requires only a single grammar.  For the final
>      >      recognition,
>      >      > > another large grammar is required.  If the MRCP server
>      >      is resource
>      >      > > constrained, one or more of the earlier grammars will
>      >      be flushed
>      >      > > from cache to make space for the new grammar.  Let's
>      >      assume that
>      >      > > Large_1 gets flushed; the RECOGNIZE will fail.
>      >      > >
>      >      > > As I discussed, there is no language in the
>      MRCP specification
>      >      > > describing grammar lifetimes nor do I see any
>      >      notification mechanism
>      >      > > that would informing the client of which grammars are
>      >      unavailable to
>      >      > > permit a recovery.
>      >      > > I see this as a serious and significant deficiency.
>      >      > >
>      >      > > For additional comments and a proposed solution, I
>      >      refer back to the
>      >      > > 24 March email.
>      >      > >
>      >      > >
>      >      > >> -----Original Message-----
>      >      > >> From: Burger, Eric [mailto:[email-masked]]
>      >      > >> Sent: Saturday, April 08, 2006 11:00 PM
>      >      > >> To: Carter, Jerry
>      >      > >> Cc: [email-masked]
>      >      > >> Subject: RE: [Speechsc] Issues around grammar lifetimes
>      >      > >>
>      >      > >>>>> 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. <<<
>      >      > >>
>      >      > >> Under what circumstance would an MRCP server
>      *not* retain the
>      >      > >> grammar?  If you cannot think of one, and this is
>      >      important, than
>      >      > >> an MRCP server MUST retain grammars until the next
>      >      RECOGNIZE.
>      >      > >> Conversely, if there are too many
>      circumstances when the MRCP
>      >      > >> server would not retain the grammar, there is no
>      >      point saying it
>      >      > >> should, because implementers will do whatever they
>      >      want, anyway.
>      >      > >>
>      >      > >> In general, if we have a statement that X SHOULD do
>      >      Y, then in the
>      >      > >> same paragraph one needs to enumerate when X
>      would NOT do Y.
>      >      > >>
>      >      > >> ________________________________________
>      >      > >> From: Carter, Jerry [mailto:[email-masked]]
>      >      > >> Sent: Friday, March 24, 2006 11:25 AM
>      >      > >> To: [email-masked]
>      >      > >> Subject: [Speechsc] Issues around grammar lifetimes
>      >      > >>
>      >      > >> 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
>      >
>      >      _______________________________________________
>      >      Speechsc mailing list
>      >      [email-masked]
>      >      https://www1.ietf.org/mailman/listinfo/speechsc
>      >
> 

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