RE: Protocol call tomorrow

Task #6 - Parameters

 

My recommendation is to use MRCP v2 "stickiness" semantics for all of
those parameters defined within that spec.  In general, this means that
writeable parameters set with a SET-PARMS are good until a subsequent
SET-PARAMs overwrites the value or the session ends.  Authors are free
to supply an "override" value for a particular method, but that last
value is implicitly restored when that method transaction completes.

 

The parameters which are specific to the HTML Speech protocol should
follow the same paradigm.  We may decide, however, that some of the
parameters like "audio-codec" may not be used for a method override.  A
few additional comments:

*        I don't understand why we would prevent
"active/inactive-grammars" from being included in SET-PARAMS.   Not so
much that there is a strong use case for doing this, but singling this
out breaks consistency.

*        Should note that the "Stream-ID" synthesis parameter is
read-only.

*        MRCP v2 uses case-insensitive parameter names.  Suggest we
follow suite with HTML Speech parameters.

 

Regarding standardizing URI parameters, I think we agreed to push that
out to the next major version of the protocol spec.

 

 


Task #8 - Inactive Grammars

 

Let's start by defining an inactive grammar.  In my thinking, this is
some grammar which was at one time loaded and parsed by the service, but
is not presently active in a request.  Such grammar made their way into
the service in one of two ways:

  DEFINE-GRAMMAR  - Handles to these grammars SHOULD be held by the
client.  If the client somehow looses track of this list, it can always
re-issue the DEFINE-GRAMMAR request, and this MUST not result in a
service error as long as the mapping is consistent with the original
request.  Once in place, the handle definition MUST be honored by the
service for the duration of the session.  If the service runs low on
resources, it is free to unload the handle's payload, but it must always
continue to honor the handle as though the payload were still available
(performance not withstanding).

  LISTEN/SET-GRAMMR - The now inactive grammar was once an active
grammar in a request.  Unlike explicitly DEFINEd grammars, such grammars
do not have handles that persist past the scope of the parent request.

 

Assuming we agree on the above, the use case for reporting inactive
grammars is slim.  I find it unlikely that a client would ever need to
read this value as it would probably already have that information in
memory.  For that matter, reporting the active grammar list is probably
unnecessary for the same reason, but at least the active-grammar list is
useful for logging and so should remain.

 

 

 

Other Thoughts

*        I wasn't present when it was decided to rename RECOGNIZE to
LISTEN.  I'm not sure if I support this move, but either way it probably
makes sense that the completion state (currently RECOGNITION-COMPLETE)
would use the same naming convention.

*        Vendor-Specific-Parameters was another casualty in my absence.
This seems to be a pretty easy parameter to spec so I don't understand
why it was pulled.  Perhaps we can discuss this on the next call.

 

 

Thanks

 

 

 

From: Robert Brown [mailto:Robert.Brown@microsoft.com] 
Sent: Wednesday, August 10, 2011 2:29 PM
To: Michael Johnston (AT&T); Patrick Ehlen (AT&T); Dan Burnett (Voxeo);
Marc Schroeder (DFKI); Young, Milan
Cc: HTML Speech XG
Subject: Protocol call tomorrow

 

There won't be a protocol call tomorrow. I figure SpeechTek will have
some people distracted, and we still have work-items assignments from
last week to get through before we bite off anything else.

 

Rather than have the call, please refer to the list below, and reply
with ETA for your work items if you have any. (The ETA for my stuff is
Tuesday 16th.)

 

Thanks,

 

/Rob

 

-- Michael:

 

1.       TODO: Add a sentence or two about the higher level motivation.
[Michael Johnston]

4.       TODO: Write the rationale for why we mix media and signal in
the same session. [Michael Johnston]

10.   TODO: no match is returned, is the EMMA no-match document
required? [Yes. Michael will provide an example of uninterpreted]

11.   TODO: Insert some EMMA document examples.

[Michael - a 1-best example, an n-best example, and a lattice example]

 

-- Milan:

 

6.       TODO: Specify which headers are sticky. URI request parameters
aren't standardized. [Milan]

 

8.       TODO: Should GET-GRAMMARS also return the list of inactive
grammars/rules? It's not clear how that would be useful. Also, the list
of inactive rules could be rather long and unwieldy [Milan will review
this]

 

-- Robert:

 

2.       TODO: add a section on security. Include authentication,
encryption, transitive authorization to fetch resources. [Robert Brown]

7.       TODO: Specify Completion-Cause value for no input stream.

[Robert - pick something away from the existing values]