16:31:50 RRSAgent has joined #htmlspeech
16:31:50 logging to http://www.w3.org/2010/11/11-htmlspeech-irc
16:36:36 zakim, nick burn is DanBurnett
16:36:36 sorry, burn, I do not see a party named 'DanBurnett'
16:40:11 rrsagent, bye
16:41:28 rrsagent, draft minutes
16:41:28 I have made the request to generate http://www.w3.org/2010/11/11-htmlspeech-minutes.html burn
16:41:31 rrsagent, bye
16:57:03 marc has joined #htmlspeech
16:57:08 INC_(HTMLSPEECH)12:00PM has now started
16:57:15 +[Microsoft]
16:57:46 zakim, code?
16:57:46 the conference code is 48657 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), burn
16:58:32 ddahl has joined #htmlspeech
16:58:32 +??P2
16:58:37 +??P7
16:59:14 +Debbie_Dahl
16:59:29 trackbot start telcon
16:59:54 zakim, mute P7
16:59:54 sorry, burn, I do not know which phone connection belongs to P7
17:00:02 mbodell has joined #htmlspeech
17:00:04 trackbot, start telcon
17:00:04 zakim, mute ??P7
17:00:04 ??P7 should now be muted
17:00:06 +??P14
17:00:07 RRSAgent, make logs public
17:00:09 Zakim, this will be
17:00:09 I don't understand 'this will be', trackbot
17:00:10 Meeting: HTML Speech Incubator Group Teleconference
17:00:10 Date: 11 November 2010
17:00:11 yes
17:00:16 zakim, unmute ??P7
17:00:16 ??P7 should no longer be muted
17:00:22 Zakim, ??P14 is Olli_Pettay
17:00:22 +Olli_Pettay; got it
17:00:32 Zakim, smaug is Olli_Pettay
17:00:32 sorry, smaug_, I do not recognize a party named 'smaug'
17:00:35 + +39.335.766.aaaa
17:00:38 Zakim, smaug_ is Olli_Pettay
17:00:38 sorry, smaug_, I do not recognize a party named 'smaug_'
17:00:39 zakim, ??P7 is Marc_Schroeder
17:00:40 +Marc_Schroeder; got it
17:00:43 chair: Dan_Burnett
17:00:55 zakim, ??P2 is Dan_Burnett
17:00:55 +Dan_Burnett; got it
17:00:56 +Michael_Bodell
17:01:10 zakim, nick burn is Dan_Burnett
17:01:10 ok, burn, I now associate you with Dan_Burnett
17:01:18 ah
17:01:29 Zakim, nick smaug_ is Olli_Pettay
17:01:29 ok, smaug_, I now associate you with Olli_Pettay
17:01:40 zakim, nick marc is Marc_Schroeder
17:01:40 ok, marc, I now associate you with Marc_Schroeder
17:01:45 zakim, who's on the phone?
17:01:45 On the phone I see [Microsoft], Dan_Burnett, Marc_Schroeder, Debbie_Dahl, Olli_Pettay, +39.335.766.aaaa, Michael_Bodell
17:01:51 zakim, nick ddahl is Debbie_Dahl
17:01:51 ok, ddahl, I now associate you with Debbie_Dahl
17:01:55 zakim, aaaa is Paolo_Baggia
17:01:55 +Paolo_Baggia; got it
17:02:00 +Milan_Young
17:02:05 + +1.760.705.aabb
17:02:35 zakim, aabb is Bjorn_Bringert
17:02:37 +Bjorn_Bringert; got it
17:03:06 Milan has joined #htmlspeech
17:03:16 zakim, who's on the phone?
17:03:16 On the phone I see [Microsoft], Dan_Burnett, Marc_Schroeder, Debbie_Dahl, Olli_Pettay, Paolo_Baggia, Michael_Bodell, Milan_Young, Bjorn_Bringert
17:03:26 rrsagent, start logging
17:03:26 I'm logging. I don't understand 'start logging', ddahl. Try /msg RRSAgent help
17:04:01 + +1.425.391.aacc
17:04:38 zakim, [Microsoft] is temporarily Robert_Brown
17:04:39 +Robert_Brown; got it
17:04:59 zakim, aacc is Dan_Druta
17:04:59 +Dan_Druta; got it
17:05:11 zakim, who's here?
17:05:20 On the phone I see Robert_Brown, Dan_Burnett, Marc_Schroeder, Debbie_Dahl, Olli_Pettay, Paolo_Baggia, Michael_Bodell, Milan_Young, Bjorn_Bringert, Dan_Druta
17:05:23 On IRC I see Milan, mbodell, ddahl, marc, RRSAgent, Zakim, burn, smaug_, trackbot
17:05:47 zakim, nick Milan is Milan_Young
17:05:47 ok, burn, I now associate Milan with Milan_Young
17:05:59 zakim, nick ddahl is Debbie_Dahl
17:05:59 ok, burn, I now associate ddahl with Debbie_Dahl
17:06:13 zakim, nick mbodell is Michael_Bodell
17:06:13 ok, burn, I now associate mbodell with Michael_Bodell
17:06:56 topic: minute takers and expectations
17:07:30 scribe: ddahl
17:08:03 dan: important to start and end on time
17:08:49 ... in the future we will track when people take minutes, also will prefer to to select people who join late and haven't taken minutes
17:09:16 bringert has joined #htmlspeech
17:09:20 ...will start asking newer people in the coming weeks
17:09:52 ...suggestion that we check on f2f minutes and requirements draft
17:10:25 ...send minor corrections to minutes by email, or bring up major corrections now.
17:10:55 ...new requirements draft sent out based on f2f discussion by Michael Bodell
17:11:48 http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0102.html
17:11:49 michael: started new section and struck out requirements that have been deleted. the new draft just covers f2f
17:12:08 dan: concerns about requirements?
17:12:12 agenda is at http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0104.html
17:12:33 zakim, who is noisy?
17:12:44 burn, listening for 10 seconds I heard sound from the following: Marc_Schroeder (85%), Paolo_Baggia (14%)
17:13:02 marc: should this requirements document be at a stable uri?
17:13:20 michael: would like to do this, but still need CVS access
17:13:32 dan: we're going through this process as quickly as we can
17:13:54 ...this is supposed to be more of a live draft
17:14:01 ...comments on requirements?
17:14:25 paolo: would like to know more about section 4, is that the place where the new changes will be placed?
17:14:30 michael: yes
17:14:58 ...as we go through this, all of section 3 will be moved, but section 4 will replace it
17:15:16 ...confusing to mix old and new requirements
17:15:40 dan: paolo, were you asking if there was a way to link old and new requirements?
17:16:00 paolo: yes, and in the old one there was explanation
17:16:30 michael: was mainly trying to capture what we agreed on rather than include a lot of text
17:16:42 ...new ones link back to old ones
17:17:13 zakim, who is noisy?
17:17:24 marc, listening for 10 seconds I could not identify any sounds
17:17:40 dan: this approach reduces confusion about which are the new requirements, when we finish the old requirements I will ask if there's anything that didn't get captured, then it will be safe to remove old requirements.
17:17:50 topic: requirements
17:18:07 dan: start with R21
17:18:55 michael: status is that there was mostly agreement that it was out of scope, was not sure what the scenario was that Eric Johansson had in mind.
17:19:53 dan: recommend drawing a line through this requirement and letting Eric raise concerns
17:20:11 zakim, nick bringert is Bjorn_Bringert
17:20:11 ok, burn, I now associate bringert with Bjorn_Bringert
17:20:22 bjorn: i think Eric agreed that it was out of scope
17:20:30 dan: he may want to continue discussion
17:20:38 dan: R6
17:21:08 michael: we already covered this in discussion of R27
17:21:17 for the minutes, also note that we explicitly had consensus on the call to remove R21
17:21:46 dan: does anyone object to removing R6?
17:21:50 (no objections)
17:21:59 topic: R17
17:22:29 michael: little discussion, but some bleeded over from R18
17:22:50 ...should have requirement that API for recognition should not introduce unneeded latency
17:23:15 s/dan: R6/topic:R6
17:23:34 dan: any more comments on R17?
17:23:55 my connection dropped, dialing again
17:23:56 ...any objections to Michael's wording to replace R17
17:24:25 michael: two requirements, one that Bjorn proposed and one that Michael proposed
17:25:13 ...first one is that applications can start processing captured audio right away and second says that applications can introduce unneeded latency
17:25:37 s/can introduce/should not/
17:25:50 dan: any objections to replacing original R17 with these two requirements?
17:25:59 (no objections)
17:26:01 "Implementations should be allowed to start processing captured audio before the capture completes." and "The API to do recognition should not introduce unneeded latency."
17:26:13 topic: R18
17:26:14 (w3c doesn't answer the phone), no objection from me
17:26:37 bjorn, just try again. zakim does this sometimes
17:27:23 dan: we acknowledge no objections to R17 (including from bjorn)
17:28:00 ...we will do what we can on R18, will get started while waiting for bjorn
17:28:29 + +44.122.546.aadd
17:28:31 dan: any objections?
17:29:08 zakim, aadd is Bjorn_Bringert
17:29:08 +Bjorn_Bringert; got it
17:29:54 Implementations should be allowed to start playing back synthesized speech before the complete results of the speech synthesis request are available.
17:30:25 dan: any objections to adding this requirement?
17:30:47 michael: other proposals that may have come out of this discussion.
17:31:21 ... other issues about what user agent must allow, codecs, not sure how to tackle
17:31:38 dan: there are others where we're closed to consensus, so let's start with those
17:32:00 ...some of the ones proposed by Milan were addressing other wording on email list
17:32:20 milan: first two, about writing and reading to the audio buffer is handled
17:32:42 bjorn: we might have consensus on the requirement about unneeded latency
17:32:49 ...for TTS
17:33:15 marc: we agree with this
17:33:49 michael: that takes care of the first 3, and the others aren't needed
17:34:10 ...then we had user agents must not filter results from the application
17:34:41 no, not "the others aren't needed" -- instead, the next 3 are not needed
17:35:02 ... through filtering results
17:35:17 bjorn: the next two are that the ua must not interfere with result or timing
17:35:42 oops, i meant through passing parameters
17:35:58 yes, we are now discussing results and timing
17:36:17 bjorn: you might have some results that are suspicious
17:36:27 ..that the ua might want to filter
17:36:39 marc: what speaks in favor of these requirements?
17:37:23 milan: concerned that ua think that it knows best about the speech interaction and deleting something that was part of the protocol between the speech resource and the web application
17:38:14 michael: api needs to be extensible so that additional functionality is supported?
17:39:09 milan: actually wants to make sure that if an EMMA result is sent to the web app the ua must not change it because it doesn't know what it is? also wants events fired by the speech resource to make it into the user space.
17:39:22 bjorn: what kind of event are you talking about?
17:39:35 actually, that was olli
17:39:42 (not bjorn)
17:39:59 Yeah, I think ealier too about supspicious results was also olli
17:40:14 milan: if we have a "start of speech" event, as long as our API is flexible enough we can add new things
17:40:31 s/bjorn: what/olli: what
17:41:12 s/bjorn: you/olli: you
17:42:13 milan: API should be flexible so that new events don't break apps
17:42:47 bjorn: how about if we say that it should be possible to add new information to speech recognition results
17:43:16 ...then for events we would have to require that speech server specific events would be able to be returned to the web app
17:44:01 milan: web applications need to be able to continue to run even if they aren't expecting them
17:44:15 bjorn: can't expect that app will never crash
17:44:34 ...so speech server should be able to return implementation-specific events
17:44:55 ...two new requirements
17:45:32 new requirement 1: speech recognition implementations should be allowed to add implementation specific information to speech recognition results
17:46:29 new requirement 2: speech recognition implementations should be allowed to fire implementation specific events
17:47:41 milan: previously we had discussed that there was a particular ordering of events, if we just have events being fired in between those events, we might destabilize applications
17:48:24 bjorn: the apps that don't care about events won't register for them. and if we say "a before b" that doesn't mean that there's anything in between.
17:49:11 milan: if speech server doesn't generate "start of speech" does the ua insert it?
17:49:21 bjorn: we haven't defined events
17:49:25 s/that doesn't mean that there's anything/that doesn't mean that there's not anything/
17:49:32 -Paolo_Baggia
17:49:41 michael: it could be the ua or the speech resource that generates some of these events
17:50:18 dan: any objections to adding these two requirements as stated on IRC
17:50:44 milan: are we going to allow TTS to fire events? these just talk about recognition.
17:50:53 +Paolo_Baggia
17:50:56 marc: it would make sense to have that?
17:51:33 michael: rather than changing R2 to speech resources would it make sense to have new requirement for TTS events?
17:51:49 bjorn: other use cases for TTS events other than "mark"?
17:52:11 marc: yes, "mark" is too coarse-grained for lip synchronization
17:52:26 new requirement 3: speech synthesis implementations should be allowed to fire implementation specific events
17:52:55 dan: sounds like we have agreement on these three
17:53:07 michael: back to R18
17:53:30 dan: should be split into two, first is exactly as worded
17:54:21 michael: i.e. requires support for remote services, e.g. by HTTP 1.1
17:54:45 dan: yes, second is that speech services and ua may negotiate on other protocols
17:55:13 dan: first one is mandatory support for HTTP 1.1
17:55:30 michael: does HTTP 1.1 include https?
17:55:59 marc: this seems like a low-level technical requirement, should not discuss now
17:56:30 dan: two issues -- we use a generic term "communication" but we might need to distinguish control and media
17:56:59 ...at IETF there is a lot of discussion for using HTTP for streaming, when should you use that or not
17:57:27 ...we might not want to define these protocols, just pick from what's available, but may not want to pick now
17:57:47 marc: would like to settle on some existing protocol, but now is too early
17:58:04 michael: likes rewording with "such as"
17:58:30 olli: likes "lowest common denominator"
17:58:45 that wasn't me
17:58:57 that was robert
17:59:13 s/olli: likes/robert: likes
18:01:00 marc: requirement should be: the communication between the us and the speech server must allow for some lowest common denominator like HTTP 1.1
18:01:07 s/us/ua
18:01:43 dan: we want to require a lowest common denominator protocol
18:02:14 bjorn: we want to avoid mismatch between browser and speech server communication
18:02:18 i said "require a mandatory-to-support communication protocol, such protocol TBD"
18:03:45 michael: the communication between the us and the speech server must require a mandatory-to-support lowest common denominator such as HTTP 1.1, TBD
18:03:51 s/us/ua
18:05:07 dan: the reason for this is that four months from now it might be construed as requiring HTTP 1.1
18:05:21 michael: do we have agreement on this?
18:06:01 ...ok what about the second sentence?
18:07:02 dan: we could write a requirement but may not end up considering it as something that we need to do now
18:07:20 ...we don't want to prevent negotiation in the future
18:07:56 robert: negotiation sounds like a runtime handshake but what we really want is the freedom to use something else if something better shows up
18:08:55 ...in telephony negotiation is important, but in web apps you just ask for what you want and if it doesn't work, try something else
18:09:05 dan: this concept is important to capture
18:09:13 michael: requirement text?
18:09:23 what i had proposed initially was: "UAs and speech services may negotiate on use of other protocols for communication."
18:10:34 ... another wording: "UAs and speech services may agree to use alternate protocols for communication."
18:10:41 dan: agreement?
18:10:49 (no objections)
18:10:58 agree with another wording
18:12:18 marc: another one for R18, should we have one for implementation data for TTS, a mirror image to the new one we added for ASR
18:12:31 robert: we added that at the f2f
18:12:40 michael: two more
18:12:59 ...require ua's to expose an API for local speech services
18:13:13 bjorn: i don't see this as necessary
18:13:20 michael: i agree
18:13:35 dan: do you think that whatever API we define should be sufficient?
18:14:05 bjorn: the ua is free to talk to any speech service whenever it wants
18:14:14 my question is whether even in the local case that the single api we are defining should be required
18:14:26 ... and that UAs can optimize the behavior
18:14:46 or are you saying that the UA can do anything it wants any way it wants when the resource is local?
18:17:17 bjorn: as long as the specification is specified, if the web app requests a local speech service but it's not available, what happens
18:17:17 -Paolo_Baggia
18:18:14