Wot-thing-description: Introducing assumptions about TD instances that have no IP addresses

[sebastiankb]

There are use cases such as from PlugFest like from @citrullin that there are no domain / IP addresses in the TD since this information may change over time. The idea is to take the IP address from the server origin of the TD. This approach is also applied by the html websites.

[egekorkan]

I would say that these are TD models and that a base with a URI template should still be used. If there is any out-of-band information in a TD, like the security credentials, their lack should be obvious, like it is for security. So I would not call it assumptions since assumptions are against the design of TD

[sebastiankb]

I'm not sure about this. TM typically not intended to address an instance specific representation of a Thing. The mentioned TD above is kind of individual, however, relative to the domain where is it come from.

Regarding the issue of identifying the protocol that will not be present in such a TD, I would expect / assume that the protocol used is the one that was used to request the TD.

[egekorkan]

But what would be against having the URI variables in the "TD" in this case?

I would still say that it is not a TD _document_ since this cannot be exchanged between Consumers without out-of-band information, cannot be consumed in the Scripting API way without inserting this information. Also, without at least having a URI template, how would the final TD be constructed would not be known and again require out-of-band information.

[Citrullin]

A use-case where this can be important:
In order to reduce computation on a microcontroller, it makes sense to cache the TD in a persistent storage.
Even when the IPv6 address doesn't change, it would make it more complicated, and therefore more computational intensive, to look into the IP packet and parse the destination address in order to generate the TD with it.
In IPv6 we have at least 3 addresses. link-local, ULA and a global address. When we add the privacy extension of IPv6 to it as well we get even more addresses.
I agree with @sebastiankb in this regards. It would be the same behavior as known from the web.

Regarding the issue of identifying the protocol that will not be present in such a TD, I would expect / assume that the protocol used is the one that was used to request the TD.

This was actually just a lack of implementation at the moment. The flexible nature of the context extension makes it a bit challenging to implement in a deterministic system. Even though it was just skipped for now, I find this use-case quite interesting. I agree with you. That would be an interpretation which makes sense.

[Citrullin]

But what would be against having the URI variables in the "TD" in this case?

I would still say that it is not a TD _document_ since this cannot be exchanged between Consumers without out-of-band information, cannot be consumed in the Scripting API way without inserting this information. Also, without at least having a URI template, how would the final TD be constructed would not be known and again require out-of-band information.

Interesting perspective. If we say the consumer has to check the IPv6 address, before exchanging, we would actually fix two possible issues. If my MCU replies with an ULA address and you exchange this with an entity outside of the scope of the ULA, the consumer outside of the ULA scope would run into issues as well.

[egekorkan]

Well a couple of things here:

• I also agree with the use case that where and how the TD is gotten can be reused. I am however against any kind of assumption, it breaks the design of TDs from my point of view. Without concrete endpoints, TDs become just API specifications (which isn't something bad). Also, this assumption is very bad against the TD directories since where you get a TD is not necessarily the device that it describes.
• Regarding having multiple addresses, here is an example on how that can look like in a TD currently:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyLampThing",
    "properties": {
        "status" : {
            "type": "string",
            "forms": [
              {"href": "https://mylamp.example.com/status"},
              {"href": "http://192.168.0.10/status"}
             ]
        }
    }
}

• The previous example is something that is possible but sadly creates a lot of problems since the Consumer cannot know which form to pick.
• What @sebastiankb proposes is the following:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyLampThing",
    "properties": {
        "status" : {
            "type": "string",
            "forms": [
              {"href": "/status"}
             ]
        }
    }
}

whereas what I was trying to say is the following:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyLampThing",
    "properties": {
        "status" : {
            "type": "string",
            "forms": [
              {"href": "https://{{myInitialConnectionPoint}}/status"}
             ]
        }
    }
}

This can of course be extended to include the protocol etc. There is a related issue to this: https://github.com/w3c/wot-thing-description/issues/897

Differently, I have voiced the need for describing initial connection in this other issue: https://github.com/w3c/wot-thing-description/issues/878 I was not thinking of this use case but I think it can be two birds with one stone. If we manage to describe initial connection and how it can be further used, we would be able to describe MQTT based things properly. For now, there is no sound way of differentiating topics from broker address in MQTT Things.

[Citrullin]

