15:36:22 <RRSAgent> RRSAgent has joined #did
15:36:22 <RRSAgent> logging to https://www.w3.org/2019/12/17-did-irc
15:36:23 <ivan> rrsagent, set log public
15:36:23 <ivan> Meeting: DID Working Group Telco
15:36:23 <ivan> Chair: burn
15:36:23 <ivan> Date: 2019-12-17
15:36:23 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/0015.html
15:36:23 <ivan> ivan has changed the topic to: Meeting Agenda 2019-12-17: https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/0015.html
15:53:03 <burn> burn has joined #did
15:53:17 <burn> present+
15:54:03 <TallTed> TallTed has joined #did
15:54:35 <ChristopherA> present+
15:57:59 <ivan> present+
15:59:10 <mike-lodder> mike-lodder has joined #did
15:59:13 <phila> phila has joined #did
15:59:42 <TallTed> present+
16:00:19 <dmitriz> dmitriz has joined #did
16:00:20 <phila> present+
16:00:31 <dmitriz> present+
16:00:32 <daniel> daniel has joined #did
16:00:38 <Justin_R> Justin_R has joined #did
16:00:55 <dlongley> present+
16:00:59 <mike-lodder> present+
16:01:18 <yancy> present+
16:01:24 <gannan> present+
16:01:31 <rhiaro> present+
16:01:38 <Orie> Orie has joined #did
16:01:40 <Orie> present+
16:01:45 <rhiaro> scribe+ dmitriz
16:01:47 <dmitriz> scribe+ dmitriz
16:01:48 <agropper> agropper has joined #did
16:01:52 <burn> Topic: Agenda Review, Introductions, Re-introductions
16:02:05 <dezell> dezell has joined #did
16:02:08 <agropper> present+
16:02:10 <markus_sabadello> markus_sabadello has joined #did
16:02:13 <Irene_Jolocom> Irene_Jolocom has joined #did
16:02:16 <selfissued> selfissued has joined #did
16:02:19 <dezell> present+
16:02:20 <dmitriz> burn: Agenda today - announcements, JSON/JSON-LD discussion for a few mins,
16:02:25 <chriswinc> present+
16:02:31 <dmitriz> … then move into the meat of the meeting - discussion of matrix params
16:02:40 <daniel> present+
16:02:45 <drummond> drummond has joined #did
16:02:46 <dmitriz> … because we were making good progress before (talking about their dimensions etc)
16:02:52 <drummond> present+
16:02:53 <dmitriz> … then we'll move to discussion of Metadata
16:03:05 <brent> brent has joined #did
16:03:08 <dmitriz> … and if we end up with time, will work on additional unrelated PRs
16:03:11 <dmitriz> … any requests?
16:03:14 <ChristopherA> q+ on hold the date for rwot
16:03:16 <selfissued> present+
16:03:17 <JoeAndrieu> JoeAndrieu has joined #did
16:03:23 <daniel> Markus: again on Slack yesterday, someone was arguing that any use of a Matrix parameter changes the entire DID of the string
16:03:44 <dmitriz> Irene_Jolocom: <question about Amsterdam logistics>
16:03:52 <daniel> I have literally heard this and the opposite by 5 different people now
16:03:54 <daniel> which is it?
16:04:00 <ivan> present+ Irene_Jolocom
16:04:02 <dmitriz> burn: there's a link to detailed logistics for the f2f off the Meetings page of the WG
16:04:08 <brent> present+
16:04:13 <daniel> Would putting a value in a param after the DID Suffix change the DID itself, or not?
16:04:18 <Justin_R> present+
16:04:22 <selfissued> Please post the meetings link to this chat
16:04:26 <dmitriz> burn: introductions? anyone joining us for the first time?
16:04:31 <phila> q+
16:04:32 <Justin_R> https://www.w3.org/2019/did-wg/Meetings/F2F/2020.01.Amsterdam
16:04:40 <dmitriz> … ok, re-introductions!
16:04:51 <manu> present+
16:04:56 <dmitriz> … ok, how about Amy (rhiaro)
16:05:00 <phila> q-
16:05:16 <dmitriz> … also this is a good opportunity for you to mention the other ways of getting to the f2f
16:05:24 <dmitriz> rhiaro: hi, I'm amy, working with Digital Bazaar
16:05:27 <phila> q+
16:05:34 <ChristopherA>  I will be Amsterdam a week earlier - any ssi meetupds.
16:05:42 <dmitriz> … other ways to get to the f2f - Europe is very well connected, so this is a great opportunity for trains/buses/ferries
16:05:52 <dmitriz> … if anyone wants help planning that / do that instead of flying, let me know
16:06:06 <burn> Amy is very modest - she is well-known for great standards work at W3C
16:06:12 <drummond> Hooray for Amy!
16:06:13 <dmitriz> … and if you're interested in coming from the US by ship (freighter), I know a couple websites
16:06:15 <JoeAndrieu> present+
16:06:29 <dezell> present+
16:06:31 <burn> ack ChristopherA
16:06:31 <Zakim> ChristopherA, you wanted to comment on hold the date for rwot
16:06:43 <jonathan_holt> jonathan_holt has joined #did
16:06:50 <burn> ack phila
16:06:56 <jonathan_holt> present+ jonathan_holt
16:06:57 <burn> q+ ChristopherA
16:07:02 <dmitriz> phila: I don't see any reference to remote participation, for the f2f
16:07:14 <dmitriz> burn: I'm awaiting reply on that, from our hosts
16:07:20 <burn> q?
16:08:03 <burn> Topic: Announcements
16:08:19 <dmitriz> burn: we need you to get your issues in
16:08:30 <dmitriz> … the Editors will be spending the next week or two looking at issues / PRs, trying to classify them
16:08:45 <dmitriz> … so if you have outstanding issues for the spec, please do get them in
16:09:04 <burn> F2f signup/topics: https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0
16:09:07 <dmitriz> … related to that, there is a page (link in the agenda), there is a doc both for signing up for the f2f, and requesting agenda topics
16:09:16 <dmitriz> … so there's two tabs, attendees and Agendas
16:09:35 <dmitriz> … on the Agenda tab, don't fill in particular time slots, but add stuff to the yellow area (topics you'd like covered for the f2f)
16:09:56 <dmitriz> … the discussion about JSON / abstract data model WILL be on the agenda, no worries
16:10:02 <dmitriz> … one other thing that we wanted to bring up is that
16:10:13 <dmitriz> … we have our f2f meeting in Jan. Our WG will meet at TPAC in Sepct
16:10:21 <dmitriz> s/Sepct/Sept/
16:10:23 <rhiaro> Do we know where tpac is?
16:10:34 <dmitriz> … so there is an opportunity to schedule another face to face, between that
16:10:42 <dmitriz> … there is an Advisory Committee in May, in Seoul
16:10:54 <dmitriz> … quick show of hands - anybody interested in a may f2f, in Seoul?
16:11:00 <drummond> Maybe
16:11:02 <Orie> :(
16:11:03 <Justin_R> IIW is in March and October
16:11:07 <burn> STRAW POLL: interest in May f2f in Seoul?
16:11:11 <dmitriz> … IIW would be easier, but it's in March, too close to the previous one
16:11:16 <dezell> +1
16:11:17 <ivan> +1
16:11:18 <drummond> 0
16:11:21 <manu> -1, I won't be going to AC meeting :(
16:11:21 <markus_sabadello> q+
16:11:22 <yancy> +1
16:11:22 <selfissued> +1
16:11:24 <phila> -1
16:11:25 <JoeAndrieu> -1
16:11:25 <dmitriz> -1
16:11:26 <Orie> -1
16:11:27 <selfissued> But what specific dates in May???
16:11:27 <TallTed> +0
16:11:34 <brent> 0
16:11:35 <rhiaro> +0
16:11:41 <ken> ken has joined #did
16:11:44 <selfissued> When is the AC meeting?
16:11:45 <markus_sabadello> IIW is end of April, not March
16:11:54 <ken> present+
16:11:55 <markus_sabadello> q-
16:11:59 <Orie> ^ IIW would be better
16:12:02 <ivan> AC meeting days: 18-19 May
16:12:10 <phila> +1 for IIW in late April
16:12:12 <dmitriz> burn: ok, I'm getting enough of a sense, not overwhelming strong support
16:12:19 <drummond> IIW is April 28-30 in Mountain View
16:12:20 <Justin_R> +1 for post-IIW
16:12:25 <dmitriz> … so May / Korea is not looking great. will consider other options
16:12:26 <selfissued> q+
16:12:37 <dmitriz> … (and yes, will ask this again on the other time zone call)
16:12:42 <dmitriz> ChristopherA: two things
16:12:43 <burn> ack ChristopherA
16:13:00 <dmitriz> … firstly, hold the date for IIW, Mar 16-20th, for Buenos Aires, for the next Rebooting Web of Trust
16:13:18 <dmitriz> … this is our first Southern Hemisphere RWoT, trying to attract some of the dev communities in the central & south americas
16:13:19 <burn> s/IIW/RWOT/
16:13:32 <dmitriz> … tentatively holding the RWoT date for Singapore, for Sept
16:13:46 <dmitriz> … so if you're interested in that area of the world, that's a good opportunity
16:13:47 <daniel> Will there ever be another RWOT anywhere within 4-5 hours of the West coast of the US?
16:13:54 <daniel> Just wondering
16:14:04 <daniel> I may want to go again
16:14:11 <ivan> q+
16:14:19 <daniel> I am only asking for something literally 5 hours in any direction
16:14:21 <dmitriz> … finally, I will be at the gathering at the end of Jan, in Amsterdam - I'll be there a week early, and will stay a week late. hoping to attend a few SSI meetups in a few places, maybe Berlin's meetup
16:14:35 <dmitriz> … so if you have interest in joining me or meeting with me, let me know
16:14:40 <burn> ack selfissued
16:15:07 <dmitriz> selfissued: the answers to the interim meeting question depends on whether it's Korea or IIW
16:15:19 <dmitriz> burn: right, the straw poll was specifically for Korea
16:15:27 <dmitriz> … the IIW one or others will be separate polls
16:15:49 <burn> q?
16:15:52 <burn> ack ivan
16:15:54 <dmitriz> … any other announcements?
16:16:21 <dmitriz> ivan: question about Buenos Aires. Do you have any more details on the rough agenda? As in, when to fly in, etc?
16:16:31 <dmitriz> ChristopherA: It is a full week.
16:16:48 <dmitriz> … doesn't start until the evening of the first day, Monday. So, I imagine it's ok for ppl to arrive then
16:16:55 <kdenhartog> kdenhartog has joined #did
16:16:58 <dmitriz> … it tends to go through a full day on Fri, so most people leave on Sat
16:17:20 <dmitriz> … JoeAndrieu is working on the EventBrite
16:17:26 <dmitriz> … we'll be in the center of town
16:17:28 <dmitriz> … hotel-wise
16:17:46 <dmitriz> burn: RWoT should be able to provide additional info on hotel options and logistics
16:17:51 <dmitriz> burn: anything else on announcements?
16:17:57 <burn> Topic: JSON/JSON-LD Abstract data model - arrange special call
16:18:07 <dmitriz> Topic: JSON/JSON-LD
16:18:23 <dmitriz> burn: the chairs are very aware of this discussion
16:18:25 <manu> s/Topic: JSON/JSON-LD/Topic: JSON/JSON-LD Abstract Data Model/
16:18:40 <dmitriz> … I have several comments. One, we've been following this very closely, and are very aware of the discussion thread.
16:18:50 <dmitriz> … we've heard people are wondering what the chairs are waiting for here, why not force a vote now
16:19:04 <dmitriz> … the Chairs are waiting for Proposals. and by that we mean, text.
16:19:13 <dmitriz> … we're not in incubation spec here, we're in the WG.
16:19:31 <dmitriz> … so we're not looking for vague proposals. We need a PR, or a similar document with concrete text.
16:20:01 <dmitriz> … the text doesn't have to be perfect, it can contain stubs, and so on. But it has to be concrete.
16:20:12 <jonathan_holt> q+
16:20:13 <dmitriz> … only then can we call for a vote, to merge a PR into the document, even as working text.
16:20:30 <dmitriz> … standards work is done by those that do the work. Manu is not the only one who's allowed to do PRs; anybody can do them.
16:20:39 <dmitriz> … if you have trouble, let us know, we can help.
16:20:52 <dmitriz> … if you don't like the discussion that is happening on a PR, you're not stuck with it, you can write a competing one.
16:21:22 <dmitriz> … second point. I think most of you are aware that the recent giant discussion thread on a PR has been locked by an editor
16:21:37 <dmitriz> … we want to remind everyone that issue locking takes more than one editor; we're continuing discussion with chairs on that.
16:21:48 <dmitriz> … however, we firmly believe that everyone has been acting in good faith.
16:21:57 <dmitriz> … to put it bluntly: please stop accusing others of acting in bad faith.
16:22:09 <dmitriz> … doesn't help conversation. If you think that a PR is not going the way you want, write a new one.
16:22:24 <dmitriz> … the Chairs do not consider a PR a decision, until the group actually agrees.
16:22:36 <dmitriz> … third point: we expect to spend major discussion time on this at the Face to Face meeting.
16:22:51 <dmitriz> … just to be clear, we've always understood from the beginning, that there's a Data Model, and separately, Syntactic Realizations
16:23:00 <dmitriz> … so we're waiting on concrete text on those.
16:23:14 <dmitriz> … so yes, we'll be discussing this at the f2f. Of course, proposals in advance do help.
16:23:21 <dmitriz> … we will be also scheduling calls about this, before the f2f.
16:23:27 <dmitriz> … beginning in January, post-holidays.
16:23:39 <dmitriz> … the intent of those calls will be to determine the relevant factors necessary for the discussion
16:23:55 <dmitriz> … this includes things like - if we have a JSON format and a JSON-LD format, how much interop will there be, or we wish to encourage?
16:24:06 <ivan> zakim, who is here?
16:24:06 <Zakim> Present: burn, ChristopherA, ivan, TallTed, phila, dmitriz, dlongley, mike-lodder, yancy, gannan, rhiaro, Orie, agropper, dezell, chriswinc, daniel, drummond, selfissued,
16:24:09 <Zakim> ... Irene_Jolocom, brent, Justin_R, manu, JoeAndrieu, jonathan_holt, ken
16:24:09 <Zakim> On IRC I see kdenhartog, ken, jonathan_holt, JoeAndrieu, brent, drummond, selfissued, Irene_Jolocom, markus_sabadello, dezell, agropper, Orie, Justin_R, daniel, dmitriz, phila,
16:24:11 <Zakim> ... mike-lodder, TallTed, burn, RRSAgent, Zakim, gannan, ivan, tzviya, hadleybeeman, chriswinc, dlehn, dlongley, manu, deiu, yancy, ChristopherA, Travis, jfishback, bigbluehat,
16:24:11 <Zakim> ... rhiaro
16:24:16 <dmitriz> burn: there have been statements about "if you have an @context, it will have such & such problem" and others saying opposite.
16:24:35 <dmitriz> … so, the intent of these pre-calls is not to make final decisions, but to see if we can come up with a set of factors for us to consider at the f2f
16:24:52 <burn> q?
16:24:55 <dmitriz> … we will be sending out a doodle poll to schedule those calls, 1st / 2nd week of Jan, so look for that
16:25:05 <dmitriz> … brent, anything to add?
16:25:25 <dmitriz> brent: Just to reiterate, the January calls are not to come to consensus. It's to come up with consensus criteria.
16:25:35 <burn> ack jonathan_holt
16:25:35 <dmitriz> burn: any clarification questions?
16:25:58 <dmitriz> jonathan_holt: just to point out, I had a PR in Barcelona last year, about IPLD, to go alongside / on top of JSON-LD
16:26:03 <dmitriz> … and it came down to an issue of MIME types
16:26:23 <dmitriz> … I made the PR, and it got shelved (because I didn't get it in on time, before the closed date), and now it seems to be gone.
16:26:44 <dmitriz> … so, I've been working on - once we get the MIME type thing worked out - on how to transform it to JSON-LD
16:27:19 <dmitriz> burn: please open a new issue / PR.
16:27:26 <dmitriz> … unless the PR was discussed and nobody was interested.
16:27:38 <burn> q?
16:27:38 <dmitriz> … so, usually our policy is not to close things unless there is consensus.
16:27:53 <burn> Topic: Matrix Parameters
16:27:56 <brent> https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix
16:28:05 <manu> q+
16:28:14 <markus_sabadello> q+
16:28:15 <manu> q+ to provide info to jonathan_holt
16:28:16 <dmitriz> burn: ok, on to Matrix Parameters.
16:28:45 <manu> q- later
16:28:45 <selfissued> The key issue is https://github.com/w3c/did-core/issues/137
16:28:48 <dmitriz> … which of the editors would like to lead this discussion?
16:29:00 <selfissued> q+
16:29:04 <manu> q- manu
16:29:04 <jonathan_holt> found it: https://github.com/w3c/did-core/issues/92
16:29:13 <dmitriz> markus_sabadello: we've talked about Matrix Params a few types
16:29:21 <dmitriz> s/few types/few times/
16:29:21 <burn> https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix
16:29:24 <daniel> Can someone DEFINITIVELY answer whether or not adding a Matrix param changes what the actual DID is?
16:29:26 <manu> jonathan_holt, yes --- it wasn't summarily closed... we converted it into an issue, which is still open (and waiting on you)
16:29:34 <manu> q?
16:29:43 <markus_sabadello> https://github.com/w3c/did-core/pull/144/
16:29:44 <dmitriz> markus_sabadello: one piece of feedback that we've received is - there is not enough guidance for WHEN matrix parameters should or should not be used
16:29:49 <brent> ack markus_sabadello
16:29:49 <dmitriz> … I've added a clarifying language PR
16:30:10 <dmitriz> … there's also a green Note box in the spec, bookmarking this
16:30:20 <dmitriz> … so let's give a quick summary
16:30:40 <dmitriz> … When you use Matrix Params, you are creating a NEW identifier.
16:30:53 <dmitriz> … the PR also explains that matrix params are not the only way to influence DID resolution & de-referencing,
16:31:00 <dmitriz> … there's also the ability to pass query params to a DID Resolver
16:31:23 <dmitriz> … and explains how in HTTP, you can make a decision whether to pass parameters as part of the http URL, or in http headers
16:31:40 <ivan> -> The new text by Markus https://pr-preview.s3.amazonaws.com/w3c/did-core/pull/144.html#generic-did-parameter-names
16:31:41 <burn> q?
16:31:54 <dmitriz> … so, DID params should be used when there is a clear use case when the param should be part of the URI - to be included in other JSON / JSON-LD documents
16:32:01 <daniel> q+
16:32:23 <dmitriz> … also provides guidance for when DID Parameters (our alias for Matrix Parameters) should NOT be used
16:32:53 <dmitriz> … for instance, we recently closed a PR for a 'key' matrix param, since we have url fragments to accomplish the same mechanism, so we don't need a second one
16:33:25 <dmitriz> … also, this PR provides a second guidance on when they shouldn't be used — that's when the same thing can be accomplished by passing headers to the resolver (caching, format / content negotiation)
16:33:32 <brent> q?
16:33:40 <dmitriz> … so, please review the PR, propose additions and changes
16:33:46 <kdenhartog> present+
16:33:50 <jonathan_holt> manu, not accusing any one of burying it... and i do appreciate you filing the issue to keep it alive.  Just taking me a while to architect it properly, which is now dependent on MIME type discussion.
16:34:03 <phila> q+ to ask for usage scenario, given other options
16:34:10 <dmitriz> selfissued: I think we'd agreed on the last call that we would track the issue of whether there should be matrix parameters at all, in issue 137
16:34:17 <burn> s/The key issue is/The key JSON etc issue is/
16:34:22 <dmitriz> … so, we need to decide if they should exist at all, before specifics
16:34:22 <manu> jonathan_holt, ack, sounds good... just wanted you to know that we didn't close it :)
16:34:22 <burn> ack daniel
16:34:26 <burn> ack selfissued
16:34:27 <dmitriz> daniel: clarifying question to markus.
16:34:48 <dmitriz> … the whole reason I was using matrix params is - I must be able to add some values for a DID that are temporary
16:34:56 <dmitriz> … to be discarded later, to be used for the purposes of resolution
16:34:56 <drummond> q+
16:35:00 <markus_sabadello> q+
16:35:02 <dmitriz> … I dont want these to change the URL
16:35:12 <dmitriz> … just like query params do not change the authority/path of the URL
16:35:17 <burn> ack phila
16:35:17 <Zakim> phila, you wanted to ask for usage scenario, given other options
16:35:24 <dmitriz> … so, are matrix params appropriate for this use case or not?
16:35:27 <burn> ack drummond
16:35:28 <dmitriz> phila: I had the same question
16:35:42 <dmitriz> drummond: the answer, based on the work we've done on matrix params, is that it's very similar to the example you just used
16:35:57 <dmitriz> drummond: the DID always identifies the DID Subject. that is unchanged.
16:36:12 <dmitriz> … the Matrix Param does change the Resource identified by the overall url
16:36:31 <phila> q+
16:36:31 <dmitriz> … as I've watched the discussion around the Initial Values param, my initial take as an editor was - that's fine, you're not changing the resource identified
16:36:32 <dmitriz> q+
16:36:44 <dmitriz> … I think of it as a temporal param, somewhat similar to a version
16:36:54 <selfissued> q+
16:37:06 <dlongley> q+
16:37:10 <dmitriz> … I want to reinforce - the intent of Matrix Params is never to change the subject identified by the DID
16:37:22 <dmitriz> … but like anything else, if you add a path, that changes the resource
16:37:27 <daniel> q+
16:37:47 <dmitriz> burn: queue is growing really fast, we were hoping this would be a shorter discussion.
16:37:56 <dmitriz> … closing the queue for the moment.
16:37:58 <burn> zakim, close the queue
16:37:58 <Zakim> ok, burn, the speaker queue is closed
16:38:01 <burn> ack markus_sabadello
16:38:09 <dmitriz> markus_sabadello: to answer Daniel, the proposed Initial Values param makes sense, I'm personally in favor of it
16:38:14 <daniel> My only follow-up would be: thank you Drummond - in light of this, should I use a generic param for this, given multiple methods use it the same way, or a bunch of method-specific ones that do the same thing
16:38:15 <daniel> ?
16:38:29 <dmitriz> … adding matrix param could change the resource identified, as in the case of a service param
16:38:40 <daniel> correct
16:38:43 <dmitriz> … in teh case of initial values, it doesn't change the DID Subject identifier, so that's fine,
16:38:53 <burn> q?
16:39:02 <ivan> s/teh/the/
16:39:09 <dmitriz> … to answer Mike, yes, it's valid to have that discussion on whether we want matrix params at all
16:39:21 <dmitriz> … I dont recall which issue that should be in.
16:39:33 <burn> ack phila
16:39:48 <dmitriz> phila: I'm in danger of asking a question that's been answered before
16:40:02 <dmitriz> … If you didn't have matrix params, would you not just use a Query param string?
16:40:15 <dmitriz> … looking at Tim's original matrix param proposal, there was a lot of mechanisms in there
16:40:39 <dmitriz> … so, imagine if matrix params didn't exist. would you re-invent them, or use existing mechanisms (query params)
16:40:42 <burn> ack dmitriz
16:40:46 <dmitriz> burn: yeah, there's been a lot of ddiscussion
16:41:01 <ivan> scribe+ manu
16:41:02 <markus_sabadello> yes this is a good question, perhaps we should add an info box to the spec explaining this
16:41:17 <manu> dmitriz: I also wanted to ask a similar question... are there any reasons why you cannot use a query param for the initial value.
16:41:19 <daniel> I could
16:41:22 <manu> s/value./value?/
16:41:26 <daniel> I just want to know the thing to do
16:41:28 <manu> dmitriz: Why not just use query parameters?
16:41:39 <daniel> need to stick some crap on the DID, don't care about the vehicle for the crap
16:42:05 <daniel> could be a crap truck, crap car, just need me some crap
16:42:10 <burn> dmitri that is not correct.  The DID Document is not the resource
16:42:13 <burn> q?
16:42:16 <burn> ack selfissued
16:42:17 <manu> dmitriz: I want to push back on what Drummond said about DID subject... especially in the case of service parameters, when you add one, it fundamentally points to a different resource... it's somewhat misleading to say that the bare DID identifies the subject... what the DID subject is is meaningless (in the case of services) because it's a link to a binary resource.
16:42:35 <dmitriz> selfissued: we owe it to ourselves to understand how we can use query params and fragments to solve all these use cases
16:42:50 <manu> I agree with daniel's use case can be solved w/ query parameters.
16:42:50 <dmitriz> … even if that means dedicating / reserving particular query or fragment params for those purposes
16:42:56 <drummond> @phila it is a good question and it has been a long discussion. The short very high level answer is that if we use query parameters, we step on the ability of developers to control the complete query string.
16:43:04 <phila> +1 to selfissued
16:43:04 <dmitriz> … that seems far more preferable, than having to write / modify URL parsers, to handle semicolons
16:43:06 <daniel> +1 to that
16:43:06 <Orie> +1 i dislike non standard url parsing...
16:43:11 <yancy> +1 to dedicated query parms instead of introducing a non standard url parser
16:43:29 <manu> +1 *if* we do it right...
16:43:29 <dmitriz> … meta-comment to phila — I wasn't in the CCG either. but, a WG is a whole new thing, totally fine to re-ask questions.
16:43:48 <burn> ack dlongley
16:43:53 <dmitriz> burn: of course, ok to re-ask questions. I was just pointing out that there has been extensive discussion on this
16:43:58 <burn> q?
16:44:09 <dmitriz> dlongley: I think I've been mostly persuaded by Mike's/selfissued's perspective on this
16:44:23 <dmitriz> … as in, why can't we just use query params
16:44:40 <dmitriz> … and the reasons FOR them has been to cleanly separate spaces / concerns
16:44:56 <dmitriz> … as far as I can tell, we're basically whittling things down to Service redirection
16:45:23 <dmitriz> … servers that are using service links will need to be aware of this mechanism anyways,
16:45:34 <dmitriz> … so there isn't quite a reason to shy away from query params for this purpose
16:45:46 <dmitriz> … I'm also persuaded by the argument of - we wouldn't have to modify URL parsers
16:45:58 <burn> ack daniel
16:46:01 <dmitriz> … so in short, our use cases CAN be satisfied by query params. It won't be as clean, but not so bad.
16:46:07 <dmitriz> daniel: ok, so, just to confirm
16:46:25 <dmitriz> … the initial use case could be addressed by EITHER matrix params or query params,
16:46:32 <dmitriz> … I'm happy to just use query params and close this out
16:46:34 <burn> zakim, open the queue
16:46:34 <Zakim> ok, burn, the speaker queue is open
16:46:49 <dmitriz> burn: we were hoping we could make some progress on a specific answer
16:46:59 <dmitriz> … since this is clearly going to exceed the bounds of our call today
16:47:15 <dmitriz> … we'd like to plan to schedule this for another discussion on matrix params. probably a separate call.
16:47:28 <dmitriz> … also, we'd like to make some progress on Metadata.
16:47:34 <dmitriz> … so lets switch to that
16:47:37 <burn> Topic: metadata
16:47:51 <manu> q+
16:47:54 <brent> https://github.com/w3c/did-core/labels/metadata
16:47:56 <burn> ack manu
16:48:02 <dmitriz> manu: at the end of last weeks' call,
16:48:14 <dmitriz> … we almost got to consensus on - there's 3 buckets of metadata
16:48:26 <dmitriz> … 1) controller-asserted meta, 2) resolver-asserted meta, and 3) ledger-asserted meta
16:48:37 <dmitriz> … when we were talking about 'created' timestamp, we were specifically talking about Controller-asserted metadata
16:48:48 <JoeAndrieu> q+
16:48:52 <dmitriz> … and at the end, on the straw poll, JoeA had a -1 on that
16:48:57 <dmitriz> … so, I want to understand why
16:48:59 <burn> ack JoeAndrieu
16:49:16 <dmitriz> JoeAndrieu: because that is the only place that the controller can specify when it was created
16:49:16 <oliver> oliver has joined #did
16:49:25 <oliver> present+
16:49:29 <dmitriz> q+
16:49:44 <burn> ack dmitriz
16:50:12 <dmitriz> dmitriz: that's very close to what the straw poll was proposing
16:50:16 <dmitriz> manu: let me clarify
16:50:25 <dmitriz> … the proposal was: let's experiment with this in the did:web method;
16:50:39 <dmitriz> … if we find it's generally applicable, we can pull it into the core DID spec
16:50:59 <dmitriz> … the other option is - we try it out on the core DID spec, and agree on whether other methods will want that feature
16:51:14 <dmitriz> … so, the proposal is - let's kick it over to did:web for now
16:51:21 <burn> q?
16:51:34 <dmitriz> JoeAndrieu: I'm not sure we should take it out
16:51:55 <dmitriz> manu: counter-proposal. We clarify that 'created' and 'updated' are specifically controller asserting when the /document/ was created or updated
16:52:01 <dmitriz> … so we at least clarify the semantics, to avoid confusion
16:52:08 <Justin_R> +1 to clear, narrow semantics
16:52:09 <dlongley> i still think it's mismodeled, it's a statement about the DID subject right now, i would -1 that change to change the meaning without remodeling it
16:52:11 <dmitriz> … if anyone wants to, we can argue about whether it's a useful general feature
16:52:13 <dlongley> -1
16:52:17 <dlongley> q+
16:52:19 <dmitriz> JoeAndrieu: I can support that.
16:52:22 <dmitriz> manu: any objections?
16:52:22 <burn> ack dlongley
16:52:37 <dmitriz> dlongley: I consider it a statement about the DID Subject right now. If we change the meaning
16:52:39 <dmitriz> q+
16:52:42 <JoeAndrieu> q+
16:52:44 <burn> ack dmitriz
16:53:02 <dlongley> q+
16:53:03 <TallTed> "a DID about a thing" doesn't make sense. a DID *identifies* a thing. a DID *document* is about a thing.
16:53:05 <drummond> @dlongley: can we do that just by changing the name of the property?
16:53:09 <Justin_R> +1 to clear, narrow names
16:53:11 <rhiaro> scribe+ rhiaro
16:53:12 <rhiaro> dmitriz: we have consensus we're only talking about document-created and document-upated. If the name is confusing, let's rename it
16:53:15 <dlongley> insufficient to just change the name
16:53:19 <burn> ack JoeAndrieu
16:53:39 <dmitriz> JoeAndrieu: +1 to changing name to clarify
16:53:43 <dlongley> didDocument.created, didDocument.updated would be fine with me, it's a separate object
16:53:52 <dlongley> but not just longer names
16:53:55 <dmitriz> … dlongley and I are at distinct odds about whether the subject of the DID is the subject of all the statements in the doc
16:53:55 <burn> q?
16:54:12 <dmitriz> … I feel quite strongly that - what's in the DID Document is /how you interact/ with the subject, not statements /about/ the subject
16:54:22 <burn> ack dlongley
16:54:22 <dmitriz> … because that latter is what VCs are.
16:54:30 <dmitriz> dlongley: I would object to making longer names
16:54:41 <dmitriz> … if we want to embed another object in there, that's ok
16:54:45 <Justin_R> q+
16:54:47 <dmitriz> … but that's my modeling concern
16:54:54 <burn> ack Justin_R
16:54:58 <TallTed> DIDCreated, DIDDocCreated, DIDRegEntryCreated...
16:54:58 <dmitriz> … I want to separate statements about DID Subj and metadata about it
16:55:01 <Orie> +1 to object encapsulation
16:55:15 <dmitriz> Justin_R: just to clarify, if we had a "_document" property or whatever, for metadata,
16:55:29 <burn> q?
16:55:33 <dlongley> q+
16:55:38 <dmitriz> … two questions - one, would you be OK with that, and two, would the group consider it to be able to be queryable from multiple metadata locations
16:55:43 <drummond> +1 to make a clear distinction between statements describing the DID subject and statements describing the DID document.
16:55:50 <drummond> q+
16:55:58 <burn> zakim, close the queue
16:55:58 <Zakim> ok, burn, the speaker queue is closed
16:56:02 <manu> q+
16:56:25 <dmitriz> … what I mean is - if you get that property in the document itself,
16:56:41 <burn> q?
16:56:41 <dmitriz> … can you ask the DID Resolver to hand that section to you in addition to the resolver/method meta
16:57:05 <dmitriz> … basically, can we pull this out and re-use it for resolver results
16:57:09 <burn> ack dlongley
16:57:16 <dmitriz> dlongley: the short answer is - I think you're heading in the right direction, to resolve my concerns
16:57:20 <daniel> My last month of aimless URL/Matrix wandering, crying out for a final answer, in one image: https://giphy.com/gifs/hr9SUKNQYgEcLykKjp/fullscreen
16:57:25 <dmitriz> … lots of bikeshedding is in order, but this is the right direction
16:57:30 <burn> ack drummond
16:57:32 <manu> q+
16:57:45 <burn> zakim, open the queue
16:57:45 <Zakim> ok, burn, the speaker queue is open
16:57:46 <manu> q+
16:57:46 <burn> q+ manu
16:57:59 <dmitriz> drummond: I've been wondering when this was going to come up, to clearly separate statements about the DID Subject, from metadata about the document
16:58:06 <dmitriz> … so I'd be for a unified way of doing that
16:58:14 <dmitriz> burn: ok, let's wrap up
16:58:26 <dmitriz> manu: yes, I'll put together a concrete PR with a proposal for this
16:58:33 <dmitriz> … and then we can revisit
16:58:36 <dmitriz> burn: thank you
16:58:38 <daniel> That's why they pay me the medium bucks, orie
16:58:41 <dmitriz> … and just remember, anyone can submit a PR
16:58:51 <dmitriz> … Manu has volunteered to write one, but you can also make your own one in parallel
16:58:55 <dmitriz> … any other comments?
16:59:06 <dmitriz> … Ah, Justin made a PR, thank you.
16:59:12 <dmitriz> … ok, next call is Jan 7th
16:59:22 <dmitriz> … look out for a Doodle poll to schedule upcoming calls / meetings
16:59:24 <dmitriz> … happy holidays
16:59:34 <ivan> rrsagent, draft minutes
16:59:34 <RRSAgent> I have made the request to generate https://www.w3.org/2019/12/17-did-minutes.html ivan
16:59:34 <ivan> zakim, bye
16:59:34 <ivan> rrsagent, bye
16:59:34 <RRSAgent> I see no action items
16:59:35 <Zakim> leaving.  As of this point the attendees have been burn, ChristopherA, ivan, TallTed, phila, dmitriz, dlongley, mike-lodder, yancy, gannan, rhiaro, Orie, agropper, dezell,
16:59:35 <Zakim> Zakim has left #did
16:59:37 <Zakim> ... chriswinc, daniel, drummond, selfissued, Irene_Jolocom, brent, Justin_R, manu, JoeAndrieu, jonathan_holt, ken, kdenhartog, oliver