14:59:19 <RRSAgent> RRSAgent has joined #tt
14:59:19 <RRSAgent> logging to http://www.w3.org/2016/01/14-tt-irc
14:59:21 <trackbot> RRSAgent, make logs public
14:59:21 <Zakim> Zakim has joined #tt
14:59:23 <trackbot> Zakim, this will be TTML
14:59:23 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:59:24 <trackbot> Meeting: Timed Text Working Group Teleconference
14:59:24 <trackbot> Date: 14 January 2016
15:01:15 <Frans> Frans has joined #tt
15:02:14 <nigel> Present: nigel. frans, andreas, david
15:02:16 <nigel> chair: nigel
15:03:39 <pal> pal has joined #tt
15:03:44 <nigel> Present+ pierre
15:04:02 <nigel> Topic: This Meeting
15:05:12 <nigel> Present+ glenn
15:05:49 <tmichel> tmichel has joined #tt
15:06:03 <glenn> glenn has joined #tt
15:06:50 <nigel> Present+ tmichel
15:08:03 <nigel> Present+ shinjan
15:10:08 <dae> dae has joined #tt
15:10:30 <dae> present+dae
15:10:42 <nigel> nigel: For today we have a presentation by David Ronca of Netflix and lots of IMSC issues to discuss.
15:11:09 <nigel> ... Is there any other business to raise not on the agenda?
15:11:25 <nigel> nigel: Aside from noting that we received an Emmy on Friday of course.
15:12:04 <nigel> Present+ dae, harold
15:12:16 <nigel> group: No other business
15:12:47 <nigel> Topic: Action Items
15:14:58 <nigel> scribe: nigel
15:15:09 <nigel> nigel: No progress to report on any of the open actions.
15:15:13 <nigel> Topic: Netflix presentation
15:15:24 <nigel> https://drive.google.com/file/d/0B3C-Bd2ZEyo_TlVQaURzenRSeE0/view
15:16:28 <nigel> david: I have a few people on my team - Dae, Shinjan, Harold, in the content supply team at Netflix, whose job
15:16:29 <hsutherland> hsutherland has joined #tt
15:16:38 <nigel> ... is to make sure that all of the assets are efficiently processed.
15:17:11 <nigel> ... [slide 2] We turned on Netflix lat week for every country in the world except for China, Syria and Crimea.
15:17:45 <nigel> ... With the global launch we're looking to make all content available in every language, over time.
15:18:01 <nigel> ... [slide 3]
15:18:05 <nigel> ... [slide 4]
15:18:52 <nigel> ... We're taking a leadership role regarding contributions to specifications and partnering. Becoming more active contributors.
15:19:18 <nigel> ... We do not accept image based subtitle assets. TTML2 and IMSC 2 are important even essential globally.
15:19:38 <nigel> ... In particular in Japan and bi-directional Arabic language, the tools are built on the current draft of TTML2 so we
15:20:02 <nigel> ... will be providing open source implementations of a good amount of this, in partnership with Glenn Adams of Skynav.
15:21:14 <nigel> ... [slide 5] At first the presentation was simplified, in 2012 we updated it to meet FCC regulations for subtitles, using 608 positioning etc.
15:21:34 <nigel> ... In 2014 we realised that the model would not be suitable for Japan.
15:22:38 <nigel> ... [slide 6] We do format specific inspections for each legacy format, then convert to a canonical model in Java.
15:22:55 <nigel> ... Then we would do general inspections - overlapping text, no more than 4 things live at the same time etc.
15:23:23 <nigel> ... The content provider would deliver, and get a specific error and rejection if the inspection found a problem. So
15:23:44 <nigel> ... it is a provider controlled issue to meet the minimum quality constraints.
15:24:18 <nigel> ... [Slide 7] We parse the canonical model to one of three output formats - TTML, WebVTT and SRT.
15:24:19 <atai> atai has joined #tt
15:24:31 <nigel> ... We generally use TTML for all platforms and use WebVTT just for a single company.
15:24:54 <nigel> ... [Slide 8] Screenshot of subtitles. Shows a challenging feature of Japanese subtitles.
15:25:24 <nigel> ... [Slide 9] Vertical text, horizontal in vertical, oblique, Ruby annotations (etc)
15:25:59 <nigel> ... [Slide 10] Challenges for implementation. LambdaCAP is most used but presented problems due to differences
15:26:08 <nigel> ... in interpretation and lack of consistency across tools.
15:26:27 <nigel> ... TTML1 doesn't support the essential Japanese features so we need TTML2.
15:27:06 <nigel> ... We already had a lot of devices out there that did not support the essential Japanese features. Fortunately the
15:27:23 <nigel> ... device architecture has most of the UI in HTML so we were able to move to an image model, that required us
15:28:16 <nigel> ... in early Dec 2014, 8 months from launch, to deliver subtitles with good quality, as we have a lot of control.
15:28:25 <nigel> ... It was an interesting experience for us.
15:29:02 <nigel> ... [Slide 11] Subtitle workflow. LambdaCAP -> TTML2 -> Image subs or WebVTT. The images are PNG assets.
15:29:22 <nigel> ... The file has an XML manifest that is turned into a binary manifest - the client simply pulls images for ranges, on
15:29:38 <nigel> ... demand. The 3 green modules on the slide are open source modules that Glenn's team has delivered and that
15:29:41 <nigel> ... are on github.
15:31:13 <nigel> ... [Slide 12] Global languages - everything not Latin alphabet. "Gibbon" is our internal rendering engine that we
15:31:46 <nigel> ... are deploying to our clients, i.e. a TTML2 rendering engine. We will use this for Arabic and Chinese. The rendering
15:32:09 <nigel> ... experience will be identical on clients regardless of whether they use image or text data. TTML2 is the canonical model.
15:32:29 <nigel> ... We can, at our discretion, start moving devices from image to text.
15:33:16 <nigel> ... [Slide 13] The Global subtitle workflow will support IMSC-T V1 in the near term and then IMSC-T v2 as a mandatory standard later.
15:33:58 <nigel> ... Internally we use TTML2 ISD for rendering WebVTT or client TTML, which would also be used to drive the
15:34:12 <nigel> ... Gibbon renderer for image subs or TTPE.
15:34:38 <nigel> ... We are going to move to 100% IMF, which requires IMSC 1 adoption so we're working hard to move IMSC 1
15:34:53 <nigel> ... forward. The tools that Glenn is working on right now are currently looking at IMSC tests, and we're about 2
15:35:22 <nigel> ... months out for deploying a complete IMSC 1 implementation that we can declare. IMSC-I publicly, IMSC-T internally.
15:35:57 <nigel> ... We're using TTML2 internally, so we will map IMSC forceDisplay to condition. When we have IMSC 2 we will
15:36:08 <nigel> ... declare them, before the ink on the spec is dry!
15:36:34 <nigel> ... The tools by the way are based on a BSD license.
15:36:56 <nigel> ... [Slide 14] tts:position is required for Japanese.
15:37:19 <nigel> ... [Slide 15] @condition is useful for more robust archives beyond forced vs non-forced.
15:37:47 <nigel> ... At this point we do not use forced - we deliver different assets. For the ingest model we think it is the right
15:38:25 <nigel> ... way to go, and allows other features to be added into the files. You could even call out
15:38:49 <nigel> ... One of the problems is combining in a single archive document multiple languages, regions etc.
15:39:12 <nigel> ... We prefer tts:position to tts:origin because it's easier to map to css background positions.
15:39:34 <nigel> ... We see the future rendering using HTML and CSS.
15:39:49 <nigel> ... We're also looking at bpd and ipd which we believe are required for correct presentation.
15:40:13 <nigel> ... In summary [Slide 16]
15:41:37 <nigel> ... We will make the implementations available for our roadmap. Netflix is really enthusiastic about HTMLCue!
15:42:10 <atai> q+
15:42:21 <nigel> ack atai
15:42:37 <nigel> atai: Thanks very much for this incredible and interesting presentation. One question re your TTML profiles.
15:42:48 <nigel> ... Is there any documentation out there that define the different profiles?
15:43:22 <nigel> david: No, since they are just between us and our clients. I'm happy to have a conversation about global-sdh, which
15:43:48 <nigel> ... will incorporate all the lessons we've learned. We're happy to have that conversation.
15:44:03 <nigel> atai: Thank you
15:44:20 <nigel> glenn: I should mention that there is some preliminary validation support for a couple of earlier Netflix profiles
15:44:39 <nigel> ... in TTV, which supports the Netflix model for netflix closed caption and the earlier sdh model. That's some
15:44:41 <nigel> ... documentation.
15:44:58 <nigel> david: What we call netflix-tt is an archive model that is a set of minor restrictions on top of the current IMSC draft.
15:45:35 <nigel> ... It also supports the sdh profile. We were able to use it to make sure our clients were working properly.
15:46:07 <nigel> glenn: I should mention that is very exciting to work with David and his team to work on these new features.
15:46:22 <nigel> ... It is unusual so far in this WG to work with an organisation that is deploying the technology in a rapid fashion
15:46:37 <nigel> ... from which we can get quick feedback on feature specifications and identify missing features.
15:47:00 <nigel> ... For example in going through all of the essential Japanese requirements, just to support the legacy LambdaCAP
15:47:14 <nigel> ... we found a number of additional style properties related to Ruby that were needed, and were anticipated by the
15:47:28 <nigel> ... Japanese language requirements document but for which the CSS WG has not made progress to spec out those
15:47:48 <nigel> ... features. Although we tried to adopt any specification that we could from HTML and CSS, on a couple of occasions
15:48:04 <nigel> ... we had to go beyond those. I showed you some of the results of that in Sapporo. It's been very useful in
15:48:24 <nigel> ... validating and moving the spec forward. We're working on prioritising my time on moving TTML2 actions
15:48:37 <nigel> ... forward especially relating to the Ruby features we've implemented already in this tool chain.
15:49:15 <nigel> david: Moving very fast is something we're good at here at Netflix. We found from Japanese QC feedback that there
15:49:32 <nigel> ... were lots of nuances. We feel at this point we have uncovered all of the main issues for Japanese subtitles. The
15:50:23 <nigel> ... knowledge we've gained should make the spec good.
15:50:39 <nigel> nigel: Can I ask if Netflix has discussed these technologies with other content distributors or providers?
15:51:12 <nigel> david: We have begun this. We have to go upstream and engage with the tool vendors, to make sure that for example
15:51:35 <nigel> ... the LambdaCAP implementations are conformant. We will also re-engage on TTML2 but are waiting in case there
15:51:51 <nigel> ... are some necessary changes that need to be made.
15:52:08 <nigel> ... One of the popular formats for bidi is EBU STL. It doesn't provide a model for bidi, so we have some challenges
15:52:39 <nigel> ... there, where an external authoring context was needed. We don't like that as it hinders scale. It's better if a
15:53:04 <nigel> ... document is fully self described. That's one of the challenges that we've taken care of. I think moving everything
15:53:09 <nigel> ... to TTML removes the ambiguity.
15:54:03 <nigel> nigel: Thanks again for the great presentation David, and for your work advancing our group's standards.
15:54:58 <nigel> nigel: Let's have a 5 minute break and return to look at IMSC issues.
15:59:36 <nigel> rrsagent, draft minutes
15:59:36 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/14-tt-minutes.html nigel
16:00:14 <nigel> s/Syria/Syria, North Korea
16:00:34 <nigel> rrsagent, draft minutes
16:00:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/14-tt-minutes.html nigel
16:00:50 <nigel> Topic: IMSC 1 Issues etc
16:01:10 <nigel> https://github.com/w3c/imsc/issues
16:03:17 <nigel> nigel: shall we start with issue 111 https://github.com/w3c/imsc/issues/111 ?
16:03:58 <nigel> glenn: I sent an email saying that we have withdrawn the objection based on progress and offline conversations.
16:04:17 <nigel> ... We believe that we can resolve it post-CR3. Until I can finish the process of discussing details I don't think we
16:04:34 <nigel> ... can discuss it here online - it's too complicated and deep a topic, unless there's something new to take into
16:04:41 <nigel> ... account I'd like to handle it that way.
16:05:26 <nigel> nigel: What is the status of publication of CR3 since the FO was withdrawn?
16:05:43 <nigel> tmichel: We did not have much time to work on this but the action is for us if we want a new meeting with the
16:06:32 <nigel> ... Director or if we want to modify the document to fulfil Glenn's input.
16:06:57 <nigel> nigel: So the status is that no progress has been made in publishing CR3 and the Director has not met with Philippe
16:07:09 <nigel> tmichel: Yes, we cancelled that meeting.
16:07:31 <nigel> nigel: So that meeting was not rescheduled?
16:07:49 <nigel> tmichel: Correct. The question is do we want to publish CR3 as is or do we want to include some resolutions?
16:08:04 <nigel> pal: I don't know how much time is required for that resolution. It sounds like Glenn is having discussions and
16:08:29 <nigel> ... the Editor has to make the changes. I thought that we would not try to include the resolution in CR3.
16:08:54 <nigel> glenn: That's my understanding too. We can take up the resolution in the next CR.
16:09:28 <nigel> tmichel: That clarifies - we have no objection so we can go ahead with publication. It may be that plh and the Director
16:09:43 <nigel> ... can do that process, as was agreed before the objection was discussed during the meeting in December.
16:09:48 <nigel> nigel: That's right.
16:10:21 <nigel> Action: tmichel Schedule between tmichel and philippe the transition to CR3 with any Director call as needed.
16:10:22 <trackbot> Created ACTION-453 - Schedule between tmichel and philippe the transition to cr3 with any director call as needed. [on Thierry Michel - due 2016-01-21].
16:10:54 <nigel> tmichel: Is the document fully ready?
16:11:28 <nigel> pal: I'll have update the dates etc. I'll make the updates after this meeting and send tmichel the right document.
16:11:38 <nigel> tmichel: I'll request transition when I've got that.
16:12:41 <nigel> glenn: Before we complete with 111 I just want to note for the record that our expectation is that whatever the
16:13:02 <nigel> ... technical resolution it will involve defining a fallback default profile. That's our position and we'll continue to
16:13:07 <nigel> ... contribute towards that detail.
16:13:40 <nigel> nigel: Pierre, is there an order you'd prefer to tackle the issues in?
16:13:57 <nigel> pal: Yes. there are some issues filed recently for the test suite - I haven't had a chance to look at them yet.
16:14:23 <nigel> ... I want to discuss issue 128 raised a week ago. It's probably pretty serious. It looks like in our haste in Sapporo
16:14:37 <nigel> ... we forbade a feature that was previously allowed, which is the presence of ttp:profile element.
16:14:53 <nigel> ... In Sapporo we couldn't find a reason to allow it. Glenn pointed out that it is actually required by SDP-US.
16:15:16 <nigel> ... One of the goals is for a valid SDP-US document to be a valid IMSC Text profile document. That's a significant
16:15:33 <nigel> ... issue. The solution is straightforward, so I proposed a pull request simply to permit ttp:profile element.
16:15:57 <nigel> ... This looks like we introduced a real bug in Sapporo. Assuming that we'll want to permit it again, has anyone
16:16:03 <nigel> ... else had chance to consider the problem?
16:16:13 <nigel> https://github.com/w3c/imsc/issues/128
16:16:41 <nigel> glenn: The puil request looks reasonable. It certainly makes profile resolution process more difficult. It seems okay
16:16:44 <nigel> ... as a first approach.
16:17:18 <nigel> atai: I agree it is a serious bug that should be amended before going to CR. Some statements in IMSC 1 would be
16:17:37 <nigel> ... wrong otherwise, because IMSC 1 would not be a strict superset of SDP-US. At least some solution that fixes the
16:17:42 <nigel> ... error would be really good.
16:18:09 <nigel> nigel: I agree with all the above.
16:18:12 <nigel> https://github.com/w3c/imsc/pull/129/files
16:19:01 <nigel> glenn: Andreas raised a question about if this should go into the new CR or a later one. I think we should answer that.
16:20:27 <nigel> pal: The PR isn't exactly a reversal of the previous text. It provides guidance on SDP-US and EBU-TT-D conformance.
16:21:19 <nigel> pal: I also moved the profile signalling to a new section which will make is easier to put other profile issues in a good place
16:21:25 <nigel> ... rather than cramming them into that table.
16:22:17 <nigel> nigel: You can't really win for documents that are SDP-US and EBU-TT-D conformant in every respect other than
16:22:21 <nigel> ... signalling profile.
16:22:49 <nigel> atai: Documents cannot be SDP-US and EBU-TT-D conformant at the same time because of the profile features.
16:23:07 <nigel> glenn: It's my estimation that EBU-TT-D does not prohibit either ttp:profile element or attribute, notwithstanding
16:23:27 <nigel> ... the informative schema. My question is if that was the intention of the EBU, and if so is there a plan to revise
16:23:47 <nigel> ... EBU-TT-D to make clear that other foreign vocabulary are prohibited.
16:24:05 <nigel> atai: Previously I did confirm that the intention was clearly to only allow document content and TTML elements that
16:24:24 <nigel> ... are defined in the specification. The ttp:profile element and attributes are not included. I can confirm that the
16:24:40 <nigel> ... intention was not to allow them. If it is not clear enough then it may be clarified later in an update. For
16:24:56 <nigel> ... discussing this issue it's important that the intention was not to allow it: a conformant EBU-TT-D document shall
16:25:02 <nigel> ... not have a ttp:profile attribute or element.
16:25:21 <nigel> glenn: I view that as a statement of the intent of the group but not a statement of fact. It's my contention that
16:26:07 <nigel> ... simply failing to list as prohibited an entity does not prohibit its presence. In that case I'd be happy to file a bug,
16:26:16 <nigel> ... though I'd prefer you to file it on my behalf if possible.
16:26:36 <nigel> pal: Is that related to #128 that was strictly about SDP-US? Not to say it's not important.
16:26:58 <nigel> glenn: It's a sidebar not strictly related to 128 or any IMSC bug. I raise it to deal with the repeated assertion that
16:27:04 <nigel> ... it is not permitted in EBU-TT-D.
16:27:21 <nigel> pal: If you'd like to capture that within the scope of IMSC you should file an issue with the part that deals with EBU-TT-D.
16:29:23 <nigel> glenn: The proposal for 128 makes sense only if the point about EBU-TT-D is correct.
16:30:37 <nigel> nigel: I'm happy with the proposal but in the sense that conformant SDP-US documents can exceed HRM thresholds
16:30:58 <nigel> ... it is not true that all SDP-US documents are valid IMSC text profile documents that part of the problem has not
16:31:02 <nigel> ... been addressed.
16:31:25 <nigel> pal: The intent is merely to say that it is possible to create documents that are conformant both to IMSC Text profile
16:31:39 <nigel> ... and SDP-US. We may need a new issue around the statement in the abstract.
16:31:44 <nigel> nigel: Okay I'll file that.
16:32:01 <nigel> pal: To atai's point should we try to revert the mistake before CR3?
16:32:15 <nigel> nigel: Would anyone object to it?
16:32:37 <nigel> atai: I would favour it. CR3 would then not introduce the error, subject to being changed back after CR3. If possible
16:32:45 <nigel> ... from the process side I would favour fixing this in CR3.
16:34:23 <nigel> nigel: I just want to check with tmichel that having made a resolution to publish, with no objections, and in the
16:34:36 <nigel> ... case that publication has not occurred, do we have an opportunity to modify the document?
16:35:19 <nigel> tmichel: yes we can do that.
16:35:25 <nigel> glenn: We've done that plenty of times in the past.
16:36:15 <nigel> nigel: Okay so the proposal is to incorporate the pull request in the current version before CR3.
16:36:27 <nigel> glenn: In the past we have authorised the editor to make such changes.
16:37:08 <nigel> nigel: I'm not hearing any objections and this seems sensible, so let's go ahead with merging the pull request.
16:37:30 <nigel> ... Also the group agrees to move that modified text forward for publishing within CR3.
16:39:36 <nigel> glenn: All of the new issues I filed last night were based on my adding all of the W3C IMSC tests to the TTV
16:39:56 <nigel> ... test suite, which is considerably larger, in the 200-300 range. There are only 42 documents in the IMSC test
16:40:16 <nigel> ... suite. So I discovered these issues running the tests through the new IMSC validator caught a few problems.
16:41:00 <nigel> pal: Issue 114 - I need some guidance from glenn and nigel following the conversation.
16:41:12 <nigel> https://github.com/w3c/imsc/issues/114
16:41:30 <nigel> pal: For the record I'm happy with the current text - I just want everyone to be happy so we can close the issue.
16:41:50 <nigel> glenn: 114 is certainly my next highest priority after 111 and 128. In my estimation it is a bug that needs resolving.
16:42:02 <nigel> pal: Maybe I'll follow up with the two of you.
16:43:08 <nigel> nigel: Looking at the comments, I think we are a bit stuck on this. I had hoped we could modify the definitions to achieve the desired effect.
16:43:22 <nigel> glenn: I don't believe that the current language that defines "prohibited" actually does that.
16:43:53 <nigel> pal: So there's been no further discussion on this since the last posting 30 days ago?
16:44:06 <nigel> glenn: Not publicly - Nigel and I had a bit of private discussion that isn't resolved yet.
16:45:27 <nigel> nigel: I think that the essence of the problem is the mismatch when trying to use processor features to define
16:45:48 <nigel> ... document conformance. I think we all want to achieve the same thing - it's just about getting a clear readable
16:46:01 <nigel> ... form of words. Would you agree?
16:46:59 <nigel> glenn: Yes, we also need to take into account that TTML2 does provide content features and we don't want a mismatch between IMSC 1 language and TTML2 language,
16:47:04 <nigel> ... as that will cause us problems later.
16:48:57 <nigel> glenn: [explained in a way the scribe couldn't follow]
16:48:59 <nigel> nigel: I agree with that.
16:49:18 <nigel> david: I'd like clarity on this - I think it's really important to get the definition of prohibited right.
16:51:02 <nigel> nigel: I think there's one linguistic point we need to be careful about, which is the term "feature" which references
16:52:15 <nigel> ... terms in TTML1 which are each defined in terms of processor behaviour.
16:52:31 <nigel> glenn: I think we can resolve that since we have a shared understanding of the problem.
16:53:23 <nigel> pal: I need time to go through the test suite issues. The others are less critical, or editorial, so I think we've
16:53:30 <nigel> ... covered everything I had on my agenda.
16:54:15 <nigel> nigel: Just to note that we'll need to update the substantive change list to take into account issue 128 resolution.
16:54:22 <nigel> pal: Thanks for reminding me, I'll do that.
16:54:35 <nigel> pal: I'm going to add a note to the issue right now so I don't forget.
16:55:54 <nigel> Topic: HTMLCue proposal progress update
16:56:51 <nigel> nigel: Noting Netflix's enthusiasm for the HTMLCue concept, I think there was an expectation on me to write
16:57:12 <nigel> ... something up. There's also an action on atai to look into the VTTCue approach. Opening up to comments?
16:57:26 <nigel> glenn: Personally I think WebVTT is the wrong approach so I'd probably be unhappy with it. I think we need to
16:57:35 <nigel> ... define this mechanism in a way that is independent of WebVTT.
16:57:53 <nigel> atai: I think we agreed to at least follow up this suggestion with Simon and also other developers to try to use
16:58:14 <nigel> ... the VTTCue mechanism without extending it to HTMLCue, but as I remember we said it does not conflict
16:58:31 <nigel> ... to work independently on an HTMLCue. Both are valid. What we want is a proposal that is both specified and
16:58:47 <nigel> ... implemented. It's important to deal with the feedback from the browser communities. I think what would
16:59:06 <nigel> ... also be interesting is if Netflix has specific feedback on HTMLCue and can add or give some requirements for the
16:59:20 <nigel> ... use of HTMLCue from their side. That would definitely help to communicate this kind of proposal.
16:59:38 <nigel> glenn: On the VTTCue, yes, if it were handled separately from HTMLCue I would have no problem. It might be
17:00:32 <nigel> ... appropriate to handle that in the mapping document.
17:01:26 <pal> (need to drop off)
17:03:07 <nigel> david: Our clients would be rendering TTML to HTML so we see HTMLCue as a direct route without going via VTTCue
17:03:31 <nigel> ... would be preferable. As I understand it the Cue gives timing information. If you look at our Japanese WebVTT
17:03:47 <nigel> ... implementation there's a lot of missing functionality so I'd prefer to bypass that altogether. It's not clear who will
17:04:06 <nigel> ... move that spec forward. I am willing to commit Netflix resources into the development of HTMLCue.
17:04:40 <nigel> nigel: That's a great point to end. Thanks everyone. Probably a 1 hour meeting next week, same time. [adjourns meeting]
17:04:43 <nigel> rrsagent, draft minutes
17:04:43 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/14-tt-minutes.html nigel
17:08:47 <nigel> s/Present: nigel. frans/Present: nigel, frans
17:15:17 <nigel> s/I'll have update the dates/I'll update the dates/
17:15:48 <nigel> s/tackle the issues in/tackle the remaining issues in/
17:16:15 <nigel> s/puil request/pull request/
17:22:02 <nigel> s/valid IMSC text profile documents that part/valid IMSC text profile documents, that part/
17:24:21 <nigel> s/scribe couldn't follow/scribe couldn't type quickly and accurately enough
17:25:36 <nigel> s/move that spec/move that [WebVTT] spec
17:25:51 <nigel> rrsagent, draft minutes
17:25:51 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/14-tt-minutes.html nigel
17:27:50 <nigel> ScribeOptions: -final -noEmbedDiagnostics
17:27:52 <nigel> rrsagent, draft minutes
17:27:52 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/14-tt-minutes.html nigel
18:03:02 <Zakim> Zakim has left #tt