* I also agree with the use case that where and how the TD is gotten can be reused. I am however against any kind of assumption, it breaks the design of TDs from my point of view. Without concrete endpoints, TDs become just API specifications (which isn't something bad). Also, this assumption is very bad against the TD directories since where you get a TD is not necessarily the device that it describes.

This is a question you have to ask yourself in the WG. I find it quite powerful that browser are even able to interpret broken HTML. This may be not the way the programmer wanted it to be, but at least the site is rendered. I am not very familiar with directories yet. Would it be so hard to implement something like this? Or even use a reverse DNS, if needed.
Interesting, what is the TD then? From my current understanding TD is for Things what HTML is for the web. A structured document to describe a Thing.

Regarding having multiple addresses, here is an example on how that can look like in a TD currently:

Okay, so I need to add all my addresses for all my endpoints? A lot of unnecessary additional bytes, from my point of view. I try to avoid exchanging unnecessary data on a microcontroller. I am already not that happy with the fact JSON is used for the TD and not CBOR. Considering the nature of lossy network this can become an bigger issue. Additionally to this: Every ms uptime on a constrained device can reduce the battery life dramatically. But since TDs aren't exchanged that often, I can overlook this. Adding more and more bytes to the TD just makes this issue for constrained devices bigger. And also there is already an issue for that.

If relative paths are not allowed, I would prefer the {{myInitialConnectionPoint}} pattern. Even though this would still not fix the issue for ULA, link-local and global addresses. Or do you exchange this template with other devices? Or provide context data with it?

[danielpeintner]

I am already not that happy with the fact JSON is used for the TD and not CBOR. Considering the nature of lossy network this can become an bigger issue.

FYI: We did some measurements in the past about the difference between minified JSON and binary implementations like CBOR.
see here for some results

My take away at that time was that minified JSON is not that bad (especially when it comes to heavy string-based TDs) compared to binary solutions..
We might (should?) redo them probably.

[relu91]

see here for some results

Nice done! I wasn't aware of those results. I guess every byte counts on microcontrollers, however, it seems that CBOR doesn't make a big difference. Surely, I do not see big issues in supporting also CBOR for TDs in the future. Even more, now that https://digitalbazaar.github.io/cbor-ld-spec/ is born.

About the topic, I agree with @egekorkan we should keep out of band information at the minimum. I also think that the HTML parallelism does not hold too much in this case. The key difference is that browsers have a defined application protocol to fetch HTML documents and resources. In WoT, we did not prescribe a specific protocol to retrieve TDs. The problem is right here in my opinion and it is also related to the Discovery process (i.e. we might say that the base address of every form is the URL used in the exploration phase).

Even when the IPv6 address doesn't change, it would make it more complicated, and therefore more computational intensive, to look into the IP packet and parse the destination address in order to generate the TD with it.

Just wondering, why are you looking to the destination address? Shouldn't it be the sender address? and also this is just a one-time computation. I know that microcontrollers are though but I guess you can afford a one-time string replacement, is it?

[egekorkan]

I agree with comments of @relu91 above. Regarding one time computation, it might be (from my limited experience) relevant for mobile and very resource constrained whose IP addresses can change often. One interesting thing to think about would be defining a way for a Consumer to construct a TD from a TD Model (a TD that has no specific IP address). This way, there would be no extra effort by the Thing to construct the TD.

[Citrullin]

I agree with comments of @relu91 above. Regarding one time computation, it might be (from my limited experience) relevant for mobile and very resource constrained whose IP addresses can change often. One interesting thing to think about would be defining a way for a Consumer to construct a TD from a TD Model (a TD that has no specific IP address). This way, there would be no extra effort by the Thing to construct the TD.

This sounds actually quite interesting, because the TD Model should be applicable to a group of Things.
From my point of view I could imagine the following: The constrained device generates the TD when it gets a request.
So that the IP address is the correct one. The Consumer just checks, if the returned TD matches the TD Model.
After that you don't need to request the TD from the constrained device anymore. Or in case of a dynamic TD Model at least not that often anymore. I know you talked about dynamic/changing TDs. Is there also some kind of interval for checking if the TD changed? Or some other mechanism in order to get informed when the TD changed?
The Consumer should also be able to discover the changing IP in another way. DNS? With the TD Model it should be able to replace the IP address in it then.

[egekorkan]

, because the TD Model should be applicable to a group of Things.
Yes, this was the driving argument behind having such representation formats.
These are all valid points but the following questions should be actually addressed by the discovery task force:

• > Is there also some kind of interval for checking if the TD changed?
• > Or some other mechanism in order to get informed when the TD changed?
• > The Consumer should also be able to discover the changing IP in another way. DNS?

Since @mmccool @farshidtz and others that I couldn't tag now are active in the discovery, I have tagged them here :)

Just some background information:

• TDs are not necessarily hosted by the Thing it describes
• There are TD directories that can be different in terms of default caching/time to live periods etc.
• The TD task force is focusing on describing a Thing's network interface/API. Other mechanisms around it should be dealt separately and should be possible to be dealt separetly, meaning that how a TD is constructed should have no influence on how a TD describes an individual Thing

@Citrullin also from the plugfest you seem to have a really good and not previously explored use case, thank you for the fresh ideas :)

[zolkis]

I also think CBOR should be supported, and it doesn't have the drawbacks of JSON/JSON-LD with binary representations. The work on CBOR-LD seems incomplete, but a good start.

[relu91]

I know you talked about dynamic/changing TDs. Is there also some kind of interval for checking if the TD changed? Or some other mechanism in order to get informed when the TD changed?

As hinted by @egekorkan this is something that goes under the Discovery process. In general, I feel that we have agreed that a TD instance should not change. For example, in handling dynamic resources we are exploring statical ways to describe dynamic entities.

However, in the Thing Description Directory interface we have the means to update a TD and get notified about changes. Constraint devices could leverage on TDDs and offload some TD modification and management processes.

Anyhow, I think too that the mobile constraint device is a nice use case that it has not been sufficiently explored. We should talk about this in the next TD call. Thanks! 👍

[sebastiankb]

From today's TD meeting:

• one idea can be provide a convention in the base like "base":"http://." that IP address should use from TD orign
• alternative can be to exchange such a use case as TM (@egekorkan proposal)
• we should provide a use case description about client side generation of TD instances (@sebastiankb will provide a PR for an existing Use case to include this description)
• this topic will further discussed in the Discovery TF (@mmccool)

[sebastiankb]

this topic will further discussed in the Discovery TF (@mmccool)

@mmccool Are there any news?