idnits 2.17.1 draft-hollenbeck-epp-rfc3730bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3108. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (November 17, 2006) is 6370 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 3066 (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3730 (Obsoleted by RFC 4930) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 12 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: 3730 (if approved) November 17, 2006 5 Intended status: Standards Track 6 Expires: May 21, 2007 8 Extensible Provisioning Protocol (EPP) 9 draft-hollenbeck-epp-rfc3730bis-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2006). 40 Abstract 42 This document describes an application layer client-server protocol 43 for the provisioning and management of objects stored in a shared 44 central repository. Specified in XML, the protocol defines generic 45 object management operations and an extensible framework that maps 46 protocol operations to objects. This document includes a protocol 47 specification, an object mapping template, and an XML media type 48 registration. This document obsoletes RFC 3730 if approved. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 54 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Transport Mapping Considerations . . . . . . . . . . . . . 7 56 2.2. Protocol Identification . . . . . . . . . . . . . . . . . 8 57 2.3. Hello Format . . . . . . . . . . . . . . . . . . . . . . . 8 58 2.4. Greeting Format . . . . . . . . . . . . . . . . . . . . . 8 59 2.5. Command Format . . . . . . . . . . . . . . . . . . . . . . 12 60 2.6. Response Format . . . . . . . . . . . . . . . . . . . . . 13 61 2.7. Protocol Extension Framework . . . . . . . . . . . . . . . 18 62 2.7.1. Protocol Extension . . . . . . . . . . . . . . . . . . 18 63 2.7.2. Object Extension . . . . . . . . . . . . . . . . . . . 18 64 2.7.3. Command-Response Extension . . . . . . . . . . . . . . 19 65 2.8. Object Identification . . . . . . . . . . . . . . . . . . 20 66 2.9. Protocol Commands . . . . . . . . . . . . . . . . . . . . 21 67 2.9.1. Session Management Commands . . . . . . . . . . . . . 21 68 2.9.1.1. EPP Command . . . . . . . . . . . . . . . 21 69 2.9.1.2. EPP Command . . . . . . . . . . . . . . . 24 70 2.9.2. Query Commands . . . . . . . . . . . . . . . . . . . . 25 71 2.9.2.1. EPP Command . . . . . . . . . . . . . . . 25 72 2.9.2.2. EPP Command . . . . . . . . . . . . . . . . 27 73 2.9.2.3. EPP Command . . . . . . . . . . . . . . . . 28 74 2.9.2.4. EPP Query Command . . . . . . . . . . . 32 75 2.9.3. Object Transform Commands . . . . . . . . . . . . . . 34 76 2.9.3.1. EPP Command . . . . . . . . . . . . . . . 34 77 2.9.3.2. EPP Command . . . . . . . . . . . . . . . 36 78 2.9.3.3. EPP Command . . . . . . . . . . . . . . . 37 79 2.9.3.4. EPP Command . . . . . . . . . . . . . . 39 80 2.9.3.5. EPP Command . . . . . . . . . . . . . . . 41 81 3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . 42 82 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48 83 4.1. Base Schema . . . . . . . . . . . . . . . . . . . . . . . 48 84 4.2. Shared Structure Schema . . . . . . . . . . . . . . . . . 58 85 5. Internationalization Considerations . . . . . . . . . . . . . 60 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 61 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 92 Appendix A. Object Mapping Template . . . . . . . . . . . . . . . 64 93 Appendix B. Media Type Registration: application/epp+xml . . . . 66 94 Appendix C. Changes from RFC 3730 . . . . . . . . . . . . . . . . 67 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70 96 Intellectual Property and Copyright Statements . . . . . . . . . . 71 98 1. Introduction 100 This document describes specifications for the Extensible 101 Provisioning Protocol (EPP) version 1.0, an XML text protocol that 102 permits multiple service providers to perform object provisioning 103 operations using a shared central object repository. EPP is 104 specified using the Extensible Markup Language (XML) 1.0 as described 105 in [W3C.REC-xml-20040204] and XML Schema notation as described in 106 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 107 EPP meets and exceeds the requirements for a generic registry 108 registrar protocol as described in [RFC3375]. This document 109 obsoletes RFC 3730 [RFC3730] if approved. 111 EPP content is identified by MIME media type application/epp+xml. 112 Registration information for this media type is included in an 113 appendix to this document. 115 EPP is intended for use in diverse operating environments where 116 transport and security requirements vary greatly. It is unlikely 117 that a single transport or security specification will meet the needs 118 of all anticipated operators, so EPP was designed for use in a 119 layered protocol environment. Bindings to specific transport and 120 security protocols are outside the scope of this specification. 122 This original motivation for this protocol was to provide a standard 123 Internet domain name registration protocol for use between domain 124 name registrars and domain name registries. This protocol provides a 125 means of interaction between a registrar's applications and registry 126 applications. It is expected that this protocol will have additional 127 uses beyond domain name registration. 129 XML is case sensitive. Unless stated otherwise, XML specifications 130 and examples provided in this document MUST be interpreted in the 131 character case presented to develop a conforming implementation. 133 1.1. Conventions Used In This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 In examples, "C:" represents lines sent by a protocol client and "S:" 140 represents lines returned by a protocol server. Indentation and 141 white space in examples is provided only to illustrate element 142 relationships and is not a REQUIRED feature of this protocol. 144 2. Protocol Description 146 EPP is a stateful XML protocol that can be layered over multiple 147 transport protocols. Protected using lower-layer security protocols, 148 clients exchange identification, authentication, and option 149 information, and then engage in a series of client-initiated command- 150 response exchanges. All EPP commands are atomic (there is no partial 151 success or partial failure) and designed so that they can be made 152 idempotent (executing a command more than once has the same net 153 effect on system state as successfully executing the command once). 155 EPP provides four basic service elements: service discovery, 156 commands, responses, and an extension framework that supports 157 definition of managed objects and the relationship of protocol 158 requests and responses to those objects. 160 An EPP server MUST respond to client-initiated communication (which 161 can be either a lower-layer connection request or an EPP service 162 discovery message) by returning a greeting to a client. A server 163 MUST promptly respond to each EPP command with a coordinated response 164 that describes the results of processing the command. The following 165 server state machine diagram illustrates the message exchange process 166 in detail: 168 | 169 V 170 +-----------------+ +-----------------+ 171 | Waiting for | Connected | Prepare | 172 | Client |----------------->| Greeting | 173 +-----------------+ or +-----------------+ 174 ^ | 175 | Close Connection Send | 176 | or Idle Greeting | 177 +-----------------+ V 178 | End | Timeout +-----------------+ 179 | Session |<-----------------| Waiting for | 180 +-----------------+ | Client | 181 ^ ^ ^ Send +-------->| Authentication | 182 | | | Response | +-----------------+ 183 | | | +--------------+ | 184 | | | | Prepare Fail | | 185 | | +-----| Response | | Received 186 | | Send +--------------+ V 187 | | 2501 ^ +-----------------+ 188 | | Response | | Processing | 189 | | +---------| | 190 | | Auth Fail +-----------------+ 191 | | Timeout | 192 | +-------------------------------+ | Auth OK 193 | | V 194 | +-----------------+ +-----------------+ 195 | | Prepare |<----------| Waiting for | 196 | | Greeting |---------->| Command or | 197 | +-----------------+ Send | | 198 | Send x5xx Greeting +-----------------+ 199 | Response +-----------------+ Send ^ | 200 +-----------| Prepare | Response | | Command 201 | Response |----------+ | Received 202 +-----------------+ V 203 ^ +-----------------+ 204 Command | | Processing | 205 Processed +----------| Command | 206 +-----------------+ 208 Figure 1: EPP Server State Machine 210 EPP commands fall into three categories: session management commands, 211 query commands, and data transform commands. Session management 212 commands are used to establish and end persistent sessions with an 213 EPP server. Query commands are used to perform read-only object 214 information retrieval operations. Transform commands are used to 215 perform read-write object management operations. 217 Commands are processed by a server in the order they are received 218 from a client. Though an immediate response confirming receipt and 219 processing of the command is produced by the server, the protocol 220 includes features that allow for offline review of transform commands 221 before the requested action is actually completed. In such 222 situations the response from the server MUST clearly note that the 223 command has been received and processed, but the requested action is 224 pending. The state of the corresponding object MUST clearly reflect 225 processing of the pending action. The server MUST also notify the 226 client when offline processing of the action has been completed. 227 Object mappings SHOULD describe standard formats for notices that 228 describe completion of offline processing. 230 EPP uses XML namespaces to provide an extensible object management 231 framework and to identify schemas required for XML instance parsing 232 and validation. These namespaces and schema definitions are used to 233 identify both the base protocol schema and the schemas for managed 234 objects. The XML namespace prefixes used in examples (such as the 235 string "foo" in "xmlns:foo") are solely for illustrative purposes. A 236 conforming implementation MUST NOT require the use of these or any 237 other specific namespace prefixes. 239 All XML instances SHOULD begin with an declaration to 240 identify the version of XML that is being used, optionally identify 241 use of the character encoding used, and optionally provide a hint to 242 an XML parser that an external schema file is needed to validate the 243 XML instance. Conformant XML parsers recognize both UTF-8 (defined 244 in RFC 3629 [RFC3629]) and UTF-16 (defined in RFC 2781 [RFC2781]); 245 per RFC 2277 [RFC2277] UTF-8 is the RECOMMENDED character encoding 246 for use with EPP. 248 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 249 UTF-8 is the default encoding assumed by XML in the absence of an 250 "encoding" attribute or a byte order mark (BOM), thus the "encoding" 251 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 252 used. EPP clients and servers MUST accept a UTF-8 BOM if present, 253 though emitting a UTF-8 BOM is NOT RECOMMENDED. 255 Example XML declarations: 257 259 261 263 265 2.1. Transport Mapping Considerations 267 As described previously, EPP can be layered over multiple transport 268 protocols. There are, however, a common set of considerations that 269 MUST be addressed by any transport mapping defined for EPP. These 270 include: 272 - The transport mapping MUST preserve command order. 274 - The transport mapping MUST address the relationship between 275 sessions and the client-server connection concept. 277 - The transport mapping MUST preserve the stateful nature of the 278 protocol. 280 - The transport mapping MUST frame data units. 282 - The transport mapping MUST be onto a transport such as TCP 283 [RFC0793] or SCTP [RFC2960] that provides congestion avoidance 284 that follows RFC 2914 [RFC2914], or if it maps onto a protocol 285 such as SMTP [RFC2821] or BEEP [RFC3080], then the performance 286 issues need to take into account issues of overload, server 287 availability and so forth. 289 - The transport mapping MUST ensure reliability. 291 - The transport mapping MUST explicitly allow or prohibit 292 pipelining. 294 Pipelining, also known as command streaming, is when a client sends 295 multiple commands to a server without waiting for each corresponding 296 response. After sending the commands, the client waits for the 297 responses to arrive in the order corresponding to the completed 298 commands. Performance gains can sometimes be realized with 299 pipelining, especially with high latency transports, but there are 300 additional considerations associated with defining a transport 301 mapping that supports pipelining: 303 - Commands MUST be processed independent of each other. 305 - Depending on the transport, pipelining MAY be possible in the form 306 of sending a complete session in a well-defined "batch". 308 - The transport mapping MUST describe how an error in processing a 309 command affects continued operation of the session. 311 A transport mapping MUST explain how all of these requirements are 312 met given the transport protocol being used to exchange data. 314 2.2. Protocol Identification 316 All EPP XML instances MUST begin with an element. This element 317 identifies the start of an EPP protocol element and the namespace 318 used within the protocol. The start element and the associated 319 ending element MUST be applied to all structures sent by both 320 clients and servers. 322 Example "start" and "end" EPP elements: 324 325 327 2.3. Hello Format 329 EPP MAY be carried over both connection-oriented and connection-less 330 transport protocols. An EPP client MAY request a from an 331 EPP server at any time by sending a to a server. Use of this 332 element is essential in a connection-less environment where a server 333 can not return a in response to a client-initiated 334 connection. An EPP MUST be an empty element with no child 335 elements. 337 Example : 339 C: 340 C: 341 C: 342 C: 344 2.4. Greeting Format 346 An EPP server responds to a successful connection and element 347 by returning a element to the client. An EPP greeting 348 contains the following elements: 350 - An element that contains the name of the server. 352 - An element that contains the server's current date and 353 time in UTC. 355 - An element that identifies the services supported by the 356 server, including: 358 - One or more elements that identify the protocol 359 versions supported by the server. 361 - One or more elements that contain the identifiers of the 362 text response languages known by the server. Language 363 identifiers MUST be structured as documented in [RFC3066]. 365 - One or more elements that contain namespace URIs 366 representing the objects that the server is capable of 367 managing. A server MAY limit object management privileges on a 368 per-client basis. 370 - An OPTIONAL element that contains one or more 371 elements that contain namespace URIs representing 372 object extensions supported by the server. 374 - A (data collection policy) element that contains child 375 elements used to describe the server's privacy policy for data 376 collection and management. Policy implications usually extend 377 beyond the client-server relationship. Both clients and 378 servers can have relationships with other entities that need to 379 know the server operator's data collection policy to make 380 informed provisioning decisions. Policy information MUST be 381 disclosed to provisioning entities, though the method of 382 disclosing policy data outside of direct protocol interaction 383 is beyond the scope of this specification. Child elements 384 include the following: 386 - An element that describes the access provided by 387 the server to the client on behalf of the originating data 388 source. The element MUST contain one of the 389 following child elements: 391 - : Access is given to all identified data. 393 - : No access is provided to identified data. 395 - : Data is not persistent, so no access is 396 possible. 398 - : Access is given to identified data relating 399 to individuals and organizational entities. 401 - : Access is given to identified data 402 relating to individuals, organizational entities, and 403 other data of a non-personal nature. 405 - : Access is given to other identified data of a 406 non- personal nature. 408 - One or more elements that describe data 409 collection purposes, data recipients, and data retention. 410 Each element MUST contain a element, a 411 element, and a element. The 412 element MUST contain one or more of the following 413 child elements that describe the purposes for which data is 414 collected: 416 - : Administrative purposes. Information can be 417 used for administrative and technical support of the 418 provisioning system. 420 - : Contact for marketing purposes. Information 421 can be used to contact individuals, through a 422 communications channel other than the protocol, for the 423 promotion of a product or service. 425 - : Object provisioning purposes. Information can 426 be used to identify objects and inter-object 427 relationships. 429 - : Other purposes. Information may be used in 430 other ways not captured by the above definitions. 432 - The element MUST contain one or more of the 433 following child elements that describes the recipients of 434 collected data: 436 - : Other entities following unknown practices. 438 - : Server operator and/or entities acting as agents 439 or entities for whom the server operator is acting as an 440 agent. An agent in this instance is defined as a third 441 party that processes data only on behalf of the service 442 provider for the completion of the stated purposes. The 443 element contains an OPTIONAL element 444 that can be used to describe the recipient. 446 - : Public forums. 448 - : Other entities following server practices. 450 - : Unrelated third parties. 452 - The element MUST contain one of the following 453 child elements that describes data retention practices: 455 - : Data persists per business practices. 457 - : Data persists indefinitely. 459 - : Data persists per legal requirements. 461 - : Data is not persistent, and is not retained for 462 more than a brief period of time necessary to make use of 463 it during the course of a single online interaction. 465 - : Data persists to meet the stated purpose. 467 - An OPTIONAL element that describes the lifetime of 468 the policy. The element MUST contain one of the 469 following child elements: 471 - : The policy is valid from the current date 472 and time until it expires on the specified date and time. 474 - : The policy is valid from the current date 475 and time until the end of the specified duration. 477 Data collection policy elements are based on work described in the 478 World Wide Web Consortium's Platform for Privacy Preferences 479 [W3C.REC-P3P-20020416] specification. 481 Example greeting: 483 S: 484 S: 485 S: 486 S: Example EPP server epp.example.com 487 S: 2000-06-08T22:00:00.0Z 488 S: 489 S: 1.0 490 S: en 491 S: fr 492 S: urn:ietf:params:xml:ns:obj1 493 S: urn:ietf:params:xml:ns:obj2 494 S: urn:ietf:params:xml:ns:obj3 495 S: 496 S: http://custom/obj1ext-1.0 497 S: 498 S: 499 S: 500 S: 501 S: 502 S: 503 S: 504 S: 505 S: 506 S: 507 S: 508 S: 510 2.5. Command Format 512 An EPP client interacts with an EPP server by sending a command to 513 the server and receiving a response from the server. In addition to 514 the standard EPP elements, an EPP command contains the following 515 elements: 517 - A command element whose tag corresponds to one of the valid EPP 518 commands described in this document. The command element MAY 519 contain either protocol-specified or object-specified child 520 elements. 522 - An OPTIONAL element that MAY be used for server- 523 defined command extensions. 525 - An OPTIONAL (client transaction identifier) element that 526 MAY be used to uniquely identify the command to the client. 527 Clients are responsible for maintaining their own transaction 528 identifier space to ensure uniqueness. 530 Example command with object-specified child elements: 532 C: 533 C: 534 C: 535 C: 536 C: 537 C: example 538 C: 539 C: 540 C: ABC-12345 541 C: 542 C: 544 2.6. Response Format 546 An EPP server responds to a client command by returning a response to 547 the client. EPP commands are atomic, so a command will either 548 succeed completely or fail completely. Success and failure results 549 MUST NOT be mixed. In addition to the standard EPP elements, an EPP 550 response contains the following elements: 552 - One or more elements that document the success or failure 553 of command execution. If the command was processed successfully, 554 only one element MUST be returned. If the command was 555 not processed successfully, multiple elements MAY be 556 returned to document failure conditions. Each element 557 contains the following attribute and child elements: 559 - A "code" attribute whose value is a four-digit, decimal number 560 that describes the success or failure of the command. 562 - A element containing a human-readable description of the 563 response code. The language of the response is identified via 564 an OPTIONAL "lang" attribute. If not specified, the default 565 attribute value MUST be "en" (English). 567 - Zero or more OPTIONAL elements that identify a client- 568 provided element (including XML tag and value) or other 569 information that caused a server error condition. 571 - Zero or more OPTIONAL elements that can be used to 572 provide additional error diagnostic information, including: 574 - A element that identifies a client-provided element 575 (including XML tag and value) that caused a server error 576 condition. 578 - A element containing a human-readable message that 579 describes the reason for the error. The language of the 580 response is identified via an OPTIONAL "lang" attribute. If 581 not specified, the default attribute value MUST be "en" 582 (English). 584 - An OPTIONAL element that describes messages queued for 585 client retrieval. A element MUST NOT be present if there 586 are no messages queued for client retrieval. A element MAY 587 be present in responses to EPP commands other than the 588 command if messages are queued for retrieval. A element 589 MUST be present in responses to the EPP command if messages 590 are queued for retrieval. The element contains the 591 following attributes: 593 - A "count" attribute that describes the number of messages that 594 exist in the queue. 596 - An "id" attribute used to uniquely identify the message at the 597 head of the queue. 599 The element contains the following OPTIONAL child elements 600 that MUST be returned in response to a request command and 601 MUST NOT be returned in response to any other command, including a 602 acknowledgement: 604 - A element that contains the date and time that the 605 message was enqueued. 607 - A element containing a human-readable message. The 608 language of the response is identified via an OPTIONAL "lang" 609 attribute. If not specified, the default attribute value MUST 610 be "en" (English). This element MAY contain XML content for 611 formatting purposes, but the XML content is not specified by 612 the protocol and will thus not be processed for validity. 614 - An OPTIONAL (response data) element that contains child 615 elements specific to the command and associated object. 617 - An OPTIONAL element that MAY be used for server- 618 defined response extensions. 620 - A (transaction identifier) element containing the 621 transaction identifier assigned by the server to the command for 622 which the response is being returned. The transaction identifier 623 is formed using the associated with the command if 624 supplied by the client and a (server transaction 625 identifier) that is assigned by and unique to the server. 627 Transaction identifiers provide command-response synchronization 628 integrity. They SHOULD be logged, retained, and protected to ensure 629 that both the client and the server have consistent temporal and 630 state management records. 632 Example response without or : 634 S: 635 S: 636 S: 637 S: 638 S: Command completed successfully 639 S: 640 S: 641 S: ABC-12345 642 S: 54321-XYZ 643 S: 644 S: 645 S: 646 Example response with : 648 S: 649 S: 650 S: 651 S: 652 S: Command completed successfully 653 S: 654 S: 655 S: 656 S: example 657 S: 658 S: 659 S: 660 S: ABC-12345 661 S: 54321-XYZ 662 S: 663 S: 664 S: 665 Example response with error value elements: 667 S: 668 S: 669 S: 670 S: 671 S: Parameter value range error 672 S: 673 S: 2525 674 S: 675 S: 676 S: 677 S: Parameter value syntax error 678 S: 679 S: ex(ample 680 S: 681 S: 682 S: 683 S: abc.ex(ample 684 S: 685 S: Invalid character found. 686 S: 687 S: 688 S: 689 S: ABC-12345 690 S: 54321-XYZ 691 S: 692 S: 693 S: 695 Example response with notice of waiting server messages: 697 S: 698 S: 699 S: 700 S: 701 S: Command completed successfully 702 S: 703 S: 704 S: 705 S: ABC-12345 706 S: 54321-XYZ 707 S: 708 S: 709 S: 711 Command success or failure MUST NOT be assumed if no response is 712 returned or if a returned response is malformed. Protocol 713 idempotency ensures the safety of retrying a command in cases of 714 response delivery failure. 716 2.7. Protocol Extension Framework 718 EPP provides an extension framework that allows features to be added 719 at the protocol, object, and command-response levels. 721 2.7.1. Protocol Extension 723 The EPP extension framework allows for definition of new protocol 724 elements identified using XML namespace notation with a reference to 725 an XML schema that defines the namespace. The element that 726 identifies the beginning of a protocol instance includes multiple 727 child element choices, one of which is an element whose 728 children define the extension. For example, a protocol extension 729 element would be described in generic terms as follows: 731 C: 732 C: 733 C: 734 C: 735 C: 736 C: 737 C: 738 C: 740 This document does not define mappings for specific extensions. 741 Extension specifications MUST be described in separate documents that 742 define the objects and operations subject to the extension. 744 2.7.2. Object Extension 746 EPP provides an extensible object management framework that defines 747 the syntax and semantics of protocol operations applied to a managed 748 object. This framework pushes the definition of each protocol 749 operation into the context of a specific object, providing the 750 ability to add mappings for new objects without having to modify the 751 base protocol. 753 Protocol elements that contain data specific to objects are 754 identified using XML namespace notation with a reference to an XML 755 schema that defines the namespace. The schema for EPP supports use 756 of dynamic object schemas on a per-command and per-response basis. 757 For example, the start of an object-specific command element would be 758 described in generic terms as follows: 760 C: 761 C: 762 C: 763 C: 764 C: 766 An object-specific response element would be described similarly: 768 S: 769 S: 770 S: 771 S: 772 S: 774 This document does not define mappings for specific objects. The 775 mapping of EPP to an object MUST be described in separate documents 776 that specifically address each command and response in the context of 777 the object. A suggested object mapping outline is included as an 778 appendix to this document. 780 2.7.3. Command-Response Extension 782 EPP provides a facility for protocol command and response extensions. 783 Protocol commands and responses MAY be extended by an 784 element that contains additional elements whose syntax and semantics 785 are not explicitly defined by EPP or an EPP object mapping. This 786 element is OPTIONAL. Extensions are typically defined by agreement 787 between client and server and MAY be used to extend EPP for unique 788 operational needs. A server-extended command element would be 789 described in generic terms as follows: 791 C: 792 C: 793 C: 794 C: 795 C: 796 C: 797 C: 798 C: 799 C: 800 C: 801 C: 803 An server-extended response element would be described similarly: 805 S: 806 S: 807 S: Command completed successfully 808 S: 809 S: 810 S: 811 S: 812 S: 813 S: ABC-12345 814 S: 54321-XYZ 815 S: 816 S: 818 This document does not define any specific server extensions. The 819 mapping of server extensions to EPP MUST be described in separate 820 documents that specifically address extended commands and responses 821 in the server's operational context. 823 2.8. Object Identification 825 Some objects, such as name servers and contacts, can have utility in 826 multiple repositories. However, maintaining disjoint copies of 827 object information in multiple repositories can lead to 828 inconsistencies that have adverse consequences for the Internet. For 829 example, changing a name server name in one repository, but not in a 830 second repository that refers to the server for domain name 831 delegation, can produce unexpected DNS query results. 833 Globally unique identifiers can help facilitate object information 834 sharing between repositories. A globally unique identifier MUST be 835 assigned to every object when the object is created; the identifier 836 MUST be returned to the client as part of any request to retrieve the 837 detailed attributes of an object. Specific identifier values are a 838 matter of repository policy, but they SHOULD be constructed according 839 to the following algorithm: 841 a. Divide the provisioning repository world into a number of object 842 repository classes. 844 b. Each repository within a class is assigned an identifier that is 845 maintained by IANA. 847 c. Each repository is responsible for assigning a unique local 848 identifier for each object within the repository. 850 d. The globally unique identifier is a concatenation of the local 851 identifier, followed by a hyphen ("-", ASCII value 0x002D), 852 followed by the repository identifier. 854 2.9. Protocol Commands 856 EPP provides commands to manage sessions, retrieve object 857 information, and perform transformation operations on objects. All 858 EPP commands are atomic and designed so that they can be made 859 idempotent, either succeeding completely or failing completely and 860 producing predictable results in case of repeated execution. This 861 section describes each EPP command, including examples with 862 representative server responses. 864 2.9.1. Session Management Commands 866 EPP provides two commands for session management: to 867 establish a session with a server, and to end a session with 868 a server. The command establishes an ongoing server session 869 that preserves client identity and authorization information during 870 the duration of the session. 872 2.9.1.1. EPP Command 874 The EPP command is used to establish a session with an EPP 875 server in response to a greeting issued by the server. A 876 command MUST be sent to a server before any other EPP command to 877 establish an ongoing session. A server operator MAY limit the number 878 of failed login attempts N, 1 <= N <= infinity, after which a login 879 failure results in the connection to the server (if a connection 880 exists) being closed. 882 A client identifier and initial password MUST be created on the 883 server before a client can successfully complete a command. 884 The client identifier and initial password MUST be delivered to the 885 client using an out-of-band method that protects the identifier and 886 password from inadvertent disclosure. 888 In addition to the standard EPP command elements, the command 889 contains the following child elements: 891 - A element that contains the client identifier assigned to 892 the client by the server. 894 - A element that contains the client's plain text password. 895 The value of this element is case sensitive. 897 - An OPTIONAL element that contains a new plain text 898 password to be assigned to the client for use with subsequent 899 commands. The value of this element is case sensitive. 901 - An element that contains the following child elements: 903 - A element that contains the protocol version to be 904 used for the command or ongoing server session. 906 - A element that contains the text response language to be 907 used for the command or ongoing server session commands. 909 The values of the and elements MUST exactly match 910 one of the values presented in the EPP greeting. 912 - A element that contains one or more elements that 913 contain namespace URIs representing the objects to be managed 914 during the session. The element MAY contain an OPTIONAL 915 element that contains one or more elements 916 that identify object extensions to be used during the session. 918 The PLAIN SASL mechanism presented in [RFC2595] describes a format 919 for providing a user identifier, an authorization identifier, and a 920 password as part of a single plain text string. The EPP 921 authentication mechanism is similar, though EPP does not require a 922 session-level authorization identifier and the user identifier and 923 password are separated into distinct XML elements. Additional 924 identification and authorization schemes MUST be provided at other 925 protocol layers to provide more robust security services. 927 Example command: 929 C: 930 C: 931 C: 932 C: 933 C: ClientX 934 C: foo-BAR2 935 C: bar-FOO2 936 C: 937 C: 1.0 938 C: en 939 C: 940 C: 941 C: urn:ietf:params:xml:ns:obj1 942 C: urn:ietf:params:xml:ns:obj2 943 C: urn:ietf:params:xml:ns:obj3 944 C: 945 C: http://custom/obj1ext-1.0 946 C: 947 C: 948 C: 949 C: ABC-12345 950 C: 951 C: 953 When a command has been processed successfully, a server MUST 954 respond with an EPP response with no element. If 955 successful, the server will respond by creating and maintaining a new 956 session that SHOULD be terminated by a future command. 958 Example response: 960 S: 961 S: 962 S: 963 S: 964 S: Command completed successfully 965 S: 966 S: 967 S: ABC-12345 968 S: 54321-XYZ 969 S: 970 S: 971 S: 973 The EPP command is used to establish a session with an EPP 974 server. A command MUST be rejected if received within the 975 bounds of an existing session. This action MUST be open to all 976 authorized clients. 978 2.9.1.2. EPP Command 980 The EPP command is used to end a session with an EPP server. 981 The command MUST be represented as an empty element with no 982 child elements. 984 A server MAY end a session due to client inactivity or excessive 985 client session longevity. The parameters for determining excessive 986 client inactivity or session longevity are a matter of server policy 987 and are not specified by this protocol. 989 Transport mappings MUST explicitly describe any connection-oriented 990 processing that takes place after processing a command and 991 ending a session. 993 Example command: 995 C: 996 C: 997 C: 998 C: 999 C: ABC-12345 1000 C: 1001 C: 1003 When a command has been processed successfully, a server 1004 MUST respond with an EPP response with no element. If 1005 successful, the server MUST also end the current session. 1007 Example response: 1009 S: 1010 S: 1011 S: 1012 S: 1013 S: Command completed successfully; ending session 1014 S: 1015 S: 1016 S: ABC-12345 1017 S: 54321-XYZ 1018 S: 1019 S: 1020 S: 1022 The EPP command is used to end a session with an EPP server. 1024 A command MUST be rejected if the command has not been 1025 preceded by a successful command. This action MUST be open 1026 to all authorized clients. 1028 2.9.2. Query Commands 1030 2.9.2.1. EPP Command 1032 The EPP command is used to determine if an object can be 1033 provisioned within a repository. It provides a hint that allows a 1034 client to anticipate the success or failure of provisioning an object 1035 using the command as object provisioning requirements are 1036 ultimately a matter of server policy. 1038 The elements needed to identify an object are object-specific, so the 1039 child elements of the command are specified using the EPP 1040 extension framework. In addition to the standard EPP command 1041 elements, the command contains the following child elements: 1043 - An object-specific element that identify the objects 1044 to be queried. Multiple objects of the same type MAY be queried 1045 within a single command. 1047 Example command: 1049 C: 1050 C: 1051 C: 1052 C: 1053 C: 1054 C: example1 1055 C: example2 1056 C: example3 1057 C: 1058 C: 1059 C: ABC-12346 1060 C: 1061 C: 1063 When a command has been processed successfully, a server MUST 1064 respond with an EPP element that MUST contain a child 1065 element that identifies the object namespace. The child elements of 1066 the element are object-specific, though the EPP 1067 element MUST contain a child element that contains one 1068 or more (check data) elements. Each element 1069 contains the following child elements: 1071 - An object-specific element that identifies the queried object. 1072 This element MUST contain an "avail" attribute whose value 1073 indicates object availability (can it be provisioned or not) at 1074 the moment the command was completed. A value of "1" or 1075 "true" means that the object can be provisioned. A value of "0" 1076 or "false" means that the object can not be provisioned. 1078 - An OPTIONAL element that MAY be provided when an 1079 object can not be provisioned. If present, this element contains 1080 server-specific text to help explain why the object can not be 1081 provisioned. This text MUST be represented in the response 1082 language previously negotiated with the client; an OPTIONAL "lang" 1083 attribute MAY be present to identify the language if the 1084 negotiated value is something other than the default value of "en" 1085 (English). 1087 Example response: 1089 S: 1090 S: 1091 S: 1092 S: 1093 S: Command completed successfully 1094 S: 1095 S: 1096 S: 1097 S: 1098 S: example1 1099 S: 1100 S: 1101 S: example2 1102 S: In use 1103 S: 1104 S: 1105 S: example3 1106 S: 1107 S: 1108 S: 1109 S: 1110 S: ABC-12346 1111 S: 54322-XYZ 1112 S: 1113 S: 1114 S: 1116 The EPP command is used to determine if an object can be 1117 provisioned within a repository. This action MUST be open to all 1118 authorized clients. 1120 2.9.2.2. EPP Command 1122 The EPP command is used to retrieve information associated 1123 with an existing object. The elements needed to identify an object 1124 and the type of information associated with an object are both 1125 object-specific, so the child elements of the command are 1126 specified using the EPP extension framework. In addition to the 1127 standard EPP command elements, the command contains the 1128 following child elements: 1130 - An object-specific element that identifies the object 1131 to be queried. 1133 Example command: 1135 C: 1136 C: 1137 C: 1138 C: 1139 C: 1140 C: 1141 C: 1142 C: 1143 C: ABC-12346 1144 C: 1145 C: 1147 When an command has been processed successfully, a server MUST 1148 respond with an EPP element that MUST contain a child 1149 element that identifies the object namespace and the Repository 1150 Object Identifier (ROID) that was assigned to the object when the 1151 object was created. Other child elements of the element 1152 are object-specific. 1154 Example response: 1156 S: 1157 S: 1158 S: 1159 S: 1160 S: Command completed successfully 1161 S: 1162 S: 1163 S: 1164 S: EXAMPLE1-REP 1165 S: 1166 S: 1167 S: 1168 S: 1169 S: ABC-12346 1170 S: 54322-XYZ 1171 S: 1172 S: 1173 S: 1175 The EPP command is used to retrieve information associated 1176 with an existing object. This action SHOULD be limited to authorized 1177 clients; restricting this action to the sponsoring client is 1178 RECOMMENDED. 1180 2.9.2.3. EPP Command 1182 The EPP command is used to discover and retrieve service 1183 messages queued by a server for individual clients. If the message 1184 queue is not empty, a successful response to a command MUST 1185 return the first message from the message queue. Each response 1186 returned from the server includes a server-unique message identifier 1187 that MUST be provided to acknowledge receipt of the message, and a 1188 counter that indicates the number of messages in the queue. After a 1189 message has been received by the client, the client MUST respond to 1190 the message with an explicit acknowledgement to confirm that the 1191 message has been received. A server MUST dequeue the message and 1192 decrement the queue counter after receiving acknowledgement from the 1193 client, making the next message in the queue (if any) available for 1194 retrieval. 1196 Servers can occasionally perform actions on objects that are not in 1197 direct response to a client request, or an action taken by one client 1198 can indirectly involve a second client. Examples of such actions 1199 include deletion upon expiration, automatic renewal upon expiration, 1200 and transfer coordination; other types of service information MAY be 1201 defined as a matter of server policy. Service messages SHOULD be 1202 created for passive clients affected by an action on an object. 1203 Service messages MAY also be created for active clients that request 1204 an action on an object, though such messages MUST NOT replace the 1205 normal protocol response to the request. For example, 1206 actions SHOULD be reported to the client that has the authority to 1207 approve or reject a transfer request. Other methods of server-client 1208 action notification, such as offline reporting, are also possible and 1209 are beyond the scope of this specification. 1211 Message queues can consume server resources if clients do not 1212 retrieve and acknowledge messages on a regular basis. Servers MAY 1213 implement other mechanisms to dequeue and deliver messages if queue 1214 maintenance needs exceed server resource consumption limits. Server 1215 operators SHOULD consider time-sensitivity and resource management 1216 factors when selecting a delivery method for service information 1217 because some message types can be reasonably delivered using non- 1218 protocol methods that require fewer server resources. 1220 Some of the information returned in response to a command can 1221 be object-specific, so some child elements of the response MAY 1222 be specified using the EPP extension framework. The command 1223 MUST be represented as an empty element with no child elements. An 1224 "op" attribute with value "req" is REQUIRED to retrieve the first 1225 message from the server message queue. An "op" attribute (with value 1226 "ack") and a "msgID" attribute (whose value corresponds to the value 1227 of the "id" attribute copied from the element in the message 1228 being acknowledged) are REQUIRED to acknowledge receipt of a message. 1230 Example command: 1232 C: 1233 C: 1234 C: 1235 C: 1236 C: ABC-12345 1237 C: 1238 C: 1240 The returned result code notes that a message has been dequeued and 1241 returned in response to a command. 1243 Example response with object-specific information: 1245 S: 1246 S: 1247 S: 1248 S: 1249 S: Command completed successfully; ack to dequeue 1250 S: 1251 S: 1252 S: 2000-06-08T22:00:00.0Z 1253 S: Transfer requested. 1254 S: 1255 S: 1256 S: 1258 S: example.com 1259 S: pending 1260 S: ClientX 1261 S: 2000-06-08T22:00:00.0Z 1262 S: ClientY 1263 S: 2000-06-13T22:00:00.0Z 1264 S: 2002-09-08T22:00:00.0Z 1265 S: 1266 S: 1267 S: 1268 S: ABC-12345 1269 S: 54321-XYZ 1270 S: 1271 S: 1272 S: 1274 A client MUST acknowledge each response to dequeue the message and 1275 make subsequent messages available for retrieval. 1277 Example acknowledgement command: 1279 C: 1280 C: 1281 C: 1282 C: 1283 C: ABC-12346 1284 C: 1285 C: 1287 A acknowledgement response notes the ID of the message that 1288 has been acknowledged and the number of messages remaining in the 1289 queue. 1291 Example acknowledgement response: 1293 S: 1294 S: 1295 S: 1296 S: 1297 S: Command completed successfully 1298 S: 1299 S: 1300 S: 1301 S: ABC-12346 1302 S: 54322-XYZ 1303 S: 1304 S: 1305 S: 1307 Service messages can also be returned without object information. 1309 Example response with mixed message content and without 1310 object-specific information: 1312 S: 1313 S: 1314 S: 1315 S: 1316 S: Command completed successfully; ack to dequeue 1317 S: 1318 S: 1319 S: 2000-06-08T22:10:00.0Z 1320 S: Credit balance low. 1321 S: 1005 1322 S: 1323 S: 1324 S: 1325 S: ABC-12346 1326 S: 54321-XYZ 1327 S: 1328 S: 1329 S: 1331 The returned result code and message is used to note an empty server 1332 message queue. 1334 Example response to note an empty message queue: 1336 S: 1337 S: 1338 S: 1339 S: 1340 S: Command completed successfully; no messages 1341 S: 1342 S: 1343 S: ABC-12346 1344 S: 54321-XYZ 1345 S: 1346 S: 1347 S: 1349 The EPP command is used to discover and retrieve client 1350 service messages from a server. This action SHOULD be limited to 1351 authorized clients; queuing service messages and limiting queue 1352 access on a per-client basis is RECOMMENDED. 1354 2.9.2.4. EPP Query Command 1356 The EPP command provides a query operation that allows a 1357 client to determine real-time status of pending and completed 1358 transfer requests. The elements needed to identify an object that is 1359 the subject of a transfer request are object-specific, so the child 1360 elements of the query command are specified using the EPP 1361 extension framework. In addition to the standard EPP command 1362 elements, the command contains an "op" attribute with 1363 value "query", and the following child elements: 1365 - An object-specific element that identifies the 1366 object whose transfer status is requested. 1368 Transfer status is typically considered sensitive information by the 1369 clients involved in the operation. Object mappings MUST provide 1370 features to restrict transfer queries to authorized clients, such as 1371 by requiring authorization information as part of the request. 1373 Example query command: 1375 C: 1376 C: 1377 C: 1378 C: 1379 C: 1380 C: 1381 C: 1382 C: 1383 C: ABC-12346 1384 C: 1385 C: 1387 When a query command has been processed successfully, a 1388 server MUST respond with an EPP element that MUST contain a 1389 child element that identifies the object namespace. The child 1390 elements of the element are object-specific, but they MUST 1391 include elements that identify the object, the status of the 1392 transfer, the identifier of the client that requested the transfer, 1393 the date and time that the request was made, the identifier of the 1394 client that is authorized to act on the request, the date and time by 1395 which an action is expected, and an OPTIONAL date and time noting 1396 changes in the object's validity period (if applicable) that occur as 1397 a result of the transfer. 1399 Example query response: 1401 S: 1402 S: 1403 S: 1404 S: 1405 S: Command completed successfully 1406 S: 1407 S: 1408 S: 1409 S: example 1410 S: pending 1411 S: ClientX 1412 S: 2000-06-08T22:00:00.0Z 1413 S: ClientY 1414 S: 2000-06-13T22:00:00.0Z 1415 S: 2002-09-08T22:00:00.0Z 1416 S: 1417 S: 1418 S: 1419 S: ABC-12346 1420 S: 54322-XYZ 1421 S: 1422 S: 1423 S: 1425 The EPP command provides a query operation that allows a 1426 client to determine real-time status of pending and completed 1427 transfer requests. This action SHOULD be limited to authorized 1428 clients; restricting queries to the requesting and responding clients 1429 is RECOMMENDED. Object transfer MAY be unavailable or limited by 1430 object-specific policies. 1432 2.9.3. Object Transform Commands 1434 EPP provides five commands to transform objects: to create 1435 an instance of an object with a server, to remove an 1436 instance of an object from a server, to extend the validity 1437 period of an object, to change information associated with 1438 an object, and to manage changes in client sponsorship of 1439 an object. 1441 2.9.3.1. EPP Command 1443 The EPP command is used to create an instance of an object. 1444 An object can be created for an indefinite period of time, or an 1445 object can be created for a specific validity period. The EPP 1446 mapping for an object MUST describe the status of an object with 1447 respect to time, to include expected client and server behavior if a 1448 validity period is used. 1450 The elements needed to identify an object and associated attributes 1451 are object-specific, so the child elements of the command 1452 are specified using the EPP extension framework. In addition to the 1453 standard EPP command elements, the command contains the 1454 following child elements: 1456 - An object-specific element that identifies the object 1457 to be created and the elements that are required to create the 1458 object. 1460 Example command: 1462 C: 1463 C: 1464 C: 1465 C: 1466 C: 1467 C: 1468 C: 1469 C: 1470 C: ABC-12345 1471 C: 1472 C: 1474 When a command has been processed successfully, a server MAY 1475 respond with an EPP element that MUST contain a child 1476 element that identifies the object namespace. The child elements of 1477 the element are object-specific. 1479 Example response with : 1481 S: 1482 S: 1483 S: 1484 S: 1485 S: Command completed successfully 1486 S: 1487 S: 1488 S: 1489 S: 1490 S: 1491 S: 1492 S: 1493 S: ABC-12345 1494 S: 54321-XYZ 1495 S: 1496 S: 1497 S: 1499 The EPP command is used to create an instance of an object. 1500 This action SHOULD be limited to authorized clients and MAY be 1501 restricted on a per-client basis. 1503 2.9.3.2. EPP Command 1505 The EPP command is used to remove an instance of an existing 1506 object. The elements needed to identify an object are object- 1507 specific, so the child elements of the command are specified 1508 using the EPP extension framework. In addition to the standard EPP 1509 command elements, the command contains the following child 1510 elements: 1512 - An object-specific element that identifies the object 1513 to be deleted. 1515 Example command: 1517 C: 1518 C: 1519 C: 1520 C: 1521 C: 1522 C: 1523 C: 1524 C: 1525 C: ABC-12346 1526 C: 1527 C: 1529 When a command has been processed successfully, a server MAY 1530 respond with an EPP element that MUST contain a child 1531 element that identifies the object namespace. The child elements of 1532 the element are object-specific. 1534 Example response without : 1536 S: 1537 S: 1538 S: 1539 S: 1540 S: Command completed successfully 1541 S: 1542 S: 1543 S: ABC-12346 1544 S: 54322-XYZ 1545 S: 1546 S: 1547 S: 1549 The EPP command is used to remove an instance of an existing 1550 object. This action SHOULD be limited to authorized clients; 1551 restricting this action to the sponsoring client is RECOMMENDED. 1553 2.9.3.3. EPP Command 1555 The EPP command is used to extend the validity period of an 1556 existing object. The elements needed to identify and extend the 1557 validity period of an object are object-specific, so the child 1558 elements of the command are specified using the EPP extension 1559 framework. In addition to the standard EPP command elements, the 1560 command contains the following child elements: 1562 - An object-specific element that identifies the object 1563 to be renewed and the elements that are required to extend the 1564 validity period of the object. 1566 Example command: 1568 C: 1569 C: 1570 C: 1571 C: 1572 C: 1573 C: 1574 C: 1575 C: 1576 C: ABC-12346 1577 C: 1578 C: 1580 When a command has been processed successfully, a server MAY 1581 respond with an EPP element that MUST contain a child 1582 element that identifies the object namespace. The child elements of 1583 the element are object-specific. 1585 Example response with : 1587 S: 1588 S: 1589 S: 1590 S: 1591 S: Command completed successfully 1592 S: 1593 S: 1594 S: 1595 S: 1596 S: 1597 S: 1598 S: 1599 S: ABC-12346 1600 S: 54322-XYZ 1601 S: 1602 S: 1603 S: 1605 The EPP command is used to extend the validity period of an 1606 existing object. This action SHOULD be limited to authorized 1607 clients; restricting this action to the sponsoring client is 1608 RECOMMENDED. Object renewal MAY be unavailable or limited by object- 1609 specific policies. 1611 2.9.3.4. EPP Command 1613 The EPP command is used to manage changes in client 1614 sponsorship of an existing object. Clients can initiate a transfer 1615 request, cancel a transfer request, approve a transfer request, and 1616 reject a transfer request using the "op" command attribute. 1618 A client who wishes to assume sponsorship of a known object from 1619 another client uses the command with the value of the "op" 1620 attribute set to "request". Once a transfer has been requested, the 1621 same client can cancel the request using a command with 1622 the value of the "op" attribute set to "cancel". A request to cancel 1623 the transfer MUST be sent to the server before the current sponsoring 1624 client either approves or rejects the transfer request and before the 1625 server automatically processes the request due to responding client 1626 inactivity. 1628 Once a transfer request has been received by the server, the server 1629 MUST notify the current sponsoring client of the requested transfer 1630 by either queuing a service message for retrieval via the 1631 command or by using an out-of-band mechanism to inform the client of 1632 the request. The current status of a pending command for 1633 any object can be found using the query command. Transfer 1634 service messages MUST include the object-specific elements specified 1635 for command responses. 1637 The current sponsoring client MAY explicitly approve or reject the 1638 transfer request. The client can approve the request using a 1639 command with the value of the "op" attribute set to 1640 "approve". The client can reject the request using a 1641 command with the value of the "op" attribute set to "reject". 1643 A server MAY automatically approve or reject all transfer requests 1644 that are not explicitly approved or rejected by the current 1645 sponsoring client within a fixed amount of time. The amount of time 1646 to wait for explicit action and the default server behavior are local 1647 matters not specified by EPP, but they SHOULD be documented in a 1648 server-specific profile document that describes default server 1649 behavior for client information. 1651 Objects eligible for transfer MUST have associated authorization 1652 information that MUST be provided to complete a command. 1653 The type of authorization information required is object-specific; 1654 passwords or more complex mechanisms based on public key cryptography 1655 are typical. 1657 The elements needed to identify and complete the transfer of an 1658 object are object-specific, so the child elements of the 1659 command are specified using the EPP extension framework. In addition 1660 to the standard EPP command elements, the command contains 1661 the following child elements: 1663 - An object-specific element that identifies the 1664 object to be transferred and the elements that are required to 1665 process the transfer command. 1667 Example command: 1669 C: 1670 C: 1671 C: 1672 C: 1673 C: 1674 C: 1675 C: 1676 C: 1677 C: ABC-12346 1678 C: 1679 C: 1681 When a command has been processed successfully, a server 1682 MUST respond with an EPP element that MUST contain a child 1683 element that identifies the object namespace. The child elements of 1684 the element are object-specific, but they MUST include 1685 elements that identify the object, the status of the transfer, the 1686 identifier of the client that requested the transfer, the date and 1687 time that the request was made, the identifier of the client that is 1688 authorized to act on the request, the date and time by which an 1689 action is expected, and an OPTIONAL date and time noting changes in 1690 the object's validity period (if applicable) that occur as a result 1691 of the transfer. 1693 Example response with : 1695 S: 1696 S: 1697 S: 1698 S: 1699 S: Command completed successfully; action pending 1700 S: 1701 S: 1702 S: 1703 S: example 1704 S: pending 1705 S: ClientX 1706 S: 2000-06-08T22:00:00.0Z 1707 S: ClientY 1708 S: 2000-06-13T22:00:00.0Z 1709 S: 2002-09-08T22:00:00.0Z 1710 S: 1711 S: 1712 S: 1713 S: ABC-12346 1714 S: 54322-XYZ 1715 S: 1716 S: 1717 S: 1719 The EPP command is used to manage changes in client 1720 sponsorship of an existing object. This action SHOULD be limited to 1721 authorized clients; restricting requests to a client other 1722 than the current sponsoring client, approval requests to 1723 the current sponsoring client, and cancellation requests 1724 to the original requesting client is RECOMMENDED. Object transfer 1725 MAY be unavailable or limited by object-specific policies. 1727 2.9.3.5. EPP Command 1729 The EPP command is used to change information associated 1730 with an existing object. The elements needed to identify and modify 1731 an object are object-specific, so the child elements of the 1732 command are specified using the EPP extension framework. In addition 1733 to the standard EPP command elements, the command contains 1734 the following child elements: 1736 - An object-specific element that identifies the object 1737 to be updated and the elements that are required to modify the 1738 object. Object-specific elements MUST identify values to be 1739 added, values to be removed, or values to be changed. 1741 Example command: 1743 C: 1744 C: 1745 C: 1746 C: 1747 C: 1748 C: 1749 C: 1750 C: 1751 C: ABC-12346 1752 C: 1753 C: 1755 When an command has been processed successfully, a server 1756 MAY respond with an EPP element that MUST contain a child 1757 element that identifies the object namespace. The child elements of 1758 the element are object-specific. 1760 Example response without : 1762 S: 1763 S: 1764 S: 1765 S: 1766 S: Command completed successfully 1767 S: 1768 S: 1769 S: ABC-12346 1770 S: 54322-XYZ 1771 S: 1772 S: 1773 S: 1775 The EPP command is used to change information associated 1776 with an existing object. This action SHOULD be limited to authorized 1777 clients; restricting this action to the sponsoring client is 1778 RECOMMENDED. 1780 3. Result Codes 1782 EPP result codes are based on the theory of reply codes described in 1783 section 4.2.1 of [RFC2821]. EPP uses four decimal digits to describe 1784 the success or failure of each EPP command. Each of the digits of 1785 the reply have special significance. 1787 The first digit denotes command success or failure. The second digit 1788 denotes the response category, such as command syntax or security. 1789 The third and fourth digits provide explicit response detail within 1790 each response category. 1792 There are two values for the first digit of the reply code: 1794 1yzz Positive completion reply. The command has been accepted and 1795 processed by the system without error. 1797 2yzz Negative completion reply. The command was not accepted and 1798 the requested action did not occur. 1800 The second digit groups responses into one of six specific 1801 categories: 1803 x0zz Protocol Syntax 1804 x1zz Implementation-specific Rules 1805 x2zz Security 1806 x3zz Data Management 1807 x4zz Server System 1808 x5zz Connection Management 1810 The third and fourth digits provide response detail within the 1811 categories defined by the first and second digits. Specific result 1812 codes are listed in the table below. 1814 Every EPP response MUST include a result code and a human-readable 1815 description of the result code. The language used to represent the 1816 description MAY be identified using an instance of the "lang" 1817 attribute within the element. If not specified, the default 1818 language is English, identified as "en". A description of the 1819 structure of valid values for the "lang" attribute is described in 1820 [RFC3066]. 1822 Response text MAY be translated into other languages, though the 1823 translation MUST preserve the meaning of the code as described here. 1824 Response code values MUST NOT be changed when translating text. 1826 Response text in the table below is enclosed in quotes to clearly 1827 mark the beginning and ending of each response string. Quotes MUST 1828 NOT be used to delimit these strings when returning response text via 1829 the protocol. 1831 Successful command completion responses: 1833 Code Response text in English 1834 ____ ________________________ 1836 1000 "Command completed successfully" 1837 This is the usual response code for a successfully completed 1838 command that is not addressed by any other 1xxx-series 1839 response code. 1841 1001 "Command completed successfully; action pending" 1842 This response code MUST be returned when responding to a 1843 command the requires offline activity before the requested 1844 action can be completed. See Section 2 for a description of 1845 other processing requirements. 1847 1300 "Command completed successfully; no messages" 1848 This response code MUST be returned when responding to a 1849 request command and the server message queue is empty. 1851 1301 "Command completed successfully; ack to dequeue" 1852 This response code MUST be returned when responding to a 1853 request command and a message has been retrieved from 1854 the server message queue. 1856 1500 "Command completed successfully; ending session" 1857 This response code MUST be returned when responding to a 1858 successful command. 1860 Command error responses: 1862 Code Response text in English 1863 ____ ________________________ 1865 2000 "Unknown command" 1866 This response code MUST be returned when a server receives a 1867 command element that is not defined by EPP. 1869 2001 "Command syntax error" 1870 This response code MUST be returned when a server receives an 1871 improperly formed command element. 1873 2002 "Command use error" 1874 This response code MUST be returned when a server receives a 1875 properly formed command element, but the command can not be 1876 executed due to a sequencing or context error. For example, 1877 a command can not be executed without having first 1878 completed a command. 1880 2003 "Required parameter missing" 1881 This response code MUST be returned when a server receives a 1882 command for which a required parameter value has not been 1883 provided. 1885 2004 "Parameter value range error" 1886 This response code MUST be returned when a server receives a 1887 command parameter whose value is outside the range of values 1888 specified by the protocol. The error value SHOULD be 1889 returned via a element in the EPP response. 1891 2005 "Parameter value syntax error" 1892 This response code MUST be returned when a server receives a 1893 command containing a parameter whose value is improperly 1894 formed. The error value SHOULD be returned via a 1895 element in the EPP response. 1897 2100 "Unimplemented protocol version" 1898 This response code MUST be returned when a server receives a 1899 command element specifying a protocol version that is not 1900 implemented by the server. 1902 2101 "Unimplemented command" 1903 This response code MUST be returned when a server receives a 1904 valid EPP command element that is not implemented by the 1905 server. For example, a command can be 1906 unimplemented for certain object types. 1908 2102 "Unimplemented option" 1909 This response code MUST be returned when a server receives a 1910 valid EPP command element that contains a protocol option 1911 that is not implemented by the server. 1913 2103 "Unimplemented extension" 1914 This response code MUST be returned when a server receives a 1915 valid EPP command element that contains a protocol command 1916 extension that is not implemented by the server. 1918 2104 "Billing failure" 1919 This response code MUST be returned when a server attempts to 1920 execute a billable operation and the command can not be 1921 completed due to a client billing failure. 1923 2105 "Object is not eligible for renewal" 1924 This response code MUST be returned when a client attempts to 1925 an object that is not eligible for renewal in 1926 accordance with server policy. 1928 2106 "Object is not eligible for transfer" 1929 This response code MUST be returned when a client attempts to 1930 an object that is not eligible for transfer in 1931 accordance with server policy. 1933 2200 "Authentication error" 1934 This response code MUST be returned when a server notes an 1935 error when validating client credentials. 1937 2201 "Authorization error" 1938 This response code MUST be returned when a server notes a 1939 client authorization error when executing a command. This 1940 error is used to note that a client lacks privileges to 1941 execute the requested command. 1943 2202 "Invalid authorization information" 1944 This response code MUST be returned when a server receives 1945 invalid command authorization information required to confirm 1946 authorization to execute a command. This error is used to 1947 note that a client has the privileges required to execute the 1948 requested command, but the authorization information provided 1949 by the client does not match the authorization information 1950 archived by the server. 1952 2300 "Object pending transfer" 1953 This response code MUST be returned when a server receives a 1954 command to transfer an object that is pending transfer due to 1955 an earlier transfer request. 1957 2301 "Object not pending transfer" 1958 This response code MUST be returned when a server receives a 1959 command to confirm, reject, or cancel the transfer an object 1960 when no command has been made to transfer the object. 1962 2302 "Object exists" 1963 This response code MUST be returned when a server receives a 1964 command to create an object that already exists in the 1965 repository. 1967 2303 "Object does not exist" 1968 This response code MUST be returned when a server receives a 1969 command to query or transform an object that does not exist 1970 in the repository. 1972 2304 "Object status prohibits operation" 1973 This response code MUST be returned when a server receives a 1974 command to transform an object that can not be completed due 1975 to server policy or business practices. For example, a 1976 server can disallow commands under terms and 1977 conditions that are matters of local policy, or the server 1978 might have received a command for an object whose 1979 status prohibits deletion. 1981 2305 "Object association prohibits operation" 1982 This response code MUST be returned when a server receives a 1983 command to transform an object that can not be completed due 1984 to dependencies on other objects that are associated with the 1985 target object. For example, a server can disallow 1986 commands while an object has active associations with other 1987 objects. 1989 2306 "Parameter value policy error" 1990 This response code MUST be returned when a server receives a 1991 command containing a parameter value that is syntactically 1992 valid, but semantically invalid due to local policy. For 1993 example, the server can support a subset of a range of valid 1994 protocol parameter values. The error value SHOULD be 1995 returned via a element in the EPP response. 1997 2307 "Unimplemented object service" 1998 This response code MUST be returned when a server receives a 1999 command to operate on an object service that is not supported 2000 by the server. 2002 2308 "Data management policy violation" 2003 This response code MUST be returned when a server receives a 2004 command whose execution results in a violation of server data 2005 management policies. For example, removing all attribute 2006 values or object associations from an object might be a 2007 violation of a server's data management policies. 2009 2400 "Command failed" 2010 This response code MUST be returned when a server is unable 2011 to execute a command due to an internal server error that is 2012 not related to the protocol. The failure can be transient. 2013 The server MUST keep any ongoing session active. 2015 2500 "Command failed; server closing connection" 2016 This response code MUST be returned when a server receives a 2017 command that can not be completed due to an internal server 2018 error that is not related to the protocol. The failure is 2019 not transient, and will cause other commands to fail as well. 2020 The server MUST end the active session and close the existing 2021 connection. 2023 2501 "Authentication error; server closing connection" 2024 This response code MUST be returned when a server notes an 2025 error when validating client credentials and a server-defined 2026 limit on the number of allowable failures has been exceeded. 2027 The server MUST close the existing connection. 2029 2502 "Session limit exceeded; server closing connection" 2030 This response code MUST be returned when a server receives a 2031 command, and the command can not be completed because 2032 the client has exceeded a system-defined limit on the number 2033 of sessions that the client can establish. It might be 2034 possible to establish a session by ending existing unused 2035 sessions and closing inactive connections. 2037 4. Formal Syntax 2039 EPP is specified in XML Schema notation. The formal syntax presented 2040 here is a complete schema representation of EPP suitable for 2041 automated validation of EPP XML instances. 2043 Two schemas are presented here. The first schema is the base EPP 2044 schema. The second schema defines elements and structures that can 2045 be used by both the base EPP schema and object mapping schemas. The 2046 BEGIN and END tags are not part of the schema; they are used to note 2047 the beginning and ending of the schema for URI registration purposes. 2049 4.1. Base Schema 2051 BEGIN 2052 2054 2060 2064 2066 2067 2068 Extensible Provisioning Protocol v1.0 schema. 2069 2070 2072 2075 2077 2081 2082 2083 2084 2085 2086 2087 2088 2089 2091 2095 2096 2097 2098 2099 2100 2101 2102 2104 2107 2108 2109 2110 2112 2113 2115 2118 2119 2120 2122 2124 2126 2128 2129 2131 2134 2135 2136 2137 2139 2141 2142 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2155 2156 2157 2158 2159 2161 2162 2164 2165 2166 2168 2170 2172 2174 2175 2177 2178 2179 2181 2183 2185 2187 2189 2190 2192 2193 2194 2196 2197 2199 2200 2201 2202 2203 2204 2206 2207 2208 2209 2210 2211 2212 2213 2214 2216 2217 2218 2219 2220 2221 2223 2226 2227 2228 2230 2231 2233 2234 2235 2237 2238 2240 2243 2244 2245 2246 2247 2248 2250 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2269 2271 2272 2274 2277 2278 2279 2280 2281 2283 2284 2285 2286 2288 2289 2290 2291 2292 2293 2295 2296 2297 2298 2299 2300 2302 2303 2304 2306 2308 2309 2311 2314 2315 2317 2318 2320 2321 2322 2323 2324 2325 2327 2331 2332 2333 2334 2335 2337 2339 2340 2341 2342 2343 2344 2345 2346 2347 2349 2355 2356 2357 2358 2359 2361 2362 2363 2365 2366 2367 2369 2370 2371 2372 2373 2374 2376 2379 2380 2381 2383 2385 2387 2389 2390 2391 2393 2394 2395 2396 2397 2398 2399 2400 2401 2403 2405 2406 2407 2408 2409 2410 2412 2413 2414 2415 2416 2417 2419 2420 2421 2423 2425 2426 2428 2430 2432 2433 2434 2436 2437 2439 2441 2444 2445 2446 2447 2449 2451 2452 2454 2457 2458 2459 2460 2461 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 2496 2499 2500 END 2502 4.2. Shared Structure Schema 2504 BEGIN 2505 2507 2512 2513 2514 Extensible Provisioning Protocol v1.0 2515 shared structures schema. 2516 2517 2519 2522 2523 2524 2525 2526 2527 2528 2530 2531 2532 2533 2534 2536 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2553 2556 2557 2558 2559 2560 2561 2563 2566 2567 2568 2569 2570 2571 2573 2576 2577 2578 2579 2580 2582 2585 2586 2587 2588 2589 2591 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2605 2608 2609 END 2611 5. Internationalization Considerations 2613 EPP is represented in XML, which provides native support for encoding 2614 information using the Unicode character set and its more compact 2615 representations including UTF-8. Conformant XML processors recognize 2616 both UTF-8 and UTF-16. Though XML includes provisions to identify 2617 and use other character encodings through use of an "encoding" 2618 attribute in an declaration, use of UTF-8 is RECOMMENDED in 2619 environments where parser encoding support incompatibility exists. 2621 EPP includes a provision for returning a human-readable message with 2622 every result code. This document describes result codes in English, 2623 but the actual text returned with a result MAY be provided in a 2624 language negotiated when a session is established. Languages other 2625 than English MUST be noted through specification of a "lang" 2626 attribute for each message. Valid values for the "lang" attribute 2627 and "lang" negotiation elements are described in [RFC3066]. 2629 All date-time values presented via EPP MUST be expressed in Universal 2630 Coordinated Time using the Gregorian calendar. XML Schema allows use 2631 of time zone identifiers to indicate offsets from the zero meridian, 2632 but this option MUST NOT be used with EPP. The extended date-time 2633 form using upper case "T" and "Z" characters defined in 2634 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 2635 values as XML Schema does not support truncated date-time forms or 2636 lower case "T" and "Z" characters. 2638 6. IANA Considerations 2640 This document uses URNs to describe XML namespaces and XML schemas 2641 conforming to a registry mechanism described in [RFC3688]. Four URI 2642 assignments have been registered by the IANA. 2644 Registration request for the EPP namespace: 2646 URI: urn:ietf:params:xml:ns:epp-1.0 2648 Registrant Contact: See the "Author's Address" section of this 2649 document. 2651 XML: None. Namespace URIs do not represent an XML specification. 2653 Registration request for the EPP XML schema: 2655 URI: urn:ietf:params:xml:schema:epp-1.0 2657 Registrant Contact: See the "Author's Address" section of this 2658 document. 2660 XML: See the "Base Schema" section of this document. 2662 Registration request for the EPP shared structure namespace: 2664 URI: urn:ietf:params:xml:ns:eppcom-1.0 2666 Registrant Contact: See the "Author's Address" section of this 2667 document. 2669 XML: None. Namespace URIs do not represent an XML specification. 2671 Registration request for the EPP shared structure XML schema: 2673 URI: urn:ietf:params:xml:schema:eppcom-1.0 2675 Registrant Contact: See the "Author's Address" section of this 2676 document. 2678 XML: See the "Shared Structure Schema" section of this document. 2680 7. Security Considerations 2682 EPP provides only simple client authentication services. A passive 2683 attack is sufficient to recover client identifiers and passwords, 2684 allowing trivial command forgery. Protection against most common 2685 attacks and more robust security services MUST be provided by other 2686 protocol layers. Specifically, EPP instances MUST be protected using 2687 a transport mechanism or application protocol that provides 2688 integrity, confidentiality, and mutual strong client-server 2689 authentication. 2691 EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] 2692 to provide a simple application-layer authentication service that 2693 augments or supplements authentication and identification services 2694 that might be available at other protocol layers. Where the PLAIN 2695 SASL mechanism specifies provision of an authorization identifier, 2696 authentication identifier, and password as a single string separated 2697 by ASCII NUL characters, EPP specifies use of a combined 2698 authorization and authentication identifier and a password provided 2699 as distinct XML elements. 2701 Repeated password guessing attempts can be discouraged by limiting 2702 the number of attempts that can be attempted on an open 2703 connection. A server MAY close an open connection if multiple 2704 attempts are made with either an invalid client identifier, 2705 an invalid password, or both an invalid client identifier and an 2706 invalid password. 2708 EPP uses authentication information associated with objects to 2709 confirm object transfer authority. Authentication information 2710 exchanged between EPP clients and third party entities MUST be 2711 exchanged using a facility that provides privacy and integrity 2712 services to protect against unintended disclosure and modification 2713 while in transit. 2715 EPP instances SHOULD be protected using a transport mechanism or 2716 application protocol that provides anti-replay protection. EPP 2717 provides some protection against replay attacks through command 2718 idempotency and client-initiated transaction identification. 2719 Consecutive command replays will not change the state of an object in 2720 any way. There is, however, a chance of unintended or malicious 2721 consequence if a command is replayed after intervening commands have 2722 changed the object state and client identifiers are not used to 2723 detect replays. For example, a replayed command that 2724 follows a command might succeed without additional 2725 facilities to prevent or detect the replay. 2727 8. Acknowledgements 2729 This document was originally written as an individual submission 2730 Internet-Draft. The provreg working group later adopted it as a 2731 working group document and provided many invaluable comments and 2732 suggested improvements. The author wishes to acknowledge the efforts 2733 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 2734 editorial contributions. 2736 Specific suggestions that have been incorporated into this document 2737 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 2738 Roger Castillo Cortazar, Dave Crocker, Ayesha Damaraju, Sheer El- 2739 Showk, Patrik Faltstrom, James Gould, John Immordino, Dan Kohn, Hong 2740 Liu, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, 2741 Andrew Newton, Budi Rahardjo, Asbjorn Steira, Rick Wesson, and Jay 2742 Westerdal. 2744 9. References 2746 9.1. Normative References 2748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2749 Requirement Levels", BCP 14, RFC 2119, March 1997. 2751 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2752 Languages", BCP 18, RFC 2277, January 1998. 2754 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2755 RFC 2914, September 2000. 2757 [RFC3066] Alvestrand, H., "Tags for the Identification of 2758 Languages", RFC 3066, January 2001. 2760 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2761 10646", STD 63, RFC 3629, November 2003. 2763 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2764 January 2004. 2766 [W3C.REC-xml-20040204] 2767 Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., and 2768 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 2769 Edition)", World Wide Web Consortium Recommendation REC- 2770 xml-20040204, February 2004, 2771 . 2773 [W3C.REC-xmlschema-1-20041028] 2774 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn, 2775 "XML Schema Part 1: Structures Second Edition", World Wide 2776 Web Consortium Recommendation REC-xmlschema-1-20041028, 2777 October 2004, 2778 . 2780 [W3C.REC-xmlschema-2-20041028] 2781 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2782 Second Edition", World Wide Web Consortium 2783 Recommendation REC-xmlschema-2-20041028, October 2004, 2784 . 2786 9.2. Informative References 2788 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2789 RFC 793, September 1981. 2791 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 2792 RFC 2595, June 1999. 2794 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 2795 10646", RFC 2781, February 2000. 2797 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2798 April 2001. 2800 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 2801 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 2802 Zhang, L., and V. Paxson, "Stream Control Transmission 2803 Protocol", RFC 2960, October 2000. 2805 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2806 Types", RFC 3023, January 2001. 2808 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 2809 RFC 3080, March 2001. 2811 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol 2812 Requirements", RFC 3375, September 2002. 2814 [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 2815 RFC 3730, March 2004. 2817 [W3C.REC-P3P-20020416] 2818 Marchiori, M., "The Platform for Privacy Preferences 1.0 2819 (P3P1.0) Specification", World Wide Web Consortium 2820 Recommendation REC-P3P-20020416, April 2002, 2821 . 2823 Appendix A. Object Mapping Template 2825 This appendix describes a recommended outline for documenting the EPP 2826 mapping of an object. Documents that describe EPP object mappings 2827 SHOULD describe the mapping in a format similar to the one used here. 2828 Additional sections are required if the object mapping is written in 2829 Internet-Draft or RFC format. 2831 1. Introduction 2833 Provide an introduction that describes the object and an overview 2834 of the mapping to EPP. 2836 2. Object Attributes 2838 Describe the attributes associated with the object, including 2839 references to syntax specifications as appropriate. Examples of 2840 object attributes include a name or identifier and dates 2841 associated with modification events. 2843 3. EPP Command Mapping 2845 3.1. EPP Query Commands 2847 3.1.1. EPP Command 2849 Describe the object-specific mappings required to implement the 2850 EPP command. Include both sample commands and sample 2851 responses. 2853 3.1.2. EPP Command 2855 Describe the object-specific mappings required to implement the 2856 EPP command. Include both sample commands and sample 2857 responses. 2859 3.1.3. EPP Command 2861 Describe the object-specific mappings required to implement the 2862 EPP command. Include both sample commands and sample 2863 responses. 2865 3.1.4. EPP Command 2867 Describe the object-specific mappings required to implement the 2868 EPP query command. Include both sample commands and 2869 sample responses. 2871 3.2. EPP Transform Commands 2873 3.2.1. EPP Command 2875 Describe the object-specific mappings required to implement the 2876 EPP command. Include both sample commands and sample 2877 responses. Describe the status of the object with respect to 2878 time, including expected client and server behavior if a validity 2879 period is used. 2881 3.2.2. EPP Command 2883 Describe the object-specific mappings required to implement the 2884 EPP command. Include both sample commands and sample 2885 responses. 2887 3.2.3. EPP Command 2889 Describe the object-specific mappings required to implement the 2890 EPP command. Include both sample commands and sample 2891 responses. 2893 3.2.4. EPP Command 2895 Describe the object-specific mappings required to implement the 2896 EPP command. Include both sample commands and sample 2897 responses. 2899 3.2.4. EPP Command 2901 Describe the object-specific mappings required to implement the 2902 EPP command. Include both sample commands and sample 2903 responses. 2905 4. Formal Syntax 2907 Provide the XML schema for the object mapping. An XML DTD MUST 2908 NOT be used as DTDs do not provide sufficient support for XML 2909 namespaces and strong data typing. 2911 Appendix B. Media Type Registration: application/epp+xml 2913 MIME media type name: application 2915 MIME subtype name: epp+xml 2917 Mandatory parameters: none 2918 Optional parameters: Same as the charset parameter of application/xml 2919 as specified in [RFC3023]. 2921 Encoding considerations: Same as the encoding considerations of 2922 application/xml as specified in [RFC3023]. 2924 Security considerations: This type has all of the security 2925 considerations described in [RFC3023] plus the considerations 2926 specified in the Security Considerations section of this document. 2928 Interoperability considerations: XML has proven to be interoperable 2929 across WebDAV clients and servers, and for import and export from 2930 multiple XML authoring tools. For maximum interoperability, 2931 validating processors are recommended. Although non-validating 2932 processors can be more efficient, they are not required to handle all 2933 features of XML. For further information, see sub-section 2.9 2934 "Standalone Document Declaration" and section 5 "Conformance" of 2935 [W3C.REC-xml-20040204]. 2937 Published specification: This document. 2939 Applications which use this media type: EPP is device-, platform-, 2940 and vendor-neutral and is supported by multiple service providers. 2942 Additional information: If used, magic numbers, fragment identifiers, 2943 base URIs, and use of the BOM should be as specified in [RFC3023]. 2945 Magic number(s): None. 2947 File extension(s): .xml 2949 Macintosh File Type Code(s): "TEXT" 2951 Person and email address for further information: See the "Author's 2952 Address" section of this document. 2954 Intended usage: COMMON 2956 Author/Change controller: IETF 2958 Appendix C. Changes from RFC 3730 2960 1. Minor reformatting as a result of converting I-D source format 2961 from nroff to XML. 2963 2. Updated the state diagram in Section 2 to note that a 2964 can be received and processed at any time that a server is 2965 waiting for a command. The text correctly describes how this 2966 works, but the state diagram was inconsistent with the text. 2968 3. In Section 2, changed "The specific strings used to associate 2969 URIs and namespaces (such as the string "foo" in "xmlns:foo") in 2970 EPP are illustrative and are not needed for interoperability" to 2971 "The XML namespace prefixes used in examples (such as the string 2972 "foo" in "xmlns:foo") are solely for illustrative purposes. A 2973 conforming implementation MUST NOT require the use of these or 2974 any other specific namespace prefixes". 2976 4. Removed the last paragraph from Section 2 that described an 2977 error in the W3C XML reference specification. This was 2978 corrected in a later edition. References in this specification 2979 have been updated to cite the most current version. Preserved 2980 the last sentence by appending it to the end of the previous 2981 paragraph. 2983 5. Updated the description of the element in Section 2.6 to 2984 add "or other information" to "a client-provided element 2985 (including XML tag and value)". 2987 6. Changed text in Section 2.9.2.3 from this: 2989 "Service messages MUST be created for all clients affected by an 2990 action on an object. For example, actions MUST be 2991 reported to both the client that requests an object transfer and 2992 the client that has the authority to approve or reject the 2993 transfer request." 2995 to this: 2997 "Service messages SHOULD be created for passive clients affected 2998 by an action on an object. Service messages MAY also be created 2999 for active clients that request an action on an object, though 3000 such messages MUST NOT replace the normal protocol response to 3001 the request. For example, actions SHOULD be reported 3002 to the client that has the authority to approve or reject a 3003 transfer request. Other methods of server-client action 3004 notification, such as offline reporting, are also possible and 3005 are beyond the scope of this specification." 3007 7. Changed text in Section 2.9.2.3 from this: 3009 "A acknowledgement response notes the number of messages 3010 remaining in the queue and the ID of the next message available 3011 for retrieval." 3013 to this: 3015 "A acknowledgement response notes the ID of the message 3016 that has been acknowledged and the number of messages remaining 3017 in the queue." 3019 Fixed the example to note the correct message ID. This was done 3020 because the msgID isn't needed to retrieve a message, only to 3021 ack and dequeue it, so it doesn't need to be returned in the 3022 response. Implementations are known to implement this feature 3023 as updated. 3025 8. Changed text in Section 2.9.3.4 from this: 3027 "Once a transfer request has been received by the server, the 3028 server MUST notify the current sponsoring client of the 3029 requested transfer by queuing a service message for retrieval 3030 via the command." 3032 to this: 3034 "Once a transfer request has been received by the server, the 3035 server MUST notify the current sponsoring client of the 3036 requested transfer by either queuing a service message for 3037 retrieval via the command or by using an out-of-band 3038 mechanism to inform the client of the request." 3040 9. Updated Security Considerations to note implemented required 3041 practices for authentication and replay protection. 3043 10. Updated XML references. Updated reference from RFC 2279 to RFC 3044 3629. 3046 11. Removed text describing use of the XML Schema schemaLocation 3047 attribute. This is an optional attribute that doesn't need to 3048 be mandated for use in EPP. 3050 12. Moved RFCs 2781 and 3375 (Informational RFCs) from the normative 3051 reference section to the informative reference section. 3053 13. Moved RFC 3023 from the normative reference section to the 3054 informative reference section. This reference is used only in 3055 an informative appendix. 3057 14. Removed references to RFC 3339 and replaced them with references 3058 to the W3C XML Schema specification. 3060 Author's Address 3062 Scott Hollenbeck 3063 VeriSign, Inc. 3064 21345 Ridgetop Circle 3065 Dulles, VA 20166-6503 3066 US 3068 Email: shollenbeck@verisign.com 3070 Full Copyright Statement 3072 Copyright (C) The IETF Trust (2006). 3074 This document is subject to the rights, licenses and restrictions 3075 contained in BCP 78, and except as set forth therein, the authors 3076 retain all their rights. 3078 This document and the information contained herein are provided on an 3079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3081 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3082 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3083 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3086 Intellectual Property 3088 The IETF takes no position regarding the validity or scope of any 3089 Intellectual Property Rights or other rights that might be claimed to 3090 pertain to the implementation or use of the technology described in 3091 this document or the extent to which any license under such rights 3092 might or might not be available; nor does it represent that it has 3093 made any independent effort to identify any such rights. Information 3094 on the procedures with respect to rights in RFC documents can be 3095 found in BCP 78 and BCP 79. 3097 Copies of IPR disclosures made to the IETF Secretariat and any 3098 assurances of licenses to be made available, or the result of an 3099 attempt made to obtain a general license or permission for the use of 3100 such proprietary rights by implementers or users of this 3101 specification can be obtained from the IETF on-line IPR repository at 3102 http://www.ietf.org/ipr. 3104 The IETF invites any interested party to bring to its attention any 3105 copyrights, patents or patent applications, or other proprietary 3106 rights that may cover technology that may be required to implement 3107 this standard. Please address the information to the IETF at 3108 ietf-ipr@ietf.org. 3110 Acknowledgment 3112 Funding for the RFC Editor function is provided by the IETF 3113 Administrative Support Activity (IASA).