<McCool> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#13_Dec_2017
<kaz> scribenick: GraemeColeman
<kaz> Graeme: from Paciello Group
<kaz> ... interested in relationship between WoT/IoT and accessibility
McCool: Anyone have anything to report?
(none)
McCool: Agenda item 1: Next face-to-face, to be held in Prague March 24-29, 2018.
<kaz> Prague f2f wiki
Koster: There will be a joint meeting
on Friday 23rd 2018, and an IETF Hackathon in London on the
17th + 18th March
... If you're interested in semantic interop, you are
encouraged to go to WISHI as part of the IETF.
McCool: As before, people need to start to propose topics for the plenary and breakout sessions.
Kaz: We are still working on a schedule for the plugfest
McCool: There will also be a Plugfest meeting call today immediately after this meeting.
<kaz> (PlugFest wiki has been updated)
McCool: Do we have a host for Plugfest? At this moment, it's not clear.
Sebastian: We do not have the latest news about who will host, but this will be discussed.
TF report 1 - Thing Description
Sebastian: MK proposed some changes to
the Thing Description, including introducing and renaming such
as using "form" instead of "link". This Friday's TD meeting
will cover producing a simplified version of the TD. Siemens
will provide a simplified version that follows the Mozilla
version.
... Also asks the group if it will be OK for this week's TD
meeting to be the last meeting for the year, as next Friday is
the start of the Christmas holidays, as DA will be not be
around (so a new moderator will be required). DA will be back
on the 8th January.
McCool: Suggests that the Wiki page should be updated to reflect the new meeting times after the Christmas holidays. At the moment, TD will meet this Friday (15th).
Sebastian: If there is someone able to moderate on the 22nd, the TD will go ahead on the 22nd - otherwise, it won't start again until the 12th January.
Sebastian: They will have a draft proposal for this friday
Task force report 2 - Scripting
<kaz> dp: conditional notification
<kaz> ... and security information for scripting
Daniel: 1st point How often do you
get informed, 2nd point relates to security. They noted that
security is a bit vague so far, so the scripting does not
support any possibility to populate security information in the
scripting.
... Once we proceed, we plan to integrate security into scripting as well.
... The next meeting will be next week, and then one in the new
year on the 8th, but this will need to be confirmed at the next
meeting (once they know holiday schedules).
TF report 3: Binding Templates
Koster: Yesterday's meeting covered
the idea of a resource that you get in response to actions as
well as event patterns. Another meeting will be held next week,
but not another one until the 9th January.
... Plan to have a document around the 9th January to meet W3C
publication deadline, even if it is still relatively loose and
not fully figured out.
... Also have slides on conditional notifications.
<mjkoster> https://github.com/mjkoster/wot-protocol-binding/blob/master/Notification.pdf
<kaz> (above presentation to be presented after the Security TF report)
TF reprt 4: Security
<McCool> https://github.com/mmccool/ndss-wot-sec/blob/master/ndss-wot-sec.pdf
McCool: Paper submitted yesterday.
... Feel free to point people to
the above URL. The paper covers the various issues, risks and
opportunities that arise for security.
... Next step is to get the note published. There are still two
broken URLs that need to be fixed - if it can't be fixed today,
it won't get published until next year.
<kaz> Koster's slides
Koster: Discussion on notifications
<inserted> [Conditional Notification]
Koster: Talks about asynchronous notification, which results in a sequence of notifications that conforms to a filter specification. These consist of time and value threshold controls. Exists in IETF drafts (e.g. IETF CoRE), OMA LWM2M and OCF, as well as others.
<kaz> [IETF - CoRE Dynlink (draft)]
Koster: IETF - Core Dynlink (draft):
The first that the others are more or less loosely based
on.
... Time threshold controls pmin and pmax, value threshold
controls gt, lt and st.
<inserted> [Threshold controls]
Koster: pmin = minimum period between
notifications, even if data are changing frequently
(effectively a noise filter).
... pmax = maximum interval between notifications. Even if data
haven't changed, you might still want to send out a
notification. Useful for long term synchronisation of things
that don't change often.
... st = minimum reportable change in data. Prevents seeing
tiny little changes that may not be hugely
relevant/important.
... lt and gt. If you have too little water in a water tank, it
will warn you if it's less than (say) 10%, or warn you if it's
greater than (say) 90%.
Sebastian: Question - Is there anything relating to stability flags?
Koster: Stability flags/numbers are indications of how noisy/variability over time is expected. It relates to pmin and st parameters. You could set st to be a bit larger, and pmin to a bit longer.
Sebastian: Stability could be defined with pmin and pmax, because stability relates to how frequently the value changes - but now we have two parameters instead in one.
Koster: You could expose similar things - instead of saying something stable or unstable, you could use st (step) to characterize stability, i.e. "This is how much stability I accept"
McCool: Does the threshold apply
before or after quantization?
... We need to be clear, as we don't have any way of reporting
the value before quantization. So, these thresholds can only be
based on the reported values.
Kaz: This method currently focuses on interval, but what about concrete time synchronization in the client/server?
Koster: You can use pmin and pmax to do that - for example, if you want to create periodic samples, you set pmin and pmax to the same value. So if you want a sample every 5 seconds, you set both to the same, and you get a sample every 5 seconds.
Kaz: This could be useful for origin time.
Koster: You could have more frequent reports by combining parameters, e.g. pmin, pmax and st.
<inserted> [Reporting mode]
Koster: Reporting mode (currently in
design and being incorporated)
... Whenever lt or gt are crossed in either direction, you get
a report.
... Band mode - when a sample is above/below lt/gt, we want to
report whatever is outside the limits of these parameters. e.g.
when the signal is above/below these parameters, notify me
every 5 seconds, otherwise notify me every 30 seconds.
Conditional Observe
Koster: pmin and pmax can be provided as parameters in the URI, and can be configured differently.
McCool: Can I use decimals for the unit of time?
Koster: Typically, they are integers and in seconds. MK has some use cases that require subsecond resolution, but currently it is integer based.
Kaz: What about other kinds of conditions? e.g. pmin equals less than something?
<kaz> (or (temp<10 || temp>80) :))
Koster: All of the rules are applied together so that everything is true to trigger the notification.
MLagally: How do you change a subscription of observer? Do you have to clear it first? Is there an unsubscribe mechanism already defined?
Koster: Currently, with coap, you have to unsubscribe. Per client you can only have one subscription, although theoretically you can have any number of clients each with their own subscription. For one client, you cannot apply more than one filter.
<kaz> (we're getting the end of the hour...)
<kaz> [Koster goes through the rest of the slides: CoRE Dynlink Bindings, CoRE DYnlink example (local update), CoRE Dynlink example remote update), OMA LWM2M Notification Control, OCF Conditional Notification, Notification Patterns, Subscription creation, What is an Event?]
Koster: The rest of the presentation
covers different ways of applying these parameters - link
bindings (example provided in the slides), OMA LWM2M
notification control, OCF conditional notification,
notification patterns, what events are.
... The slides introduce use cases, but the next step will be
to make a specific proposal about how to handle all this - such
as exposing specific parameters to the client, but also how to
let the client know they are available, while other times how
you can set this up with an observe.
Kaz: Can we create an issue on the Github repository for this? This topic is related to TD, scripting and binding
McCool: Can the presentation be shared?
<mjkoster> https://github.com/mjkoster/wot-protocol-binding/blob/master/Notification.pdf
Koster: Will open a Github issue related to this presentation.
<kaz> [adjourned]