See also: IRC log
<trackbot> Date: 07 July 2015
Scott: Physical web
discussion
... web page to control
... started 18 months ago and open source project
... discovered privacy and efficieny issues
... use BLE
... BLE is connection less, advertise based
... stick to single basic packet, 18 bytes
... step 1 advertise
... step 2 - client, open sourcing of client
... going through proxy is good for content, privacy
... considering spam and security
... physical web should reflect original spirit of web, so no
centralized authority
... safe search API, get rid of phising sites, spams from
beacons
...
https://github.com/google/physical-web/blob/master/documentation/introduction.md
... standardize the broadcasting
Arne: question - easy to clone
such beacon, is there a mechanism to prevent that
... depending on context
Scott: lots of security issues,
discussion on parking meter use case
... being interactive is the key
... Arne's concern is a valid one, need to consider spam
filtering, trying to make it more secure
Arne: Apple's iBeacon is
centralized approach
... what are pros and cons?
Scott: there is no register, just
a number for iBeacon
... difficult to figure out what to do with the number
... need to have apps, difficult for discovery
... iBeacon is centralized which is against the philosophy of
web
... users need to give a lot of permissions
... user might receive a lot of notifications from such
beacons
Joerg: physical web could be
entry point for WoT
... is there a different means of interaction
... having a browser find and click on things is the
simplest
discussion on that
Scott: devices could be
broadcasting URLs, schema based ad saying a device is a
light
... self discovery
... a lot of emphasis on security
... trying to form a proximity-dns
... not going too far in protocol stack
... mDNS version is there
... it solves some security issues
... not everything is good with BLE
... use multiple tech like SSDP, mDNS, BLE
next Arne's discussion
Arne: structure the thoughts of
discussion in wot-di
... extend the wiki page with new tech on discovery
... landscape divided into four categories
... discuss the categorization aspect
... next aim - derive generic discovery interaction
patterns
... for WoT
... one could be finding things around me
... first category - UriBeacon
Scott: comment - finding things - "white-listed" things from pre-installed apps (iBeacon) and "unknown" or "any" things (uribeacon)
Arne: wiki modified
... finding thing in my network
... mDNS
... implemented by Apple Bonjour, UriBeacon
... next SSDP, multitask approach
... CoAP based approach
... next web service discovery
https://www.w3.org/WoT/IG/wiki/Discovery_Categories_and_Tech_Landscape
Arne: third category - searching
in directory
... first candidate is CoRE resource directory
... second - XMPP IoT discovery
... third - sparql endpoints, a complex one, allows advanced
queries
... fourth categories - accessing thing metadata
... access metadata resources after we find things
... CoRE link format is a candidate, provides a well known
entry point
... HATEOAS is another one
Scott: comment - JSON-LD could be used in place of XML
Arne: we are looking at JSON-LD in thing description
Scott: suggest to include JSON-LD in category four
Joerg: hook to what is discussed in TF-TD, hand over from discovery from thing description
Soumya: joint TF-DI and TF-TD call at 9AM and proposed discussion there
Joerg: not defined what is web
thing in tech landscape wiki
... looking for bringing web connectivity at small things
discussion on coming F2F in bay area
Joerg: start a principle kind of
taxonomy of categories
... short taxonomy to compare technologies for discovery
... put them at the beginning of the wiki sections
Arne: tie that up with use cases, list also pros and cons
Scott: add - things that want to
be discovered, things that want to be controlled, put a bit in
the physical web
... category 1 and 2 are finding real things while category 3
is finding resources, directories
... category 3 might need UI based search
Arne: agrees on the points
Scott: we can put a LDAP server in category 3
Joerg: XMPP IoT discovery - built for things that are largely distributed - look for a thing with particular metadata or location or serial no. - not sure about what is look up in directory
Scott: discussion on interoperability and metadata, structure of things, discovery, metadata - need to know what is the stack to be created
Joerg: certain scenarios do not
have directories while some others might need to register
themselves into directories
... diff kinds of discovery, how they are addressed in tech
landscape, commonalities in technologies, context and purpose
of discovery
Scott: interface between the categories using "an address"
Joerg: good comment
Soumya: continue the discussion on next TF-DI meeting
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Soumya Inferring Scribes: Soumya WARNING: No "Topic:" lines found. Present: Arne Soumya Scott Joerg WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 07 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/07-wot-di-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]