idnits 2.17.1 draft-mcd-identifier-access-responce-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 532 has weird spacing: '...ing the of th...' -- The document date (December 25, 2019) is 1577 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3651' is mentioned on line 160, but not defined -- Looks like a reference, but probably isn't: '6' on line 163 == Unused Reference: 'RFC5730' is defined on line 910, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-08) exists of draft-ma-identifier-access-http-00 == Outdated reference: A later version (-08) exists of draft-mcd-identifier-access-security-00 == Outdated reference: A later version (-08) exists of draft-mcd-identifier-access-query-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Ma 2 Internet Draft J. Chen 3 Intended status: Experimental X. Fan 4 Expires: June 25, 2020 M. Chen 5 Z. Li 6 China Academy of Information and Communications Technology 7 December 25, 2019 9 JSON Responses for the Industrial Internet Identifier Data Access 10 Protocol (IIIDAP) 11 draft-mcd-identifier-access-responce-00 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 25, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document describes JSON data structures representing identifier 54 information maintained by Second-Level Nodes (SLN). These data 55 structures are used to form Industrial Internet Identifier Data 56 Access Protocol (IIIDAP) query responses. 58 Table of Contents 60 1. Introduction ................................................ 2 61 1.1. Terminology and Definitions............................. 3 62 1.2. Data Model ............................................. 3 63 2. Use of JSON ................................................. 4 64 2.1. Naming ................................................. 4 65 3. Common Data Types ........................................... 4 66 4. Common Data Structures....................................... 5 67 4.1. IIIDAP Conformance...................................... 5 68 4.2. Links .................................................. 5 69 4.3. Notices and Remarks..................................... 6 70 4.4. Language Identifier..................................... 8 71 5. Nodes ....................................................... 8 72 6. Error Response Body ........................................ 12 73 7. Responding to Help Queries.................................. 14 74 8. Responding To Searches...................................... 14 75 9. Indicating Truncated Responses.............................. 15 76 10. IANA Considerations........................................ 17 77 10.1. IIIDAP JSON Media Type Registration................... 17 78 11. Security Considerations.................................... 18 79 12. Internationalization Considerations........................ 18 80 12.1. Character Encoding.................................... 18 81 12.2. URIs and IRIs ........................................ 18 82 13. Privacy Considerations..................................... 18 83 14. References ................................................ 19 84 14.1. Normative References.................................. 19 85 14.2. Informative References................................ 20 87 1. Introduction 89 This document describes responses in the JSON [RFC7159] format for 90 the queries as defined by the Industrial Internet Identifier Data 91 Access Protocol Query Format [IDENTIFIER-QUERY]. A communication 92 protocol for exchanging queries and responses is described in 93 [IDENTIFIER-HTTP]. 95 1.1. Terminology and Definitions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 The following list describes terminology and definitions used 102 throughout this document: 104 TLN: Top-Level Nodes 106 SLN: Second-Level Nodes 108 ELN: Enterprise-Level Nodes 110 member: data found within an object as defined by JSON [RFC7159]. 112 object: a data structure as defined by JSON [RFC7159]. 114 IIIDAP: Industrial Internet Identifier Data Access Protocol 116 1.2. Data Model 118 The data model for JSON responses is specified in five sections: 120 1. simple data types conveyed in JSON strings 122 2. data structures specified as JSON arrays or objects that are used 123 repeatedly when building up larger objects 125 3. arrays of objects representing structured data corresponding to a 126 search for multiple objects 128 4. the response to an error 130 Positive responses take two forms. A response to a lookup of a 131 single object yields a JSON object, which is the subject of the 132 lookup. A response to a search for multiple objects yields a JSON 133 object that contains an array of JSON objects that are the subject 134 of the search. In each type of response, other data structures are 135 present within the topmost JSON object. 137 2. Use of JSON 139 2.1. Naming 141 Clients of these JSON responses SHOULD ignore unrecognized JSON 142 members in responses. 144 Clients processing JSON responses need to be prepared for members 145 representing identifier data specified in this document to be absent 146 from a response. In other words, servers are free to not include 147 JSON members containing identifier data based on their own policies. 149 Finally, all JSON names specified in this document are case 150 sensitive. Both servers and clients MUST transmit and process them 151 using the specified character case. 153 3. Common Data Types 155 JSON [RFC7159] defines the data types of a number, character string, 156 boolean, array, object, and null. This section describes the 157 semantics and/or syntax reference for common, JSON character strings 158 used in this document. 160 identifier: Take Handle Protocol [RFC3651] as an example, 161 Identifier format of TLN is XX; identifier format 162 of SLD is XX.YY; identifier format of ELD is 163 XX.YY.ZZ; XX, YY, ZZ are UTF-8 [6] encoded 164 character strings, which use any characters from 165 the Unicode 2.0 standard except the ASCII character 166 '/' (0x2F). 168 name: The maximum limit of name field is 255 ASCII 169 characters. 171 picture: Pictures need to be Base64 encoded, then 172 transferred via json. 174 id: The maximum limit of id field is 32 ASCII 175 characters. 177 dates and times: The syntax for values denoting dates and times is 178 defined in [RFC3339]. 180 URIs: The syntax for values denoting a Uniform Resource 181 Identifier (URI) is defined by [RFC3986]. 183 4. Common Data Structures 185 This section defines common data structures used in responses. 187 4.1. IIIDAP Conformance 189 The data structure named "iiidapConformance" is an array of strings, 190 each providing a hint as to the specifications used in the 191 construction of the response. This data structure appears only in 192 the topmost JSON object of a response. 194 An example iiidapConformance data structure: 196 "iiidapConformance" : 198 [ 200 "iiidap_level_0" 202 ] 204 Figure 1 206 The string literal "iiidap_level_0" signifies conformance with this 207 specification. 209 4.2. Links 211 The "links" array is found in data structures to signify links to 212 other resources on the Internet. The relationship of these links is 213 defined by the IANA registry described by [RFC5988]. 215 The following is an example of the link structure: 217 { 218 "value" : "http://example.com/context_uri", 219 "rel" : "self", 220 "href" : "http://example.com/target_uri", 221 "hreflang" : [ "en", "ch" ], 222 "title" : "title", 223 "media" : "screen", 224 "type" : "application/json" 225 } 226 Figure 2 228 The JSON name/values of "rel", "href", "hreflang", "title", "media", 229 and "type" correspond to values found in Section 5 of [RFC5988]. The 230 "value" JSON value is the context URI as described by [RFC5988]. The 231 "href" JSON value MUST be specified. All other JSON values are 232 OPTIONAL. 234 This is an example of the "links" array as it might be found in an 235 notice: 237 "links" : 238 [ 240 { 242 "href" : "http://example.com", 244 "title" : ""Terms of Use"" 246 } 248 ] 250 Figure 3 252 4.3. Notices and Remarks 254 The "notices" and "remarks" data structures take the same form. The 255 notices structure denotes information about the service providing 256 IIIDAP information and/or information about the entire response, 257 whereas the remarks structure denotes information about the 258 identifiers that contains it. 260 Both are arrays of objects. Each object contains an optional "title" 261 string representing the title of the object, an optional "type" 262 string denoting a registered type of remark or notice, an array of 263 strings named "description" for the purposes of conveying any 264 descriptive text, and an optional "links" array as described in 265 Section 4.2. 267 An example of the notices data structure: 269 "notices" : 270 [ 271 { 272 "title" : "Terms of Use", 273 "description" : 274 [ 275 "Service subject to The Registry of the Moon's TOS.", 276 "Copyright (c) 2020 LunarNIC" 277 ], 278 "links" : 279 [ 280 { 281 "value" : "http://example.net/entity/XXXX", 282 "rel" : "alternate", 283 "type" : "text/html", 284 "href" : http://www.example.com/terms_of_use.html 285 } 286 ] 287 } 288 ] 290 Figure 4 292 It is the job of the clients to determine line breaks, spacing, and 293 display issues for sentences within the character strings of the 294 "description" array. Each string in the "description" array contains a 295 single complete division of human-readable text indicating to clients 296 where there are semantic breaks. 298 An example of the remarks data structure: 300 "remarks" : 302 [ 303 { 304 "description" : 305 [ 306 "She sells sea shells down by the sea shore.", 307 "Originally written by Terry Sullivan." 308 ] 309 } 310 ] 312 Figure 5 314 Note that objects in the "remarks" array may also have a "links" array. 316 While the "title" and "description" fields are intended primarily for 317 human consumption, the "type" string contains a well-known value to be 318 registered with TLN for programmatic use. 320 An example of the remarks data structure: 322 "remarks" : 323 [ 324 { 325 "type" : "information truncated due to authorization", 326 "description" : 327 [ 328 "Some identifier data may not have been given.", 329 "Use proper authorization credentials to see all of it." 330 ] 331 } 332 ] 334 Figure 6 336 4.4. Language Identifier 338 This data structure consists solely of a name/value pair, where the 339 name is "lang" and the value is a string containing a language 340 identifier as described in [RFC5646]. 342 "lang" : "mn-Cyrl-MN" 344 5. Nodes 346 An identifier appears throughout this document and is an appropriate 347 response for the /identifier/XXXX query defined in "Industrial 348 Internet Identifier Data Access Protocol (IIIDAP) Query Format" 349 [IDENTIFIER-QUERY]. It represents the information of a SLN or ELN. 350 All of these representations are expected to represent in JSON 351 [RFC7159]. 353 The following is an example of an entity. 355 { 356 "iiidapConformance" : 357 [ 358 "iiidap_level_0" 359 ], 360 "notices" : 361 [ 362 { 363 "title" : "Content Removed", 364 "description" : 365 [ 366 "Without full authorization, content has been removed.", 367 "Sorry, dude!" 368 ], 369 "links" : 370 [ 371 { 372 "value" : "http://example.net/identifier/86.100.1", 373 "rel" : "alternate", 374 "type" : "text/html", 375 "href" : http://www.example.com/redaction_policy.html 376 } 377 ] 378 } 379 ], 380 "lang" : "en", 381 "identifier" : "86.100.1", 382 "regTime" : "2017-09-12T08:57:32.0Z", 383 "status" : "ok", 384 "node" : 385 { 386 "name" : "mengniu" 387 "nature" : "research institutions", 388 "type" : "education", 389 "address" : 390 "No.52 Huayuan North Road, Haidian District Beijing, Beijing", 391 "idNumber" : "84929141111234", 392 "idType" : "other", 393 "idPhoto" : 394 { 395 "mime": "data:image/jpeg;base64", 396 "data": 397 "/9j/4AAaebZJRgABAQEASABIAAD/ha6aYeDr18DWornKrlX+/sP/9k=" 398 }, 399 "introduction" : "hello, i am ok", 400 "legalPerson" : 401 [ 402 { 403 "name" : "San Zhang", 404 "idNumber" : "131187199507297827", 405 "idType" : "resident ID card", 406 "idPhoto" : 407 { 408 "mime": "data:image/jpeg;base64", 409 "data": 410 "/9j/4AAaebZJRgABAQEASABIAAD/ha6aYeDr18DWornKrlX+/sP/9k=" 411 } 412 } 413 ] 415 "contact" : 416 [ 417 { 418 "name" : "Si Li", 419 "phone" : "+86 100 0138 5070", 420 "email" : test@caict.ac.cn 421 } 422 ] 423 } 424 ], 425 "remarks" : 426 [ 427 { 428 "description" : 429 [ 430 "She sells sea shells down by the sea shore.", 431 "Originally written by Terry Sullivan." 432 ] 433 } 434 ] 435 } 437 Figure 7 439 An identifier of a SLN or ELN can contain the following members: 441 o identifier -- a unique identifier of a SLN or ELN 443 o regTime -- a string representing the registration time of the 444 identifier of a node 446 o status -- a string representing the registration status of the 447 identifier. Optional values of the status MUST be defined by the 448 TLN. For example, status of nodes can be classified as: "ok" and 449 "hold". 451 o node -- an object representing a SLN or ELN, each containing the 452 following values: 454 * name -- a sting containing the name of a node 456 * nature -- a string representing the nature of a node. The 457 nature of a node (SLN or ELN) MUST be defined by the TLN. For 458 example, according to their nature, nodes can be classified as: 459 "government organs", "research institutions", "social 460 organizations", and "enterprises and institutions". 462 * type -- a string containing the type of industry the node 463 belongs to. The type of a node (SLN or ELN) MUST be defined by the 464 TLN. For example, types of nodes can be classified as: 465 "agriculture, forestry, animal husbandry and fishery", 466 "the mining industry", 467 "manufacturing", 468 "electricity, heat, gas and water production and supply", 469 "the construction industry", 470 "wholesale and retail", 471 "transportation, warehousing and postal services", 472 "accommodation and catering", 473 "information transmission, software and information technology 474 services" 475 "the financial sector", 476 "the real estate industry", 477 "leasing and business services", 478 "scientific research and technology services", 479 "water conservancy, environment and public facilities 480 management", 481 "residential services, repairs and other services", 482 "education", 483 "health and social work", 484 "culture, sports and entertainment", 485 "public administration, social security and social 486 organization", 487 and "the international organization". 489 * address -- a string containing the address of the node 491 * idNumber -- a string representing the unique legally binding 492 identification number of a node 494 * idType -- a string representing the type of the idNumber of 495 the node. The type of the identification number of a node (SLN or 496 ELN) MUST be defined by the TLN. For example, according to their 497 type, identification number of a node can be classified as: "unified 498 social credit code", and "other". 500 * idPhoto -- an object containing the picture messages for the 501 legally binding entity proof of a node. The file type of the image 502 can be .jpg, .png, .bmf and .jpeg, and base64 encoding is required 503 for the file upload. 505 * introduce -- a string describing some business information of 506 the node 507 * legalPerson -- an object representing the legal person of the 508 node 510 + name -- a string containing the name of the legal person 512 + idNumber -- a string representing the unique legally 513 binding identification number of the legal person 515 + idType -- a string representing the type of the idNumber of 516 the legal person. The type of the identification number of a contact 517 MUST be defined by the TLN. For example, according to their type, 518 identification number of a contact can be classified as: 519 "Chinese identity card", "Travel permit for Hong Kong and 520 Macao residents to and from the mainland", 521 "Permit for Taiwan residents to travel to and from the 522 mainland", 523 "Permanent resident identity CARDS for foreigners", 524 "Hong Kong, Macao and Taiwan resident permit", and 525 "passport". 527 + idPhoto -- an object containing the picture messages for 528 the legally binding entity proof of a legal person. The file type of 529 the image can be .jpg, .png, .bmf and .jpeg, and base64 encoding is 530 required for the file upload. 532 * contact -- an object representing the of the node 534 + name -- a string containing the name of the contact 536 + phone -- a string containing the phone of the contact 538 + email -- a string containing the Email of the contact 540 6. Error Response Body 542 Some non-answer responses may return entity bodies with information 543 that could be more descriptive. 545 The basic structure of that response is an object containing an 546 error code number (corresponding to the HTTP response code) followed 547 by a string named "title" and an array of strings named 548 "description". 550 This is an example of the common response body. 552 { 553 "errorCode": 418, 554 "title": "Your Beverage Choice is Not Available", 555 "description": 556 [ 557 "I know coffee has more ummppphhh.", 558 "Sorry, dude!" 559 ] 560 } 562 Figure 8 564 This is an example of the common response body with an 565 iiidapConformance and notices data structures: 567 { 568 "iiidapConformance" : 569 [ 570 "iiidap_level_0" 571 ], 572 "notices" : 573 [ 574 { 575 "title" : "Beverage Policy", 576 "description" : 577 [ 578 "Beverages with caffeine for keeping horses awake." 579 ], 580 "links" : 581 [ 582 { 583 "value" : "http://example.net/identifier/86.100.1", 584 "rel" : "alternate", 585 "type" : "text/html", 586 "href" : "http://www.example.com/redaction_policy.html" 587 } 588 ] 589 } 590 ], 591 "lang" : "en", 592 "errorCode": 418, 593 "title": "Your beverage choice is not available", 594 "description": 595 [ 596 "I know coffee has more ummppphhh.", 597 "Sorry, dude!" 598 ] 599 } 600 Figure 9 602 7. Responding to Help Queries 604 The appropriate response to /help queries as defined by [IDENTIFIER- 605 QUERY] is to use the notices structure as defined in Section 4.3. 607 This is an example of a response to a /help query including the 608 iiidapConformance data structure. 610 { 611 "iiidapConformance" : 612 [ 613 "iiidap_level_0" 614 ], 615 "notices" : 616 [ 617 { 618 "title" : "Authentication Policy", 619 "description" : 620 [ 621 "Access to sensitive data for users with proper 622 credentials." 623 ], 624 "links" : 625 [ 626 { 627 "value" : "http://example.net/help", 628 "rel" : "alternate", 629 "type" : "text/html", 630 "href" : "http://www.example.com/auth_policy.html" 631 } 632 ] 633 } 634 ] 635 } 637 Figure 10 639 8. Responding To Searches 641 [IDENTIFIER-QUERY] specifies the pattern of searches through the 642 names of SLN and ELN. Responses to searches take the form of an 643 array of identifier objects. These arrays are contained within the 644 response object. 646 The following is an elided example of a response to a /names search. 648 { 649 "iiidapConformance" : 650 [ 651 "iiidap_level_0" 652 ], 653 ... 654 "NodeSearchResults" : 655 [ 656 { 657 "identifier" : "86.100.1", 658 "regTime" : "2019-12-12T08:57:32.0Z", 659 "status" : "ok", 660 ... 661 }, 662 { 663 "identifier" : "86.100.2", 664 "regTime" : "2018-12-12T08:57:32.0Z", 665 "status" : "ok", 666 ... 667 } 668 ] 669 } 671 Figure 11 673 9. Indicating Truncated Responses 675 In cases where the data of a response needs to be limited or parts 676 of the data need to be omitted, the response is considered 677 "truncated". A truncated response is still valid JSON, but some of 678 the results in a search set or some of the data in an object are not 679 provided by the server. A server may indicate this by including a 680 typed notice in the response object. 682 { 683 "iiidapConformance" : 684 [ 685 "iiidap_level_0" 686 ], 687 "notices" : 688 [ 689 { 690 "title" : "Search Policy", 691 "type" : "result set truncated due to authorization", 692 "description" : 693 [ 694 "Search results are limited to 25 per day per querying IP." 696 ], 697 "links" : 698 [ 699 { 700 "value" : "http://example.net/help", 701 "rel" : "alternate", 702 "type" : "text/html", 703 "href" : "http://www.example.com/search_policy.html" 704 } 705 ] 706 } 707 ], 708 "domainSearchResults" : 709 [ 710 ... 711 ] 712 } 714 Figure 12 716 A similar technique can be used with a typed remark where a single 717 object has been returned and data in that object has been truncated. 719 The following is an elided example of a truncated data. 721 { 722 "identifier" : "86.100.1", 723 "regTime" : "2019-12-12T08:57:32.0Z", 724 "status" : "ok", 725 "node" : 727 { 728 "name" : "", 729 "nature" : "research institutions", 730 "type" : "education", 731 ... 732 "legalPerson" : 733 { 734 ... 735 } 736 "contact" : 737 { 738 ... 739 } 740 }, 742 "remarks" : 744 [ 745 { 746 "title" : "Data Policy", 747 "type" : "object truncated due to unexplainable reason", 748 "description" : 749 [ 750 "Some of the data in this object has been removed." 751 ], 752 "links" : 753 [ 754 { 755 "value" : "http://example.net/help", 756 "rel" : "alternate", 757 "type" : "text/html", 758 "href" : "http://www.example.com/data_policy.html" 759 } 760 ] 761 } 762 ] 764 } 766 Figure 13 768 10. IANA Considerations 770 10.1. IIIDAP JSON Media Type Registration 772 This specification will register the "application/iiidap+json" media 773 type. 775 Type name: application 777 Subtype name: iiidap+json 779 Required parameters: n/a 781 Encoding considerations: See Section 3.1 of [RFC6839]. 783 Security considerations: The media represented by this identifier 784 does not have security considerations beyond that found in Section 6 785 of [RFC7159]. 787 Interoperability considerations: There are no known interoperability 788 problems regarding this media format. 790 Work in progress specification: draft-mcd-identifier-access- 791 responce-00 793 Applications that use this media type: Implementations of the 794 Industrial Internet Identifier Data Access Protocol (IIIDAP). 796 Intended usage: COMMON 798 Restrictions on usage: none 800 Author: Chendi Ma 802 Change controller: IETF 804 Provisional Registration: No (upon publication of this draft) 806 11. Security Considerations 808 This specification model information serialized in JSON format. As 809 JSON is a subset of JavaScript, implementations are advised to 810 follow the security considerations outlined in Section 6 of 811 [RFC7159] to prevent code injection. 813 Though not specific to JSON, IIIDAP implementers should be aware of 814 the security considerations specified in [IDENTIFIER-HTTP] and the 815 security requirements and considerations in [IDENTIFIER-SECURITY]. 817 Finally, service operators should be aware of the privacy mechanisms 818 noted in Section 13. 820 12. Internationalization Considerations 822 12.1. Character Encoding 824 The default text encoding for JSON responses in IIIDAP is UTF-8 825 [RFC3629], and all servers and clients MUST support UTF-8. 827 12.2. URIs and IRIs 829 [IDENTIFIER-HTTP] defines the use of URIs and IRIs in IIIDAP. 831 13. Privacy Considerations 833 This specification suggests some of values to identifier information 834 that has been marked as private and/or has been removed or obscured, 835 except: 837 o identifer 839 o name of a node 841 o type of a node 843 o introduce of a node 845 A few of the status values indicate that there are privacy concerns 846 associated with the identifier object. The following status codes 847 SHOULD be used to describe data elements of a response when 848 appropriate: 850 o private -- The object is not be shared in query responses, unless 851 the user is authorized to view this information. 853 o removed -- Data elements within the object have been collected 854 but have been omitted from the response. This option can be used 855 to prevent unauthorized access to associated identifier objects 856 without the need to mark them as private. 858 o obscured -- Data elements within the object have been collected, 859 but the response value has been altered so that values are not 860 easily discernible. A value changed from "1212" to "XXXX" is an 861 example of obscured data. This option may reveal privacy 862 sensitive information and should only be used when data 863 sensitivity does not require a more protective option like 864 "private" or "removed". 866 14. References 868 14.1. Normative References 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 874 Internet: Timestamps", RFC 3339, July 2002, 875 . 877 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 878 10646", STD 63, RFC 3629, November 2003, 879 . 881 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 882 Resource Identifier (URI): Generic Syntax", STD 66, RFC 883 3986, January 2005, 884 . 886 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 887 Languages", BCP 47, RFC 5646, September 2009, 888 . 890 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010, 891 . 893 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 894 Interchange Format", RFC 7159, March 2014, 895 . 897 14.2. Informative References 899 [JSON_ascendancy] 900 MacVittie, L., "The Stealthy Ascendancy of JSON", April 901 2011, . 904 [JSON_performance_study] 905 Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta, 906 "Comparison of JSON and XML Data Interchange Formats: A 907 Case Study", 2009, 908 . 910 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 911 STD 69, RFC 5730, August 2009, . 914 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 915 Structured Syntax Suffixes", RFC 6839, January 2013, 916 918 [IDENTIFIER-HTTP] 919 Ma, C., "HTTP Usage in the Industrial Internet Identifier 920 Data Access Protocol (IIIDAP)", Work in Progress, draft- 921 ma-identifier-access-http-00, December 2019. 923 [IDENTIFIER-SECURITY] 924 Ma, C., "Security Services for the Industrial Internet 925 Identifier Data Access Protocol (IIIDAP)", Work in 926 Progress, draft-mcd-identifier-access-security-00, 927 December 2019. 929 [IDENTIFIER-QUERY] 930 Ma, C., "Industrial Internet Identifier Data Access 931 Protocol (IIIDAP) Query Format", Work in Progress, draft- 932 mcd-identifier-access-query-00, December 2019. 934 Authors' Addresses 936 Chendi Ma 937 CAICT 938 No.52 Huayuan North Road, Haidian District 939 Beijing, Beijing, 100191 940 China 942 Phone: +86 177 1090 9864 943 Email: machendi@caict.ac.cn 945 Chen Jian 946 CAICT 947 No.52 Huayuan North Road, Haidian District 948 Beijing, Beijing, 100191 949 China 951 Phone: +86 138 1103 3332 952 Email: chenjian3@caict.ac.cn 954 Xiaotian Fan 955 CAICT 956 No.52 Huayuan North Road, Haidian District 957 Beijing, Beijing, 100191 958 China 960 Phone: +86 134 0108 6945 961 Email: fanxiaotian@caict.ac.cn 963 Meilan Chen 964 CAICT 965 No.52 Huayuan North Road, Haidian District 966 Beijing, Beijing, 100191 967 China 969 Phone: +86 139 1143 7301 970 Email: chenmeilan@caict.ac.cn