HTML Speech Incubator Group Teleconference -- 27 Oct 2011

<burn> trackbot, start telcon

<trackbot> Date: 27 October 2011

<burn> Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0058.html

<scribe> scribe:ddahl

<scribe> chair:Dan_Burnett

protocol questions

<burn> Document is http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0033.html

dan: let's postpone this

f2f planning

dan: who will be at f2f?

olli: can we call in?

dan: didn't ask for a phone, usually hard to talk to someone on the phone at f2f

<mbodell> I know Robert will be there and so will Avery (a person from Microsoft who is starting to track these issues)

dan: will look into one-way audio stream
... topics that people want to discuss?

glen: won't that be close to our last chance?

dan: we need to be done by the end of November

glen: we won't have much time after f2f, only 1-2 calls

michael: we should not expect to have any substantive discussions after f2f
... only editorial

dan: after f2f, anything that we don't agree on, we have to stop work on
... editorial work can be substantial, too

glen: should go into f2f with prioritized list of issues that we want to resolve

michael: try to raise open issues on email, can people also write up code examples, also want to make sure that we're handling use cases

dan: get people to sign up for sample code, even if not coming to f2f

glen: what sample code should we be completing? is there a list?

<mbodell> http://www.w3.org/2005/Incubator/htmlspeech/live/requirements.html#section-use-cases

michael: we don't have a list, but can work through use cases to generate a list

glen: we should have priorities and examples ahead of time

dan: we know what needs to happen, now we need to get people to sign up to do things.

glen: will sign up to do some sample code

michael: about seven people here who will be at f2f

registrants -- http://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants#HTMLSpeech

glen: need quality use cases

danD: from a developer's perspective, I would like to see some real examples that allow me to accomplish a particular task
... e.g. voice search, set up a service that isn't a default service
... for example, a speech recognition service

glen: specifying a speech service is a good idea for an example.
... some use cases span the gamut, that might require a huge JavaScript effort

danD: to show developers that this is real, we need to address immediate needs. we might not have the resources to fully accomplish this, but we should have a few examples

glen: I'm willing to take a crack at many of these

michael: some are pretty extensive, everyone should prepare samples for using the protocol and for using the WebAPI.
... it doesn't hurt if there is some duplication, but would like to have coverage of many use cases

dan: do we need to make this more precise?

glen: no suggestions for making this more precise

michael: people should check with others if they also plan to do some

olli: will try something for permission handling

milan: would like to do something about continuous dictation in the protocol
... would do the full stack

glen: will focus on the WebAPI, not the protocol

debbie: will do use case 5, Domain Specific Grammars Filling Multiple Input Fields

glen: what is the protocol aspect of that?

michael: the author doesn't have to get into that but we have to specify what goes into the protocol to accomplish the use case.

danD: could give a summarized description of what the connection is between the WebAPI and the protocol, could go back to the architecture and describe the bits and pieces we've put together over the past year. I can describe the architecture visually and in words.

michaelJ: will try to do something around multimodal interaction

dan: if you can't send sample before f2f, there probably won't be a chance to discuss it.
... this is an important deadline

charles: will review and provide feedback on other contributions, will take a look at TTS but can't promise

<MJ> http://www.w3.org/2005/Incubator/htmlspeech/live/NOTE-htmlspeech.html#use-cases

robert: driving directions, u15, rerecognition
... will look at 3.3.3

dan: could we find something for Bjorn and Satish?

<robert> i'll look at 3.3.3, 3.3.7 and 3.3.15. can't promise quality

glen: will encourage them to do what they can

michael: can do a quick example on speech translation, both API and protocol

dan: might do an example of interpret from text, but may not get that done
... will primarily work on compiling the report together

michaelJ: did we end up having the ability to put the grammar inline?

michael: not currently, but we talked about using a data scheme in the URI

charles: we should have an example showing that
... can volunteer to provide that

michael: please send any substantive issues to the list in advance of the meeting.

questions on the protocol

<mbodell> For the data scheme if people need reminders on how it works the wikipedia page at http://en.wikipedia.org/wiki/Data_URI_scheme describes it

robert: the first question is whether we would ever allow unencryted transmission
... I think TLS encryption should be optional

olli: if there's a proxy, the proxy must not be able to read the transmission

michael: the user should know if the speech is happening over a secure channel or not
... i don't know if it needs to be required for that

robert: if the page was fetched over TLS, would expect speech to be handled over TLS

dan: the security of the speech should be at least as strong as the security of the page

