Coucou
Extrait tres interessant:
Imagine every single device having an IP address, and from there an actual name. Take for example thermometer.floor1.house.john.smith.com. That's a good start, but how will we know what that device can do? How will other devices be told how to communicate with it? What can thermometer.floor1 offer to the Internet at large? In more technical terms, the problem is that of discovering the device and its API (an application programming interface, which is an interface implemented by a software program to enable interaction with other software).
Using IP addresses and the DNS can solve this problem very elegantly, using the techniques .tel has perfected; leveraging the DNS infrastructure to expose communication channels and entry points. Here's a concrete example: Assume I own a Ford GT and a fridge. Both are fully networked and both are full of really neat sensors. I could set up my .tel domain to not only let someone (securely) discover the existence of these machines, but also what they can do. Here's how I'd set up my .tel domain:
fridge.devices.henri.tel would have records like:
x-temp:http+x-inside =>
http://fe80::222:41ff:fefa:e3ba/temp/
x-pwr:http =>
http://fe80::222:41ff:fefa:e3ba/power/
and fordgt.devices.henri.tel could have records similar to the below:
x-temp:http+x-outside =>
http://fe80::222:41ff:fefa:e3be/deg/
x-vol:http =>
http://fe80::222:41ff:fefa:e3be/gastank/
where both fridge and fordgt would update their location (LOC) records in real time (obviously the fridge wouldn't move too much, but hopefully the Ford would).
Of course these are just hypothetical records, but anyone defining an x-temp service type could specify how that would work over http. For example, appending "get_temp" to the url could return the temperature of the sensor.
