Timed Text Working Group Teleconference

<cyril> scribe: cyril

nigel: Quick summary of last week: we went through all of our requirements and decided if we want to go with them or not in 2019
... and decided to go with the idea of a modularization
... we'll have a draft charter update by the end of Februrary

plh: do you need anything?
... I will share the charter template that we have

nigel: it might already by done because we have a TTWG charter

plh: we keep changing the template efvery two months

<plh> ACTION: plh to refresh the Timed Text charter draft [recorded in https://www.w3.org/2019/02/07-tt-irc]

<trackbot> Created ACTION-515 - Refresh the timed text charter draft [on Philippe Le Hégaret - due 2019-02-14].

nigel: we are not using the tracker anymore but a github repo
... also to host the wg home page

plh: I recorded the action because it's easier for me

nigel: it'd be good to have it as an issue on the TTWG charter repo

glenn: I have a short item for philippe
... regarding the TTML3 repo

nigel: we'll discuss it in the AOB

TTML Profile Registry Actions, Pull Requests and Issues

nigel: we have both editors
... no specific agenda
... but bunch of issues open
... one about whether we ought to use specref to W3C documents

plh: my recommendation is to try to use specref as much as possible
... but it also has its own limitations

glenn: my position is that because arbitrary changes can be made in specref it creates an instability
... a normative ref can be changed underneath

plh: you need to specify a dated reference

glenn: a specific commit in the repo?

<plh> https://www.specref.org/?q=ttml1

plh: example TTML1
... if you search specref, you have lot of entries
... you can find a specific version

glenn: what is preventing this ref from changing under me

<plh> eg [ttml1-20181108]

nigel: for all of the W3C reference it is using the TR spec as a reference for sourcing the info
... the only way it can change is if the TR document changes

plh: specref pulls data from databases (IETF, W3C, ...)
... no change out of the blue

glenn: are you claiming it is impossible to have a change

plh: no in theory
... it's possible but hard

glenn: it makes me uncomfortable to delegate the handling of normative references

mike: I like stable documents, but no comment

glenn: you have no objection to us delegating the normative references

mike: seems that W3C staff don't worry about that

pal: can this be settle offline
... can we move to something more substansive
... I think we have discussed it enough

<inserted> Nigel: No, this question is blocking substantive changes, we need to deal with it.

plh: if you are referencing a dated version, chances that it changes behind your back are null

glenn: I'm willing to compromise with the following condition
... if the information pulled from specref is indentical to what we would put locally
... I can accept this
... but in some cases it produces something inconsistent
... for example there was an issue btw WG Note vs non Note

<nigel> PR diff

plh: it is substantively the same

glenn: it would be good for W3C to take over responsibility

plh: which tool are you using respec, bikeshed, ...

glenn: respec

plh: marcos is a great guy and I hope he'll keep maintaining it
... I'm willing to fix any issue that are not solved in respec
... W3C staff commits to ensure that respec or specref still satisfy the needs of the WG

<inserted> Glenn: With that commitment I can accept this change.

nigel: there is one other PR but it does not need discussion as it can be unlocked now
... can we get a view from the editors as to how much work is needed to publish a new version

glenn: since this issue of respec has been blocking me, I have not worked on it. Now I can work on it
... I need to take today's decision into account
... but we should be able to move on

mike: when I said I'd be happy to be editor it was to add more profiles, not to rewrite everything
... it might be better if someone else would approve the PR

nigel: are you asking not be editor anymore?

mike: yes because I'm not up to why these changes are necessary

nigel: glenn seems happy to make the changes

TTWG Future requirements

nigel: we are in a pretty good place after last week's meeting
... I have an action to try to address the vagueness of one or 2 requirements
... certainly one for spoken/audio subtitles
... everything else is pretty much agreed
... thanks andreas to volunteer as primary editor for the VR/360 module work
... drafting an explainer document would be helpful internally and externally
... for horizontal review groups, including the tag
... I sent an email explaining how to write an explainer

<nigel> TAG Explainer for Explainers

nigel: if we can all look at the requirements for which we have ownership and write something short
... for mid march
... I'd suggest we do it as a markdown document, for speed
... it makes sense to do that in the requirements repo
... maybe we will need separate repos per module

glenn: should it be in the TTML3 repo or not
... I can see both ways

nigel: same here
... in the CSS WG, they have a single CSS WG repo

glenn: I think that's crazy personally, too hard to manage

plh: our tooling works better if we have one spec per repo
... I would recommend creating a new repo for TTML3
... but you would need to transfer issues

glenn: I did
... the only negative I can see is since TTML3 is going to be depending on TTML2 2nd edition, it will be complicated

cyril: why this dependency?

glenn: we are going to have TTML3 reference TTML2

[discussing fork considerations]

plh: I see that TTML3 repo seems configured properly

glenn: I need you to enter the deploy keys
... and the webhooks, I created them manually
... I tried to make them identical to TTML2

plh: the repo manager needs to be the one setting it up
... can you write this down in an email
... and I'll do it

glenn: yes

TTML in RTP IETF submission

<nigel> IETF submission

nigel: we had some interesting feedback, some of which already taken into account
... the idea of this is that it defines semantic for carrying TTML in RTP streams for live workflows
... RTP transports data over UDP
... and is used for live low latency streaming
... used by SMPTE 2110
... part of the work from BBC is to enable a 2110 for TTML
... mike provided feedback
... we have already updated
... 3 times
... also even if we have copied the media type registration it says the change controller is W3C

mike: I still think it's awkward to do that
... having a 3rd copy is not a good idea
... it belongs in TTML W3C documents
... I understand and for 99% of the RTP spec it is fine, but this is a special case
... I think it should be reviewed formally by IETF experts
... the other comment is on the emphasis put on EBU-TT-D
... it's fine to have an example
... but it should at least include W3C IMSC
... it shouldn't be only EBU-TT-D

nigel: I'm not sure it mentions EBU-TT-D
... I'm not clear where you see the emphasis

mike: the fact that it mentions EBU only and not IMSC is the concern

nigel: there is one mention of EBU TT live because it's the only profile for live
... in the most recent draft, there is an example with codec = im1t
... in 7.7.3.1
... I would recommed you look at the more recent version

mike: do we as W3C log comments as a group or individuals

nigel: I'm neutral on this
... IETF accepts individual contributions
... but we can also send comments if needed

atai: the discussion with other standards group on this document would be good
... sending liaison letters, collecting feedback
... another way would be to organize a call between BBC, W3C and EBU
... could nigel/bbc organize it?
... is this a good idea?

pal: I'd like to echo andreas comment
... I'm not quite sure what are the use cases, how people will use it
... coordination between groups
... more discussions on the target use cases
... EBU TT Live can be used with other profiles IIUC

<cyril_> scribe: cyril_

nigel: this is absolutely not limited to EBU
... and relies on the signaling of the codec
... the use case in general is the live contribution of subtitles from an authoring environment to an encoder
... it's not typical to use RTP for sending to client devices
... on the idea to have a session to explain what we are trying to do
... I'll bring that to my colleague
... not sure it's needed, but we'll see

atai: we are in a critical time
... last week we discussed bringing live TTML to W3C
... we have a triangle: EBU / W3C / BBC
... if some of us have trouble understand this constellation, outsiders will have problem too
... we should be clear on the communication

<mike> draft...02 says: 8. IANA Considerations This document makes use of the media type application/ttml+xml. The media types registry SHOULD be updated to make reference to this document for the application/ttml+xml media type.

atai: we should not jeopardize the goal we set last week

mike: I posted on IRC that the latest draft is pointing the IANA to this document
... "media types registry" means IANA registry
... this is very clear

nigel: I see
... I completely agree
... what should be updated is the TTML profile registry
... nothing in the base IANA registry

mike: my position is that it should not be there at all, and yes this is an exception, but there is a good reason

cyril_: I agree with mike's position

nigel: I also
... I feel that we have consensus for that
... I'll make sure that comment is registered

glenn: I haven't read the draft RFC but can you make sure there is language that makes sure that the codecs parameter is not capable of denoting all profiles
... in particular since the document can embed a profile, it cannot be in the codecs parameter
... maybe we should have a value like 'internal'
... for embedded profile definition

nigel: maybe we want to do the opposite and say that you shall signal a profile that matches the document
... at the moment it says 'if ...'

<mike> this would require an update to our existing media type definition (unrelated to the draft RFC)

<nigel> If signalling this processor profile in the "codecs" parameter of the media type, the registered short code for the processor profile SHOULD be combined with each other applicable processor profile using the "+" operator.

<nigel> scribe: nigel

Nigel: Thanks everyone for that feedback. I would encourage everyone to look at this document on the IETF datatracker
... and I can either collate feedback here and provide it as Chair of TTWG or you can feed back directly.
... Right now I have two items of feedback - a very clear one from Mike, and another that I will need to check back with
... Glenn on for the nuance, to make sure I've understood it correctly.
... We're out of time now so I'll adjourn. We covered the AOB items already. Thank you everyone! [adjourns meeting]