15:13:57 RRSAgent has joined #did 15:13:57 logging to https://www.w3.org/2021/02/02-did-irc 15:13:59 RRSAgent, make logs Public 15:14:01 please title this meeting ("meeting: ..."), ivan 15:14:18 Meeting: DID WG Telco 15:14:18 Chair: brent 15:14:18 Date: 2021-02-02 15:14:18 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Jan/0032.html 15:14:18 ivan has changed the topic to: Meeting Agenda 2021-02-02: https://lists.w3.org/Archives/Public/public-did-wg/2021Jan/0032.html 15:17:43 TallTed has joined #did 15:51:11 burn has joined #did 15:52:35 present+ 15:59:27 present+ 15:59:48 present+ adrian 16:00:04 present+ 16:00:10 present+ 16:00:12 present+ dlongley 16:00:25 nick brent 16:00:44 agropper has joined #did 16:00:52 present+ 16:00:55 present+ 16:01:09 present+ 16:01:25 present+ 16:01:46 JoeAndrieu has joined #did 16:02:16 present+ jonathan 16:02:32 markus_sabadello has joined #did 16:02:43 present+ JoeAndrieu 16:02:48 present+ 16:02:49 present+ 16:02:49 may be irc only, network issues 16:03:04 present+ drummond 16:03:12 present+ wayne 16:03:15 scribe+ 16:03:17 present+ 16:03:23 Orie has joined #did 16:03:25 present+ orie 16:03:41 justin_r has joined #did 16:03:42 drummond has joined #did 16:03:49 present+ 16:04:00 present+ justin_r 16:04:13 present+ 16:04:14 brent: We'll start with agenda review. We're going to remind everyone of the PR deadline and the special topic call. We'll have a brief conversation about WG scope followed by a reminder about normative references in the spec and we'll move what we expect to be a lively conversation about CBOR. 16:04:20 brent: As time permits we'll talk about CR exit criteria. 16:04:29 brent: Anything to add to the agenda? 16:04:36 q? 16:05:05 manu: Somewhat on the fence, chair discretion if you want to pick this up, maybe talk a bit about the expectations over Feb and March and what the editors will try to be doing, what will happen at Feb 9th deadline, that kind of stuff. 16:05:17 brent: I'll incorporate that into the PR deadline topic and give you some time for that 16:05:20 manu: Thanks. 16:05:52 brent: We're going to skip intros and reintros today. Next topic is PR deadline. 16:05:58 present+ dmitri 16:06:06 brent: We sent out an email (the chairs did) letting people know the PR deadline is Feb 9th. 16:06:39 brent: What this means is -- any issues that are not addressed by PRs submitted by Feb 9th will need to be deferred to a future version of the spec. We've been working hard for a long time and if we want to actually produce a spec we have to move forward so that the process has time to complete. 16:07:04 Topic: CR Timeline 16:07:53 manu: Right, so the thing that we kind of want to make sure that the whole group is on board with. What the process is/expectations are. We expect all PRs in by Feb 9. At that point, that doesn't mean all PRs have been committed, it means they are in. We will have a flurry of activity to get those PRs merged down. Dealing with objections, editorial things. Ideally they'd all be in by the 9th but there are always some last minute ones that come in 16:07:53 overnight. During that week we will try to get them all in. 16:08:11 jonathan_holt has joined #did 16:08:22 manu: The week of the 9th, the editors and others will make multiple passes over the entire document and a huge flurry of activity, to make editorial passes, tightening up terminology, doing all of the last things we need to do before CR. 16:08:22 present+ jonathan_holt 16:09:02 q? 16:09:03 manu: There's a request here from at least one editor, me, that we go into a mode of operation where we do 24 hr reviews. We will put all the PRs through the process, all expected to be editorial, if they do have to make normative changes it will be a 7 day period. But for editorial ones, we want to do 24 hr review cycles. 16:09:11 manu: These are editorial changes and we can always undo them because they are. 16:09:47 manu: Feb 9th hits, we get remaining PRs to get them in, then flurry of editors with editorial PRs with 24 hr review periods. Once that's done, we hope the transition period goes through, the chairs/staff contact will handle that. Then a call thereafter. 16:09:50 manu: Any questions? 16:09:54 q+ 16:10:04 ack justin_r 16:10:32 q+ 16:10:35 justin_r: Yeah, I agree with the sentiment that's every thing that's stated. I'm a little concerned about things being declared as editorial that make more than just editorial changes. There isn't always agreement on equivalence of text. I know there's one right now being discussed with that very nature. 16:10:45 justin_r: So I'm not sure what I'm asking of the group other than to be aware of that and try not to do that. 16:10:46 ack manu 16:11:04 dbuc has joined #did 16:11:44 manu: +1 to being aware of that and trying not to do it. It will happen. It's the nature of this stage and when it does happen and people can ask for the change to be backed out. If any asserted editorial change is objected to as actually normative, people should object in the PR and the PR won't go in. Even if it gets missed then the editors will default to backing out such changes if they have hit the spec. 16:11:57 manu: Hopefully that puts everyone's minds at ease. That we won't make any massive breaking change, etc. 16:12:30 manu: When we say "editorial change" that typically means it won't change what implementers will do. Usually during the CR stage, we tend to say that a normative change that will -- that will change an implementation. 16:12:45 manu: A substantive change is something that will change the implementations. 16:13:04 manu: We hear you Justin, we're trying to do the right thing and stick to the aggressive schedule. 16:13:05 present+ dbuc 16:13:15 +1 thank you, it's not easy to balance a timeline like this with not surprising people 16:13:41 brent: Thank you, Manu. We have full confidence in our editors and in their impartiality as they do editorial things. We recognize that everyone is human and look to the group that -- no one will try to sneak things in or railroad, this is just the process and you can say "I'm not sure I agree with that" and we can continue the conversation. 16:13:50 topic: special topic call 16:14:00 and +1 to a clear redress process 16:14:16 brent: Our special topic call is today at 6pm ET. The goal of the call is to provide folks with feedback on PRs. If you're working on a PR or want to write one, this meeting is to give you feedback on PRs. 16:14:24 brent: Please come to the special topic call. 16:14:31 Clarification: when is the special topic call? 16:14:48 Ignore that, got it 16:15:06 brent: WG scope -- the chairs met with our staff contact, had a very in depth conversation on our charter and what our scope entails. We would like to make the following statement: Defining canonicalization algorithms for any representation is outside of the scope of our WG charter. 16:15:09 Topic: WG Scope 16:15:28 brent: If you have a question about what that means we might be able to take it now, but we also have time set aside in the agenda in detail for something it definitely affects. 16:15:54 Topic: Normative References Reminder 16:16:53 brent: All normative references in the DID core spec must point to a reference of equal standing. This is W3C policy. What this means is, while our spec is in the working draft stage, then it's appropriate to point to other specs in a working draft stage. But once we move to CR and PR, those references, the standards to which those references point must be of equal standing. 16:16:54 Equal or greater maturity 16:16:58 brent: They need to essentially be W3C/IETF standards. 16:17:21 brent: If there's a normative reference to something that is not going to be an equally (or greater) standard at the time we wish to publish, then that reference must be removed. 16:17:29 brent: Any questions on this topic? 16:17:39 CR -> CR would be acceptable ... but timelines don't usually line up that well 16:17:52 drummond: Do we know -- I understand the blanket thing. Is there a specific reference that we need to address? Is that a general warning? 16:18:07 TallTed, agreed. Equal or greater maturity 16:18:10 brent: It is a reminder and it does affect CBOR or possibly affect DagCBOR which we'll talk about next. 16:18:15 Topic: Conversation about CBOR 16:18:57 "Thou shalt only point to other carved ivory artifacts of antiquity within the Ivory Tower" 16:19:05 brent: To start off, the chairs have pushed from the beginning and hoped from the beginning that we'd have multiple representations. Once we had an ADM the chairs hoped to see JSON, JSON-LD, but also CBOR. We have been rooting from the sidelines hoping for it to proceed. 16:19:37 q+ to note ramifications. 16:19:49 brent: We will need to see some changes to the CBOR section based on what was just highlighted and this is an opportunity to have this conversation. I'd much prefer that folks jump on the queue to talk about what they see as the ramifications of these determinations. 16:19:52 ack manu 16:19:52 manu, you wanted to note ramifications. 16:20:30 q+ 16:20:48 manu: I've very interested to hear Jonathan's thoughts on all this. The CBOR section currently has a section about canonicalization. My expectation is that based on the chairs and the staff finding that that part would come out, the canonicalization algorithm in the CBOR section. We could still refer to the things you should keep into account when defining a canonicalization algorithm by referencing the CBOR RFC. 16:20:58 q+ to propose moving application/did+cbor to did spec registry 16:21:29 manu: Now there would be potentially a PR to remove that canonicalization language. The other ramification would be for the DagCBOR section. We would need to reference something normatively that has clear canonical rules for DagCBOR or that section wouldn't say anything about canonicalization. 16:22:04 manu: The discussion during the special topic call last week that if we moved DagCBOR into its own spec and registered it in the DID spec registries it would allow that spec to define canonicalization rules and continue to improve and mature at its own pace instead of being tightly coupled to DID core. 16:22:10 manu: Is that interpretation correct, question mark? 16:22:14 ack jonathan_holt 16:23:04 jonathan_holt: I think there's room for a compromise. It was my hope in the 4+ months that I wrote the section and I hoped it would mature and wanted it to be to a level we could point to normatively. The IPFS community is a bit slow to formalize -- that's the challenge. Despite my best efforts it didn't happen in the timeframe expected. 16:23:28 jonathan_holt: `ipfs:` is now a registered scheme, many users now have access to ipfs in the browser, which is a good thing. 16:23:44 jonathan_holt: I think we reached a compromise to move the DagCBOR spec into its own spec and put it in the DID spec registries. 16:23:47 hoooray wrt. DagCBOR -> separate specification and put it in DID Spec Registries. 16:24:07 q? 16:24:19 q+ to remind folks that JSON-LD can encode DAGs. 16:24:43 jonathan_holt: My goal was to have a DAG data model in the spec and I think that would be worthy to be represented. The other compromise side of that is that there is normative language for the core deterministic requirements that's in the new RFC 8949, which replaces RFC 7049. I'm arguing that the deterministic representation is important in our work and I was hoping to inherit those constraints. 16:24:45 q+ to also remind folks that there is a canonicalization algorithm for RDF and JSON-LD. 16:25:03 jonathan_holt: To the DagCBOR section. That was my attempt 4 months ago to have the text in the CBOR section, not the DagCBOR section. 16:25:21 jonathan_holt: But I realize I wrote that text 4 months ago while recouping from a motorcycle accident on narcotics and it wasn't perfect. 16:25:26 jonathan_holt: Now we have core requirements. 16:25:39 q- 16:25:41 q+ 16:25:52 ack Orie 16:25:52 Orie, you wanted to propose moving application/did+cbor to did spec registry 16:25:54 jonathan_holt: Just as we've been building an ADM if we have a canonical representation and that can live in RFC 8949 and the rest of CBOR can play out in other standards including the DID spec registries. 16:26:01 q+ 16:26:31 Orie: I agree with the chairs. We should have nothing to do with canonicalization. I'd prefer to not have that discussion. I would propose we do the same thing that we've agreed to do with DagCBOR to also do with CBOR. Implementers haven't had enough time to work with CBOR. There's been even less contribution to CBOR than DagCBOR. 16:26:34 q+ to move Vanilla CBOR out... but as a NOTE, and I can volunteer to do that. 16:26:43 q+ 16:27:17 Orie: It would be prudent to move CBOR to the DID spec registries and not commit the WG to production and consumption rules for something no one has done implementations for. I think we should defend CBOR from a sloppy rushed approach. The DID spec registries allow us to rapidly iterate and it's necessary for those representations to survive and be useful. 16:27:42 ack ivan 16:27:43 Orie: I think it's dangerous to keep it in DID core when no one is doing anything with it. I propose both CBOR and DagCBOR move to other specs and be registered in the DID spec registries. 16:27:58 q+ to ask if the Editors can have some RESOLUTIONS to refer to when doing these PRs. 16:28:20 ivan: My original only comment was that if we take out DagCBOR from the current document, we should publish it separately as a NOTE and don't lose it. It's not mature enough to become a recommendation but it may become one in a later iteration of the WG and we keep that up. 16:28:41 I think did core should reserve the mime types for cbor, and point to the registry 16:29:02 ivan: I can't comment on the technical content of the CBOR section. But to move the basic CBOR out of the spec because there haven't been any implementations ... moving it into a NOTE is a possibility. The fact of keeping CBOR in the doc is that it conveys a message that representations that are fairly different are also there and possible. 16:29:18 Unfortunately, the CBOR thing /isn't/ different from JSON and JSON-LD -- it's a straight translation. 16:29:32 ivan: Perhaps marking the CBOR at-risk would be a compromise to give it a chance. 16:29:39 q? 16:29:47 CBOR as currently defined is 100% equivalent to JSON / JSON-LD 16:29:53 ack justin_r 16:30:08 ... making it actually the opposite of what ivan wants. 16:30:35 justin_r: So I agree with Ivan's statement of not only the messaging that inclusion of CBOR sends outside of the group, but as a reminder inside the group that we have always claimed to be creating a specification that could be represented in a number of different ways. I fully understand that a lot of implementers will only be doing a single representation themselves. 16:30:51 justin_r: That does not mean that we should only be defining one because abstraction from a single point leads to laziness and a brittle architecture. 16:30:58 justin_r you know that CBOR representation is just CBOR(JSON) right now? 16:31:42 justin_r: I disagree with the statements in the chat just now that it was a direct translation. Then there would be zero argument to remove it. Because it would be a simple set of statements of "see this field do this". I don't have strong opinions with DagCBOR but the CBOR section can be included at the same level as the JSON/JSON-LD sections because the focus is getting things into and out of the representation. 16:32:10 justin_r: You've got the ADM and the representation and tell me how to go into/out of. Don't tell me anything else. If it includes field order, great, those are serialization rules, if we stay in those lines I think we'll be fine. 16:32:12 +1 to justin_r 16:32:14 ack manu 16:32:14 manu, you wanted to move Vanilla CBOR out... but as a NOTE, and I can volunteer to do that. and to ask if the Editors can have some RESOLUTIONS to refer to when doing these PRs. 16:32:30 manu: I put some proposals in the IRC channel to look at and modify before we potentially run them. 16:33:14 q? 16:33:16 I would like to point out that what Manu's describing is explicitly prohibited :) 16:33:29 manu: I would prefer to move the CBOR section out as a NOTE at this point. I don't feel very strongly about it. Just to highlight my statement in IRC. You can basically do CBOR by taking the JSON or JSON-LD and spinning it through a CBOR<=>JSON translator. It's effectively the same thing. Yes, some of the binary encoding is different, but, in my opinion, it doesn't utilize CBOR in a way I'd expect. 16:34:05 justin_r you are not correct. the transformation through the ADM is equivalent to what manu is saying 16:34:30 manu: It's lossless, it goes to/from ADM and for those reasons I can go along with keeping it in the spec, but I'd be surprised if implementers would choose it as their CBOR encoding. I'd expect them to do something more compact, maybe doing artisinal CBOR or doing something more dynamic like CBOR-LD. I'd be surprised if people used the lazy conversation as the CBOR representation they prefer. 16:34:31 its not the only way to do it though 16:34:58 manu: That's the strongest reason I think to move it out, it's a bit of weird encoding. Also, I don't know any implementers that plan on using it. I would love to hear from the group if there are any implementers excited to use it and "for reason X". 16:35:01 q? 16:35:18 manu: I'm happy to volunteer to take it out an put it in its own spec and it would be good to have an example of using the DID spec registries to register it. 16:35:21 ack jonathan_holt 16:35:32 q+ to put some resolutions in. 16:36:11 jonathan_holt: The entire point of going down the road with an ADM is to facilitate lossless translations to/from the ADM. CBOR is critical to that. As I showed, it's a binary representation. So it's a lot easier/more straightforward transformations into other formats. I think that's the point to facilitate that. 16:36:27 jonathan_holt: I don't like the characterization of Vanilla CBOR or lazy CBOR. 16:36:40 q+ 16:37:16 q- later 16:37:22 jonathan_holt: I think that's unfair, when talking with Jim Schaad about the discussion around JSON/CBOR they settled on a compromise to ensure there's lossless translations. I'm not opposed to the artisinal approach with ints as keys, and that's a great use of the DID spec registries since all properties need to be registered there. If we register an int with each one that would be great. 16:37:37 +1 to jonathan's point regarding registering properties that cbor might make use of 16:37:51 q+ to talk about "lossless and ints as keys" 16:37:54 jonathan_holt: I would hate to see the section yanked because I spent so much time on it, I would use it, I can settle on CBOR since DagCBOR isn't there. I think there's another implementer [missed] as well. He'd leverage the CBOR section just as I am. 16:38:51 Issue is not inviting others, it's that they needed to be here 4 or more months ago. 16:38:54 jonathan_holt: I was hoping to get the IPFS community involved in W3C and at least a few are considering becoming members. I think it would behoove the W3C to get IPFS to come to W3C to use as their standardization body. It would be great to have their things get under the W3C lab. They have keen interest in joining and they are trying to figure out what category they fall under for the size of their organization. 16:38:54 q- later 16:39:06 ack markus_sabadello 16:39:10 jonathan_holt: I would hate to have them rally to participate in this discussion only to have a non-receptive ear when they join. 16:39:58 markus_sabadello: I wanted to support Jonathan's view that there was strong interest in having a CBOR representation. I also think that it's important to have that to illustrate why we did the ADM. I agree with Jonathan on that. It's in pretty good shape. My personal preference would be to keep that in DID core but remove DagCBOR. 16:40:04 +1 to markus_sabadello 16:40:06 ack justin_r 16:40:06 justin_r, you wanted to talk about "lossless and ints as keys" 16:41:14 justin_r: I think having maps with ints as keys -- the production and consumption rules with the ADM allow translation into and out of a representation. If the CBOR community wants to and likes to do that, it's a very clear message to other representations that you can call a property whatever you like in your serialization as long as you can get it in/out in a deterministic fashion. 16:41:21 ack manu 16:41:21 manu, you wanted to put some resolutions in. 16:41:23 justin_r: You aren't bound to do just a lazy translation as has been claimed. 16:41:25 For reference, notes from a Topic Call on CBOR last year: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-09-10-did-topic 16:41:30 manu: Just to run a couple of proposals. 16:41:38 PROPOSAL: All canonicalization algorithms will be removed from, and no new canonicalization algorithms will be added to, the DID Core specification. 16:41:54 q+ 16:41:59 ack justin_r 16:42:18 justin_r: I would just like to see a list of what is considered a canonicalization algorithm because that could be a wider net than I'm interpreting that as. 16:42:25 q+ 16:42:49 manu: There is specifically the CBOR canonicalization algorithm that is in the CBOR section right now. Presumably the DagCBOR canonicalization algorithm that exists outside of the spec and isn't referenced but was planned to be pulled into the spec. 16:43:03 manu: Right now there's only one, there were plans to be two, and the group is saying: We don't want any. 16:43:45 To be clear, I agree with the scope statement, I am worried about the interpretation 16:43:47 burn: It is the determination of the chairs that defining a canonicalization algorithm is out of scope. This determination has already been made and your proposal just captures what will happen. 16:43:56 q+ 16:44:02 q+ 16:44:54 q+ 16:44:57 ack jonathan_holt 16:45:02 s/of the chairs/of the chairs, in consultation with the team contact,/ 16:45:22 jonathan_holt: I'm agreeing with Justin, there's no algorithm. With a list of items -- there are 5, they are constraints. To get to determinism. The only algorithm is sorting of the order of the mpa. 16:45:24 s/mpa/map/ 16:45:31 q+ to note that this is why I'm trying to get a resolution down. 16:45:35 jonathan_holt: In which case, ordered maps is the algorithm. That's it. 16:45:40 ack ivan 16:45:41 +1, I'm not seeing any algorithm here 16:46:20 q+ to try a new proposal 16:46:30 ivan: As Dan said, canonicalization is out of scope is a state, we don't have to vote on this. We are over-administrating ourselves. We also had a proposal to take DagCBOR out of the spec into a NOTE. If that's accepted, that makes part of this moot. This is a bit of loss of time. 16:46:40 ivan: We can discuss what to do with the CBOR section if we keep it in. 16:46:51 I'm fine with moving dagCBOR as a note and would like to see it in did-spec-registries 16:46:53 ack justin_r 16:47:24 justin_r: To echo what I said in the chat, I'm not seeing a canonicalization algorithm. I know Manu and Ivan have said they are dropping this specific proposal. 16:47:59 +1 to justin_r , 16:48:03 justin_r: I'm fine with that. I just read through the CBOR section and it gives you rules for producing CBOR, it's not changing the data model at all. It's no more canonicalization than saying each value of the JSON array is added in order. It's telling you how to create the objects in the underlying representation. 16:48:13 ack markus_sabadello 16:48:22 +1 to junsin_r too. 16:48:26 https://w3c.github.io/did-core/#production-1 16:48:42 +1 to markus_sabadello 16:48:44 To produce a deterministic canonical CBOR representation of a DID document and faciliate maximal lossless compatiblity with other core representations via the Abstract Data Model the following constraints of a CBOR... 16:49:07 ^ quoted 16:49:08 markus_sabadello: I don't think it's a problem to remove the word "canonical" from the sections and then maybe everyone is happy. Regarding the one rule that says ordering the keys in the map -- is that important or could that also be removed? 16:49:17 Orie: Right, remove the word "canonical", the rest can stay 16:49:20 jonathan_holt: It would be nice to have it in that format. 16:49:32 jonathan_holt: For determinism it's needed. 16:49:48 q+ 16:50:02 jonathan_holt: Order matters just like order matters for a naked array, there's meaning behind the order. In an infra ordered map, we're agnostic but it could be important for the producer. 16:50:03 q+ 16:50:08 ack manu 16:50:08 manu, you wanted to note that this is why I'm trying to get a resolution down. and to try a new proposal 16:50:28 PROPOSAL: The DagCBOR representation will be moved into its own specification and registered in the DID Spec Registries. 16:50:30 +1 16:50:32 +1 16:50:33 +0 16:50:33 +1 16:50:34 +1 16:50:34 +1 16:50:36 +1 16:50:36 +1 16:50:37 +1 16:50:39 agropper_ has joined #did 16:50:40 +1 16:50:41 0 16:50:42 +1 16:50:44 +1 16:51:08 +0 16:51:13 dag+cbor to the moon! 16:51:18 RESOLVED: The DagCBOR representation will be moved into its own specification and registered in the DID Spec Registries. 16:52:38 q+ to ask what makes it `at risk` 16:52:46 manu: We do both proposals from both ways to see if there's one that gets more support than the other, just because you -1/+1 one doesn't mean you'll do the same in reverse. 16:52:53 PROPOSAL: The CBOR representation will be moved into its own specification and registered in the DID Spec Registries. 16:52:57 +1 16:52:58 +1 16:53:00 -1 16:53:00 +1 16:53:01 -0.9 16:53:02 -1 16:53:03 +1 16:53:04 -1 16:53:06 -1 16:53:07 -1 16:53:11 -1 16:53:13 -1 16:53:23 0 16:53:33 PROPOSAL: The CBOR representation will be kept in the DID Core specification as an at-risk representation. 16:53:37 +1 16:53:38 +1 16:53:38 -0.5 16:53:41 +1 16:53:45 +1 16:53:45 +1 16:53:46 +1 16:53:47 +1 16:53:50 +1 16:53:51 +1 16:53:52 -1, what makes it at risk? 16:53:55 +0.5 16:54:00 +0.5 16:54:21 brent: We add the at-risk flag so that if circumstances require us to remove it from the spec during CR we don't have to enter another CR phase. 16:55:20 manu: No formal objection from me. 16:55:31 brent: Jonathan will you formally object to marking it at-risk? 16:56:50 ivan: The only role of at-risk is to make sure we don't get into trouble if we don't have two interop implementations -- if you are confident we'll get to that it doesn't matter. 16:57:51 q+ 16:58:06 q- 16:58:12 RESOLVED: The CBOR representation will be kept in the DID Core specification as an at-risk representation. 16:58:38 jonathan_holt: I will not formally object. 16:59:08 q- 16:59:24 ack ivan 16:59:46 And writing tests is also important to be able to keep a section in! For everything! 16:59:52 clarification: ordered maps, not lists 16:59:59 lists are explicitly ordered in both places 17:00:04 ivan: We say in the spec that infra doesn't have an unordered structure that we need and we say in the spec we don't care about the order. 17:00:11 +1 justin_r 17:00:18 that's a problem with the signing alg not the representation 17:00:18 ordered set, not list 17:00:33 https://infra.spec.whatwg.org/#sets 17:00:35 brent: Thank you all for joining in the conversation and thanks to the scribe. 17:00:53 zakim, end meeting 17:00:53 As of this point the attendees have been burn, ivan, adrian, TallTed, dlongley, brent, agropper, shigeya, manu, jonathan, JoeAndrieu, markus_sabadello, rhiaro, drummond, wayne, 17:00:57 ... orie, justin_r, dmitri, jonathan_holt, dbuc 17:00:57 RRSAgent, please draft minutes 17:00:57 I have made the request to generate https://www.w3.org/2021/02/02-did-minutes.html Zakim 17:00:59 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 17:01:03 Zakim has left #did 17:01:38 RRSAgent, make logs public 17:01:52 rrsagent, bye 17:01:52 I see no action items