idnits 2.17.1 draft-ietf-provreg-epp-09.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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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. 'IETF-XML' ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2781 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Downref: Normative reference to an Informational RFC: RFC 3375 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'P3P' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 March 11, 2003 Expires: September 11, 2003 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 Transport Mapping Considerations ............................ 7 55 2.2 Protocol Identification ..................................... 8 56 2.3 Hello Format ................................................ 8 57 2.4 Greeting Format ............................................. 8 58 2.5 Command Format .............................................. 12 59 2.6 Response Format ............................................. 13 60 2.7 Protocol Extension Framework ................................ 18 61 2.7.1 Protocol Extension ........................................ 18 62 2.7.2 Object Extension .......................................... 19 63 2.7.3 Command-Response Extension ................................ 20 64 2.8 Object Identification ....................................... 21 65 2.9 Protocol Commands ........................................... 21 66 2.9.1 Session Management Commands ............................... 21 67 2.9.1.1 EPP Command ..................................... 22 68 2.9.1.2 EPP Command .................................... 24 69 2.9.2 Query Commands ............................................ 25 70 2.9.2.1 EPP Command ..................................... 26 71 2.9.2.2 EPP Command ...................................... 28 72 2.9.2.3 EPP Command ...................................... 29 73 2.9.2.4 EPP Query Command ............................ 34 74 2.9.3 Object Transform Commands ................................. 35 75 2.9.3.1 EPP Command .................................... 36 76 2.9.3.2 EPP Command .................................... 37 77 2.9.3.3 EPP Command ..................................... 38 78 2.9.3.4 EPP Command .................................. 40 79 2.9.3.5 EPP Command .................................... 43 80 3. Result Codes ................................................. 46 81 4. Formal Syntax ................................................ 52 82 4.1 Base Schema ................................................. 52 83 4.2 Shared Structure Schema ..................................... 62 84 5. Internationalization Considerations .......................... 65 85 6. IANA Considerations .......................................... 66 86 7. Security Considerations ...................................... 67 87 8. Acknowledgements ............................................. 68 88 9. References ................................................... 69 89 10. Author's Address ............................................ 70 90 A. Full Copyright Statement ..................................... 71 91 B: Object Mapping Template ...................................... 72 92 C: Media Type Registration: application/epp+xml ................. 74 93 D. Revisions From Previous Version .............................. 75 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 [RFC3375]. 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 all 113 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 2. Protocol Description 130 EPP is a stateful XML protocol that can be layered over multiple 131 transport protocols. Protected using lower-layer security protocols, 132 clients exchange identification, authentication, and option 133 information, and then engage in a series of client-initiated 134 command-response exchanges. All EPP commands are atomic (there is no 135 partial success or partial failure) and designed so that they can 136 be made idempotent (executing a command more than once has the same 137 net effect on system state as successfully executing the command once). 139 EPP provides four basic service elements: service discovery, commands, 140 responses, and an extension framework that supports definition of 141 managed objects and the relationship of protocol requests and 142 responses to those objects. 144 An EPP server MUST respond to client-initiated communication (which 145 can be either a lower-layer connection request or an EPP service 146 discovery message) by returning a greeting to a client. A server MUST 147 promptly respond to each EPP command with a coordinated response that 148 describes the results of processing the command. The following server 149 state machine diagram illustrates the message exchange process in 150 detail: 152 | 153 V 154 +-----------------+ +-----------------+ 155 | Waiting for | Connected | Prepare | 156 | Client |----------------->| Greeting | 157 +-----------------+ or +-----------------+ 158 ^ | 159 | Close Connection Send | 160 | or Idle Greeting | 161 +-----------------+ V 162 | End | Timeout +-----------------+ 163 | Session |<-----------------| Waiting for | 164 +-----------------+ | Client | 165 ^ ^ ^ Send +-------->| Authentication | 166 | | | Response | +-----------------+ 167 | | | +--------------+ | 168 | | | | Prepare Fail | | 169 | | +-----| Response | | Received 170 | | Send +--------------+ V 171 | | 2501 ^ +-----------------+ 172 | | Response | | Processing | 173 | | +---------| | 174 | | Auth Fail +-----------------+ 175 | | | 176 | | | Auth OK 177 | | V 178 | | Timeout +-----------------+ 179 | +----------------------------| Waiting for | 180 | | Command | 181 | Send x5xx +-----------------+ 182 | Response +-----------------+ Send ^ | 183 +-----------| Prepare | Response | | Command 184 | Response |----------+ | Received 185 +-----------------+ V 186 ^ +-----------------+ 187 Command | | Processing | 188 Processed +----------| Command | 189 +-----------------+ 191 Figure 1: EPP Server State Machine 193 EPP commands fall into three categories: session management commands, 194 query commands, and data transform commands. Session management 195 commands are used to establish and end persistent sessions with an EPP 196 server. Query commands are used to perform read-only object 197 information retrieval operations. Transform commands are used to 198 perform read-write object management operations. 200 Commands are processed by a server in the order they are received from 201 a client. Though an immediate response confirming receipt and 202 processing of the command is produced by the server, the protocol 203 includes features that allow for offline review of transform commands 204 before the requested action is actually completed. In such situations 205 the response from the server MUST clearly note that the command has 206 been received and processed, but the requested action is pending. The 207 state of the corresponding object MUST clearly reflect processing of 208 the pending action. The server MUST also notify the client when 209 offline processing of the action has been completed. Object mappings 210 SHOULD describe standard formats for notices that describe completion 211 of offline processing. 213 EPP uses XML namespaces to provide an extensible object management 214 framework and to identify schemas required for XML instance parsing 215 and validation. These namespaces and schema definitions are used to 216 identify both the base protocol schema and the schemas for managed 217 objects. 219 All XML instances SHOULD begin with an declaration to identify 220 the version of XML that is being used, optionally identify use of the 221 character encoding used, and optionally provide a hint to an XML 222 parser that an external schema file is needed to validate the XML 223 instance. Conformant XML parsers recognize both UTF-8 (defined in RFC 224 2279 [RFC2279]) and UTF-16 (defined in RFC 2781 [RFC2781]); per RFC 225 2277 [RFC2277] UTF-8 is the RECOMMENDED character encoding for use 226 with EPP. 228 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 229 UTF-8 is the default encoding assumed by XML in the absence of an 230 "encoding" attribute or a byte order mark (BOM), thus the "encoding" 231 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 232 used. 234 Normative section 4.3.3 and non-normative appendix F of [XML] describe 235 use of a BOM to identify the character encoding in the absence of an 236 XML declaration or encapsulating headers. Appendix F includes a BOM 237 to represent UTF-8 encoding, though section 4.3.3 notes that a BOM is 238 not needed to identify UTF-8 encoding. Section 4.3.3 was later 239 amended (see [XMLE]) to clarify that a BOM MAY be used to identify 240 UTF-8 encoding. EPP clients and servers MUST accept a UTF-8 BOM if 241 present, though emitting a UTF-8 BOM is NOT RECOMMENDED. 243 Example XML declarations: 245 247 249 251 253 2.1 Transport Mapping Considerations 255 As described previously, EPP can be layered over multiple transport 256 protocols. There are, however, a common set of considerations that 257 MUST be addressed by any transport mapping defined for EPP. These 258 include: 260 - The transport mapping MUST preserve command order. 262 - The transport mapping MUST address the relationship between sessions 263 and the client-server connection concept. 265 - The transport mapping MUST preserve the stateful nature of the 266 protocol. 268 - The transport mapping MUST frame data units. 270 - The transport mapping MUST be onto a transport such as TCP [RFC793] 271 or SCTP [RFC2960] that provides congestion avoidance that follows RFC 272 2914 [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] 273 or BEEP [RFC3080], then the performance issues need to take into 274 account issues of overload, server availability and so forth. 276 - The transport mapping MUST ensure reliability. 278 - The transport mapping MUST explicitly allow or prohibit pipelining. 280 Pipelining, also known as command streaming, is when a client sends 281 multiple commands to a server without waiting for each corresponding 282 response. After sending the commands, the client waits for the 283 responses to arrive in the order corresponding to the completed 284 commands. Performance gains can sometimes be realized with 285 pipelining, especially with high latency transports, but there are 286 additional considerations associated with defining a transport mapping 287 that supports pipelining: 289 - Commands MUST be processed independent of each other. 291 - Depending on the transport, pipelining MAY be possible in the form 292 of sending a complete session in a well-defined "batch". 294 - The transport mapping MUST describe how an error in processing a 295 command affects continued operation of the session. 297 A transport mapping MUST explain how all of these requirements are met 298 given the transport protocol being used to exchange data. 300 2.2 Protocol Identification 302 All EPP XML instances MUST begin with an element. This element 303 identifies the start of an EPP protocol element, the namespace used 304 within the protocol, and the location of the protocol schema. The 305 start element and the associated ending element MUST be 306 applied to all structures sent by both clients and servers. 308 Example "start" and "end" EPP elements: 310 314 316 2.3 Hello Format 318 EPP MAY be carried over both connection-oriented and connection-less 319 transport protocols. An EPP client MAY request a from an 320 EPP server at any time by sending a to a server. Use of this 321 element is essential in a connection-less environment where a server 322 can not return a in response to a client-initiated 323 connection. An EPP MUST be an empty element with no child 324 elements. 326 Example : 328 C: 329 C: 333 C: 334 C: 336 2.4 Greeting Format 338 An EPP server responds to a successful connection and element 339 by returning a element to the client. An EPP greeting 340 contains the following elements: 342 - An element that contains the name of the server. 344 - An element that contains the server's current date and time 345 in UTC. 347 - An element that identifies the services supported by the 348 server, including: 350 - One or more elements that identify the protocol versions 351 supported by the server. 353 - One or more elements that contain the identifiers of the 354 text response languages known by the server. Language identifiers 355 MUST be structured as documented in [RFC3066]. 357 - One or more elements that contain namespace URIs 358 representing the objects that the server is capable of managing. A 359 server MAY limit object management privileges on a per-client basis. 361 - An OPTIONAL element that contains one or more 362 elements that contain namespace URIs representing object 363 extensions supported by the server. 365 - A (data collection policy) element that contains child 366 elements used to describe the server's privacy policy for data 367 collection and management. Policy implications usually extend 368 beyond the client-server relationship. Both clients and servers can 369 have relationships with other entities that need to know the server 370 operator's data collection policy to make informed provisioning 371 decisions. Policy information MUST be disclosed to provisioning 372 entities, though the method of disclosing policy data outside of 373 direct protocol interaction is beyond the scope of this 374 specification. Child elements include the following: 376 - An element that describes the access provided by the 377 server to the client on behalf of the originating data source. 378 The element MUST contain one of the following child 379 elements: 381 : Access is given to all identified data. 383 : No access is provided to identified data. 385 : Data is not persistent, so no access is possible. 387 : Access is given to identified data relating to 388 individuals and organizational entities. 390 : Access is given to identified data relating 391 to individuals, organizational entities, and other data of a 392 non-personal nature. 394 : Access is given to other identified data of a non- 395 personal nature. 397 - One or more elements that describe data collection 398 purposes, data recipients, and data retention. Each 399 element MUST contain a element, a element, 400 and a element. 402 The element MUST contain one or more of the following 403 child elements that describe the purposes for which data is 404 collected: 406 : Administrative purposes. Information can be used 407 for administrative and technical support of the provisioning 408 system. 410 : Contact for marketing purposes. Information can 411 be used to contact individuals, through a communications 412 channel other than the protocol, for the promotion of a 413 product or service. 415 : Object provisioning purposes. Information can be 416 used to identify objects and inter-object relationships. 418 : Other purposes. Information may be used in other 419 ways not captured by the above definitions. 421 The element MUST contain one or more of the 422 following child elements that describes the recipients of 423 collected data: 425 : Other entities following unknown practices. 427 : Server operator and/or entities acting as agents or 428 entities for whom the server operator is acting as an agent. 429 An agent in this instance is defined as a third party that 430 processes data only on behalf of the service provider for the 431 completion of the stated purposes. The element 432 contains an OPTIONAL element that can be used to 433 describe the recipient. 435 : Public forums. 437 : Other entities following server practices. 439 : Unrelated third parties. 441 The element MUST contain one of the following child 442 elements that describes data retention practices: 444 : Data persists per business practices. 446 : Data persists indefinitely. 448 : Data persists per legal requirements. 450 : Data is not persistent, and is not retained for more 451 than a brief period of time necessary to make use of it during 452 the course of a single online interaction. 454 : Data persists to meet the stated purpose. 456 - An OPTIONAL element that describes the lifetime of the 457 policy. The element MUST contain one of the following 458 child elements: 460 : The policy is valid from the current date and time 461 until it expires on the specified date and time. 463 : The policy is valid from the current date and time 464 until the end of the specified duration. 466 Data collection policy elements are based on work described in the 467 World Wide Web Consortium's Platform for Privacy Preferences [P3P] 468 specification. 470 Example greeting: 472 S: 473 S: 477 S: 478 S: Example EPP server epp.example.com 479 S: 2000-06-08T22:00:00.0Z 480 S: 481 S: 1.0 482 S: en 483 S: fr 484 S: urn:ietf:params:xml:ns:obj1 485 S: urn:ietf:params:xml:ns:obj2 486 S: urn:ietf:params:xml:ns:obj3 487 S: 488 S: http://custom/obj1ext-1.0 489 S: 490 S: 491 S: 492 S: 493 S: 494 S: 495 S: 496 S: 497 S: 498 S: 499 S: 500 S: 502 2.5 Command Format 504 An EPP client interacts with an EPP server by sending a command to the 505 server and receiving a response from the server. In addition to the 506 standard EPP elements, an EPP command contains the following elements: 508 - A command element whose tag corresponds to one of the valid EPP 509 commands described in this document. The command element MAY contain 510 either protocol-specified or object-specified child elements. 512 - An OPTIONAL element that MAY be used for server-defined 513 command extensions. 515 - An OPTIONAL (client transaction identifier) element that 516 MAY be used to uniquely identify the command to the client. Clients 517 are responsible for maintaining their own transaction identifier space 518 to ensure uniqueness. 520 Example command with object-specified child elements: 522 C: 523 C: 527 C: 528 C: 529 C: 531 C: example 532 C: 533 C: 534 C: ABC-12345 535 C: 536 C: 538 2.6 Response Format 540 An EPP server responds to a client command by returning a response to 541 the client. EPP commands are atomic, so a command will either succeed 542 completely or fail completely. Success and failure results MUST NOT 543 be mixed. In addition to the standard EPP elements, an EPP response 544 contains the following elements: 546 - One or more elements that document the success or failure 547 of command execution. If the command was processed successfully, only 548 one element MUST be returned. If the command was not 549 processed successfully, multiple elements MAY be returned to 550 document failure conditions. Each element contains the 551 following attribute and child elements: 553 - A "code" attribute whose value is a four-digit, decimal number 554 that describes the success or failure of the command. 556 - A element containing a human-readable description of the 557 response code. The language of the response is identified via an 558 OPTIONAL "lang" attribute. If not specified, the default attribute 559 value MUST be "en" (English). 561 - Zero or more OPTIONAL elements that identify a client- 562 provided element (including XML tag and value) that caused a server 563 error condition. 565 - Zero or more OPTIONAL elements that can be used to 566 provide additional error diagnostic information, including: 568 - A element that identifies a client-provided element 569 (including XML tag and value) that caused a server error 570 condition. 572 - A element containing a human-readable message that 573 describes the reason for the error. The language of the response 574 is identified via an OPTIONAL "lang" attribute. If not specified, 575 the default attribute value MUST be "en" (English). 577 - An OPTIONAL element that describes messages queued for client 578 retrieval. A element MUST NOT be present if there are no 579 messages queued for client retrieval. A element MAY be present 580 in responses to EPP commands other than the command if messages 581 are queued for retrieval. A element MUST be present in 582 responses to the EPP command if messages are queued for 583 retrieval. The element contains the following attributes: 585 - A "count" attribute that describes the number of messages that 586 exist in the queue. 588 - An "id" attribute used to uniquely identify the message at the 589 head of the queue. 591 The element contains the following OPTIONAL child elements 592 that MUST be returned in response to a request command and 593 MUST NOT be returned in response to any other command, including a 594 acknowledgement: 596 - A element that contains the date and time that the message 597 was enqueued. 599 - A element containing a human-readable message. The language 600 of the response is identified via an OPTIONAL "lang" attribute. If 601 not specified, the default attribute value MUST be "en" (English). 602 This element MAY contain XML content for formatting purposes, but 603 the XML content is not specified by the protocol and will thus not 604 be processed for validity. 606 - An OPTIONAL (response data) element that contains child 607 elements specific to the command and associated object. 609 - An OPTIONAL element that MAY be used for server-defined 610 response extensions. 612 - A (transaction identifier) element containing the transaction 613 identifier assigned by the server to the command for which the 614 response is being returned. The transaction identifier is formed 615 using the associated with the command if supplied by the 616 client and a (server transaction identifier) that is assigned 617 by and unique to the server. 619 Transaction identifiers provide command-response synchronization 620 integrity. They SHOULD be logged, retained, and protected to ensure 621 that both the client and the server have consistent temporal and state 622 management records. 624 Example response without or : 626 S: 627 S: 631 S: 632 S: 633 S: Command completed successfully 634 S: 635 S: 636 S: ABC-12345 637 S: 54321-XYZ 638 S: 639 S: 640 S: 641 Example response with : 643 S: 644 S: 648 S: 649 S: 650 S: Command completed successfully 651 S: 652 S: 653 S: 655 S: example 656 S: 657 S: 658 S: 659 S: ABC-12345 660 S: 54321-XYZ 661 S: 662 S: 663 S: 664 Example response with error value elements: 666 S: 667 S: 671 S: 672 S: 673 S: Parameter value range error 674 S: 675 S: 2525 676 S: 677 S: 678 S: 679 S: Parameter value syntax error 680 S: 681 S: ex(ample 682 S: 683 S: 684 S: 685 S: abc.ex(ample 686 S: 687 S: Invalid character found. 688 S: 689 S: 690 S: 691 S: ABC-12345 692 S: 54321-XYZ 693 S: 694 S: 695 S: 696 Example response with notice of waiting server messages: 698 S: 699 S: 703 S: 704 S: 705 S: Command completed successfully 706 S: 707 S: 708 S: 709 S: ABC-12345 710 S: 54321-XYZ 711 S: 712 S: 713 S: 715 Command success or failure MUST NOT be assumed if no response is 716 returned or if a returned response is malformed. Protocol idempotency 717 ensures the safety of retrying a command in cases of response delivery 718 failure. 720 2.7 Protocol Extension Framework 722 EPP provides an extension framework that allows features to be added 723 at the protocol, object, and command-response levels. 725 2.7.1 Protocol Extension 727 The EPP extension framework allows for definition of new protocol 728 elements identified using XML namespace notation with a reference to 729 an XML schema that defines the namespace. The element that 730 identifies the beginning of a protocol instance includes multiple 731 child element choices, one of which is an element whose 732 children define the extension. For example, a protocol extension 733 element would be described in generic terms as follows: 735 C: 736 C: 737 C: 738 C: 740 C: 741 C: 742 C: 743 C: 745 This document does not define mappings for specific extensions. 746 Extension specifications MUST be described in separate documents that 747 define the objects and operations subject to the extension. 749 2.7.2 Object Extension 751 EPP provides an extensible object management framework that defines 752 the syntax and semantics of protocol operations applied to a managed 753 object. This framework pushes the definition of each protocol 754 operation into the context of a specific object, providing the ability 755 to add mappings for new objects without having to modify the base 756 protocol. 758 Protocol elements that contain data specific to objects are identified 759 using XML namespace notation with a reference to an XML schema that 760 defines the namespace. The schema for EPP supports use of dynamic 761 object schemas on a per-command and per-response basis. For example, 762 the start of an object-specific command element would be described in 763 generic terms as follows: 765 C: 766 C: 768 C: 769 C: 770 C: 772 An object-specific response element would be described similarly: 774 S: 775 S: 777 S: 778 S: 779 S: 781 This document does not define mappings for specific objects. The 782 mapping of EPP to an object MUST be described in separate documents 783 that specifically address each command and response in the context of 784 the object. A suggested object mapping outline is included as an 785 appendix to this document. 787 2.7.3 Command-Response Extension 789 EPP provides a facility for protocol command and response extensions. 790 Protocol commands and responses MAY be extended by an 791 element that contains additional elements whose syntax and semantics 792 are not explicitly defined by EPP or an EPP object mapping. This 793 element is OPTIONAL. Extensions are typically defined by agreement 794 between client and server and MAY be used to extend EPP for unique 795 operational needs. A server-extended command element would be 796 described in generic terms as follows: 798 C: 799 C: 800 C: 801 C: 803 C: 804 C: 805 C: 806 C: 807 C: 808 C: 809 C: 811 An server-extended response element would be described similarly: 813 S: 814 S: 815 S: Command completed successfully 816 S: 817 S: 818 S: 819 S: 820 S: 821 S: ABC-12345 822 S: 54321-XYZ 823 S: 824 S: 826 This document does not define any specific server extensions. The 827 mapping of server extensions to EPP MUST be described in separate 828 documents that specifically address extended commands and responses in 829 the server's operational context. 831 2.8 Object Identification 833 Some objects, such as name servers and contacts, can have utility in 834 multiple repositories. However, maintaining disjoint copies of object 835 information in multiple repositories can lead to inconsistencies that 836 have adverse consequences for the Internet. For example, changing a 837 name server name in one repository, but not in a second repository 838 that refers to the server for domain name delegation, can produce 839 unexpected DNS query results. 841 Globally unique identifiers can help facilitate object information 842 sharing between repositories. A globally unique identifier MUST be 843 assigned to every object when the object is created; the identifier 844 MUST be returned to the client as part of any request to retrieve the 845 detailed attributes of an object. Specific identifier values are a 846 matter of repository policy, but they SHOULD be constructed according 847 to the following algorithm: 849 a) Divide the provisioning repository world into a number of object 850 repository classes. 852 b) Each repository within a class is assigned an identifier that is 853 maintained by IANA. 855 (c) Each repository is responsible for assigning a unique local 856 identifier for each object within the repository. 858 (d) The globally unique identifier is a concatenation of the local 859 identifier, followed by a hyphen ("-", ASCII value 0x002D), followed 860 by the repository identifier. 862 2.9 Protocol Commands 864 EPP provides commands to manage sessions, retrieve object information, 865 and perform transformation operations on objects. All EPP commands 866 are atomic and designed so that they can be made idempotent, either 867 succeeding completely or failing completely and producing predictable 868 results in case of repeated execution. This section describes each 869 EPP command, including examples with representative server responses. 871 2.9.1 Session Management Commands 873 EPP provides two commands for session management: to establish 874 a session with a server, and to end a session with a server. 875 The command establishes an ongoing server session that 876 preserves client identity and authorization information during the 877 duration of the session. 879 2.9.1.1 EPP Command 881 The EPP command is used to establish a session with an EPP 882 server in response to a greeting issued by the server. A 883 command MUST be sent to a server before any other EPP command to 884 establish an ongoing session. A server operator MAY limit the number 885 of failed login attempts N, 1 <= N <= infinity, after which a login 886 failure results in the connection to the server (if a connection 887 exists) being closed. 889 A client identifier and initial password MUST be created on the server 890 before a client can successfully complete a command. The 891 client identifier and initial password MUST be delivered to the client 892 using an out-of-band method that protects the identifier and password 893 from inadvertent disclosure. 895 In addition to the standard EPP command elements, the command 896 contains the following child elements: 898 - A element that contains the client identifier assigned to the 899 client by the server. 901 - A element that contains the client's plain text password. The 902 value of this element is case sensitive. 904 - An OPTIONAL element that contains a new plain text password 905 to be assigned to the client for use with subsequent commands. 906 The value of this element is case sensitive. 908 - An element that contains the following child elements: 910 - A element that contains the protocol version to be used 911 for the command or ongoing server session. 913 - A element that contains the text response language to be 914 used for the command or ongoing server session commands. 916 The values of the and elements MUST exactly match 917 one of the values presented in the EPP greeting. 919 - A element that contains one or more elements that 920 contain namespace URIs representing the objects to be managed during 921 the session. The element MAY contain an OPTIONAL 922 element that contains one or more elements 923 that identify object extensions to be used during the session. 925 The PLAIN SASL mechanism presented in [RFC2595] describes a format for 926 providing a user identifier, an authorization identifier, and a 927 password as part of a single plain text string. The EPP 928 authentication mechanism is similar, though EPP does not require a 929 session-level authorization identifier and the user identifier and 930 password are separated into distinct XML elements. Additional 931 identification and authorization schemes MUST be provided at other 932 protocol layers to provide more robust security services. 934 Example command: 936 C: 937 C: 941 C: 942 C: 943 C: ClientX 944 C: foo-BAR2 945 C: bar-FOO2 946 C: 947 C: 1.0 948 C: en 949 C: 950 C: 951 C: urn:ietf:params:xml:ns:obj1 952 C: urn:ietf:params:xml:ns:obj2 953 C: urn:ietf:params:xml:ns:obj3 954 C: 955 C: http://custom/obj1ext-1.0 956 C: 957 C: 958 C: 959 C: ABC-12345 960 C: 961 C: 963 When a command has been processed successfully, a server MUST 964 respond with an EPP response with no element. If 965 successful, the server will respond by creating and maintaining a new 966 session that SHOULD be terminated by a future command. 968 Example response: 970 S: 971 S: 975 S: 976 S: 977 S: Command completed successfully 978 S: 979 S: 980 S: ABC-12345 981 S: 54321-XYZ 982 S: 983 S: 984 S: 986 The EPP command is used to establish a session with an EPP 987 server. A command MUST be rejected if received within the 988 bounds of an existing session. This action MUST be open to all 989 authorized clients. 991 2.9.1.2 EPP Command 993 The EPP command is used to end a session with an EPP server. 994 The command MUST be represented as an empty element with no 995 child elements. 997 A server MAY end a session due to client inactivity or excessive 998 client session longevity. The parameters for determining excessive 999 client inactivity or session longevity are a matter of server policy 1000 and are not specified by this protocol. 1002 Transport mappings MUST explicitly describe any connection-oriented 1003 processing that takes place after processing a command and 1004 ending a session. 1006 Example command: 1008 C: 1009 C: 1013 C: 1014 C: 1015 C: ABC-12345 1016 C: 1017 C: 1019 When a command has been processed successfully, a server MUST 1020 respond with an EPP response with no element. If 1021 successful, the server MUST also end the current session. 1023 Example response: 1025 S: 1026 S: 1030 S: 1031 S: 1032 S: Command completed successfully; ending session 1033 S: 1034 S: 1035 S: ABC-12345 1036 S: 54321-XYZ 1037 S: 1038 S: 1039 S: 1041 The EPP command is used to end a session with an EPP server. 1042 A command MUST be rejected if the command has not been 1043 preceded by a successful command. This action MUST be open to 1044 all authorized clients. 1046 2.9.2 Query Commands 1048 EPP provides four commands to retrieve object information: to 1049 determine if an object can be provisioned within a repository, 1050 to retrieve detailed information associated with a known object, 1051 to receive service notifications from the server, and 1052 to retrieve object transfer status information. 1054 2.9.2.1 EPP Command 1056 The EPP command is used to determine if an object can be 1057 provisioned within a repository. It provides a hint that allows a 1058 client to anticipate the success or failure of provisioning an object 1059 using the command as object provisioning requirements are 1060 ultimately a matter of server policy. 1062 The elements needed to identify an object are object-specific, so the 1063 child elements of the command are specified using the EPP 1064 extension framework. In addition to the standard EPP command 1065 elements, the command contains the following child elements: 1067 - An object-specific element that identify the objects to 1068 be queried. Multiple objects of the same type MAY be queried within a 1069 single command. 1071 Example command: 1073 C: 1074 C: 1078 C: 1079 C: 1080 C: 1082 C: example1 1083 C: example2 1084 C: example3 1085 C: 1086 C: 1087 C: ABC-12346 1088 C: 1089 C: 1091 When a command has been processed successfully, a server MUST 1092 respond with an EPP element that MUST contain a child 1093 element that identifies the object namespace and the location of the 1094 object schema. The child elements of the element are 1095 object-specific, though the EPP element MUST contain a child 1096 element that contains one or more (check data) 1097 elements. Each elements contains the following child 1098 elements: 1100 - An object-specific element that identifies the queried object. This 1101 element MUST contain an "avail" attribute whose value indicates object 1102 availability (can it be provisioned or not) at the moment the 1103 command was completed. A value of "1" or "true" means that the object 1104 can be provisioned. A value of "0" or "false" means that the object 1105 can not be provisioned. 1107 - An OPTIONAL element that MAY be provided when an object 1108 can not be provisioned. If present, this element contains server- 1109 specific text to help explain why the object can not be provisioned. 1110 This text MUST be represented in the response language previously 1111 negotiated with the client; an OPTIONAL "lang" attribute MAY be 1112 present to identify the language if the negotiated value is something 1113 other than the default value of "en" (English). 1115 Example response: 1117 S: 1118 S: 1122 S: 1123 S: 1124 S: Command completed successfully 1125 S: 1126 S: 1127 S: 1129 S: 1130 S: example1 1131 S: 1132 S: 1133 S: example2 1134 S: In use 1135 S: 1136 S: 1137 S: example3 1138 S: 1139 S: 1140 S: 1141 S: 1142 S: ABC-12346 1143 S: 54322-XYZ 1144 S: 1145 S: 1146 S: 1148 The EPP command is used to determine if an object can be 1149 provisioned within a repository. This action MUST be open to all 1150 authorized clients. 1152 2.9.2.2 EPP Command 1154 The EPP command is used to retrieve information associated with 1155 an existing object. The elements needed to identify an object and the 1156 type of information associated with an object are both object- 1157 specific, so the child elements of the command are specified 1158 using the EPP extension framework. In addition to the standard EPP 1159 command elements, the command contains the following child 1160 elements: 1162 - An object-specific element that identifies the object to 1163 be queried. 1165 Example command: 1167 C: 1168 C: 1172 C: 1173 C: 1174 C: 1176 C: 1177 C: 1178 C: 1179 C: ABC-12346 1180 C: 1181 C: 1183 When an command has been processed successfully, a server MUST 1184 respond with an EPP element that MUST contain a child 1185 element that identifies the object namespace and the location of the 1186 object schema and the Repository Object Identifier (ROID) that was 1187 assigned to the object when the object was created. Other child 1188 elements of the element are object-specific. 1190 Example response: 1192 S: 1193 S: 1197 S: 1198 S: 1199 S: Command completed successfully 1200 S: 1201 S: 1202 S: 1204 S: EXAMPLE1-REP 1205 S: 1206 S: 1207 S: 1208 S: 1209 S: ABC-12346 1210 S: 54322-XYZ 1211 S: 1212 S: 1213 S: 1215 The EPP command is used to retrieve information associated with 1216 an existing object. This action SHOULD be limited to authorized 1217 clients; restricting this action to the sponsoring client is 1218 RECOMMENDED. 1220 2.9.2.3 EPP Command 1222 The EPP command is used to discover and retrieve service 1223 messages queued by a server for individual clients. If the message 1224 queue is not empty, a successful response to a command MUST 1225 return the first message from the message queue. Each response 1226 returned from the server includes a server-unique message identifier 1227 that MUST be provided to acknowledge receipt of the message, and a 1228 counter that indicates the number of messages in the queue. After a 1229 message has been received by the client, the client MUST respond to 1230 the message with an explicit acknowledgement to confirm that the 1231 message has been received. A server MUST dequeue the message and 1232 decrement the queue counter after receiving acknowledgement from the 1233 client, making the next message in the queue (if any) available for 1234 retrieval. 1236 Servers can occasionally perform actions on objects that are not in 1237 direct response to a client request, or an action taken by one client 1238 can indirectly involve a second client. Examples of such actions 1239 include deletion upon expiration, automatic renewal upon expiration, 1240 and transfer coordination; other types of service information MAY be 1241 defined as a matter of server policy. Service messages MUST be 1242 created for all clients affected by an action on an object. For 1243 example, actions MUST be reported to both the client that 1244 requests an object transfer and the client that has the authority to 1245 approve or reject the transfer request. 1247 Message queues can consume server resources if clients do not retrieve 1248 and acknowledge messages on a regular basis. Servers MAY implement 1249 other mechanisms to dequeue and deliver messages if queue maintenance 1250 needs exceed server resource consumption limits. Server operators 1251 SHOULD consider time-sensitivity and resource management factors when 1252 selecting a delivery method for service information because some 1253 message types can be reasonably delivered using non-protocol methods 1254 that require fewer server resources. 1256 Some of the information returned in response to a command can 1257 be object-specific, so some child elements of the response MAY 1258 be specified using the EPP extension framework. The command 1259 MUST be represented as an empty element with no child elements. An 1260 "op" attribute with value "req" is REQUIRED to retrieve the first 1261 message from the server message queue. An "op" attribute (with value 1262 "ack") and a "msgID" attribute (whose value corresponds to the value 1263 of the "id" attribute copied from the element in the message 1264 being acknowledged) are REQUIRED to acknowledge receipt of a message. 1266 Example command: 1268 C: 1269 C: 1273 C: 1274 C: 1275 C: ABC-12345 1276 C: 1277 C: 1279 The returned result code notes that a message has been dequeued and 1280 returned in response to a command. 1282 Example response with object-specific information: 1284 S: 1285 S: 1289 S: 1290 S: 1291 S: Command completed successfully; ack to dequeue 1292 S: 1293 S: 1294 S: 2000-06-08T22:00:00.0Z 1295 S: Transfer requested. 1296 S: 1297 S: 1298 S: 1302 S: example.com 1303 S: pending 1304 S: ClientX 1305 S: 2000-06-08T22:00:00.0Z 1306 S: ClientY 1307 S: 2000-06-13T22:00:00.0Z 1308 S: 2002-09-08T22:00:00.0Z 1309 S: 1310 S: 1311 S: 1312 S: ABC-12345 1313 S: 54321-XYZ 1314 S: 1315 S: 1316 S: 1318 A client MUST acknowledge each response to dequeue the message and 1319 make subsequent messages available for retrieval. 1321 Example acknowledgement command: 1323 C: 1324 C: 1328 C: 1329 C: 1330 C: ABC-12346 1331 C: 1332 C: 1334 A acknowledgement response notes the number of messages 1335 remaining in the queue and the ID of the next message available for 1336 retrieval. 1338 Example acknowledgement response: 1340 S: 1341 S: 1345 S: 1346 S: 1347 S: Command completed successfully 1348 S: 1349 S: 1350 S: 1351 S: ABC-12346 1352 S: 54322-XYZ 1353 S: 1354 S: 1355 S: 1357 Service messages can also be returned without object information. 1359 Example response with mixed message content and without 1360 object-specific information: 1362 S: 1363 S: 1367 S: 1368 S: 1369 S: Command completed successfully; ack to dequeue 1370 S: 1371 S: 1372 S: 2000-06-08T22:10:00.0Z 1373 S: Credit balance low. 1374 S: 1005 1375 S: 1376 S: 1377 S: 1378 S: ABC-12346 1379 S: 54321-XYZ 1380 S: 1381 S: 1382 S: 1384 The returned result code and message is used to note an empty server 1385 message queue. 1387 Example response to note an empty message queue: 1389 S: 1390 S: 1394 S: 1395 S: 1396 S: Command completed successfully; no messages 1397 S: 1398 S: 1399 S: ABC-12346 1400 S: 54321-XYZ 1401 S: 1402 S: 1403 S: 1405 The EPP command is used to discover and retrieve client service 1406 messages from a server. This action SHOULD be limited to authorized 1407 clients; queuing service messages and limiting queue access on a per- 1408 client basis is RECOMMENDED. 1410 2.9.2.4 EPP Query Command 1412 The EPP command provides a query operation that allows a 1413 client to determine real-time status of pending and completed transfer 1414 requests. The elements needed to identify an object that is the 1415 subject of a transfer request are object-specific, so the child 1416 elements of the query command are specified using the EPP 1417 extension framework. In addition to the standard EPP command 1418 elements, the command contains an "op" attribute with value 1419 "query", and the following child elements: 1421 - An object-specific element that identifies the object 1422 whose transfer status is requested. 1424 Transfer status is typically considered sensitive information by the 1425 clients involved in the operation. Object mappings MUST provide 1426 features to restrict transfer queries to authorized clients, such as 1427 by requiring authorization information as part of the request. 1429 Example query command: 1431 C: 1432 C: 1436 C: 1437 C: 1438 C: 1440 C: 1441 C: 1442 C: 1443 C: ABC-12346 1444 C: 1445 C: 1447 When a query command has been processed successfully, a 1448 server MUST respond with an EPP element that MUST contain a 1449 child element that identifies the object namespace and the location of 1450 the object schema. The child elements of the element are 1451 object-specific, but they MUST include elements that identify the 1452 object, the status of the transfer, the identifier of the client that 1453 requested the transfer, the date and time that the request was made, 1454 the identifier of the client that is authorized to act on the request, 1455 the date and time by which an action is expected, and an OPTIONAL date 1456 and time noting changes in the object's validity period (if 1457 applicable) that occur as a result of the transfer. 1459 Example query response: 1461 S: 1462 S: 1466 S: 1467 S: 1468 S: Command completed successfully 1469 S: 1470 S: 1471 S: 1473 S: example 1474 S: pending 1475 S: ClientX 1476 S: 2000-06-08T22:00:00.0Z 1477 S: ClientY 1478 S: 2000-06-13T22:00:00.0Z 1479 S: 2002-09-08T22:00:00.0Z 1480 S: 1481 S: 1482 S: 1483 S: ABC-12346 1484 S: 54322-XYZ 1485 S: 1486 S: 1487 S: 1489 The EPP command provides a query operation that allows a 1490 client to determine real-time status of pending and completed transfer 1491 requests. This action SHOULD be limited to authorized clients; 1492 restricting queries to the requesting and responding clients is 1493 RECOMMENDED. Object transfer MAY be unavailable or limited by 1494 object-specific policies. 1496 2.9.3 Object Transform Commands 1498 EPP provides five commands to transform objects: to create an 1499 instance of an object with a server, to remove an instance of 1500 an object from a server, to extend the validity period of an 1501 object, to change information associated with an object, and 1502 to manage changes in client sponsorship of an object. 1504 2.9.3.1 EPP Command 1506 The EPP command is used to create an instance of an object. 1507 An object can be created for an indefinite period of time, or an 1508 object can be created for a specific validity period. The EPP mapping 1509 for an object MUST describe the status of an object with respect to 1510 time, to include expected client and server behavior if a validity 1511 period is used. 1513 The elements needed to identify an object and associated attributes 1514 are object-specific, so the child elements of the command are 1515 specified using the EPP extension framework. In addition to the 1516 standard EPP command elements, the command contains the 1517 following child elements: 1519 - An object-specific element that identifies the object 1520 to be created and the elements that are required to create the object. 1522 Example command: 1524 C: 1525 C: 1529 C: 1530 C: 1531 C: 1533 C: 1534 C: 1535 C: 1536 C: ABC-12345 1537 C: 1538 C: 1540 When a command has been processed successfully, a server MAY 1541 respond with an EPP element that MUST contain a child 1542 element that identifies the object namespace and the location of the 1543 object schema. The child elements of the element are 1544 object-specific. 1546 Example response with : 1548 S: 1549 S: 1553 S: 1554 S: 1555 S: Command completed successfully 1556 S: 1557 S: 1558 S: 1560 S: 1561 S: 1562 S: 1563 S: 1564 S: ABC-12345 1565 S: 54321-XYZ 1566 S: 1567 S: 1568 S: 1570 The EPP command is used to create an instance of an object. 1571 This action SHOULD be limited to authorized clients and MAY be 1572 restricted on a per-client basis. 1574 2.9.3.2 EPP Command 1576 The EPP command is used to remove an instance of an existing 1577 object. The elements needed to identify an object are object- 1578 specific, so the child elements of the command are specified 1579 using the EPP extension framework. In addition to the standard EPP 1580 command elements, the command contains the following child 1581 elements: 1583 - An object-specific element that identifies the object 1584 to be deleted. 1586 Example command: 1588 C: 1589 C: 1593 C: 1594 C: 1595 C: 1597 C: 1598 C: 1599 C: 1600 C: ABC-12346 1601 C: 1602 C: 1604 When a command has been processed successfully, a server MAY 1605 respond with an EPP element that MUST contain a child 1606 element that identifies the object namespace and the location of the 1607 object schema. The child elements of the element are 1608 object-specific. 1610 Example response without : 1612 S: 1613 S: 1617 S: 1618 S: 1619 S: Command completed successfully 1620 S: 1621 S: 1622 S: ABC-12346 1623 S: 54322-XYZ 1624 S: 1625 S: 1626 S: 1628 The EPP command is used to remove an instance of an existing 1629 object. This action SHOULD be limited to authorized clients; 1630 restricting this action to the sponsoring client is RECOMMENDED. 1632 2.9.3.3 EPP Command 1633 The EPP command is used to extend the validity period of an 1634 existing object. The elements needed to identify and extend the 1635 validity period of an object are object-specific, so the child 1636 elements of the command are specified using the EPP extension 1637 framework. In addition to the standard EPP command elements, the 1638 command contains the following child elements: 1640 - An object-specific element that identifies the object to 1641 be renewed and the elements that are required to extend the validity 1642 period of the object. 1644 Example command: 1646 C: 1647 C: 1651 C: 1652 C: 1653 C: 1655 C: 1656 C: 1657 C: 1658 C: ABC-12346 1659 C: 1660 C: 1662 When a command has been processed successfully, a server MAY 1663 respond with an EPP element that MUST contain a child 1664 element that identifies the object namespace and the location of the 1665 object schema. The child elements of the element are 1666 object-specific. 1668 Example response with : 1670 S: 1671 S: 1675 S: 1676 S: 1677 S: Command completed successfully 1678 S: 1679 S: 1680 S: 1682 S: 1683 S: 1684 S: 1685 S: 1686 S: ABC-12346 1687 S: 54322-XYZ 1688 S: 1689 S: 1690 S: 1692 The EPP command is used to extend the validity period of an 1693 existing object. This action SHOULD be limited to authorized clients; 1694 restricting this action to the sponsoring client is RECOMMENDED. 1695 Object renewal MAY be unavailable or limited by object-specific 1696 policies. 1698 2.9.3.4 EPP Command 1700 The EPP command is used to manage changes in client 1701 sponsorship of an existing object. Clients can initiate a transfer 1702 request, cancel a transfer request, approve a transfer request, and 1703 reject a transfer request using the "op" command attribute. 1705 A client who wishes to assume sponsorship of a known object from 1706 another client uses the command with the value of the "op" 1707 attribute set to "request". Once a transfer has been requested, the 1708 same client can cancel the request using a command with the 1709 value of the "op" attribute set to "cancel". A request to cancel the 1710 transfer MUST be sent to the server before the current sponsoring 1711 client either approves or rejects the transfer request and before the 1712 server automatically processes the request due to responding client 1713 inactivity. 1715 Once a transfer request has been received by the server, the server 1716 MUST notify the current sponsoring client of the requested transfer by 1717 queuing a service message for retrieval via the command. The 1718 current status of a pending command for any object can be 1719 found using the query command. Transfer service messages 1720 MUST include the object-specific elements specified for 1721 command responses. 1723 The current sponsoring client MAY explicitly approve or reject the 1724 transfer request. The client can approve the request using a 1725 command with the value of the "op" attribute set to 1726 "approve". The client can reject the request using a 1727 command with the value of the "op" attribute set to "reject". 1729 A server MAY automatically approve or reject all transfer requests 1730 that are not explicitly approved or rejected by the current sponsoring 1731 client within a fixed amount of time. The amount of time to wait for 1732 explicit action and the default server behavior are local matters not 1733 specified by EPP, but they SHOULD be documented in a server-specific 1734 profile document that describes default server behavior for client 1735 information. 1737 Objects eligible for transfer MUST have associated authorization 1738 information that MUST be provided to complete a command. 1739 The type of authorization information required is object-specific; 1740 passwords or more complex mechanisms based on public key cryptography 1741 are typical. 1743 The elements needed to identify and complete the transfer of an object 1744 are object-specific, so the child elements of the command 1745 are specified using the EPP extension framework. In addition to the 1746 standard EPP command elements, the command contains the 1747 following child elements: 1749 - An object-specific element that identifies the object 1750 to be transferred and the elements that are required to process the 1751 transfer command. 1753 Example command: 1755 C: 1756 C: 1760 C: 1761 C: 1762 C: 1764 C: 1765 C: 1766 C: 1767 C: ABC-12346 1768 C: 1769 C: 1771 When a command has been processed successfully, a server 1772 MUST respond with an EPP element that MUST contain a child 1773 element that identifies the object namespace and the location of the 1774 object schema. The child elements of the element are 1775 object-specific, but they MUST include elements that identify the 1776 object, the status of the transfer, the identifier of the client that 1777 requested the transfer, the date and time that the request was made, 1778 the identifier of the client that is authorized to act on the request, 1779 the date and time by which an action is expected, and an OPTIONAL date 1780 and time noting changes in the object's validity period (if 1781 applicable) that occur as a result of the transfer. 1783 Example response with : 1785 S: 1786 S: 1790 S: 1791 S: 1792 S: Command completed successfully 1793 S: 1794 S: 1795 S: 1797 S: example 1798 S: pending 1799 S: ClientX 1800 S: 2000-06-08T22:00:00.0Z 1801 S: ClientY 1802 S: 2000-06-13T22:00:00.0Z 1803 S: 2002-09-08T22:00:00.0Z 1804 S: 1805 S: 1806 S: 1807 S: ABC-12346 1808 S: 54322-XYZ 1809 S: 1810 S: 1811 S: 1813 The EPP command is used to manage changes in client 1814 sponsorship of an existing object. This action SHOULD be limited to 1815 authorized clients; restricting requests to a client other 1816 than the current sponsoring client, approval requests to 1817 the current sponsoring client, and cancellation requests to 1818 the original requesting client is RECOMMENDED. Object transfer MAY be 1819 unavailable or limited by object-specific policies. 1821 2.9.3.5 EPP Command 1823 The EPP command is used to change information associated with 1824 an existing object. The elements needed to identify and modify an 1825 object are object-specific, so the child elements of the 1826 command are specified using the EPP extension framework. In addition 1827 to the standard EPP command elements, the command contains 1828 the following child elements: 1830 - An object-specific element that identifies the object 1831 to be updated and the elements that are required to modify the object. 1832 Object-specific elements MUST identify values to be added, values to 1833 be removed, or values to be changed. 1835 Example command: 1837 C: 1838 C: 1842 C: 1843 C: 1844 C: 1846 C: 1847 C: 1848 C: 1849 C: ABC-12346 1850 C: 1851 C: 1853 When an command has been processed successfully, a server MAY 1854 respond with an EPP element that MUST contain a child 1855 element that identifies the object namespace and the location of the 1856 object schema. The child elements of the element are 1857 object-specific. 1859 Example response without : 1861 S: 1862 S: 1866 S: 1867 S: 1868 S: Command completed successfully 1869 S: 1870 S: 1871 S: ABC-12346 1872 S: 54322-XYZ 1873 S: 1874 S: 1875 S: 1877 The EPP command is used to change information associated with 1878 an existing object. This action SHOULD be limited to authorized 1879 clients; restricting this action to the sponsoring client is 1880 RECOMMENDED. 1882 3. Result Codes 1884 EPP result codes are based on the theory of reply codes described in 1885 section 4.2.1 of [RFC2821]. EPP uses four decimal digits to describe 1886 the success or failure of each EPP command. Each of the digits of the 1887 reply have special significance. 1889 The first digit denotes command success or failure. The second digit 1890 denotes the response category, such as command syntax or security. 1891 The third and fourth digits provide explicit response detail within 1892 each response category. 1894 There are two values for the first digit of the reply code: 1896 1yzz Positive completion reply. The command has been accepted and 1897 processed by the system without error. 1899 2yzz Negative completion reply. The command was not accepted and 1900 the requested action did not occur. 1902 The second digit groups responses into one of six specific categories: 1904 x0zz Protocol Syntax 1905 x1zz Implementation-specific Rules 1906 x2zz Security 1907 x3zz Data Management 1908 x4zz Server System 1909 x5zz Connection Management 1911 The third and fourth digits provide response detail within the 1912 categories defined by the first and second digits. Specific result 1913 codes are listed in the table below. 1915 Every EPP response MUST include a result code and a human-readable 1916 description of the result code. The language used to represent the 1917 description MAY be identified using an instance of the "lang" 1918 attribute within the element. If not specified, the default 1919 language is English, identified as "en". A description of the 1920 structure of valid values for the "lang" attribute is described in 1921 [RFC3066]. 1923 Response text MAY be translated into other languages, though the 1924 translation MUST preserve the meaning of the code as described here. 1925 Response code values MUST NOT be changed when translating text. 1927 Response text in the table below is enclosed in quotes to clearly mark 1928 the beginning and ending of each response string. Quotes MUST NOT be 1929 used to delimit these strings when returning response text via the 1930 protocol. 1932 Successful command completion responses: 1934 Code Response text in English 1935 ___________________________________ 1937 1000 "Command completed successfully" 1938 This is the usual response code for a successfully completed 1939 command that is not addressed by any other 1xxx-series response 1940 code. 1942 1001 "Command completed successfully; action pending" 1943 This response code MUST be returned when responding to a command 1944 the requires offline activity before the requested action can be 1945 completed. See section 2 for a description of other processing 1946 requirements. 1948 1300 "Command completed successfully; no messages" 1949 This response code MUST be returned when responding to a 1950 request command and the server message queue is empty. 1952 1301 "Command completed successfully; ack to dequeue" 1953 This response code MUST be returned when responding to a 1954 request command and a message has been retrieved from the server 1955 message queue. 1957 1500 "Command completed successfully; ending session" 1958 This response code MUST be returned when responding to a successful 1959 command. 1961 Command error responses: 1963 Code Response text in English 1964 ___________________________________ 1966 2000 "Unknown command" 1967 This response code MUST be returned when a server receives a command 1968 element that is not defined by EPP. 1970 2001 "Command syntax error" 1971 This response code MUST be returned when a server receives an 1972 improperly formed command element. 1974 2002 "Command use error" 1975 This response code MUST be returned when a server receives a properly 1976 formed command element, but the command can not be executed due to a 1977 sequencing or context error. For example, a command can not 1978 be executed without having first completed a command. 1980 2003 "Required parameter missing" 1981 This response code MUST be returned when a server receives a command 1982 for which a required parameter value has not been provided. 1984 2004 "Parameter value range error" 1985 This response code MUST be returned when a server receives a command 1986 parameter whose value is outside the range of values specified 1987 by the protocol. The error value SHOULD be returned via a 1988 element in the EPP response. 1990 2005 "Parameter value syntax error" 1991 This response code MUST be returned when a server receives a command 1992 containing a parameter whose value is improperly formed. The error 1993 value SHOULD be returned via a element in the EPP response. 1995 2100 "Unimplemented protocol version" 1996 This response code MUST be returned when a server receives a command 1997 element specifying a protocol version that is not implemented by the 1998 server. 2000 2101 "Unimplemented command" 2001 This response code MUST be returned when a server receives a valid 2002 EPP command element that is not implemented by the server. For 2003 example, a command can be unimplemented for certain object 2004 types. 2006 2102 "Unimplemented option" 2007 This response code MUST be returned when a server receives a valid 2008 EPP command element that contains a protocol option that is not 2009 implemented by the server. 2011 2103 "Unimplemented extension" 2012 This response code MUST be returned when a server receives a valid 2013 EPP command element that contains a protocol command extension that 2014 is not implemented by the server. 2016 2104 "Billing failure" 2017 This response code MUST be returned when a server attempts to execute 2018 a billable operation and the command can not be completed due to a 2019 client billing failure. 2021 2105 "Object is not eligible for renewal" 2022 This response code MUST be returned when a client attempts to 2023 an object that is not eligible for renewal in accordance with server 2024 policy. 2026 2106 "Object is not eligible for transfer" 2027 This response code MUST be returned when a client attempts to 2028 an object that is not eligible for transfer in accordance 2029 with server policy. 2031 2200 "Authentication error" 2032 This response code MUST be returned when a server notes an error when 2033 validating client credentials. 2035 2201 "Authorization error" 2036 This response code MUST be returned when a server notes a client 2037 authorization error when executing a command. This error is used to 2038 note that a client lacks privileges to execute the requested command. 2040 2202 "Invalid authorization information" 2041 This response code MUST be returned when a server receives invalid 2042 command authorization information required to confirm authorization to 2043 execute a command. This error is used to note that a client has the 2044 privileges required to execute the requested command, but the 2045 authorization information provided by the client does not match the 2046 authorization information archived by the server. 2048 2300 "Object pending transfer" 2049 This response code MUST be returned when a server receives a command 2050 to transfer an object that is pending transfer due to an earlier 2051 transfer request. 2053 2301 "Object not pending transfer" 2054 This response code MUST be returned when a server receives a command 2055 to confirm, reject, or cancel the transfer an object when no command 2056 has been made to transfer the object. 2058 2302 "Object exists" 2059 This response code MUST be returned when a server receives a command 2060 to create an object that already exists in the repository. 2062 2303 "Object does not exist" 2063 This response code MUST be returned when a server receives a command 2064 to query or transform an object that does not exist in the repository. 2066 2304 "Object status prohibits operation" 2067 This response code MUST be returned when a server receives a command 2068 to transform an object that can not be completed due to server policy 2069 or business practices. For example, a server can disallow 2070 commands under terms and conditions that are matters of local policy, 2071 or the server might have received a command for an object 2072 whose status prohibits deletion. 2074 2305 "Object association prohibits operation" 2075 This response code MUST be returned when a server receives a command 2076 to transform an object that can not be completed due to dependencies 2077 on other objects that are associated with the target object. For 2078 example, a server can disallow commands while an object has 2079 active associations with other objects. 2081 2306 "Parameter value policy error" 2082 This response code MUST be returned when a server receives a command 2083 containing a parameter value that is syntactically valid, but 2084 semantically invalid due to local policy. For example, the server 2085 can support a subset of a range of valid protocol parameter values. 2086 The error value SHOULD be returned via a element in the EPP 2087 response. 2089 2307 "Unimplemented object service" 2090 This response code MUST be returned when a server receives a command 2091 to operate on an object service that is not supported by the server. 2093 2308 "Data management policy violation" 2094 This response code MUST be returned when a server receives a command 2095 whose execution results in a violation of server data management 2096 policies. For example, removing all attribute values or object 2097 associations from an object might be a violation of a server's data 2098 management policies. 2100 2400 "Command failed" 2101 This response code MUST be returned when a server is unable to 2102 execute a command due to an internal server error that is not related 2103 to the protocol. The failure can be transient. The server MUST keep 2104 any ongoing session active. 2106 2500 "Command failed; server closing connection" 2107 This response code MUST be returned when a server receives a command 2108 that can not be completed due to an internal server error that is not 2109 related to the protocol. The failure is not transient, and will 2110 cause other commands to fail as well. The server MUST end the 2111 active session and close the existing connection. 2113 2501 "Authentication error; server closing connection" 2114 This response code MUST be returned when a server notes an error when 2115 validating client credentials and a server-defined limit on the number 2116 of allowable failures has been exceeded. The server MUST close the 2117 existing connection. 2119 2502 "Session limit exceeded; server closing connection" 2120 This response code MUST be returned when a server receives a 2121 command, and the command can not be completed because the client has 2122 exceeded a system-defined limit on the number of sessions that the 2123 client can establish. It might be possible to establish a session by 2124 ending existing unused sessions and closing inactive connections. 2126 4. Formal Syntax 2128 EPP is specified in XML Schema notation. The formal syntax presented 2129 here is a complete schema representation of EPP suitable for automated 2130 validation of EPP XML instances. 2132 Two schemas are presented here. The first schema is the base EPP 2133 schema. The second schema defines elements and structures that can be 2134 used by both the base EPP schema and object mapping schemas. The 2135 BEGIN and END tags are not part of the schema; they are used to note 2136 the beginning and ending of the schema for URI registration purposes. 2138 4.1 Base Schema 2140 BEGIN 2141 2143 2149 2152 2155 2156 2157 Extensible Provisioning Protocol v1.0 schema. 2158 2159 2161 2164 2166 2170 2171 2172 2173 2174 2175 2176 2177 2178 2180 2184 2185 2186 2187 2188 2189 2190 2191 2193 2196 2197 2198 2199 2200 2201 2203 2206 2207 2208 2210 2212 2214 2216 2217 2219 2222 2223 2224 2225 2227 2229 2230 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2243 2244 2245 2246 2247 2248 2249 2251 2252 2253 2255 2257 2259 2261 2262 2264 2265 2266 2268 2271 2273 2275 2277 2278 2280 2281 2282 2284 2285 2287 2288 2289 2290 2291 2292 2294 2295 2296 2297 2298 2299 2300 2301 2302 2304 2305 2306 2307 2308 2309 2311 2314 2315 2316 2318 2320 2322 2323 2324 2326 2327 2329 2332 2333 2334 2335 2336 2337 2339 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2358 2360 2361 2363 2366 2367 2368 2369 2370 2372 2373 2374 2375 2377 2378 2379 2380 2381 2382 2384 2385 2386 2387 2388 2389 2391 2392 2393 2395 2397 2398 2400 2403 2404 2406 2407 2409 2410 2411 2412 2413 2414 2416 2420 2421 2422 2423 2424 2426 2428 2429 2430 2431 2432 2433 2434 2435 2436 2438 2443 2444 2445 2446 2447 2449 2450 2451 2453 2454 2455 2457 2458 2459 2460 2461 2462 2464 2467 2468 2469 2471 2473 2475 2477 2478 2479 2481 2482 2483 2484 2485 2486 2487 2488 2489 2491 2493 2494 2495 2496 2497 2498 2500 2501 2502 2503 2504 2505 2507 2508 2509 2511 2513 2514 2516 2518 2520 2521 2522 2524 2525 2527 2529 2532 2533 2534 2535 2537 2538 2539 2541 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2583 2586 2587 END 2589 4.2 Shared Structure Schema 2591 BEGIN 2592 2594 2599 2600 2601 Extensible Provisioning Protocol v1.0 2602 shared structures schema. 2603 2604 2606 2609 2610 2611 2612 2613 2614 2615 2617 2618 2619 2620 2621 2623 2626 2627 2628 2629 2630 2631 2632 2634 2635 2636 2637 2638 2639 2641 2644 2645 2646 2647 2648 2649 2651 2654 2655 2656 2657 2658 2659 2661 2664 2665 2666 2667 2668 2670 2673 2674 2675 2676 2677 2679 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2693 2696 2697 END 2699 5. Internationalization Considerations 2701 EPP is represented in XML, which provides native support for encoding 2702 information using the Unicode character set and its more compact 2703 representations including UTF-8. Conformant XML processors recognize 2704 both UTF-8 and UTF-16. Though XML includes provisions to identify and 2705 use other character encodings through use of an "encoding" attribute 2706 in an declaration, use of UTF-8 is RECOMMENDED in environments 2707 where parser encoding support incompatibility exists. 2709 EPP includes a provision for returning a human-readable message with 2710 every result code. This document describes result codes in English, 2711 but the actual text returned with a result MAY be provided in a 2712 language negotiated when a session is established. Languages other 2713 than English MUST be noted through specification of a "lang" attribute 2714 for each message. Valid values for the "lang" attribute and "lang" 2715 negotiation elements are described in [RFC3066]. 2717 All date-time values presented via EPP MUST be expressed in Universal 2718 Coordinated Time using the Gregorian calendar. XML Schema allows use 2719 of time zone identifiers to indicate offsets from the zero meridian, 2720 but this option MUST NOT be used with EPP. The extended date-time 2721 form using upper case "T" and "Z" characters defined in [RFC3339] MUST 2722 be used to represent date-time values as XML Schema does not support 2723 truncated date-time forms or lower case "T" and "Z" characters. 2725 6. IANA Considerations 2727 This document uses URNs to describe XML namespaces and XML schemas 2728 conforming to a registry mechanism described in [IETF-XML]. Four URI 2729 assignments are requested. 2731 Registration request for the EPP namespace: 2733 URI: urn:ietf:params:xml:ns:epp-1.0 2735 Registrant Contact: See the "Author's Address" section of this 2736 document. 2738 XML: None. Namespace URIs do not represent an XML specification. 2740 Registration request for the EPP XML schema: 2742 URI: urn:ietf:params:xml:schema:epp-1.0 2744 Registrant Contact: See the "Author's Address" section of this 2745 document. 2747 XML: See the "Base Schema" section of this document. 2749 Registration request for the EPP shared structure namespace: 2751 URI: urn:ietf:params:xml:ns:eppcom-1.0 2753 Registrant Contact: See the "Author's Address" section of this 2754 document. 2756 XML: None. Namespace URIs do not represent an XML specification. 2758 Registration request for the EPP shared structure XML schema: 2760 URI: urn:ietf:params:xml:schema:eppcom-1.0 2762 Registrant Contact: See the "Author's Address" section of this 2763 document. 2765 XML: See the "Shared Structure Schema" section of this document. 2767 7. Security Considerations 2769 EPP provides only simple client authentication services. A passive 2770 attack is sufficient to recover client identifiers and passwords, 2771 allowing trivial command forgery. Protection against most common 2772 attacks and more robust security services MUST be provided by other 2773 protocol layers. Specifically, EPP instances MUST be protected using 2774 a transport mechanism or application protocol that provides integrity 2775 and confidentiality. 2777 EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] 2778 to provide a simple application-layer authentication service that 2779 augments or supplements authentication and identification services 2780 that might be available at other protocol layers. Where the PLAIN 2781 SASL mechanism specifies provision of an authorization identifier, 2782 authentication identifier, and password as a single string separated 2783 by ASCII NUL characters, EPP specifies use of a combined authorization 2784 and authentication identifier and a password provided as distinct XML 2785 elements. 2787 Repeated password guessing attempts can be discouraged by limiting the 2788 number of attempts that can be attempted on an open 2789 connection. A server MAY close an open connection if multiple 2790 attempts are made with either an invalid client identifier, an invalid 2791 password, or both an invalid client identifier and an invalid 2792 password. 2794 EPP uses authentication information associated with objects to confirm 2795 object transfer authority. Authentication information exchanged 2796 between EPP clients and third party entities MUST be exchanged using a 2797 facility that provides privacy and integrity services to protect 2798 against unintended disclosure and modification while in transit. 2800 8. Acknowledgements 2802 This document was originally written as an individual submission 2803 Internet-Draft. The provreg working group later adopted it as a 2804 working group document and provided many invaluable comments and 2805 suggested improvements. The author wishes to acknowledge the efforts 2806 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 2807 editorial contributions. 2809 Specific suggestions that have been incorporated into this document 2810 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 2811 Roger Castillo Cortazar, Dave Crocker, Ayesha Damaraju, Sheer El- 2812 Showk, Patrik Faltstrom, James Gould, John Immordino, Dan Kohn, Hong 2813 Liu, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, 2814 Andrew Newton, Budi Rahardjo, Asbjorn Steira, Rick Wesson, and Jay 2815 Westerdal. 2817 9. References 2819 Normative References: 2821 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 2823 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 2824 Requirement Levels", BCP 14, RFC 2119, March 1997. 2826 [RFC2277] H. Alvestrand: "IETF Policy on Character Sets and 2827 Languages", BCP 18, RFC 2277, January 1998. 2829 [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646", 2830 RFC 2279, January 1998. 2832 [RFC2781] P. Hoffman, F. Yergeau: "UTF-16, an encoding of ISO 10646", 2833 RFC 2781, February 2000. 2835 [RFC2914] S. Floyd: "Congestion Control Principles", BCP 41, RFC 2914, 2836 September 2000. 2838 [RFC3023] M. Murata et al.: "XML Media Types", RFC 3023, January 2001. 2840 [RFC3066] H. Alvestrand: "Tags for the Identification of Languages", 2841 BCP 47, RFC 3066, January 2001. 2843 [RFC3339] G. Klyne, C. Newman: "Date and Time on the Internet: 2844 Timestamps", RFC 3339, July 2002. 2846 [RFC3375] S. Hollenbeck: "Generic Registry-Registrar Protocol 2847 Requirements", RFC 3375, September 2002. 2849 [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 2850 (Second Edition)", W3C Recommendation 6 October 2000. 2852 [XMLE] "XML 1.0 Second Edition Specification Errata", E22, 25 July 2853 2001, http://www.w3.org/XML/xml-V10-2e-errata#E22. 2855 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 2856 W3C Recommendation 2 May 2001. 2858 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 2859 Datatypes", W3C Recommendation 2 May 2001. 2861 Informative References: 2863 [P3P] Editor M. Marchiori: "The Platform for Privacy Preferences 1.0 2864 (P3P1.0) Specification", W3C Recommendation 16 April 2002. 2866 [RFC793] J. Postel: "Transmission Control Protocol", STD 7, RFC 793, 2867 September 1981. 2869 [RFC2595] C. Newman: "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2870 June 1999. 2872 [RFC2821] J. Klensin: "Simple Mail Transfer Protocol", RFC 2821, April 2873 2001. 2875 [RFC2960] R. Stewart et al.: "Stream Control Transmission Protocol", 2876 RFC 2960, October 2000. 2878 [RFC3080] M. Rose: "The Blocks Extensible Exchange Protocol Core", RFC 2879 3080, March 2001. 2881 10. Author's Address 2883 Scott Hollenbeck 2884 VeriSign Global Registry Services 2885 21345 Ridgetop Circle 2886 Dulles, VA 20166-6503 2887 USA 2888 shollenbeck@verisign.com 2890 A. Full Copyright Statement 2892 Copyright (C) The Internet Society 2002. All Rights Reserved. 2894 This document and translations of it may be copied and furnished to 2895 others, and derivative works that comment on or otherwise explain it 2896 or assist in its implementation may be prepared, copied, published and 2897 distributed, in whole or in part, without restriction of any kind, 2898 provided that the above copyright notice and this paragraph are 2899 included on all such copies and derivative works. However, this 2900 document itself may not be modified in any way, such as by removing 2901 the copyright notice or references to the Internet Society or other 2902 Internet organizations, except as needed for the purpose of developing 2903 Internet standards in which case the procedures for copyrights defined 2904 in the Internet Standards process must be followed, or as required to 2905 translate it into languages other than English. 2907 The limited permissions granted above are perpetual and will not be 2908 revoked by the Internet Society or its successors or assigns. 2910 This document and the information contained herein is provided on an 2911 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2912 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2913 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2914 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2915 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2917 Acknowledgement 2919 Funding for the RFC Editor function is currently provided by the 2920 Internet Society. 2922 B: Object Mapping Template 2924 This appendix describes a recommended outline for documenting the EPP 2925 mapping of an object. Documents that describe EPP object mappings 2926 SHOULD describe the mapping in a format similar to the one used here. 2927 Additional sections are required if the object mapping is written in 2928 Internet-Draft or RFC format. 2930 1. Introduction 2932 Provide an introduction that describes the object and an overview of 2933 the mapping to EPP. 2935 2. Object Attributes 2937 Describe the attributes associated with the object, including 2938 references to syntax specifications as appropriate. Examples of 2939 object attributes include a name or identifier and dates associated 2940 with modification events. 2942 3. EPP Command Mapping 2944 3.1 EPP Query Commands 2946 3.1.1 EPP Command 2948 Describe the object-specific mappings required to implement the EPP 2949 command. Include both sample commands and sample responses. 2951 3.1.2 EPP Command 2953 Describe the object-specific mappings required to implement the EPP 2954 command. Include both sample commands and sample responses. 2956 3.1.3 EPP Command 2958 Describe the object-specific mappings required to implement the EPP 2959 command. Include both sample commands and sample responses. 2961 3.1.4 EPP Command 2963 Describe the object-specific mappings required to implement the EPP 2964 query command. Include both sample commands and sample 2965 responses. 2967 3.2 EPP Transform Commands 2969 3.2.1 EPP Command 2970 Describe the object-specific mappings required to implement the EPP 2971 command. Include both sample commands and sample responses. 2972 Describe the status of the object with respect to time, including 2973 expected client and server behavior if a validity period is used. 2975 3.2.2 EPP Command 2977 Describe the object-specific mappings required to implement the EPP 2978 command. Include both sample commands and sample responses. 2980 3.2.3 EPP Command 2982 Describe the object-specific mappings required to implement the EPP 2983 command. Include both sample commands and sample responses. 2985 3.2.4 EPP Command 2987 Describe the object-specific mappings required to implement the EPP 2988 command. Include both sample commands and sample 2989 responses. 2991 3.2.5 EPP Command 2993 Describe the object-specific mappings required to implement the EPP 2994 command. Include both sample commands and sample responses. 2996 4. Formal Syntax 2998 Provide the XML schema for the object mapping. An XML DTD MUST NOT be 2999 used as DTDs do not provide sufficient support for XML namespaces and 3000 strong data typing. 3002 C: Media Type Registration: application/epp+xml 3004 MIME media type name: application 3006 MIME subtype name: epp+xml 3008 Mandatory parameters: none 3010 Optional parameters: Same as the charset parameter of application/xml 3011 as specified in [RFC3023]. 3013 Encoding considerations: Same as the encoding considerations of 3014 application/xml as specified in [RFC3023]. 3016 Security considerations: This type has all of the security 3017 considerations described in [RFC3023] plus the considerations 3018 specified in the Security Considerations section of this document. 3020 Interoperability considerations: XML has proven to be interoperable 3021 across WebDAV clients and servers, and for import and export from 3022 multiple XML authoring tools. For maximum interoperability, 3023 validating processors are recommended. Although non-validating 3024 processors can be more efficient, they are not required to handle all 3025 features of XML. For further information, see sub-section 2.9 3026 "Standalone Document Declaration" and section 5 "Conformance" of 3027 [XML]. 3029 Published specification: This document. 3031 Applications which use this media type: EPP is device-, platform-, and 3032 vendor-neutral and is supported by multiple service providers. 3034 Additional information: If used, magic numbers, fragment identifiers, 3035 base URIs, and use of the BOM should be as specified in [RFC3023]. 3037 Magic number(s): None. File extension(s): .xml Macintosh File Type 3038 Code(s): "TEXT" 3040 Person and email address for further information: See the "Author's 3041 Address" section of this document. 3043 Intended usage: COMMON 3045 Author/Change controller: IETF 3047 D. Revisions From Previous Version 3049 (Note to RFC editor: please remove this section completely before 3050 publication as an RFC.) 3052 -08 to -09 (IESG review): 3054 Made the element mandatory in the schema (section 4.1) and 3055 modified the descriptive text in section 2.3. 3057 Reordered the appendices to put this section last so that the RFC 3058 Editor has a little less work to do when removing this section.