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]