RE: [Speechsc] Default support for TLS?

before

   =
A number of
   mechanisms exist to resolve this condition and the =
mechanism chosen
   is left to the implementers of recognition =
resource.  The =
recognizer
   SHOULD expect the media =
to start flowing when it receives =
the
   recognize request, but SHOULD NOT buffer anything =
it receives
   beforehand.
I believe that accept-charset header is missing from generic-header =
list:
generic-header      =
=3D    =
channel-identifier
       &nbs=
p;            =
;   /    =
accept
       &nbs=
p;            =
;   /    =
active-request-id-list
       &nbs=
p;            =
;   /    =
proxy-sync-id
       &nbs=
p;            =
;   /    =
content-id
       &nbs=
p;            =
;   /    =
content-type
       &nbs=
p;            =
;   /    =
content-length
       &nbs=
p;            =
;   /    =
content-base
       &nbs=
p;            =
;   /    =
content-location
       &nbs=
p;            =
;   /    =
content-encoding
       &nbs=
p;            =
;   /    =
cache-control
       &nbs=
p;            =
;   /    =
logging-tag
       &nbs=
p;            =
;   /    =
set-cookie
       &nbs=
p;            =
;   /    =
set-cookie2
       &nbs=
p;            =
;   /    =
vendor-specific

Should be =
(note the accept-charset =
added):

generic-header      =
=3D    =
channel-identifier
       &nbs=
p;            =
;   /    =
accept
       &nbs=
p;            =
;   /    =
active-request-Id-List
       &nbs=
p;            =
;   /    =
proxy-sync-Id
       &nbs=
p;            =
;   /    accept-charset
       &nbs=
p;            =
;   /    =
content-type
       &nbs=
p;            =
;   /    =
content-ID
       &nbs=
p;            =
;   /    =
content-base
       &nbs=
p;            =
;   /    =
content-encoding
       &nbs=
p;            =
;   /    =
content-location
       &nbs=
p;            =
;   /    =
content-length
       &nbs=
p;            =
;   /    =
cache-control
       &nbs=
p;            =
;   /    =
logging-tag
       &nbs=
p;            =
;   /    set-cookie =

       &nbs=
p;            =
;   /    =
set-cookie2
       &nbs=
p;            =
;   /    =
vendor-specific

Thanks,
Ilya =
Knyazhansky
Ilyak at =
nscspeech.com

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

“The sensitivity-level header is a float value between 0.0 =
and 1.0…”
sensitivity-level =
       =3D  =
"Sensitivity-Level" ":" FLOAT =
CRLF

In section =
10.4.1:
sensitivity-level =
   =3D     "Sensitivity-Level" =
":" 1*DIGIT CRLF

The language in section =
10.4.11 does not define the units for the =
Final-Silence parameter.  Presumably the values should denote a =
value in milliseconds.

Editorial note: =
s/milli-seconds/milliseconds/g  to fix sections such as =
10.4.10.
In section 10.4.12, the =
description notes that

    The value for this header =
is a Boolean.  
    The default value =
for this header is false.

but the =
BNF rule is

   =
capture-on-speech        =3D  =
"Capture-On-Speech " ":" 1*DIGIT =
CRLF
   =
capture-on-speech        =3D  =
"Capture-On-Speech " ":" boolean-value =
CRLF
input-type      =
;   =3D  "Input-Ttype" ":"  =
inputs CRLF
In the current language in 9.4.20, =
Fetch-Timout “MAY occur in =
RECOGNIZE, ‘SET-PARAMS’ or ‘GET-PARAMS’.” =
 Presumably, this parameter should also be available to grammars =
loaded via DEFINE-GRAMMAR.
In the current language in 9.4.20, Fetch-Timout “MAY =
occur in RECOGNIZE, ‘SET-PARAMS’ or =
‘GET-PARAMS’.”  Presumably, this parameter should =
also be available to grammars loaded via =
DEFINE-GRAMMAR.
I believe that =
accept-charset header is missing from =
generic-header list:
generic-header      =3D    =
channel-identifier
           &n=
bsp;           =
/    =
accept
           &n=
bsp;           =
/    =
active-request-id-list
           &n=
bsp;           =
/    =
proxy-sync-id
           &n=
