Skip to main content

Identifier Tracing Protocol (IDTP)
draft-huangng-idtp-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author huangng@gmail.com
Last updated 2014-06-28
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-huangng-idtp-03
Independent Submission                                    N. G. Huang
Internet Draft                            Wuxi Institute of Technology
Intended status: Experimental                            June 28, 2014
Expires: December 2014

                    Identifier Tracing Protocol (IDTP)
                         draft-huangng-idtp-03.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 December 28, 2014.

N. G. Huang           Expires December 28, 2014               [Page 1]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 2]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 3]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 4]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 5]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 6]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 7]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 8]
Internet-Draft                  IDTP                         June 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 December 28, 2014               [Page 9]
Internet-Draft                  IDTP                         June 2014

           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 December 28, 2014              [Page 10]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 11]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 12]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 13]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 14]
Internet-Draft                  IDTP                         June 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:

   <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 December 28, 2014              [Page 15]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 16]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 17]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 18]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 19]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 20]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 21]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 22]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 23]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 24]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 25]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 26]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 27]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 28]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 29]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 30]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 31]
Internet-Draft                  IDTP                         June 2014

   draft-huangng-idtp-03: (2) 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.

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-03.txt, Jun. 2014.

N. G. Huang           Expires December 28, 2014              [Page 32]
Internet-Draft                  IDTP                         June 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,
         <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 December 28, 2014              [Page 33]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 34]
Internet-Draft                  IDTP                         June 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 December 28, 2014              [Page 35]
Internet-Draft                  IDTP                         June 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":"<?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 December 28, 2014              [Page 36]
Internet-Draft                  IDTP                         June 2014

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 December 28, 2014              [Page 37]
Internet-Draft                  IDTP                         June 2014

   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) 2014 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 December 28, 2014              [Page 38]
Internet-Draft                  IDTP                         June 2014

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 December 28, 2014              [Page 39]