Meeting minutes
minutes
<kaz> Mar-23
McCool: note I have not updated the profile Implementation Report, mostly have been working on arch Implementation Report
Lagally: regarding events, ben was working on a PR
Lagally: any objections to publishing?
… hearing none, we will publish these minutes
<mlagally> https://
new issues
Issue 190
<kaz> Consider splitting Use Cases & Requirements out into a separate document
Lagally: new issue #190
… ben noted that use cases and requirements should be moved to another document; has "blocks publication", not sure why
<kaz> Issues which block further publications
McCool: suggestion to resolve this particular issue is to change name to "summary of use cases and requirements"
Lagally: more general issue is we do need to review "blocks publication" usage
McCool: still only about 1/3 of the use cases are marked this way
profile names
Lagally: four have been proposed
<kaz> Core Profile
<kaz> Core HTTP Profile
<kaz> Baseline Profile
<kaz> Baseline HTTP Profile
McCool: I would prefer "HTTP Baseline Profile"; core is contentious, and HTTP should be mentioned
<kaz> Core profile name has undesired implications
Lagally: I would support HTTP Baseline or Baseline HTTP
Kaz: so there could be extensions, right?
Lagally: yes, for example, to include event
Kaz: in that case, concur
<mlagally> proposal: use the name "HTTP Baseline Profile" for the HTTP profile that includes properties and actions.
<mlagally> proposal: use the name "HTTP Baseline Profile" for the HTTP profile that includes properties and actions. (closes https://
RESOLUTION: use the name "HTTP Baseline Profile" for the HTTP profile that includes properties and actions. (closes https://
<mlagally> Proposal: Split core into baseline + (multiple) event bindings
profiles for event bindings
PR 188
<kaz> PR 188 - Split Core Profile into HTTP Baseline Profile and HTTP SSE Profile
Lagally: see PR 188, draft where SSE and WebHooks broken into separate sections, and use names "HTTP Baseline Profile" plus "HTTP SSE Profile" and "HTTP Webhooks Profile"
Lagally: not sure how security got moved
McCool: looks like it was part of error responses, which was moved above events, which is fine
McCool: my personal opinion is that having separate profiles for SSE and Webhooks makes sense
… although might lead to some fragmentation, better than alternatives
Lagally: concur, let's merge
contributions
PR 145
<mlagally> PR 145 - removing outdated+obsolete content
Lagally: PR 145 - remove outdated content; merge conflict, will resolve and merge
Lagally: PR 135 for Issue 104
<mlagally> PR 135 - Define order of arrays in queryallactions - closes #104
McCool: only one minor point, should really say "chronological order as seen by the server", but ok with merging as-is
Lagally: ok, merging
PR 131
Lagally: PR 131
<kaz> PR 131 - initial draft of a "common constraints" section
McCool: I would like to suggest that we hold this PR and take comments and improve it.
Lagally: have been waiting for comments
McCool: are there any constraints that are not data model constraints? Eg. time and date formats are data model constraints.
Lagally: would suggest merging as a placeholder for now; if we don't need it, can delete it later
… have a merge conflict, will fix
McCool: suggest extend ed note to say will remove if there aren't any
PR 127
<kaz> PR 127 - Add timestamps to actions protocol binding - closes #101
Lagally: PR 127
… timestamps to action protocol binding
McCool: my concern is that not all constrained devices will have a clock
… and if this is mandatory, means that it can't be implemented on Things without them
Lagally: let's start by assuming clocks are not synched, and might be low-resolution
McCool: not a total blocker, since devices capable of HTTP probably also have an RTC
McCool: but at the very least it adds a hardware requirements
McCool: feel there are two options: add hardware requirement, make it optional
<kaz> High Resolution Time
Kaz: wondering about resolution of time-stamp data
Kaz: might want to see what it says about time resolution
Lagally: would say it is very device dependent, resolution might be quite low
Kaz: depends on the use cases, we should perhaps define
McCool: agree, we should think about purposes: sequence, elapsed time for actions, etc.
… for instance, maybe we only need sequence numbers and relative time
… also, there is the problem of initializing the clock; when is that done? Onboarding?
Lagally: so sequence numbers and relative time?
McCool: may not even need that, have sequence from query ordering
… as kaz said, we need to be more precise about use cases
PR 87
<kaz> PR 87 - Placeholder section on transport security
McCool: think this makes more time to discuss than we have
Lagally: ok, will defer
adjourn