See also: IRC log
<burn> trackbot, start telcon
<trackbot> Date: 19 May 2011
<burn> Scribe: Michael_Bodell
<burn> ScribeNick: mbodell
<burn> Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0011.html
Dan: There is a summary page on the logistics of the F2F at:
<burn> logistics page: http://www.w3.org/2005/Incubator/htmlspeech/group/2011/05/f2f_logistics.html
bjorn: There is a light weight NDA to sign before arriving
Dan: Can we get a copy early?
bjorn: No it only exists there. But I think you can sign no.
<scribe> ACTION: Bjorn will verify that signing the nda is not required for attending the f2f. [recorded in http://www.w3.org/2011/05/19-htmlspeech-minutes.html#action01]
<trackbot> Created ACTION-3 - Will verify that signing the nda is not required for attending the f2f. [on Bjorn Bringert - due 2011-05-26].
Dan: the link in the email is wrong. The text is correct. The mail program made too many links.
charles: I thought item 24 was too strong
Dan: Let's talk about that. "It must not be possible to customize the "system is listening" (microphone open) notification. This is for security and privacy reasons." The hope was that if you can customize it you could customize it out of existiance.
Charles: Well I think that is perhaps valid but there may be other choices like have 3 different flavors of browser UI and the web ap could choose which one it is.
Olli: The web application should
not be able to override the browser controls. Perhaps in the
browser chrome.
... Perhaps 2 different notifications: One in the browser
chrome that can't be customized and maybe one in the web app
that can be customized.
Dan: That's interesting and new, but I think that Charles's 3 choices still matches that.
Robert: This is over complicated. I think this is similar to https with mismatched certificate where the browser has a notification from the browser on the page that the web application has no control over. But the browser shouldn't interfear with the web application.
Bjorn: I don't think we can specify how the browser displays the information.
Dan: So the browser chrome must support a notification that can not be over ridden.
Bjorn: I don't like saying chrome as it implies a certain type of browser and certain type of notification.
Dan: User agent instead?
DanD: I like user agent better as it matches other scenarios like in the car.
Bjorn: Yes user agent works.
<scribe> ACTION: Dan will modify 24 on the document to reflect this discussion. [recorded in http://www.w3.org/2011/05/19-htmlspeech-minutes.html#action02]
<trackbot> Sorry, amibiguous username (more than one match) - Dan
<trackbot> Try using a different identifier, such as family name or username (eg. dburnett, ddruta)
Dan: Is it too early to go to IDL definitions and discussion like the reco discusion started by http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0013.html
Robert: I think it is too early, just because it may distract us from our major issues to discuss, but then it is apporiate to discuss things like the idl over email quickly.
Bjorn: I had a couple of purposes: one, to make sure that I was covering everything we agreed with, even if we hadn't discussed it (I.e., we all agree on maxresults but we haven't discussed it yet); two, to show how much agreement we've had.
Dan: We have had a lot of
agreement. I think it is ok to have this low priority
discussion on email, but the main focus of discussion will be
the issues.
... Any other agreements?
Bjorn: Maxresults? I think everyone has these.
Dan: do we agree?
Bjorn: Microsoft and Google had it and Olli agreed in email.
Robert: I agree.
Dan: Alright, we have agreement
on maxresults.
... Any others?
Bjorn: I think maybe timeout. Not positive if we have agreement here or not, but I think timeout is probably agreed.
Dan: We've had the discussion of all the different events we support (end of speech, etc.). not sure if this is separate.
Bjorn: That reminds me that item 30 doesn't work. We have sound end as a low latency event (I.e., might be energy detected). But then we'd have soundend event before a speechdone.
Dan: I think that is solved because by definition you'd raise a speechdone automatically when you'd have a soundend so you'd know there was a soundend and then send both in order.
Bjorn: I'm ok with that.
Dan: We agree, how about others?
Robert: I think this is the wrong discussion to have, surely we have more important issues to discuss than the details of the ordering of these events.
Dan: Fair enough, we can go back to this topic later.
Bjorn: We agreed http needs to be supported.
Dan: We did agree to "We will require support for http for all communication between the user agent and any selected engine, including chunked http for media streaming, and support negotiation of other protocols"
Bjorn: what is left? what to specify?
Dan: Yes, what to specify.
Milan: If we can pass arbitrary properties do we need anything else?
<Robert> FYI, here's the proposal we made: http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#http_conventions
Michael: We may want to specify how certain well defined parameters are passed, like maxresults, but that should have a set way to do it.
Bjorn: I'd rather the parameters *not* end up as query params as I'd want the uri that is specified in the web app might be host/reco?webappparam1=foo&webappparam2=bar and other parameters would go some other method (post body, headers, something)
MichaelJ: Strawman proposal, all parameters go over http query params.
Bjorn: You could do that, but the problem I have with that is that then the user will be mucking with the uri to add the grammar
MichaelB: I don't think that is the issue, you could have the JS API have addGrammar() and it would let the browser know how to add the parameters and muck with the uri. That is easy for it to do. The danger with all URI paramaters is most proxies and webservers will chooke on uri larger then some number (1K, 2K, and 4K are all common size limits). So if you wanted to send audio or a large grammar you'd hit that.
Bjorn: Yeah, I agree with this as a problem.
Milan: Maybe what goes on the url is engine specific?
Bjorn: That would be good for me.
Milan: But maybe you want language or something.
Bjorn: I don't think even then you would put the language on the uri.
Milan: So even that would go in the header.
MichaelB: Header has other issues, multiline grammar as a header is problematic.
Bjorn: Yeah, post body.
Milan: fine, post body, I was being general with headers.
Dan: So do we have agreement that no parameters will be in the url
<burn> No, that's not what I said
MichaelB: My one concern is that while I agree the API should be the prefered way to set certain values; however, in most web services today you can set parameters on the uri or as post parameters and you can do either. So in the maxnbest parameter if setMaxNBest(3) sets a post body great. But if the user knows that, and chooses to set their speech service uri as server.org/reco?maxnbest=3 then that should be fine for the user to do if that is their pre
<burn> ah, yes it is -- sorry, I was behind
Bjorn: that seems fine, but if the user then does that and calls the api the value will be specified in the post body as well, and if it is specified in both places the body wins
Robert: YEah, that sounds right. That way the api doesn't need to change the uri values.
DanD: That sounds right to me as well.
Bjorn: I think that's the way we'd have to do it as the URI is completely opaque to the user agent so it can't enforce anything on the uri
<burn> - User agent will use URI for ASR engine as given by the web app -- it will not modify it.
<burn> - Scripting API would set its values in the POST body.
<burn> - If engine allows params to be specified in the URI in addition to in the POST body, then conflicting ones in the body have precedence. This has the effect of making parameters set in the URI be treated as default values.
Dan: Added to the minutes the
general summary agreement.
... Any other questions on this topic?
Charles: Last week we talked about web sockets or streaming, does "the body" work out in these cases?
Bjorn: Not sure we've decided on POST versus headers versus some other part of the request
Robert: I thought we did agree that.
Bjorn: Ok, we said header or body and header has issues so we should be fine on saying POST body
Robert: Agree. Are we further agreed on multipart/formdata?
MichaelB: Might also be multipart/mixed.
Bjorn: Yeah, the agreement is that separate post body of type multipart but the exact sub-mime type of multipart/mixed versus multipart/formdata versus multipart/foo is not agreed
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/brjorn/bjorn/ Succeeded: s/, +1.415.248.aaaa// Succeeded: s/, +1.425.786.aabb// Succeeded: s/Bjron/Bjorn/g Found Scribe: Michael_Bodell Found ScribeNick: mbodell Default Present: Dan_Burnett, Michael_Bodell, Olli_Pettay, Robert_Brown, Debbie_Dahl, Patrick_Ehlen, Bjorn_Bringert, Raj_Tumuluri, Dan_Druta, Milan_Young, Charles_Hemphill, Michael_Johnston Present: Dan_Burnett Michael_Bodell Olli_Pettay Robert_Brown Debbie_Dahl Patrick_Ehlen Bjorn_Bringert Raj_Tumuluri Dan_Druta Milan_Young Charles_Hemphill Michael_Johnston Regrets: Marc_Schroeder Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0011.html Found Date: 19 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/19-htmlspeech-minutes.html People with action items: bjorn dan[End of scribe.perl diagnostic output]