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