idnits 2.17.1 draft-ietf-provreg-epp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GRRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DATE-TIME' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-XML' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-2' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 January 24, 2002 Expires: July 24, 2002 6 Extensible Provisioning Protocol 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an application layer client-server protocol 32 for the provisioning and management of objects stored in a shared 33 central repository. Specified in XML, the protocol defines generic 34 object management operations and an extensible framework that maps 35 protocol operations to objects. This document includes a protocol 36 specification, an object mapping template, and an XML media type 37 registration. 39 Conventions Used In This Document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [RFC2119]. 45 In examples, "C:" represents lines sent by a protocol client and "S:" 46 represents lines returned by a protocol server. Indentation and white 47 space in examples is provided only to illustrate element relationships 48 and is not a REQUIRED feature of this protocol. 50 Table of Contents 52 1. Introduction ................................................. 3 53 2. Protocol Description ......................................... 4 54 2.1 Protocol Identification ..................................... 5 55 2.2 Hello Format ................................................ 5 56 2.3 Greeting Format ............................................. 6 57 2.4 Command Format .............................................. 9 58 2.5 Response Format ............................................. 11 59 2.6 Protocol Extension Framework ................................ 16 60 2.6.1 Protocol Extension ........................................ 16 61 2.6.2 Object Extension .......................................... 17 62 2.6.3 Command-Response Extension ................................ 18 63 2.7 Object Identification ....................................... 18 64 2.8 Protocol Commands ........................................... 19 65 2.8.1 Session Management Commands ............................... 19 66 2.8.1.1 EPP Command ..................................... 20 67 2.8.1.2 EPP Command .................................... 22 68 2.8.2 Query Commands ............................................ 23 69 2.8.2.1 EPP Command ..................................... 23 70 2.8.2.2 EPP Command ...................................... 25 71 2.8.2.3 EPP Command ...................................... 27 72 2.8.2.4 EPP Command .................................... 32 73 2.8.2.5 EPP Query Command ............................ 34 74 2.8.3 Object Transform Commands ................................. 36 75 2.8.3.1 EPP Command .................................... 36 76 2.8.3.2 EPP Command .................................... 38 77 2.8.3.3 EPP Command ..................................... 39 78 2.8.3.4 EPP Command .................................. 41 79 2.8.3.5 EPP Command .................................... 44 80 3. Result Codes ................................................. 47 81 4. Formal Syntax ................................................ 52 82 4.1 Base Schema ................................................. 52 83 4.2 Shared Structure Schema ..................................... 63 84 5. Internationalization Considerations .......................... 66 85 6. IANA Considerations .......................................... 67 86 7. Security Considerations ...................................... 68 87 8. Acknowledgements ............................................. 69 88 9. References ................................................... 70 89 10. Author's Address ............................................ 71 90 A. Revisions From Previous Version .............................. 72 91 B. Full Copyright Statement ..................................... 73 92 C: Object Mapping Template ...................................... 74 93 D: Media Type Registration: application/epp+xml ................. 76 95 1. Introduction 97 This document describes specifications for the Extensible Provisioning 98 Protocol (EPP) version 1.0, an XML text protocol that permits multiple 99 service providers to perform object provisioning operations using a 100 shared central object repository. EPP is specified using the 101 Extensible Markup Language (XML) 1.0 as described in [XML] and XML 102 Schema notation as described in [XMLS-1] and [XMLS-2]. EPP meets and 103 exceeds the requirements for a generic registry registrar protocol as 104 described in [GRRP]. 106 EPP content is identified by MIME media type application/epp+xml. 107 Registration information for this media type is included in an 108 appendix to this document. 110 EPP is intended for use in diverse operating environments where 111 transport and security requirements vary greatly. It is unlikely that 112 a single transport or security specification will meet the needs of 113 all anticipated operators, so EPP was designed for use in a layered 114 protocol environment. Bindings to specific transport and security 115 protocols are outside the scope of this specification. 117 This original motivation for this protocol was to provide a standard 118 Internet domain name registration protocol for use between domain name 119 registrars and domain name registries. This protocol provides a means 120 of interaction between a registrar's applications and registry 121 applications. It is expected that this protocol will have additional 122 uses beyond domain name registration. 124 XML is case sensitive. Unless stated otherwise, XML specifications 125 and examples provided in this document MUST be interpreted in the 126 character case presented to develop a conforming implementation. 128 This document is being discussed on the "ietf-provreg" mailing list. 129 To join the list, send a message to with the 130 words "subscribe ietf-provreg" in the body of the message. There is a 131 web site for the list archives at http://www.cafax.se/ietf-provreg. 133 2. Protocol Description 135 EPP is an XML protocol that can be layered over multiple transport 136 protocols. Protected using lower-layer security protocols, clients 137 exchange identification, authentication, and option information, and 138 then engage in a series of client-initiated command-response 139 exchanges. All EPP commands are atomic (there is no partial success 140 or partial failure) and idempotent (executing a command more than once 141 has the same net effect on system state as successfully executing the 142 command once). 144 EPP provides four basic service elements: service discovery, commands, 145 responses, and an extension framework that supports definition of 146 managed objects and the relationship of protocol requests and 147 responses to those objects. 149 A connection-oriented EPP server MUST respond to connection creation 150 by returning a greeting to a client. A connection-less EPP server 151 MUST be prompted to provide a greeting to a client. In both cases, a 152 client SHOULD wait for a greeting before sending an EPP command to the 153 server. A server MUST respond to each EPP command with a coordinated 154 response that describes the results of processing the command. 155 Commands and responses MAY be exchanged synchronously or 156 asynchronously; asynchronous exchanges might result in higher error 157 rates if a client issues commands without waiting to receive the 158 responses for prior commands. 160 Implementers MUST consider the mechanics of command-response 161 synchronization when implementing a client that supports asynchronous 162 command-response exchanges. Server implementers MUST support 163 asynchronous command-response exchanges. 165 EPP commands fall into three categories: session management commands, 166 query commands, and data transform commands. Session management 167 commands are used to establish and end persistent sessions with an EPP 168 server. Query commands are used to perform read-only object 169 information retrieval operations. Transform commands are used to 170 perform read-write object management operations. 172 EPP uses XML namespaces to provide an extensible object management 173 framework and to identify schemas required for XML instance parsing 174 and validation. These namespaces and schema definitions are used to 175 identify both the base protocol schema and the schemas for managed 176 objects. 178 All XML instances SHOULD begin with an declaration to identify 179 the version of XML that is being used, optionally identify use of the 180 UTF-8 character set defined in [RFC2279], and optionally to provide a 181 hint to an XML parser that an external schema file is needed to 182 validate the XML instance. EPP use with character sets other than 183 UTF-8 is not described in this document. Conformant XML parsers are 184 required to understand UTF-8, thus the "encoding" attribute is 185 OPTIONAL. 187 Example XML declarations: 189 191 193 195 197 2.1 Protocol Identification 199 All EPP XML instances MUST begin with an element. This element 200 identifies the start of an EPP protocol element, the namespace used 201 within the protocol, and the location of the protocol schema. This 202 start element and the associated ending element MUST be applied to all 203 structures sent by both clients and servers. 205 Example "start" and "end" EPP elements: 207 211 213 2.2 Hello Format 215 EPP MAY be carried over both connection-oriented and connection-less 216 transport protocols. An EPP client MAY request a from an 217 EPP server at any time by sending a to a server. Use of this 218 element is essential in a connection-less environment where a server 219 can not return a in response to a client-initiated 220 connection. An EPP MUST be an empty element with no child 221 elements. 223 Example : 225 C: 226 C: 230 C: 231 C: 233 2.3 Greeting Format 235 An EPP server responds to a successful connection and element 236 by returning a element to the client. An EPP greeting 237 contains the following elements: 239 - An element that contains the name of the server. 241 - An element that contains the server's current date and time 242 in UTC. 244 - An element that identifies the services supported by the 245 server, including: 247 - One or more elements that identify the protocol versions 248 supported by the server. 250 - One or more elements that contain the identifiers of the 251 text response languages known by the server. Language identifiers 252 MUST be structured as documented in [RFC3066]. 254 - One or more elements that contain namespace URIs 255 representing the objects that the server is capable of managing. A 256 server MAY limit object management privileges on a per-client basis. 258 - An OPTIONAL element that contains one or more 259 elements that contain namespace URIs representing object 260 extensions supported by the server. 262 - An OPTIONAL (data collection policy) element that contains 263 child elements used to describe the server's policy for data 264 collection and management. Policy implications usually extend 265 beyond the client-server relationship. Both clients and servers can 266 have relationships with other entities that need to know the server 267 operator's data collection policy to make informed provisioning 268 decisions. If present, policy information MUST be disclosed to 269 provisioning entities, though the method of disclosing policy data 270 outside of direct protocol interaction is beyond the scope of this 271 specification. Child elements include the following: 273 - An element that describes the access provided by the 274 server to the client on behalf of the originating data source. 275 The element MUST contain one of the following child 276 elements: 278 : Access is given to all identified data. 280 : No access is provided to identified data. 282 : Data is not persistent, so no access is possible. 284 : Access is given to identified data relating to 285 individuals and organizational entities. 287 : Access is given to identified data relating 288 to individuals, organizational entities, and other data of a 289 non-personal nature. 291 : Access is given to other identified data of a non- 292 personal nature. 294 - One or more elements that describe data collection 295 purposes, data recipients, and data retention. Each 296 element MUST contain a element, a element, 297 and a element. 299 The element MUST contain one or more of the following 300 child elements that describe the purposes for which data is 301 collected: 303 : Administrative purposes. 305 : Contact for marketing purposes. 307 : Object provisioning purposes. 309 : Other purposes. 311 The element MUST contain one or more of the 312 following child elements that describes the recipients of 313 collected data: 315 : Other entities following unknown practices. 317 : Server operator and/or entities acting as agents or 318 entities for whom the server operator is acting as an agent. 319 An agent in this instance is defined as a third party that 320 processes data only on behalf of the service provider for the 321 completion of the stated purposes. The element 322 contains an OPTIONAL element that can be used to 323 describe the recipient. 325 : Public forums. 327 : Other entities following server practices. 329 : Unrelated third parties. 331 The element MUST contain one of the following child 332 elements that describes data retention practices: 334 : Data persists per business practices. 336 : Data persists indefinitely. 338 : Data persists per legal requirements. 340 : Data is not persistent, and is not retained for more 341 than a brief period of time necessary to make use of it during 342 the course of a single online interaction. 344 : Data persists to meet the stated purpose. 346 - An OPTIONAL element that describes the lifetime of the 347 policy. The element MUST contain one of the following 348 child elements: 350 : The policy is valid from the current date and time 351 until it expires on the specified date and time. 353 : The policy is valid from the current date and time 354 until the end of the specified duration. 356 Data collection policy elements are based on work described in the 357 World Wide Web Consortium's Platform for Privacy Preferences [P3P] 358 specification. 360 Example greeting: 362 S: 363 S: 367 S: 368 S: Example EPP server epp.example.tld 369 S: 2000-06-08T22:00:00.0Z 370 S: 371 S: 1.0 372 S: en 373 S: fr 374 S: urn:ietf:params:xml:ns:obj1 375 S: urn:ietf:params:xml:ns:obj2 376 S: urn:ietf:params:xml:ns:obj3 377 S: 378 S: http://custom/obj1ext-1.0 379 S: 380 S: 381 S: 382 S: 383 S: 384 S: 385 S: 386 S: 387 S: 388 S: 389 S: 390 S: 392 2.4 Command Format 394 An EPP client interacts with an EPP server by sending commands to the 395 server and receiving responses from the server. Commands and 396 responses need not be exchanged synchronously. In addition to the 397 standard EPP elements, an EPP command contains the following elements: 399 - A (client identity credentials) element that provides client 400 identity information. Use of this element can be OPTIONAL or REQUIRED 401 depending on how the client wishes to manage sessions with the server. 402 A element contains the following elements: 404 - A element that contains the client identifier assigned to 405 the client by the server. 407 - A element that contains the client's plain text password. 408 The value of this element is case sensitive. 410 - An OPTIONAL element that contains a new plain text 411 password to be assigned to the client for use with subsequent 412 elements. The value of this element is case sensitive. 414 - An element that contains the following child elements: 416 - A element that contains the protocol version to be 417 used for the command or ongoing server session. 419 - A element that contains the text response language to be 420 used for the command or ongoing server session commands. 422 The values of the and elements MUST exactly match 423 one of the values presented in the EPP greeting. 425 - A command element whose tag corresponds to one of the valid EPP 426 commands described in this document. The command element MAY contain 427 either protocol-specified or object-specified child elements. 429 - An OPTIONAL element that MAY be used for server-defined 430 command extensions. 432 - An OPTIONAL (client transaction identifier) element that 433 uniquely identifies the command to the client. 435 EPP supports both session-less and session-oriented operating modes, 436 though the two operating modes MUST NOT be mixed. An ongoing server 437 session that preserves client identity and authorization information 438 can be created and ended using the and commands. 439 Commands MAY also be executed outside of an established session 440 through use of the element within the command. 442 Session-less operation implies that object service availability and 443 client identity MUST be checked on a per-command basis. Significant 444 improvements in server processing performance can be realized using 445 the protocol's session-oriented operating mode. 447 Example command without credentials: 449 C: 450 C: 454 C: 455 C: 456 C: 458 C: example 459 C: 460 C: 461 C: ABC-12345 462 C: 463 C: 465 Example command with credentials: 467 C: 468 C: 472 C: 473 C: 474 C: ClientX 475 C: foo-BAR2 476 C: bar-FOO2 477 C: 478 C: 1.0 479 C: en 480 C: 481 C: 482 C: 483 C: 485 C: example 486 C: 487 C: 488 C: ABC-12345 489 C: 490 C: 492 2.5 Response Format 493 An EPP server responds to a client command by returning a response to 494 the client. EPP commands are atomic, so a command will either succeed 495 completely or fail completely. Success and failure results MUST NOT 496 be mixed. In addition to the standard EPP elements, an EPP response 497 contains the following elements: 499 - One or more elements that document the success or failure 500 of command execution. If the command was processed successfully, only 501 one element MUST be returned. If the command was not 502 processed successfully, multiple elements MAY be returned to 503 document failure conditions. Each element contains the 504 following attribute and child elements: 506 - A "code" attribute whose value is a four-digit, decimal number 507 that describes the success or failure of the command. 509 - A element containing a human-readable description of the 510 response code. The language of the response is identified via an 511 OPTIONAL "lang" attribute. If not specified, the default attribute 512 value MUST be "en" (English). 514 - Zero or more OPTIONAL elements that echo client-provided 515 elements (including XML tag and value) that caused server error 516 conditions. 518 - An OPTIONAL element that contains a child element 519 used to return information in response to a command. 521 - An OPTIONAL element that describes messages queued for client 522 retrieval. A element MUST NOT be present if there are no 523 messages queued for client retrieval. A element MAY be present 524 in responses to EPP commands other than the command if messages 525 are queued for retrieval. A element MUST be present in 526 responses to the EPP command if messages are queued for 527 retrieval. The element contains the following attributes: 529 - A "count" attribute that describes the number of messages that 530 exist in the queue. 532 - An "id" attribute used to uniquely identify the message at the 533 head of the queue. 535 The element contains the following OPTIONAL child elements 536 that MUST be returned in response to a request command and 537 MUST NOT be returned in response to any other command, including a 538 acknowledgement: 540 - A element that contains the date and time that the message 541 was enqueued. 543 - A element containing a human-readable message. The language 544 of the response is identified via an OPTIONAL "lang" attribute. If 545 not specified, the default attribute value MUST be "en" (English). 547 - An OPTIONAL (response data) element that contains child 548 elements specific to the command and associated object. 550 - An OPTIONAL element that MAY be used for server-defined 551 response extensions. 553 - A (transaction identifier) element containing the transaction 554 identifier assigned by the server to the command for which the 555 response is being returned. The transaction identifier is formed 556 using the associated with the command if supplied by the 557 client and a (server transaction identifier) that is assigned 558 by and unique to the server. 560 Transaction identifiers provide command-response synchronization 561 integrity. They SHOULD be logged, retained, and protected to ensure 562 that both the client and the server have consistent temporal and state 563 management records. 565 Example response without or : 567 S: 568 S: 572 S: 573 S: 574 S: Command completed successfully 575 S: 576 S: 577 S: ABC-12345 578 S: 54321-XYZ 579 S: 580 S: 581 S: 582 Example response with : 584 S: 585 S: 589 S: 590 S: 591 S: Command completed successfully 592 S: 593 S: 594 S: 596 S: example 597 S: 598 S: 599 S: 600 S: ABC-12345 601 S: 54321-XYZ 602 S: 603 S: 604 S: 605 Example response with error value elements: 607 S: 608 S: 612 S: 613 S: 614 S: Parameter value range error 615 S: 616 S: 2525 617 S: 618 S: 619 S: 620 S: Parameter value syntax error 621 S: 622 S: ex(ample 623 S: 624 S: 625 S: abc.ex(ample 626 S: 627 S: 628 S: 629 S: ABC-12345 630 S: 54321-XYZ 631 S: 632 S: 633 S: 634 Example response with notice of waiting server messages: 636 S: 637 S: 641 S: 642 S: 643 S: Command completed successfully 644 S: 645 S: 646 S: 647 S: ABC-12345 648 S: 54321-XYZ 649 S: 650 S: 651 S: 653 Command success or failure MUST NOT be assumed if no response is 654 returned or if a returned response is malformed. Protocol idempotency 655 ensures the safety of retrying a command in cases of response delivery 656 failure. 658 2.6 Protocol Extension Framework 660 EPP provides an extension framework that allows features to be added 661 at the protocol, object, and command-response levels. 663 2.6.1 Protocol Extension 665 The EPP extension framework allows for definition of new protocol 666 elements identified using XML namespace notation with a reference to 667 an XML schema that defines the namespace. The element that 668 identifies the beginning of a protocol instance includes multiple 669 child element choices, one of which is an element whose 670 children define the extension. For example, a protocol extension 671 element would be described in generic terms as follows: 673 C: 674 C: 675 C: 676 C: 678 C: 679 C: 680 C: 681 C: 683 This document does not define mappings for specific extensions. 684 Extension specifications MUST be described in separate documents that 685 define the objects and operations subject to the extension. 687 2.6.2 Object Extension 689 EPP provides an extensible object management framework that defines 690 the syntax and semantics of protocol operations applied to a managed 691 object. This framework pushes the definition of each protocol 692 operation into the context of a specific object, providing the ability 693 to add mappings for new objects without having to modify the base 694 protocol. 696 Protocol elements that contain data specific to objects are identified 697 using XML namespace notation with a reference to an XML schema that 698 defines the namespace. The schema for EPP supports use of dynamic 699 object schemas on a per-command and per-response basis. For example, 700 the start of an object-specific command element would be described in 701 generic terms as follows: 703 C: 704 C: 706 C: 707 C: 708 C: 710 An object-specific response element would be described similarly: 712 S: 713 S: 715 S: 716 S: 717 S: 719 This document does not define mappings for specific objects. The 720 mapping of EPP to an object MUST be described in separate documents 721 that specifically address each command and response in the context of 722 the object. A suggested object mapping outline is included as an 723 appendix to this document. 725 2.6.3 Command-Response Extension 727 EPP provides a facility for protocol command and response extensions. 728 Protocol commands and responses MAY be extended by an 729 element that contains additional elements whose syntax and semantics 730 are not explicitly defined by EPP or an EPP object mapping. This 731 element is OPTIONAL. Extensions are typically defined by agreement 732 between client and server and MAY be used to extend EPP for unique 733 operational needs. A server-extended command element would be 734 described in generic terms as follows: 736 C: 737 C: 739 C: 740 C: 741 C: 742 C: 743 C: 744 C: 746 An server-extended response element would be described similarly: 748 S: 749 S: 750 S: Command completed successfully 751 S: 752 S: 753 S: 754 S: 755 S: 756 S: ABC-12345 757 S: 54321-XYZ 758 S: 759 S: 761 This document does not define any specific server extensions. The 762 mapping of server extensions to EPP MUST be described in separate 763 documents that specifically address extended commands and responses in 764 the server's operational context. 766 2.7 Object Identification 767 Some objects, such as name servers and contacts, can have utility in 768 multiple repositories. However, maintaining disjoint copies of object 769 information in multiple repositories can lead to inconsistencies that 770 have adverse consequences for the Internet. For example, changing a 771 name server name in one repository, but not in a second repository 772 that refers to the server for domain name delegation, can produce 773 unexpected DNS query results. 775 Globally unique identifiers can help facilitate object information 776 sharing between repositories. A globally unique identifier MUST be 777 assigned to every object when the object is created, and the 778 identifier MUST be returned within the response for the command that 779 created the object. Specific identifier values are a matter of 780 repository policy, but they SHOULD be constructed according to the 781 following algorithm: 783 a) Divide the provisioning repository world into a number of object 784 repository classes. 786 b) Each repository within a class is assigned an identifier that is 787 maintained by IANA. 789 (c) Each repository is responsible for assigning a unique local 790 identifier for each object within the repository. 792 (d) The globally unique identifier is a concatenation of the local 793 identifier, followed by a hyphen ("-", ASCII value 0x002D), followed 794 by the repository identifier. 796 2.8 Protocol Commands 798 EPP provides commands to manage sessions, retrieve object information, 799 and perform transformation operations on objects. All EPP commands 800 are atomic and idempotent, either succeeding completely or failing 801 completely and producing predictable results in case of repeated 802 execution. This section describes each EPP command, including 803 examples with representative server responses. 805 2.8.1 Session Management Commands 807 EPP provides two commands for session management: to establish 808 a session with a server, and to end a session with a server. 809 The command establishes an ongoing server session that 810 preserves client identity and authorization information during the 811 duration of the session. Alternatively, identity credentials MAY be 812 provided with an EPP command to facilitate session-less operation. 814 Session-oriented and session-less operating modes MUST NOT be mixed. 816 Commands other than the command MUST NOT include identity 817 credentials when submitted after successfully processing a 818 command. 820 2.8.1.1 EPP Command 822 The EPP command is used to establish a session with an EPP 823 server in response to a greeting issued by the server. A 824 command MUST be sent to a server before any other EPP command to 825 establish an ongoing session. 827 A client identifier and initial password MUST be created on the server 828 before a client can successfully complete a command. The 829 client identifier and initial password MUST be delivered to the client 830 using an out-of-band method that protects the identifier and password 831 from inadvertent disclosure. 833 A element MUST be provided with the command. Once a 834 session has been established with the command, subsequent 835 commands MUST NOT include a element. 837 In addition to the standard EPP command elements, the command 838 contains the following child elements: 840 - A element that contains one or more elements that 841 contain namespace URIs representing the objects to be managed during 842 the session. The element MAY contain an OPTIONAL 843 element that contains one or more elements 844 that identify object extensions to be used during the session. 846 The PLAIN SASL mechanism presented in [RFC2595] describes a format for 847 providing a user identifier, an authorization identifier, and a 848 password as part of a single plain text string. The EPP 849 authentication mechanism is similar, though EPP does not require a 850 session-level authorization identifier and the user identifier and 851 password are separated into distinct XML elements. Additional 852 identification and authorization schemes MUST be provided at other 853 protocol layers to provide more robust security services. 855 Example command: 857 C: 858 C: 862 C: 863 C: 864 C: ClientX 865 C: foo-BAR2 866 C: bar-FOO2 867 C: 868 C: 1.0 869 C: en 870 C: 871 C: 872 C: 873 C: 874 C: urn:ietf:params:xml:ns:obj1 875 C: urn:ietf:params:xml:ns:obj2 876 C: urn:ietf:params:xml:ns:obj3 877 C: 878 C: http://custom/obj1ext-1.0 879 C: 880 C: 881 C: 882 C: ABC-12345 883 C: 884 C: 886 When a command has been processed successfully, a server MUST 887 respond with an EPP response with no element. If 888 successful, the server will respond by creating and maintaining a new 889 session that SHOULD be terminated by a future command. 891 Example response: 893 S: 894 S: 898 S: 899 S: 900 S: Command completed successfully 901 S: 902 S: 903 S: ABC-12345 904 S: 54321-XYZ 905 S: 906 S: 907 S: 909 The EPP command is used to establish a session with an EPP 910 server. A command MUST be rejected if received within the 911 bounds of an existing session. This action MUST be open to all 912 authorized clients. 914 2.8.1.2 EPP Command 916 The EPP command is used to end a session with an EPP server. 917 The command MUST be represented as an empty element with no 918 child elements. 920 A server MAY also end a session asynchronously due to client 921 inactivity or excessive client session longevity. The parameters for 922 determining excessive client inactivity or session longevity are a 923 matter of server policy and are not specified by this protocol. 925 Example command: 927 C: 928 C: 932 C: 933 C: 934 C: ABC-12345 935 C: 936 C: 937 When a command has been processed successfully, a server MUST 938 respond with an EPP response with no element. If 939 successful, the server MUST also end the current session. 941 Example response: 943 S: 944 S: 948 S: 949 S: 950 S: Command completed successfully; ending session 951 S: 952 S: 953 S: ABC-12345 954 S: 54321-XYZ 955 S: 956 S: 957 S: 959 The EPP command is used to end a session with an EPP server. 960 A command MUST be rejected if the command has not been 961 preceded by a successful command. This action MUST be open to 962 all authorized clients. 964 2.8.2 Query Commands 966 EPP provides four commands to retrieve object information: to 967 determine if an object can be provisioned within a repository, 968 to retrieve detailed information associated with a known object, 969 to receive service notifications from the server, and 970 to retrieve object transfer status information. A 971 command is provided to allow a client to determine if a previously 972 issued transform command was received and processed by the server. 974 2.8.2.1 EPP Command 976 The EPP command is used to determine if an object can be 977 provisioned within a repository. It provides a hint that allows a 978 client to anticipate the success or failure of provisioning an object 979 using the command. Object availability and provisioning 980 conditions are a matter of server policy. 982 The elements needed to identify an object are object-specific, so the 983 child elements of the command are specified using the EPP 984 extension framework. In addition to the standard EPP command 985 elements, the command contains the following child elements: 987 - An object-specific element that identify the objects to 988 be queried. Multiple objects of the same type MAY be queried within a 989 single command. 991 Example command: 993 C: 994 C: 998 C: 999 C: 1000 C: 1002 C: example1 1003 C: example2 1004 C: example3 1005 C: 1006 C: 1007 C: ABC-12346 1008 C: 1009 C: 1011 When a command has been processed successfully, a server MUST 1012 respond with an EPP element that MUST contain a child 1013 element that identifies the object namespace and the location of the 1014 object schema. The child elements of the element are 1015 object-specific, though the EPP element MUST contain a child 1016 element that contains one or more (check data) 1017 elements. Each elements contains the following child 1018 elements: 1020 - An object-specific element that identifies the queried object. This 1021 element MUST contain an "avail" attribute whose value indicates object 1022 availability at the moment the command was completed. A value 1023 of "1" or "true" means that the object is available. A value of "0" 1024 or "false" means that the object is not available. 1026 - An OPTIONAL element that MAY be provided when an object 1027 is not available for provisioning. If present, this element contains 1028 server-specific text to help explain why the object is unavailable. 1029 This text MUST be represented in the response language previously 1030 negotiated with the client; an OPTIONAL "lang" attribute MAY be 1031 present to identify the language if the negotiated value is something 1032 other than the default value of "en" (English). 1034 Example response: 1036 S: 1037 S: 1041 S: 1042 S: 1043 S: Command completed successfully 1044 S: 1045 S: 1046 S: 1048 S: 1049 S: example1 1050 S: 1051 S: 1052 S: example2 1053 S: In use 1054 S: 1055 S: 1056 S: example3 1057 S: 1058 S: 1059 S: 1060 S: 1061 S: ABC-12346 1062 S: 54322-XYZ 1063 S: 1064 S: 1065 S: 1067 The EPP command is used to determine if an object can be 1068 provisioned within a repository. This action MUST be open to all 1069 authorized clients. 1071 2.8.2.2 EPP Command 1073 The EPP command is used to retrieve information associated with 1074 an existing object. The elements needed to identify an object and the 1075 type of information associated with an object are both object- 1076 specific, so the child elements of the command are specified 1077 using the EPP extension framework. In addition to the standard EPP 1078 command elements, the command contains the following child 1079 elements: 1081 - An object-specific element that identifies the object to 1082 be queried. 1084 Example command: 1086 C: 1087 C: 1091 C: 1092 C: 1093 C: 1095 C: 1096 C: 1097 C: 1098 C: ABC-12346 1099 C: 1100 C: 1102 When an command has been processed successfully, a server MUST 1103 respond with an EPP element that MUST contain a child 1104 element that identifies the object namespace and the location of the 1105 object schema and the Repository Object Identifier (ROID) that was 1106 assigned to the object when the object was created. Other child 1107 elements of the element are object-specific. 1109 Example response: 1111 S: 1112 S: 1116 S: 1117 S: 1118 S: Command completed successfully 1119 S: 1120 S: 1121 S: 1123 S: EXAMPLE1-REP 1124 S: 1125 S: 1126 S: 1127 S: 1128 S: ABC-12346 1129 S: 54322-XYZ 1130 S: 1131 S: 1132 S: 1134 The EPP command is used to retrieve information associated with 1135 an existing object. This action SHOULD be limited to authorized 1136 clients; restricting this action to the sponsoring client is 1137 RECOMMENDED. 1139 2.8.2.3 EPP Command 1141 The EPP command is used to discover and retrieve service 1142 messages queued by a server for individual clients. If the message 1143 queue is not empty, a successful response to a command MUST 1144 return the first message from the message queue. Each response 1145 returned from the server includes a server-unique message identifier 1146 that MUST be provided to acknowledge receipt of the message, and a 1147 counter that indicates the number of messages in the queue. After a 1148 message has been received by the client, the client MUST respond to 1149 the message with an explicit acknowledgement to confirm that the 1150 message has been received. A server MUST dequeue the message and 1151 decrement the queue counter after receiving acknowledgement from the 1152 client, making the next message in the queue (if any) available for 1153 retrieval. 1155 Servers can occasionally perform actions on objects that are not in 1156 direct response to a client request, or an action taken by one client 1157 can indirectly involve a second client. Examples of such actions 1158 include deletion upon expiration, automatic renewal upon expiration, 1159 and transfer coordination; other types of service information MAY be 1160 defined as a matter of server policy. Service messages MUST be 1161 created for all clients affected by an action on an object. For 1162 example, actions MUST be reported to both the client that 1163 requests an object transfer and the client that has the authority to 1164 approve or reject the transfer request. 1166 Message queues can consume server resources if clients do not retrieve 1167 and acknowledge messages on a regular basis. Servers MAY implement 1168 other mechanisms to dequeue and deliver messages if queue maintenance 1169 needs exceed server resource consumption limits. Server operators 1170 SHOULD consider time-sensitivity and resource management factors when 1171 selecting a delivery method for service information because some 1172 message types can be reasonably delivered using non-protocol methods 1173 that require fewer server resources. 1175 Some of the information returned in response to a command can 1176 be object-specific, so some child elements of the response MAY 1177 be specified using the EPP extension framework. The command 1178 MUST be represented as an empty element with no child elements. An 1179 "op" attribute with value "req" is REQUIRED to retrieve the first 1180 message from the server message queue. An "op" attribute (with value 1181 "ack") and a "msgID" attribute (whose value corresponds to the value 1182 of the "id" attribute copied from the element in the message 1183 being acknowledged) are REQUIRED to acknowledge receipt of a message. 1185 Example command: 1187 C: 1188 C: 1192 C: 1193 C: 1194 C: ABC-12345 1195 C: 1196 C: 1198 The returned result code notes that a message has been dequeued and 1199 returned in response to a command. 1201 Example response with object-specific information: 1203 S: 1204 S: 1208 S: 1209 S: 1210 S: Command completed successfully; message dequeued 1211 S: 1212 S: 1213 S: 2000-06-08T22:00:00.0Z 1214 S: Transfer requested. 1215 S: 1216 S: 1217 S: 1220 S: example 1221 S: pending 1222 S: ClientX 1223 S: 2000-06-08T22:00:00.0Z 1224 S: ClientY 1225 S: 2000-06-13T22:00:00.0Z 1226 S: 2002-09-08T22:00:00.0Z 1227 S: 1228 S: 1229 S: 1230 S: ABC-12345 1231 S: 54321-XYZ 1232 S: 1233 S: 1234 S: 1236 A client MUST acknowledge each response to dequeue the message and 1237 make subsequent messages available for retrieval. 1239 Example acknowledgement command: 1241 C: 1242 C: 1246 C: 1247 C: 1248 C: ABC-12346 1249 C: 1250 C: 1252 A acknowledgement response notes the number of messages 1253 remaining in the queue and the ID of the next message available for 1254 retrieval. 1256 Example acknowledgement response: 1258 S: 1259 S: 1263 S: 1264 S: 1265 S: Command completed successfully 1266 S: 1267 S: 1268 S: 1269 S: ABC-12346 1270 S: 54322-XYZ 1271 S: 1272 S: 1273 S: 1275 Service messages can also be returned without object information. 1277 Example response without object-specific information: 1279 S: 1280 S: 1284 S: 1285 S: 1286 S: Command completed successfully; message dequeued 1287 S: 1288 S: 1289 S: 2000-06-08T22:10:00.0Z 1290 S: Credit balance low. 1291 S: 1292 S: 1293 S: ABC-12346 1294 S: 54321-XYZ 1295 S: 1296 S: 1297 S: 1299 The returned result code and message is used to note an empty server 1300 message queue. 1302 Example response to note an empty message queue: 1304 S: 1305 S: 1309 S: 1310 S: 1311 S: Command completed successfully; no messages 1312 S: 1313 S: 1314 S: ABC-12346 1315 S: 54321-XYZ 1316 S: 1317 S: 1318 S: 1320 The EPP command is used to discover and retrieve client service 1321 messages from a server. This action SHOULD be limited to authorized 1322 clients; queuing service messages and limiting queue access on a per- 1323 client basis is RECOMMENDED. 1325 2.8.2.4 EPP Command 1327 The EPP command is used to determine if an previously issued 1328 transform command was received and processed by a server. While EPP 1329 provides command completion status by returning a response to every 1330 command, responses can be lost due to network, hardware, or software 1331 failures. In such cases, it is often useful to be able to determine 1332 command status after the failure situation has been discovered and 1333 corrected. With the search space for previously completed command 1334 identifiers potentially being very large, this command includes 1335 elements and attributes to help focus the search. In addition to the 1336 standard EPP command elements, the command contains the 1337 following child elements: 1339 - A (client transaction identifier) element that contains the 1340 transaction identifier assigned by the client to the earlier command 1341 whose status is in question. 1343 In addition, the element contains a "command" attribute that 1344 is used to identify the type of the earlier command. Valid values are 1345 "create", "delete", "renew", "transfer", and "update". 1347 It is important to note that a client transaction identifier is not 1348 required for every transform command, so clients who wish to use the 1349 command successfully MUST provide a client identifier with 1350 all transactions whose status might be queried in the future. 1352 Example command: 1354 C: 1355 C: 1359 C: 1360 C: 1361 C: ABC-12345 1362 C: 1363 C: ABC-12346 1364 C: 1365 C: 1367 When a command has been processed successfully, a server MUST 1368 respond with an EPP response with no element. Status 1369 information is returned in the child element of the 1370 element. The element contains a child element that 1371 contains the following child elements: 1373 - Zero or more elements that contain the client transaction 1374 identifier used to identify the queried command. No elements 1375 will be returned if the server fails to recognize the identifier. 1376 Servers are not required to enforce client transaction identifier 1377 uniqueness, so a single client identifier might be associated with 1378 multiple commands if a client reuses identifiers. One element will be 1379 returned if the server recognizes the identifier and the client 1380 enforces identifier uniqueness. Multiple elements MAY be returned if 1381 the server recognizes the identifier and the client does not enforce 1382 identifier uniqueness. Each element contains an "ack" 1383 attribute whose positive boolean value confirms that the command was 1384 received and the requested action was completed. A negative boolean 1385 value indicates that the requested action was not completed. 1387 Example response for a recognized transaction: 1389 S: 1390 S: 1394 S: 1395 S: 1396 S: Command completed successfully 1397 S: 1398 S: 1399 S: ABC-12345 1400 S: 1401 S: 1402 S: 1403 S: 1404 S: ABC-12346 1405 S: 54322-XYZ 1406 S: 1407 S: 1408 S: 1410 An empty element is returned when a server fails to recognize 1411 a client transaction. 1413 Example response for an unrecognized transaction: 1415 S: 1416 S: 1420 S: 1421 S: 1422 S: Command completed successfully 1423 S: 1424 S: 1425 S: 1426 S: ABC-12346 1427 S: 54322-XYZ 1428 S: 1429 S: 1430 S: 1432 The EPP command is used to retrieve information associated 1433 with client commands. This action SHOULD be limited to authorized 1434 clients; restricting this action to the issuing client is RECOMMENDED. 1436 2.8.2.5 EPP Query Command 1438 The EPP command provides a query operation that allows a 1439 client to determine real-time status of pending and completed transfer 1440 requests. The elements needed to identify an object that is the 1441 subject of a transfer request are object-specific, so the child 1442 elements of the query command are specified using the EPP 1443 extension framework. In addition to the standard EPP command 1444 elements, the command contains an "op" attribute with value 1445 "query", and the following child elements: 1447 - An object-specific element that identifies the object 1448 whose transfer status is requested. 1450 Transfer status is typically considered sensitive information by the 1451 clients involved in the operation. Object mappings MUST provide 1452 features to restrict transfer queries to authorized clients, such as 1453 by requiring authorization information as part of the request. 1455 Example query command: 1457 C: 1458 C: 1462 C: 1463 C: 1464 C: 1466 C: 1467 C: 1468 C: 1469 C: ABC-12346 1470 C: 1471 C: 1473 When a query command has been processed successfully, a 1474 server MUST respond with an EPP element that MUST contain a 1475 child element that identifies the object namespace and the location of 1476 the object schema. The child elements of the element are 1477 object-specific, but they MUST include elements that identify the 1478 object, the status of the transfer, the identifier of the client that 1479 requested the transfer, the date and time that the request was made, 1480 the identifier of the client that is authorized to act on the request, 1481 the date and time by which an action is expected, and an OPTIONAL date 1482 and time noting changes in the object's validity period (if 1483 applicable) that occur as a result of the transfer. 1485 Example query response: 1487 S: 1488 S: 1492 S: 1493 S: 1494 S: Command completed successfully 1495 S: 1496 S: 1497 S: 1499 S: example 1500 S: pending 1501 S: ClientX 1502 S: 2000-06-08T22:00:00.0Z 1503 S: ClientY 1504 S: 2000-06-13T22:00:00.0Z 1505 S: 2002-09-08T22:00:00.0Z 1506 S: 1507 S: 1508 S: 1509 S: ABC-12346 1510 S: 54322-XYZ 1511 S: 1512 S: 1513 S: 1515 The EPP command provides a query operation that allows a 1516 client to determine real-time status of pending and completed transfer 1517 requests. This action SHOULD be limited to authorized clients; 1518 restricting queries to the requesting and responding clients is 1519 RECOMMENDED. Object transfer MAY be unavailable or limited by 1520 object-specific policies. 1522 2.8.3 Object Transform Commands 1524 EPP provides five commands to transform objects: to create an 1525 instance of an object with a server, to remove an instance of 1526 an object from a server, to extend the validity period of an 1527 object, to change information associated with an object, and 1528 to manage changes in client sponsorship of an object. 1530 2.8.3.1 EPP Command 1531 The EPP command is used to create an instance of an object. 1532 An object can be created for an indefinite period of time, or an 1533 object can be created for a specific validity period. The EPP mapping 1534 for an object MUST describe the status of an object with respect to 1535 time, to include expected client and server behavior if a validity 1536 period is used. 1538 The elements needed to identify an object and associated attributes 1539 are object-specific, so the child elements of the command are 1540 specified using the EPP extension framework. In addition to the 1541 standard EPP command elements, the command contains the 1542 following child elements: 1544 - An object-specific element that identifies the object 1545 to be created and the elements that are required to create the object. 1547 Example command: 1549 C: 1550 C: 1554 C: 1555 C: 1556 C: 1558 C: 1559 C: 1560 C: 1561 C: ABC-12345 1562 C: 1563 C: 1565 When a command has been processed successfully, a server MAY 1566 respond with an EPP element that MUST contain a child 1567 element that identifies the object namespace and the location of the 1568 object schema. The child elements of the element are 1569 object-specific. 1571 Example response with : 1573 S: 1574 S: 1578 S: 1579 S: 1580 S: Command completed successfully 1581 S: 1582 S: 1583 S: 1585 S: 1586 S: 1587 S: 1588 S: 1589 S: ABC-12345 1590 S: 54321-XYZ 1591 S: 1592 S: 1593 S: 1595 The EPP command is used to create an instance of an object. 1596 This action SHOULD be limited to authorized clients and MAY be 1597 restricted on a per-client basis. 1599 2.8.3.2 EPP Command 1601 The EPP command is used to remove an instance of an existing 1602 object. The elements needed to identify an object are object- 1603 specific, so the child elements of the command are specified 1604 using the EPP extension framework. In addition to the standard EPP 1605 command elements, the command contains the following child 1606 elements: 1608 - An object-specific element that identifies the object 1609 to be deleted. 1611 Example command: 1613 C: 1614 C: 1618 C: 1619 C: 1620 C: 1622 C: 1623 C: 1624 C: 1625 C: ABC-12346 1626 C: 1627 C: 1629 When a command has been processed successfully, a server MAY 1630 respond with an EPP element that MUST contain a child 1631 element that identifies the object namespace and the location of the 1632 object schema. The child elements of the element are 1633 object-specific. 1635 Example response without : 1637 S: 1638 S: 1642 S: 1643 S: 1644 S: Command completed successfully 1645 S: 1646 S: 1647 S: ABC-12346 1648 S: 54322-XYZ 1649 S: 1650 S: 1651 S: 1653 The EPP command is used to remove an instance of an existing 1654 object. This action SHOULD be limited to authorized clients; 1655 restricting this action to the sponsoring client is RECOMMENDED. 1657 2.8.3.3 EPP Command 1658 The EPP command is used to extend the validity period of an 1659 existing object. The elements needed to identify and extend the 1660 validity period of an object are object-specific, so the child 1661 elements of the command are specified using the EPP extension 1662 framework. In addition to the standard EPP command elements, the 1663 command contains the following child elements: 1665 - An object-specific element that identifies the object to 1666 be renewed and the elements that are required to extend the validity 1667 period of the object. 1669 Example command: 1671 C: 1672 C: 1676 C: 1677 C: 1678 C: 1680 C: 1681 C: 1682 C: 1683 C: ABC-12346 1684 C: 1685 C: 1687 When a command has been processed successfully, a server MAY 1688 respond with an EPP element that MUST contain a child 1689 element that identifies the object namespace and the location of the 1690 object schema. The child elements of the element are 1691 object-specific. 1693 Example response with : 1695 S: 1696 S: 1700 S: 1701 S: 1702 S: Command completed successfully 1703 S: 1704 S: 1705 S: 1707 S: 1708 S: 1709 S: 1710 S: 1711 S: ABC-12346 1712 S: 54322-XYZ 1713 S: 1714 S: 1715 S: 1717 The EPP command is used to extend the validity period of an 1718 existing object. This action SHOULD be limited to authorized clients; 1719 restricting this action to the sponsoring client is RECOMMENDED. 1720 Object renewal MAY be unavailable or limited by object-specific 1721 policies. 1723 2.8.3.4 EPP Command 1725 The EPP command is used to manage changes in client 1726 sponsorship of an existing object. Clients can initiate a transfer 1727 request, cancel a transfer request, approve a transfer request, and 1728 reject a transfer request using the "op" command attribute. 1730 A client who wishes to assume sponsorship of a known object from 1731 another client uses the command with the value of the "op" 1732 attribute set to "request". Once a transfer has been requested, the 1733 same client can cancel the request using a command with the 1734 value of the "op" attribute set to "cancel". A request to cancel the 1735 transfer MUST be sent to the server before the current sponsoring 1736 client either approves or rejects the transfer request and before the 1737 server automatically processes the request due to responding client 1738 inactivity. 1740 Once a transfer request has been received by the server, the server 1741 MUST notify the current sponsoring client of the requested transfer by 1742 queuing a service message for retrieval via the command. The 1743 current status of a pending command for any object can be 1744 found using the query command. Transfer service messages 1745 MUST include the object-specific elements specified for 1746 command responses. 1748 The current sponsoring client MAY explicitly approve or reject the 1749 transfer request. The client can approve the request using a 1750 command with the value of the "op" attribute set to 1751 "approve". The client can reject the request using a 1752 command with the value of the "op" attribute set to "reject". 1754 A server MAY automatically approve or reject all transfer requests 1755 that are not explicitly approved or rejected by the current sponsoring 1756 client within a fixed amount of time. The amount of time to wait for 1757 explicit action and the default server behavior are local matters not 1758 specified by EPP, but they SHOULD be documented in a server-specific 1759 profile document that describes default server behavior for client 1760 information. 1762 Objects MUST have associated authorization information that MUST be 1763 provided to complete a command. The type of authorization 1764 information required is object-specific; passwords or more complex 1765 mechanisms based on public key cryptography are typical. 1767 The elements needed to identify and complete the transfer of an object 1768 are object-specific, so the child elements of the command 1769 are specified using the EPP extension framework. In addition to the 1770 standard EPP command elements, the command contains the 1771 following child elements: 1773 - An object-specific element that identifies the object 1774 to be transferred and the elements that are required to process the 1775 transfer command. 1777 Example command: 1779 C: 1780 C: 1784 C: 1785 C: 1786 C: 1788 C: 1789 C: 1790 C: 1791 C: ABC-12346 1792 C: 1793 C: 1795 When a command has been processed successfully, a server 1796 MUST respond with an EPP element that MUST contain a child 1797 element that identifies the object namespace and the location of the 1798 object schema. The child elements of the element are 1799 object-specific, but they MUST include elements that identify the 1800 object, the status of the transfer, the identifier of the client that 1801 requested the transfer, the date and time that the request was made, 1802 the identifier of the client that is authorized to act on the request, 1803 the date and time by which an action is expected, and an OPTIONAL date 1804 and time noting changes in the object's validity period (if 1805 applicable) that occur as a result of the transfer. 1807 Example response with : 1809 S: 1810 S: 1814 S: 1815 S: 1816 S: Command completed successfully 1817 S: 1818 S: 1819 S: 1821 S: example 1822 S: pending 1823 S: ClientX 1824 S: 2000-06-08T22:00:00.0Z 1825 S: ClientY 1826 S: 2000-06-13T22:00:00.0Z 1827 S: 2002-09-08T22:00:00.0Z 1828 S: 1829 S: 1830 S: 1831 S: ABC-12346 1832 S: 54322-XYZ 1833 S: 1834 S: 1835 S: 1837 The EPP command is used to manage changes in client 1838 sponsorship of an existing object. This action SHOULD be limited to 1839 authorized clients; restricting requests to a client other 1840 than the current sponsoring client, approval requests to 1841 the current sponsoring client, and cancellation requests to 1842 the original requesting client is RECOMMENDED. Object transfer MAY be 1843 unavailable or limited by object-specific policies. 1845 2.8.3.5 EPP Command 1847 The EPP command is used to change information associated with 1848 an existing object. The elements needed to identify and modify an 1849 object are object-specific, so the child elements of the 1850 command are specified using the EPP extension framework. In addition 1851 to the standard EPP command elements, the command contains 1852 the following child elements: 1854 - An object-specific element that identifies the object 1855 to be updated and the elements that are required to modify the object. 1856 Object-specific elements MUST identify values to be added, values to 1857 be removed, or values to be changed. 1859 Example command: 1861 C: 1862 C: 1866 C: 1867 C: 1868 C: 1870 C: 1871 C: 1872 C: 1873 C: ABC-12346 1874 C: 1875 C: 1877 When an command has been processed successfully, a server MAY 1878 respond with an EPP element that MUST contain a child 1879 element that identifies the object namespace and the location of the 1880 object schema. The child elements of the element are 1881 object-specific. 1883 Example response without : 1885 S: 1886 S: 1890 S: 1891 S: 1892 S: Command completed successfully 1893 S: 1894 S: 1895 S: ABC-12346 1896 S: 54322-XYZ 1897 S: 1898 S: 1899 S: 1901 The EPP command is used to change information associated with 1902 an existing object. This action SHOULD be limited to authorized 1903 clients; restricting this action to the sponsoring client is 1904 RECOMMENDED. 1906 3. Result Codes 1908 EPP result codes are based on the Theory of Reply Codes described in 1909 Appendix E of [RFC821]. EPP uses four decimal digits to describe the 1910 success or failure of each EPP command. Each of the digits of the 1911 reply have special significance. 1913 The first digit denotes command success or failure. The second digit 1914 denotes the response category, such as command syntax or security. 1915 The third and fourth digits provide explicit response detail within 1916 each response category. 1918 There are two values for the first digit of the reply code: 1920 1yzz Positive completion reply. The command has been accepted and 1921 processed by the system without error. 1923 2yzz Negative completion reply. The command was not accepted and 1924 the requested action did not occur. 1926 The second digit groups responses into one of six specific categories: 1928 x0zz Protocol Syntax 1929 x1zz Implementation-specific Rules 1930 x2zz Security 1931 x3zz Data Management 1932 x4zz Server System 1933 x5zz Connection Management 1935 The third and fourth digits provide response detail within the 1936 categories defined by the first and second digits. Specific result 1937 codes are listed in the table below. 1939 Every EPP response MUST include a result code and a human-readable 1940 description of the result code. The language used to represent the 1941 description MAY be identified using an instance of the "lang" 1942 attribute within the element. If not specified, the default 1943 language is English, identified as "en". A description of the 1944 structure of valid values for the "lang" attribute is described in 1945 [RFC3066]. 1947 Response text MAY be translated into other languages, though the 1948 translation MUST preserve the meaning of the code as described here. 1949 Response code values MUST NOT be changed when translating text. 1951 Response text in the table below is enclosed in quotes to clearly mark 1952 the beginning and ending of each response string. Quotes MUST NOT be 1953 used to delimit these strings when returning response text via the 1954 protocol. 1956 Successful command completion responses: 1958 Code Response text in English 1959 ___________________________________ 1961 1000 "Command completed successfully" 1962 This is the nominal response code for a successfully completed 1963 command. This response code MUST be returned in responses for all 1964 commands other than for the situations relating to the , 1965 , and commands as described here. 1967 1300 "Command completed successfully; no messages" 1968 This response code MUST be returned when responding to a 1969 request command and the server message queue is empty. 1971 1301 "Command completed successfully; message dequeued" 1972 This response code MUST be returned when responding to a 1973 request command and a message has been dequeued from the server 1974 message queue. 1976 1500 "Command completed successfully; ending session" 1977 This response code MUST be returned when responding to a successful 1978 command. 1980 Command error responses: 1982 Code Response text in English 1983 ___________________________________ 1985 2000 "Unknown command" 1986 This response code MUST be returned when a server receives a command 1987 element that is not defined by EPP. 1989 2001 "Command syntax error" 1990 This response code MUST be returned when a server receives an 1991 improperly formed command element. 1993 2002 "Command use error" 1994 This response code MUST be returned when a server receives a properly 1995 formed command element, but the command can not be executed due to a 1996 sequencing or context error. For example, a command can not 1997 be executed without having first completed a command. 1999 2003 "Required parameter missing" 2000 This response code MUST be returned when a server receives a command 2001 for which a required parameter value has not been provided. 2003 2004 "Parameter value range error" 2004 This response code MUST be returned when a server receives a command 2005 parameter whose value is outside the range of values specified 2006 by the protocol. The error value SHOULD be returned via a 2007 element in the EPP response. 2009 2005 "Parameter value syntax error" 2010 This response code MUST be returned when a server receives a command 2011 containing a parameter whose value is improperly formed. The error 2012 value SHOULD be returned via a element in the EPP response. 2014 2100 "Unimplemented protocol version" 2015 This response code MUST be returned when a server receives a command 2016 element specifying a protocol version that is not implemented by the 2017 server. 2019 2101 "Unimplemented command" 2020 This response code MUST be returned when a server receives a valid 2021 EPP command element that is not implemented by the server. For 2022 example, a command can be unimplemented for certain object 2023 types. 2025 2102 "Unimplemented option" 2026 This response code MUST be returned when a server receives a valid 2027 EPP command element that contains a protocol option that is not 2028 implemented by the server. For example, a server might not implement 2029 the protocol's session-less operating mode. 2031 2103 "Unimplemented extension" 2032 This response code MUST be returned when a server receives a valid 2033 EPP command element that contains a protocol command extension that 2034 is not implemented by the server. 2036 2104 "Billing failure" 2037 This response code MUST be returned when a server attempts to execute 2038 a billable operation and the command can not be completed due to a 2039 client billing failure. 2041 2105 "Object is not eligible for renewal" 2042 This response code MUST be returned when a client attempts to 2043 an object that is not eligible for renewal in accordance with server 2044 policy. 2046 2106 "Object is not eligible for transfer" 2047 This response code MUST be returned when a client attempts to 2048 an object that is not eligible for transfer in accordance 2049 with server policy. 2051 2200 "Authentication error" 2052 This response code MUST be returned when a server notes an error when 2053 validating client credentials. 2055 2201 "Authorization error" 2056 This response code MUST be returned when a server notes a client 2057 authorization error when executing a command. This error is used to 2058 note that a client lacks privileges to execute the requested command. 2060 2202 "Invalid authorization information" 2061 This response code MUST be returned when a server receives invalid 2062 command authorization information required to confirm authorization to 2063 execute a command. This error is used to note that a client has the 2064 privileges required to execute the requested command, but the 2065 authorization information provided by the client does not match the 2066 authorization information archived by the server. 2068 2300 "Object pending transfer" 2069 This response code MUST be returned when a server receives a command 2070 to transfer an object that is pending transfer due to an earlier 2071 transfer request. 2073 2301 "Object not pending transfer" 2074 This response code MUST be returned when a server receives a command 2075 to confirm, reject, or cancel the transfer an object when no command 2076 has been made to transfer the object. 2078 2302 "Object exists" 2079 This response code MUST be returned when a server receives a command 2080 to create an object that already exists in the repository. 2082 2303 "Object does not exist" 2083 This response code MUST be returned when a server receives a command 2084 to query or transform an object that does not exist in the repository. 2086 2304 "Object status prohibits operation" 2087 This response code MUST be returned when a server receives a command 2088 to transform an object that can not be completed due to server policy 2089 or business practices. For example, a server can disallow 2090 commands under terms and conditions that are matters of local policy, 2091 or the server might have received a command for an object 2092 whose status prohibits deletion. 2094 2305 "Object association prohibits operation" 2095 This response code MUST be returned when a server receives a command 2096 to transform an object that can not be completed due to dependencies 2097 on other objects that are associated with the target object. For 2098 example, a server can disallow commands while an object has 2099 active associations with other objects. 2101 2306 "Parameter value policy error" 2102 This response code MUST be returned when a server receives a command 2103 containing a parameter value that is syntactically valid, but 2104 semantically invalid due to local policy. For example, the server 2105 can support a subset of a range of valid protocol parameter values. 2106 The error value SHOULD be returned via a element in the EPP 2107 response. 2109 2307 "Unimplemented object service" 2110 This response code MUST be returned when a server receives a command 2111 to operate on an object service that is not supported by the server. 2113 2308 "Data management policy violation" 2114 This response code MUST be returned when a server receives a command 2115 whose execution results in a violation of server data management 2116 policies. For example, removing all attribute values or object 2117 associations from an object might be a violation of a server's data 2118 management policies. 2120 2400 "Command failed" 2121 This response code MUST be returned when a server is unable to 2122 execute a command due to an internal server error that is not related 2123 to the protocol. The failure can be transient. The server MUST keep 2124 any ongoing session active. 2126 2500 "Command failed; server ending session" 2127 This response code MUST be returned when a server receives a command 2128 that can not be completed due to an internal server error that is not 2129 related to the protocol. The failure is not transient, and will 2130 cause other commands to fail as well. The server MUST end any 2131 ongoing active session. 2133 2501 "Timeout; server ending session" 2134 This response code MUST be returned when a server receives a command 2135 that can not be completed due to a session-oriented timeout. 2137 2502 "Session limit exceeded; server closing connection" 2138 This response code MUST be returned when a server receives a 2139 command, and the command can not be completed because the client has 2140 exceeded a system-defined limit on the number of sessions that the 2141 client can establish. It might be possible to establish a session by 2142 ending existing unused sessions. 2144 4. Formal Syntax 2146 EPP is specified in XML Schema notation. The formal syntax presented 2147 here is a complete schema representation of EPP suitable for automated 2148 validation of EPP XML instances. 2150 Two schemas are presented here. The first schema is the base EPP 2151 schema. The second schema defines elements and structures that can be 2152 used by both the base EPP schema and object mapping schemas. The 2153 BEGIN and END tags are not part of the schema; they are used to note 2154 the beginning and ending of the schema for URI registration purposes. 2156 4.1 Base Schema 2158 BEGIN 2159 2161 2167 2170 2173 2174 2175 Extensible Provisioning Protocol v1.0 schema. 2176 2177 2179 2182 2184 2188 2189 2190 2191 2192 2193 2194 2195 2196 2198 2202 2203 2204 2205 2206 2207 2209 2210 2212 2215 2216 2217 2218 2219 2220 2222 2225 2226 2227 2229 2231 2233 2235 2236 2238 2242 2243 2244 2245 2247 2249 2250 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2263 2264 2265 2266 2267 2268 2269 2271 2272 2273 2275 2277 2279 2281 2282 2284 2285 2286 2288 2290 2292 2294 2296 2297 2299 2300 2301 2303 2304 2306 2307 2308 2309 2310 2311 2313 2314 2315 2316 2317 2318 2319 2320 2321 2323 2324 2325 2326 2327 2328 2330 2333 2334 2335 2338 2339 2341 2342 2343 2345 2346 2348 2351 2352 2353 2354 2355 2356 2358 2361 2362 2363 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2380 2382 2383 2385 2391 2392 2393 2394 2395 2397 2398 2399 2401 2402 2403 2404 2405 2406 2408 2409 2410 2411 2412 2413 2415 2418 2419 2420 2421 2422 2424 2425 2426 2428 2430 2431 2433 2436 2437 2439 2440 2442 2443 2444 2445 2446 2447 2449 2452 2453 2454 2455 2456 2458 2460 2461 2462 2463 2464 2465 2466 2467 2468 2470 2474 2475 2476 2477 2478 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2491 2496 2497 2498 2499 2500 2502 2503 2504 2506 2507 2508 2510 2511 2512 2513 2514 2515 2517 2520 2521 2522 2524 2526 2528 2530 2531 2532 2534 2535 2536 2537 2539 2541 2542 2544 2546 2547 2548 2549 2550 2551 2553 2554 2555 2556 2557 2559 2560 2561 2563 2564 2566 2567 2568 2569 2571 2572 2573 2575 2576 2577 2579 2581 2582 2584 2586 2588 2591 2592 2593 2594 2596 2597 2598 2600 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2641 2644 2645 END 2647 4.2 Shared Structure Schema 2649 BEGIN 2650 2652 2657 2658 2659 Extensible Provisioning Protocol v1.0 2660 shared structures schema. 2661 2662 2664 2667 2668 2669 2670 2672 2673 2674 2675 2677 2678 2679 2680 2681 2683 2686 2687 2688 2689 2690 2691 2692 2694 2695 2696 2697 2698 2699 2701 2704 2705 2706 2707 2708 2709 2711 2714 2715 2716 2717 2718 2719 2721 2724 2725 2726 2727 2728 2730 2733 2734 2735 2736 2737 2739 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2753 2756 2757 END 2759 5. Internationalization Considerations 2761 EPP is represented in XML, which provides native support for encoding 2762 information using the Unicode character set and its more compact 2763 representations including UTF-8. Compliant XML processors are 2764 REQUIRED to understand both UTF-8 and UTF-16. Though XML includes 2765 provisions to identify other character set encodings through use of an 2766 "encoding" attribute in an declaration, EPP use with character 2767 sets other than UTF-8 is NOT RECOMMENDED. 2769 EPP includes a provision for returning a human-readable message with 2770 every result code. This document describes result codes in English, 2771 but the actual text returned with a result MAY be provided in a 2772 language negotiated when a session is established. Languages other 2773 than English MUST be noted through specification of a "lang" attribute 2774 for each message. Valid values for the "lang" attribute and "lang" 2775 negotiation elements are described in [RFC3066]. 2777 All date-time values presented via EPP MUST be expressed in Universal 2778 Coordinated Time using the Gregorian calendar. XML Schema allows use 2779 of time zone identifiers to indicate offsets from the zero meridian, 2780 but this option MUST NOT be used with EPP. The extended date-time 2781 form defined in [DATE-TIME] MUST be used to represent date-time values 2782 as XML Schema does not support truncated date-time forms. 2784 6. IANA Considerations 2786 This document uses URNs to describe XML namespaces and XML schemas 2787 conforming to a registry mechanism described in [IETF-XML]. Four URI 2788 assignments are requested. 2790 Registration request for the EPP namespace: 2792 URI: urn:ietf:params:xml:ns:epp-1.0 2794 Registrant Contact: See the "Author's Address" section of this 2795 document. 2797 XML: None. Namespace URIs do not represent an XML specification. 2799 Registration request for the EPP XML schema: 2801 URI: urn:ietf:params:xml:schema:epp-1.0 2803 Registrant Contact: See the "Author's Address" section of this 2804 document. 2806 XML: See the "Base Schema" section of this document. 2808 Registration request for the EPP shared structure namespace: 2810 URI: urn:ietf:params:xml:ns:eppcom-1.0 2812 Registrant Contact: See the "Author's Address" section of this 2813 document. 2815 XML: None. Namespace URIs do not represent an XML specification. 2817 Registration request for the EPP shared structure XML schema: 2819 URI: urn:ietf:params:xml:schema:eppcom-1.0 2821 Registrant Contact: See the "Author's Address" section of this 2822 document. 2824 XML: See the "Shared Structure Schema" section of this document. 2826 7. Security Considerations 2828 EPP provides only simple client authentication services. A passive 2829 attack is sufficient to recover client identifiers and passwords, 2830 allowing trivial command forgery. Protection against most common 2831 attacks and more robust security services MUST be provided by other 2832 protocol layers. 2834 EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] 2835 to provide a simple application-layer authentication service. Where 2836 the PLAIN SASL mechanism specifies provision of an authorization 2837 identifier, authentication identifier, and password as a single string 2838 separated by ASCII NUL characters, EPP specifies use of a combined 2839 authorization and authentication identifier and a password provided as 2840 distinct XML elements. 2842 Repeated password guessing attempts can be discouraged by limiting the 2843 number of attempts that can be attempted on an open 2844 connection. A server MAY close an open connection if multiple 2845 attempts are made with either an invalid client identifier, an invalid 2846 password, or both an invalid client identifier and an invalid 2847 password. 2849 EPP uses authentication information associated with objects to confirm 2850 object transfer authority. Authentication information exchanged 2851 between EPP clients and third party entities MUST be exchanged using a 2852 facility that provides privacy and integrity services to protect 2853 against unintended disclosure and modification while in transit. 2855 8. Acknowledgements 2857 This document was originally written as an individual submission 2858 Internet-Draft. The provreg working group later adopted it as a 2859 working group document and provided many invaluable comments and 2860 suggested improvements. The author wishes to acknowledge the efforts 2861 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 2862 editorial contributions. 2864 Specific suggestions that have been incorporated into this document 2865 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 2866 Dave Crocker, Ayesha Damaraju, Sheer El-Showk, James Gould, John 2867 Immordino, Dan Kohn, Klaus Malorny, Dan Manley, Michael Mealling, 2868 Patrick Mevzek, Andrew Newton, Budi Rahardjo, Asbjorn Steira, Rick 2869 Wesson, and Jay Westerdal. 2871 9. References 2873 Normative References: 2875 [GRRP] S. Hollenbeck: "Generic Registry-Registrar Protocol 2876 Requirements", work in progress. 2878 [DATE-TIME] G. Klyne, C. Newman: "Date and Time on the Internet: 2879 Timestamps", work in progress. 2881 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 2883 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 2884 Requirement Levels", BCP 14, RFC 2119, March 1997. 2886 [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646", 2887 RFC 2279, January 1998. 2889 [RFC3023] M. Murata et al.: "XML Media Types", RFC 3023, January 2001. 2891 [RFC3066] H. Alvestrand: "Tags for the Identification of Languages", 2892 BCP 47, RFC 3066, January 2001. 2894 Informative References: 2896 [P3P] Editor M. Marchiori: "The Platform for Privacy Preferences 1.0 2897 (P3P1.0) Specification", W3C Working Draft 28 September 2001. 2899 [RFC821] J. Postel: "Simple Mail Transfer Protocol", RFC 821, August 2900 1982. 2902 [RFC2595] C. Newman: "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2903 June 1999. 2905 [XML] Editors T. Bray et al.: "Extensible Markup Language (XML) 1.0 2906 (Second Edition)", W3C Recommendation 6 October 2000. 2908 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 2909 W3C Recommendation 2 May 2001. 2911 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 2912 Datatypes", W3C Recommendation 2 May 2001. 2914 10. Author's Address 2916 Scott Hollenbeck 2917 VeriSign Global Registry Services 2918 21345 Ridgetop Circle 2919 Dulles, VA 20166-6503 2920 USA 2921 shollenbeck@verisign.com 2923 A. Revisions From Previous Version 2925 (Note to RFC editor: please remove this section completely before 2926 publication as an RFC.) 2928 -05 to -06 (WG last call updates): 2930 Fixed typos. 2932 Updated data collection policy description and elements based on last 2933 call comments. Added P3P reference. 2935 Changed description of element in responses to note that this 2936 element is used to return client-specified elements that caused an 2937 error condition. 2939 Fixed text in section 2.8.2 to note that is used to determine 2940 if an object can be provisioned within a repository, not if an object 2941 is "known". 2943 Changed return structure in section 2.8.2.3 and description of 2944 response code 1301. 2946 Modified description text slightly to note that servers must 2947 create service messages for all clients involved in an operation. 2949 Changed ROID regex pattern to allow the "_" character. 2951 Fixed a schema error that limited child elements to a 2952 single extension. 2954 Fixed another schema error that limited version numbers to single 2955 digits. 2957 Changed some lower-case "must"s, "may"s, etc. to avoid confusion with 2958 RFC 2119 directives. 2960 Separated references into normative and informative subsections. 2962 Removed references to ISO 639 since RFC 3066 is already cited. 2964 Replaced reference to ISO 8601 with an IMPP I-D that will hopefully be 2965 an RFC soon. 2967 Added nonEmptyTokenType definition to the shared schema. 2969 B. Full Copyright Statement 2971 Copyright (C) The Internet Society 2002. All Rights Reserved. 2973 This document and translations of it may be copied and furnished to 2974 others, and derivative works that comment on or otherwise explain it 2975 or assist in its implementation may be prepared, copied, published and 2976 distributed, in whole or in part, without restriction of any kind, 2977 provided that the above copyright notice and this paragraph are 2978 included on all such copies and derivative works. However, this 2979 document itself may not be modified in any way, such as by removing 2980 the copyright notice or references to the Internet Society or other 2981 Internet organizations, except as needed for the purpose of developing 2982 Internet standards in which case the procedures for copyrights defined 2983 in the Internet Standards process must be followed, or as required to 2984 translate it into languages other than English. 2986 The limited permissions granted above are perpetual and will not be 2987 revoked by the Internet Society or its successors or assigns. 2989 This document and the information contained herein is provided on an 2990 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2991 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2992 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2993 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2994 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2996 Acknowledgement 2998 Funding for the RFC Editor function is currently provided by the 2999 Internet Society. 3001 C: Object Mapping Template 3003 This appendix describes a recommended outline for documenting the EPP 3004 mapping of an object. Documents that describe EPP object mappings 3005 SHOULD describe the mapping in a format similar to the one used here. 3006 Additional sections are required if the object mapping is written in 3007 Internet-Draft or RFC format. 3009 1. Introduction 3011 Provide an introduction that describes the object and an overview of 3012 the mapping to EPP. 3014 2. Object Attributes 3016 Describe the attributes associated with the object, including 3017 references to syntax specifications as appropriate. Examples of 3018 object attributes include a name or identifier and dates associated 3019 with modification events. 3021 3. EPP Command Mapping 3023 3.1 EPP Query Commands 3025 3.1.1 EPP Command 3027 Describe the object-specific mappings required to implement the EPP 3028 command. Include both sample commands and sample responses. 3030 3.1.2 EPP Command 3032 Describe the object-specific mappings required to implement the EPP 3033 command. Include both sample commands and sample responses. 3035 3.1.3 EPP Command 3037 Describe the object-specific mappings required to implement the EPP 3038 command. Include both sample commands and sample responses. 3040 3.1.4 EPP Command 3042 Describe the object-specific mappings required to implement the EPP 3043 query command. Include both sample commands and sample 3044 responses. 3046 3.2 EPP Transform Commands 3048 3.2.1 EPP Command 3049 Describe the object-specific mappings required to implement the EPP 3050 command. Include both sample commands and sample responses. 3051 Describe the status of the object with respect to time, including 3052 expected client and server behavior if a validity period is used. 3054 3.2.2 EPP Command 3056 Describe the object-specific mappings required to implement the EPP 3057 command. Include both sample commands and sample responses. 3059 3.2.3 EPP Command 3061 Describe the object-specific mappings required to implement the EPP 3062 command. Include both sample commands and sample responses. 3064 3.2.4 EPP Command 3066 Describe the object-specific mappings required to implement the EPP 3067 command. Include both sample commands and sample 3068 responses. 3070 3.2.5 EPP Command 3072 Describe the object-specific mappings required to implement the EPP 3073 command. Include both sample commands and sample responses. 3075 4. Formal Syntax 3077 Provide the XML schema for the object mapping. An XML DTD MUST NOT be 3078 used as DTDs do not provide sufficient support for XML namespaces and 3079 strong data typing. 3081 D: Media Type Registration: application/epp+xml 3083 MIME media type name: application 3085 MIME subtype name: epp+xml 3087 Mandatory parameters: none 3089 Optional parameters: Same as the charset parameter of application/xml 3090 as specified in [RFC3023]. 3092 Encoding considerations: Same as the encoding considerations of 3093 application/xml as specified in [RFC3023]. 3095 Security considerations: This type has all of the security 3096 considerations described in [RFC3023] plus the considerations 3097 specified in the Security Considerations section of this document. 3099 Interoperability considerations: XML has proven to be interoperable 3100 across WebDAV clients and servers, and for import and export from 3101 multiple XML authoring tools. For maximum interoperability, 3102 validating processors are recommended. Although non-validating 3103 processors can be more efficient, they are not required to handle all 3104 features of XML. For further information, see sub-section 2.9 3105 "Standalone Document Declaration" and section 5 "Conformance" of 3106 [XML]. 3108 Published specification: This document. 3110 Applications which use this media type: EPP is device-, platform-, and 3111 vendor-neutral and is supported by multiple service providers. 3113 Additional information: If used, magic numbers, fragment identifiers, 3114 base URIs, and use of the BOM should be as specified in [RFC3023]. 3116 Magic number(s): None. File extension(s): .xml Macintosh File Type 3117 Code(s): "TEXT" 3119 Person and email address for further information: See the "Author's 3120 Address" section of this document. 3122 Intended usage: COMMON 3124 Author/Change controller: IETF