- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 10 Jul 2019 02:37:46 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/07/09-vcwg-minutes.html
also as text below.
Thanks a lot for taking the minutes, Manu, Dan and Amy!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
09 Jul 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0004.html
Attendees
Present
Dan_Burnett, Amy_Guy, Andrei_Sambra, Adrian_Gropper,
Dave_Longley, Ted_Thibodeau, Matt_Stone, David_Chadwick,
Dmitri_Zagidulin, Manu_Sporny, Jonathan_Holt, Ken_Ebert,
Justin_Richer, Sercan_Kum, Kaz_Ashimura, Kaliya_Young,
Tzviya_Siegman
Regrets
Brent_Zundel
Chair
Dan_Burnett
Scribe
manu, burn, rhiaro
Contents
* [3]Topics
1. [4]Describe plan for the call
2. [5]PR announcements
3. [6]Issues
4. [7]Is doc ready for PR?
5. [8]What else might block publication?
6. [9]Test Suite Issues and Discussion
7. [10]Implementation Guide
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
scribenick: manu
Describe plan for the call
burn: Plan for the call is...
... This is the same Agenda that we have typically, but an
additional set of things today... we're asking if the document
is ready for PR?
... We need to know if we're done, what else might block
publication?
... Beyond the document itself, what else is left?
... Not just the spec itself, but things that could affect the
spec? Any other topics for today?
scribenick: burn
PR announcements
<manu> [13]https://github.com/w3c/vc-data-model/pulls
[13] https://github.com/w3c/vc-data-model/pulls
[14]https://github.com/w3c/vc-data-model/pulls
[14] https://github.com/w3c/vc-data-model/pulls
manu: we only have 2 left
<manu> [15]https://github.com/w3c/vc-data-model/pull/668
[15] https://github.com/w3c/vc-data-model/pull/668
manu: was not on call where PR was approved, concerned that it
included substantive changes. W3C process team says it is
indeed a substantive change, even though all impls. did the
right thing. changing the spec will force a CR.
<rhiaro> Extending the WG for *just this one thing* seems not
unreasonable
manu: process folks suggested some options. we are talking with
W3C management shortly (chairs + Manu). options are extending
group charter, making the change and going through focused
minimal CR for that feature (28 days). Approval usually takes
about 3 weeks though. Could remove JWT section of spec and move
it to another Rec track spec, but not ideal. We are between
rock and a hard place here. It is up to W3C management on
advising us how to proceed.
<rhiaro> I forgot there was already one admin extension
manu: extending seems reasonable, but we have already gotten
our 6 months extension. Beyond that will probably require
asking membership. Which can open us up to expected objections.
<manu> [16]https://github.com/w3c/vc-data-model/pull/674
[16] https://github.com/w3c/vc-data-model/pull/674
TallTed: W3M has got to get their act together. Ours is not an
isolated instance, and it will get worse.
justin: just say the spec isn't ready. this is not the only
issue that has come up over the past few months. maybe the
group should say the spec isn't read.
<justin> +1 to long term fixes if we go there
DavidC: thx justin. wanted to say something similar. there were
other issues where we might have wanted to change the spec. if
we do another CR we should go back and fix those other issues.
<burn> -1 to fix fest that will not complete
<justin> maybe find a new SDO?
manu: chairs and i are concerned about re-opening a whole bunch
of issues. then how much more charter do we need. That would
mean going back to AC for approval. They might anyway. W3M
could just end the group. No spec. We will discuss with them.
<justin> ok
manu: going to a new SDO could be tough at this point. Would
open huge can of worms.
... WHATWG/HTML 5 battle was already an issue.
... this happens commonly in WGs. Every WG, right at the end,
says the same thing "we need to go back and do X, etc" because
the ecosystem is always changing.
<dlongley> +1 to ship -- and revise later via Evergreen
manu: so most groups just publish something to get a stake in
the ground, then switch to CG, maintenance, etc.
<stonematt> +1 to ship and evolve. we will never stop learning
and wanting to adapt/adjust.
manu: This is how groups fix these things without the arduous
task of a charter extension. we will bring up with W3M.
<ken> What's evergreen
dmitriz: spec is not ready. we will go on to update in one way
or another. have no doubt that we will fix these things in the
future.
<manu> [17]https://github.com/w3c/vc-data-model/pull/674
[17] https://github.com/w3c/vc-data-model/pull/674
<burn> +100 to ship and evolve
<dlongley> [18]https://www.w3.org/wiki/Evergreen_Standards
[18] https://www.w3.org/wiki/Evergreen_Standards
manu: DavidC, conversation has slowed down. We are at a
standstill. Background: this PR tries to explain the type of
types you can have in a VC, associated with cred subject, etc.
... think DavidC wants the language stronger with MUSTs, others
assert that was not what we intended
... this PR looks at important nuances.
... Brent suggested maybe text belongs in impl. guide, Ted
agrees, Manu agrees (at least from editorial perspective)
... group may never agree on what was always in the spec or
always intended.
... a new CR where we try to get MUSTs/SHOULDs in would
definitely push our group beyond its charter. At least in impl.
guide we can give general direction.
... need input from others.
... without other input it really shouldn't go it.
DavidC: anyone else want to contribute here?
(crickets)
DavidC: I only want one MUST. I am adamant about it. Upset
about implicit statement.
... to suggest other text is not to be in at all i feel
strongly against.
... there are other issues that need to be fixed. Would like to
understand a 1.1 process.
manu: W3C Advisory Board is aware of this kind of problem.
Trying to make it so that after a spec has been published it's
easier to continue fixing things.
<stonematt> but it requires that there is a spec to hand
over... right?
manu: as long as there's consensus. Still only a proposal,
probably not ready until next year, but we can hand spec to CG
immediately when published and have CG publish a 1.1 doc. CG
will be in charge of test suite. As long as we address
compatibility, etc. we are fine. Work doesn't stop once 1.0 is
done. Evergreen is a more formal way to do this.
... suggest reading through Wiki
<dlongley> This is the wiki Manu is referring to:
[19]https://www.w3.org/wiki/Evergreen_Standards
[19] https://www.w3.org/wiki/Evergreen_Standards
manu: it is better aligned with real world needs. But will
still be >6 months before ready.
TallTed: as the author of the word "implicit", i have many
times read the minutes involved and went with the mandatory
base type because will lower the basis for entry.
... complex activity will be a future thing. VCs issued for one
purpose will eventually be put to other purposes. Other
subjects will be needed to be added on the fly. Current
revision text says you have to put a URI pointing to your type,
whatever it is.
... doesn't sayit must be resolvable by other verifiers. Other
verifiers might not be able to get to and see these other
properties.
<manu> +1 to what TallTed is saying right now.
TallTed: by adding this text it suggests a reliability which is
not delivered. Better to leave it out and provide guidance that
indicates pitfalls.
<manu> Excellent point, Matt... no idea why I hadn't considered
that before... :)
stonematt: regardless of process track, CG or evergreen, both
require a spec to hand over. So we must publish something now
to have a spec to start from, or we can go nowhere. A 1.0 gives
us a vessel for continued discussion.
<dlongley> +1 to matt
<manu> also, +1 to what Matt is saying.
stonematt: CG would be less formal than evergreen, but in
meantime if we get to Sept. and end group with no spec, there
is nothing to hand over.
... we would be done. over. can't move to other SDO for
licensing reasons. Would only have an orphan doc in the
marketplace in an odd state.
manu: if we don't get to Rec that is correct.
DavidC: nobody wants to delay spec. everyone here wants it to
go out. a 1.1 will be essential. We all know there are
weaknesses.
<stonematt> +1 to continue working on the spec post PR
DavidC: text I wrote says you are allowed implicit types for
new attributes (?? got this wrong)
TallTed: implicit types for attributes?
<manu> DavidC: I'm talking about the top level properties in
the VC.
<manu> DavidC: Is that what you were talking about TallTed?
DavidC: 3 ways for type to be extended: top-level properties,
type of the subject (IoT device example), in the actual
properties of the subject itself (adding marks to degree
certificate). want Ted to be explicit .
TallTed: does anyone else think i was being vague?
manu: let's try something else here
... Ted is correct here, but David is making good points about
what implementers should be aware of.
<Zakim> manu, you wanted to suggest a path forward.
manu: you want to make it more normative, but if we make it
mandatory there is disagreement in the group on whether it
should be or not. That means it is substantive.
... that would force a new CR. So how can we get to something
acceptable, if imperfect, to everyone?
... list is much longer than David mentioned, but implementers
do need to pay attention to this.
... this is a problem for David in his verifier, but not for
others.
... we are not getting anywhere with current conversation.
Understanding that we absolutely are going to work on a 1.1 in
CG/evergreen, David would you be okay with taking the text,
wording it more strongly, and putting in the impl. guide?
... if we do that we still have 3 months to work out that
wording.
DavidC: no, would not be okay. insertion of 'implicit'
statement is a problem. this text must go into base spec to
limit the damage of this statement.
<Zakim> dlongley, you wanted to say i don't think this makes a
lot of sense with selective disclosure
<rhiaro> scribenick: rhiaro
dlongley: it's a should that you include a type, not a must,
and there are use cases for this
<dlongley> dlongley: There are a number of use cases that
involve anonymizing data or selectively disclosing data where
having a specific VC type just doesn't make any sense or isn't
possible, I don't want to rule those out.
DavidC: I agree with what dlongley said, it's the associated
bit of working that led to the confusion. I was very clear at
the time that that wording was meant at a higher level. It
meant you can put things lower down but the type would be
associated at a higher level and not in the actual object
itself. It didn't mean implicit. We had different
interpretation. It was very clear that summary wording was
needed, and there was some rewording proposed
... that clarified it meant at a higher level. But then the
implicit crept in and that's where the problem started
... what i've tried to do in my clarification is say in these
instances implicit is okay and in this one instance implicit is
not okay
burn: that's implementation guideance, what you just said
<dlongley> +1 to implementation guidance
manu: I'm trying to figure out what the options are. You're
saying you're not okay with this being implementation guidance.
I'm not hearing a lot of support to put it in the spec. Which
means we're headed towards a formal objection from you? Unless
you say you won't formally object
... the next thing to do is to poll the group
... I don't know what the question is though
... the question has to be are we putting this PR in the spec
or in implementation guidance. I think arguing over what the
text meant before is futile because it's clear that it was not
clear
... Right now I think some people feel that what is in there is
appropriate, but not David
... there could be two polls. One of them is is the text in the
spec for type appropriate as long as David's language goes in
the implementation guide. I feel like that's the right balance
for consensus, with the risk of David raising a formal
objection because it's not strong enough from his perspective
<Zakim> burn, you wanted to poll the group
burn: I tend to agree with manu. I think that's the question. I
have seen this in other groups, these disagreements, we know
we're up against the wire and we need a way forward. Sometimes
that's going to happen even when there are disagreements. We
need to find the largest consensus
... Sometimes it goes one way and sometimes in another person's
favor. I want to make sure that we understand where the group
wants to go
... before I do that poll is there anyone who would like to say
something?
... queue up please
TallTed: To be clear, as the text is right now, David's suggest
action is perfectly viable. With the change that he wants, the
other activity pattern is not viable. The way it is is
flexible, the other way is rigid. The flexibility is the way to
go with this spec
burn: Ted does manu's proposed poll text match what you were
trying to say?
TallTed: fine by me
burn: we have tried not to do much of this in this group.
Sometimes groups do a straw poll, not an official vote, but an
attempt to find out the will of the group
... Let's do the poll first and we can do a proposed/resolved
in a moment
<burn> POLL: The language in the VC Data Model specification
with respect to types is appropriate and that is the text that
should go to Proposed Recommendation. The text in PR #674
should be moved to Implementation Guidance.
<TallTed> +1
<DavidC> -1
<burn> +1
<dlongley> +1
<deiu> +1
<stonematt> +1
<manu> +1
<SercanK> +1
<ken> +1
<jonathan_holt> 0, I don't understand to consequences of
implicit
burn: anyone who has an opinion chime in please
... the intent of this is to see what the will of the group is.
I think we have seen that
... is there anyone else who needs to hear the answer to
jonathan's statement before they can give their response?
jonathan_holt: what's the implication of having the implicit?
are there any security concerns as far as.. the thought I had
was in order to bootstrap the VC ecosystem you're gonna have to
have claims prepared beforehand by other people. If it's not
resolvable is there any risks for signing an attribute/value
that you don't know the consequences are?
DavidC: this is the whole reason why I want it to be explicit
on the top level type. it's because the types can be introduced
implicitly which actually totally alter the meaning of the
credential. A verifier who doesn't understand that implicit
will be mislead.
... What I suggest is that it is a security vulnerability if
you introduce a top level type which can significantly change
the meaning of a VC, but you don't tell the verifier you are
doing it because it's implicit. Verifiers who have done out of
band communication will be fine but others will not
... Why don't we pass this to the security group and get their
resolution? I'm happy to accept their assessment
... My assessment is a security vuln and that's why it must be
explicit
TallTed: that vulnerability concern is 100% addressable by the
policy set by the verifier. If a verifier has security concerns
then they can say I will only accept strongly typed
credentials. i will only accept these types. I will only accept
credentials that include these properties and no others
... these are all policy questions
... there is no rule in anything we've written that says if you
take a credential you must take all credentials
<yancy> +1
TallTed: none of those things are mandatory, policy handles it
all
<Zakim> manu, you wanted to say and that policy is why it
belongs in implementation guidance, and we really, really have
to move on.
dlongley: I agree with Ted and I want to add that we already
have a context field that does the mapping to the semantics of
the attributes and types. You must understand the context
either by reading human readable text, or by jsonld processing.
You already know what those attributes map to. I disagree that
the semantics are going to change. You can check the context
before you look at anything else. It provides a stronger
guarantee than having to check a type field
manu: I was somewhat on the fence when this text was originally
introduced, and now I think it's a bad idea. I think it's
important to point it out David which is why I think it should
go in implementation guidance. Ted is correct this is a policy
decision. If we send it to the security group that's what
they're going to come back with, that's how they've found these
things in the past. It depends on the risk profile of the
application. The spec
... shouldn't enforce a risk policy that needs to be dynamic
... it needs to be in the implementation guidance.
... We are burning a lot of time on this
... We need to move on
... We have poll, we should make it into a proposal/resolution
and move on. If there's a formal object we point back to the
resolution that the group made
DavidC: no further comments.
burn: I hate to do this in the obvious absence of agreement,
but we need to move forward. I'm gonna write the previous
statement as a proposal. Please vote on it
<burn> PROPOSED: The language in the VC Data Model
specification with respect to types is appropriate and that is
the text that should go to Proposed Recommendation. The text in
PR #674 should be moved to Implementation Guidance.
<TallTed> +1
<deiu> +1
<DavidC> -1
<manu> +1
<stonematt> +1
<burn> +1
<yancy> +1
<ken> +1
<dlongley> +1
<jonathan_holt> 0
<agropper> +1
<SercanK> +1
burn: we've tried to hit this as many different ways as
possible, David has tried to explain as much as he can and the
group is just not seeing that
... I'm going to declare that there is a decisions
RESOLUTION: The language in the VC Data Model specification
with respect to types is appropriate and that is the text that
should go to Proposed Recommendation. The text in PR #674
should be moved to Implementation Guidance.
burn: You may type something in the minutes if you wish David
stating that you object
<manu> [20]https://github.com/w3c/vc-data-model/pulls
[20] https://github.com/w3c/vc-data-model/pulls
manu: Those are the two PRs from today.
Issues
<manu>
[21]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+-label%3Adefer
[21] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+-label:defer
<manu> [22]https://github.com/w3c/vc-data-model/issues/222
[22] https://github.com/w3c/vc-data-model/issues/222
manu: First one is coordinate with PING, assigned to chairs
<TallTed> top to bottom sort --
[23]https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is
%3Aopen+-label%3Adefer+sort%3Acreated-asc
[23] https://github.com/w3c/vc-data-model/issues?q=is:issue+is:open+-label:defer+sort:created-asc
burn: we will close when final implementaion guide action items
are completed
... ti says that already. The question is have they been
completed?
ken: there's one item on the checklist and I think we'll cover
it
burn: progressive trust, that's right, there's a pending pr
... we need to have the implementation guide discussion which
maybe be sufficient to close it
<manu> [24]https://github.com/w3c/vc-data-model/issues/436
[24] https://github.com/w3c/vc-data-model/issues/436
manu: has to do with i81n discussion which took a month and a
half but i think we have closure, the PR is merged, the 7 day
close period has ended, we should close this issue
... I don't think we need a wg proposal to close that?
burn: once the group has decided to close in 7 days there's no
group decision needed to close
<manu> [25]https://github.com/w3c/vc-data-model/issues/526
[25] https://github.com/w3c/vc-data-model/issues/526
manu: changing the technical report link, that happens whenever
the next cr or pr is published so that's on kaz's plate
<manu> [26]https://github.com/w3c/vc-data-model/issues/537
[26] https://github.com/w3c/vc-data-model/issues/537
manu: next up is the json-ld reference, it was suggested that
we update the reference to jsonld 1.1
... which was not a substantive change even though the
submitter has asserted that to the TAG.
... No implementations had to change. The PR was merged
... issue should be closed to day if there's no objection from
the submitter. It has been 7 days... tomorrow
... 22:32 tonight is the 7 days
<manu> [27]https://github.com/w3c/vc-data-model/issues/621
[27] https://github.com/w3c/vc-data-model/issues/621
manu: this is the clarification of json types one. This was
actually a PR that brent put in that was merged
... that specifies the arity of each property
... it was non substantive, non normative, and was marked 7 day
closed 9 days ago and oliver has not objected to closing
burn: done
<manu> [28]https://github.com/w3c/vc-data-model/issues/632
[28] https://github.com/w3c/vc-data-model/issues/632
<manu> [29]https://github.com/w3c/vc-data-model/issues/633
[29] https://github.com/w3c/vc-data-model/issues/633
<manu> [30]https://github.com/w3c/vc-data-model/issues/634
[30] https://github.com/w3c/vc-data-model/issues/634
burn: the chairs will be discussing these with w3m because
there are ongoing frequently stated objections around these
issues
<manu> [31]https://github.com/w3c/vc-data-model/issues/634
[31] https://github.com/w3c/vc-data-model/issues/634
<manu> [32]https://github.com/w3c/vc-data-model/issues/653
[32] https://github.com/w3c/vc-data-model/issues/653
manu: this one is the one brent made about type in presentation
that kicked off the discussion at the beginning for this
meeting. Brent raised the issue then raised his PR that
addressed his issue and that was merged 9 days ago. The
assertion is that brent addressed his own issue here but that
kicked off another issue that david authored some text for and
based on the proposal that we did today that suggestion did not
make it into the spec, but brent
... addressed his concerns with the spec, therefore we should
close this issue
burn: my only hesitation is that there was a change that needed
to be made and it would be appropriate to say something about
the change before closing it
<manu>
[33]https://github.com/w3c/vc-data-model/pull/658/commits/12681
f9a24bb7669e0f23268b16ef4d318b172c2
[33] https://github.com/w3c/vc-data-model/pull/658/commits/12681f9a24bb7669e0f23268b16ef4d318b172c2
manu: removed terms of use presentation, that was the requested
change
<manu> [34]https://github.com/w3c/vc-data-model/issues/667
[34] https://github.com/w3c/vc-data-model/issues/667
manu: next up is the iat/nbf change and because the spec text
was wrong it is a substantive change and we're going to discuss
with w3m how to approach this today
... that is all of the issues
burn: that leaves us with 7, of which we'll probably close
another today, one will happen when we go to the next version
of the spec. Two real issues and 3 tracking issues
... s/Two/one
... anything else on issues?
dmitriz: no
Is doc ready for PR?
<manu> scribenick: manu
burn: Is the document ready for PR?
... We may be asked by W3M to do a single change Candidate
Recommendation.
... Is there any other reason that anyone has as to why we
can't publish this as a CR or a PR?
<scribe> scribenick: rhiaro
What else might block publication?
burn: this was intended to be a catchall to cover a number of
the issues we have already brought up. Three tracking issues
from a submitter, vague comments in general about other
problems including to the TAG. We'll have to talk about the TAG
discussion with w3m
... And then outstanding issue.
... Separately we know we're going to need the implementation
guide. These are things that happen after the spec publication.
... Anything anyone is aware of that could block publication?
... Any other topics?
(none)
Test Suite Issues and Discussion
<burn> [35]https://github.com/w3c/vc-test-suite/issues
[35] https://github.com/w3c/vc-test-suite/issues
<dmitriz>
[36]https://w3c.github.io/vc-test-suite/implementations/#confor
mance-testing-results
[36] https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results
<manu> scribenick: manu
dmitriz: we have had a few people re run the test suite, the
implementation report has been updated.
burn: Anything we can make progress on quickly?
dmitriz: Add documentation and a table of contents...
TallTed: There is one open issue, task... that dmitri said he'd
take care of... change hyphen to match the doc.
dmitriz: That's still pending.
burn: I'm scrolling through this to see where we don't have at
least two check marks... seeing a couple of JWT tests... bunch
at end of JWT section that's untested.
... Anything else?
ken: Looks like I forgot to resubmit my tests... that may be
the issue.
<dmitriz> stonematt:
[37]https://w3c.github.io/vc-test-suite/implementations/#confor
mance-testing-results
[37] https://w3c.github.io/vc-test-suite/implementations/#conformance-testing-results
<inserted> manu: I double checked the test report, we have full
coverage when we checked, we need to check again now that we
have a new test report
ken: I'll get in the updates in quickly.
Implementation Guide
burn: Looking at implementation guide - issue #222 for the main
spec, which is implementation guide issue 6.
<deiu> [38]https://github.com/w3c/vc-imp-guide/issues/6
[38] https://github.com/w3c/vc-imp-guide/issues/6
deiu: We have an open issue... we haven't merged yet, needs
review. Renamed to a work in progress, during last call,
haven't heard anything else on review.
<deiu> [39]https://github.com/w3c/vc-imp-guide/pulls
[39] https://github.com/w3c/vc-imp-guide/pulls
deiu: The status of the implementation guide - we're still
expecting work to be done and as soon as we have that text in
the PRs, and we can review it and merge it, we have issue
#14...
<burn> [40]https://github.com/w3c/vc-imp-guide/pull/14
[40] https://github.com/w3c/vc-imp-guide/pull/14
<deiu> [41]https://github.com/w3c/vc-imp-guide/pull/17
[41] https://github.com/w3c/vc-imp-guide/pull/17
<deiu> [42]https://github.com/w3c/vc-imp-guide/pull/18
[42] https://github.com/w3c/vc-imp-guide/pull/18
deiu: Out of all of the issues, we're waiting on input from
Oliver on JWTs, we're waiting also on input from Brent...
otherwise, we have other issues assigned to Dave Longley.
burn: It looks like there just needs to be work done, manu and
dave, focus on 6, please.
<dlongley> [43]https://github.com/w3c/vc-imp-guide/pull/18
[43] https://github.com/w3c/vc-imp-guide/pull/18
dlongley: For the progressive trust PR, I did review that PR...
PR #18, I'd like to get input on.... there is a PR there, good
amount of text on how to create a new type of credential and
how things work.
<DavidC> I will take a look at #18
<dlongley> thanks, DavidC
deiu: Even if you don't find yourself as a person that is
assigned to an issue or a PR... you can still help.
<Zakim> burn, you wanted to ask what else we need for PR #14
burn: For PR #14, how many more people do we need to approve
it... the text looks fairly simple, hoping to get one more
person to read/approve on this call.
... That closes the main VC issue...
dmitriz: I'll volunteer to review.
TallTed: As far as the text goes, I'm fine with it, but I'm not
sure how much it says about Progressive Trust.
burn: It doesn't start by saying "Progressive Trust" is "X"...
... We are out of time, thanks to all, long and challenging
call, appreciate all of you sticking with it... thanks again to
Manu, he does more than we know. :)
... Thanks all, talk with you all next week.
[adjourned]
Summary of Action Items
Summary of Resolutions
1. [44]The language in the VC Data Model specification with
respect to types is appropriate and that is the text that
should go to Proposed Recommendation. The text in PR #674
should be moved to Implementation Guidance.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [45]scribe.perl version 1.154 ([46]CVS log)
$Date: 2019/07/09 17:36:25 $
[45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[46] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 9 July 2019 17:38:52 UTC