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

[Barry Leiba <[e-mail]>]

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
>
>