idnits 2.17.1 draft-hollenbeck-epp-e164-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. 'DDDS-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP-D' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-XML' ** Obsolete normative reference: RFC 2916 (Obsoleted by RFC 3761) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLS-2' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 January 24, 2002 Expires: July 24, 2002 6 Extensible Provisioning Protocol E.164 Number Mapping 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract This document describes an Extensible Provisioning Protocol 30 (EPP) extension mapping for the provisioning and management of E.164 31 numbers representing domain names stored in a shared central 32 repository. Specified in XML, this mapping extends the EPP domain 33 name mapping to provide additional features required for the 34 provisioning of E.164 numbers. 36 Conventions Used In This Document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 In examples, "C:" represents lines sent by a protocol client and "S:" 43 represents lines returned by a protocol server. Indentation and white 44 space in examples is provided only to illustrate element relationships 45 and is not a REQUIRED feature of this protocol. 47 Table of Contents 49 1. Introduction ................................................. 3 50 2. Object Attributes ............................................ 4 51 2.1 E.164 Domain Names .......................................... 4 52 2.2 NAPTR Fields ................................................ 4 53 3. EPP Command Mapping .......................................... 6 54 3.1 EPP Query Commands .......................................... 6 55 3.1.1 EPP Command ....................................... 6 56 3.1.2 EPP Command ........................................ 6 57 3.1.3 EPP Command .................................... 8 58 3.2 EPP Transform Commands ...................................... 8 59 3.2.1 EPP Command ...................................... 8 60 3.2.2 EPP Command ...................................... 10 61 3.2.3 EPP Command ....................................... 10 62 3.2.4 EPP Command .................................... 10 63 3.2.5 EPP Command ...................................... 10 64 4. Formal Syntax ................................................ 12 65 5. Internationalization Considerations .......................... 15 66 6. IANA Considerations .......................................... 15 67 7. Security Considerations ...................................... 16 68 8. Acknowledgements ............................................. 16 69 9. References ................................................... 17 70 10. Author's Address ............................................ 18 71 A. Revisions From Previous Version .............................. 18 72 B. Full Copyright Statement ..................................... 19 74 1. Introduction 76 This document describes an E.164 number mapping for version 1.0 of the 77 Extensible Provisioning Protocol (EPP). This mapping, an extension of 78 the domain name mapping described in [EPP-D], is specified using the 79 Extensible Markup Language (XML) 1.0 as described in [XML] and XML 80 Schema notation as described in [XMLS-1] and [XMLS-2]. 82 [EPP] provides a complete description of EPP command and response 83 structures. A thorough understanding of the base protocol 84 specification is necessary to understand the mapping described in this 85 document. 87 [RFC2916] describes how the Domain Name System (DNS) can be used to 88 identify services associated with an E.164 number. The EPP mapping 89 described in this document specifies a mechanism for the provisioning 90 and management of E.164 numbers stored in a shared central repository. 91 Information exchanged via this mapping can be extracted from the 92 repository and used to publish DNS resource records as described in 93 [RFC2916]. Examples used in this document were chosen specifically to 94 illustrate provisioning concepts for the example resource records 95 described in [RFC2916]. 97 XML is case sensitive. Unless stated otherwise, XML specifications 98 and examples provided in this document MUST be interpreted in the 99 character case presented to develop a conforming implementation. 101 2. Object Attributes 103 This extension adds additional elements to the domain name mapping 104 described in [EPP-D]. Only new element descriptions are described 105 here. 107 2.1 E.164 Domain Names 109 An E.164 domain name is a representation of an E.164 number that has 110 been translated to conform to domain name syntax as described in 111 [RFC2916]. The labels used to describe the name space of an E.164 112 domain name are a policy matter that is beyond the scope of this 113 document. 115 2.2 NAPTR Fields 117 According to [RFC2916], Naming Authority Pointer (NAPTR) resource 118 records are used to identify available ways of contacting a specific 119 node identified by a domain name created from the translation of an 120 E.164 number. The format and processing rules for NAPTR records are 121 described in [DDDS-3]. 123 2.2.1 Order 125 The NAPTR order field, a 16-bit unsigned integer, is represented in 126 this mapping using the XML Schema "unsignedShort" data type. 128 2.2.2 Preference 130 The NAPTR preference field, a 16-bit unsigned integer, is represented 131 in this mapping using the XML Schema "unsignedShort" data type. 133 2.2.3 Flags 135 The NAPTR flags field is represented in this mapping using a single 136 character. The case of the flag character is not significant. 138 2.2.4 Service 140 The NAPTR service field is represented in this mapping using a 141 character string with a maximum length of 65 characters. 143 2.2.5 Regular Expression 145 The NAPTR regexp field is represented in this mapping using a 146 character string with an unspecified maximum length. This field can 147 contain numerous backslashes and should thus be treated with care. 149 2.2.6 Replacement 151 The NAPTR replacement field is represented in this mapping using a 152 character string with a maximum length of 255 characters. 154 3. EPP Command Mapping 156 A detailed description of the EPP syntax and semantics can be found in 157 [EPP]. The command mappings described here are specifically for use 158 in provisioning and managing E.164 numbers via EPP. 160 3.1 EPP Query Commands 162 EPP provides three commands to retrieve object information: to 163 determine if an object is known to the server, to retrieve 164 detailed information associated with an object, and to 165 retrieve object transfer status information. 167 3.1.1 EPP Command 169 This extension does not add any elements to the EPP command or 170 response described in [EPP-D]. 172 3.1.2 EPP Command 174 This extension does not add any elements to the EPP command 175 described in [EPP-D]. Additional elements are defined for the 176 response. 178 When an command has been processed successfully, the EPP 179 element MUST contain child elements as described in [EPP-D]. 180 In addition, the EPP element MUST contain a child 181 element that identifies the e164 namespace and the 182 location of the e164 schema. The element contains one 183 or more elements that contain the following child 184 elements: 186 - An element that contains a NAPTR order value. 188 - An element that contains a NAPTR preference value. 190 - An OPTIONAL element that contains a NAPTR flags value. 192 - An OPTIONAL element that contains a NAPTR service value. 194 - An OPTIONAL element that contains a NAPTR regular 195 expression value. 197 - An OPTIONAL element that contains a NAPTR 198 replacement value. 200 Example response: 202 S: 203 S: 207 S: 208 S: 209 S: Command completed successfully 210 S: 211 S: 212 S: 216 S: 4.3.2.1.6.7.9.8.6.4.e164.arpa 217 S: EXAMPLE1-REP 218 S: 219 S: jd1234 220 S: sh8013 221 S: sh8013 222 S: ns1.example.tld 223 S: ns2.example.tld 224 S: ns1.example.tld 225 S: ns2.example.tld 226 S: ClientX 227 S: ClientY 228 S: 1999-04-03T22:00:00.0Z 229 S: ClientX 230 S: 1999-12-03T09:00:00.0Z 231 S: 2005-04-03T22:00:00.0Z 232 S: 2000-04-08T09:00:00.0Z 233 S: 2fooBAR 234 S: 235 S: 236 S: 237 S: 240 S: 241 S: 100 242 S: 10 243 S: u 244 S: sip+E2U 245 S: !^.*$!sip:info@tele2.se! 246 S: 247 S: 248 S: 102 249 S: 10 250 S: u 251 S: mailto+E2U 252 S: !^.*$!mailto:info@tele2.se! 253 S: 254 S: 255 S: 256 S: 257 S: ABC-12345 258 S: 54322-XYZ 259 S: 260 S: 261 S: 263 An EPP error response MUST be returned if an command can not be 264 processed for any reason. 266 3.1.3 EPP Command 268 This extension does not add any elements to the EPP command 269 or response described in [EPP-D]. 271 3.2 EPP Transform Commands 273 EPP provides five commands to transform objects: to create an 274 instance of an object, to delete an instance of an object, 275 to extend the validity period of an object, to 276 manage object sponsorship changes, and to change information 277 associated with an object. 279 3.2.1 EPP Command 281 This extension defines additional elements for the EPP 282 command described in [EPP-D]. No additional elements are defined for 283 the EPP response. 285 The EPP command provides a transform operation that allows a 286 client to create a domain object. In addition to the EPP command 287 elements described in [EPP-D], the command MUST contain an 288 element. The element MUST contain a child 289 element that identifies the e164 namespace and the location of the 290 e164 schema. The element contains one or more 291 elements that contain the following child elements: 293 - An element that contains a NAPTR order value. 295 - An element that contains a NAPTR preference value. 297 - An OPTIONAL element that contains a NAPTR flags value. 299 - An OPTIONAL element that contains a NAPTR service value. 301 - An OPTIONAL element that contains a NAPTR regular 302 expression value. 304 - An OPTIONAL element that contains a NAPTR 305 replacement value. 307 Example command: 309 C: 310 C: 314 C: 315 C: 316 C: 320 C: 4.3.2.1.6.7.9.8.6.4.e164.arpa 321 C: 2 322 C: ns1.example.tld 323 C: ns2.example.tld 324 C: jd1234 325 C: sh8013 326 C: sh8013 327 C: 2fooBAR 328 C: 329 C: 330 C: 331 C: 335 C: 336 C: 100 337 C: 10 338 C: u 339 C: sip+E2U 340 C: !^.*$!sip:info@tele2.se! 341 C: 342 C: 343 C: 102 344 C: 10 345 C: u 346 C: mailto+E2U 347 C: !^.*$!mailto:info@tele2.se! 348 C: 349 C: 350 C: 351 C: ABC-12345 352 C: 353 C: 355 When a command has been processed successfully, the EPP 356 response is as described in [EPP-D]. 358 3.2.2 EPP Command 360 This extension does not add any elements to the EPP command 361 or response described in [EPP-D]. 363 3.2.3 EPP Command 365 This extension does not add any elements to the EPP command or 366 response described in [EPP-D]. 368 3.2.4 EPP Command 370 This extension does not add any elements to the EPP command 371 or response described in [EPP-D]. 373 3.2.5 EPP Command 375 This extension defines additional elements for the EPP 376 command described in [EPP-D]. No additional elements are defined for 377 the EPP response. 379 The EPP command provides a transform operation that allows a 380 client to modify the attributes of a domain object. In addition to 381 the EPP command elements descried in [EPP-D], the command MUST contain 382 an element. The element MUST contain a child 383 element that identifies the e164 namespace and the 384 location of the e164 schema. The element contains one 385 or more or elements. Each and 386 element contains an element that contains the 387 following child elements: 389 - An element that contains a NAPTR order value. 391 - An element that contains a NAPTR preference value. 393 - An OPTIONAL element that contains a NAPTR flags value. 395 - An OPTIONAL element that contains a NAPTR service value. 397 - An OPTIONAL element that contains a NAPTR regular 398 expression value. 400 - An OPTIONAL element that contains a NAPTR 401 replacement value. 403 Example command: 405 C: 406 C: 410 C: 411 C: 412 C: 416 C: 4.3.2.1.6.7.9.8.6.4.e164.arpa 417 C: 418 C: 419 C: 420 C: 423 C: 424 C: 425 C: 102 426 C: 10 427 C: u 428 C: mailto+E2U 429 C: !^.*$!mailto:info@tele2.se! 430 C: 431 C: 432 C: 433 C: 434 C: ABC-12345 435 C: 436 C: 438 When an command has been processed successfully, the EPP 439 response is as described in [EPP-D]. 441 4. Formal Syntax 443 An EPP object mapping is specified in XML Schema notation. The formal 444 syntax presented here is a complete schema representation of the 445 object mapping suitable for automated validation of EPP XML instances. 446 The BEGIN and END tags are not part of the schema; they are used to 447 note the beginning and ending of the schema for URI registration 448 purposes. 450 BEGIN 451 453 458 459 460 Extensible Provisioning Protocol v1.0 461 domain name extension schema for E.164 number provisioning. 462 463 465 468 469 471 474 476 479 480 481 482 483 485 486 487 488 489 491 493 495 497 498 500 501 502 503 504 506 507 508 509 510 511 513 514 515 516 517 519 520 521 522 523 524 526 529 530 531 533 535 536 538 541 542 543 544 545 547 550 552 555 556 557 558 559 561 564 565 END 567 5. Internationalization Considerations 569 EPP is represented in XML, which provides native support for encoding 570 information using the Unicode character set and its more compact 571 representations including UTF-8. Compliant XML processors are 572 REQUIRED to understand both UTF-8 and UTF-16. Though XML includes 573 provisions to identify other character set encodings through use of an 574 "encoding" attribute in an declaration, EPP use with character 575 sets other than UTF-8 is NOT RECOMMENDED. 577 6. IANA Considerations 579 This document uses URNs to describe XML namespaces and XML schemas 580 conforming to a registry mechanism described in [IETF-XML]. Two URI 581 assignments are requested. 583 Registration request for the e164 namespace: 585 URI: urn:ietf:params:xml:ns:e164-1.0 587 Registrant Contact: See the "Author's Address" section of this 588 document. 590 XML: None. Namespace URIs do not represent an XML specification. 592 Registration request for the e164 XML schema: 594 URI: urn:ietf:params:xml:schema:e164-1.0 596 Registrant Contact: See the "Author's Address" section of this 597 document. 599 XML: See the "Formal Syntax" section of this document. 601 7. Security Considerations 603 The mapping extensions described in this document do not provide any 604 security services or introduce any additional considerations beyond 605 those described by [EPP] and protocol layers used by EPP. 607 8. Acknowledgements 609 The author gratefully acknowledges contributions to this document 610 provided by Edward Lewis, Michael Mealling, Chip Sharp, and James Yu. 612 9. References 614 Normative references: 616 [DDDS-3] M. Mealling: "Dynamic Delegation Discovery System (DDDS) Part 617 Three: The DNS Database", work in progress. 619 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 620 progress. 622 [EPP-D] S. Hollenbeck: "Extensible Provisioning Protocol Domain Name 623 Mapping", work in progress. 625 [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 627 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC2916] P. Faltstrom: "E.164 number and DNS", RFC 2916, September 631 2000. 633 Informative references: 635 [XML] Editors T. Bray et al.: "Extensible Markup Language (XML) 1.0 636 (Second Edition)", W3C Recommendation 6 October 2000. 638 [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 639 W3C Recommendation 2 May 2001. 641 [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 642 Datatypes", W3C Recommendation 2 May 2001. 644 10. Author's Address 646 Scott Hollenbeck 647 VeriSign Global Registry Services 648 21345 Ridgetop Circle 649 Dulles, VA 20166-6503 650 USA 651 shollenbeck@verisign.com 653 A. Revisions From Previous Version 655 -01 to -02: 657 Fixed typos. 659 Updated references. 661 Updated examples to keep in synch with the base EPP spec. 663 Simplified the schema through use of element references. 665 B. Full Copyright Statement 667 Copyright (C) The Internet Society 2002. All Rights Reserved. 669 This document and translations of it may be copied and furnished to 670 others, and derivative works that comment on or otherwise explain it 671 or assist in its implementation may be prepared, copied, published and 672 distributed, in whole or in part, without restriction of any kind, 673 provided that the above copyright notice and this paragraph are 674 included on all such copies and derivative works. However, this 675 document itself may not be modified in any way, such as by removing 676 the copyright notice or references to the Internet Society or other 677 Internet organizations, except as needed for the purpose of developing 678 Internet standards in which case the procedures for copyrights defined 679 in the Internet Standards process must be followed, or as required to 680 translate it into languages other than English. 682 The limited permissions granted above are perpetual and will not be 683 revoked by the Internet Society or its successors or assigns. 685 This document and the information contained herein is provided on an 686 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 687 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 688 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 689 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 690 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 Acknowledgement 694 Funding for the RFC Editor function is currently provided by the 695 Internet Society.