14:42:32 <RRSAgent> RRSAgent has joined #epub
14:42:32 <RRSAgent> logging to https://www.w3.org/2020/11/06-epub-irc
14:42:35 <Zakim> RRSAgent, make logs Public
14:42:36 <Zakim> please title this meeting ("meeting: ..."), ivan
14:42:44 <ivan> ivan has changed the topic to: Meeting Agenda 2020-11-06: https://www.w3.org/mid/531BE57F-F01F-4CFC-A84A-1B50C6AC8604@rakuten.com
14:42:45 <ivan> Chair: wendy
14:42:45 <ivan> Date: 2020-11-06
14:42:45 <ivan> Agenda: https://www.w3.org/mid/531BE57F-F01F-4CFC-A84A-1B50C6AC8604@rakuten.com
14:42:45 <ivan> Meeting: EPUB 3 Working Group Telco
14:57:17 <LauraB__> LauraB__ has joined #epub
14:57:20 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:57:41 <MattChan> MattChan has joined #epub
14:59:11 <BenSchroeter> BenSchroeter has joined #epub
14:59:42 <ivan> present+
15:00:06 <MasakazuKitahara> present+
15:00:12 <toshiakikoike> toshiakikoike has joined #epub
15:00:14 <BenSchroeter> present+
15:00:22 <LauraB__> present+
15:00:25 <wendyreid> wendyreid has joined #epub
15:01:04 <MattChan> present+
15:01:04 <duga> duga has joined #epub
15:01:07 <ivan> present+ MasakazuKitahara
15:01:11 <wendyreid> present+
15:01:14 <toshiakikoike> present+
15:01:28 <mgarrish> mgarrish has joined #epub
15:01:33 <Avneesh> Avneesh has joined #epub
15:01:52 <ivan> present+ avneesh
15:01:53 <zhengxu> present+
15:01:58 <ivan> present+ george
15:02:02 <ivan> present+ laurent
15:02:02 <George> George has joined #epub
15:02:03 <duga> present+
15:02:08 <ivan> present+ charles
15:02:15 <ivan> present+ garth
15:02:16 <mgarrish> present+
15:02:18 <laurent_> present+ laurent
15:02:24 <George> present+
15:02:35 <ivan> present+ juliette
15:02:44 <gpellegrino> present+
15:02:47 <dauwhe> scribe+
15:03:03 <dauwhe> wendyreid: let's get started
15:03:18 <dauwhe> Topic: F2F review
15:03:27 <CharlesL> CharlesL has joined #epub
15:03:39 <dauwhe> wendyreid: I thought the meetings were productive, and we covered all of our topics
15:03:43 <Juliette> Juliette has joined #EPUB
15:03:44 <CharlesL> present+
15:03:46 <CharlesL> agenda?
15:03:49 <dauwhe> ... and we came to conclusions on our XML issue
15:03:52 <Garth> Garth has joined #epub
15:03:53 <Juliette> present+
15:03:59 <dauwhe> ... we had volunteers for testing
15:04:09 <dauwhe> ... and we'll have a meeting next week about FXLA11Y
15:04:14 <Garth> present+ Garth
15:04:18 <dauwhe> present+
15:04:25 <dauwhe> ... we've got a lot of work to do
15:04:44 <dauwhe> ... mgarrish has been REALLY busy revising the documents
15:04:49 <dauwhe> ... there are lots of PRs
15:04:54 <dauwhe> ... lots of cleaning up of errors
15:05:16 <dauwhe> mgarrish: we've done some more shuffling, now that we don't have five separate docs
15:05:26 <dauwhe> ... we can find a more natural place for stuff
15:05:31 <ivan> present+ billk
15:05:33 <dauwhe> ... we merged a big one on the vocabs
15:05:41 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
15:05:47 <Bill_Kasdorf> present+
15:06:00 <dauwhe> ... there's stuff that was used in packages, content docs, and MO
15:06:09 <dauwhe> ... so Ivan suggested a general overview
15:06:16 <dauwhe> ... so now we reference an appendix
15:06:31 <dauwhe> ... and epub:type is an appendix
15:06:39 <dauwhe> ... it simplifies the cross-linking in the docs
15:06:54 <dauwhe> ... and there was the FXL section which got sliced up in 3.0.1
15:07:14 <dauwhe> ... the structural semantics vocab was an outlier
15:07:31 <ivan> q+
15:08:04 <dauwhe> ... now we don't have plans for extensive revisions for SSV, so it makes sense to put it in the core
15:08:18 <dauwhe> ... and there have been lots of editorial cleanup
15:08:20 <wendyreid> ack ivan
15:08:25 <dauwhe> ivan: two more things
15:08:40 <dauwhe> ... nav doc is now a top-level section; it used to be hidden in content docs; it's more readable
15:08:53 <Hadrien> Hadrien has joined #epub
15:09:00 <dauwhe> ... and we had three or four different conformance sections, and now they have been unified
15:09:05 <Hadrien> present+
15:09:30 <George> kq+
15:09:50 <dauwhe> George: the a11y spec is inside or outside of the core
15:09:52 <dauwhe> mgarrish: outside
15:10:02 <Garth> q+
15:10:16 <wendyreid> ack Garth
15:10:16 <dauwhe> wendyreid: there are still some satellite specs
15:10:47 <Avneesh> q+
15:11:07 <wendyreid> ack Avneesh
15:11:33 <dauwhe> Avneesh: I was not aware of an FXL call ; I thought it was for EPUB a11y revision
15:11:37 <dauwhe> wendyreid: oops
15:12:36 <dauwhe> wendyreid: any other questions about the reorg/editorial revisions?
15:12:46 <dauwhe> ... most of them are merged so you can see them in the draft
15:12:58 <dauwhe> ... you can also look at the previews and diffs in open or closed PRs
15:13:16 <dauwhe> ivan: mgarrish did an amazing job on this
15:13:18 <CharlesL> +1 Matt, way to go!
15:13:19 <Garth> +1
15:13:20 <dauwhe> ... it's much more readable
15:13:35 <dauwhe> mgarrish: it's fun to clean up the wreckage of history :)
15:13:54 <dauwhe> wendyreid: some of these PRs were purely editorial
15:14:06 <dauwhe> ... some of these PRs have addressed open issues
15:15:15 <dauwhe> Topic: DTDs
15:15:29 <dauwhe> ... we had resolutions at the F2F, and further discussions on github
15:15:34 <dauwhe> ... and came to a happy place
15:15:43 <mgarrish> https://github.com/w3c/epub-specs/pull/1368
15:16:04 <dauwhe> mgarrish: where we ended up was...
15:16:22 <dauwhe> ... we put in an allowance for a specific set of external identifiers that we have put in an appendix
15:16:36 <dauwhe> ... we have SVG and MathML that are allowed to be used in content docs or in separate files
15:16:55 <dauwhe> ... and we made a restriction against external entities in the internal DTD subset
15:17:11 <dauwhe> ... so it prevents some security issues but eases authoring
15:17:47 <dauwhe> ... so we'll no longer force people to remove SVG DTDs from tool-generated files
15:17:55 <dauwhe> ... I'm hoping this is it :)
15:18:11 <ivan> q+
15:18:14 <wendyreid> ack ivan
15:18:21 <dauwhe> ivan: tech comment
15:18:29 <dauwhe> ... in fact, the changes are such that
15:18:44 <dauwhe> ... makes possible something that I'm not sure we real;ly use
15:19:04 <dauwhe> ... I can define as part of an internal entity something that won't go out to the network
15:19:18 <dauwhe> ... I'm not sure if this feature is in use
15:19:42 <dauwhe> ... formal comment
15:20:09 <dauwhe> ... there was a formal resolution on the previous version; this PR slightly changes that
15:20:30 <dauwhe> ... can we get a formal resolution to merge, and also close a bunch of issues which were examples of the problem?
15:21:04 <Teenya> Teenya has joined #epub
15:21:24 <Teenya> present+
15:22:11 <wendyreid> Proposed: Merge PR #1368 to address outstanding DTD issues, and close GH issues 1369-1373
15:22:17 <Garth> +1
15:22:19 <mgarrish> +1
15:22:20 <ivan> +1
15:22:20 <CharlesL> +1
15:22:21 <MattChan> +1
15:22:22 <wendyreid> +1
15:22:24 <duga>  +1
15:22:26 <George> +1
15:22:28 <LauraB__> +1
15:22:29 <Bill_Kasdorf> +1
15:22:49 <BenSchroeter> +1
15:22:53 <wendyreid> Resolved: Merge PR #1368 to address outstanding DTD issues, and close GH issues 1369-1373
15:23:56 <wendyreid> https://www.w3.org/Consortium/Patent-Policy-20200915/
15:23:59 <dauwhe> Topic: New Patent Policy
15:24:19 <dauwhe> wendyreid: our WG was chartered right before the new patent policy
15:24:37 <dauwhe> ... W3M has asked if WGs are interested in upgrading to the new patent policy
15:24:37 <ivan> q+
15:24:41 <Avneesh> q+
15:24:49 <dauwhe> ... I can't describe the new policy
15:24:59 <dauwhe> ... should we move to the new policy?
15:25:33 <dauwhe> ivan: &ianal;
15:26:05 <dauwhe> ... the essence of the policy may not be absolutely clear
15:26:27 <wendyreid> ack ivan
15:26:41 <dauwhe> ... the main goal of the patent policy is that, if you implement a spec, then you should not have to worry about other WG participants having a patent and coming after you to pay a royalty.
15:26:55 <dauwhe> ... the patent policy aims to prevent this
15:27:09 <dauwhe> ... if an organization joins a WG, by default it signs a statement
15:27:26 <dauwhe> ... even if I have a relevant patent somewhere, I will not go after anyone implementing the spec
15:28:07 <dauwhe> ... the 2017 patent policy comes into effect when you publish a REC
15:28:30 <dauwhe> ... but in many WGs, specs are implemented before reaching REC
15:29:04 <dauwhe> ... and during CR phase there's no patent protection
15:29:15 <dauwhe> ... so that's the legal loophole in the 2017 policy
15:29:58 <dauwhe> ... so the 2020 policy, CR starts the process for patent claims, rather than REC
15:30:16 <dauwhe> ... so the question is, is this work IPR-heavy?
15:30:35 <dauwhe> ... is there a danger of infringement? If so, we should move to 2020 policy
15:30:45 <dauwhe> ... but if we think the risk is low, then we can forget about it
15:31:47 <dauwhe> ... if we move to 2020 policy, people would have to rejoin the WG
15:32:05 <dauwhe> ... we can't decide today, because people might need to talk to their lawyers
15:32:12 <wendyreid> ack Avneesh
15:32:29 <dauwhe> Avneesh: I want to check about using evergreen feature of process 2020
15:32:55 <dauwhe> ... the IP used to trigger at REC, now it starts at FPWD, so specs can remain evergreen at CR
15:33:13 <ivan> q+
15:33:20 <dauwhe> ... might some sections not getting implementations, and keeping them in CR?
15:33:29 <wendyreid> acl ivan
15:33:33 <wendyreid> ack ivan
15:33:34 <dauwhe> ivan: we have to separate process from 2020 from IPR 2020
15:33:40 <dauwhe> ... process 2020 we are already in
15:34:04 <dauwhe> ... the only thing it gives us is the possiblity it describes of infinite CR cycles
15:34:14 <dauwhe> ... I would prefer a traditional REC
15:34:33 <dauwhe> ... but once we have a REC, we can add/change much more easily than under older process docs
15:34:42 <dauwhe> ... but we can do that with either patent policy
15:34:48 <dauwhe> Avneesh: they are independent
15:35:00 <dauwhe> wendyreid: I'll send an email to the list, with a link to the patent policy
15:35:10 <dauwhe> ... and we can decide next week
15:35:54 <ivan> There is a [PP 2020 Explainer](https://www.w3.org/wiki/Process2020)
15:36:33 <ivan> There is a [slide deck of the DID WG](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47)
15:36:44 <dauwhe> ivan: we had a discussion in the DiD WG
15:36:51 <dauwhe> ... and made slides about the differences
15:37:03 <dauwhe> q+
15:37:07 <wendyreid> ack dauwhe
15:37:27 <wendyreid> dauwhe: I just want to mention that this WG is involved with a spec whose outlines were defined 20 years ago
15:37:38 <wendyreid> ... our exposure to new IPR is minimal at best
15:37:47 <wendyreid> ... it's not come up before
15:38:12 <wendyreid> ... does any possible change in IPR affect [the situation]
15:39:23 <dauwhe> George: I like the new policy better than the old policy, as things are settled well before rec
15:40:04 <ivan> present+ hadrien
15:40:20 <dauwhe> wendyreid: I'll send an email with links and let people discuss with their organizations
15:40:30 <dauwhe> ... I think it's a net positive
15:40:48 <dauwhe> wendyreid: AOB?
15:41:07 <dauwhe> George: were there media types on the agenda?
15:41:19 <dauwhe> ivan: there's still WebP
15:41:29 <dauwhe> wendyreid: I thought we were waiting for an answer from someone
15:41:56 <dauwhe> ivan: perhaps in a non-normative fashion
15:42:04 <dauwhe> ... it's not registered anywhere
15:42:07 <dauwhe> q+
15:42:16 <wendyreid> https://github.com/w3c/epub-specs/pull/1347
15:42:20 <wendyreid> ack dauwhe
15:42:36 <wendyreid> dauwhe: When we were talking about WebP, it's an internal doc at Google
15:42:50 <wendyreid> ... the person who wrote the spec didn't want to register the media type
15:43:01 <wendyreid> ... various W3C people have offered to help register the type
15:43:08 <George_> George_ has joined #epub
15:43:11 <wendyreid> ... some concern that google could change the spec
15:43:44 <dauwhe> wendyreid: Chris Lilley had offered to help with media type registration
15:43:58 <dauwhe> ivan: what we could do is... we can do two things
15:44:08 <dauwhe> ... one, keep the PR open and comes back in a year
15:44:25 <dauwhe> ... two, we put it in with a big yellow warning saying this is a feature that may be taken out
15:44:32 <dauwhe> ... because status is unclear
15:44:41 <dauwhe> ... I don't know which of the two is better
15:44:44 <dauwhe> q+
15:44:47 <Garth> q+
15:44:52 <wendyreid> ack dauwhe
15:45:11 <wendyreid> dauwhe: I would be curious to see if WebP works in existing reading systems
15:45:17 <wendyreid> Hadrien: It works in readium
15:45:34 <wendyreid> ivan: Readium relies on Chromium or whatever is aroudn
15:45:38 <dauwhe> ivan: does it rely on google engine
15:45:49 <dauwhe> Hadrien: it works everywhere if iOS 14+
15:45:54 <wendyreid> Hadrien: Whatever is around, if you're on iOS 14 it works there, on android it has worked for a few years
15:46:02 <dauwhe> ... has worked on Android for a while
15:46:07 <dauwhe> ivan: what about thorium?
15:46:07 <wendyreid> ... Thorium uses chromium, so it works, even on a mac
15:46:09 <dauwhe> Hadrien: yes
15:46:13 <dauwhe> ivan: even on a mac?
15:46:14 <dauwhe> Hadrien: yes
15:46:33 <dauwhe> ... I would expect it would work in a lot of places, because it's supported by many webviews
15:46:44 <dauwhe> ... probably won't work on RMSDK
15:46:49 <mgarrish> q+
15:46:55 <wendyreid> ack Garth
15:47:04 <dauwhe> Garth: I agree with Dave and Hadrien
15:47:14 <dauwhe> ... I think we should put it in with a warning
15:47:19 <dauwhe> ... that might drive more learning
15:47:51 <wendyreid> ack mgarrish
15:48:08 <dauwhe> mgarrish: a third option is reconsider mandating support in the spec
15:48:24 <dauwhe> ... there are custom implementations, we need a baseline... I don't know if that
15:48:38 <dauwhe> ... 's somehting the spec needs to say
15:48:53 <dauwhe> ... and not getting into the whole restricting things that are outside of our control
15:49:02 <dauwhe> ... that's a separate discussion
15:49:05 <dauwhe> ivan: not separate
15:49:23 <dauwhe> wendyreid: I support putting in WebP with a warning
15:49:25 <dauwhe> q?
15:49:30 <ivan> q+
15:49:33 <wendyreid> ack ivan
15:49:40 <dauwhe> ivan: to follow up on what matt said
15:49:49 <dauwhe> ... we are already in an awkward situation
15:49:58 <dauwhe> ... there are some media types where we are explicit
15:50:03 <dauwhe> ... we don't have a list of video types
15:50:09 <dauwhe> q+
15:50:19 <wendyreid> ack dauwhe
15:50:41 <wendyreid> dauwhe: Difference between video and images, 99% of EPUBs have images, but very few EPUBS have video
15:51:10 <George> q+q+
15:51:27 <Hadrien> q+
15:51:28 <zhengxu> zhengxu has left #epub
15:51:41 <wendyreid> ack George
15:51:48 <ivan> ack q+
15:51:48 <wendyreid> ack q+
15:51:53 <dauwhe> George: I would love to see us start testing video in the titles
15:51:53 <Garth> ack "q+"
15:52:02 <gpellegrino> great bug q+ in queue! :)
15:52:09 <dauwhe> ... people are waiting for that quality of content being added to educational materials
15:52:40 <dauwhe> ... putting it in the spec would protect from Google IP
15:52:46 <duga> ack ack
15:52:50 <wendyreid> ack Hadrien
15:52:59 <dauwhe> Hadrien: ivan hinted at the larger question
15:53:08 <dauwhe> ... can we tackle that larger question?
15:53:14 <gpellegrino> q+
15:53:18 <dauwhe> ... I don't think it's sustainable
15:53:28 <dauwhe> ... it belongs in a best practices doc
15:53:35 <Garth> q+
15:53:45 <dauwhe> ... we are not consistent with how we deal with HTML/CSS vs images
15:53:48 <tzviya> tzviya has joined #epub
15:54:06 <wendyreid> ack gpellegrino
15:54:18 <ivan> q+
15:54:18 <dauwhe> gpellegrino: for the image format I'm concerned about e-readers
15:54:32 <dauwhe> ... there are a lot of old e-readers which would never support webp
15:54:36 <wendyreid> ack Garth
15:54:39 <dauwhe> ... and new content wouldn't work
15:54:51 <dauwhe> Garth: I would like to get to Hadrien's discussion
15:54:58 <dauwhe> ... we can have a vote now about WebP
15:55:03 <dauwhe> ... then return to the larger issue
15:55:17 <dauwhe> ... should we move image specificity to video specificity
15:55:21 <wendyreid> ack ivan
15:55:28 <dauwhe> ivan: garth almost said what I wanted to say
15:55:35 <dauwhe> ... let's decide on webp today
15:55:53 <dauwhe> ... and open an issue on github
15:57:12 <wendyreid> Proposed: Merge #1347 with an additional warning about support for WebP
15:57:20 <George> q+
15:57:32 <ivan> +1
15:57:35 <Garth> +1
15:57:37 <mgarrish> +1
15:57:39 <George> +
15:57:41 <Hadrien> +1
15:57:41 <Bill_Kasdorf> +1
15:57:42 <CharlesL> +1
15:57:43 <Juliette> +1
15:57:50 <gpellegrino> 0
15:57:50 <duga> 0
15:57:52 <wendyreid> +1
15:57:56 <MattChan> 0
15:57:57 <dauwhe> George: I think it's great if we put this in
15:57:57 <toshiakikoike> 0
15:57:59 <laurent_> +1
15:58:06 <dauwhe> ... if it moves to a best practice that's fine
15:58:13 <BenSchroeter> 0
15:58:17 <MasakazuKitahara> 0
15:58:18 <dauwhe> ... but we get the format into implentations and documented
15:58:23 <dauwhe> wendyreid: that's another discussion
15:58:40 <wendyreid> Resolved: Merge #1347 with an additional warning about support for WebP
15:59:20 <dauwhe> wendyreid: happy weekend all!
15:59:45 <ivan> zakim, end meeting
15:59:45 <Zakim> As of this point the attendees have been ivan, MasakazuKitahara, BenSchroeter, LauraB__, MattChan, wendyreid, toshiakikoike, avneesh, zhengxu, george, laurent, duga, charles,
15:59:48 <Zakim> ... garth, mgarrish, juliette, gpellegrino, CharlesL, dauwhe, billk, Bill_Kasdorf, Hadrien, Teenya
15:59:48 <Zakim> RRSAgent, please draft minutes
15:59:48 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/06-epub-minutes.html Zakim
15:59:51 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:59:55 <Zakim> Zakim has left #epub
16:01:11 <ivan> rrsagent, bye
16:01:11 <RRSAgent> I see no action items