<kaz> scribenick: McCool

Quick updates

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

Architecture PRs

<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

TD Issues

<inserted> TD Issues

* Issue 700

<inserted> Issue 700|

Matthias: must be renamed to "Data Schema" to be consistent
... taki, could you create a PR for this?

* Issue 715

<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

* Issue 770

<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

* Issue 712

<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

* Issue 772

<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

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

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> Implementation Report draft

* 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> 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

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> 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.

Security and privacy guidelines updates

<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.

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 <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

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: 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]