idnits 2.17.1 draft-ietf-crisp-iris-dchk-09.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (Nov 14, 2007) is 6008 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) ** Obsolete normative reference: RFC 3491 (ref. '3') (Obsoleted by RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 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 Intended status: Standards Track M. Sanz 5 Expires: May 17, 2008 DENIC eG 6 Nov 14, 2007 8 A Domain Availability Check (DCHK) Registry Type for the Internet 9 Registry Information Service (IRIS) 10 draft-ietf-crisp-iris-dchk-09 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 22 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 May 17, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a lightweight domain availability service 44 using the Internet Registry Information Service (IRIS) framework and 45 the data model of the IRIS Domain Registry (DREG) service. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 51 3. Domain Availability Check Registry . . . . . . . . . . . . . . 5 52 3.1. Schema Description . . . . . . . . . . . . . . . . . . . . 5 53 3.1.1. The Result . . . . . . . . . . . . . . . . . 5 54 3.1.2. Support for . . . . . . . . . . . 8 55 3.2. DCHK Formal XML Syntax . . . . . . . . . . . . . . . . . . 8 56 3.3. BEEP Transport Compliance . . . . . . . . . . . . . . . . 13 57 3.3.1. Message Pattern . . . . . . . . . . . . . . . . . . . 13 58 3.3.2. Server Authentication . . . . . . . . . . . . . . . . 13 59 3.4. URI Resolution . . . . . . . . . . . . . . . . . . . . . . 13 60 3.4.1. Application Service Label . . . . . . . . . . . . . . 14 61 3.4.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . 14 62 3.4.3. Top-Down Resolution . . . . . . . . . . . . . . . . . 14 63 4. Internationalization Considerations . . . . . . . . . . . . . 15 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 65 5.1. XML Namespace Registration . . . . . . . . . . . . . . . . 16 66 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 16 67 5.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 16 68 5.4. BEEP Registration . . . . . . . . . . . . . . . . . . . . 17 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 74 Intellectual Property and Copyright Statements . . . . . . . . . . 21 76 1. Introduction 78 This document describes a lightweight service for checking the 79 availability of domain names. This service is based on the IRIS 80 framework and uses the data model defined by RFC3982 [7]. By doing 81 this, the domain availability service has the advantages provided by 82 IRIS and DREG, such as well-known methods for server navigation, 83 structured queries and results, and layered extensibility. 85 The use of IRIS for this service also allows seamless integration 86 between the domain availability service and the service provided by 87 DREG. This allows a user to find the availability status of a domain 88 and reference the full registration information in DREG. 90 The data model in this service (called a registry schema in IRIS 91 terms) is a strict subset of the DREG data model. This enables 92 implementors to directly reuse DREG code paths and allows operators 93 to deploy the service in either the same server processes as a DREG 94 service (same host and port) or in a different server process 95 (different port) or machine (different host). 97 As an example, an operator may wish to deploy both types of service 98 on the same set of machines. As time goes on, the operator may then 99 decide to segregate the services, placing the domain availability 100 service on one set of machines and the DREG service on a separate set 101 of machines with a stricter set of controls. Either deployment 102 scenario is transparent to the end user and always appear to be 103 seamlessly complementary. 105 When coupled with [9], this domain availability service is 106 lightweight and extremely efficient for high-volume, public-facing 107 service. 109 2. Document Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC2119 [2]. 115 3. Domain Availability Check Registry 117 The data model used for the domain availability check (DCHK) service 118 is a strict subset of the DREG data model. This section describes 119 the DCHK registry type. 121 3.1. Schema Description 123 References to XML elements with no namespace qualifier are from the 124 schema defined in Section 3.2. References to elements and attributes 125 with the "iris" XML namespace qualifier are from the schema defined 126 in IRIS [6]. 128 The schema present in this document is tied to the protocol version 129 associated to the XML namespace URI defined in Section 5.2. 130 Extensions to the present DCHK schema are allowed -though not 131 recommended- but would require a new version. Please refer to 132 RFC3981 [6] for more details about versioning the IRIS protocol. 134 The descriptions contained within this section refer to XML elements 135 and attributes and their relation to the exchange of data within the 136 protocol. These descriptions also contain specifications outside the 137 scope of the formal XML syntax. Therefore, this section will use 138 terms defined by RFC 2119 [2] to describe the specification outside 139 the scope of the formal XML syntax. While reading this section, 140 please reference Section 3.2 for needed details on the formal XML 141 syntax. 143 3.1.1. The Result 145 An example of a result: 147 150 example.com 151 152 154 Example 156 The result represents an instance of a domain assignment. 157 The children of the element are as follows: 159 o - the full name of the domain as it is in DNS. The 160 contents of this element MUST be a domain name as specified by RFC 161 1035 [1]. 163 o - the name of the domain in nameprep form if applicable. 164 See RFC 3491 [3]. 166 o - this element contains child elements representing 167 domain status information. It defines the following status types: 169 * - available via DNS (either via delegation or direct 170 publication) 172 * - unavailable via DNS 174 * - registrant assignment is in dispute 176 * - renewal of domain registration 178 * - the domain is in the grace period after creation 179 or activation (see RFC 3915 [5]). 181 * - the domain is in the grace period after renewal 182 (see RFC 3915 [5]). 184 * - the domain is in the grace period after 185 automatic renewal (see RFC 3915 [5]). 187 * - the domain is in the grace period after 188 transfer (see RFC 3915 [5]). 190 * - the domain is in the grace period after 191 deletion (see RFC 3915 [5]). 193 * - change to previous status of this domain 195 * - the domain is considered compliant 196 according to a given policy specified by the substatus 197 identifier. 199 * - the domain is not considered compliant 200 according to a given policy specified by the substatus 201 identifier. 203 * - the domain is reserved and is not available for 204 registration under normal registration procedures. 206 * - specifies the creation status of the domain in the 207 registration system. 209 * - specifies the deletion status of the domain in the 210 registration system. 212 * - specifies the transfer status of the domain from 213 one responsible or owning entity in the registration system to 214 another. 216 * - specifies the status of the domain as it relates to 217 information in the domain being modified or having the ability 218 to be modified. 220 * - specifies a registration system specific status of 221 the domain. 223 o - an element containing an entity 224 reference, the referent of which MUST be either a 225 (Section 3.1.1) or a as defined by RFC3982 [7]. The 226 intent of this element is to point to the downstream registration 227 reference. Therefore, if this is a result given back by a domain 228 registry, it should point to the domain in the domain registrar or 229 registrant service. 231 o - an element containing the date and time of the 232 creation of this domain 234 o - an element containing the date and 235 time of the initial delegation of this domain. 237 o - an element containing the date and time of 238 the expiration of this domain 240 o - an element containing the date and 241 time of the last actualization of the database that is source for 242 this result 244 o - an element containing an entity reference 245 specifying a referent that is indirectly associated with this 246 domain. 248 3.1.1.1. Domain Status Type 250 Each element of type 'domainStatusType' has the following 251 composition: 253 o - an optional child element containing the date 254 applicable to creation of the status. 256 o - an optional child element containing a service ticket 257 identifier relevant to the status. 259 o - zero or more child elements with text to describe 260 the status in natural language. Each of these elements MUST have 261 a 'language' attribute describing the language of the description 262 element. 264 o - a child element indicating further status 265 information. Values for this element are not defined by this 266 specification. This child element has a required 'authority' 267 attribute to indicate the origin of the specification of the value 268 of this element. 270 o 'actor' - an optional attribute indicating the acting entity for 271 which this status is applied. The values may be "registry", 272 "registrar" or "registrationServiceProvider". 274 o 'disposition' - an optional attribute indicating the nature of 275 this status. The values may be "pending" or "prohibited". 277 o 'scope' - an optional attribute indicating the context or origin 278 of the status value. 280 3.1.2. Support for 282 The following types of entity classes are recognized by the 283 query of IRIS for this registry: 285 o domain-name - the fully qualified name of a domain. This a domain 286 name as specified by RFC 1035 [1]. Yields a 287 (Section 3.1.1) in the response. 289 o idn - the fully qualified name of a domain in nameprep form (see 290 RFC 3491 [3]). Yields a (Section 3.1.1) in the response. 292 3.2. DCHK Formal XML Syntax 294 This registry schema is specified in the XML Schema notation (see 295 [10] and [11]). The formal syntax presented here is a complete 296 schema representation suitable for automated validation of an XML 297 instance when combined with the formal schema syntax of IRIS. 299 300 305 307 308 309 Domain availability check schema 310 derived from IRIS schema 311 312 314 315 316 317 318 320 321 322 324 326 327 329 330 333 338 341 342 343 346 349 352 355 358 361 364 367 370 373 376 379 382 385 388 391 394 397 398 399 400 405 410 415 420 425 429 430 431 432 434 439 441 442 447 452 456 457 458 460 464 465 466 467 468 472 473 474 476 480 481 482 483 484 485 487 488 490 492 494 496 498 499 500 502 503 505 507 509 510 511 512 515 516 518 Figure 2: dchk.xsd 520 3.3. BEEP Transport Compliance 522 All DCHK client and servers MUST implement the Lightweight UDP 523 Transport Protocol (IRIS-LWZ) [9]. The use of other transports like 524 the XML Pipelining with Chunks (IRIS-XPC) transport [12] or the BEEP 525 transport [8] is optional and completely at the discretion of the 526 server operator. The XPC transport is in any case preferable to the 527 BEEP transport. 529 IRIS allows several extensions of the core capabilities. This 530 section outlines those extensions allowable by IRIS-BEEP [8]. 532 3.3.1. Message Pattern 534 This registry type uses the default message pattern as described in 535 IRIS-BEEP [8]. 537 3.3.2. Server Authentication 539 This registry type uses the default server authentication method as 540 described in IRIS-BEEP [8]. 542 3.4. URI Resolution 543 3.4.1. Application Service Label 545 The application service label associated with this registry type MUST 546 be "DCHK1". This is the abbreviated form of the URN for this 547 registry type, urn:ietf:params:xml:ns:dchk1. 549 3.4.2. Bottom-Up Resolution 551 The bottom-up alternative resolution method MUST be identified as 552 'bottom' in IRIS URI's. Its process is identical to the 'bottom' 553 process described by RFC3982 [7]. 555 3.4.3. Top-Down Resolution 557 The top-down alternative resolution method MUST be identified as 558 'top' in IRIS URI's. Its process is identical to the 'top' process 559 described by RFC3982 [7]. 561 4. Internationalization Considerations 563 Implementers should be aware of considerations for 564 internationalization in IRIS [6]. 566 Clients needing to localize the data tags in this protocol should 567 take note that localization is only needed on the names of XML 568 elements and attributes with the exception of elements containing 569 date and time information. The schema for this registry has been 570 designed so that clients need not interpret the content of elements 571 or attributes for localization, other than those elements containing 572 date and time information. 574 Clients should also make use of the elements provided in 575 many of the results. Results containing internationalized data can 576 be accompanied by these elements in order to aid better localization 577 of the data by the user 579 All date and time elements make use of the XML Schema [10] data type 580 "dateTime". If their contents are Coordinated Universal Time (UTC) 581 timestamps, they MUST be specified by using the capitalized 'Z' 582 indicator (instead of 'z'). 584 5. IANA Considerations 586 5.1. XML Namespace Registration 588 This document makes use of the XML registry specified in RFC 3688 589 [4]. Accordingly, the following registration information is provided 590 for the IANA: 592 o XML Namespace URN/URI: 594 * urn:ietf:params:xml:ns:dchk1 596 o Contact: 598 * Andrew Newton 600 * Marcos Sanz 602 o XML: 604 * None. 606 5.2. XML Schema Registration 608 This document makes use of the XML registry specified in RFC 3688 609 [4]. Accordingly, the following registration information is provided 610 for the IANA: 612 o XML Schema URN/URI: 614 * urn:ietf:params:xml:ns:dchk1 616 o Contact: 618 * Andrew Newton 620 * Marcos Sanz 622 o XML: 624 * The XML Schema specified in Section 3.2 626 5.3. S-NAPTR Registration 628 The following S-NAPTR application service label will need to be 629 registered with IANA according to the IANA considerations defined in 630 IRIS [6]: 632 DCHK1 634 5.4. BEEP Registration 636 The following BEEP Profile URI is to be registered with IANA, in 637 addition to the registration provided in IRIS-BEEP [8]. 639 http://iana.org/beep/iris1/dchk1 641 6. Security Considerations 643 Being a proper subset of RFC3982 [7], the registry described in this 644 document introduces no security considerations beyond those 645 documented in RFC3981 [6]. 647 7. References 649 7.1. Normative References 651 [1] Mockapetris, P., "Domain names - implementation and 652 specification", STD 13, RFC 1035, November 1987. 654 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 655 Levels", BCP 14, RFC 2119, March 1997. 657 [3] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 658 for Internationalized Domain Names (IDN)", RFC 3491, 659 March 2003. 661 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 662 January 2004. 664 [5] Hollenbeck, S., "Domain Registry Grace Period Mapping for the 665 Extensible Provisioning Protocol (EPP)", RFC 3915, 666 September 2004. 668 [6] Newton, A. and M. Sanz, "IRIS: The Internet Registry 669 Information Service (IRIS) Core Protocol", RFC 3981, 670 January 2005. 672 [7] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type 673 for the Internet Registry Information Service (IRIS)", 674 RFC 3982, January 2005. 676 [8] Newton, A. and M. Sanz, "Using the Internet Registry 677 Information Service (IRIS) over the Blocks Extensible Exchange 678 Protocol (BEEP)", RFC 3983, January 2005. 680 [9] Newton, A., "A Lightweight UDP Transfer Protocol for the 681 Internet Registry Information Service", RFC 4993, August 2007. 683 [10] World Wide Web Consortium, "XML Schema Part 2: Datatypes", 684 W3C XML Schema, October 2004, 685 . 687 [11] World Wide Web Consortium, "XML Schema Part 1: Structures", 688 W3C XML Schema, October 2004, 689 . 691 7.2. Informative References 693 [12] Newton, A., "XML Pipelining with Chunks for the Internet 694 Registry Information Service", RFC 4992, August 2007. 696 Authors' Addresses 698 Andrew L. Newton 699 VeriSign, Inc. 700 21345 Ridgetop Circle 701 Sterling, VA 20166 702 USA 704 Phone: +1 703 948 3382 705 Email: andy@hxr.us 706 URI: http://www.verisignlabs.com/ 708 Marcos Sanz 709 DENIC eG 710 Wiesenhuettenplatz 26 711 D-60329 Frankfurt 712 Germany 714 Email: sanz@denic.de 715 URI: http://www.denic.de/ 717 Full Copyright Statement 719 Copyright (C) The IETF Trust (2007). 721 This document is subject to the rights, licenses and restrictions 722 contained in BCP 78, and except as set forth therein, the authors 723 retain all their rights. 725 This document and the information contained herein are provided on an 726 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 727 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 728 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 729 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 730 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 731 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 733 Intellectual Property 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed to 737 pertain to the implementation or use of the technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; nor does it represent that it has 740 made any independent effort to identify any such rights. Information 741 on the procedures with respect to rights in RFC documents can be 742 found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use of 747 such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository at 749 http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at 755 ietf-ipr@ietf.org. 757 Acknowledgment 759 Funding for the RFC Editor function is provided by the IETF 760 Administrative Support Activity (IASA).