<kaz> Lagally, Cristiano, Kaz
<kaz> scribenick: mlagally
mmc: non members should be aware of
the patent policy
... we have updated the agenda, will decide FPWD today.
<kaz> (Hoya-san from JBA, Yun_Li from Tencent , Yamaoka-san from Yahoo and Josh from W3C Team)
mmc: tomorrow's main call is cancelled
kaz: discussion in MEIG and WebRTC
group about testing environment created by ... project
... it would be nice to collaborate with them
mmc: please add to agenda of a future
testing call
... probably first week of November
... We did other joint calls, follow-ups are in issue
trackers
... for example APA follow-up, planning a meeting for Dec
9th.
... probably other follow up actions as well
<inserted> [Kaz has just added an entry for the future PlugFest/Testing call]
mmc: there's a moratorium for publication starting tomorrow. We either decide today, or it will be pushed out to November
<kaz> Publication moratorium (Member-only)
sk: We have 3 PRs, let's review
... issue 986 gets merged
... MR 989:
... I fixed a bug in example 8
... some other typos and formatting changes
<kaz> PR 989
sk: MR was merged
<kaz> PR 993
sk: MR: 993
... we need a tentative namespace until we have allocated a new
one
... some discussions about the tentative namespace
<McCool> proposal: proceed with FPWD of the TD 1.1 editor's draft after merging PR 993
<McCool> proposal: proceed with FPWD of the TD 1.1 editor's draft after merging PR 993, with short name wot-thing-description11
RESOLUTION: proceed with FPWD of the TD 1.1 editor's draft after merging PR 993, with short name wot-thing-description11
<McCool> proposal: proceed with FPWD of the WoT Discovery editor's draft, with short name wot-discovery
<McCool> proposal: publish the FPWD of the WoT Discovery editor's draft, with short name wot-discovery
RESOLUTION: publish the FPWD of the WoT Discovery editor's draft, with short name wot-discovery
<McCool> proposal: publish the FPWD of the WoT Architecture 1.1 editor's draft, with short name wot-architecture11
RESOLUTION: publish the FPWD of the WoT Architecture 1.1 editor's draft, with short name wot-architecture11
<kaz> https://github.com/w3c/wot-profile
<McCool> proposal: publish the FPWD of the WoT Profile editor's draft, with short name wot-profile
RESOLUTION: publish the FPWD of the WoT Profile editor's draft, with short name wot-profile
sk: we are good to go
kaz: let's send out the transition request today
mmc: we have four presentations, let me do the overview
<inserted> Discovery overview slides
mmc: the draft of the discovery
architecture is still very rought, please create issues or provide
feedback in this session
... we are *prescribing* a new system
... this is like late binding
... support search based on content, geospatial search
... local and global context, not limited to local network, also
peer to peer
... directories are special kind of things
... we have a two-phase concept, we don't want to ignore existing
protocols but some have privacy/security issues
... we have a protected exploration mechanism
... first phase is "introduction", "exploration" is 2nd
... we want to make sure not to leak any information and protect
data
... <mmc explains the diagram on slide 3>
... we look at various mechanisms to return URLs for
introduction
... sometimes the link is typed, sometimes we don't know if the
link points to a directory or to a thing
ml: difference between a TD and a directory?
cristiano: we will look into standard ways to connect with directories with other protocols
mmc: please create an issue in the discovery TF repo
zkis: we standardize discovery because of security and privacy, otherwise it could be just an application
mmc: yes, it also belongs into
architecture, since it is prescriptive
... we have some open issues, specifically wrt. geospatial
data
... JSONPath is not a standard yet
... Federation, chained queries
... Lifecycle - we need to clarify / create diagrams
... registration needs some additional work
sk: is geospatial query also considered in semantic search?
mmc: you could include geospatial
info in TD and write a SPARQL query, which requires a full SPARQL
impl.
... we want to support a simple filter implementation and not
require full SPARQL
... need to discuss with other groups
... want to make it implementable by lower end impl.
zk: How to handle multicast queries
mmc: directory would not respond to mDNS query ...
zk: want to map to existing scripting API
mmc: in scripting you have some
options to do dicovery
... the actual fetch is in the 2nd process
... we have to make sure to include privacy controls
zk: we have provisioning for multicast discovery, need to do some mappings here
mmc: we never return a TD directly, always authenticate via a URL first
<7 mins break>
<kaz> scribenick: cris_
<kaz> WoT Discovery Introduction Mechanisms
toumura: (shows outline)
... list of different introduction mechanisms: direct, well-known,
DNS, CoRE and DID
... finally a discussion about security/privacy
... an introduction mechanism is to find an URL which points to a
Thing Description or a Thing Directory
... accessing TD should be authenticated
... this mechanism does not define new protocols but uses the
existing ones
... the content type of the resource pointed by the URL should be
td json
mc: there might have some cases where
the authentication is not required, like public TDs. That's why it
is not a MUST but a SHOULD
... well-know is used when you have to guess the real url from an
ip address
sebastian: in the first part you are
saying that you're looking for URL but then you require that the
content-type should be a td-json
... are you looking for URL or TDs
mc: first you looking for URL and then you have to a GET in this URL to retrieve a TD
lagally: we could you TDDs to publish Thing Models, have you explore this possibility?
mc: we have consider it but it is not in the current draft
toumura: so let's start with the
first introduction mechanism. Direct method is really simple is
every time you get URL. Like from QRs or Bluetooth
... beacon
... Well-know URI on the other hand is based on RFC 8615.
... the next one is DNS service discovery. We can use multicast DNS
to discovery Things or TDDs
... we have defined DNS-SD service instance name in
... the format
<instance>.<service>.<domain>
... currently we prescribe that service MUST be _wot._tcp or
_wot._upd for things
... and _directory._sub._wot._tcp for TDDs
... when consumer resolve the service it can inspect the type field
to know if it is a TDD or Thing
... another method is CoRe-RD which is a draft specification of
IETF
... we have defined two endpoints type there.
... finally the last method is DID
... DID define a service where you could retrive a TD or access
TDD
... about security some introduction mechanisms must be used in
trusted environments. For example use private networks (i.e. VPNs
etc.).
... Also TDs should be protected for example using OAuth
mc: we can't trust introduction
mechanisms
... we should recommend people not include any sensible
information
... i.e. use opaque URLs (i.e. not
my.domain/this-is-my-wallet)
... in the end introduction methods are not safe
kaz: do we need some encryption and/or abstraction mechanism for URLs and TDs, e.g., not directly using myHome/Living/AirConditioner as the URL
mc: I have to do research on the
topic
... for example tiny url is a pretty famous option
... another thing is that DNS have extra fields for metadata. I'd
like to discourage to use them...
... like for example the type of a device
... we could even leave off the distinction between td or tdd,
because we could later inspect the TD to know if it's a TDDs
... however knowing beforehand that it is a TDD could spare some
time.
<hazel> left to join TPAC
cris: in M-DNS does a TDDs answer the query with all the contained TDs?
mc: just its Thing Description
sebastian: another topic can we trust the received TDs from a discovery step?
mc: we can always use mutual
authentication
... or we could use signed TDs. We've been discussing that with
LD-proof
... group
... however there're some technical challenges there.
toumura: what about verified credentials?
mc: we could use certificates in DID
kaz: I think extending TD with a way to singed them would make sense given Verifiable Credential is data model with encryption for users' credential management and TD is a data model to handle Thing information.
zoltan: is discovery meant for operational stage?
mc: we need to include more discussion on this topic on the document. Right now we are describing more the operational stage
<kaz> s/a way to signed them/a way of signing on/
mc: another thing is the concept of a
process able to discover Web Things and register things on a
TDDs
... onboarding is more about giving the keys for registration than
the actual registration process
lagally: should the device be active when it is registered?
mc: I think yes, because people would aspect to talk with the device when its discovered.
lagally: I think it is just one use case but whole picture could be different
mc: it is an open issue
lagally: I am thinking of scenarios
where the device is registered but not active
... we should not make assumption about the status of a device.
mc: operational it means that it can talk to the network.
farshid: we could also have different
TDDs
... each one specialized to a specific status of a device
(operational or not)
mc: it is equivalent to have metadata on the TD
lagally: what do you do when you have contradicting responses from different TDDs?
mc: it should never happen if they are trusty directories.
farshid: the consumer could already
know which has operational TDs
... probably we are overthinking it.
kaz: what about adding trustiness and response time constraints to TDDs?
mc: yeah great point please open an
issue about this.
... time check, farshid should present Directory API
<inserted> WoT Directory API
farshid: the api is composed by a set
of sub api: registration, notification, search, and managment
... management is a wip.
... the api is described as a Thing Description
... (shows the TD in the discovery document)
mc: technically this is a thing model
farshid: right
<kaz> s/what about adding trustiness and response time constraints TDDs?/It sounds to me that we might want to add trustability, response time, etc., as possible evaluation features of TDDs for advanced directory services./
farshid: please try this thing model
and provide feedback
... back to the API. basically is a typical restfull API.
... a simple POST to /td creates an anonymous Thing Description
record
... however you could do a PUT /td/{id} to create a TD with a
specific id
... with PATCH you could use partial TDs to update the database
record
... a GET operation on /td endpoint returns a list of all TDs.
However, it requires further discussion. Big TDs are challenging...
and probably will require pagination/streaming
... another solution is return just links, but it is too heavy to
GET every one of them later
... we could also prevent the creation of big TDs
... another topic that needs to be discussed is streaming
sebastian: I have several questions: on slide 4 do you have already in mind the payload type of the id returned in the POST ?
farshid: it is returned in one specific header
sebastian: what do you mean by streaming? is it a subscription on TD events?
farshid: no it is about sending a big list of TDs
mc: On slide 5, it is a pretty rare
use case to ask for all the TDs.
... I do agree that big TDs are problematic, one simple solution is
to limit TD size and return an error
... another problem is encode TD is small udp payloads
farshid: regarding listing all TDs I
think it is pretty usefull... like in UIs
... we have to look to json-line which is a protocol that let you
read json line by line
mc: HTTP/3 and QUIC are other interesting protocols
ege: HTTP/3 is already a reality
<McCool> s/quick/QUIC/
ege: 2.9%/s of internet traffic is already on HTTP/3
<kaz> Web Transport WG
kaz: there's a proposed WG that would work on APIs for QUIC on QUIC
<kaz> W3C API
<McCool> ... also W3C Team provides API to access the W3C DB, and that includes pagination, for instance
kaz: my third point is about the
PATCH command within the proposed Registration API. how to deal
with TD fragments is a little bit complicated, also PATCH is
challenging
... how to extract the fragment is still under discussion
right?
farshid: we'll talk about that
later
... partial TDs is just a part of TD
<McCool> (comment: diff format for changes could also be used for patching... needed anyway to delete things in PATCH...)
farshid: in TDDs you can also subscribe for different events.
mc: the diff could be also used to
partial deletion of part of a TD
... about id, we have a local identifier different form the TD
id
sebastian: what kind of subprotocol do you have in mind for notifications?
farshid: we are using SSE, but we
have to add some feature on top of this
... for example old libraries did not support authorization
daniel: slide 8 there's naming inconsistency, could you harmonize it?
farshid: yeah there's a mistake
... finally, we have defined error responses. For now they are
omitted because they need more discussion on the TD task
... there are still some open issues, for example usage of OAuth
socpes for fine grained access control, Anonymous TD deduplication
etc.
mc: time check, we have 40 minutes left. let's do a short break (5 minutes) and start again.
<kaz> [5min break till 10:23 EDT ]
<FarshidT_> I just checked, it wasn't a mistake. "updated_td" is the event type. "td_updates" is the field inside the event object that is set to the td diff. We can try to harmonize if it is unclear.
<kaz> scribenick: kaz
ca: Discovery in a nutshell
... JSONPath syntactic discovery API example
... sample TD on the left side
... app-TDD sequence diagram on the right side
... query from application
... and answer from the TDD
... XPath syntactic discovery API example
... this time the query is XPath
... and the answer is array of strings
... including TD fragments
... Example syntactic discovery queries
... JSONPath vs XPath
... Pros and Cons
<inserted> ... Pros
ca: short and expressive
... passed as URL query parameters
... XPath is a standard
mm: comparison between JSONPath and
XPath
... JSONPath is more directly fits JavaScript
ca: yeah
... Conclusion
... JSONPath must, XPath should
... array of TDs and array of TD fragments
... privacy&security
ac: could we use combination of conditions?
ca: yes, like this (on p12)
... combination of title and created date
ac: what about searching for all the gateways?
ft: maybe using created dates?
... but we need to wait until JSONPath becomes a standard
<FarshidT_> slides: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-online-f2f
<Zakim> dape, you wanted to fallback if JSONPath never becomes a standard?
<FarshidT_> jsonpath draft: https://tools.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html (S. Gössner is the original author)
<McCool> ... ah yeah, the month is wrong ;)
<McCool> ... will have to fix that
<dape> https://www.w3.org/TR/xpath-functions-31/#json
<FarshidT_> Let's talk about IETF standardization of JSONPath: https://github.com/cburgmer/json-path-comparison/issues/70
sk: what about the standardization for JSONPath within W3C?
kaz: I thought Ivan mentioned there
was a plan for standardization during the joint meeting the other
day
... so we need to wait for that (for the normative reference)
... meanwhile we can add a reference as an informative
reference
<FarshidT_> @kaz I don't get it. The slides are here: https://github.com/w3c/wot/tree/master/PRESENTATIONS/2020-10-online-f2f Where did you get that URL?
<McCool> ... right, but the day should be 20, not 07, so it sorts correctly...
<McCool> ... I will fix
mm: note that we do need a normative reference based on a concrete specification at some point
ac: TDD and discovery
... SPARQL semantic discovery API
@@@syntactic/semantic queries are presented by Andrea
ac: SPARQL semantic discovery API
exmple
... SPARQL queries examples: SELECT
... SPARQL queries examples: ASK
... SPARQL queries examples: DESCRIBE
... SPARQL queries examples: CONSTRUCT
mm: one possible use cases is having
multiple lights
... analysis of content needed
ac: that can be handled
... then Advanced SPARQL queries
... more interesting part :)
... SPARQL allows query federation
... TDD forwards the query to other TDDs
... former TDD returns a unified query answer
... Pros: allow extending discovery criterion to other TDDs easily
and extends the discovery scope
... Cons: TDDs addresses must be know beforehand, also brute force
forwarding
... example
... assuming 100 TDD services here
... put under "VALUES ?tdd" section
... Pros and Cons of SPARQL
... Pros: expressive and it originally has query capability, also a
W3C standard
... Cons: possibly verbose than JSONPath/Xpath, consumes more
resources, also complex (than JSONPath/XPath)
mm: given we just have 2 more mins,
the details to be discussed during the discovery calls
... federation definitely needs some more discussion
... note that there will be no Discovery call next week on Oct
26
... please create GitHub issues for the discussion
sk: are there any implementations
other than LinkSmart?
... e.g., SPARQL-based one?
ac: planning to release one
mm: having a SPARQL end point would
be great
... btw, does LinkSmart have semantic query capability?
ft: no
mm: need a second implementation
then
... also we need some converter from semantic query to DNS-based
discovery services
mm: tomorrow we'll talk about TD
[Day 3 adjourned]