bsp;           =
/    =
content-id
           &n=
bsp;           =
/    =
content-type
           &n=
bsp;           =
/    =
content-length
           &n=
bsp;           =
/    =
content-base
           &n=
bsp;           =
/    =
content-location
           &n=
bsp;           =
/    =
content-encoding
           &n=
bsp;           =
/    =
cache-control
           &n=
bsp;           =
/    =
logging-tag
           &n=
bsp;           =
/    =
set-cookie
           &n=
bsp;           =
/    =
set-cookie2
           &n=
bsp;           =
/    =
vendor-specific

Should be (note the =
accept-charset =
added):

generic-header      =
=3D    =
channel-identifier
           &n=
bsp;           =
/    =
accept
           &n=
bsp;           =
/    =
active-request-Id-List
           &n=
bsp;           =
/    =
proxy-sync-Id
           &n=
bsp;           =
/    =
accept-charset
           &n=
bsp;           =
/    =
content-type
           &n=
bsp;           =
/    =
content-ID
           &n=
bsp;           =
/    =
content-base
           &n=
bsp;           =
/    =
content-encoding
           &n=
bsp;           =
/    =
content-location
           &n=
bsp;           =
/    =
content-length
           &n=
bsp;           =
/    =
cache-control
           &n=
bsp;           =
/    =
logging-tag
           &n=
bsp;           =
/    =
set-cookie 
           &n=
bsp;           /    =
set-cookie2
           &n=
bsp;           =
/    =
vendor-specific

Thanks,
Ilya Knyazhansky
Ilyak at =
nscspeech.com

“The sensitivity-level header is a float =
value between 0.0 and =
1.0…”
sensitivity-level        =
=3D  "Sensitivity-Level" ":" FLOAT =
CRLF

In section 10.4.1:
sensitivity-level    =
=3D     "Sensitivity-Level" ":" 1*DIGIT =
CRLF

The =
language in section 10.4.11 does not define the units =
for the Final-Silence parameter.  Presumably the values should =
denote a value in milliseconds.

Editorial note: =
s/milli-seconds/milliseconds/g  to fix sections such as =
10.4.10.
In section =
10.4.12, the description notes =
that

    The =
value for this header is a Boolean.  =

    The =
default value for this header is =
false.

but the BNF rule =
is

   =
capture-on-speech        =3D  =
"Capture-On-Speech " ":" 1*DIGIT CRLF
   =
capture-on-speech        =3D  =
"Capture-On-Speech " ":" boolean-value =
CRLF
input-type         =
=3D  "Input-Ttype" ":"  inputs =
CRLF
   A number =
of
   mechanisms exist to =
resolve this condition and the mechanism =
chosen
   is left to the =
implementers of recognition resource.  The =
recognizer
   SHOULD expect the media to start flowing when =
it receives the
   recognize request, but SHOULD NOT buffer anything =
it receives
   beforehand.
    To ensure control channel =
protection, MRCPv2 clients
    and servers MUST support =
TLS and SHOULD utilize it
    by default.  =
Alternative control channel =
protection
    MAY be used if desired =
(e.g. IPSEC).
    To ensure control channel =
protection, MRCPv2 clients
    and servers MUST support =
TLS and SHOULD utilize it
    by default.  =
Alternative control channel =
protection
    MAY be used if desired =
(e.g. IPSEC).
    To =
ensure control channel protection, MRCPv2 =
clients
    and servers =
MUST support TLS and SHOULD utilize =
it
    by =
default.  Alternative control channel =
protection
    MAY be used =
if desired (e.g. IPSEC).
    To ensure control channel =
protection, MRCPv2 clients
    and servers MUST support =
TLS and SHOULD utilize it
    by default.  =
Alternative control channel =
protection
    MAY be used if desired =
(e.g. IPSEC).
    To =
ensure control channel protection, MRCPv2 =
clients
    and servers =
MUST support TLS and SHOULD utilize =
it
    by =
default.  Alternative control channel =
protection
    MAY be used =
if desired (e.g. IPSEC).
    To ensure control channel =
protection, MRCPv2 clients
    and servers MUST support =
TLS and SHOULD utilize it
    by default.  =
Alternative control channel =
protection
    MAY be used if desired =
(e.g. IPSEC).

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

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. 