Protocol call this week (8/18)

Thanks everybody for working through your to-do list and reporting back to the group. Much appreciated.

Tomorrow let's:

1.       assign remaining to-do items

2.       spend a few minutes discussing any new questions issues raised during the week

Here's the list of remaining items to assign:


12.   TODO: What notation should be used? The Media Fragments Draft, "Temporal Dimensions" section has some potentially viable formats, such as the "wall clock" Zulu-time format.

13.   TODO: does the Waveform-URI return a URI for each input stream, or are all input streams magically encoded into a single stream?

14.   TODO: does the Input-Waveform-URI cause any existing input streams to be ignored?

15.   TODO: Write some examples of one-shot and continuous recognition, EMMA documents, partial results, vendor-extensions, grammar/rule activation/deactivation, etc.

16.   TODO: insert more synthesis examples

Remaining issues from the requirements doc (http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jul/att-0023/Protocol_requirements_draft_-_RB.htm) and not already covered in the above list:

17.   DD64. API must have ability to set service-specific parameters using names that clearly identify that they are service-specific, e.g., using an "x-" prefix. Parameter values can be arbitrary Javascript objects. PE: We have custom vendor resource under 3.2.1 and vendor-listen-mode under 5.3. Presumably other custom params can be set by SET_PARAMS? MJ: Any issues pushing 'arbitrary javascript objects' over the protocol. RB: I'm uneasy declaring victory on this one. What exactly is an 'arbitrary javascript object'? If it can be serialized to something that can be conveyed with a vendor-specific header<http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-24#section-6.2.16> then we're okay. But I'd like to be sure.

18.   FPR58. Web application and speech services must have a means of binding session information to communications.<http://www.w3.org/2005/Incubator/htmlspeech/live/requirements.html#fpr58> MJ: Need to clarify. RB: This essentially means "supports cookies". The exact requirements for this are IMHO unclear and unconvincing. With headers like user-ID, vendor-specific headers, reco-context-block, etc, and the fact that there's a websockets session that wraps all the requests, it's unclear what a session cookie is needed for. But it could be added if necessary.