Subject: RE: [Speechsc] Issues around grammar lifetimes

From: "Burger, Eric" <[email-masked]>
Date: Sat, 8 Apr 2006 23:00:25 -0400

>>> 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

---

From: "Carter, Jerry" <[email-masked]>
Date: Wed, 12 Apr 2006 11:13:32 -0400

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.
> >>
> >> 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
> >> 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
> >>
> >> 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.
> >>
> >>
> >> (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'.
> >>
> >> <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)
> >> Furthermore, if the client believes that the server has sufficient
> >> storage
> >> capabilities, the existing protocol may be followed.
> >>
> >> 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.
> >>
> >
> >

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 12 Apr 2006 16:18:44 -0700

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.

     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.
     
     > 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.
     > > 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
     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
     > > 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.
     > >
     > > describing grammar lifetimes nor do I see any 
     notification mechanism 
     > > that would informing the client of which grammars are 
     unavailable to 
     > > permit a recovery.
     > > For additional comments and a proposed solution, I 
     refer back to the 
     > > 24 March email.
     > >>>>> An MRCP server SHOULD retain grammars on each 
     session created by 
     > >>>>> a
     > >> retain grammars for much longer. <<<
     > >>
     > >> 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.
     > >> same paragraph one needs to enumerate when X would NOT do Y.
     > >>
     > >> 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
     > >> 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.
     > >>
     > >> 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
     > >> 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.
     > >>
     > >>
     > >> 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.
     > >>
     > >>
     > >> by a DEFINE-GRAMMAR message until at least the next 
     RECOGNIZE.  It 
     > >> MAY retain grammars for much longer.
     > >>
     > >> 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.
     > >>
     > >> 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
     > >>
     > >> DEFINE-GRAMMAR documentLevel1 (new definition) DEFINE-GRAMMAR 
     > >> documentLevel2 (new definition) DEFINE-GRAMMAR 
     formLevel1 (new 
     > >> definition) DEFINE-GRAMMAR fieldLevel1 (new 
     definition) RECOGNIZE
     > >> reassert continued need; an error is returned indicating that
     > >> documentLevel2 could
     > >> not load)
     > >> DEFINE-GRAMMAR documentLevel2 (new definition) DEFINE-GRAMMAR 
     > >> fieldLevel2 (new definition) RECOGNIZE
     > >>
     > >> 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
     > >> 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.

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 12 Apr 2006 16:30:29 -0700

I sent an earlier response talking about the difference between grammar
storage for inline-grammars associated  "session:" URI and grammar cache
for external URI reference. 

We could simply clarify that when an "session:" URI is defined, compiled
and stored, any external URI references within it are also downloaded
and compile and stored(NOT cached) for the lifetime of the "session:"
URI, which is the life of the session.

Even in this case, when that particular "session:" URI is re-defined
through a DEFINE-GRAMMAr method, and the external URI in the new inline
block are loaded/stored and the external gramars previously
loaded/stored are removed. Where such external grammars are
loaded/stored, whether in cache or a separate storage is totally up to
the server implementation.

Thx,
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

     
     DEFINE-GRAMMAR Large_1
     DEFINE-GRAMMAR Large_2
     DEFINE-GRAMMAR Small_3

     
     client can do 
     server can itself.
     grammars, it may be 
     DEFINE-GRAMMAR Large_4 
     (against Large_1, 
     several grammars.  
     requires only a 
     (perhaps another 
     is resource 
     be flushed 
     assume that 
     notification mechanism 
     unavailable to 
     refer back to the 
     session created by 
     important, than 
     RECOGNIZE.  
     point saying it 
     want, anyway.
     MRCP client might 
     available when 
     client of 
     the session URI 
     finite cache and 
     unreasonable to 
     large cache 
     particularly if sessions 
     requirement 
     Presumably a 
     returned.  The 
     message but this 
     Additionally, 
     RECOGNIZE is invoked 
     instead require that 
     only until the 
     RECOGNIZE.  It 
     appropriate for this 
     completion cause of 
     formLevel1 (new 
     definition) RECOGNIZE
     formLevel1 (IDs only 
     formLevel1 (new 
     definition) RECOGNIZE
     > >> DEFINE-GRAMMAR documentLevel1 documentLevel2 
     formLevel1 (only to 
     formLevel1 (new 
     definition) RECOGNIZE
     will fail because 
     acceptable risk.  
     the client 
     might experience

---

From: "Carter, Jerry" <[email-masked]>
Date: Wed, 12 Apr 2006 21:55:05 -0400

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.

> From: Shanmugham, Saravanan [mailto:[email-masked]]
> Sent: Wednesday, April 12, 2006 7:19 PM
> To: Carter, Jerry; David R Oran
> specified and reused mu size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C65E9D.4914B2CC--

--===============1328135067==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1328135067==--

---

From: "Carter, Jerry" <[email-masked]>
Date: Wed, 12 Apr 2006 21:55:05 -0400

>      > > RECOGNIZE (against Large_4) DEltiple times in a RECOGNIZE. Such grammars are
>      > >> require that the MRCFINE-GRAMMAR Large_5 RECOGNIZE
>      >P server provision a sufficiently
>      large cache

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 12 Apr 2006 21:51:08 -0700

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. 
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. 
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.
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. 4. The server MAY store the compiled
version of this inline grammar block. 
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.

6. The server MUST implement a cache for external grammars referenced
through a URI.  
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.

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.
     
     > 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.
     > 
     > 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.
     > 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
     > 
     >      > >>       the lifetime of the session with the 
     entity storing the
     >      > >> resource.
     >      > >>    Clients SHOULD NOT interpret the completion 
     reason text.
     >      > >> Instead it
     >      > >>    otherwise made available for debugging and 
     instrumentation
     >      > >> purposes.
     DEFINE-GRAMMAR
     >      > >> to reassert continued need) DEFINE-GRAMMAR 
     fieldLevel2 (new
     DEFINE-GRAMMAR
     >      > >> DEFINE-GRAMMAR documentLevel2 (new definition) 
     DEFINE-GRAMMAR
     >      > >> DEFINE-GRAMMAR documentLevel1 (new definition) 
     DEFINE-GRAMMAR
     >      > >> DEFINE-GRAMMAR documentLevel2 (new definition) 
     DEFINE-GRAMMAR

---

From: "Burger, Eric" <[email-masked]>
Date: Tue, 18 Apr 2006 17:51:24 -0400

How large are the grammar files?

-----Original Message-----
From: Carter, Jerry [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2006 9: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.

> the life of the session. The "lifetime of the session" was
specifically
> cached out by other DEFINE-GRAMMAR/RECOGNIZE methods. The
implementation
>      > >>       the lifetime of the session with the entity storing
the
instrumentation
DEFINE-GRAMMAR
DEFINE-GRAMMAR
DEFINE-GRAMMAR
DEFINE-GRAMMAR
DEFINE-GRAMMAR