Independent Submission N. G. Huang Internet Draft Wuxi Institute of Technology Intended status: Experimental November 21, 2014 Expires: May 2015 Identifier Tracing Protocol (IDTP) draft-huangng-idtp-04.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 May 21, 2015. N. G. Huang Expires May 21, 2015 [Page 1] Internet-Draft IDTP November 2014 Copyright Notice Copyright (c) 2014 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 May 21, 2015 [Page 2] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 3] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 4] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 5] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 6] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 7] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 8] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 9] Internet-Draft IDTP November 2014 idtp:/ The protocol version uses a "." 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 "" 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 May 21, 2015 [Page 10] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 11] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 12] Internet-Draft IDTP November 2014 +-----------------------------------------------------------------+ | 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 May 21, 2015 [Page 13] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 14] Internet-Draft IDTP November 2014 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: book66.82013-11- 06T12:37:28.883+0000 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 May 21, 2015 [Page 15] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 16] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 17] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 18] Internet-Draft IDTP November 2014 +------------------------+--+--+----------+------------------------+ | | | | | | | 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 May 21, 2015 [Page 19] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 20] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 21] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 22] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 23] Internet-Draft IDTP November 2014 +--------+---------------------------------------------------------+ | | 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 May 21, 2015 [Page 24] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 25] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 26] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 27] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 28] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 29] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 30] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 31] Internet-Draft IDTP November 2014 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-04: (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-04.txt, Jun. 2014. N. G. Huang Expires May 21, 2015 [Page 32] Internet-Draft IDTP November 2014 [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, 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 May 21, 2015 [Page 33] Internet-Draft IDTP November 2014 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 May 21, 2015 [Page 34] Internet-Draft IDTP November 2014 {} 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 May 21, 2015 [Page 35] Internet-Draft IDTP November 2014 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":"\n