15:45:05 <RRSAgent> RRSAgent has joined #pwg
15:45:05 <RRSAgent> logging to https://www.w3.org/2019/04/15-pwg-irc
15:45:06 <ivan> rrsagent, set log public
15:45:06 <ivan> Meeting: Publishing Working Group Telco
15:45:06 <ivan> Chair: wendy
15:45:06 <ivan> Date: 2019-04-15
15:45:06 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2019Apr/0017.html
15:45:06 <ivan> ivan has changed the topic to: Meeting Agenda 2019-04-15: https://lists.w3.org/Archives/Public/public-publ-wg/2019Apr/0017.html
15:45:07 <ivan> Regrets+ Luc, bigbluehat
15:54:13 <mgarrish> mgarrish has joined #pwg
15:55:05 <mateus> mateus has joined #pwg
15:55:24 <ivan> present+
15:55:57 <dkaplan3> dkaplan3 has joined #pwg
15:56:06 <tzviya> present+
15:56:16 <dkaplan3> present+
15:56:39 <mateus> present+
15:57:10 <ivan> present+ george
15:57:57 <rkwright> rkwright has joined #pwg
15:58:49 <geoffjukes> geoffjukes has joined #pwg
15:58:53 <dauwhe> present+
15:59:04 <George> George has joined #pwg
15:59:10 <wendyreid> present+
15:59:12 <George> present+ George
15:59:49 <Avneesh> Avneesh has joined #pwg
16:01:26 <mgarrish> present+
16:01:48 <gpellegrino> gpellegrino has joined #pwg
16:01:52 <dauwhe> scribenick: dauwhe
16:01:56 <gpellegrino> present+
16:02:02 <dauwhe> wendyreid: let's get started
16:02:02 <wendyreid> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-04-08-pwg
16:02:07 <laurent> laurent has joined #pwg
16:02:07 <dauwhe> ... last week's minutes
16:02:11 <dauwhe> ... any comments?
16:02:25 <dauwhe> ... minutes approved
16:02:28 <ivan> resolved: last week's minutes approved
16:02:44 <ivan> topic: publishing CG
16:02:48 <dauwhe> ... we now have a Publishing Community Group!
16:02:55 <dauwhe> ... chaired by Mateus and Jeff
16:02:59 <dauwhe> ... doing incubation
16:03:03 <dauwhe> ... please join
16:03:07 <BenSchroeter> BenSchroeter has joined #pwg
16:03:12 <BenSchroeter> present+
16:03:12 <George> George has joined #pwg
16:03:33 <laurent> present+
16:03:38 <dauwhe> wendyreid: we're going to talk about audio again
16:03:40 <ivan> topic: issues
16:03:41 <Avneesh> present+
16:03:43 <wendyreid> https://github.com/w3c/wpub/issues/420
16:03:48 <marisa> marisa has joined #pwg
16:03:50 <ivan> subtopic: duration
16:03:53 <marisa> present+
16:03:59 <dauwhe> ... should duration be required?
16:04:00 <franco> franco has joined #pwg
16:04:00 <ivan> #420 and #421
16:04:05 <josh> josh has joined #pwg
16:04:06 <franco> present+
16:04:12 <ivan> q+
16:04:13 <dauwhe> ... duration will become part of the core spec
16:04:14 <josh> present+
16:04:18 <wendyreid> ack ivan
16:04:21 <dauwhe> ivan: there are 2 issues
16:04:37 <garth> garth has joined #pwg
16:04:37 <dauwhe> ... one is, if i take duration for one resource, the question came up is what is the format for the value?
16:04:53 <dauwhe> ... one possibility would be to use the ISO ??? Value, which is used by schema
16:04:55 <tzviya> https://github.com/w3c/wpub/issues/420
16:04:59 <dauwhe> ... or we could use RFC xxx
16:05:04 <wendyreid> s/???/8601/
16:05:06 <dauwhe> ... which is used in the media world
16:05:08 <duga> duga has joined #pwg
16:05:15 <duga> present+
16:05:32 <dauwhe> ... the majority seem to favor the RFC value, as it's more readable than ISO
16:05:50 <dauwhe> ... we had an issue a while ago where that was decided, but it wasn't clean in the doc
16:05:50 <wendyreid> s/xxx/7826/
16:05:57 <timCole> timCole has joined #pwg
16:06:01 <dauwhe> ... we can reinforce this decision
16:06:06 <dauwhe> ... this is one part of it
16:06:08 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
16:06:13 <Bill_Kasdorf> present+
16:06:33 <timCole> present+ Tim_Cole
16:06:43 <dauwhe> wendyreid: I've tried to talk to danbri about this, no response yet
16:07:02 <dauwhe> ... the RFC value fits better with what we want to do, especially if we also want to reference media fragments
16:07:05 <laurent> present+
16:07:14 <dauwhe> ... can we merge the PR and close this issue?
16:07:30 <dauwhe> ivan: do we want to make a new resolution, or the already decided one?
16:07:42 <dauwhe> wendyreid: let's stick with the mpt?
16:07:52 <wendyreid> s/mpt/NPT/
16:07:59 <geoffjukes> q+
16:08:04 <dauwhe> ivan: I don't know if Geoff can get on the call
16:08:16 <wendyreid> ack geoffjukes
16:08:25 <dauwhe> geoffjukes: I'm confused about the intent
16:08:31 <dauwhe> ... specifying the duration of the resource
16:08:39 <dauwhe> ... it's the file, effectively
16:08:47 <dauwhe> ... that duration is only specified in seconds
16:08:58 <dauwhe> ... never anything else
16:09:13 <dauwhe> ... my concern is that putting in media fragments at the resource level doesn't make sense
16:09:30 <dauwhe> ... if the intent is to conform to schema.org, and we should just use ISO
16:09:41 <dauwhe> ... so why NPT instead of using a double?
16:09:55 <dauwhe> ... I don't know why it's a consideration
16:10:27 <dauwhe> wendyreid: media fragments will be a thing, although maybe more in TOC etc than in resources
16:10:47 <dauwhe> geoffjukes: that's not describing a resource, but metadata
16:10:57 <dauwhe> wendyreid: we don't want two different formats for these things
16:11:00 <dauwhe> geoffjukes: I disagree
16:11:02 <ivan> q+
16:11:28 <dauwhe> ... and I'm having trouble with these very long discussions
16:11:41 <dauwhe> ... I think of a media fragment as a different thing than a resource
16:11:42 <wendyreid> ack ivan
16:12:01 <dkaplan3> geoffjukes: +1 for calling out our confusing conversations as confusing. Thanks.
16:12:12 <dauwhe> ivan: the NPT format is defined in a way that it can have only a number, which is seconds
16:12:36 <dauwhe> ... the author may choose to use raw seconds
16:12:42 <tzviya> q+
16:12:46 <laurent> q?
16:12:48 <wendyreid> ack tzviya
16:13:07 <dauwhe> tzviya: i missed last week. is it possible to summarize the discussion?
16:13:15 <dauwhe> ivan: in a way we jumped ahead
16:13:22 <geoffjukes> q+
16:13:24 <dauwhe> ... we have make a choice between ISO and RFC
16:13:42 <dauwhe> ... then during the discussion a third option became possible, just taking the number of seconds
16:13:46 <dauwhe> ... those are the three options
16:14:04 <dauwhe> ... so the question is which of the three?
16:14:08 <wendyreid> ack geoffjukes
16:14:26 <dauwhe> geoffjukes: in addition to that, what is the desire to conform to schema? Is that a design priinciple?
16:14:30 <laurent> q+
16:15:00 <dauwhe> ivan: we want the contents of the manifest to be accessible to the knowledge graph
16:15:09 <dauwhe> ... it's mostly important for bibliographic metadata
16:15:54 <dauwhe> geoffjukes: the desire to conform to schema is high, so we can obtain cross-venddor parsing capability
16:16:06 <dauwhe> ... is that correct?
16:16:08 <dauwhe> ivan: yes
16:16:11 <wendyreid> ack laurent
16:16:35 <dauwhe> laurent: here we are speaking on duration of resource, not duration of audiobook. it's not a property of a book.
16:16:49 <dauwhe> ... so it's not tied to a need to express audiobook metadata for schema
16:17:08 <dauwhe> ... so we could use seconds, with a name other than duration (like runtime or length)
16:17:17 <dauwhe> ... and the audiobook industry would be happy with that
16:17:19 <geoffjukes> q+
16:17:23 <ivan> q+
16:17:25 <wendyreid> ack geoffjukes
16:17:33 <JunGamo> JunGamo has joined #pwg
16:17:39 <dauwhe> geoffjukes: I'd be happy with a new thing called length or whatever, that's just a double
16:17:44 <dauwhe> ... it's what we already do
16:17:44 <wendyreid> ack ivan
16:17:50 <dauwhe> ivan: to be clear I am just a messenger
16:17:57 <dauwhe> ... whatever the group decides is fine
16:18:02 <timCole> q+
16:18:06 <wendyreid> ack timCole
16:18:39 <dauwhe> timCole: the decision could be made, that in this community we would use duration but constrain the value of seconds
16:18:40 <ivan> q+
16:18:43 <dauwhe> ... i think this is OK
16:18:53 <garth> present+ Garth
16:18:57 <dauwhe> ... it could be enforced via a context document
16:19:09 <dauwhe> ... we could also define our own property, and connect it to duration
16:19:28 <dauwhe> ... there are ways to express constrained versions of other properties
16:19:31 <wendyreid> ack ivan
16:19:38 <dauwhe> ivan: I don't think that works
16:19:50 <dauwhe> ... schema uses the ISO format, and it doesn't allow a simple number
16:20:06 <dauwhe> ... a number can be a subset of RFC, but not of ISO
16:20:27 <ivan> q+
16:20:33 <JunGamo> present+
16:20:43 <dauwhe> wendyreid: the reason we were leaning on RFC it has only two ways to express time, including only seconds
16:20:57 <dauwhe> ivan: I would propose to move on
16:20:58 <wendyreid> ack ivan
16:21:24 <dauwhe> ... we define that property to have a value being a float consisting of the number of seconds
16:21:30 <dauwhe> ... with a new term like length
16:22:12 <wendyreid> Resolution: The time length property (unnamed) will only use a float consisting of the number of seconds of the resource.
16:22:23 <ivan> +1
16:22:24 <laurent> +1
16:22:26 <dauwhe> +1
16:22:27 <franco> +1
16:22:29 <timCole> +1
16:22:29 <geoffjukes> +1
16:22:30 <josh> +1
16:22:33 <marisa> 0
16:22:40 <Avneesh> +-0
16:23:02 <dauwhe> Avneesh: no strong opinion :)
16:23:03 <ivan> zakim, who is here?
16:23:03 <Zakim> Present: ivan, tzviya, dkaplan, mateus, george, dauwhe, wendyreid, mgarrish, gpellegrino, BenSchroeter, laurent, Avneesh, marisa, franco, josh, duga, Bill_Kasdorf, Tim_Cole, Garth,
16:23:07 <Zakim> ... JunGamo, -0
16:23:07 <Zakim> On IRC I see JunGamo, Bill_Kasdorf, timCole, duga, garth, josh, franco, marisa, George, BenSchroeter, laurent, Avneesh, geoffjukes, rkwright, dkaplan3, mateus, mgarrish, RRSAgent,
16:23:07 <Zakim> ... Zakim, ivan, wendyreid, tzviya, dauwhe, plinss_, astearns, github-bot, dmitry, florian[m], Travis, bigbluehat, jyasskin
16:23:17 <ivan> present+ avneesh
16:23:18 <dauwhe> ... waiting for feedback from media sync people
16:23:27 <dauwhe> wendyreid: does this impact sync media
16:23:35 <rkwright> present+ rkwright
16:23:41 <dauwhe> marisa: I don't think so... this is just properties of resources
16:23:58 <BenSchroeter> +1
16:24:00 <duga> Abstain (don't plan to use the value)
16:24:02 <dauwhe> ... this issue doesn't need to get more complicated
16:24:11 <ivan> resolved: The time length property (unnamed) will only use a float consisting of the number of seconds of the resource.
16:24:25 <dauwhe> ivan:  the other issue that came up is more controversial
16:24:43 <dauwhe> ... there may be a notion of duration of the whole audiobook
16:25:03 <dauwhe> ... it turned out that having that as book-level metadata is something that implementors may ignore
16:25:17 <dauwhe> ... they may deduce that from the individual resources
16:25:42 <dauwhe> ... but it may be helpful as a hint to the user, as a value in the catalog etc
16:25:55 <dauwhe> ... what I did, mostly to generate discussion, was to
16:26:08 <dauwhe> ... put a global property there, with the same format
16:26:30 <dauwhe> ... primarily defined for a user interface
16:26:40 <laurent> q+
16:26:41 <dauwhe> ... do we need this, or should we remove it from the PR doc?
16:26:46 <wendyreid> ack laurent
16:26:51 <gpellegrino> gpellegrino has joined #pwg
16:27:08 <dauwhe> laurent: I would say that the audiobook schema.org object supports the duration with ISO 8601
16:27:16 <dauwhe> ... it's there and it's optional, and it is what we want
16:27:23 <dauwhe> ... it's descriptive metadata
16:27:31 <dauwhe> ... we could just adopt this and move on
16:27:32 <ivan> +1 to laureng
16:27:41 <geoffjukes> +1 to laureng
16:27:51 <dauwhe> wendyreid: simple descriptive metadata
16:28:30 <wendyreid> Resolution: Schema.org's Duration will be a required metadata descriptor for audiobooks
16:28:35 <ivan> +1
16:28:42 <BenSchroeter> +1
16:29:15 <dauwhe> laurent: I thought the idea was to keep it optional, as in schema.org
16:29:30 <wendyreid> Resolution: Schema.org's Duration will be a recommended metadata descriptor for audiobooks
16:29:46 <laurent> and it's a 'duration' property (of type 'Duration')
16:29:48 <ivan> +1
16:29:52 <laurent> +1
16:29:55 <marisa> q+
16:30:03 <wendyreid> ack marisa
16:30:09 <dauwhe> marisa: is this a different property?
16:30:11 <dauwhe> ivan: yes
16:30:17 <geoffjukes> q+
16:30:25 <marisa> -1
16:30:28 <dkaplan3> +1
16:30:44 <timCole> +1
16:30:46 <josh> +1
16:30:46 <wendyreid> ack geoffjukes
16:30:47 <dauwhe> wendyreid: this is schema.org duration descriptor for audio book, the length of the entire work, the sum of all the parts
16:30:52 <laurent> see https://schema.org/Audiobook
16:30:53 <dauwhe> geoffjukes: it's not the same concept
16:31:06 <laurent> and https://schema.org/duration
16:31:13 <dauwhe> ... it might be the sum of all resources, but it might be different, for example if there's non-book audio resources
16:31:26 <ivan> +1  to geoffjukes
16:31:33 <geoffjukes> +1
16:31:37 <dauwhe> ... so it's ok to have a different name and format, and it's good for it to be in schema.org so it's universally digestable
16:32:06 <dauwhe> wendyreid: it would be called duration, it would be the total length of the book, provided by the publisher
16:32:43 <ivan> q+
16:32:46 <wendyreid> ack ivan
16:32:48 <dauwhe> dkaplan3: are we voting on making this required?
16:32:53 <dauwhe> ivan: there is a mess-up
16:32:59 <dauwhe> ... there are 2 things here
16:33:11 <dauwhe> ... one is, what is the global descriptive metadata, and what value it takes
16:33:35 <dauwhe> ... and the only resolution we are proposing is to use duration with ISO as in schema.org
16:33:47 <dauwhe> ... and then there's the question of whether this metadata item is required
16:33:55 <geoffjukes> +q
16:34:00 <wendyreid> ack geoffjukes
16:34:06 <dauwhe> geoffjukes: I would happy for it to be required
16:34:19 <dauwhe> ... we have to send it to our publishers/distributors
16:34:38 <dauwhe> wendyreid: when I said required I meant for the audiobook profile
16:34:40 <laurent> q+
16:34:44 <dauwhe> q+
16:34:44 <wendyreid> ack laurent
16:34:53 <dauwhe> laurent: q for geoffjukes. Why is it required?
16:35:06 <dauwhe> geoffjukes: when we send ONIX we include runtime
16:35:21 <dauwhe> ... and they like to cross-reference to check they make sure they got the right book
16:35:27 <wendyreid> ack dauwhe
16:35:40 <dauwhe> ... if it's not required we'll supply it anyway
16:36:25 <tzviya> +1 to limited metadata!
16:36:27 <wendyreid> dauwhe: The web platform requires very little metadata, we should require the important things (title, author), this does not seem like required metadata
16:36:33 <ivan> +1 to dauwhe
16:36:33 <wendyreid> ... I suggest we make it optional
16:36:35 <laurent> +1 to dauwhe
16:36:51 <dauwhe> wendyreid: for an audiobook it's almost as important as title
16:37:03 <dauwhe> ... for a user to understand what they're getting into
16:37:14 <ivan> q+
16:37:17 <dauwhe> ... to find out if it's abridged or unabridged
16:37:27 <dauwhe> ... or if my phone will keep it
16:37:33 <wendyreid> ack ivan
16:37:33 <dauwhe> ... I think it should be required
16:37:49 <dauwhe> ivan: there is no requirement to provide metadata for the number of book pages
16:38:01 <dauwhe> ... but the same argument applies, ish
16:38:17 <tzviya> q+
16:38:18 <dauwhe> ... I agree it is recommended
16:38:24 <dauwhe> ... but "must" is too far
16:38:34 <dauwhe> q+
16:38:40 <wendyreid> ack tzviya
16:38:44 <dauwhe> tzviya: I hate to prolong this discussion
16:39:05 <dauwhe> ... when we were deciding on EPUB metadata, lots of people said that title should be required
16:39:26 <dauwhe> ... but then you get into lots of nuance with what titles means, but most systems don't pay attention
16:39:48 <dauwhe> ... we should look into how systems work with information about length
16:39:57 <dauwhe> ... and how this will play out in the real world
16:40:27 <laurent> q+
16:40:30 <duga> q+
16:40:37 <wendyreid> ack dauwhe
16:40:39 <dauwhe> ... maybe the implementors can tell us more about this information is used
16:41:26 <wendyreid> dauwhe: It strikes me as many of the arguments for the utility of the information is about file size not chronological duration, this information can be useful, but requiring them is not traditionally how the web works
16:41:36 <wendyreid> ... we run into issues of validation
16:41:53 <wendyreid> ... are we then going to get to a point where validators takes the values and compares them
16:42:03 <wendyreid> ... requiring this is complicated
16:42:08 <wendyreid> ack laurent
16:42:23 <dauwhe> laurent: I agree on principle we shouldn't require descriptive metadata
16:42:41 <dauwhe> ... and we should keep properties required for user agent functioning or content identification
16:42:55 <dauwhe> ... so we should recommend this, underlining all the advantages of using this
16:43:00 <wendyreid> ack duga
16:43:31 <dauwhe> duga: when considering required metadata, we should ask if it's impossible to create a book without this metadata.
16:43:43 <dauwhe> ... if it's not impossible, we shouldn't require it
16:43:43 <ivan> q+
16:43:55 <wendyreid> ack ivan
16:44:02 <dauwhe> wendyreid: I'm OK with recommended, even though y'all are completely wrong :)
16:44:03 <Bill_Kasdorf> vendors can still require it
16:44:14 <dauwhe> ivan: we have 2 resolutions
16:44:33 <dauwhe> ... we never closed the previous resolution
16:45:02 <ivan> proposed: duration is a descriptive medata for wp, whose value is the ISO format (as used in schema.org). It is optional.
16:45:18 <ivan> +1
16:45:22 <timCole> +1
16:45:25 <laurent> +1
16:45:26 <Bill_Kasdorf> +1
16:45:26 <dkaplan3> +1
16:45:28 <geoffjukes> +1
16:45:30 <BenSchroeter> +1
16:45:32 <dauwhe> +1
16:45:33 <duga> +1
16:45:37 <garth> +1
16:45:38 <George> +1
16:45:44 <ivan> resolved: duration is a descriptive medata for wp, whose value is the ISO format (as used in schema.org). It is optional.
16:45:49 <josh> +1
16:46:13 <wendyreid> Proposed: Schema.org duration value is recommended metadata for the audiobooks profile
16:46:16 <ivan> +1
16:46:19 <laurent> +1
16:46:20 <marisa> +1
16:46:21 <timCole> +1
16:46:23 <Bill_Kasdorf> +1
16:46:24 <BenSchroeter> +1
16:46:31 <dkaplan3> +1
16:47:02 <ivan> resolved:  Schema.org duration value is recommended metadata for the audiobooks profile
16:47:07 <dauwhe> wendyreid: can we move on and never speak of this again?
16:47:09 <dauwhe> ivan: no
16:47:29 <dauwhe> ... I will make the edits according to the resolutions, is it OK to then merge?
16:47:42 <wendyreid> +!
16:47:44 <wendyreid> +1
16:47:48 <dauwhe> ... and then the PR and the issue can be closed then?
16:47:53 <dauwhe> everyone: YES
16:48:06 <wendyreid> https://github.com/w3c/wpub/issues/398
16:48:06 <laurent> we just need a name for the resource lever property ...
16:48:19 <ivan> topic: file hashes
16:48:48 <dauwhe> wendyreid: (sound of leaks from submarines)
16:49:28 <dauwhe> ... the issue is around file hashes, so content creators can provide identifiable hashes to individual resources
16:49:57 <dauwhe> ... the proposal is to use SRI
16:50:04 <ivan> q+
16:50:08 <wendyreid> ack ivan
16:50:18 <dauwhe> ivan: what term should I use
16:50:25 <laurent> q+
16:50:34 <dauwhe> ... this is not in schema, so we need to pick a term
16:50:36 <laurent> q-
16:50:38 <wendyreid> ack laurent
16:50:41 <dauwhe> q+
16:50:54 <wendyreid> dauwhe:
16:50:56 <garth> q+
16:51:00 <wendyreid> ack dauwhe
16:51:43 <wendyreid> dauwhe: Garth brought up the question of requirements on reading systems, it's a problem in RSs, EPUB has signatures but RSs don't always understand them
16:51:50 <duga> q+
16:52:01 <wendyreid> ... if an integrity hash is present, the UA must check it and terminate processing if it does not pass
16:52:02 <laurent> q+
16:52:04 <wendyreid> ack garth
16:52:19 <wendyreid> ack duga
16:52:44 <dauwhe> duga: hashes are great. If you want to pretend that these have anything to do with security or integrity I object.
16:52:57 <dauwhe> ... they do not provide this at all.
16:53:05 <dauwhe> ... they do not provide security.
16:53:06 <dauwhe> q+
16:53:08 <garth> q+
16:53:13 <wendyreid> ack laurent
16:53:30 <dauwhe> laurent: I agree with the objection about security. I think it says something about integrity.
16:53:55 <dauwhe> ... I'm worried that some user agents might not be able to deal with any algo that is expressed
16:54:02 <dauwhe> ... is there a closed list of algos?
16:54:10 <wendyreid> ack dauwhe
16:54:26 <wendyreid> dauwhe: Can someone educate me as to why the SRI spec exists?
16:54:29 <ivan> q+
16:55:08 <dauwhe> ivan: the big difference between SRI on HTML is that it is mainly used for the JS you bring in when you use external JS
16:55:09 <wendyreid> ack ivan
16:55:22 <dauwhe> ... I can't really answer brady's concerns
16:55:23 <geoffjukes> q+
16:55:50 <dauwhe> ... if I trust what I get from a URL as JS, has the same hash that I expected, then I can believe it's the correct JS
16:56:10 <wendyreid> ack garth
16:56:10 <dauwhe> ... but it may be different for audio files
16:56:29 <wendyreid> ack geoffjukes
16:56:31 <dauwhe> garth: I was going to disagree with Dave. I have no objection to this, but don't want user agents to have to deal with this.
16:56:57 <dauwhe> geoffjukes: it's doesn't provide security or integrity. we use it to communicate to our apps that a file was downloaded completely.
16:57:12 <dauwhe> ... we just use it to detect bad downloads.
16:57:26 <garth> q?
16:57:33 <dauwhe> wendyreid: do we want to include this?
16:57:52 <geoffjukes> q+
16:57:59 <wendyreid> ack geoffjukes
16:58:02 <dauwhe> ivan: how important is this?
16:58:36 <dauwhe> geoffjukes: our apps rely on this utterly. we deliver to cellphones. Not evveryone has 5G. We have to deal with unreliable delivery. We're OK with this in the spec and optional.
16:58:41 <dauwhe> .... we *will* use this
16:59:17 <dauwhe> wendyreid: this sounds like something that a distributor/reading system can handle on its own
16:59:28 <garth> q?
16:59:40 <dauwhe> ... perhaps we ask other distributors/UAs?
16:59:50 <dauwhe> ivan: isn't that the definition of an optional thing?
16:59:57 <dauwhe> ... we know someone uses it.
17:00:04 <dauwhe> ... is it important to have a standard format?
17:00:18 <ivan> proposed: add the optional integrity property for linked resources, using the subresource integrity format
17:00:25 <dauwhe> wendyreid: let's add it as optional
17:00:27 <wendyreid> +1
17:00:28 <garth> +1
17:00:31 <duga> +1
17:00:31 <geoffjukes> +1
17:00:33 <laurent> +1
17:00:37 <ivan> +1
17:00:39 <Bill_Kasdorf> +1
17:00:42 <tzviya> +1 (i think)
17:00:48 <josh> +1
17:00:50 <timCole> +1
17:01:02 <ivan> resolved: add the optional integrity property for linked resources, using the subresource integrity format
17:01:14 <geoffjukes> thanks everyone
17:01:21 <dkaplan3> dkaplan3 has left #pwg
17:01:28 <JunGamo> JunGamo has left #pwg
17:01:32 <ivan> rrsagent, draft minutes
17:01:32 <RRSAgent> I have made the request to generate https://www.w3.org/2019/04/15-pwg-minutes.html ivan
17:01:32 <ivan> zakim, bye
17:01:32 <ivan> rrsagent, bye
17:01:32 <RRSAgent> I see no action items
17:01:32 <Zakim> leaving.  As of this point the attendees have been ivan, tzviya, dkaplan, mateus, george, dauwhe, wendyreid, mgarrish, gpellegrino, BenSchroeter, laurent, Avneesh, marisa, franco,
17:01:32 <Zakim> Zakim has left #pwg
17:01:35 <Zakim> ... josh, duga, Bill_Kasdorf, Tim_Cole, Garth, JunGamo, -0, rkwright, !