RE: proposed plan for protocol group

SET-PARAMS is a back door for sending arbitrary events from client to
server.  But I agree that communication from server to client is limited
to client polling (ie GET-PARAMS) in the current protocol proposal.

I could see the lack of native server eventing causing problems in an
MMI architecture.  So perhaps you are right that this is something that
should be considered.  On the other hand, I want to be careful not to
invent functionality that is outside the scope of the API.  At present,
I think the API is assuming server events are in response to client
requests, but perhaps this is still up for debate.

Outside of server events, do you have other specific concerns with the
structure of MRCP?

Thanks


-----Original Message-----
From: JOHNSTON, MICHAEL J (MICHAEL J) [mailto:johnston@research.att.com]

Sent: Wednesday, June 08, 2011 12:39 PM
To: Young, Milan
Cc: Robert Brown; Satish Sampath (Google); gshires@google.com; Marc
Schroeder (DFKI); EHLEN, PATRICK (ATTSI); HTML Speech XG; Dan Burnett
(Voxeo); Michael Bodell
Subject: Re: proposed plan for protocol group

I think we should take care in the way
borrow from MRCP so that we do not end
unnecessarily limiting the use of the protocol. 
For example, in addition to the established
MRCP control messages we should also
include support for an arbitrary general 
control message that can be used for use
cases not covered by MRCP.

Michael


On Jun 8, 2011, at 2:26 PM, Young, Milan wrote:

