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 Thursday, 2 June 2011 16:19:39 UTC