RE: Speech protocol draft 6

Here's a revision.

I added the following to section 3.4 (security), to reflect yesterday's discussion:

"In practice, to prevent man-in-the-middle snooping of a user's voice, user agents SHOULD NOT use the WS: scheme, and SHOULD ONLY use the WSS: scheme. In non-mainstream cases, such as service-to-service mashups, or specialized user agents for secured networks, the unencrypted WS: scheme MAY be used."

________________________________
From: public-xg-htmlspeech-request@w3.org [public-xg-htmlspeech-request@w3.org] on behalf of Robert Brown [Robert.Brown@microsoft.com]
Sent: Tuesday, October 18, 2011 6:28 PM
To: HTML Speech XG
Subject: Speech protocol draft 6

Here’s another draft, incorporating feedback from the last few weeks of discussion.

Let me know if I missed anything.

---

>From Olli’s feedback (http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0010.html, and http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0011.html)

> Nit, currently the protocol is "html-speech/1.0".
> Would be probably better to call it something more generic, since the
> 'html' is kind of just a buzz word there.
> Maybe "web-speech/1.0", or just "web-speech/1.0"

I replaced “html-speech” with “web-speech” throughout the doc

> Should we actually require wss protocol always.
> Is there any reason to use ws?

We didn’t discuss this in the call. My personal opinion is that TLS is a lot of overhead to impose for apps where privacy isn’t a concern.
In any case, I left it as-is until we could discuss it.

> "1-Best EMMA document with JSON payload"
> Is that really needed? Do I remember right that we agreed to use XML format always.

Yes, Olli remember correctly. The idea behind the example is to show that vendors could add other stuff into the EMMA. However, I think Olli’s right in that this example is misleading because without explanation it can be interpreted as our recommended way to return structured results. I’ve removed in from draft 6. We can discuss whether it makes sense to put it back with appropriate explanation.

---

>From minutes from 6th October (http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0015.html)

> AGREEMENT: remove set-params from protocol

I removed section “4.1 Getting and Setting Parameters” and incorporated some of the GET-PARAMS content into “4.2 Capabilities Discovery” (was 4.3).
I also removed all references to SET-PARAMS from the document. Most of these were generally of the form “The foo header can be set in the BAR method or in SET-PARAMS”, which I changed to “The foo header is set in the BAR method”. There were also a couple of examples I changed too.

The exchange that begins with:
> DanD: will we have an API key registration
… and ends with:
>    DanD: we need to capture this in the security section and just say
>    that vendor-specific key-value pairs can be used

I’ve captured this in section “3.4 Security” as “Web services may wish to authenticate the application requesting service. There is no standardized way to do this. However, the Vendor-Specific-Parameters header can be used to perform proprietary authentication using a key-value-pair scheme defined by the service.”

> AGREEMENT: allow any positive number as grammar weight

I changed the definition to this:
1*3DIGIT ["." 1*3DIGIT]
And I noted in the description that the default value is “1”