idnits 2.17.1 draft-chen-epp-identifier-mapping-02.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-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 108: '...in this document MUST be interpreted i...' RFC 2119 keyword, line 121: '...ps and are not a REQUIRED feature of t...' RFC 2119 keyword, line 168: '...espace described in this document MUST...' RFC 2119 keyword, line 176: '... it MAY also apply to handle identif...' RFC 2119 keyword, line 189: '...dentifier object MUST always have at l...' (78 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 497 has weird spacing: '...version used ...' == Line 718 has weird spacing: '...version used ...' == Line 981 has weird spacing: '...tion of the...' == Line 991 has weird spacing: '...version used ...' == Line 993 has weird spacing: '...contain the...' -- The document date (February 24, 2020) is 1523 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 117, but not defined == Missing Reference: 'RFC3688' is mentioned on line 1564, but not defined == Missing Reference: 'RFC0791' is mentioned on line 1613, but not defined Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Y. Chen 2 Internet Draft J. Xie 3 Intended status: Experimental Z. Li 4 Expires: August 24, 2020 Z. Fan 5 China Academy of Information and Communications Technology 6 February 24, 2020 8 Extensible Provisioning Protocol (EPP) Industrial Internet 9 Identifier Mapping 10 draft-chen-epp-identifier-mapping-02 12 Abstract 14 This document describes an Extensible Provisioning Protocol 15 (EPP)mapping for the provisioning and management of Industrial 16 Internet Identifiers. Specified in XML, the mapping defines EPP 17 command syntax and semantics as applied to identifiers. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on August 24, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................... 4 60 1.1. Conventions Used in This Document ......................... 4 61 1.2 Scope of Experimentation................................... 4 62 2. Object Attributes .............................................. 4 63 2.1. Industrial Internet Identifier Object ..................... 5 64 2.2. Client Identifiers ........................................ 5 65 2.3. Status Values ............................................. 5 66 2.4. Dates and Times.............................................7 67 2.5. IP Addresses ...............................................7 68 3. EPP Command Mapping ............................................ 7 69 3.1. EPP Query Commands ........................................ 7 70 3.1.1. EPP Command ................................ 8 71 3.1.2. EPP Command ................................ 10 72 3.1.3. EPP Query Command ........................ 14 73 3.2. EPP Transform Commands .................................. 14 74 3.2.1. EPP Command .............................. 15 75 3.2.2. EPP Command .............................. 19 76 3.2.3. EPP Command .............................. 20 77 3.2.4. EPP Command ............................ 20 78 3.2.5. EPP Command ............................. 20 79 4. Formal Syntax ................................................. 25 80 5. Internationalization Considerations ........................... 33 81 6. Security Considerations ..................................... 34 82 7. IANA Considerations ........................................... 34 83 8. Acknowledgments ................................................35 84 9. References .....................................................35 85 9.1. Normative References ................................... 35 86 9.2. Informative References ................................. 36 88 1. Introduction 90 Industrial Internet Identifiers are character strings with a 91 specified format that may consist of digits, letters or notations 92 being structured in a way that is interpretable by one or more 93 computational facilities. 95 This document describes an Industrial Internet Identifier mapping 96 for version 1.0 of the Extensible Provisioning Protocol (EPP). This 97 mapping is specified using the Extensible Markup Language (XML)1.0 98 as described in [W3C.REC-xml-20040204] and XML Schema notation as 99 described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema- 100 2-20041028]. 102 [RFC5730]provides a complete description of EPP command and response 103 structures. A thorough understanding of the base protocol 104 specification is necessary to understand the mapping described in 105 this document. 107 XML is case sensitive. Unless stated otherwise, XML specifications 108 and examples provided in this document MUST be interpreted in the 109 character case presented to develop a conforming implementation. 111 1.1. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 115 this document are to be interpreted as described in RFC 2119 116 [RFC2119]. 118 In examples, "C:" represents lines sent by a protocol client and 119 "S:" represents lines returned by a protocol server. Indentation 120 and white space in examples are provided only to illustrate element 121 relationships and are not a REQUIRED feature of this protocol. 123 1.2. Scope of Experimentation 125 This document describes an experimental extension to EPP protocol. 126 This section specifies scope of this experiment and how it can yield 127 useful information. 129 This EPP extension is designed to manage the registration, 130 modification and resolution of digital objects, handles, OID, for 131 example throughout the Industrial Internet. According to the 132 definition of EPP, this extension is an XML text protocol that 133 permits multiple service providers to perform object-provisioning 134 operations using a shared central object repository. It is designed 135 for use in a layered protocol environment. Bindings to specific 136 transport and security protocols are outside the scope of this 137 specification. 139 Given the above points, the experiment can be run on the open 140 Internet between consenting client and server implementations. 142 2. Object Attributes 144 An EPP identifier object has attributes and associated values that 145 can be viewed and modified by the sponsoring client or the server. 146 This section describes each attribute type in detail. The formal 147 syntax for the attribute values described here can be found in the 148 "Formal Syntax" section of this document and in the appropriate 149 normative references. 151 2.1. Industrial Internet Identifier Object 153 Industrial Internet Identifiers are character strings with a 154 specified format that may consist of digits, letters or notations 155 being structured in a way that is interpretable by one or more 156 computational facilities. 158 It is an unique persistent set of bits used to identify and obtain 159 state information about physical resource such as machines, 160 products, or digital resources such as algorithms, manufacturing 161 process, etc. 163 This document provides an overview of the EPP mapping of Industrial 164 Internet Identification. Handle mapping is specified as an example, 165 while description in this document applies to other identification 166 techniques as well. 168 The syntax for handle namespace described in this document MUST 169 conform to [RFC3650], [RFC3651], [RFC3652]. Handle identifiers are 170 character strings with a specified length and a specified format. 172 All handle identifiers are of the form prefix/suffix where, by 173 default, the prefix may first be resolved to locate the specific 174 identifier service and the suffix may be any bit sequence. Epp 175 mapping on the prefix examples are provided in this document while 176 it MAY also apply to handle identifiers with suffix. 178 These conformance requirements might change in the future as a 179 result of progressing work in developing standards for 180 internationalized digital object identification. 182 2.2. Client Identifiers 184 All EPP clients are identified by a server-unique identifier. Client 185 identifiers conform to the "clIDType" syntax described in [RFC5730]. 187 2.3. Status Values 189 An EPP identifier object MUST always have at least one associated 190 status value. Status values MAY be set only by the client that 191 sponsors an identifier object and by the server on which the object 192 resides. A client can change the status of object using the EPP 193 command. Each status value MAY be accompanied by a string 194 of human-readable text that describes the rationale for the status 195 applied to the object. 197 A client MUST NOT alter status values set by the server. A server 198 MAY alter or override status values set by a client, subject to 199 local server policies. The status of an object MAY change as a 200 result of either a client-initiated transform command or an action 201 performed by a server operator. 203 Status values that can be added or removed by a client are prefixed 204 with "client". Corresponding status values that can be added or 205 removed by a server are prefixed with "server". Status values that 206 do not begin with either "client" or "server" are server-managed. 208 Status Value Descriptions: 210 - clientDeleteProhibited, serverDeleteProhibited 212 Requests to delete the object MUST be rejected. 214 - clientUpdateProhibited, serverUpdateProhibited 216 Requests to update the object (other than to remove this status) 217 MUST be rejected. 219 - linked 221 The identifier object has at least one active association with 222 another object. Servers SHOULD provide services to determine 223 existing object associations. 225 - ok 227 This is the normal status value for an object that has no pending 228 operations or prohibitions. This value is set and removed by the 229 server as other status values are added or removed. 231 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 233 A transform command has been processed for the object, but the 234 action has not been completed by the server. Server operators can 235 delay action completion for a variety of reasons, such as to allow 236 for human review or third-party action. A transform command that is 237 processed, but whose requested action is pending, is noted with 238 response code 1001. 240 When the requested action has been completed, the pendingCreate, 241 pendingDelete, pendingTransfer, or pendingUpdate status value MUST 242 be removed. All clients involved in the transaction MUST be 243 notified using a service message that the action has been completed 244 and that the status of the object has changed. 246 "ok" status MAY only be combined with "linked" status. 248 "linked" status MAY be combined with any status. 250 "pendingDelete" status MUST NOT be combined with either 251 "clientDeleteProhibited" or "serverDeleteProhibited" status. 253 "pendingUpdate" status MUST NOT be combined with either 254 "clientUpdateProhibited" or "serverUpdateProhibited" status. 256 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 257 status values MUST NOT be combined with each other. 259 Other status combinations not expressly prohibited MAY be used. 261 2.4. Dates and Times 263 Date and time attribute values MUST be represented in Universal 264 Coordinated Time (UTC) using the Gregorian calendar. The extended 265 date-time form using upper case "T" and "Z" characters defined in 266 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 267 values, as XML Schema does not support truncated date-time forms or 268 lower case "T" and "Z" characters. 270 2.5. IP Addresses 272 The syntax for IPv4 addresses described in this document MUST 273 conform To[RFC5730]. The syntax for IPv6 addresses described in 274 this document MUST conform to [RFC4291]. Practical considerations 275 for publishing IPv6 address information in zone files are documented 276 in [RFC2874] and [RFC3596]. A server MAY reject IP addresses that 277 have not been allocated for public use by IANA. 279 3. EPP Command Mapping 281 A detailed description of the EPP syntax and semantics is specified 282 in [RFC5730]. The command mappings described here are specifically 283 for use in provisioning and managing Industrial Internet identifiers 284 via EPP. 286 3.1. EPP Query Commands 288 EPP provides two commands to retrieve object information: to 289 determine if an EPP object can be provisioned within a repository, 290 and to retrieve detailed information associated with an EPP 291 object. 293 3.1.1. EPP Command 295 The EPP command is used to determine if an object can be 296 provisioned within a repository. It provides a hint that allows a 297 client to anticipate the success or failure of provisioning an 298 object using the command, as object-provisioning 299 requirements are ultimately a matter of server policy. 301 In addition to the standard EPP command elements, the 302 command MUST contain an element that recognizes 303 the identifier namespace. The element contains 304 the following child elements: 306 o One or more elements that contain the fully 307 qualified names of the identifier objects to be queried. 309 example command: 311 C: 312 C: 315 C: 316 C: 317 C: 320 C: 88.1000.1 321 C: 88.1000.2 322 C: 323 C: 324 C: ABC-12345 325 C: 326 C: 328 When a command has been processed successfully, a server 329 MUST respond with an EPP element that MUST contain a child 330 element that identifies the identifier object namespace. The child 331 elements of the element are identifier-specific, though 332 the EPP element MUST contain a child 333 element that contains one or more (check data) 334 elements. Each element contains the following child 335 elements: 337 o An identifier-specific element that identifies the queried 338 identifier. 340 This element MUST contain an "avail" attribute whose value 341 indicates object availability (can it be provisioned or not) at 342 the moment the command was completed. A value of "1" or 343 "true" means that the identifier can be provisioned. A value of "0" 344 or "false" means that the identifier cannot be provisioned. 346 o An element that is provided when an 347 identifier cannot be provisioned. This element contains server- 348 specific text to help explain why the identifier cannot be 349 provisioned. This text MUST be represented in the response 350 language previously negotiated with the client; an OPTIONAL "lang" 351 attribute MAY be present to identify the language if the 352 negotiated value is something other than the default value of "en" 353 (English). 355 Example response: 357 S: 358 S: 359 S: 360 S: 361 S: Command completed successfully 362 S: 363 S: 364 S: 366 S: 367 S: 88.1000.1 368 S: 369 S: The identifier already exists 370 S: 371 S: 372 S: 373 S: 88.1000.1 374 S: 375 S: 376 S: 377 S: 378 S: 379 S: ABC-12345 380 S: 54321-XYZ 381 S: 382 S: 383 S: 385 An EPP error response MUST be returned if a command cannotbe 386 processed for any reason. 388 3.1.2. EPP Command 390 The EPP command is used to retrieve information associated 391 with an Industrial Internet Identifier object. In addition to the 392 standard EPP command elements, the command MUST contain an 393 element that identifies the identifier namespace. 394 The element contains one child element: 396 An element that contains the fully qualified name 397 of the identifier object for which information is requested. 399 Example command: 401 C: 402 C: 405 C: 406 C: 407 C: 410 C: 88.1000.1 411 C: 412 C: 413 C: ABC-12345 414 C: 415 C: 417 When an command has been processed successfully, the EPP 418 element MUST contain a child element 419 that identifies the identifier namespace. The 420 element contains the following child elements: 422 o An element that contains the fully qualified 423 name of the identifier object to be created. The identifier name 424 with a minimum length of 1 byte and a maximum length of 255 bytes 425 SHOULD be unique and SHOULD NOT be reused. 427 o An element that specifies type of identification 428 technique of the identifier object. Handle is taken as an example 429 in this document. 431 o Zero or more OPTIONAL elements that contain 432 contact information of the enterprise that applies for the 433 identifier to be queried. 435 o Zero or more OPTIONAL elements that contain the 436 URL associated with the identifier object to be queried. 438 o An element that contains one or more 439 elements that specify administrator 440 information of the identifier object. Identifier administrators 441 are entitled to create identifier or sub-naming authorities under 442 the handle prefix according to the permission defined by its 443 sub-element. 445 Each element includes the following 446 child elements: 448 An element that provides the reference to 449 the authentication key that can be used to authenticate the 450 administrator. 452 An element that contains the authentication 453 key of the administrator and information of the type of the 454 technique used to authenticate administrator. The public key is 455 processed with base64 encoding schemes. 457 Three types of algorithms are recommended to authenticate the 458 identifier administrator: Digital Signature Algorithm (DSA) 459 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 460 cryptography, or the password-based authentication mechanism. 462 The Digital Signature Algorithm (DSA) is a typical kind of 463 cryptographic algorithm to generate pairs of keys used in 464 public-key system: public keys which may be stored in the 465 server, and private keys which are known only to the client. 467 The RSA is one of the first public-key cryptosystems and is another 468 kind of cryptographic algorithm used for secure data transmission. 470 The password is a word or string of characters used for user 471 authentication to prove identity of the administrator. 473 An element MAY contain zero or more 474 elements that specify information about 475 the administration authority of the administrator. A set of 476 administration functions that include adding, deleting, and 477 modifying identifier or identifier values are supported by the 478 identifier service. Before fulfilling any administration request, 479 the server must authenticate the client as the identifier 480 administrator that is authorized for the administrative operation. 482 List of all the permissions see the "Formal Syntax" section of this 483 document. 485 o An element that contains one or more 486 elements that provide information to locate 487 the site to implement provisions and resolution of the identifier. 488 In this section, the element defines a handle service site by 489 identifying the server computers that comprise the site along with 490 their service configurations (e.g., port numbers). 492 Each contains the following child elements: 493 An element that indicates the specific 494 index of a site. 496 An element that indicates handle 497 protocol version used to create the handle identifier. 499 One or more elements that contain the 500 following elements: 502 An element defines the number of servers in 503 the service site. 505 One or more elements that describe IP address of 506 the identifier service. Each element MAY 507 contain an "ip" attribute to identify the IP address format. 508 Attribute value "v4" is used to note IPv4 address format. 509 Attribute value "v6" is used to note IPv6 address format. If the 510 "ip" attribute is not specified,"v4" is the default attribute 511 value. 513 An element that contains the server's public 514 key with a "type" attribute that specifies algorithms used to 515 generate the public key. Public key in the 516 can be used to authenticate any service 517 response from the handle server. 519 One or more elements that have 520 three child elements: an element that 521 indicates whether the service is for query or for administration, 522 an element that specifies transmission 523 protocol, where UDP and HTTP could be considered as alternative 524 protocols, and the element that represents 525 service port of specific the service component. 527 Example response: 529 S: 530 S: 531 S: 532 S: 533 S: Command completed successfully 534 S: 535 S: 536 S: 538 S: 88.1000.1 539 S: handle 540 S: 541 S: jd1234 542 S: www.caict.ac.cn 543 S: 544 S: 545 S: 100 546 S: 547 S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 548 S: wYFTfB05hhLDC1... 549 S: 550 S: add_handle 551 S: 552 S: delete_handle 553 S: 554 S: add_value 555 S: 556 S: modify_admin 557 S: 558 S: remove_admin 559 S: 560 S: 561 S: 562 S: 563 S: 564 S: 565 S: 500 566 S: 2.10 567 S: 568 S: 569 S: 1 570 S: 192.0.2.2 571 S: 572 S: 1080:0:0:0:8:800:200C:417A 573 S: 574 S: 575 S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03QfwY 576 S: FTfB05hhLDC1... 577 S: 578 S: query 579 S: 580 S: tcp 581 S: 2641 582 S: 583 S: 584 S: 585 S: 586 S: 587 S: 588 S: 589 S: ABC-12345 590 S: 54322-XYZ 591 S: 592 S: 593 S: 594 An EPP error response MUST be returned if an command cannot 595 be processed for any reason. 597 3.1.3. EPP Query Command 599 Transfer semantics do not directly apply to identifier objects, so 600 there is no mapping defined for the EPP query command. 602 3.2. EPP Transform Commands 604 EPP provides three commands to transform identifier objects: 605 to create an instance of an identifier object, to 606 delete an instance of an identifier object, and to change 607 information associated with an identifier object. This document 608 does not define identifier-object mappings for the EPP and 609 commands. 611 Transform commands are typically processed and completed in real 612 time. Server operators MAY receive and process transform commands 613 but defer completing the requested action if human or third-party 614 review is required before the requested action can be completed. In 615 such situations, the server MUST return a 1001 response code to the 616 client to note that the command has been received and processed but 617 that the requested action is pending. The server MUST also manage 618 the status of the object that is the subject of the command to 619 reflect the initiation and completion of the requested action. Once 620 the action has been completed; all clients involved in the 621 transaction MUST be notified using a service message that the action 622 has been completed and that the status of the object has changed. 624 Other notification methods MAY be used in addition to the required 625 service message. 627 Server operators SHOULD confirm that a client is authorized to 628 perform a transform command on a given object. Any attempt to 629 transform an object by an unauthorized client MUST be rejected, and 630 the server MUST return a 2201 response code to the client to note 631 that the client lacks privileges to execute the requested command. 633 3.2.1. EPP Command 635 The EPP command provides an operation that allows a client 636 to create an identifier object. In addition to the standard EPP 637 command elements, the command MUST contain an element that identifies the identifier to be created. The 639 element contains the following child elements: 641 o An element that contains the fully qualified 642 name of the identifier object to be created. The identifier name 643 with a minimum length of 1 byte and a maximum length of 255 bytes 644 SHOULD be unique and SHOULD NOT be reused. 646 o An element that specifies type of identification 647 technique of the identifier object. Handle is taken as an example 648 in this document. 650 o Zero or more OPTIONAL elements that contain 651 contact information of the enterprise that applies for the 652 identifier to be created. 654 o Zero or more OPTIONAL elements that contain the 655 URL associated with the identifier object to be created. 657 o An element that contains one or 658 more elements that specify 659 administrator information of the identifier object. Identifier 660 administrators are entitled to administrate or resolve identifier 661 or identifier values according to the permission defined by its 662 sub-element. 664 Each element includes the following 665 child elements: 667 An element that provides the reference to 668 the authentication key that can be used to authenticate the 669 administrator. 671 An element that contains the authentication 672 key of the administrator and information of the type of the 673 technique used to authenticate administrator. The public key is 674 processed with base64 encoding schemes. 676 Three types of algorithms are recommended to authenticate the 677 identifier administrator: Digital Signature Algorithm (DSA) 678 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 679 cryptography, or the password-based authentication mechanism. 681 The Digital Signature Algorithm (DSA) is a typical kind of 682 cryptographic algorithm to generate pairs of keys used in public- 683 key system: public keys which may be stored in the server, and 684 private keys which are known only to the client. 686 The RSA is one of the first public-key cryptosystems and is 687 another kind of cryptographic algorithm used for secure data 688 transmission. 690 The password is a word or string of characters used for user 691 authentication to prove identity of the administrator. 693 An element MAY contain zero or more 694 elements that specify information about 695 the administration authority of the administrator. A set of 696 administration functions that include adding, deleting, and 697 modifying identifier or identifier values are supported by the 698 identifier service. Before fulfilling any administration request, 699 the server must authenticate the client as the identifier 700 administrator that is authorized for the administrative operation. 702 List of all the permissions see the "Formal Syntax" section of 703 this document. 705 o An element that contains one or more 706 elements that provide information to locate 708 the site to implement provisions and resolution of the identifier. 709 In this section, the element defines a handle service site by 710 identifying the server computers that comprise the site along with 711 their service configurations (e.g., port numbers). 713 Each contains the following child elements: 714 An element that indicates the specific 715 index of a site. 717 An element that indicates handle 718 protocol version used to create the handle identifier. 720 One or more elements that contain the 721 following elements: 723 An element defines the number of servers in 724 the service site. 726 One or more elements that describe IP address of 727 the identifier service. Each element MAY 728 contain an "ip" attribute to identify the IP address format. 730 Attribute value "v4" is used to note IPv4 address format. 731 Attribute value "v6" is used to note IPv6 address format. If the 732 "ip" attribute is not specified,"v4" is the default attribute 733 value. 735 An element that contains the server's public 736 key with a "type" attribute that specifies algorithms used to 737 generate the public key. Public key in the 738 can be used to authenticate any service 739 response from the handle server. 741 One or more elements that have 742 three child elements: an element that 743 indicates whether the service is for query or for administration, 744 an element that specifies transmission 745 protocol, where UDP and HTTP could be considered as alternative 746 protocols, and the element that represents 747 service port of specific the service component. 749 Example command: 751 C: 752 C: 755 C: 756 C: 757 C: 761 C: 88.1000.1 762 C: handle 763 C: jd1234 764 C: www.caict.ac.cn 765 C: 766 C: 767 C: 100 768 C: 769 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4 770 C: e175lVnv03QfwYFTfB05hhLDC1... 771 C: 772 C: add_handle 773 C: 774 C: delete_handle 775 C: 776 C: add_value 777 C: 778 C: modify_admin 779 C: 780 C: remove_admin 781 C: 782 C: 783 C: 784 C: 785 C: 786 C: 787 C: 500 788 C: 2.10 789 C: 790 C: 791 C: 1 792 C: 192.0.2.2 793 C: 1080:0:0:0:8:800:200C:417A 794 C: 795 C: 796 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e 797 C: 175lVnv03QfwYFTfB05hhLDC1... 798 C: 799 C: query 800 C: 801 C: tcp 802 C: 2641 803 C: 804 C: 805 C: 806 C: 807 C: 808 C: 809 C: ABC-12345 810 C: 811 C: 812 When a command has been processed successfully, the EPP 813 element MUST contain a child element that 814 identifies the result of processing. 816 Example response: 818 S: 819 S: 820 S: 821 S: 822 S: Command completed successfully 823 S: 824 S: 825 S: ABC-12345 826 S: 54321-XYZ 827 S: 828 S: 829 S: 831 An EPP error response MUST be returned if a command cannot 832 be processed for any reason. 834 3.2.2. EPP Command 836 The EPP command provides an operation that allows a client 837 to delete an identifier object. In addition to the standard EPP 838 command elements, the command MUST contain an 839 element that specifies the identifier namespace. 840 The element contains the following child element: 842 o An element that contains the fully qualified 843 name of the identifier object to be deleted. 845 Example command: 847 C: 848 C: 851 C: 852 C: 853 C: 856 C: 88.1000.1 857 C: 858 C: 859 C: ABC-12345 860 C: 861 C: 863 When a command has been processed successfully, a server 864 MUST respond with an EPP response with no element. 866 Example response 868 870 S: 871 S: 872 S: 873 S: 874 S: Command completed successfully 875 S: 876 S: 877 S: ABC-12345 878 S: 54321-XYZ 879 S: 880 S: 881 S: 883 An EPP error response MUST be returned if a command cannot 884 be processed for any reason. 886 3.2.3. EPP Command 888 Renewal semantics do not apply to identifier objects, so there is no 889 identifier mapping defined for the EPP command. 891 3.2.4. EPP Command 893 Transfer semantics do not directly apply to identifier objects, so 894 there is no mapping defined for the EPP command. 896 3.2.5. EPP Command 898 The EPP command provides an operation that allows a client 899 to modify the attributes of an identifier. In addition to the 900 standard EPP command elements, the command MUST contain an 901 element that identifies the identifier object 902 and attributes to be updated. The element 903 contains the following child elements: 905 o An element that contains the fully qualified 906 name of the identifier object to be updated. 908 o An OPTIONAL element that contains attribute 909 values to be added to the identifier object. 911 o An OPTIONAL element that contains attribute 912 values to be removed from the object. It has the following child 913 elements: An OPTIONAL element that contains 914 contact information that is to be removed from the identifier. 916 An optional element that contains the URL to be 917 removed. An OPTIONAL element that 918 specifies the index of the identifier administrator to be deleted. 919 An OPTIONAL element that contains 920 information about index of the site to be removed from the 921 identifier object. At least one child element of MUST be provided 922 if the element is present. 924 o An OPTIONAL element that contains object 925 attribute values to be changed. The name of an identifier MUST NOT 926 be changed, due to impacts on associated identifier objects. 928 At least one , , or 929 element MUST be provided if the command is not being extended. All 930 of these elements MAY be omitted if an extension is 931 present. The and elements share 932 two common child elements: and the 933 element. 935 The element has two additional child elements: 936 and other than the common 937 element. 939 Whereas the has an additional 940 element that specifies status of the identifier object. Description 941 of the common child elements of and 942 goes as follows: 944 - An element that specifies 945 administrator information of the identifier object. Identifier 946 administrators are entitled to administrate or resolve 947 identifier or identifier values according to the permission 948 defined by its sub-element. An 949 element includes the following 951 child elements: 953 An element that provides the reference 954 to the authentication key that can be used to authenticate the 955 administrator. 957 An element that contains the authentication 958 key of the administrator and information of the type of the 959 technique used to authenticate administrator. The public key is 960 processed with base64 encoding schemes. 962 Three types of algorithms are recommended to authenticate the 963 identifier administrator: Digital Signature Algorithm (DSA) 964 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 965 cryptography, or the password-based authentication mechanism. 967 An element MAY contain zero or more 968 elements that specify information about 969 the administration authority of the administrator. A set of 970 administration functions that include adding, deleting, and 971 modifying identifier or identifier values are supported by the 972 identifier service. Before fulfilling any administration 973 request, the server must authenticate the client as the 974 identifier administrator that is authorized for the 975 administrative operation. 977 Lists of all the permissions see the "Formal Syntax" section of 978 this document. 980 - An element that provides information to 981 locate the site to implement provisions and resolution of the 982 identifier.The element defines a handle 983 service site by identifying the server computers that comprise 984 the site along with their service configurations (e.g., port 985 numbers).It contains the following child elements: 987 An element that indicates the specific 988 index of a site that is added or modified. 990 An element that indicates handle 991 protocol version used to create the handle identifier. 993 One or more elements that contain the 994 following elements: An element defines the 995 number of servers in the service site. One or more 996 elements that describe IP address of the 997 identifier service. Each element MAY contain 998 an "ip" attribute to identify the IP address format. Attribute 999 value "v4" is used to note IPv4 address format. Attribute value 1000 "v6" is used to note IPv6 address format. If the "ip" attribute 1001 is not specified,"v4" is the default attribute value. An 1002 element that contains the server's public key 1003 with a "type" attribute that specifies algorithms used to 1004 generate the public key. Public key in the 1005 can be used to authenticate any service 1006 response from the handle server. One or more 1007 elements that have three child 1008 elements: an element that indicates 1009 whether the service is for query or for administration, an 1010 element that specifies transmission 1011 protocol, where UDP and HTTP could be considered as alternative 1012 protocols, and the element that represents 1013 service port of specific the service component. 1015 Example command: 1017 C: 1018 C: 1021 C: 1022 C: 1023 C: 1027 C: 88.1000.1 1028 C: 1029 C: jd12345 1030 C: www.abc.com 1031 C: 1032 C: 101 1033 C: 1034 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 1035 C: wYFTfB05hhLDC1... 1036 C: 1037 C: add_handle 1038 C: 1039 C: delete_handle 1040 C: 1041 C: add_value 1042 C: 1043 C: modify_admin 1044 C: 1045 C: remove_admin 1046 C: 1047 C: 1048 C: 1049 C: 1050 C: 501 1051 C: 2.10 1052 C: 1053 C: 1054 C: 1 1055 C: 192.0.2.2 1056 C: 1080:0:0:0:8:800:200C:417A 1057 C: 1058 C: 1059 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e 1060 C: 175lVnv03QfwYFTfB05hhLDC1... 1061 C: 1062 C: admin 1063 C: 1064 C: tcp 1065 C: 2641 1066 C: 1067 C: 1068 C: 1069 C: 1070 C: 1071 C: jd12345 1072 C: www.abc.com 1073 C: 101 1074 C: 500 1075 C: 1076 C: 1077 C: 1078 C: 1079 C: 102 1080 C: 1081 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 1082 C: wYFTfB05hhLDC1... 1083 C: 1084 C: add_handle 1085 C: 1086 C: delete_handle 1087 C: 1088 C: add_value 1089 C: 1090 C: 1091 C: 1092 C: 1093 C: 500 1094 C: 2.10 1095 C: 1096 C: 1097 C: 2 1098 C: 192.0.2.2 1099 C: 1080:0:0:0:8:800:200C:417A 1100 C: 1101 C: 1102 C: query 1103 C: 1104 C: tcp 1105 C: 2641 1106 C: 1107 C: 1108 C: 1109 C: 1110 C: 1111 C: 1112 C: ABC-12345 1113 C: 1114 C: 1116 When an command has been processed successfully, a server 1117 MUST respond with an EPP response with no element. 1119 Example response: 1121 S: 1122 S: 1123 S: 1124 S: 1125 S: Command completed successfully 1126 S: 1127 S: 1128 S: ABC-12345 1129 S: 54321-XYZ 1130 S: 1131 S: 1132 S: 1134 An EPP error response MUST be returned if an command could 1135 not be processed for any reason. 1137 4. Formal Syntax 1139 An EPP object mapping is specified in XML Schema notation. The 1140 formal syntax presented here is a complete schema representation of 1141 the object mapping suitable for automated validation of EPP XML 1142 instances. The BEGIN and END tags are not part of the schema; they 1143 are used to note the beginning and ending of the schema for URI 1144 registration purposes. 1146 Redistribution and use in source and binary forms, with or without 1147 modification, are permitted provided that the following conditions 1148 are met: 1150 o Redistributions of source code must retain the above copyright 1151 notice, this list of conditions and the following disclaimer. 1153 o Redistributions in binary form must reproduce the above copyright 1154 notice, this list of conditions and the following disclaimer in 1155 the documentation and/or other materials provided with the 1156 distribution. 1158 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1159 names of specific contributors, may be used to endorse or promote 1160 products derived from this software without specific prior written 1161 permission. 1163 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 1164 CONTRIBUTORS"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 1165 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 1166 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 1167 IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 1168 ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR 1169 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 1170 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,DATA, OR PROFITS; OR 1171 BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 1172 LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 1173 NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 1174 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1176 BEGIN 1178 1180 1186 1189 1191 1193 1194 Extensible Provisioning Protocol v1.0 1195 identifier provisioning schema. 1196 1197 1200 1201 1202 1203 1204 1205 1208 1209 1210 1211 1212 1214 1215 1217 1219 1220 1221 1224 1225 1226 1227 1228 1229 1232 1233 1234 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1267 1268 1269 1270 1271 1272 1273 1275 1276 1277 1278 1279 1280 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1296 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1319 1320 1321 1322 1323 1324 1325 1327 1328 1329 1330 1331 1332 1334 1336 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1396 1398 1401 1403 1405 1407 1408 1409 1410 1411 1413 1415 1417 1419 1420 1421 1422 1423 1425 1428 1430 1432 1434 1435 1436 1441 1442 1443 1444 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1474 1475 1476 1480 1481 1482 1484 1485 1486 1487 1488 1489 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1507 1508 1510 1512 1513 1514 1517 1518 END 1519 5. Internationalization Considerations 1521 EPP is represented in XML, which provides native support for 1522 encoding information using the Unicode character set and its more 1523 compact representations including UTF-8. Conformant XML processors 1524 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 1525 provisions to identify and use other character encodings through use 1526 of an "encoding" attribute in an declaration, use of UTF-8 1527 is RECOMMENDED in environments where parser encoding support 1528 incompatibility exists. 1530 All date-time values presented via EPP MUST be expressed in 1531 Universal Coordinated Time using the Gregorian calendar. XML Schema 1532 allows use of time zone identifiers to indicate offsets from the 1533 zero meridian, but this option MUST NOT be used with EPP. The 1534 extended date-time form using upper case "T" and "Z" characters 1535 defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent 1536 date-time values, as XML Schema does not support truncated date-time 1537 forms or lower case "T" and "Z" characters. 1539 The syntax for handle identifiers described in this document MUST 1540 conform to [RFC3650], [RFC3651], [RFC3652]. The conformance 1541 requirements might change as a result of progressing work in 1542 developing standards for internationalized identifier techniques. 1544 6. Security Considerations 1546 Authorization information as described in Section 3.2 is REQUIRED to 1547 create an identifier object. This information is used in some query 1548 and transfer operations as an additional means of determining client 1549 authorization to perform the command. Failure to protect 1550 authorization information from inadvertent disclosure can result in 1551 unauthorized transfer operations and unauthorized information 1552 release. Both client and server MUST ensure that authorization 1553 information is stored and exchanged with high-grade encryption 1554 mechanisms to provide privacy services. 1556 The object mapping described in this document does not provide any 1557 other security services or introduce any additional considerations 1558 beyond those described by [RFC5730] or those caused by the protocol 1559 layers used by EPP. 1561 7. IANA Considerations 1563 This document uses URNs to describe XML namespaces and XML schemas 1564 conforming to a registry mechanism described in [RFC3688]. Two URI 1565 assignments have been registered by the IANA. 1567 Registration request for the identifier namespace: 1569 URI: urn:ietf:params:xml:ns:identifier-1.0 1571 Registrant Contact: See the "Author's Address" section of this 1572 document. 1574 XML: None. Namespace URIs do not represent an XML specification. 1576 Registration request for the identifier XML schema: 1578 URI: urn:ietf:params:xml:schema:identifier-1.0 1580 Registrant Contact: See the "Author's Address" section of this 1581 document. 1583 XML: See the "Formal Syntax" section of this document. 1585 8. Acknowledgments 1587 This document is based on an identifier application of EPP.Thus, the 1588 author would like to thank J. Xie who suggested improvements and 1589 provided many invaluable comments. This document are individual 1590 submissions, based on the work done in RFC 5730. 1591 This document was prepared using 2-Word-v2.0.template.dot. 1593 9. References 1595 9.1. Normative References 1597 [W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, 1598 F., Paoli, J., and T. Bray, "Extensible Markup Language 1599 (XML) 1.0 (Third Edition)", World Wide Web Consortium 1600 FirstEdition REC-xml-20040204, February 2004, 1601 . 1603 [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., 1604 Mendelsohn, N., and D. Beech, "XML Schema Part 1: 1605 Structures Second Edition", World Wide Web Consortium 1606 Recommendation REC-xmlschema-1-20041028, October 2004, 1607 . 1609 [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML 1610 Schema Part 2: Datatypes Second Edition", World Wide Web 1611 Consortium Recommendation REC-xmlschema-2-20041028, 1612 October 2004, . [RFC0791] Postel, J., "Internet Protocol", 1614 STD 5, RFC 791, September 1981. 1616 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1617 STD 69, RFC 5730, August 2009. 1619 [RFC3650] Sun, S. and L. Lannom, "Handle System Overview", November 1620 2003. 1622 [RFC3651] Sun, S., Reilly, S. and L. Lannom, "Handle System 1623 Namespace and Service Definition", November 2003. 1625 [RFC3652] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol 1626 (ver 2.1) Specification", November 2003. 1628 9.2. Informative References 1630 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1631 10646", RFC 2781, February 2000. 1633 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 1634 IPv6 Address Aggregation and Renumbering", RFC 2874, July 1635 2000. 1637 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1638 "DNS Extensions to Support IP Version 6", RFC 3596, 1639 October 2003. 1641 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1642 Architecture", RFC 4291, February 2006. 1644 Author's Address 1646 Yuying Chen 1647 CAICT 1648 No.52 Huayuan North Road, Haidian District 1649 Beijing, Beijing, 100191 1650 China 1652 Phone: +86 188 1008 2358 1653 Email: chenyuying@caict.ac.cn 1655 Jiagui Xie 1656 CAICT 1657 No.52 Huayuan North Road, Haidian District 1658 Beijing, Beijing, 100191 1659 China 1661 Phone: +86 150 0138 5070 1662 Email: xiejiagui@caict.ac.cn 1664 Zhiping Li 1665 CAICT 1666 No.52 Huayuan North Road, Haidian District 1667 Beijing, Beijing, 100191 1668 China 1670 Phone: +86 185 1107 1386 1671 Email: lizhiping@caict.ac.cn 1673 Zhipeng Fan 1674 CAICT 1675 No.52 Huayuan North Road, Haidian District 1676 Beijing, Beijing, 100191 1677 China 1679 Phone: +86 159 1112 3285 1680 Email: fanzhipeng@caict.ac.cn