RE: proposed plan for protocol group

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 18:27:23 UTC