16:43:42 RRSAgent has joined #pwg 16:43:42 logging to https://www.w3.org/2018/01/29-pwg-irc 16:43:43 rrsagent, set log public 16:43:43 Meeting: Publishing Working Group Telco 16:43:43 Chair: Tzviya 16:43:43 Date: 2018-01-29 16:43:43 Regrets+ Vlad, George 16:43:43 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Jan/0077.html 16:43:43 ivan has changed the topic to: Meeting Agenda 2018-01-29: https://lists.w3.org/Archives/Public/public-publ-wg/2018Jan/0077.html 16:51:04 jbuehler has joined #pwg 16:52:19 baldurbjarnason has joined #pwg 16:52:21 NickRuffilo has joined #pwg 16:52:46 Teenya has joined #pwg 16:56:47 present+ 16:57:28 rkwright has joined #pwg 16:57:44 present+ 16:57:58 Avneesh has joined #pwg 16:58:05 evan has joined #pwg 16:58:06 toshiakikoike has joined #pwg 16:58:13 present+ 16:58:26 present+ 16:58:33 laurab has joined #pwg 16:58:37 dkaplan3 has joined #pwg 16:58:41 present+ 16:59:04 present+ 16:59:11 present+ 16:59:34 JunGamo has joined #pwg 16:59:53 present+ 17:00:03 present+ 17:00:11 cmaden2 has joined #pwg 17:00:19 present+ 17:00:29 present+ dauwhe 17:00:35 scribenick: nickruffilo 17:00:37 present+ 17:00:41 present+ wolfgang 17:00:58 rdeltour has joined #pwg 17:01:01 present+ Chris_Maden 17:01:02 lsullam has joined #pwg 17:01:10 laudrain has joined #pwg 17:01:12 present+ 17:01:23 present+ 17:01:56 present+ 17:01:59 Evan_Owens has joined #pwg 17:01:59 present+ teenya 17:02:13 present+ 17:02:13 josh has joined #pwg 17:02:16 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-01-22-minutes 17:02:19 Tzviya: Review the minutes from last week - any comments? 17:02:27 present+ 17:02:34 present+ 17:02:41 ...: Minutes approved - we have Jeffrey Askin here to talk to us about web packaging 17:02:51 s/askin/Yasskin 17:03:14 present+ 17:03:20 mateus has joined #pwg 17:03:20 marisa has joined #pwg 17:03:25 present+ 17:03:29 present+ 17:03:49 Jeffrey: I'm here to answer questions - but I can tell you what has changed. Since the last ITF, their advice was to split the spec into two pieces - which is mostly done. Half is about signing an HTTP request/response pair from a given origin (which is what chrome is doing with amp). The other piece is about bundling a set of request/response pairs. That is probably more interesting to your 17:03:49 group but less far along. 17:04:15 pkra has joined #pwg 17:04:23 present pkra 17:04:29 present+ pkra 17:04:29 ...: We have a draft of the bundling proposal, but it's a flat list of exchanges (Req/Res pair) and i would like feedback from you to know what I would need to include to make it useful for you. What is the minimum number of things that you would need. 17:04:56 q+ 17:05:00 Bundling PR: https://github.com/WICG/webpackage/pull/98 17:05:01 Hadrien has joined #pwg 17:05:03 Tzviya: Last week there was extensive discussion over IRC - i followed it - I'm not sure we need to reiterate, but Ben/Hadrien, do you have opinions about this? 17:05:08 present+ 17:05:30 BenSchroeter has joined #pwg 17:05:34 s/ITF/IETF 17:05:52 zheng_xu has joined #pwg 17:06:06 Ben: I don't know if I technically have any problems with it, but there are broad concerns over developer tooling because it is new. There is the process of decoding and encoding. We should think through what the process of putting these together is and what scenarios we need to pack/unpack. With google working on it, it should be primed for text search, but I don't have concrete asks of the 17:06:06 spec yet. 17:06:07 ack dauwhe 17:06:14 present+ 17:06:18 Dave: I wanted to ask the basic question about the web-application manifest step. 17:06:23 present+ 17:06:55 Jeffrey: The web app manifest is the top of the bundle - which resources mean what. It has a start URL - to know which page to display. I imagine that a publication could extend the manifest to include additional metadata. 17:07:15 garth has joined #pwg 17:07:19 Dave: There is not going to be - I get confused because web application don't serve as a manifest in the way of listing all contents within... 17:07:29 present+ Garth 17:07:29 Jeffrey: Yes - I believe it's misnamed, but, that is what it is named... 17:07:36 q? 17:07:48 Bill_Kasdorf has joined #pwg 17:07:49 Dave: You don't envision this package requiring that sort of thing? 17:07:50 present+ 17:07:59 q+ 17:08:18 q+ 17:08:28 for reference https://github.com/w3c/wpub/issues/118 17:08:46 Jeffrey: The package has a list at the top which lists all the exchanges. It's a list of the requests of the exchanges and a list of responses. There has been talk from web performance people for a manifest to be available. I haven't designed that - i'm probably not the best person to do that, but the webapp manifest could point to the resource manifest. 17:08:48 q? 17:08:53 ack bigbluehat 17:09:50 Benjamin: The performance thing is interested - a core thing we're working on in another JSON manifest ... would be items in the packages and what is referenced in the manfiest. A key constraint is that it needs to be ordered - so it would be useful for items to be able to get just what they want... 17:09:54 Jeffrey: What order? 17:10:34 q? 17:10:45 Benjamin: Reading order. but ultimately an intentional progression from front to back. Right now that doesn't exist. RSS and ATOM have them in a date-based progression, but no other manifest that has linearity of retrieval. It's not that it's necessarily a requirement of packaging, but it's something we're encoding. 17:10:51 duga has joined #pwg 17:11:01 ack Hadrien 17:11:04 present+ 17:11:10 Jeffrey: The package does not have any order for the index or the resources. If a web publication would like to say that things appear in a reading order, that would be fine. 17:11:40 Hadrien: I don't mind that the package would be a list of reqs/resp - but how would this work in the case of the WAM - where this could show as the first resource in the package - how can you be the first if there is no order? 17:12:21 q+ 17:12:22 q? 17:12:22 Jeffrey: There is a top-level index of sections - there is the manifest request/URL - and the index location. You would generally put the manifest URL in the beginning, then you'd look that up in the index. You would want to put it early in the package. Does that make sense? 17:13:13 Hadrien: In your list, which is a manifest - you'd have a member of this list, that would be what is the WAM. Once I know that, i can look at the list of resp/req - Once I've identified which URI is required - I can do a range request to only get the content I want? 17:13:17 Jeffrey: yes 17:13:29 Hadrien: The full list of req/resp is a full list? 17:14:04 Jeffrey: It's a mapping of HTTP requests to the range within the package to the response and payload. Right now it has no structure, but if there is a need for struction - such as a btree, we could add that, but no one said that is essential - so the whole index is loaded. 17:14:38 s/struction/structure/ 17:15:12 Hadrien: A flat list is fine, as it has a very different role - and we shouldn't try to do too many things at once. it's a flat list which gives specific information about how to get specific data. The one thing I want to make sure is possible is that - how you identify the manifest shouldn't be something that only works with the WAM - not just for our own group, but for any group that works 17:15:12 with WAM. There should be a generic way to identify the manifest 17:15:36 Jeffrey: The top level is named indexes. The manifest key means WAM - It could be named and we could add other top-level names. 17:16:14 Hadrien: have you thought about generic link elements? With ATOM there are generic links that can point to any source, then you have a rel tag. That way resources are actually embedded and you don't have to create a name element. You can use whatever rel and media type you want. 17:16:19 ack bigbluehat 17:16:23 Jeffrey: that makes sense to think of it that way 17:18:44 benjamin: I agree with Hadrien's concerns - I feel like extensibility is a bit tangled up in that document and it's use here, so I'd love to see clarification. The flexibility to use a different manifest would be useful. We need to look through how this uses full reqs/resp. I think it's great that it's in there, but what are the ramifications and what things from what places can be included. 17:18:44 There is an intent to do origin-based signing, but what are the ramifications of those design choices. We've talked about being able to combine multiple resources into a package - if that is a thing, that this is that. Or that a lack of that is OK as well - so what does it mean to package things up in this way. So - are we moving the filesystem to the web, or the web to the filesystem. This 17:18:44 is coming from the web to a filesystem - so we need to think through that as well. 17:18:52 Jeffrey: Are you going to want external dependencies? 17:19:25 Benjamin: External in the package - there are scenarios where that is desired - where we get a publication that is a collection of published resources - that would want to utilize resources that are already on the web. 17:19:45 +1 (external resources) 17:19:50 Tzviya: I'm sure there are many people who are confused - Ben - can you do a 30 second summary on how this discussion relates to web package and such. 17:20:26 jyasskin: use case documents https://w3c.github.io/dpub-pwp-ucr/ 17:21:19 present+ Bill_Kasdorf 17:22:29 Benjamin: The epub zip format is the one best known to the group = in it, it has an initial member of a media type, and an XML manifest. The zip package is made off of a hard drive - and items are in order of whatever the zip tool wants to put them. Another thing points to reading order, then one the TOC. None of these have web knowledge or network knowledge. The single file then gets moved 17:22:29 around. In this package format - it encodes more than just a file - it includes the initial request of the server to give you - usually a GET request (i want a PDF version, etc) and then it includes the response "i got it this time, etc" and then the body of the response - which would be analogous to the file stored within the EPUB. 17:23:28 Benjamin - it would be the URL and the file. It is also - because it's based on web packaging - has MIME-like tendencies. There is more information about the existence of this thing than we've had in the past. What we cannot do with this format is to go from a non-web-connected hard drive and package a thing and move the thing around. All these items need to be on the web and requested and 17:23:28 responded to. 17:23:59 q? 17:24:15 Jeffrey: You could fake it - but you'd need to do it from a disk (you'd need a signing key) so you aren't going to build a package simply from the req/resp, but they are there on behalf of the client. Most of the time they will be generated from a disk with extra metadata. 17:24:40 Benjamin - so it's a little more like service workers where it makes a fake HTTP world - so you make fake requests and responses come back. That's where signing comes in. 17:24:54 Jeffrey: We do expect that if you make a web request that they will have something to do with each other, but they do not have to. 17:25:37 q? 17:25:52 Jeffrey: I've been using the assumption that if you see a request in a package, if you make the same request, you'll get the same response - but for instance some of the signature verifications, you can update a signature by re-requesting from the actual web. If you are completely from the back-end you wouldn't need to fake it. You would probably build things from the server, not from making 17:25:52 requests. 17:26:32 Garth: It sounds like where Benjamin was going - that this format the request URL could be a file URL - it's not really that relevant. it's not invalid to say: "there are a bunch of resources that have never been on the web" 17:26:55 q+ 17:26:58 Jeffrey: You could have a bunch of file URLs but i'm concerned about how that would load - but there are ways of generating URIs that are not accessible via the web. 17:27:02 q+ 17:27:20 Jeffrey: It should work - signing would be weird, but yeah, it should work 17:27:34 ack bigbluehat 17:28:13 I'm also happy to get more comments as bugs on https://github.com/WICG/webpackage/issues 17:28:41 Benjamin: It would be great to get exact questions that need answering. What I was going to mention - related to origin signing - that's one of the most valuable part of this. If we didn't go with that, we'd miss out about origin-based. In the history of publishing - what a publisher provides is the authority that they went through the trouble of vetting authority - so they put their name and 17:28:41 reputation on it. And it's something the web terribly lacks and this tool provides. 17:29:20 timCole has joined #pwg 17:29:50 q? 17:29:51 Jeffrey: The current design is missing that - the layering that was asked for is sign exchanges - so you could sign a single or bundle of exchanges. A publisher probably wants to sign an entire book - not the individual pages - so it's about bundling. That publisher signature can be counter-signature - so individual pages are by the author, and the publisher signs the book - which should work 17:29:51 with file-URLS, they aren't signing as the file-origin... 17:30:01 ack NickRuffilo 17:30:28 NickRuffilo: what if there was no file and the reading system acted as a mini web server as a local host? 17:30:53 ...would that open up an opportunity for offline reading? I know you can 17:31:02 s/I know you can/ 17:31:19 q? 17:31:19 Jeffrey: You cannot get a signing for localhost - so you would leave that resource unsigned. You then would have a publisher sign it as a non-origin signature. 17:31:24 q+ 17:31:28 ack Hadrien 17:32:15 q+ 17:32:41 ack garth 17:32:44 Hadrien: I wanted to point out that this is what readium and readium 2 are doing. They are using localhost to serve files in a package. It should work perfectly fine with other packages. This works OK when you have relative URIs. If you have absolute URIs - such as pointing on a web - this doesn't work very well. We have two situations - where native browser support works well, and one that 17:32:44 only works well in a native environemnt. Having somethign that works well with pubs that are on the web AND for things that never existed on the web - they are quite different. 17:33:08 Garth: Jeffrey - you talked about using non-signed resources locally, and the pub signing later - what is required, if anything to be signed? 17:34:40 Jeffrey: To sign something, you get a certificate saying who you are. Private/Public key. You sign something and it attaches it to your identity. There are many different type of security - such as TLS, but there are others. There are also certificates that say a signer is a legal entity. If you sign with something like that, a web browser cannot really use that. Although it could be displayed 17:34:40 above content to say this entity vouches for this. 17:34:46 Garth: What is the requirement for signing resources? 17:36:31 q? 17:36:50 Jeffrey: There is no requirement that you have to sign a resource in a bundle. There is a requirement from a web browser that - if a resource in a package claims a request URL - to act as a URL, it needs to be signed as it's origin. That's where origin signing requirement comes from. If you go to a website and you want to save it - you cannot generate signatures for it - the URL that shows when 17:36:50 loading that will be different. In a reading system, that may not matter - you may not have it definitely from that origin. You may still want the publisher to counter-sign it. 17:37:14 Garth: In the past, Ivan, you were viewing the complexity of origins as a feature and a bug. Does this recent discussion make you happy or not? 17:37:41 +1 17:38:29 +1 to Ivan's worries 17:38:32 Ivan: My problem was different - even if we wanted to go from just the web, because there is a strong wish to have signature, the problem comes that for everyday person's to have all the signature provided, becomes a headache because of the complexity of the flow of getting a signature - and the tools. it's not a fault of those around the table... If I want to create a packaged publication, and 17:38:32 i want to sign it - i don't have the tools yet. 17:38:49 Jeffrey: An individual author may not create a signed version. 17:38:59 q? 17:39:21 Ivan: Because signature is so important, we need to work on making the process better (by asking our friends to make it better/easier) 17:39:22 q+ 17:39:38 ...: There is a community out there that we should put pressure on. 17:40:13 Jeffrey: If you're running a web server we'd expect you to have a module to be able to create these. it's straightforward to write software to generate packages as a server - and I'm sure it will get integrated with a wordpress, there will be tools. 17:40:40 ack NickRuffilo 17:40:44 Ivan: Let's be optimistic... I tried to update my personal domain certificate - but the process left me very uneasy, even though it was spelled out for me. 17:41:01 Nick: why is signing important? 17:41:11 q+ 17:41:14 q+ 17:41:33 Jeffrey: If you want to publish something and have it be interactive, and save data, you have to sign - so that it isn't exposing it to everyone. or you have to be CORS. 17:41:54 ...: If you are just in read mode - it will show up in a URL bar, but otherwise you don't actually need to sign. 17:41:56 q+ 17:41:58 ack ivan 17:43:55 q+ to suggest we write up some apocalyptic scenarios also 17:44:07 Ivan: Stepping away from the tech details - we wanted to see how we could move forward. What I was wondering - the first step - is it possible to use Moby Dick - and try to go through the process of creating a packaged version of that using this concept as a spec. This makes it clearer what is going on - what are the difficulties and easy parts, then work together on that, which might raise 17:44:07 issues that are interesting/new. Then see how we can help you with some of the work, Jeffrey. We can always raise issues, but issues are on very specific things. I'm not sure - besides maybe Benjamin and Hadrien, we don't have a good view as how the whole thing will resolve. I see Benjamin has volunteered for a flowchart? 17:44:20 ...: Most of us need this... Dave? Have you tried this yet? 17:44:34 Dave: I've done it for different formats, and I've played around, but I need to look. 17:44:59 q- 17:45:00 Ivan: We should cross-check with Jeffrey to make sure we have the same thing. 17:45:29 Tzviya: I was going to comment about signatures, but lets' make sure dave's example is current then pass it to Jeffrey. 17:45:34 Note that "webpack" is a different thing from "web packages", and we're trying to find a new name for "web package" to avoid that confusion. 17:45:39 ack NickRuffilo 17:46:19 q? 17:46:22 https everywhere! 17:46:24 ack bigbluehat 17:46:24 bigbluehat, you wanted to suggest we write up some apocalyptic scenarios also 17:46:26 Nick: So not everyone would need signatures - just certain types of content (especially ones that are interactive) 17:46:33 Jeffrey: Yes... 17:48:03 q? 17:48:03 Benjamin: I suggest we write down some apocalyptic scenarios. We talk about idealistic stuff - but we rarely talk about publisher A buying publisher B - where publisher B no longer exists as a domain... That way we can think about how that affects the content. Then how this would map to the Web Package Format - but generally, what are the actions that a publisher would need to get into all the 17:48:03 formats. 17:49:32 Jeffrey: There's an issue - all of the signatures in a package, those signatures expire, and fairly quickly. A publication you'd want to trust longer, but I'm not sure how we would be able to,... Publications should not need revalidation all the time - and I'm not sure how to square these things. 17:49:48 Benjamin: We should research verifiable claims. 17:49:51 this WG https://www.w3.org/2017/vc/WG/ 17:49:56 Ivan: Can you summarize in one minute? 17:51:57 https://www.w3.org/TR/verifiable-claims-use-cases/ 17:52:21 Benjamin: Verifiable Claims is working on being able to verify the claims made in files that move around that doesn't require them to permenantly exist on the web, or constant money flow into a registry. That way you can make a claim, sign that claim, then pass that file around to those who need it and they can act on that claim. ID-related scenarios - a publisher signing they are - such as a 17:52:21 hash even. Those statements need a foundation. Right now we just sort-of trust. What I'm hearing is that the web pacakge format plays inside the existing space, and works with existing services, but knowing the volatility of domains, it has to stay inside that space and is providing more optimizations around cached collections and web distributions, not necessarily chausser's work for eternity 17:52:21 - which is what publishers need - validated verifiable claim... 17:53:04 Jeffrey: I think VC is missing some of the apoc - such as what if a cert gets stolen, etc. Revocation is the hard part... 17:53:26 q? 17:53:35 Tzviya: Any other questions for Jeffrey? 17:53:43 Ivan: How do we step forward? 17:54:17 Jeffrey: I'm going to be finishing up the first draft of the bundling spec next week. The PR that i posted to the minutes - please do. Send patches... Look at what I produced, and if it works, great, if not, let me know. 17:54:37 q+ 17:54:52 ack ivan 17:54:57 q- 17:54:59 ...: The sign exchanges draft i hope they will accept in March. I don't know after that what timeline is likely to look like. The bundling spec might get discussed in london, and the IETF won't discuss and it'll come back to the W3C. 17:55:16 Ivan: I see that the URL you gave refers to IETF work - so none of that is done in W3C? 17:55:28 Jeffrey: Bundling - we don't know yet, but W3C will stay involved. 17:55:52 Ivan: Do we have any timeline on how things would evolve - we have dependencies. 17:56:12 Jeffrey: I can take some of the timeline by you - do you have a date for when you'd need a bundling spec scetched? 17:56:30 Ivan: We are supposed to have a candidate rec - tech wise we should be fixed - by end of this year. 17:56:34 Tzviya: Q1 2019... 17:56:52 Ivan: in about a year - that means the packaging spec should be at our disposal in 8 months? 17:57:07 Jeffrey: I should be able to have a finished draft by summer - but I expect we'll need to iterate on it. 17:57:20 Garth: Thank you Jeffrey 17:57:36 https://docs.google.com/document/d/1kY6NJs5s28S2uXfcB55IdTSAPTnbMeP4rVVajdCaQBc/edit?usp=sharing 17:58:01 Tzviya: For the first public working drafts - we put together a google doc. If you have people who would be interested in this - if you work for an org that will utilize this - please shout about this. 17:58:10 https://www.w3.org/publishing/groups/publ-wg/Meetings/F2F/2018.05.Toronto 17:58:59 ...: We have a F2F coming up in Toronto in May. Garth, Ivan, and I will be talking with our hosts (Kobo) there are information about Hotels - get hotels and flights in order, but we wanted to make sure people were aware of that. If you are new - there is a meeting tomorrow for new members. 17:58:59 q? 17:59:16 bye! 17:59:20 zheng_xu has left #pwg 17:59:30 evan has left #pwg 17:59:37 JunGamo has left #pwg 18:00:18 dkaplan3 has left #pwg 18:00:38 cmaden2 has left #pwg 18:01:07 rrsagent, draft minutes 18:01:07 I have made the request to generate https://www.w3.org/2018/01/29-pwg-minutes.html ivan 18:01:34 rrsagent, draft minutes 18:01:34 I have made the request to generate https://www.w3.org/2018/01/29-pwg-minutes.html ivan