idnits 2.17.1 draft-hollenbeck-epp-rfc3733bis-06.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 1899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1923. 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 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 (January 9, 2007) is 6316 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.E164.2005' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 3733 (Obsoleted by RFC 4933) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 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: 3733 (if approved) January 9, 2007 5 Intended status: Standards Track 6 Expires: July 13, 2007 8 Extensible Provisioning Protocol (EPP) Contact Mapping 9 draft-hollenbeck-epp-rfc3733bis-06.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 July 13, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes an Extensible Provisioning Protocol (EPP) 43 mapping for the provisioning and management of individual or 44 organizational social information identifiers (known as "contacts") 45 stored in a shared central repository. Specified in Extensible 46 Markup Language (XML), the mapping defines EPP command syntax and 47 semantics as applied to contacts. This document obsoletes RFC 3733 48 if approved. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 54 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Contact and Client Identifiers . . . . . . . . . . . . . . 3 56 2.2. Status Values . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Individual and Organizational Names . . . . . . . . . . . 5 58 2.4. Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4.1. Street, City, and State or Province . . . . . . . . . 6 60 2.4.2. Postal Code . . . . . . . . . . . . . . . . . . . . . 6 61 2.4.3. Country . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.5. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 6 63 2.6. Email Addresses . . . . . . . . . . . . . . . . . . . . . 6 64 2.7. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6 65 2.8. Authorization Information . . . . . . . . . . . . . . . . 7 66 2.9. Disclosure of Data Elements and Attributes . . . . . . . . 7 67 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8 68 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 8 69 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 9 70 3.1.2. EPP Command . . . . . . . . . . . . . . . . . . 10 71 3.1.3. EPP Query Command . . . . . . . . . . . . . 14 72 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 16 73 3.2.1. EPP Command . . . . . . . . . . . . . . . . . 17 74 3.2.2. EPP Command . . . . . . . . . . . . . . . . . 20 75 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 76 3.2.4. EPP Command . . . . . . . . . . . . . . . . 21 77 3.2.5. EPP Command . . . . . . . . . . . . . . . . . 23 78 3.3. Offline Review of Requested Actions . . . . . . . . . . . 27 79 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 80 5. Internationalization Considerations . . . . . . . . . . . . . 38 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 40 87 Appendix A. Changes from RFC 3733 . . . . . . . . . . . . . . . . 41 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 89 Intellectual Property and Copyright Statements . . . . . . . . . . 43 91 1. Introduction 93 This document describes a personal and organizational identifier 94 mapping for version 1.0 of the Extensible Provisioning Protocol 95 (EPP). This mapping is specified using the Extensible Markup 96 Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML 97 Schema notation as described in [W3C.REC-xmlschema-1-20041028] and 98 [W3C.REC-xmlschema-2-20041028]. This document obsoletes RFC 3733 99 [RFC3733] if approved. 101 [I-D.hollenbeck-epp-rfc3730bis] provides a complete description of 102 EPP command and response structures. A thorough understanding of the 103 base protocol specification is necessary to understand the mapping 104 described in this document. 106 XML is case sensitive. Unless stated otherwise, XML specifications 107 and examples provided in this document MUST be interpreted in the 108 character case presented to develop a conforming implementation. 110 1.1. Conventions Used In This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 In examples, "C:" represents lines sent by a protocol client and "S:" 117 represents lines returned by a protocol server. Indentation and 118 white space in examples is provided only to illustrate element 119 relationships and is not a REQUIRED feature of this protocol. 121 2. Object Attributes 123 An EPP contact object has attributes and associated values that can 124 be viewed and modified by the sponsoring client or the server. This 125 section describes each attribute type in detail. The formal syntax 126 for the attribute values described here can be found in the "Formal 127 Syntax" section of this document and in the appropriate normative 128 references. 130 2.1. Contact and Client Identifiers 132 All EPP contacts are identified by a server-unique identifier. 133 Contact identifiers are character strings with a specified minimum 134 length, a specified maximum length, and a specified format. Contact 135 identifiers use the "clIDType" client identifier syntax described in 136 [I-D.hollenbeck-epp-rfc3730bis]. 138 2.2. Status Values 140 A contact object MUST always have at least one associated status 141 value. Status values can be set only by the client that sponsors a 142 contact object and by the server on which the object resides. A 143 client can change the status of a contact object using the EPP 144 command. Each status value MAY be accompanied by a string 145 of human-readable text that describes the rationale for the status 146 applied to the object. 148 A client MUST NOT alter status values set by the server. A server 149 MAY alter or override status values set by a client subject to local 150 server policies. The status of an object MAY change as a result of 151 either a client-initiated transform command or an action performed by 152 a server operator. 154 Status values that can be added or removed by a client are prefixed 155 with "client". Corresponding status values that can be added or 156 removed by a server are prefixed with "server". Status values that 157 do not begin with either "client" or "server" are server-managed. 159 Status Value Descriptions: 161 - clientDeleteProhibited, serverDeleteProhibited 163 Requests to delete the object MUST be rejected. 165 - clientTransferProhibited, serverTransferProhibited 167 Requests to transfer the object MUST be rejected. 169 - clientUpdateProhibited, serverUpdateProhibited 171 Requests to update the object (other than to remove this status) 172 MUST be rejected. 174 - linked 176 The contact object has at least one active association with 177 another object, such as a domain object. Servers SHOULD provide 178 services to determine existing object associations. 180 - ok 182 This is the normal status value for an object that has no pending 183 operations or prohibitions. This value is set and removed by the 184 server as other status values are added or removed. 186 - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, 187 pendingUpdate 189 A transform command has been processed for the object, but the 190 action has not been completed by the server. Server operators can 191 delay action completion for a variety of reasons, such as to allow 192 for human review or third-party action. A transform command that 193 is processed, but whose requested action is pending, is noted with 194 response code 1001. 196 When the requested action has been completed, the pendingCreate, 197 pendingDelete, pendingTransfer, or pendingUpdate status value MUST be 198 removed. All clients involved in the transaction MUST be notified 199 using a service message that the action has been completed and that 200 the status of the object has changed. 202 "ok" status MAY only be combined with "linked" status. 204 "linked" status MAY be combined with any status. 206 "pendingDelete" status MUST NOT be combined with either 207 "clientDeleteProhibited" or "serverDeleteProhibited" status. 209 "pendingTransfer" status MUST NOT be combined with either 210 "clientTransferProhibited" or "serverTransferProhibited" status. 211 "pendingUpdate" status MUST NOT be combined with either 212 "clientUpdateProhibited" or "serverUpdateProhibited" status. 214 The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate 215 status values MUST NOT be combined with each other. 217 Other status combinations not expressly prohibited MAY be used. 219 2.3. Individual and Organizational Names 221 Individual and organizational names associated with a contact are 222 represented using character strings. These strings have a specified 223 minimum length and a specified maximum length. Individual and 224 organizational names MAY be provided in both UTF-8 [RFC3629] and a 225 subset of UTF-8 that can be represented in 7-bit ASCII depending on 226 local needs. 228 2.4. Address 230 Every contact has associated postal address information. A postal 231 address contains OPTIONAL street information, city information, 232 OPTIONAL state/province information, an OPTIONAL postal code, and a 233 country identifier. Address information MAY be provided in both 234 UTF-8 and a subset of UTF-8 that can be represented in 7-bit ASCII 235 depending on local needs. 237 2.4.1. Street, City, and State or Province 239 Contact street, city, and state or province information is 240 represented using character strings. These strings have a specified 241 minimum length and a specified maximum length. 243 2.4.2. Postal Code 245 Contact postal codes are represented using character strings. These 246 strings have a specified minimum length and a specified maximum 247 length. 249 2.4.3. Country 251 Contact country identifiers are represented using two-character 252 identifiers specified in [ISO.3166.1997]. 254 2.5. Telephone Numbers 256 Contact telephone number structure is derived from structures defined 257 in [ITU.E164.2005]. Telephone numbers described in this mapping are 258 character strings that MUST begin with a plus sign ("+", ASCII value 259 0x002B), followed by a country code defined in [ITU.E164.2005], 260 followed by a dot (".", ASCII value 0x002E), followed by a sequence 261 of digits representing the telephone number. An optional "x" 262 attribute is provided to note telephone extension information. 264 2.6. Email Addresses 266 Email address syntax is defined in [RFC0822]. This mapping does not 267 prescribe minimum or maximum lengths for character strings used to 268 represent email addresses. 270 2.7. Dates and Times 272 Date and time attribute values MUST be represented in Universal 273 Coordinated Time (UTC) using the Gregorian calendar. The extended 274 date-time form using upper case "T" and "Z" characters defined in 275 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 276 values as XML Schema does not support truncated date-time forms or 277 lower case "T" and "Z" characters. 279 2.8. Authorization Information 281 Authorization information is associated with contact objects to 282 facilitate transfer operations. Authorization information is 283 assigned when a contact object is created, and it might be updated in 284 the future. This specification describes password-based 285 authorization information, though other mechanisms are possible. 287 2.9. Disclosure of Data Elements and Attributes 289 The EPP core protocol requires a server operator to announce data 290 collection policies to clients; see section 2.4 of 291 [I-D.hollenbeck-epp-rfc3730bis]. In conjunction with this disclosure 292 requirement, this mapping includes data elements that allow a client 293 to identify elements that require exceptional server operator 294 handling to allow or restrict disclosure to third parties. 296 A server operator announces a default disclosure policy when 297 establishing a session with a client. When an object is created or 298 updated, the client can specify contact attributes that require 299 exceptional disclosure handling using an OPTIONAL 300 element. Once set, disclosure preferences can be reviewed using a 301 contact information query. A server operator MUST reject any 302 transaction that requests disclosure practices that do not conform to 303 the announced data collection policy with a 2308 error response code. 305 If present, the element MUST contain a "flag" 306 attribute. The "flag" attribute contains an XML Schema boolean 307 value. A value of "true" or "1" (decimal one) notes a client 308 preference to allow disclosure of the specified elements as an 309 exception to the stated data collection policy. A value of "false" 310 or "0" (decimal zero) notes a client preference to not allow 311 disclosure of the specified elements as an exception to the stated 312 data collection policy. 314 The element MUST contain at least one of the 315 following child elements: 317 318 319 320 321 322 323 324 325 326 Example element, flag="0": 328 329 330 331 333 In this example, the contact email address and voice telephone number 334 can not be disclosed. All other elements are subject to disclosure 335 in accordance with the server's data collection policy. 337 Example element, flag="1": 339 340 341 342 343 345 In this example, the internationalized contact name, organization, 346 and address information can be disclosed. All other elements are 347 subject to disclosure in accordance with the server's data collection 348 policy. 350 Client identification features provided by the EPP command 351 and contact authorization information are used to determine if a 352 client is authorized to perform contact information query commands. 353 These features also determine if a client is authorized to receive 354 data that is otherwise marked for non-disclosure in a query response. 356 3. EPP Command Mapping 358 A detailed description of the EPP syntax and semantics can be found 359 in [I-D.hollenbeck-epp-rfc3730bis]. The command mappings described 360 here are specifically for use in provisioning and managing contact 361 objects via EPP. 363 3.1. EPP Query Commands 365 EPP provides three commands to retrieve contact information: 366 to determine if a contact object can be provisioned within a 367 repository, to retrieve detailed information associated with a 368 contact object, and to retrieve contact object transfer 369 status information. 371 3.1.1. EPP Command 373 The EPP command is used to determine if an object can be 374 provisioned within a repository. It provides a hint that allows a 375 client to anticipate the success or failure of provisioning an object 376 using the command as object provisioning requirements are 377 ultimately a matter of server policy. 379 In addition to the standard EPP command elements, the command 380 MUST contain a element that identifies the contact 381 namespace. The element contains the following child 382 elements: 384 - One or more elements that contain the server-unique 385 identifier of the contact objects to be queried. 387 Example command: 389 C: 390 C: 391 C: 392 C: 393 C: 395 C: sh8013 396 C: sah8013 397 C: 8013sah 398 C: 399 C: 400 C: ABC-12345 401 C: 402 C: 404 When a command has been processed successfully, the EPP 405 element MUST contain a child element that 406 identifies the contact namespace. The element 407 contains one or more elements that contain the following 408 child elements: 410 - A element that identifies the queried object. This 411 element MUST contain an "avail" attribute whose value indicates 412 object availability (can it be provisioned or not) at the moment 413 the command was completed. A value of "1" or "true" means 414 that the object can be provisioned. A value of "0" or "false" 415 means that the object can not be provisioned. 417 - An OPTIONAL element that MAY be provided when an 418 object can not be provisioned. If present, this element contains 419 server-specific text to help explain why the object can not be 420 provisioned. This text MUST be represented in the response 421 language previously negotiated with the client; an OPTIONAL "lang" 422 attribute MAY be present to identify the language if the 423 negotiated value is something other than the default value of "en" 424 (English). 426 Example response: 428 S: 429 S: 430 S: 431 S: 432 S: Command completed successfully 433 S: 434 S: 435 S: 437 S: 438 S: sh8013 439 S: 440 S: 441 S: sah8013 442 S: In use 443 S: 444 S: 445 S: 8013sah 446 S: 447 S: 448 S: 449 S: 450 S: ABC-12345 451 S: 54322-XYZ 452 S: 453 S: 454 S: 456 An EPP error response MUST be returned if a command can not 457 be processed for any reason. 459 3.1.2. EPP Command 461 The EPP command is used to retrieve information associated 462 with a contact object. In addition to the standard EPP command 463 elements, the command MUST contain a element 464 that identifies the contact namespace. The element 465 contains the following child elements: 467 - A element that contains the server-unique identifier 468 of the contact object to be queried. 470 - An OPTIONAL element that contains authorization 471 information associated with the contact object. If this element 472 is not provided or if the authorization information is invalid, 473 server policy determines if the command is rejected or if response 474 information will be returned to the client. 476 Example command: 478 C: 479 C: 480 C: 481 C: 482 C: 484 C: sh8013 485 C: 486 C: 2fooBAR 487 C: 488 C: 489 C: 490 C: ABC-12345 491 C: 492 C: 494 When an command has been processed successfully, the EPP 495 element MUST contain a child element that 496 identifies the contact namespace. The element 497 contains the following child elements: 499 - A element that contains the server-unique identifier 500 of the contact object. 502 - A element that contains the Repository Object 503 IDentifier assigned to the contact object when the object was 504 created. 506 - One or more elements that describe the status of 507 the contact object. 509 - One or two elements that contain postal 510 address information. Two elements are provided so that address 511 information can be provided in both internationalized and 512 localized forms; a "type" attribute is used to identify the two 513 forms. If an internationalized form (type="int") is provided, 514 element content MUST be represented in a subset of UTF-8 that can 515 be represented in the 7-bit US-ASCII character set. If a 516 localized form (type="loc") is provided, element content MAY be 517 represented in unrestricted UTF-8. The 518 element contains the following child elements: 520 - A element that contains the name of the 521 individual or role represented by the contact. 523 - An OPTIONAL element that contains the name of the 524 organization with which the contact is affiliated. 526 - A element that contains address information 527 associated with the contact. A element contains 528 the following child elements: 530 - One, two, or three OPTIONAL elements that 531 contain the contact's street address. 533 - A element that contains the contact's city. 535 - An OPTIONAL element that contains the contact's 536 state or province. 538 - An OPTIONAL element that contains the contact's 539 postal code. 541 - A element that contains the contact's country 542 code. 544 - An OPTIONAL element that contains the contact's 545 voice telephone number. 547 - An OPTIONAL element that contains the contact's 548 facsimile telephone number. 550 - A element that contains the contact's email 551 address. 553 - A element that contains the identifier of the 554 sponsoring client. 556 - A element that contains the identifier of the 557 client that created the contact object. 559 - A element that contains the date and time of 560 contact object creation. 562 - A element that contains the identifier of the 563 client that last updated the contact object. This element MUST 564 NOT be present if the contact has never been modified. 566 - A element that contains the date and time of the 567 most recent contact object modification. This element MUST NOT be 568 present if the contact object has never been modified. 570 - A element that contains the date and time of the 571 most recent successful contact object transfer. This element MUST 572 NOT be provided if the contact object has never been transferred. 574 - A element that contains authorization 575 information associated with the contact object. This element MUST 576 NOT be provided if the querying client is not the current 577 sponsoring client. 579 - An OPTIONAL element that identifies elements 580 that require exceptional server operator handling to allow or 581 restrict disclosure to third parties. See section 2.9. for a 582 description of the child elements contained within the element. 585 Example response for an authorized client: 587 S: 588 S: 589 S: 590 S: 591 S: Command completed successfully 592 S: 593 S: 594 S: 596 S: sh8013 597 S: SH8013-REP 598 S: 599 S: 600 S: 601 S: John Doe 602 S: Example Inc. 603 S: 604 S: 123 Example Dr. 605 S: Suite 100 606 S: Dulles 607 S: VA 608 S: 20166-6503 609 S: US 610 S: 611 S: 612 S: +1.7035555555 613 S: +1.7035555556 614 S: jdoe@example.com 615 S: ClientY 616 S: ClientX 617 S: 1999-04-03T22:00:00.0Z 618 S: ClientX 619 S: 1999-12-03T09:00:00.0Z 620 S: 2000-04-08T09:00:00.0Z 621 S: 622 S: 2fooBAR 623 S: 624 S: 625 S: 626 S: 627 S: 628 S: 629 S: 630 S: 631 S: ABC-12345 632 S: 54322-XYZ 633 S: 634 S: 635 S: 637 An EPP error response MUST be returned if an command can not 638 be processed for any reason. 640 3.1.3. EPP Query Command 642 The EPP command provides a query operation that allows a 643 client to determine real-time status of pending and completed 644 transfer requests. In addition to the standard EPP command elements, 645 the command MUST contain an "op" attribute with value 646 "query", and a element that identifies the contact 647 namespace. The element MUST contain the following 648 child elements: 650 - A element that contains the server-unique identifier 651 of the contact object to be queried. 653 - An OPTIONAL element that contains authorization 654 information associated with the contact object. If this element 655 is not provided or if the authorization information is invalid, 656 server policy determines whether the command is rejected or the 657 response information will be returned to the client. 659 Example query command: 661 C: 662 C: 663 C: 664 C: 665 C: 667 C: sh8013 668 C: 669 C: 2fooBAR 670 C: 671 C: 672 C: 673 C: ABC-12345 674 C: 675 C: 677 When a query command has been processed successfully, the 678 EPP element MUST contain a child element 679 that identifies the contact namespace. The element 680 contains the following child elements: 682 - A element that contains the server-unique identifier 683 for the queried contact. 685 - A element that contains the state of the most 686 recent transfer request. 688 - A element that contains the identifier of the 689 client that requested the object transfer. 691 - A element that contains the date and time that 692 the transfer was requested. 694 - A element that contains the identifier of the 695 client that SHOULD act upon a PENDING transfer request. For all 696 other status types, the value identifies the client that took the 697 indicated action. 699 - A element that contains the date and time of a 700 required or completed response. For a pending request, the value 701 identifies the date and time by which a response is required 702 before an automated response action SHOULD be taken by the server. 703 For all other status types, the value identifies the date and time 704 when the request was completed. 706 Example query response: 708 S: 709 S: 710 S: 711 S: 712 S: Command completed successfully 713 S: 714 S: 715 S: 717 S: sh8013 718 S: pending 719 S: ClientX 720 S: 2000-06-06T22:00:00.0Z 721 S: ClientY 722 S: 2000-06-11T22:00:00.0Z 723 S: 724 S: 725 S: 726 S: ABC-12345 727 S: 54322-XYZ 728 S: 729 S: 730 S: 732 An EPP error response MUST be returned if a query command 733 can not be processed for any reason. 735 3.2. EPP Transform Commands 737 EPP provides four commands to transform contact object information: 738 to create an instance of a contact object, to 739 delete an instance of a contact object, to manage contact 740 object sponsorship changes, and to change information 741 associated with a contact object. This document does not define a 742 mapping for the EPP command. 744 Transform commands are typically processed and completed in real 745 time. Server operators MAY receive and process transform commands, 746 but defer completing the requested action if human or third-party 747 review is required before the requested action can be completed. In 748 such situations the server MUST return a 1001 response code to the 749 client to note that the command has been received and processed, but 750 the requested action is pending. The server MUST also manage the 751 status of the object that is the subject of the command to reflect 752 the initiation and completion of the requested action. Once the 753 action has been completed, all clients involved in the transaction 754 MUST be notified using a service message that the action has been 755 completed and that the status of the object has changed. 757 3.2.1. EPP Command 759 The EPP command provides a transform operation that allows a 760 client to create a contact object. In addition to the standard EPP 761 command elements, the command MUST contain a element that identifies the contact namespace. The element contains the following child elements: 765 - A element that contains the desired server-unique 766 identifier for the contact to be created. 768 - One or two elements that contain postal 769 address information. Two elements are provided so that address 770 information can be provided in both internationalized and 771 localized forms; a "type" attribute is used to identify the two 772 forms. If an internationalized form (type="int") is provided, 773 element content MUST be represented in a subset of UTF-8 that can 774 be represented in the 7-bit US-ASCII character set. If a 775 localized form (type="loc") is provided, element content MAY be 776 represented in unrestricted UTF-8. The 777 element contains the following child elements: 779 - A element that contains the name of the 780 individual or role represented by the contact. 782 - An OPTIONAL element that contains the name of the 783 organization with which the contact is affiliated. 785 - A element that contains address information 786 associated with the contact. A element contains 787 the following child elements: 789 - One, two, or three OPTIONAL elements that 790 contain the contact's street address. 792 - A element that contains the contact's city. 794 - An OPTIONAL element that contains the contact's 795 state or province. 797 - An OPTIONAL element that contains the contact's 798 postal code. 800 - A element that contains the contact's country 801 code. 803 - An OPTIONAL element that contains the contact's 804 voice telephone number. 806 - An OPTIONAL element that contains the contact's 807 facsimile telephone number. 809 - A element that contains the contact's email 810 address. 812 - A element that contains authorization 813 information to be associated with the contact object. This 814 mapping includes a password-based authentication mechanism, but 815 the schema allows new mechanisms to be defined in new schemas. 817 - An OPTIONAL element that allows a client to 818 identify elements that require exceptional server operator 819 handling to allow or restrict disclosure to third parties. See 820 section 2.9 for a description of the child elements contained 821 within the element. 823 Example command: 825 C: 826 C: 827 C: 828 C: 829 C: 831 C: sh8013 832 C: 833 C: John Doe 834 C: Example Inc. 835 C: 836 C: 123 Example Dr. 837 C: Suite 100 838 C: Dulles 839 C: VA 840 C: 20166-6503 841 C: US 842 C: 843 C: 844 C: +1.7035555555 845 C: +1.7035555556 846 C: jdoe@example.com 847 C: 848 C: 2fooBAR 849 C: 850 C: 851 C: 852 C: 853 C: 854 C: 855 C: 856 C: ABC-12345 857 C: 858 C: 860 When a command has been processed successfully, the EPP 861 element MUST contain a child element that 862 identifies the contact namespace. The element 863 contains the following child elements: 865 - A element that contains the server-unique identifier 866 for the created contact. 868 - A element that contains the date and time of 869 contact object creation. 871 Example response: 873 S: 874 S: 875 S: 876 S: 877 S: Command completed successfully 878 S: 879 S: 880 S: 882 S: sh8013 883 S: 1999-04-03T22:00:00.0Z 884 S: 885 S: 886 S: 887 S: ABC-12345 888 S: 54321-XYZ 889 S: 890 S: 891 S: 893 An EPP error response MUST be returned if a command can not 894 be processed for any reason. 896 3.2.2. EPP Command 898 The EPP command provides a transform operation that allows a 899 client to delete a contact object. In addition to the standard EPP 900 command elements, the command MUST contain a element that identifies the contact namespace. The element MUST contain the following child element: 904 - A element that contains the server-unique identifier 905 of the contact object to be deleted. 907 A contact object SHOULD NOT be deleted if it is associated with other 908 known objects. An associated contact SHOULD NOT be deleted until 909 associations with other known objects have been broken. A server 910 SHOULD notify clients of object relationships when a command 911 is attempted and fails due to existing object relationships. 913 Example command: 915 C: 916 C: 917 C: 918 C: 919 C: 921 C: sh8013 922 C: 923 C: 924 C: ABC-12345 925 C: 926 C: 928 When a command has been processed successfully, a server 929 MUST respond with an EPP response with no element. 931 Example response: 933 S: 934 S: 935 S: 936 S: 937 S: Command completed successfully 938 S: 939 S: 940 S: ABC-12345 941 S: 54321-XYZ 942 S: 943 S: 944 S: 946 An EPP error response MUST be returned if a command can not 947 be processed for any reason. 949 3.2.3. EPP Command 951 Renewal semantics do not apply to contact objects, so there is no 952 mapping defined for the EPP command. 954 3.2.4. EPP Command 956 The EPP command provides a transform operation that allows 957 a client to manage requests to transfer the sponsorship of a contact 958 object. In addition to the standard EPP command elements, the 959 command MUST contain a element that 960 identifies the contact namespace. The element 961 contains the following child elements: 963 - A element that contains the server-unique identifier 964 of the contact object for which a transfer request is to be 965 created, approved, rejected, or cancelled. 967 - A element that contains authorization 968 information associated with the contact object. 970 Every EPP command MUST contain an "op" attribute that 971 identifies the transfer operation to be performed as defined in 972 [I-D.hollenbeck-epp-rfc3730bis]. 973 Example request command: 975 C: 976 C: 977 C: 978 C: 979 C: 981 C: sh8013 982 C: 983 C: 2fooBAR 984 C: 985 C: 986 C: 987 C: ABC-12345 988 C: 989 C: 991 When a command has been processed successfully, the EPP 992 element MUST contain a child element that 993 identifies the contact namespace. The element 994 contains the same child elements defined for a transfer query 995 response. 997 Example response: 999 S: 1000 S: 1001 S: 1002 S: 1003 S: Command completed successfully; action pending 1004 S: 1005 S: 1006 S: 1008 S: sh8013 1009 S: pending 1010 S: ClientX 1011 S: 2000-06-08T22:00:00.0Z 1012 S: ClientY 1013 S: 2000-06-13T22:00:00.0Z 1014 S: 1015 S: 1016 S: 1017 S: ABC-12345 1018 S: 54322-XYZ 1019 S: 1020 S: 1021 S: 1023 An EPP error response MUST be returned if a command can 1024 not be processed for any reason. 1026 3.2.5. EPP Command 1028 The EPP command provides a transform operation that allows a 1029 client to modify the attributes of a contact object. In addition to 1030 the standard EPP command elements, the command MUST contain 1031 a element that identifies the contact namespace. 1032 The element contains the following child elements: 1034 - A element that contains the server-unique identifier 1035 of the contact object to be updated. 1037 - An OPTIONAL element that contains attribute values 1038 to be added to the object. 1040 - An OPTIONAL element that contains attribute values 1041 to be removed from the object. 1043 - An OPTIONAL element that contains object attribute 1044 values to be changed. 1046 At least one , , or element 1047 MUST be provided if the command is not being extended. All of these 1048 elements MAY be omitted if an extension is present. The 1049 and elements contain the following child 1050 elements: 1052 - One or more elements that contain status values 1053 to be associated with or removed from the object. When specifying 1054 a value to be removed, only the attribute value is significant; 1055 element text is not required to match a value for removal. 1057 A element contains the following OPTIONAL child 1058 elements. At least one child element MUST be present: 1060 - One or two elements that contain postal 1061 address information. Two elements are provided so that address 1062 information can be provided in both internationalized and 1063 localized forms; a "type" attribute is used to identify the two 1064 forms. If an internationalized form (type="int") is provided, 1065 element content MUST be represented in a subset of UTF-8 that can 1066 be represented in the 7-bit US-ASCII character set. If a 1067 localized form (type="loc") is provided, element content MAY be 1068 represented in unrestricted UTF-8. The 1069 element contains the following OPTIONAL child elements: 1071 - A element that contains the name of the 1072 individual or role represented by the contact. 1074 - A element that contains the name of the 1075 organization with which the contact is affiliated. 1077 - A element that contains address information 1078 associated with the contact. A element contains 1079 the following child elements: 1081 - One, two, or three OPTIONAL elements that 1082 contain the contact's street address. 1084 - A element that contains the contact's city. 1086 - An OPTIONAL element that contains the contact's 1087 state or province. 1089 - An OPTIONAL element that contains the contact's 1090 postal code. 1092 - A element that contains the contact's country 1093 code. 1095 - A element that contains the contact's voice 1096 telephone number. 1098 - A element that contains the contact's facsimile 1099 telephone number. 1101 - A element that contains the contact's email 1102 address. 1104 - A element that contains authorization 1105 information associated with the contact object. This mapping 1106 includes a password-based authentication mechanism, but the schema 1107 allows new mechanisms to be defined in new schemas. 1109 - A element that allows a client to identify 1110 elements that require exceptional server operator handling to 1111 allow or restrict disclosure to third parties. See section 2.9. 1112 for a description of the child elements contained within the 1113 element. 1115 Example command: 1117 C: 1118 C: 1119 C: 1120 C: 1121 C: 1123 C: sh8013 1124 C: 1125 C: 1126 C: 1127 C: 1128 C: 1129 C: 1130 C: 1131 C: 124 Example Dr. 1132 C: Suite 200 1133 C: Dulles 1134 C: VA 1135 C: 20166-6503 1136 C: US 1137 C: 1138 C: 1139 C: +1.7034444444 1140 C: 1141 C: 1142 C: 2fooBAR 1143 C: 1144 C: 1145 C: 1146 C: 1147 C: 1148 C: 1149 C: 1150 C: 1151 C: ABC-12345 1152 C: 1153 C: 1155 When an command has been processed successfully, a server 1156 MUST respond with an EPP response with no element. 1158 Example response: 1160 S: 1161 S: 1162 S: 1163 S: 1164 S: Command completed successfully 1165 S: 1166 S: 1167 S: ABC-12345 1168 S: 54321-XYZ 1169 S: 1170 S: 1171 S: 1173 An EPP error response MUST be returned if an command can not 1174 be processed for any reason. 1176 3.3. Offline Review of Requested Actions 1178 Commands are processed by a server in the order they are received 1179 from a client. Though an immediate response confirming receipt and 1180 processing of the command is produced by the server, a server 1181 operator MAY perform an offline review of requested transform 1182 commands before completing the requested action. In such situations, 1183 the response from the server MUST clearly note that the transform 1184 command has been received and processed, but the requested action is 1185 pending. The status of the corresponding object MUST clearly reflect 1186 processing of the pending action. The server MUST notify the client 1187 when offline processing of the action has been completed. 1189 Examples describing a command that requires offline review 1190 are included here. Note the result code and message returned in 1191 response to the command. 1193 S: 1194 S: 1195 S: 1196 S: 1197 S: Command completed successfully; action pending 1198 S: 1199 S: 1200 S: 1202 S: sh8013 1203 S: 1999-04-03T22:00:00.0Z 1204 S: 1205 S: 1206 S: 1207 S: ABC-12345 1208 S: 54321-XYZ 1209 S: 1210 S: 1211 S: 1213 The status of the contact object after returning this response MUST 1214 include "pendingCreate". The server operator reviews the request 1215 offline, and informs the client of the outcome of the review by 1216 either queuing a service message for retrieval via the command 1217 or by using an out-of-band mechanism to inform the client of the 1218 request. 1220 The service message MUST contain text in the , , 1221 element that describes the notification. In addition, the EPP 1222 element MUST contain a child element that 1223 identifies the contact namespace. The element 1224 contains the following child elements: 1226 - A element that contains the server-unique identifier 1227 of the contact object. The element contains a 1228 REQUIRED "paResult" attribute. A positive boolean value indicates 1229 that the request has been approved and completed. A negative 1230 boolean value indicates that the request has been denied and the 1231 requested action has not been taken. 1233 - A element that contains the client transaction 1234 identifier and server transaction identifier returned with the 1235 original response to process the command. The client transaction 1236 identifier is OPTIONAL and will only be returned if the client 1237 provided an identifier with the original command. 1239 - A element that contains the date and time 1240 describing when review of the requested action was completed. 1242 Example "review completed" service message: 1244 S: 1245 S: 1246 S: 1247 S: 1248 S: Command completed successfully; ack to dequeue 1249 S: 1250 S: 1251 S: 1999-04-04T22:01:00.0Z 1252 S: Pending action completed successfully. 1253 S: 1254 S: 1255 S: 1257 S: sh8013 1258 S: 1259 S: ABC-12345 1260 S: 54321-XYZ 1261 S: 1262 S: 1999-04-04T22:00:00.0Z 1263 S: 1264 S: 1265 S: 1266 S: BCD-23456 1267 S: 65432-WXY 1268 S: 1269 S: 1270 S: 1272 4. Formal Syntax 1274 An EPP object mapping is specified in XML Schema notation. The 1275 formal syntax presented here is a complete schema representation of 1276 the object mapping suitable for automated validation of EPP XML 1277 instances. The BEGIN and END tags are not part of the schema; they 1278 are used to note the beginning and ending of the schema for URI 1279 registration purposes. 1281 BEGIN 1282 1284 1291 1294 1295 1297 1298 1299 Extensible Provisioning Protocol v1.0 1300 contact provisioning schema. 1301 1302 1304 1307 1308 1309 1310 1311 1312 1314 1317 1318 1319 1320 1321 1323 1324 1325 1326 1327 1328 1329 1331 1332 1333 1334 1335 1336 1338 1339 1340 1341 1342 1344 1345 1346 1347 1348 1349 1351 1352 1353 1354 1355 1357 1360 1361 1362 1363 1365 1367 1369 1370 1371 1373 1374 1376 1377 1378 1379 1381 1383 1384 1386 1388 1389 1390 1391 1392 1393 1395 1396 1397 1399 1400 1402 1404 1405 1406 1408 1409 1410 1411 1412 1413 1415 1416 1417 1419 1421 1423 1424 1425 1426 1427 1428 1430 1431 1433 1435 1438 1439 1440 1441 1442 1444 1447 1448 1449 1451 1452 1454 1457 1458 1459 1460 1462 1463 1465 1468 1469 1470 1471 1473 1475 1477 1478 1480 1483 1484 1485 1487 1488 1490 1493 1494 1495 1497 1499 1501 1503 1505 1507 1508 1510 1511 1512 1514 1516 1518 1519 1521 1523 1526 1527 1528 1529 1530 1532 1535 1536 1537 1539 1540 1542 1543 1544 1545 1547 1548 1550 1551 1552 1553 1555 1556 1557 1559 1562 1563 1564 1565 1566 1567 1569 1572 1573 1574 1575 1576 1578 1580 1582 1584 1585 1586 1587 1588 1590 1592 1594 1596 1598 1599 1601 1605 1606 1607 1608 1610 1612 1613 1614 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1633 1636 1637 1638 1639 1640 1641 1642 1644 1645 1646 1647 1649 1650 1651 1653 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1667 1670 1671 END 1673 5. Internationalization Considerations 1675 EPP is represented in XML, which provides native support for encoding 1676 information using the Unicode character set and its more compact 1677 representations, including UTF-8. Conformant XML processors 1678 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 1679 provisions to identify and use other character encodings through use 1680 of an "encoding" attribute in an declaration, use of UTF-8 is 1681 REQUIRED with this specification. 1683 All date-time values presented via EPP MUST be expressed in Universal 1684 Coordinated Time using the Gregorian calendar. The XML Schema allows 1685 use of time zone identifiers to indicate offsets from the zero 1686 meridian, but this option MUST NOT be used with EPP. The extended 1687 date-time form using upper case "T" and "Z" characters defined in 1688 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 1689 values as the XML Schema does not support truncated date-time forms 1690 or lower case "T" and "Z" characters. 1692 Humans, organizations, and other entities often need to represent 1693 social information in both a commonly understood character set and a 1694 locally optimized character set. This specification provides 1695 features allowing representation of social information in both a 1696 subset of UTF-8 for broad readability and unrestricted UTF-8 for 1697 local optimization. 1699 6. IANA Considerations 1701 This document uses URNs to describe XML namespaces and XML schemas 1702 conforming to a registry mechanism described in [RFC3688]. Two URI 1703 assignments have been registered by the IANA. 1705 Registration request for the contact namespace: 1707 URI: urn:ietf:params:xml:ns:contact-1.0 1709 Registrant Contact: See the "Author's Address" section of this 1710 document. 1712 XML: None. Namespace URIs do not represent an XML specification. 1714 Registration request for the contact XML schema: 1716 URI: urn:ietf:params:xml:schema:contact-1.0 1718 Registrant Contact: See the "Author's Address" section of this 1719 document. 1721 XML: See the "Formal Syntax" section of this document. 1723 7. Security Considerations 1725 Authorization information as described in Section 2.8 is REQUIRED to 1726 create a contact object. This information is used in some query and 1727 transfer operations as an additional means of determining client 1728 authorization to perform the command. Failure to protect 1729 authorization information from inadvertent disclosure can result in 1730 unauthorized transfer operations and unauthorized information 1731 release. Both client and server MUST ensure that authorization 1732 information is stored and exchanged with high-grade encryption 1733 mechanisms to provide privacy services. 1735 The object mapping described in this document does not provide any 1736 other security services or introduce any additional considerations 1737 beyond those described by [I-D.hollenbeck-epp-rfc3730bis] and 1738 protocol layers used by EPP. 1740 8. Acknowledgements 1742 This document was originally written as an individual submission 1743 Internet-Draft. The provreg working group later adopted it as a 1744 working group document and provided many invaluable comments and 1745 suggested improvements. The author wishes to acknowledge the efforts 1746 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 1747 editorial contributions. 1749 Specific suggestions that have been incorporated into this document 1750 were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, 1751 Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer 1752 El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael 1753 Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson. 1755 9. References 1757 9.1. Normative References 1759 [I-D.hollenbeck-epp-rfc3730bis] 1760 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1761 draft-hollenbeck-epp-rfc3730bis-04 (work in progress), 1762 November 2006. 1764 [ISO.3166.1997] 1765 International Organization for Standardization, "Codes for 1766 the representation of names of countries and their 1767 subdivisions -- Part 1: Country codes", ISO Standard 3166, 1768 October 1997. 1770 [ITU.E164.2005] 1771 International Telecommunication Union, "The international 1772 public telecommunication numbering plan", ITU- 1773 T Recommendation E.164, February 2005. 1775 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1776 text messages", STD 11, RFC 822, August 1982. 1778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1779 Requirement Levels", BCP 14, RFC 2119, March 1997. 1781 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1782 10646", STD 63, RFC 3629, November 2003. 1784 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1785 January 2004. 1787 [W3C.REC-xml-20040204] 1788 Maler, E., Sperberg-McQueen, C., Bray, T., Yergeau, F., 1789 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third 1790 Edition)", World Wide Web Consortium FirstEdition REC-xml- 1791 20040204, February 2004, 1792 . 1794 [W3C.REC-xmlschema-1-20041028] 1795 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn, 1796 "XML Schema Part 1: Structures Second Edition", World Wide 1797 Web Consortium Recommendation REC-xmlschema-1-20041028, 1798 October 2004, 1799 . 1801 [W3C.REC-xmlschema-2-20041028] 1802 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1803 Second Edition", World Wide Web Consortium 1804 Recommendation REC-xmlschema-2-20041028, October 2004, 1805 . 1807 9.2. Informative References 1809 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1810 10646", RFC 2781, February 2000. 1812 [RFC3733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1813 Contact Mapping", RFC 3733, March 2004. 1815 Appendix A. Changes from RFC 3733 1817 1. Minor reformatting as a result of converting I-D source format 1818 from nroff to XML. 1820 2. Removed this text from Section 2.2: 1822 "With one exception, transform commands MUST be rejected when a 1823 pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate 1824 status is set. The only exception is that a command 1825 to approve, reject, or cancel a transfer MAY be processed while 1826 an object is in "pendingTransfer" status." 1828 3. Fixed examples in section 2.9 (added missing "/" characters). 1830 4. Changed text in Section 3.1.3 from "A element 1831 that contains the identifier of the client that SHOULD act upon 1832 the transfer request" to "A element that contains 1833 the identifier of the client that SHOULD act upon a PENDING 1834 transfer request. For all other status types, the value 1835 identifies the client that took the indicated action". 1837 5. Fixed the example response in Section 3.2.4 to use the correct 1838 response code and response text. 1840 6. Changed text in Section 3.2.5 from "At least one , 1841 , or element MUST be provided." to 1842 "At least one , , or 1843 element MUST be provided if the command is not being extended. 1844 All of these elements MAY be omitted if an extension is 1845 present.". 1847 7. Changed text in Section 3.3 (old Section 3.2.6) from this: 1849 "The server operator reviews the request offline, and informs 1850 the client of the outcome of the review by queuing a service 1851 message for retrieval via the command." 1853 to this: 1855 "The server operator reviews the request offline, and informs 1856 the client of the outcome of the review by either queuing a 1857 service message for retrieval via the command or by using 1858 an out-of-band mechanism to inform the client of the request." 1860 8. Removed text describing use of the XML Schema schemaLocation 1861 attribute. This is an optional attribute that doesn't need to 1862 be mandated for use in EPP. 1864 9. Updated text describing a requirement to use UTF-8 encoding in 1865 the "Internationalization Considerations" section. 1867 10. Removed references to RFC 3339 and replaced them with references 1868 to the W3C XML Schema specification. 1870 11. Updated the E.164 reference. 1872 12. Updated EPP and XML references. Updated reference from RFC 2279 1873 to RFC 3629. 1875 Author's Address 1877 Scott Hollenbeck 1878 VeriSign, Inc. 1879 21345 Ridgetop Circle 1880 Dulles, VA 20166-6503 1881 US 1883 Email: shollenbeck@verisign.com 1885 Full Copyright Statement 1887 Copyright (C) The IETF Trust (2007). 1889 This document is subject to the rights, licenses and restrictions 1890 contained in BCP 78, and except as set forth therein, the authors 1891 retain all their rights. 1893 This document and the information contained herein are provided on an 1894 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1895 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1896 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1897 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1898 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1901 Intellectual Property 1903 The IETF takes no position regarding the validity or scope of any 1904 Intellectual Property Rights or other rights that might be claimed to 1905 pertain to the implementation or use of the technology described in 1906 this document or the extent to which any license under such rights 1907 might or might not be available; nor does it represent that it has 1908 made any independent effort to identify any such rights. Information 1909 on the procedures with respect to rights in RFC documents can be 1910 found in BCP 78 and BCP 79. 1912 Copies of IPR disclosures made to the IETF Secretariat and any 1913 assurances of licenses to be made available, or the result of an 1914 attempt made to obtain a general license or permission for the use of 1915 such proprietary rights by implementers or users of this 1916 specification can be obtained from the IETF on-line IPR repository at 1917 http://www.ietf.org/ipr. 1919 The IETF invites any interested party to bring to its attention any 1920 copyrights, patents or patent applications, or other proprietary 1921 rights that may cover technology that may be required to implement 1922 this standard. Please address the information to the IETF at 1923 ietf-ipr@ietf.org. 1925 Acknowledgment 1927 Funding for the RFC Editor function is provided by the IETF 1928 Administrative Support Activity (IASA).