Meeting minutes
Agenda
<kaz> McCool's slides
McCool: probably we can squeeze publication status a bit
McCool: we do not want to reach resolutions today
McCool: maybe zoltan can talk about the scripting api status
Review publication status, testing requirements, planning
Discovery
<McCool_> PR 409 - Update DNS-SD section (usage of TXT Record)
McCool: decided to go to CR for discovery after handling the above PR on DNS registration.
McCool: I will send an email to start CR transition for discovery by starting the review process
TD
McCool: is there a TD call?
Ege: yes, but the topic will be Binding Templates today.
McCool: is there a CR version of TD?
Ege: I think so
McCool: do you plan for a resolution of the binding templates?
Ege: yes but not very soon, still need to work on the main document
McCool: so no need for resolutions at the moment
Architecture
<kaz> WoT Architecture 1.1 2nd WD just published
McCool: what about architecture
Kaz: the updated WD has just been published as above.
Lagally: the spec is frozen since multiple weeks
Ege: what about the testing of the arch spec?
McCool: we should go
through the assertions one last time
… we need manual assertions
McCool: e.g. we have an assertion about the secure updates but that is difficult to implement now
McCool: we can put them and make them lower case if no one implements it
Kaz: we should discuss how to do the testing of the arch spec
McCool: we can have one but we did not plan it yet
Kaz: maybe it should be discussed in the arch call first
Scripting API
Daniel: planning to publish an updated Note but need some more time.
Security
McCool: security guidelines needs a revision
deliverable proposals
<kaz> Kaz's slides
Kaz: daniel asked me to prepare differnt types of documents based on the process document
Kaz: there are alternatives based on Standard or NOT Protected by W3C Patent Policy or NOT Sufficient implementations or NOT Endorsed by W3C or NOT
Kaz: my suggestion for scripting api is to go with rec if it should be a basis for wot implementations
Daniel: I have noted that normative notes are endorsed by wot group
Kaz: it is not endorsed by W3C. It is implicitly endorsed by the working group
Lagally: so normative notes do not require implementations?
<McCool_> acl ml
<kaz> Contributors License Agreement (CLA) for CGs
Zoltan: CG allows external people to contribute
Zoltan: Ben, do you have an input on where this development should continue?
Kaz: my general recommendation is to go for REC
Kaz: for that purpose, we need to get the AC Review for REC transition, but we need to get AC Review for the proposed deliverables within the Charter as well., if we would like to publish our specs as the basis of implementations for WoT.
McCool: the objection was about including in the browser
Daniel: we want to have normative language in our spec, but we had to switch from REC to a Note, so would prefer a normative Note.
<zkis> Thanks Ben, these were clear thoughts.
Ben: I think it does not have to be a standard, can be something on github
Cristiano: we actually have multiple implementations, dart and python
Cristiano: I agree with daniel that the REC would be too soon for us now
Ege: REC does not mean that browsers have to implement it and we can reduce the scope to make it implementable in a browser
McCool: I can summarize. Scripting API editors prefer a normative Note resolution. There are opinions for an incubation.
McCool: I am worried about the patent policy
<McCool_> (time check - we need to wrap up)
<McCool_> (no, we don't: sorry, still have an hour)
Zoltan: we can follow what
some apis do, like machine learning in the web
… aside security concerns, we can use a ws+http to
make it possible in the browser
Kaz: It is nice to have participation from browser community
Kaz: and now I'd like to ask you about which problem is bigger for you with Scripting API, (1) browser vendors would not implement it or (2) we already have TD as a standard data model and we don't need to have a standardized API for WoT
Ben: the latter. why not letting the webpages generate fetch api etc. from TD?
Cristiano: wondering if CLA can't be applied to normative Notes
Kaz: CLA is defined for CGs and not included in the W3C Process
McCool: the type of documents itself is W3C Process issue
<cris> +1
Kaz: yeah, so I'd like you all to start with thinking about the 4 viewpoints, standard or not, protected by pp or not, implementations required or not, endorsed by W3C or not
McCool: defining the purpose is important, then the pub option
<citrullin> +1 More or less
McCool: one purpose where a
standard is useful is automation
… but for automation a simpler if-then system might
be better than JS...
Zoltan: value in Scripting
API can provide patterns and
… options for implementations of WoT
applications
McCool: we can brainstorm
use cases and applications
… maybe we should revisit the existing document
again
Philipp: having data locally and accessing the data using Scripting API is useful
McCool: accessing the local data is important in general
Philipp: getting permission as well
McCool: related to key
management for onboarding as well
… not only API per se
… let's go back to the agenda now
… my impression is going for normative Note for the
next Charter
<dape> +1
McCool: any objections?
<McCool_> proposal: use a normative note for scripting in the next charter
<Ege> mm: any change requests?
Resolution: use a Note including normative statements for the Scripting API deliverable in the next charter
Action: kaz to talk with PLH about that idea
Daniel: we still have two more points, so can we have 20 minute slot in tpac?
McCool: per deliverable we plan 10 minutes
Charter Proposals
<kaz> Deliverable Proposals
Discovery
<kaz> discovery.md
<kaz> PR 1032 - Update Discovery Deliverable Proposal
Ege: can anyone create for spec or only the editors?
McCool: you can create a proposal
Kaz: agree
… as discussed yesterday, it's kind of
brainstorming at this stage, so getting ideas is good. we can
discuss the proposals during the TPAC meeting and the post-TPAC
meeting.
(going back to the discussion on Discovery proposal)
McCool: geolocation has multiple solutions
<kaz> (merged)
Security
<kaz> PR 1031 - Create Security Deliverable Proposal
McCool: (goes through the PR content)
Ege: which TF to discuss it?
McCool: security review to
be put into one place
… one document to take a look
… should include security for TD, Discovery,
etc.
… however, handling keys, etc., would impact
Discovery spec specifically
Ben: agree with general
idea of consolidating security portion
… currently you got to read all the related
specs
… regarding the onboarding topic, I'm not really
sure if it's the right topic, maybe discovery in
general?
McCool: could be "onboarding during discovery"
Ben: I think this would make the specification more difficult to read since there would be too many interdependencies
Lagally: I support consolidating security documents into a single document or a section of the architecture or TD spec
Philipp: I think that informal documents to help and guide people for implementation would be a good option to resolve this conflict of ease of implementation vs. ease of security review. I see security as the more important point. Helping developer would be more of a topic for the CG.
Kaz: I'm OK with the
Security&Privacy proposal itself and extending the
content
… however, our procedure has been (1) generating
requirements within the Security&Privacy Note, (2) distribute
them to the normative specs, and (3) think about the detailed
assertions and behaviors on the normative spec side
… so I'm wondering if this proposal means we need
to put the detailed considerations on the spec side back to the
Security&Privacy Note.
McCool: this makes architecture normative but some people want it informative
<kaz> (discussion on the relationship among relates specs)
Kaz: sorry but let me ask how to record this discussion
McCool: let's record the details in the GitHub PR's comment area for today.
<kaz> McCool's comments
Profile
<kaz> profiles.md
Lagally: (gives explanations)
McCool: issue with
versioning, etc.
… each profile may need its own compatibility
requirements
Ben: could consider
extension by reference
… regarding digital twin profile and cloud
profile
… I'm implementing digital twins using the core
profile
… what specifically needed for them?
<Zakim> mlagally_, you wanted to react to McCool_
Lagally: individual scope to be discussed
McCool: hoping longer
discussion
… one word is not enough
… it's a list of possible profiles we might be
working on
<Zakim> McCool_, you wanted to react to mlagally_
Ben: at the moment,
don't really agree...
… CoAP profile and constraint device profile should
be similar and possible, though
Ege: general
comment
… initial work of WoT is removing IoT
silos
<McCool_> (time check)
Ege: so don't think it
would be good to create another kind of silos on the top of
WoT
… if we need to have profiles based on each use
case, that would not be good
<Zakim> mlagally_, you wanted to react to b
Lagally: it's just an example, can be removed
McCool: please make another
update
… and people can give further comments
Lagally: ok
Ege: my comment is that we should not have vertical profiles per use case
Ege: it will lead to fragmentation on top of our own specification
Kaz: agree we update the proposal, and for that purpose, we should remember we need to clarify what the objectives and motivations of "WoT Profile" is
[adjourned]