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

[Tim Bray <[e-mail]>]

My primary question would be "are there implementations, and what useful
things do they do?"
On Jul 6, 2014 8:20 AM, "Barry Leiba" <[e-mail]> 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
>
>
> On Fri, Jul 4, 2014 at 11:24 AM, Neng Geng Huang <[e-mail]>
> wrote:
>
>> 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: [phone]
>> email: [e-mail]
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>