> Thank you for putting this together Robert.
> 
> As a design philosophy, I suggest we stay with the required/proven
> portions of the MRCP spec rather than open it up to the peripheral.
> Agreeing on optional reco-methods like GET-RESULT is probably risky
> given our short runway.
> 
> I know this is an early draft, but I wanted to make sure that we are
> planning to require support for the standard headers on the control
> messages.  These are defined in section 6.2 of the MRCP V2 spec
> (http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-24#section-6.2)
> 
> I'd also like to know more about how I can help authoring this
document.
> One thought is to demonstrate the various control messages that would
be
> passed in the course of a simple application.
> 
> And yes, I'm available for our call tomorrow.
> 
> Thanks
> 
> 
> -----Original Message-----
> From: Robert Brown [mailto:Robert.Brown@microsoft.com] 
> Sent: Friday, June 03, 2011 6:21 PM
> To: Robert Brown; Young, Milan; Satish Sampath (Google); Glen Shires
> (gshires@google.com); Marc Schroeder (DFKI); Patrick Ehlen (AT&T)
> Cc: HTML Speech XG; Dan Burnett (Voxeo); Michael Bodell; Michael
> Johnston (AT&T)
> Subject: RE: proposed plan for protocol group
> 
> I've attached a short document outlining the basic approach I have in
> mind.
> 
> If you're in the protocol group, please review and comment.  (comments
> from others welcome too)
> 
> - thanks
> 
> -----Original Message-----
> From: public-xg-htmlspeech-request@w3.org
> [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Robert Brown
> Sent: Thursday, June 02, 2011 9:19 AM
> To: Milan Young (Nuance); Satish Sampath (Google); Glen Shires
> (gshires@google.com); Marc Schroeder (DFKI); Michael Johnston (AT&T)
> Cc: HTML Speech XG; Dan Burnett (Voxeo); Michael Bodell
> Subject: RE: proposed plan for protocol group
> 
> Thanks for this morning's call.
> 
> Here are my notes
> 
> Overall plan
> - Add Glen and Patrick to the list of protocol participants.
> - We agreed on the scope that I sent out on Wednesday
> - We agreed on the schedule outlined below.
> - If we can't stabilize the protocol spec on the schedule below, we
> should change the plan to ensure we express the detailed requirements.
> (RB: I suggest we decide this in July)
> - Please don't incorporate anything that potentially has IP issues
> associated with it.
> 
> Basic design approach
> - Robert will send a document this week, as noted below
> - We had some discussion on the choice of MRCP.  We won't
nececessarily
> copy MRCP2, but should be inspired by it.
> 
> Protocol requirements
> - Marc volunteers to take a first pass at pulling together the
protocol
> requirements from what we already have, and will get a first draft in
> the next two weeks, maybe sooner.  (RB: thanks Marc!)
> 
> 
> 
> ________________________________________
> From: public-xg-htmlspeech-request@w3.org
> [public-xg-htmlspeech-request@w3.org] on behalf of Robert Brown
> [Robert.Brown@microsoft.com]
> Sent: Wednesday, June 01, 2011 5:32 PM
> To: Milan Young (Nuance); Satish Sampath (Google); Glen Shires
> (gshires@google.com); Marc Schroeder (DFKI); Michael Johnston (AT&T)
> Cc: HTML Speech XG; Dan Burnett (Voxeo); Michael Bodell
> Subject: proposed plan for protocol group
> 
> Here's how I'd like to tackle the protocol work.  If you're in the
> protocol group (or just interested), please read through this and
> suggest any tweaks as appropriate.  We'll also discuss this in
> tomorrow's conf call.
> 
> Thanks,
> 
> /Rob
> 
> -----
> Outline
> 
> We'll break the work into a sequence of four tasks, with some overlap
of
> tasks #2 and #3.
> 
> 1. Agree on the basic design approach
> 2. Enumerate protocol requirements, based on API spec/requirements 3.
> 1st draft of the protocol based on those requirements 4. Review &
refine
> to a "last call" quality bar.
> 
> 5/30 - 6/03 <-- we are here
> 6/06 - 6/10 Finish #1 (6/09 conf call: Plan reports from web api and
> protocol groups)
> 6/13 - 6/17 1st draft of #2, then start #3
> 6/20 - 6/24
> 6/27 - 7/01 Finish #2
> 7/04 - 7/08 Finish #3 (7/07 conf call: Protocol report/discussion)
> 7/11 - 7/15 Start #4
> 7/18 - 7/22
> 7/25 - 7/29
> 8/01 - 8/05 Finish #4 (Seems like a reasonable final date for any
> substantive changes)
> 8/08 - 8/12 (For the last few weeks, we're just 'baking', fixing any
> errors we find,
> 8/15 - 8/19  clarifying as appropriate,  and responding to any
external
> feedback)
> 8/22 - 8/26
> 8/29 - 9/02 End of XG of 8/31
> 
> -----
> #1: Agree on the basic design approach
> 
> We can get started on #1 straight away.  Those of us who huddled at
the
> end of the last meeting briefly discussed using WebSockets, with the
> audio sent as a series of binary messages, and signaling as MIME text
> messages using a subset of MRCP as a starting point.  I'd already
> started writing some notes along these lines few weeks ago - nothing
> profound, but it might be a good starting point.  I'll tidy it up and
> send it out for discussion.  Milan, you had also mentioned you could
> suggest a subset of MRCP.  I think this would be useful to give us a
> sense of the scope of work.
> 
> Are there any other design approaches people have in mind?
> 
> -----
> #2: Enumerate protocol requirements
> 
> #2 is just a matter of sifting through all the agreements the XG's
made,
> and noting the implied protocol requirements.  "Ugh, not *more*
> requirements documents... Robert are you insane?"  No comment on the
> latter, but I don't envisage a big production here.  Just an exercise
in
> diligence.  Most of the requirements have been expressed from the
point
> of view of the UA, API or user agent, and I'm concerned that some of
the
> protocol requirements are implied but not explicit.  Better to find
> those now rather than later.
> 
> I suggest that one of us volunteer to take a first pass at this, and
> share with the group for refinement.  Any volunteers?
> 
> -----
> #3: First draft of the protocol spec
> 
> #3 builds on #1, to the point where all necessary functionality is
> incorporated, at least in a rough draft form, with some hand-waves and
> plenty of rough edges.  There's no need to complete #2 before starting
> #3, although I would like to have a draft of #2 before diving into #3
so
> we can structure the discussion.
> 
> -----
> #4 is refinement, fleshing out missing descriptions, adjusting to fit
> the specifics of the API, and generally getting to a "last call"
quality
> bar.
>

Received on Wednesday, 8 June 2011 20:09:35 UTC