- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 20 Jun 2019 22:34:46 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
https://www.w3.org/2019/06/19-wot-minutes.html
also as text below.
Thanks a lot for taking the minutes, McCool!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-IG/WG
20 Jun 2019
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Kunihiko_Toumura, Michael_Koster,
Michael_McCool, Takahisa_Suzuki, Taki_Kamiya,
Zoltan_Kis, Ege_Korkan, Matthias_Kovatsch,
Ryuichi_Matsukura, Tetsushi_Matsuda, Tomoaki_Mizushima,
Toru_Kawaguchi, Michael_Lagally
Regrets
Chair
Matthias, McCool
Scribe
McCool, kaz
Contents
* [3]Topics
1. [4]Quick updates
2. [5]Architecture PRs
3. [6]TD Issues
o [7]Issue 700
o [8]issue 715
o [9]issue 770
o [10]Issue 712
o [11]Issue 772
4. [12]Implementation descriptions
5. [13]At-risk features
o [14]Digest QoP
o [15]OAuth2
o [16]POP scheme
o [17]PSK, cert, public
6. [18]PR WoT Arch
7. [19]PR TD WoT
8. [20]Security and privacy guidelines updates
9. [21]Possible press release?
10. [22]Scripting API updated WD
11. [23]Scripting API updated WD (contd.)
* [24]Summary of Action Items
* [25]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: McCool
Quick updates
Matthias: any quick updates?
Kaz: reminder of early-bird reg for TPAC
... is this Friday
<inserted> [26]TPAC 2019 registration
[26] https://www.w3.org/2019/09/TPAC/registration.html
Zoltan: scripting...
Matthias: let's deal with PR as the first priority
Lagally: would like to ask for approval to include editorial
PRs in Arch
Matthias: this is on the agenda
McCool: perhaps people can look at these so that when we get to
that item
Matthias: also, good news from Ege; final implementation for
unobserveproperty
... which was a blocker, and will be resolved with this
<kaz> [27]Draft Implementation Report
[27] https://w3c.github.io/wot-thing-description/testing/report.html
Ege: well, I'm still working on it...
... second implementation with different components
Matthias: have one at-risk item which is very useful, proxy
McCool: I would recommend that if we can't, we can still
publish an extension
Matthias: yes, but the main plan is still to get them in
Architecture PRs
<inserted> [28]Architecture PRs
[28] https://github.com/w3c/wot-architecture/pulls
Matthias: open PRs for architecture, purely editorial
<mkovatsc> [29]PR 362
[29] https://github.com/w3c/wot-architecture/pull/362
Matthias: capitialization changes and such
... we will go through them
... any objections?
no objections, merged
<inserted> [30]PR 361
[30] https://github.com/w3c/wot-architecture/pull/361
Matthias: pr 361
... capitalization and spelling issues
... their to thier, titles with consistent capitals
... any objections?
no objections, merged
<inserted> [31]PR 360
[31] https://github.com/w3c/wot-architecture/pull/360
Matthias: PR360
... larger change, changed "Consume" to "Consuming", "Expose"
to "Exposing"
... and other capitalization issues
... any objections?
no objections, merged
Matthias: lagally, can you comment the status of the arch
document?
... do we need a change log entry, for example?
McCool: I would add just one line, "Spelling and capitalization
corrections"
Matthias: I will do that
TD Issues
<inserted> [32]TD Issues
[32] https://github.com/w3c/wot-thing-description/issues
* Issue 700
<inserted> [33]Issue 700|
[33] https://github.com/w3c/wot-thing-description/issues/700
Matthias: must be renamed to "Data Schema" to be consistent
... taki, could you create a PR for this?
* Issue 715
<inserted> [34]Issue 715
[34] https://github.com/w3c/wot-thing-description/issues/715
Matthias: right now only have one example that uses checkbox
... it would be nice to have these for the examples in the
appendix
McCool: I'm a little worried this would introduce a bunch of
errors...
... I'm ok to go ahead with this, but we MUST make sure the
examples are correct, and we don't have a validator that can
check the default values
Matthias: ok, will move to the end of the priority list, likely
we will not be able to do it
* Issue 770
<kaz> [35]Issue 770
[35] https://github.com/w3c/wot-thing-description/issues/770
Matthias: unfortunate that victor is not here
... proposed solution by Kaz is to have an editor's draft for
now
... can fix it in the IG later
Kaz: at the moment we don't have to publish it as a note, so
there is no problem
... but after IG recharter next month we can easily publish it
as a note
... but basically we don't have time to publish a new note
right now in the current charter
Matthias: ok, I will coordinate with victor to make sure the
updates are done
* Issue 712
<kaz> [36]Issue 712
[36] https://github.com/w3c/wot-thing-description/issues/712
Matthias: comment during CR period
... what happens when we have multiple method names
... thought is that we can explain how to do this, have
multiple links with multiple rel
... we have examples of this
... also see this for observe and read in the Intel TDs
... you need a different URL for longpolling
koster: there is a simple example
McCool: since we need to do a resolution to go to PR today but
there are changes pending
... I think we should defer this to keep the number of pending
changes small
... but we can certainly discuss this in tutorial information
... and in the next version of the spec
* Issue 772
<inserted> [37]Issue 772
[37] https://github.com/w3c/wot-thing-description/issues/772
we require a processor that can both serialize and deserialize
Matthias: but this seems to go against our practice
... should we fix this, and allow a processor to do only one of
producing or consuming
Zoltan: we do have some discussion of different levels of
conformance
... although the definition is different in W3C
Matthias: this is a little different...
McCool: so, do we change TD Processor or add TD Producer?
... maybe we just modify the definition of TD Processor to (a)
allow a processor to just produce or consume in some cases and
(b) allow the use of TD producer in the case of a TD processor
that does not consume TDs
<mkovatsc> Proposal: Clarify in the definition of TD Processor
with an additional sentence that a Processor can be TD Consumer
only, TD Producer only, or both. Fix td-processor assertion to
say and/or instead of only and (meaning both)
McCool: agree
Matthias: any objections to the proposal being a resolution?
no objections
RESOLUTION: Clarify in the definition of TD Processor with an
additional sentence that a Processor can be TD Consumer only,
TD Producer only, or both. Fix td-processor assertion to say
and/or instead of only and (meaning both)
Implementation descriptions
implementation descriptions, need to be in the right place
<mkovatsc> [38]Implementation Report - 6. Systems section
[38] https://w3c.github.io/wot-thing-description/testing/report.html#test-systems
Matthias: did my best to identify the latest versions
... so please double-check that the version in the report is
what you want
<mkovatsc> [39]Implementation descriptions
[39] https://github.com/w3c/wot/tree/master/testing/tests/2019-05/descriptions
Matthias: and please update in the wot repository at the link
above
... and please use a unique name and id for your
implementation, eg using an org prefix
... please do this by EOD so we can finalize the implementation
report
At-risk features
Matthias: we need a resolution to do this
McCool: kaz, what is the process?
Kaz: if possible, better to remove the at-risk features from
the spec but mention them in the Implementation Report.
... Another option is simply keeping the at-risk features in
the spec draft for transition request, and remove them after
the transition discussion with the Director
Matthias: can we do this when final version is generated?
... so for the PR request we leave the at-risk features, but in
the email for the request we state we will remove them
... so the changes for the spec will only happen when we
... submit
McCool: I suggest we go ahead and submit with the at-risk
features
... but start working on a draft immediately that takes out the
at-risk features
koster: would it not be better to have a clean version?
Matthias: I think it is better to have a record
koster: ok
Matthias: we now need a resolution to remove the at-risk
features
<inserted> [40]Implementation Report draft
[40] https://w3c.github.io/wot-thing-description/testing/report.html#test_results
* Digest QoP
<mkovatsc> Proposal: At-risk Digest QoP feature will be
removed, but we keep the DigestSecurityScheme
Matthias: any objections
no objections
RESOLUTION: At-risk Digest QoP feature will be removed, but we
keep the DigestSecurityScheme
* OAuth2
Matthias: we will keep just the code flow
<mkovatsc> Proposal: Drop the at-risk OAuth2 subfeatures for
flows except the code flow. We keep the OAuth2SecurityScheme
with code flow.
Kaz: should be ok to just have partial feature
Matthias: any objections?
no objections
RESOLUTION: Drop the at-risk OAuth2 subfeatures for flows
except the code flow. We keep the OAuth2SecurityScheme with
code flow.
* POP scheme
<mkovatsc> Proposal: Drop the at-risk PoPSecurityScheme
feature.
any objections?
no objections
RESOLUTION: Drop the at-risk PoPSecurityScheme feature.
* PSK, cert, public
Matthias: we do have PSK implemented, but there are some
missing details
... different ciphersuites, etc.
... so I don't think we have enough experience
... they are meant for CoAPS, and we need to work on the coap
vocabulary
koster: you mean we would add vocab for these options?
Matthias: what I mean is we only have http vocab
... but nothing for coap methods, options, etc.
... so when we add that, we can also add all the security
schemes
koster: ok
<mkovatsc> Proposal: Drop the at-risk features
PSKSecurityScheme, CertSecurityScheme, PublicSecurityScheme,
which are for CoAP. We will work on them later when we also
work on the CoAP(S) protocol binding vocabulary.
any objections?
no objections
RESOLUTION: Drop the at-risk features PSKSecurityScheme,
CertSecurityScheme, PublicSecurityScheme, which are for CoAP.
We will work on them later when we also work on the CoAP(S)
protocol binding vocabulary.
PR WoT Arch
Matthias: pending have a change log entry
... master branch is the version that gets submitted, but with
a small one-line change log addition
<mkovatsc> Proposal: Use the current Editors Draft in the
master plus the coming fix of the changelog for the PR
transition of the WoT Architecture specification.
McCool: might be better to cite a specific issue, say that
after that issue is closed and merged, the resulting version
will be submitted
Matthias: creates issue 363
<kaz> [41]Architecture Issue 363
[41] https://github.com/w3c/wot-architecture/issues/363
<mkovatsc> Proposal: Use the current Editors Draft in the
master plus the coming fix of the changelog (#363) for the PR
transition request of the WoT Architecture specification.
any objections?
RESOLUTION: Use the current Editors Draft in the master plus
the coming fix of the changelog (#363) for the PR transition
request of the WoT Architecture specification.
no objections
<taki> +q
PR TD WoT
Matthias: would be current master plus resolutions of the
various issues
<mkovatsc> Proposal: Use the current Editors Draft in the
master plus the coming fixes for #769, #700, #772 for the PR
transition request of the WoT Thing Description specification.
Taki: is one pending PR that is related to the ontology issue
<mkovatsc> Proposal: Use the current Editors Draft in the
master plus the coming fixes for #769, #700, #772, #777 for the
PR transition request of the WoT Thing Description
specification.
Taki: basically the references are old
Matthias: ok, kaz, what is the best process here
... the changes are in the ttl files
... basically referred to RFCs for basic, digest, and beaerer
Kaz: references do not impact specification
McCool: I agree with adding these references
Kaz: should be fine
Matthias: when we add the mqtt binding, then we can explain
that basic also applies
... wanted to ask taki to clarify his PR and what it addresses
Taki: ontology already updated
... but example needs to be updated to be consistent with the
ontology
... also, not a one-time-fix, we may need to update the
ontologies further
... which might break the example again
... so we probably should remove things that depend on the
ontology
... issue 770, has a proposed solution
Matthias: we should remove the part we know will change
... we can always have an external tutorial
<kaz> [42]Issue 770
[42] https://github.com/w3c/wot-thing-description/issues/770
McCool: I think we should remove the appendix, and put the
content in a tutorial
Proposal: Use the current Editors Draft in the master plus the
coming fixes for #769, #700, #772, #777 for the PR transition
request of the WoT Thing Description specification.
... Use the current Editors Draft in the master plus the coming
fixes for #769, #700, #770, #772, #777 for the PR transition
request of the WoT Thing Description specification. As part of
#770, Appendix D.1 will be removed.
... Use the current Editors Draft in the master plus the coming
fixes for #769, #700, #770, #772, #777 for the PR transition
request of the WoT Thing Description specification. As part of
#770, Appendix D.1 will be modified or removed.
<kaz> [43]Appendix D.1
[43] https://w3c.github.io/wot-thing-description/#thing-description-json-ld-context
Proposal: Use the current Editors Draft in the master plus the
coming fixes for #769, #700, #770, #772, #777 for the PR
transition request of the WoT Thing Description specification.
As part of #770, Appendix D will be modified or removed.
<kaz> [44]Appendix D
[44] https://w3c.github.io/wot-thing-description/#note-jsonld11-processing
any objections?
no objections
RESOLUTION: Use the current Editors Draft in the master plus
the coming fixes for #769, #700, #770, #772, #777 for the PR
transition request of the WoT Thing Description specification.
As part of #770, Appendix D will be modified or removed.
Security and privacy guidelines updates
<kaz> [45]Security TF minutes
[45] https://www.w3.org/2019/06/17-wot-sec-minutes.html
Proposal: Update the WoT Security and Privacy Guidelines (a
renaming of the WoT Security and Privacy Considerations) using
the current master in wot-security, and following the
resolution made by the Security TF.
<kaz> [46]WoT Security and Privacy Guidelines draft
[46] https://w3c.github.io/wot-security/
any objections?
no objections
RESOLUTION: Update the WoT Security and Privacy Guidelines (a
renaming of the WoT Security and Privacy Considerations) using
the current master in wot-security, and following the
resolution made by the Security TF.
Possible press release?
<Zakim> kaz, you wanted to suggest we issue a press release
with Member testimonials for the WoT RECs publication (in July)
Kaz: press release to go with REC
... usually includes testimonials "WoT is great", etc.
McCool: do we get a chance to review the press release before
it goes out?
Kaz: yes, we will work with the marketing team
<scribe> ACTION: Implementers should generate testimonials
<trackbot> Error finding 'Implementers'. You can review and
register nicknames at
<[47]https://www.w3.org/WoT/IG/track/users>.
[47] https://www.w3.org/WoT/IG/track/users
Matthias: some guidelines as to length, etc would be helpful
<kaz> [48]HTML5 top page news
[48] https://www.w3.org/blog/news/archives/4167
Kaz: this link has various examples
Scripting API updated WD
Matthias: zoltan, do you need feedback?
Zoltan: yes, we need feedback on working draft
... will transform into a note in July
Matthias: we could stay on for the next half hour
<kaz> (break)
Scripting API updated WD (contd.)
<zkis> Scripting PR:
[49]https://github.com/w3c/wot-scripting-api/pull/174
[49] https://github.com/w3c/wot-scripting-api/pull/174
<zkis> Rendered:
[50]https://zolkis.github.io/wot-scripting-api/
[50] https://zolkis.github.io/wot-scripting-api/
<kaz> (Zoltan gives summary explanation)
<inserted> scribenick: kaz
Matthias: the updated Scripting API still uses "client" and
"server"
Zoltan: would use "User Agent" so that Web developers can
easily understand
... would find other terms for "client" and "server"
... user agent (UA) belongs to Web specs
... "WoT Consumer" and "WoT Producer" as terms with bold font
Zoltan: you can check the updated draft
Matthias: this draft looks good but would like to look into
more
Kaz: how to proceed?
... Scripting TF will review the updated draft on Monday, June
24
... and final WG resolution on Wednesday, June 26?
... we can use Echidna for publication
Zoltan: ok
... WG review on next Wednesday, June 26 then
Kaz: are we done for the main call today?
Matthias: yes
[adjourned]
Summary of Action Items
[NEW] ACTION: Implementers should generate testimonials
Summary of Resolutions
1. [51]Clarify in the definition of TD Processor with an
additional sentence that a Processor can be TD Consumer
only, TD Producer only, or both. Fix td-processor assertion
to say and/or instead of only and (meaning both)
2. [52]At-risk Digest QoP feature will be removed, but we keep
the DigestSecurityScheme
3. [53]Drop the at-risk OAuth2 subfeatures for flows except
the code flow. We keep the OAuth2SecurityScheme with code
flow.
4. [54]Drop the at-risk PoPSecurityScheme feature.
5. [55]Drop the at-risk features PSKSecurityScheme,
CertSecurityScheme, PublicSecurityScheme, which are for
CoAP. We will work on them later when we also work on the
CoAP(S) protocol binding vocabulary.
6. [56]Use the current Editors Draft in the master plus the
coming fix of the changelog (#363) for the PR transition
request of the WoT Architecture specification.
7. [57]Use the current Editors Draft in the master plus the
coming fixes for #769, #700, #770, #772, #777 for the PR
transition request of the WoT Thing Description
specification. As part of #770, Appendix D will be modified
or removed.
8. [58]Update the WoT Security and Privacy Guidelines (a
renaming of the WoT Security and Privacy Considerations)
using the current master in wot-security, and following the
resolution made by the Security TF.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [59]scribe.perl version
1.152 ([60]CVS log)
$Date: 2019/06/20 13:34:07 $
[59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[60] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 20 June 2019 13:35:50 UTC