idnits 2.17.1 draft-hoeneisen-enum-validation-epp-01.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1034. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 21, 2005) is 7003 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) == Unused Reference: '1' is defined on line 957, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 960, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. '1') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3730 (ref. '4') (Obsoleted by RFC 4930) ** Obsolete normative reference: RFC 3731 (ref. '5') (Obsoleted by RFC 4931) ** Obsolete normative reference: RFC 3761 (ref. '6') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ENUM -- Telephone Number Mapping B. Hoeneisen 2 Working Group Switch 3 Internet-Draft February 21, 2005 4 Expires: August 22, 2005 6 ENUM Validation Information Mapping for the Extensible Provisioning 7 Protocol 8 draft-hoeneisen-enum-validation-epp-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 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 22 Internet-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 August 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes an EPP extension framework for mapping 44 information about the validation process that has been applied for 45 the E.164 number (or number range), which the ENUM domain name is 46 based on. Specified in XML, this mapping extends the EPP domain name 47 mapping to provide an additional feature required for the 48 provisioning of ENUM domain names. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1 ENUM Domain Names . . . . . . . . . . . . . . . . . . . . 4 60 4.2 Validation Information Commands . . . . . . . . . . . . . 4 61 4.3 Id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.4 Validation information . . . . . . . . . . . . . . . . . . 5 63 4.5 Validation Fields in the Example . . . . . . . . . . . . . 5 64 4.5.1 Method Identifier . . . . . . . . . . . . . . . . . . 5 65 4.5.2 Validation Entity Identifier . . . . . . . . . . . . . 5 66 4.5.3 Registrar Identifier . . . . . . . . . . . . . . . . . 5 67 4.5.4 Execution Date . . . . . . . . . . . . . . . . . . . . 5 68 4.5.5 Expire Date . . . . . . . . . . . . . . . . . . . . . 5 70 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 71 5.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . . 6 72 5.1.1 EPP Command . . . . . . . . . . . . . . . . . 6 73 5.1.2 EPP Command . . . . . . . . . . . . . . . . . . 6 74 5.1.3 EPP Command . . . . . . . . . . . . . . . . 8 75 5.2 EPP Transform Commands . . . . . . . . . . . . . . . . . . 8 76 5.2.1 EPP Command . . . . . . . . . . . . . . . . . 8 77 5.2.2 EPP Command . . . . . . . . . . . . . . . . . 10 78 5.2.3 EPP Command . . . . . . . . . . . . . . . . . 10 79 5.2.4 EPP Command . . . . . . . . . . . . . . . . 12 80 5.2.5 EPP Command . . . . . . . . . . . . . . . . . 14 82 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 92 10.2 Non-Normative References . . . . . . . . . . . . . . . . . . 21 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 96 Intellectual Property and Copyright Statements . . . . . . . . 23 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 [3]. 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 E.164 Number Mapping 116 (ENUM) validation information mapping for version 1.0 of the 117 Extensible Provisioning Protocol (EPP). This mapping, an extension 118 of the domain name mapping described in [5], is specified using the 119 Extensible Markup Language (XML) 1.0 as described in [7] and XML 120 Schema notation as described in [8] and [9]. 122 The EPP core protocol specification [4] provides a complete 123 description of EPP command and response structures. A thorough 124 understanding of the base protocol specification is necessary to 125 understand the mapping described in this document. 127 ENUM [6] describes how the Domain Name System (DNS) can be used to 128 identify services associated with an E.164 number. 130 Usually only the holder of the E.164 number (or number range) has the 131 right to register the corresponding ENUM domain name. Therefore an 132 ENUM validation process has to be applied before the ENUM domain name 133 can be inserted into the DNS. The validation process shall ensure, 134 that the holder of the ENUM domain name coincides with the holder of 135 the corresponding E.164 number (or number range). 137 Several validation methods come into question; e.g. a confirmation 138 of the number assignment entity, which is often the Telephony Service 139 Provider (TSP) of the E.164 number holder. In cases where an E.164 140 number is assigned together with the corresponding ENUM domain name, 141 the validation process is rather simple. However, the details of the 142 ENUM validation methods are beyond the scope of this document. 144 The EPP extension described in this document specifies a framework 145 for the mapping of information about the validation process that has 146 been applied for the E.164 number (or number range) the ENUM domain 147 name is based on. As the local legislation or the validation 148 procedures may vary, the content of validation information itself is 149 not specified in this document. However, it includes a working 150 example (including XML schema) to show how the validation information 151 could look like. Using this extension framework, the content of the 152 validation information can be specified according to the local 153 requirements. Such an extension is specified in [11]. 155 More background information concerning the validation can be found in 156 [11], which also describes a typical basic role model for the ENUM 157 registration process. 159 3. Requirements 161 The following requirements are the basis for this work: 162 1. The design shall allow multiple policies and validation 163 procedures. 164 2. It shall be possible to transmit validation information with EPP 165 domain object requests and responses. 166 3. It shall be possible to add, modify, and remove validation 167 information. 168 4. It shall be possible to retrieve validation information stored at 169 the ENUM Registry. 171 4. Object Attributes 173 This extension adds additional elements to the EPP domain name 174 mapping [5]. Only new element descriptions are listed here. 176 4.1 ENUM Domain Names 178 An ENUM Domain Name is a representation of an E.164 number that has 179 been translated to conform to domain name syntax as described in the 180 ENUM specification [6]. 182 4.2 Validation Information Commands 184 The following commands are defined for handling validation 185 information at the registry: 186 o add: to add new validation information 187 o rem: to revoke validation information 188 o chg: to change stored validation information 189 o inf: to get information about stored validation information 191 4.3 Id 193 The "id" attribute, used to identify the validation, is represented 194 in this mapping using a character string. It MUST be unique at least 195 within the same ENUM Domain Name. The "id" attribute is used to 196 identify a specific validation and appears in the Validation 197 Information Command elements (see above). 199 4.4 Validation information 201 The validationInfo element can contain any element containing 202 validation information, which is documented adequately. It is 203 represented in this mapping using the XML any element and therefore 204 it is extensible. 206 4.5 Validation Fields in the Example 208 As described above, this document includes an example for a possible 209 content of validation information, which is used in the EPP examples 210 throughout this document. 212 4.5.1 Method Identifier 214 The methodID field is represented in this mapping using a character 215 string with a maximum length of 63 characters. It contains an 216 identifier for the method used for the validation. 218 As stated above, the details of the ENUM validation methods are 219 beyond the scope of this document. 221 4.5.2 Validation Entity Identifier 223 The valEntityID field is represented in this mapping using a 224 character string with a length of 3 to 16 characters. It contains an 225 identifier assigned to the Validation Entity e.g. by the Registry. 227 4.5.3 Registrar Identifier 229 The registrarID field is represented in this mapping using a 230 character string with a length of 3 to 16 characters. It contains an 231 identifier assigned to the Registrar by the Registry. 233 4.5.4 Execution Date 235 The execDate field, the execution date of the validation, is 236 represented in this mapping using the XML Schema 'date' data type. 238 4.5.5 Expire Date 240 The expireDate field, the expire date of the validation, is 241 represented in this mapping using the XML Schema 'date' data type. 243 5. EPP Command Mapping 245 A detailed description of the EPP syntax and semantics can be found 246 in the EPP core protocol specification [4], and the EPP domain name 247 mapping is described in [5]. The command mappings described here are 248 specifically for use in implementing ENUM validation information 249 provisioning processes via EPP. 251 5.1 EPP Query Commands 253 EPP provides three commands to retrieve object information: 254 to determine if an object is known to the server, to retrieve 255 detailed information associated with an object, and to 256 retrieve object transfer status information. 258 5.1.1 EPP Command 260 This extension does not add any elements to the EPP command 261 or response described in the EPP domain mapping [5]. 263 5.1.2 EPP Command 265 This extension does not add any elements to the EPP command 266 described in the EPP domain mapping [5]. Additional elements are 267 defined for the response. 269 When an command has been processed successfully, the EPP 270 element MUST contain child elements as described in the EPP 271 domain mapping [5]. In addition, the EPP element MUST 272 contain an element that identifies the extension 273 namespace and the location of the extension schema. The 274 element contains one or more elements 275 each with an "id" attribute identifying the validation. Each 276 element contains an element, 277 which contains the validation information as child element. 279 In the examples below, the validation information consists of an 280 element that identifies the extension namespace 281 and the location of the extension schema. The 282 element contains the following child elements: 283 o An element that contains an identifier of the 284 validation method. 285 o An OPTIONAL element that contains an 286 identifier assigned to the Validation Entity. 287 o An OPTIONAL element that contains an 288 identifier assigned to the Registrar by the Registry. 289 o An element that contains the date, when the 290 validation has been performed. 292 o An OPTIONAL element that contains the date, 293 when the validation expires. 295 Example for response: 297 S: 298 S: 302 S: 303 S: 304 S: Command completed successfully 305 S: 306 S: 307 S: 311 S: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 312 S: EXAMPLE1-REP 313 S: 314 S: jd1234 315 S: sh8013 316 S: sh8013 317 S: 318 S: ns1.example.com 319 S: ns2.example.com 320 S: 321 S: ClientX 322 S: ClientY 323 S: 1999-04-03T22:00:00.0Z 324 S: ClientX 325 S: 1999-12-03T09:00:00.0Z 326 S: 2005-04-03T22:00:00.0Z 327 S: 2000-04-08T09:00:00.0Z 328 S: 329 S: 2fooBAR 330 S: 331 S: 332 S: 333 S: 334 S: 338 S: 339 S: 340 S: 344 S: Validation-X 345 S: VE09-NMQ 346 S: Client-X 347 S: 2004-04-08 348 S: 2004-10-07 349 S: 350 S: 351 S: 352 S: 353 S: 354 S: 355 S: ABC-23456 356 S: 54321-XYZ 357 S: 358 S: 359 S: 361 Figure 1 363 5.1.3 EPP Command 365 This extension does not add any elements to the EPP 366 command or response described in the EPP domain mapping 367 [5]. 369 5.2 EPP Transform Commands 371 EPP provides five commands to transform objects: to create 372 an instance of an object, to delete an instance of an 373 object, to extend the validity period of an object, 374 to manage object sponsorship changes, and to 375 change information associated with an object. 377 5.2.1 EPP Command 379 This extension defines additional elements for the EPP 380 command described in the EPP domain mapping [5]. No additional 381 elements are defined for the EPP response. 383 The EPP command provides a transform operation that allows a 384 client to create a domain object. In addition to the EPP command 385 elements described in the EPP domain mapping [5], the command MUST 386 contain an element. The element MUST contain 387 an element that identifies the extension namespace 388 and the location of the extension schema. The 389 element contains one or more elements each with an "id" 390 attribute identifying the validation. Each element 391 contains an element, which contains the 392 validation information as child element. 394 In the examples below, the validation information consists of an 395 element that identifies the extension namespace 396 and the location of the extension schema. The 397 element contains the following child elements: 398 o An element that contains an identifier of the 399 validation method. 400 o An OPTIONAL element that contains an 401 identifier assigned to the Validation Entity. 402 o An OPTIONAL element that contains an 403 identifier assigned to the Registrar by the Registry. 404 o An element that contains the date, when the 405 validation has been performed. 406 o An OPTIONAL element that contains the date, 407 when the validation expires. 409 Example for command: 411 C: 412 C: 416 C: 417 C: 418 C: 422 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 423 C: 1 424 C: 425 C: ns1.example.com 426 C: ns2.example.com 427 C: 428 C: jd1234 429 C: sh8013 430 C: sh8013 431 C: 432 C: 2fooBAR 433 C: 434 C: 435 C: 436 C: 437 C: 441 C: 442 C: 443 C: 447 C: Validation-X 448 C: VE09-NMQ 449 C: Client-X 450 C: 2004-04-08 451 C: 2004-10-07 452 C: 453 C: 454 C: 455 C: 456 C: 457 C: ABC-12345 458 C: 459 C: 461 Figure 2 463 When an extended command has been processed successfully, 464 the EPP response is as described in the EPP domain mapping [5]. 466 5.2.2 EPP Command 468 This extension does not add any elements to the EPP command 469 or response described in the EPP domain mapping [5]. 471 5.2.3 EPP Command 473 This extension defines additional elements for the EPP 474 command described in the EPP domain mapping [5]. No additional 475 elements are defined for the EPP response. 477 The EPP command provides a transform operation that allows a 478 client to extend the validity period of a domain object. In addition 479 to the EPP command elements described in the EPP domain mapping [5], 480 the command MUST contain an element. The 481 element MUST contain an element that 482 identifies the extension namespace and the location of the extension 483 schema. The element contains one or more 484 elements each with an "id" attribute identifying the 485 validation. Each element contains an 486 element, which contains the validation 487 information as child element. 489 In the examples below, the validation information consists of an 490 element that identifies the extension namespace 491 and the location of the extension schema. The 492 contains the following child elements: 493 o An element that contains an identifier of the 494 validation method. 495 o An OPTIONAL element that contains an 496 identifier assigned to the Validation Entity. 497 o An OPTIONAL element that contains an 498 identifier assigned to the Registrar by the Registry. 499 o An element that contains the date, when the 500 validation has been performed. 501 o An OPTIONAL element that contains the date, 502 when the validation expires. 504 Example for command: 506 C: 507 C: 511 C: 512 C: 513 C: 517 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 518 C: 2005-04-09 519 C: 1 520 C: 521 C: 522 C: 523 C: 527 C: 528 C: 529 C: 533 C: Validation-X 534 C: VE09-NMQ 535 C: Client-X 536 C: 2005-03-30 537 C: 2005-09-29 538 C: 539 C: 540 C: 541 C: 542 C: 543 C: ABC-45678 544 C: 545 C: 547 Figure 3 549 When an extended command has been processed successfully, the 550 EPP response is as described in the EPP domain mapping [5]. 552 5.2.4 EPP Command 554 This extension defines additional elements for the EPP 555 command described in the EPP domain mapping [5]. No additional 556 elements are defined for the EPP response. 558 The EPP command provides a transform operation that allows 559 a client to manage requests to transfer the sponsorship of a domain 560 object. Clients can initiate, cancel, approve, and reject a transfer 561 request. 563 In case of a transfer request, in addition to the EPP command 564 elements described in the EPP domain mapping [5], the command MUST 565 contain an element. The element MUST contain 566 an element that identifies the extension namespace 567 and the location of the extension schema. The 568 element contains one or more elements each with an "id" 569 attribute identifying the validation. Each element 570 contains an element, which contains the 571 validation information as child element. 573 In the examples below, the validation information consists of an 574 element that identifies the extension namespace 575 and the location of the extension schema. The 576 contains the following child elements: 577 o An element that contains an identifier of the 578 validation method. 579 o An OPTIONAL element that contains an 580 identifier assigned to the Validation Entity. 581 o An OPTIONAL element that contains an 582 identifier assigned to the Registrar by the Registry. 583 o An element that contains the date, when the 584 validation has been performed. 585 o An OPTIONAL element that contains the date, 586 when the validation expires. 588 Example for command: 590 C: 591 C: 595 C: 596 C: 597 C: 601 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 602 C: 603 C: 2fooBAR 604 C: 605 C: 606 C: 607 C: 608 C: 612 C: 613 C: 614 C: 618 C: Validation-Y 619 C: VE48-LMQ 620 C: Client-Y 621 C: 2005-01-22 622 C: 2005-07-21 623 C: 624 C: 625 C: 626 C: 627 C: 628 C: XYZ-54789 629 C: 630 C: 632 Figure 4 634 When an extended command has been processed successfully, 635 the EPP response is as described in the EPP domain mapping [5]. 637 5.2.5 EPP Command 639 This extension defines additional elements for the EPP 640 command described in the EPP domain mapping [5]. No additional 641 elements are defined for the EPP response. 643 The EPP command provides a transform operation that allows a 644 client to change the state of a domain object. In addition to the 645 EPP command elements described in the EPP domain mapping [5], the 646 command MUST contain an element. The 647 element MUST contain an element that 648 identifies the extension namespace and the location of the extension 649 schema. The element contains one or more 650 , or elements each with an 651 "id" attribute identifying the validation. Each and 652 element contains an element, 653 which contains the validation information as child element. 654 elements do not have child elements 656 In the examples below, the validation information consists of an 657 element that identifies the extension namespace 658 and the location of the extension schema. The 659 contains the following child elements: 660 o An element that contains an identifier of the 661 validation method. 662 o An OPTIONAL element that contains an 663 identifier assigned to the Validation Entity. 664 o An OPTIONAL element that contains an 665 identifier assigned to the Registrar by the Registry. 666 o An element that contains the date, when the 667 validation has been performed. 669 o An OPTIONAL element that contains the date, 670 when the validation expires. 672 Example for command: 674 C: 675 C: 679 C: 680 C: 681 C: 685 C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa 686 C: 687 C: 688 C: 689 C: 693 C: 694 C: 695 C: 699 C: Validation-X 700 C: VE09-NMQ 701 C: Client-X 702 C: 2004-10-02 703 C: 2005-04-01 704 C: 705 C: 706 C: 707 C: 708 C: 709 C: 710 C: ABC-34567 711 C: 712 C: 714 Figure 5 716 When an extended command has been processed successfully, 717 the EPP response is as described in the EPP domain mapping [5]. 719 6. Formal Syntax 721 An EPP object mapping is specified in XML Schema notation. The 722 formal syntax presented here is a complete schema representation of 723 the object mapping suitable for automated validation of EPP XML 724 instances. The BEGIN and END tags are not part of the schemas; they 725 are used to note the beginning and ending of the schema for URI 726 registration purposes. 728 Formal syntax for Framework: 730 BEGIN 731 732 738 741 744 745 746 Extensible Provisioning Protocol v1.0 747 domain name extension schema for framework for 748 provisioning of E.164 number validation information. 749 750 752 755 756 757 758 760 763 764 765 767 768 770 773 774 775 778 781 784 785 787 790 791 792 793 794 796 798 799 800 801 802 804 806 807 809 811 814 816 819 820 821 824 825 827 830 831 832 833 834 836 838 841 843 846 847 848 849 850 852 855 856 END 857 Figure 6 859 Formal syntax for a simple validation (example): 861 BEGIN 862 863 869 872 875 876 877 Example for E.164 number validation information. 878 879 881 883 884 885 886 888 890 891 893 894 896 897 898 899 900 901 903 906 907 END 909 Figure 7 911 7. IANA Considerations 913 This document uses URNs to describe XML namespaces and XML schemas 914 conforming to a registry mechanism described in RFC 3688 [10]. Two 915 URI assignments are requested. 916 1. Registration request for the extension namespace: 917 * URI: urn:ietf:params:xml:ns:e164val-1.0 918 * Registrant Contact: See the "Author's Address" section of this 919 document. 920 * XML: None. Namespace URIs do not represent an XML 921 specification. 922 2. Registration request for the extension XML schema: 923 * URI: urn:ietf:params:xml:schema:e164val-1.0 924 * Registrant Contact: See the "Author's Address" section of this 925 document. 926 * XML: See the "Formal Syntax" section of this document. 928 8. Security Considerations 930 The mapping extensions described in this document do not provide any 931 security services beyond those described by EPP [4], the EPP domain 932 name mapping [5], and protocol layers used by EPP. Security 933 considerations related to ENUM are described in the "Security 934 Considerations" section of the ENUM specification [6]. The security 935 considerations described in these other specifications apply to this 936 specification as well. 938 Validation information often contains sensitive personal information. 939 It is RECOMMENDED that validation information in the response 940 is only provided to the sponsoring client. 942 9. Acknowledgements 944 [12] has been used as a template for this document. The structure 945 and those paragraphs, which apply to both documents have been taken 946 over from [12]. The author would like to thank Scott Hollenbeck for 947 this great spadework. 949 The author would like to thank the following people who have provided 950 significant contributions to the development of this document: 951 Alexander Mayrhofer, Marcel Parodi, Patrick Zenklusen 953 10. References 955 10.1 Normative References 957 [1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, 958 February 2004. 960 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 961 BCP 79, RFC 3668, February 2004. 963 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 964 Levels", BCP 14, RFC 2119, March 1997. 966 [4] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 967 3730, March 2004. 969 [5] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain 970 Name Mapping", RFC 3731, March 2004. 972 [6] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 973 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 974 Application (ENUM)", RFC 3761, April 2004. 976 [7] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and E. 977 Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", 978 W3C REC REC-xml-20040204, February 2004. 980 [8] Maloney, M., Beech, D., Thompson, H. and N. Mendelsohn, "XML 981 Schema Part 1: Structures Second Edition", W3C REC 982 REC-xmlschema-1-20041028, October 2004. 984 [9] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second 985 Edition", W3C REC REC-xmlschema-2-20041028, October 2004. 987 [10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 988 January 2004. 990 10.2 Non-Normative References 992 [11] Mayrhofer, A., "ENUM Validation Architecture and Token Format 993 Definition", draft-mayrhofer-enum-validation-00 (work in 994 progress), October 2004. 996 [12] Hollenbeck, S., "E.164 Number Mapping for the Extensible 997 Provisioning Protocol", draft-ietf-enum-epp-e164-08 (work in 998 progress), December 2004. 1000 Author's Address 1002 Bernie Hoeneisen 1003 Switch 1004 Neumuehlequai 6 1005 CH-8001 Zuerich 1006 Switzerland 1008 Phone: +41 44 268 1515 1009 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org 1010 URI: http://www.switch.ch/ 1012 Intellectual Property Statement 1014 The IETF takes no position regarding the validity or scope of any 1015 Intellectual Property Rights or other rights that might be claimed to 1016 pertain to the implementation or use of the technology described in 1017 this document or the extent to which any license under such rights 1018 might or might not be available; nor does it represent that it has 1019 made any independent effort to identify any such rights. Information 1020 on the procedures with respect to rights in RFC documents can be 1021 found in BCP 78 and BCP 79. 1023 Copies of IPR disclosures made to the IETF Secretariat and any 1024 assurances of licenses to be made available, or the result of an 1025 attempt made to obtain a general license or permission for the use of 1026 such proprietary rights by implementers or users of this 1027 specification can be obtained from the IETF on-line IPR repository at 1028 http://www.ietf.org/ipr. 1030 The IETF invites any interested party to bring to its attention any 1031 copyrights, patents or patent applications, or other proprietary 1032 rights that may cover technology that may be required to implement 1033 this standard. Please address the information to the IETF at 1034 ietf-ipr@ietf.org. 1036 Disclaimer of Validity 1038 This document and the information contained herein are provided on an 1039 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1040 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1041 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1042 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1043 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1044 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1046 Copyright Statement 1048 Copyright (C) The Internet Society (2005). This document is subject 1049 to the rights, licenses and restrictions contained in BCP 78, and 1050 except as set forth therein, the authors retain all their rights. 1052 Acknowledgment 1054 Funding for the RFC Editor function is currently provided by the 1055 Internet Society.