idnits 2.17.1 draft-chen-epp-identifier-mapping-03.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. RFC 2119 keyword, line 108: '...in this document MUST be interpreted i...' RFC 2119 keyword, line 115: '...ps and are not a REQUIRED feature of t...' RFC 2119 keyword, line 162: '...espace described in this document MUST...' RFC 2119 keyword, line 170: '... it MAY also apply to handle identif...' RFC 2119 keyword, line 183: '...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 491 has weird spacing: '...version used ...' == Line 712 has weird spacing: '...version used ...' == Line 975 has weird spacing: '...tion of the...' == Line 985 has weird spacing: '...version used ...' == Line 987 has weird spacing: '...contain the...' -- The document date (August 17, 2020) is 1341 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 1558, but not defined == Unused Reference: 'RFC0791' is defined on line 1608, but no explicit reference was found in the text == Unused Reference: 'RFC1558' is defined on line 1625, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1558 (Obsoleted by RFC 1960) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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 24, 2021 Z. Fan 5 China Academy of Information and Communications Technology 6 August 17, 2020 8 Extensible Provisioning Protocol (EPP) Industrial Internet 9 Identifier Mapping 10 draft-chen-epp-identifier-mapping-03 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 February 24, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 112 In examples, "C:" represents lines sent by a protocol client and 113 "S:" represents lines returned by a protocol server. Indentation 114 and white space in examples are provided only to illustrate element 115 relationships and are not a REQUIRED feature of this protocol. 117 1.2. Scope of Experimentation 119 This document describes an experimental extension to EPP protocol. 120 This section specifies scope of this experiment and how it can yield 121 useful information. 123 This EPP extension is designed to manage the registration, 124 modification and resolution of digital objects, handles, OID, for 125 example throughout the Industrial Internet. According to the 126 definition of EPP, this extension is an XML text protocol that 127 permits multiple service providers to perform object-provisioning 128 operations using a shared central object repository. It is designed 129 for use in a layered protocol environment. Bindings to specific 130 transport and security protocols are outside the scope of this 131 specification. 133 Given the above points, the experiment can be run on the open 134 Internet between consenting client and server implementations. 136 2. Object Attributes 138 An EPP identifier object has attributes and associated values that 139 can be viewed and modified by the sponsoring client or the server. 140 This section describes each attribute type in detail. The formal 141 syntax for the attribute values described here can be found in the 142 "Formal Syntax" section of this document and in the appropriate 143 normative references. 145 2.1. Industrial Internet Identifier Object 147 Industrial Internet Identifiers are character strings with a 148 specified format that may consist of digits, letters or notations 149 being structured in a way that is interpretable by one or more 150 computational facilities. 152 It is an unique persistent set of bits used to identify and obtain 153 state information about physical resource such as machines, 154 products, or digital resources such as algorithms, manufacturing 155 process, etc. 157 This document provides an overview of the EPP mapping of Industrial 158 Internet Identification. Handle mapping is specified as an example, 159 while description in this document applies to other identification 160 techniques as well. 162 The syntax for handle namespace described in this document MUST 163 conform to [RFC3650], [RFC3651], [RFC3652]. Handle identifiers are 164 character strings with a specified length and a specified format. 166 All handle identifiers are of the form prefix/suffix where, by 167 default, the prefix may first be resolved to locate the specific 168 identifier service and the suffix may be any bit sequence. Epp 169 mapping on the prefix examples are provided in this document while 170 it MAY also apply to handle identifiers with suffix. 172 These conformance requirements might change in the future as a 173 result of progressing work in developing standards for 174 internationalized digital object identification. 176 2.2. Client Identifiers 178 All EPP clients are identified by a server-unique identifier. Client 179 identifiers conform to the "clIDType" syntax described in [RFC5730]. 181 2.3. Status Values 183 An EPP identifier object MUST always have at least one associated 184 status value. Status values MAY be set only by the client that 185 sponsors an identifier object and by the server on which the object 186 resides. A client can change the status of object using the EPP 187 command. Each status value MAY be accompanied by a string 188 of human-readable text that describes the rationale for the status 189 applied to the object. 191 A client MUST NOT alter status values set by the server. A server 192 MAY alter or override status values set by a client, subject to 193 local server policies. The status of an object MAY change as a 194 result of either a client-initiated transform command or an action 195 performed by a server operator. 197 Status values that can be added or removed by a client are prefixed 198 with "client". Corresponding status values that can be added or 199 removed by a server are prefixed with "server". Status values that 200 do not begin with either "client" or "server" are server-managed. 202 Status Value Descriptions: 204 - clientDeleteProhibited, serverDeleteProhibited 206 Requests to delete the object MUST be rejected. 208 - clientUpdateProhibited, serverUpdateProhibited 210 Requests to update the object (other than to remove this status) 211 MUST be rejected. 213 - linked 215 The identifier object has at least one active association with 216 another object. Servers SHOULD provide services to determine 217 existing object associations. 219 - ok 221 This is the normal status value for an object that has no pending 222 operations or prohibitions. This value is set and removed by the 223 server as other status values are added or removed. 225 - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate 227 A transform command has been processed for the object, but the 228 action has not been completed by the server. Server operators can 229 delay action completion for a variety of reasons, such as to allow 230 for human review or third-party action. A transform command that is 231 processed, but whose requested action is pending, is noted with 232 response code 1001. 234 When the requested action has been completed, the pendingCreate, 235 pendingDelete, pendingTransfer, or pendingUpdate status value MUST 236 be removed. All clients involved in the transaction MUST be 237 notified using a service message that the action has been completed 238 and that the status of the object has changed. 240 "ok" status MAY only be combined with "linked" status. 242 "linked" status MAY be combined with any status. 244 "pendingDelete" status MUST NOT be combined with either 245 "clientDeleteProhibited" or "serverDeleteProhibited" status. 247 "pendingUpdate" status MUST NOT be combined with either 248 "clientUpdateProhibited" or "serverUpdateProhibited" status. 250 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 251 status values MUST NOT be combined with each other. 253 Other status combinations not expressly prohibited MAY be used. 255 2.4. Dates and Times 257 Date and time attribute values MUST be represented in Universal 258 Coordinated Time (UTC) using the Gregorian calendar. The extended 259 date-time form using upper case "T" and "Z" characters defined in 260 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 261 values, as XML Schema does not support truncated date-time forms or 262 lower case "T" and "Z" characters. 264 2.5. IP Addresses 266 The syntax for IPv4 addresses described in this document MUST 267 conform To[RFC5730]. The syntax for IPv6 addresses described in 268 this document MUST conform to [RFC4291]. Practical considerations 269 for publishing IPv6 address information in zone files are documented 270 in [RFC2874] and [RFC3596]. A server MAY reject IP addresses that 271 have not been allocated for public use by IANA. 273 3. EPP Command Mapping 275 A detailed description of the EPP syntax and semantics is specified 276 in [RFC5730]. The command mappings described here are specifically 277 for use in provisioning and managing Industrial Internet identifiers 278 via EPP. 280 3.1. EPP Query Commands 282 EPP provides two commands to retrieve object information: to 283 determine if an EPP object can be provisioned within a repository, 284 and to retrieve detailed information associated with an EPP 285 object. 287 3.1.1. EPP Command 289 The EPP command is used to determine if an object can be 290 provisioned within a repository. It provides a hint that allows a 291 client to anticipate the success or failure of provisioning an 292 object using the command, as object-provisioning 293 requirements are ultimately a matter of server policy. 295 In addition to the standard EPP command elements, the 296 command MUST contain an element that recognizes 297 the identifier namespace. The element contains 298 the following child elements: 300 o One or more elements that contain the fully 301 qualified names of the identifier objects to be queried. 303 example command: 305 C: 306 C: 309 C: 310 C: 311 C: 314 C: 88.1000.1 315 C: 88.1000.2 316 C: 317 C: 318 C: ABC-12345 319 C: 320 C: 322 When a command has been processed successfully, a server 323 MUST respond with an EPP element that MUST contain a child 324 element that identifies the identifier object namespace. The child 325 elements of the element are identifier-specific, though 326 the EPP element MUST contain a child 327 element that contains one or more (check data) 328 elements. Each element contains the following child 329 elements: 331 o An identifier-specific element that identifies the queried 332 identifier. 334 This element MUST contain an "avail" attribute whose value 335 indicates object availability (can it be provisioned or not) at 336 the moment the command was completed. A value of "1" or 337 "true" means that the identifier can be provisioned. A value of "0" 338 or "false" means that the identifier cannot be provisioned. 340 o An element that is provided when an 341 identifier cannot be provisioned. This element contains server- 342 specific text to help explain why the identifier cannot be 343 provisioned. This text MUST be represented in the response 344 language previously negotiated with the client; an OPTIONAL "lang" 345 attribute MAY be present to identify the language if the 346 negotiated value is something other than the default value of "en" 347 (English). 349 Example response: 351 S: 352 S: 353 S: 354 S: 355 S: Command completed successfully 356 S: 357 S: 358 S: 360 S: 361 S: 88.1000.1 362 S: 363 S: The identifier already exists 364 S: 365 S: 366 S: 367 S: 88.1000.1 368 S: 369 S: 370 S: 371 S: 372 S: 373 S: ABC-12345 374 S: 54321-XYZ 375 S: 376 S: 377 S: 379 An EPP error response MUST be returned if a command cannotbe 380 processed for any reason. 382 3.1.2. EPP Command 384 The EPP command is used to retrieve information associated 385 with an Industrial Internet Identifier object. In addition to the 386 standard EPP command elements, the command MUST contain an 387 element that identifies the identifier namespace. 388 The element contains one child element: 390 An element that contains the fully qualified name 391 of the identifier object for which information is requested. 393 Example command: 395 C: 396 C: 399 C: 400 C: 401 C: 404 C: 88.1000.1 405 C: 406 C: 407 C: ABC-12345 408 C: 409 C: 411 When an command has been processed successfully, the EPP 412 element MUST contain a child element 413 that identifies the identifier namespace. The 414 element contains the following child elements: 416 o An element that contains the fully qualified 417 name of the identifier object to be created. The identifier name 418 with a minimum length of 1 byte and a maximum length of 255 bytes 419 SHOULD be unique and SHOULD NOT be reused. 421 o An element that specifies type of identification 422 technique of the identifier object. Handle is taken as an example 423 in this document. 425 o Zero or more OPTIONAL elements that contain 426 contact information of the enterprise that applies for the 427 identifier to be queried. 429 o Zero or more OPTIONAL elements that contain the 430 URL associated with the identifier object to be queried. 432 o An element that contains one or more 433 elements that specify administrator 434 information of the identifier object. Identifier administrators 435 are entitled to create identifier or sub-naming authorities under 436 the handle prefix according to the permission defined by its 437 sub-element. 439 Each element includes the following 440 child elements: 442 An element that provides the reference to 443 the authentication key that can be used to authenticate the 444 administrator. 446 An element that contains the authentication 447 key of the administrator and information of the type of the 448 technique used to authenticate administrator. The public key is 449 processed with base64 encoding schemes. 451 Three types of algorithms are recommended to authenticate the 452 identifier administrator: Digital Signature Algorithm (DSA) 453 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 454 cryptography, or the password-based authentication mechanism. 456 The Digital Signature Algorithm (DSA) is a typical kind of 457 cryptographic algorithm to generate pairs of keys used in 458 public-key system: public keys which may be stored in the 459 server, and private keys which are known only to the client. 461 The RSA is one of the first public-key cryptosystems and is another 462 kind of cryptographic algorithm used for secure data transmission. 464 The password is a word or string of characters used for user 465 authentication to prove identity of the administrator. 467 An element MAY contain zero or more 468 elements that specify information about 469 the administration authority of the administrator. A set of 470 administration functions that include adding, deleting, and 471 modifying identifier or identifier values are supported by the 472 identifier service. Before fulfilling any administration request, 473 the server must authenticate the client as the identifier 474 administrator that is authorized for the administrative operation. 476 List of all the permissions see the "Formal Syntax" section of this 477 document. 479 o An element that contains one or more 480 elements that provide information to locate 481 the site to implement provisions and resolution of the identifier. 482 In this section, the element defines a handle service site by 483 identifying the server computers that comprise the site along with 484 their service configurations (e.g., port numbers). 486 Each contains the following child elements: 487 An element that indicates the specific 488 index of a site. 490 An element that indicates handle 491 protocol version used to create the handle identifier. 493 One or more elements that contain the 494 following elements: 496 An element defines the number of servers in 497 the service site. 499 One or more elements that describe IP address of 500 the identifier service. Each element MAY 501 contain an "ip" attribute to identify the IP address format. 502 Attribute value "v4" is used to note IPv4 address format. 503 Attribute value "v6" is used to note IPv6 address format. If the 504 "ip" attribute is not specified,"v4" is the default attribute 505 value. 507 An element that contains the server's public 508 key with a "type" attribute that specifies algorithms used to 509 generate the public key. Public key in the 510 can be used to authenticate any service 511 response from the handle server. 513 One or more elements that have 514 three child elements: an element that 515 indicates whether the service is for query or for administration, 516 an element that specifies transmission 517 protocol, where UDP and HTTP could be considered as alternative 518 protocols, and the element that represents 519 service port of specific the service component. 521 Example response: 523 S: 524 S: 525 S: 526 S: 527 S: Command completed successfully 528 S: 529 S: 530 S: 532 S: 88.1000.1 533 S: handle 534 S: 535 S: jd1234 536 S: www.caict.ac.cn 537 S: 538 S: 539 S: 100 540 S: 541 S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 542 S: wYFTfB05hhLDC1... 543 S: 544 S: add_handle 545 S: 546 S: delete_handle 547 S: 548 S: add_value 549 S: 550 S: modify_admin 551 S: 552 S: remove_admin 553 S: 554 S: 555 S: 556 S: 557 S: 558 S: 559 S: 500 560 S: 2.10 561 S: 562 S: 563 S: 1 564 S: 192.0.2.2 565 S: 566 S: 1080:0:0:0:8:800:200C:417A 567 S: 568 S: 569 S: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03QfwY 570 S: FTfB05hhLDC1... 571 S: 572 S: query 573 S: 574 S: tcp 575 S: 2641 576 S: 577 S: 578 S: 579 S: 580 S: 581 S: 582 S: 583 S: ABC-12345 584 S: 54322-XYZ 585 S: 586 S: 587 S: 588 An EPP error response MUST be returned if an command cannot 589 be processed for any reason. 591 3.1.3. EPP Query Command 593 Transfer semantics do not directly apply to identifier objects, so 594 there is no mapping defined for the EPP query command. 596 3.2. EPP Transform Commands 598 EPP provides three commands to transform identifier objects: 599 to create an instance of an identifier object, to 600 delete an instance of an identifier object, and to change 601 information associated with an identifier object. This document 602 does not define identifier-object mappings for the EPP and 603 commands. 605 Transform commands are typically processed and completed in real 606 time. Server operators MAY receive and process transform commands 607 but defer completing the requested action if human or third-party 608 review is required before the requested action can be completed. In 609 such situations, the server MUST return a 1001 response code to the 610 client to note that the command has been received and processed but 611 that the requested action is pending. The server MUST also manage 612 the status of the object that is the subject of the command to 613 reflect the initiation and completion of the requested action. Once 614 the action has been completed; all clients involved in the 615 transaction MUST be notified using a service message that the action 616 has been completed and that the status of the object has changed. 618 Other notification methods MAY be used in addition to the required 619 service message. 621 Server operators SHOULD confirm that a client is authorized to 622 perform a transform command on a given object. Any attempt to 623 transform an object by an unauthorized client MUST be rejected, and 624 the server MUST return a 2201 response code to the client to note 625 that the client lacks privileges to execute the requested command. 627 3.2.1. EPP Command 629 The EPP command provides an operation that allows a client 630 to create an identifier object. In addition to the standard EPP 631 command elements, the command MUST contain an element that identifies the identifier to be created. The 633 element contains the following child elements: 635 o An element that contains the fully qualified 636 name of the identifier object to be created. The identifier name 637 with a minimum length of 1 byte and a maximum length of 255 bytes 638 SHOULD be unique and SHOULD NOT be reused. 640 o An element that specifies type of identification 641 technique of the identifier object. Handle is taken as an example 642 in this document. 644 o Zero or more OPTIONAL elements that contain 645 contact information of the enterprise that applies for the 646 identifier to be created. 648 o Zero or more OPTIONAL elements that contain the 649 URL associated with the identifier object to be created. 651 o An element that contains one or 652 more elements that specify 653 administrator information of the identifier object. Identifier 654 administrators are entitled to administrate or resolve identifier 655 or identifier values according to the permission defined by its 656 sub-element. 658 Each element includes the following 659 child elements: 661 An element that provides the reference to 662 the authentication key that can be used to authenticate the 663 administrator. 665 An element that contains the authentication 666 key of the administrator and information of the type of the 667 technique used to authenticate administrator. The public key is 668 processed with base64 encoding schemes. 670 Three types of algorithms are recommended to authenticate the 671 identifier administrator: Digital Signature Algorithm (DSA) 672 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 673 cryptography, or the password-based authentication mechanism. 675 The Digital Signature Algorithm (DSA) is a typical kind of 676 cryptographic algorithm to generate pairs of keys used in public- 677 key system: public keys which may be stored in the server, and 678 private keys which are known only to the client. 680 The RSA is one of the first public-key cryptosystems and is 681 another kind of cryptographic algorithm used for secure data 682 transmission. 684 The password is a word or string of characters used for user 685 authentication to prove identity of the administrator. 687 An element MAY contain zero or more 688 elements that specify information about 689 the administration authority of the administrator. A set of 690 administration functions that include adding, deleting, and 691 modifying identifier or identifier values are supported by the 692 identifier service. Before fulfilling any administration request, 693 the server must authenticate the client as the identifier 694 administrator that is authorized for the administrative operation. 696 List of all the permissions see the "Formal Syntax" section of 697 this document. 699 o An element that contains one or more 700 elements that provide information to locate 702 the site to implement provisions and resolution of the identifier. 703 In this section, the element defines a handle service site by 704 identifying the server computers that comprise the site along with 705 their service configurations (e.g., port numbers). 707 Each contains the following child elements: 708 An element that indicates the specific 709 index of a site. 711 An element that indicates handle 712 protocol version used to create the handle identifier. 714 One or more elements that contain the 715 following elements: 717 An element defines the number of servers in 718 the service site. 720 One or more elements that describe IP address of 721 the identifier service. Each element MAY 722 contain an "ip" attribute to identify the IP address format. 724 Attribute value "v4" is used to note IPv4 address format. 725 Attribute value "v6" is used to note IPv6 address format. If the 726 "ip" attribute is not specified,"v4" is the default attribute 727 value. 729 An element that contains the server's public 730 key with a "type" attribute that specifies algorithms used to 731 generate the public key. Public key in the 732 can be used to authenticate any service 733 response from the handle server. 735 One or more elements that have 736 three child elements: an element that 737 indicates whether the service is for query or for administration, 738 an element that specifies transmission 739 protocol, where UDP and HTTP could be considered as alternative 740 protocols, and the element that represents 741 service port of specific the service component. 743 Example command: 745 C: 746 C: 749 C: 750 C: 751 C: 755 C: 88.1000.1 756 C: handle 757 C: jd1234 758 C: www.caict.ac.cn 759 C: 760 C: 761 C: 100 762 C: 763 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4 764 C: e175lVnv03QfwYFTfB05hhLDC1... 765 C: 766 C: add_handle 767 C: 768 C: delete_handle 769 C: 770 C: add_value 771 C: 772 C: modify_admin 773 C: 774 C: remove_admin 775 C: 776 C: 777 C: 778 C: 779 C: 780 C: 781 C: 500 782 C: 2.10 783 C: 784 C: 785 C: 1 786 C: 192.0.2.2 787 C: 1080:0:0:0:8:800:200C:417A 788 C: 789 C: 790 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e 791 C: 175lVnv03QfwYFTfB05hhLDC1... 792 C: 793 C: query 794 C: 795 C: tcp 796 C: 2641 797 C: 798 C: 799 C: 800 C: 801 C: 802 C: 803 C: ABC-12345 804 C: 805 C: 806 When a command has been processed successfully, the EPP 807 element MUST contain a child element that 808 identifies the result of processing. 810 Example response: 812 S: 813 S: 814 S: 815 S: 816 S: Command completed successfully 817 S: 818 S: 819 S: ABC-12345 820 S: 54321-XYZ 821 S: 822 S: 823 S: 825 An EPP error response MUST be returned if a command cannot 826 be processed for any reason. 828 3.2.2. EPP Command 830 The EPP command provides an operation that allows a client 831 to delete an identifier object. In addition to the standard EPP 832 command elements, the command MUST contain an 833 element that specifies the identifier namespace. 834 The element contains the following child element: 836 o An element that contains the fully qualified 837 name of the identifier object to be deleted. 839 Example command: 841 C: 842 C: 845 C: 846 C: 847 C: 850 C: 88.1000.1 851 C: 852 C: 853 C: ABC-12345 854 C: 855 C: 857 When a command has been processed successfully, a server 858 MUST respond with an EPP response with no element. 860 Example response 862 864 S: 865 S: 866 S: 867 S: 868 S: Command completed successfully 869 S: 870 S: 871 S: ABC-12345 872 S: 54321-XYZ 873 S: 874 S: 875 S: 877 An EPP error response MUST be returned if a command cannot 878 be processed for any reason. 880 3.2.3. EPP Command 882 Renewal semantics do not apply to identifier objects, so there is no 883 identifier mapping defined for the EPP command. 885 3.2.4. EPP Command 887 Transfer semantics do not directly apply to identifier objects, so 888 there is no mapping defined for the EPP command. 890 3.2.5. EPP Command 892 The EPP command provides an operation that allows a client 893 to modify the attributes of an identifier. In addition to the 894 standard EPP command elements, the command MUST contain an 895 element that identifies the identifier object 896 and attributes to be updated. The element 897 contains the following child elements: 899 o An element that contains the fully qualified 900 name of the identifier object to be updated. 902 o An OPTIONAL element that contains attribute 903 values to be added to the identifier object. 905 o An OPTIONAL element that contains attribute 906 values to be removed from the object. It has the following child 907 elements: An OPTIONAL element that contains 908 contact information that is to be removed from the identifier. 910 An optional element that contains the URL to be 911 removed. An OPTIONAL element that 912 specifies the index of the identifier administrator to be deleted. 913 An OPTIONAL element that contains 914 information about index of the site to be removed from the 915 identifier object. At least one child element of MUST be provided 916 if the element is present. 918 o An OPTIONAL element that contains object 919 attribute values to be changed. The name of an identifier MUST NOT 920 be changed, due to impacts on associated identifier objects. 922 At least one , , or 923 element MUST be provided if the command is not being extended. All 924 of these elements MAY be omitted if an extension is 925 present. The and elements share 926 two common child elements: and the 927 element. 929 The element has two additional child elements: 930 and other than the common 931 element. 933 Whereas the has an additional 934 element that specifies status of the identifier object. Description 935 of the common child elements of and 936 goes as follows: 938 - An element that specifies 939 administrator information of the identifier object. Identifier 940 administrators are entitled to administrate or resolve 941 identifier or identifier values according to the permission 942 defined by its sub-element. An 943 element includes the following 945 child elements: 947 An element that provides the reference 948 to the authentication key that can be used to authenticate the 949 administrator. 951 An element that contains the authentication 952 key of the administrator and information of the type of the 953 technique used to authenticate administrator. The public key is 954 processed with base64 encoding schemes. 956 Three types of algorithms are recommended to authenticate the 957 identifier administrator: Digital Signature Algorithm (DSA) 958 public-key cryptography, Rivest-Shamir-Adleman(RSA) public-key 959 cryptography, or the password-based authentication mechanism. 961 An element MAY contain zero or more 962 elements that specify information about 963 the administration authority of the administrator. A set of 964 administration functions that include adding, deleting, and 965 modifying identifier or identifier values are supported by the 966 identifier service. Before fulfilling any administration 967 request, the server must authenticate the client as the 968 identifier administrator that is authorized for the 969 administrative operation. 971 Lists of all the permissions see the "Formal Syntax" section of 972 this document. 974 - An element that provides information to 975 locate the site to implement provisions and resolution of the 976 identifier.The element defines a handle 977 service site by identifying the server computers that comprise 978 the site along with their service configurations (e.g., port 979 numbers).It contains the following child elements: 981 An element that indicates the specific 982 index of a site that is added or modified. 984 An element that indicates handle 985 protocol version used to create the handle identifier. 987 One or more elements that contain the 988 following elements: An element defines the 989 number of servers in the service site. One or more 990 elements that describe IP address of the 991 identifier service. Each element MAY contain 992 an "ip" attribute to identify the IP address format. Attribute 993 value "v4" is used to note IPv4 address format. Attribute value 994 "v6" is used to note IPv6 address format. If the "ip" attribute 995 is not specified,"v4" is the default attribute value. An 996 element that contains the server's public key 997 with a "type" attribute that specifies algorithms used to 998 generate the public key. Public key in the 999 can be used to authenticate any service 1000 response from the handle server. One or more 1001 elements that have three child 1002 elements: an element that indicates 1003 whether the service is for query or for administration, an 1004 element that specifies transmission 1005 protocol, where UDP and HTTP could be considered as alternative 1006 protocols, and the element that represents 1007 service port of specific the service component. 1009 Example command: 1011 C: 1012 C: 1015 C: 1016 C: 1017 C: 1021 C: 88.1000.1 1022 C: 1023 C: jd12345 1024 C: www.abc.com 1025 C: 1026 C: 101 1027 C: 1028 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 1029 C: wYFTfB05hhLDC1... 1030 C: 1031 C: add_handle 1032 C: 1033 C: delete_handle 1034 C: 1035 C: add_value 1036 C: 1037 C: modify_admin 1038 C: 1039 C: remove_admin 1040 C: 1041 C: 1042 C: 1043 C: 1044 C: 501 1045 C: 2.10 1046 C: 1047 C: 1048 C: 1 1049 C: 192.0.2.2 1050 C: 1080:0:0:0:8:800:200C:417A 1051 C: 1052 C: 1053 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e 1054 C: 175lVnv03QfwYFTfB05hhLDC1... 1055 C: 1056 C: admin 1057 C: 1058 C: tcp 1059 C: 2641 1060 C: 1061 C: 1062 C: 1063 C: 1064 C: 1065 C: jd12345 1066 C: www.abc.com 1067 C: 101 1068 C: 500 1069 C: 1070 C: 1071 C: 1072 C: 1073 C: 102 1074 C: 1075 C: AAAAB3NzaC1yc2EAAAADAQABAAABAQCprNl4N4e175lVnv03Qf 1076 C: wYFTfB05hhLDC1... 1077 C: 1078 C: add_handle 1079 C: 1080 C: delete_handle 1081 C: 1082 C: add_value 1083 C: 1084 C: 1085 C: 1086 C: 1087 C: 500 1088 C: 2.10 1089 C: 1090 C: 1091 C: 2 1092 C: 192.0.2.2 1093 C: 1080:0:0:0:8:800:200C:417A 1094 C: 1095 C: 1096 C: query 1097 C: 1098 C: tcp 1099 C: 2641 1100 C: 1101 C: 1102 C: 1103 C: 1104 C: 1105 C: 1106 C: ABC-12345 1107 C: 1108 C: 1110 When an command has been processed successfully, a server 1111 MUST respond with an EPP response with no element. 1113 Example response: 1115 S: 1116 S: 1117 S: 1118 S: 1119 S: Command completed successfully 1120 S: 1121 S: 1122 S: ABC-12345 1123 S: 54321-XYZ 1124 S: 1125 S: 1126 S: 1128 An EPP error response MUST be returned if an command could 1129 not be processed for any reason. 1131 4. Formal Syntax 1133 An EPP object mapping is specified in XML Schema notation. The 1134 formal syntax presented here is a complete schema representation of 1135 the object mapping suitable for automated validation of EPP XML 1136 instances. The BEGIN and END tags are not part of the schema; they 1137 are used to note the beginning and ending of the schema for URI 1138 registration purposes. 1140 Redistribution and use in source and binary forms, with or without 1141 modification, are permitted provided that the following conditions 1142 are met: 1144 o Redistributions of source code must retain the above copyright 1145 notice, this list of conditions and the following disclaimer. 1147 o Redistributions in binary form must reproduce the above copyright 1148 notice, this list of conditions and the following disclaimer in 1149 the documentation and/or other materials provided with the 1150 distribution. 1152 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1153 names of specific contributors, may be used to endorse or promote 1154 products derived from this software without specific prior written 1155 permission. 1157 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 1158 CONTRIBUTORS"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 1159 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 1160 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 1161 IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR 1162 ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR 1163 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 1164 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,DATA, OR PROFITS; OR 1165 BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 1166 LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 1167 NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 1168 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1170 BEGIN 1172 1174 1180 1183 1185 1187 1188 Extensible Provisioning Protocol v1.0 1189 identifier provisioning schema. 1190 1191 1194 1195 1196 1197 1198 1199 1202 1203 1204 1205 1206 1208 1209 1211 1213 1214 1215 1218 1219 1220 1221 1222 1223 1226 1227 1228 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1261 1262 1263 1264 1265 1266 1267 1269 1270 1271 1272 1273 1274 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1290 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1313 1314 1315 1316 1317 1318 1319 1321 1322 1323 1324 1325 1326 1328 1330 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1390 1392 1395 1397 1399 1401 1402 1403 1404 1405 1407 1409 1411 1413 1414 1415 1416 1417 1419 1422 1424 1426 1428 1429 1430 1435 1436 1437 1438 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1468 1469 1470 1474 1475 1476 1478 1479 1480 1481 1482 1483 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1501 1502 1504 1506 1507 1508 1511 1512 END 1513 5. Internationalization Considerations 1515 EPP is represented in XML, which provides native support for 1516 encoding information using the Unicode character set and its more 1517 compact representations including UTF-8. Conformant XML processors 1518 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 1519 provisions to identify and use other character encodings through use 1520 of an "encoding" attribute in an declaration, use of UTF-8 1521 is RECOMMENDED in environments where parser encoding support 1522 incompatibility exists. 1524 All date-time values presented via EPP MUST be expressed in 1525 Universal Coordinated Time using the Gregorian calendar. XML Schema 1526 allows use of time zone identifiers to indicate offsets from the 1527 zero meridian, but this option MUST NOT be used with EPP. The 1528 extended date-time form using upper case "T" and "Z" characters 1529 defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent 1530 date-time values, as XML Schema does not support truncated date-time 1531 forms or lower case "T" and "Z" characters. 1533 The syntax for handle identifiers described in this document MUST 1534 conform to [RFC3650], [RFC3651], [RFC3652]. The conformance 1535 requirements might change as a result of progressing work in 1536 developing standards for internationalized identifier techniques. 1538 6. Security Considerations 1540 Authorization information as described in Section 3.2 is REQUIRED to 1541 create an identifier object. This information is used in some query 1542 and transfer operations as an additional means of determining client 1543 authorization to perform the command. Failure to protect 1544 authorization information from inadvertent disclosure can result in 1545 unauthorized transfer operations and unauthorized information 1546 release. Both client and server MUST ensure that authorization 1547 information is stored and exchanged with high-grade encryption 1548 mechanisms to provide privacy services. 1550 The object mapping described in this document does not provide any 1551 other security services or introduce any additional considerations 1552 beyond those described by [RFC5730] or those caused by the protocol 1553 layers used by EPP. 1555 7. IANA Considerations 1557 This document uses URNs to describe XML namespaces and XML schemas 1558 conforming to a registry mechanism described in [RFC3688]. Two URI 1559 assignments have been registered by the IANA. 1561 Registration request for the identifier namespace: 1563 URI: urn:ietf:params:xml:ns:identifier-1.0 1565 Registrant Contact: See the "Author's Address" section of this 1566 document. 1568 XML: None. Namespace URIs do not represent an XML specification. 1570 Registration request for the identifier XML schema: 1572 URI: urn:ietf:params:xml:schema:identifier-1.0 1574 Registrant Contact: See the "Author's Address" section of this 1575 document. 1577 XML: See the "Formal Syntax" section of this document. 1579 8. Acknowledgments 1581 This document is based on an identifier application of EPP.Thus, the 1582 authors would like to thank J. Xie who suggested improvements and 1583 provided many invaluable comments. This document are individual 1584 submissions, based on the work done in RFC 5730. 1585 This document was prepared using 2-Word-v2.0.template.dot. 1587 9. References 1589 9.1. Normative References 1591 [W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, 1592 F., Paoli, J., and T. Bray, "Extensible Markup Language 1593 (XML) 1.0 (Third Edition)", World Wide Web Consortium 1594 FirstEdition REC-xml-20040204, February 2004, 1595 . 1597 [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., 1598 Mendelsohn, N., and D. Beech, "XML Schema Part 1: 1599 Structures Second Edition", World Wide Web Consortium 1600 Recommendation REC-xmlschema-1-20041028, October 2004, 1601 . 1603 [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML 1604 Schema Part 2: Datatypes Second Edition", World Wide Web 1605 Consortium Recommendation REC-xmlschema-2-20041028, 1606 October 2004, . 1608 [RFC0791] Postel, J., "Internet Protocol", 1609 STD 5, RFC 791, September 1981. 1611 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1612 STD 69, RFC 5730, August 2009. 1614 [RFC3650] Sun, S. and L. Lannom, "Handle System Overview", November 1615 2003. 1617 [RFC3651] Sun, S., Reilly, S. and L. Lannom, "Handle System 1618 Namespace and Service Definition", November 2003. 1620 [RFC3652] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol 1621 (ver 2.1) Specification", November 2003. 1623 9.2. Informative References 1625 [RFC1558] T. Howes, "A String Representation of LDAP Search Filters", 1626 RFC 1558, December 1993. 1628 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1629 10646", RFC 2781, February 2000. 1631 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 1632 IPv6 Address Aggregation and Renumbering", RFC 2874, July 1633 2000. 1635 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1636 "DNS Extensions to Support IP Version 6", RFC 3596, 1637 October 2003. 1639 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1640 Architecture", RFC 4291, February 2006. 1642 Author's Address 1644 Yuying Chen 1645 CAICT 1646 No.52 Huayuan North Road, Haidian District 1647 Beijing, Beijing, 100191 1648 China 1650 Phone: +86 188 1008 2358 1651 Email: chenyuying@caict.ac.cn 1653 Jiagui Xie 1654 CAICT 1655 No.52 Huayuan North Road, Haidian District 1656 Beijing, Beijing, 100191 1657 China 1659 Phone: +86 150 0138 5070 1660 Email: xiejiagui@caict.ac.cn 1662 Zhiping Li 1663 CAICT 1664 No.52 Huayuan North Road, Haidian District 1665 Beijing, Beijing, 100191 1666 China 1668 Phone: +86 185 1107 1386 1669 Email: lizhiping@caict.ac.cn 1671 Zhipeng Fan 1672 CAICT 1673 No.52 Huayuan North Road, Haidian District 1674 Beijing, Beijing, 100191 1675 China 1677 Phone: +86 159 1112 3285 1678 Email: fanzhipeng@caict.ac.cn