idnits 2.17.1 draft-hollenbeck-rfc4930bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4930, but the abstract doesn't seem to directly say this. It does mention RFC4930 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (June 15, 2009) is 5428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4930 (Obsoleted by RFC 5730) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 Obsoletes: 4930 (if approved) June 15, 2009 5 Intended status: Standards Track 6 Expires: December 17, 2009 8 Extensible Provisioning Protocol (EPP) 9 draft-hollenbeck-rfc4930bis-02 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 17, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes an application layer client-server protocol 48 for the provisioning and management of objects stored in a shared 49 central repository. Specified in XML, the protocol defines generic 50 object management operations and an extensible framework that maps 51 protocol operations to objects. This document includes a protocol 52 specification, an object mapping template, and an XML media type 53 registration. This document is intended to obsolete RFC 4930. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 59 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Transport Mapping Considerations . . . . . . . . . . . . . 8 61 2.2. Protocol Identification . . . . . . . . . . . . . . . . . 9 62 2.3. Hello Format . . . . . . . . . . . . . . . . . . . . . . . 9 63 2.4. Greeting Format . . . . . . . . . . . . . . . . . . . . . 9 64 2.5. Command Format . . . . . . . . . . . . . . . . . . . . . . 13 65 2.6. Response Format . . . . . . . . . . . . . . . . . . . . . 14 66 2.7. Protocol Extension Framework . . . . . . . . . . . . . . . 19 67 2.7.1. Protocol Extension . . . . . . . . . . . . . . . . . . 19 68 2.7.2. Object Extension . . . . . . . . . . . . . . . . . . . 19 69 2.7.3. Command-Response Extension . . . . . . . . . . . . . . 20 70 2.8. Object Identification . . . . . . . . . . . . . . . . . . 21 71 2.9. Protocol Commands . . . . . . . . . . . . . . . . . . . . 22 72 2.9.1. Session Management Commands . . . . . . . . . . . . . 22 73 2.9.1.1. EPP Command . . . . . . . . . . . . . . . 22 74 2.9.1.2. EPP Command . . . . . . . . . . . . . . . 25 75 2.9.2. Query Commands . . . . . . . . . . . . . . . . . . . . 26 76 2.9.2.1. EPP Command . . . . . . . . . . . . . . . 26 77 2.9.2.2. EPP Command . . . . . . . . . . . . . . . . 28 78 2.9.2.3. EPP Command . . . . . . . . . . . . . . . . 29 79 2.9.2.4. EPP Query Command . . . . . . . . . . . 33 80 2.9.3. Object Transform Commands . . . . . . . . . . . . . . 35 81 2.9.3.1. EPP Command . . . . . . . . . . . . . . . 35 82 2.9.3.2. EPP Command . . . . . . . . . . . . . . . 37 83 2.9.3.3. EPP Command . . . . . . . . . . . . . . . 38 84 2.9.3.4. EPP Command . . . . . . . . . . . . . . 40 85 2.9.3.5. EPP Command . . . . . . . . . . . . . . . 42 86 3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . 43 87 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 49 88 4.1. Base Schema . . . . . . . . . . . . . . . . . . . . . . . 49 89 4.2. Shared Structure Schema . . . . . . . . . . . . . . . . . 59 90 5. Internationalization Considerations . . . . . . . . . . . . . 61 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 62 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 65 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 97 Appendix A. Object Mapping Template . . . . . . . . . . . . . . . 66 98 Appendix B. Media Type Registration: application/epp+xml . . . . 68 99 Appendix C. Changes from RFC 4930 . . . . . . . . . . . . . . . . 69 101 1. Introduction 103 This document describes specifications for the Extensible 104 Provisioning Protocol (EPP) version 1.0, an XML text protocol that 105 permits multiple service providers to perform object provisioning 106 operations using a shared central object repository. EPP is 107 specified using the Extensible Markup Language (XML) 1.0 as described 108 in [W3C.REC-xml-20040204] and XML Schema notation as described in 109 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 110 EPP meets and exceeds the requirements for a generic registry 111 registrar protocol as described in [RFC3375]. This document is 112 intended to obsolete RFC 4930 [RFC4930]. 114 EPP content is identified by MIME media type application/epp+xml. 115 Registration information for this media type is included in an 116 appendix to this document. 118 EPP is intended for use in diverse operating environments where 119 transport and security requirements vary greatly. It is unlikely 120 that a single transport or security specification will meet the needs 121 of all anticipated operators, so EPP was designed for use in a 122 layered protocol environment. Bindings to specific transport and 123 security protocols are outside the scope of this specification. 125 The original motivation for this protocol was to provide a standard 126 Internet domain name registration protocol for use between domain 127 name registrars and domain name registries. This protocol provides a 128 means of interaction between a registrar's applications and registry 129 applications. It is expected that this protocol will have additional 130 uses beyond domain name registration. 132 XML is case sensitive. Unless stated otherwise, XML specifications 133 and examples provided in this document MUST be interpreted in the 134 character case presented to develop a conforming implementation. 136 1.1. Conventions Used in This Document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 In examples, "C:" represents lines sent by a protocol client and "S:" 143 represents lines returned by a protocol server. Indentation and 144 white space in examples are provided only to illustrate element 145 relationships and are not a REQUIRED feature of this protocol. A 146 protocol client that is authorized to manage an existing object is 147 described as a "sponsoring" client throughout this document. 149 2. Protocol Description 151 EPP is a stateful XML protocol that can be layered over multiple 152 transport protocols. Protected using lower-layer security protocols, 153 clients exchange identification, authentication, and option 154 information, and then engage in a series of client-initiated command- 155 response exchanges. All EPP commands are atomic (there is no partial 156 success or partial failure) and designed so that they can be made 157 idempotent (executing a command more than once has the same net 158 effect on system state as successfully executing the command once). 160 EPP provides four basic service elements: service discovery, 161 commands, responses, and an extension framework that supports 162 definition of managed objects and the relationship of protocol 163 requests and responses to those objects. 165 An EPP server MUST respond to client-initiated communication (which 166 can be either a lower-layer connection request or an EPP service 167 discovery message) by returning a greeting to a client. A server 168 MUST promptly respond to each EPP command with a coordinated response 169 that describes the results of processing the command. The following 170 server state machine diagram illustrates the message exchange process 171 in detail: 173 | 174 V 175 +-----------------+ +-----------------+ 176 | Waiting for | Connected | Prepare | 177 | Client |----------------->| Greeting | 178 +-----------------+ or +-----------------+ 179 ^ | 180 | Close Connection Send | 181 | or Idle Greeting | 182 +-----------------+ V 183 | End | Timeout +-----------------+ 184 | Session |<-----------------| Waiting for | 185 +-----------------+ | Client | 186 ^ ^ ^ Send +-------->| Authentication | 187 | | | Response | +-----------------+ 188 | | | +--------------+ | 189 | | | | Prepare Fail | | 190 | | +-----| Response | | Received 191 | | Send +--------------+ V 192 | | 2501 ^ +-----------------+ 193 | | Response | | Processing | 194 | | +---------| | 195 | | Auth Fail +-----------------+ 196 | | Timeout | 197 | +-------------------------------+ | Auth OK 198 | | V 199 | +-----------------+ +-----------------+ 200 | | Prepare |<----------| Waiting for | 201 | | Greeting |---------->| Command or | 202 | +-----------------+ Send | | 203 | Send x5xx Greeting +-----------------+ 204 | Response +-----------------+ Send ^ | 205 +-----------| Prepare | Response | | Command 206 | Response |----------+ | Received 207 +-----------------+ V 208 ^ +-----------------+ 209 Command | | Processing | 210 Processed +----------| Command | 211 +-----------------+ 213 Figure 1: EPP Server State Machine 215 EPP commands fall into three categories: session management commands, 216 query commands, and object transform commands. Session management 217 commands are used to establish and end persistent sessions with an 218 EPP server. Query commands are used to perform read-only object 219 information retrieval operations. Transform commands are used to 220 perform read-write object management operations. 222 Commands are processed by a server in the order they are received 223 from a client. Though an immediate response confirming receipt and 224 processing of the command is produced by the server, the protocol 225 includes features that allow for offline review of transform commands 226 before the requested action is actually completed. In such 227 situations, the response from the server MUST clearly note that the 228 command has been received and processed, but the requested action is 229 pending. The state of the corresponding object MUST clearly reflect 230 processing of the pending action. The server MUST also notify the 231 client when offline processing of the action has been completed. 232 Object mappings SHOULD describe standard formats for notices that 233 describe completion of offline processing. 235 EPP uses XML namespaces to provide an extensible object management 236 framework and to identify schemas required for XML instance parsing 237 and validation. These namespaces and schema definitions are used to 238 identify both the base protocol schema and the schemas for managed 239 objects. The XML namespace prefixes used in examples (such as the 240 string "foo" in "xmlns:foo") are solely for illustrative purposes. A 241 conforming implementation MUST NOT require the use of these or any 242 other specific namespace prefixes. 244 All XML instances SHOULD begin with an declaration to 245 identify the version of XML that is being used, optionally identify 246 use of the character encoding used, and optionally provide a hint to 247 an XML parser that an external schema file is needed to validate the 248 XML instance. Conformant XML parsers recognize both UTF-8 (defined 249 in RFC 3629 [RFC3629]) and UTF-16 (defined in RFC 2781 [RFC2781]); 250 per RFC 2277 [RFC2277] UTF-8 is the RECOMMENDED character encoding 251 for use with EPP. 253 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 254 UTF-8 is the default encoding assumed by XML in the absence of an 255 "encoding" attribute or a byte order mark (BOM); thus, the "encoding" 256 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 257 used. EPP clients and servers MUST accept a UTF-8 BOM if present, 258 though emitting a UTF-8 BOM is NOT RECOMMENDED. 260 Example XML declarations: 262 264 266 268 270 2.1. Transport Mapping Considerations 272 As described previously, EPP can be layered over multiple transport 273 protocols. There are, however, a common set of considerations that 274 MUST be addressed by any transport mapping defined for EPP. These 275 include: 277 - The transport mapping MUST preserve command order. 279 - The transport mapping MUST address the relationship between 280 sessions and the client-server connection concept. 282 - The transport mapping MUST preserve the stateful nature of the 283 protocol. 285 - The transport mapping MUST frame data units. 287 - The transport mapping MUST be onto a transport such as TCP 288 [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] 289 that provides congestion avoidance that follows RFC 2914 290 [RFC2914], or if it maps onto a protocol such as SMTP [RFC5321] or 291 Blocks Extensible Exchange Protocol (BEEP) [RFC3080], then the 292 performance issues need to take into account issues of overload, 293 server availability, and so forth. 295 - The transport mapping MUST ensure reliability. 297 - The transport mapping MUST explicitly allow or prohibit 298 pipelining. 300 Pipelining, also known as command streaming, is when a client sends 301 multiple commands to a server without waiting for each corresponding 302 response. After sending the commands, the client waits for the 303 responses to arrive in the order corresponding to the completed 304 commands. Performance gains can sometimes be realized with 305 pipelining, especially with high-latency transports, but there are 306 additional considerations associated with defining a transport 307 mapping that supports pipelining: 309 - Commands MUST be processed independent of each other. 311 - Depending on the transport, pipelining MAY be possible in the form 312 of sending a complete session in a well-defined "batch". 314 - The transport mapping MUST describe how an error in processing a 315 command affects continued operation of the session. 317 A transport mapping MUST explain how all of these requirements are 318 met given the transport protocol being used to exchange data. 320 2.2. Protocol Identification 322 All EPP XML instances MUST begin with an element. This element 323 identifies the start of an EPP protocol element and the namespace 324 used within the protocol. The start element and the associated 325 ending element MUST be applied to all structures sent by both 326 clients and servers. 328 Example "start" and "end" EPP elements: 330 331 333 2.3. Hello Format 335 EPP MAY be carried over both connection-oriented and connection-less 336 transport protocols. An EPP client MAY request a from an 337 EPP server at any time between a successful command and a 338 command by sending a to a server. Use of this 339 element is essential in a connection-less environment where a server 340 cannot return a in response to a client-initiated 341 connection. An EPP MUST be an empty element with no child 342 elements. 344 Example : 346 C: 347 C: 348 C: 349 C: 351 2.4. Greeting Format 353 An EPP server responds to a successful connection and element 354 by returning a element to the client. An EPP greeting 355 contains the following elements: 357 - An element that contains the name of the server. 359 - An element that contains the server's current date and 360 time in UTC. 362 - An element that identifies the services supported by the 363 server, including: 365 - One or more elements that identify the protocol 366 versions supported by the server. 368 - One or more elements that contain the identifiers of the 369 text response languages known by the server. Language 370 identifiers MUST be structured as documented in [RFC4646]. 372 - One or more elements that contain namespace URIs 373 representing the objects that the server is capable of 374 managing. A server MAY limit object management privileges on a 375 per-client basis. 377 - An OPTIONAL element that contains one or more 378 elements that contain namespace URIs representing 379 object extensions supported by the server. 381 - A (data collection policy) element that contains child 382 elements used to describe the server's privacy policy for data 383 collection and management. Policy implications usually extend 384 beyond the client-server relationship. Both clients and 385 servers can have relationships with other entities that need to 386 know the server operator's data collection policy to make 387 informed provisioning decisions. Policy information MUST be 388 disclosed to provisioning entities, though the method of 389 disclosing policy data outside of direct protocol interaction 390 is beyond the scope of this specification. Child elements 391 include the following: 393 - An element that describes the access provided by 394 the server to the client on behalf of the originating data 395 source. The element MUST contain one of the 396 following child elements: 398 - : Access is given to all identified data. 400 - : No access is provided to identified data. 402 - : Data is not persistent, so no access is 403 possible. 405 - : Access is given to identified data relating 406 to individuals and organizational entities. 408 - : Access is given to identified data 409 relating to individuals, organizational entities, and 410 other data of a non-personal nature. 412 - : Access is given to other identified data of a 413 non-personal nature. 415 - One or more elements that describe data 416 collection purposes, data recipients, and data retention. 417 Each element MUST contain a element, a 418 element, and a element. The 419 element MUST contain one or more of the following 420 child elements that describe the purposes for which data is 421 collected: 423 - : Administrative purposes. Information can be 424 used for administrative and technical support of the 425 provisioning system. 427 - : Contact for marketing purposes. Information 428 can be used to contact individuals, through a 429 communications channel other than the protocol, for the 430 promotion of a product or service. 432 - : Object provisioning purposes. Information can 433 be used to identify objects and inter-object 434 relationships. 436 - : Other purposes. Information may be used in 437 other ways not captured by the above definitions. 439 - The element MUST contain one or more of the 440 following child elements that describes the recipients of 441 collected data: 443 - : Other entities following unknown practices. 445 - : Server operator and/or entities acting as agents 446 or entities for whom the server operator is acting as an 447 agent. An agent in this instance is defined as a third 448 party that processes data only on behalf of the service 449 provider for the completion of the stated purposes. The 450 element contains an OPTIONAL element 451 that can be used to describe the recipient. 453 - : Public forums. 455 - : Other entities following server practices. 457 - : Unrelated third parties. 459 - The element MUST contain one of the following 460 child elements that describes data retention practices: 462 - : Data persists per business practices. 464 - : Data persists indefinitely. 466 - : Data persists per legal requirements. 468 - : Data is not persistent and is not retained for 469 more than a brief period of time necessary to make use of 470 it during the course of a single online interaction. 472 - : Data persists to meet the stated purpose. 474 - An OPTIONAL element that describes the lifetime of 475 the policy. The element MUST contain one of the 476 following child elements: 478 - : The policy is valid from the current date 479 and time until it expires on the specified date and time. 481 - : The policy is valid from the current date 482 and time until the end of the specified duration. 484 Data collection policy elements are based on work described in the 485 World Wide Web Consortium's Platform for Privacy Preferences 486 [W3C.REC-P3P-20020416] specification. 488 Example greeting: 490 S: 491 S: 492 S: 493 S: Example EPP server epp.example.com 494 S: 2000-06-08T22:00:00.0Z 495 S: 496 S: 1.0 497 S: en 498 S: fr 499 S: urn:ietf:params:xml:ns:obj1 500 S: urn:ietf:params:xml:ns:obj2 501 S: urn:ietf:params:xml:ns:obj3 502 S: 503 S: http://custom/obj1ext-1.0 504 S: 505 S: 506 S: 507 S: 508 S: 509 S: 510 S: 511 S: 512 S: 513 S: 514 S: 515 S: 517 2.5. Command Format 519 An EPP client interacts with an EPP server by sending a command to 520 the server and receiving a response from the server. In addition to 521 the standard EPP elements, an EPP command contains the following 522 elements: 524 - A command element whose tag corresponds to one of the valid EPP 525 commands described in this document. The command element MAY 526 contain either protocol-specified or object-specified child 527 elements. 529 - An OPTIONAL element that MAY be used for server- 530 defined command extensions. 532 - An OPTIONAL (client transaction identifier) element that 533 MAY be used to uniquely identify the command to the client. 534 Clients are responsible for maintaining their own transaction 535 identifier space to ensure uniqueness. 537 Example command with object-specified child elements: 539 C: 540 C: 541 C: 542 C: 543 C: 544 C: example 545 C: 546 C: 547 C: ABC-12345 548 C: 549 C: 551 2.6. Response Format 553 An EPP server responds to a client command by returning a response to 554 the client. EPP commands are atomic, so a command will either 555 succeed completely or fail completely. Success and failure results 556 MUST NOT be mixed. In addition to the standard EPP elements, an EPP 557 response contains the following elements: 559 - One or more elements that document the success or failure 560 of command execution. If the command was processed successfully, 561 only one element MUST be returned. If the command was 562 not processed successfully, multiple elements MAY be 563 returned to document failure conditions. Each element 564 contains the following attribute and child elements: 566 - A "code" attribute whose value is a four-digit, decimal number 567 that describes the success or failure of the command. 569 - A element containing a human-readable description of the 570 response code. The language of the response is identified via 571 an OPTIONAL "lang" attribute. If not specified, the default 572 attribute value MUST be "en" (English). 574 - Zero or more OPTIONAL elements that identify a client- 575 provided element (including XML tag and value) or other 576 information that caused a server error condition. 578 - Zero or more OPTIONAL elements that can be used to 579 provide additional error diagnostic information, including: 581 - A element that identifies a client-provided element 582 (including XML tag and value) that caused a server error 583 condition. 585 - A element containing a human-readable message that 586 describes the reason for the error. The language of the 587 response is identified via an OPTIONAL "lang" attribute. If 588 not specified, the default attribute value MUST be "en" 589 (English). 591 - An OPTIONAL element that describes messages queued for 592 client retrieval. A element MUST NOT be present if there 593 are no messages queued for client retrieval. A element MAY 594 be present in responses to EPP commands other than the 595 command if messages are queued for retrieval. A element 596 MUST be present in responses to the EPP command if messages 597 are queued for retrieval. The element contains the 598 following attributes: 600 - A "count" attribute that describes the number of messages that 601 exist in the queue. 603 - An "id" attribute used to uniquely identify the message at the 604 head of the queue. 606 The element contains the following OPTIONAL child elements 607 that MUST be returned in response to a request command and 608 MUST NOT be returned in response to any other command, including a 609 acknowledgement: 611 - A element that contains the date and time that the 612 message was enqueued. 614 - A element containing a human-readable message. The 615 language of the response is identified via an OPTIONAL "lang" 616 attribute. If not specified, the default attribute value MUST 617 be "en" (English). This element MAY contain XML content for 618 formatting purposes, but the XML content is not specified by 619 the protocol and will thus not be processed for validity. 621 - An OPTIONAL (response data) element that contains child 622 elements specific to the command and associated object. 624 - An OPTIONAL element that MAY be used for server- 625 defined response extensions. 627 - A (transaction identifier) element containing the 628 transaction identifier assigned by the server to the command for 629 which the response is being returned. The transaction identifier 630 is formed using the associated with the command if 631 supplied by the client and a (server transaction 632 identifier) that is assigned by and unique to the server. 634 Transaction identifiers provide command-response synchronization 635 integrity. They SHOULD be logged, retained, and protected to ensure 636 that both the client and the server have consistent temporal and 637 state management records. 639 Example response without or : 641 S: 642 S: 643 S: 644 S: 645 S: Command completed successfully 646 S: 647 S: 648 S: ABC-12345 649 S: 54321-XYZ 650 S: 651 S: 652 S: 653 Example response with : 655 S: 656 S: 657 S: 658 S: 659 S: Command completed successfully 660 S: 661 S: 662 S: 663 S: example 664 S: 665 S: 666 S: 667 S: ABC-12345 668 S: 54321-XYZ 669 S: 670 S: 671 S: 672 Example response with error value elements: 674 S: 675 S: 676 S: 677 S: 678 S: Parameter value range error 679 S: 680 S: 2525 681 S: 682 S: 683 S: 684 S: Parameter value syntax error 685 S: 686 S: ex(ample 687 S: 688 S: 689 S: 690 S: abc.ex(ample 691 S: 692 S: Invalid character found. 693 S: 694 S: 695 S: 696 S: ABC-12345 697 S: 54321-XYZ 698 S: 699 S: 700 S: 702 Example response with notice of waiting server messages: 704 S: 705 S: 706 S: 707 S: 708 S: Command completed successfully 709 S: 710 S: 711 S: 712 S: ABC-12345 713 S: 54321-XYZ 714 S: 715 S: 716 S: 717 Command success or failure MUST NOT be assumed if no response is 718 returned or if a returned response is malformed. Protocol 719 idempotency ensures the safety of retrying a command in cases of 720 response delivery failure. 722 2.7. Protocol Extension Framework 724 EPP provides an extension framework that allows features to be added 725 at the protocol, object, and command-response levels. 727 2.7.1. Protocol Extension 729 The EPP extension framework allows for definition of new protocol 730 elements identified using XML namespace notation with a reference to 731 an XML schema that defines the namespace. The element that 732 identifies the beginning of a protocol instance includes multiple 733 child element choices, one of which is an element whose 734 children define the extension. For example, a protocol extension 735 element would be described in generic terms as follows: 737 C: 738 C: 739 C: 740 C: 741 C: 742 C: 743 C: 744 C: 746 This document does not define mappings for specific extensions. 747 Extension specifications MUST be described in separate documents that 748 define the objects and operations subject to the extension. 750 2.7.2. Object Extension 752 EPP provides an extensible object management framework that defines 753 the syntax and semantics of protocol operations applied to a managed 754 object. This framework pushes the definition of each protocol 755 operation into the context of a specific object, providing the 756 ability to add mappings for new objects without having to modify the 757 base protocol. 759 Protocol elements that contain data specific to objects are 760 identified using XML namespace notation with a reference to an XML 761 schema that defines the namespace. The schema for EPP supports use 762 of dynamic object schemas on a per-command and per-response basis. 763 For example, the start of an object-specific command element would be 764 described in generic terms as follows: 766 C: 767 C: 768 C: 769 C: 770 C: 772 An object-specific response element would be described similarly: 774 S: 775 S: 776 S: 777 S: 778 S: 780 This document does not define mappings for specific objects. The 781 mapping of EPP to an object MUST be described in separate documents 782 that specifically address each command and response in the context of 783 the object. A suggested object mapping outline is included as an 784 appendix to this document. 786 2.7.3. Command-Response Extension 788 EPP provides a facility for protocol command and response extensions. 789 Protocol commands and responses MAY be extended by an 790 element that contains additional elements whose syntax and semantics 791 are not explicitly defined by EPP or an EPP object mapping. This 792 element is OPTIONAL. Extensions are typically defined by agreement 793 between client and server and MAY be used to extend EPP for unique 794 operational needs. A server-extended command element would be 795 described in generic terms as follows: 797 C: 798 C: 799 C: 800 C: 801 C: 802 C: 803 C: 804 C: 805 C: 806 C: 807 C: 809 An server-extended response element would be described similarly: 811 S: 812 S: 813 S: Command completed successfully 814 S: 815 S: 816 S: 817 S: 818 S: 819 S: ABC-12345 820 S: 54321-XYZ 821 S: 822 S: 824 This document does not define any specific server extensions. The 825 mapping of server extensions to EPP MUST be described in separate 826 documents that specifically address extended commands and responses 827 in the server's operational context. 829 2.8. Object Identification 831 Some objects, such as name servers and contacts, can have utility in 832 multiple repositories. However, maintaining disjoint copies of 833 object information in multiple repositories can lead to 834 inconsistencies that have adverse consequences for the Internet. For 835 example, changing a name server name in one repository, but not in a 836 second repository that refers to the server for domain name 837 delegation, can produce unexpected DNS query results. 839 Globally unique identifiers can help facilitate object information 840 sharing between repositories. A globally unique identifier MUST be 841 assigned to every object when the object is created; the identifier 842 MUST be returned to the client as part of any request to retrieve the 843 detailed attributes of an object. Specific identifier values are a 844 matter of repository policy, but they SHOULD be constructed according 845 to the following algorithm: 847 a. Divide the provisioning repository world into a number of object 848 repository classes. 850 b. Each repository within a class is assigned an identifier that is 851 maintained by IANA. 853 c. Each repository is responsible for assigning a unique local 854 identifier for each object within the repository. 856 d. The globally unique identifier is a concatenation of the local 857 identifier, followed by a hyphen ("-", ASCII value 0x002D), 858 followed by the repository identifier. 860 2.9. Protocol Commands 862 EPP provides commands to manage sessions, retrieve object 863 information, and perform transformation operations on objects. All 864 EPP commands are atomic and designed so that they can be made 865 idempotent, either succeeding completely or failing completely and 866 producing predictable results in case of repeated executions. This 867 section describes each EPP command, including examples with 868 representative server responses. 870 2.9.1. Session Management Commands 872 EPP provides two commands for session management: to 873 establish a session with a server, and to end a session with 874 a server. The command establishes an ongoing server session 875 that preserves client identity and authorization information during 876 the duration of the session. 878 2.9.1.1. EPP Command 880 The EPP command is used to establish a session with an EPP 881 server in response to a greeting issued by the server. A 882 command MUST be sent to a server before any other EPP command to 883 establish an ongoing session. A server operator MAY limit the number 884 of failed login attempts N, 1 <= N <= infinity, after which a login 885 failure results in the connection to the server (if a connection 886 exists) being closed. 888 A client identifier and initial password MUST be created on the 889 server before a client can successfully complete a command. 890 The client identifier and initial password MUST be delivered to the 891 client using an out-of-band method that protects the identifier and 892 password from inadvertent disclosure. 894 In addition to the standard EPP command elements, the command 895 contains the following child elements: 897 - A element that contains the client identifier assigned to 898 the client by the server. 900 - A element that contains the client's plain text password. 901 The value of this element is case sensitive. 903 - An OPTIONAL element that contains a new plain text 904 password to be assigned to the client for use with subsequent 905 commands. The value of this element is case sensitive. 907 - An element that contains the following child elements: 909 - A element that contains the protocol version to be 910 used for the command or ongoing server session. 912 - A element that contains the text response language to be 913 used for the command or ongoing server session commands. 915 The values of the and elements MUST exactly match 916 one of the values presented in the EPP greeting. 918 - A element that contains one or more elements that 919 contain namespace URIs representing the objects to be managed 920 during the session. The element MAY contain an OPTIONAL 921 element that contains one or more elements 922 that identify object extensions to be used during the session. 924 The PLAIN Simple Authentication and Security Layer (SASL) mechanism 925 presented in [RFC4616] describes a format for providing a user 926 identifier, an authorization identifier, and a password as part of a 927 single plain text string. The EPP authentication mechanism is 928 similar, though EPP does not require a session-level authorization 929 identifier and the user identifier and password are separated into 930 distinct XML elements. Additional identification and authorization 931 schemes MUST be provided at other protocol layers to provide more 932 robust security services. 934 Example command: 936 C: 937 C: 938 C: 939 C: 940 C: ClientX 941 C: foo-BAR2 942 C: bar-FOO2 943 C: 944 C: 1.0 945 C: en 946 C: 947 C: 948 C: urn:ietf:params:xml:ns:obj1 949 C: urn:ietf:params:xml:ns:obj2 950 C: urn:ietf:params:xml:ns:obj3 951 C: 952 C: http://custom/obj1ext-1.0 953 C: 954 C: 955 C: 956 C: ABC-12345 957 C: 958 C: 960 When a command has been processed successfully, a server MUST 961 respond with an EPP response with no element. If 962 successful, the server will respond by creating and maintaining a new 963 session that SHOULD be terminated by a future command. 965 Example response: 967 S: 968 S: 969 S: 970 S: 971 S: Command completed successfully 972 S: 973 S: 974 S: ABC-12345 975 S: 54321-XYZ 976 S: 977 S: 978 S: 979 The EPP command is used to establish a session with an EPP 980 server. A command MUST be rejected if received within the 981 bounds of an existing session. This command MUST be available to all 982 clients. 984 2.9.1.2. EPP Command 986 The EPP command is used to end a session with an EPP server. 987 The command MUST be represented as an empty element with no 988 child elements. 990 A server MAY end a session due to client inactivity or excessive 991 client session longevity. The parameters for determining excessive 992 client inactivity or session longevity are a matter of server policy 993 and are not specified by this protocol. 995 Transport mappings MUST explicitly describe any connection-oriented 996 processing that takes place after processing a command and 997 ending a session. 999 Example command: 1001 C: 1002 C: 1003 C: 1004 C: 1005 C: ABC-12345 1006 C: 1007 C: 1009 When a command has been processed successfully, a server 1010 MUST respond with an EPP response with no element. If 1011 successful, the server MUST also end the current session. 1013 Example response: 1015 S: 1016 S: 1017 S: 1018 S: 1019 S: Command completed successfully; ending session 1020 S: 1021 S: 1022 S: ABC-12345 1023 S: 54321-XYZ 1024 S: 1025 S: 1026 S: 1027 The EPP command is used to end a session with an EPP server. 1028 A command MUST be rejected if the command has not been 1029 preceded by a successful command. This command MUST be 1030 available to all clients. 1032 2.9.2. Query Commands 1034 2.9.2.1. EPP Command 1036 The EPP command is used to determine if an object can be 1037 provisioned within a repository. It provides a hint that allows a 1038 client to anticipate the success or failure of provisioning an object 1039 using the command as object provisioning requirements are 1040 ultimately a matter of server policy. 1042 The elements needed to identify an object are object-specific, so the 1043 child elements of the command are specified using the EPP 1044 extension framework. In addition to the standard EPP command 1045 elements, the command contains the following child elements: 1047 - An object-specific element that identifies the objects 1048 to be queried. Multiple objects of the same type MAY be queried 1049 within a single command. 1051 Example command: 1053 C: 1054 C: 1055 C: 1056 C: 1057 C: 1058 C: example1 1059 C: example2 1060 C: example3 1061 C: 1062 C: 1063 C: ABC-12346 1064 C: 1065 C: 1067 When a command has been processed successfully, a server MUST 1068 respond with an EPP element that MUST contain a child 1069 element that identifies the object namespace. The child elements of 1070 the element are object-specific, though the EPP 1071 element MUST contain a child element that contains one 1072 or more (check data) elements. Each element 1073 contains the following child elements: 1075 - An object-specific element that identifies the queried object. 1076 This element MUST contain an "avail" attribute whose value 1077 indicates object availability (can it be provisioned or not) at 1078 the moment the command was completed. A value of "1" or 1079 "true" means that the object can be provisioned. A value of "0" 1080 or "false" means that the object cannot be provisioned. 1082 - An OPTIONAL element that MAY be provided when an 1083 object cannot be provisioned. If present, this element contains 1084 server-specific text to help explain why the object cannot be 1085 provisioned. This text MUST be represented in the response 1086 language previously negotiated with the client; an OPTIONAL "lang" 1087 attribute MAY be present to identify the language if the 1088 negotiated value is something other than the default value of "en" 1089 (English). 1091 Example response: 1093 S: 1094 S: 1095 S: 1096 S: 1097 S: Command completed successfully 1098 S: 1099 S: 1100 S: 1101 S: 1102 S: example1 1103 S: 1104 S: 1105 S: example2 1106 S: In use 1107 S: 1108 S: 1109 S: example3 1110 S: 1111 S: 1112 S: 1113 S: 1114 S: ABC-12346 1115 S: 54322-XYZ 1116 S: 1117 S: 1118 S: 1120 The EPP command is used to determine if an object can be 1121 provisioned within a repository. This action MUST be open to all 1122 authorized clients. 1124 2.9.2.2. EPP Command 1126 The EPP command is used to retrieve information associated 1127 with an existing object. The elements needed to identify an object 1128 and the type of information associated with an object are both 1129 object-specific, so the child elements of the command are 1130 specified using the EPP extension framework. In addition to the 1131 standard EPP command elements, the command contains the 1132 following child elements: 1134 - An object-specific element that identifies the object 1135 to be queried. 1137 Example command: 1139 C: 1140 C: 1141 C: 1142 C: 1143 C: 1144 C: 1145 C: 1146 C: 1147 C: ABC-12346 1148 C: 1149 C: 1151 When an command has been processed successfully, a server MUST 1152 respond with an EPP element that MUST contain a child 1153 element that identifies the object namespace and the Repository 1154 Object IDentifier (ROID) that was assigned to the object when the 1155 object was created. Other child elements of the element 1156 are object-specific. 1158 Example response: 1160 S: 1161 S: 1162 S: 1163 S: 1164 S: Command completed successfully 1165 S: 1166 S: 1167 S: 1168 S: EXAMPLE1-REP 1169 S: 1170 S: 1171 S: 1172 S: 1173 S: ABC-12346 1174 S: 54322-XYZ 1175 S: 1176 S: 1177 S: 1179 The EPP command is used to retrieve information associated 1180 with an existing object. This action SHOULD be limited to authorized 1181 clients; restricting this action to the sponsoring client is 1182 RECOMMENDED. 1184 2.9.2.3. EPP Command 1186 The EPP command is used to discover and retrieve service 1187 messages queued by a server for individual clients. If the message 1188 queue is not empty, a successful response to a command MUST 1189 return the first message from the message queue. Each response 1190 returned from the server includes a server-unique message identifier 1191 that MUST be provided to acknowledge receipt of the message, and a 1192 counter that indicates the number of messages in the queue. After a 1193 message has been received by the client, the client MUST respond to 1194 the message with an explicit acknowledgement to confirm that the 1195 message has been received. A server MUST dequeue the message and 1196 decrement the queue counter after receiving acknowledgement from the 1197 client, making the next message in the queue (if any) available for 1198 retrieval. 1200 Servers can occasionally perform actions on objects that are not in 1201 direct response to a client request, or an action taken by one client 1202 can indirectly involve a second client. Examples of such actions 1203 include deletion upon expiration, automatic renewal upon expiration, 1204 and transfer coordination; other types of service information MAY be 1205 defined as a matter of server policy. Service messages SHOULD be 1206 created for passive clients affected by an action on an object. 1207 Service messages MAY also be created for active clients that request 1208 an action on an object, though such messages MUST NOT replace the 1209 normal protocol response to the request. For example, 1210 actions SHOULD be reported to the client that has the authority to 1211 approve or reject a transfer request. Other methods of server-client 1212 action notification, such as offline reporting, are also possible and 1213 are beyond the scope of this specification. 1215 Message queues can consume server resources if clients do not 1216 retrieve and acknowledge messages on a regular basis. Servers MAY 1217 implement other mechanisms to dequeue and deliver messages if queue 1218 maintenance needs exceed server resource consumption limits. Server 1219 operators SHOULD consider time-sensitivity and resource management 1220 factors when selecting a delivery method for service information 1221 because some message types can be reasonably delivered using non- 1222 protocol methods that require fewer server resources. 1224 Some of the information returned in response to a command can 1225 be object-specific, so some child elements of the response MAY 1226 be specified using the EPP extension framework. The command 1227 MUST be represented as an empty element with no child elements. An 1228 "op" attribute with value "req" is REQUIRED to retrieve the first 1229 message from the server message queue. An "op" attribute (with value 1230 "ack") and a "msgID" attribute (whose value corresponds to the value 1231 of the "id" attribute copied from the element in the message 1232 being acknowledged) are REQUIRED to acknowledge receipt of a message. 1234 Example command: 1236 C: 1237 C: 1238 C: 1239 C: 1240 C: ABC-12345 1241 C: 1242 C: 1244 The returned result code notes that a message has been dequeued and 1245 returned in response to a command. 1247 Example response with object-specific information: 1249 S: 1250 S: 1251 S: 1252 S: 1253 S: Command completed successfully; ack to dequeue 1254 S: 1255 S: 1256 S: 2000-06-08T22:00:00.0Z 1257 S: Transfer requested. 1258 S: 1259 S: 1260 S: 1262 S: example.com 1263 S: pending 1264 S: ClientX 1265 S: 2000-06-08T22:00:00.0Z 1266 S: ClientY 1267 S: 2000-06-13T22:00:00.0Z 1268 S: 2002-09-08T22:00:00.0Z 1269 S: 1270 S: 1271 S: 1272 S: ABC-12345 1273 S: 54321-XYZ 1274 S: 1275 S: 1276 S: 1278 A client MUST acknowledge each response to dequeue the message and 1279 make subsequent messages available for retrieval. 1281 Example acknowledgement command: 1283 C: 1284 C: 1285 C: 1286 C: 1287 C: ABC-12346 1288 C: 1289 C: 1291 A acknowledgement response notes the ID of the message that 1292 has been acknowledged and the number of messages remaining in the 1293 queue. 1295 Example acknowledgement response: 1297 S: 1298 S: 1299 S: 1300 S: 1301 S: Command completed successfully 1302 S: 1303 S: 1304 S: 1305 S: ABC-12346 1306 S: 54322-XYZ 1307 S: 1308 S: 1309 S: 1311 Service messages can also be returned without object information. 1313 Example response with mixed message content and without 1314 object-specific information: 1316 S: 1317 S: 1318 S: 1319 S: 1320 S: Command completed successfully; ack to dequeue 1321 S: 1322 S: 1323 S: 2000-06-08T22:10:00.0Z 1324 S: Credit balance low. 1325 S: 1005 1326 S: 1327 S: 1328 S: 1329 S: ABC-12346 1330 S: 54321-XYZ 1331 S: 1332 S: 1333 S: 1335 The returned result code and message is used to note an empty server 1336 message queue. 1338 Example response to note an empty message queue: 1340 S: 1341 S: 1342 S: 1343 S: 1344 S: Command completed successfully; no messages 1345 S: 1346 S: 1347 S: ABC-12346 1348 S: 54321-XYZ 1349 S: 1350 S: 1351 S: 1353 The EPP command is used to discover and retrieve client 1354 service messages from a server. This action SHOULD be limited to 1355 authorized clients; queuing service messages and limiting queue 1356 access on a per-client basis is RECOMMENDED. 1358 2.9.2.4. EPP Query Command 1360 The EPP command provides a query operation that allows a 1361 client to determine real-time status of pending and completed 1362 transfer requests. The elements needed to identify an object that is 1363 the subject of a transfer request are object-specific, so the child 1364 elements of the query command are specified using the EPP 1365 extension framework. In addition to the standard EPP command 1366 elements, the command contains an "op" attribute with 1367 value "query", and the following child elements: 1369 - An object-specific element that identifies the 1370 object whose transfer status is requested. 1372 Transfer status is typically considered sensitive information by the 1373 clients involved in the operation. Object mappings MUST provide 1374 features to restrict transfer queries to authorized clients, such as 1375 by requiring authorization information as part of the request. 1377 Example query command: 1379 C: 1380 C: 1381 C: 1382 C: 1383 C: 1384 C: 1385 C: 1386 C: 1387 C: ABC-12346 1388 C: 1389 C: 1391 When a query command has been processed successfully, a 1392 server MUST respond with an EPP element that MUST contain a 1393 child element that identifies the object namespace. The child 1394 elements of the element are object-specific, but they MUST 1395 include elements that identify the object, the status of the 1396 transfer, the identifier of the client that requested the transfer, 1397 the date and time that the request was made, the identifier of the 1398 client that is authorized to act on the request, the date and time by 1399 which an action is expected, and an OPTIONAL date and time noting 1400 changes in the object's validity period (if applicable) that occur as 1401 a result of the transfer. 1403 Example query response: 1405 S: 1406 S: 1407 S: 1408 S: 1409 S: Command completed successfully 1410 S: 1411 S: 1412 S: 1413 S: example 1414 S: pending 1415 S: ClientX 1416 S: 2000-06-08T22:00:00.0Z 1417 S: ClientY 1418 S: 2000-06-13T22:00:00.0Z 1419 S: 2002-09-08T22:00:00.0Z 1420 S: 1421 S: 1422 S: 1423 S: ABC-12346 1424 S: 54322-XYZ 1425 S: 1426 S: 1427 S: 1429 The EPP command provides a query operation that allows a 1430 client to determine real-time status of pending and completed 1431 transfer requests. This action SHOULD be limited to authorized 1432 clients; restricting queries to the requesting and responding clients 1433 is RECOMMENDED. Object transfer MAY be unavailable or limited by 1434 object-specific policies. 1436 2.9.3. Object Transform Commands 1438 EPP provides five commands to transform objects: to create 1439 an instance of an object with a server, to remove an 1440 instance of an object from a server, to extend the validity 1441 period of an object, to manage changes in client 1442 sponsorship of an object, and to change information 1443 associated with an object. 1445 2.9.3.1. EPP Command 1447 The EPP command is used to create an instance of an object. 1448 An object can be created for an indefinite period of time, or an 1449 object can be created for a specific validity period. The EPP 1450 mapping for an object MUST describe the status of an object with 1451 respect to time, to include expected client and server behavior if a 1452 validity period is used. 1454 The elements needed to identify an object and associated attributes 1455 are object-specific, so the child elements of the command 1456 are specified using the EPP extension framework. In addition to the 1457 standard EPP command elements, the command contains the 1458 following child elements: 1460 - An object-specific element that identifies the object 1461 to be created and the elements that are required to create the 1462 object. 1464 Example command: 1466 C: 1467 C: 1468 C: 1469 C: 1470 C: 1471 C: 1472 C: 1473 C: 1474 C: ABC-12345 1475 C: 1476 C: 1478 When a command has been processed successfully, a server MAY 1479 respond with an EPP element that MUST contain a child 1480 element that identifies the object namespace. The child elements of 1481 the element are object-specific. 1483 Example response with : 1485 S: 1486 S: 1487 S: 1488 S: 1489 S: Command completed successfully 1490 S: 1491 S: 1492 S: 1493 S: 1494 S: 1495 S: 1496 S: 1497 S: ABC-12345 1498 S: 54321-XYZ 1499 S: 1500 S: 1501 S: 1503 The EPP command is used to create an instance of an object. 1504 This action SHOULD be limited to authorized clients and MAY be 1505 restricted on a per-client basis. 1507 2.9.3.2. EPP Command 1509 The EPP command is used to remove an instance of an existing 1510 object. The elements needed to identify an object are object- 1511 specific, so the child elements of the command are specified 1512 using the EPP extension framework. In addition to the standard EPP 1513 command elements, the command contains the following child 1514 elements: 1516 - An object-specific element that identifies the object 1517 to be deleted. 1519 Example command: 1521 C: 1522 C: 1523 C: 1524 C: 1525 C: 1526 C: 1527 C: 1528 C: 1529 C: ABC-12346 1530 C: 1531 C: 1533 When a command has been processed successfully, a server MAY 1534 respond with an EPP element that MUST contain a child 1535 element that identifies the object namespace. The child elements of 1536 the element are object-specific. 1538 Example response without : 1540 S: 1541 S: 1542 S: 1543 S: 1544 S: Command completed successfully 1545 S: 1546 S: 1547 S: ABC-12346 1548 S: 54322-XYZ 1549 S: 1550 S: 1551 S: 1553 The EPP command is used to remove an instance of an existing 1554 object. This action SHOULD be limited to authorized clients; 1555 restricting this action to the sponsoring client is RECOMMENDED. 1557 2.9.3.3. EPP Command 1559 The EPP command is used to extend the validity period of an 1560 existing object. The elements needed to identify and extend the 1561 validity period of an object are object-specific, so the child 1562 elements of the command are specified using the EPP extension 1563 framework. In addition to the standard EPP command elements, the 1564 command contains the following child elements: 1566 - An object-specific element that identifies the object 1567 to be renewed and the elements that are required to extend the 1568 validity period of the object. 1570 Example command: 1572 C: 1573 C: 1574 C: 1575 C: 1576 C: 1577 C: 1578 C: 1579 C: 1580 C: ABC-12346 1581 C: 1582 C: 1584 When a command has been processed successfully, a server MAY 1585 respond with an EPP element that MUST contain a child 1586 element that identifies the object namespace. The child elements of 1587 the element are object-specific. 1589 Example response with : 1591 S: 1592 S: 1593 S: 1594 S: 1595 S: Command completed successfully 1596 S: 1597 S: 1598 S: 1599 S: 1600 S: 1601 S: 1602 S: 1603 S: ABC-12346 1604 S: 54322-XYZ 1605 S: 1606 S: 1607 S: 1609 The EPP command is used to extend the validity period of an 1610 existing object. This action SHOULD be limited to authorized 1611 clients; restricting this action to the sponsoring client is 1612 RECOMMENDED. Object renewal MAY be unavailable or limited by object- 1613 specific policies. 1615 2.9.3.4. EPP Command 1617 The EPP command is used to manage changes in client 1618 sponsorship of an existing object. Clients can initiate a transfer 1619 request, cancel a transfer request, approve a transfer request, and 1620 reject a transfer request using the "op" command attribute. 1622 A client who wishes to assume sponsorship of a known object from 1623 another client uses the command with the value of the "op" 1624 attribute set to "request". Once a transfer has been requested, the 1625 same client can cancel the request using a command with 1626 the value of the "op" attribute set to "cancel". A request to cancel 1627 the transfer MUST be sent to the server before the current sponsoring 1628 client either approves or rejects the transfer request and before the 1629 server automatically processes the request due to responding client 1630 inactivity. 1632 Once a transfer request has been received by the server, the server 1633 MUST notify the current sponsoring client of the requested transfer 1634 either by queuing a service message for retrieval via the 1635 command or by using an out-of-band mechanism to inform the client of 1636 the request. The current status of a pending command for 1637 any object can be found using the query command. Transfer 1638 service messages MUST include the object-specific elements specified 1639 for command responses. 1641 The current sponsoring client MAY explicitly approve or reject the 1642 transfer request. The client can approve the request using a 1643 command with the value of the "op" attribute set to 1644 "approve". The client can reject the request using a 1645 command with the value of the "op" attribute set to "reject". 1647 A server MAY automatically approve or reject all transfer requests 1648 that are not explicitly approved or rejected by the current 1649 sponsoring client within a fixed amount of time. The amount of time 1650 to wait for explicit action and the default server behavior are local 1651 matters not specified by EPP, but they SHOULD be documented in a 1652 server-specific profile document that describes default server 1653 behavior for client information. 1655 Objects eligible for transfer MUST have associated authorization 1656 information that MUST be provided to complete a command. 1657 The type of authorization information required is object-specific; 1658 passwords or more complex mechanisms based on public key cryptography 1659 are typical. 1661 The elements needed to identify and complete the transfer of an 1662 object are object-specific, so the child elements of the 1663 command are specified using the EPP extension framework. In addition 1664 to the standard EPP command elements, the command contains 1665 the following child elements: 1667 - An object-specific element that identifies the 1668 object to be transferred and the elements that are required to 1669 process the transfer command. 1671 Example command: 1673 C: 1674 C: 1675 C: 1676 C: 1677 C: 1678 C: 1679 C: 1680 C: 1681 C: ABC-12346 1682 C: 1683 C: 1685 When a command has been processed successfully, a server 1686 MUST respond with an EPP element that MUST contain a child 1687 element that identifies the object namespace. The child elements of 1688 the element are object-specific, but they MUST include 1689 elements that identify the object, the status of the transfer, the 1690 identifier of the client that requested the transfer, the date and 1691 time that the request was made, the identifier of the client that is 1692 authorized to act on the request, the date and time by which an 1693 action is expected, and an OPTIONAL date and time noting changes in 1694 the object's validity period (if applicable) that occur as a result 1695 of the transfer. 1697 Example response with : 1699 S: 1700 S: 1701 S: 1702 S: 1703 S: Command completed successfully; action pending 1704 S: 1705 S: 1706 S: 1707 S: example 1708 S: pending 1709 S: ClientX 1710 S: 2000-06-08T22:00:00.0Z 1711 S: ClientY 1712 S: 2000-06-13T22:00:00.0Z 1713 S: 2002-09-08T22:00:00.0Z 1714 S: 1715 S: 1716 S: 1717 S: ABC-12346 1718 S: 54322-XYZ 1719 S: 1720 S: 1721 S: 1723 The EPP command is used to manage changes in client 1724 sponsorship of an existing object. This action SHOULD be limited to 1725 authorized clients; restricting requests to a client other 1726 than the current sponsoring client, approval requests to 1727 the current sponsoring client, and cancellation requests 1728 to the original requesting client is RECOMMENDED. Object transfer 1729 MAY be unavailable or limited by object-specific policies. 1731 2.9.3.5. EPP Command 1733 The EPP command is used to change information associated 1734 with an existing object. The elements needed to identify and modify 1735 an object are object-specific, so the child elements of the 1736 command are specified using the EPP extension framework. In addition 1737 to the standard EPP command elements, the command contains 1738 the following child elements: 1740 - An object-specific element that identifies the object 1741 to be updated and the elements that are required to modify the 1742 object. Object-specific elements MUST identify values to be 1743 added, values to be removed, or values to be changed. 1745 Example command: 1747 C: 1748 C: 1749 C: 1750 C: 1751 C: 1752 C: 1753 C: 1754 C: 1755 C: ABC-12346 1756 C: 1757 C: 1759 When an command has been processed successfully, a server 1760 MAY respond with an EPP element that MUST contain a child 1761 element that identifies the object namespace. The child elements of 1762 the element are object-specific. 1764 Example response without : 1766 S: 1767 S: 1768 S: 1769 S: 1770 S: Command completed successfully 1771 S: 1772 S: 1773 S: ABC-12346 1774 S: 54322-XYZ 1775 S: 1776 S: 1777 S: 1779 The EPP command is used to change information associated 1780 with an existing object. This action SHOULD be limited to authorized 1781 clients; restricting this action to the sponsoring client is 1782 RECOMMENDED. 1784 3. Result Codes 1786 EPP result codes are based on the theory of reply codes described in 1787 section 4.2.1 of [RFC5321]. EPP uses four decimal digits to describe 1788 the success or failure of each EPP command. Each of the digits of 1789 the reply have special significance. 1791 The first digit denotes command success or failure. The second digit 1792 denotes the response category, such as command syntax or security. 1793 The third and fourth digits provide explicit response detail within 1794 each response category. 1796 There are two values for the first digit of the reply code: 1798 1yzz Positive completion reply. The command was accepted and 1799 processed by the system without error. 1801 2yzz Negative completion reply. The command was not accepted, and 1802 the requested action did not occur. 1804 The second digit groups responses into one of six specific 1805 categories: 1807 x0zz Protocol Syntax 1808 x1zz Implementation-specific Rules 1809 x2zz Security 1810 x3zz Data Management 1811 x4zz Server System 1812 x5zz Connection Management 1814 The third and fourth digits provide response detail within the 1815 categories defined by the first and second digits. The complete list 1816 of valid result codes is enumerated below and in the normative 1817 schema. 1819 Every EPP response MUST include a result code and a human-readable 1820 description of the result code. The language used to represent the 1821 description MAY be identified using an instance of the "lang" 1822 attribute within the element. If not specified, the default 1823 language is English, identified as "en". A description of the 1824 structure of valid values for the "lang" attribute is described in 1825 [RFC4646]. 1827 Response text MAY be translated into other languages, though the 1828 translation MUST preserve the meaning of the code as described here. 1829 Response code values MUST NOT be changed when translating text. 1831 Response text in the table below is enclosed in quotes to clearly 1832 mark the beginning and ending of each response string. Quotes MUST 1833 NOT be used to delimit these strings when returning response text via 1834 the protocol. 1836 Successful command completion responses: 1838 Code Response text in English 1839 ____ ________________________ 1841 1000 "Command completed successfully" 1842 This is the usual response code for a successfully completed 1843 command that is not addressed by any other 1xxx-series 1844 response code. 1846 1001 "Command completed successfully; action pending" 1847 This response code MUST be returned when responding to a 1848 command that requires offline activity before the requested 1849 action can be completed. See Section 2 for a description of 1850 other processing requirements. 1852 1300 "Command completed successfully; no messages" 1853 This response code MUST be returned when responding to a 1854 request command and the server message queue is empty. 1856 1301 "Command completed successfully; ack to dequeue" 1857 This response code MUST be returned when responding to a 1858 request command and a message has been retrieved from 1859 the server message queue. 1861 1500 "Command completed successfully; ending session" 1862 This response code MUST be returned when responding to a 1863 successful command. 1865 Command error responses: 1867 Code Response text in English 1868 ____ ________________________ 1870 2000 "Unknown command" 1871 This response code MUST be returned when a server receives a 1872 command element that is not defined by EPP. 1874 2001 "Command syntax error" 1875 This response code MUST be returned when a server receives an 1876 improperly formed command element. 1878 2002 "Command use error" 1879 This response code MUST be returned when a server receives a 1880 properly formed command element, but the command cannot be 1881 executed due to a sequencing or context error. For example, 1882 a command cannot be executed without having first 1883 completed a command. 1885 2003 "Required parameter missing" 1886 This response code MUST be returned when a server receives a 1887 command for which a required parameter value has not been 1888 provided. 1890 2004 "Parameter value range error" 1891 This response code MUST be returned when a server receives a 1892 command parameter whose value is outside the range of values 1893 specified by the protocol. The error value SHOULD be 1894 returned via a element in the EPP response. 1896 2005 "Parameter value syntax error" 1897 This response code MUST be returned when a server receives a 1898 command containing a parameter whose value is improperly 1899 formed. The error value SHOULD be returned via a 1900 element in the EPP response. 1902 2100 "Unimplemented protocol version" 1903 This response code MUST be returned when a server receives a 1904 command element specifying a protocol version that is not 1905 implemented by the server. 1907 2101 "Unimplemented command" 1908 This response code MUST be returned when a server receives a 1909 valid EPP command element that is not implemented by the 1910 server. For example, a command can be 1911 unimplemented for certain object types. 1913 2102 "Unimplemented option" 1914 This response code MUST be returned when a server receives a 1915 valid EPP command element that contains a protocol option 1916 that is not implemented by the server. 1918 2103 "Unimplemented extension" 1919 This response code MUST be returned when a server receives a 1920 valid EPP command element that contains a protocol command 1921 extension that is not implemented by the server. 1923 2104 "Billing failure" 1924 This response code MUST be returned when a server attempts to 1925 execute a billable operation and the command cannot be 1926 completed due to a client billing failure. 1928 2105 "Object is not eligible for renewal" 1929 This response code MUST be returned when a client attempts to 1930 an object that is not eligible for renewal in 1931 accordance with server policy. 1933 2106 "Object is not eligible for transfer" 1934 This response code MUST be returned when a client attempts to 1935 an object that is not eligible for transfer in 1936 accordance with server policy. 1938 2200 "Authentication error" 1939 This response code MUST be returned when a server notes an 1940 error when validating client credentials. 1942 2201 "Authorization error" 1943 This response code MUST be returned when a server notes a 1944 client authorization error when executing a command. This 1945 error is used to note that a client lacks privileges to 1946 execute the requested command. 1948 2202 "Invalid authorization information" 1949 This response code MUST be returned when a server receives 1950 invalid command authorization information required to confirm 1951 authorization to execute a command. This error is used to 1952 note that a client has the privileges required to execute the 1953 requested command, but the authorization information provided 1954 by the client does not match the authorization information 1955 archived by the server. 1957 2300 "Object pending transfer" 1958 This response code MUST be returned when a server receives a 1959 command to transfer of an object that is pending transfer due 1960 to an earlier transfer request. 1962 2301 "Object not pending transfer" 1963 This response code MUST be returned when a server receives a 1964 command to confirm, reject, or cancel the transfer an object 1965 when no command has been made to transfer the object. 1967 2302 "Object exists" 1968 This response code MUST be returned when a server receives a 1969 command to create an object that already exists in the 1970 repository. 1972 2303 "Object does not exist" 1973 This response code MUST be returned when a server receives a 1974 command to query or transform an object that does not exist 1975 in the repository. 1977 2304 "Object status prohibits operation" 1978 This response code MUST be returned when a server receives a 1979 command to transform an object that cannot be completed due 1980 to server policy or business practices. For example, a 1981 server can disallow commands under terms and 1982 conditions that are matters of local policy, or the server 1983 might have received a command for an object whose 1984 status prohibits deletion. 1986 2305 "Object association prohibits operation" 1987 This response code MUST be returned when a server receives a 1988 command to transform an object that cannot be completed due 1989 to dependencies on other objects that are associated with the 1990 target object. For example, a server can disallow 1991 commands while an object has active associations with other 1992 objects. 1994 2306 "Parameter value policy error" 1995 This response code MUST be returned when a server receives a 1996 command containing a parameter value that is syntactically 1997 valid, but semantically invalid due to local policy. For 1998 example, the server can support a subset of a range of valid 1999 protocol parameter values. The error value SHOULD be 2000 returned via a element in the EPP response. 2002 2307 "Unimplemented object service" 2003 This response code MUST be returned when a server receives a 2004 command to operate on an object service that is not supported 2005 by the server. 2007 2308 "Data management policy violation" 2008 This response code MUST be returned when a server receives a 2009 command whose execution results in a violation of server data 2010 management policies. For example, removing all attribute 2011 values or object associations from an object might be a 2012 violation of a server's data management policies. 2014 2400 "Command failed" 2015 This response code MUST be returned when a server is unable 2016 to execute a command due to an internal server error that is 2017 not related to the protocol. The failure can be transient. 2018 The server MUST keep any ongoing session active. 2020 2500 "Command failed; server closing connection" 2021 This response code MUST be returned when a server receives a 2022 command that cannot be completed due to an internal server 2023 error that is not related to the protocol. The failure is 2024 not transient and will cause other commands to fail as well. 2025 The server MUST end the active session and close the existing 2026 connection. 2028 2501 "Authentication error; server closing connection" 2029 This response code MUST be returned when a server notes an 2030 error when validating client credentials and a server-defined 2031 limit on the number of allowable failures has been exceeded. 2032 The server MUST close the existing connection. 2034 2502 "Session limit exceeded; server closing connection" 2035 This response code MUST be returned when a server receives a 2036 command, and the command cannot be completed because 2037 the client has exceeded a system-defined limit on the number 2038 of sessions that the client can establish. It might be 2039 possible to establish a session by ending existing unused 2040 sessions and closing inactive connections. 2042 4. Formal Syntax 2044 EPP is specified in XML Schema notation. The formal syntax presented 2045 here is a complete schema representation of EPP suitable for 2046 automated validation of EPP XML instances. 2048 Two schemas are presented here. The first schema is the base EPP 2049 schema. The second schema defines elements and structures that can 2050 be used by both the base EPP schema and object mapping schemas. The 2051 BEGIN and END tags are not part of the schema; they are used to note 2052 the beginning and ending of the schema for URI registration purposes. 2054 4.1. Base Schema 2056 BEGIN 2057 2059 2065 2068 2070 2071 2072 Extensible Provisioning Protocol v1.0 schema. 2073 2074 2076 2079 2081 2085 2086 2087 2088 2089 2090 2091 2092 2093 2095 2099 2100 2101 2102 2103 2104 2105 2106 2108 2111 2112 2113 2114 2115 2117 2119 2122 2123 2124 2126 2128 2130 2132 2133 2135 2138 2139 2140 2141 2143 2145 2146 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2159 2160 2161 2162 2163 2164 2166 2168 2169 2170 2172 2174 2176 2178 2179 2181 2182 2183 2185 2187 2189 2191 2193 2194 2196 2197 2198 2200 2201 2203 2204 2205 2206 2207 2208 2210 2211 2212 2213 2214 2215 2216 2217 2218 2220 2221 2222 2223 2224 2225 2227 2230 2231 2232 2234 2235 2237 2238 2239 2241 2242 2244 2247 2248 2249 2250 2251 2252 2254 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2273 2275 2276 2278 2281 2282 2283 2284 2285 2287 2288 2289 2290 2292 2293 2294 2295 2296 2297 2299 2300 2301 2302 2303 2304 2306 2307 2308 2311 2313 2314 2316 2319 2320 2322 2323 2325 2326 2327 2328 2329 2330 2332 2336 2337 2338 2339 2340 2342 2344 2345 2346 2347 2348 2349 2350 2351 2352 2354 2359 2360 2361 2362 2363 2365 2366 2367 2369 2370 2371 2373 2374 2375 2376 2377 2378 2380 2383 2384 2385 2387 2389 2391 2393 2394 2395 2397 2398 2399 2400 2401 2402 2403 2404 2405 2408 2410 2411 2412 2413 2414 2415 2417 2418 2419 2420 2421 2422 2424 2425 2426 2428 2430 2431 2433 2435 2437 2438 2439 2441 2442 2444 2446 2449 2450 2451 2452 2454 2455 2457 2459 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2501 2504 2505 END 2507 4.2. Shared Structure Schema 2509 BEGIN 2510 2512 2517 2518 2519 Extensible Provisioning Protocol v1.0 2520 shared structures schema. 2521 2522 2524 2527 2528 2529 2530 2531 2532 2533 2535 2536 2537 2538 2539 2541 2544 2545 2546 2547 2548 2549 2550 2552 2553 2554 2555 2556 2557 2559 2562 2563 2564 2565 2566 2567 2569 2572 2573 2574 2575 2576 2577 2579 2582 2583 2584 2585 2586 2588 2591 2592 2593 2594 2595 2597 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2611 2614 2615 END 2617 5. Internationalization Considerations 2619 EPP is represented in XML, which provides native support for encoding 2620 information using the Unicode character set and its more compact 2621 representations including UTF-8. Conformant XML processors recognize 2622 both UTF-8 and UTF-16. Though XML includes provisions to identify 2623 and use other character encodings through use of an "encoding" 2624 attribute in an declaration, use of UTF-8 is RECOMMENDED in 2625 environments where parser encoding support incompatibility exists. 2627 EPP includes a provision for returning a human-readable message with 2628 every result code. This document describes result codes in English, 2629 but the actual text returned with a result MAY be provided in a 2630 language negotiated when a session is established. Languages other 2631 than English MUST be noted through specification of a "lang" 2632 attribute for each message. Valid values for the "lang" attribute 2633 and "lang" negotiation elements are described in [RFC4646]. 2635 All date-time values presented via EPP MUST be expressed in Universal 2636 Coordinated Time using the Gregorian calendar. XML Schema allows use 2637 of time zone identifiers to indicate offsets from the zero meridian, 2638 but this option MUST NOT be used with EPP. The extended date-time 2639 form using upper case "T" and "Z" characters defined in 2640 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 2641 values as XML Schema does not support truncated date-time forms or 2642 lower case "T" and "Z" characters. 2644 6. IANA Considerations 2646 This document uses URNs to describe XML namespaces and XML schemas 2647 conforming to a registry mechanism described in [RFC3688]. Four URI 2648 assignments have been registered by the IANA. 2650 Registration request for the EPP namespace: 2652 URI: urn:ietf:params:xml:ns:epp-1.0 2654 Registrant Contact: See the "Author's Address" section of this 2655 document. 2657 XML: None. Namespace URIs do not represent an XML specification. 2659 Registration request for the EPP XML schema: 2661 URI: urn:ietf:params:xml:schema:epp-1.0 2663 Registrant Contact: See the "Author's Address" section of this 2664 document. 2666 XML: See the "Base Schema" section of this document. 2668 Registration request for the EPP shared structure namespace: 2670 URI: urn:ietf:params:xml:ns:eppcom-1.0 2672 Registrant Contact: See the "Author's Address" section of this 2673 document. 2675 XML: None. Namespace URIs do not represent an XML specification. 2677 Registration request for the EPP shared structure XML schema: 2679 URI: urn:ietf:params:xml:schema:eppcom-1.0 2681 Registrant Contact: See the "Author's Address" section of this 2682 document. 2684 XML: See the "Shared Structure Schema" section of this document. 2686 A MIME media type registration template is included in Appendix B. 2688 7. Security Considerations 2690 EPP provides only simple client authentication services. A passive 2691 attack is sufficient to recover client identifiers and passwords, 2692 allowing trivial command forgery. Protection against most common 2693 attacks and more robust security services MUST be provided by other 2694 protocol layers. Specifically, EPP instances MUST be protected using 2695 a transport mechanism or application protocol that provides 2696 integrity, confidentiality, and mutual strong client-server 2697 authentication. 2699 EPP uses a variant of the PLAIN SASL mechanism described in [RFC4616] 2700 to provide a simple application-layer authentication service that 2701 augments or supplements authentication and identification services 2702 that might be available at other protocol layers. Where the PLAIN 2703 SASL mechanism specifies provision of an authorization identifier, 2704 authentication identifier, and password as a single string separated 2705 by ASCII NUL characters, EPP specifies use of a combined 2706 authorization and authentication identifier and a password provided 2707 as distinct XML elements. 2709 Repeated password guessing attempts can be discouraged by limiting 2710 the number of attempts that can be attempted on an open 2711 connection. A server MAY close an open connection if multiple 2712 attempts are made with either an invalid client identifier, 2713 an invalid password, or both an invalid client identifier and an 2714 invalid password. 2716 EPP uses authentication information associated with objects to 2717 confirm object transfer authority. Authentication information 2718 exchanged between EPP clients and third-party entities MUST be 2719 exchanged using a facility that provides privacy and integrity 2720 services to protect against unintended disclosure and modification 2721 while in transit. 2723 EPP instances SHOULD be protected using a transport mechanism or 2724 application protocol that provides anti-replay protection. EPP 2725 provides some protection against replay attacks through command 2726 idempotency and client-initiated transaction identification. 2727 Consecutive command replays will not change the state of an object in 2728 any way. There is, however, a chance of unintended or malicious 2729 consequence if a command is replayed after intervening commands have 2730 changed the object state and client identifiers are not used to 2731 detect replays. For example, a replayed command that 2732 follows a command might succeed without additional 2733 facilities to prevent or detect the replay. 2735 As described in Section 2, EPP includes features that allow for 2736 offline review of transform commands before the requested action is 2737 actually completed. The server is required to notify the client when 2738 offline processing of the action has been completed. Notifications 2739 can be sent using an out-of-band mechanism that is not protected by 2740 the mechanism used to provide EPP transport security. Notifications 2741 sent without EPP's transport security services should be protected 2742 using another mechanism that provides an appropriate level of 2743 protection for the notification. 2745 8. Acknowledgements 2747 This document was originally written as an individual submission 2748 Internet-Draft. The PROVREG working group later adopted it as a 2749 working group document and provided many invaluable comments and 2750 suggested improvements. The author wishes to acknowledge the efforts 2751 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 2752 editorial contributions. 2754 Specific suggestions that have been incorporated into this document 2755 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 2756 Roger Castillo Cortazar, Dave Crocker, Ayesha Damaraju, Sheer El- 2757 Showk, Patrik Faltstrom, James Gould, John Immordino, Dan Kohn, Hong 2758 Liu, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, 2759 Andrew Newton, Budi Rahardjo, Asbjorn Steira, Rick Wesson, and Jay 2760 Westerdal. 2762 9. References 2764 9.1. Normative References 2766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2767 Requirement Levels", BCP 14, RFC 2119, March 1997. 2769 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2770 Languages", BCP 18, RFC 2277, January 1998. 2772 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2773 RFC 2914, September 2000. 2775 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2776 10646", STD 63, RFC 3629, November 2003. 2778 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2779 January 2004. 2781 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 2782 Languages", BCP 47, RFC 4646, September 2006. 2784 [W3C.REC-xml-20040204] 2785 Yergeau, F., Maler, E., Bray, T., Paoli, J., and C. 2786 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 2787 (Third Edition)", World Wide Web Consortium 2788 FirstEdition REC-xml-20040204, February 2004, 2789 . 2791 [W3C.REC-xmlschema-1-20041028] 2792 Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, 2793 "XML Schema Part 1: Structures Second Edition", World Wide 2794 Web Consortium Recommendation REC-xmlschema-1-20041028, 2795 October 2004, 2796 . 2798 [W3C.REC-xmlschema-2-20041028] 2799 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 2800 Second Edition", World Wide Web Consortium 2801 Recommendation REC-xmlschema-2-20041028, October 2004, 2802 . 2804 9.2. Informative References 2806 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2807 RFC 793, September 1981. 2809 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 2810 10646", RFC 2781, February 2000. 2812 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2813 Types", RFC 3023, January 2001. 2815 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 2816 RFC 3080, March 2001. 2818 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol 2819 Requirements", RFC 3375, September 2002. 2821 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 2822 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 2824 [RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2825 RFC 4930, May 2007. 2827 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2828 RFC 4960, September 2007. 2830 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2831 October 2008. 2833 [W3C.REC-P3P-20020416] 2834 Marchiori, M., "The Platform for Privacy Preferences 1.0 2835 (P3P1.0) Specification", World Wide Web Consortium 2836 Recommendation REC-P3P-20020416, April 2002, 2837 . 2839 Appendix A. Object Mapping Template 2841 This appendix describes a recommended outline for documenting the EPP 2842 mapping of an object. Documents that describe EPP object mappings 2843 SHOULD describe the mapping in a format similar to the one used here. 2844 Additional sections are required if the object mapping is written in 2845 Internet-Draft or RFC format. 2847 1. Introduction 2849 Provide an introduction that describes the object and an overview 2850 of the mapping to EPP. 2852 2. Object Attributes 2854 Describe the attributes associated with the object, including 2855 references to syntax specifications as appropriate. Examples of 2856 object attributes include a name or identifier and dates 2857 associated with modification events. 2859 3. EPP Command Mapping 2861 3.1. EPP Query Commands 2863 3.1.1. EPP Command 2865 Describe the object-specific mappings required to implement the 2866 EPP command. Include both sample commands and sample 2867 responses. 2869 3.1.2. EPP Command 2871 Describe the object-specific mappings required to implement the 2872 EPP command. Include both sample commands and sample 2873 responses. 2875 3.1.3. EPP Command 2877 Describe the object-specific mappings required to implement the 2878 EPP command. Include both sample commands and sample 2879 responses. 2881 3.1.4. EPP Command 2883 Describe the object-specific mappings required to implement the 2884 EPP query command. Include both sample commands and 2885 sample responses. 2887 3.2. EPP Transform Commands 2889 3.2.1. EPP Command 2891 Describe the object-specific mappings required to implement the 2892 EPP command. Include both sample commands and sample 2893 responses. Describe the status of the object with respect to 2894 time, including expected client and server behavior if a validity 2895 period is used. 2897 3.2.2. EPP Command 2899 Describe the object-specific mappings required to implement the 2900 EPP command. Include both sample commands and sample 2901 responses. 2903 3.2.3. EPP Command 2905 Describe the object-specific mappings required to implement the 2906 EPP command. Include both sample commands and sample 2907 responses. 2909 3.2.4. EPP Command 2911 Describe the object-specific mappings required to implement the 2912 EPP command. Include both sample commands and sample 2913 responses. 2915 3.2.4. EPP Command 2917 Describe the object-specific mappings required to implement the 2918 EPP command. Include both sample commands and sample 2919 responses. 2921 4. Formal Syntax 2923 Provide the XML schema for the object mapping. An XML DTD MUST 2924 NOT be used as DTDs do not provide sufficient support for XML 2925 namespaces and strong data typing. 2927 Appendix B. Media Type Registration: application/epp+xml 2929 MIME media type name: application 2931 MIME subtype name: epp+xml 2933 Required parameters: none 2935 Optional parameters: Same as the charset parameter of application/xml 2936 as specified in [RFC3023]. 2938 Encoding considerations: Same as the encoding considerations of 2939 application/xml as specified in [RFC3023]. 2941 Security considerations: This type has all of the security 2942 considerations described in [RFC3023] plus the considerations 2943 specified in the Security Considerations section of this document. 2945 Interoperability considerations: XML has proven to be interoperable 2946 across WWW Distributed Authoring and Versioning (WebDAV) clients and 2947 servers, and for import and export from multiple XML authoring tools. 2948 For maximum interoperability, validating processors are recommended. 2949 Although non-validating processors can be more efficient, they are 2950 not required to handle all features of XML. For further information, 2951 see Section 2.9, "Standalone Document Declaration", and Section 5, 2952 "Conformance", of [W3C.REC-xml-20040204]. 2954 Published specification: This document. 2956 Applications that use this media type: EPP is device-, platform-, and 2957 vendor-neutral and is supported by multiple service providers. 2959 Additional information: If used, magic numbers, fragment identifiers, 2960 base URIs, and use of the BOM should be as specified in [RFC3023]. 2962 Magic number(s): None. 2964 File extension(s): .xml 2966 Macintosh file type code(s): "TEXT" 2968 Person & email address for further information: See the "Author's 2969 Address" section of this document. 2971 Intended usage: COMMON 2973 Author/Change controller: IETF 2975 Appendix C. Changes from RFC 4930 2977 1. Changed "This document obsoletes RFC 3730" to "This document is 2978 intended to obsolete RFC 4930". 2979 2. Replaced references to RFC 2595 with references to RFC 4616. 2980 3. Replaced references to RFC 2821 with references to RFC 5321. 2981 4. Replaced references to RFC 2960 with references to RFC 4960. 2982 5. Replaced references to RFC 3066 with references to RFC 4646. 2983 6. Replaced references to RFC 3730 with references to RFC 4930. 2984 7. Added "A protocol client that is authorized to manage an 2985 existing object is described as a "sponsoring" client throughout 2986 this document" in Section 1.1. 2987 8. Changed "This action MUST be open to all authorized clients" to 2988 "This command MUST be available to all clients" in the 2989 descriptions of the and commands. 2990 9. Changed "Specific result codes are listed in the table below" to 2991 "The complete list of valid result codes is enumerated below and 2992 in the normative schema" in Section 3. 2993 10. Added new paragraph to Section 7 to give guidance on the need to 2994 protect offline transaction notices. 2995 11. Added reference to Appendix B in the IANA Considerations 2996 section. 2998 Author's Address 3000 Scott Hollenbeck 3001 VeriSign, Inc. 3002 21345 Ridgetop Circle 3003 Dulles, VA 20166-6503 3004 US 3006 EMail: shollenbeck@verisign.com