idnits 2.17.1 draft-chen-epp-identifier-mapping-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 are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 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 109: '...in this document MUST be interpreted i...' RFC 2119 keyword, line 122: '...ps and are not a REQUIRED feature of t...' RFC 2119 keyword, line 149: '...espace described in this document MUST...' RFC 2119 keyword, line 157: '... MAY also apply to handle identifier...' RFC 2119 keyword, line 170: '...dentifier object MUST always have at l...' (79 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 479 has weird spacing: '...version used ...' == Line 966 has weird spacing: '...version used ...' -- The document date (August 5, 2019) is 1723 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 118, but not defined == Missing Reference: 'RFC3688' is mentioned on line 1534, but not defined == Unused Reference: 'RFC0791' is defined on line 1583, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 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: February 5, 2020 Z. Fan 5 China Academy of Information and Communications Technology 6 August 5, 2019 8 Extensible Provisioning Protocol (EPP) Industrial Internet 9 Identifier Mapping 10 draft-chen-epp-identifier-mapping-00 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 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 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 February 5, 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 respect 52 to this document. 54 Code Components extracted from this document must include Simplified 55 BSD License text as described in Section 4.e of the Trust Legal 56 Provisions and are provided without warranty as described in the 57 Simplified BSD License. 59 Table of Contents 61 1. Introduction ....................................................3 62 1.1. Conventions Used in This Document ..........................4 63 2. Object Attributes ...............................................4 64 2.1. Industrial Internet Identifier Object ......................4 65 2.2. Client Identifiers..........................................5 66 2.3. Status Values ..............................................5 67 2.4. Dates and Times.............................................6 68 2.5. IP Addresses ...............................................7 69 3. EPP Command Mapping .............................................7 70 3.1. EPP Query Commands..........................................7 71 3.1.1. EPP Command....................................7 72 3.1.2. EPP Command.....................................9 73 3.1.3. EPP Query Command .........................13 74 3.2. EPP Transform Commands.....................................13 75 3.2.1. EPP Command..................................14 76 3.2.2. EPP Command..................................18 77 3.2.3. EPP Command...................................19 78 3.2.4. EPP Command................................19 79 3.2.5. EPP Command..................................20 80 4. Formal Syntax ..................................................25 81 5. Internationalization Considerations ............................33 82 6. Security Considerations.........................................33 83 7. IANA Considerations ............................................34 84 8. Acknowledgments ................................................34 85 9. References .....................................................34 86 9.1. Normative References.......................................34 87 9.2. Informative References.....................................35 89 1. Introduction 91 Industrial Internet Identifiers are character strings with a 92 specified format that may consist of digits, letters or notations 93 being structured in a way that is interpretable by one or more 94 computational facilities. 96 This document describes an Industrial Internet Identifier mapping for 97 version 1.0 of the Extensible Provisioning Protocol (EPP). This 98 mapping is specified using the Extensible Markup Language (XML)1.0 as 99 described in [W3C.REC-xml-20040204] and XML Schema notation as 100 described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2- 101 20041028]. 103 [RFC5730]provides a complete description of EPP command and response 104 structures. A thorough understanding of the base protocol 105 specification is necessary to understand the mapping described in 106 this document. 108 XML is case sensitive. Unless stated otherwise, XML specifications 109 and examples provided in this document MUST be interpreted in the 110 character case presented to develop a conforming implementation. 112 1.1. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 115 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 116 this document are to be interpreted as described in RFC 2119 117 [RFC2119]. 119 In examples, "C:" represents lines sent by a protocol client and "S:" 120 represents lines returned by a protocol server. Indentation and 121 white space in examples are provided only to illustrate element 122 relationships and are not a REQUIRED feature of this protocol. 124 2. Object Attributes 126 An EPP identifier object has attributes and associated values that 127 can be viewed and modified by the sponsoring client or the server. 128 This section describes each attribute type in detail. The formal 129 syntax for the attribute values described here can be found in the 130 "Formal Syntax" section of this document and in the appropriate 131 normative references. 133 2.1. Industrial Internet Identifier Object 135 Industrial Internet Identifiers are character strings with a 136 specified format that may consist of digits, letters or notations 137 being structured in a way that is interpretable by one or more 138 computational facilities. 140 It is an unique persistent set of bits used to identify and obtain 141 state information about physical resource such as machines, products, 142 or digital resources such as algorithms, manufacturing process, etc. 144 This document provides an overview of the EPP mapping of Industrial 145 Internet Identification. Handle mapping is specified as an example, 146 while description in this document applies to other identification 147 techniques as well. 149 The syntax for handle namespace described in this document MUST 150 conform to [RFC3650], [RFC3651], [RFC3652]. Handle identifiers are 151 character strings with a specified length and a specified format. 153 All handle identifiers are of the form prefix/suffix where, by 154 default, the prefix may first be resolved to locate the specific 155 identifier service and the suffix may be any bit sequence. Epp 156 mapping on the prefix examples are provided in this document while it 157 MAY also apply to handle identifiers with suffix. 159 These conformance requirements might change in the future as a result 160 of progressing work in developing standards for internationalized 161 digital object identification. 163 2.2. Client Identifiers 165 All EPP clients are identified by a server-unique identifier. Client 166 identifiers conform to the "clIDType" syntax described in [RFC5730]. 168 2.3. Status Values 170 An EPP identifier object MUST always have at least one associated 171 status value. Status values MAY be set only by the client that 172 sponsors an identifier object and by the server on which the object 173 resides. A client can change the status of object using the EPP 174 command. Each status value MAY be accompanied by a string 175 of human-readable text that describes the rationale for the status 176 applied to the object. 178 A client MUST NOT alter status values set by the server. A server 179 MAY alter or override status values set by a client, subject to local 180 server policies. The status of an object MAY change as a result of 181 either a client-initiated transform command or an action performed by 182 a server operator. 184 Status values that can be added or removed by a client are prefixed 185 with "client". Corresponding status values that can be added or 186 removed by a server are prefixed with "server". Status values that 187 do not begin with either "client" or "server" are server-managed. 189 Status Value Descriptions: 191 - clientDeleteProhibited, serverDeleteProhibited 193 Requests to delete the object MUST be rejected. 195 - clientUpdateProhibited, serverUpdateProhibited 197 Requests to update the object (other than to remove this status) 198 MUST be rejected. 200 - linked 202 The identifier object has at least one active association with 203 another object. Servers SHOULD provide services to determine existing 204 object associations. 206 - ok 208 This is the normal status value for an object that has no pending 209 operations or prohibitions. This value is set and removed by the 210 server as other status values are added or removed. 212 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 214 A transform command has been processed for the object, but the 215 action has not been completed by the server. Server operators can 216 delay action completion for a variety of reasons, such as to allow 217 for human review or third-party action. A transform command that is 218 processed, but whose requested action is pending, is noted with 219 response code 1001. 221 When the requested action has been completed, the pendingCreate, 222 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 223 removed. All clients involved in the transaction MUST be notified 224 using a service message that the action has been completed and that 225 the status of the object has changed. 227 "ok" status MAY only be combined with "linked" status. 229 "linked" status MAY be combined with any status. 231 "pendingDelete" status MUST NOT be combined with either 232 "clientDeleteProhibited" or "serverDeleteProhibited" status. 234 "pendingUpdate" status MUST NOT be combined with either 235 "clientUpdateProhibited" or "serverUpdateProhibited" status. 237 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 238 status values MUST NOT be combined with each other. 240 Other status combinations not expressly prohibited MAY be used. 242 2.4. Dates and Times 244 Date and time attribute values MUST be represented in Universal 245 Coordinated Time (UTC) using the Gregorian calendar. The extended 246 date-time form using upper case "T" and "Z" characters defined in 247 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 248 values, as XML Schema does not support truncated date-time forms or 249 lower case "T" and "Z" characters. 251 2.5. IP Addresses 253 The syntax for IPv4 addresses described in this document MUST conform 254 to[RFC5730]. The syntax for IPv6 addresses described in this 255 document MUST conform to [RFC4291]. Practical considerations for 256 publishing IPv6 address information in zone files are documented in 257 [RFC2874] and [RFC3596]. A server MAY reject IP addresses that have 258 not been allocated for public use by IANA. 260 3. EPP Command Mapping 262 A detailed description of the EPP syntax and semantics is specified 263 in [RFC5730]. The command mappings described here are specifically 264 for use in provisioning and managing Industrial Internet identifiers 265 via EPP. 267 3.1. EPP Query Commands 269 EPP provides two commands to retrieve object information: to 270 determine if an EPP object can be provisioned within a repository, 271 and to retrieve detailed information associated with an EPP 272 object. 274 3.1.1. EPP Command 276 The EPP command is used to determine if an object can be 277 provisioned within a repository. It provides a hint that allows a 278 client to anticipate the success or failure of provisioning an object 279 using the command, as object-provisioning requirements are 280 ultimately a matter of server policy. 282 In addition to the standard EPP command elements, the command 283 MUST contain an element that recognizes the 284 identifier namespace. The element contains the 285 following child elements: 287 o One or more elements that contain the fully 288 qualified names of the identifier objects to be queried. 290 example command: 292 C: 293 C: 296 C: 297 C: 298 C: 302 C: 88.1000.1 303 C: 88.1000.2 304 C: 305 C: 306 C: ABC-12345 307 C: 308 C: 310 When a command has been processed successfully, a server MUST 311 respond with an EPP element that MUST contain a child 312 element that identifies the identifier object namespace. The child 313 elements of the element are identifier-specific, though the 314 EPP element MUST contain a child 315 element that contains one or more (check data) 316 elements. Each element contains the following child 317 elements: 319 o An identifier-specific element that identifies the queried 320 identifier. 322 This element MUST contain an "avail" attribute whose value 323 indicates object availability (can it be provisioned or not) at 324 the moment the command was completed. A value of "1" or 325 "true" means that the identifier can be provisioned. A value of "0" 326 or "false" means that the identifier cannot be provisioned. 328 o An element that is provided when an 329 identifier cannot be provisioned. This element contains server- 330 specific text to help explain why the identifier cannot be 331 provisioned. This text MUST be represented in the response 332 language previously negotiated with the client; an OPTIONAL "lang" 333 attribute MAY be present to identify the language if the 334 negotiated value is something other than the default value of "en" 335 (English). 337 Example response: 339 S: 340 S: 341 S: 342 S: 343 S: Command completed successfully 344 S: 345 S: 346 S: 348 S: 349 S: 88.1000.1 350 S: 351 S: The identifier already exists 352 S: 353 S: 354 S: 355 S: 88.1000.1 356 S: 357 S: 358 S: 359 S: 360 S: 361 S: ABC-12345 362 S: 54321-XYZ 363 S: 364 S: 365 S: 367 An EPP error response MUST be returned if a command cannotbe 368 processed for any reason. 370 3.1.2. EPP Command 372 The EPP command is used to retrieve information associated 373 with an Industrial Internet Identifier object. In addition to the 374 standard EPP command elements, the command MUST contain an 375 element that identifies the identifier namespace. 376 The element contains one child element: 378 An element that contains the fully qualified name 379 of the identifier object for which information is requested. 381 Example command: 383 C: 384 C: 387 C: 388 C: 389 C: 392 C: 88.1000.1 393 C: 394 C: 395 C: ABC-12345 396 C: 397 C: 399 When an command has been processed successfully, the EPP 400 element MUST contain a child element 401 that identifies the identifier namespace. The 402 element contains the following child elements: 404 o An element that contains the fully qualified 405 name of the identifier object to be created. The identifier name 406 with a minimum length of 1 byte and a maximum length of 255 bytes 407 SHOULD be unique and SHOULD NOT be reused. 409 o An element that specifies type of identification 410 technique of the identifier object. Handle is taken as an example 411 in this document. 413 o Zero or more OPTIONAL elements that contain 414 contact information of the enterprise that applies for the 415 identifier to be queried. 417 o Zero or more OPTIONAL elements that contain the 418 URL associated with the identifier object to be queried. 420 o An element that contains one or more 421 elements that specify administrator 422 information of the identifier object. Identifier administrators 423 are entitled to create identifier or sub-naming authorities under 424 the handle prefix according to the permission defined by its 425 sub-element. 427 Each element includes the following 428 child elements: 430 An element that provides the reference to 431 the authentication key that can be used to authenticate the 432 administrator. 434 An element that contains the authentication 435 key of the administrator and information of the type of the 436 technique used to authenticate administrator. The public key is 437 processed with base64 encoding schemes. 439 Three types of algorithms are recommended to authenticate the 440 identifier administrator: Digital Signature Algorithm (DSA) 441 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 442 cryptography, or the password-based authentication mechanism. 444 The Digital Signature Algorithm (DSA) is a typical kind of 445 cryptographic algorithm to generate pairs of keys used in 446 public-key system: public keys which may be stored in the 447 server, and private keys which are known only to the client. 449 The RSA is another kind of cryptographic algorithm used for secure 450 data transmission. 452 The password is a word or string of characters used for user 453 authentication to prove identity of the administrator. 455 An element MAY contain zero or more 456 elements that specify information about 457 the administration authority of the administrator. A set of 458 administration functions that include adding, deleting, and 459 modifying identifier or identifier values are supported by the 460 identifier service. Before fulfilling any administration request, 461 the server must authenticate the client as the identifier 462 administrator that is authorized for the administrative operation. 464 List of all the permissions see the "Formal Syntax" section of this 465 document. 467 o An element that contains one or more 468 elements that provide information to locate 469 the site to implement provisions and resolution of the identifier. 470 In this section, the element defines a handle service site by 471 identifying the server computers that comprise the site along with 472 their service configurations (e.g., port numbers). 474 Each contains the following child elements: 475 An element that indicates the specific 476 index of a site. 478 An element that indicates handle 479 protocol version used to create the handle identifier. 481 One or more elements that contain the 482 following elements: 484 An element defines the number of servers in 485 the service site. 487 One or more elements that describe IP address of 488 the identifier service. Each element MAY 489 contain an "ip" attribute to identify the IP address format. 490 Attribute value "v4" is used to note IPv4 address format. 491 Attribute value "v6" is used to note IPv6 address format. If the 492 "ip" attribute is not specified,"v4" is the default attribute 493 value. 495 An element that contains the server's public 496 key with a "type" attribute that specifies algorithms used to 497 generate the public key. Public key in the 498 can be used to authenticate any service 499 response from the handle server. 501 One or more elements that have 502 three child elements: an element that 503 indicates whether the service is for query or for administration, 504 an element that specifies transmission 505 protocol, where UDP and HTTP could be considered as alternative 506 protocols, and the element that represents 507 service port of specific the service component. 509 Example response: 511 S: 512 S: 513 S: 514 S: 515 S: Command completed successfully 516 S: 517 S: 518 S: 520 S: 88.1000.1 521 S: handle 522 S: 523 S: jd1234 524 S: www.caict.ac.cn 525 S: 526 S: 527 S: 100 528 S: 529 S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 530 S: wYFTfB05hhLDC1... 531 S: 532 S: add_handle 533 S: 534 S: delete_handle 535 S: 536 S: add_value 537 S: 538 S: modify_admin 539 S: 540 S: remove_admin 541 S: 542 S: 543 S: 544 S: 545 S: 546 S: 547 S: 500 548 S: 2.10 549 S: 550 S: 551 S: 1 552 S: 192.0.2.2 553 S: 554 S: 1080:0:0:0:8:800:200C:417A 555 S: 556 S: 557 S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03QfwY 558 S: FTfB05hhLDC1... 559 S: 560 S: query 561 S: 562 S: tcp 563 S: 2641 564 S: 565 S: 566 S: 567 S: 568 S: 569 S: 570 S: 571 S: ABC-12345 572 S: 54322-XYZ 573 S: 574 S: 575 S: 576 An EPP error response MUST be returned if an command cannot be 577 processed for any reason. 579 3.1.3. EPP Query Command 581 Transfer semantics do not directly apply to identifier objects, so 582 there is no mapping defined for the EPP query command. 584 3.2. EPP Transform Commands 586 EPP provides three commands to transform identifier objects: 587 to create an instance of an identifier object, to delete an 588 instance of an identifier object, and to change information 589 associated with an identifier object. This document does not define 590 identifier-object mappings for the EPP and 591 commands. 593 Transform commands are typically processed and completed in real time. 594 Server operators MAY receive and process transform commands but defer 595 completing the requested action if human or third-party review is 596 required before the requested action can be completed. In such 597 situations, the server MUST return a 1001 response code to the client 598 to note that the command has been received and processed but that the 599 requested action is pending. The server MUST also manage the status 600 of the object that is the subject of the command to reflect the 601 initiation and completion of the requested action. Once the action 602 has been completed; all clients involved in the transaction MUST be 603 notified using a service message that the action has been completed 604 and that the status of the object has changed. Other notification 605 methods MAY be used in addition to the required service message. 607 Server operators SHOULD confirm that a client is authorized to 608 perform a transform command on a given object. Any attempt to 609 transform an object by an unauthorized client MUST be rejected, and 610 the server MUST return a 2201 response code to the client to note 611 that the client lacks privileges to execute the requested command. 613 3.2.1. EPP Command 615 The EPP command provides an operation that allows a client 616 to create an identifier object. In addition to the standard EPP 617 command elements, the command MUST contain an element that identifies the identifier to be created. The 619 element contains the following child elements: 621 o An element that contains the fully qualified 622 name of the identifier object to be created. The identifier name 623 with a minimum length of 1 byte and a maximum length of 255 bytes 624 SHOULD be unique and SHOULD NOT be reused. 626 o An element that specifies type of identification 627 technique of the identifier object. Handle is taken as an example 628 in this document. 630 o Zero or more OPTIONAL elements that contain 631 contact information of the enterprise that applies for the 632 identifier to be created. 634 o Zero or more OPTIONAL elements that contain the 635 URL associated with the identifier object to be created. 637 o An element that contains one or 638 more elements that specify 639 administrator information of the identifier object. Identifier 640 administrators are entitled to administrate or resolve identifier 641 or identifier values according to the permission defined by its 642 sub-element. 644 Each element includes the following 645 child elements: 647 An element that provides the reference to 648 the authentication key that can be used to authenticate the 649 administrator. 651 An element that contains the authentication 652 key of the administrator and information of the type of the 653 technique used to authenticate administrator. The public key is 654 processed with base64 encoding schemes. 656 Three types of algorithms are recommended to authenticate the 657 identifier administrator: Digital Signature Algorithm (DSA) 658 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 659 cryptography, or the password-based authentication mechanism. 661 The Digital Signature Algorithm (DSA) is a typical kind of 662 cryptographic algorithm to generate pairs of keys used in public- 663 key system: public keys which may be stored in the server, and 664 private keys which are known only to the client. 666 The RSA is one of the first public-key cryptosystems and is 667 another kind of cryptographic algorithm used for secure data 668 transmission. 670 The password is a word or string of characters used for user 671 authentication to prove identity of the administrator. 673 An element MAY contain zero or more 674 elements that specify information about 675 the administration authority of the administrator. A set of 676 administration functions that include adding, deleting, and 677 modifying identifier or identifier values are supported by the 678 identifier service. Before fulfilling any administration request, 679 the server must authenticate the client as the identifier 680 administrator that is authorized for the administrative operation. 682 List of all the permissions see the "Formal Syntax" section of 683 this document. 685 o An element that contains one or more 686 elements that provide information to locate 687 the site to implement provisions and resolution of the identifier. 688 In this section, the element defines a handle service site by 689 identifying the server computers that comprise the site along with 690 their service configurations (e.g., port numbers). 692 Each contains the following child elements: 693 An element that indicates the specific 694 index of a site. 696 An element that indicates handle 697 protocol version used to create the handle identifier. 699 One or more elements that contain the 700 following elements: 702 An element defines the number of servers in 703 the service site. 704 One or more elements that describe IP address 705 of the identifier service. Each element MAY 706 contain an "ip" attribute to identify the IP address format. 707 Attribute value "v4" is used to note IPv4 address format. 708 Attribute value "v6" is used to note IPv6 address format. If the 709 "ip" attribute is not specified,"v4" is the default attribute 710 value. 712 An element that contains the server's public 713 key with a "type" attribute that specifies algorithms used to 714 generate the public key. Public key in the 715 can be used to authenticate any service 716 response from the handle server. 718 One or more elements that have 719 three child elements: an element that 720 indicates whether the service is for query or for administration, 721 an element that specifies transmission 722 protocol, where UDP and HTTP could be considered as alternative 723 protocols, and the element that represents 724 service port of specific the service component. 726 Example command: 728 C: 729 C: 732 C: 733 C: 734 C: 738 C: 88.1000.1 739 C: handle 740 C: jd1234 741 C: www.caict.ac.cn 742 C: 743 C: 744 C: 100 745 C: 746 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4 747 C: e175lVnv03QfwYFTfB05hhLDC1... 748 C: 749 C: add_handle 750 C: 751 C: delete_handle 752 C: 753 C: add_value 754 C: 755 C: modify_admin 756 C: 757 C: remove_admin 758 C: 759 C: 760 C: 761 C: 762 C: 763 C: 764 C: 500 765 C: 2.10 766 C: 767 C: 768 C: 1 769 C: 192.0.2.2 770 C: 1080:0:0:0:8:800:200C:417A 771 C: 772 C: 773 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e 774 C: 175lVnv03QfwYFTfB05hhLDC1... 775 C: 776 C: query 777 C: 778 C: tcp 779 C: 2641 780 C: 781 C: 782 C: 783 C: 784 C: 785 C: 786 C: ABC-12345 787 C: 788 C: 789 When a command has been processed successfully, the EPP 790 element MUST contain a child element that 791 identifies the result of processing. 793 Example response: 795 S: 796 S: 797 S: 798 S: 799 S: Command completed successfully 800 S: 801 S: 802 S: ABC-12345 803 S: 54321-XYZ 804 S: 805 S: 806 S: 808 An EPP error response MUST be returned if a command cannot 809 be processed for any reason. 811 3.2.2. EPP Command 813 The EPP command provides an operation that allows a client 814 to delete an identifier object. In addition to the standard EPP 815 command elements, the command MUST contain an 816 element that specifies the identifier namespace. 817 The element contains the following child element: 819 o An element that contains the fully qualified 820 name of the identifier object to be deleted. 822 Example command: 824 C: 825 C: 828 C: 829 C: 830 C: 833 C: 88.1000.1 834 C: 835 C: 836 C: ABC-12345 837 C: 838 C: 840 When a command has been processed successfully, a server 841 MUST respond with an EPP response with no element. 843 Example response 845 847 S: 848 S: 849 S: 850 S: 851 S: Command completed successfully 852 S: 853 S: 854 S: ABC-12345 855 S: 54321-XYZ 856 S: 857 S: 858 S: 860 An EPP error response MUST be returned if a command cannot 861 be processed for any reason. 863 3.2.3. EPP Command 865 Renewal semantics do not apply to identifier objects, so there is no 866 identifier mapping defined for the EPP command. 868 3.2.4. EPP Command 870 Transfer semantics do not directly apply to identifier objects, so 871 there is no mapping defined for the EPP command. 873 3.2.5. EPP Command 875 The EPP command provides an operation that allows a client 876 to modify the attributes of an identifier. In addition to the 877 standard EPP command elements, the command MUST contain an 878 element that identifies the identifier object and 879 attributes to be updated. The element contains 880 the following child elements: 882 o An element that contains the fully qualified 883 name of the identifier object to be updated. 885 o An OPTIONAL element that contains attribute 886 values to be added to the identifier object. 888 o An OPTIONAL element that contains attribute 889 values to be removed from the object. It has the following child 890 elements: An OPTIONAL element that contains 891 contact information that is to be removed from the identifier. 892 An optional element that contains the URL to be 893 removed. An OPTIONAL element that 894 specifies the index of the identifier administrator to be deleted. 895 An OPTIONAL element that contains 896 information about index of the site to be removed from the 897 identifier object. At least one child element of MUST be provided 898 if the element is present. 900 o An OPTIONAL element that contains object 901 attribute values to be changed. The name of an identifier MUST NOT 902 be changed, due to impacts on associated identifier objects. 904 At least one , , or 905 element MUST be provided if the command is not being extended. All 906 of these elements MAY be omitted if an extension is present. 907 The and elements share two common 908 child elements: and the 909 element. 911 The element has two additional child elements: 912 and other than the common 913 element. 915 Whereas the has an additional 916 element that specifies status of the identifier object. Description 917 of the common child elements of and 918 goes as follows: 920 - An element that specifies 921 administrator information of the identifier object. Identifier 922 administrators are entitled to administrate or resolve 923 identifier or identifier values according to the permission 924 defined by its sub-element. An 925 element includes the following 926 child elements: 928 An element that provides the reference 929 to the authentication key that can be used to authenticate the 930 administrator. 932 An element that contains the authentication 933 key of the administrator and information of the type of the 934 technique used to authenticate administrator. The public key is 935 processed with base64 encoding schemes. 937 Three types of algorithms are recommended to authenticate the 938 identifier administrator: Digital Signature Algorithm (DSA) 939 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 940 cryptography, or the password-based authentication mechanism. 942 An element MAY contain zero or more 943 elements that specify information about 944 the administration authority of the administrator. A set of 945 administration functions that include adding, deleting, and 946 modifying identifier or identifier values are supported by the 947 identifier service. Before fulfilling any administration 948 request, the server must authenticate the client as the 949 identifier administrator that is authorized for the 950 administrative operation. 952 Lists of all the permissions see the "Formal Syntax" section of 953 this document. 955 - An element that provides information to 956 locate the site to implement provisions and resolution of the 957 identifier. The element defines a handle 958 service site by identifying the server computers that comprise 959 the site along with their service configurations (e.g., port 960 numbers).It contains the following child elements: 962 An element that indicates the specific 963 index of a site that is added or modified. 965 An element that indicates handle 966 protocol version used to create the handle identifier. 968 One or more elements that contain the 969 following elements: An element defines the 970 number of servers in the service site. One or more 971 elements that describe IP address of the 972 identifier service. Each element MAY contain 973 an "ip" attribute to identify the IP address format. Attribute 974 value "v4" is used to note IPv4 address format. Attribute value 975 "v6" is used to note IPv6 address format. If the "ip" attribute 976 is not specified,"v4" is the default attribute value. An 977 element that contains the server's public key 978 with a "type" attribute that specifies algorithms used to 979 generate the public key. Public key in the 980 can be used to authenticate any service 981 response from the server. One or more 982 elements that have three child 983 elements: an element that indicates 984 whether the service is for query or for administration, an 985 element that specifies transmission 986 protocol, where UDP and HTTP could be considered as alternative 987 protocols, and the element that represents 988 service port of specific the service component. 990 Example command: 992 C: 993 C: 996 C: 997 C: 998 C: 1002 C: 88.1000.1 1003 C: 1004 C: jd12345 1005 C: www.abc.com 1006 C: 1007 C: 101 1008 C: 1009 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 1010 C: wYFTfB05hhLDC1... 1011 C: 1012 C: add_handle 1013 C: 1014 C: delete_handle 1015 C: 1016 C: add_value 1017 C: 1018 C: modify_admin 1019 C: 1020 C: remove_admin 1021 C: 1022 C: 1023 C: 1024 C: 1025 C: 501 1026 C: 2.10 1027 C: 1028 C: 1029 C: 1 1030 C: 192.0.2.2 1031 C: 1080:0:0:0:8:800:200C:417A 1032 C: 1033 C: 1034 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e 1035 C: 175lVnv03QfwYFTfB05hhLDC1... 1036 C: 1037 C: admin 1038 C: 1039 C: tcp 1040 C: 2641 1041 C: 1042 C: 1043 C: 1044 C: 1045 C: 1046 C: jd12345 1047 C: www.abc.com 1048 C: 101 1049 C: 500 1050 C: 1051 C: 1052 C: 1053 C: 1054 C: 102 1055 C: 1056 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 1057 C: wYFTfB05hhLDC1... 1058 C: 1059 C: add_handle 1060 C: 1061 C: delete_handle 1062 C: 1063 C: add_value 1064 C: 1065 C: 1066 C: 1067 C: 1068 C: 500 1069 C: 2.10 1070 C: 1071 C: 1072 C: 2 1073 C: 192.0.2.2 1074 C: 1080:0:0:0:8:800:200C:417A 1075 C: 1076 C: 1077 C: query 1078 C: 1079 C: tcp 1080 C: 2641 1081 C: 1082 C: 1083 C: 1084 C: 1085 C: 1086 C: 1087 C: ABC-12345 1088 C: 1089 C: 1091 When an command has been processed successfully, a server 1092 MUST respond with an EPP response with no element. 1094 Example response: 1096 S: 1097 S: 1098 S: 1099 S: 1100 S: Command completed successfully 1101 S: 1102 S: 1103 S: ABC-12345 1104 S: 54321-XYZ 1105 S: 1106 S: 1107 S: 1109 An EPP error response MUST be returned if an command could 1110 not be processed for any reason. 1112 4. Formal Syntax 1114 An EPP object mapping is specified in XML Schema notation. The 1115 formal syntax presented here is a complete schema representation of 1116 the object mapping suitable for automated validation of EPP XML 1117 instances. The BEGIN and END tags are not part of the schema; they 1118 are used to note the beginning and ending of the schema for URI 1119 registration purposes. 1121 Redistribution and use in source and binary forms, with or without 1122 modification, are permitted provided that the following conditions 1123 are met: 1125 o Redistributions of source code must retain the above copyright 1126 notice, this list of conditions and the following disclaimer. 1128 o Redistributions in binary form must reproduce the above copyright 1129 notice, this list of conditions and the following disclaimer in 1130 the documentation and/or other materials provided with the 1131 distribution. 1133 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1134 names of specific contributors, may be used to endorse or promote 1135 products derived from this software without specific prior written 1136 permission. 1138 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 1139 CONTRIBUTORS"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, 1140 BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 1141 FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL 1142 THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 1143 INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 1144 (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 1145 SERVICES; LOSS OF USE,DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 1146 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 1147 STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 1148 IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1149 POSSIBILITY OF SUCH DAMAGE. 1151 BEGIN 1153 1155 1161 1165 1167 1169 1170 Extensible Provisioning Protocol v1.0 1171 identifier provisioning schema. 1172 1173 1176 1177 1178 1179 1180 1181 1184 1185 1186 1187 1188 1190 1191 1193 1195 1196 1197 1200 1201 1202 1203 1204 1205 1208 1209 1210 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1242 1243 1244 1245 1246 1247 1248 1250 1251 1252 1253 1254 1255 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1293 1294 1295 1296 1297 1298 1299 1301 1302 1303 1304 1305 1306 1308 1310 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1369 1371 1374 1376 1377 1379 1380 1381 1382 1383 1385 1387 1389 1391 1392 1393 1394 1395 1397 1400 1402 1404 1406 1407 1408 1413 1414 1415 1416 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1446 1447 1448 1451 1452 1453 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1477 1478 1480 1482 1483 1484 1487 1488 END 1489 5. Internationalization Considerations 1491 EPP is represented in XML, which provides native support for encoding 1492 information using the Unicode character set and its more compact 1493 representations including UTF-8. Conformant XML processors recognize 1494 both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to 1495 identify and use other character encodings through use of an 1496 "encoding" attribute in an declaration, use of UTF-8 is 1497 RECOMMENDED in environments where parser encoding support 1498 incompatibility exists. 1500 All date-time values presented via EPP MUST be expressed in Universal 1501 Coordinated Time using the Gregorian calendar. XML Schema allows use 1502 of time zone identifiers to indicate offsets from the zero meridian, 1503 but this option MUST NOT be used with EPP. The extended date-time 1504 form using upper case "T" and "Z" characters defined in [W3C.REC- 1505 xmlschema-2-20041028] MUST be used to represent date-time values, as 1506 XML Schema does not support truncated date-time forms or lower case 1507 "T" and "Z" characters. 1509 The syntax for handle identifiers described in this document MUST 1510 conform to [RFC3650], [RFC3651], [RFC3652]. The conformance 1511 requirements might change as a result of progressing work in 1512 developing standards for internationalized identifier techniques. 1514 6. Security Considerations 1516 Authorization information as described in Section 3.2 is REQUIRED to 1517 create an identifier object. This information is used in some query 1518 and transfer operations as an additional means of determining client 1519 authorization to perform the command. Failure to protect 1520 authorization information from inadvertent disclosure can result in 1521 unauthorized transfer operations and unauthorized information release. 1522 Both client and server MUST ensure that authorization information is 1523 stored and exchanged with high-grade encryption mechanisms to provide 1524 privacy services. 1526 The object mapping described in this document does not provide any 1527 other security services or introduce any additional considerations 1528 beyond those described by [RFC5730] or those caused by the protocol 1529 layers used by EPP. 1531 7. IANA Considerations 1533 This document uses URNs to describe XML namespaces and XML schemas 1534 conforming to a registry mechanism described in [RFC3688]. Two URI 1535 assignments have been registered by the IANA. 1537 Registration request for the identifier namespace: 1539 URI: urn:ietf:params:xml:ns:identifier-1.0 1541 Registrant Contact: See the "Author's Address" section of this 1542 document. 1544 XML: None. Namespace URIs do not represent an XML specification. 1546 Registration request for the identifier XML schema: 1548 URI: urn:ietf:params:xml:schema:identifier-1.0 1550 Registrant Contact: See the "Author's Address" section of this 1551 document. 1553 XML: See the "Formal Syntax" section of this document. 1555 8. Acknowledgments 1557 This document is based on an identifier application of EPP.Thus, the 1558 author would like to thank J. Xie who suggested improvements and 1559 provided many invaluable comments. This document are individual 1560 submissions, based on the work done in RFC 5730. 1561 This document was prepared using 2-Word-v2.0.template.dot. 1563 9. References 1565 9.1. Normative References 1567 [W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, F., 1568 Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1569 1.0 (Third Edition)", World Wide Web Consortium 1570 FirstEdition REC-xml-20040204, February 2004, 1571 . 1573 [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., 1574 Mendelsohn, N., and D. Beech, "XML Schema Part 1: 1575 Structures Second Edition", World Wide Web Consortium 1576 Recommendation REC-xmlschema-1-20041028, October 2004, 1577 . 1579 [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML 1580 Schema Part 2: Datatypes Second Edition", World Wide Web 1581 Consortium Recommendation REC-xmlschema-2-20041028, October 1582 2004, . 1583 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1584 September 1981. 1586 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1587 STD 69, RFC 5730, August 2009. 1589 [RFC3650] Sun, S. and L. Lannom, "Handle System Overview", November 1590 2003. 1592 [RFC3651] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace 1593 and Service Definition", November 2003. 1595 [RFC3652] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol 1596 (ver 2.1) Specification", November 2003. 1598 9.2. Informative References 1600 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1601 10646", RFC 2781, February 2000. 1603 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 1604 IPv6 Address Aggregation and Renumbering", RFC 2874, July 1605 2000. 1607 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS 1608 Extensions to Support IP Version 6", RFC 3596, October 1609 2003. 1611 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1612 Architecture", RFC 4291, February 2006. 1614 Author's Address 1616 Yuying Chen 1617 CAICT 1618 No.52 Huayuan North Road, Haidian District 1619 Beijing, Beijing, 100191 1620 China 1622 Phone: +86 188 1008 2358 1623 Email: chenyuying@caict.ac.cn 1624 Jiagui Xie 1625 CAICT 1626 No.52 Huayuan North Road, Haidian District 1627 Beijing, Beijing, 100191 1628 China 1630 Phone: +86 150 0138 5070 1631 Email: xiejiagui@caict.ac.cn 1633 Zhiping Li 1634 CAICT 1635 No.52 Huayuan North Road, Haidian District 1636 Beijing, Beijing, 100191 1637 China 1639 Phone: +86 185 1107 1386 1640 Email: lizhiping@caict.ac.cn 1642 Zhipeng Fan 1643 CAICT 1644 No.52 Huayuan North Road, Haidian District 1645 Beijing, Beijing, 100191 1646 China 1648 Phone: +86 159 1112 3285 1649 Email: fanzhipeng@caict.ac.cn