idnits 2.17.1 draft-ietf-crisp-iris-dreg-06.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 : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 15, 2004) is 7314 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 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 Expires: October 14, 2004 M. Sanz 5 DENIC eG 6 April 15, 2004 8 IRIS - A Domain Registry (dreg) Type for the Internet Registry 9 Information Service 10 draft-ietf-crisp-iris-dreg-06 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 14, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes an IRIS registry schema for registered DNS 41 information. The schema extends the necessary query and result 42 operations of IRIS to provide the functional information service 43 needs for syntaxes and results used by domain registries and 44 registrars. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 50 3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 5 52 3.1.1 Query . . . . . . . . . . . . . 5 53 3.1.2 Query . . . . . . . . . . . . . 5 54 3.1.3 Query . . . . . . . . . . . . . . 6 55 3.1.4 Query . . . . . . . . . . . . . . . 6 56 3.1.5 Query . . . . . . . . . . . . . . . . . 6 57 3.1.6 Query . . . . . . . . . . . . . . 7 58 3.1.7 Contact Search Group . . . . . . . . . . . . . . . . . 7 59 3.2 Result Derivatives . . . . . . . . . . . . . . . . . . . . 8 60 3.2.1 Privacy Labels . . . . . . . . . . . . . . . . . . . . 8 61 3.2.2 Result . . . . . . . . . . . . . . . . . . . 9 62 3.2.3 Result . . . . . . . . . . . . . . . . . . . . 11 63 3.2.4 Result . . . . . . . . . . . . . . . . . . . 12 64 3.2.5 . . . . . . . . . . . . . . . 13 65 3.3 Generic Code Derivatives . . . . . . . . . . . . . . . . . 14 66 3.3.1 . . . . . . . . . . . . . . . . . . . 14 67 3.3.2 . . . . . . . . . . . . . . . . 15 68 3.4 Support for . . . . . . . . . . . . . 15 69 4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 16 70 5. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 38 71 5.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . 38 72 5.2 Server Authentication . . . . . . . . . . . . . . . . . . 38 73 6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 39 74 6.1 Application Service Label . . . . . . . . . . . . . . . . 39 75 6.2 Bottom-Up Resolution . . . . . . . . . . . . . . . . . . . 39 76 6.3 Top-Down Resolution . . . . . . . . . . . . . . . . . . . 39 77 7. Internationalization Considerations . . . . . . . . . . . . . 41 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 79 8.1 XML Namespace URN Registration . . . . . . . . . . . . . . 42 80 8.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 42 81 8.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 42 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 43 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 84 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 44 85 10.2 Informative References . . . . . . . . . . . . . . . . . . . 45 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 87 A. Example Requests and Responses . . . . . . . . . . . . . . . . 47 88 A.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 47 89 A.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 48 90 A.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 49 91 B. An Example Database Serialization . . . . . . . . . . . . . . 53 92 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 93 Intellectual Property and Copyright Statements . . . . . . . . 56 95 1. Introduction 97 This document describes an IRIS registry schema for Internet domain 98 registries using an XML Schema [4] derived from and using the IRIS 99 [5] schema. The query and result types outlined in this document are 100 based on the functional requirements described in CRISP [17]. 102 The schema given is this document is specified using the Extensible 103 Markup Language (XML) 1.0 as described in XML [1], XML Schema 104 notation as described in XML_SD [3] and XML_SS [4], and XML 105 Namespaces as described in XML_NS [2]. 107 Examples of client/server XML exchanges with this registry type are 108 available in Appendix A. 110 2. Document Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [10]. 116 3. Schema Description 118 IRIS requires the derivation of both query and result elements by a 119 registry schemas. These descriptions follow. 121 References to XML elements with no namespace qualifier are from the 122 schema defined in Section 4. References to elements and attributes 123 with the "iris" XML namespace qualifier are from the schema defined 124 in IRIS [5]. 126 The descriptions contained within this section refer to XML elements 127 and attributes and their relation to the exchange of data within the 128 protocol. These descriptions also contain specifications outside the 129 scope of the formal XML syntax. Therefore, this section will use 130 terms defined by RFC 2119 [10] to describe the specification outside 131 the scope of the formal XML syntax. While reading this section, 132 please reference Section 4 for needed details on the formal XML 133 syntax. 135 3.1 Query Derivatives 137 3.1.1 Query 139 searches for a registration authority 140 designated as a registrar for the registry of the server. 142 If present, the element MUST restrict the results of the 143 search to only registrars capable of registering subdomains in the 144 domain signified by the content of this element. 146 The element restricts the scope of the query with its 147 child elements. The element specifies the beginning of 148 the registrar's name. The element specifies the end of the 149 registrar's name. The element specifies an equivalence 150 to the registrar's name. 152 If the element is not present, the query MUST return all 153 registrars applicable (i.e. in consideration of ). 155 This query MUST return a result set of zero or more 156 elements. See Section 3.2.5. 158 3.1.2 Query 160 finds domains by searches on fields associated 161 with a domain's contact. A search constraint of MUST 162 restrict the results to domains only underneath the domain specified 163 by its content if it is present. 165 The allowable search fields are handled with either the 166 element or one of the elements in the 167 "contactSearchGroup" (see Section 3.1.7). The element 168 allows for the domains to be selected based on the contact having the 169 specified contact handle. 171 The query MAY also be constrained further using the optional 172 element. The contents of this element signify the role the contact 173 has with the domain. 175 This query also provides optional elements containing 176 language tags. Clients MAY use these elements to give a hint about 177 the natural language(s) of the affected element. Servers MAY use this 178 information in processing the query, such as tailoring normalization 179 routines to aid in more effective searches. 181 3.1.3 Query 183 The query finds domains by the name of a domain 184 as it is known in DNS. The element restricts the scope of 185 the query with its child elements. The element specifies 186 the beginning of the domain name. The element specifies 187 the end of the domain name. 189 3.1.4 Query 191 This query differs from the query by allowing the 192 scope of the query to take into consideration internationalized 193 domain names. This query will return the union of the desired domain 194 and any associated variants, therefore differing from a lookup in the 195 "idn" entity class (Section 3.4) (which is to only return the domain 196 or no results). 198 The element restricts the scope of the query with its 199 child element. Its child, the element, is designed to 200 contain IDNs and not ACE labels, and thus MUST match only against 201 equivalent IDNs, according to the notion of equivalence defined in 202 RFC 3490 [14]. 204 This query also provides optional elements containing 205 language tags. Clients MAY use these elements to give a hint about 206 the natural language(s) of the affected element. Servers MAY use this 207 information in processing the query, such as tailoring normalization 208 routines to aid in more effective searches. 210 3.1.5 Query 212 searches for contacts given search constraints. 214 The allowable search fields are handled by one of the elements in the 215 "contactSearchGroup" (see Section 3.1.7). 217 This query also provides optional elements containing 218 language tags. Clients MAY use these elements to give a hint about 219 the natural language(s) of the affected element. Servers MAY use this 220 information in processing the query, such as tailoring normalization 221 routines to aid in more effective searches. 223 3.1.6 Query 225 This query does a simple search for the domains being hosted by a 226 name server. The search is constrained using either the host name 227 [12], host handle, IPv4 address, or IPv6 address of the name server. 229 3.1.7 Contact Search Group 231 Some of the queries above have similar query constraints for 232 searching on contacts. This section describes those common 233 parameters. 235 allows the query to be constrained based on the common 236 name of the contact. The constraint can either constrain the query by 237 an exact match using the element, or it may constrain 238 the query by a subset of the common name using the and 239 elements. 241 allows the query to be constrained based on the 242 organization name of the contact. It has the same semantics as the 243 element. 245 constrains the query based on the e-mail address of the 246 contact. This may be done by an exact e-mail address using the 247 element or by any e-mail address in a domain using the 248 element. The MUST only contain a valid domain 249 name (i.e. no '@' symbol), and the matching SHOULD take place only on 250 the domain given (i.e. no partial matches with respect to substrings 251 or parent domains). If either the contents of the element 252 or domain part of the contents of the element contain a 253 name with non-ASCII characters, they MUST be normalized according to 254 the processes of RFC 3491 [15]. 256 The , , and elements restrict the scope of 257 the query based on the city, region, or postal code of the contact, 258 respectively. Each one must only contain an element 259 containing the exact city, region, or postal code (i.e. no substring 260 searches). 262 3.2 Result Derivatives 264 3.2.1 Privacy Labels 266 Several of the results in this registry type have values that cannot 267 be given but must be specified as present or must be flagged so that 268 clients do not divulge them. In order to achieve this, some of the 269 results use the following element types: 270 o "dateTimePrivacyType" - contains the XML Schema [3] data type 271 "dateTime". The contents of this element MUST be specified using 272 the 'Z' indicator for Coordinated Universal Time (UTC). 273 o "stringPrivacyType" - contains the XML Schema [3] data type 274 "string". 275 o "normalizedStringPrivacyType" - contains the XML Schema [3] data 276 type "normalizedString". 277 o "tokenPrivacyType" - contains the XML Schema [3] data type 278 "token". 279 o "domainStatusType" - contains an optional element of 280 indicating the date and time the status was applied and an 281 optional element of with required attribute 282 'language' indicating a description of the status. This element 283 also has an optional attribute of 'scope' to indicate the scope or 284 origin of the status value. 285 o "contactTypeType" - contains an optional child 286 elements. Each child element requires a 'language' 287 attribute. 289 As specified, they are nillable and therefore may be present with 290 empty content or present with their specified content. And their 291 specified cardinality allows their absence. 293 Each of these element types MUST have one or more of the following 294 boolean attributes if they are present without content: 295 o 'private' - if true, this specifies that the content is absent 296 because it may never be published. 297 o 'denied' - if true, this specifies that the content is absent 298 because policy does not allow it to be given under the current 299 level of access. 301 Each of these element types MAY have one or more of the following 302 boolean attributes if they are present with content: 303 o 'doNotRedistribute' - if true, this specifies that the content is 304 not to be redistributed. 305 o 'specialAccess' - if true, this specifies that the content has 306 been provided due to special access rights. 308 3.2.2 Result 310 An example of a result: 312 315 example.com 316 tcs-com-1 317 321 325 331 335 336 338 The result represents an instance of a domain assignment. 339 The children of the element are as follows: 340 o - the full name of the domain as it is in DNS. The 341 contents of this element MUST be a domain name as specified by RFC 342 1035 [9]. 343 o - the name of the domain in nameprep form if applicable. See 344 RFC 3491 [15]. 345 o - a registry unique assigned identifier to a 346 domain. 347 o - MUST contain an entity reference to a referent of 348 type (Section 3.2.3). 349 o - an element containing an entity reference to the 350 registrant of this domain. The referent MUST be a 351 (Section 3.2.4) result. 352 o Domain contacts - the following elements contain an entity 353 reference with a relationship to the domain. The referent of each 354 MUST be a (Section 3.2.4). 356 * 357 * 358 * 359 * 360 * 361 * 362 * 363 * 364 o - may contain at least one of the following elements of 365 type 'domainStatusType' (see Section 3.2.1), but none of these 366 elements may appear more than once. 367 * - permanently inactive 368 * - normal state 369 * - registration assigned but delegation 370 inactive 371 * - dispute 372 * - database purge pending 373 * - change of authority pending 374 * - on hold by registry 375 * - on hold by registrar 376 o - contains an entity reference, the referent of 377 which MUST be a (Section 3.2.2). 378 o - an element containing an entity 379 reference, the referent of which MUST be a (Section 380 3.2.2). The intention of this element is to point to the 381 downstream registration reference. Therefore, if this is a result 382 given back by a domain registry, it should point to the domain in 383 the domain registrar or registrant service. 384 o - contains an entity reference specifying the domain 385 registry operator for this domain which MUST be a 386 (Section 3.2.5). This element has an 387 optional, boolean 'hosting' attribute. When the value of this 388 attribute is positive, it indicates that the registry is 389 responsible for authoratively answering DNS queries for this 390 domain. 391 o - contains an entity reference specifying the domain 392 registrar operator for this domain which MUST be a 393 (Section 3.2.5). This element has an 394 optional, boolean 'hosting' attribute. When the value of this 395 attribute is positive, it indicates that the registrar is 396 responsible for authoratively answering DNS queries for this 397 domain. 398 o - an element containing the date and 399 time of the initial delegation of this domain. 400 o - an element containing the date and time of 401 last renewal of this domain. 402 o - an element containing the date and time of 403 the expiration of this domain. 405 o - specifies the last time a 406 contact for the domain was added or removed. 407 o - an element containing an entity 408 reference. The referent MUST be a (Section 3.2.4) 409 responsible for the last addition or removal of a contact for this 410 domain. 411 o - an element containing the 412 date and time of the last time one of the nameservers was added or 413 removed for the delegation of this domain. 414 o - an element containing an entity 415 reference. The referent MUST be a (Section 3.2.4) result 416 and be responsible for the last addition or removal of a 417 nameserver for this domain. 418 o - an element containing the date and 419 time of the last time the data for this domain was verified by the 420 responsible registration authority. 421 o - an element containing an entity reference 422 specifying a referent that is indirectly associated with this 423 domain. 425 3.2.3 Result 427 An example of a result: 429 432 nsol184 433 a.iana-servers.net 434 192.0.34.43 435 439 441 The element represents an instance of a host registration. The 442 children of the element are as follows: 443 o - a registry unique assigned identifier for the host. 444 o - the fully qualified domain name of the host. The 445 contents of this element are a domain name and MUST conform to RFC 446 1035 [9]. 447 o - the content of which MUST conform to the a valid 448 IP version 4 host address as specified by RFC 791 [8]. 449 o - the content of which MUST conform to the a valid 450 IP version 6 host address as specified by RFC 3513 [7]. 451 o - an element containing an entity reference 452 specifying a contact associated with this host. The referent MUST 453 be (Section 3.2.4) results. 454 o - an element containing the date and time this 455 host was created. 456 o - an element containing the date and 457 time this host was last modified. 458 o - an element containing the date and 459 time this data for this host was last verified to be correct by 460 the appropriate registration authority. 461 o - an element containing an entity reference 462 specifying a referent that is indirectly associated with this 463 host. 465 3.2.4 Result 467 An example of a result: 469 472 dbarton 473 IANA Manager 474 Internet Assigned Numbers Authority 475 res-dom@iana.org 476 477
4676 Admiralty Way, Suite 330
478 Marina del Rey 479 CA 480 92092 481 US 482 483 310-823-9358 484 486 The element represents an instance of a contact 487 registration. The children of the element are as follows: 488 o - a registry unique assigned identifier for this 489 contact. 490 o - the name of the contact. 491 o - a specification of the language code to use to 492 localize the data in this result. 493 o - contains one of the following child elements: , 494 , , or . Each of these elements is a 495 "contactTypeType" as defined in Section 3.2.1. 496 o - an element containing the organization name of 497 the contact. 498 o - elements containing an e-mail address for this contact. 499 o - elements containing an e-mail address within an 500 internationalized domain name [14]. 502 o - elements containing a SIP address for this contact. 503 o - elements containing children representing a 504 postal address. has the following children: 505 *
- an element containing the street address for this 506 contact. 507 * - an element containing the city for this contact. 508 * - an element containing the national region for this 509 contact. 510 * - an element containing the postal code for this 511 contact. 512 * - an element containing the country for this contact. 513 This SHOULD be a 2-letter country code compliant with ISO 3166 514 [11]. 515 o - elements containing a voice phone number for this 516 contact. If it begins with a '+' (plus) character, it MUST be a 517 number defined by E164 [13]. The format number defined in E164 518 [13] is RECOMMENDED. 519 o - elements containing a facsimile phone number for this 520 contact. If it begins with a '+' (plus) character, it MUST be a 521 number defined by E164 [13]. The format number defined in E164 522 [13] is RECOMMENDED. 523 o - an element containing the date and time this 524 contact was created. 525 o - an element containing the date and 526 time this contact was last modified. 527 o - an element containing the date and 528 time this data for this contact was last verified to be correct by 529 the appropriate registration authority. 530 o - an element containing an entity reference 531 specifying equivalents of this contact that have been translated 532 into other languages. The referent MUST be (Section 533 3.2.4) results. 534 o - an element containing an entity reference 535 specifying a referent that is indirectly associated with this 536 contact. 538 3.2.5 540 An example of a result: 542 545 549 550 Internet Assigned Numbers Authority 551 552 553 555 The result represents an entity capable of 556 registering domains. 558 The child element of 559 contains an entity reference pointing to the entity "id" in the 560 entity class "iris". The authority areas found in the referent MUST 561 be domains for which a given registration authority has control. 563 The child element contains the name of the 564 registration authority. 566 The registration authority type child elements, , 567 , and , determine the role in which this 568 registration authority plays in the process of registering domains. 569 The intent of this element is to explain the various roles a 570 registration authority may have with regards to the authority areas 571 pointed to by the element. A client MAY understand 572 the relationship of a registration authority with respect to a domain 573 by the placement of the reference in the domain (e.g. or 574 ). 576 The child elements each contain one domain name signifying 577 the domains for which this registration authority may register 578 sub-domains. 580 3.3 Generic Code Derivatives 582 3.3.1 584 Servers MAY use the error code when a query must be 585 narrowed to yield a result set acceptable to the policies of the 586 server operator. 588 3.3.2 590 The queries , , and 591 support optional language tags that allow a client to 592 suggest to a server the languages in which to scope the queries. If a 593 client passes to the server a language which the server does not 594 support, the server MAY use this error code to indicate that one of 595 the languages is not supported. 597 This element contains child elements named . 598 Each of these child elements specify a language not supported by the 599 server. When a server returns this error, it MUST give the languages 600 from the query which are not supported. 602 3.4 Support for 604 The following types of entity classes are recognized by the 605 query of IRIS for this registry: 606 o host-name - the fully qualified domain name of a nameserver. 607 Yields a (Section 3.2.3) in the response. 608 o host-handle - the registry unique identifier given a nameserver. 609 Yields a (Section 3.2.3) in the response. 610 o domain-name - the fully qualified name of a domain. This a domain 611 name as specified by RFC 1035 [9]. Yields a (Section 612 3.2.2) in the response. 613 o idn - the fully qualified name of a domain in nameprep form (see 614 RFC 3491 [15]). Yields a (Section 3.2.2) in the response. 615 o domain-handle - the registry unique identifier given a domain. 616 Yields a (Section 3.2.2) in the response. 617 o contact-handle - the registry unique identifier given a contact. 618 Yields a (Section 3.2.4) in the response. 619 o ipv4-address - the IPv4 address of a nameserver. Yields a 620 (Section 3.2.3) in the response. 621 o ipv6-address - the IPv6 address of a nameserver. Yields a 622 (Section 3.2.3) in the response. 623 o registration-authority - the name of a registration authority. 624 Yields a (Section 3.2.5) in the response. 625 o All names in these entity classes are case insensitive. 627 4. Formal XML Syntax 629 This registry schema is specified in the XML Schema notation. The 630 formal syntax presented here is a complete schema representation 631 suitable for automated validation of an XML instance when combined 632 with the formal schema syntax of IRIS. 634 635 641 643 644 645 Domain registry schema 646 derived from IRIS schema 647 648 650 651 652 653 654 656 657 658 660 662 663 665 666 670 675 676 677 678 680 685 686 687 689 691 692 694 695 699 700 702 705 706 710 711 713 715 717 719 721 723 725 727 729 731 732 733 734 739 740 741 742 744 749 750 751 753 755 756 758 759 762 763 764 765 767 772 773 774 776 778 779 781 782 785 790 791 792 793 795 800 801 802 804 806 807 809 810 812 817 819 820 821 823 828 829 830 832 834 835 837 838 842 843 846 849 852 855 856 857 858 859 861 866 867 868 870 872 873 876 879 882 885 888 891 892 894 896 897 899 901 902 904 906 908 910 912 913 916 917 919 921 922 924 927 928 930 934 936 937 938 940 941 943 945 946 947 948 951 952 954 956 957 958 959 960 962 963 965 967 968 969 970 971 973 975 976 979 980 982 983 984 985 986 988 989 990 992 994 995 997 998 1001 1006 1013 1018 1023 1028 1033 1038 1043 1048 1053 1058 1063 1069 1074 1078 1079 1080 1085 1090 1095 1100 1105 1110 1115 1120 1125 1126 1127 1128 1133 1138 1142 1143 1144 1146 1149 1150 1151 1152 1153 1157 1158 1159 1161 1164 1165 1166 1167 1168 1174 1180 1186 1192 1197 1203 1207 1208 1209 1210 1212 1217 1218 1219 1221 1223 1224 1226 1227 1233 1236 1241 1246 1251 1257 1263 1269 1273 1274 1275 1276 1278 1283 1284 1285 1287 1289 1290 1292 1293 1299 1305 1310 1314 1315 1316 1319 1322 1325 1328 1329 1330 1331 1337 1343 1350 1356 1360 1361 1362 1368 1374 1380 1386 1392 1393 1394 1395 1401 1407 1413 1419 1425 1430 1434 1435 1436 1437 1439 1444 1445 1446 1448 1450 1451 1453 1454 1457 1462 1465 1467 1468 1469 1471 1472 1473 1475 1476 1477 1478 1483 1484 1485 1486 1488 1493 1494 1495 1497 1499 1502 1505 1508 1511 1513 1515 1516 1518 1520 1521 1522 1524 1526 1527 1529 1531 1532 1533 1535 1537 1538 1540 1543 1544 1545 1547 1549 1550 1552 1554 1555 1556 1558 1560 1561 1566 1570 1571 1572 1574 1578 1579 1580 1581 1582 1583 1585 1588 1590 1592 1593 1597 1598 1599 1601 1605 1606 1607 1608 1609 1610 1612 1614 1615 1616 1617 1618 1620 1621 1622 1624 1629 1630 1631 1633 1635 1636 1638 1639 1644 1645 1646 1647 1649 1654 1656 Figure 5: dreg.xsd 1658 5. BEEP Transport Compliance 1660 IRIS allows several extensions of the core capabilities. This section 1661 outlines those extensions allowable by IRIS-BEEP [6]. 1663 5.1 Message Pattern 1665 This registry type uses the default message pattern as described in 1666 IRIS-BEEP [6]. 1668 5.2 Server Authentication 1670 This registry type uses the default server authentication method as 1671 described in IRIS-BEEP [6]. 1673 6. URI Resolution 1675 6.1 Application Service Label 1677 The application service label associated with this registry type MUST 1678 be "DREG1". This is the abbreviated form of the URN for this registry 1679 type, urn:ietf:params:xml:ns:dreg1. 1681 6.2 Bottom-Up Resolution 1683 The bottom-up alternative resolution method MUST be identified as 1684 'bottom' in IRIS URI's. 1686 The process for this resolution method differs from the 1687 direct-resolution method if the authority is only a domain name (i.e. 1688 without the port number). The process for this condition is as 1689 follows: 1690 1. The IRIS [5] direct resolution process is tried on the domain 1691 name (e.g. "example.com" ). 1692 2. If the direct resolution process yields no server for which a 1693 connection can be made, then the leftmost label of the domain 1694 name is removed, and the first step is repeated again (e.g. "com" 1695 ). 1696 3. If all the labels of the domain name are removed and no server 1697 connections have been made, then the DNS is queried for the 1698 address records corresponding to the original domain name and the 1699 port used is the well-known port for the default protocol of 1700 IRIS. 1702 6.3 Top-Down Resolution 1704 The top-down alternative resolution method MUST be identified as 1705 'top' in IRIS URI's. 1707 The process for this resolution method differs from the 1708 direct-resolution method if the authority is only a domain name (i.e. 1709 without the port number). The process for this condition is as 1710 follows: 1711 1. The domain name is reduced to its rightmost label. This is always 1712 '.'. 1713 2. The IRIS [5] direct resolution process is tried on the domain 1714 name. 1715 3. If the direct resolution process yields no server for which a 1716 connection can be made, then the original label to the left of 1717 the rightmost label of the domain name is prepended, and the 1718 second step is repeated again (e.g. if "." then "com", if "com" 1719 then "example.com"). 1721 4. If all the labels of the original domain are present and no 1722 server connections have been made, then the DNS is queried for 1723 the address records corresponding to the original domain name and 1724 the port used is the well-known port for the default protocol of 1725 IRIS. 1727 7. Internationalization Considerations 1729 Implementers should be aware of considerations for 1730 internationalization in IRIS [5]. 1732 This document specifies the lookup of domain names, both the 1733 traditional ASCII form and the IDN form. In addition, the social data 1734 associated with contacts may also be non-ASCII, and could contain 1735 virtually any Unicode character. The element is provided 1736 in queries that have potential to traverse such data. Clients should 1737 use these elements to indicate to the server of the target languages 1738 desired, and servers should use these elements to better enable 1739 normalization and search processes (see [18]). 1741 Clients needing to localize the data tags in this protocol should 1742 take note that localization is only needed on the names of XML 1743 elements and attributes with the exception of elements containing 1744 date and time information. The schema for this registry has been 1745 designed so that clients need not interpret the content of elements 1746 or attributes for localization, other than those elements containing 1747 date and time information. 1749 Clients should also make use of the elements provided in 1750 many of the results. Results containing data that may be in Unicode 1751 are accompanied by these elements in order to aid better presentation 1752 of the data to the user. 1754 The "dateTimePrivacyType" element type contains the XML Schema [3] 1755 data type "dateTime". The contents of this element MUST be specified 1756 using the 'Z' indicator for Coordinated Universal Time (UTC). 1758 8. IANA Considerations 1760 8.1 XML Namespace URN Registration 1762 This document makes use of a proposed XML namespace and schema 1763 registry specified in XML_URN [16]. Accordingly, the following 1764 registration information is provided for the IANA: 1765 o URN/URI: 1766 * urn:ietf:params:xml:ns:dreg1 1767 o Contact: 1768 * Andrew Newton 1769 * Marcos Sanz 1770 o XML: 1771 * The XML Schema specified in Section 4 1773 8.2 S-NAPTR Registration 1775 The following S-NAPTR application service label will need to be 1776 registered with IANA according to the IANA considerations defined in 1777 IRIS [5]: 1778 DREG1 1780 8.3 BEEP Registration 1782 The following BEEP Profile URI is to be registeried with IANA, in 1783 addition to the registration provided in IRIS-BEEP [6]. 1785 http://iana.org/beep/iris1/dreg1 1787 9. Security Considerations 1789 This document lays out no new considerations for security precautions 1790 beyond that specified in IRIS [5]. 1792 10. References 1794 10.1 Normative References 1796 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1797 1.0", W3C XML, February 1998, . 1800 [2] World Wide Web Consortium, "Namespaces in XML", W3C XML 1801 Namespaces, January 1999, . 1804 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C 1805 XML Schema, October 2000, . 1808 [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C 1809 XML Schema, October 2000, . 1812 [5] Newton, A. and M. Sanz, "Internet Registry Information 1813 Service", draft-ietf-crisp-iris-core-05 (work in progress), 1814 January 2004. 1816 [6] Newton, A. and M. Sanz, "Internet Registry Information Service 1817 (IRIS) over Blocks Extensible Exchange Protocol (BEEP)", 1818 draft-ietf-crisp-iris-beep-05 (work in progress), January 2004. 1820 [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1821 Addressing Architecture", RFC 3513, April 2003. 1823 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1824 1981. 1826 [9] Mockapetris, P., "Domain names - implementation and 1827 specification", STD 13, RFC 1035, November 1987. 1829 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1830 Levels", RFC 2119, BCP 14, March 1997. 1832 [11] International Organization for Standardization, "Codes for the 1833 representation of names of countries, 3rd edition", ISO 1834 Standard 3166, August 1988. 1836 [12] Braden, R., "Requirements for Internet Hosts - Application and 1837 Support", STD 3, RFC 1123, October 1989. 1839 [13] International Telecommunications Union, "The International 1840 Public Telecommunication Numbering Plan", ITU-T Recommendation 1841 E.164, 1991. 1843 [14] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 1844 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 1846 [15] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 1847 for Internationalized Domain Names (IDN)", RFC 3491, March 1848 2003. 1850 [16] Mealling, M., "The IETF XML Registry", 1851 draft-mealling-iana-xmlns-registry-03 (work in progress), 1852 November 2001. 1854 10.2 Informative References 1856 [17] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 1857 Requirements", RFC 3707, February 2004. 1859 URIs 1861 [18] 1863 Authors' Addresses 1865 Andrew L. Newton 1866 VeriSign, Inc. 1867 21345 Ridgetop Circle 1868 Sterling, VA 20166 1869 USA 1871 Phone: +1 703 948 3382 1872 EMail: anewton@verisignlabs.com; andy@hxr.us 1873 URI: http://www.verisignlabs.com/ 1875 Marcos Sanz 1876 DENIC eG 1877 Wiesenhuettenplatz 26 1878 D-60329 Frankfurt 1879 Germany 1881 EMail: sanz@denic.de 1882 URI: http://www.denic.de/ 1884 Appendix A. Example Requests and Responses 1886 The examples in this section use the string "C:" to denote data sent 1887 by a client to a server and the string "S:" to denote data sent by a 1888 server to a client. 1890 A.1 Example 1 1892 The following is an example of an entity lookup in a dreg1 registry 1893 for the domain-name of 'example.com'. The response shows the ability 1894 to specify data as being withheld because it is private. 1896 C: 1897 C: 1899 C: 1900 C: 1901 C: 1902 C: 1906 C: 1907 C: 1908 C: 1909 C: 1911 S: 1912 S: 1914 S: 1915 S: 1916 S: 1917 S: 1918 S: 1921 S: 1922 S: example.com 1923 S: tcs-com-1 1924 S: 1925 S: 1928 S: 1929 S: 1932 S: 1933 S: 1936 S: 1937 S: 1938 S: 1939 S: 1940 S: 1941 S: 1944 S: 1945 S: 1946 S: 1947 S: 1950 S: 1951 S: 1952 S: 1953 S: 1954 S: 1955 S: 1957 Figure 6: Example 1 1959 A.2 Example 2 1961 The following is an example of an entity lookup in a dreg1 registry 1962 for the contact-handle of 'mak21'. The response shows the ability to 1963 specify data as being withheld because it is private. 1965 C: 1966 C: 1968 C: 1969 C: 1970 C: 1971 C: 1975 C: 1976 C: 1977 C: 1978 C: 1979 S: 1980 S: 1982 S: 1983 S: 1984 S: 1985 S: 1986 S: 1989 S: 1990 S: mak21 1991 S: 1992 S: 1993 S: Mark Kosters 1994 S: 1995 S: 1996 S: 1997 S: VeriSign, Inc. 1998 S: 1999 S: 2000 S: markk@verisignlabs.com 2001 S: 2002 S: 2003 S: 2004 S: 2005 S: 2006 S: 2007 S: 2008 S: 2009 S: 2011 Figure 7: Example 2 2013 A.3 Example 3 2015 The following is an example of a domain search based on a 2016 registrant's name beginning with the string 'The Cobbler Shoppe'. 2017 This example also shows the use of bags. 2019 C: 2020 C: 2022 C: 2023 C: 2024 C: 2025 C: 2027 C: com 2028 C: 2029 C: 2030 C: The Cobbler Shoppe 2031 C: 2032 C: 2033 C: registrant 2034 C: 2035 C: 2036 C: 2037 C: 2038 C: 2040 S: 2041 S: 2044 S: 2045 S: 2046 S: 2047 S: 2052 S: thecobblershoppe.com 2053 S: 2057 S: 2061 S: 2065 S: 2066 S: Bill Eckels 2067 S: 2068 S: 2069 S: 2074 S: 2075 S: Mark Kosters 2076 S: 2077 S: 2078 S: 2079 S: 2080 S: 2081 S: 2082 S: 2087 S: 2091 S: 2092 S: 2093 S: 2094 S: 2099 S: beb140 2100 S: 2101 S: Bill Eckels 2102 S: 2103 S: en 2104 S: 2105 S: 2106 S: 2107 S: Bill sells shoes down by the sea shore. 2108 S: 2109 S: 2110 S: Rechnung verkauft Schuhe unten durch das Seeufer. 2111 S: 2112 S: 2113 S: 2114 S: 2115 S: The Cobbler Shoppe 2116 S: 2117 S: 2118 S: 2119 S:
2120 S: 21 North Main Street 2121 S:
2122 S: 2123 S: Britt 2124 S: 2125 S: 2126 S: IA 2127 S: 2128 S: 2129 S: 50423 2130 S: 2131 S: 2132 S: US 2133 S: 2134 S: 2135 S: 2136 S: 515-843-3521 2137 S: 2138 S: 2139 S: 2142 S: 2143 S: It is illegal to use information from this service 2144 S: for the purposes of sending unsolicited bulk email. 2145 S: 2146 S: 2147 S: 2148 S: 2149 S: 2150 S: 2151 S: 2152 S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ 2153 S: c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn 2154 S: T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48 2155 S: Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8= 2156 S: 2157 S: 2158 S: 2159 S: 2160 S: 2162 Figure 8: Example 3 2164 Appendix B. An Example Database Serialization 2166 The following is an example of serializing domain data. 2168 This example shows the serialization of a domain, a host, and a 2169 referral. 2171 2176 2180 example.com 2181 2185 2189 2193 2198 2199 IANA Administrator 2200 2201 2202 2204 2208 nsol184 2209 ns1.iana.org 2210 10.0.0.1 2211 2216 2217 IANA Techie 2218 2219 2220 2222 2223 2227 2230 2231 com 2232 2234 2235 2237 2239 Figure 9: dreg-serialization.xml 2241 Appendix C. Acknowledgements 2243 Many of the concepts concerning the use of SRV records for step-wise 2244 refinement towards finding authoritative servers and many of the 2245 details of result objects in this draft were originally created by 2246 Eric A. Hall in his memos regarding the use of LDAP to satisfy the 2247 CRISP requirements. These concepts have contributed significantly to 2248 the development of this protocol. 2250 David Blacka gave many technical contributions due to work on his 2251 IRIS implementation and experienced judgement. He also contributed 2252 many editorial clarifications. 2254 Intellectual Property Statement 2256 The IETF takes no position regarding the validity or scope of any 2257 intellectual property or other rights that might be claimed to 2258 pertain to the implementation or use of the technology described in 2259 this document or the extent to which any license under such rights 2260 might or might not be available; neither does it represent that it 2261 has made any effort to identify any such rights. Information on the 2262 IETF's procedures with respect to rights in standards-track and 2263 standards-related documentation can be found in BCP-11. Copies of 2264 claims of rights made available for publication and any assurances of 2265 licenses to be made available, or the result of an attempt made to 2266 obtain a general license or permission for the use of such 2267 proprietary rights by implementors or users of this specification can 2268 be obtained from the IETF Secretariat. 2270 The IETF invites any interested party to bring to its attention any 2271 copyrights, patents or patent applications, or other proprietary 2272 rights which may cover technology that may be required to practice 2273 this standard. Please address the information to the IETF Executive 2274 Director. 2276 Full Copyright Statement 2278 Copyright (C) The Internet Society (2004). All Rights Reserved. 2280 This document and translations of it may be copied and furnished to 2281 others, and derivative works that comment on or otherwise explain it 2282 or assist in its implementation may be prepared, copied, published 2283 and distributed, in whole or in part, without restriction of any 2284 kind, provided that the above copyright notice and this paragraph are 2285 included on all such copies and derivative works. However, this 2286 document itself may not be modified in any way, such as by removing 2287 the copyright notice or references to the Internet Society or other 2288 Internet organizations, except as needed for the purpose of 2289 developing Internet standards in which case the procedures for 2290 copyrights defined in the Internet Standards process must be 2291 followed, or as required to translate it into languages other than 2292 English. 2294 The limited permissions granted above are perpetual and will not be 2295 revoked by the Internet Society or its successors or assignees. 2297 This document and the information contained herein is provided on an 2298 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2299 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2300 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2301 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2302 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2304 Acknowledgment 2306 Funding for the RFC Editor function is currently provided by the 2307 Internet Society.