Meeting minutes
minutes
<mlagally> https://
Lagally: any issues? "ben you wanted to react to McCool", what does that mean?
… let's remove it, it does not seem to have any meaning
<kaz> removed ( that is automatic log by Zakim in response to Ben's "q+" at that time)
McCool: note we merged sebastian's TM PR, but I did not get a chance to update mine (which layers on top of Sebastians)
Lagally: any objections to publishing? None... will be published
PR 78
<benfrancis> https://
Ben: let's reorder things to do actions and events first; also multiple data model PRs
Lagally: data model PR restructures just data model section, there is another PR that removes it from ben; will discuss
… but let's do actions first (#89)
PR #89 - Actions
<kaz> PR 89 - Define protocol binding for actions - closes #81
Lagally: this should close issue #81
… some open issues are whether the link to the resource should be in the header or in the body of the response
McCool: I do think this is overall in the right direction
McCool: regarding headers, I think "doing what people expect" is stronger than "protocol independence"
Lagally: disagree, I think we are trying to develop an abstraction, so the details should not matter so much
<benfrancis> https://
McCool: if we are using an abstraction, the real point is can we describe the abstraction with the TD, e.g. can we easily extract information from a header?
Cristiano: yes, agree, we can describe input data for a header, but not currently output data
Lagally: if it's in the body, then the implementation is also easier
Ben: in JS at least, easier to get from the header than the body
McCool: still two actions rather than two (storing body, or storing body and header)
Ben: only applies to async case... is no body, status is a separate resource
Lagally: could combine them
Ben: yes, could do that, but would have to make status member optional, consumer would have to follow link, would have self-links in some cases
… it makes things complicated
McCool: having a self-link in the status object is not the end of the world
Ben: agree
Ben: ok to put it in both places
Lagally: would have a preference to make it mandatory in the body
McCool: best interop approach would be to make it mandatory in both places, and also assert they are the same
… then the consumer can get it from where it is most convenient
… does add some overhead, but...
Ben: I can do that, and is ok
Lagally: why do we need different data models?
Ben: think you might be confusing sync and async cases
… there are different resources for these two
Lagally: in invocation can we just return the action status?
Ben: but our mechanism for distinguishing the two responses would have to change
Lagally: can just put a flag in the response to distinguish the two; a "done" flag can let you know which is which
Ben: so that changes the API a little
McCool: (talks about how sees API would work with single action status)
Ben: could use status section, "pending" vs. "completed"
McCool: I can look at the PR updates tomorrow and give my feedback immediately
Kaz: would also be useful to have some basic background
… maybe we can discuss this mechanism based on this example
McCool: good idea, but would be useful to extend the example to have some output, as ben already mentioned
Ben: have a separate pull request to have a TD at the top to use as an example
… only partially complete; my intention is to keep updating that as we work through other items
Lagally: examples by nature are informative
McCool: even a TM won't work, since a device might have multiple actions; maybe a TM template fragment?
… at any rate we should start with good examples
Lagally: and also to summarize: resource link in both header and body; always return action status
Lagally: for parallel actions, rather than an error, could have a special status, like "blocked"
Ben: I think an error code would be better myself
McCool: I will take an action to create an issue to follow up on this
McCool: then there are notifications of action completion...
Ben: feel we should defer that
McCool: I think keeping it simple for now is best, as long as we are not painting ourselves into a corner
Lagally: ok
data models
Lagally: PR #93
… this moves description to a recommendation rather than a requirement
Ben: send a response to this PR
… not that we don't care about human readability, but it's not central to the "interop" goal, which we agreed we would focus on
… I still think we should remove this section due to conflicting requirements
Ben: other part of this feedback is this could be moved to TD spec; recommendations should be in TD
McCool: titles might be interop issue for UIs
<cris> https://
Cristiano: think style rules are specific to human readability, e.g. multiple languages, etc
… those rules are better treated in the context of the TD
… and it's weird to disallow talking with a thing if the title is missing
… so I think we should simplify the core profile and not include this here
Lagally: so are we aiming at interop between devices or between people?
Cristiano: think of this like linting tools to improve style; code can work, but be bad style
… we want to focus on function first
Sebastian: ml, I understand your motivation; but it does not guarantee the title will be used in a nice way
… someone might just use an empty string; is still open to abuse, in other words
… also, maybe we don't need the title in some cases, e.g. if we are using semantic annotations
… schema.org will already provide meaning from which I can generate button titles, etc.
… don't want to repeat it in the title and description
Lagally: of course we cannot prevent abuse
… people can leave the title empty; but it at least makes them think about it
… so they are not forgetting about it
Ben: this is the same rationale that led to security being unnecessarily verbose
(Lagaly and Cristiano leave)
(McCool takes over the Chair's role)
PR 92
PR 92 - Define protocol binding for events - closes #42
Ben: protocol binding or events using SSE
… (goes through the PR)
McCool: my issue with making subprotocol for event...
… would be better to say protocol should have SSE as a subprotocol
… which spec to be referred to?
Ben: used the reference provided by the ReSpec
McCool: W3C spec or WHATWG spec?
Ben: currently referring to https://
McCool: Superseded REC
… wondering about when the WHATWG spec would become a REC
<benfrancis> https://
Kaz: thought we had discussion with PLH and Ralph at some point
… and Ralph suggested we rather use the WHATWG spec
McCool: right
Kaz: so we should refer to the WHATWG spec manually for the moment?
Ben: yeah, could do so
HTML5 LS - 9.2 Server-sent events
McCool: (describes McCool's latest comments)
<seb> (Sebastian leaves)
McCool: problem with credentials
… should review the security for events
… any requirements for keeping connection open?
… need to clarify what the role of Profile is
Ben: one benefit of SSE is being a builtin mechanism
… not clear to which protocol to be pick on the server side
… and some concern on the client side
… limit of 6 connections per domain
McCool: agree we should consider SSE
… and we should agree the scope of the Profile is limited
Ben: fine to have multiple event operations
… this is implementation-specific limitation
McCool: right
… kind of hacky workaround there
… anyway, still think SSE is the way to go
Ben: what about canonical TD?
McCool: the definition is the same as the original TD
[[
The canonical form should not change URLs - perhaps you meant the form, e.g. with default values filled in?
]]
Ben: responded to that point
[[
The important part here is that defaults need to be applied to the Form, otherwise there may not be a Form with a subscribeevent operation because the op member may have been omitted. Specifying Canonical TD is just a shorthand way of saying to apply defaults first. Please let me know if you can think of a better way of specifying that.
]]
Ben: a form with default supply
McCool: would be safer
… maybe it's self-contained
… (adds another comment)
… probably safer to just explicitly say "apply all defaults" and not depend on canonical TDs
Ben: in the Scripting API, you can close the connection
… Web browsers basically keep the connection
… the server can also provide recommended period
McCool: webhook is right way to handle the problem
… (looks at another comment from Ben)
[[
but I don't think it's common to use a URL
]]
McCool: any other comments?
… not convinced we can merge this PR 92 right now
… do we want to make this "PENDING"?
Ben: noted three action points here
… subprotocol of SSE
… WHATWG version of spec
… replace canonical TDs reference with "Forms with defaults applied"
… based on the discussion today
PR 94
PR 94 - time format - initial draft
McCool: any thoughts?
… (adds some comments)
… constraining datetime reduces complexity
… but doesn't necessarily improve interoperability
… if we do accept this PR, a dependence on canonical form is OK since that part of canonicalization is not likely to go away
PR 87
PR 87 - Placeholder section on transport security
McCool: related to https://
… Update Secure Local Transport
… Local HTTP CG doesn't have resolution
… any thoughts/comments?
Ben: what we can say is an easy way possible
McCool: (adds a comment)
… don't think we can mandate HTTP...
… so defer it to the WoT Security Best Practices document
… anybody knows any information?
Ben: for interoperability, should provide a list of security schemes.
McCool: (adds another comment about that)
… API key is open-ended
Ben: we already have a list of security schemes
… none, barer token, OAuth2, etc.
McCool: we should review the list and perhaps constrain them a bit
… even OAuth2 has some variations, e.g., on where the token is embedded.
… we should also perhaps disallow certain things like "in": "uri"
… which is generally a bad idea but is there for compatibility reasons
Ben: how to proceed?
McCool: can continue the discussion by emails as well
… to get a consensus
Ben: we want all the Editors to approve the PRs. right?
McCool: yeah
… basically consensus-based
<McCool> https://
McCool: we should have some appropriate policy
Ben: what about the other groups?
Kaz: depends on groups
… we, WoT WG, can clarify our own policy
… like we did for the Marketing purposes
McCool: (shows the policy for the Marketing TF)
Policies and Publication Procedures
McCool: can have discussion during the WoT main calls as well
[adjourned]