21:57:49 <RRSAgent> RRSAgent has joined #did
21:57:49 <RRSAgent> logging to https://www.w3.org/2020/09/22-did-irc
21:58:02 <brent> rrsagent, draft minutes
21:58:02 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/22-did-minutes.html brent
21:58:12 <brent> rrsagent, make logs public
21:59:16 <brent> brent has changed the topic to: DID WG Agenda 2020-09-22: https://lists.w3.org/Archives/Public/public-did-wg/2020Sep/0018.html
21:59:32 <markus_sabadello> markus_sabadello has joined #did
22:00:28 <brent> Chair: Brent Zundel
22:00:43 <markus_sabadello> present+
22:00:49 <justin_r> justin_r has joined #did
22:00:49 <brent> Meeting: Decentralized Identifier Working Group
22:00:51 <wayne> present+
22:00:53 <rhiaro> present+
22:00:54 <justin_r> present+
22:01:17 <jonathan_holt> jonathan_holt has joined #did
22:01:17 <Orie> Orie has joined #did
22:01:18 <brent> present+
22:01:20 <Orie> \
22:01:24 <Orie> present+
22:01:25 <jonathan_holt> present+ jonathan_holt
22:01:30 <brent> zakim, this is did
22:01:30 <Zakim> got it, brent
22:02:00 <drummond> drummond has joined #did
22:02:20 <drummond> present+
22:02:24 <drummond> scribe+
22:02:50 <pam> pam has joined #did
22:03:57 <drummond> brent: we'll start with agenda review and intros
22:04:19 <kdenhartog> kdenhartog has joined #did
22:04:22 <drummond> ...we'll briefly talk about our Web of Things special meeting
22:04:35 <drummond> ...then a discussion about the abstract data model type system...
22:04:39 <drummond> ...and then issues
22:04:42 <tplooker_> tplooker_ has joined #did
22:04:54 <dlongley> present+
22:04:57 <tplooker_> present+
22:04:57 <kdenhartog> present+
22:05:06 <kdenhartog> scribe+
22:05:07 <drummond> ...please type present+ when you join IRC...
22:05:17 <identitywoman> identitywoman has joined #did
22:05:21 <identitywoman> +present
22:05:26 <manu> present+
22:05:32 <drummond> ...and q+ for queuing, with q+ to "text" for a reminder of your topic
22:05:52 <pam> present+
22:05:53 <brent> present+ identitywoman
22:06:17 <drummond> kdenhartog: In New Zealand, working for Mattr, working on decentralized identity...
22:06:22 <dbuc> dbuc has joined #did
22:06:24 <identitywoman> do they have taco bell in NZ
22:06:25 <dbuc> present+
22:06:33 <drummond> ...and favorite food is STILL Taco Bell
22:07:02 <kdenhartog> brent: come to regular meeting time on 13th of october for joint meeting with Web of Things WG
22:07:03 <drummond> brent: we will have a joint meeting with Web of Trust at our regular time on 13th October
22:07:15 <dbuc> In NZ, I hear Taco Bell changed their slogan to "Swim for the border"
22:08:17 <kdenhartog> brent: next special topic call Thursday
22:08:33 <agropper> agropper has joined #did
22:08:33 <kdenhartog> brent: next topic is abstract data model system
22:08:38 <manu> https://docs.google.com/presentation/d/1mb46JM7vgItg84Ucn3xUt021x3e9Te2lqUwZ-4OYk2w/edit
22:08:53 <kdenhartog> manu: including link into IRC
22:09:37 <kdenhartog> manu: We wanted to review did-core type system and the related issues to it
22:09:56 <kdenhartog> manu: part of this is a rehash of what we have right now and the rest is the remaining issues
22:10:13 <kdenhartog> manu: What do we have today. Today we have an abstract data model using INFRA
22:10:30 <kdenhartog> manu: This is used by W3C to describe data types in abstract data models
22:10:46 <kdenhartog> manu: Basically supports all the types we've needed to represent in this WG
22:11:04 <kdenhartog> manu: INFRA doesn't support numbers though
22:11:25 <kdenhartog> manu: This has led to some issues in the WG as of today
22:11:39 <kdenhartog> manu: Is also silent on unknown properties
22:12:25 <kdenhartog> ... Those are really the two issues left. We don't support numbers because INFRA leaves them undefined and we can't represent unknown properties
22:12:57 <kdenhartog> ... Everything we want to representable using INFRA as base model and then layer additional things on top
22:13:05 <kdenhartog> ... people seem to be more or less ok with this today
22:13:27 <kdenhartog> ... There is an issue (click first link in slide 3)
22:13:39 <kdenhartog> ... that discusses use of Numbers in INFRA
22:14:04 <kdenhartog> ... There won't be a definition of number before we're done though.
22:14:31 <kdenhartog> ... We can define number as a Real Number, in the mathematical sense
22:14:46 <kdenhartog> ... Implementations SHOULD limit ranges for interoperability
22:15:13 <Orie> https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#61-ignore-rule
22:15:25 <kdenhartog> ... specify ranges for integers and IEEE 754 floats
22:15:30 <brent> q?
22:15:58 <markus_sabadello> q+
22:15:59 <Orie> "For loosely coupled clients where the exact shape of the data is not known before the call, if the server returns something the client wasn't expecting, the client MUST safely ignore it."
22:15:59 <justin_r> Orie: that's the root of the question though -- does "ignore" mean "preserve" or "drop"?
22:16:04 <kdenhartog> ... Suggestions for unknown properties found here: https://docs.google.com/presentation/d/1mb46JM7vgItg84Ucn3xUt021x3e9Te2lqUwZ-4OYk2w/edit#slide=id.g99f34da178_0_13
22:16:18 <justin_r> Orie: that was the root of the question in issue 205
22:16:33 <Orie> justin_r i hope that ignore means "preserve"
22:16:41 <kdenhartog> ... We can also say if you can't convert to and from the INFRA model (such as a 64 bit int) then you should throw an error
22:16:41 <Orie> i like json
22:16:49 <justin_r> Orie: "hope" is not good spec language...
22:16:50 <kdenhartog> ... another thing we can do is push this onto did methods
22:17:30 <jonathan_holt> q+
22:17:35 <kdenhartog> ... That's it thoughts concerns?
22:17:35 <drummond> q+ to say should NOT allow DID methods to control formatting of representations - only to define properties
22:17:36 <brent> ack markus_sabadello
22:17:52 <drummond> q?
22:18:00 <dlongley> reminder that I-JSON exists: https://tools.ietf.org/html/rfc7493
22:18:13 <kdenhartog> markus_sabadello: This is interesting. 1 comment first. You mentioned we'd probably want to define what a number means. We'll likely also want to do that for datetime.
22:18:26 <manu> q+ to note we don't have to specify DateTime if it is a string.... that conforms to XMLDateTime.
22:18:47 <kdenhartog> ... I did that in my PR for consistency of language. I don't think we should assume a specific format of  a datetime
22:19:05 <brent> ack jonathan_holt
22:19:11 <justin_r> +1 the abstract data model shouldn't do "datetime" as a formatted string when it can be a data type
22:19:18 <kdenhartog> ... so we likely need to do the same thing for datetime
22:19:30 <kdenhartog> jonathan_holt: We ran into this when doing the CBOR section
22:20:25 <kdenhartog> ... I at first was fine with INFRA. It's kind of a loose constraints. I'd prefer that we constrain possible representations and allows for better cross representations
22:21:01 <kdenhartog> ... I've been working a lot with CDDL and that's worked well with JSON and CBOR
22:21:11 <brent> ack drummond
22:21:11 <Zakim> drummond, you wanted to say should NOT allow DID methods to control formatting of representations - only to define properties
22:21:47 <manu> q+ to note to drummond that that's not what was suggested.
22:21:58 <manu> q+ to say - not define representations -- just what is kept/removed.
22:22:22 <Orie> q+
22:22:25 <kdenhartog> drummond: Manu mentioned that an option to allow did methods to change representations. I've been discussing this lately and I don't believe they should not change the representations to allow for beffer cross representations
22:22:27 <manu> q- latr
22:22:30 <brent> ack manu
22:22:30 <Zakim> manu, you wanted to note we don't have to specify DateTime if it is a string.... that conforms to XMLDateTime. and to note to drummond that that's not what was suggested. and to
22:22:31 <manu> q- later
22:22:34 <Zakim> ... say - not define representations -- just what is kept/removed.
22:23:17 <brent> ack Orie
22:23:20 <kdenhartog> Orie: I'm hopeful that by clarifying the core data model that will help us to better understand how dates and numbers will be represented
22:23:21 <brent> ack manu
22:23:27 <justin_r> q+
22:23:40 <drummond> q+ to say that I'm totally in favor of the ADM including as comprehensive a set of abstract data types as we can afford
22:23:50 <kdenhartog> manu: to markus your point on datetime we could specify a datetime as a different type, but everyone seems happy with XMLDatetime
22:23:55 <justin_r> q- later
22:24:14 <kdenhartog> ... it's a choice that we can take, but it's not clear what defining a type for would be for
22:24:56 <brent> xml datetime or https://tools.ietf.org/html/rfc3339 ? or are those the same?
22:24:56 <justin_r> q+ to talk about data sanitization
22:24:57 <kdenhartog> ... for Drummond, it wouldn't be about allowing DID methods to chose their types, but rather they can chose if they want to exclude types
22:25:17 <brent> ack drummond
22:25:17 <Zakim> drummond, you wanted to say that I'm totally in favor of the ADM including as comprehensive a set of abstract data types as we can afford
22:25:29 <kdenhartog> ... or want to keep. This would allow us to preserve as much at the core layer while keeping the methods to defining the security model
22:26:23 <kdenhartog> drummond: That helps quite a bit and make sense. I'm more trying to have us get more precise about the question Orie brought up. If we have a sufficient data type system to describe how to go in and out of the data model
22:26:31 <manu> q+ to speak to Orie's question -- it's INFRA, those are the types supported.
22:26:39 <kdenhartog> ... then we don't have an unknown property problem if we define all the possible types
22:26:44 <brent> ack justin_r
22:26:44 <Zakim> justin_r, you wanted to talk about data sanitization
22:26:46 <manu> q+ to say we could list them explicitly.
22:27:01 <kdenhartog> justin_r: it's clear that we need more data types then what INFRA offers.
22:27:09 <kdenhartog> ... we have string but it's more than a string it's a URI
22:27:10 <Orie> if we are not going to use infra, I propose we just use JSON.
22:27:28 <burn> burn has joined #did
22:27:29 <kdenhartog> ... I'd rather define our data model with actual types like datatime and uri
22:27:33 <burn> present+
22:27:46 <kdenhartog> ... these are things that can be represented in multiple representations and programming languages
22:27:46 <manu> q+ to say "if we just use JSON, we can't support CBOR"
22:27:47 <Orie> lets create our own type system, so we can represent datetimes.
22:28:02 <kdenhartog> ... this way if I have a datetime object then how do we put it in the representation
22:28:24 <kdenhartog> ... representations then need to define how to fit every type in the did document
22:28:34 <Orie> q+
22:28:40 <manu> q- later
22:29:16 <drummond> +1 to representations needing to define how they serialize every abstract data type defined in the ADM. This will give us the precision we are looking for and take care of the issue of "unknown types".
22:29:20 <manu> +1 to what Justin just said wrt. sanitization.
22:29:20 <kdenhartog> ... also quick note on data sanitization. It's unclear if data sanitziation would happen after consumption or before production
22:29:28 <Orie> you cannot sannitize an abstract data model
22:29:29 <dbuc> Justin plugging Transmute
22:29:35 <dbuc> free advertising
22:29:37 <Orie> i know right :)
22:29:43 <kdenhartog> ... I think we need to be much more clear about things like that
22:29:48 <justin_r> s/transmute/transmogrify/
22:29:53 <brent> ack Orie
22:30:31 <kdenhartog> Orie: To respond to Justin, I'm having a hard time understanding what sanitization is in a abstract data model.
22:30:41 <drummond> "sanitization" takes place before you go into the ADM or once you go out of the ADM
22:31:10 <drummond> touche
22:31:19 <justin_r> I think this is a rabbit hole because this isn't the kind of santization that I was tlaking about
22:31:24 <kdenhartog> ... since representations affect the sanitizations that leaves me confused how we "properly" without thinking about the sanitization without knowing the representation
22:31:25 <justin_r> s/tlaking/talking/
22:31:38 <brent> q?
22:31:46 <justin_r> q+
22:31:50 <kdenhartog> ... on the production side I'm unconvinced that we can do anything with regards to sanitization
22:31:56 <drummond> @justin, you might want to clarify that's not what you meant by "sanitization"
22:32:03 <kdenhartog> ... I think we can do it on the consumption side though
22:32:04 <brent> ack manu
22:32:04 <Zakim> manu, you wanted to speak to Orie's question -- it's INFRA, those are the types supported. and to say we could list them explicitly. and to say "if we just use JSON, we can't
22:32:07 <Zakim> ... support CBOR"
22:32:28 <jonathan_holt> q+
22:32:48 <kdenhartog> manu: I wanted to get feedback from the group to get consensus. It's suggested that we throw INFRA out. We picked it for a reason. I want to make sure the WG doesn't have something else that's workable as well.
22:32:57 <Orie> +1 to throwing infra out :) we already don't support CBOR.... we should support CBOR properly when we can... until then, we should DO JSON right!
22:33:14 <kdenhartog> ... a few options build ontop of INFRA, define our own, etc
22:33:19 <drummond> q+ to say the ADM should be: a) INFRA if it is defined there, b) all other abstract data types we think we need to have a very high interoperability
22:33:36 <kdenhartog> ... 2 questions: Is there a serious question to move away from INFRA please make the proposal
22:33:45 <drummond> URI
22:33:57 <kdenhartog> ... I want to see if there's anything other than datetime and number that we need to define
22:34:01 <brent> ack justin_r
22:34:15 <kdenhartog> brent: yes we'll handle this at the end
22:34:44 <kdenhartog> justin_r: There's a lot of byte set values that we need to be clear about how they're used
22:35:14 <kdenhartog> ... my suggestion is we build on top of INFRA but then we define all of the abstract data types in addition
22:35:32 <kdenhartog> ... e.g. datetime would be just like what we would have to do with numbers
22:36:00 <kdenhartog> ... then it's up to the representations to define how to take all the types and translate that into the defined representations
22:36:13 <drummond> Justin stole all my best lines ;-)
22:36:19 <brent> q?
22:36:26 <brent> ack jonathan_holt
22:36:27 <kdenhartog> ... I should be able to create a brand new representations by looking at all the types defined and if I can represent all of them then it should work
22:36:44 <justin_r> q+ to talk about property names, too
22:36:55 <kdenhartog> jonathan_holt: To respond to manu it's not mutually exclusive that what's represented in JSON can be represented in CBOR
22:37:04 <kdenhartog> ... I've been impressed with CDDL
22:37:07 <brent> zakim, close the queue
22:37:07 <Zakim> ok, brent, the speaker queue is closed
22:37:35 <manu> q+ to run some proposals
22:37:39 <kdenhartog> ... What I think is lacking is that we have a concept but not the required properties types
22:37:42 <brent> ack drummond
22:37:42 <Zakim> drummond, you wanted to say the ADM should be: a) INFRA if it is defined there, b) all other abstract data types we think we need to have a very high interoperability
22:38:19 <brent> ack justin_r
22:38:19 <Zakim> justin_r, you wanted to talk about property names, too
22:38:21 <kdenhartog> drummond: I'd like to see the proposal that Justin just said and then representations could say what types we need
22:39:08 <drummond> +1 to making sure the representation production rules and consumption rules cover conversion of property names as well as values
22:39:14 <kdenhartog> justin_r: I wanted to point out this more then representation values but also representation property names. Eg. with CBOR when I see a specific property name then I can recognize those CBOR tags
22:39:15 <brent> zakim, open the queue
22:39:15 <Zakim> ok, brent, the speaker queue is open
22:39:19 <manu> PROPOSAL: The Abstract Data Model will support ONLY JSON types, and will use JSON for the Abstract Data Model for this version of the spec.
22:39:22 <Orie> +1
22:39:25 <manu> -1
22:39:30 <drummond> -1
22:39:31 <justin_r> -1
22:39:31 <dlongley> -1
22:39:31 <jonathan_holt> -1
22:39:34 <brent> -1
22:39:38 <markus_sabadello> -1
22:39:39 <tplooker_> -1
22:39:40 <kdenhartog> -1
22:40:02 <manu> PROPOSAL: The Abstract Data Model will use INFRA it's base and will add additional types on top of INFRA.
22:40:09 <Orie> -1
22:40:09 <drummond> +1
22:40:10 <manu> +1
22:40:10 <jonathan_holt> -1
22:40:12 <justin_r> +1
22:40:13 <rhiaro> +1
22:40:13 <brent> +1
22:40:14 <kdenhartog> +1
22:40:14 <dlongley> +1
22:40:14 <tplooker_> +1
22:40:21 <markus_sabadello> +1
22:40:57 <kdenhartog> jonathan_holt: I think I'm ok with JSON, but I'm not impressed with INFRA
22:41:08 <kdenhartog> ... I'd suggest everyone take a look at CDDL
22:41:16 <justin_r> I would be ok with "json as a base" for the data structure types but it would need to be extended too
22:42:08 <kdenhartog> Orie: My main concern is that I wanted to create DIDs in JSON and so I find the engagement in defining abstract data models and date types and I think it's going to be a giant distraction
22:42:30 <kdenhartog> brent: remember we passed a previous proposal to use INFRA as a type system
22:42:32 <Orie> modifying a type system is making a type system
22:42:38 <Orie> extension is a form of creation
22:42:43 <justin_r> Orie: yes. The DID Core Document Type System
22:42:46 <manu> PROPOSAL: Add Number as a primitive type to the Abstract Data Model.
22:42:49 <pam> q+ to ask about implications of a dependency on a living standards document
22:42:51 <manu> +1
22:43:02 <justin_r> +1
22:43:09 <brent> +1
22:43:11 <dlongley> +1 with appropriate ranges for interoperability like I-JSON specifies
22:43:13 <kdenhartog> +1
22:43:16 <drummond> +1
22:43:17 <tplooker_> +1
22:43:18 <brent> ack pam
22:43:18 <Zakim> pam, you wanted to ask about implications of a dependency on a living standards document
22:43:29 <Orie> +0 numbers should be supported.
22:43:43 <markus_sabadello> +1
22:44:02 <jonathan_holt> 0, but not a big fan of INFRA
22:44:05 <manu> RESOLVED: Add Number as a primitive type to the Abstract Data Model.
22:44:12 <kdenhartog> Brent: That proposal is resolved
22:44:16 <manu> PROPOSAL: Add DateTime as a primitive type to the Abstract Data Model.
22:44:17 <Orie> -1
22:44:21 <justin_r> +1
22:44:30 <manu> -1, don't think we need it, happy to reconsider if we have a use case/limitation
22:44:35 <tplooker_> +1
22:44:36 <kdenhartog> +0
22:44:36 <dlongley> -1 don't think we need it
22:44:49 <jonathan_holt> q+
22:44:53 <markus_sabadello> +1 the format used by XML Schema is not abstract
22:44:59 <tplooker_> q+
22:45:00 <drummond> +1
22:45:03 <justin_r> q+ to say why these kinds of things are important (if we have time for it)
22:45:17 <manu> PROPOSAL: Add URL as a primitive type to the Abstract Data Model.
22:45:22 <Orie> -1
22:45:23 <justin_r> +1 (actually URI)
22:45:24 <drummond> +1
22:45:25 <agropper> agropper has joined #did
22:45:27 <jonathan_holt> URI
22:45:29 <manu> -1, don't think we need it, happy to reconsider if we have a use case/limitation
22:45:30 <dlongley> -1 don't think we need it
22:45:40 <tplooker_> +1
22:45:46 <kdenhartog> manu: Treat URL as URI as well
22:45:52 <kdenhartog> +1
22:46:03 <jonathan_holt> 0
22:46:04 <markus_sabadello> +1
22:46:11 <drummond> Consider that this is an *identifier* specification
22:46:52 <manu> q+ to respond to Pam -- have considered.
22:47:13 <kdenhartog> pam: Do we have a plan for when INFRA adds some of these types we want to define?
22:47:13 <jonathan_holt> q-
22:47:16 <tplooker_> q-
22:47:25 <drummond> q+ to talk about the ADM model
22:48:11 <dlongley> everything we create an abstract type for that can't be covered by simple JSON types (strings, numbers, etc.) requires more work to document canonical representations
22:48:15 <brent> ack justin_r
22:48:15 <Zakim> justin_r, you wanted to say why these kinds of things are important (if we have time for it)
22:48:19 <Orie> what justin just said is exactly why I don't want to get into defining a type system for URIs
22:48:19 <drummond> Precision = better security
22:48:20 <brent> ack manu
22:48:20 <Zakim> manu, you wanted to respond to Pam -- have considered.
22:48:21 <kdenhartog> justin_r: if you're thinking about URIs as a string that contains a string that's a URI. If we can be more precise then we should
22:48:27 <justin_r> dlongley: literally everything can just be a string so that's a strawman argument
22:48:45 <kdenhartog> manu: to respond to Pam, as you know pointing to living docs is an issue. There's been recommendations that do point to living docs like HTML5
22:49:10 <justin_r> a URI is a collection of scheme, authority, path, query, fragment, etc. It has a string syntax but it's also a data object model.
22:49:19 <brent> ack drummond
22:49:19 <Zakim> drummond, you wanted to talk about the ADM model
22:49:23 <kdenhartog> ... what WG are doing now is they go into maintanence mode, and in then if INFRA added those types then we could modify as necessary in the maintainence WG to keep it up to date
22:49:53 <kdenhartog> drummond: This whole conversation is a prelude to the unknown properties issue and the ability to go in and out of representations
22:50:26 <dlongley> justin_r, it's just about where to draw the line, it has to be drawn somewhere ... you can always add more "abstract types".
22:50:29 <kdenhartog> brent: We'll move onto last topic which is issues
22:50:42 <brent> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
22:51:05 <brent> https://github.com/w3c/did-core/issues/119
22:51:10 <kdenhartog> brent: first 3 horizontal related
22:51:44 <kdenhartog> brent: 119 is waiting on TAG and we're waiting on security/privacy questionaires to resubmit
22:52:07 <kdenhartog> brent: 104 and 105 are simply tracking items for CR phase
22:52:13 <brent> https://github.com/w3c/did-core/issues/356
22:52:44 <kdenhartog> Orie: We talked about this and adding restrictions such as no private key material
22:52:56 <kdenhartog> ... we should be at the point of just needing to add a PR
22:53:22 <brent> https://github.com/w3c/did-core/issues/337
22:53:57 <justin_r> dlongley: yes, exactly. And I think we can do better than drawing the line at "JSON" and throwing up our hands.
22:54:08 <kdenhartog> dbuc: I've still got to do a PR for this sorry for the delay
22:54:16 <brent> https://github.com/w3c/did-core/issues/291
22:54:55 <kdenhartog> agropper: we're still waiting on the service endpoints to finish up the security and privacy questionaire
22:55:05 <brent> https://github.com/w3c/did-core/issues/58
22:55:58 <kdenhartog> wayne: we're happy to accept this as a work item in the CCG but we need work item owners to step up
22:56:19 <brent> https://github.com/w3c/did-core/issues/72
22:56:48 <kdenhartog> drummond: we're planning to update this once we're done with the normative sections of the core spec
22:57:09 <kdenhartog> ... buying us time is helpful because we're learning more about DIDs and GDPR everyday
22:57:27 <kdenhartog> ... if there's a reason this surfaces to be faster I can reprioritize
22:57:28 <brent> https://github.com/w3c/did-core/issues/163
22:57:41 <kdenhartog> brent: this is going to be done right before CR
22:58:13 <kdenhartog> brent: same status is for 118
22:58:20 <brent> https://github.com/w3c/did-core/issues/375
22:58:45 <tplooker_> +1
22:59:32 <kdenhartog> drummond: I'm not sure about this issue but I'll reach out to daniel hardman to figure out what's needed to get it done
23:00:01 <identitywoman> thank you Markus
23:00:29 <kdenhartog> drummond: special topic call on service endpoints is at Noon EST on Thursday
23:00:44 <manu> rrsagent, make logs public
23:00:51 <manu> rrsagent, draft minutes
23:00:51 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/22-did-minutes.html manu
23:01:14 <brent> zakim, end the meeting
23:01:14 <Zakim> As of this point the attendees have been markus_sabadello, wayne, rhiaro, justin_r, brent, Orie, jonathan_holt, drummond, dlongley, tplooker_, kdenhartog, present, manu, pam,
23:01:17 <Zakim> ... identitywoman, dbuc, burn
23:01:17 <Zakim> RRSAgent, please draft minutes
23:01:17 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/22-did-minutes.html Zakim
23:01:19 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
23:01:23 <Zakim> Zakim has left #did
23:01:32 <brent> rrsagent, please excuse us
23:01:32 <RRSAgent> I see no action items