14:05:36 <RRSAgent> RRSAgent has joined #vcwg
14:05:41 <RRSAgent> logging to https://www.w3.org/2023/10/04-vcwg-irc
14:05:41 <Zakim> RRSAgent, make logs Public
14:05:42 <Zakim> please title this meeting ("meeting: ..."), ivan
14:06:08 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:06:09 <ivan> Date: 2023-10-04
14:06:09 <ivan> Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231004T110000/
14:06:09 <ivan> chair: kristina
14:06:09 <ivan> ivan has changed the topic to: Meeting Agenda 2023-10-04: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231004T110000/
14:56:32 <pauld_gs1> pauld_gs1 has joined #vcwg
14:58:11 <hsano> hsano has joined #vcwg
14:58:50 <ivan> present+
14:59:36 <decentralgabe> decentralgabe has joined #vcwg
14:59:48 <hsano> present+
15:00:03 <ivan> present+ pauld
15:00:06 <DavidC> DavidC has joined #vcwg
15:00:12 <DavidC> present+
15:00:22 <Orie> Orie has joined #vcwg
15:00:30 <ivan> present+ orie, kristina
15:01:03 <ivan> present+ brent
15:01:09 <kristina> kristina has joined #vcwg
15:01:12 <kristina> present+
15:01:42 <brent> brent has joined #vcwg
15:01:50 <brent> present+
15:02:25 <ivan> present+ manu, dlongley
15:02:45 <ivan> present+ seabass
15:02:52 <manu> present+
15:02:58 <TallTed> TallTed has joined #vcwg
15:02:58 <shigeya> present+
15:03:20 <Will> Will has joined #vcwg
15:03:22 <Will> present+
15:03:32 <ivan> present+ TallTed
15:04:06 <ivan> present+ selfissued
15:04:25 <ivan> present+ benjamin
15:04:48 <GregB> GregB has joined #vcwg
15:04:57 <GregB> present+
15:06:49 <bigbluehat> scribe+
15:06:59 <cabernet> cabernet has joined #vcwg
15:07:00 <cabernet> present+
15:07:04 <andres> andres has joined #vcwg
15:07:08 <bigbluehat> kristina: I expect us to spend a good bit of time on PRs today
15:07:08 <andres> present+
15:07:14 <bigbluehat> ... many things are blocked
15:07:18 <decentralgabe> present+
15:07:26 <ivan> present+ cabernet
15:07:35 <bigbluehat> ... they should be labeled, but some may not be, so we may consult others if time
15:07:37 <ivan> present+ joeandrieu
15:07:53 <bigbluehat> ... manu raised Data Integrity PR reviews as needing to be addressed
15:08:02 <ivan> present+ gregb
15:08:18 <kristina> q?
15:08:38 <manu> q+
15:08:39 <bigbluehat> ... anyone want to start with a PR or status update?
15:08:42 <DavidC> q+
15:08:51 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:08:52 <ivan> Topic: PR status updates
15:08:56 <kristina> ack manu
15:09:03 <bigbluehat> ... DavidC are you queued to talk about ToS topics?
15:09:13 <bigbluehat> manu: do you want these in oldest to newest order?
15:09:24 <bigbluehat> kristina: probably skip 1271
15:09:32 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1270
15:09:46 <bigbluehat> manu: so, 1270  has multiple requests for changes
15:10:00 <bigbluehat> ... selfissued is blocking. Orie is blocking
15:10:01 <Orie> q+
15:10:06 <bigbluehat> ... what changes need to be made?
15:10:07 <selfissued> selfissued has joined #vcwg
15:10:12 <selfissued> present+
15:10:16 <manu> scribe+
15:10:18 <bigbluehat> 1270
15:10:23 <decentralgabe> https://github.com/w3c/vc-data-model/pull/1270
15:10:40 <selfissued> q+
15:11:29 <kristina> ack Orie
15:12:08 <bigbluehat> Orie: we have this section about JSON processing...which I don't really like
15:12:31 <bigbluehat> ... I'd believed we would/should add a JSON-LD section to explain applying `@context` more completely
15:12:46 <bigbluehat> ... and these two things differ substantially when you just process JSON
15:12:58 <bigbluehat> ... I think the text in the JSON processing section is dangerous and misleading
15:13:14 <bigbluehat> ... that text is mostly information that doesn't help implementers
15:13:17 <dlongley> -1 to what Orie is saying :) ... the information is the same, JSON-LD is a syntax that expresses graph information.
15:13:24 <bigbluehat> ... and doesn't help people use RDF or JSON-LD
15:13:37 <bigbluehat> ... so the changes I want to see are to remove these differences
15:13:58 <bigbluehat> ... bigbluehat's comments are excellent
15:14:07 <PL-ASU> PL-ASU has joined #vcwg
15:14:07 <PL-ASU> present+
15:14:12 <bigbluehat> ... he says there dangers of doing just JSON processing
15:14:32 <bigbluehat> ... it's a huge mistake for us to be vague
15:14:45 <bigbluehat> ... and this will harm interop if these things differ too much
15:14:59 <bigbluehat> ... the JSON-LD processing section needs to talk more about RDF data model
15:15:07 <bigbluehat> ... `@id`, `@list`, etc.
15:15:21 <bigbluehat> ... basically the stuff that's in the `@context` that only an advanced processor would use
15:15:31 <bigbluehat> ... I strongly disagree with the position that dlongley stated
15:15:48 <bigbluehat> ... that we should avoid the JSON-LD feature to keep it compatible with JSON processing
15:16:10 <bigbluehat> ... bigbluehat's PR has some of this, but not enough which is why I'm requesting changes
15:16:13 <kristina> ack selfissued
15:16:26 <bigbluehat> selfissued: this PR kind of runs at the mouth
15:16:30 <kristina> +1 to json processing is not compatible with JSON-LD processing (without additional checks on top co json processing)
15:16:37 <bigbluehat> ...it says a lot of things that aren't useful to implementers
15:16:49 <bigbluehat> ... we don't need to be an evangelist mouth piece for JSON-LD
15:16:55 <kristina> q?
15:17:01 <dlongley> q+
15:17:02 <bigbluehat> ... I will not approve this until it's down to a sentence or a paragraph
15:17:08 <TallTed> q+
15:17:12 <kristina> ack dlongley
15:17:24 <bigbluehat> dlongley: trying to figure out where to start
15:17:28 <Orie> I would encourage better direct references to the JSON-LD spec, for example: https://www.w3.org/TR/json-ld11/#relationship-to-rdf
15:17:33 <bigbluehat> ...there are many competing requests
15:17:47 <bigbluehat> ... many from Orie requesting explanation of the advantages of JSON-LD
15:18:01 <kristina> chairs hat on, i don't think the request was "json-ld advantage" it was about "json-ld processing guide"
15:18:13 <Orie> I disagree that the PR captures the advantages on JSON-LD, but I agree that is an objective... and I think citing the JSON-LD spec, would better accomplish the mission.
15:18:19 <bigbluehat> ... new comers are often confused by the ability to process JSON-LD further with libraries
15:18:29 <bigbluehat> ... but they miss that JSON-LD is a syntax
15:18:42 <bigbluehat> ... if you understand the `@context`, then you can move ahead
15:18:58 <bigbluehat> ... if you don't understand what's in `@context, then you do need to process that and understand it
15:19:11 <bigbluehat> ... so this section is really talking about that difference
15:19:19 <bigbluehat> ... JSON is really just a syntax
15:19:30 <bigbluehat> ... and if you want to do anything with JSON, you need a spec to read and implement
15:19:48 <bigbluehat> ... whereas JSON-LD is an object-oriented graph model that defines how to be processed
15:19:56 <bigbluehat> ... JSON-LD imposes additional constraints
15:20:17 <bigbluehat> ... so you don't have this problem of missing out on this extensibility and data model
15:20:38 <Orie> I agree with what dave is saying, that JSON-LD and JSON claims can't be merged, without understanding RDF... that is the security issue that the group is being unclear regarding.
15:20:46 <seabass> q+
15:20:58 <bigbluehat> ... the JSON processing model section basically says that if you know it's using these `@context` definitions that the spec specifies, then you can just process this in JSON--because you trust it implemented the spec
15:21:19 <bigbluehat> ... on top of that Orie has been asking on elaborating on the additional value of JSON-LD
15:21:34 <Orie> We don't have the section, we have draft text, which I don't feel is acceptable yet... the mission is still ongoing.
15:21:42 <bigbluehat> ... but now we have the counter request to remove all of this--both JSON-LD values that were requested and the JSON processing section
15:21:54 <bigbluehat> ... many of the new comers have missed the history here
15:22:09 <bigbluehat> ... that this context ability was chosen on purpose
15:22:26 <bigbluehat> ... that it provides the clarity of what the data is about referenced from that data
15:22:40 <Orie> Agree with what dave is saying about JSON-LD providing value to W3C Verifiable Credentials, hence the need to communicate the value of JSON-LD and RDF processing as opposed to "JSON Processing", which does not require reading the JSON-LD spec, to do safely.
15:22:43 <selfissued> q+
15:22:55 <Orie> +1 to landing the PR, after revising it.
15:23:09 <bigbluehat> ... it's valuable to explain this value and how it helps and has helped this community since the beginning
15:23:15 <bigbluehat> kristina: I don't think we don't want to have this section
15:23:26 <bigbluehat> ... it feels like there's more discussion needed for this PR
15:23:34 <bigbluehat> ... it's not like this needs huge conversation
15:23:40 <bigbluehat> ... so lets entertain the queue
15:23:43 <manu> q+ to move on to next issue.
15:23:55 <bigbluehat> ... but keep it sort and sweet to exactly what you want to see here
15:24:02 <kristina> ack TallTed
15:24:05 <bigbluehat> ... not debate the values of JSON-LD etc.
15:24:23 <bigbluehat> TallTed: I started off being extremely frustrated by two voices in this conversation
15:24:36 <bigbluehat> ... both are asking for vague changes with no specific changes
15:24:43 <Orie> If the working group agrees, I am happy to author an alternative PR
15:24:50 <bigbluehat> ... I kinda want to lock Orie and selfissued in a room and let you hash it out
15:24:58 <bigbluehat> ... but I don't think that's going to be useful
15:25:07 <bigbluehat> ... and others should support you if they agree
15:25:15 <bigbluehat> ... Orie's been asking for this for months
15:25:26 <bigbluehat> ... but without any actual contribution to the conversation
15:25:26 <Orie> IMO its better to refer to a spec, than it is to mischaracterize the benefits of a spec, without references.
15:25:36 <bigbluehat> ... he hasn't put the concrete suggestion forth
15:26:02 <bigbluehat> ... and selfissued if you want this down to a sentence, then write that sentence
15:26:06 <bigbluehat> ... otherwise you're just blocking to block
15:26:19 <bigbluehat> kristina: this is an inclusive environment
15:26:29 <bigbluehat> TallTed: you're spending more time on this than anyone
15:26:34 <bigbluehat> ... let's move onto the queue
15:26:41 <bigbluehat> kristina: please leave the call TallTed
15:27:22 <bigbluehat> brent: ivan please remove TallTed from the call
15:27:30 <kristina> q?
15:27:44 <kristina> ack seabass
15:27:57 <Orie> My offer to author an alternative is sincere, we may find that merging 2 different PRs is an effective path forward.
15:28:06 <manu> yes, please write something Orie ^
15:28:12 <Orie> will do
15:28:18 <bigbluehat> seabass: my comment was related to dlongley's comment earlier
15:28:26 <kristina> ack selfissued
15:28:26 <bigbluehat> kristina: ok. skipping
15:28:39 <bigbluehat> selfissued: strangely related to what TallTed was saying
15:28:49 <bigbluehat> ... I do have a specific action
15:28:55 <bigbluehat> ... put this in a note, and reference the note
15:28:56 <manu> q+ to suggest line in imp guide
15:29:07 <manu> q+ to suggest text in imp guide
15:29:17 <bigbluehat> ivan: clarification. you mean a separate note, correct?
15:29:20 <bigbluehat> selfissued: yes.
15:29:54 <bigbluehat> kristina: there is a separate JSON-LD spec...so I'm not sure a separate note gets us much
15:30:05 <Orie> IMO, its worth highlighting the parts of the JSON-LD spec that can provide the most value to Verifiable Credentials.
15:30:09 <bigbluehat> ... please offer concrete PRs with concrete suggestions Orie
15:30:13 <bigbluehat> ... and we can move from there
15:30:20 <Orie> yes, i will do a PR.
15:30:21 <bigbluehat> ... Orie is that OK?
15:30:24 <kristina> q?
15:30:31 <kristina> ack DavidC
15:30:45 <manu> q-
15:30:45 <dlongley> +1 to see something from Orie ... but also note, Orie, I think there may be more benefits to VCs that you're thinking of (including all of the ones in the PR of that subtopic)
15:31:00 <DavidC> https://github.com/w3c/vc-data-model/pull/1295
15:31:02 <dlongley> s/VCs that/VCs than/
15:31:12 <manu> q+ to process PR 196
15:31:13 <ivan> subtopic: https://github.com/w3c/vc-data-model/pull/1295
15:31:33 <bigbluehat> DavidC: no one had implemented this on the v1 data model, but there have been some now
15:31:45 <bigbluehat> ... to the best of our knowledge there are several now
15:32:06 <bigbluehat> ... the problem now is that the original term was generic
15:32:20 <bigbluehat> ... and my original PR was to improve it to make it more encompassing
15:32:41 <bigbluehat> ... the v1 had generic text, but talked about mandatory things to do...which was not equally generic
15:32:56 <bigbluehat> ... so this PR makes the actions also be generic
15:33:10 <bigbluehat> ... then the comments came to provide examples
15:33:18 <bigbluehat> ... so I did that with real URIs, etc.
15:33:42 <bigbluehat> ... but then the feedback came about the URI's and that they may not be around as long as the spec
15:33:55 <bigbluehat> ... so now I think the data model should have the generic text
15:34:02 <ivan> present+ dmitri
15:34:05 <bigbluehat> ... and we should point to an extension space for these
15:34:35 <bigbluehat> ... so my proposal is that if we want the EBSI example to be the example, then we'd have to explain it all
15:34:44 <Orie> q+
15:34:55 <bigbluehat> ... or we could make it a generic example...but then it wouldn't be a good example
15:35:13 <manu> q+ to speak to examples in spec.
15:35:15 <bigbluehat> kristina: so the question I have is proving that there are two implementations in the example--is that what we want to see?
15:35:19 <manu> q-
15:35:20 <manu> q+ to speak to examples in spec.
15:35:30 <bigbluehat> ... how the use of the ToS seems underspecified
15:35:37 <DavidC> q+
15:35:38 <kristina> ack Orie
15:35:43 <bigbluehat> ... so how can that be improved --that's the question I want addressed
15:35:50 <bigbluehat> Orie: I want to thank DavidC
15:36:01 <bigbluehat> ... he's been good about addressing feedback
15:36:23 <bigbluehat> ... there's some v1 stuff that still needs removed, but overall this seems ready for tests to be written for
15:36:35 <bigbluehat> ... once there's two tests we can merge this
15:36:39 <kristina> w?
15:36:39 <kristina> q?
15:36:42 <kristina> ack manu
15:36:42 <Zakim> manu, you wanted to speak to examples in spec.
15:37:05 <bigbluehat> manu: the examples in the spec are non-normative, so the URL's in them shouldn't matter
15:37:21 <bigbluehat> ... DavidC has proved that there are multiple extensions
15:37:30 <bigbluehat> s/extensions/implementations
15:37:36 <bigbluehat> ... there is v1 cleanup
15:37:48 <bigbluehat> ... but I am confused about testing the extensions
15:37:51 <Orie> q+
15:38:10 <bigbluehat> ... feel like goal posts are being moved unless we're being very clear about what needs testing
15:38:18 <bigbluehat> ... multiple people are using it
15:38:24 <bigbluehat> ... there is a separate test suite
15:38:33 <bigbluehat> ... and I think that tests that it's being used
15:38:40 <ivan> present+ nsteele
15:38:40 <kristina> ack DavidC
15:38:44 <bigbluehat> ... so not sure we need to take on the interop tests
15:38:59 <bigbluehat> DavidC: I accept that it's v1 because it's based on their existing work
15:39:03 <bigbluehat> ... I can upgrade it to v2
15:39:21 <bigbluehat> ... I realized it takes more than swapping out the contexts
15:39:34 <bigbluehat> ... and that an additional EBSI context needs to be defined now
15:39:39 <bigbluehat> ... to work with the v2 data model
15:39:54 <bigbluehat> ... however, I don't think I should be describing how EBSI works
15:40:08 <kristina> ack Orie
15:40:11 <bigbluehat> ... maybe I can just say, this is implemented according to the EBSI spec and link there
15:40:17 <bigbluehat> Orie: this is about testing
15:40:29 <bigbluehat> ... my request is about removing that "at risk" flag
15:40:41 <bigbluehat> ... to do that we need 2 supporting implementations that past tests
15:41:04 <bigbluehat> ... if the only normative requirement that it use an RDF type, then having an example should pass that test
15:41:12 <bigbluehat> ... I don't think there are additional tests to write
15:41:19 <manu> q+ to ask about ExampleToU as test
15:41:25 <bigbluehat> ... just share examples that can survive issuance and validation
15:41:30 <kristina> ack manu
15:41:30 <Zakim> manu, you wanted to ask about ExampleToU as test
15:41:37 <bigbluehat> manu: so Orie if I'm understanding you
15:41:53 <bigbluehat> ... then a test that says, "uses issuer defined type"
15:42:12 <bigbluehat> ... and as long as that issues and verifies, would that meet your expectation of the testing requirement?
15:42:25 <bigbluehat> manu: can we use an example in the type in the terms of use?
15:42:52 <bigbluehat> Orie: as far as I'm concerned we just need to prove that two implementations can handle these examples
15:43:09 <bigbluehat> manu: so if 2 implementations do not choke on these examples then we're fine?
15:43:28 <bigbluehat> ... and you do not believe they need to understand the Terms of Use terms?
15:43:35 <bigbluehat> Orie: I hope not.
15:43:54 <kristina> q?
15:43:56 <ivan> q+
15:43:56 <bigbluehat> manu: k. then as long as issuance and verification don't choke across two implementations, then I agree that we're good
15:44:04 <manu> q+ to cover 196
15:44:07 <kristina> ack ivan
15:44:11 <bigbluehat> DavidC: this is great, thank you.
15:44:35 <bigbluehat> ivan: to clarify, if DavidC goes through what was just discussed, then we remove the at-risk flag? correct?
15:44:37 <bigbluehat> kristina: yes
15:44:44 <bigbluehat> DavidC: do I remove them now?
15:44:46 <Orie> I left a comment similar to what ivan said on the PR
15:44:50 <bigbluehat> kristina: no, we need them tested first
15:44:59 <kristina> q?
15:45:02 <bigbluehat> ... and an issue to track
15:45:02 <kristina> ack manu
15:45:02 <Zakim> manu, you wanted to cover 196
15:45:14 <manu> subtopic: https://github.com/w3c/vc-data-integrity/pull/196
15:45:30 <bigbluehat> manu: this is a base PR for many other things
15:45:36 <bigbluehat> ... selfissued has made many requests
15:45:42 <bigbluehat> ... and I want to get through them on the call
15:45:46 <manu> https://github.com/w3c/vc-data-integrity/pull/196#pullrequestreview-1657894864
15:45:47 <bigbluehat> ... 'cause this is dragging out
15:46:09 <bigbluehat> ... selfissued, you are asking for more normative definitions where there are just examples
15:46:20 <bigbluehat> ... so the normative references you want are in other specs
15:46:23 <manu> https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/196.html#multibase-0
15:46:43 <bigbluehat> ... this preview shows these definitions have been in there for awhile
15:46:45 <selfissued> q+
15:46:55 <bigbluehat> ... it's normatively defined in the specification
15:47:09 <bigbluehat> ... the other thing is asking about the header format and how they're used
15:47:22 <bigbluehat> ... they're headers, they're doing what they've been defined to do
15:47:32 <bigbluehat> ... these are examples, so they are not normative
15:47:39 <manu> https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/196.html#resource-integrity
15:47:41 <bigbluehat> ... same thing is true for the others also
15:47:47 <bigbluehat> ... this stuff is defined in there
15:48:09 <bigbluehat> ... I can go and respond to each one, but they are all already normatively defined
15:48:09 <kristina> ack selfissued
15:48:11 <bigbluehat> selfissued: I am reading the specification
15:48:38 <bigbluehat> ... the text that you're talking about does not normatively define how to translate the alphabet to string or binary
15:49:03 <bigbluehat> ... in all cases where we're using data structures, we need to define in sufficient detail, so implementers can build implementations
15:49:22 <bigbluehat> ... I'm still doing a review, but there's similar incomplete definitions in EDSA as well
15:50:22 <manu> q+
15:50:22 <kristina> ack manu
15:50:22 <bigbluehat> ... counting on tribal knowledge isn't acceptable when we're normatively referencing something
15:50:22 <bigbluehat> manu: base encoding something is something no ones had a problem with since forever
15:50:24 <bigbluehat> ... no other spec has to define this
15:50:31 <bigbluehat> selfissued: no. you must define it in the spec
15:50:36 <Orie> @manu, you an paste in this example: https://github.com/cryptocoinjs/base-x/blob/master/src/index.js. lol
15:50:45 <bigbluehat> manu: then if I define base encoding, will you let us merge this?
15:50:49 <bigbluehat> selfissued: yes
15:51:01 <bigbluehat> manu: so you want all these things redefined directly in this spec?
15:51:05 <bigbluehat> selfissued: yes.
15:51:25 <bigbluehat> manu: there's a term, multibase prefix...and that's not defined
15:51:41 <bigbluehat> s/manu: there's a term, multibase prefix...and that's not defined/selfissued: there's a term, multibase prefix...and that's not defined
15:51:44 <manu> Here is the normative definition: https://pr-preview.s3.amazonaws.com/w3c/vc-di-eddsa/pull/63.html#multikey
15:51:54 <bigbluehat> selfissued: when I review stuff, I like to pretend I'm an implementer
15:52:05 <bigbluehat> ... and imagine whether I can build code with that of others
15:52:09 <manu> Here is the other normative definition: https://pr-preview.s3.amazonaws.com/w3c/vc-di-ecdsa/pull/42.html#multikey
15:52:10 <manu> q+
15:52:12 <bigbluehat> ... and if I can't, then I raise issues
15:52:15 <kristina> ack manu
15:52:25 <bigbluehat> manu: I have pointed directly to the normatively to the definitions
15:52:37 <bigbluehat> ... and they tell you how to build the format front to back
15:52:43 <bigbluehat> ... I can make these changes, selfissued
15:52:51 <bigbluehat> ... but every time I make a change, you request new ones
15:52:58 <bigbluehat> selfissued: I'm sorry that's the way it feels
15:53:02 <dlongley> would referencing RFC 4648 and say that the bases used are `58`, `64`, and the alphabets are `base58-btc` and `base64-no-pad`?
15:53:09 <dlongley> would that help?
15:53:14 <dlongley> https://datatracker.ietf.org/doc/html/rfc4648
15:53:24 <bigbluehat> ... but the intent is to have each of these specs completely define everything implementers need to do to implement everything
15:53:37 <seabass> q+
15:53:39 <bigbluehat> manu: can you read what dlongley just shared
15:53:48 <bigbluehat> selfissued: maybe. I'd have to looke
15:53:58 <Orie> ref'ing that RFC seems like a good move.
15:54:08 <ivan> s/looke/look/
15:54:17 <bigbluehat> manu: I can address all the comments
15:54:30 <manu> q+
15:54:45 <bigbluehat> kristina: sorry we can't pick a date
15:54:54 <bigbluehat> ... we'll continue to believe there's good intent here
15:54:57 <manu> q-
15:55:01 <bigbluehat> ... but please address these concerns seabass
15:55:02 <kristina> ack seabass
15:55:06 <bigbluehat> s/seabass/selfissued
15:55:23 <bigbluehat> seabass: it seems selfissued's main concern is anything multibase/multikey
15:55:40 <bigbluehat> ... it seems our charter includes defining these things
15:56:41 <Orie> +1 to potentially publishing multiabse as a w3c document
15:56:41 <bigbluehat> ... so, if selfissued, you take issue with these not being defined at the IETF, then a probably solution is to take these multibase/multikey stuff through the W3C process within this group
15:56:41 <Orie> s/multiabse/multibase/
15:56:46 <bigbluehat> kristina: we can talk about multibase
15:57:01 <bigbluehat> ... but I do not think it is realistic within the lifetime of the WG
15:57:22 <bigbluehat> ... in the meantime if selfissued and manu can work through the PR that would help
15:57:30 <ivan> q+
15:57:34 <bigbluehat> ... next week is IIW, but we will cancel the special topic call
15:57:39 <bigbluehat> ... but keep the main call
15:57:51 <bigbluehat> ... I think the special topic call will be about accessibililty
15:58:04 <bigbluehat> ... so seabass if you could send stuff out about it, that'd be great
15:58:19 <kristina> ack ivan
15:58:20 <bigbluehat> seabass: I will be absent for part of the coming weeks
15:58:33 <bigbluehat> ivan: next week, WG is at a EU unfriendly time
15:58:42 <bigbluehat> ... and I want to be part of the timing discussions
15:58:58 <bigbluehat> ... so you're welcome to meet and provide a time...but I may have to disapprove it after I see it
15:59:06 <bigbluehat> kristina: yeah, lets discuss offline
15:59:09 <bigbluehat> ... thx all
15:59:19 <ivan> rrsagent, draft minutes
15:59:20 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/04-vcwg-minutes.html ivan
15:59:27 <bigbluehat> ... thx for scribing bigbluehat
15:59:27 <gkellogg> gkellogg has joined #vcwg
16:00:25 <ivan> zakim, bye
16:00:25 <Zakim> leaving.  As of this point the attendees have been ivan, hsano, pauld, DavidC, orie, kristina, brent, manu, dlongley, seabass, shigeya, Will, TallTed, selfissued, benjamin, GregB,
16:00:25 <Zakim> Zakim has left #vcwg
16:00:30 <Zakim> ... cabernet, andres, decentralgabe, joeandrieu, PL-ASU, dmitri, nsteele
16:00:31 <ivan> rrsagent, bye
16:00:31 <RRSAgent> I see no action items