Subject: [apps-discuss] Two new Internet Drafts (Independent Submissions)

From: Neng Geng Huang <[email-masked]>
Date: Fri, 4 Jul 2014 23:24:19 +0800

Hello, everybody:

I have submitted two revised Internet Drafts as Independent Submissions.

https://datatracker.ietf.org/doc/draft-huangng-utid/
https://datatracker.ietf.org/doc/draft-huangng-idtp/

Here is a brief introduction to the concepts of UTID and IDTP and discuss
their use through three small examples, showing the potential to construct
a new kind of application architecture for the Internet of Things.

UTID is a unique identifier for a physical thing or a virtual thing in the
world, which consists of three components with the following syntax:

Id~catalog$dns

It is a character-based identifier, where dns is a domain name of
organization who named the thing, catalog is used by the organization to
classify the thing, and id is unique in the scope of dns and catalog.
Examples are 125.product~db$com1.test, ~db$com1.test,
125.product~$com1.test, and ~$com1.test.

IDTP is a communication protocol to tracing messages of things identified
by UTIDs, which adapt request/response model and like a hybrid of HTTP and
Web Service but using JSON data format rather than XML format. It is
characterized by using UTID rather than URL to indicate the destination
address and using build-in forward mechanism to trace the messages of
UTIDs. The forward rules are UTID suffix match (called *tracing rule* in
this paper) and namespace match (called *tracing track* in this paper). The
underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web
Service, or local handling without forwarding.

The first example is tracing of products message. A company (com1.test)
produced a product and then sold it to another company (com2.test), where
UTID is used to identify the product and IDTP is used to trace the message
of the product.

