14:08:53 <RRSAgent> RRSAgent has joined #did
14:08:53 <RRSAgent> logging to https://www.w3.org/2020/09/15-did-irc
14:08:55 <Zakim> RRSAgent, make logs Public
14:08:56 <Zakim> please title this meeting ("meeting: ..."), ivan
14:09:12 <ivan> Meeting: DID WG Telco
14:09:12 <ivan> Chair: burn
14:09:12 <ivan> Date: 2020-09-15
14:09:12 <ivan> Agenda: https://www.w3.org/mid/00000000000044a9ca05af0a652a@google.com
14:09:12 <ivan> ivan has changed the topic to: Meeting Agenda 2020-09-15: https://www.w3.org/mid/00000000000044a9ca05af0a652a@google.com
14:48:46 <burn> burn has joined #did
14:54:10 <burn> present+
14:55:35 <ivan> present+
14:58:12 <brent> brent has joined #did
14:58:51 <rhiaro> regrets+
15:00:14 <justin_r> justin_r has joined #did
15:00:42 <ivan> present+ justin_r
15:00:58 <ivan> present+ dmitriz
15:01:00 <dlongley> present+
15:01:08 <ivan> present+ dlongley
15:01:37 <ivan> present+ brent
15:01:37 <justin_r> present+
15:02:02 <ivan> present+ chriswinc
15:02:11 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:02:14 <chriswinc> chriswinc has joined #did
15:02:18 <ivan> present+ james
15:02:27 <chriswinc> present+
15:02:30 <ivan> present+ markus
15:02:34 <dmitriz> scribe+
15:02:36 <dmitriz> present+
15:02:37 <burn> Topic: Agenda Review, Introductions, Re-introductions
15:03:05 <wayne> present+
15:03:07 <dmitriz> burn: we have an interesting agenda today, a number of reminders, and then the typical Next Special Topic call reminder, then a discussion of Service Endpoints (explanation of what's next)
15:03:12 <Orie> Orie has joined #did
15:03:14 <dmitriz> ... and then a recap of the CBOR and Registry conversation
15:03:15 <Orie> present+
15:03:20 <dmitriz> ... that is an important discussion to the group
15:03:22 <jonathan_holt> jonathan_holt has joined #did
15:03:30 <dmitriz> ... if time remains, we'll go back to usual core issue status check
15:03:33 <jonathan_holt> present+ jonathan_holt
15:03:37 <ivan> present+ jonathan_holt
15:03:40 <ivan> present+ wayne
15:03:41 <dmitriz> ... do we have anyone joining us for the first time? doesnt look like it
15:03:50 <jonathan_holt> q+ to add cbor to discussion today
15:03:55 <dmitriz> ... anyone want anything else on the agenda?
15:03:58 <burn> ack jonathan_holt
15:03:58 <Zakim> jonathan_holt, you wanted to add cbor to discussion today
15:04:10 <dezell> dezell has joined #did
15:04:26 <ivan> present+ dezell
15:04:27 <burn> Topic: Normative Statements homework reminder
15:04:35 <ivan> present+ adrian
15:04:41 <Eugeniu_Jolocom> present+
15:04:43 <burn> https://docs.google.com/spreadsheets/d/1oVFYZdK65C6f4ErF5zfoGv1c57M5Em75YKCtRdAF-yg/edit#gid=0
15:04:48 <dmitriz> burn: this is a document sent out to the group
15:04:57 <dmitriz> ... in it, there's a list of all of the normative statements in the DID spec
15:05:02 <dmitriz> ... in preparation for doing the test suite work
15:05:10 <ivan> present+ drummond
15:05:17 <JamesQU> JamesQU has joined #did
15:05:22 <dmitriz> ... please take a look at the list. Make sure the normative statements match your understanding. If something doesn't strike you as right, suggest changes
15:05:24 <drummond> drummond has joined #did
15:05:24 <agropper> agropper has joined #did
15:05:31 <drummond> present+
15:05:35 <dmitriz> ... this is what will be required for your implementations.
15:05:38 <agropper> present+
15:05:39 <burn> Topic: Reminder WoT joint meeting poll
15:05:40 <ivan> present+ Eugeniu_Jolocom
15:05:42 <JamesQU> present+
15:05:47 <dmitriz> ... next is a reminder - the Web of Things WG has requested to meet with us around TPAC time
15:05:48 <burn> https://doodle.com/poll/b9hvv66nxqsfnbzc
15:05:54 <dmitriz> ... Brent put together a Doodle poll ^
15:06:10 <dmitriz> ... re normative statements list - that's going to remain open for another week or so. So please do review it soon.
15:06:29 <dmitriz> ... with respect to WoT meeting poll - that'll remain open till Thurs, and we'll select a time to meet with them
15:06:34 <burn> q?
15:06:41 <burn> Topic: Next special topic call
15:06:51 <dmitriz> ... next Special Topic call is going to be on Unknown Properties in did docs
15:07:03 <burn> https://lists.w3.org/Archives/Public/public-did-wg/2020Sep/0014.html
15:07:04 <dmitriz> ... here's a link to the relevant topic.
15:07:28 <dmitriz> ... it's about Unknown Properties. I believe Markus has a slide to share with us...
15:07:54 <burn> q?
15:07:55 <dmitriz> ... ah, maybe it's just a reminder for unknown properties. It'll make more sense to share it on the special topic call
15:08:08 <dbuc> dbuc has joined #did
15:08:09 <burn> Topic: Service Endpoints - next steps
15:08:13 <dbuc> present+
15:08:18 <dmitriz> ... next item is : Service Endpoints
15:08:31 <dmitriz> ... I believe one of the Editors is going to lead this summary of where we are, and the next steps
15:08:31 <burn> https://github.com/w3c/did-core/issues/382
15:08:44 <dmitriz> ... I'll drop a link to the relevant issue. Who wants to handle this summary?
15:08:50 <dmitriz> Drummond: I will
15:09:02 <dmitriz> drummond: there has been an awful lot of discussion around this topic,
15:09:31 <dmitriz> ... and it doesn't seem like it's converging. Our goal of the Special Topic call is to say - ok, we have dramatically different points of view, and we have to decide what is going into DID Core, what will go into the Implementation Guide, extensions, etc.
15:09:46 <dmitriz> ... We had the topic call. There was a lot of discussion, but no consensus or convergence.
15:10:03 <dmitriz> ... We have to make a practical decision now, on what to do in DID Core.
15:10:11 <ivan> -> https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-08-27-did-topic Minutes of the topic all on service endpoints
15:10:24 <dmitriz> ... so, we had an earlier call, we had discussion, now let's focus on what we can agree to do, with service endpoints.
15:10:37 <burn> q?
15:10:48 <dmitriz> markus: We've had a number of resolutions on Service Endpoints
15:10:52 <Orie> One point we might get clarity on would be the use of the registries for managing "service types".
15:10:54 <identitywoman> identitywoman has joined #did
15:11:00 <identitywoman> present+
15:11:02 <dmitriz> markus: We wanted to model in a non-normative Appendix about service endpionts and privacy
15:11:04 <ivan> -> https://www.w3.org/2019/did-wg/Meetings/Minutes/resolutions#resolutions-taken-at-working-group-topic-calls topic call resolutions on the top of the lists
15:11:08 <manu> present+
15:11:30 <dmitriz> drummond: we didn't come to any conclusions, though. The proposals are fairly general.
15:11:38 <ivan> present+ identitywoman
15:11:38 <agropper> also, service endpoints are blocking the PING work
15:11:44 <dmitriz> ... now, let's have a call that focuses on the decisions / what goes where.
15:12:14 <dmitriz> burn: reminder, this next call is Unknown Properties, not service endpoints (though we'll talk about those again)
15:12:24 <dmitriz> ... that's today, in just under 7 hours if I recall correctly
15:12:31 <dmitriz> ... editors, anything else about service endpoints?
15:12:31 <markus_sabadello> markus_sabadello has joined #did
15:12:33 <markus_sabadello> present+
15:12:34 <dmitriz> drummond: no
15:12:39 <burn> Topic: Recap - CBOR and the Registry
15:12:44 <markus_sabadello> Resolutions from last Topic Call on service endpoints: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-08-27-did-topic#res
15:12:51 <dmitriz> burn: let's move on to our topic of the day - CBOR and Registry
15:12:58 <dmitriz> ... I believe, Brent, you were going to take us through this
15:13:00 <burn> q?
15:13:14 <dmitriz> brent: first recap of the meeting - there was very strong consensus around interest in a CBOR representation
15:13:23 <burn> q+ to remind people to present plus in irc
15:13:38 <ivan> -> https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-09-10-did-topic Minutes of the topic call on CBOR
15:13:40 <jonathan_holt> q+
15:13:44 <dmitriz> ... following that, the next 45 mins of discussion brought absolutely no consensus regarding which particular flavor of CBOR to include in the spec. or anything else.
15:13:53 <dmitriz> ... so, go ahead and queue up if anyone wants to add to brief recap
15:13:54 <ivan> present+ phila
15:13:59 <burn> ack burn
15:13:59 <Zakim> burn, you wanted to remind people to present plus in irc
15:14:00 <phila> phila has joined #did
15:14:04 <dmitriz> ... not really intending to make it a massive discussion
15:14:07 <phila> present+
15:14:08 <brent> ack burn
15:14:20 <burn> ack jonathan_holt
15:14:30 <brent> ack jonathan_holt
15:14:31 <dmitriz> jonathan_holt: can I share screen?
15:14:37 <dmitriz> brent: is this about recap of meeting?
15:14:38 <dmitriz> jonathan_holt: yes
15:15:08 <dmitriz> brent: maybe what you want to present is not in recap, but in the next section (on next steps)
15:15:13 <dmitriz> jonathan_holt: one small point.
15:15:27 <dmitriz> jonathan_holt: (sharing screen to section 6.3 CBOR of did-core)
15:15:39 <dmitriz> ... (quotes from second sentence of that section)
15:16:15 <dmitriz> brent: the next steps that need to happen, in order for the CBOR representation to thrive, as part of the data model,
15:16:24 <dmitriz> ... is we need to come to consensus on the particular flavor we want to include
15:16:32 <dmitriz> ... that includes a stable normative specification for that flavor
15:16:38 <jonathan_holt> please clarify "flavor"
15:16:45 <dmitriz> ... we need to have Translation to CBOR added to the registry for all existing properties
15:16:55 <dmitriz> ... we need to have clear guidance on how to add CBOR to the registry for all new properties
15:17:08 <dmitriz> ... and we need a clear specification in the DID Core, for producing and consuming CBOR,
15:17:24 <dmitriz> ... so that it can be losslessly converted to and from other specifications
15:17:43 <dmitriz> ... and this needs to be done by the end of September
15:17:52 <dmitriz> ... those are the next steps.
15:18:12 <justin_r> q+
15:18:12 <dmitriz> ... are there any other steps that seem necessary, or other clarifications?
15:19:02 <dmitriz> jonathan_holt: the wording and constraints I made in the current CBOR section, was to get the semantic alignment with a core data model that can be converted to different representations, including JSON and JSON-LD
15:19:19 <dmitriz> ... the beauty of that is / the challenge we're having is - the DID Document has a potentially mixed data type
15:19:37 <burn> q?
15:19:42 <dmitriz> ... we have a potentially binary representation in CBOR, and then (potentially) hex encoding in JSON/JSON-LD. (encoding of binary fields?)
15:20:11 <dmitriz> ... encoding of public key material
15:20:32 <dmitriz> jonathan_holt: (my thoughts on this were interrupted by motorcycle accident this weekend! :( )
15:21:08 <dmitriz> jonathan_holt: (screenshare example. CBOR representation is 10-20% smaller than equivalent JSON repr.)
15:22:19 <dmitriz> ... the issue is really about the semantics of the properties in the core data model
15:22:24 <dmitriz> ... so that there's clear semantic interop
15:22:42 <dmitriz> ... that's what I attempted to do with the CBOR section. So that the representations can be translated, back and forth, including JSON to YAML , etc.
15:23:18 <dmitriz> ... I provided a sample algorithm (that provides an ordering to the properties, for translation)
15:23:23 <brent> Steps that need to be made:
15:23:41 <dmitriz> ... so, in short, there is lossless transformation between JSON <-> CBOR <-> YAML <-> JSON-LD
15:23:44 <brent> 1. consensus around the flavor of CBOR to include in the spec
15:23:56 <brent> 2. stable normative reference to a spec for that flavor
15:23:59 <dmitriz> ... we can have our cake and eat it too
15:24:03 <dmitriz> brent: thank you Jonathan!
15:24:11 <brent> 3. CBOR added to the registry for all existing properties
15:24:19 <dmitriz> justin_r: two quick things
15:24:23 <brent> 4. Clear guidance on how to add CBOR to the registry for any new properties
15:24:35 <dmitriz> ... one, when we're adding this section, please keep in mind that this is not a commercial for how great CBOR is.
15:24:38 <brent> 5. Clear specification in DID Core for producing and consuming CBOR such that it can be "losslessly converted" (via the abstract data model) to the other representations
15:25:03 <dmitriz> ... two, when dealing with property types, it's my understanding that the group's current direction is to define JSON/CBOR/etc encoding for each individual property
15:25:15 <dmitriz> ... I'd like to invite the group to define things in general data types
15:25:23 <dmitriz> ... such as - URIs, binary key material value, etc
15:25:27 <dmitriz> ... so, intermediate types
15:25:40 <dmitriz> ... which is the direction that I took with the JSON representation in the core doc
15:25:42 <ivan> q+
15:25:45 <brent> ack justin_r
15:25:47 <drummond> +1 to Justin's suggestion
15:25:50 <brent> ack ivan
15:25:59 <dmitriz> ivan: I'm not a CBOR expert. looking at the doc right now,
15:26:10 <justin_r> more like "semantic types" more than "intermediate types" but yes
15:26:11 <dmitriz> ... the problem I have is - the separate section which is 6.3.3.1 on DAG-CBOR
15:26:19 <jonathan_holt> q+
15:26:24 <dmitriz> ... what is DAG-CBOR, where is it defined, is there a way to normatively refer to the spec?
15:26:27 <jonathan_holt> iana tag 42
15:26:52 <dmitriz> ... the rest of the CBOR section is no problem, but we have to be careful with linking to specs
15:27:01 <dmitriz> brent: jonathan has linked us to the possible spec
15:27:09 <wanghaiguang> wanghaiguang has joined #did
15:27:15 <justin_r> to be clear, my concerns are all very addressable :)
15:27:26 <dmitriz> ... I have outlined 5 steps in the IRC notes,
15:27:39 <dmitriz> ... regarding what we need to do for CBOR to be a valid addition to our spec
15:27:43 <brent> ack jonathan_holt
15:27:45 <manu> q+ on steps
15:27:47 <dmitriz> ... are there any feedback items, on those 5 steps?
15:28:03 <dmitriz> jonathan_holt: DAG-CBOR is basically CBOR, with the constraint that it's just IANA tag 42
15:28:18 <brent> 1. consensus around the flavor of CBOR to include in the spec
15:28:26 <brent> 2. stable normative reference to a spec for that flavor
15:28:36 <dmitriz> jonathan_holt: with regard to the 5 steps -- the clearest path for semantic interop is to make the registry of properties in the DID Registries is to have a symbol representing a concept
15:28:38 <brent> 3. CBOR added to the registry for all existing properties
15:28:46 <brent> 4. Clear guidance on how to add CBOR to the registry for any new properties
15:28:50 <dmitriz> ... the symbol is a Byte String, which can be represented in all the various representations
15:28:58 <brent> 5. Clear specification in DID Core for producing and consuming CBOR such that it can be "losslessly converted" (via the abstract data model) to the other representations
15:29:18 <dmitriz> ... (also incidentally, I'm supporting DAG-CBOR <-> JSON-LD interop, in that section)
15:29:40 <dmitriz> ... advanced topics in CBOR, and the kind of compression you get with CBOR-LD, I think that should be topic for later discussion
15:29:57 <brent> ack manu
15:29:57 <Zakim> manu, you wanted to comment on steps
15:30:09 <dmitriz> manu: I wanted to +1 the 5 steps from Brent
15:30:15 <drummond> +1 to the five steps
15:30:17 <dmitriz> ... those are fairly typical of anything that needs to go into the spec
15:30:18 <justin_r> q
15:30:24 <justin_r> q+ on the steps
15:30:25 <dmitriz> ... so, +1.
15:30:37 <brent> ack justin_r
15:30:37 <Zakim> justin_r, you wanted to comment on the steps
15:30:54 <dmitriz> justin_r: in general, a +1 to the steps. I wanted to clarify that my second point about abstract property types is directly related to steps 3 & 4
15:31:01 <dmitriz> brent: I agree
15:31:09 <dmitriz> brent: I'm hearing no alteration requests (to the steps)
15:31:19 <dmitriz> ... I'm going to make a proposal to the group
15:31:29 <brent> Proposal: if all of these 5 steps are not done by the end of september, the CBOR representation will be removed from DID core and made its own note.
15:31:45 <burn> +1
15:31:46 <Orie> +1
15:31:46 <ivan> +1
15:31:49 <dmitriz> +1
15:31:50 <drummond> +1
15:31:50 <dlongley> +1
15:31:56 <markus_sabadello> +1
15:31:56 <phila> +1
15:31:59 <manu> +0.8 -- would rather state something about "Alternate Representations" in the spec, but that doesn't preclude this item.
15:32:05 <jonathan_holt> q+ to ask about flavor
15:32:11 <phila> q+
15:32:34 <agropper> +1
15:32:42 <dmitriz> q+ to ask about consensus mechanism
15:32:49 <dmitriz> jonathan_holt: can you clarify what 'flavor' of CBOR is?
15:33:08 <brent> ack jonathan_holt
15:33:08 <Zakim> jonathan_holt, you wanted to ask about flavor
15:33:13 <dmitriz> brent: DAG-CBOR vs CBOR-LD vs "vanilla CBOR" (conversion of JSON to CBOR without specific tags)
15:33:16 <brent> ack phila
15:33:29 <dmitriz> phila: I was thinking about the implications on your proposal
15:33:46 <dmitriz> ... my question is - does this mean that any implementaiton that uses DIDs now has to process CBOR? Or is support optional?
15:34:07 <dmitriz> brent: step 5 describes what a conforming producer or consumer of a CBOR representation must do
15:34:19 <dmitriz> ... so if a DID method chooses to be a producer or consumer of it, those are the reqs
15:34:26 <dmitriz> ... but there is no requirement for any DID method to do so
15:34:52 <dmitriz> phila: do we know of 2 independent CBOR implementations, to get us out of CR?
15:34:56 <brent> q?
15:34:58 <dmitriz> Ivan: if not, it'll be taken out of document
15:35:02 <brent> ack dmitriz
15:35:02 <Zakim> dmitriz, you wanted to ask about consensus mechanism
15:35:19 <manu> dmitriz: One of the items we're discussing is coming to consensus -- what's the mechanism for that consensus?
15:35:26 <justin_r> @Manu the spec should say more about defining representations anyway
15:35:26 <dmitriz> brent: the ideal mechanism is the same one outlined in our charter
15:35:34 <dmitriz> ... which is - someone raises a PR, and group approves
15:35:36 <manu> @justin_r, agreed.
15:35:38 <ivan> scribe+ manu
15:35:41 <manu> it doesn't say enough right now.
15:35:47 <dmitriz> ... alternate method is - somebody makes a proposal during a call, and group comes to resolution that way
15:35:51 <dmitriz> brent: I'm seeing
15:35:53 <burn> Phil, this is why step 1 is important.  Without consensus on the flavor we cannot be sure there are imlementations.
15:35:54 <brent> Resolved: if all of these 5 steps are not done by the end of september, the CBOR representation will be removed from DID core and made its own note.
15:36:00 <dmitriz> ... no opposition to my proposal. Resolved.
15:36:07 <phila> ack burn
15:36:24 <manu> @justin_r -- something like "Guidelines for Creating Representation Specifications"... or something roughly equivalent.
15:36:57 <dmitriz> brent: secondary proposal
15:37:01 <brent> Proposal: If CBOR is removed, we will add an 'additional representations' section which includes: the efforts we made for a CBOR representation and our belief that such a representation would be very good for the DID ecosystem; that additional representations of the abstract data model could and should be specified, either in a separate specification, or in a future version of the DID Spec.
15:37:31 <drummond> +1
15:37:35 <ivan> +1
15:37:35 <justin_r> -1 we should have that section anyway
15:37:36 <dmitriz> +1
15:37:36 <Orie> +1
15:37:41 <phila> +1
15:37:43 <burn> +1
15:37:48 <manu> +0.8 -- we should have that section anyway.
15:37:51 <dlongley> +1
15:38:00 <drummond> q+
15:38:19 <dmitriz> justin_r: when I first wrote the text for the Representations section, that's what I wanted to capture there (what's in the proposal)
15:38:34 <dmitriz> ... this should not be contingent on what we do with CBOR, we should have this section anyway
15:38:39 <manu> q+
15:38:45 <dmitriz> ... cause you never know when DID-PDF and DID-S-Expressions may strike
15:39:19 <drummond> +1
15:39:20 <dmitriz> brent: manu has drafted an alternate version of the proposal
15:39:20 <brent> ack drummond
15:39:23 <Orie> +1
15:39:25 <dmitriz> drummond: giant +1
15:39:27 <dmitriz> +1
15:40:00 <dmitriz> manu: (forgot to put the proposal to the record. so those previous +1s are just acausal quantum pilot waves)
15:40:00 <brent> ack manu
15:40:27 <drummond> +1
15:40:35 <manu> PROPOSAL: Language should be added to the DID Core specification that provides guidelines to Representation specification writers.
15:40:37 <Orie> +1
15:40:38 <ivan> +1
15:40:39 <dmitriz> +1
15:40:39 <drummond> +1
15:40:39 <dlongley> +1
15:40:40 <justin_r> +1
15:40:40 <manu> +1
15:40:43 <phila> +1
15:40:43 <agropper> +1
15:40:44 <markus_sabadello> +1
15:40:47 <burn> +1
15:40:50 <brent> +1
15:41:26 <dmitriz> brent: seeing no opposition, resolved.
15:41:38 <manu> RESOLVED: Language should be added to the DID Core specification that provides guidelines to Representation specification writers.
15:41:39 <brent> RESOLVED: Language should be added to the DID Core specification that provides guidelines to Representation specification writers.
15:41:56 <dmitriz> brent: that was everything I was hoping to cover, during this section!
15:42:10 <dmitriz> burn: ok
15:42:21 <dmitriz> burn: is there any other comments on this topic before we move on?
15:42:34 <burn> Topic: Core issue status check
15:42:42 <dmitriz> burn: last topic for today, issue status check
15:42:48 <dmitriz> ... we'll do something a little different.
15:42:55 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:42:56 <dmitriz> ... first - do the Editors have anything in particular they'd like to bring up?
15:42:59 <manu> q+
15:43:06 <burn> ack manu
15:43:21 <dmitriz> manu: in general, we've been hovering at around the same number of issues
15:43:36 <dmitriz> ... in some cases, it's understandable (they're hard issues), in other cases, just lack of PRs
15:43:43 <burn> yes, we are at the magic "around 50".
15:43:54 <dmitriz> ... so as a general comment, if you're assigned an issue, we are definitely in the home stretch of having to get these resolved
15:44:02 <dmitriz> ... you don't have to write the PR, but.. you should start considering it
15:44:09 <brent> +1
15:44:15 <burn> Magic as in "groups get stuck here, and when you make progress past this point it means you're about done"
15:44:16 <dmitriz> ... usually allocating 4 hrs during the week
15:44:35 <dmitriz> ... the failure case is, if we don't do that, the issues will be closed due to no progress
15:44:42 <dmitriz> ... so, now is the time to submit PRs!
15:44:43 <wayne> q+
15:44:48 <ivan> q+
15:44:53 <burn> ack wayne
15:45:06 <dmitriz> wayne: curious - how do I identify the most important issues to the community?
15:45:10 <brent> q+
15:45:13 <drummond> q+
15:45:15 <dmitriz> ... aside from our usual 'least recently updated'?
15:45:26 <burn> ack ivan
15:45:36 <ivan> q- later
15:45:36 <ivan> q+
15:45:38 <burn> ack brent
15:45:53 <dmitriz> brent: rather than concerning about what the community cares about, find what you care about
15:45:57 <burn> ack drummond
15:46:02 <dmitriz> drummond: I like brent's answer a lot
15:46:17 <dmitriz> ... as editors, we'll start to curate issues
15:46:24 <wayne> q+ response
15:46:40 <brent> q+ wayne
15:46:40 <burn> q+ wayne to respond
15:46:45 <burn> q- response
15:46:53 <burn> ack ivan
15:47:06 <dmitriz> Ivan: just reminder re W3C background. When we go to CR, most of these issues must be closed
15:47:07 <burn> q+
15:47:19 <dmitriz> ... in other words, once in CR, no major tech changes to the spec, or else.
15:47:24 <burn> ack wayne
15:47:24 <Zakim> wayne, you wanted to respond
15:47:49 <dmitriz> wayne: I do love Choose-Your-Own-Adventure, but my interest here is specifically getting the DID Spec out the door
15:47:51 <manu> q+
15:47:53 <burn> ack burn
15:47:54 <dmitriz> ... so my question is more - what are the blockers
15:48:13 <dmitriz> burn: just to be clear, we don't go to CR until we've addressed the issue
15:48:34 <dmitriz> ... what Manu is stating is -- there will come a time when the remaining issues either need a PR or they'll be closed
15:48:38 <dmitriz> ... and we're almost at that stage
15:48:46 <burn> ack manu
15:48:49 <dmitriz> ... so, if you care about something, now's your last opportunity before the editors take action
15:48:53 <dmitriz> manu: +1 to that.
15:49:04 <dmitriz> ... regarding what are the blockers - we're actually in a pretty good place
15:49:17 <dmitriz> ... for those of you who have gone through this process -- the things that remain in the spec are not that contentious
15:49:32 <dmitriz> ... sure, there's things like Service Endpoints and the CBOR stuff, but that pales in comparison with what other groups go through around this time
15:49:49 <dmitriz> ... so, there's some significant language to change, but the group is demonstrating strong amount of cohesion
15:50:06 <dmitriz> ... so, the remaining issues - most of them are low-key, just need PRs
15:50:17 <dmitriz> ... so, people, roll up your sleeves and we'll move into CR
15:50:38 <dmitriz> ... take a look at what's happening in the Normative Statements spreadsheet
15:50:44 <dmitriz> ... take a look at the comments in the margin
15:51:21 <burn> q?
15:51:26 <jonathan_holt> q+ to ask what happened to "proofs"
15:51:31 <burn> ack jonathan_holt
15:51:31 <Zakim> jonathan_holt, you wanted to ask what happened to "proofs"
15:51:32 <drummond> +1 to doing the attempt on the PR.
15:51:42 <dmitriz> jonathan_holt: after reading this over the weekend / normative statements,
15:51:58 <dmitriz> ... there's several I'm having a hard time with. What happened to the 'proofs' property, for example?
15:52:04 <manu> q+ to note that proofs were removed by consensus.
15:52:08 <dmitriz> ... it has disappeared off my radar
15:52:08 <burn> ack manu
15:52:08 <Zakim> manu, you wanted to note that proofs were removed by consensus.
15:52:18 <dmitriz> manu: proofs were removed in a PR, by consensus
15:52:38 <dmitriz> manu: folks didn't feel like it was appropriate to have proof in the spec
15:52:43 <dmitriz> jonathan_holt: because there was no consensus?
15:53:02 <dmitriz> manu: I don't think so. and anyway, that's a perfectly reasonable method for removing something
15:53:15 <dmitriz> jonathan_holt: certain things about the data model surprised me
15:53:16 <manu> q+ reviews are good too.
15:53:20 <manu> q+ to note that reviews are good too.
15:53:24 <burn> ack manu
15:53:24 <Zakim> manu, you wanted to note that reviews are good too.
15:53:41 <markus_sabadello> q+
15:53:48 <dmitriz> manu: Jonathan - spec surprising you is good feedback (thorough review of the spec)
15:53:59 <dmitriz> ... we always need as many eyes as possible on the whole spec
15:54:19 <burn> ack markus_sabadello
15:54:29 <dmitriz> markus_sabadello: I also don't remember exactly when proofs were removed,
15:54:38 <dmitriz> ... but I'm pretty sure it was in the context of metadata
15:54:50 <dmitriz> ... so proofs (and timestamps etc) are considered metadata, not data about the subject
15:54:53 <burn> q?
15:54:58 <manu> Here's where we removed Proofs -- https://github.com/w3c/did-core/pull/305
15:55:15 <dmitriz> burn: the reason I asked if the Editors wanted to highlight any issues
15:55:29 <dmitriz> burn: I was going to offer for us to end early-ish
15:55:47 <dmitriz> burn: so, everyone, go work on issues and PRs!
15:56:20 <ivan> zakim, end meeting
15:56:20 <Zakim> As of this point the attendees have been burn, ivan, justin_r, dmitriz, dlongley, brent, chriswinc, james, markus, wayne, Orie, jonathan_holt, dezell, adrian, Eugeniu_Jolocom,
15:56:23 <Zakim> ... drummond, agropper, JamesQU, dbuc, identitywoman, manu, markus_sabadello, phila
15:56:23 <Zakim> RRSAgent, please draft minutes
15:56:23 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/15-did-minutes.html Zakim
15:56:25 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:56:30 <Zakim> Zakim has left #did
15:57:01 <ivan> rrsagent, bye
15:57:01 <RRSAgent> I see no action items