Subject: RE: [Speechsc] Managing big grammars

From: "Wyss, Felix" <[email-masked]>
Date: Wed, 15 Jun 2005 09:09:51 -0500

> 1. If the MRCP server temporarily uses stale content in an effort to
avoid
> latency then it is reasonable that the DEFINE-GRAMMAR/RECOGNISE
complete
> response/event includes a warning. RFC2616 would suggest we return
> something
> like:
> 
>     Warning: 110 10.0.0.1 Response is stale

[Felix I. Wyss] I'm fine with that

> 2. Allowing DEFINE-GRAMMAR or RECOGNIZE to prefer reduced latency over
> accuracy seems fine. I'd posit that the default action is to prefer
> reduced
> latency. To enforce accuracy (e.g. as one might want during
development
> and
> testing of an application), a Cache-Control: max-stale=0 could be
used. I
> can't convince myself that we need an option to fail if a resource is
not
> in the cache.

[Felix I. Wyss] Using max-stale=0 on the DEFINE-GRAMMAR request seems
reasonable to me.  

Without an the ability to have DEFINE-GRAMMAR fail immediately if an
item is not in the cache (i.e. probing the cache), clients will have to
use timeouts in their MRCP stack if they want to enforce an upper bound
on grammar registration latency and provide automatic fallback.  It just
seems it'd be really easy for the server to provide this information.  

> 
> 3. Disallowing a grammar in an MRCP session to change outside of that
> session's invocation DEFINE-GRAMMAR or RECOGNIZE (due to a
revalidation in
> a different MRCP session) seems perfectly reasonable.

[Felix I. Wyss] It's a MUST then, right?

> 
> 4. Given that latencies are much more detrimental to VUIs than GUIs,
it
> seems reasonable to make caching a SHOULD. Fancy optimisations such as
a
> centralised cache and informing other servers in a cluster to reload
seem
> like they ought to remain MAYs. Going for SHOULD over MUST seems
> reasonable
> to me to allow dtmfrecog and low-end speechrecogs. Ref. David's
comment
> about protocol engineering encroaching on system engineering.

[Felix I. Wyss] I can live with that.  

I recommend that there be a discussion on grammar registration latency
and caching strategies in the specification to ensure implementers (both
servers and clients) are aware of the issues.  

Felix

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

---

From: "Dave Burke" <[email-masked]>
Date: Wed, 15 Jun 2005 21:53:35 +0100

Inline.

Dave

----- Original Message ----- 
From: "Wyss, Felix" <[email-masked]>
To: "Dave Burke" <[email-masked]>; "Bennett, Patrick" 
<[email-masked]>; "David R. Oran" <[email-masked]>
Cc: "Reifenrath, Klaus" <[email-masked]>; 
<[email-masked]>; "Shanmugham, Saravanan" <[email-masked]>
Sent: Wednesday, June 15, 2005 3:09 PM
Subject: RE: [Speechsc] Managing big grammars

avoid
complete

development
used. I
not

[Dave B] . If you invoke DEFINE-GRAMMAR with some kind of
header to indicate fail if the object is not in the cache, is the MRCP
server to go fetch it anyway for future use? Should this mechanism
fail if the grammar is an intermediate cache somewhere between the
MRCP server and HTTP origin server? 

revalidation in

[Dave B] I agree that the spec MUST not allow weird things to happen!

it
a
seem
comment

Felix