14:03:39 <RRSAgent> RRSAgent has joined #epub
14:03:39 <RRSAgent> logging to https://www.w3.org/2021/11/19-epub-irc
14:03:43 <Zakim> RRSAgent, make logs Public
14:03:43 <Zakim> please title this meeting ("meeting: ..."), ivan
14:04:16 <ivan> ivan has changed the topic to: Meeting Agenda 2021-11-19: https://lists.w3.org/Archives/Public/public-epub-wg/2021Nov/0033.html
14:04:17 <ivan> Chair: wendy
14:04:17 <ivan> Date: 2021-11-19
14:04:17 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Nov/0033.html
14:04:17 <ivan> Meeting: EPUB 3 Working Group Telco
14:05:10 <Karen> Karen has joined #epub
14:39:06 <dauwhe> dauwhe has joined #epub
14:39:21 <romain> romain has joined #epub
14:53:22 <mgarrish> mgarrish has joined #epub
14:56:32 <romain> romain has joined #epub
14:57:50 <toshiakikoike> toshiakikoike has joined #epub
14:58:17 <ivan> present+
14:58:23 <ivan> present+ rickj
14:58:31 <ivan> present+ avneesh
14:58:42 <ivan> present+ george
14:58:47 <avneeshsingh> avneeshsingh has joined #epub
14:58:56 <MattChan> MattChan has joined #epub
14:58:58 <ivan> present+ toshiakikoike
14:59:17 <toshiakikoike> present+
14:59:18 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:59:26 <MasakazuKitahara> present+
14:59:30 <ivan> present+ dauwhe
14:59:49 <rickj> rickj has joined #epub
14:59:54 <ivan> present+ matthew
14:59:58 <rickj> present+
15:00:10 <romain> present+
15:00:18 <CharlesL1> CharlesL1 has joined #epub
15:00:28 <ivan> present+ ubbink
15:00:59 <CharlesL1> agenda?
15:01:01 <ivan> present+ vlopes
15:01:13 <ivan> present+ ben
15:01:15 <BenSchroeter> BenSchroeter has joined #epub
15:01:23 <MattChan> scribe+
15:01:26 <ivan> present+ Victoria
15:01:28 <BenSchroeter> present+
15:01:35 <ivan> present+ MasakazuKitahara
15:01:37 <gpellegrino> gpellegrino has joined #epub
15:01:51 <gpellegrino> present+
15:01:51 <George> George has joined #epub
15:01:59 <mgarrish> present+
15:02:14 <avneeshsingh> one of the best scribes has taken up!
15:02:49 <George> George has joined #epub
15:02:59 <ivan> present+ makoto
15:03:15 <MURATA> MURATA has joined #epub
15:03:21 <MURATA> +present
15:03:24 <MattChan> dauwhe: any new member introductions?
15:03:29 <avneeshsingh> present+
15:03:29 <George> George has joined #epub
15:03:34 <MattChan> rickj: rick johnson, vitalsource
15:03:40 <MURATA> Welcome back!
15:03:45 <ivan> +1
15:03:49 <MattChan> dauwhe: rickj has been major player in epub for a long time, glad to have him back
15:03:52 <dauwhe> https://github.com/w3c/epub-specs/pull/1898
15:03:56 <MattChan> TOPIC: Open PRs
15:04:33 <victoria> victoria has joined #epub
15:05:00 <MattChan> romain: basically the intent of the PR is to clarify how URLs are passed to epub
15:05:30 <MattChan> ... basic idea is to more clearly define root URL of the OCF container, and based on that precisely say that all URLs are to be passed relative to this root
15:05:54 <MattChan> ... one addition is that we do not define the root URL of the container, we say it is implementation specific
15:06:12 <MURATA> :-) I know that it's difficult.
15:06:16 <MattChan> ... we just say RS must implement it such that it has certain properties
15:06:16 <ivan> q+
15:06:26 <dauwhe> ack iv
15:06:38 <MattChan> dauwhe: we want certain behaviours to come out of this definition, but we don't want to control RS implementation
15:06:48 <George> George has joined #epub
15:07:02 <MattChan> ivan: implication of this PR is that the problem of relative URIs being able to leak out of the container is gone
15:07:11 <romain> q+
15:07:16 <dauwhe> ack rom
15:07:17 <MURATA> Good point
15:07:18 <MattChan> ... this PR defines a hard stop at the top of the container
15:07:34 <MattChan> romain: to be clear, this is enforced in the RS spec
15:07:56 <MattChan> ... RS must implement the root URL in such a way that whatever the root URL looks like, it is something inside the container
15:08:25 <MattChan> ... so far we say that any relative URL is valid
15:08:33 <MattChan> ... we may limit this in the next agenda item
15:08:48 <George> George has joined #epub
15:09:18 <MattChan> ... re. these properties we say must be defined on the root URL, it is not certain that all RS are currently done this way, so this PR may make some existing RS non-conforming
15:09:24 <MattChan> dauwhe: can we test for this?
15:10:03 <MattChan> romain: I have created a test epub that uses js to display the URL of a content document, and based on this we may be able to infer the RS's root URL for the container
15:10:35 <MattChan> ... based on this naive test (done on Readium, ibooks, and ADE), ibooks and Readium do not implement the root URL internally the way we have it defined in the PR
15:10:42 <MattChan> ... not yet applied this test to other RS
15:10:48 <George> George has joined #epub
15:10:57 <MattChan> ... to answer the question, no, it's not really testable
15:11:03 <ivan> q+
15:11:07 <dauwhe> ack iv
15:11:07 <MattChan> ... we can only try to infer it
15:11:27 <George> George has joined #epub
15:11:30 <MattChan> ivan: i think we do the right thing if we show there is a discrepancy between RS, that's why we're here, that's what CR is for
15:12:07 <MattChan> ... also, a warning for the wg, if we get a green light to merge today, there are still some follow up issues to handle afterwards, mostly editorial issues
15:12:25 <MattChan> ... these may require further discussion, but they are mostly minor and editorial
15:12:29 <dauwhe> q?
15:12:32 <MattChan> romain: yes, i agree
15:12:48 <George> George has joined #epub
15:12:50 <MattChan> ivan: so don't be alarmed if you see follow up issues, it is intentional
15:12:56 <romain> q+
15:12:59 <dauwhe> ack ro
15:13:06 <MattChan> dauwhe: agree. Better to split the issue into manageable pieces
15:13:09 <George> George has joined #epub
15:13:30 <MattChan> romain: in this PR we use one way to characterize the root URL, there may be something more minimal that would result in more RS being conforming
15:13:39 <MattChan> ... but we haven't heard for that many RS folks
15:14:19 <dauwhe> q?
15:14:31 <dlazin> dlazin has joined #epub
15:14:36 <dlazin> present+
15:14:46 <MattChan> ... the benefit of this PR is that it clarifies a lot of things. We may need to lose some of this precision later.
15:14:48 <George> George has joined #epub
15:14:53 <MattChan> ivan: we had one RS give feedback in the issue
15:15:04 <AUbbink> AUbbink has joined #epub
15:15:06 <MattChan> s/in the issue/in the PR
15:15:14 <MattChan> dauwhe: any other comments?
15:15:14 <AUbbink> present+
15:15:23 <victoria> present+
15:15:27 <dauwhe> Proposal: Merge 1898
15:15:29 <George> George has joined #epub
15:15:38 <ivan> +1
15:15:41 <gpellegrino> +1
15:15:42 <romain> +1
15:15:45 <MattChan> +1
15:15:45 <toshiakikoike> +1
15:15:46 <dlazin> +1
15:15:50 <MURATA> +1
15:15:52 <MasakazuKitahara> +1
15:15:53 <dauwhe> +1
15:15:55 <MURATA> +i
15:15:56 <BenSchroeter> +1
15:16:09 <rickj> +1
15:16:29 <dauwhe> Resolved: Merge 1898
15:16:34 <George> George has joined #epub
15:17:06 <MattChan> ivan: we should thank Romain for this. This situation has existed for a long time in the spec before Romain proposed a solution
15:17:10 <MattChan> dauwhe: thank you Romain
15:17:28 <Victor_Lopes> Victor_Lopes has joined #epub
15:17:43 <dauwhe> https://github.com/w3c/epub-specs/pull/1899
15:17:48 <George> George has joined #epub
15:18:13 <MattChan> dauwhe: historically epub has been focused on interop and we've had some limits on characters allowed in file names
15:18:28 <MattChan> ... makes epubs portable across different OSes
15:19:01 <MattChan> ... as part of i18n review we've gotten a lot of feedback about allowing authors to use their own languages in file names
15:19:48 <George> George has joined #epub
15:19:54 <MattChan> ... this has exposed more edge cases, e.g. allowing unicode chars in the emoji tag sequence
15:20:22 <MattChan> ... a sequence of unicode characters that renders out as the icon of a flag
15:20:49 <MattChan> ... this PR allows this, while still excluding some even more problematic characters
15:20:58 <mgarrish> q+
15:20:59 <dlazin> q+
15:21:02 <dauwhe> ack mg
15:21:18 <MattChan> ... tested this with a file named as the welsh flag, and ADE wasn't happy with the result
15:21:42 <MattChan> mgarrish: wasn't just emoji characters, it was languages with variation selectors (e.g. mongolia script)
15:21:48 <George> George has joined #epub
15:22:05 <MattChan> ... not sure how often authors use this, but if its possible to author it i suppose we should allow it
15:22:17 <ivan> q+
15:22:28 <George> George has joined #epub
15:22:41 <MattChan> ... after consulting with i18n group, we've identified 2 chars that are deprecated and which we still exclude
15:22:59 <dauwhe> ack dl
15:23:28 <MattChan> dlazin: seems like the primary concern here is that we want to support this, but we're wary that its not supported today and we don't want to give authors bad advice
15:24:16 <MattChan> ... physical readers either can't or in practice don't get updates, its not practical for an author to make an ebook using these emojis in file names
15:24:31 <MattChan> ... but then there's the issue of these characters displaying in the stores
15:24:37 <MattChan> ... even if they work in RS
15:24:57 <Karen> Karen has joined #epub
15:25:01 <MURATA> We might want to have a look at https://unicode.org/reports/tr51/#EmojiVersions
15:25:24 <dauwhe> ack iv
15:25:48 <George> George has joined #epub
15:25:58 <MattChan> ... recommend that we make MUST statement in RS spec, SHOULD NOT statement in core, with the possibility that we change to MAY in core in future
15:26:14 <MattChan> ivan: how would we test this?
15:26:25 <George> George has joined #epub
15:26:33 <mgarrish> q+
15:27:05 <George> George has joined #epub
15:27:06 <dauwhe> ack mg
15:27:15 <MattChan> dlazin: in practice i think RS will support UTF-8 or not, but expecting that UTF-8 support will existing throughout the store ecosystem and legacy readers is hard
15:27:21 <MattChan> ... we can test, but we might not get 100%
15:28:20 <dauwhe> q+
15:28:25 <BenSchroeter> +1 to Matt
15:28:38 <romain> q+
15:28:54 <MattChan> mgarrish: are we restricting this because these file names might not work in certain North American stores? Can't the stores themselves decide their own policies for what they will allow?
15:28:56 <ivan> ack dauwhe
15:28:58 <rickj> q+
15:29:01 <dauwhe> ack ro
15:29:06 <MattChan> dauwhe: agree, let's let unicode be unicode
15:29:45 <MattChan> romain: there are quite a few standards/api that define file names, some only exist as editor drafts or cg documents
15:29:48 <George> George has joined #epub
15:30:07 <MattChan> ... the web generally lacks a unified model of a file system, but that means we don;
15:30:07 <dauwhe> q?
15:30:21 <MattChan> ... don't have precedent on the web to rely on
15:30:30 <MattChan> ... and most of these APIs don't restrict file names a lot
15:30:47 <MattChan> ... just say path specific characters can't be part of the file name
15:31:13 <dauwhe> q?
15:31:23 <MattChan> ... to be safe, until we have a unified file system model for the web, we should loosen the restriction by changing the MUST NOT to SHOULD NOT, at least in the authoring system spec
15:31:28 <dauwhe> ack ri
15:31:48 <avneeshsingh> q+
15:31:48 <George> George has joined #epub
15:31:58 <dauwhe> ack av
15:32:01 <MattChan> rickj: we seem to be saying this is a supply chain issue, can we pass this over to the business group? Meanwhile we let unicode be unicode
15:32:22 <romain> for the record, some of the standards I looked at:
15:32:25 <romain> File API: https://w3c.github.io/FileAPI/
15:32:29 <George> George has joined #epub
15:32:35 <romain> File and DIrectory Entries API https://wicg.github.io/entries-api/#names-paths
15:32:44 <romain> Directory Upload: https://wicg.github.io/directory-upload/proposal.html
15:32:48 <mgarrish> q+
15:32:58 <romain> File System Access: https://wicg.github.io/file-system-access/
15:33:01 <MattChan> avneeshsingh: after getting such nice feedback from i18n, I think this is a sign that we should not be restrictive here. Maybe a note that these characters are now allowed, but that some RS may not support it. At least for this revision.
15:33:09 <dauwhe> ack mg
15:33:34 <dauwhe> q?
15:33:35 <MattChan> mgarrish: i'm almost positive that there's a note about zip tools that authors should stay within the ASCII range
15:33:42 <MURATA> ???
15:33:46 <MURATA> +q
15:33:48 <George> George has joined #epub
15:33:53 <MattChan> ... to avneeshsingh's point, perhaps we could generalize this note
15:33:57 <dauwhe> ack mur
15:34:09 <MattChan> MURATA: mgarrish where is this note you just referred to?
15:34:37 <MattChan> mgarrish: it's bottom of 6.1.4
15:35:48 <George> George has joined #epub
15:35:53 <ivan> s/6.1.4/6.1.3/
15:35:57 <MattChan> dauwhe: i think we should merge the PR. This part is uncontroversial. It satisfies i18n and keeps with our philosophy
15:36:02 <dlazin> q+
15:36:09 <MattChan> ... do we need an additional note about the supply chain?
15:36:21 <dauwhe> ack dl
15:36:22 <MattChan> mgarrish: or can we just expand the existing note we were talking about just now?
15:36:41 <MattChan> dlazin: i think we need a note that says caution when using unicode characters
15:36:48 <George> George has joined #epub
15:36:55 <MURATA> +q
15:37:00 <dauwhe> ack mu
15:37:04 <MattChan> ... if you're distributing to only one store and you know that your store supports it, then go ahead, otherwise stay away
15:37:07 <MattChan> MURATA: i don
15:37:15 <dauwhe> q?
15:37:20 <MattChan> ... i don't like that. It discourages non-ASCII characters
15:37:31 <MattChan> dlazin: i want to encourage the use, just not sure it is safe to do so today
15:37:37 <mgarrish> q+
15:37:53 <dauwhe> ack mg
15:37:56 <MattChan> MURATA: i've heard that argument for 20 years, haha. That argument endangers the use of non-ASCII characters
15:38:19 <MattChan> mgarrish: if we change the restriction from MUST NOT to SHOULD NOT, would that work MURATA?
15:39:01 <MattChan> MURATA: this issue is about emoji characters, if we start talking about non-ASCII we may be opening a can of worms
15:39:02 <dauwhe> q?
15:39:13 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
15:39:15 <MattChan> mgarrish: i think the issue is just about what is allowed in file naming, and how restrictive the spec should be
15:39:18 <dauwhe> Some commercial ZIP tools do not support the full Unicode range for File Names. EPUB Creators who want to use ZIP tools that have these restrictions may find it best to restrict their File Names to the [US-ASCII] range.
15:39:41 <wendyreid> wendyreid has joined #epub
15:39:46 <ivan> present+ wendyreid
15:39:48 <George> George has joined #epub
15:39:55 <ivan> present+ Bill_Kasdorf
15:41:09 <MattChan> dauwhe: can we re-write above to avoid referring to US ASCII?
15:41:46 <dauwhe> Proposal: merge 1899
15:41:48 <George> George has joined #epub
15:41:56 <dauwhe> +1
15:41:57 <ivan> +1
15:41:58 <dlazin> +1
15:41:58 <romain> +1
15:41:59 <MattChan> MURATA: this issue is about emoji only, so why are we writing a note about non-ASCII
15:42:03 <MattChan> +1
15:42:04 <mgarrish> +1
15:42:13 <avneeshsingh> +1
15:42:13 <wendyreid> +1
15:42:14 <BenSchroeter> +1
15:42:39 <victoria> +1
15:42:44 <MattChan> dlazin: #1899 just changes "don't use wide range of unicode" to "don't use the two deprecated characters"
15:42:55 <dauwhe> Resolved: merge 1899
15:42:56 <rickj> +1
15:42:56 <MattChan> ... not controversial, I don't think
15:43:08 <MURATA> +1
15:43:48 <George> George has joined #epub
15:44:04 <MattChan> dauwhe: mgarrish do you want to try to reword that note a little?
15:44:18 <MattChan> mgarrish: we'll open an issue about this note?
15:44:20 <MattChan> dauwhe: yes, please
15:44:33 <dauwhe> https://github.com/w3c/epub-specs/issues/1912
15:44:50 <MattChan> TOPIC: Out of container relative URLs
15:45:14 <MattChan> dauwhe: there is a related problem of ../ repeated until it leaks out of the epub
15:45:19 <MattChan> ... should we just disallow such URLs?
15:45:25 <MattChan> ... i think yes
15:45:28 <ivan> q+
15:45:31 <dauwhe> ack iv
15:45:48 <George> George has joined #epub
15:45:58 <MattChan> ivan: isn't it correct that we don't need to do anything about this problem because what we just merged avoids any sort of security issue
15:45:58 <romain> q+
15:46:41 <MattChan> ... this sounds like adding a good practice to the text, but its an extra measure to guard against RS that don't follow what we merged in #1898
15:47:05 <MattChan> romain: this would add an authoring conformance requirement for URLs
15:47:26 <MattChan> ... such leaky URLs will likely create interop issues with legacy/non-conforming RS
15:47:30 <dauwhe> q?
15:47:32 <romain> <item href="../../../../EPUB/content.xhtml"/>
15:47:35 <dauwhe> ack r
15:47:48 <romain> <item href="EPUB/content.xhtml"/>
15:47:48 <George> George has joined #epub
15:47:55 <mgarrish> q+
15:47:57 <MattChan> ... so to avoid conforming but non-interop friendly epubs, we just ban such URLs
15:48:03 <rickj> q+
15:48:37 <MattChan> ... #1898 makes the two URLs above equivalent, but i'm doubtful that in practice all RS will handle this properly
15:48:47 <dauwhe> ack mg
15:49:14 <dauwhe> ack ri
15:49:22 <MattChan> mgarrish: an epub2 RS must still be able to open epub3. And because of that it makes sense to keep things consistent from an authoring perspective
15:49:41 <MattChan> rickj: seems like this obligates a change in epubcheck? How does that change happen?
15:49:48 <George> George has joined #epub
15:50:00 <MattChan> romain: epubcheck will be updated to implement epub 33, don't worry
15:50:04 <MattChan> rickj: thank you!
15:50:20 <ivan> q+
15:50:21 <George> George has joined #epub
15:50:32 <dauwhe> ack iv
15:50:34 <MattChan> dauwhe: alignment of epub 33 spec and epubcheck will be smooth, thanks to mgarrish and romain
15:50:45 <MattChan> ivan: there is already an alpha version of epubcheck for epub spec 33
15:50:59 <George> George has joined #epub
15:51:09 <romain> https://github.com/w3c/epubcheck/releases/tag/preview
15:51:25 <MattChan> dauwhe: i think we just disallow out of container URLs
15:51:36 <dauwhe> proposal: disallow "out-of-container" relative URLs
15:51:46 <MattChan> romain: in the issue i propose an algorithm to identify what is an out of container URL string
15:51:54 <MattChan> ... please comment in issue if you spot error there
15:52:02 <dauwhe> +1
15:52:04 <rickj> +1
15:52:09 <BenSchroeter> +1
15:52:09 <mgarrish> +1
15:52:11 <dlazin> +1
15:52:13 <victoria> +1
15:52:15 <MattChan> +1
15:52:17 <ivan> +1
15:52:18 <romain> +1
15:52:22 <MasakazuKitahara> +1
15:52:28 <Bill_Kasdorf> +1
15:52:33 <toshiakikoike> +1
15:52:35 <wendyreid> +1
15:52:41 <MURATA> +1
15:52:55 <dauwhe> resolved: disallow "out-of-container" relative URLs
15:53:10 <George> George has joined #epub
15:53:18 <MattChan> TOPIC: How to handle deprecation during CR
15:53:33 <MattChan> dauwhe: i propose we push this to a different meeting given time restriction
15:53:38 <MattChan> ... it's a complex topic
15:54:02 <MattChan> wendyreid: can we outline the issue and give people time to think during the addjournment?
15:54:36 <MattChan> ... as part of our CR prep, we have to have a plan for what to do when we discover features that are at risk
15:54:39 <dauwhe> https://html.spec.whatwg.org/multipage/obsolete.html#obsolete
15:54:48 <MattChan> ... once we go through the testing process we will likely discover some of these
15:55:05 <MattChan> ... it's up to us what to do about these, but generally you deprecate these
15:55:11 <MattChan> ... however, we have an obligation to backwards compat
15:55:32 <MattChan> ... so what is our plan for these at risk features?
15:55:48 <George> George has joined #epub
15:56:17 <MattChan> ... we've said "deprecate" in the past, but HTML spec uses various flavors of "obsolete"
15:56:25 <ivan> q+
15:56:40 <dauwhe> ack iv
15:56:45 <MattChan> ... we're thinking of a similar model - deprecated features that might still have some life in them vs deprecated features that are pretty much done
15:57:11 <MattChan> ivan: usually if a feature doesn't have the required number of implementations, that feature is just cut from spec
15:57:35 <MattChan> ... we are saying we can't do that because of our backwards compat charter
15:57:48 <George> George has joined #epub
15:58:13 <MattChan> ... re. vocab, personally my preference would be to just adopt the HTML spec's vocab and definition
15:58:22 <dauwhe> q?
15:58:34 <MattChan> ... the content in the epub is HTML anyway, so being compatible seems to make a lot of sense
15:58:59 <MattChan> ... that's something that we'd have to review in detail. It might just be an editorial change, maybe more.
15:59:18 <MattChan> ... also, we have to think about how that maps to report from epubcheck
15:59:25 <dauwhe> q?
15:59:26 <MattChan> wendyreid: okay, we can discuss this in the next meeting
15:59:37 <MattChan> dauwhe: okay, thank you all
15:59:43 <MURATA> Bye now!
15:59:47 <MattChan> ivan: happy thanksgiving to all us friends!
15:59:48 <George> George has joined #epub
16:00:21 <ivan> rssagent, draft minutes
16:01:19 <ivan> rrsagent, draft minutes
16:01:19 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/19-epub-minutes.html ivan
16:02:17 <ivan> zakim, end meeting
16:02:17 <ivan> rrsagent, bye
16:02:17 <RRSAgent> I see no action items
16:02:17 <Zakim> As of this point the attendees have been ivan, rickj, avneesh, george, toshiakikoike, MasakazuKitahara, dauwhe, matthew, romain, ubbink, vlopes, ben, Victoria, BenSchroeter,