<kaz> scribenick: McCool
Matthias: any quick updates?
Kaz: reminder of early-bird reg for
TPAC
... is this Friday
<inserted> TPAC 2019 registration
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> Draft Implementation Report
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
<inserted> Architecture PRs
Matthias: open PRs for architecture, purely editorial
<mkovatsc> PR 362
Matthias: capitialization changes and
such
... we will go through them
... any objections?
no objections, merged
<inserted> PR 361
Matthias: pr 361
... capitalization and spelling issues
... their to thier, titles with consistent capitals
... any objections?
no objections, merged
<inserted> PR 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
<inserted> TD Issues
<inserted> Issue 700|
Matthias: must be renamed to "Data Schema" to be consistent
... taki, could you create a PR for this?
<inserted> Issue 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
<kaz> Issue 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
<kaz> Issue 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
<inserted> Issue 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, need to be in the right place
<mkovatsc> Implementation Report - 6. Systems section
Matthias: did my best to identify the
latest versions
... so please double-check that the version in the report is what
you want
<mkovatsc> Implementation 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
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> Implementation Report draft
<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
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.
<mkovatsc> Proposal: Drop the at-risk PoPSecurityScheme feature.
any objections?
no objections
RESOLUTION: Drop the at-risk PoPSecurityScheme feature.
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.
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> Architecture Issue 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
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> Issue 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> Appendix D.1
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> Appendix D
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.
<kaz> Security TF minutes
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> WoT Security and Privacy Guidelines draft
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.
<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 <https://www.w3.org/WoT/IG/track/users>.
Matthias: some guidelines as to length, etc would be helpful
<kaz> HTML5 top page news
Kaz: this link has various examples
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)
<zkis> Scripting PR: https://github.com/w3c/wot-scripting-api/pull/174
<zkis> Rendered: 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]