Fig. 1 Tracing reference between two databases  (visit
http://www.utid.org/utid/NewArchitecture.html to see the pictures)

A record was inserted into database of company com1.test with empty value
of tracing key when a product was produced by company com1.test and marked
as 125.product~db$com1.test, which may be used to trace to the record by
IDTP in the company com1.test (Fig. 1).

A record was inserted into database of company com2.test when the product
was purchased by company com2.test and re-marked as
312.purchase~db$com2.test, whose message was send back to company com1.test
by the following IDTP request:

idtp:0.9/1

utid:125.product~db$com1.test

ns:u.iot.db

name:UtidEcho

len:39

{"refUtid":"312.purchase~db$com2.test"}

This request was forwarded to the database of company com1.test by the
tracing mechanism of IDTP using the UTID carried by the request as
destination address and was used to update the field of tracing key of the
record. Then a response was returned back:

idtp:0.9/1

code:200 OK

len:17

{"msg":"success"}

Therefore, tracing references between the two databases were established,
just like a foreign key reference in a relational database system. The
difference is that the tracing reference is build between two independent
databases and any client application may trace any UTIDs through tracing
references by IDTP protocol.

The second example is tracing different properties of same UTID. A company
(com1.test) has a temperature sensor, which sends temperature value to a
database server every 10 minutes. The company has an internal network,
which consists of a database server that saves historical temperature
value, a tracing bridge that connect to the temperature sensor, and a
tracing gateway that forwards request based on tracing rule and tracing
track. A tracing bridge may be a system with very low capacity of
computation, such as a single chip microcomputer with Ethernet interface,
which acts as a connection node between IDTP node and non-IDTP node (Fig.
2).

The sensor was marked as 56.loc1.t~s$com1.test. A request was forwarded to
the tracing bridge by the tracing gateway if the namespace (field ns in the
request) is u.iot.sensor when a user sent a request for real time
temperature value. The tracing bridge got temperature value from the sensor
and returned the value to the requester. A request with the same UTID was
forwarded to the database server by the tracing gateway if the namespace is
u.iot.db when a user sent a request for historical temperature value. The
database server retrieved temperature values from database and returned the
value to the requester.

Fig. 2 Tracing to different node by namespace with same UTID (visit
http://www.utid.org/utid/NewArchitecture.html to see the pictures)

The tracing rule and tracing track on the tracing gateway is listed in Tab.
1 and Tab. 2.

Tab. 1 Tracing rule on the tracing gateway

*utid suffix*

*Rule*

$com1.test

ruel1

Tab. 2 Tracing track on the tracing gateway

*Rule*

*Namespace*

*Protocol*

*Address*

*Port*

rule1

u.iot.db

tcp

db.com1.test

8091

rule1

u.iot.sensor

tcp

bridge.com1.test

8092

The third example is for local request and remote request. A database
server of a company (com1.test) has various kinks of tracing keys, which
reference to local database or remote databases. A request may be handled
locally or forwarded to remote servers. In this case, the server may deal
with this situation easily by set up settings as listed in Tab. 3 and Tab.
4. There is no tracing rule for dns other than itself dns because that IDTP
will forward all unmatched requests to TCP port 25604 (default port number
for IDTP, registered in IANA) of the server indicated by the dns of the
UTID carried by a request.

Tab. 3 Tracing rule on the database server

*utid suffix*

*Rule*

$com1.test

ruel1

Tab. 4 Tracing track on the database server

*Rule*

*Namespace*

*Protocol*

*Address*

*Port*

rule1

*

local

It is encouraged to use IDTP request for local calls because of its high
efficiency to form a unified API both for local calls and remote calls.
This mechanism will help designers to develop highly interoperable
application.

Despite of the differences between IDTP and Web Service, IDTP is
conditional compatible with Web Service, adapts WSDL as data format
definition of request and response, and adapt UDDI for the discovery of
IDTP service.

In summary, UTID and IDTP suggested a new kind of application architecture
for the Internet of Things that is universal, simple, low cost, and high
efficiency. The architecture simplifies the design of application
framework, promote the efficiency of system development, and increase the
interoperability of application system.

Best regards,

Huang

-- 
------------------------------
Mr. Huang Neng Geng
------------------------------
Associate Professor
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, Jiangsu, China, 214121
Mobile: 86-13921501950
email: [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Sun, 6 Jul 2014 11:20:47 -0400

App Area folks:
The Independent Stream Editor really needs comments on these as part of his
decision to publish them.  The primary question is whether what's proposed
is in conflict with IETF work.  Please have a look, and comment.

Barry

On Fri, Jul 4, 2014 at 11:24 AM, Neng Geng Huang <[email-masked]> wrote:

> this paper) and namespace match (called *tracing track* in this paper).
> The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web
> The tracing rule and tracing track on the tracing gateway is listed in
> Tab. 1 and Tab. 2.
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Tim Bray <[email-masked]>
Date: Sun, 6 Jul 2014 09:06:24 -0700

My primary question would be "are there implementations, and what useful
things do they do?"
On Jul 6, 2014 8:20 AM, "Barry Leiba" <[email-masked]> wrote:

> App Area folks:
> The Independent Stream Editor really needs comments on these as part of
> his decision to publish them.  The primary question is whether what's
> proposed is in conflict with IETF work.  Please have a look, and comment.
>
> Barry
>
>
>>  Here is a brief introduction to the concepts of UTID and IDTP and
>> discuss their use through three small examples, showing the potential to
>> construct a new kind of application architecture for the Internet of Things.
>>
>> UTID is a unique identifier for a physical thing or a virtual thing in
>> the world, which consists of three components with the following syntax:
>>
>> Id~catalog$dns
>>
>> The second example is tracing different properties of same UTID. A
>> company (com1.test) has a temperature sensor, which sends temperature value
>> to a database server every 10 minutes. The company has an internal network,
>> The sensor was marked as 56.loc1.t~s$com1.test. A request was forwarded
>> to the tracing bridge by the tracing gateway if the namespace (field ns in
>> the request) is u.iot.sensor when a user sent a request for real time
>> In summary, UTID and IDTP suggested a new kind of application
>> architecture for the Internet of Things that is universal, simple, low
>> cost, and high efficiency. The architecture simplifies the design of
>> application framework, promote the efficiency of system development, and
>> increase the interoperability of application system.
>>
>>
>> Best regards,
>>
>>
>> Huang
>>
>> --

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 Jul 2014 23:52:38 +0200

> https://datatracker.ietf.org/doc/draft-huangng-idtp/

After a cursory check:

I do not think this is a complete specification of a protocol, so it is hard to say anything definite.

It seems to be interested in some of the use cases of CoAP, and I wonder why it doesn’t discuss its relationship with CoAP, which has been around since before this work started.  The draft does mention HTTP, but only in a superficial way as in [IDTP] "is similar to HTTP, Web Service, Java RMI, or CORBA.”  It says it maps to TCP, UDP, and HTTP, but doesn’t say how (it does say it uses port 25604 for TCP, which indeed has been allocated in 2011).

I was hoping to find some answers in the reference implementation, which has some 7000 lines of Java.
There you can find gems such as an XOR “encryption”.
As the drafts didn't really help me find out about their motivation, I was interested to find an “overview.html” there that has to say this:

> 1.4 Why a new protocol?
> 
> There are various coding system and communication protocols widely used in the IOT. The EPC and Web Service are the typical that makes a great contributes to the development of IOT. However, any technology inevitably has some disadvantages. For example, EPC is mainly used in identify products in production process and shipping goods in logistics and is the best coding system in the context. But in the era of IOT, after being produced, a product will go through circulation process, storage process, and consumption process. The same product might need to be recoded in different process by different company using different coding system to provide and share the information of the same product in the different status from different company. For example, no company would like to identify its fixed assets using EPC system, which is originally designed for identify products. The problem is that the communication among these different company and different coding system. The result is the producer is difficult to trace the outgoing process and the consumer is difficult to find the information in the circulation process except the producer. Another example is IP protocol, the key technology in the Internet. But it could not be applied to a network consists of sensors that do not have IP address.
> 
> In generally, we need a coding system and a protocol that are more open, more generalized. This specification provides such an open solution that is independent to any industry or any context.

I gave up there, because I cannot make sense of this.

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Sun, 06 Jul 2014 17:36:17 -0700

On 7/6/2014 9:06 AM, Tim Bray wrote:
> On Jul 6, 2014 8:20 AM, "Barry Leiba" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     App Area folks:
>     The Independent Stream Editor really needs comments on these as part
>     of his decision to publish them.  The primary question is whether
>     what's proposed is in conflict with IETF work.  Please have a look,
>     and comment.

Tim, et al,

The "IETF" has a limited role in commenting on Independent Stream RFC
drafts.  Barry's query summarized the key point that is /within/ the
IETF's purview.

We do not get to comment on whether we like a protocol spec or what its
deficiencies are.  Individually, we might, if we are asked by the
Independent Stream Editor.

But the question "The IETF" is alloed to ask is much more limited:

   http://tools.ietf.org/html/rfc5742

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net