RE: Control portion of SS protocol

Thanks Milan, this is a nice tight list.

A couple of minor tweaks to make the method list consistent with MRCP2-24:   (I assume 24 is the latest version?)

-          GET/SET-PARAMS are now listed as generic methods.

-          RECOGNITION-START-TIMERS has been re-named START-INPUT-TIMERS

I agree on the response & event list.  In addition, reco results would default to EMMA rather than NLSML

I generally agree on using the same list of headers.  When you said "except verification" I assume you mean those unique headers listed under the speaker verification feature?  The other thing I think we should remove is the cookie headers.  I recall we had a discussion on cookies at the F2F, and a number of us felt that it was inappropriate to give the service transitive use of the UA's cookies, and brainstormed an alternative mechanism.  Michael Bodell volunteered make a proposal.

I like the NOTIFY event.  Services could send it while processing any in-progress request.  We may want to introduce a mechanism for clients to only subscribe to certain events.  For example, all the Microsoft TTS engines can produce viseme events (e.g. http://dict.bing.com.cn/#%3Ahome, and click on the orange TV icon), but most apps wouldn't want to receive them.  This may be as simple as introducing a "subscribe" header that lists the custom events you want to receive.





From: Young, Milan [mailto:Milan.Young@nuance.com]
Sent: Friday, June 10, 2011 11:46 AM
To: Robert Brown; Satish Sampath (Google); gshires@google.com; Marc Schroeder (DFKI); Patrick Ehlen (AT&T); JOHNSTON, MICHAEL J (MICHAEL J)
Cc: Dan Burnett (Voxeo); HTML Speech XG
Subject: Control portion of SS protocol

Robert's draft referenced a few placeholder control methods and headers that were "inspired from MRCP".  This is a start at making these sections more concrete.

One notable omission is handling of continuous recognition results and corrections.  I will follow up on this section early next week.


---------------------------


Client Requests
For the contents of 'recognition-method', I suggest we use the following as defined by MRCP v2:
SET-PARAMS
GET-PARAMS
DEFINE-GRAMMAR
RECOGNIZE
RECOGNITION-START-TIMERS
STOP
INTERPRET

... and for 'synthesizer-method':
            SET-PARAMS
            GET-PARAMS
            SPEAK
            STOP
            PAUSE
            RESUME
            BARGE-IN-OCCURRED
            CONTROL
            DEFINE-LEXICON

I suggest we also add a recorder resource (this probably needs discussion in the API group).  Although there are other ways to pass recorded audio from client to server, doing it within the protocol has some nice advantages:
*         Consistent use of server-based endpointing and channel adaptation.
*         Shares the headers with the other control messages (eg timeouts, cookies, and channel-identifier).
*         Same network paths

'recorder-method' would be defined as per MRCP v2 using the following methods:
            RECORD
            STOP
            START-INPUT-TIMERS



Server Responses
Server request state should be exactly as defined by MRCP v2:
            COMPLETE
            IN-PROGRESS
            PENDING


For 'recognizer-event', I suggest we use the following as defined by MRCP:
            START-OF-INPUT
            RECOGNITION-COMPLETE
            INTERPRETATION-COMPLETE

... and for 'synthesizer-event'
            SPEECH-MARKER
            SPEAK-COMPLETE

...and for 'recorder-event'
            START-OF-INPUT
            RECORD-COMPLETE



Headers
I suggest that we use all the headers defined by MRCP v2 except those that are specific to verification.  Specifically, this means:
  * Generic (see http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-24#section-6.2).
  * Synthesizer (see http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-24#section-8.4)
  * Recognizer (see http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-24#section-9.4)
  * Recorder (see http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-24#section-10.4)

Appropriate use of these headers is defined as per MRCP v2 spec in the context of a specific method or response reference by this specification.



Server Notifications
Within MRCP v2, the server may only send message in response to a client-driven request.  Client polling via GET-PARAMS is the only option for "pushing" a message from the server to the client.

It's unclear whether server push through the HTML Speech protocol and API is required functionality.  These messages could, for example, be accomplished outside the specification using a separate WebSocket connection.  On the other hand, frameworks like MMI hinge on the ability for the server to proactively send state updates to the client.

If this is found to be convenient, then we may choose to add to our list of 'event-names' with a 'notification-event'.  This new event would use a status code of '200', and a request state of 'NOTIFY'.  The value of the 'Channel-Identifier' header would use a new resource type called 'notification'.   For example:

html-speech/1.0 92 323340 200 NOTIFY
Channel-Identifier: 817@notification
Content-Length: 36
Content-Type: text/xml

<?xml version="1.0"?>
<foo>bar</foo>

A couple notes:
  * If the [body] was detected as being XML or JSON, it would be nice if the client browser could automatically reflect the data as a DOM or EMCA object.  But I don't know much about that sort of technology, so would need someone else to comment.
  * The client would request notifications using the SDP-like setup protocol that Robert is working on.  Something like 'a=resource:notification'.
  * The client browser would not interpret any headers in the notification those required to parse the message (ie 'Content-Length', 'Content-Type', and 'Content-Encoding').
  * The request-id, Channel-Identifier, and other headers would be bundled up along with the body and handed to the webapp.  It would be up to the application to decide the meaning of such headers in the context of the notification.