{minutes} TTWG Meeting 2019-02-07

Thanks all for attending today’s TTWG meeting. Minutes can be found at https://www.w3.org/2019/02/07-tt-minutes.html


In text format:


   [1]W3C

      [1] http://www.w3.org/


                Timed Text Working Group Teleconference

07 Feb 2019

   [2]Agenda

      [2] https://github.com/w3c/ttwg/issues/17


   See also: [3]IRC log

      [3] https://www.w3.org/2019/02/07-tt-irc


Attendees

   Present
          Andreas, Cyril, Glenn, Mike, Nigel, Philippe, Pierre

   Regrets
          Gary, Thierry

   Chair
          Nigel

   Scribe
          cyril, cyril_, nigel

Contents

     * [4]Topics
         1. [5]TTML Profile Registry Actions, Pull Requests and
            Issues
         2. [6]TTWG Future requirements
         3. [7]TTML in RTP IETF submission
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <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 [10]https://www.w3.org/2019/02/07-tt-irc]

     [10] 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> [11]https://www.specref.org/?q=ttml1


     [11] 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> [12]PR diff

     [12] https://pr-preview.s3.amazonaws.com/w3c/tt-profile-registry/59/5483f8e...c847a99.html


   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> [13]TAG Explainer for Explainers

     [13] https://w3ctag.github.io/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> [14]IETF submission

     [14] https://datatracker.ietf.org/doc/draft-sandford-payload-rtp-ttml/


   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]

Summary of Action Items

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

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [15]scribe.perl version 1.154 ([16]CVS log)
    $Date: 2019/02/07 17:26:47 $

     [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [16] http://dev.w3.org/cvsweb/2002/scribe/






----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------