idnits 2.17.1 draft-huangng-idtp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 3) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 430 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([I-D-UTID]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 571 has weird spacing: '...version yes ...' == Line 579 has weird spacing: '...ptional optio...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2015) is 3265 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'Huang2011' is defined on line 1451, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission N. G. Huang 3 Internet Draft Wuxi Institute of Technology 4 Intended status: Experimental May 19, 2015 5 Expires: November 2015 7 Identifier Tracing Protocol (IDTP) 8 draft-huangng-idtp-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on November 19, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. 57 Abstract 59 The Identifier Tracing Protocol (IDTP) is an application-level 60 protocol for distributed and collaborative information systems. It 61 is a generic communication protocol which can be used for many tasks 62 with two types of forwarding mechanisms to achieve traceability by 63 using Universal Traceable Identifier (UTID) [I-D-UTID] which 64 contains two types of forwarding messages. 66 This document provides the specification of IDTP, including syntax, 67 data format, and the guidelines for their use, too. 69 Table of Contents 71 1. Introduction ................................................ 4 72 1.1. Design Considerations 73 ................................... 5 74 1.2. Terminology ............................................ 5 75 1.3. Overall Operation ...................................... 7 76 2. Conventions Used in This Document 77 ............................ 9 78 3. Protocol Parameters ......................................... 9 79 3.1. Header Data ............................................ 9 80 3.1.1. Header Data Field 81 .................................. 9 82 3.1.1.1. Idtp ......................................... 9 83 3.1.1.2. Utid ........................................ 10 84 3.1.1.3. Ns (namespace) 85 ............................... 10 86 3.1.1.4. Name ........................................ 10 87 3.1.1.5. Code ........................................ 11 88 3.1.1.6. Len ......................................... 11 89 3.1.1.7. Hop ......................................... 12 90 3.1.1.8. Hops ........................................ 12 91 3.1.1.9. Enc ......................................... 12 92 3.1.2. Header Data Format 93 ................................ 12 94 3.1.3. Header Data Examples 95 .............................. 13 97 3.2. User's Data ........................................... 14 98 3.2.1. User's Data Format 99 ................................ 14 100 3.2.2. User's Data Type 101 .................................. 14 102 3.2.3. User's Data Field Name 103 ............................ 15 104 3.2.4. User's Data Example 105 ............................... 15 106 3.3. Request ............................................... 15 107 3.4. Response .............................................. 16 108 4. Underlying Protocol ........................................ 16 109 4.1. TCP ................................................... 17 110 4.2. UDP ................................................... 17 111 4.3. UDP multicast ......................................... 17 112 4.4. HTTP .................................................. 18 113 4.5. Other Protocols ....................................... 18 114 5. Traceability ............................................... 18 115 5.1. Overview of Traceability 116 ............................... 18 117 5.2. Tracing Gate .......................................... 20 118 5.2.1. Tracing .......................................... 20 119 5.2.2. Tracing Mechanism 120 ................................. 21 121 5.2.2.1. Internet-based Forwarding .................... 21 122 5.2.2.2. Intranet-based Tracing 123 ....................... 21 124 5.2.3. Tracing Rules .................................... 22 125 5.2.4. Tracing Track .................................... 23 126 5.2.5. Infinite Loop .................................... 24 127 5.2.6. Tracing Inconsistency 128 ............................. 25 129 5.3. Tracing Bridge ........................................ 25 130 6. Request and Response ....................................... 26 131 6.1. Request and Namespace 132 .................................. 26 133 6.2. Namespace and Catalog of UTID 134 .......................... 26 135 6.3. Discovery ............................................. 27 136 7. Status Code Definitions .................................... 27 137 7.1. Reserved 1xx .......................................... 27 138 7.2. Successful 2xx ........................................ 27 139 7.2.1. 200 OK ........................................... 27 140 7.2.2. 201 UDP Multicast Sent Out 141 ........................ 28 142 7.3. Client Error 3xx ...................................... 28 143 7.3.1. 300 Invalid UTID 144 .................................. 28 145 7.3.2. 301 Invalid Header 146 ................................ 28 147 7.3.3. 302 Invalid Data 148 .................................. 28 149 7.4. Server Error 4xx ...................................... 28 150 7.4.1. 400 Internal Server Error 151 ......................... 28 152 7.4.2. 401 IDTP Version Not Supported .................... 28 153 7.4.3. 402 Encrypt/Decrypt Error 154 ......................... 28 155 7.4.4. 403 Missing Encrypt Error 156 ......................... 28 157 7.4.5. 404 Service Not Found 158 ............................. 29 159 7.5. Tracing Error 5xx ..................................... 29 160 7.5.1. 500 Failed To Connect To Server ................... 29 161 7.5.2. 501 Max Hop Count Reached 162 ......................... 29 163 7.5.3. 502 UDP Message Is Too Long 164 ....................... 29 165 8. Usage 166 ...................................................... 29 167 8.1. Application Scopes .................................... 29 168 8.1.1. Remote Procedure Call 169 ............................. 29 170 8.1.2. Distributed Database 171 .............................. 29 172 8.1.3. Cloud Computing 173 ................................... 30 174 8.1.4. Ubiquitous Computing 175 .............................. 30 176 8.1.5. Internet of Things 177 ................................ 30 178 8.2. Synchronization ....................................... 30 179 9. Security Considerations .................................... 30 180 9.1. Sensitive Information 181 .................................. 31 182 9.2. Data Encryption ....................................... 31 183 9.3. Authentication and Authorization 184 ....................... 31 185 9.4. Other Risks ........................................... 31 186 10. IANA Considerations ....................................... 31 187 11. Change log of this document 188 ................................ 31 189 12. References ................................................ 32 190 12.1. Normative References 191 .................................. 32 192 12.2. Informative References 193 ................................ 32 194 13. Acknowledgments ........................................... 33 195 Appendix A. Built-in Request 196 ................................... 34 197 A.1. Index ................................................. 34 198 A.2. Wsdl .................................................. 35 199 A.3. Ping .................................................. 37 201 1. Introduction 203 The Identifier Tracing Protocol (IDTP) is an application-level 204 protocol for distributed and collaborative information systems. It 205 is a generic communication protocol which can be used for many tasks 206 with two types of forwarding mechanisms and with low computation 207 cost. 209 IDTP is a protocol based on request-response model. It is similar to 210 HTTP, Web Service, Java RMI, or CORBA. The unique feature of IDTP is 211 that it has two types of forwarding mechanisms to achieve 212 traceability by using Universal Traceable Identifier (UTID) [I-D- 213 UTID] which contains two types of forwarding messages. 215 Note 1: This version of this document has an important change 216 compare to the previous version. The major change is tracing 217 mechanism which has many influences on this document. 219 Note 2: A reference implementation, which is called "busilet", of 220 UTID and IDTP has been developed as open source software and could 221 be downloaded from http://sourceforge.net/projects/busilet/. For 222 more information please visit http://www.utid.org. 224 1.1. Design Considerations 226 o Traceability: Traceability is the major objective of designing 227 IDTP and UTID. The network will become extra huge in the near 228 future to connect not only computers but also smart devices and 229 even every object in the world through various technologies. IDTP 230 provides two types of forwarding mechanisms to trace a request to 231 its origin specified by UTID associated to the request. This is 232 why a new identification system and a new communication protocol 233 are proposed. 235 o Consistency: It should be able to use a uniform mechanism to send 236 a request and get a consistent response, regardless of local call 237 or remote call, regardless of different underlying protocols, 238 regardless of programming language, and regardless of the 239 platform of the origin server. 241 o Simplicity: It should be simple enough to be used by developers, 242 simple enough to be run in any kind of devices with low 243 computation cost. 245 1.2. Terminology 247 This specification uses a number of terms related to IDTP for 248 understanding the concept of IDTP. 250 o Traceability: It refers to the ability to trace the history, 251 application or location of an entity by means of recorded 252 identifications [ISO8402]. The concept of entity in this document 253 is extended to abstract object and physical object. 255 o Object: It is refer to an abstract object or a physical object in 256 this document. 258 o UTID: It is Universally Traceable Identifier, as defined in 259 reference [I-D-UTID]. The UTID is designed special for IDTP. 261 o FQUTID: It is full qualified UTID, as defined in Section 7.1 of 262 reference [I-D-UTID]. 264 o UTID suffix: It is the last part of a FQUTID starting from a 265 given position, as defined in Section 7.3 of reference [I-D-UTID]. 267 o Request: It is an IDTP request message, as defined in Section 3.3. 269 o Response: It is an IDTP request message, as defined in Section 270 3.4. 272 o Namespace: It is a name assigned to a request to avoid naming 273 conflicts, as defined in Section 6.1. 275 o Client: It is an application program that establishes connections 276 for the purpose of sending requests. 278 o Server: It is an application program that accepts connections in 279 order to service requests by sending back responses. 281 o Origin Server: It is a server on which information associated 282 with a given UTID resides or is to be created. 284 o Node: It is a server or a client. A node usually acts both as a 285 server and a client at same time. 287 o Node Name: Each node should have a name, which is global unique 288 usually consisting of DNS name and a sub domain name. An example 289 is "n1.sample.test". 291 o Tracing: It is the process to trace a request to its origin 292 server by forwarding the request. It is a special kind of 293 forwarding for the purpose of traceability. 295 o Tracing Gate: It is the node that responsible for tracing of 296 requests, in which data format conversion may be conducted during 297 the tracing. 299 o Tracing Bridge: It is a tracing gate that also acts as a bridge 300 between TCP/IP network and non TCP/IP network, in which smart 301 devices are to be connected to IDTP through any available 302 communication channels such as ZigBee, Bluetooth, CAN, or serial 303 port. 305 o Tracing Rules: They are a data set stored in tracing gate that 306 list the next hop address and connection parameters for tracing a 307 request. 309 o IDTP domain: It is a group of nodes with same tracing rules and 310 policy, usually owned by same organization. Therefore, the owner 311 could be able to make a unified rules and policy for tracing in 312 the IDTP domain. 314 o IDTP domain name: It is the name of IDTP domain, which is the DNS 315 name of the organization that owns the IDTP domain and shared by 316 all nodes in the IDTP domain. An example is "id.sample.test". 317 IDTP domain name usually is the dns component of a UTID as 318 defined in Section 5.1.2 of reference [I-D-UTID]. 320 o IDTP port number: It is TCP port number 25604 registered by IDTP 321 in IANA. This port number is recommended as a default TCP port 322 number of IDTP. 324 o Local processing: It means that the requester and the responder 325 is in same process, that is, same port number in same machine. 327 o Remote processing: It means that the requester and the responder 328 is NOT in same process, that is, different machine or different 329 port number in same machine. 331 1.3. Overall Operation 333 The IDTP is a request/response protocol. A client sends a message to 334 a server in the form of a request, which consists of header data and 335 user's data delimited by double LF characters. The server responds 336 with a response, which also consists of header data and user's data 337 delimited by double LF characters, back to the client through the 338 reverse route path. 340 An IDTP communication is initiated by a client, in which a request 341 is transmitted to origin server. In the simplest case, this may be 342 accomplished via a single connection (v) between the client (C) and 343 the origin server (O), as showed in Figure 1. 345 +------------------------------------------------+ 346 | | 347 | request chain ------------------------> | 348 | C -------------------v------------------- O | 349 | <----------------------- response chain | 350 | | 351 +------------------------------------------------+ 353 Figure 1 Communication between a client and an origin server 355 A more complicated situation occurs when one or more intermediaries 356 are present in the request/response chain. There are two forms of 357 intermediary: tracing gate and tracing bridge. 359 A tracing gate is a forwarding agent, which receives a request and 360 forwards the request to next hops address configured in the tracing 361 rules of the tracing gate. A tracing gate may rewrite part of the 362 header, encrypt or decrypt the user's data, or forward through a 363 different underlying protocol. For example, a tracing gate may 364 receive a request through TCP protocol and forward the request 365 through UDP protocol. 367 A tracing bridge is a tracing gate that also acts as a bridge 368 between an IDTP node and a device that does not have TCP/IP 369 connection and translates the request and response between the two 370 sides. 372 +-------------------------------------------------+ 373 | | 374 | request chain ---------------------------> | 375 | C -----v1----- A -----v2---- B -----v3------ O | 376 | <-------------------------- response chain | 377 | | 378 +-------------------------------------------------+ 380 Figure 2 Communication via intermediaries 382 Figure 2 shows two intermediaries (A and B) between the client and 383 origin server. A request or response message that travels the whole 384 chain will pass through three separate connections. IDTP 385 communication may apply only to the connection with the nearest 386 neighbor. Each connection may use different underlying protocols, 387 such as v1 connection uses TCP protocol, v2 connection uses UDP 388 protocol, v3 connection uses HTTP protocol to one origin server or 389 UDP multicast to a group of servers. 391 Although the diagram is linear, each participant may be engaged in 392 multiple, simultaneous communications. For example, B may be 393 receiving requests from many clients other than A, and/or forwarding 394 requests to servers other than O, at the same time that it is 395 handling A's request. 397 IDTP communication may takes place over TCP, UDP, HTTP, UDP 398 multicast connections. The default TCP port number is 25604, but 399 other ports can be used. 401 2. Conventions Used in This Document 403 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 404 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 405 document are to be interpreted as described in RFC-2119 [RFC2119]. 407 In this document, these words will appear with that interpretation 408 only when in ALL CAPS. Lower case uses of these words are not to be 409 interpreted as carrying RFC-2119 significance. 411 This specification uses the terms "character" in accordance with the 412 definitions provided in [BCP19]. 414 3. Protocol Parameters 416 The IDTP is a request/response protocol. The request and response 417 are consisted of header data and user's data: 419 header data 421 (a blank line) 423 user's data 425 The header data consists of several lines delimited by a LF 426 character and there should be no blank line. The user's data 427 consists of one or several lines with any delimit character, such as 428 LF, CR, or CRLF, and there may have blank lines. 430 The header data and the user's data are separated by double LF 431 characters, which mean they are separated by a blank line. 433 3.1. Header Data 435 3.1.1. Header Data Field 437 There are nine fields in header data as defined in following in the 438 order they appear in the header data. 440 3.1.1.1. Idtp 442 Idtp in the header data indicates that the message is an IDTP 443 request or response. It also indicates the version of IDTP and 444 version of request/response. The format of the idtp field is as 445 follows: 447 idtp:/ 449 The protocol version uses a "." numbering scheme to 450 indicate versions of the IDTP. The protocol versioning policy is 451 intended to allow the sender to indicate the format of a message and 452 its capacity for understanding further IDTP communication, rather 453 than the features obtained via that communication. 455 The request/response version uses a "" numbering scheme to 456 indicate versions of the request or response. The request/response 457 version is reserved for the version mechanism for the request and 458 response in the future. The version of a request should be same as 459 the version of corresponding response. 461 An example of idtp field is "idtp:0.9/1". 463 3.1.1.2. Utid 465 Utid in the header data indicates the origin server of the request. 466 It is the identifier to inform the origin server the object 467 concerned. The syntax of UTIDs is defined by reference [I-D-UTID]. 469 An example of utid field is "utid:101$a.test". 471 3.1.1.3. Ns (namespace) 473 Ns (abbr. of namespace) in the header data indicates the namespace 474 of a request to avoid naming conflict of requests. It usually adopts 475 the DNS name of the organization that defines the request, with the 476 higher level in the first. 478 Namespace should be in lower case. It is recommended that namespace 479 be added a prefix of "utid." in order to declare that it is an UTID 480 namespace. 482 An example of namespace field is "utid.example.project1.list". 484 3.1.1.4. Name 486 Name in the header data indicates the name of a request, which 487 determines the data format of the request and response. 489 It is recommended that the naming of requests follow the upper camel 490 case nomenclature. 492 An example of name field is "ProductList". 494 3.1.1.5. Code 496 Code in the header data indicates the response status code, which is 497 similar to the status code and reason phrase of HTTP. The code field 498 consists of two parts: a 3-digit integer and a reason phrase, 499 separated by a space. 501 The first digit of the 3-digit integer defines the class of the 502 response status. The last two digits do not have any categorization 503 role. There are 5 values for the first digit: 505 o 1xx Reserved - Not used currently 507 o 2xx Success - The action was successfully received, understood, 508 and accepted 510 o 3xx Client Error - The request contains bad syntax or cannot be 511 fulfilled or the response received contains bad syntax 513 o 4xx Server Error - The server failed to fulfill an apparently 514 valid request 516 o 5xx Tracing Error - The request failed to be traced or response 517 failed to be received 519 These status codes are fully defined in Section 7. The reason phrase 520 is intended to give a short textual description of the code for the 521 human user to understand. 523 The reason phrase is omitted if the underlying protocol is UDP or 524 UDP multicast. 526 An example of name code is "code:200 OK". 528 3.1.1.6. Len 530 Len in the header data indicates the user's data length, which does 531 not include the length of header data and the double LF, which are 532 used as the delimiter of header data and user's data. 534 An example of name len is "len:52". 536 3.1.1.7. Hop 538 Hop in the header data indicates the count of hops, which is used to 539 avoid loop tracing. The tracing is failure if hop reaches a 540 predetermined value (maximum hop count, default is 8). 542 An example of hop field is "hop:2". 544 3.1.1.8. Hops 546 Hops in the header data indicates the list of hops separated by 547 semicolons, which is used for debug when loop tracing occurs. It is 548 omitted if the underlying protocol is UDP or UDP multicast. 550 An example of name hops is "hops:n1.a.test;n0.demo.test". 552 3.1.1.9. Enc 554 Enc in the header data indicates the encryption/decryption 555 parameters. It is reserved for future use. It is omitted if the 556 underlying protocol is UDP or UDP multicast. 558 3.1.2. Header Data Format 560 Each field in header data appears as one line. Each line is a key- 561 value pair separated by a colon. Each line ends with a LF character 562 rather than a CRLF pair. Space or white space is not allowed in 563 header data except in the value of code field. If the value of one 564 field is null or empty, the field is omitted in the header data. 566 All ten fields are list in Figure 3. 568 +-----------------------------------------------------------------+ 569 | Field Description Request Response| 570 +-----------------------------------------------------------------+ 571 | idtp Idtp version,request/response version yes yes | 572 | utid Request UTID by client yes no | 573 | ns Namespace (package) of a request yes no | 574 | name Name of a request yes no | 575 | code Response status code no yes | 576 | len User's data length yes yes | 577 | hop Count of hops, maximum is 8 yes yes | 578 | hops List of hops for loop checking yes yes | 579 | enc Encryption parameters optional optional| 580 +-----------------------------------------------------------------+ 581 Note: The "yes" or "no" in the third and fourth column indicates 582 whether the field exists in request or response header data. 584 Figure 3 Summary of Header Fields 586 The order of the fields in header data MUST be appeared in the same 587 order listed in Figure 3. If more fields are to be added into the 588 header data in next version of IDTP, the new fields SHOULD be 589 appended to the list rather than inserted into the list. 591 3.1.3. Header Data Examples 593 An example of header data of a request is as follows: 595 idtp:0.9/1 597 utid:101$a.test 599 ns:utid.test.a 601 name:Product 603 len:19 605 An example of header data of a response is as follows: 607 idtp:0.9/1 609 code:200 OK 611 len:52 613 hop:2 614 hops:n1.a.test,n0.demo.test 616 3.2. User's Data 618 3.2.1. User's Data Format 620 The user's data is a JSON string or an XML string in one or more 621 lines, which represents serialized data of an object in Object 622 Oriented Languages. 624 For the consideration of performance and simplicity, the JSON format 625 is recommended. 627 There is no format type field in header data to indicate that the 628 user's data is in JSON string or in XML string. The format type is 629 easy to determine by checking the first character of the user's data, 630 where '{' stands for JSON string and '<' stand for XML string. 632 3.2.2. User's Data Type 634 Although there is no data type limited in the user's data 635 theoretically, the data types of fields in user's data are 636 recommended to be limited to following data types: 638 o Numeric type: Only three numeric types are recommended: int (32 639 bits), long (64 bits), and double (64 bits). Other numeric data 640 types, such as byte, short, and float are not encouraged although 641 these data types may be used in most context. 643 o Boolean: A boolean value should be express in lower case "true" 644 and "false" rather than "True" or "TRUE". 646 o String: A string is a sequence of characters defined by ISO/IEC 647 646 [ISO646] and Unicode [Unicode]. The Unicode character SHOULD 648 be encoded in UTF-8 [STD63] character set. 650 o Date: The date and time should be in ISO-8601 [ISO8601] format. 651 An example is "2013-11-06T12:06:46.257+0000". 653 o Array data: This includes array, list, set, and dictionary (map) 654 of data types list above. 656 o Structured data: This includes struct in C language and classes 657 in Object Oriented Languages, which consist of data types listed 658 above or another structured data. 660 o Binary data: Binary data is not encouraged to be used in IDTP 661 because IDTP is a light weight communication protocol. Binary 662 data may be expressed in the array of byte format if necessary. 664 o Other types: All other types are recommended to be converted into 665 string and negotiated between clients and servers in advance. 666 Examples are arbitrary-precision integers and arbitrary-precision 667 signed decimal numbers. 669 All data in various types will be converted into string in JSON or 670 XML format when transmitted on network. 672 3.2.3. User's Data Field Name 674 It is recommended that the data field naming follows the lower camel 675 case nomenclature. Examples are "fileName" and "userName". 677 Any data field name in the user's data starting with and ending with 678 double underscore are reserved for internal use. Examples are 679 "__attri__", "__session_id__", and "__utid_suffix__". 681 3.2.4. User's Data Example 683 Below is an example of user's data in JSON format. 685 {"name":"book","price":66.8,"date":"2013-11-06T12:37:28.883+0000"} 687 Below is an example of user's data in XML format: 689 book66.82013-11- 690 06T12:37:28.883+0000 692 3.3. Request 694 A request represents the header data and user's data that are to be 695 sent to an origin server. It encapsulates all messages required to 696 tracing a request to the server and understood by the server, where 697 the UTID is the most important because that the UTID contains the 698 forwarding messages to the origin server. 700 An example of request is: 702 idtp:0.9/1 704 utid:101$a.test 705 ns:utid.test.a 707 name:Product 709 len:19 711 {"sender":"Bella."} 713 The two parts are separated by double LF ("\n\n") characters so it 714 seems to be separated by a blank line. 716 3.4. Response 718 A response represents the header data and user's data that are to be 719 responded from an orgin server. It encapsulates all concerned 720 information of the UTID of the request. 722 An example of response is: 724 idtp:0.9/1 726 code:200 OK 728 len:52 730 hop:2 732 hops:n1.a.test,n0.demo.test 734 {"name":"Pen","price":12.0,"remark":"Hello, Bella."} 736 The two parts are separated by double LF ("\n\n") characters. 738 4. Underlying Protocol 740 IDTP is an application protocol that requires support of underlying 741 protocols including TCP, UDP, UDP multicast, and HTTP, which are 742 chose according to the requirements of applications, such as 743 efficiency, features, or compatibility requirements, to extend the 744 scopes of IDTP could applies. 746 4.1. TCP 748 TCP is known as a connection-oriented and reliable protocol, which 749 is suitable for use in most circumstance as an underlying protocol 750 of IDTP. However, it is not suitable for use in case of real time or 751 low computation capacity devices because of the cost due to the 752 establishment and termination of connections. 754 TCP is the default underlying protocol if no underlying protocol 755 specified for an IDTP connection. 757 4.2. UDP 759 UDP is a connectionless and unreliable protocol, which emphasizes 760 low-overhead operation and is suitable for real time or low 761 computation capacity devices as an underlying protocol of IDTP. 763 Although the data length transferred by UDP is limited to 65,507 764 bytes, the practical limit for the data length may be much less due 765 to the capacity limit of network equipments. For this reason, the 766 data length of UDP used in IDTP is limited to 484 bytes. Therefore, 767 the IDTP header data is simplified as follows: 769 o Omit two header data fields: "hops" and "enc". 771 o Reduce the length of the "code" field value: "code" field keeps 772 only the 3-digit integer without the reason phrase followed. 774 4.3. UDP multicast 776 Multicast is a technique for one-to-many communication that 777 increases the efficiency by which a node sends a packet only once 778 and the packet is delivered to a large number of receivers. UDP 779 multicast enables IDTP sending a request to multiple nodes in case 780 to broadcast a notification or get a list of activity nodes. 782 The disadvantages of UDP multicast are two: (1) it is unreliable so 783 the messages may be lost, and (2) it is one-way communication 784 without response. The measures to remedy the disadvantages may be: 786 o Duplicating multicast: The sender multicast more than once. For 787 example, a sender multicast a message three times at interval of 788 2 seconds then assumes that all nodes should receive the message. 790 o Responded by a new request: All receivers are requested to send 791 back a new request to inform the sender after receiving a 792 multicast message. 794 4.4. HTTP 796 HTTP is a popular protocol for data transfer mainly for hypertext 797 data of web pages. IDTP adopts HTTP as one of its underlying 798 protocol in order to enabling browsers to be a client to access IDTP 799 server, typically by Ajax technology. 801 4.5. Other Protocols 803 There are no limits on the underlying protocols that IDTP can use. 804 Examples of other protocols include wireless sensor network, near 805 field communication, mobile protocols, and industry buses, which are 806 mainly used to connect to smart devices by tracing bridges, as 807 defined in section 5.3. 809 5. Traceability 811 5.1. Overview of Traceability 813 Distributed computing, cloud computing, pervasive computing, 814 ubiquitous computing, and the Internet of Things make computing to 815 appear everywhere and anywhere. In the new era, computing can occur 816 using any device, in any location, and in any format. The devices 817 may be laptop computers, tablets, terminals, mobile phones, sensors, 818 actuators, and various smart devices, while the underlying 819 technologies include the Internet, wireless sensor network, advanced 820 middleware, near field communication, sensors, actuator, 821 microprocessors, new I/O and user interfaces, networks, mobile 822 protocols, location and positioning and new materials. 824 Devices located in various places are origins of information. The 825 UTIDs and IDTP are used to identify objects of origins and to 826 communicate each other. The traceability is the most important 827 feature of IDTP and UTID. Both of IDTP and UTID will lost their 828 values if without traceability. 830 A scenario that UTIDs and IDTP apply is illustrated in Figure 4. 832 +------------------------+--+--+----------+------------------------+ 833 | | | | | | 834 | Na1 | | | | Nb2 | 835 | \ | | Na4==Sa2 | / | 836 | \ | | | / | 837 | Sb1====Na3------Na0---+ | | / | 838 | / | Nc +---Nb0------Nb3====Sb1 | 839 | / | | \ | 840 | / +----Nb4 | \ | 841 | Na2 | | Nb1 | 842 | | | | 843 | | INTERNET | | 844 | LAN-A | (CLOUD) | LAN-B | 845 +------------------------+----------------+------------------------+ 847 Figure 4 A scenario of ubiquitous computing where IDTP applies 849 There are tow organizations ('a' and 'b') in Figure 4, which owns 850 LAN-A and LAN-B respectively, where 'N' stands for node, 'S' stands 851 for smart device, second letter in lower case stands for the 852 organization who own the nodes or smart devices, 'Nc' stands for an 853 independent node, single line stands for TCP/IP connections, and 854 double line stands for non TCP/IP connections. The two organizations 855 also have remote nodes, one of which is attached with a smart device. 856 All nodes are connected each other through Internet and the smart 857 devices are connected to nodes through other communication 858 technology, such as wireless sensor network, near field 859 communication, or various type of industry bus. 861 The two organizations registered DNS names and bound the DNS names 862 to node Na0 and Nb0 respectively. Other nodes may have either a 863 secondary DNS name or IP address only. The smart devices usually do 864 not have IP address. 866 Both nodes and smart devices may be act as origin servers to provide 867 information. For example, smart device 'Sa1' may be a temperature 868 sensor that provides real-time temperature values. 870 All nodes and smart device owned by organization 'a' are in one IDTP 871 domain and it is possible for them to share same tracing rules. An 872 IDTP domain may across LANs, such as node 'Na4' in Figure 4 belongs 873 to IDTP domain 'a'. 875 The traceability is implemented by tracing (forwarding) a request 876 directly or indirectly to origin server. There are two tracing 877 mechanisms: 879 o DNS/IP forwarding: It is the request forwarding according to the 880 DNS component of UTID in a request. It is based on DNS, IP 881 address, and IP forwarding technologies in the Internet. It is 882 the same as what happens in HTTP and SMTP and is not necessary to 883 be documented in this document. 885 o IDTP tracing: It is the request forwarding in an IDTP domain 886 internal according to the ending part of catalog and id 887 components of UTID in a request rather than the DNS component of 888 UTID in a request. It is based on UTID suffix matching algorithm 889 to forward a request to a server by the DNS name or IP address 890 specified in tracing rules. It is unique to the IDTP and is 891 documented in this section. 893 In the simplest IDTP domain, there is only one central IDTP server 894 that provides all information of the IDTP domain. Therefore, there 895 is no IDTP tracing in that IDTP domain. 897 However, the scenarios in the real world usually are that all nodes 898 and smart devices are origin server to achieve computing to appear 899 everywhere and anywhere. In this case, all nodes should be 900 configured with tracing rules and act both as IDTP servers and 901 tracing gates. The nodes on boundary of TCP/IP and non TCP/IP 902 network act as tracing bridges, such as Na3 and Nb3 in Figure 4. 904 5.2. Tracing Gate 906 A tracing gate is a node that responsible for tracing of requests, 907 in which data format conversion may be conducted during the tracing 909 5.2.1. Tracing 911 Tracing is essentially forwarding, of which the forwarding is 912 limited in an IDTP domain internal based on tracing rules. In the 913 IDTP domain internal, all nodes are tracing gate that configured 914 tracing rules used to determine the next hop address, either in DNS 915 or IP address. 917 A request may come from: 919 o Local request: It is from the same process of the tracing gate. 921 o Remote request: It is from a remote host or a different process 922 of the tracing gate. 924 The next hop may be: 926 o Local: The request is forwarded to the same process of the 927 tracing gate and is handled locally. 929 o Remote: The request is forwarded to a remote host or a different 930 process of the tracing gate (different port). 932 Therefore, a tracing gate handles a request in one of the following 933 four ways: 935 1. Local request is handled in local. 937 2. Local request is forwarding to remote. 939 3. Remote request is handled in local. 941 4. Remote request is forwarding to remote. 943 5.2.2. Tracing Mechanism 945 The tracing mechanism of tracing (forwarding) is determined by the 946 UTID and the namespace carried by a request. 948 The UTID, like URL in HTTP protocol, is used to determine the target 949 of tracing. There are two types of tracing: (1) Internet-based 950 forwarding, and (2) Intranet-based tracing. 952 5.2.2.1. Internet-based Forwarding 954 This is the forwarding using the DNS component in UTID in the 955 Internet based on the TCP/IP network. 957 This type of forwarding is not discussed in this document. 959 5.2.2.2. Intranet-based Tracing 961 This is the tracing using the UTID suffix match and namespace match 962 algorithm in the Intranet of an organization. 964 There are several tracing rules in a tracing gate. A tracing rule 965 consists of one or more tracing tracks, which define the mapping 966 between namespace and track. A track contains forwarding parameters, 967 such as target address, underlying protocol, and port number, etc. 969 There are two steps occurred in the Intranet-based tracing. The 970 first step is to match UTID with UTID suffix to find one tracing 971 rule. The second step is to match namespace to find one tracing 972 track. These two steps are discussed in the following. 974 5.2.3. Tracing Rules 976 A tracing rule is a name that contains a set of tracing track. Each 977 UTID suffix has one and only one tracing rule. But several UTID 978 suffix may share same tracing rule. 980 The first step is to match the UTID of a request to UTID suffix. If 981 a UTID ends with one UTID suffix, the UTID matches to the tracing 982 rule of the UTID suffix. If a UTID ends with more than one UTID 983 suffix, the longest UTID suffix wins. 985 When a tracing gate received a request either from local or remote, 986 the UTID of the request is used to match UTID Suffixes in tracing 987 rules. If no match found, then the request will be forwarded 988 according to the dns of the UTID by TCP and port number of 25604. If 989 one match found, then the request will be handled according to the 990 rule. 992 +------------------------------------------------------------------+ 993 | No. UTID suffix Rule | 994 +------------------------------------------------------------------+ 995 | 1 $test1.example rule1 | 996 | 2 .x1~a2$test2.example rule2 | 997 | 3 ~a1$test2.example rule2 | 998 | 4 ~$test2.example rule2 | 999 | 5 $test2.example rule1 | 1000 +------------------------------------------------------------------+ 1002 Figure 5 Example of tracing rules 1004 In the example show in Figure 5, there are five UTID suffixes and 1005 two rules. Any UTID ends with $test1.example will match rule1. A 1006 UTID of "123.x1~a2$test2.example" will match rule2. A UTID of 1007 "123~$test2.example " will match rule2. Any UTID in test2.example 1008 that doesn't match no. 2,3,4 will match rule1. 1010 In addition, a UTID of "123~$abc.test" will be forwarded to tcp port 1011 number 25604 in "abc.test" because there are no rule matched. 1013 5.2.4. Tracing Track 1015 A tracing track defines the mapping between namespace and track. A 1016 track contains forwarding parameters, such as target address, 1017 underlying protocol, and port number, etc. 1019 The second step is to match the namespace of the request to the 1020 namespace of a rule. If one match found, then the request will be 1021 handled according to the track parameters, that is, handled locally 1022 or forwarded to the defined address with the defined protocol and 1023 port number. If no match found, then the request will be forwarded 1024 according to the dns of the UTID by TCP and port number of 25604. 1026 A track has following parameters: 1028 o Namespace: It is used to match a request. It is considered as 1029 matched if the namespace ("ns" field in header data) of a request 1030 is exactly equal to the namespace in a tracing parameter. There 1031 is also one special namespace in a tracing parameter, that is, a 1032 wildcard of star ('*'), which matches all namespace in a request. 1034 o Underlying protocol: The underlying protocol may be one of TCP, 1035 UDP, UDP multicast, and HTTP. There are no other parameters if 1036 the underlying protocol is "Local". 1038 o Forward address: It indicates the address of next hop, which may 1039 either be DNS name or IP address. If the UTID of a request 1040 matches a UTID suffix, then the request will be forwarded to the 1041 address by TCP/IP network. 1043 o Port number: It is the port number of underlying protocol. The 1044 default TCP port number registered in IANA for IDTP is 25604. 1046 o Other index: There is other parameter for UDP multicast and HTTP. 1048 +--------+---------------------------------------------------------+ 1049 | | Track | 1050 | Rule +---------------------------------------------------------+ 1051 | | Namespace Protocol Address Port Path | 1052 +--------+---------------------------------------------------------+ 1053 | rule1 | org.sensor UDP 192.0.2.1 25604 N/A | 1054 | rule1 | org.database LOCAL N/A N/A N/A | 1055 | rule1 | * TCP 192.0.2.2 25604 N/A | 1056 | rule2 | org.iot TCP i1.test2.example 25604 N/A | 1057 | rule2 | * HTTP test2.example 80 /idtp | 1058 +--------+---------------------------------------------------------+ 1059 Note: * matches any namespace. 1061 Figure 6 Example of tracing tracks 1063 Figure 6 shows that rule1 has three tracks and rule2 has two tracks. 1064 Each track defines the namespace and the target. 1066 The result of two step matching may be (regardless where the request 1067 comes from): 1069 o Local handling: If a request matches to a track by match UTID 1070 suffix and namespace and the protocol of the track is local, the 1071 request will be handled locally. 1073 o Remote forwarding: If a request matches to a track by match UTID 1074 suffix and namespace and the protocol of the track is not local, 1075 the request will be forwarded to the address defined in the track 1076 by the protocol and port number defined in the track. 1078 o No match: If no match found, either UTID suffix match or 1079 namespace match fails, then the request will be forwarded 1080 according to the dns of the UTID by TCP and port number of 25604. 1082 5.2.5. Infinite Loop 1084 Infinite loop occurs if tracing gates is not configured correctly in 1085 an IDTP domain or in several IDTP domains. For example, a request is 1086 forwarded from node A to node B, then from node B to node C, and 1087 again from node C to node A. In order to avoid request loops, a 1088 header field of "hop", which increments by 1 each time of forwarding, 1089 is designed in a request. A request will not be forwarded any more 1090 and return a "403 Max Hop Count Reached" status code if hop reaches 1091 maximum count. 1093 A header field of "hops", which records all nodes' name passed by 1094 the request, is designed in a request. If infinite loop occurs, the 1095 tracing rules of all tracing gates listed in "hops" should be 1096 carefully checked in order to avoid such loops again. 1098 If the underlying protocol is UDP or UDP multicast, the header field 1099 "hops" is omitted so that no debug message is recorded. In this case, 1100 a built-in request named "Ping" with same UTID may be used for debug 1101 purpose. The built-in requests "Ping" are defined in Appendix A.1. 1103 5.2.6. Tracing Inconsistency 1105 Tracing inconsistency occurs if two requests with same UTID from two 1106 nodes are forwarded to different origin server. It is difficult to 1107 be detected out and should be avoided by carefully check the tracing 1108 rules of all concerned tracing gates to make the tracing rules 1109 consistency. In this case, the "hops" field in header data is also a 1110 good debug tool to find out tracing tracks of requests from two 1111 nodes. 1113 5.3. Tracing Bridge 1115 A tracing bridge is definitely a tracing gate. However, besides 1116 acting as a tracing gate, a tracing bridge also act as a bridge 1117 between TCP/IP network and non TCP/IP network. 1119 The nodes in non TCP/IP network are typically smart devices with low 1120 capacity of computation, such as sensors, actuators. These smart 1121 devices are connected to tracing bridges by various technologies, 1122 such as wireless sensor network, near field communication, and 1123 industry buses. 1125 A tracing bridge should be able to forward requests to smart devices 1126 and accept requests from smart devices through connections in a data 1127 format that could be understood by both sides. 1129 It is more desirable that the smart devices themselves are tracing 1130 bridges. 1132 The specification of tracing bridges is not defined in this document 1133 because of the diversity of smart devices and the connection 1134 technologies. 1136 6. Request and Response 1138 IDTP is based on request-response model. This document defines the 1139 syntax of requests and responses. However, the semantic of the 1140 requests and responses should be defined by both sides of the 1141 communications. For example, the data fields and their meaning of a 1142 request and a response for product information query should be 1143 recognized by both client and origin server. 1145 In the circumstance of ubiquitous computation, it is a key issue to 1146 make consensus about the semantic of the requests and responses. 1147 Therefore, it is an important issue to establish a standardization 1148 system of requests and responses, which is the constraint of the 1149 development of the IDTP. 1151 This section discusses some issues related to the standardization of 1152 requests and responses only. 1154 6.1. Request and Namespace 1156 Each request has a name and coupled with a response. Usually a group 1157 of request and response pair is involved to achieve an objective. 1158 Such a group of requests is developed by organizations and is used 1159 as a local standard. A namespace is assigned to the group of 1160 requests to avoid naming conflicts. 1162 It is necessary to publish a namespace to public by mechanisms like 1163 WSDL in Web Service [WSDL]. A namespace may become industry standard 1164 or international standard if the namespace is recognized by 1165 consensus among the industries. 1167 6.2. Namespace and Catalog of UTID 1169 A namespace represents a standard related to a group of requests, 1170 which is exposure to public. A UTID is designed and assigned to an 1171 object in an IDTP domain by an organization. Therefore, the public 1172 need to know the relationship between standards and UTIDs. 1174 Catalog of UTIDs is designed to establish the relationship between 1175 namespace and UTIDs by mapping the catalog of UTIDs to namespace. An 1176 IDTP domain should keep a mapping of catalog and namespace, which is 1177 to be published to public. Each node in the IDTP domain should be 1178 able to provide the mapping information to public. Appendix A.2 1179 defines a built-in request named "Index" for public to access the 1180 mapping information. 1182 The namespace stands for the standard of requests and responses and 1183 is exposure to public. The catalog is used to group UTIDs in an 1184 organization and is assigned internally by the organization. The 1185 organization should keep a mapping of catalog to namespace when 1186 design its catalog system, which is many to many relationship. 1188 6.3. Discovery 1190 If a client does not have any information about a UTID, IDTP 1191 provides a mechanism for public to discover the requests and 1192 responses used by the client to access the UTID, as follows: 1194 o From catalog to namespace: A client may obtain a list of 1195 namespaces that a UTID mapped through a built-in request "Index", 1196 which provide an index of namespace of the catalog component of 1197 the UTID from origin server. 1199 o From namespace to request: Then the client may obtain all 1200 requests and responses definition of a namespace in WSDL [WSDL] 1201 format from origin server through a built-in request "Wsdl", as 1202 defined in Appendix A.3. The wsdl message describes the requests 1203 and responses and can be used to generate requests and responses. 1205 o Access UTID by sending a request: Finally, the client access the 1206 UTID using the requests discovered by above approaches. 1208 The build-in requests are defined in Appendix A. 1210 7. Status Code Definitions 1212 Each status code is described below, including a brief description. 1214 7.1. Reserved 1xx 1216 Unused. It is reserved for future use. 1218 7.2. Successful 2xx 1220 The 2xx class of status code indicates that the client's request was 1221 successfully received, understood, and accepted 1223 7.2.1. 200 OK 1225 The request has succeeded and a response is returned. 1227 7.2.2. 201 UDP Multicast Sent Out 1229 The request has been multicast in the last node of a tracing chain. 1230 A response with code 201 is returned. 1232 7.3. Client Error 3xx 1234 The 3xx class of status code is used to indicate that the request to 1235 be sent or the response received contains bad syntax. 1237 7.3.1. 300 Invalid UTID 1239 The UTID in a request or a response contains bad syntax, which means 1240 the UTID is not follow the UTID specification [I-D-UTID]. 1242 7.3.2. 301 Invalid Header 1244 The header of a request or a response contains bad syntax. 1246 7.3.3. 302 Invalid Data 1248 The data of a request or a response contains bad syntax, which cause 1249 the failure of serialization or deserialization. 1251 7.4. Server Error 4xx 1253 The 5xx class of status code is used to indicate the server failed 1254 to fulfill an apparently valid request. 1256 7.4.1. 400 Internal Server Error 1258 It is a server error caused by many reasons in the server. 1260 7.4.2. 401 IDTP Version Not Supported 1262 The current IDTP version is 0.9. If IDTP version of a request is 1263 bigger than it, "502" code will be returned. 1265 7.4.3. 402 Encrypt/Decrypt Error 1267 It indicates errors related to encryption or decryption. 1269 7.4.4. 403 Missing Encrypt Error 1271 It indicates that a request should be encrypted but is transmitted 1272 in plaintext without encryption. 1274 7.4.5. 404 Service Not Found 1276 It indicates that the service (business logic) corresponding to a 1277 request is not found. 1279 7.5. Tracing Error 5xx 1281 The 5xx class of status code is used to indicate that an error 1282 occurs in the tracing process. 1284 7.5.1. 500 Failed To Connect To Server 1286 A client could not connect to server till timeout. It should 1287 indicate the underlying protocol type: TCP/UDP/UDP-MC/HTTP 1289 7.5.2. 501 Max Hop Count Reached 1291 The count of forwarding of a request reached the maximum number 1292 (default is 8). It means tracing loop occurred. 1294 7.5.3. 502 UDP Message Is Too Long 1296 The length of request or response is larger than the maximum length 1297 (484 bytes) if underlying protocol is UDP and UDP multicast. 1299 8. Usage 1301 8.1. Application Scopes 1303 IDTP may be applied in many application scopes. 1305 8.1.1. Remote Procedure Call 1307 IDTP is based on request-response model, which is actually one type 1308 of remote procedure call (RPC) or remote method invocation. 1310 In addition, the traceability feature of IDTP makes it suitable to 1311 be applied both for local call and remote call, with very low 1312 computation cost when used in local call. 1314 8.1.2. Distributed Database 1316 UTIDs are good candidates to be used as primary keys and foreign 1317 keys in databases distributed in different places to form a loosely- 1318 coupled distributed relational database system. There are no foreign 1319 key constraints between the primary keys and the foreign keys 1320 because that they are in different databases. However, there are 1321 still logic constraints between the primary keys and foreign keys. 1322 IDTP is the right choice to be the protocol to establish connections 1323 among these databases. 1325 Unlike traditional distributed database management system, this type 1326 of loosely-coupled distributed database system is light weight 1327 without replication and duplication, allowing full independence of 1328 databases. It is suitable to be used to establish traceability 1329 systems, which is open, global, and pervasive. 1331 8.1.3. Cloud Computing 1333 Cloud computing is a general term for anything that involves 1334 delivering hosted services over the Internet. These services are 1335 broadly divided into three categories: Infrastructure-as-a-Service 1336 (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service 1337 (SaaS). IDTP may play a role in the SaaS category as general 1338 communication protocol. 1340 8.1.4. Ubiquitous Computing 1342 Ubiquitous computing is a computing concept where computing is made 1343 to appear everywhere and anywhere. The traceability of UTID and IDTP 1344 makes computing to reach everywhere and anywhere. IDTP is the 1345 protocol to achieve the objective. 1347 8.1.5. Internet of Things 1349 The Internet of Things (IoT) is a scenario in which objects are 1350 provided with unique identifiers and the ability to automatically 1351 transfer data over a network. UTIDs are initially designed to be the 1352 unique identifiers of objects. IDTP is the suitable protocol for the 1353 communications of objects with traceability of UTID. 1355 8.2. Synchronization 1357 For simplicity, IDTP is typically implemented in a purely 1358 synchronous fashion, which holds a connection open and waits until 1359 the response is delivered or the timeout period expires. It is also 1360 possible to be implemented in asynchronous fashion in the future. 1362 9. Security Considerations 1364 This section is meant to inform application developers, information 1365 providers, and users of the security limitations in IDTP as 1366 described by this document. The discussion does not include 1367 definitive solutions to the problems revealed, though it does make 1368 some suggestions for reducing security risks. 1370 9.1. Sensitive Information 1372 It is very possible to transmit sensitive information (e.g. the 1373 user's name, places, mail address, passwords, encryption keys, etc.) 1374 over network via IDTP. It SHOULD be very careful to prevent 1375 unintentional leakage of this information via the IDTP to other 1376 sources. It is very strongly recommend that a convenient interface 1377 be provided for the user to control dissemination of such 1378 information, and that designers and implementers be particularly 1379 careful in this area. 1381 9.2. Data Encryption 1383 Data encryption and decryption technologies provide a solution to 1384 prevent unintentional leakage of sensitive information. It is 1385 suggest that designers and implementers consider providing 1386 alternative choice of encryption and decryption of sensitive 1387 information. 1389 9.3. Authentication and Authorization 1391 This document does not define any authentication and authorization 1392 for IDTP. There may be such mechanisms by adapting suitable 1393 technology when implementing IDTP in the future. 1395 9.4. Other Risks 1397 There are many other risks, such as denial of service attacks and 1398 DNS spoofing, which are hard to defend against. 1400 10. IANA Considerations 1402 No IANA actions are required by this document. 1404 11. Change log of this document 1406 draft-huangng-idtp-01: Add two links to the web site of reference 1407 implementation of UTID and IDTP and official web site of UTID and 1408 IDTP in the section "1. Introduction". 1410 draft-huangng-idtp-02: (1)Change the delimiter of header field from 1411 ";" to "\n" (LF); (2)Add a header field "from". 1413 draft-huangng-idtp-03: (1) Change the tracing rule from "by suffix 1414 only" to "by suffix and namespace"; (2) Change the features of 1415 built-in request of Ping; (3) Delete a header field "from", which 1416 added in draft-huangng-idtp-02. 1418 draft-huangng-idtp-05: (1) No changes; (2) Just make the ID active. 1420 12. References 1422 12.1. Normative References 1424 [BCP19] Freed, N. and J. Postel, "IANA Charset Registration 1425 Procedures", BCP 19, RFC 2978, October 2000. 1427 [ISO646] International Organization for Standardization (ISO), 1428 "Information Technology: ISO 7-bit Coded Character Set for 1429 Information Interchange", International Standard, Ref. No. 1430 ISO/IEC 646:1991. 1432 [ISO8402] International Organization for Standardization. ISO 8402: 1433 1994: Quality Management and Quality Assurance-Vocabulary. 1434 International Organization for Standardization, 1994. 1436 [ISO8601] ISO, TC. (2004). Data Elements and Interchange Formats- 1437 Information Exchange-Representation of Dates and Times-ISO 1438 8601: 2004. International Standardizaton Organization (ISO). 1440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1441 Requirement Levels", BCP 14, RFC 2119, March 1997. 1443 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1444 STD 63, RFC 3629, November 2003. 1446 [Unicode] Julie D. Allen. The Unicode Standard, Version 6.0, The 1447 Unicode Consortium, Mountain View, 2011. 1449 12.2. Informative References 1451 [Huang2011] Neng-Geng Huang, Bing-Liang Zhang, Zhi-Yuan Huang (2011): 1452 "Concept and design of a things mail system", Signal 1453 Processing, Communications and Computing (ICSPCC), 2011 IEEE 1454 International Conference on. DOI: 10.1109/ICSPCC.2011.6061741 1456 [I-D-UTID] N. G. Huang, "Universally Traceable Identifier (UTID)", 1457 Internet-Draft, draft-huangng-utid-05.txt, May. 2015. 1459 [WSDL] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web 1460 Services Description Language (WSDL) Version 2.0 Part 1: Core 1461 Language", W3C Recommendation 26 June 2007, 1462 1464 13. Acknowledgments 1466 The author of this document thanks to Mr. Zhang Bing-Liang for his 1467 innovative idea of things mail that inspired the concept of UTID and 1468 IDTP. 1470 This document was prepared using 2-Word-v2.0.template.dot. 1472 Appendix A. 1473 Built-in Request 1475 This appendix documents the built-in request needed when implements 1476 IDTP. The namespace of built-in requests is "org.utid.request". All 1477 built-in requests should be forwarded through underlying protocol 1478 TCP by tracing gate. 1480 A.1. Index 1482 A request named "Index" under namespace "org.utid.request" is a 1483 built-in request, which is used to get an index of namespace of the 1484 catalog in a UTID. 1486 The definition of "Index" built-in request is as follows: 1488 Namespace: org.utid.request 1490 Request name: Index 1492 User's data fields in request: 1494 No user's data fields. 1496 User's data fields in response: 1498 description: A string that describes the catalog of the UTID 1499 in a request. 1501 namespace: An array of string that list all namespaces that 1502 mapped by the catalog of the UTID in a request. 1504 An example of "Index" request is as follows: 1506 idtp:0.9/1 1508 utid:123~sensor$sample.test 1510 ns:org.utid.request 1512 name:Index 1514 len:2 1516 hop:1 1518 hops:n0.sample.test 1519 {} 1521 And the response is: 1523 idtp:0.9/1 1525 code:200 OK 1527 len:129 1529 hop:1 1531 hops:n1.sample.test 1533 {"namespace":["utid.org.utid.session","utid.org.utid.simple"],"descr 1534 iption":"This is the description of the catalog \"sensor\"."} 1536 The "description" field in the response shows that this list of 1537 namespace is for a catalog named "sensor". The "namespace" field in 1538 the response is an array of string that shows the catalog is mapped 1539 to two namespaces: "utid.org.utid.session" and 1540 "utid.org.utid.simple", which is assigned by the origin server. 1542 A.2. Wsdl 1544 A request named "Wsdl" under namespace "org.utid.request" is a 1545 built-in request, which is used to get a definition of request and 1546 response in WSDL format of a namespace. 1548 The definition of "Wsdl" built-in request is as follows: 1550 Namespace: org.utid.request 1552 Request name: Wsdl 1554 User's data fields in request: 1556 namespace: A string that indicates the namespace. 1558 User's data fields in response: 1560 wsdl: A string that contains the definition of the requests 1561 and responses of the namespace in WSDL format. 1563 An example of "Wsdl" request is as follows: 1565 idtp:0.9/1 1567 utid:123~sensor$sample.test 1569 ns:org.utid.request 1571 name:Wsdl 1573 len:36 1575 hop:1 1577 hops:n1.sample.test 1579 {"namespace":"utid.org.utid.simple"} 1581 The second line is the user's data of the request. The response is: 1583 idtp:0.9/1 1585 code:200 OK 1587 len:5726 1589 hop:1 1591 hops:n1.sample.test 1593 {"wsdl":"\n