idnits 2.17.1 draft-mcd-identifier-access-responce-01.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 are 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 660 has weird spacing: '...ing the of th...' -- The document date (January 16, 2020) is 1555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 1044, 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: 2 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 (IETF) C. Ma 2 Internet Draft J. Chen 3 Intended status: Informational X. Fan 4 Expires: July 16, 2020 M. Chen 5 Z. Li 6 China Academy of Information and Communications Technology 7 January 16, 2020 9 JSON Responses for the Industrial Internet Identifier Data Access 10 Protocol (IIIDAP) 11 draft-mcd-identifier-access-responce-01.txt 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 ........................................ 15 73 7. Responding to Help Queries.................................. 16 74 8. Responding To Searches...................................... 17 75 9. Indicating Truncated Responses.............................. 18 76 10. IANA Considerations........................................ 20 77 10.1. IIIDAP JSON Media Type Registration................... 20 78 11. Security Considerations.................................... 20 79 12. Internationalization Considerations........................ 21 80 12.1. Character Encoding.................................... 21 81 12.2. URIs and IRIs ........................................ 21 82 13. Privacy Considerations..................................... 21 83 14. References ................................................ 22 84 14.1. Normative References.................................. 22 85 14.2. Informative References................................ 23 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 country codes: Where the identity of a geopolitical nation or 178 country is needed, these identities are represented 179 with the alpha-2 or two-character country code 180 designation as defined in [ISO.3166.1988]. The 181 alpha-2 representation is used because it is freely 182 available, whereas the alpha-3 and numeric-3 183 standards are not. 185 dates and times: The syntax for values denoting dates and times is 186 defined in [RFC3339]. 188 URIs: The syntax for values denoting a Uniform Resource 189 Identifier (URI) is defined by [RFC3986]. 191 4. Common Data Structures 193 This section defines common data structures used in responses. 195 4.1. IIIDAP Conformance 197 The data structure named "iiidapConformance" is an array of strings, 198 each providing a hint as to the specifications used in the 199 construction of the response. This data structure appears only in 200 the topmost JSON object of a response. 202 An example iiidapConformance data structure: 204 "iiidapConformance" : 206 [ 208 "iiidap_level_0" 210 ] 212 Figure 1 214 The string literal "iiidap_level_0" signifies conformance with this 215 specification. 217 4.2. Links 219 The "links" array is found in data structures to signify links to 220 other resources on the Internet. The relationship of these links is 221 defined by the IANA registry described by [RFC5988]. 223 The following is an example of the link structure: 225 { 226 "value" : "http://example.com/context_uri", 227 "rel" : "self", 228 "href" : "http://example.com/target_uri", 229 "hreflang" : [ "en", "ch" ], 230 "title" : "title", 231 "media" : "screen", 232 "type" : "application/json" 233 } 235 Figure 2 237 The JSON name/values of "rel", "href", "hreflang", "title", "media", 238 and "type" correspond to values found in Section 5 of [RFC5988]. The 239 "value" JSON value is the context URI as described by [RFC5988]. The 240 "href" JSON value MUST be specified. All other JSON values are 241 OPTIONAL. 243 This is an example of the "links" array as it might be found in an 244 notice: 246 "links" : 247 [ 249 { 251 "href" : "http://example.com", 253 "title" : ""Terms of Use"" 255 } 257 ] 259 Figure 3 261 4.3. Notices and Remarks 263 The "notices" and "remarks" data structures take the same form. The 264 notices structure denotes information about the service providing 265 IIIDAP information and/or information about the entire response, 266 whereas the remarks structure denotes information about the 267 identifiers that contains it. 269 Both are arrays of objects. Each object contains an optional "title" 270 string representing the title of the object, an optional "type" 271 string denoting a registered type of remark or notice, an array of 272 strings named "description" for the purposes of conveying any 273 descriptive text, and an optional "links" array as described in 274 Section 4.2. 276 An example of the notices data structure: 278 "notices" : 279 [ 280 { 281 "title" : "Terms of Use", 282 "description" : 283 [ 284 "Service subject to The Registry of the Moon's TOS.", 285 "Copyright (c) 2020 LunarNIC" 286 ], 287 "links" : 288 [ 289 { 290 "value" : "http://example.net/entity/XXXX", 291 "rel" : "alternate", 292 "type" : "text/html", 293 "href" : http://www.example.com/terms_of_use.html 294 } 295 ] 296 } 297 ] 299 Figure 4 301 It is the job of the clients to determine line breaks, spacing, and 302 display issues for sentences within the character strings of the 303 "description" array. Each string in the "description" array contains a 304 single complete division of human-readable text indicating to clients 305 where there are semantic breaks. 307 An example of the remarks data structure: 309 "remarks" : 311 [ 312 { 313 "description" : 314 [ 315 "She sells sea shells down by the sea shore.", 316 "Originally written by Terry Sullivan." 317 ] 318 } 319 ] 321 Figure 5 323 Note that objects in the "remarks" array may also have a "links" array. 325 While the "title" and "description" fields are intended primarily for 326 human consumption, the "type" string contains a well-known value to be 327 registered with TLN for programmatic use. 329 An example of the remarks data structure: 331 "remarks" : 332 [ 333 { 334 "type" : "information truncated due to authorization", 335 "description" : 336 [ 337 "Some identifier data may not have been given.", 338 "Use proper authorization credentials to see all of it." 339 ] 340 } 341 ] 343 Figure 6 345 4.4. Language Identifier 347 This data structure consists solely of a name/value pair, where the 348 name is "lang" and the value is a string containing a language 349 identifier as described in [RFC5646]. 351 "lang" : "mn-Cyrl-MN" 353 5. Nodes 355 An identifier appears throughout this document and is an appropriate 356 response for the /identifier/XXXX query defined in "Industrial 357 Internet Identifier Data Access Protocol (IIIDAP) Query Format" 358 [IDENTIFIER-QUERY]. It represents the information of a SLN or ELN. 359 All of these representations are expected to represent in JSON 360 [RFC7159]. 362 The following is an example of an entity. 364 { 365 "iiidapConformance" : 366 [ 367 "iiidap_level_0" 368 ], 369 "notices" : 371 [ 372 { 373 "title" : "Content Removed", 374 "description" : 375 [ 376 "Without full authorization, content has been removed.", 377 "Sorry, dude!" 378 ], 379 "links" : 380 [ 381 { 382 "value" : "http://example.net/identifier/86.100.1", 383 "rel" : "alternate", 384 "type" : "text/html", 385 "href" : http://www.example.com/redaction_policy.html 386 } 387 ] 388 } 389 ], 390 "lang" : "en", 391 "identifier" : "86.100.1", 392 "regTime" : "2017-09-12T08:57:32.0Z", 393 "status" : "ok", 394 "country" : "CN", 395 "node" : 396 { 397 "name" : "mengniu" 398 "nature" : "research institutions", 399 "type" : "education", 400 "subType" : "education", 401 "address" : "No.52 Huayuan North Road, Haidian District Beijing, 402 Beijing", 403 "idNumber" : "84929141111234", 404 "idType" : "other", 405 "idPhoto" : 406 { 407 "mime": "data:image/jpeg;base64", 408 "data": 409 "/9j/4AAaebZJRgABAQEASABIAAD/ha6aYeDr18DWornKrlX+/sP/9k=" 410 }, 411 "introduction" : "hello, I am ok", 412 "legalPerson" : 413 [ 414 { 415 "name" : "San Zhang", 416 "idNumber" : "131187199507297827", 417 "idType" : "resident ID card", 419 "idPhoto" : 420 { 421 "mime": "data:image/jpeg;base64", 422 "data": 423 "/9j/4AAaebZJRgABAQEASABIAAD/ha6aYeDr18DWornKrlX+/sP/9k=" 424 } 425 } 426 ] 427 "contact" : 428 [ 429 { 430 "name" : "Si Li", 431 "phone" : "+86 100 0138 5070", 432 "email" : test@caict.ac.cn 433 } 434 ] 435 } 436 ], 437 "remarks" : 438 [ 439 { 440 "description" : 441 [ 442 "She sells sea shells down by the sea shore.", 443 "Originally written by Terry Sullivan." 444 ] 445 } 446 ] 447 } 449 Figure 7 451 An identifier of a SLN or ELN can contain the following members: 453 o identifier -- a unique identifier of a SLN or ELN 455 o regTime -- a string representing the registration time of the 456 identifier of a node 458 o status -- a string representing the registration status of the 459 identifier. Optional values of the status MUST be defined by the 460 TLN. For example, status of nodes can be classified as: "ok" and 461 "hold". 463 o country -- a string containing the two-character country code of 464 the network 466 o node -- an object representing a SLN or ELN, each containing the 467 following values: 469 * name -- a sting containing the name of a node 471 * nature -- a string representing the nature of a node. The 472 nature of a node (SLN or ELN) MUST be defined by the TLN. For 473 example, according to their nature, nodes can be classified as: 474 "government organs", "research institutions", "social 475 organizations", and "enterprises and institutions". 477 * type -- a string containing the business type of the node. The 478 type of a node (SLN or ELN) MUST be defined by the TLN. For example, 479 types of nodes can be classified as: 480 "agriculture, forestry, animal husbandry and fishery", 481 "the mining industry", 482 "manufacturing", 483 "electricity, heat, gas and water production and supply", 484 "the construction industry", 485 "wholesale and retail", 486 "transportation, warehousing and postal services", 487 "accommodation and catering", 488 "information transmission, software and information technology 489 services" 490 "the financial sector", 491 "the real estate industry", 492 "leasing and business services", 493 "scientific research and technology services", 494 "water conservancy, environment and public facilities 495 management", 496 "residential services, repairs and other services", 497 "education", 498 "health and social work", 499 "culture, sports and entertainment", 500 "public administration, social security and social 501 organization", 502 and "the international organization". 504 * subType -- a string containing the business subtype of the 505 node. The Subtype of a node (SLN or ELN) MUST be defined by the TLN. 506 For example, types of nodes can be classified as: 507 "agricultural" 509 "forestry" 510 "animal husbandry" 511 "fisheries" 512 "agriculture, forestry, animal husbandry, fishing and 514 auxiliary activities" 515 "coal mining and washing industry" 516 "oil and gas extraction" 517 "ferrous metal mining industry" 518 "nonferrous metal mining industry" 519 "non-metallic mining industry" 520 "mining professionals and auxiliary activities" 521 "other mining" 522 "agricultural and sideline food processing" 523 "food manufacturing" 524 "wine, beverage and refined tea manufacturing" 525 "tobacco manufacturing" 526 "textile industry" 527 "textile and garment industry" 528 "leather, fur, feathers and their products and footwear" 529 "wood processing and water, bamboo, cane, palm, grass 530 products" 531 "furniture manufacturing" 532 "paper and paper products industry" 533 "the printing and recording media reproduction industry" 534 "culture and education, the United States, sports and 535 entertainment products" manufacturing" 536 "oil, coal and other fuel processing industries" 537 "chemical raw materials and chemical products manufacturing" 538 "pharmaceutical manufacturing" 539 "chemical fibre manufacturing" 540 "rubber and plastic products" 541 "non-metallic mineral products industry" 542 "ferrous metal smelting and rolling industry" 543 "non - ferrous metal smelting and rolling processing industry" 544 "metal manufacturing" 545 "general equipment manufacturing" 546 "special equipment manufacturing" 547 "automobile manufacturing" 548 "manufacturing of railway, shipping, aerospace and other 549 transport equipment" 550 "electrical machinery and equipment manufacturing" 551 "manufacturing of computers, communications and other 552 electronic equipment" 553 "instrument manufacturing" 554 "other manufacturing" 555 "waste resources comprehensive utilization industry" 556 "metal products, machinery and equipment repair industry" 557 "power and heat production and supply industries" 558 "gas production and supply" 559 "the production and supply of water" 560 "housing construction industry" 561 "civil engineering construction industry" 562 "construction and installation industry" 563 "architectural decoration, fitting-out and other construction 564 industries" 565 "wholesaling" 566 "retail" 567 "transportation industry" 568 "road transport" 569 "marine transportation" 570 "air transport" 571 "pipeline transportation" 572 "intermodal transport and transportation agencies" 573 "loading, unloading, handling and warehousing" 574 "the postal service" 575 "the lodging industry" 576 "the restaurant industry" 577 "telecommunications, radio, television and satellite 578 transmission services" 579 "internet and related services" 580 "software and information technology services" 581 "monetary and financial services" 582 "capital market services" 583 "the insurance industry" 584 "other financial sectors" 585 "the real estate industry" 586 "rental" 587 "business services" 588 "research and experimental development" 589 "professional technical services" 590 "technology extension and application services" 591 "water management" 592 "ecological protection and environmental management industry" 593 "public facilities management industry" 594 "land management industry" 595 "residential service" 596 "motor vehicles, electronic products and household products 597 repair industry" 598 "other services" 599 "education" 600 "health" 601 "social work" 602 "news and print industry" 603 "radio, television, film and audio production" 604 "arts and culture" 605 "sports" 606 "the entertainment industry" 607 "organs of the communist party of China" 608 "national institutions" 609 "the people coordinate government and the democratic parties" 610 "the social security" 611 "mass organizations, social organizations and other member 612 organizations" 613 "grassroots self-government organizations" 614 "the international organization" 616 * address -- a string containing the address of the node 618 * idNumber -- a string representing the unique legally binding 619 identification number of a node 621 * idType -- a string representing the type of the idNumber of 622 the node. The type of the identification number of a node (SLN or 623 ELN) MUST be defined by the TLN. For example, according to their 624 type, identification number of a node can be classified as: "unified 625 social credit code", and "other". 627 * idPhoto -- an object containing the picture messages for the 628 legally binding entity proof of a node. The file type of the image 629 can be .jpg, .png, .bmf and .jpeg, and base64 encoding is required 630 for the file upload. 632 * introduce -- a string describing some business information of 633 the node 635 * legalPerson -- an object representing the legal person of the 636 node 638 + name -- a string containing the name of the legal person 640 + idNumber -- a string representing the unique legally 641 binding identification number of the legal person 643 + idType -- a string representing the type of the idNumber of 644 the legal person. The type of the identification number of a contact 645 MUST be defined by the TLN. For example, according to their type, 646 identification number of a contact can be classified as: 647 "Chinese identity card", "Travel permit for Hong Kong and 648 Macao residents to and from the mainland", 649 "Permit for Taiwan residents to travel to and from the 650 mainland", 651 "Permanent resident identity CARDS for foreigners", 652 "Hong Kong, Macao and Taiwan resident permit", and 653 "passport". 655 + idPhoto -- an object containing the picture messages for 656 the legally binding entity proof of a legal person. The file type of 657 the image can be .jpg, .png, .bmf and .jpeg, and base64 encoding is 658 required for the file upload. 660 * contact -- an object representing the of the node 662 + name -- a string containing the name of the contact 664 + phone -- a string containing the phone of the contact 666 + email -- a string containing the Email of the contact 668 6. Error Response Body 670 Some non-answer responses may return entity bodies with information 671 that could be more descriptive. 673 The basic structure of that response is an object containing an 674 error code number (corresponding to the HTTP response code) followed 675 by a string named "title" and an array of strings named 676 "description". 678 This is an example of the common response body. 680 { 681 "errorCode": 418, 682 "title": "Your Beverage Choice is Not Available", 683 "description": 684 [ 685 "I know coffee has more ummppphhh.", 686 "Sorry, dude!" 687 ] 688 } 690 Figure 8 692 This is an example of the common response body with an 693 iiidapConformance and notices data structures: 695 { 696 "iiidapConformance" : 697 [ 698 "iiidap_level_0" 699 ], 700 "notices" : 701 [ 702 { 703 "title" : "Beverage Policy", 704 "description" : 705 [ 706 "Beverages with caffeine for keeping horses awake." 707 ], 708 "links" : 709 [ 710 { 711 "value" : "http://example.net/identifier/86.100.1", 712 "rel" : "alternate", 713 "type" : "text/html", 714 "href" : "http://www.example.com/redaction_policy.html" 715 } 716 ] 717 } 718 ], 719 "lang" : "en", 720 "errorCode": 418, 721 "title": "Your beverage choice is not available", 722 "description": 723 [ 724 "I know coffee has more ummppphhh.", 725 "Sorry, dude!" 726 ] 727 } 729 Figure 9 731 7. Responding to Help Queries 733 The appropriate response to /help queries as defined by [IDENTIFIER- 734 QUERY] is to use the notices structure as defined in Section 4.3. 736 This is an example of a response to a /help query including the 737 iiidapConformance data structure. 739 { 740 "iiidapConformance" : 741 [ 742 "iiidap_level_0" 743 ], 744 "notices" : 745 [ 746 { 747 "title" : "Authentication Policy", 748 "description" : 750 [ 751 "Access to sensitive data for users with proper 752 credentials." 753 ], 754 "links" : 755 [ 756 { 757 "value" : "http://example.net/help", 758 "rel" : "alternate", 759 "type" : "text/html", 760 "href" : "http://www.example.com/auth_policy.html" 761 } 762 ] 763 } 764 ] 765 } 767 Figure 10 769 8. Responding To Searches 771 [IDENTIFIER-QUERY] specifies the pattern of searches through the 772 names of SLN and ELN. Responses to searches take the form of an 773 array of identifier objects. These arrays are contained within the 774 response object. 776 The following is an elided example of a response to a /names search. 778 { 779 "iiidapConformance" : 780 [ 781 "iiidap_level_0" 782 ], 783 ... 784 "NodeSearchResults" : 785 [ 786 { 787 "identifier" : "86.100.1", 788 "regTime" : "2019-12-12T08:57:32.0Z", 789 "status" : "ok", 790 ... 791 }, 792 { 793 "identifier" : "86.100.2", 794 "regTime" : "2018-12-12T08:57:32.0Z", 795 "status" : "ok", 796 ... 798 } 799 ] 800 } 802 Figure 11 804 9. Indicating Truncated Responses 806 In cases where the data of a response needs to be limited or parts 807 of the data need to be omitted, the response is considered 808 "truncated". A truncated response is still valid JSON, but some of 809 the results in a search set or some of the data in an object are not 810 provided by the server. A server may indicate this by including a 811 typed notice in the response object. 813 { 814 "iiidapConformance" : 815 [ 816 "iiidap_level_0" 817 ], 818 "notices" : 819 [ 820 { 821 "title" : "Search Policy", 822 "type" : "result set truncated due to authorization", 823 "description" : 824 [ 825 "Search results are limited to 25 per day per querying IP." 826 ], 827 "links" : 828 [ 829 { 830 "value" : "http://example.net/help", 831 "rel" : "alternate", 832 "type" : "text/html", 833 "href" : "http://www.example.com/search_policy.html" 834 } 835 ] 836 } 837 ], 838 "domainSearchResults" : 839 [ 840 ... 841 ] 842 } 844 Figure 12 846 A similar technique can be used with a typed remark where a single 847 object has been returned and data in that object has been truncated. 849 The following is an elided example of a truncated data. 851 { 852 "identifier" : "86.100.1", 853 "regTime" : "2019-12-12T08:57:32.0Z", 854 "status" : "ok", 855 "node" : 857 { 858 "name" : "", 859 "nature" : "research institutions", 860 "type" : "education", 861 ... 862 "legalPerson" : 863 { 864 ... 865 } 866 "contact" : 867 { 868 ... 869 } 870 }, 872 "remarks" : 873 [ 874 { 875 "title" : "Data Policy", 876 "type" : "object truncated due to unexplainable reason", 877 "description" : 878 [ 879 "Some of the data in this object has been removed." 880 ], 881 "links" : 882 [ 883 { 884 "value" : "http://example.net/help", 885 "rel" : "alternate", 886 "type" : "text/html", 887 "href" : "http://www.example.com/data_policy.html" 888 } 889 ] 890 } 891 ] 893 } 895 Figure 13 897 10. IANA Considerations 899 10.1. IIIDAP JSON Media Type Registration 901 This specification will register the "application/iiidap+json" media 902 type. 904 Type name: application 906 Subtype name: iiidap+json 908 Required parameters: n/a 910 Encoding considerations: See Section 3.1 of [RFC6839]. 912 Security considerations: The media represented by this identifier 913 does not have security considerations beyond that found in Section 6 914 of [RFC7159]. 916 Interoperability considerations: There are no known interoperability 917 problems regarding this media format. 919 Work in progress specification: draft-mcd-identifier-access- 920 responce-00 922 Applications that use this media type: Implementations of the 923 Industrial Internet Identifier Data Access Protocol (IIIDAP). 925 Intended usage: COMMON 927 Restrictions on usage: none 929 Author: Chendi Ma 931 Change controller: IETF 933 Provisional Registration: No (upon publication of this draft) 935 11. Security Considerations 937 This specification model information serialized in JSON format. As 938 JSON is a subset of JavaScript, implementations are advised to 939 follow the security considerations outlined in Section 6 of 940 [RFC7159] to prevent code injection. 942 Though not specific to JSON, IIIDAP implementers should be aware of 943 the security considerations specified in [IDENTIFIER-HTTP] and the 944 security requirements and considerations in [IDENTIFIER-SECURITY]. 946 Finally, service operators should be aware of the privacy mechanisms 947 noted in Section 13. 949 12. Internationalization Considerations 951 12.1. Character Encoding 953 The default text encoding for JSON responses in IIIDAP is UTF-8 954 [RFC3629], and all servers and clients MUST support UTF-8. 956 12.2. URIs and IRIs 958 [IDENTIFIER-HTTP] defines the use of URIs and IRIs in IIIDAP. 960 13. Privacy Considerations 962 This specification suggests some of values to identifier information 963 that has been marked as private and/or has been removed or obscured, 964 except: 966 o identifer 968 o name of a node 970 o type of a node 972 o introduce of a node 974 A few of the status values indicate that there are privacy concerns 975 associated with the identifier object. The following status codes 976 SHOULD be used to describe data elements of a response when 977 appropriate: 979 o private -- The object is not be shared in query responses, unless 980 the user is authorized to view this information. 982 o removed -- Data elements within the object have been collected 983 but have been omitted from the response. This option can be used 984 to prevent unauthorized access to associated identifier objects 985 without the need to mark them as private. 987 o obscured -- Data elements within the object have been collected, 988 but the response value has been altered so that values are not 989 easily discernible. A value changed from "1212" to "XXXX" is an 990 example of obscured data. This option may reveal privacy 991 sensitive information and should only be used when data 992 sensitivity does not require a more protective option like 993 "private" or "removed". 995 14. References 997 14.1. Normative References 999 [ISO.3166.1988] 1000 International Organization for Standardization, "Codes for 1001 the representation of names of countries, 3rd edition", 1002 ISO Standard 3166, August 1988. 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, March 1997. 1007 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1008 Internet: Timestamps", RFC 3339, July 2002, 1009 . 1011 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1012 10646", STD 63, RFC 3629, November 2003, 1013 . 1015 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1016 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1017 3986, January 2005, 1018 . 1020 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1021 Languages", BCP 47, RFC 5646, September 2009, 1022 . 1024 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010, 1025 . 1027 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1028 Interchange Format", RFC 7159, March 2014, 1029 . 1031 14.2. Informative References 1033 [JSON_ascendancy] 1034 MacVittie, L., "The Stealthy Ascendancy of JSON", April 1035 2011, . 1038 [JSON_performance_study] 1039 Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta, 1040 "Comparison of JSON and XML Data Interchange Formats: A 1041 Case Study", 2009, 1042 . 1044 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1045 STD 69, RFC 5730, August 2009, . 1048 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 1049 Structured Syntax Suffixes", RFC 6839, January 2013, 1050 1052 [IDENTIFIER-HTTP] 1053 Ma, C., "HTTP Usage in the Industrial Internet Identifier 1054 Data Access Protocol (IIIDAP)", Work in Progress, draft- 1055 ma-identifier-access-http-00, December 2019. 1057 [IDENTIFIER-SECURITY] 1058 Ma, C., "Security Services for the Industrial Internet 1059 Identifier Data Access Protocol (IIIDAP)", Work in 1060 Progress, draft-mcd-identifier-access-security-00, 1061 December 2019. 1063 [IDENTIFIER-QUERY] 1064 Ma, C., "Industrial Internet Identifier Data Access 1065 Protocol (IIIDAP) Query Format", Work in Progress, draft- 1066 mcd-identifier-access-query-00, December 2019. 1068 Authors' Addresses 1070 Chendi Ma 1071 CAICT 1072 No.52 Huayuan North Road, Haidian District 1073 Beijing, Beijing, 100191 1074 China 1076 Phone: +86 177 1090 9864 1077 Email: machendi@caict.ac.cn 1079 Chen Jian 1080 CAICT 1081 No.52 Huayuan North Road, Haidian District 1082 Beijing, Beijing, 100191 1083 China 1085 Phone: +86 138 1103 3332 1086 Email: chenjian3@caict.ac.cn 1088 Xiaotian Fan 1089 CAICT 1090 No.52 Huayuan North Road, Haidian District 1091 Beijing, Beijing, 100191 1092 China 1094 Phone: +86 134 0108 6945 1095 Email: fanxiaotian@caict.ac.cn 1097 Meilan Chen 1098 CAICT 1099 No.52 Huayuan North Road, Haidian District 1100 Beijing, Beijing, 100191 1101 China 1103 Phone: +86 139 1143 7301 1104 Email: chenmeilan@caict.ac.cn