<scribe> scribenick: dlongley

Agenda review, Introductions, Re-introductions

burn: I'm going to change the agenda, I've got a proposal to change it, let me send this out.

<burn> 1-Agenda review, Introductions, Re-introductions (5 min) 2-Unassigned issues [1] (5 min) 3-PR review [2] (20 min) 4-Open Issues Review [3] (5 min) 5-Vote to publish CR? (20 min) Links [1] https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee [2] https://github.com/w3c/vc-data-model/pulls [3] https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Adefer

burn: We don't have any unassigned issues ... at least we didn't 10 minutes ago. I hope we do not, I'll confirm. Then we'll look at PRs and then maybe only one issue. The primary goal today is to vote to publish a CR document.
... This is a very unusual call. Those joining for the first time -- this is a very different call, I'll be very very hard nosed.
... The chairs have been given conflicting info on whether this group needs to publish a CR doc to get an extension. We recently heard some more concerns about it. Unless someone on this call says they will officially block CR, we are looking for votes in support of publishing. This is to get our extension and to continue our work that we need to do.
... If anyone is unclear about that I will ask again when we get to the CR stage. Intros ... anyone joining us for the first time today?

no one

burn: No reintroductions, any questions about the agenda?

none

unassigned issues

<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee

burn: We have unassigned issues. I have labeled or triaged all of them at this point. Not looking to assign anyone today, we're trying to make sure we have time to get to the critical item today. We can come back and get assignments at the end if necessary.
... Any concerns with going that today?

none

PR review

burn: The next thing I want to do is look at the PRs.

<burn> https://github.com/w3c/vc-data-model/pulls

burn: We have a really full crew today on the call, thank you everyone.
... Looking at the PRs ... we have four PRs, two are ones created in response to comments from the i18n group at W3C. Chaals has been working pretty heavily with them over the last 24 hours. Some of those comments they wanted addressed before entering CR and others they were ok with us delaying as long as those editorial comments could be discussed later.
... Like edits to the examples. The goal was to get into these PRs the number and type of changes necessary for the i18n group to be ok with us publishing a CR doc.
... Chaals could you talk to this?

<kaz> pr 469

chaals: Sure. 469 is pretty straightforward. At this state it just adds language information using the mechanisms that are allowed already by JSON-LD to show how they work so people understand that you may get information with language tagging and you need to process it.
... 454 is purely editorial, it takes i18n considerations and talk about things you need to think about in your work and JSON-LD allows for a set of different approaches to managing language information. It is currently really weak on text direction, unfortunately, there is only one reliable way of dealing with that and you will run into the need to do things with text direction if you aren't stuck in your little silo and this shows how that will work.

burn: Ok, thank you.
... Here's what's going to happen, I'm leading up to a formal request for publishing the CR document. That proposal will say "as amended by the PRs that we have approved today."
... So I'm going to be looking for approval to merge specific PRs today, including those two.
... I will include those by reference.
... I understand that those are new PRs -- most of you haven't seen them. For those who have opinions on those things, I'd like you to take a look *now* at them.
... My first question is, is there anyone on this call you does not believe they can make a decision on approving application of those PRs at this time.

no one

burn: Ok. I will begin with 454.
... Any objections to us applying and merging 454, understanding that it will become part of the CR vote later today?

no objections

burn: No objections.

<chaals> [+1 to merge 454]

<kaz> pr 454

<TallTed> I would suggest including a day or two window for "omg, not that!" upon seeing the doc with those PRs merged, in the CR proposal

<burn> ACTION: merge PR 454

burn: Ted, that's a good suggestion.
... I want to ask you about that. We have a practical consideration and that is the amount of time that we have to allow from when we make the request and the time the publication occurs. I would prefer not to have to do that. In practice, I am going to be spending the rest of the day making minor administrative edits to get it into shape for publication.

TallTed: I'm not trying to block the CR resolution by any stretch. It has happened to me on occasion in the past, and for whatever phrasing didn't make sense and it ended up being problematic in whole cloth.
... I'm between a rock and a hard place and the policies are built that way but we're stuck with it.

