EPUB 3 Working Group Telco — Minutes

Date: 2021-11-11

See also the Agenda and the IRC Log

Attendees

Present: Toshiaki Koike, Dave Cramer, Masakazu Kitahara, Shinya Takami (高見真也), Matthew Chan, Matt Garrish, Brady Duga, Victoria Lee

Regrets:

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Dave Cramer: 4 items on the agenda today, revisiting old issues, but hopefully we can make some progress today.

1. Obfuscation (issue epub-specs#1873)

See github issue epub-specs#1873.

Dave Cramer: from PING horizontal review, there were questions about obfuscation.
… fair amount of discussion. Obfuscation is widely used, so that means we can’t get rid of it without invalidating existing epubs regardless of the merits.
… right now obfuscation can be applied to any number of resources in the epub. I’m in favor of restricting this to fonts - i.e. the original use case.
… not aware of real uses of obfuscation for anything other than fonts, so risk of limiting uses of obfuscation is low.
… we could also recommend alternatives to obfuscation, such as use of WOFF and subsetting.

Brady Duga: WOFF also can’t be copied for use on your system.
… so I support this.

Shinya Takami (高見真也): in JP in many cases we don’t have encryption in RS. So this won’t have a big impact on JP market. It won’t be a problem..

Matt Garrish: re. limiting to fonts, how would we do this? List a set of font formats?.
… we’ll need to update epubcheck as well.
… i don’t think we’d be limiting it to the font mime type right?.

Dave Cramer: i was thinking we would limit to font core media type.

Matt Garrish: that covers the widely used ones, but not sure if there’s anything else out there.
… don’t want to have to keep updating epubcheck.

Brady Duga: I wish we could just restrict the list of fonts to the core list.

Dave Cramer: right, what about postscript type1 fonts.
… would it be reasonable to say you can only obfuscate fonts in the core media types, that this will be testable in epubcheck, and then let the people who are working around this in obscure ways speak up?.

Brady Duga: can we just non-normatively note what the intention is?.
… i.e. don’t obfuscate things that aren’t fonts, and try to use WOFF instead.

Proposed resolution: allow obsfucation only for fonts. Formally restrict to the font core media types. Add note suggesting using WOFF instead of obsfucation, and to say the intent is to cover all types of fonts.. (Dave Cramer)

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

Dave Cramer: +1.

Matthew Chan: +1.

Victoria Lee: +1.

Toshiaki Koike: +1.

Masakazu Kitahara: +1.

Brady Duga: +1.

Resolution #1: allow obsfucation only for fonts. Formally restrict to the font core media types. Add note suggesting using WOFF instead of obsfucation, and to say the intent is to cover all types of fonts..

Matt Garrish: i wonder if there’s some way of tying this to how fonts are declared.
… e.g. font family, link, etc..
… rather than trying to list the types of fonts specifically.

Dave Cramer: okay, that might be cleaner way of getting to the result we want.

Brady Duga: it feels like that would be hard to do, e.g. chemML which has its own way of referencing fonts.
… but the reality is that the industry is still going to use obfuscation. Drafting language around this is going to be tricky. Easiest way would be to just have a non-normative note and see if that is satisfactory to PING..

Dave Cramer: the proposed solution would satisfy the vast majority of cases though, most people would be happy with it….
… so do we go back to ndoty now to propose a non-normative, note based solution?.

Brady Duga: the problem is that the media type for fonts isn’t well defined, there could be epubs out there using weird fonts.

Matt Garrish: i think epubcheck already has some sort of internal list of font types, but we’d need them to confirm.

Brady Duga: changes like this push vendors towards moving away from using epubcheck as part of their ingestion pipeline.

2. Privacy and DRM (issue epub-specs#1874)

See github issue epub-specs#1874.

Dave Cramer: next PING issue, there was some discussion earlier about ripping some of the DRM hooks out of the spec.
… general consensus was no, there are valid use cases, such as obfuscation.
… can’t get right of encryption.xml, signing things could be useful.
… leaning towards recommending that we not change the DRM things that are already in the spec.
… does that seem reasonable?.

Matt Garrish: I found some old language about “future versions of spec might require specific format for DRM”, so I’ll probably just cut that.

Dave Cramer: yes.
… where did you see that?.

Matt Garrish: that was in core spec.

Proposed resolution: Close 1874; remove line from spec about “This version of the specification does not require a specific format for DRM information, but a future version might. “. (Dave Cramer)

Matt Garrish: might want to just cut that whole paragraph, the rest of it is pretty non-specific.

Proposed resolution: Cclose 1874; remove para from spec that contains “This version of the specification does not require a specific format for DRM information, but a future version might. “. (Dave Cramer)

Dave Cramer: +1.

Matthew Chan: +1.

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

Masakazu Kitahara: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Brady Duga: +1.

Victoria Lee: +1.

Resolution #2: Close 1874; remove para from spec that contains “This version of the specification does not require a specific format for DRM information, but a future version might. “.

3. Proposal for base URLs to be used for URL parsing (pr epub-specs#1898)

See github pull request epub-specs#1898.

Brady Duga: do we want to wait until we have Romain?.
… looking at comments on PR, it seems like most people are okay with the idea, but the specific details need to be hashed out.

Dave Cramer: i’m fine with not addressing this tonight, we can probably let the conversation continue over in github.

4. Approve PRs.

See github pull request epub-specs#1889.

Dave Cramer: this is writing language for when should happen when same item is referenced multiple times in the spine.
… there are a bunch of approvals from reviewers over in github.

Matt Garrish: okay with me.

Proposed resolution: merge 1889. (Dave Cramer)

Dave Cramer: +1.

Matt Garrish: +1.

Brady Duga: +1.

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

Victoria Lee: +1.

Matthew Chan: +1.

Toshiaki Koike: +1.

Masakazu Kitahara: +1.

Resolution #3: merge 1889.

5. AOB?.

Dave Cramer: that’s it for the agenda items.
… we’ve been making progress in some other areas. We’re getting formal approval on APA horizontal review.

Matt Garrish: procedurally its been a bit complicated.

Dave Cramer: in the cases of PING and TAG they have review repositories.
… TAG triaged their review for us today, assigned people to do the reviewing.
… PING issues are ongoing, we’re close on i18n.
… thanks everyone for being here, we’ll see you over on github or on next week’s call.

6. Resolutions