16:02:17 RRSAgent has joined #tt 16:02:17 logging to https://www.w3.org/2019/03/07-tt-irc 16:02:19 RRSAgent, make logs public 16:02:19 Zakim has joined #tt 16:02:21 Meeting: Timed Text Working Group Teleconference 16:02:21 Date: 07 March 2019 16:02:45 Log: https://www.w3.org/2019/03/07-tt-irc 16:02:54 Agenda: https://github.com/w3c/ttwg/issues/25 16:03:06 Present: Philippe, Andreas, Glenn, Pierre, Nigel 16:03:22 Regrets: Cyril, Gary, Thierry 16:03:27 Chair: Nigel 16:03:29 scribe: nigel 16:04:02 Topic: This Meeting 16:05:03 Nigel: [iterates through current draft agenda] 16:05:34 atai2 has joined #tt 16:05:41 https://github.com/w3c/w3process/issues/79 16:05:46 .. AOB? Or other points to get to? 16:06:05 Philippe: Yes, evergreen standards - see above link 16:06:13 .. I made a proposal 2 days ago on how the process will change to do this. 16:06:23 .. Major use case is Registries, so it is highly relevant for this WG. 16:06:39 .. If this proposal does not help answering the question How to do Registries in TTWG, then the proposal is broken. 16:06:56 .. We're looking at feedback and it would be helpful to get support, especially from you Nigel. 16:07:07 .. It's very early, we expect the wording to change based on comments in the Process CG. 16:07:17 .. We're getting some reluctance from the Process CG to consider it. 16:07:54 Nigel: Thanks for that. As a matter of fact I've started looking at it and will have some feedback. 16:08:40 Topic: TTML Profile Registry 16:09:02 Nigel: There are no pull requests open and 2 issues open. 16:09:43 Present+ Mike 16:10:06 Nigel: Going back to the question from 2 weeks ago, are we happy to continue with the current modus operandi? 16:10:11 Pierre: It's great to see progress, thanks. 16:10:34 Nigel: Great, if no other comments let's keep going and work towards publication as soon as possible. 16:11:43 Topic: Elaborate + and | operators further. tt-profile-registry #62 16:11:49 github: https://github.com/w3c/tt-profile-registry/issues/62 16:12:37 Glenn: I added a comment after the last meeting that the intent of the + and | operators is not to map 16:12:53 .. directly to a combination method in TTML2 but to serve as a shorthand for the any and all syntax defined for 16:13:03 .. use with the processorProfiles attribute currently defined. 16:13:14 .. There's no mapping of those to the combination method logic which is an interesting point 16:13:22 .. and potential discrepancy for us to address. 16:13:39 .. Another point I noted was that the syntax we defined for these operators allows for a combination of any and all 16:13:55 .. which is not directly supported by processorProfiles which raises a question if we should have those combinations 16:14:11 .. or if we should add the support to the attribute or restrict codecs to disallow them. 16:14:23 .. Those are questions in my mind that I need guidance from the group on. 16:14:58 .. If we make any changes then they would need an IANA registration because they are in the body of the media 16:15:06 .. type registration, so I'd like to hear what the group thinks in this regard. 16:15:08 q+ 16:15:12 pal has joined #tt 16:15:39 .. It's possible to have a richer logic here that is not directly supported in TTML2 on the presumption that 16:15:51 .. processing them is done in the envelope before TTML2 processing per se, as a precursor. 16:16:04 .. If that is the case then there is no strong mandate to support combination of the two operators. 16:16:27 .. But I wanted to mention that it is possible to have a larger set of semantics apply to codecs than we have at the moment. 16:18:26 Nigel: My view is we should not change the media type registration and instead add an informative 16:18:44 .. link to the processorProfiles algorithm in case computation of combined processor profiles is desired, 16:19:01 .. and we should also further explain the processorProfiles combination algorithms in TTML2 with respect to the 16:19:04 .. combine semantics. 16:19:08 ack ni 16:19:35 Glenn: What do you have in mind, a note in the body of the media type where it talks about the two operators? 16:19:53 .. Something to say that the two operators are intended to be similar functionally to any and all in processorProfiles? 16:21:10 Nigel: you may want to use the processor profile mechanism to compute, but there is no requirement to do so 16:21:31 Glenn: Please could you add comments in the issue so we can continue the conversation? 16:21:35 Nigel: Yes, will do. 16:21:43 q? 16:22:20 Topic: The codecs parameter and media type registration. tt-profile-registry#63 16:22:27 github: https://github.com/w3c/tt-profile-registry/issues/63 16:22:43 Glenn: The main point here is that we have not defined the syntax of the codecs value space in a formal fashion. 16:23:01 .. We did refer somewhere to IETF6381 but that reference is not in the media type definition itself where it should 16:23:11 .. probably be, close to the definition of @codecs. 16:23:37 .. To be syntactically complete it should say that the syntax corresponds to 6381 and we should define a subset 16:23:54 .. for use here. In the comment I proposed a specific syntax which I believe corresponds to what we have right now. 16:24:11 .. We should have some conversation in the thread to decide what actions to take. 16:24:27 .. If we are changing the media type definition of codecs in this regard then I realised at the last meeting a couple of 16:24:46 .. people including Pierre seemed to express an opinion that we do not want changes to the body, but Mike is saying 16:24:52 .. we need to make these changes and have the review. 16:25:10 Nigel: What would be the worst thing that could happen if we didn't do this? 16:25:10 Nigel: what are we trying to solve? 16:25:28 Glenn: Someone could create a codecs parameter that doesn't match the syntax in that comment. 16:25:36 .. Right now we are controlling the tokens used for short identifiers. 16:25:46 .. We can insist on only short identifiers that match that syntax. 16:25:54 q+ 16:25:59 .. We informally defined the + and | syntax in a way that matches. 16:26:04 .. In reality there is no huge problem. 16:26:16 .. Mike is pointing out that formally we haven't defined the syntax properly. 16:26:18 ack m 16:26:24 Mike: Glenn said what I was going to say. 16:26:41 .. It needs fixing up but because we're in the loop we can prevent anyone from doing any evil. 16:26:51 .. The syntax conforms so long as we don't allow silly profile codes. 16:26:54 q+ 16:27:38 ack n 16:27:53 Nigel: Can we add to the requirements for registration that we will not allow short codes that would, if used, 16:27:58 .. violate 6381? 16:28:05 Glenn: That would work, put the requirement on us. 16:28:15 .. You're trying to do this without changing the media type body, right? 16:28:17 Nigel: Right! 16:28:35 Philippe: Are you trying to avoid a review from IESG or someone else? 16:28:41 Glenn: Yes, that's the point. 16:28:48 Philippe: It's relatively easy to do it these days. 16:29:05 Pierre: Based on the last thing you said Glenn, and what Mike said, why would there be a need to change the 16:29:16 .. registration if the syntax just happens to be compatible with 6381? 16:29:29 Mike: The constraint is on the codecs parameter not on the codes, but it turns out if you're careful about choosing 16:29:34 .. codes then you can't get into trouble. 16:29:42 Mike: I think it should be, but not urgently. 16:29:59 Pierre: So one approach is to have the text outside the registration text today and at a later date if we need a change 16:30:06 .. for some other reason then bring it into the registration? 16:30:07 Mike: Yes 16:30:13 https://w3c.github.io/tt-profile-registry/#Registration_Entry_Requirements_and_Update_Process 16:30:18 Glenn: A reminder about section 3 of the document ^ 16:30:35 .. This defines the process and already refers to 6381. 16:31:16 .. Point 1 makes the correct technical point already, and prohibits + and | characters which removes the 16:31:24 .. possible collision between the identifier and the operator syntax. 16:31:29 .. We may already be covered here! 16:31:31 Nigel: +1 16:31:57 Mike: I don't disagree, but the constraint is in the wrong place. The codecs string has to conform to 6381. 16:32:08 .. Yes we've backed ourselves into probably being okay. 16:32:09 q+ 16:32:22 ack n 16:32:34 Nigel: Is there some other spec that already requires codecs parameters to adhere to 6381? 16:32:55 Mike: Yes and no. Codecs here is particular to this media type. There's no overreaching global codecs. They're defined 16:33:14 .. in each type separately and mostly adhere to 6381. 16:33:26 .. If you want to use it in DASH and other places then it must adhere to 6381. 16:33:36 .. The genesis of this is to work in those contexts. 16:34:02 Glenn: Right now we do conform to 6381 and if we follow our own requirements that means we will not admit any 16:34:11 .. syntactic values for the IDs that don't conform to 6381. 16:34:16 .. The operator syntax is fine. 16:34:30 .. So the only point here is whether to move that statement into the media type body itself. 16:34:43 .. Formally that would be a nice thing to do but is technically unnecessary because we are in control of the registry. 16:34:46 Nigel: I agree. 16:34:56 Mike: Near term, I am not concerned. 16:35:15 .. When we all retire and someone looks at this they might break it. 16:35:36 .. Let's leave it on the queue of things to look at if there's a reason to update the type registration one day. 16:35:51 Glenn: In general I don't like to leave issues open - can we close this and reopen in the future? 16:36:25 Mike: Can't we say in the informative text that the codecs string must necessarily also conform to 6381? 16:36:36 Glenn: Yes, section 3 is outside the media type body so we can change that. 16:36:58 Mike: Note that this is the result of the rules. 16:37:10 Glenn: Yes I could put a Note under point 1 that says just that. 16:37:46 Nigel: I think we've reached agreement. Anyone want any other action than adding that Note? 16:37:52 group: [silence] 16:38:17 RESOLUTION: Add a note under §3.1 saying the result of the requirements is to have codecs conform to 6381. 16:39:10 Topic: TTWG Future Requirements 16:39:19 Nigel: Nothing to add here, other than we need to get around to writing our explainers. 16:39:30 Topic: TTML in RTP IETF submission 16:39:49 Nigel: This was published as an ietf draft recently. 16:40:14 -> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ IETF draft payload link 16:40:56 Nigel: Any other feedback for me to gather now? 16:41:00 q? 16:41:32 Philippe: I see it says "No IANA action" 16:41:39 Nigel: That's right - it's required. It's clear! 16:42:12 Topic: WebVTT Implementation Report 16:42:36 Nigel: Gary posted an update with a pull request including features to mark as at risk - in his absence I suggest we 16:42:41 .. add review comments to the pull request. 16:43:10 Topic: TTWG Charter 16:43:19 Nigel: There are several pull requests which I opened. 16:44:14 .. I noticed pr-preview can't preview docs that aren't bikeshed or respec! 16:44:18 Philippe: I'll look into that. 16:45:20 Nigel: I opened pull requests to address all the issues I could, the others are for the team or for later, like the Chairs 16:45:23 .. and the timeline. 16:45:28 Philippe: I will do the Chairs at the last minute. 16:45:48 .. Depending on how we are dealing with WebVTT I will deal with that. 16:45:59 https://github.com/w3c/charter-timed-text 16:46:04 -> https://github.com/w3c/charter-timed-text/ Repo for the draft charter 16:46:29 Pierre: Thanks I'll watch that repo 16:47:12 Nigel: I don't want to discuss any of the pulls now but just to flag them up. 16:47:34 .. I'll try to target a fuller discussion maybe in 2 weeks time, on Mar 21. 16:48:19 Topic: Possible liaisons with MPEG and VR-IF about 360º subtitle positioning 16:48:43 Andreas: One of the requirements we want to work on is positioning of subtitles in 360º videos, 16:48:53 .. which is a general requirement for AR, VR etc. 16:49:16 .. We had a call on the M&E IG with other groups, including accessibility groups, WebVR, but still I think there is a lot 16:49:32 .. to do to get a good view on the standards situation and see what is already done, where we are, where does the 16:49:38 .. TTWG specification best fit. 16:49:41 q+ 16:49:55 .. So it needs a couple of talks more to get to the right point where our work should be done. 16:50:08 .. For a start we should contact the organisations which we know are working on this issue. 16:50:30 .. This is mostly MPEG with the OMAF format which uses IMSC to position subtitles, 16:50:46 .. and the VR-IF industry forum which gives guidance about combining existing standards. 16:50:52 .. Both could be very useful for our work. 16:51:27 .. For MPEG, because they published that they are working on OMAF already, Mike maybe could help us a bit, but MPEG 16:51:34 .. doesn't publish drafts so a liaison could help. 16:51:50 .. I had a brief conversation with someone from that group and he said that a general liaison with MPEG could be 16:52:01 .. difficult because of the different IPR policies so he suggested the VR-IF forum. 16:52:09 q+ 16:52:11 .. I think the most direct way would be to liaise with the MPEG group. 16:52:22 .. First question is how we could best do this and how we did it before? 16:52:26 ack pl 16:52:33 Philippe: Thanks for bringing this up. 16:52:33 https://gist.github.com/LJWatson/b535b30062ff681a56171582d15cbd72 16:52:47 .. Connecting the dots, there is an ongoing conversation around immersive web and accessibility. 16:53:07 .. They are looking to organise a workshop, maybe November on the west coast, and he pointed me to the gist above. 16:53:18 .. My guess is that we are going to be interested in that workshop. 16:53:40 Andreas: Yes, but it is a different question. I spoke with Judy, Janina, Chris Wilson - we already filed an issue as IRT on 16:53:43 .. the WebVR CG. 16:53:56 .. We are targeting the simple question how to position subtitles in a 360º environment. 16:54:14 .. In parallel we need to talk with the different W3C groups, which is a different issue. 16:54:24 .. There are some SDOs where we know they work on that. 16:54:43 .. At IRT we did some reviews of the document, and are not sure they understand IMSC. 16:54:44 ack m 16:55:08 Mike: To the questions about form and process, W3C is a category C liaison with ITC XXXX 16:55:25 .. and the points of contact are Jean-Claud Dufour and Daniel Dardailler 16:55:41 Philippe: Daniel has retired, I'll take the action to look at that. 16:56:01 Mike: SC29/WG11 - there's someone else listed. We can get that straightened out. 16:56:18 .. Cat C liaisons have access to MPEG work products and can deep dive in and share documents formally. 16:56:37 .. MPEG is meeting in a week and a half so if you want something then we should draft and contribute the liaison quickly. 16:56:56 Andreas: Do you suggest the W3C contact person does the liaison and builds the bridge or should we do it? 16:57:09 Philippe: My take is we should do it at the WG level which will be more efficient and better. 16:57:19 .. Daniel was overseeing the entire liaison. 16:57:46 Nigel: Andreas if you can draft a liaison then I will submit it. 16:58:02 Mike: There's a form for getting proper circulation in MPEG which I can help with. 16:58:13 Nigel: Yes please Mike! 16:58:26 Andreas: Perfect 16:58:31 Philippe: Thank you Mike 17:01:07 atai2 has left #tt 17:02:01 Topic: F2F poll 17:02:17 Nigel: The poll closes today so if you haven't responded you have a few hours left. 17:02:25 Topic: Mercurial decommissioning 17:02:40 Nigel: I haven't checked this out but my default position will be there is no action to take. 17:03:34 Topic: ITU-R BT.2342-2 Update 17:03:58 Nigel: I filed an update to the annex on IMSC via the UK body representative on the group that publishes this, as previously mentioned. 17:04:07 Topic: DST - upcoming meeting times. 17:05:56 Nigel: As per https://github.com/w3c/ttwg/issues/29 we will switch to 1600 UTC on 4th April. 17:06:02 Mike: But the meeting is still on Boston time right? 17:06:10 Nigel: No, we've been on UTC for a number of months. 17:06:16 Philippe: What time is that in Boston? 17:06:27 Nigel: I don't know! I'll send a timeanddate.com link round. 17:06:35 Topic: Meeting close 17:06:54 Nigel: We've hit the end of our time, so I'll adjourn now. Thank you everyone! [adjourns meeting] 17:07:00 rrsagent, make minutes 17:07:00 I have made the request to generate https://www.w3.org/2019/03/07-tt-minutes.html nigel 17:22:32 s/I think it should be, but not urgently./I think it should be updated, but not urgently. 17:23:47 s/it's required. It's clear!/it's a required section. At least it is clear! 17:33:40 rrsagent, make minutes 17:33:40 I have made the request to generate https://www.w3.org/2019/03/07-tt-minutes.html nigel 17:34:12 scribeOptions: -final -noEmbedDiagnostics 17:34:13 rrsagent, make minutes 17:34:13 I have made the request to generate https://www.w3.org/2019/03/07-tt-minutes.html nigel 17:34:20 github-bot, end meeting 17:34:20 nigel, Sorry, I don't understand that command. Try 'help'. 17:34:26 github-bot, help 17:34:26 nigel, The commands I understand are: 17:34:26 help - Send this message. 17:34:26 intro - Send a message describing what I do. 17:34:27 status - Send a message with current bot status. 17:34:27 bye - Leave the channel. (You can /invite me back.) 17:34:27 end topic - End the current topic without starting a new one. 17:34:28 reboot - Make me leave the server and exit. If properly configured, I will then update myself and return. 17:34:42 github-bot, end topic 19:13:11 Zakim has left #tt