burn: I need to prepare the document anyway that will go into the transition request. That will take me at least today to do and there is back and forth between me and Kaz, possible won't go out until tomorrow morning. In any case, approval is not immediate. I would like to propose that we go ahead with the vote and the process to request publication. If, within 48 hours from this call, someone says -- "OMG, this didn't go in the way I expected."
... "Those PRs clash in a terrible way, you've applied it wrong" or something like that.
... Then we will cancel the transition request and do what we need to address that. Would that be acceptable?

TallTed: Yeah, that's acceptable. I just want that small window.
... So 30 hours of review.

burn: It wasn't 30 hours of review, it's until Thursday at this time.
... If you want 48 hours from the time it comes out I can't argue with that.

TallTed: That's legit.

burn: 48 hours from the time that the document is finalized enough for us to send a transition request.

<scribe> ACTION: Dan will send out a pointer to the list for that document.

burn: This is not for commas or minor editorial changes.
... There are typos that sometimes have to be fixed, but it's not an open season on the spec.

(this is for OMG)

ken: Amy and I were assigned on issue 394 for normative language in non-normative languages. One of those popped up -- and Amy brought up a list of eight items and I haven't reviewed all of hers and there might be a problem with normative language in a non-normative section so we might need to close that out.

<rhiaro> Only 3 of my items were about normative text in non-normative sections

burn: Does that mean you are making a statement that you can't vote today for CR without those changes?

ken: No, but I don't know the rules on that.

<rhiaro> Also I think normative language in non-normative sections are not blocking

ken: Just trying to bring that to your awareness.
... None of the other comments I filed ... I don't believe any of the other ones are CR blockers.

burn: I'm going to make a statement that there are things that you normally want fixed before CR -- things that you MUST fix before CR, but what I'm really concerned about are things that could lead us into a discussion that delay us too long to actually have a vote.

<rhiaro> +1 chaals

chaals: Just to be clear about normative text in non-normative section; the non-normative section is NON-NORMATIVE. It's just a confusing editorial process rather than the universe maybe blowing up.

ken: Thank you, I would leave it until after CR to fix that then.

<dlongley> +1

<brent> seems like fixing normative text in a non-normative section is an editorial change.

burn: That's also how I understand it. The section is non-normative.

chaals: There are legitimate sensible cases where normative language is quoted in non-normative sections.

burn: We did agree here to merge PR 454.
... So let me ask about 469. Any objections to applying PR 469 as well?

<TallTed> As I recall, *editorial* changes (typos, punctuation, etc.) are acceptable between CR (Candidate Rec) and PR (Proposed Rec) -- so I think those should be fine to raise at this point; they just shouldn't be CR TR (Candidate Rec Transition Req) blockers.

<kaz> pr 454

<kaz> pr 469

burn: So Ted is pointing out that non-normative text may be changed in the CR phase. Between entry to CR and close of CR. They are ok to raise at this point, I just want to make sure that we get to a vote. They are good to know about.
... I would frankly prefer to not hear about them until we vote about CR. I'd like to get that done. But then they are absolutely great.

<TallTed> Yes, hold those to after the vote. My point is that they're OK to raise during the 48hr crash-review.

burn: I have added a label into the github repo and that is "Clarification". I don't like "Editorial". People use that to mean non-normative. I dislike that use of the term. Editorial is something that the editor can apply or modify at their discretion. A clarification is also permitted between CR and PR and that's a change that you make to non-normative text that might require the group to agree on, so not editor doing whatever they want.
... Use cases are a good example of that.

brent: What about a non-normative change to normative text. Or a non-normative clarification added to a normative section.

burn: We'll get to that, let me get through the i18n PR section first then your issue is next.
... Any objections to merging 469?

jonathan: I'm just looking at the content of the PR. Is it really using "spans" in the JSON or is that for presentation in the spec?

