Internet DRAFT - draft-huangng-idtp
draft-huangng-idtp
Independent Submission N. G. Huang
Internet Draft Wuxi Institute of Technology
Intended status: Experimental May 19, 2015
Expires: November 2015
Identifier Tracing Protocol (IDTP)
draft-huangng-idtp-05.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 19, 2015.
N. G. Huang Expires November 19, 2015 [Page 1]
Internet-Draft IDTP May 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
The Identifier Tracing Protocol (IDTP) is an application-level
protocol for distributed and collaborative information systems. It
is a generic communication protocol which can be used for many tasks
with two types of forwarding mechanisms to achieve traceability by
using Universal Traceable Identifier (UTID) [I-D-UTID] which
contains two types of forwarding messages.
This document provides the specification of IDTP, including syntax,
data format, and the guidelines for their use, too.
Table of Contents
1. Introduction ................................................ 4
1.1. Design Considerations
................................... 5
1.2. Terminology ............................................ 5
1.3. Overall Operation ...................................... 7
2. Conventions Used in This Document
............................ 9
3. Protocol Parameters ......................................... 9
3.1. Header Data ............................................ 9
3.1.1. Header Data Field
.................................. 9
3.1.1.1. Idtp ......................................... 9
3.1.1.2. Utid ........................................ 10
3.1.1.3. Ns (namespace)
............................... 10
3.1.1.4. Name ........................................ 10
3.1.1.5. Code ........................................ 11
3.1.1.6. Len ......................................... 11
3.1.1.7. Hop ......................................... 12
3.1.1.8. Hops ........................................ 12
3.1.1.9. Enc ......................................... 12
3.1.2. Header Data Format
................................ 12
3.1.3. Header Data Examples
.............................. 13
N. G. Huang Expires November 19, 2015 [Page 2]
Internet-Draft IDTP May 2015
3.2. User's Data ........................................... 14
3.2.1. User's Data Format
................................ 14
3.2.2. User's Data Type
.................................. 14
3.2.3. User's Data Field Name
............................ 15
3.2.4. User's Data Example
............................... 15
3.3. Request ............................................... 15
3.4. Response .............................................. 16
4. Underlying Protocol ........................................ 16
4.1. TCP ................................................... 17
4.2. UDP ................................................... 17
4.3. UDP multicast ......................................... 17
4.4. HTTP .................................................. 18
4.5. Other Protocols ....................................... 18
5. Traceability ............................................... 18
5.1. Overview of Traceability
............................... 18
5.2. Tracing Gate .......................................... 20
5.2.1. Tracing .......................................... 20
5.2.2. Tracing Mechanism
................................. 21
5.2.2.1. Internet-based Forwarding .................... 21
5.2.2.2. Intranet-based Tracing
....................... 21
5.2.3. Tracing Rules .................................... 22
5.2.4. Tracing Track .................................... 23
5.2.5. Infinite Loop .................................... 24
5.2.6. Tracing Inconsistency
............................. 25
5.3. Tracing Bridge ........................................ 25
6. Request and Response ....................................... 26
6.1. Request and Namespace
.................................. 26
6.2. Namespace and Catalog of UTID
.......................... 26
6.3. Discovery ............................................. 27
7. Status Code Definitions .................................... 27
7.1. Reserved 1xx .......................................... 27
7.2. Successful 2xx ........................................ 27
7.2.1. 200 OK ........................................... 27
7.2.2. 201 UDP Multicast Sent Out
........................ 28
7.3. Client Error 3xx ...................................... 28
7.3.1. 300 Invalid UTID
.................................. 28
7.3.2. 301 Invalid Header
................................ 28
7.3.3. 302 Invalid Data
.................................. 28
7.4. Server Error 4xx ...................................... 28
7.4.1. 400 Internal Server Error
......................... 28
7.4.2. 401 IDTP Version Not Supported .................... 28
7.4.3. 402 Encrypt/Decrypt Error
......................... 28
7.4.4. 403 Missing Encrypt Error
......................... 28
7.4.5. 404 Service Not Found
............................. 29
7.5. Tracing Error 5xx ..................................... 29
7.5.1. 500 Failed To Connect To Server ................... 29
N. G. Huang Expires November 19, 2015 [Page 3]
Internet-Draft IDTP May 2015
7.5.2. 501 Max Hop Count Reached
......................... 29
7.5.3. 502 UDP Message Is Too Long
....................... 29
8. Usage
...................................................... 29
8.1. Application Scopes .................................... 29
8.1.1. Remote Procedure Call
............................. 29
8.1.2. Distributed Database
.............................. 29
8.1.3. Cloud Computing
................................... 30
8.1.4. Ubiquitous Computing
.............................. 30
8.1.5. Internet of Things
................................ 30
8.2. Synchronization ....................................... 30
9. Security Considerations .................................... 30
9.1. Sensitive Information
.................................. 31
9.2. Data Encryption ....................................... 31
9.3. Authentication and Authorization
....................... 31
9.4. Other Risks ........................................... 31
10. IANA Considerations ....................................... 31
11. Change log of this document
................................ 31
12. References ................................................ 32
12.1. Normative References
.................................. 32
12.2. Informative References
................................ 32
13. Acknowledgments ........................................... 33
Appendix A. Built-in Request
................................... 34
A.1. Index ................................................. 34
A.2. Wsdl .................................................. 35
A.3. Ping .................................................. 37
1. Introduction
The Identifier Tracing Protocol (IDTP) is an application-level
protocol for distributed and collaborative information systems. It
is a generic communication protocol which can be used for many tasks
with two types of forwarding mechanisms and with low computation
cost.
IDTP is a protocol based on request-response model. It is similar to
HTTP, Web Service, Java RMI, or CORBA. The unique feature of IDTP is
that it has two types of forwarding mechanisms to achieve
traceability by using Universal Traceable Identifier (UTID) [I-D-
UTID] which contains two types of forwarding messages.
Note 1: This version of this document has an important change
compare to the previous version. The major change is tracing
mechanism which has many influences on this document.
Note 2: A reference implementation, which is called "busilet", of
UTID and IDTP has been developed as open source software and could
N. G. Huang Expires November 19, 2015 [Page 4]
Internet-Draft IDTP May 2015
be downloaded from http://sourceforge.net/projects/busilet/. For
more information please visit http://www.utid.org.
1.1. Design Considerations
o Traceability: Traceability is the major objective of designing
IDTP and UTID. The network will become extra huge in the near
future to connect not only computers but also smart devices and
even every object in the world through various technologies. IDTP
provides two types of forwarding mechanisms to trace a request to
its origin specified by UTID associated to the request. This is
why a new identification system and a new communication protocol
are proposed.
o Consistency: It should be able to use a uniform mechanism to send
a request and get a consistent response, regardless of local call
or remote call, regardless of different underlying protocols,
regardless of programming language, and regardless of the
platform of the origin server.
o Simplicity: It should be simple enough to be used by developers,
simple enough to be run in any kind of devices with low
computation cost.
1.2. Terminology
This specification uses a number of terms related to IDTP for
understanding the concept of IDTP.
o Traceability: It refers to the ability to trace the history,
application or location of an entity by means of recorded
identifications [ISO8402]. The concept of entity in this document
is extended to abstract object and physical object.
o Object: It is refer to an abstract object or a physical object in
this document.
o UTID: It is Universally Traceable Identifier, as defined in
reference [I-D-UTID]. The UTID is designed special for IDTP.
o FQUTID: It is full qualified UTID, as defined in Section 7.1 of
reference [I-D-UTID].
o UTID suffix: It is the last part of a FQUTID starting from a
given position, as defined in Section 7.3 of reference [I-D-UTID].
N. G. Huang Expires November 19, 2015 [Page 5]
Internet-Draft IDTP May 2015
o Request: It is an IDTP request message, as defined in Section 3.3.
o Response: It is an IDTP request message, as defined in Section
3.4.
o Namespace: It is a name assigned to a request to avoid naming
conflicts, as defined in Section 6.1.
o Client: It is an application program that establishes connections
for the purpose of sending requests.
o Server: It is an application program that accepts connections in
order to service requests by sending back responses.
o Origin Server: It is a server on which information associated
with a given UTID resides or is to be created.
o Node: It is a server or a client. A node usually acts both as a
server and a client at same time.
o Node Name: Each node should have a name, which is global unique
usually consisting of DNS name and a sub domain name. An example
is "n1.sample.test".
o Tracing: It is the process to trace a request to its origin
server by forwarding the request. It is a special kind of
forwarding for the purpose of traceability.
o Tracing Gate: It is the node that responsible for tracing of
requests, in which data format conversion may be conducted during
the tracing.
o Tracing Bridge: It is a tracing gate that also acts as a bridge
between TCP/IP network and non TCP/IP network, in which smart
devices are to be connected to IDTP through any available
communication channels such as ZigBee, Bluetooth, CAN, or serial
port.
o Tracing Rules: They are a data set stored in tracing gate that
list the next hop address and connection parameters for tracing a
request.
o IDTP domain: It is a group of nodes with same tracing rules and
policy, usually owned by same organization. Therefore, the owner
could be able to make a unified rules and policy for tracing in
the IDTP domain.
N. G. Huang Expires November 19, 2015 [Page 6]
Internet-Draft IDTP May 2015
o IDTP domain name: It is the name of IDTP domain, which is the DNS
name of the organization that owns the IDTP domain and shared by
all nodes in the IDTP domain. An example is "id.sample.test".
IDTP domain name usually is the dns component of a UTID as
defined in Section 5.1.2 of reference [I-D-UTID].
o IDTP port number: It is TCP port number 25604 registered by IDTP
in IANA. This port number is recommended as a default TCP port
number of IDTP.
o Local processing: It means that the requester and the responder
is in same process, that is, same port number in same machine.
o Remote processing: It means that the requester and the responder
is NOT in same process, that is, different machine or different
port number in same machine.
1.3. Overall Operation
The IDTP is a request/response protocol. A client sends a message to
a server in the form of a request, which consists of header data and
user's data delimited by double LF characters. The server responds
with a response, which also consists of header data and user's data
delimited by double LF characters, back to the client through the
reverse route path.
An IDTP communication is initiated by a client, in which a request
is transmitted to origin server. In the simplest case, this may be
accomplished via a single connection (v) between the client (C) and
the origin server (O), as showed in Figure 1.
+------------------------------------------------+
| |
| request chain ------------------------> |
| C -------------------v------------------- O |
| <----------------------- response chain |
| |
+------------------------------------------------+
Figure 1 Communication between a client and an origin server
A more complicated situation occurs when one or more intermediaries
are present in the request/response chain. There are two forms of
intermediary: tracing gate and tracing bridge.
N. G. Huang Expires November 19, 2015 [Page 7]
Internet-Draft IDTP May 2015
A tracing gate is a forwarding agent, which receives a request and
forwards the request to next hops address configured in the tracing
rules of the tracing gate. A tracing gate may rewrite part of the
header, encrypt or decrypt the user's data, or forward through a
different underlying protocol. For example, a tracing gate may
receive a request through TCP protocol and forward the request
through UDP protocol.
A tracing bridge is a tracing gate that also acts as a bridge
between an IDTP node and a device that does not have TCP/IP
connection and translates the request and response between the two
sides.
+-------------------------------------------------+
| |
| request chain ---------------------------> |
| C -----v1----- A -----v2---- B -----v3------ O |
| <-------------------------- response chain |
| |
+-------------------------------------------------+
Figure 2 Communication via intermediaries
Figure 2 shows two intermediaries (A and B) between the client and
origin server. A request or response message that travels the whole
chain will pass through three separate connections. IDTP
communication may apply only to the connection with the nearest
neighbor. Each connection may use different underlying protocols,
such as v1 connection uses TCP protocol, v2 connection uses UDP
protocol, v3 connection uses HTTP protocol to one origin server or
UDP multicast to a group of servers.
Although the diagram is linear, each participant may be engaged in
multiple, simultaneous communications. For example, B may be
receiving requests from many clients other than A, and/or forwarding
requests to servers other than O, at the same time that it is
handling A's request.
IDTP communication may takes place over TCP, UDP, HTTP, UDP
multicast connections. The default TCP port number is 25604, but
other ports can be used.
N. G. Huang Expires November 19, 2015 [Page 8]
Internet-Draft IDTP May 2015
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
This specification uses the terms "character" in accordance with the
definitions provided in [BCP19].
3. Protocol Parameters
The IDTP is a request/response protocol. The request and response
are consisted of header data and user's data:
header data
(a blank line)
user's data
The header data consists of several lines delimited by a LF
character and there should be no blank line. The user's data
consists of one or several lines with any delimit character, such as
LF, CR, or CRLF, and there may have blank lines.
The header data and the user's data are separated by double LF
characters, which mean they are separated by a blank line.
3.1. Header Data
3.1.1. Header Data Field
There are nine fields in header data as defined in following in the
order they appear in the header data.
3.1.1.1. Idtp
Idtp in the header data indicates that the message is an IDTP
request or response. It also indicates the version of IDTP and
version of request/response. The format of the idtp field is as
follows:
N. G. Huang Expires November 19, 2015 [Page 9]
Internet-Draft IDTP May 2015
idtp:<protocol version>/<request/response version>
The protocol version uses a "<major>.<minor>" numbering scheme to
indicate versions of the IDTP. The protocol versioning policy is
intended to allow the sender to indicate the format of a message and
its capacity for understanding further IDTP communication, rather
than the features obtained via that communication.
The request/response version uses a "<major>" numbering scheme to
indicate versions of the request or response. The request/response
version is reserved for the version mechanism for the request and
response in the future. The version of a request should be same as
the version of corresponding response.
An example of idtp field is "idtp:0.9/1".
3.1.1.2. Utid
Utid in the header data indicates the origin server of the request.
It is the identifier to inform the origin server the object
concerned. The syntax of UTIDs is defined by reference [I-D-UTID].
An example of utid field is "utid:101$a.test".
3.1.1.3. Ns (namespace)
Ns (abbr. of namespace) in the header data indicates the namespace
of a request to avoid naming conflict of requests. It usually adopts
the DNS name of the organization that defines the request, with the
higher level in the first.
Namespace should be in lower case. It is recommended that namespace
be added a prefix of "utid." in order to declare that it is an UTID
namespace.
An example of namespace field is "utid.example.project1.list".
3.1.1.4. Name
Name in the header data indicates the name of a request, which
determines the data format of the request and response.
It is recommended that the naming of requests follow the upper camel
case nomenclature.
An example of name field is "ProductList".
N. G. Huang Expires November 19, 2015 [Page 10]
Internet-Draft IDTP May 2015
3.1.1.5. Code
Code in the header data indicates the response status code, which is
similar to the status code and reason phrase of HTTP. The code field
consists of two parts: a 3-digit integer and a reason phrase,
separated by a space.
The first digit of the 3-digit integer defines the class of the
response status. The last two digits do not have any categorization
role. There are 5 values for the first digit:
o 1xx Reserved - Not used currently
o 2xx Success - The action was successfully received, understood,
and accepted
o 3xx Client Error - The request contains bad syntax or cannot be
fulfilled or the response received contains bad syntax
o 4xx Server Error - The server failed to fulfill an apparently
valid request
o 5xx Tracing Error - The request failed to be traced or response
failed to be received
These status codes are fully defined in Section 7. The reason phrase
is intended to give a short textual description of the code for the
human user to understand.
The reason phrase is omitted if the underlying protocol is UDP or
UDP multicast.
An example of name code is "code:200 OK".
3.1.1.6. Len
Len in the header data indicates the user's data length, which does
not include the length of header data and the double LF, which are
used as the delimiter of header data and user's data.
An example of name len is "len:52".
N. G. Huang Expires November 19, 2015 [Page 11]
Internet-Draft IDTP May 2015
3.1.1.7. Hop
Hop in the header data indicates the count of hops, which is used to
avoid loop tracing. The tracing is failure if hop reaches a
predetermined value (maximum hop count, default is 8).
An example of hop field is "hop:2".
3.1.1.8. Hops
Hops in the header data indicates the list of hops separated by
semicolons, which is used for debug when loop tracing occurs. It is
omitted if the underlying protocol is UDP or UDP multicast.
An example of name hops is "hops:n1.a.test;n0.demo.test".
3.1.1.9. Enc
Enc in the header data indicates the encryption/decryption
parameters. It is reserved for future use. It is omitted if the
underlying protocol is UDP or UDP multicast.
3.1.2. Header Data Format
Each field in header data appears as one line. Each line is a key-
value pair separated by a colon. Each line ends with a LF character
rather than a CRLF pair. Space or white space is not allowed in
header data except in the value of code field. If the value of one
field is null or empty, the field is omitted in the header data.
All ten fields are list in Figure 3.
N. G. Huang Expires November 19, 2015 [Page 12]
Internet-Draft IDTP May 2015
+-----------------------------------------------------------------+
| Field Description Request Response|
+-----------------------------------------------------------------+
| idtp Idtp version,request/response version yes yes |
| utid Request UTID by client yes no |
| ns Namespace (package) of a request yes no |
| name Name of a request yes no |
| code Response status code no yes |
| len User's data length yes yes |
| hop Count of hops, maximum is 8 yes yes |
| hops List of hops for loop checking yes yes |
| enc Encryption parameters optional optional|
+-----------------------------------------------------------------+
Note: The "yes" or "no" in the third and fourth column indicates
whether the field exists in request or response header data.
Figure 3 Summary of Header Fields
The order of the fields in header data MUST be appeared in the same
order listed in Figure 3. If more fields are to be added into the
header data in next version of IDTP, the new fields SHOULD be
appended to the list rather than inserted into the list.
3.1.3. Header Data Examples
An example of header data of a request is as follows:
idtp:0.9/1
utid:101$a.test
ns:utid.test.a
name:Product
len:19
An example of header data of a response is as follows:
idtp:0.9/1
code:200 OK
len:52
hop:2
N. G. Huang Expires November 19, 2015 [Page 13]
Internet-Draft IDTP May 2015
hops:n1.a.test,n0.demo.test
3.2. User's Data
3.2.1. User's Data Format
The user's data is a JSON string or an XML string in one or more
lines, which represents serialized data of an object in Object
Oriented Languages.
For the consideration of performance and simplicity, the JSON format
is recommended.
There is no format type field in header data to indicate that the
user's data is in JSON string or in XML string. The format type is
easy to determine by checking the first character of the user's data,
where '{' stands for JSON string and '<' stand for XML string.
3.2.2. User's Data Type
Although there is no data type limited in the user's data
theoretically, the data types of fields in user's data are
recommended to be limited to following data types:
o Numeric type: Only three numeric types are recommended: int (32
bits), long (64 bits), and double (64 bits). Other numeric data
types, such as byte, short, and float are not encouraged although
these data types may be used in most context.
o Boolean: A boolean value should be express in lower case "true"
and "false" rather than "True" or "TRUE".
o String: A string is a sequence of characters defined by ISO/IEC
646 [ISO646] and Unicode [Unicode]. The Unicode character SHOULD
be encoded in UTF-8 [STD63] character set.
o Date: The date and time should be in ISO-8601 [ISO8601] format.
An example is "2013-11-06T12:06:46.257+0000".
o Array data: This includes array, list, set, and dictionary (map)
of data types list above.
o Structured data: This includes struct in C language and classes
in Object Oriented Languages, which consist of data types listed
above or another structured data.
N. G. Huang Expires November 19, 2015 [Page 14]
Internet-Draft IDTP May 2015
o Binary data: Binary data is not encouraged to be used in IDTP
because IDTP is a light weight communication protocol. Binary
data may be expressed in the array of byte format if necessary.
o Other types: All other types are recommended to be converted into
string and negotiated between clients and servers in advance.
Examples are arbitrary-precision integers and arbitrary-precision
signed decimal numbers.
All data in various types will be converted into string in JSON or
XML format when transmitted on network.
3.2.3. User's Data Field Name
It is recommended that the data field naming follows the lower camel
case nomenclature. Examples are "fileName" and "userName".
Any data field name in the user's data starting with and ending with
double underscore are reserved for internal use. Examples are
"__attri__", "__session_id__", and "__utid_suffix__".
3.2.4. User's Data Example
Below is an example of user's data in JSON format.
{"name":"book","price":66.8,"date":"2013-11-06T12:37:28.883+0000"}
Below is an example of user's data in XML format:
<idtp><name>book</name><price>66.8</price><date>2013-11-
06T12:37:28.883+0000</date></idtp>
3.3. Request
A request represents the header data and user's data that are to be
sent to an origin server. It encapsulates all messages required to
tracing a request to the server and understood by the server, where
the UTID is the most important because that the UTID contains the
forwarding messages to the origin server.
An example of request is:
idtp:0.9/1
utid:101$a.test
N. G. Huang Expires November 19, 2015 [Page 15]
Internet-Draft IDTP May 2015
ns:utid.test.a
name:Product
len:19
{"sender":"Bella."}
The two parts are separated by double LF ("\n\n") characters so it
seems to be separated by a blank line.
3.4. Response
A response represents the header data and user's data that are to be
responded from an orgin server. It encapsulates all concerned
information of the UTID of the request.
An example of response is:
idtp:0.9/1
code:200 OK
len:52
hop:2
hops:n1.a.test,n0.demo.test
{"name":"Pen","price":12.0,"remark":"Hello, Bella."}
The two parts are separated by double LF ("\n\n") characters.
4. Underlying Protocol
IDTP is an application protocol that requires support of underlying
protocols including TCP, UDP, UDP multicast, and HTTP, which are
chose according to the requirements of applications, such as
efficiency, features, or compatibility requirements, to extend the
scopes of IDTP could applies.
N. G. Huang Expires November 19, 2015 [Page 16]
Internet-Draft IDTP May 2015
4.1. TCP
TCP is known as a connection-oriented and reliable protocol, which
is suitable for use in most circumstance as an underlying protocol
of IDTP. However, it is not suitable for use in case of real time or
low computation capacity devices because of the cost due to the
establishment and termination of connections.
TCP is the default underlying protocol if no underlying protocol
specified for an IDTP connection.
4.2. UDP
UDP is a connectionless and unreliable protocol, which emphasizes
low-overhead operation and is suitable for real time or low
computation capacity devices as an underlying protocol of IDTP.
Although the data length transferred by UDP is limited to 65,507
bytes, the practical limit for the data length may be much less due
to the capacity limit of network equipments. For this reason, the
data length of UDP used in IDTP is limited to 484 bytes. Therefore,
the IDTP header data is simplified as follows:
o Omit two header data fields: "hops" and "enc".
o Reduce the length of the "code" field value: "code" field keeps
only the 3-digit integer without the reason phrase followed.
4.3. UDP multicast
Multicast is a technique for one-to-many communication that
increases the efficiency by which a node sends a packet only once
and the packet is delivered to a large number of receivers. UDP
multicast enables IDTP sending a request to multiple nodes in case
to broadcast a notification or get a list of activity nodes.
The disadvantages of UDP multicast are two: (1) it is unreliable so
the messages may be lost, and (2) it is one-way communication
without response. The measures to remedy the disadvantages may be:
o Duplicating multicast: The sender multicast more than once. For
example, a sender multicast a message three times at interval of
2 seconds then assumes that all nodes should receive the message.
N. G. Huang Expires November 19, 2015 [Page 17]
Internet-Draft IDTP May 2015
o Responded by a new request: All receivers are requested to send
back a new request to inform the sender after receiving a
multicast message.
4.4. HTTP
HTTP is a popular protocol for data transfer mainly for hypertext
data of web pages. IDTP adopts HTTP as one of its underlying
protocol in order to enabling browsers to be a client to access IDTP
server, typically by Ajax technology.
4.5. Other Protocols
There are no limits on the underlying protocols that IDTP can use.
Examples of other protocols include wireless sensor network, near
field communication, mobile protocols, and industry buses, which are
mainly used to connect to smart devices by tracing bridges, as
defined in section 5.3.
5. Traceability
5.1. Overview of Traceability
Distributed computing, cloud computing, pervasive computing,
ubiquitous computing, and the Internet of Things make computing to
appear everywhere and anywhere. In the new era, computing can occur
using any device, in any location, and in any format. The devices
may be laptop computers, tablets, terminals, mobile phones, sensors,
actuators, and various smart devices, while the underlying
technologies include the Internet, wireless sensor network, advanced
middleware, near field communication, sensors, actuator,
microprocessors, new I/O and user interfaces, networks, mobile
protocols, location and positioning and new materials.
Devices located in various places are origins of information. The
UTIDs and IDTP are used to identify objects of origins and to
communicate each other. The traceability is the most important
feature of IDTP and UTID. Both of IDTP and UTID will lost their
values if without traceability.
A scenario that UTIDs and IDTP apply is illustrated in Figure 4.
N. G. Huang Expires November 19, 2015 [Page 18]
Internet-Draft IDTP May 2015
+------------------------+--+--+----------+------------------------+
| | | | | |
| Na1 | | | | Nb2 |
| \ | | Na4==Sa2 | / |
| \ | | | / |
| Sb1====Na3------Na0---+ | | / |
| / | Nc +---Nb0------Nb3====Sb1 |
| / | | \ |
| / +----Nb4 | \ |
| Na2 | | Nb1 |
| | | |
| | INTERNET | |
| LAN-A | (CLOUD) | LAN-B |
+------------------------+----------------+------------------------+
Figure 4 A scenario of ubiquitous computing where IDTP applies
There are tow organizations ('a' and 'b') in Figure 4, which owns
LAN-A and LAN-B respectively, where 'N' stands for node, 'S' stands
for smart device, second letter in lower case stands for the
organization who own the nodes or smart devices, 'Nc' stands for an
independent node, single line stands for TCP/IP connections, and
double line stands for non TCP/IP connections. The two organizations
also have remote nodes, one of which is attached with a smart device.
All nodes are connected each other through Internet and the smart
devices are connected to nodes through other communication
technology, such as wireless sensor network, near field
communication, or various type of industry bus.
The two organizations registered DNS names and bound the DNS names
to node Na0 and Nb0 respectively. Other nodes may have either a
secondary DNS name or IP address only. The smart devices usually do
not have IP address.
Both nodes and smart devices may be act as origin servers to provide
information. For example, smart device 'Sa1' may be a temperature
sensor that provides real-time temperature values.
All nodes and smart device owned by organization 'a' are in one IDTP
domain and it is possible for them to share same tracing rules. An
IDTP domain may across LANs, such as node 'Na4' in Figure 4 belongs
to IDTP domain 'a'.
The traceability is implemented by tracing (forwarding) a request
directly or indirectly to origin server. There are two tracing
mechanisms:
N. G. Huang Expires November 19, 2015 [Page 19]
Internet-Draft IDTP May 2015
o DNS/IP forwarding: It is the request forwarding according to the
DNS component of UTID in a request. It is based on DNS, IP
address, and IP forwarding technologies in the Internet. It is
the same as what happens in HTTP and SMTP and is not necessary to
be documented in this document.
o IDTP tracing: It is the request forwarding in an IDTP domain
internal according to the ending part of catalog and id
components of UTID in a request rather than the DNS component of
UTID in a request. It is based on UTID suffix matching algorithm
to forward a request to a server by the DNS name or IP address
specified in tracing rules. It is unique to the IDTP and is
documented in this section.
In the simplest IDTP domain, there is only one central IDTP server
that provides all information of the IDTP domain. Therefore, there
is no IDTP tracing in that IDTP domain.
However, the scenarios in the real world usually are that all nodes
and smart devices are origin server to achieve computing to appear
everywhere and anywhere. In this case, all nodes should be
configured with tracing rules and act both as IDTP servers and
tracing gates. The nodes on boundary of TCP/IP and non TCP/IP
network act as tracing bridges, such as Na3 and Nb3 in Figure 4.
5.2. Tracing Gate
A tracing gate is a node that responsible for tracing of requests,
in which data format conversion may be conducted during the tracing
5.2.1. Tracing
Tracing is essentially forwarding, of which the forwarding is
limited in an IDTP domain internal based on tracing rules. In the
IDTP domain internal, all nodes are tracing gate that configured
tracing rules used to determine the next hop address, either in DNS
or IP address.
A request may come from:
o Local request: It is from the same process of the tracing gate.
o Remote request: It is from a remote host or a different process
of the tracing gate.
The next hop may be:
N. G. Huang Expires November 19, 2015 [Page 20]
Internet-Draft IDTP May 2015
o Local: The request is forwarded to the same process of the
tracing gate and is handled locally.
o Remote: The request is forwarded to a remote host or a different
process of the tracing gate (different port).
Therefore, a tracing gate handles a request in one of the following
four ways:
1. Local request is handled in local.
2. Local request is forwarding to remote.
3. Remote request is handled in local.
4. Remote request is forwarding to remote.
5.2.2. Tracing Mechanism
The tracing mechanism of tracing (forwarding) is determined by the
UTID and the namespace carried by a request.
The UTID, like URL in HTTP protocol, is used to determine the target
of tracing. There are two types of tracing: (1) Internet-based
forwarding, and (2) Intranet-based tracing.
5.2.2.1. Internet-based Forwarding
This is the forwarding using the DNS component in UTID in the
Internet based on the TCP/IP network.
This type of forwarding is not discussed in this document.
5.2.2.2. Intranet-based Tracing
This is the tracing using the UTID suffix match and namespace match
algorithm in the Intranet of an organization.
There are several tracing rules in a tracing gate. A tracing rule
consists of one or more tracing tracks, which define the mapping
between namespace and track. A track contains forwarding parameters,
such as target address, underlying protocol, and port number, etc.
There are two steps occurred in the Intranet-based tracing. The
first step is to match UTID with UTID suffix to find one tracing
N. G. Huang Expires November 19, 2015 [Page 21]
Internet-Draft IDTP May 2015
rule. The second step is to match namespace to find one tracing
track. These two steps are discussed in the following.
5.2.3. Tracing Rules
A tracing rule is a name that contains a set of tracing track. Each
UTID suffix has one and only one tracing rule. But several UTID
suffix may share same tracing rule.
The first step is to match the UTID of a request to UTID suffix. If
a UTID ends with one UTID suffix, the UTID matches to the tracing
rule of the UTID suffix. If a UTID ends with more than one UTID
suffix, the longest UTID suffix wins.
When a tracing gate received a request either from local or remote,
the UTID of the request is used to match UTID Suffixes in tracing
rules. If no match found, then the request will be forwarded
according to the dns of the UTID by TCP and port number of 25604. If
one match found, then the request will be handled according to the
rule.
+------------------------------------------------------------------+
| No. UTID suffix Rule |
+------------------------------------------------------------------+
| 1 $test1.example rule1 |
| 2 .x1~a2$test2.example rule2 |
| 3 ~a1$test2.example rule2 |
| 4 ~$test2.example rule2 |
| 5 $test2.example rule1 |
+------------------------------------------------------------------+
Figure 5 Example of tracing rules
In the example show in Figure 5, there are five UTID suffixes and
two rules. Any UTID ends with $test1.example will match rule1. A
UTID of "123.x1~a2$test2.example" will match rule2. A UTID of
"123~$test2.example " will match rule2. Any UTID in test2.example
that doesn't match no. 2,3,4 will match rule1.
In addition, a UTID of "123~$abc.test" will be forwarded to tcp port
number 25604 in "abc.test" because there are no rule matched.
N. G. Huang Expires November 19, 2015 [Page 22]
Internet-Draft IDTP May 2015
5.2.4. Tracing Track
A tracing track defines the mapping between namespace and track. A
track contains forwarding parameters, such as target address,
underlying protocol, and port number, etc.
The second step is to match the namespace of the request to the
namespace of a rule. If one match found, then the request will be
handled according to the track parameters, that is, handled locally
or forwarded to the defined address with the defined protocol and
port number. If no match found, then the request will be forwarded
according to the dns of the UTID by TCP and port number of 25604.
A track has following parameters:
o Namespace: It is used to match a request. It is considered as
matched if the namespace ("ns" field in header data) of a request
is exactly equal to the namespace in a tracing parameter. There
is also one special namespace in a tracing parameter, that is, a
wildcard of star ('*'), which matches all namespace in a request.
o Underlying protocol: The underlying protocol may be one of TCP,
UDP, UDP multicast, and HTTP. There are no other parameters if
the underlying protocol is "Local".
o Forward address: It indicates the address of next hop, which may
either be DNS name or IP address. If the UTID of a request
matches a UTID suffix, then the request will be forwarded to the
address by TCP/IP network.
o Port number: It is the port number of underlying protocol. The
default TCP port number registered in IANA for IDTP is 25604.
o Other index: There is other parameter for UDP multicast and HTTP.
N. G. Huang Expires November 19, 2015 [Page 23]
Internet-Draft IDTP May 2015
+--------+---------------------------------------------------------+
| | Track |
| Rule +---------------------------------------------------------+
| | Namespace Protocol Address Port Path |
+--------+---------------------------------------------------------+
| rule1 | org.sensor UDP 192.0.2.1 25604 N/A |
| rule1 | org.database LOCAL N/A N/A N/A |
| rule1 | * TCP 192.0.2.2 25604 N/A |
| rule2 | org.iot TCP i1.test2.example 25604 N/A |
| rule2 | * HTTP test2.example 80 /idtp |
+--------+---------------------------------------------------------+
Note: * matches any namespace.
Figure 6 Example of tracing tracks
Figure 6 shows that rule1 has three tracks and rule2 has two tracks.
Each track defines the namespace and the target.
The result of two step matching may be (regardless where the request
comes from):
o Local handling: If a request matches to a track by match UTID
suffix and namespace and the protocol of the track is local, the
request will be handled locally.
o Remote forwarding: If a request matches to a track by match UTID
suffix and namespace and the protocol of the track is not local,
the request will be forwarded to the address defined in the track
by the protocol and port number defined in the track.
o No match: If no match found, either UTID suffix match or
namespace match fails, then the request will be forwarded
according to the dns of the UTID by TCP and port number of 25604.
5.2.5. Infinite Loop
Infinite loop occurs if tracing gates is not configured correctly in
an IDTP domain or in several IDTP domains. For example, a request is
forwarded from node A to node B, then from node B to node C, and
again from node C to node A. In order to avoid request loops, a
header field of "hop", which increments by 1 each time of forwarding,
is designed in a request. A request will not be forwarded any more
and return a "403 Max Hop Count Reached" status code if hop reaches
maximum count.
N. G. Huang Expires November 19, 2015 [Page 24]
Internet-Draft IDTP May 2015
A header field of "hops", which records all nodes' name passed by
the request, is designed in a request. If infinite loop occurs, the
tracing rules of all tracing gates listed in "hops" should be
carefully checked in order to avoid such loops again.
If the underlying protocol is UDP or UDP multicast, the header field
"hops" is omitted so that no debug message is recorded. In this case,
a built-in request named "Ping" with same UTID may be used for debug
purpose. The built-in requests "Ping" are defined in Appendix A.1.
5.2.6. Tracing Inconsistency
Tracing inconsistency occurs if two requests with same UTID from two
nodes are forwarded to different origin server. It is difficult to
be detected out and should be avoided by carefully check the tracing
rules of all concerned tracing gates to make the tracing rules
consistency. In this case, the "hops" field in header data is also a
good debug tool to find out tracing tracks of requests from two
nodes.
5.3. Tracing Bridge
A tracing bridge is definitely a tracing gate. However, besides
acting as a tracing gate, a tracing bridge also act as a bridge
between TCP/IP network and non TCP/IP network.
The nodes in non TCP/IP network are typically smart devices with low
capacity of computation, such as sensors, actuators. These smart
devices are connected to tracing bridges by various technologies,
such as wireless sensor network, near field communication, and
industry buses.
A tracing bridge should be able to forward requests to smart devices
and accept requests from smart devices through connections in a data
format that could be understood by both sides.
It is more desirable that the smart devices themselves are tracing
bridges.
The specification of tracing bridges is not defined in this document
because of the diversity of smart devices and the connection
technologies.
N. G. Huang Expires November 19, 2015 [Page 25]
Internet-Draft IDTP May 2015
6. Request and Response
IDTP is based on request-response model. This document defines the
syntax of requests and responses. However, the semantic of the
requests and responses should be defined by both sides of the
communications. For example, the data fields and their meaning of a
request and a response for product information query should be
recognized by both client and origin server.
In the circumstance of ubiquitous computation, it is a key issue to
make consensus about the semantic of the requests and responses.
Therefore, it is an important issue to establish a standardization
system of requests and responses, which is the constraint of the
development of the IDTP.
This section discusses some issues related to the standardization of
requests and responses only.
6.1. Request and Namespace
Each request has a name and coupled with a response. Usually a group
of request and response pair is involved to achieve an objective.
Such a group of requests is developed by organizations and is used
as a local standard. A namespace is assigned to the group of
requests to avoid naming conflicts.
It is necessary to publish a namespace to public by mechanisms like
WSDL in Web Service [WSDL]. A namespace may become industry standard
or international standard if the namespace is recognized by
consensus among the industries.
6.2. Namespace and Catalog of UTID
A namespace represents a standard related to a group of requests,
which is exposure to public. A UTID is designed and assigned to an
object in an IDTP domain by an organization. Therefore, the public
need to know the relationship between standards and UTIDs.
Catalog of UTIDs is designed to establish the relationship between
namespace and UTIDs by mapping the catalog of UTIDs to namespace. An
IDTP domain should keep a mapping of catalog and namespace, which is
to be published to public. Each node in the IDTP domain should be
able to provide the mapping information to public. Appendix A.2
defines a built-in request named "Index" for public to access the
mapping information.
N. G. Huang Expires November 19, 2015 [Page 26]
Internet-Draft IDTP May 2015
The namespace stands for the standard of requests and responses and
is exposure to public. The catalog is used to group UTIDs in an
organization and is assigned internally by the organization. The
organization should keep a mapping of catalog to namespace when
design its catalog system, which is many to many relationship.
6.3. Discovery
If a client does not have any information about a UTID, IDTP
provides a mechanism for public to discover the requests and
responses used by the client to access the UTID, as follows:
o From catalog to namespace: A client may obtain a list of
namespaces that a UTID mapped through a built-in request "Index",
which provide an index of namespace of the catalog component of
the UTID from origin server.
o From namespace to request: Then the client may obtain all
requests and responses definition of a namespace in WSDL [WSDL]
format from origin server through a built-in request "Wsdl", as
defined in Appendix A.3. The wsdl message describes the requests
and responses and can be used to generate requests and responses.
o Access UTID by sending a request: Finally, the client access the
UTID using the requests discovered by above approaches.
The build-in requests are defined in Appendix A.
7. Status Code Definitions
Each status code is described below, including a brief description.
7.1. Reserved 1xx
Unused. It is reserved for future use.
7.2. Successful 2xx
The 2xx class of status code indicates that the client's request was
successfully received, understood, and accepted
7.2.1. 200 OK
The request has succeeded and a response is returned.
N. G. Huang Expires November 19, 2015 [Page 27]
Internet-Draft IDTP May 2015
7.2.2. 201 UDP Multicast Sent Out
The request has been multicast in the last node of a tracing chain.
A response with code 201 is returned.
7.3. Client Error 3xx
The 3xx class of status code is used to indicate that the request to
be sent or the response received contains bad syntax.
7.3.1. 300 Invalid UTID
The UTID in a request or a response contains bad syntax, which means
the UTID is not follow the UTID specification [I-D-UTID].
7.3.2. 301 Invalid Header
The header of a request or a response contains bad syntax.
7.3.3. 302 Invalid Data
The data of a request or a response contains bad syntax, which cause
the failure of serialization or deserialization.
7.4. Server Error 4xx
The 5xx class of status code is used to indicate the server failed
to fulfill an apparently valid request.
7.4.1. 400 Internal Server Error
It is a server error caused by many reasons in the server.
7.4.2. 401 IDTP Version Not Supported
The current IDTP version is 0.9. If IDTP version of a request is
bigger than it, "502" code will be returned.
7.4.3. 402 Encrypt/Decrypt Error
It indicates errors related to encryption or decryption.
7.4.4. 403 Missing Encrypt Error
It indicates that a request should be encrypted but is transmitted
in plaintext without encryption.
N. G. Huang Expires November 19, 2015 [Page 28]
Internet-Draft IDTP May 2015
7.4.5. 404 Service Not Found
It indicates that the service (business logic) corresponding to a
request is not found.
7.5. Tracing Error 5xx
The 5xx class of status code is used to indicate that an error
occurs in the tracing process.
7.5.1. 500 Failed To Connect To Server
A client could not connect to server till timeout. It should
indicate the underlying protocol type: TCP/UDP/UDP-MC/HTTP
7.5.2. 501 Max Hop Count Reached
The count of forwarding of a request reached the maximum number
(default is 8). It means tracing loop occurred.
7.5.3. 502 UDP Message Is Too Long
The length of request or response is larger than the maximum length
(484 bytes) if underlying protocol is UDP and UDP multicast.
8. Usage
8.1. Application Scopes
IDTP may be applied in many application scopes.
8.1.1. Remote Procedure Call
IDTP is based on request-response model, which is actually one type
of remote procedure call (RPC) or remote method invocation.
In addition, the traceability feature of IDTP makes it suitable to
be applied both for local call and remote call, with very low
computation cost when used in local call.
8.1.2. Distributed Database
UTIDs are good candidates to be used as primary keys and foreign
keys in databases distributed in different places to form a loosely-
coupled distributed relational database system. There are no foreign
key constraints between the primary keys and the foreign keys
N. G. Huang Expires November 19, 2015 [Page 29]
Internet-Draft IDTP May 2015
because that they are in different databases. However, there are
still logic constraints between the primary keys and foreign keys.
IDTP is the right choice to be the protocol to establish connections
among these databases.
Unlike traditional distributed database management system, this type
of loosely-coupled distributed database system is light weight
without replication and duplication, allowing full independence of
databases. It is suitable to be used to establish traceability
systems, which is open, global, and pervasive.
8.1.3. Cloud Computing
Cloud computing is a general term for anything that involves
delivering hosted services over the Internet. These services are
broadly divided into three categories: Infrastructure-as-a-Service
(IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service
(SaaS). IDTP may play a role in the SaaS category as general
communication protocol.
8.1.4. Ubiquitous Computing
Ubiquitous computing is a computing concept where computing is made
to appear everywhere and anywhere. The traceability of UTID and IDTP
makes computing to reach everywhere and anywhere. IDTP is the
protocol to achieve the objective.
8.1.5. Internet of Things
The Internet of Things (IoT) is a scenario in which objects are
provided with unique identifiers and the ability to automatically
transfer data over a network. UTIDs are initially designed to be the
unique identifiers of objects. IDTP is the suitable protocol for the
communications of objects with traceability of UTID.
8.2. Synchronization
For simplicity, IDTP is typically implemented in a purely
synchronous fashion, which holds a connection open and waits until
the response is delivered or the timeout period expires. It is also
possible to be implemented in asynchronous fashion in the future.
9. Security Considerations
This section is meant to inform application developers, information
providers, and users of the security limitations in IDTP as
N. G. Huang Expires November 19, 2015 [Page 30]
Internet-Draft IDTP May 2015
described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks.
9.1. Sensitive Information
It is very possible to transmit sensitive information (e.g. the
user's name, places, mail address, passwords, encryption keys, etc.)
over network via IDTP. It SHOULD be very careful to prevent
unintentional leakage of this information via the IDTP to other
sources. It is very strongly recommend that a convenient interface
be provided for the user to control dissemination of such
information, and that designers and implementers be particularly
careful in this area.
9.2. Data Encryption
Data encryption and decryption technologies provide a solution to
prevent unintentional leakage of sensitive information. It is
suggest that designers and implementers consider providing
alternative choice of encryption and decryption of sensitive
information.
9.3. Authentication and Authorization
This document does not define any authentication and authorization
for IDTP. There may be such mechanisms by adapting suitable
technology when implementing IDTP in the future.
9.4. Other Risks
There are many other risks, such as denial of service attacks and
DNS spoofing, which are hard to defend against.
10. IANA Considerations
No IANA actions are required by this document.
11. Change log of this document
draft-huangng-idtp-01: Add two links to the web site of reference
implementation of UTID and IDTP and official web site of UTID and
IDTP in the section "1. Introduction".
draft-huangng-idtp-02: (1)Change the delimiter of header field from
";" to "\n" (LF); (2)Add a header field "from".
N. G. Huang Expires November 19, 2015 [Page 31]
Internet-Draft IDTP May 2015
draft-huangng-idtp-03: (1) Change the tracing rule from "by suffix
only" to "by suffix and namespace"; (2) Change the features of
built-in request of Ping; (3) Delete a header field "from", which
added in draft-huangng-idtp-02.
draft-huangng-idtp-05: (1) No changes; (2) Just make the ID active.
12. References
12.1. Normative References
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[ISO646] International Organization for Standardization (ISO),
"Information Technology: ISO 7-bit Coded Character Set for
Information Interchange", International Standard, Ref. No.
ISO/IEC 646:1991.
[ISO8402] International Organization for Standardization. ISO 8402:
1994: Quality Management and Quality Assurance-Vocabulary.
International Organization for Standardization, 1994.
[ISO8601] ISO, TC. (2004). Data Elements and Interchange Formats-
Information Exchange-Representation of Dates and Times-ISO
8601: 2004. International Standardizaton Organization (ISO).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[Unicode] Julie D. Allen. The Unicode Standard, Version 6.0, The
Unicode Consortium, Mountain View, 2011.
12.2. Informative References
[Huang2011] Neng-Geng Huang, Bing-Liang Zhang, Zhi-Yuan Huang (2011):
"Concept and design of a things mail system", Signal
Processing, Communications and Computing (ICSPCC), 2011 IEEE
International Conference on. DOI: 10.1109/ICSPCC.2011.6061741
[I-D-UTID] N. G. Huang, "Universally Traceable Identifier (UTID)",
Internet-Draft, draft-huangng-utid-05.txt, May. 2015.
N. G. Huang Expires November 19, 2015 [Page 32]
Internet-Draft IDTP May 2015
[WSDL] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web
Services Description Language (WSDL) Version 2.0 Part 1: Core
Language", W3C Recommendation 26 June 2007,
<http://www.w3.org/TR/2007/REC-wsdl20-20070626>
13. Acknowledgments
The author of this document thanks to Mr. Zhang Bing-Liang for his
innovative idea of things mail that inspired the concept of UTID and
IDTP.
This document was prepared using 2-Word-v2.0.template.dot.
N. G. Huang Expires November 19, 2015 [Page 33]
Internet-Draft IDTP May 2015
Appendix A.
Built-in Request
This appendix documents the built-in request needed when implements
IDTP. The namespace of built-in requests is "org.utid.request". All
built-in requests should be forwarded through underlying protocol
TCP by tracing gate.
A.1. Index
A request named "Index" under namespace "org.utid.request" is a
built-in request, which is used to get an index of namespace of the
catalog in a UTID.
The definition of "Index" built-in request is as follows:
Namespace: org.utid.request
Request name: Index
User's data fields in request:
No user's data fields.
User's data fields in response:
description: A string that describes the catalog of the UTID
in a request.
namespace: An array of string that list all namespaces that
mapped by the catalog of the UTID in a request.
An example of "Index" request is as follows:
idtp:0.9/1
utid:123~sensor$sample.test
ns:org.utid.request
name:Index
len:2
hop:1
hops:n0.sample.test
N. G. Huang Expires November 19, 2015 [Page 34]
Internet-Draft IDTP May 2015
{}
And the response is:
idtp:0.9/1
code:200 OK
len:129
hop:1
hops:n1.sample.test
{"namespace":["utid.org.utid.session","utid.org.utid.simple"],"descr
iption":"This is the description of the catalog \"sensor\"."}
The "description" field in the response shows that this list of
namespace is for a catalog named "sensor". The "namespace" field in
the response is an array of string that shows the catalog is mapped
to two namespaces: "utid.org.utid.session" and
"utid.org.utid.simple", which is assigned by the origin server.
A.2. Wsdl
A request named "Wsdl" under namespace "org.utid.request" is a
built-in request, which is used to get a definition of request and
response in WSDL format of a namespace.
The definition of "Wsdl" built-in request is as follows:
Namespace: org.utid.request
Request name: Wsdl
User's data fields in request:
namespace: A string that indicates the namespace.
User's data fields in response:
N. G. Huang Expires November 19, 2015 [Page 35]
Internet-Draft IDTP May 2015
wsdl: A string that contains the definition of the requests
and responses of the namespace in WSDL format.
An example of "Wsdl" request is as follows:
idtp:0.9/1
utid:123~sensor$sample.test
ns:org.utid.request
name:Wsdl
len:36
hop:1
hops:n1.sample.test
{"namespace":"utid.org.utid.simple"}
The second line is the user's data of the request. The response is:
idtp:0.9/1
code:200 OK
len:5726
hop:1
hops:n1.sample.test
{"wsdl":"<?xml version=\"1.0\" encoding=\"utf-
8\"?>\n<wsdl:definitions xmlns:soap=\"http://schemas.xmlsoap.......
The user's data in the response is very long (5726 bytes). The line
above shows only the beginning of the user's data. It is shows that
the "wsdl" field in the response is a string of WSDL format, which
defined the requests and responses in the namespace.
N. G. Huang Expires November 19, 2015 [Page 36]
Internet-Draft IDTP May 2015
A.3. Ping
A request named "Ping" under namespace "org.utid.request" is a
built-in request, which is used for testing purpose only.
The definition of "Ping" built-in request is as follows:
Namespace: org.utid.request
Request name: Ping
User's data fields in request:
No user's data fields.
User's data fields in response:
agent: A string that contains the operating system,
programming language, and the name of the
implementation of IDTP in origin server.
nodeName: The node name of the origin server.
note: A descriptive message about the origin server.
Time: Time used by the ping process in nanosecond.
An example of "Ping" request is as follows:
idtp:0.9/1
utid:101~db$sample.test
ns:org.utid.request
name:Ping
len:2
{}
The second line of the request is only a pair of braces, which
indicates that there is no user's data in the request. The response
is:
N. G. Huang Expires November 19, 2015 [Page 37]
Internet-Draft IDTP May 2015
idtp:0.9/1
code:200 OK
len:118
hop:2
hops:n1.sample.test;n0.sample.test
{"agent":"Win7/Java6/Busilet0.97","nodeName":"n1.sample.test","note"
:"This is a gateway for abc.com","time":233633987}
The "agent" field in the response shows that the origin server is
running Windows 7, the implementation of IDTP is called Busilet 0.97
using Java 6. The time used is about 233 millisecond.
The Ping request is used to test the accessibility of the target. It
also should be able to ping the UTID and namespace because the
target is determined by UTID suffix match and namespace match.
Copyright (c) 2015 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
N. G. Huang Expires November 19, 2015 [Page 38]
Internet-Draft IDTP May 2015
Authors' Addresses
Neng Geng Huang
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, Jiangsu,
China, 214121
Phone: 86-13921501950
Email: huangng@gmail.com
N. G. Huang Expires November 19, 2015 [Page 39]