Expand the Direct method

[relu91]

Now that FWPD is almost out I think we should improve the direct introduction method and extend it to also non-HTTP URLs. I propose to follow what we have already done with HTTP. In particular, in the document, we defined a standard way to retrieve TDs from an HTTP scheme URL:

A GET on all such URLs MUST result in a TD.

I propose to do the same also for other protocol bindings. I think the best approach is to have a dedicated section in the https://w3c.github.io/wot-binding-templates/#protocol-vocabulary that describes how TD fetching should happen when an URL is given.

Another open point is how to deal with security. HTTP has a security negotiation mechanism, but other protocols may lack this feature.

[zolkis]

FWIW there is "direct discovery" for OCF, too.

[danielpeintner]

I guess the idea is to propose "well known" addresses as mentioned here also...

[relu91]

I guess the idea is to propose "well known" addresses as mentioned here also...

It is more about what to do with just an URL. For example, with HTTP we prescribed to use a GET; for MQTT we could use SUBSCRIBE, etc.

[mmccool]

We should probably start with a limited and finite set of protocols, at most CoAP, HTTP, and MQTT. Also, these may also apply to directories (including to the initial fetch of the TD of the directories). I think it is reasonable to specify synonyms for GET. Note that if we use a TD (or TM) to specify the network interface for a directory we can do this explicitly.

A related issue is content encoding. CoAP generally pairs well with CBOR. Do we want to allow a CBOR encoding of query results from a directory, or even just from a single Thing (Direct mode)? Note that we will have to deal with chunking as well (UDP...) but the simple answer is to send the TD as a string serialization (of JSON-LD) embedded a string value in CBOR. That also avoid breaking signing due to conversion of the data to/from CBOR data values. It does require the consumer to be able to parse JSON no matter what, but I think that's ok.

[mmccool]

So regarding well-known URLs, we should clear up the difference between this and "Direct". Direct specifies the location of the TD, period. It does NOT need to be .well-known, etc. The .well-known approach is for when you are guessing where the TD is knowing only the IP address (for instance) of a Thing. I want to avoid having people thing they have to waste bits in a QR code encoding the .well-known etc. I think I mentioned this already and have to re-read the text to see if it was addressed.

To resolve issue #135 I proposed that security schemes for fetching TDs in self-description should be limited to security schemes which the protocol describes the requirements for (since you don't have the TD yet...). I know what that list is for HTTP, but we need to define it for any other protocol that supports self-description.

[benfrancis]

As mentioned in the vF2F call today, when I read the spec I was confused about the distinction between "Direct" introduction and the other introduction mechanisms.

The spec says that Direct introduction is "any mechanism that results in a single URL", but then the terminology section defines introduction in general "a 'first contact' discovery mechanism, whose result is a URL."

• Getting a well known URL for a given host will also return a single URL
• Whilst an mDNS client listening for broadcasts on a local network may receive multiple records from different hosts, my understanding is that an individual DNS-SD record would usually only include one URL per service type
• I don't know enough about CoRE resource directories and DID documents to know how they work, but the examples given also seem to indicate a single URL.

Maybe "a single URL" isn't the best distinction?

Maybe Bluetooth beacons, QR codes (and RFID tags, which aren't currently listed) could instead be categorised as something else like "proximity based"?

[zolkis]

To give examples, the experimental Scripting API for discovery (which is nothing final), currently makes distinction between the following 2 use cases.

1. When the app requests direct discovery with a URL, that is like OCF direct discovery, i.e. a TD of the device (WoT runtime with that address) is expected. If the device is a directory, then the TD of the directory is returned.

let iterator = WOT.discover({ url: "192.168.1.12" });
do {
  let td = await iterator.next();
  console.log("This is the TD of the device");
} while (!iterator.done);  // well, will happen only once

2. When the same thing is requested, but with the "directory" method, then all TDs hosted by the directory that are visible to the client will be served.

let filter = { url: "192.168.1.12", method: "directory"; };
let discovery = WOT.discover(filter);
do {
  let td = await discovery.next();
  console.log("This is the next TD from the Thing directory at " + filter.url);
} while (!discovery.done);  // will happen many times

Edit: if the device is not a Thing directory, all next() calls with reject and discovery.done will be true.

[relu91]

Note that the new https://w3c.github.io/wot-discovery/#exploration-self paragraph covers quite well the requirements that I detailed in the first post. I still believe that this information might be better located inside the protocol binding spec. However, the binding spec is not normative, opening for different implementations.

[mmccool]

I think we can probably close this now, but I've marked it using Discuss as well.