chaals: So you have a piece of HTML inside the string, that is one of the ways in which you can identify the language unambiguously.

jonathan: So in the VC there are HTML tags in the JSON payload.
... Is that commonly done?

chaals: Define commonly.

jonathan: I wasn't anticipating having to parse HTML.

chaals: It's a long standing practice.

jonathan: Ok, thank you.

<TallTed> inconsistent markup for those... `"alumniOf": "&lt;span lang='fr-CA'>` vs `"alumniOf": "<span lang='en'>`

burn: Any objections to merging PR 469?

TallTed: Not an objection, there is some inconsistency in it.

burn: A quick comment to this is fine and these two are the critical issues for this today. Chaals a response to Ted?

chaals: Just a matter of going into the thing to get the right brackets to show up in the doc.

jonathan: My only reservation here is that it could be a security vulnerability. If any HTML can be there it could be a problem.

chaals: You could, don't. Nobody accepts HTML like that. Everyone sanitizes that and throw away bad content.

burn: Jonathan, do you need to respond to that?

jonathan: No, I'm good. I don't want to hold it up, if this is common practice I don't want to hold it up. I was just kind of surprised, wasn't expecting to see HTML in JSON. If there's a better way of doing it like in the JSON-LD 1.1 spec that would be great.

burn: CR is an implementation phase. If it turns out from implementation that this doesn't work we should have appropriate discussions about it.

jonathan: Right, just surprised, won't hold it up. Don't have an expert opinion about it.

burn: Any other discussion on this PR?
... Chaals will patch the PR to deal with the bracket inconsistency.
... We'll come back to this one because chaals will have hopefully patched this one by then.
... Moving on.
... To the best of my understanding, we have now looked at all of the PRs, assuming we merge the one Chaals is adjusting right now, we've handled all the ones that could block us for CR.
... At this point, I'd like to quickly look at the other PRs and see if there is agreement on merging them and if there's discussion, I suggest we don't include those for CR.
... PR 460. Brent?

<kaz> pr 460

brent: 460 is in response to community feedback we got for the ZKP section of the spec. They had just requested a bit more clarification. I added a single block of non-normative text to the middle of it that highlights some of the capabilities that ZKP may enable.

burn: Any objections to merging PR 460?

no objections

<burn> ACTION: merge PR 460

burn: Let's look at PR 461. Ken?

ken: This was as I did my final read through, the statement was that revocation shouldn't reveal information to the issuer and I thought that was not very understandable because the issuer already knows that information. I thought that revocation *by the issuer* shouldn't reveal that information.

<kaz> pr 461

ken: So it's a simple two line change.

<burn> ACTION: merge PR 461

burn: Joe and David Chadwick approved this. Matt not here to review, Tzviya emailed me to agree. I think this is a fine change to put in. It is non-normative and editorial in particular.
... Any objections to merge?

No objections

burn: Ok, we will merge that.
... Let me go ahead right now and merge 454.
... I'm not seeing any issues with it, I think it's editorial.
... Are they editorial or is there a lack of agreement is the question.

<TallTed> see https://github.com/w3c/vc-data-model/pull/469/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR4030

<TallTed> "image": <span class="highlight">"https://example.edu/images/58473"</span>,

burn: Is it possible I've missed something?

TallTed: It's in the total file.

chaals: That's a totally different thing. Those pieces are to highlight a particular piece of an example.

<Zakim> dlongley, you wanted to say this is editorial

chaals: You should read it in the rendered view. In the HTML in the spec.

burn: This is editorial at this point.

<dlongley> +1 totally agree, not about disagreement

TallTed: Right, that's fine.

burn: Any objections to merging PR 469?

<burn> ACTION: merge PR 469

No objections

burn: Ok, I am merging now.
... One other thing before we do the final vote.
... Someone just opened a new issue but it's just a clarification, that's fine.
... There is an issue we received 450 that we committed to providing time to on this call. I have a quick question to ask briefly. His statement is that certain concepts in this paper are derived from 0xcert, please provide a citation for referencing that. Brent?

