EPUB 3 Working Group Telco — Minutes

Date: 2022-04-08

See also the Agenda and the IRC Log

Attendees

Present: Murata Makoto, Ivan Herman, Avneesh Singh, Masakazu Kitahara, Wendy Reid, Shinya Takami (高見真也), Dave Cramer, Charles LaPierre, Ben Schroeter, Matthew Chan, Aimee Ubbink, Bill Kasdorf, Gregorio Pellegrino, Zheng Xu (徐征), Dan Lazin, Matt Garrish, Jen Goulden, George Kerscher, GeorgeK, Toshiaki Koike

Regrets: Tzviya Siegman

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

1. Close Privacy & Security Issues.

Dave Cramer: the TAG has reappeared of making a couple comments, I am making a PR to mention that when using web APIs, which have the most dramatic privacy and security implications (geolocations, push notifications) then you should get user consent.

See github issue epub-specs#1959.

Dave Cramer: we have several issues where there was never much discussion in the issue (#1959 for example).
… I think the PR i mentioned earlier would serve to close this issue.
… agree/disagree?

Ivan Herman: we had a lot of discussion with PING, good discussions, after which we made extensive additions to answer the issues they raised.
… and we contacted them several times to get their acknowledgement. So at this point we consider these issues closed..
… they have the right to reopen issues if they like.
… Amy from TAG has closed the issue of epub review on the TAG repo, so that is an indication of how they feel.

Gregorio Pellegrino: so is this passed? it is okay?

See github issue epub-specs#1872.

Ivan Herman: yes, it is okay.

Dave Cramer: risk of exposure and finger printability.
… this was raised before we clarified the threat model, can we close this now?

See github issue epub-specs#1873.

Dave Cramer: obfuscation, which we’ve discussed extensively, followed by updates to the spec docs.

See github issue epub-specs#1875.

See github issue epub-specs#1876.

Dave Cramer: interactivity, which we’ve addressed as best we can given that it’s ambiguous.
… self-contained packages, this is a case where its appropriate to close because epub is clear that it is largely self-contained, subject to exceptions enumerated in the spec. Not dramatically impacting privacy.

See github issue epub-specs#1957.

Dave Cramer: we enumerated the threat model, which deals with #1957.

See github issue epub-specs#1958.

Dave Cramer: permission prompts, we’re dealing with this, strengthened text.

See github issue epub-specs#1959.

Proposed resolution: Close remaining privacy and security issues. (Wendy Reid)

Dave Cramer: broad user expectations issues, which is covered by the other changes we’ve made.

Ivan Herman: +1.

Matthew Chan: +1.

Shinya Takami (高見真也): +1.

Bill Kasdorf: +1.

Dave Cramer: +7.

Wendy Reid: +1.

Matt Garrish: +1.

Murata Makoto: +1.

Dan Lazin: +1.

Charles LaPierre: +1.

Ben Schroeter: +1.

Masakazu Kitahara: +1.

Resolution #1: Close remaining privacy and security issues.

Ivan Herman: clap, clap.

Dave Cramer: I think the spec is now much more informative/clear about some of these issues, so thanks everyone.

GeorgeK: +1.

2. Missing CSS values (issue epub-specs#2153)

See github issue epub-specs#2153.

Dave Cramer: this refers to our appendix documenting epub’s prefixed CSS properties.
… original intent was to document what epub had and how that related to the current state of CSS, but we did not exhaustively document all modern CSS properties with epub equivalents.
… there was a suggestion in the issue, and I have no objection to that.
… mgarrish had sample text in issue.
… “The prefix definitions are no longer being synchronized with their CSS counterparts. In some cases, the unprefixed versions of these properties now support additional values. Reading Systems may not support the new syntaxes with the prefixed properties, so EPUB Creators are advised to use the unprefixed versions for newer features.”.
… seems like good advice.

Matt Garrish: avoids wg having to maintain this section going forward.

Dave Cramer: we’d have to reference various different CSS modules in the appendix to our spec, not the goal.

Ivan Herman: does this modify the existing CSS tests that wendyreid made? Does it require new tests?

Dave Cramer: I don’t think so.

Murata Makoto: Agreed.

Matt Garrish: we’re testing what was already there, but we’re not testing what has been added to CSS since the prefixes.

Ivan Herman: okay, good with me.

Dave Cramer: i don’t think we should test using a new value in a epub prefixed property.

Matt Garrish: I’ll create PR that just implements that text from the issue.

Proposed resolution: Adopt the recommended text in issue 2153, close issue. (Wendy Reid)

Murata Makoto: +1.

Matt Garrish: +1.

Ivan Herman: +1.

Wendy Reid: +1.

Matthew Chan: +1.

GeorgeK: +1.

Dave Cramer: +1.

Bill Kasdorf: +1.

Shinya Takami (高見真也): +1.

Masakazu Kitahara: +1.

Ben Schroeter: +1.

Resolution #2: Adopt the recommended text in issue 2153, close issue.

3. Section D.3.2 Review (issue epub-specs#2200)

See github issue epub-specs#2200.

See github pull request epub-specs#2233.

Matt Garrish: this was basically a mini-registry that IDPF was making, we said you can use certain limited token values unless you provide a URL.
… there was a request to add to this mini-registry, but my preference is rather to drop restrictions on registry values.
… add note that we are no longer maintaining this.

Ivan Herman: in addition, mgarrish and I went through a number of older IDPF documents.
… Bill_Kasdorf noted that that there are a number of IDPF documents linked to older versions of spec.
… so I updated these links.
… in doing this we found the mini-registry, which is what this issue is about.
… so the proposal is that we use the same IDPF registries that were there before.
… in the meantime, we’ve gone through the registry values and updated links.
… we’ve reached out to various wg members, from JP, DE, etc. to ask for clarification on which links would be proper to use.
… zheng_xu_ if you can please help interpret the link to the chinese website, to see if it is the correct one.
… I wonder if there are other IDPF documents that need updating in the same way, but I’m not sure what those would be.

Matt Garrish: main ones are the vocabs, the CMT, so I think we got most of them.

Murata Makoto: do we need to finalize those changes to the IDPF registry today?

Ivan Herman: not right now at this meeting, but I’d like to have all of these changes behind us by next week.
… if you could look at the pointer that Koike-san provided by then, that would help.

Murata Makoto: are there EN versions of the data linked via these links?

Ivan Herman: I’m not sure, but these documents only need to be in their native languages.

Shinya Takami (高見真也): the first link from Koike-san’s comment is good for these needs.
… the second one is more an introduction from the committee in charge, so it may not be correct for this use.

Ivan Herman: okay, I will wait until next week before finalizing any changes to the IDPF registry.

Murata Makoto: I will make my comments in the issue.

Ivan Herman: okay, thank you.

Matt Garrish: noting that there is a PR to resolve this.

Proposed resolution: Do a final update of the IDPF registry, add note that it will no longer be updated, accept PR 2233, close issue 2200. (Wendy Reid)

Wendy Reid: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Ivan Herman: +1.

Charles LaPierre: +1.

GeorgeK: +1.

Murata Makoto: +1.

Dan Lazin: +1.

Dave Cramer: +hbg:1.

Bill Kasdorf: +1.

Ben Schroeter: +1.

Masakazu Kitahara: +1.

Resolution #3: Do a final update of the IDPF registry, add note that it will no longer be updated, accept PR 2233, close issue 2200.

4. Move to Candidate Recommendation.

Ivan Herman: what CR means in terms of the process for the outside world is that the wg declares that the technical work is done.
… there may still be changes on the document, but those should be editorial.
… patenting issues arise at this stage, but likely not for this wg.
… Director will look at the document now, and review our plans for testing.
… the goal is that eventually the testing results will prove that the document is consistent, etc..
… once CR is published, we can still make editorial changes on the document without any problems the same way we do now, including automatic publishing.
… if we realize that there does need to be a technical change, we can request for a new snapshot. We would request with Director for this if we need it..
… from public facing point of view, it is an important milestone.
… it is worth beating bushes around it, because this means that authors who are producing epubs should begin to look at 3.3 rather than 3.2.
… they should expect that eventually 3.3 will supplant 3.2.
… going into CR requires a formal vote, after which I will notify Director.

Charles LaPierre: looking at our github issues, there are still 3 outstanding PRs.

Ivan Herman: we have to agree when we go to CR exactly.
… which I think should be when we merge these existing PRs, close these issues, unless they are editorial only.

Charles LaPierre: good, thank you.

Matt Garrish: do we need to put something on the 3.2 documents?

Ivan Herman: we will do that only after 3.3 goes to rec.

Murata Makoto: after a CR is published, will we be prohibited from introducing technical changes? If we do, will the CR revert to working draft?

Ivan Herman: no, in the old process that was the case, but in the new process we decide.
… only for very serious technical issues would we revert to working draft.
… for smaller technical issues, we can just snapshot.

GeorgeK: once the CR is announced, do we recommend to publishers to start producing to 3.3?

Ivan Herman: informally I think so, noting that 3.3 would not be a rec yet.

Matt Garrish: that change at the publisher level will depend on updates to epubcheck too.

GeorgeK: those publishers making a move now may support implementation when we get to rec.

Ivan Herman: just having the publishers indicate that they intend to adopt 3.3 when it becomes rec is good enough.

GeorgeK: same goes for authoring tools.

Avneesh Singh: a procedural thing, we also need to allow offline voting for 5 days.
… suppose we start voting on date x, what will be the wait time after that? Just in terms of synchronizing with epubcheck.

Ivan Herman: if we vote today, I will not send the request to go to CR until next Friday.
… the decision of when to publish should also take into account upcoming dates: e.g. upcoming AC meeting, publication moratorium, Director’s ability to review.
… so we probably won’t publish before May 5th.
… proposing that we make the formal request to go to CR May 5th.
… but if it works better for epubcheck to do it a few days later, we can.

Avneesh Singh: that works for us.
… will there be an email vote to go to CR as well?

Ivan Herman: no, not an email vote, but there will be a waiting period of 5 business days if anyone wants to object.
… I will highlight this right in my email of the minutes.

Bill Kasdorf: we’ve got 3 specs, so what’s the relationship of this to a11y 1.1 and RS?

Ivan Herman: we will have all 3 go to CR at once.

Ben Schroeter: do we anticipate that content providers will want assurances that RSes will handle 3.3 before they start producing to it?
… we will probably be asked what has changed between 3.2 and 3.3, what should we direct them to?

Dave Cramer: the change log.

Ben Schroeter: is that consumable by the people who will be asking?

Dave Cramer: most of the changes will not be major.

Dave Cramer: See change log in the specification.

Ivan Herman: remember that we have a backwards compatibility clause in our charter.
… the change log is more for RS developers, but these are not for the publishers to worry about too much.
… for both developers and authors, all the text that we put in about security and privacy are very relevant, these are new.
… this set of sections should be reviewed closely by both devs and authors.
… and then, as dauwhe, all 3 documents have detailed change logs.
… dauwhe and wendyreid and monique will make a presentation at ebookcraft on 04/28.
… this will be available as a video.
… i hope I will get permission from the speakers to put link to that video to publications page of w3c.

Bill Kasdorf: just saying that publishers don’t need to worry isn’t going to make them not worry. The more we can do to provide reassurance (like the presentation), the better..

Ivan Herman: but remember “no good deed goes unpunished”. My wish is that once CR is out, we should have a really well written blog on epub 3.3 and CR.
… but I’m not ready to do that.
… but I agree that something like that is necessary, we’re taking volunteers.

Bill Kasdorf: I’d be happy to do that, but I’m thinking that the best thing would be to write up the presentation we discussed earlier, it should be in sync.

Dave Cramer: also keep in mind that we’ve gone through this before with 3.2.

GeorgeK: tzviya has requested a similar write-up, potentially for use with WAI announcements.

Ivan Herman: the fact that a11y 1.1 is central to the new set of spec docs is an important point to make.

Charles LaPierre: should the business group be involved in this? Should they write the blog article, or at least be harmonized with what we are planning?

Bill Kasdorf: I would feel more comfortable with our members writing it, and then just having business group socialize it.

Proposed resolution: Move EPUB 3.3 Core, EPUB 3.3 Reading Systems, and EPUB Accessibility 1.1 to CR, publication date May 5 (preliminary), pending all PRs are closed by April 15th. (Wendy Reid)

Dan Lazin: +1.

Dave Cramer: +1.

Zheng Xu (徐征): +1.

Ben Schroeter: +1.

Ivan Herman: +1.

GeorgeK: +1.

Charles LaPierre: +1.

Wendy Reid: +1.

Shinya Takami (高見真也): +1.

Murata Makoto: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Bill Kasdorf: +1.

Aimee Ubbink: +1.

Masakazu Kitahara: +1.

Avneesh Singh: +1.

Resolution #4: Move EPUB 3.3 Core, EPUB 3.3 Reading Systems, and EPUB Accessibility 1.1 to CR, publication date May 5 (preliminary), pending all PRs are closed by April 15th.

Wendy Reid: hooray!!.

Ivan Herman: so from now on, the boss is dlazin, as all emphasis is on testing.
… this is the prerequisite for going to Rec.
… please everyone, look at tests, write tests, and if you are part of RS dev, then we need you to help run the tests.

Dan Lazin: we’re in reasonably good shape on RS spec, not terrible shape in Core spec/vocab.
… ivan has a plan for those.
… there is a lot of work to be done, and I have limited capacity right now.
… first step is to finish writing the tests for RS spec, and catalog tests in epubcheck.

Dave Cramer: thanks everyone, congratulations!.

5. Resolutions