14:00:08 RRSAgent has joined #tt 14:00:08 logging to http://www.w3.org/2017/10/05-tt-irc 14:00:10 RRSAgent, make logs public 14:00:10 Zakim has joined #tt 14:00:12 Meeting: Timed Text Working Group Teleconference 14:00:12 Date: 05 October 2017 14:00:28 Regrets: Cyril 14:01:49 Present: Nigel, Pierre 14:01:51 Are you able to connect to Webex ? 14:01:52 Chair: Nigel 14:01:56 scribe: nigel 14:02:25 Present+ Andreas 14:02:32 s/Are you able to connect to Webex ?/ 14:02:41 pal has joined #tt 14:02:45 Present+ Mike 14:03:22 mike has joined #tt 14:03:40 Present+ Thierry 14:04:13 Present+ Glenn 14:05:02 Topic: This meeting 14:05:20 NIgel: I haven't had confirmation of whether David or Silvia will join, so we'll bump WebVTT 14:05:28 .. down the agenda until they join. 14:05:32 s/NI/Ni 14:06:13 Nigel: Today then we have IMSC vNext requirements, TTML2 wide review comments, and 14:06:20 .. then WebVTT review comments. 14:06:59 Nigel: Anything else to cover, or specific points to raise? 14:07:31 Pierre: I sent an email - suggest getting to FPWD of IMSCvNext as soon as possible, 14:07:39 .. hopefully by next week so that it can be in time for MPEG. 14:08:14 Nigel: OK got that for the agenda, anything else. I know for TTML2 we need to think about 14:08:18 .. review comment timing. 14:08:46 Pierre: I'd like to cover Mike's two IMSC issues too. 14:09:51 Nigel: I don't think there's anything to discuss re TPAC so I'll drop it from today's agenda. 14:11:21 Topic: IMSC Issues 14:12:27 Pierre: Mike brought up two issues: a) if all IMSC vNext references should be to TTML2, 14:12:39 .. and if TTML2 is in fact a superset of TTML1 and processing a TTML1 document with the 14:12:47 .. TTML2 processor will yield the same result. 14:13:05 .. b) deprecation of smpte:backgroundImage - to me that was a good exercise to try 14:13:09 .. deprecating that. 14:13:20 s/IMSC Issues/IMSC vNext Issues 14:13:35 atai has joined #tt 14:14:45 github: https://github.com/w3c/imsc/issues/258 14:15:16 Mike: I was concerned that the focus has shifted from being an extension of IMSC 1.0.1 14:15:29 .. to being a subset of TTML2 and those things aren't necessarily incompatible but they 14:15:45 .. change the risk profile, so I'd like the group to consider the choice here. It may be that 14:16:01 .. we have to reference both TTML1 and TTML2, but changing everything to TTML2 when 14:16:40 .. there's a risk that the processing would change. 14:16:55 Nigel: I've always thought that TTML2 is a superset of TTML1, and I've never seen anything 14:17:04 .. that made me doubt that. 14:17:59 Pierre: There's a related issue w3c/ttml2#442 requesting that the scope of TTML2 is 14:18:32 .. defined as a superset of TTML1. For example there are changes to prose for style resolution. 14:18:49 Glenn: Something to bear in mind is that a TTML2 document will be processed differently 14:19:02 .. by a TTML1 processor and a TTML2 processor. But more importantly if a TTML2 14:19:18 .. processor is processing a TTML1 document then its incumbent on the implementation 14:19:45 .. to behave modally as a TTML1 processor. It's not completely clear what we're talking about. 14:20:05 Mike: We need to make a fundamental decision that either IMSC vNext is a superset of 14:20:23 .. IMSC 1.0.1 or a subset of TTML2. Based on what Glenn just said I'm really concerned here 14:20:29 .. about replacing TTML1 references with TTML2 ones. 14:20:49 Andreas: I think this is really important, that IMSC vNext is a strict superset of 1.0.1. 14:21:03 .. The question for this superset in the next version of which version of TTML should be 14:21:16 .. referenced for already present features is not easy to answer. If we change any TTML1 14:21:28 .. reference to TTML2 that could be a blocker for adoption of IMSC vNext because all 14:21:47 .. implementers need to check everything that's referenced and verify that their 14:21:56 .. implementation is still compliant. 14:22:12 Pierre: I thought the goal was to make TTML2 a superset of TTML1, but are you saying 14:22:29 .. that a TTML2 processor would process a document differently from a TTML1 processor? 14:22:42 Glenn: Not if it is processing it as a TTML1 processor. 14:22:46 Pierre: What has changed? 14:22:59 Glenn: Lots of things, I'd have to check. Looking at the version number, treating origin and 14:23:18 .. position if both are present - if processing as a TTML2 document it would use position 14:24:54 .. in preference to origin. 14:26:48 Nigel: I think that's a different question - position would never be present in a TTML1-only document. 14:27:11 Mike: But other TTML2 properties may be added to a TTML1 document, such as disparity, 14:27:33 .. as has been adopted by ATSC. If the presence of that TTML2 attribute triggers different 14:27:49 .. processing of the whole document than in TTML1 that would be a worry. 14:28:41 Glenn: It may be that we need to think about this a bit more. 14:28:56 Pierre: I'm happy to back out the TTML2 references and replace by TTML1 in IMSC vNext, 14:29:05 .. or I'm equally happy to make TTML2 a superset of TTML1. 14:29:17 Glenn: It is a superset in that it supports the features. The question is which mode is it 14:29:33 .. operating in, either with the knowledge of some fixes relative to TTML1, or if the author 14:29:52 .. declares that it's a TTML2 document, and puts a version="2" parameter on it, then the 14:30:01 .. author has said that TTML2 rules should apply. 14:30:14 .. I don't see this as a binary answer. 14:30:24 Mike: In the case of TTML1 vs TTML2 we can sort that out as we go, but in the case of 14:30:42 .. IMSC vNext it's fundamental. If the intent is backwards compatible then that's a different 14:30:58 .. thing to "it's compatible with some different behaviours". 14:31:01 Glenn: I agree 14:31:16 Mike: I'm aligned with Andreas that IMSC vNext should be a superset of IMSC v1.0.1. 14:31:44 Glenn: It may be that when there is an identified difference, I wonder if we can make a default choice without studying each case. 14:31:56 .. Absent of information, I would assume that a reference to TTML1 would be a safer bet 14:32:04 .. than simply adopting references to TTML2 across the board. 14:33:36 Nigel: How does rendering using CSS factor into this, given that we're putting the mappings 14:34:10 .. from TTML style attributes to CSS informatively into TTML2? 14:34:29 Pierre: If we want to continue referencing TTML1 for processing behaviours but also add 14:34:46 .. TTML2 features like ruby, then we will have to create new features for that syntax. We 14:35:04 .. can't reference the TTML2 features because that brings the whole TTML2 processing model. 14:35:11 s/new features/new extension features 14:35:24 Pierre: For disparity it's not an issue but for something like Ruby then it might be an issue. 14:37:15 Nigel: Adding something else into the mix here, we have an intention to work on TTML1 Third Edition 14:37:51 .. which essentially backports the important fixes to TTML1 Second Edition. Which version 14:38:00 .. of TTML1 do we want to reference in IMSC vNext? 14:38:34 Pierre: Going back to Andreas's suggestion, if we explicitly state in TTML2 that the 14:38:47 .. processor should process TTML1 documents as TTML1 then we'd be good right? Why 14:38:51 .. can't we say that? 14:39:08 Nigel: I have no reason not to be able to say that. 14:39:37 Pierre: Can we say in TTML2 that a TTML2 processor should process a TTML1 document 14:39:41 .. exactly as a TTML1 processor? 14:40:05 Glenn: Yes, that's always been the goal. 14:40:11 .. There are no blanket statements to that effect. 14:40:26 Pierre: Then we have the specific issue here that Mike has raised - that ATSC allows 14:40:45 .. tts:disparity to be used in a TTML1 document without specifying ttp:version="2". 14:41:00 .. Could one solution in the case of IMSC vNext be never to use ttp:version="2" except when 14:41:19 .. using a whitelist of features that are known to affect the processing model. Or prohibit 14:41:39 .. ttp:version altogether? 14:42:00 Andreas: A question for my understtanding for ttp:version - if we have a TTML1 document 14:42:15 .. and we add ttp:version="2" the rendered outcome of a TTML1 document would be no 14:42:26 .. different from a TTML1 processor at the moment? That should not have any effect on the 14:42:31 .. outcome. 14:42:53 Pierre: The particular example that Glenn brought up is position, if ttp:version="2". 14:43:12 Glenn: More substantively if there's no profile present then signalling ttp:version="2" 14:43:31 .. causes selection of a different default profile. If it is missing then the default would be 14:43:44 .. as in TTML1, the old DFXP profiles. However if ttp:version="2" is present then it would 14:44:00 .. substitute the TTML2 default profiles which bring in new processor profile defaults. 14:44:18 Pierre: If ttp:version is absent, and a TTML2 processor encounters a ruby element what does 14:44:21 .. it do? 14:44:37 Glenn: It depends on whether it is processing it as a TTML1 or a TTML2 document, independently of ttp:version. 14:44:49 .. If it is processing as a TTML1 document then it might ignore ruby even if it knows how 14:45:01 .. to process ruby. That's an implementation choice. We can't from a spec perspective 14:45:13 .. mandate the implementation in terms of backward compatibility in this regard. 14:45:26 Pierre: If we remove ttp:version and let profile signalling completely drive processing then 14:45:32 .. there would be no ambiguity. 14:45:49 Mike: An IMSC1.0.1 document could add all the vNext features, and the processor might 14:46:05 .. understand it, then the version becomes critical, because you're explicitly telling the processor 14:46:11 .. to do something different. 14:46:34 Pierre: In the case of IMSC vNext there would be a profile identifier so version wouldn't be needed. 14:46:47 Glenn: I disagree. We changed the profile mechanism. The processor needs to know which 14:47:02 .. profile processing system is being used. 14:47:15 Pierre: The mere presence of ttp:contentProfiles signals that the new system is being used. 14:47:31 .. The processor can unambiguously identify which TTML version it would be using. 14:47:48 Glenn: You're suggesting removing ttp:version and adding an algorithm for deriving the 14:47:59 .. TTML version being used. I don't see that as being any different. 14:48:23 Pierre: I'm addressing the case identified by Mike that everyone might start putting ttp:version="2" in the IMSC documents. 14:48:34 Glenn: That's maybe something that IMSC vNext should say something about but I see it 14:48:44 .. as a different issue from what is in TTML2. 14:49:08 Pierre: TTML2 requires ttp:version="2" if any TTML2 feature is used including ttp:contentProfile. 14:49:14 .. That's what the thread has said. 14:49:31 Glenn: No you're overstating it. I said if an author requires TTML2 processing they can 14:49:50 .. specify it. They can still not do so. If they fail to do so then it would still provide some sort 14:50:01 .. processing dependent on the implementation. I guess the question is what should TTML2 14:50:13 .. say regarding documents without ttp:version that do use a TTML2 feature. My response 14:50:28 .. would be as an implementer, since the author hasn't said it is required, I would derive it 14:50:42 .. using other methods, for example seeing if contentProfiles were present. I don't know 14:50:56 .. what you can say about authors blanket putting ttp:version in the document. Maybe add 14:51:16 .. a big warning saying "If you put ttp:version="2" then that may cause processing differences in TTMl2 processors compared to TTML1". 14:51:33 Pierre: What will ATSC signal as the profile in documents with tts:disparity? 14:51:50 Mike: There's no choice, just IMSC 1.0.1 with the extensions and with no other signalling. 14:52:02 .. I don't remember if we suggested explicitly stating the profile. 14:52:10 Pierre: Yes, IMSC, absolutely. 14:52:24 Mike: Ok, but there's no version, or other profile and there probably never will be. To the 14:52:54 .. extent that IMSC 1 is deployed in the US, nobody believes that the additions in IMSC vNext are needed. 14:53:19 .. If the additions land somewhere else, in a different country, what is an ATSC decoder 14:53:35 .. going to do? I don't know, this isn't heading in a good direction... 14:53:59 Pierre: Imagine an IMSC 1 processor - it would ignore tts:disparity. 14:54:19 Mike: The ATSC processor would know what to do with it. It was explicitly agreed by this 14:54:29 .. group that an IMSC processor ignore attributes it doesn't understand. 14:54:47 Pierre: Now the same document appears in a non-ATSC decoder, but one that is IMSC vNext, 14:55:25 .. and it is labelled as IMSC v1 and there's no profile, and it has tts:disparity, are we trying 14:55:44 .. to solve the case of what it does? 14:56:10 Andreas: Isn't the question if we can make IMSC vNext use TTML2 processors in a TTML1 processor? 14:56:23 .. If a TTML2 feature is used then the processor must be a TTML2 processor. 14:56:58 Pierre: It's hard to specify that, is TTML2 processing required whenever a TTML2 feature is encountered? 14:57:20 Glenn: Here's something to consider: a complicated thing was introduced in HTML5 - is it compatible with previous specifications? 14:57:37 .. Probably not. Have implementers verified that it's compatible with their own implementations? 14:57:49 .. Probably not. It was just defined. We have a similar issue. We have to go ahead with 14:58:11 .. caution about changes that affect processing in older processors. I don't know how we 14:58:24 .. check that we don't break compatibility. It's not out intention to break it, and I don't have 14:58:32 .. a list where we have made that decision either. 14:58:40 Mike: I understand the analogy, I'm not sure it's a good one. 15:01:15 Nigel: It's hard to move from the abstract to the concrete without any specific examples 15:01:28 .. where a TTML2 processor has a significantly worse presentation than a TTML2 processor 15:01:32 .. for a TTML1 document. 15:01:50 Pierre: I'm encouraged by Glenn's response that there's no intention to differ. Glenn, do 15:02:08 .. you have any objection to making a blanket statement in TTML2 that a TTML2 processor 15:02:30 .. processing a TTML1 document should yield identical results? 15:02:35 Mike: Be careful of the language. 15:02:45 Glenn: Tbd the language, but I have no reason to object to doing so. 15:03:04 .. The question is do we want to introduce extra language. I think I added a compatibility section. 15:03:14 Pierre: I would add it up front in the scope so the objective is clear. 15:03:33 Glenn: Putting that in the front matter should be okay. I'm just going to find the section I think I added. 15:03:51 Andreas: [I have to drop off] I support what Pierre suggested. It's a good opportunity to 15:04:11 .. start the IMSC requirements and to keep the backward compatibility, which means that 15:04:24 .. a TTML2 feature being used in an IMSC vNext processor would not change any TTML1 15:04:29 .. features used in IMSC. 15:04:43 Glenn: I added §3.4 under conformance, and it has forward and backward sections. It is 15:05:06 .. marked as non-normative but says things along the lines of what we're talking about. 15:05:17 Mike: The conformance is one angle - it's important that a presentation processor also 15:05:21 .. does the same thing. 15:05:51 .. Currently all the language is about conformance of documents as opposed to rendering. 15:06:05 .. Let's work on the language a bit - I'll take a run at it. 15:06:11 Glenn: It's §3.4 in TTML2. 15:06:44 .. I recall we had a look at this in the past for TTML2 too. 15:07:12 SUMMARY: Mike to study TTML2 §3.4 and propose any modifications. 15:08:20 Topic: SMPTE backgroundImage deprecation 15:08:28 Nigel: We should defer discussing this. 15:08:37 Pierre: Maybe a public document would help also. 15:16:55 Topic: TTML2 Wide and Horizontal Review 15:17:30 Thierry: I went through the archives and verified all the comments sent in are there plus 15:17:48 .. I've added some sent as liaisons. They're all on GitHub. Some issues don't need any 15:18:01 .. processing - if they say everything is fine. I still put them on GitHub so they will be on 15:18:17 .. our disposition of comments. All the comments have a label, open, pending, etc. When 15:18:26 .. the issue status changes we will add a new label. 15:18:33 Nigel: Fantastic, thanks for that - a lot of work. 15:18:36 Action-506? 15:18:36 Action-506 -- Thierry Michel to Draft a wiki page explaining our review and disposition steps and labels -- due 2017-09-21 -- OPEN 15:18:36 http://www.w3.org/AudioVideo/TT/tracker/actions/506 15:18:43 close action-506 15:18:43 Closed action-506. 15:19:26 Nigel: There were a number of issues that said thank you, they would look at TTML2 but 15:19:31 .. not before 30th September. 15:19:46 Thierry: If you agree I would take the action to write to them to say we will process their 15:19:54 .. comments but they should send them ASAP after their meetings. 15:20:05 Pierre: I recommend to do nothing, and process them when they come in, and put them 15:20:18 .. in a queue. 15:20:30 Thierry: I've had comments come in 6 months late in the past and the Director still wants 15:20:34 .. to take them into account. 15:20:47 .. I want to add a bit of pressure. 15:20:55 Pierre: They know how this works, I would say nothing! 15:21:20 Nigel: I'm happy to do nothing - they've told us they will do something and we should assume that they will do so. 15:22:00 .. I just wanted to check if we want to explicitly extend the deadline. 15:22:03 Pierre: I would not. 15:22:07 Thierry: I would not. 15:22:38 Glenn: I agree, the deadline has passed. I would not put those in as wide review comments anyway, they're not comments about the spec. 15:23:34 Nigel: The point at which we draw a close to the wide review opportunity is when we 15:23:41 .. have agreed to request transition to CR. 15:23:44 Thierry: Correct. 15:23:59 Mike: Would it help to track comments as late and put them at the bottom of the pile. 15:24:14 Pierre: I like that, a priori put them at the bottom of the pile unless we all see that it's a big 15:24:16 .. issue. 15:25:17 Nigel: Okay this is all fine for me, thanks everyone, we don't need to take any action at all here. 15:25:38 .. We simply need to come up with a disposition for every substantive comment. 15:25:56 Thierry: Some issues are marked as editorial - we should have a type label for editorial vs substantive. 15:26:01 Nigel: That works for me. 15:26:29 .. I think in the old tracker there was a flag for exactly that. 15:26:45 Action: Thierry Check if there are editorial/substantive labels for TTML2 issues and add if not. 15:26:45 Created ACTION-508 - Check if there are editorial/substantive labels for ttml2 issues and add if not. [on Thierry Michel - due 2017-10-12]. 15:27:33 Nigel: Between now and next week please could everyone look at the GitHub issues and 15:27:48 .. propose any dispositions, so that we can start to agree them in next week's meeting, or 15:27:53 .. at any rate discuss them? 15:29:30 Glenn: I've already addressed a couple of TTML2 issues, so if we can get resolution on those 15:29:36 .. today then I would be happy to close something. 15:29:40 Topic: IMSC vNext FPWD 15:30:04 Pierre: I propose a 1 week review of the draft and the requirements document, which go 15:30:37 .. hand in hand, and I keep synchronised. If there are no major objections publish as a FPWD 15:30:50 .. and send a liaison informing them of the beginning of this work and inviting them to provide comments. 15:31:13 Nigel: What's the URL of the thing we're discussing? 15:31:50 .. I see that IMSCvNext is not on the master branch of the imsc repo. 15:33:01 .. Can we put IMSC vNext in a new folder so we don't get a clash of URIs. 15:33:42 Pierre: I didn't do that because then I'd have to synchronise IMSC 1.0.1 changes with 15:33:52 .. vNext. Also we haven't got a name for it yet. 15:34:05 pal has joined #tt 15:34:08 https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d9799609814299e4b361cf/imsc1/spec/ttml-ww-profiles.html 15:35:05 Nigel: Given that we're not proposing a pure subset of TTML2 I would propose calling this 15:35:23 .. IMSC v1.1, especially since we seem to be targeting IMSC 1 compatibility. 15:35:28 Pierre: That's what I'm thinking too. 15:35:55 Nigel: In that case I think we need an imsc1_1 folder. 15:36:33 Pierre: I really would like to delay that as much as possible. Once it's published on /TR 15:36:42 .. it doesn't really matter where it is in the repo. 15:37:30 Nigel: It makes it really awkward to navigate though. When would you move it to a different folder? 15:37:37 Pierre: I think it will become obvious. 15:37:59 Nigel: We're not really expecting any changes to 1.0.1 15:38:14 Pierre: Compare with software development - you'd maintain different versions on different branches. 15:38:33 .. Here all the tests, examples etc are going to be substantially the same. 15:38:42 Nigel: The other thing you'd do is use release tags. 15:39:19 .. Okay, Pierre, you proceed as Editor. 15:39:25 Pierre: Can you request a short name? 15:39:30 https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0005.html 15:40:09 Thierry: Yes I will. Just to let you know there's a new rule as per the above link, and it 15:40:22 .. would be worth Editors looking at this. 15:41:05 Nigel: This is a convention for Latest Version links, mainly. 15:41:34 .. Thanks for the reminder Thierry, I had seen that and not taken any action. 15:42:21 ttml-imsc1.1 15:43:11 PROPOSAL: Publish a FPWD of IMSC v1.1 with the short code ttml-imsc1.1, based on the ED in the IMSCvNEXT branch 15:43:21 Pierre: Would you like me to propose liaison text? 15:43:24 Nigel: Yes please 15:43:50 Action: pal Propose liaison text for the IMSC 1.1 FPWD 15:43:51 Created ACTION-509 - Propose liaison text for the imsc 1.1 fpwd [on Pierre-Anthony Lemieux - due 2017-10-12]. 15:44:10 action-507? 15:44:10 action-507 -- Nigel Megitt to Add imsc vnext repo to agenda, board, github-bot etc -- due 2017-10-05 -- OPEN 15:44:10 http://www.w3.org/AudioVideo/TT/tracker/actions/507 15:44:48 Nigel: I link from the agenda to http://www.w3.org/AudioVideo/TT/board/ 15:45:01 .. Has anyone here ever followed that link and looked at it? 15:45:06 Pierre: I have not. 15:45:10 Thierry: No. 15:45:17 Nigel: Does anyone use it? 15:45:29 Pierre: I didn't realise it existed 15:46:07 Nigel: The reason I ask is that if nobody uses it then I will drop it; conversely I could maintain it. 15:46:28 Thierry: I think it's valuable. I did use it some times, I recall, but I'd forgotten about it. 15:47:00 Nigel: Okay I'll update the board and continue with it. 15:48:07 Topic: TTML2 #454 Missing ruby attributes from list of styling attributes 15:48:14 github: https://github.com/w3c/ttml2/issues/454 15:48:29 Glenn: This was an editorial change, I've already fixed it and updated the ED. 15:49:42 .. I guess we can change the status of this with labels. It's done. 15:49:56 Nigel: I see, there's nothing significant to review here - Thierry do you want to apply the 15:49:59 .. appropriate labels? 15:50:21 Thierry: Yes, it's spec updated and WG approved. 15:50:28 Nigel: I've assigned it to you Thierry. 15:50:55 Topic: TTML2 #440 Condition attribute missing in Core catalog. 15:51:04 github: https://github.com/w3c/ttml2/issues/440 15:51:19 Glenn: This is from Andreas and he's reviewed to say it looks good. 15:51:54 Nigel: Okay I'm assigning to Thierry to update the labels. 15:52:26 Thierry: Once we have all three of: WG resolution + spec updated + commenter agreement 15:52:30 .. we can close issues. 15:52:44 Glenn: What if we cannot get agreement from the commenter, do we have to leave issues 15:52:50 .. as open if we have disagreement? 15:53:03 Thierry: We can close issues but it will red flag to the Director that we will have to explain 15:53:10 .. to the Director. 15:54:26 SUMMARY: WG approves, Thierry to update labels 15:55:23 Topic: Other TTML2 issues 15:55:30 Glenn: We haven't discussed XML, CSS comments etc. 15:55:57 Pierre: I would like to close those issues off, so can we schedule a time to do so? 15:56:17 Nigel: Sure, if we cannot resolve it on the GitHub issue. 15:59:33 .. We have discussed over the years some issues about time, mediaOffset, and begin and 15:59:49 .. end clipping, which I want to resolve soon too. 15:59:56 Glenn: Check if there are existing issues. 15:59:58 Nigel: Will do. 16:00:13 Topic: Meeting close 16:00:36 Nigel: Thanks everyone, we've done what we could on the agenda. [adjourns meeting] 16:01:05 rrsagent, make minutes 16:01:05 I have made the request to generate http://www.w3.org/2017/10/05-tt-minutes.html nigel 16:03:09 s/OK got that for the agenda, anything else./OK got that for the agenda, anything else? 16:10:37 s/vNext use TTML2 processors in a TTML1 processor?/vNext use TTML2 features in a TTML1 processor? 16:11:20 s/Tbd the/TBD the 16:13:35 s/bottom of the pile./bottom of the pile? 16:14:17 s/a clash of URIs./a clash of URIs? 16:16:11 rrsagent, make minutes 16:16:11 I have made the request to generate http://www.w3.org/2017/10/05-tt-minutes.html nigel 16:17:44 scribeOptions: -final -noEmbedDiagnostics 16:17:46 rrsagent, make minutes 16:17:46 I have made the request to generate http://www.w3.org/2017/10/05-tt-minutes.html nigel 16:26:55 Zakim has left #tt