<scribe> scribe: nigel
Nigel: [introductions - everyone knows each
other already]
... First item is the schedule and the agenda.
... But the zeroth thing is to thank Apple for hosting us here today and
tomorrow.
... Schedule
... Any constraints? I should leave around 1600 tomorrow.
David: I have a call 9-10 tomorrow but go ahead regardless
Nigel: We'll go until 1800 today and
reconvene around 0830 tomorrow.
... In terms of topics Andreas requested some TTML1 issues for first
thing today,
... and IMSC 1.1 issues first thing tomorrow.
... David asked for WebVTT to CR transition discussions.
David: Yes, the goal is a CR transition
resolution, or if not then a conditional one, or if not
... then a set of tasks to get there.
Nigel: Shall we do that tomorrow afternoon, say 1530?
David: That would be fine. I don't want to
discuss any technical issues because we don't
... have the right people on the call. Half an hour of discussion should
be plenty.
Nigel: I also want to discuss Charter -
David and I need to find time to do that today.
... (not necessarily with the rest of the group)
Andreas: There are 3 TTML2 issues I would
like to be around to discuss, could be after the
... break today. They are #442 and #439. The others do not need
discussion now.
Nigel: In terms of goals...
... TTML1 Third Edition - can we get to Discussed and Agreed on all the
issues?
Pierre: Definitely, all the ones marked for
the agenda. We should target end of the month
... for completing the editing work.
... TTML2:
... For TTML2 our goal is to resolve the WR comments. There are also a
bunch of other issues
... to resolve on TTML2 to get to CR there.
Andreas: In a recent meeting we mentioned
the deadline to publish TTML2 CR by end of
... January, and the goal of this meeting is to close off all the issues
to allow that to happen.
Nigel: IMSC 1.1 -
Pierre: 2 classes of issues - resolve
outstanding issues related to deprecations - that should
... be the goal for this meeting.
... There may be one or two IMSC 1.1 specific issues, I'm not sure, but
the primary blocker
... for IMSC 1.1 are those deprecation issues and the TTML2 dependency.
Nigel: What we're trying to get to is the
point where we can publish a new WD of IMSC 1.1
... with those resolutions.
Pierre: I'd like a small slot on the agenda
today to see if everyone's position is the same
... on IMSC 1.1 so we have a shot at talking them over in offline time
tonight before we come
... back to them tomorrow.
Nigel: Yes, we have incoming liaisons on
IMSC 1.1. [updates schedule]
... IMSC 1.0.1 - I'm not aware of any new information.
Pierre: We need 5 minutes to deal with the WR comment, maybe straight after lunch for 5 minutes
Cyril: We need to add TTML2 CR Exit Criteria
to the agenda
... and features at risk
Nigel: AOB or other points to cover in this meeting?
group: [no AOB]
Andreas: I'd like to cover #251 please
github: https://github.com/w3c/ttml1/issues/251
Andreas: Two distinctions we made in the
thread:
... 1. Attributes not defined in TTML1 - are they part of the TTML1
document model? Are they allowed in the syntax?
... 2. If the attributes are not yet defined in TTML1 but they appear,
how should a processor behave and treat them?
... Both issues need to be discussed differently.
Glenn: The ambiguity is between style
attributes defined in the TTS namespace and those
... listed in the TTML1 spec.
Cyril: We should take the looser
interpretation, allow things in the TTS namespace even if
... they are not defined.
Pierre: We should ask ourselves what problems that could cause for processors?
Nigel: That's the same as processors seeing a TTML1 tts attribute profiled out.
Andreas: If you just want to make sure that
expected vocabulary you expect then you
... need something stronger for say schema validation. If you make an
error in attribute
... name spelling and allow a lax interpretation then it will not be
spotted.
Pierre: What's the difference between making
a typo in a foreign namespace attribute and
... a TTML2 namespace attribute? And if a document has profiles that
apply then they can
... impose stricter rules that a validator can use. Those things to me
mitigate your point.
Andreas: For foreign namespace attributes
they are stripped out anyway and you do not
... care from a TTML1 processor perspective so that's different from
TTML1 core vocabulary
... secondly, EBU for example did not put stricter rules in on the basis
that the interpretation
... is that unexpected vocabulary is not allowed.
... Note Glenn's point in the thread that the schema provided a hint
about the intent.
Nigel: We need to get to a resolution here.
Pierre: The downside I have heard is that schema validation won't catch some errors.
Glenn: It significantly complicates schema
validation if we use the looser interpretation
... because it will require adding a wildcard that does not exist now.
Pierre: If you tell a validator to use a
TTML1 model then I would expect a non-TTML1
... piece of vocabulary to generate a warning, which would show up
typos.
Nigel: I'm wondering about saying anyone who
wants TTML2 defined syntax needs a
... TTML2 profile with stuff subtracted.
Pierre: I wonder if we could add to the
pruning list things not in the TTML1 defined vocabulary
... as well as non-TTML1 namespace content.
Glenn: That would avoid the need for a
schema change but the schema might end up
... overly restrictive.
Andreas: I wanted to ask Tess your opinion -
there's a similar problem in WebVTT and
... maybe also HTML5, which is not XHTML5 because of the XML error
handling.
... I wonder if there's a solution to separate document conformance from
processor conformance.
... In WebVTT as far as I can see there is a clear line what an author
is allowed to put in the
... document, but on the other hand the processor can support more. Is
that correct?
Tess: Yes that's correct.
Andreas: So I think it makes sense in terms
of general strategy to handle these cases
... like this.
Glenn: I would not agree to use the same error strategy as in HTML and WebVTT.
Pierre: The proposal on the table is to
prune non-TTML1 defined vocabulary before validating
... for the purpose of TTML1 document conformance. After that profiles
can do whatever
... they want.
Tess: That's doing half of what Andreas suggests anyway.
ack
Glenn: The section to change would be §4
bullet 3. It would be consistent with the way
... we prune foreign elements.
Andreas: I don't think so because foreign
namespace attributes are specifically permitted
... in the model. Now we are discussing more - I am flexible if everyone
agrees we should
... have this new approach, I can accept it but I still have concerns.
Pierre: I think that's what we're saying. In
addition to fixing bullet 3 of section 4, I think
... Andreas wants to state explicitly that, say, in §7.13 body, that it
is any attribute in the
... TT style namespace not just those listed in the TTML1 vocabulary?
Andreas: Yes, either this or do nothing. Then we don't want to do pruning for validation.
Glenn: There's a major disconnect here - all
of the foreign namespace elements and attributes
... are removed before considering element item definitions, therefore
it is irrelevant what
... the "any attribute not in default of any TT namespace" is irrelevant
for this purpose because
... it is post pruning. In fact it is misleading to have that in there
in the first place.
Nigel: If we do this we really need to have
an informative statement explaining what is
... permitted and what is not.
Pierre: I would add an example to section 4.
Andreas: We could add something to the end of 5.1 where we say [gap]
Glenn: We've already done the work in the ED
to prune out attributes not associated with
... the abstract document type.
Pierre: My proposed step is for Andreas to craft some text that I can put in a pull.
Andreas: From my interpretation the document
model is strict but I would accept something
... else. I definitely will add some text to the issue for example to
say in 5.1 that all undefined
... names in those mutable namespaces are part of the document model,
regardless of which
... specification defines it.
Pierre: I think we need an informative note
and example explaining the difference between
... pre- and post-pruning syntax permission and behaviour.
<glenn> See https://github.com/w3c/ttml1/issues/196 for issue where we updated section 4, item 3.
Andreas: Okay I will add to the issue.
SUMMARY: General agreement to allow documents vocabulary not defined in the spec but extra wording to be proposed by @tairt
github: https://github.com/w3c/ttml1/issues/239
Glenn: The comment https://github.com/w3c/ttml1/pull/297#discussion_r159473047
was wrongly attributed because of the applicability of overflow to
fo:inline-block
... There's no question about the accuracy of the text in the pull
request. Andreas's
... request for clarification is in fact not relevant.
... [adds a comment to the pull request]
Andreas: I will review soon - let's come back to this please.
github: https://github.com/w3c/ttml1/issues/304
Glenn: I'm not going to object to merging
the pull request already open for this.
... [adjusts pull request review]
RESOLUTION: Merge the pull request as is
Cyril: My argument is that anonymous span
creation is defined only in 9.3.3 after the ISD
... has been created. So it can't affect timing. I agree that in 10.4 it
mentions the implicit
... duration of the anonymous span.
... We could create anonymous spans before calculating the timing of the
ISDs.
Glenn: That's what I did.
Pierre: That's what I did in imscjs too.
Cyril: It's in TTML2 already - the
permission to create the anonymous spans before
... calculating the timing.
Pierre: Do you want to backport that note into TTML1?
Cyril: Yes.
... This is in https://w3c.github.io/ttml2/#semantics-region-layout-step-2
bullet 2.
Nigel: The note is fine but it creates an
ambiguity, in that processors that do it could
... generate different results from those that do not.
Cyril: That was my next point too!
... §9.3.3 1c removes the anonymous spans that only contain text
children.
... It's important that this happens after the timing has been
calculated.
... It would be preferable to put the anonymous span generation in a
separate text.
David: Formally state when an anonymous span is generated and what treatment they have.
Cyril: It should be in both TTML1 and TTML2
in that case.
... We could separate out 9.3.3 step 1 into a new subsection and refer
to it for timing.
Nigel: We'd have to keep bullet 1c in the style resolution bit.
Pierre: Another idea is to include in 10.4
the handling of spans whose only content is text
... children.
... In the timing section the algorithm for creating anonymous spans is
missing.
Cyril: Yes that's why I suggest reorganising
the spec. to take 9.3.3 1a and 1b and put them
... a new section.
... Then call it from 9.3.3 leaving step c present.
... We need the same PR on TTML2
Nigel: +1
Pierre: I'm happy to take a stab at proposing the pull request for this.
Glenn: Make sure you don't adjust the
wording in those two steps.
... I would prefer to put all three bullets in the new algorithm and
conditionalise step c.
Cyril: Step c changes to removing anonymous spans not adding them.
RESOLUTION: @palemieux to propose a refactoring of §9.3.3 bullets 1a and 1b into a new subsection
Pierre: It looks like TTML2 solves this, so I generated a pull based on that.
group: [goes through pull request #301
comments. Some need new issues filing against
... TTML2 where the same issue arises on both.
... others need some additional work by the Editor]
Pierre: alright I'll try to do those changes.
github: https://github.com/w3c/ttml1/issues/239
Andreas: Having reviewed this, I do not think a pull request is needed at all.
Nigel: Should we put the example at
https://github.com/w3c/ttml1/issues/239#issuecomment-350071676
into the spec
... so that other people don't have the same problem.
Glenn: Happy to close as works for me
Pierre: I'm also happy to do that.
RESOLUTION: Close this issue without change, and consider opening a new issue to add https://github.com/w3c/ttml1/issues/239#issuecomment-350071676 to the spec
github: end topic
github-bot, end topic
github: https://github.com/w3c/ttml1/issues/251
Glenn: I'd reduce the example to a fragment here.
Pierre: I'll take the action to add that.
github-bot, end topic
Andreas: sorry, I forgot to mention
something - possibly a new issue is needed. The text
... in the schemas may throw false negative messages at the moment.
Pierre: It depends if they apply after pruning or before.
Glenn: In TTT they're applied after pruning.
Pierre: The schemas are normative but it doesn't say when to apply them.
Glenn: I don't want to change the schema. We
could add a note about schemas saying we
... don't define when they are used and that nominally we assume that
the schemas are
... are applied afterwards.
Andreas: I'm happy to add a note to the schema.
Pierre: I'd add it to §4 so they're in the same place.
Glenn: No that's not where schemas are mentioned.
Nigel: The top section of Appendix B would be a good place.
Glenn: I'd add it into 4.1 (not 4)
Pierre: Fine with me.
Nigel: Works for me too.
Pierre: What should that note say exactly?
Glenn: I'll volunteer some prose there.
Nigel: EBU and HbbTV have both sent messages:
group: [informal discussion]
Nigel: Let's look at the IMSC 1.1 issues where there was an objection after TPAC.
Cyril: We need to understand the implications for TTML2 also.
Pierre: For the purpose of meeting our
timeline requirements we cannot be dependent on
... work being completed in CSS before putting it into TTML2.
<cyril> Netflix can agree on the following:
<cyril> Should itts:forcedDisplay be deprecated? -> no, not yet, possibly in the future
<cyril> Should ebutts:linePadding be deprecated? -> no
<cyril> Should ebutts:multiRowAlign be deprecated? -> no
<cyril> Should itts:fillLineGap be deprecated? -> no, and removed from TTML2 until CSS has worked on it
<cyril> Should ittp:activeArea be deprecated? -> no, and removed from TTML2
<cyril> Should ittm:altText be deprecated? -> yes, replaced with ttm:item name=altText with the notes
<cyril> ttp:displayAspectRatio is prohibited -> no, ttp:displayAspectRatio is used instead of ittp:aspectRatio with some changes in TTML2
<glenn> +1
<pal> +1 assuming that both the deprecated and non-deprecated cannot be simultaneously used
+1
github: https://github.com/w3c/imsc/issues/273
RESOLUTION: As per https://github.com/w3c/imsc/issues/273#issuecomment-346866486 with a small change to TTML2 and with document conformance constrained not to permit both deprecated and new simultaneously
github: https://github.com/w3c/imsc/issues/274
RESOLUTION: Deprecate ittm:altText in favour of TTML2 ttm:item name="altText" and do not permit documents to use both syntaxes simultaneously.
github: https://github.com/w3c/imsc/issues/275
RESOLUTION: Do not deprecate ittp:aspectRatio
RESOLUTION: Do not deprecate ittp:fillLineGap (and also remove it from TTML2 until a CSS compatible mechanism is available)
github: https://github.com/w3c/imsc/issues/276
github: https://github.com/w3c/imsc/issues/277
RESOLUTION: Do not deprecate ebutts:multiRowAlign (and also remove it from TTML2 until a CSS compatible mechanism is available)
github: https://github.com/w3c/imsc/issues/278
RESOLUTION: Do not deprecate ebutts:linePadding (and also remove it from TTML2 until a CSS compatible mechanism is available)
github: https://github.com/w3c/imsc/issues/279
RESOLUTION: Do not deprecate itts:forcedDisplay
github-bot, end topic
@@@@@@@@@@@@@@@@@@@@@@@@
Cyril: We need to tell authors to use type
parameters available in the mime type in preference
... to the format attribute. Then the question is if we should define
some tokens, like SDR
... or HDR.
Glenn: Yes we should.
Chris: I don't think we expect SDR or HDR to be in a MIME type.
Cyril: Can we use media queries in format?
Nigel: No they should be in the condition
attribute. I agree that SDR vs HDR does seem to
... be more of a media query issue though than format.
... Unless we have a concrete use case for removing format - if SDR and
HDR are media queries then we have no others.
Glenn: It's already interoperably implemented for font format.
Cyril: This is about <image-format>
David: I think we should remove image-format
too - it is underspecified to the point that
... it is not useful. Alternatively tighten it up.
Glenn: It would be asymmetrical to leave it on audio, font and data but remove it from image.
<dsinger> we should raise an issue that we should use MIME types for fonts as well https://www.iana.org/assignments/media-types/media-types.xhtml#font
Nigel: I have raised #542 for removing
`<image-format>`
... And #543 for removing `<font-format>`.
github-bot, end topic
Andreas: [need to drop off the call]
github: https://github.com/w3c/ttml2/issues/443
Nigel: We need to write a disposition
message to send back to the commenter.
... I'll draft something for review by the group.
SUMMARY: Nigel to draft a disposition message
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/460
SUMMARY: Nigel to include information about the change made here in any draft future message to SMPTE.
github-bot, end topic
Nigel: Could we rename "Embedded Content" to "Resource Content"?
Pierre: This is an editorial change just to make it clearer for other people.
Glenn: I don't like that.
Chris: "Extrinsic Content"? Since it is all non-TTML.
Glenn: It would be a lot of work to make
this change.
... [also didn't like Media Content]
Pierre: It's up to the group.
Nigel: Seems to me that we all agree it's
not a great name right now but do not care enough
... to make a change.
RESOLUTION: We will not make a change here because we have insufficient willingness to find and implement a different name.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/436
RESOLUTION: We will not make a change here because we have insufficient willingness to find and implement a different name.
github-bot, end topic
trackbot, this is ttml
<trackbot> Sorry, nigel, I don't understand 'trackbot, this is ttml'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
trackbot, start meeting
Date: 09 January 2018
github: https://github.com/w3c/ttml2/issues/400
Pierre: I've reviewed the comment and
believe it is a misunderstanding.
... The commenter believes that tts:luminanceGain="1" yields a linear
light output of 10000 nits
... when in fact it yields a peak output of 80 nits.
Nigel: I sent an email to the commenter
drawing his attention to your comments.
... Please could you draft a formal response?
Pierre: Yes absolutely.
... The commenter proposes an example but there is already one and I
don't believe
... another would be helpful. The current example is more helpful for
web applications.
RESOLUTION:
No change is necessary.
... Since we do not agree with the issue, mark as WR-Rejected.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/403
Glenn: I plan to do what this issue requests.
RESOLUTION: WG agrees to implement the issue as requested.
github-bot, end topic
Glenn: I plan to do this.
RESOLUTION: WG agrees to add this as requested, subject to Editor input
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/539
Cyril: Yesterday we reviewed with Pierre and
Glenn the discrepancies between
... ittp:aspectRatio and ttp:displayAspectRatio and there were two cases
where the text
... was not aligned, which is this issue.
Glenn: There's now a PR open on this.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/490
group: Discusses this and agrees it.
Glenn: I'll update the pull request.
RESOLUTION: Do https://github.com/w3c/ttml2/issues/490#issuecomment-356123618
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/364
Nigel: I'm confused - there's already a note
in G.2 and G.3 saying that the TTML2 profiles
... are supersets of DFXP.
Glenn: What's different is that it didn't require support for the DFXP profile designators.
Nigel: Ah, thank you, makes sense.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/435
Cyril: We discussed this yesterday. It's a
long standing issue. Glenn came up with a list of
... cases where ttp:profile is used, one is to determine the default
processor profile when
... there is no other information and the other is to select the
validation schema.
Glenn: [points to comment describing agreement from yesterday]
Nigel: Would you please add a column to the
table in E.2 specifying the "version introduced"
... to support the heuristic bullet about inferring the spec version
from the most recently defined required feature?
Glenn: Yes, that's a good idea.
Nigel: Regarding the bullet about defining
new feature designators to drive selection of alternate algorithm
behaviour,
... if the only case where that applies is root inheritance then I would
rather remove root
... inheritance.
Pierre: Yes
Cyril: That works for me.
Glenn: I could support that as I don't know
of anyone using that.
... I created #546 for root inheritance removal.
Nigel: What are the other alternate algorithms?
Glenn: position and origin handling especially if neither is present, because they have different initial values.
Pierre: Another is the semantics of offset
time and fractions component in smpte timebase.
... In those cases I don't know why they are tied to ttp:version. In
TTML1 we said "should not be used"
... If we don't want people to use them we should just deprecate them.
Glenn: We did and conditionalised how the deprecation was handled. But I agree.
RESOLUTION: Adopt https://github.com/w3c/ttml2/issues/435#issuecomment-356142844
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/429
Cyril: We've discussed this today and agreed to remove `tts:fillLineGap`
RESOLUTION: Following further discussion, group confirms that tts:fillLineGap is to be removed.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/428
RESOLUTION: Following further discussion, group confirms that ttp:activeArea is to be removed.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/330
Glenn: Everyone agrees with this, I just
want to get confirmation.
... This will probably cause more deprecation warnings than anything
other deprecation we are making.
Nigel: How do you deprecate the absence of something?
Pierre: Require issuing a warning if pixel units are used but no tts:extent is present on tt.
Nigel: Where in the spec?
Cyril: On the `<length>` unit definition.
Pierre: And on tts:extent.
... Or on tt?
... I'm happy either way.
Glenn: Probably on the tt element.
Nigel: Can we please also have a note on the `<length>` unit to warn about this behaviour?
Glenn: Sure that's reasonable.
RESOLUTION: Implement this as per the above discussion.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/315
Cyril: I'll create an issue for TTML1 for
the equivalent of this, in color.
... It's w3c/ttml1#322.
Nigel: When you say "allow lwsp everywhere", what exactly is "everywhere"? Is it all tta, ttp and tts attributes?
Glenn: Pretty much, yes. I'm not proposing to allow lwsp between value names and ( for example.
Chris: That matches what is in CSS too.
Glenn: I should change `<color>` to combine the `"rgb" "("` into `"rgb("` and `"rgba" "("` into `"rgba("`
Nigel: In `<number>`, `<non-negative-number>` and `<percentage>` there shouldn't be any lwsp allowed.
Chris: Implementers prefer no space between a number and %.
Nigel: So that applies between number and pitch-units in `<pitch>` too.
Chris: Yes
Cyril: It may be clearer and easier to put
`<lwsp>` explicitly everywhere it is allowed.
... We should do that.
Glenn: I may have to accept that.
Nigel: `<position>` already does it.
Glenn: `<condition>` does too.
... There are some animation value expressions too that need it.
RESOLUTION: Specify explicitly where lwsp is permitted.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/260
RESOLUTION: Remove rubyOverhang as per the pull request and seek confirmation from @r12a that it addresses his comment.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/238
Glenn: If we take out ipd and bpd by marking
them as at risk then we won't be able to
... meet the SMPTE digital cinema request for "struts".
Pierre: If they have people who want to implement then we will not need to remove it.
Nigel: Is there any other use of inline-block?
Cyril: Yes, that's the only other use.
Glenn: ipd and bpd are also needed for image sizing.
Pierre: We should add inline-block to the set of at risk features if we add ipd and bpd.
RESOLUTION: WG is disposed to remove applicability of tts:textAlign to span and mark bpd, ipd and inline-block as "at risk" in the CR.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/264
Cyril: We discussed this yesterday.
direction has three usages:
... 1. When there is direction and unicodeBidi it tells you which
embedder marker you should put.
... 2. When direction is at the p level it sets the paragraph embedding
level.
... 3. It's computed value is taken from writingMode.
... The proposal for addressing this comment is not to describe the
behaviour but to link
... from direction to unicodeBidi and the special semantics section. I
would consider that
... purely editorial.
... I will propose a pull request for this and include the explanatory
note that @r12a requested.
RESOLUTION: Add the links and explanations that @r12a requested.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/268
Cyril: I think we can mark this as commenter no response.
RESOLUTION: Group considers the window for a response to be closed and to close the issue.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/236
Nigel: On reviewing this, it appears that there is work to do.
Glenn: I missed that - I will tag it for my priority.
github-bot, end topic
Pierre: When we discussed this in the
context of the slightly different w3c/ttml1#251 the
... consensus was that unrecognised elements and attributes are pruned
prior to validation
... processing.
... I now think that the wording in w3c/imsc#216 is incorrect since it
states that foreign
... namespace elements are not permitted everywhere, but we discussed
this morning that
... they are actually pruned prior to validation processing, which means
they are permitted.
... We need to reopen w3c/imsc#213 and say that the conclusion is that
foreign namespace
... elements are in fact permitted.
Nigel: In IMSC we could impose the rules
stated even if they are more specific than what
... TTML says.
... I've reopened it.
Nigel: Thanks everyone for a long and productive day. Reconvene 0830 tomorrow PST. [adjourns meeting]
<scribe> Chair: Nigel, David
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/..// Succeeded: s/before/at all/ Succeeded: s/ttml1#273/imsc#273/ Present: Glenn Cyril Pierre David Nigel Tess Chris Eric Regrets: None Found Scribe: nigel Inferring ScribeNick: nigel Found Date: 09 Jan 2018 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]