EPUB 3 Working Group Telco — Minutes

Date: 2021-05-21

See also the Agenda and the IRC Log

Attendees

Present: Masakazu Kitahara, Toshiaki Koike, Ivan Herman, Dave Cramer, Avneesh Singh, Gregorio Pellegrino, Ken Jones, Tzviya Siegman, Bill Kasdorf, Charles LaPierre, Brady Duga, Ben Schroeter, Dan Lazin, Hadrien Gardeur

Regrets: Matthew Chan, Wendy Reid

Guests:

Chair: Dave Cramer

Scribe(s): Brady Duga, Tzviya Siegman

Content:

1. Validation of SVG

See github issue #1323.

Dave Cramer: Validation of svg
… Perhaps coming to consensus
… maybe keep status quo
… don’t require validity now, just well formed, etc
… duga mentions there is real harm to the validity check
… propose informative messages when validition.nu check fails
… no spec change, acknowledge reality of tools

Ivan Herman: Fundamentally agree
… Which category corresponds to the epub check behavior?

Dave Cramer: Weird case since epubcheck is currently out of sync
… with the spec.

Matt Garrish: epubcheck follows the spec, but not entirely bound to it
… epubcheck can do what it wants, only errors and warnings need to match spec
… . Doesn’t need a statement in the spec to justify it

Proposed resolution: our spec does not require SVG to be valid only well formed (Ivan Herman)

Brady Duga: +1

Ben Schroeter: +1

Gregorio Pellegrino: +1

Matt Garrish: +1

Dave Cramer: +1

Ivan Herman: +1

Dan Lazin: +1

Tzviya Siegman: +1

Bill Kasdorf: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Resolution #1: our spec does not require SVG to be valid only well formed

Dave Cramer: https://github.com/w3c/epub-specs/issues/1456

2. xml:base in package document and elsewhere

See github issue #1456.

Dave Cramer: XML base
… Have a pull request to remove a line

See github pull request #1678.

Dave Cramer: xml base is disappearing from the world at large
… It isn’t forbidden, but not a useful requirement to support it
… Authors shouldn’t do it, and we should make it so RSes shouldn’t support it in the future

Proposed resolution: dump xml:base from the spec (Ivan Herman)

Brady Duga: +1

Dave Cramer: +1

Gregorio Pellegrino: +1

Toshiaki Koike: +1

Bill Kasdorf: +1

Masakazu Kitahara: +1

Ben Schroeter: 0

Dan Lazin: +1

Matt Garrish: +1

Resolution #2: dump xml:base from the spec

3. Is our scripting requirement normative?

See github pull request #1671.

See github issue #1659.

Dave Cramer: Security and Privacy - trying to bring more rigor

Ivan Herman: Unique origin (per epub) is something we have already decided
… Implementing that resolution I hit two things
… one editorial, one serious
… There was a statement which said roughly “you should have a unique origin, but if you can’t then do some hacks” (non-normative)

Dave Cramer: https://w3c.github.io/epub-specs/epub33/rs/#sec-scripted-content-security

“domain isolation is the most effective way to secure EPUB Publications in Web-based Reading Systems, it is not always a realistic option. Web-based Reading Systems must still maintain isolation in such cases, which may require limiting access to scripting APIs that allow client-side data storage and access.”

Ivan Herman: Didn’t know what to do with that statement
… I kept it to security and privacy, but there was a long thread of discussion on the request about what to do with it
… General hand waving over what to do if you can’t handle origins
… There are several options about how to write it
… but is tending towards the recommendation to dump it entirely
… since it is now required to support origin

Brady Duga: to add context, we did not have requirement around origin in the past
… when we added that requirement, we needed to take out the lines that said it wasn’t required. We have to revisit whether this isn’t required if we take this out

Dave Cramer: My instinct is to keep the normative requirement and get rid of the hand-waving
… acknowledging that the architecture of some RSes might have issues with this
… Don’t see the need for the spec to recognize that
… I would hope there are some tests that check the spirit of this
… Really don’t want cross-script data sharing
… The web way to do that is to use distinct origins
… If a RS can pass those tests then I am happy with it, regardless of how it is actually implemented

Proposed resolution: get rid of the hand-waving in PR 1671 on the origin issue (Ivan Herman)

Brady Duga: +1

Ivan Herman: +1

Tzviya Siegman: +1

Dave Cramer: +1

Toshiaki Koike: +1

Matt Garrish: 0

Gregorio Pellegrino: +1