michael: the page should tell you what's secure and what's not

olli: this is a new kind of data, speech is more private

robert: what do current services use?

michael: Bing uses both

glen: I don't know about Google Voice Search

<smaug> what...

robert: we should say that browsers have a strict policy about this, but it's not clear that we should disallow unencrypted transmission

dan: in MRCP it was useful to talk about the idea of a controlled environment
... e.g. if the components are located on the same machine with no external network

robert: there are probably trivial applications where I'm not saying anything that's personally identifiable.

dan: could conceivably capture enough of your voice to train a TTS

michael: this is just about informed user consent

<burn> got dropped. was saying this is indeed different from mrcp where the user is not involved

michael: people are putting their voices up in YouTube all the time

charles: people can restrict who can see their YouTubes
... people might assume that a commercial service is secure

robert: there are a lot of policy issues that depend on what country you're in, for example

glen: if you're jumping from one speech engine to another with different policies, it gets complicated, because the user might not know about it

robert: is there a strong case for disallowing unencrypted transmission?

glen: we had a discussion on how the user authorizes what speech engines are used

olli: there could be a proxy that recognizes you or other things like your gender from your voice

dan: don't see any reason to disallow unencrypted speech

michael: could discuss what happens when you're loaded securely and then Javascript tries to do something insecure

olli: is there any reason to allow unencrypted speech?

dan: we never know how our technologies are used you can't assume that there's always a person at the client, or you can't assume that the client and server are on different networks
... there could be significance performance implications from encryption

olli: there could be an additional spec for more controlled environments

dan: wouldn't have a problem with always encrypting

robert: there has to be a consent UI to even send your voice to a service

olli: what happens to the data between the client and the service, there could be any number of proxies in between.

robert: the concern is about man in the middle attacks.
... your server could disallow non-TLS connections

olli: but spec needs to be interoperable

robert: TLS is required in UA's because of man in the middle attacks, but could be optional in the other cases. we could say that between the browser and the server TLS is required.

michael: we should try to be consistent with other API's

olli: but this is a different kind of data. we could look at RTC, for example.

dan: there is a requirement for support of TLS, but I don't know if that's mandatory.

<mbodell> There is text in html for fetching at http://dev.w3.org/html5/spec/fetching-resources.html#fetch and it talks about various things (including same origin, and possilby CORS) but I don't see where it says things need to be secure, even when on a secure page

olli: in that case the UA can decide, but our situation is different

dan: will look for RTC info offline

robert: voice data is sensitive, and people don't realize that just because they're talking to their browser they might be vulnerable
... however, other services might not be affected
... once you've given the data to a service, it can do whatever it likes with it

danD: it could use dedicated media transport and might not need TLS

dan: it's outside our scope.

danD: as a user, you trust the service that you're using

EMMA with JSON payload

robert: in EMMA you can return pretty much whatever you like, JSON seemed like a good example, but we had decided not to use JSON

michael: it's ok to pull it out, the new examples will give a better sense of what you can do

michaelJ: i'm fine with that, you can do that with 1.0, in EMMA 1.1 you can specify the type of payload.
... you can put all kinds of information in EMMA, for example, emotional state
... the use case I'm most interested in is "send info". what does the EMMA coming back look like?
... if you want something outside of the API, you can go into the EMMA to get it.

robert: will pull the example.
... posted an update last week, won't plan to do another draft
... comment if you have suggestions

<reco>

dan: are we close to having a consensus?

michael: I think glen and I are close, not sure about everyone else

dan: let's summarize what it means to be close to an agreement

<mbodell> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0060.html

<mbodell> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0048.html

michael: made changes to the WebAPI document, sent around, topic of binding might be too dense for now

<mbodell> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0055.html

michael: if people have questions we could probably take a look at those.

<mbodell> Those links are examples from me, Glen, and charles respectively

dan: won't have a chance to pull things together until Sunday, so Robert's final updates to the protocol can be sent until then

robert: will do a quick update including today's discussion

michaelJ: do we have any js examples for current API spec?

michael: we have some simple examples for the markup, but not API
... could try to write up a quick example that we could start from, will add an API example to section 1 today or tomorrow.

olli: needs to reread binding stuff

- DRAFT -

HTML Speech Incubator Group Teleconference

27 Oct 2011

Attendees

Contents

protocol questions

f2f planning

questions on the protocol

EMMA with JSON payload

<reco>

Summary of Action Items

Scribe.perl diagnostic output