idnits 2.17.1 draft-ietf-crisp-iris-dreg-07.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2288. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2304), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2004) is 7227 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: 9 errors (**), 0 flaws (~~), 5 warnings (==), 13 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: January 11, 2005 M. Sanz 5 DENIC eG 6 July 13, 2004 8 IRIS - A Domain Registry (dreg) Type for the Internet Registry 9 Information Service 10 draft-ietf-crisp-iris-dreg-07 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 11, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document describes an IRIS registry schema for registered DNS 44 information. The schema extends the necessary query and result 45 operations of IRIS to provide the functional information service 46 needs for syntaxes and results used by domain registries and 47 registrars. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 53 3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 5 55 3.1.1 Query . . . . . . . . . . . . . 5 56 3.1.2 Query . . . . . . . . . . . . . 5 57 3.1.3 Query . . . . . . . . . . . . . . 6 58 3.1.4 Query . . . . . . . . . . . . . . . 6 59 3.1.5 Query . . . . . . . . . . . . . . . . . 6 60 3.1.6 Query . . . . . . . . . . . . . . 7 61 3.1.7 Contact Search Group . . . . . . . . . . . . . . . . . 7 62 3.2 Result Derivatives . . . . . . . . . . . . . . . . . . . . 8 63 3.2.1 Privacy Labels . . . . . . . . . . . . . . . . . . . . 8 64 3.2.2 Result . . . . . . . . . . . . . . . . . . . 9 65 3.2.3 Result . . . . . . . . . . . . . . . . . . . . 11 66 3.2.4 Result . . . . . . . . . . . . . . . . . . . 12 67 3.2.5 . . . . . . . . . . . . . . . 13 68 3.3 Generic Code Derivatives . . . . . . . . . . . . . . . . . 14 69 3.3.1 . . . . . . . . . . . . . . . . . . . 14 70 3.3.2 . . . . . . . . . . . . . . . . 15 71 3.4 Support for . . . . . . . . . . . . . 15 72 4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 16 73 5. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 38 74 5.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . 38 75 5.2 Server Authentication . . . . . . . . . . . . . . . . . . 38 76 6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 39 77 6.1 Application Service Label . . . . . . . . . . . . . . . . 39 78 6.2 Bottom-Up Resolution . . . . . . . . . . . . . . . . . . . 39 79 6.3 Top-Down Resolution . . . . . . . . . . . . . . . . . . . 39 80 7. Internationalization Considerations . . . . . . . . . . . . . 41 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 82 8.1 XML Namespace URN Registration . . . . . . . . . . . . . . 42 83 8.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 42 84 8.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 42 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 43 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 87 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 44 88 10.2 Informative References . . . . . . . . . . . . . . . . . . . 45 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 90 A. Example Requests and Responses . . . . . . . . . . . . . . . . 47 91 A.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 47 92 A.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 48 93 A.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 49 94 B. An Example Database Serialization . . . . . . . . . . . . . . 53 95 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 96 Intellectual Property and Copyright Statements . . . . . . . . 56 98 1. Introduction 100 This document describes an IRIS registry schema for Internet domain 101 registries using an XML Schema [4] derived from and using the IRIS 102 [5] schema. The query and result types outlined in this document are 103 based on the functional requirements described in CRISP [17]. 105 The schema given is this document is specified using the Extensible 106 Markup Language (XML) 1.0 as described in XML [1], XML Schema 107 notation as described in XML_SD [3] and XML_SS [4], and XML 108 Namespaces as described in XML_NS [2]. 110 Examples of client/server XML exchanges with this registry type are 111 available in Appendix A. 113 2. Document Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC2119 [10]. 119 3. Schema Description 121 IRIS requires the derivation of both query and result elements by a 122 registry schemas. These descriptions follow. 124 References to XML elements with no namespace qualifier are from the 125 schema defined in Section 4. References to elements and attributes 126 with the "iris" XML namespace qualifier are from the schema defined 127 in IRIS [5]. 129 The descriptions contained within this section refer to XML elements 130 and attributes and their relation to the exchange of data within the 131 protocol. These descriptions also contain specifications outside the 132 scope of the formal XML syntax. Therefore, this section will use 133 terms defined by RFC 2119 [10] to describe the specification outside 134 the scope of the formal XML syntax. While reading this section, 135 please reference Section 4 for needed details on the formal XML 136 syntax. 138 3.1 Query Derivatives 140 3.1.1 Query 142 searches for a registration authority 143 designated as a registrar for the registry of the server. 145 If present, the element MUST restrict the results of the 146 search to only registrars capable of registering subdomains in the 147 domain signified by the content of this element. 149 The element restricts the scope of the query with its 150 child elements. The element specifies the beginning of 151 the registrar's name. The element specifies the end of 152 the registrar's name. The element specifies an 153 equivalence to the registrar's name. 155 If the element is not present, the query MUST return all 156 registrars applicable (i.e. in consideration of ). 158 This query MUST return a result set of zero or more 159 elements. See Section 3.2.5. 161 3.1.2 Query 163 finds domains by searches on fields associated 164 with a domain's contact. A search constraint of MUST 165 restrict the results to domains only underneath the domain specified 166 by its content if it is present. 168 The allowable search fields are handled with either the 169 element or one of the elements in the 170 "contactSearchGroup" (see Section 3.1.7). The 171 element allows for the domains to be selected based on the contact 172 having the specified contact handle. 174 The query MAY also be constrained further using the optional 175 element. The contents of this element signify the role the contact 176 has with the domain. 178 This query also provides optional elements containing 179 language tags. Clients MAY use these elements to give a hint about 180 the natural language(s) of the affected element. Servers MAY use 181 this information in processing the query, such as tailoring 182 normalization routines to aid in more effective searches. 184 3.1.3 Query 186 The query finds domains by the name of a domain 187 as it is known in DNS. The element restricts the scope of 188 the query with its child elements. The element 189 specifies the beginning of the domain name. The element 190 specifies the end of the domain name. 192 3.1.4 Query 194 This query differs from the query by allowing the 195 scope of the query to take into consideration internationalized 196 domain names. This query will return the union of the desired domain 197 and any associated variants, therefore differing from a lookup in the 198 "idn" entity class (Section 3.4) (which is to only return the domain 199 or no results). 201 The element restricts the scope of the query with its 202 child element. Its child, the element, is designed to 203 contain IDNs and not ACE labels, and thus MUST match only against 204 equivalent IDNs, according to the notion of equivalence defined in 205 RFC 3490 [14]. 207 This query also provides optional elements containing 208 language tags. Clients MAY use these elements to give a hint about 209 the natural language(s) of the affected element. Servers MAY use 210 this information in processing the query, such as tailoring 211 normalization routines to aid in more effective searches. 213 3.1.5 Query 215 searches for contacts given search constraints. 217 The allowable search fields are handled by one of the elements in the 218 "contactSearchGroup" (see Section 3.1.7). 220 This query also provides optional elements containing 221 language tags. Clients MAY use these elements to give a hint about 222 the natural language(s) of the affected element. Servers MAY use 223 this information in processing the query, such as tailoring 224 normalization routines to aid in more effective searches. 226 3.1.6 Query 228 This query does a simple search for the domains being hosted by a 229 name server. The search is constrained using either the host name 230 [12], host handle, IPv4 address, or IPv6 address of the name server. 232 3.1.7 Contact Search Group 234 Some of the queries above have similar query constraints for 235 searching on contacts. This section describes those common 236 parameters. 238 allows the query to be constrained based on the common 239 name of the contact. The constraint can either constrain the query 240 by an exact match using the element, or it may constrain 241 the query by a subset of the common name using the and 242 elements. 244 allows the query to be constrained based on the 245 organization name of the contact. It has the same semantics as the 246 element. 248 constrains the query based on the e-mail address of the 249 contact. This may be done by an exact e-mail address using the 250 element or by any e-mail address in a domain using the 251 element. The MUST only contain a valid domain 252 name (i.e. no '@' symbol), and the matching SHOULD take place only 253 on the domain given (i.e. no partial matches with respect to 254 substrings or parent domains). If either the contents of the 255 element or domain part of the contents of the 256 element contain a name with non-ASCII characters, they MUST be 257 normalized according to the processes of RFC 3491 [15]. 259 The , , and elements restrict the scope of 260 the query based on the city, region, or postal code of the contact, 261 respectively. Each one must only contain an element 262 containing the exact city, region, or postal code (i.e. no substring 263 searches). 265 3.2 Result Derivatives 267 3.2.1 Privacy Labels 269 Several of the results in this registry type have values that cannot 270 be given but must be specified as present or must be flagged so that 271 clients do not divulge them. In order to achieve this, some of the 272 results use the following element types: 273 o "dateTimePrivacyType" - contains the XML Schema [3] data type 274 "dateTime". The contents of this element MUST be specified using 275 the 'Z' indicator for Coordinated Universal Time (UTC). 276 o "stringPrivacyType" - contains the XML Schema [3] data type 277 "string". 278 o "normalizedStringPrivacyType" - contains the XML Schema [3] data 279 type "normalizedString". 280 o "tokenPrivacyType" - contains the XML Schema [3] data type 281 "token". 282 o "domainStatusType" - contains an optional element of 283 indicating the date and time the status was applied and an 284 optional element of with required attribute 285 'language' indicating a description of the status. This element 286 also has an optional attribute of 'scope' to indicate the scope or 287 origin of the status value. 288 o "contactTypeType" - contains an optional child 289 elements. Each child element requires a 'language' 290 attribute. 292 As specified, they are nillable and therefore may be present with 293 empty content or present with their specified content. The use of 294 these elements is also optional. 296 If present without content, each of these element types MUST have one 297 or more of the following boolean attributes: 298 o 'private' - if true, this specifies that the content is absent 299 because it may never be published. 300 o 'denied' - if true, this specifies that the content is absent 301 because policy does not allow it to be given under the current 302 level of access. 304 If present with content, each of these element types MAY have one or 305 more of the following boolean attributes: 306 o 'doNotRedistribute' - if true, this specifies that the content is 307 not to be redistributed. 308 o 'specialAccess' - if true, this specifies that the content has 309 been provided due to special access rights. 311 These boolean attributes SHOULD be used in accordance with the level 312 of access being granted the recepient of the data. For example, 313 marking data as 'private' or 'denied' is to be expected if the user 314 is anonymous or has some other low level of access that does not 315 warrant viewing of that particular data. Likewise, data marked with 316 'doNotRedistribute' or 'specialAccess' is to be expected if the user 317 is authenticated and has a high level of access. 319 3.2.2 Result 321 An example of a result: 323 326 example.com 327 tcs-com-1 328 332 336 342 346 347 349 The result represents an instance of a domain assignment. 350 The children of the element are as follows: 351 o - the full name of the domain as it is in DNS. The 352 contents of this element MUST be a domain name as specified by RFC 353 1035 [9]. 354 o - the name of the domain in nameprep form if applicable. 355 See RFC 3491 [15]. 356 o - a registry unique assigned identifier to a 357 domain. 358 o - MUST contain an entity reference to a referent of 359 type (Section 3.2.3). 361 o - an element containing an entity reference to the 362 registrant of this domain. The referent MUST be a 363 (Section 3.2.4) result. 364 o Domain contacts - the following elements contain an entity 365 reference with a relationship to the domain. The referent of each 366 MUST be a (Section 3.2.4). 367 * 368 * 369 * 370 * 371 * 372 * 373 * 374 * 375 o - may contain at least one of the following elements of 376 type 'domainStatusType' (see Section 3.2.1), but none of these 377 elements may appear more than once. 378 * - permanently inactive 379 * - normal state 380 * - registration assigned but delegation 381 inactive 382 * - dispute 383 * - database purge pending 384 * - change of authority pending 385 * - on hold by registry 386 * - on hold by registrar 387 o - contains an entity reference, the referent of 388 which MUST be a (Section 3.2.2). 389 o - an element containing an entity 390 reference, the referent of which MUST be a (Section 391 3.2.2). The intention of this element is to point to the 392 downstream registration reference. Therefore, if this is a result 393 given back by a domain registry, it should point to the domain in 394 the domain registrar or registrant service. 395 o - contains an entity reference specifying the domain 396 registry operator for this domain which MUST be a 397 (Section 3.2.5). This element has an 398 optional, boolean 'hosting' attribute. When the value of this 399 attribute is positive, it indicates that the registry is 400 responsible for authoratively answering DNS queries for this 401 domain. 402 o - contains an entity reference specifying the domain 403 registrar operator for this domain which MUST be a 404 (Section 3.2.5). This element has an 405 optional, boolean 'hosting' attribute. When the value of this 406 attribute is positive, it indicates that the registrar is 407 responsible for authoratively answering DNS queries for this 408 domain. 410 o - an element containing the date and 411 time of the initial delegation of this domain. 412 o - an element containing the date and time of 413 last renewal of this domain. 414 o - an element containing the date and time of 415 the expiration of this domain. 416 o - specifies the last time a 417 contact for the domain was added or removed. 418 o - an element containing an entity 419 reference. The referent MUST be a (Section 3.2.4) 420 responsible for the last addition or removal of a contact for this 421 domain. 422 o - an element containing the 423 date and time of the last time one of the nameservers was added or 424 removed for the delegation of this domain. 425 o - an element containing an entity 426 reference. The referent MUST be a (Section 3.2.4) 427 result and be responsible for the last addition or removal of a 428 nameserver for this domain. 429 o - an element containing the date and 430 time of the last time the data for this domain was verified by the 431 responsible registration authority. 432 o - an element containing an entity reference 433 specifying a referent that is indirectly associated with this 434 domain. 436 3.2.3 Result 438 An example of a result: 440 443 nsol184 444 a.iana-servers.net 445 192.0.2.43 446 450 452 The element represents an instance of a host registration. 453 The children of the element are as follows: 454 o - a registry unique assigned identifier for the host. 455 o - the fully qualified domain name of the host. The 456 contents of this element are a domain name and MUST conform to RFC 457 1035 [9]. 459 o - the content of which MUST conform to the a valid 460 IP version 4 host address as specified by RFC 791 [8]. 461 o - the content of which MUST conform to the a valid 462 IP version 6 host address as specified by RFC 3513 [7]. 463 o - an element containing an entity reference 464 specifying a contact associated with this host. The referent MUST 465 be (Section 3.2.4) results. 466 o - an element containing the date and time this 467 host was created. 468 o - an element containing the date and 469 time this host was last modified. 470 o - an element containing the date and 471 time this data for this host was last verified to be correct by 472 the appropriate registration authority. 473 o - an element containing an entity reference 474 specifying a referent that is indirectly associated with this 475 host. 477 3.2.4 Result 479 An example of a result: 481 484 dbarton 485 IANA Manager 486 Internet Assigned Numbers Authority 487 res-dom@iana.org 488 489
4676 Admiralty Way, Suite 330
490 Marina del Rey 491 CA 492 92092 493 US 494 495 310-823-9358 496 498 The element represents an instance of a contact 499 registration. The children of the element are as follows: 500 o - a registry unique assigned identifier for this 501 contact. 502 o - the name of the contact. 503 o - a specification of the language code to use to 504 localize the data in this result. 505 o - contains one of the following child elements: , 506 , , or . Each of these elements is a 507 "contactTypeType" as defined in Section 3.2.1. 508 o - an element containing the organization name of 509 the contact. 510 o - elements containing an e-mail address for this contact. 511 o - elements containing an e-mail address within an 512 internationalized domain name [14]. 513 o - elements containing a SIP address for this contact. 514 o - elements containing children representing a 515 postal address. has the following children: 516 *
- an element containing the street address for this 517 contact. 518 * - an element containing the city for this contact. 519 * - an element containing the national region for this 520 contact. 521 * - an element containing the postal code for this 522 contact. 523 * - an element containing the country for this contact. 524 This SHOULD be a 2-letter country code compliant with ISO 3166 525 [11]. 526 o - elements containing a voice phone number for this 527 contact. If it begins with a '+' (plus) character, it MUST be a 528 number defined by E164 [13]. The format number defined in E164 529 [13] is RECOMMENDED. 530 o - elements containing a facsimile phone number for this 531 contact. If it begins with a '+' (plus) character, it MUST be a 532 number defined by E164 [13]. The format number defined in E164 533 [13] is RECOMMENDED. 534 o - an element containing the date and time this 535 contact was created. 536 o - an element containing the date and 537 time this contact was last modified. 538 o - an element containing the date and 539 time this data for this contact was last verified to be correct by 540 the appropriate registration authority. 541 o - an element containing an entity reference 542 specifying equivalents of this contact that have been translated 543 into other languages. The referent MUST be (Section 544 3.2.4) results. 545 o - an element containing an entity reference 546 specifying a referent that is indirectly associated with this 547 contact. 549 3.2.5 551 An example of a result: 553 556 560 561 Internet Assigned Numbers Authority 562 563 564 566 The result represents an entity capable of 567 registering domains. 569 The child element of 570 contains an entity reference pointing to the entity "id" in the 571 entity class "iris". The authority areas found in the referent MUST 572 be domains for which a given registration authority has control. 574 The child element contains the name of the 575 registration authority. 577 The registration authority type child elements, , 578 , and , determine the role in which this 579 registration authority plays in the process of registering domains. 580 The intent of this element is to explain the various roles a 581 registration authority may have with regards to the authority areas 582 pointed to by the element. A client MAY understand 583 the relationship of a registration authority with respect to a domain 584 by the placement of the reference in the domain (e.g. or 585 ). 587 The child elements each contain one domain name signifying 588 the domains for which this registration authority may register 589 sub-domains. 591 3.3 Generic Code Derivatives 593 3.3.1 595 Servers MAY use the error code when a query must be 596 narrowed to yield a result set acceptable to the policies of the 597 server operator. 599 3.3.2 601 The queries , , and 602 support optional language tags that allow a client to 603 suggest to a server the languages in which to scope the queries. If 604 a client passes to the server a language which the server does not 605 support, the server MAY use this error code to indicate that one of 606 the languages is not supported. 608 This element contains child elements named . 609 Each of these child elements specify a language not supported by the 610 server. When a server returns this error, it MUST give the languages 611 from the query which are not supported. 613 3.4 Support for 615 The following types of entity classes are recognized by the 616 query of IRIS for this registry: 617 o host-name - the fully qualified domain name of a nameserver. 618 Yields a (Section 3.2.3) in the response. 619 o host-handle - the registry unique identifier given a nameserver. 620 Yields a (Section 3.2.3) in the response. 621 o domain-name - the fully qualified name of a domain. This a domain 622 name as specified by RFC 1035 [9]. Yields a (Section 623 3.2.2) in the response. 624 o idn - the fully qualified name of a domain in nameprep form (see 625 RFC 3491 [15]). Yields a (Section 3.2.2) in the 626 response. 627 o domain-handle - the registry unique identifier given a domain. 628 Yields a (Section 3.2.2) in the response. 629 o contact-handle - the registry unique identifier given a contact. 630 Yields a (Section 3.2.4) in the response. 631 o ipv4-address - the IPv4 address of a nameserver. Yields a 632 (Section 3.2.3) in the response. 633 o ipv6-address - the IPv6 address of a nameserver. Yields a 634 (Section 3.2.3) in the response. 635 o registration-authority - the name of a registration authority. 636 Yields a (Section 3.2.5) in the response. 637 o All names in these entity classes are case insensitive. 639 4. Formal XML Syntax 641 This registry schema is specified in the XML Schema notation. The 642 formal syntax presented here is a complete schema representation 643 suitable for automated validation of an XML instance when combined 644 with the formal schema syntax of IRIS. 646 647 653 655 656 657 Domain registry schema 658 derived from IRIS schema 659 660 662 663 664 665 666 668 669 670 672 674 675 677 678 682 687 688 689 690 692 697 698 699 701 703 704 706 707 711 712 714 717 718 722 723 725 727 729 731 733 735 737 739 741 743 744 745 746 751 752 753 754 756 761 762 763 765 767 768 770 771 774 775 776 777 779 784 785 786 788 790 791 793 794 797 802 803 804 805 807 812 813 814 816 818 819 821 822 824 829 831 832 833 835 840 841 842 844 846 847 849 850 854 855 858 861 864 867 868 869 870 871 873 878 879 880 882 884 885 888 891 894 897 900 903 904 906 908 909 911 913 914 916 918 920 922 924 925 928 929 931 933 934 936 939 940 942 946 948 949 950 952 953 955 957 958 959 960 963 964 966 968 969 970 971 972 974 975 977 979 980 981 982 983 985 987 988 991 992 994 995 996 997 998 1000 1001 1002 1004 1006 1007 1009 1010 1013 1018 1025 1030 1035 1040 1045 1050 1055 1060 1065 1070 1075 1081 1086 1090 1091 1092 1097 1102 1107 1112 1117 1122 1127 1132 1137 1138 1139 1140 1145 1150 1154 1155 1156 1158 1161 1162 1163 1164 1165 1169 1170 1171 1173 1176 1177 1178 1179 1180 1186 1192 1198 1204 1209 1215 1219 1220 1221 1222 1224 1229 1230 1231 1233 1235 1236 1238 1239 1245 1248 1253 1258 1263 1269 1275 1281 1285 1286 1287 1288 1290 1295 1296 1297 1299 1301 1302 1304 1305 1311 1317 1322 1326 1327 1328 1331 1334 1337 1340 1341 1342 1343 1349 1355 1362 1368 1372 1373 1374 1380 1386 1392 1398 1404 1405 1406 1407 1413 1419 1425 1431 1437 1442 1446 1447 1448 1449 1451 1456 1457 1458 1460 1462 1463 1465 1466 1469 1474 1477 1479 1480 1481 1483 1484 1485 1487 1488 1489 1490 1495 1496 1497 1498 1500 1505 1506 1507 1509 1511 1514 1517 1520 1523 1525 1527 1528 1530 1532 1533 1534 1536 1538 1539 1541 1543 1544 1545 1547 1549 1550 1552 1555 1556 1557 1559 1561 1562 1564 1566 1567 1568 1570 1572 1573 1578 1582 1583 1584 1586 1590 1591 1592 1593 1594 1595 1597 1600 1602 1604 1605 1609 1610 1611 1613 1617 1618 1619 1620 1621 1622 1624 1626 1627 1628 1629 1630 1632 1633 1634 1636 1641 1642 1643 1645 1647 1648 1650 1651 1656 1657 1658 1659 1661 1666 1668 Figure 5: dreg.xsd 1670 5. BEEP Transport Compliance 1672 IRIS allows several extensions of the core capabilities. This 1673 section outlines those extensions allowable by IRIS-BEEP [6]. 1675 5.1 Message Pattern 1677 This registry type uses the default message pattern as described in 1678 IRIS-BEEP [6]. 1680 5.2 Server Authentication 1682 This registry type only uses the basic TLS server authentication 1683 method as described in IRIS-BEEP [6]. 1685 6. URI Resolution 1687 6.1 Application Service Label 1689 The application service label associated with this registry type MUST 1690 be "DREG1". This is the abbreviated form of the URN for this 1691 registry type, urn:ietf:params:xml:ns:dreg1. 1693 6.2 Bottom-Up Resolution 1695 The bottom-up alternative resolution method MUST be identified as 1696 'bottom' in IRIS URI's. 1698 The process for this resolution method differs from the 1699 direct-resolution method if the authority is only a domain name (i.e. 1700 without the port number). The process for this condition is as 1701 follows: 1702 1. The IRIS [5] direct resolution process is tried on the domain 1703 name (e.g. "example.com" ). 1704 2. If the direct resolution process yields no server for which a 1705 connection can be made, then the leftmost label of the domain 1706 name is removed, and the first step is repeated again (e.g. 1707 "com" ). 1708 3. If all the labels of the domain name are removed and no server 1709 connections have been made, then the DNS is queried for the 1710 address records corresponding to the original domain name and the 1711 port used is the well-known port for the default protocol of 1712 IRIS. 1714 6.3 Top-Down Resolution 1716 The top-down alternative resolution method MUST be identified as 1717 'top' in IRIS URI's. 1719 The process for this resolution method differs from the 1720 direct-resolution method if the authority is only a domain name (i.e. 1721 without the port number). The process for this condition is as 1722 follows: 1723 1. The domain name is reduced to its rightmost label. This is 1724 always '.'. 1725 2. The IRIS [5] direct resolution process is tried on the domain 1726 name. 1727 3. If the direct resolution process yields no server for which a 1728 connection can be made, then the original label to the left of 1729 the rightmost label of the domain name is prepended, and the 1730 second step is repeated again (e.g. if "." then "com", if "com" 1731 then "example.com"). 1733 4. If all the labels of the original domain are present and no 1734 server connections have been made, then the DNS is queried for 1735 the address records corresponding to the original domain name and 1736 the port used is the well-known port for the default protocol of 1737 IRIS. 1739 7. Internationalization Considerations 1741 Implementers should be aware of considerations for 1742 internationalization in IRIS [5]. 1744 This document specifies the lookup of domain names, both the 1745 traditional ASCII form and the IDN form. In addition, the social 1746 data associated with contacts may also be non-ASCII, and could 1747 contain virtually any Unicode character. The element is 1748 provided in queries that have potential to traverse such data. 1749 Clients should use these elements to indicate to the server of the 1750 target languages desired, and servers should use these elements to 1751 better enable normalization and search processes (see [18]). 1753 Clients needing to localize the data tags in this protocol should 1754 take note that localization is only needed on the names of XML 1755 elements and attributes with the exception of elements containing 1756 date and time information. The schema for this registry has been 1757 designed so that clients need not interpret the content of elements 1758 or attributes for localization, other than those elements containing 1759 date and time information. 1761 Clients should also make use of the elements provided in 1762 many of the results. Results containing data that may be in Unicode 1763 are accompanied by these elements in order to aid better presentation 1764 of the data to the user. 1766 The "dateTimePrivacyType" element type contains the XML Schema [3] 1767 data type "dateTime". The contents of this element MUST be specified 1768 using the 'Z' indicator for Coordinated Universal Time (UTC). 1770 8. IANA Considerations 1772 8.1 XML Namespace URN Registration 1774 This document makes use of a proposed XML namespace and schema 1775 registry specified in XML_URN [16]. Accordingly, the following 1776 registration information is provided for the IANA: 1777 o URN/URI: 1778 * urn:ietf:params:xml:ns:dreg1 1779 o Contact: 1780 * Andrew Newton 1781 * Marcos Sanz 1782 o XML: 1783 * The XML Schema specified in Section 4 1785 8.2 S-NAPTR Registration 1787 The following S-NAPTR application service label will need to be 1788 registered with IANA according to the IANA considerations defined in 1789 IRIS [5]: 1790 DREG1 1792 8.3 BEEP Registration 1794 The following BEEP Profile URI is to be registeried with IANA, in 1795 addition to the registration provided in IRIS-BEEP [6]. 1797 http://iana.org/beep/iris1/dreg1 1799 9. Security Considerations 1801 This document lays out no new considerations for security precautions 1802 beyond that specified in IRIS [5]. 1804 10. References 1806 10.1 Normative References 1808 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1809 1.0", W3C XML, February 1998, 1810 . 1812 [2] World Wide Web Consortium, "Namespaces in XML", W3C XML 1813 Namespaces, January 1999, 1814 . 1816 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C 1817 XML Schema, October 2000, 1818 . 1820 [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C 1821 XML Schema, October 2000, 1822 . 1824 [5] Newton, A. and M. Sanz, "Internet Registry Information 1825 Service", draft-ietf-crisp-iris-core-05 (work in progress), 1826 January 2004. 1828 [6] Newton, A. and M. Sanz, "Internet Registry Information Service 1829 (IRIS) over Blocks Extensible Exchange Protocol (BEEP)", 1830 draft-ietf-crisp-iris-beep-05 (work in progress), January 2004. 1832 [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1833 Addressing Architecture", RFC 3513, April 2003. 1835 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1836 1981. 1838 [9] Mockapetris, P., "Domain names - implementation and 1839 specification", STD 13, RFC 1035, November 1987. 1841 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1842 Levels", RFC 2119, BCP 14, March 1997. 1844 [11] International Organization for Standardization, "Codes for the 1845 representation of names of countries, 3rd edition", ISO 1846 Standard 3166, August 1988. 1848 [12] Braden, R., "Requirements for Internet Hosts - Application and 1849 Support", STD 3, RFC 1123, October 1989. 1851 [13] International Telecommunications Union, "The International 1852 Public Telecommunication Numbering Plan", ITU-T Recommendation 1853 E.164, 1991. 1855 [14] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 1856 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 1858 [15] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 1859 for Internationalized Domain Names (IDN)", RFC 3491, March 1860 2003. 1862 [16] Mealling, M., "The IETF XML Registry", 1863 draft-mealling-iana-xmlns-registry-03 (work in progress), 1864 November 2001. 1866 10.2 Informative References 1868 [17] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 1869 Requirements", RFC 3707, February 2004. 1871 URIs 1873 [18] 1875 Authors' Addresses 1877 Andrew L. Newton 1878 VeriSign, Inc. 1879 21345 Ridgetop Circle 1880 Sterling, VA 20166 1881 USA 1883 Phone: +1 703 948 3382 1884 EMail: anewton@verisignlabs.com; andy@hxr.us 1885 URI: http://www.verisignlabs.com/ 1887 Marcos Sanz 1888 DENIC eG 1889 Wiesenhuettenplatz 26 1890 D-60329 Frankfurt 1891 Germany 1893 EMail: sanz@denic.de 1894 URI: http://www.denic.de/ 1896 Appendix A. Example Requests and Responses 1898 The examples in this section use the string "C:" to denote data sent 1899 by a client to a server and the string "S:" to denote data sent by a 1900 server to a client. 1902 A.1 Example 1 1904 The following is an example of an entity lookup in a dreg1 registry 1905 for the domain-name of 'example.com'. The response shows the ability 1906 to specify data as being withheld because it is private. 1908 C: 1909 C: 1911 C: 1912 C: 1913 C: 1914 C: 1918 C: 1919 C: 1920 C: 1921 C: 1923 S: 1924 S: 1926 S: 1927 S: 1928 S: 1929 S: 1930 S: 1933 S: 1934 S: example.com 1935 S: tcs-com-1 1936 S: 1937 S: 1940 S: 1941 S: 1944 S: 1945 S: 1948 S: 1949 S: 1950 S: 1951 S: 1952 S: 1953 S: 1956 S: 1957 S: 1958 S: 1959 S: 1962 S: 1963 S: 1964 S: 1965 S: 1966 S: 1967 S: 1969 Figure 6: Example 1 1971 A.2 Example 2 1973 The following is an example of an entity lookup in a dreg1 registry 1974 for the contact-handle of 'mak21'. The response shows the ability to 1975 specify data as being withheld because it is private. 1977 C: 1978 C: 1980 C: 1981 C: 1982 C: 1983 C: 1987 C: 1988 C: 1989 C: 1990 C: 1991 S: 1992 S: 1994 S: 1995 S: 1996 S: 1997 S: 1998 S: 2001 S: 2002 S: mak21 2003 S: 2004 S: 2005 S: Mark Kosters 2006 S: 2007 S: 2008 S: 2009 S: VeriSign, Inc. 2010 S: 2011 S: 2012 S: markk@verisignlabs.com 2013 S: 2014 S: 2015 S: 2016 S: 2017 S: 2018 S: 2019 S: 2020 S: 2021 S: 2023 Figure 7: Example 2 2025 A.3 Example 3 2027 The following is an example of a domain search based on a 2028 registrant's name beginning with the string 'The Cobbler Shoppe'. 2029 This example also shows the use of bags. 2031 C: 2032 C: 2034 C: 2035 C: 2036 C: 2037 C: 2039 C: com 2040 C: 2041 C: 2042 C: The Cobbler Shoppe 2043 C: 2044 C: 2045 C: registrant 2046 C: 2047 C: 2048 C: 2049 C: 2050 C: 2052 S: 2053 S: 2056 S: 2057 S: 2058 S: 2059 S: 2064 S: example.com 2065 S: 2069 S: 2073 S: 2077 S: 2078 S: Bill Eckels 2079 S: 2080 S: 2081 S: 2086 S: 2087 S: Mark Kosters 2088 S: 2089 S: 2090 S: 2091 S: 2092 S: 2093 S: 2094 S: 2099 S: 2103 S: 2104 S: 2105 S: 2106 S: 2111 S: beb140 2112 S: 2113 S: Bill Eckels 2114 S: 2115 S: en 2116 S: 2117 S: 2118 S: 2119 S: Bill sells shoes down by the sea shore. 2120 S: 2121 S: 2122 S: Rechnung verkauft Schuhe unten durch das Seeufer. 2123 S: 2124 S: 2125 S: 2126 S: 2127 S: The Cobbler Shoppe 2128 S: 2129 S: 2130 S: 2131 S:
2132 S: 21 North Main Street 2133 S:
2134 S: 2135 S: Britt 2136 S: 2137 S: 2138 S: IA 2139 S: 2140 S: 2141 S: 50423 2142 S: 2143 S: 2144 S: US 2145 S: 2146 S: 2147 S: 2148 S: 515-843-3521 2149 S: 2150 S: 2151 S: 2154 S: 2155 S: It is illegal to use information from this service 2156 S: for the purposes of sending unsolicited bulk email. 2157 S: 2158 S: 2159 S: 2160 S: 2161 S: 2162 S: 2163 S: 2164 S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ 2165 S: c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn 2166 S: T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48 2167 S: Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8= 2168 S: 2169 S: 2170 S: 2171 S: 2172 S: 2174 Figure 8: Example 3 2176 Appendix B. An Example Database Serialization 2178 The following is an example of serializing domain data. 2180 This example shows the serialization of a domain, a host, and a 2181 referral. 2183 2188 2192 example.com 2193 2197 2201 2205 2210 2211 IANA Administrator 2212 2213 2214 2216 2220 nsol184 2221 ns1.iana.org 2222 192.0.2.1 2223 2228 2229 IANA Techie 2230 2231 2232 2234 2235 2239 2242 2243 com 2244 2246 2247 2249 2251 Figure 9: dreg-serialization.xml 2253 Appendix C. Acknowledgements 2255 Many of the concepts concerning the use of SRV records for step-wise 2256 refinement towards finding authoritative servers and many of the 2257 details of result objects in this draft were originally created by 2258 Eric A. Hall in his memos regarding the use of LDAP to satisfy the 2259 CRISP requirements. These concepts have contributed significantly to 2260 the development of this protocol. 2262 David Blacka gave many technical contributions due to work on his 2263 IRIS implementation and experienced judgement. He also contributed 2264 many editorial clarifications. 2266 Intellectual Property Statement 2268 The IETF takes no position regarding the validity or scope of any 2269 Intellectual Property Rights or other rights that might be claimed to 2270 pertain to the implementation or use of the technology described in 2271 this document or the extent to which any license under such rights 2272 might or might not be available; nor does it represent that it has 2273 made any independent effort to identify any such rights. Information 2274 on the procedures with respect to rights in RFC documents can be 2275 found in BCP 78 and BCP 79. 2277 Copies of IPR disclosures made to the IETF Secretariat and any 2278 assurances of licenses to be made available, or the result of an 2279 attempt made to obtain a general license or permission for the use of 2280 such proprietary rights by implementers or users of this 2281 specification can be obtained from the IETF on-line IPR repository at 2282 http://www.ietf.org/ipr. 2284 The IETF invites any interested party to bring to its attention any 2285 copyrights, patents or patent applications, or other proprietary 2286 rights that may cover technology that may be required to implement 2287 this standard. Please address the information to the IETF at 2288 ietf-ipr@ietf.org. 2290 Disclaimer of Validity 2292 This document and the information contained herein are provided on an 2293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2295 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2296 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2297 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2300 Copyright Statement 2302 Copyright (C) The Internet Society (2004). This document is subject 2303 to the rights, licenses and restrictions contained in BCP 78, and 2304 except as set forth therein, the authors retain all their rights. 2306 Acknowledgment 2308 Funding for the RFC Editor function is currently provided by the 2309 Internet Society.