Ben Schroeter: +1

Masakazu Kitahara: +1

Resolution #3: get rid of the hand-waving in PR 1671 on the origin issue

Ivan Herman: Then there was also a more editorial question
… the entire section has been enriched with more comments
… but those items, while interesting, are not related to security and privacy
… comments are around keeping data, which may be correct but is not S&P related
… Is there a place to move this to? eg general best practices for scripting
… if yes, then we should keep and enhance, otherwise we need to drop them

Dave Cramer: I don’t think we should do something like that (best practices)
… These seem out of scope for the spec
… Presumably people will figure it out

Brady Duga: All of these comments are around preserving data, but the spec does not require that
… you don’t have to use web storage, etc
… It would be tricky to write tips and tricks for specs that are not required

Tzviya Siegman: This is very niche - tips for supporting optional specs on top of optional features.

Dave Cramer: Don’t feel qualified to recommend implementation details to devs
… Seem to be drifting away from core responsibilities of the spec, would prefer fewer words here

Ivan Herman: Essentially in agreement
… Don’t need a formal resolution (this isn’t a normative statement), but will go ahead and remove those items

Hadrien Gardeur: Question about previous item: have we discussed what APIs can be used?
… Is there a policy or rough idea about our position?

Brady Duga: historically, we’ve viewed scripting as experimental. We’ve left it up to authors, publishers, systems to decide what to support. It’s a strange place to allow third party to decide what to do with user data. It’s a scary place to be, and I don’t think we should put into spec.

Ivan Herman: An analogy - no one specifies which APIs must be implemented by a browser
… It is rare (never?) to require specific API implementations
… Just like a browser, it is up to RS authors to decide what they will implement

4. Machine readable meta information for manifest items?

See github issue #1675.

Dave Cramer: Proposal to put metadata in the package file, particularly about copyright on specific manifest items
… Use case is to allow scanning of documents to check copyright status
… this concerns me
… There are various mechanisms to do that now (eg RDF)

Brady Duga: I don’t understand the use case

Matt Garrish: This seems half baked
… Might want more detail before we consider it
… It does seem like this can be done now, and the recommendation doesn’t really cover it all

Tzviya Siegman: Seems like this might be about the EU copyright directive

Tzviya Siegman: https://scholarlykitchen.sspnet.org/2021/05/17/stm-article-sharing-framework/

Tzviya Siegman: Might be about the scholarly world where you can detect if something is shareable
… Linked info above is still be discussed internationally

Hadrien Gardeur: I think in general when we get these requests, we should point out the current extensibility
… If some group comes up with a useful extension, then we can consider it
… we shouldn’t tackle these things ourselves

Proposed resolution: Close issue 1675 without further steps (Ivan Herman)

Ben Schroeter: +1

Dave Cramer: We should close the issue, nothing to see here

Dave Cramer: +1

Bill Kasdorf: +1

Brady Duga: +1

Ivan Herman: +1

Tzviya Siegman: +1

Masakazu Kitahara: +1

Matt Garrish: +1

Resolution #4: Close issue 1675 without further steps

Dave Cramer: That was all our issues

5. aob

Dave Cramer: Remember there is a face to face coming up
… If you want to talk about something ask the chairs, Ivan, or add the f2f label to the topic

Ivan Herman: Potential agenda for f2f: https://github.com/w3c/epub-specs/issues?q=is%3Aissue+is%3Aopen+label%3A%22Agenda%2B+F2F%22

Matt Garrish: What about republishing? Do we have a formal thumbs up?

Gregorio Pellegrino: +1

Charles LaPierre: +1 updated docs!

Proposed resolution: republish all specs (Ivan Herman)

Dave Cramer: +1

Ben Schroeter: +1

Brady Duga: +1

Tzviya Siegman: +1

Ivan Herman: +1

Matt Garrish: +1

Bill Kasdorf: +1

Resolution #5: republish all specs

Tzviya Siegman: https://docs.google.com/spreadsheets/d/1Jx5VvkMTQ4EL0Xfb3pDMDUiccq79mmIPHetSRfbziFM/edit?usp=sharing

Tzviya Siegman: There has been talk about creating short videos to share with the larger publishing community
… instead of a massive webinar
… If you have ideas for videos let us know
… will start creating videos over the summer
… if your name is on this and you don’t want to do it, let us know
… If you do want to do one, just add your name to the linked sheet

Dave Cramer: AOB?
… Thanks all! You can all go home

6. Resolutions