Meeting minutes
Review of 2022-08-31 Meeting Minutes
<kaz> Aug-31
Resolution: Meeting notes aproved.
Schedule
Lagally: Ideally decide profile 1.0 spec scope next week
Lagally: We should prepare for PlugFest testing
McCool: Testing calls are cancelled, so when should we organise testing?
Lagally: How about the profile call next week?
McCool: Yes let's discuss then. Times, repo etc.
Lagally: Testing call immediately after main call?
McCool: Haven't actually cancelled the main call next week. Four hours later than usual. Post-TPAC is Eastern time (earlier), but still overlapping testing call. Let's discuss in the next Profile call, which i don't think we have a conflict for
Lagally: There is a conflict
PlugFest the week after TPAC
McCool: Two week review end of September, CR & review end of October, looking at January for transition...
McCool: Have to hit the deadlines
Daniel: The decision was made to still go for CR?
McCool: We will try to, only do the normative parts we have consensus on, if not ready then defer it
Lagally: Let's see what we have at the end of September, will give us an idea of stability
Profile 1.0 Scope
Lagally: Shows a presentation with a proposal
Lagally: Make only common constraints and HTTP Baseline profile normative
<mlagally>
https://
<mlagally> https://
Looking at changes in draft PR
https://
Lagally: Some wordsmithing in the introduction which should hopefully not be contentious
McCool: Not sure about wording
Lagally: We can fix that
Lagally: I removed the information model chapter
Lagally: We had a discussion about scope of new profile work before
McCool: Could say profile for "other protocols" instead of digital twins
Ben: Yes that would be fine
Lagally: I don't mind, just thought it might trigger more interest
McCool: E.g. profiles for other protocols and a profile for resource constrained devices
Lagally: Took out JSON Schema section since it doesn't seem realistic for 1.0
Kaz: OK with adding that kind of note, but clarifying the purpose/motivation for profiles should be precisely discussed here
Kaz: The specification should maybe not be called profiles or directory implementation guidelines. If we want to publish a specification named profile we should discuss the motivation more clearly here.
Kaz: The current conclusion of protocol-based profiles and protocol extensions is fine, but should clarify the intention of profiles. Not for specific use cases.
Lagally: Please constrain the discussion to the review of this PR.
Lagally: We did extensive work on goals and requirements, would rather not re-open this discussion.
Lagally: Revisiting motiviation and goals should be done during TPAC for future profile work
Kaz: My concern is we sometimes talk about use case based profiles and we should not go in that direction
Ben: (+1 from me)
Kaz: Would prefer to focus on HTTP/CoAP, not talk about extension at all
Lagally: I'm happy to remove that paragraph with the extensions
McCool: Future statements not good, may not want to keep them. However, in general this is "profiles" not "profile", so profiles should be for narrower use cases.
Lagally: Terminology being removed
Lagally: Removed some commented out requirements from previous discussions. I think they can now be closed.
Lagally: Made one heading shorter
McCool: That's fine, good catch
Lagally: Placeholder for identifiers
Lagally: A guideline for units
Lagally: Date format recommendations
McCool: One more issue with relative values like brightness, people are confused about finite vs. percent based. Would be good to recommend using percentage for relative values.
Lagally: Please create a new issue for that
Ben: If you reference RFC3339 then you don't need the additional clarifying requirements
Lagally: Useful for people who don't read the reference
Lagally: The next change is making the two event sections non-normative
Lagally: Resolve editor's notes
Lagally: Entire section about JSON Schema removed
Lagally: That's the simplified Profile 1.0 specification
<Ege> bf: this is a step in good direction
Ben: however, this is not experience-driven
Ben: would like to see
who is implementing WoT Profile
… note Consumers would be more difficult
Lagally: I have done one implementation of HTTP Baseline + Webhook
Lagally: In terms of what we have to validate, we have to verify all of the normative statements
Daniel: What you said about the consumer simply picking them from the plugfest, I don't think that's always the case. We have a Consumer which is TD compliant, but it's not fully baseline compliant because we can't fully handle async actions. There's a pending PR from Ben which at least makes the synchronous actions from Baseline Profile compatible,
but not the async actions. Consumer is not implemented.
Lagally: don't understand
Daniel: Existing consumers can invoke an action, but not necessarily query them. You need a special implementation because the profile extends the TD.
Lagally: Extends the TD
Daniel: Doesn't just extend, it breaks compatibility. Currently the response to the invokeaction request may not match the output data schema. Not that easy.
Lagally: I understand that the TD may currently have some limitations when describing brownfield devices
Ege: Complex interactions with hypermedia is an ongoing discussion since 1.0, still no generic proposal that works
I still haven't seen a Webhook consumer implementation. Is the consumer mlagally mentioned a generic consumer, or can it only consume one TD?
Lagally: Not generic. Actually, just logging what it says in the Webook. It just lists the notifications.
Lagally: I would like to come back to Ben's comment about implementation. The indication of who is implementing this is important and we have a good way to seeing that at the upcoming plugfest. Available implementations and TDs may only need to be updated with profile ID
Lagally: Could wait for two more weeks. If only have one implementation of async actions then may have to move it out.
McCool: Can mark it as at risk.
Lagally: We have one more potential implementation. The PlugFest will help understand if there are implementation issues with the specification.
Daniel: The profile deviates from the TD spec, which may break existing TD consumers.
Daniel: This isn't something that I like, but I do understand the concern/verbosity if done differently. Still trying to find a better solution.
McCool: My understanding of the TD spec is that it has input and output data schemas. DOn't see why node-wot would have a problem with that.
Daniel: The profile uses output data schema, but the response has a wrapper around that.
McCool: The profile has to be compliant with the TD spec, can't do something different, but can't specify additional constraints
Lagally: Getting back to the review of this PR
Lagally: Could we merge this as it is?
McCool: Agree with merging this if issues we discussed are cleaned up, can file issues e.g. for the actions issue
Lagally: This PR doesn't change that
McCool: Yes can have resolution to merge then make sure actions ready for other issues
<McCool> (need to drop soon... pre-TPAC call)
<McCool> (however, I still think we should merge this for now, carry on the point ben has raised next time)
Ben: I think that there is no evidence of any profile being more implementable than the others
Ben: we can also make the whole document informative
Kaz: we can merge this now and discuss later in the pre-TPAC meeting
Lagally: Can me make this a resolution?
Resolution: merge this PR and continue discussion in the pre-TPAC meeting
[adjourned]