brent: To sum up, I said that I wrote most of if not all of the ZKP stuff and had never heard of them and had tried to be kind in telling them know. I still haven't read their whitepaper so I couldn't have quoted from it.

burn: Is there anyone on this call that is aware of specific text being pulled from a whitepaper from this company?

ken: As helping on all of the ZKP stuff that Brent wrote, I have also never heard of them before. If you'd like I can comment on that as well on the issue.

<TallTed> I note they provided no link to such a "whitepaper/techpaper" (as they describe it)

burn: Just asking a straight question. Is anyone aware of specific text being pulled from a whitepaper?

JoeAndrieu: No. My question is -- if this is patented tech, doesn't that matter somewhere?

burn: They stated a whitepaper or technical paper and no one is aware of any specific text being pulled from there.
... They made a stronger statement, I don't think it's appropriate for this group to make a determination that something was derived from their work. Just wanted to make sure there was no one on this call that was aware of any specific text coming from their material.
... If no one in this group is aware of pulling text from their papers, then I don't believe that as a group today we need to take any specific action.

<JoeAndrieu> +1 to that call

burn: Brent has suggested that they check out the CCG and Rebooting work and invited them to participate in our group which is a great suggestion.

<chaals> [I have to drop in 2 minutes. +1 to move to CR]

burn: I'll put a comment to the effect that there was no one in the group that was aware of any text being pulled from any paper by them and closing the issue.
... Any objections to moving onto the CR vote?

No objections

burn: I'm going to make a proposal.

<burn> PROPOSED: Do you support publishing the draft Candidate Recommendation emailed on 18 March (https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0010.html), as modified by the PRs agreed to above, and with such editorial changes as are needed for style, typographical errors, or publication requirements?

<TallTed> +1

<brent> +1

<dlongley> +1 (Digital Bazaar supports the proposal)

<dmitriz> +1

<JoeAndrieu> +1

<SercaK> +1

<deiu> +1

<ken> +1

<agropper> +1

<nage> +1

<Allen> +1

<burn> +1 for Matt Stone

<Ned> +1

<burn> +1 for Christopher Allen

<burn> +1 for Tzviya Siegman

<burn> +1 for me

<jonathan> +1

<gannan_> +1

<rhiaro> +1

<JoeAndrieu> +1 for David Chadwick (via email)

<yancy> +1

<chaals> +1

RESOLUTION: Do you support publishing the draft Candidate Recommendation emailed on 18 March (https://lists.w3.org/Archives/Public/public-vc-wg/2019Mar/0010.html), as modified by the PRs agreed to above, and with such editorial changes as are needed for style, typographical errors, or publication requirements?

burn: Ok, thank you very much WG.
... In the request to transition to CR, we will be pointing to this in the minutes, which is why it's important to capture precisely.
... I'm going to update the document with these changes and any other minor things we realize are necessary, including the list of changes since the last working draft.
... We will submit the transition request -- a number of people will comment on that, chairs of WG, comm team, W3C admin, including the director or acting director who might have questions for me or the editors. If all of that goes well, it will be published a week from today.
... What I'd like to ask -- people will look at our github repo. I will try to stay on top of it.
... What I was just going to say is that it would be great if you could hold off on sending in a flood of issues.
... If the director sees 40 issues then we have to say which means we can do CR and which we cannot. Let's hold off until the end of the review period, 48 hours after I send the link to the fixed document.
... Is there anything anyone would like to discuss today, I'd prefer not to merge anything at this point. Anything anyone would like to discuss?

jonathan: Looking at this whitepaper I don't see any ZKPs in their whitepaper and they'd like to have a DID method but haven't submitted enough there -- etc.

burn: Would be good for them to be involved in the CCG it looks like.
... Any other questions for today?

None

burn: If you have any questions about process you can say publicly or send to me privately. If there are no other comments, then thank you and enjoy your 6 minutes back! Talk again next week.