idnits 2.17.1 draft-ietf-enum-validation-epp-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1064. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1070. 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 (Jul 09, 2007) is 6134 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 3761 (ref. '2') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 3730 (ref. '3') (Obsoleted by RFC 4930) ** Obsolete normative reference: RFC 3731 (ref. '4') (Obsoleted by RFC 4931) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-04) exists of draft-ietf-enum-validation-token-03 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM -- Telephone Number Mapping B. Hoeneisen 3 Working Group Switch 4 Internet-Draft Jul 09, 2007 5 Intended status: Standards Track 6 Expires: January 10, 2008 8 ENUM Validation Information Mapping for the Extensible Provisioning 9 Protocol 10 draft-ietf-enum-validation-epp-06 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes an Extensible Provisioning Protocol (EPP) 44 extension framework for mapping information about the validation 45 process that has been applied for the E.164 number (or number range), 46 which the E.164 Number Mapping (ENUM) domain name is based on. 47 Specified in the Extensible Markup Language (XML), this mapping 48 extends the EPP domain name mapping to provide an additional feature 49 required for the provisioning of ENUM domain names. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. ENUM Domain Names . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Validation Information Commands . . . . . . . . . . . . . 5 62 4.3. Id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.4. Validation information . . . . . . . . . . . . . . . . . . 6 64 4.5. Validation Elements in the Example . . . . . . . . . . . . 6 65 4.5.1. Method Identifier . . . . . . . . . . . . . . . . . . 6 66 4.5.2. Validation Entity Identifier . . . . . . . . . . . . . 7 67 4.5.3. Registrar Identifier . . . . . . . . . . . . . . . . . 7 68 4.5.4. Execution Date . . . . . . . . . . . . . . . . . . . . 7 69 4.5.5. Expiration Date . . . . . . . . . . . . . . . . . . . 7 71 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 7 73 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 8 74 5.1.2. EPP Command . . . . . . . . . . . . . . . . . . 8 75 5.1.3. EPP Command . . . . . . . . . . . . . . . . 10 76 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 10 77 5.2.1. EPP Command . . . . . . . . . . . . . . . . . 10 78 5.2.2. EPP Command . . . . . . . . . . . . . . . . . 13 79 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 80 5.2.4. EPP Command . . . . . . . . . . . . . . . . 14 81 5.2.5. EPP Command . . . . . . . . . . . . . . . . . 16 83 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 93 10.2. Non-Normative References . . . . . . . . . . . . . . . . . 25 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 Intellectual Property and Copyright Statements . . . . . . . . . . 26 98 1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [1]. 104 In examples, "C:" represents lines sent by a protocol client and "S:" 105 represents lines returned by a protocol server. Indentation and 106 white space in examples is provided only to illustrate element 107 relationships and is not a REQUIRED feature of this specification. 109 XML is case sensitive. Unless stated otherwise, XML specifications 110 and examples provided in this document MUST be interpreted in the 111 character case presented to develop a conforming implementation. 113 2. Introduction 115 This document describes a framework for an ENUM [2] validation 116 information mapping for version 1.0 of EPP [3]. This mapping, an 117 extension of the EPP domain name mapping described in [4], is 118 specified using XML 1.0 as described in [5] and XML Schema notation 119 as described in [6] and [7]. 121 The EPP core protocol specification [3] provides a complete 122 description of EPP command and response structures. A thorough 123 understanding of the base protocol specification is necessary to 124 understand the mapping described in this document. 126 ENUM [2] describes how the Domain Name System (DNS) can be used to 127 identify services associated with an E.164 number. 129 As described in RFC 4725 [9], usually only the Assignee of the E.164 130 number (or number range) has the right to register the corresponding 131 ENUM domain name. Therefore an ENUM validation process has to be 132 applied before the ENUM domain name can be inserted into the DNS. 133 The validation process shall ensure that the holder of the ENUM 134 domain name coincides with the Assignee of the corresponding E.164 135 number (or number range). However, the details of the ENUM 136 validation methods are beyond the scope of this document. 138 The EPP extension described in this document specifies a framework 139 for the mapping of information about the ENUM validation process. As 140 the local legislation or the validation procedures may vary, the 141 content of the validation information itself is not part of this 142 specification. 144 However, this document contains a working example (including XML 145 schema) to show how the validation information could look like. 146 (This example could even be used for a light-weight validation 147 process. In fact, it has been an integral part of the Swiss ENUM 148 trial.) 150 Using this extension framework, the content of the validation 151 information can be specified according to the local requirements. 152 Such an extension is specified in [10]. 154 More background information concerning the validation can be found in 155 RFC 4725 [9], which also describes a typical basic role model for the 156 ENUM registration process. 158 3. Requirements 160 The following requirements are the basis for this work: 162 1. The design shall allow multiple policies and validation 163 procedures. 165 2. It shall be possible to transmit validation information with EPP 166 domain object requests and responses. 168 3. It shall be possible to add, modify, and remove validation 169 information. 171 4. It shall be possible to retrieve validation information stored at 172 the ENUM Registry. 174 4. Object Attributes 176 This extension adds additional elements to the EPP domain name 177 mapping [4]. Only new element descriptions are listed here. 179 4.1. ENUM Domain Names 181 An ENUM Domain Name is a representation of an E.164 number that has 182 been translated to conform to domain name syntax as described in the 183 ENUM specification [2]. 185 4.2. Validation Information Commands 187 The following commands are defined for handling validation 188 information at the registry: 190 o add: to add new validation information 192 o rem: to revoke validation information 194 o chg: to change stored validation information 196 o inf: to get information about stored validation information 198 4.3. Id 200 The "id" attribute, used to identify the validation, is represented 201 in this mapping using a character string. It MUST be unique at least 202 within the same ENUM Domain Name. To ensure uniqueness even after a 203 transfer of an ENUM Domain Name, it is RECOMMENDED that the "id" 204 attribute is unique per ENUM Registry. 206 The "id" attribute, usually assigned by the ENUM Registrar, is 207 required for revoking or changing stored validation information and 208 appears in the Validation Information Command elements (see above). 210 4.4. Validation information 212 The element can contain any element containing 213 validation information, which is documented adequately. It is 214 represented in this mapping using the XML schema element and 215 therefore it is extensible. 217 How many elements are permitted per domain object is 218 subject to local policy. 220 4.5. Validation Elements in the Example 222 As described above, this document includes an example for a possible 223 content of validation information, which is used in the EPP examples 224 throughout this document. 226 This example is an optional part of this specification, i.e. a fully 227 compliant RFC XXXX [Note for RFC Editor: Please replace XXXX with the 228 RFC number of this document before publication] implementation does 229 not need to implement this example. 231 4.5.1. Method Identifier 233 The element is represented in this mapping using a 234 character string with a maximum length of 63 characters. It contains 235 an identifier for the method used for the validation. 237 As stated above, the details of the ENUM validation methods are 238 beyond the scope of this document. 240 4.5.2. Validation Entity Identifier 242 The element is represented in this mapping using 243 a character string with a length of 3 to 16 characters. It contains 244 an identifier assigned to the ENUM Validation Entity e.g. by the ENUM 245 Registry. 247 4.5.3. Registrar Identifier 249 The element is represented in this mapping using a 250 character string with a length of 3 to 16 characters. It contains an 251 identifier assigned to the ENUM Registrar by the ENUM Registry. 253 4.5.4. Execution Date 255 The element, the execution date of the validation, is 256 represented in this mapping using the XML Schema 'date' data type. 258 4.5.5. Expiration Date 260 The element, the expiration date of the validation, 261 is represented in this mapping using the XML Schema 'date' data type. 263 5. EPP Command Mapping 265 A detailed description of the EPP syntax and semantics can be found 266 in the EPP core protocol specification [3], and the EPP domain name 267 mapping is described in [4]. The command mappings described here are 268 specifically for use in implementing ENUM validation information 269 provisioning processes via EPP. 271 Note: Whether or not this extension is included into an EPP request 272 or response depends on local policy. For example, a local Registry 273 policy might require the use of this extension for EPP , 274 and commands, but not support it for EPP 275 and commands. Therefore this is beyond the scope of this 276 document. 278 5.1. EPP Query Commands 280 EPP provides three commands to retrieve object information: 281 to determine if an object is known to the server, to retrieve 282 detailed information associated with an object, and to 283 retrieve object transfer status information. 285 5.1.1. EPP Command 287 This extension does not add any elements to the EPP command 288 or response described in the EPP domain mapping [4]. 290 5.1.2. EPP Command 292 This extension does not add any elements to the EPP command 293 described in the EPP domain mapping [4]. Additional elements are 294 defined for the response. 296 When an command has been processed successfully, the EPP 297 element MUST contain child elements as described in the EPP 298 domain mapping [4]. In addition, the EPP element MUST 299 contain an element that identifies the extension 300 namespace. The element contains one or more 301 elements each with an "id" attribute identifying the 302 validation. Each element contains an element, which contains the validation information as 304 child element. 306 In the examples below, the validation information consists of an 307 element that identifies the extension namespace. 308 The element contains the following child elements: 310 o An element that contains an identifier of the 311 validation method. 313 o An OPTIONAL element that contains an 314 identifier assigned to the ENUM Validation Entity. 316 o An OPTIONAL element that contains an 317 identifier assigned to the ENUM Registrar by the ENUM Registry. 319 o An element that contains the date, when 320 the validation has been performed. 322 o An OPTIONAL element that contains the 323 date, when the validation expires. 325 Example for response: 327 S: 328 S: 330 S: 331 S: 332 S: Command completed successfully 333 S: 334 S: 335 S: 337 S: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 338 S: EXAMPLE1-REP 339 S: 340 S: jd1234 341 S: sh8013 342 S: sh8013 343 S: 344 S: ns1.example.com 345 S: ns2.example.com 346 S: 347 S: ClientX 348 S: ClientY 349 S: 1999-04-03T22:00:00.0Z 350 S: ClientX 351 S: 1999-12-03T09:00:00.0Z 352 S: 2005-04-03T22:00:00.0Z 353 S: 2000-04-08T09:00:00.0Z 354 S: 355 S: 2fooBAR 356 S: 357 S: 358 S: 359 S: 360 S: 362 S: 363 S: 364 S: 366 S: Validation-X 367 S: VE-NMQ 368 S: Client-X 369 S: 2004-04-08 370 S: 2004-10-07 371 S: 372 S: 373 S: 374 S: 375 S: 376 S: 377 S: ABC-23456 378 S: 54321-XYZ 379 S: 380 S: 381 S: 383 Figure 1 385 5.1.3. EPP Command 387 This extension does not add any elements to the EPP 388 command or response described in the EPP domain mapping 389 [4]. 391 5.2. EPP Transform Commands 393 EPP provides five commands to transform objects: to create 394 an instance of an object, to delete an instance of an 395 object, to extend the validity period of an object, 396 to manage object sponsorship changes, and to 397 change information associated with an object. 399 5.2.1. EPP Command 401 This extension defines additional elements for the EPP 402 command described in the EPP domain mapping [4]. No additional 403 elements are defined for the EPP response. 405 The EPP command provides a transform operation that allows a 406 client to create a domain object. In addition to the EPP command 407 elements described in the EPP domain mapping [4], the command MUST 408 contain an element. The element MUST contain 409 an element that identifies the extension namespace. 410 The element contains one or more 411 elements each with an "id" attribute identifying the validation. 412 Each element contains an 413 element, which contains the validation information as child element. 415 In the examples below, the validation information consists of an 416 element that identifies the extension namespace. 417 The element contains the following child elements: 419 o An element that contains an identifier of the 420 validation method. 422 o An OPTIONAL element that contains an 423 identifier assigned to the ENUM Validation Entity. 425 o An OPTIONAL element that contains an 426 identifier assigned to the ENUM Registrar by the ENUM Registry. 428 o An element that contains the date, when 429 the validation has been performed. 431 o An OPTIONAL element that contains the 432 date, when the validation expires. 434 Example for command: 436 C: 437 C: 439 C: 440 C: 441 C: 443 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 444 C: 1 445 C: 446 C: ns1.example.com 447 C: ns2.example.com 448 C: 449 C: jd1234 450 C: sh8013 451 C: sh8013 452 C: 453 C: 2fooBAR 454 C: 455 C: 456 C: 457 C: 458 C: 460 C: 461 C: 462 C: 464 C: Validation-X 465 C: VE-NMQ 466 C: Client-X 467 C: 2004-04-08 468 C: 2004-10-07 469 C: 470 C: 471 C: 472 C: 473 C: 474 C: ABC-12345 475 C: 476 C: 478 Figure 2 480 When an extended command has been processed successfully, 481 the EPP response is as described in the EPP domain mapping [4]. 483 5.2.2. EPP Command 485 This extension does not add any elements to the EPP command 486 or response described in the EPP domain mapping [4]. 488 5.2.3. EPP Command 490 This extension defines additional elements for the EPP 491 command described in the EPP domain mapping [4]. No additional 492 elements are defined for the EPP response. 494 The EPP command provides a transform operation that allows a 495 client to extend the validity period of a domain object. In addition 496 to the EPP command elements described in the EPP domain mapping [4], 497 the command MUST contain an element. The 498 element MUST contain an element that 499 identifies the extension namespace. The element 500 contains one or more elements each with an "id" 501 attribute identifying the validation. Each element 502 contains an element, which contains the 503 validation information as child element. 505 In the examples below, the validation information consists of an 506 element that identifies the extension namespace. 507 The contains the following child elements: 509 o An element that contains an identifier of the 510 validation method. 512 o An OPTIONAL element that contains an 513 identifier assigned to the ENUM Validation Entity. 515 o An OPTIONAL element that contains an 516 identifier assigned to the ENUM Registrar by the ENUM Registry. 518 o An element that contains the date, when 519 the validation has been performed. 521 o An OPTIONAL element that contains the 522 date, when the validation expires. 524 Example for command: 526 C: 527 C: 529 C: 530 C: 531 C: 533 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 534 C: 2005-04-09 535 C: 1 536 C: 537 C: 538 C: 539 C: 541 C: 542 C: 543 C: 545 C: Validation-X 546 C: VE-NMQ 547 C: Client-X 548 C: 2005-03-30 549 C: 2005-09-29 550 C: 551 C: 552 C: 553 C: 554 C: 555 C: ABC-45678 556 C: 557 C: 559 Figure 3 561 When an extended command has been processed successfully, the 562 EPP response is as described in the EPP domain mapping [4]. 564 5.2.4. EPP Command 566 This extension defines additional elements for the EPP 567 command described in the EPP domain mapping [4]. No additional 568 elements are defined for the EPP response. 570 The EPP command provides a transform operation that allows 571 a client to manage requests to transfer the sponsorship of a domain 572 object. Clients can initiate, cancel, approve, and reject a transfer 573 request. 575 In case of a transfer request, in addition to the EPP command 576 elements described in the EPP domain mapping [4], the command MUST 577 contain an element. The element MUST contain 578 an element that identifies the extension 579 namespace. The element contains one or more 580 elements each with an "id" attribute identifying the 581 validation. Each element contains an element, which contains the validation information as 583 child element. 585 In the examples below, the validation information consists of an 586 element that identifies the extension namespace. 587 The contains the following child elements: 589 o An element that contains an identifier of the 590 validation method. 592 o An OPTIONAL element that contains an 593 identifier assigned to the ENUM Validation Entity. 595 o An OPTIONAL element that contains an 596 identifier assigned to the ENUM Registrar by the ENUM Registry. 598 o An element that contains the date, when 599 the validation has been performed. 601 o An OPTIONAL element that contains the 602 date, when the validation expires. 604 Example for command: 606 C: 607 C: 609 C: 610 C: 611 C: 613 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 614 C: 615 C: 2fooBAR 616 C: 617 C: 618 C: 619 C: 620 C: 622 C: 623 C: 624 C: 626 C: Validation-Y 627 C: VE2-LMQ 628 C: Client-Y 629 C: 2005-01-22 630 C: 2005-07-21 631 C: 632 C: 633 C: 634 C: 635 C: 636 C: XYZ-54789 637 C: 638 C: 640 Figure 4 642 When an extended command has been processed successfully, 643 the EPP response is as described in the EPP domain mapping [4]. 645 5.2.5. EPP Command 647 This extension defines additional elements for the EPP 648 command described in the EPP domain mapping [4]. No additional 649 elements are defined for the EPP response. 651 The EPP command provides a transform operation that allows a 652 client to change the state of a domain object. In addition to the 653 EPP command elements described in the EPP domain mapping [4], the 654 command MUST contain an element. The 655 element MUST contain an element that 656 identifies the extension namespace. The element 657 contains one or more , or 658 elements each with an "id" attribute identifying the validation. 659 Each and element contains an element, which contains the validation information as 661 child element. elements do not have child elements 663 In the examples below, the validation information consists of an 664 element that identifies the extension namespace. 665 The contains the following child elements: 667 o An element that contains an identifier of the 668 validation method. 670 o An OPTIONAL element that contains an 671 identifier assigned to the ENUM Validation Entity. 673 o An OPTIONAL element that contains an 674 identifier assigned to the ENUM Registrar by the ENUM Registry. 676 o An element that contains the date, when 677 the validation has been performed. 679 o An OPTIONAL element that contains the 680 date, when the validation expires. 682 Example for command: 684 C: 685 C: 687 C: 688 C: 689 C: 691 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 692 C: 693 C: 694 C: 695 C: 697 C: 698 C: 699 C: 701 C: Validation-X 702 C: VE-NMQ 703 C: Client-X 704 C: 2004-10-02 705 C: 2005-04-01 706 C: 707 C: 708 C: 709 C: 710 C: 711 C: 712 C: ABC-34567 713 C: 714 C: 716 Figure 5 718 When an extended command has been processed successfully, 719 the EPP response is as described in the EPP domain mapping [4]. 721 6. Formal Syntax 723 An EPP object mapping is specified in XML Schema notation. The 724 formal syntax presented here is a complete schema representation of 725 the object mapping suitable for automated validation of EPP XML 726 instances. The BEGIN and END tags are not part of the schemas; they 727 are used to note the beginning and ending of the schema for URI 728 registration purposes. 730 Formal syntax for Framework: 732 BEGIN 733 734 740 743 746 747 748 Extensible Provisioning Protocol v1.0 749 domain name extension schema for framework for 750 provisioning of E.164 number validation information. 751 752 754 757 758 759 760 762 765 766 767 769 770 772 776 777 778 781 784 787 788 790 793 794 795 796 797 799 801 802 803 804 805 807 809 810 812 814 817 819 822 823 824 827 828 830 833 834 835 836 837 839 841 844 846 849 850 851 852 853 855 858 859 END 861 Figure 6 863 Formal syntax for a simple validation (example): 865 BEGIN 866 867 873 876 879 880 881 Example for E.164 number validation information. 882 883 885 887 888 889 890 892 894 895 897 898 900 901 902 903 904 905 907 910 911 END 912 Figure 7 914 7. IANA Considerations 916 This document uses URNs to describe XML namespaces and XML schemas 917 conforming to the registry mechanism described in RFC 3688 [8]. Four 918 URI assignments are requested: 920 1. Registration request for the extension namespace: 921 * URI: urn:ietf:params:xml:ns:e164val-1.0 922 * Registrant Contact: See the "Author's Address" section of this 923 document. 924 * XML: None. Namespace URIs do not represent an XML 925 specification. 927 2. Registration request for the extension XML schema: 928 * URI: urn:ietf:params:xml:schema:e164val-1.0 929 * Registrant Contact: See the "Author's Address" section of this 930 document. 931 * XML: See the "Formal Syntax" section of this document. 933 3. Registration request for the extension namespace: 934 * URI: urn:ietf:params:xml:ns:e164valex-1.1 935 * Registrant Contact: See the "Author's Address" section of this 936 document. 937 * XML: None. Namespace URIs do not represent an XML 938 specification. 940 4. Registration request for the extension XML schema: 941 * URI: urn:ietf:params:xml:schema:e164valex-1.1 942 * Registrant Contact: See the "Author's Address" section of this 943 document. 944 * XML: See the "Formal Syntax" section of this document. 946 8. Security Considerations 948 The mapping extensions described in this document do not provide any 949 security services beyond those described by EPP [3], the EPP domain 950 name mapping [4], and protocol layers used by EPP. Security 951 considerations related to ENUM are described in the "Security 952 Considerations" section of the ENUM specification [2]. The security 953 considerations described in these other specifications apply to this 954 specification as well. 956 Validation information often contains sensitive personal information. 957 It is RECOMMENDED that validation information in the response 958 is only provided to the sponsoring client. 960 9. Acknowledgements 962 The author would like to thank the following people who have provided 963 feedback or significant contributions to the development of this 964 document: Alfred Hoenes, Helena Malmborg, Alexander Mayrhofer, Andrew 965 Newton, Marcel Parodi, Patrik Schaefer, Patrick Zenklusen 967 RFC 4114 [11] has been used as a template for this document. The 968 structure and those paragraphs, which apply to both documents have 969 been taken over from [11]. The author would like to thank Scott 970 Hollenbeck for this great spadework. 972 10. References 974 10.1. Normative References 976 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 977 Levels", BCP 14, RFC 2119, March 1997. 979 [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 980 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 981 Application (ENUM)", RFC 3761, April 2004. 983 [3] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 984 RFC 3730, March 2004. 986 [4] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain 987 Name Mapping", RFC 3731, March 2004. 989 [5] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen, 990 "Extensible Markup Language (XML) 1.0 (Second Edition)", World 991 Wide Web Consortium FirstEdition REC-xml-20001006, 992 October 2000, . 994 [6] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML 995 Schema Part 1: Structures Second Edition", World Wide Web 996 Consortium Recommendation REC-xmlschema-1-20041028, 997 October 2004, 998 . 1000 [7] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second 1001 Edition", World Wide Web Consortium Recommendation REC- 1002 xmlschema-2-20041028, October 2004, 1003 . 1005 [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1006 January 2004. 1008 10.2. Non-Normative References 1010 [9] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture", 1011 RFC 4725, November 2006. 1013 [10] Lendl, O., "ENUM Validation Token Format Definition", 1014 draft-ietf-enum-validation-token-03 (work in progress), 1015 May 2007. 1017 [11] Hollenbeck, S., "E.164 Number Mapping for the Extensible 1018 Provisioning Protocol (EPP)", RFC 4114, June 2005. 1020 Author's Address 1022 Bernie Hoeneisen 1023 Switch 1024 Werdstrasse 2 1025 CH-8004 Zuerich 1026 Switzerland 1028 Phone: +41 44 268 1515 1029 Email: hoeneisen@switch.ch, b.hoeneisen@ieee.org 1030 URI: http://www.switch.ch/ 1032 Full Copyright Statement 1034 Copyright (C) The IETF Trust (2007). 1036 This document is subject to the rights, licenses and restrictions 1037 contained in BCP 78, and except as set forth therein, the authors 1038 retain all their rights. 1040 This document and the information contained herein are provided on an 1041 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1042 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1043 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1044 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1045 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1046 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1048 Intellectual Property 1050 The IETF takes no position regarding the validity or scope of any 1051 Intellectual Property Rights or other rights that might be claimed to 1052 pertain to the implementation or use of the technology described in 1053 this document or the extent to which any license under such rights 1054 might or might not be available; nor does it represent that it has 1055 made any independent effort to identify any such rights. Information 1056 on the procedures with respect to rights in RFC documents can be 1057 found in BCP 78 and BCP 79. 1059 Copies of IPR disclosures made to the IETF Secretariat and any 1060 assurances of licenses to be made available, or the result of an 1061 attempt made to obtain a general license or permission for the use of 1062 such proprietary rights by implementers or users of this 1063 specification can be obtained from the IETF on-line IPR repository at 1064 http://www.ietf.org/ipr. 1066 The IETF invites any interested party to bring to its attention any 1067 copyrights, patents or patent applications, or other proprietary 1068 rights that may cover technology that may be required to implement 1069 this standard. Please address the information to the IETF at 1070 ietf-ipr@ietf.org. 1072 Acknowledgment 1074 Funding for the RFC Editor function is provided by the IETF 1075 Administrative Support Activity (IASA).