idnits 2.17.1 draft-ietf-crisp-iris-dreg2-00.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 on line 3892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3882. ** 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. 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 draft header indicates that this document obsoletes RFC3982, but the abstract doesn't seem to mention this, which it should. 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.) -- The document date (February 26, 2006) is 6624 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. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-core-05 == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-beep-05 ** Obsolete normative reference: RFC 3513 (ref. '7') (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 3490 (ref. '14') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (ref. '15') (Obsoleted by RFC 5891) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 ** Obsolete normative reference: RFC 4310 (ref. '20') (Obsoleted by RFC 5910) -- Obsolete informational reference (is this intentional?): RFC 3731 (ref. '22') (Obsoleted by RFC 4931) -- Obsolete informational reference (is this intentional?): RFC 3732 (ref. '23') (Obsoleted by RFC 4932) -- Obsolete informational reference (is this intentional?): RFC 3733 (ref. '24') (Obsoleted by RFC 4933) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Obsoletes: 3982 (if approved) F. Neves 5 Expires: August 30, 2006 Registro.br 6 February 26, 2006 8 Domain Registry Version 2 for the Internet Registry Information Service 9 draft-ietf-crisp-iris-dreg2-00 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 August 30, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes version 2 of the domain registration 43 information schema for IRIS. The schema extends the necessary query 44 and result operations of IRIS to provide the functional information 45 service needs for syntaxes and results used by domain registries and 46 registrars. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 5 52 3. Changes From RFC 3982 . . . . . . . . . . . . . . . . . . . . 6 53 3.1. Registration Rules . . . . . . . . . . . . . . . . . . . . 6 54 3.2. Enhanced Status Types . . . . . . . . . . . . . . . . . . 6 55 3.3. Lame Checking . . . . . . . . . . . . . . . . . . . . . . 6 56 3.4. Organizations . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Schema Description . . . . . . . . . . . . . . . . . . . . . . 13 58 4.1. Query Derivatives . . . . . . . . . . . . . . . . . . . . 13 59 4.1.1. Match Parameters . . . . . . . . . . . . . . . . . . . 13 60 4.1.2. Query . . . . . . . . . . . . . 14 61 4.1.3. Query . . . . . . . . . . . . . 14 62 4.1.4. Query . . . . . . . . . . 15 63 4.1.5. Query . . . . . . . . . . 16 64 4.1.6. Query . . . . . . . . . . . . . . 16 65 4.1.7. Query . . . . . . . . . . . . . . . 17 66 4.1.8. Query . . . . . . . . . . . . . . . . . 18 67 4.1.9. Query . . . . . . . . . . . . . . 18 68 4.1.10. Query . . . . . . . . . . . . . . 19 69 4.1.11. Query . . . . . . . . . . . . 19 70 4.1.12. Correspondence Search Group . . . . . . . . . . . . . 20 71 4.2. Result Derivatives . . . . . . . . . . . . . . . . . . . . 20 72 4.2.1. Privacy Labels . . . . . . . . . . . . . . . . . . . . 21 73 4.2.2. Result . . . . . . . . . . . . . . . . . . . 23 74 4.2.3. Result . . . . . . . . . . . . . . . . . . . . 28 75 4.2.4. Result . . . . . . . . . . . . . . . . . . . 29 76 4.2.5. Organization Types . . . . . . . . . . . . . . . . . . 31 77 4.2.6. . . . . . . . . . . . . . . . . . . 34 78 4.2.7. Correspondence Data Group . . . . . . . . . . . . . . 34 79 4.2.8. Representative Entity Group . . . . . . . . . . . . . 35 80 4.2.9. Common Date Time Group . . . . . . . . . . . . . . . . 35 81 4.2.10. Common Enhanced Status Values . . . . . . . . . . . . 36 82 4.3. Generic Code Derivatives . . . . . . . . . . . . . . . . . 36 83 4.3.1. . . . . . . . . . . . . . . . . . . . 36 84 4.3.2. . . . . . . . . . . . . . . . . 36 85 4.4. Support for . . . . . . . . . . . . . 37 86 4.5. Lameness . . . . . . . . . . . . . . . . . . . . . . . . . 38 87 5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 40 88 6. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 73 89 6.1. Message Pattern . . . . . . . . . . . . . . . . . . . . . 73 90 6.2. Server Authentication . . . . . . . . . . . . . . . . . . 73 91 7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 74 92 7.1. Application Service Label . . . . . . . . . . . . . . . . 74 93 7.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . . . 74 94 7.3. Top-Down Resolution . . . . . . . . . . . . . . . . . . . 74 95 8. Internationalization Considerations . . . . . . . . . . . . . 76 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 97 9.1. XML Namespace URN Registration . . . . . . . . . . . . . . 77 98 9.2. S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 77 99 9.3. BEEP Registration . . . . . . . . . . . . . . . . . . . . 77 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 80 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 81 104 Appendix A. Example Requests and Responses . . . . . . . . . . . 82 105 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 82 106 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 83 107 A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 85 108 Appendix B. An Example Database Serialization . . . . . . . . . . 89 109 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 91 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 92 111 Intellectual Property and Copyright Statements . . . . . . . . . . 93 113 1. Introduction 115 This document describes version 2 of an XML [1] based registry using 116 the IRIS framework. This schema is specified using the Extensible 117 Markup Language (XML) 1.0 as described in XML [1], XML Schema 118 notation as described in XML_SD [3] and XML_SS [4], and XML 119 Namespaces as described in XML_NS [2]. 121 Examples of client/server XML exchanges with this registry type are 122 available in Appendix A. 124 2. Document Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC2119 [10]. 130 3. Changes From RFC 3982 132 The following described the major differences between this 133 specification and [17]. 135 3.1. Registration Rules 137 Registration rules allow a domain registry to expose the rules upon 138 which the domain registry operates. The rules do not contain any 139 process logic or policy logic themselves. They simply specifiy rule 140 identifiers and the authority issuing the rule identifiers. 142 Registration rules are retrieved using the 143 query (see Section 4.1.11). The rules are represented by the 144 result objects (see Section 4.2.6). 146 3.2. Enhanced Status Types 148 Enhanced status types are defined to more closely align with the 149 status values of the Extensible Provisioning Protocol (EPP) (See 150 [22], [23], [24], and [19]). These status types have also been added 151 to more than just the result object. 153 The older status types and values are still specified, as some domain 154 registries expose both types and some domain registries do not have 155 EPP compatible status indicators. The two types of status are 156 clearly distinguishable. 158 3.3. Lame Checking 160 Some domain registries periodically conduct lameness checks on 161 domains and linked name servers. This specification enumerates the 162 various reasons why a domain or name server may be considered lame 163 and specifies status values. See Section 4.5. 165 3.4. Organizations 167 This specification adds the result object (see 168 Section 4.2.5.1). Organizations may have references to other 169 organizations and contacts (see Section 4.2.4). And result objects 170 that could only point to result objects in [17] now can 171 refer to either an organization or a contact. To clarify the 172 terminology, entity references such as these are now called 173 "representatives" instead of "contacts". For instance, a domain now 174 has a "legal representative" instead of a "legal contact". 176 Several new searches have been added to accomodate organizations into 177 the data model. These are , 178 , and . 180 The following example response illustrates a domain with a person as 181 a registrant and an organization as a legal representative. 183 188 189 191 195 example.com 197 201 202 Bob Smurd 203 204 206 210 211 Dewey Cheatum and Howe 212 213 215 217 218 220 223 beb140 224 225 Bill Eckels 227 228 en 229 230 231 232 Bill sells shoes down by the sea shore. 233 234 235 Rechnung verkauft Schuhe unten durch das Seeufer. 236 237 238 239 240 241
242 21 North Main Street 243
244 245 Britt 246 247 248 IA 249 250 251 50423 252 253 254 US 255 256 257 258 +1-515-555-1212 259 261 265 266 Dewey Cheatum and Howe 267 268 270 272 275 276 Dewey Cheatum and Howe 277 278 279 NAICS-040302 280 281 282 EIN-3930023-293920 283 284 285
286 1804 K Street. 287
288 289 Washington 290 291 292 DC 293 294 295 22002 296 297 298 US 299 300 301 302 +1-202-555-1212 303 304 dch-01 305 307 308 310 312 The following example response illustrates a domain with an 313 organization as a registrant and an organization as a legal 314 representative. 316 321 322 323 327 example.com 329 333 334 Big Company, Inc. 335 336 338 342 343 Dewey Cheatum and Howe 344 345 347 349 350 352 355 356 Big Company, Inc. 357 358 359 EIN-4009320-29302 360 361 362
363 1501 Hollywood Blvd. 364
365 366 Los Angeles 367 368 369 CA 370 371 372 90150 373 374 375 US 376 377 379 383 384 Dewey Cheatum and Howe 385 386 387 bigco-01 388 390 393 394 Dewey Cheatum and Howe 395 396 397 NAICS-040302 398 399 400 EIN-3930023-293920 401 402 403
404 1804 K Street. 405
406 407 Washington 408 409 410 DC 411 412 413 22002 414 415 416 US 417 418 419 420 202-555-1212 421 422 dch-01 423 425 426 428 430 4. Schema Description 432 IRIS requires the derivation of both query and result elements by a 433 registry schemas. These descriptions follow. 435 References to XML elements with no namespace qualifier are from the 436 schema defined in Section 5. References to elements and attributes 437 with the "iris" XML namespace qualifier (XML namespace prefix) are 438 from the schema defined in IRIS [5]. 440 The descriptions contained within this section refer to XML elements 441 and attributes and their relation to the exchange of data within the 442 protocol. These descriptions also contain specifications outside the 443 scope of the formal XML syntax. Therefore, this section will use 444 terms defined by RFC 2119 [10] to describe the specification outside 445 the scope of the formal XML syntax. While reading this section, 446 please reference Section 5 for needed details on the formal XML 447 syntax. 449 Many of the queries and results are unchanged from [17]. This 450 document will focus on the additions and changes, and note the 451 portions unchanged from [17]. 453 4.1. Query Derivatives 455 IRIS [5] draws a distinction between simple lookups and more complex 456 searches and queries. Simple lookups take the same form and are 457 required by all registry types, so the mechanism is defined in IRIS 458 [5]. Section 4.4 specifies the entity classes allowable in simple 459 lookups. IRIS [5] leaves the more complex and specific searches and 460 queries to be defined by each registry type. This section defines 461 those more complex queries for the domain registry type. 463 4.1.1. Match Parameters 465 The queries , , 466 , 467 , , and have 468 parameters for matching parts of character strings with whole 469 characters strings found in the registration system. This 470 specification enhances this capability from [17]. 472 Partial match parameters are defined in Section 5 in the 473 PartialMatchGroup. This grouping is composed of , 474 and . The element specifies 475 matching characters at the beginning of the string data. The 476 element specifies matching characters at the end of the 477 string data. And element specifies matching characters 478 that may be preceded or suceded by other characters in the string 479 data. 481 Some parameters allow for specifying exact matches. This is 482 accomplished using the element. 484 4.1.2. Query 486 An example of a query: 488 489 com 490 491 492 Shoe Masters Domains 493 494 495 497 searches for a registration authority 498 designated as a registrar for the registry of the server. 500 If present, the element MUST restrict the results of the 501 search to only registrars capable of registering subdomains in the 502 domain signified by the content of this element. 504 The element restricts the scope of the query with its 505 child elements using exact or partial matching (see Section 4.1.1). 506 If the element is not present, the query MUST return all 507 registrars applicable (i.e. in consideration of ). 509 This query MUST return a result set of zero or more 510 elements. See Section 4.2.5.2. 512 4.1.3. Query 514 An example of a query: 516 517 com 518 519 520 The Cobbler Shoppe 521 522 523 registrant 524 525 finds domains by searches on fields associated 526 with contacts. A search constraint of MUST restrict the 527 results to domains only underneath the domain specified by its 528 content if it is present. 530 The allowable search fields are handled with either the 531 element, the element, or one of the 532 elements in the "correspondenceSearchGroup" (see Section 4.1.12). 534 The element allows for the domains to be selected 535 based on the contact having the specified contact handle by exact 536 match. The element allows for the domains to be 537 selected based on the common name of the contact, either by exact or 538 partial matching. See Section 4.1.1. 540 The query MAY also be constrained further using the optional 541 element. The contents of this element signify the role the contact 542 has with the domain. 544 This query also provides optional elements containing 545 language tags. Clients MAY use these elements to give a hint about 546 the natural language(s) of the affected element. Servers MAY use 547 this information in processing the query, such as tailoring 548 normalization routines to aid in more effective searches. 550 While this query has structurally changed in its formal XML 551 specification, its function is unchanged from [17]. 553 4.1.4. Query 555 An example of a query: 557 558 com.br 559 560 561 005.506.560/0001-36 562 563 564 566 finds domains by searches on fields 567 associated with organizations. A search constraint of 568 MUST restrict the results to domains only underneath the domain 569 specified by its content if it is present. 571 The allowable search fields are handled with either the 572 element, the element, 573 element, the element, or one of the elements in the 574 "correspondenceSearchGroup" (see Section 4.1.12). 576 The and elements allow for the domains 577 to be selected based on the organization having the exact specified 578 value (i.e. exact match). The and elements 579 allow selection based on partial or exact match of an organizations 580 name or trading name. See Section 4.1.1. 582 The query MAY also be constrained further using the optional 583 element. The contents of this element signify the role the contact 584 has with the domain. 586 This query also provides optional elements containing 587 language tags. Clients MAY use these elements to give a hint about 588 the natural language(s) of the affected element. Servers MAY use 589 this information in processing the query, such as tailoring 590 normalization routines to aid in more effective searches. 592 does not exist in [17]. 594 4.1.5. Query 596 An example of a query: 598 599 600 601 Cobbler 602 603 604 registrant 605 607 This query is similar to (Section 4.1.3) 608 query, returning (Section 4.2.5.1) objects instead of 609 objects. This query does not have a parameter. 611 does not exist in [17]. 613 4.1.6. Query 615 An example of a query: 617 618 619 620 thecobblershop 621 622 623 625 The query finds domains by the name of a domain 626 as it is known in DNS. The element restricts the scope of 627 the query with its child elements. The element 628 specifies the beginning of the domain name. The element 629 specifies matching characters that may be preceded or suceded by 630 others characters in the domain name. The element 631 specifies the end of the domain name. 633 4.1.7. Query 635 An example of a query: 637 638 639 640 Der Schustershoppe 641 642 643 de 644 646 This query differs from the query by allowing the 647 scope of the query to take into consideration internationalized 648 domain names. This query will return the union of the desired domain 649 and any associated variants, therefore differing from a lookup in the 650 "idn" entity class (Section 4.4) (which is to only return the domain 651 or no results). 653 The element restricts the scope of the query with its 654 child element. Its child, the element, is designed to 655 contain IDNs and not ACE labels, and thus MUST match only against 656 equivalent IDNs, according to the notion of equivalence defined in 657 RFC 3490 [14]. 659 This query also provides optional elements containing 660 language tags. Clients MAY use these elements to give a hint about 661 the natural language(s) of the affected element. Servers MAY use 662 this information in processing the query, such as tailoring 663 normalization routines to aid in more effective searches. 665 It should be noted that this query is not intended to produce all 666 possible variants of a domain name but rather produce only the 667 variants of a domain that exist within the registration system. 668 Returning domain variants that do not exist within a registration 669 system is NOT RECOMMENDED. This is a clarification of this query as 670 found in [17]. 672 4.1.8. Query 674 An example of a query: 676 677 678 679 Der Schustershoppe 680 681 682 de 683 685 searches for contacts given search constraints. 687 The allowable search fields are handled by one of the elements in the 688 "correspondenceSearchGroup" (see Section 4.1.12). or the 689 element. The element selects contacts based on exact or 690 partial common name of the contact. 692 This query also provides optional elements containing 693 language tags. Clients MAY use these elements to give a hint about 694 the natural language(s) of the affected element. Servers MAY use 695 this information in processing the query, such as tailoring 696 normalization routines to aid in more effective searches. 698 4.1.9. Query 700 An example of a query: 702 703 704 705 Der Schustershoppe 706 707 708 de 709 711 searches for contacts given search constraints. 713 The allowable search fields are handled by one of the elements in the 714 "correspondenceSearchGroup" (see Section 4.1.12). or the , 715 , or elements. The , , and 716 elements select organizations based on exact or partial. 717 See Section 4.1.1. 719 This query also provides optional elements containing 720 language tags. Clients MAY use these elements to give a hint about 721 the natural language(s) of the affected element. Servers MAY use 722 this information in processing the query, such as tailoring 723 normalization routines to aid in more effective searches. 725 4.1.10. Query 727 An example of a query: 729 730 731 732 ns1.example.com 733 734 735 737 This query does a simple search for the domains being hosted by a 738 name server. The search is constrained using either the host name 739 [12], host handle, IPv4 address, or IPv6 address of the name server. 741 4.1.11. Query 743 An example of a query: 745 746 br 747 idn 748 750 This query lists the registration rules, described by 751 (Section 4.2.6) objects. This query may be 752 restricted to rules applying to a specific domain using the 753 element. This query can also be restricted to only 754 rules covering certain subjects using the element. The 755 valid subject values for this element are 'domain', 'idn', 'host', 756 'organization' and 'contact'. 758 This query does not exit in [17]. 760 4.1.12. Correspondence Search Group 762 Some of the queries above have similar query constraints for 763 searching on fields related to information used for correspondence 764 with contacts and organizations. This section describes those common 765 parameters. With the exception of , all use the matching 766 parameters outline in Section 4.1.1. 768 o constrains the query based on the e-mail address of the 769 contact or organization. This may be done by an exact e-mail 770 address using the element or by any e-mail address in 771 a domain using the element. The MUST only 772 contain a valid domain name (i.e. no '@' symbol), and the matching 773 SHOULD take place only on the domain given (i.e. no partial 774 matches with respect to substrings or parent domains). If either 775 the contents of the element or domain part of the 776 contents of the element contain a name with non-ASCII 777 characters, they MUST be normalized according to the processes of 778 RFC 3491 [15]. 780 o The , , and elements restrict the scope 781 of the query based on the city, region, or postal code of the 782 contact, respectively. Each one must only contain an 783 element containing the exact city, region, or postal code (i.e. no 784 substring searches). 786 4.2. Result Derivatives 788 With the exception of , the results of this 789 registry type have relationships with each other, specified with 790 various entity references to signify their roles. The following 791 entity-relationship diagram provides a high-level view of these 792 linkages. 794 +->>-----------------------------------------+ 795 | | 796 registrant | billing, legal, zone, abuse * 797 | security, technical, admin, +----------------+ 798 +-----------+ and other representative | | 799 | |->>--------------------+->>---+->>---*| | 800 | | | | | | 801 | |->>----------------------+ | | | 802 | |->>----+ | | +----<<-| | 803 | |-->>-+ | | | +<<-| | 804 | |->>+ | | | | | +----------------+ 805 | |-+ | | | registrant | +--------+ 806 +-----------+ | | | +-----------------------+ V 807 * | | | | | V 808 | variant | | | | V | billing, legal, zone 809 +------<<--+ | | | V | abuse, security, 810 | | | | | technical, admin, 811 name server | | | +-----|--+ and other 812 | | | | | V representative 813 +-----------+ | | registry, | | | V 814 | |*--+ | registrar, and | ^ | | 815 | | | registration | ^ * * 816 | | | service ^ | +-----------+ 817 +-----------+ | provider ^ | | | 818 * | | | | 819 +-------------------------+ | | 820 | | +-----------+ 821 | | 822 | | 823 +-------------------------+ 825 4.2.1. Privacy Labels 827 Several of the results in this registry type have values that cannot 828 be given but must be specified as present or must be flagged so that 829 clients do not divulge them. In order to achieve this, some of the 830 results use the following element types: 832 o "dateTimePrivacyType" - contains the XML Schema [3] data type 833 "dateTime". The contents of this element MUST be specified using 834 the 'Z' indicator for Coordinated Universal Time (UTC). 836 o "stringPrivacyType" - contains the XML Schema [3] data type 837 "string". 839 o "normalizedStringPrivacyType" - contains the XML Schema [3] data 840 type "normalizedString". 842 o "tokenPrivacyType" - contains the XML Schema [3] data type 843 "token". 845 o "domainStatusType" - contains an optional element of 846 indicating the date and time the status was applied and an 847 optional element of with required attribute 848 'language' indicating a description of the status. This element 849 also has an optional attribute of 'scope' to indicate the scope or 850 origin of the status value. 852 o "enhanceStatusType" - describes status that may be applied to 853 , , and results as well as 854 results. In addition to the element, 855 element, and the 'language' and 'scope' attribute, 856 has the following components: 858 * - a child element containing a service ticket 859 identifier relevant to the status. 861 * - a child element indicating further status 862 information. Values for this element are not defined by the 863 specification. This child element has a required 'authority' 864 attribute to indicate the origin of the specification of the 865 value of this element. 867 * 'actor' - an optional attribute indicating the acting entity 868 for which this status is applied. The values may be 869 "registry", "registrar", or "registrationServiceProvider". 871 * 'disposition' - an optional attribute indicating the nature of 872 this status. The values may be "pending" or "prohibited". 874 does not appear in [17]. 876 o "contactTypeType" - contains an optional child 877 elements. Each child element requires a 'language' 878 attribute. 880 As specified, they are nillable and therefore may be present with 881 empty content or present with their specified content. The use of 882 these elements is also optional. 884 If present without content, each of these element types MUST have one 885 or more of the following boolean attributes: 887 o 'private' - if true, this specifies that the content is absent 888 because it may never be published. 890 o 'denied' - if true, this specifies that the content is absent 891 because policy does not allow it to be given under the current 892 level of access. 894 If present with content, each of these element types MAY have one or 895 more of the following boolean attributes: 897 o 'doNotRedistribute' - if true, this specifies that the content is 898 not to be redistributed. 900 o 'specialAccess' - if true, this specifies that the content has 901 been provided due to special access rights. 903 These boolean attributes SHOULD be used in accordance with the level 904 of access being granted the recepient of the data. For example, 905 marking data as 'private' or 'denied' is to be expected if the user 906 is anonymous or has some other low level of access that does not 907 warrant viewing of that particular data. Likewise, data marked with 908 'doNotRedistribute' or 'specialAccess' is to be expected if the user 909 is authenticated and has a high level of access. 911 4.2.2. Result 913 An example of a result: 915 918 example.com 919 example-com-1 920 924 928 934 938 939 941 The result represents an instance of a domain assignment. 942 The children of the element are as follows: 944 o - the full name of the domain as it is in DNS. The 945 contents of this element MUST be a domain name as specified by RFC 946 1035 [9]. 948 o - the name of the domain in nameprep form if applicable. 949 See RFC 3491 [15]. 951 o - a registry unique assigned identifier to a 952 domain. 954 o - MUST contain an entity reference to a referent of 955 type (Section 4.2.3). The optional attribute 'lame' 956 indicates if this nameserver is lame as it relates to this domain. 957 Its value is specified by the "lameReasonType". See Section 4.5. 959 o - an element containing an entity reference to the 960 registrant of this domain. The referent MUST be a 961 (Section 4.2.4) result or an (Section 4.2.5.1) 962 result. 964 o The entity references found in the representativeEntityGroup (See 965 Section 4.2.8). 967 o - may contain at least one of the following elements of 968 type 'domainStatusType' (see Section 4.2.1), but none of these 969 elements may appear more than once. 971 * - permanently inactive 973 * - normal state 975 * - registration assigned but delegation 976 inactive 978 * - dispute 980 * - database purge pending 982 * - change of authority pending 984 * - on hold by registry 986 * - on hold by registrar 988 o - this element extends the enhanced status values 989 in "baseEnhancedStatusValuesType" (see Section 4.2.10). It 990 defines the following additional status values: 992 * - available via DNS (either via delegation or direct 993 publication) 995 * - unavailable via DNS 997 * - the domain has been found to be lame (see 998 Section 4.5). This element is of "lameEnhancedStatusType". 1000 * - the domain is not lame (see Section 4.5). 1002 * - registrant assignment is in dispute 1004 * - renewal of domain registration 1006 * - period at the creation or activation of this 1007 domain (see RFC 3915 [19]) 1009 * - period at the renewal of this domain (see RFC 1010 3915 [19]) 1012 * - period at the automatic renewal of this 1013 domain (see RFC 3915 [19]) 1015 * - period at the transfer of this domain (see 1016 RFC 3915 [19]) 1018 * - period at the redemption of this domain 1019 (see RFC 3915 [19]) 1021 * - change to previous status of this domain 1023 Both the and values MAY appear in a 1024 result object. However, the use of sole use of the 1025 element is RECOMMENDED. 1027 o - contains an entity reference, the referent of 1028 which MUST be a (Section 4.2.2). 1030 o - an element containing an entity 1031 reference, the referent of which MUST be a 1032 (Section 4.2.2). The intention of this element is to point to the 1033 downstream registration reference. Therefore, if this is a result 1034 given back by a domain registry, it should point to the domain in 1035 the domain registrar or registrant service. 1037 o - contains an entity reference specifying the domain 1038 registry operator for this domain which MUST be a 1039 (Section 4.2.5.2). This element has an 1040 optional, boolean 'hosting' attribute. When the value of this 1041 attribute is positive, it indicates that the registry is 1042 responsible for authoratively answering DNS queries for this 1043 domain. 1045 o - contains an entity reference specifying the domain 1046 registrar operator for this domain which MUST be a 1047 (Section 4.2.5.2). This element has an 1048 optional, boolean 'hosting' attribute. When the value of this 1049 attribute is positive, it indicates that the registrar is 1050 responsible for authoratively answering DNS queries for this 1051 domain. 1053 o - contains an entity reference 1054 specifying the registration service provider for this domain which 1055 MUST be a (Section 4.2.5.2). This element 1056 has an optional, boolean 'hosting' attribute. When the value of 1057 this attribute is positive, it indicates that the registrar is 1058 responsible for authoratively answering DNS queries for this 1059 domain. 1061 o The elements found in the commonDateTimeGroup (See Section 4.2.9). 1063 o - an element containing the date and 1064 time of the initial delegation of this domain. 1066 o - an element containing the date and time of 1067 last renewal of this domain. 1069 o - an element containing the date and time of 1070 the expiration of this domain. 1072 o - specifies the last time a 1073 contact for the domain was added or removed. 1075 o - an element containing an entity 1076 reference. The referent MUST be a (Section 4.2.4) 1077 responsible for the last addition or removal of a contact for this 1078 domain. 1080 o - an element containing the 1081 date and time of the last time one of the nameservers was added or 1082 removed for the delegation of this domain. 1084 o - an element containing an entity 1085 reference. The referent MUST be a (Section 4.2.4) 1086 result and be responsible for the last addition or removal of a 1087 nameserver for this domain. 1089 o - an element containing the date and 1090 time of the last time this domain and its nameservers were checked 1091 for lameness. See Section 4.5. 1093 o - an element containing the 1094 date and time of the last time this domain and its nameservers 1095 were checked for lameness and were considered not lame. See 1096 Section 4.5. 1098 o - indicates the number of seconds after signature 1099 generation when a parent's signature on delegation signer 1100 information will expire. See [20]. 1102 o - this element contains the following child 1103 elements describing delegation signer data: 1105 * - key tag value as described in section 5.1.1 of [18]. 1107 * - algorithm value as described in section 5.1.2 of 1108 [18]. 1110 * - digest type values as described in section 5.1.3 1111 of [18]. 1113 * - digest value as described in section 5.1.4 of [18]. 1115 * - describes the key data used as input in the 1116 delegation signer hash calculation. This element has the 1117 following child elements: 1119 + - flags field value as described in section 2.1.1 of 1120 [18]. 1122 + - protocol field value as described in section 1123 2.1.2 of [18]. 1125 + - algorithm number field as described in section 1126 2.1.3 of [18]. 1128 + - encoded public key field value as described in 1129 section 2.1.4 of [18]. 1131 o - an element containing an entity reference 1132 specifying a referent that is indirectly associated with this 1133 domain. 1135 4.2.3. Result 1137 An example of a result: 1139 1142 nsol184 1143 a.iana-servers.net 1144 192.0.2.43 1145 1149 1151 The element represents an instance of a host registration. 1152 The children of the element are as follows: 1154 o - a registry unique assigned identifier for the host. 1156 o - the fully qualified domain name of the host. The 1157 contents of this element are a domain name and MUST conform to RFC 1158 1035 [9]. 1160 o - the content of which MUST conform to the a valid 1161 IP version 4 host address as specified by RFC 791 [8]. 1163 o - the content of which MUST conform to the a valid 1164 IP version 6 host address as specified by RFC 3513 [7]. 1166 o - an element containing an entity reference 1167 specifying a contact associated with this host. The referent MUST 1168 be (Section 4.2.4) results. 1170 o the elements from the commonDateTimeGroup (see Section 4.2.9). 1172 o - this element extends the enhanced status values 1173 in "baseEnhancedStatusValuesType" (see Section 4.2.10). It 1174 defines the following additional status values: 1176 * - this host has linkages to one or more domains. 1178 * - this host has been found to be lame (see Section 4.5). 1179 This element is of the "lameEnhancedStatusType". 1181 * - this host is not lame (see Section 4.5). 1183 o - an element containing an entity reference 1184 specifying a referent that is indirectly associated with this 1185 host. 1187 4.2.4. Result 1189 An example of a result: 1191 1194 dconrad 1195 IANA Manager 1196 Internet Assigned Numbers Authority 1197 res-dom@iana.org 1198 1199
4676 Admiralty Way, Suite 330
1200 Marina del Rey 1201 CA 1202 92092 1203 US 1204 1205 310-823-9358 1207 1209 The element represents an instance of a contact 1210 registration. A contact is usually thought to be a specific person 1211 or set of persons with a specific role. Organizations SHOULD be 1212 represented with the result object. The children of 1213 the element are as follows: 1215 o - a registry unique assigned identifier for this 1216 contact. 1218 o - the name of the contact. 1220 o - a specification of the language code to use to 1221 localize the data in this result. 1223 o - contains one of the following child elements: , 1224 , , or . Each of these elements is a 1225 "contactTypeType" as defined in Section 4.2.1. Use of the 1226 result object is RECOMMENDED instead of a 1227 result object with a type indicating it is an organization. 1229 o - an element containing the organization name of 1230 the contact. Use of this element and the use of the 1231 result object to represent an organization is NOT RECOMMENDED. 1233 o The elements from the correspondenceDataGroup (see Section 4.2.7). 1235 o The elements from the representativeEntityGroup (see 1236 Section 4.2.8). 1238 o The elements from the commonDateTimeGroup (see Section 4.2.9). 1240 o - an element containing an entity reference 1241 specifying equivalents of this contact that have been translated 1242 into other languages. The referent MUST be 1243 (Section 4.2.4) results. 1245 o - this element extends the enhanced status values 1246 in "baseEnhancedStatusValuesType" (see Section 4.2.10). It 1247 defines the following additional status values: 1249 * - this contact has linkages to one or more domains, 1250 hosts, or organizations. 1252 o - an element containing an entity reference 1253 specifying a referent that is indirectly associated with this 1254 contact. 1256 4.2.5. Organization Types 1258 This specification defines two types of organizations, 1259 results objects and result objects. They 1260 share a common basic structure but differ materially in that 1261 organizations are objects that can be registered in the registration 1262 system while registration authorities usually exist in the 1263 registration system via other means. This common defintion is called 1264 the "organizationBaseType". 1266 The child elements shared by both and 1267 are as follows: 1269 o - the name of the organization. 1271 o - an alternative name of the organization used for 1272 certain types of commerce. 1274 o - elements containing identifiers of the organization 1275 type used in civic and legal systems. Examples would be business 1276 category codes, tax identification numbers, etc. 1278 o the elements in the correspondenceDataGroup (see Section 4.2.7). 1280 o the elements in the representativeEntityGroup (see Section 4.2.8). 1282 o - an element containing an entity reference 1283 specifying a referent that is indirectly associated with this 1284 organization type. 1286 4.2.5.1. 1288 An example of a result: 1290 1293 1294 Shoes and More, Inc. 1295 1296 1300 Mark Kosters 1302 1303 smi 1304 1305 1306 1307 1309 The result object is derivative of the 1310 "organizationBaseType". In addition to the child elements defined in 1311 the base type, this result object has the following child elements: 1313 o - a registry unique assigned identifier for 1314 this organization. 1316 o - this element extends the enhanced status values 1317 in "baseEnhancedStatusValuesType" (see Section 4.2.10). It 1318 defines the following additional status values: 1320 * - this organization has linkages to one or more 1321 domains or contacts. 1323 4.2.5.2. 1325 An example of a result: 1327 1330 1331 Internet Assigned Numbers Authority 1332 1333 1337 1339 1341 The result object represents an entity 1342 capable of registering domains. Like the result 1343 object, is a derivative of the 1344 "organizationBaseType". In addition to the child elements defined in 1345 the base type, this result object has the following child elements: 1347 o - a registry unique assigned 1348 identifier for this registration authority. 1350 o The child element of 1351 contains an entity reference pointing to the entity "id" in the 1352 entity class "iris". The authority areas found in the referent 1353 MUST be domains for which a given registration authority has 1354 control. 1356 o - this element extends the enhanced status values 1357 in "baseEnhancedStatusValuesType" (see Section 4.2.10). It 1358 defines the following additional status values: 1360 * - this registration authority has linkages to one or 1361 more domains, contacts, organizations, or hosts. 1363 * - this registration authority is not allow to 1364 register entities into the registration system. 1366 * - this registration authority is enabled and may 1367 register entities into the registration system. 1369 o The registration authority type child elements, , 1370 , , and , determine 1371 the role in which this registration authority plays in the process 1372 of registering domains. The intent of this element is to explain 1373 the various roles a registration authority may have with regards 1374 to the authority areas pointed to by the 1375 element. A client MAY understand the relationship of a 1376 registration authority with respect to a domain by the placement 1377 of the reference in the domain (e.g. , , or 1378 ). 1380 o The child elements each contain one domain name 1381 signifying the domains for which this registration authority may 1382 register sub-domains. 1384 4.2.6. 1386 An example of a result: 1388 1391 IDN-2005-10 1392 ONLY-LATIN 1393 1395 The result object represents a registration rule 1396 or policy of the registration system. It is not intended to provide 1397 procedural codes that may be executed by a client. Its purpose is to 1398 identify registration rules and procedures enabling clients that 1399 recognize the rule identifiers to act upon them in a predetermined 1400 way. 1402 This result object is composed of three elements, the first two being 1403 and . The content of these two elements contains 1404 a rule identifier, and each element has an 'authority' attribute 1405 containing the authority responsible for setting the rule or sub 1406 rule. is optional and there can be more than one. 1408 The final child element is containing an entity 1409 reference specifying a referent that is indirectly associated with 1410 this registration rule. 1412 4.2.7. Correspondence Data Group 1414 The correspondenceDataGroup of elements describe common information 1415 for correspondence with entities. This group is composed of the 1416 following elements: 1418 o - elements containing an e-mail address for this contact. 1420 o - elements containing a SIP address for this contact. 1422 o - elements containing children representing a 1423 postal address. has the following children: 1425 *
- an element containing the street address for this 1426 contact. 1428 * - an element containing the city for this contact. 1430 * - an element containing the national region for this 1431 contact. 1433 * - an element containing the postal code for this 1434 contact. 1436 * - an element containing the country for this contact. 1437 This SHOULD be a 2-letter country code compliant with ISO 3166 1438 [11]. 1440 o - elements containing a voice phone number for this 1441 contact. If it begins with a '+' (plus) character, it MUST be a 1442 number defined by E164 [13]. The format number defined in E164 1443 [13] is RECOMMENDED. 1445 o - elements containing a facsimile phone number for this 1446 contact. If it begins with a '+' (plus) character, it MUST be a 1447 number defined by E164 [13]. The format number defined in E164 1448 [13] is RECOMMENDED. 1450 4.2.8. Representative Entity Group 1452 The representativeEntityGroup of elements describe common entity 1453 references to contacts and organizations used by results. Each of 1454 these elements represents an entity reference, and the referent of 1455 each MUST be a (Section 4.2.4) or 1456 (Section 4.2.5.1). 1458 o 1460 o 1462 o 1464 o 1466 o 1468 o 1470 o 1472 o 1474 4.2.9. Common Date Time Group 1476 The commonDateTimeGroup of elements represent date and time values 1477 found in many of the results. These elements are as follows: 1479 o - an element containing the date and time of the 1480 creation of the containing result object. 1482 o - an element containing the date and 1483 time of the last modification of the containing result object. 1485 o - an element containing the date and 1486 time of the last time the data for the containing result was 1487 verified by the responsible registration authority. 1489 4.2.10. Common Enhanced Status Values 1491 Many of the result objects in this specification have a common set of 1492 status values. These are specified with a defined type of 1493 baseEnhancedStatusValuesType. This type definition has the following 1494 child elements, all of which are "enhancedStatusType" elements (see 1495 Section 4.2.1. 1497 o - the containing result object is reserved and is not 1498 available for registration under normal registration procedures. 1500 o - specifies the creation status of the containing result 1501 object in the registration system. 1503 o - specifies the deletion status of the containing result 1504 object in the registration system. 1506 o - specifies the transfer status of the containing 1507 result object from one responsible or owning entity in the 1508 registration system to another. 1510 o - specifies the status of the containing result object as 1511 it relates to information in the containing result object being 1512 modified or having the ability to be modified. 1514 o - specifies a registration system specific status of the 1515 containing result object. 1517 4.3. Generic Code Derivatives 1519 4.3.1. 1521 Servers MAY use the error code when a query must be 1522 narrowed to yield a result set acceptable to the policies of the 1523 server operator. 1525 4.3.2. 1527 The queries , , and 1528 support optional language tags that allow a client to 1529 suggest to a server the languages in which to scope the queries. If 1530 a client passes to the server a language which the server does not 1531 support, the server MAY use this error code to indicate that one of 1532 the languages is not supported. 1534 This element contains child elements named . 1535 Each of these child elements specify a language not supported by the 1536 server. When a server returns this error, it MUST give the languages 1537 from the query which are not supported. 1539 4.4. Support for 1541 An example of an query: 1543 1548 The following types of entity classes are recognized by the query for this registry: 1551 o host-name - the fully qualified domain name of a nameserver. 1552 Yields a (Section 4.2.3) in the response. 1554 o host-handle - the registry unique identifier given a nameserver. 1555 Yields a (Section 4.2.3) in the response. 1557 o domain-name - the fully qualified name of a domain. This a domain 1558 name as specified by RFC 1035 [9]. Yields a 1559 (Section 4.2.2) in the response. 1561 o idn - the fully qualified name of a domain in nameprep form (see 1562 RFC 3491 [15]). Yields a (Section 4.2.2) in the 1563 response. 1565 o domain-handle - the registry unique identifier given a domain. 1566 Yields a (Section 4.2.2) in the response. 1568 o contact-handle - the registry unique identifier given a contact. 1569 Yields a (Section 4.2.4) in the response. 1571 o organization-handle - the registry unique identifier given an 1572 organization. Yields a (Section 4.2.5.1) in the 1573 response. 1575 o ipv4-address - the IPv4 address of a nameserver. Yields a 1576 (Section 4.2.3) in the response. 1578 o ipv6-address - the IPv6 address of a nameserver. Yields a 1579 (Section 4.2.3) in the response. 1581 o registration-authority - the name of a registration authority. 1582 Yields a (Section 4.2.5.2) in the 1583 response. 1585 o All names in these entity classes are case insensitive. 1587 4.5. Lameness 1589 Some registries, registrars, or registration service providers may 1590 periodically check to see if a domain is "lame". In DNS terms, 1591 "lame" has a narrow definition as defined in [21], but the term is 1592 often used in a wider context. The explanation given here covers the 1593 wider context as is often found in registration systems and is not 1594 meant to redefine the stricter meaning in DNS as specified in [21]. 1595 A nameserver listed as authoritative for a domain can be considered 1596 lame for three reasons: 1598 1. The nameserver is unresponsive. 1600 2. The nameserver does not answer authoritatively for the domain. 1601 See [21]. 1603 3. The address of the nameserver cannot be resolved, usually due to 1604 the domain in which it exists being lame itself. 1606 In a registration database, lameness may exist in three places: 1608 1. A nameserver is lame if its address cannot be resolved or it does 1609 not answer queries. 1611 2. The relationship between a domain and a nameserver could be lame 1612 if the nameserver does not authoritatively answer queries for the 1613 domain (i.e. it could answer authoritatively for other domains). 1615 3. A domain is lame if all of its nameservers are lame. 1617 This specification enumerates the reasons for lameness with 1618 "lameReasonType". The enumerated values are: 1620 o queryTimeout - an answer was not received within a specified 1621 duration of time. 1623 o nonAuthoritativeAnswer - the name server queried did not return an 1624 authoritative answer. 1626 o unknownDomainName - the name server queried unknown the domain 1627 name. 1629 o unknownHostName - the name server's name is unknown. 1631 o queryRefused - the name server refused to answer the query. 1633 o connectionRefused - the name server refused to accept the query 1634 connection. 1636 o cannonicalName - the name server's name in a CNAME and not an A 1637 record. 1639 o soaVersionNotInSync - the SOA version is not in sync between this 1640 server and the delegated master. 1642 o dnsProtocolLevelError - the query resulted in a DNS protocol error 1644 o other - lame for an unexplaned reason 1646 A special status type also exists to describe lameness, the 1647 "lameEnhancedStatusType". This type extends the "enhancedStatusType" 1648 by adding an element of the "lameReasonType". See 1649 Section 4.2.1 for a description of the "enhancedStatusType". 1651 5. Formal XML Syntax 1653 This registry schema is specified in the XML Schema notation. The 1654 formal syntax presented here is a complete schema representation 1655 suitable for automated validation of an XML instance when combined 1656 with the formal schema syntax of IRIS. 1658 1659 1665 1667 1668 1669 Domain registry schema v2 1670 1671 1673 1674 1675 1676 1677 1679 1680 1681 1683 1685 1686 1688 1689 1693 1699 1700 1701 1702 1704 1709 1710 1711 1713 1715 1716 1718 1719 1723 1724 1726 1729 1732 1733 1738 1743 1744 1745 1746 1747 1752 1753 1754 1756 1758 1759 1761 1762 1766 1767 1769 1772 1775 1778 1781 1782 1787 1792 1793 1794 1796 1798 1803 1804 1805 1807 1809 1810 1812 1813 1814 1816 1819 1822 1823 1828 1833 1834 1835 1836 1838 1843 1844 1845 1847 1849 1850 1852 1853 1856 1857 1858 1859 1861 1866 1867 1868 1870 1872 1873 1875 1876 1879 1884 1885 1886 1887 1889 1894 1895 1896 1898 1900 1901 1903 1904 1905 1907 1910 1911 1916 1917 1918 1919 1921 1926 1927 1928 1930 1932 1933 1935 1936 1937 1939 1942 1945 1948 1949 1954 1955 1956 1957 1959 1964 1965 1966 1968 1970 1971 1973 1974 1978 1979 1982 1985 1989 1992 1993 1994 1995 1996 1998 2003 2004 2005 2007 2009 2010 2012 2013 2017 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2036 2041 2042 2043 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2059 2060 2061 2063 2065 2066 2069 2072 2075 2078 2079 2081 2083 2084 2086 2088 2089 2091 2093 2095 2097 2099 2100 2102 2103 2105 2107 2108 2110 2113 2114 2116 2120 2121 2122 2124 2126 2128 2129 2131 2132 2133 2134 2135 2137 2139 2140 2143 2144 2146 2147 2148 2149 2150 2152 2153 2154 2156 2158 2159 2161 2162 2165 2170 2176 2180 2181 2182 2184 2187 2188 2189 2190 2191 2196 2197 2203 2208 2212 2213 2214 2219 2224 2230 2235 2240 2245 2250 2255 2260 2261 2262 2263 2267 2268 2269 2270 2273 2276 2279 2282 2285 2288 2291 2294 2297 2300 2303 2306 2309 2310 2311 2312 2313 2314 2319 2324 2329 2334 2339 2340 2346 2352 2358 2364 2369 2375 2381 2385 2386 2387 2388 2389 2390 2391 2395 2396 2397 2399 2401 2403 2405 2407 2408 2409 2411 2413 2415 2416 2417 2418 2419 2420 2421 2423 2424 2425 2426 2427 2428 2429 2433 2434 2435 2436 2438 2443 2444 2445 2447 2450 2451 2452 2454 2455 2456 2458 2460 2461 2463 2464 2470 2473 2478 2483 2488 2489 2493 2494 2495 2496 2499 2502 2505 2508 2509 2510 2511 2512 2513 2517 2518 2520 2521 2523 2528 2529 2530 2532 2534 2535 2537 2538 2544 2550 2556 2557 2558 2562 2563 2564 2565 2567 2568 2569 2571 2573 2574 2576 2577 2583 2587 2588 2589 2590 2593 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2607 2612 2613 2614 2615 2617 2618 2620 2621 2627 2633 2638 2642 2643 2644 2647 2650 2653 2656 2657 2658 2659 2665 2666 2667 2668 2673 2677 2678 2679 2680 2683 2686 2687 2688 2689 2690 2691 2695 2696 2697 2698 2700 2705 2706 2707 2709 2710 2711 2714 2717 2719 2720 2721 2723 2725 2727 2730 2732 2733 2734 2735 2737 2739 2740 2742 2743 2744 2746 2748 2749 2751 2752 2758 2763 2766 2768 2769 2770 2772 2773 2774 2776 2777 2778 2780 2781 2782 2783 2788 2792 2793 2794 2795 2798 2801 2804 2808 2809 2810 2811 2812 2813 2814 2815 2816 2818 2823 2824 2825 2827 2829 2830 2832 2833 2838 2843 2847 2848 2849 2850 2852 2854 2855 2857 2861 2862 2863 2865 2870 2871 2872 2874 2875 2876 2879 2882 2885 2888 2891 2894 2897 2900 2901 2903 2904 2905 2907 2908 2909 2911 2914 2917 2918 2920 2921 2922 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2935 2936 2937 2939 2941 2944 2947 2950 2953 2955 2957 2958 2960 2962 2963 2964 2966 2968 2969 2971 2973 2974 2975 2977 2979 2980 2982 2984 2985 2986 2988 2990 2991 2993 2995 2996 2997 2999 3001 3002 3007 3011 3012 3013 3015 3019 3020 3021 3022 3023 3024 3026 3029 3031 3033 3034 3039 3044 3048 3049 3050 3052 3056 3057 3058 3059 3060 3064 3065 3066 3068 3072 3073 3074 3075 3076 3077 3079 3081 3082 3084 3086 3088 3090 3091 3092 3093 3095 3096 3098 3100 3102 3103 3104 3105 3108 3110 3112 3113 3117 3118 3119 3121 3125 3126 3127 3128 3129 3130 3132 3134 3135 3136 3137 3138 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3155 3156 3157 3158 3159 3161 3162 3163 3164 3166 3167 3168 3169 3170 3172 3173 3174 3176 3181 3182 3183 3185 3187 3188 3190 3191 3196 3197 3198 3199 3201 3206 3208 Figure 21: dreg.xsd 3210 6. BEEP Transport Compliance 3212 IRIS allows several extensions of the core capabilities. This 3213 section outlines those extensions allowable by IRIS-BEEP [6]. 3215 6.1. Message Pattern 3217 This registry type uses the default message pattern as described in 3218 IRIS-BEEP [6]. 3220 6.2. Server Authentication 3222 This registry type only uses the basic TLS server authentication 3223 method as described in IRIS-BEEP [6]. 3225 7. URI Resolution 3227 7.1. Application Service Label 3229 The application service label associated with this registry type MUST 3230 be "DREG2". This is the abbreviated form of the URN for this 3231 registry type, urn:ietf:params:xml:ns:dreg2. 3233 7.2. Bottom-Up Resolution 3235 The bottom-up alternative resolution method MUST be identified as 3236 'bottom' in IRIS URI's. 3238 The process for this resolution method differs from the direct- 3239 resolution method if the authority is only a domain name (i.e. 3240 without the port number). The process for this condition is as 3241 follows: 3243 1. The IRIS [5] direct resolution process is tried on the domain 3244 name (e.g. "example.com" ). 3246 2. If the direct resolution process yields no server for which a 3247 connection can be made, then the leftmost label of the domain 3248 name is removed, and the first step is repeated again (e.g. "com" 3249 ). 3251 3. If all the labels of the domain name are removed and no server 3252 connections have been made, then the DNS is queried for the 3253 address records corresponding to the original domain name and the 3254 port used is the well-known port for the default protocol of 3255 IRIS. 3257 7.3. Top-Down Resolution 3259 The top-down alternative resolution method MUST be identified as 3260 'top' in IRIS URI's. 3262 The process for this resolution method differs from the direct- 3263 resolution method if the authority is only a domain name (i.e. 3264 without the port number). The process for this condition is as 3265 follows: 3267 1. The domain name is reduced to its rightmost label. This is 3268 always '.'. 3270 2. The IRIS [5] direct resolution process is tried on the domain 3271 name. 3273 3. If the direct resolution process yields no server for which a 3274 connection can be made, then the original label to the left of 3275 the rightmost label of the domain name is prepended, and the 3276 second step is repeated again (e.g. if "." then "com", if "com" 3277 then "example.com"). 3279 4. If all the labels of the original domain are present and no 3280 server connections have been made, then the DNS is queried for 3281 the address records corresponding to the original domain name and 3282 the port used is the well-known port for the default protocol of 3283 IRIS. 3285 8. Internationalization Considerations 3287 Implementers should be aware of considerations for 3288 internationalization in IRIS [5]. 3290 This document specifies the lookup of domain names, both the 3291 traditional ASCII form and the IDN form. In addition, the social 3292 data associated with contacts may also be non-ASCII, and could 3293 contain virtually any Unicode character. The element is 3294 provided in queries that have potential to traverse such data. 3295 Clients should use these elements to indicate to the server of the 3296 target languages desired, and servers should use these elements to 3297 better enable normalization and search processes (see 3298 ). 3300 Clients needing to localize the data tags in this protocol should 3301 take note that localization is only needed on the names of XML 3302 elements and attributes with the exception of elements containing 3303 date and time information. The schema for this registry has been 3304 designed so that clients need not interpret the content of elements 3305 or attributes for localization, other than those elements containing 3306 date and time information. 3308 Clients should also make use of the elements provided in 3309 many of the results. Results containing data that may be in Unicode 3310 are accompanied by these elements in order to aid better presentation 3311 of the data to the user. 3313 The "dateTimePrivacyType" element type contains the XML Schema [3] 3314 data type "dateTime". The contents of this element MUST be specified 3315 using the 'Z' indicator for Coordinated Universal Time (UTC). 3317 9. IANA Considerations 3319 9.1. XML Namespace URN Registration 3321 This document makes use of a proposed XML namespace and schema 3322 registry specified in XML_URN [16]. Accordingly, the following 3323 registration information is provided for the IANA: 3325 o XML Schema URN/URI: 3327 * urn:ietf:params:xml:schema:dreg2 3329 o Contact: 3331 * Andrew Newton 3333 * Frederico Neves 3335 o XML: 3337 * The XML Schema specified in Section 5 3339 o XML Namespace URN/URI: 3341 * urn:ietf:params:xml:ns:dreg2 3343 o Contact: 3345 * Andrew Newton 3347 * Frederico Neves 3349 o XML: 3351 * The XML Schema specified in Section 5 3353 9.2. S-NAPTR Registration 3355 The following S-NAPTR application service label will need to be 3356 registered with IANA according to the IANA considerations defined in 3357 IRIS [5]: 3359 DREG2 3361 9.3. BEEP Registration 3363 The following BEEP Profile URI is to be registeried with IANA, in 3364 addition to the registration provided in IRIS-BEEP [6]. 3366 http://iana.org/beep/iris1/dreg2 3368 10. Security Considerations 3370 This document lays out no new considerations for security precautions 3371 beyond that specified in IRIS [5]. 3373 11. References 3375 11.1. Normative References 3377 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 3378 1.0", W3C XML, February 1998, 3379 . 3381 [2] World Wide Web Consortium, "Namespaces in XML", W3C XML 3382 Namespaces, January 1999, 3383 . 3385 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", 3386 W3C XML Schema, October 2000, 3387 . 3389 [4] World Wide Web Consortium, "XML Schema Part 1: Structures", 3390 W3C XML Schema, October 2000, 3391 . 3393 [5] Newton, A. and M. Sanz, "Internet Registry Information 3394 Service", draft-ietf-crisp-iris-core-05 (work in progress), 3395 January 2004. 3397 [6] Newton, A. and M. Sanz, "Internet Registry Information Service 3398 (IRIS) over Blocks Extensible Exchange Protocol (BEEP)", 3399 draft-ietf-crisp-iris-beep-05 (work in progress), January 2004. 3401 [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 3402 Addressing Architecture", RFC 3513, April 2003. 3404 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, 3405 September 1981. 3407 [9] Mockapetris, P., "Domain names - implementation and 3408 specification", STD 13, RFC 1035, November 1987. 3410 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3411 Levels", RFC 2119, BCP 14, March 1997. 3413 [11] International Organization for Standardization, "Codes for the 3414 representation of names of countries, 3rd edition", 3415 ISO Standard 3166, August 1988. 3417 [12] Braden, R., "Requirements for Internet Hosts - Application and 3418 Support", STD 3, RFC 1123, October 1989. 3420 [13] International Telecommunications Union, "The International 3421 Public Telecommunication Numbering Plan", ITU-T Recommendation 3422 E.164, 1991. 3424 [14] Faltstrom, P., Hoffman, P., and A. Costello, 3425 "Internationalizing Domain Names in Applications (IDNA)", 3426 RFC 3490, March 2003. 3428 [15] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 3429 for Internationalized Domain Names (IDN)", RFC 3491, 3430 March 2003. 3432 [16] Mealling, M., "The IETF XML Registry", 3433 draft-mealling-iana-xmlns-registry-03 (work in progress), 3434 November 2001. 3436 [17] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type 3437 for the Internet Registry Information Service (IRIS)", 3438 RFC 3982, January 2005. 3440 [18] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 3441 "Resource Records for the DNS Security Extensions", RFC 4034, 3442 March 2005. 3444 [19] Hollenbeck, S., "Domain Registry Grace Period Mapping for the 3445 Extensible Provisioning Protocol (EPP)", RFC 3915, 3446 September 2004. 3448 [20] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 3449 Mapping for the Extensible Provisioning Protocol (EPP)", 3450 RFC 4310, December 2005. 3452 11.2. Informative References 3454 [21] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", 3455 RFC 1612, May 1994. 3457 [22] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain 3458 Name Mapping", RFC 3731, March 2004. 3460 [23] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host 3461 Mapping", RFC 3732, March 2004. 3463 [24] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact 3464 Mapping", RFC 3733, March 2004. 3466 Appendix A. Example Requests and Responses 3468 The examples in this section use the string "C:" to denote data sent 3469 by a client to a server and the string "S:" to denote data sent by a 3470 server to a client. 3472 A.1. Example 1 3474 The following is an example of an entity lookup in a dreg2 registry 3475 for the domain-name of 'example.com'. The response shows the ability 3476 to specify data as being withheld because it is private. 3478 C: 3479 C: 3481 C: 3482 C: 3483 C: 3484 C: 3488 C: 3489 C: 3490 C: 3491 C: 3493 S: 3494 S: 3496 S: 3497 S: 3498 S: 3499 S: 3500 S: 3503 S: 3504 S: example.com 3505 S: tcs-com-1 3506 S: 3507 S: 3510 S: 3511 S: 3514 S: 3515 S: 3518 S: 3519 S: 3520 S: 3521 S: 3522 S: 3523 S: 3526 S: 3527 S: 3528 S: 3529 S: 3532 S: 3533 S: 3534 S: 3535 S: 3536 S: 3537 S: 3539 Figure 22: Example 1 3541 A.2. Example 2 3543 The following is an example of an entity lookup in a dreg2 registry 3544 for the contact-handle of 'mak21'. The response shows the ability to 3545 specify data as being withheld because it is private. 3547 C: 3548 C: 3550 C: 3551 C: 3552 C: 3553 C: 3557 C: 3558 C: 3559 C: 3560 C: 3562 S: 3563 S: 3565 S: 3566 S: 3567 S: 3568 S: 3569 S: 3572 S: 3573 S: mak21 3574 S: 3575 S: 3576 S: Mark Kosters 3577 S: 3578 S: 3579 S: 3580 S: VeriSign, Inc. 3581 S: 3582 S: 3583 S: markk@verisignlabs.com 3584 S: 3585 S: 3586 S: 3587 S: 3588 S: 3589 S: 3590 S: 3591 S: 3592 S: 3594 Figure 23: Example 2 3596 A.3. Example 3 3598 The following is an example of a domain search based on a 3599 registrant's name beginning with the string 'The Cobbler Shoppe'. 3600 This example also shows the use of bags. 3602 C: 3603 C: 3605 C: 3606 C: 3607 C: 3608 C: 3610 C: com 3611 C: 3612 C: 3613 C: The Cobbler Shoppe 3614 C: 3615 C: 3616 C: registrant 3617 C: 3618 C: 3619 C: 3620 C: 3621 C: 3623 S: 3624 S: 3627 S: 3628 S: 3629 S: 3630 S: 3635 S: example.com 3636 S: 3640 S: 3644 S: 3648 S: 3649 S: Bill Eckels 3650 S: 3651 S: 3652 S: 3657 S: 3658 S: Mark Kosters 3659 S: 3660 S: 3661 S: 3662 S: 3663 S: 3664 S: 3665 S: 3670 S: 3674 S: 3675 S: 3676 S: 3677 S: 3682 S: beb140 3683 S: 3684 S: Bill Eckels 3685 S: 3686 S: en 3687 S: 3688 S: 3689 S: 3690 S: Bill sells shoes down by the sea shore. 3692 S: 3693 S: 3694 S: Rechnung verkauft Schuhe unten durch das Seeufer. 3695 S: 3696 S: 3697 S: 3698 S: 3699 S: The Cobbler Shoppe 3700 S: 3701 S: 3702 S: 3703 S:
3704 S: 21 North Main Street 3705 S:
3706 S: 3707 S: Britt 3708 S: 3709 S: 3710 S: IA 3711 S: 3712 S: 3713 S: 50423 3714 S: 3715 S: 3716 S: US 3717 S: 3718 S: 3719 S: 3720 S: 515-843-3521 3721 S: 3722 S: 3723 S: 3726 S: 3727 S: It is illegal to use information from this service 3728 S: for the purposes of sending unsolicited bulk email. 3729 S: 3730 S: 3731 S: 3732 S: 3733 S: 3734 S: 3735 S: 3736 S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ 3737 S: c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn 3738 S: T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48 3739 S: Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8 3740 S: 3741 S: 3742 S: 3743 S: 3744 S: 3746 Figure 24: Example 3 3748 Appendix B. An Example Database Serialization 3750 The following is an example of serializing domain data. 3752 This example shows the serialization of a domain, a host, and a 3753 referral. 3755 3760 3764 example.com 3765 3769 3773 3777 3782 3783 IANA Administrator 3784 3785 3786 3788 3792 nsol184 3793 ns1.iana.org 3794 192.0.2.1 3795 3800 3801 IANA Techie 3802 3803 3804 3806 3807 3811 3814 3815 com 3816 3818 3819 3821 3823 Figure 25: dreg-serialization.xml 3825 Appendix C. Acknowledgements 3827 Many of the concepts concerning the use of SRV records for step-wise 3828 refinement towards finding authoritative servers and many of the 3829 details of result objects in this draft were originally created by 3830 Eric A. Hall in his memos regarding the use of LDAP to satisfy the 3831 CRISP requirements. These concepts have contributed significantly to 3832 the development of this protocol. 3834 David Blacka gave many technical contributions due to work on his 3835 IRIS implementation and experienced judgement. He also contributed 3836 many editorial clarifications. 3838 Authors' Addresses 3840 Andrew L. Newton 3841 VeriSign, Inc. 3842 21345 Ridgetop Circle 3843 Sterling, VA 20166 3844 USA 3846 Phone: +1 703 948 3382 3847 Email: andy@hxr.us 3848 URI: http://www.verisignlabs.com/ 3850 Frederico A. C. Neves 3851 NIC.br / Registro.br 3852 Av. das Na��es Unidas, 11541, 7 3853 S�o Paulo, SP 04578-000 3854 BR 3856 Phone: +55 11 5509 3511 3857 Email: fneves@registro.br 3858 URI: http://registro.br/ 3860 Intellectual Property Statement 3862 The IETF takes no position regarding the validity or scope of any 3863 Intellectual Property Rights or other rights that might be claimed to 3864 pertain to the implementation or use of the technology described in 3865 this document or the extent to which any license under such rights 3866 might or might not be available; nor does it represent that it has 3867 made any independent effort to identify any such rights. Information 3868 on the procedures with respect to rights in RFC documents can be 3869 found in BCP 78 and BCP 79. 3871 Copies of IPR disclosures made to the IETF Secretariat and any 3872 assurances of licenses to be made available, or the result of an 3873 attempt made to obtain a general license or permission for the use of 3874 such proprietary rights by implementers or users of this 3875 specification can be obtained from the IETF on-line IPR repository at 3876 http://www.ietf.org/ipr. 3878 The IETF invites any interested party to bring to its attention any 3879 copyrights, patents or patent applications, or other proprietary 3880 rights that may cover technology that may be required to implement 3881 this standard. Please address the information to the IETF at 3882 ietf-ipr@ietf.org. 3884 Disclaimer of Validity 3886 This document and the information contained herein are provided on an 3887 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3888 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3889 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3890 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3891 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3892 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3894 Copyright Statement 3896 Copyright (C) The Internet Society (2006). This document is subject 3897 to the rights, licenses and restrictions contained in BCP 78, and 3898 except as set forth therein, the authors retain all their rights. 3900 Acknowledgment 3902 Funding for the RFC Editor function is currently provided by the 3903 Internet Society.