Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: May 5, 2003 November 04, 2002 IRIS Domain Registry Schema draft-ietf-crisp-iris-dreg-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes an IRIS (draft-ietf-crisp-iris-core-01.txt ) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. Newton Expires May 5, 2003 [Page 1] Internet-Draft iris-dreg November 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 3. Schema Description . . . . . . . . . . . . . . . . . . . . . 5 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Query . . . . . . . . . . . . . . . . . . . 5 3.1.2 Query . . . . . . . . . . . . . . 5 3.1.3 Query . . . . . . . . . . . . . . . . . 5 3.1.4 Query . . . . . . . . . . . . . . . . . . . . 6 3.1.5 Query . . . . . . . . . . . . . . . . . 6 3.2 Result Derivatives . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 Result . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 Result . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3 Result . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4 . . . . . . . . . . . . . . . . . . 10 3.3 Generic Code Derivatives . . . . . . . . . . . . . . . . . . 11 3.4 Support for . . . . . . . . . . . . . . 11 4. Domain Registry Width . . . . . . . . . . . . . . . . . . . 12 4.1 "Thick" . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 "Thin" . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 14 6. BEEP Transport Compliance . . . . . . . . . . . . . . . . . 25 6.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . . 25 6.2 Authority Resolution . . . . . . . . . . . . . . . . . . . . 25 6.3 Server Authentication . . . . . . . . . . . . . . . . . . . 25 7. Internationalization Considerations . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . 28 References . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . 30 A. An Example Request and Response . . . . . . . . . . . . . . 31 B. An Example Database Serialization . . . . . . . . . . . . . 34 Full Copyright Statement . . . . . . . . . . . . . . . . . . 37 Newton Expires May 5, 2003 [Page 2] Internet-Draft iris-dreg November 2002 1. Introduction This document describes an IRIS registry schema for Internet domain registries using an XML Schema [4] derived from and using the IRIS [5] schema. The query and result types outlined in this document are based on the functional requirements described in CRISP [11]. The schema given is this document is specified using the Extensible Markup Language (XML) 1.0 as described in XML [1], XML Schema notation as described in XML_SD [3] and XML_SS [4], and XML Namespaces as described in XML_NS [2]. Newton Expires May 5, 2003 [Page 3] Internet-Draft iris-dreg November 2002 2. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [13]. Newton Expires May 5, 2003 [Page 4] Internet-Draft iris-dreg November 2002 3. Schema Description IRIS requires the derivation of both query and result elements by a registry schemas. These descriptions follow. References to XML elements with no namespace qualifier are from the schema defined in Section 5. References to elements with the "iris" XML namespace qualifier are from the schema defined in IRIS [5]. The descriptions contained within this section refer to XML elements and attributes and their relation to the exchange of data within the protocol. These descriptions also contain specifications outside the scope of the formal XML syntax. Therefore, this section will use terms defined by RFC 2119 [13] to describe the specification outside the scope of the formal XML syntax. While reading this section, please reference Section 5 for needed details on the formal XML syntax. 3.1 Query Derivatives 3.1.1 Query This query MUST return a result set of elements. See Section 3.2.4. 3.1.2 Query finds a domains by searches on fields associated with the domain's registrant. A search constraint of MUST restrict the results to domains only underneath the domain specified by its content if it is present. The element contains the name of the field associated with the registrant to be used in the search. See for the list of allowable content for this element. The element may be used to specify the beginning part of the target. The element may be used to specify the ending part of the target. 3.1.3 Query The query finds a domains by the name of the domain as it is known in DNS. A search constraint of MUST restrict the results to domains only underneath the domain specified by its content if it is present. The specifies the beginning of the domain name. The element specifies the end of the domain name. Newton Expires May 5, 2003 [Page 5] Internet-Draft iris-dreg November 2002 3.1.4 Query searches for contacts given search constraints. The element specifies the data of the contact to be used to narrow the search. See Section 3.2.3 for the allowable content of this element. The element specifies the beginning part of the target. The specifies the end part of the target. 3.1.5 Query This query does a simple search for the domains being hosted by a name server. The search is constrained using either the host name, host handle, IPv4 address, or IPv6 address of the name server. 3.2 Result Derivatives 3.2.1 Result The result represents an instance of a domain assignment. The children of the element are as follows: o - the full name of the domain as it is in DNS. The contents of this element MUST be a domain name as specified by RFC 1035 [12]. o - a registry unique assigned identifier to a domain. o - an element containing multiple children. Each child is an element as described by IRIS [5]. The referent of each element MUST be a (Section 3.2.2) result. o - an element containing a reference to the registrant of this domain. The referent MUST be a (Section 3.2.3) result. o - an element representing contacts associated with the domain. Each of its children are container elements contains an reference to a (Section 3.2.3) result coupled with a element. The element contains one of the following domain-to-contact relationships: * billing * technical Newton Expires May 5, 2003 [Page 6] Internet-Draft iris-dreg November 2002 * administrative * legal * zone * other o - specifies the last time a contact for the domain was added or removed. o - an element with a child of . The referent is a (Section 3.2.3) result responsible for the last addition or removal of a contact for this domain. o - an element specifying the status of the domain. This element contains one of the following: * reservedDelegation - permanently inactive * assignedAndActive - normal state * assignedAndInactive - new delegation * assignedAndOnHold - dispute * revoked - database purge pending * unspecified o - an element containing an element, the referent of which is a (Section 3.2.1). The intention of this element is to point to the downstream delegation reference. Therefore, if this is a result given back by a domain registry, it should point to the domain in the domain registrar or registrant service. o - contains a child of specifying the domain registry operator for this domain represented by a (Section 3.2.4) result. o - contains a child of specifying the domain registrar operator for this domain represented by a (Section 3.2.4). o - an element containing the date and time of the initial delegation of this domain. Newton Expires May 5, 2003 [Page 7] Internet-Draft iris-dreg November 2002 o - an element containing the date and time of last renewal of this domain. o - an element containing the date and time of the expiration of this domain. o - an element containing the date and time of the last time one of the nameservers was added or removed for the delegation of this domain. o - an element with a child of . The referent MUST be a (Section 3.2.3) result and be responsible for the last addition or removal of a nameserver for this domain. o - an element containing the date and time of the last time the data for this domain was verified by the responsible registration authority. o - an element containing elements specifying entities that are indirectly associated with this domain. 3.2.2 Result The element represents an instance of a host registration. The children of the element are as follows: - a registry unique assigned identifier for the host. - the fully qualified domain name of the host. The contents of this element are a domain name and MUST conform to RFC 1035 [12]. - contains a list of elements, the content of which MUST conform to the a valid IP version 4 host address as specified by RFC 791 [8]. - contains a list of elements, the content of which MUST conform to the a valid IP version 6 host address as specified by RFC 2373 [7]. - a list of elements specifying contacts associated with this host. The referents MUST be (Section 3.2.3) results. - an element containing the date and time this Newton Expires May 5, 2003 [Page 8] Internet-Draft iris-dreg November 2002 host was created. - an element containing the date and time this host was last modified. - an element containing elements specifying entities that are indirectly associated with this host. 3.2.3 Result The element represents an instance of a contact registration. The children of the element are as follows: - a registry unique assigned identifier for this contact. - the name of the contact. - a specification of the language code to use to localize the data in this result. - an element containing the organization name of the contact. - elements containing the e-mail address for this contact.
- an element containing the street address for this contact. - an element containing the city for this contact. - an element containing the national region for this contact. - an element containing the postal code for this contact. - an element containing the country for this contact. - an element containing the voice phone number for this contact. - an element containing the facsimile phone number for this contact. - an element containing the date and time this contact was created. Newton Expires May 5, 2003 [Page 9] Internet-Draft iris-dreg November 2002 - an element containing the date and time this contact was last modified. - an element containing the date and time this data for this contact was last verified to be correct by the appropriate registration authority. - an element containing elements specifying entities that are indirectly associated with this contact. The "contactSearchFieldType" definition specifies a list of the above fields allowable to be used for the purpose of narrowing searches that may yield contact or contact-related results. Searches MUST use only these fields. The field list is: o contactHandle o commonName o organization o eMail o city o region o postalCode o country 3.2.4 The result represents an entity capable of registering domains. The element contains an element pointing to the entity "id" in the entity class "service-definition". The authority areas found in the referent MUST be domains and are the domains for which a given registration authority has control. The child element determines the role in which this registration authority plays in the process of registering domains. The intent of this element is to explain the various roles a registration authority may have with regards to the authority areas pointed to by the element. A client MAY understand Newton Expires May 5, 2003 [Page 10] Internet-Draft iris-dreg November 2002 the relationship of a registration authority with respect to a domain by the placement of the reference in the domain (e.g. or ). 3.3 Generic Code Derivatives This schema defines only one derivative, . Servers MUST use this error code when a query capable of using the "contactSearchFieldType" (see Section 3.2.3) must be narrowed to yield a result. 3.4 Support for The following types of named entities are recognized by the query of IRIS via derivation of the element: o host-name - the fully qualified domain name of a nameserver. Yields a (Section 3.2.2) in the response. o host-handle - the registry unique identifier given a nameserver. Yields a (Section 3.2.2) in the response. o domain-name - the fully qualified name of a domain. Yields a (Section 3.2.1) in the response. o domain-handle - the registry unique identifier given a domain. Yields a (Section 3.2.1) in the response. o contact-handle - the registry unique identifier given a contact. Yields a (Section 3.2.3) in the response. o ipv4-address - the IPv4 address of a nameserver. Yields a (Section 3.2.2) in the response. o ipv6-address - the IPv6 address of a nameserver. Yields a (Section 3.2.2) in the response. Newton Expires May 5, 2003 [Page 11] Internet-Draft iris-dreg November 2002 4. Domain Registry Width As described in CRISP [11], domain registries have differing widths. Some are "thick" and some are "thin." Regardless of the domain registry width, it is important for all levels of the hierarchy of the domain delegation tree to have the same appearance from a schema perspective. This allows clients to traverse this tree with only the need to know the fingerprint of a "domain registry" and without the need to know separate fingerprints for what is a domain registry, a domain registrar, or even a domain registrant. Therefore, the schema defined in this document MUST be used at all levels despite the width of the domain registry model. However, implementers will need to take into consideration the instances where search continuations and entity references either defined in this document or defined as part of the base result, as defined in IRIS [5], will need to be employed to support the appropriate registry width. The following sections are only guidelines and the language specified in Section 2 does not apply and is not used. Implementers should determine the appropriate results for their particular implementation as the two following sections are generalized and may not be appropriate to all models of registries. All guidelines noted in the following sections are subject to policy settings of the operators involved. 4.1 "Thick" For thick registries, searches for and lookups of domains should result in a element. This element should contain most of the contact information if privileges allow for it. To reference the equivalent domain entity in a registrants service instance, an entity URI should be returned using the element of the object. Searches for contacts or holders should not yield search continuations. 4.2 "Thin" When elements are returned in a result, thin registries should also return an entity URI to the equivalent domain entity in the registrars service instance using the child. Likewise, when a registrar's service instance returns a instance, it SHOULD use the same element to reference the domain entity in the registrant's service instance, if one is available. Because thin registries do not contain contact information, certain searches will yield nothing but search continuations. These are Newton Expires May 5, 2003 [Page 12] Internet-Draft iris-dreg November 2002 listed here: o o o entity lookups in the "contact-handle" class Because handles for hosts and domains can be assigned by both registries and registrars, entity lookups in the registry in the "host-handle" and "domain-handle" classes can yield both a derivative, in this case and respectively, and search continuations. Newton Expires May 5, 2003 [Page 13] Internet-Draft iris-dreg November 2002 5. Formal XML Syntax This registry schema is specified in the XML Schema notation. The formal syntax presented here is a complete schema representation suitable for automated validation of an XML instance when combined with the formal schema syntax of IRIS. Domain registry schema derived from IRIS schema Newton Expires May 5, 2003 [Page 14] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 15] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 16] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 17] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 18] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 19] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 20] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 22] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 23] Internet-Draft iris-dreg November 2002 Newton Expires May 5, 2003 [Page 24] Internet-Draft iris-dreg November 2002 6. BEEP Transport Compliance IRIS allows several extensions of the core capabilities. This section outlines those extensions allowable by IRIS-BEEP [6]. 6.1 Message Pattern This registry type uses the default message pattern as described in IRIS-BEEP [6]. 6.2 Authority Resolution The authority resolution for this registry type is similar to the default resolution spelled out in IRIS-BEEP [6]. The default authority resolution process allows for the authority to be o a domain name o a domain name accompanied by a port number o an IP address o an IP address accompanied by a port number The resolution process for this registry only differs if the authority is only a domain name (i.e. without the port number). The process for this condition is as follows: 1. The SRV algorithm is used with a service parameter of "iris" and a protocol parameter of "tcp" to determine the IP/TCP addressing information. 2. If no SRV records are found (e.g. for "_iris._tcp.example.com"), then the left-most component of the domain name is removed, and the first step is repeated again (e.g. for "_iris._tcp.com"). 3. If all the components of the domain name are removed and no SRV records are found, then the DNS is queried for the A records corresponding to the original domain name and the port number used is the well-known port assigned by the IANA for IRIS using BEEP. 6.3 Server Authentication This registry type uses the default server authentication method as described in IRIS-BEEP [6]. Newton Expires May 5, 2003 [Page 25] Internet-Draft iris-dreg November 2002 7. Internationalization Considerations Implementers should be aware of considerations for internationalization in IRIS [5]. In addition, this document specifies the lookup of domain names. Current efforts are under way to provide "internationalized" domain names. This document does not yet strive to make distinctions between the two. However, because XML may be specified in UTF-8, it is possible to support internationalization efforts for domain names. Newton Expires May 5, 2003 [Page 26] Internet-Draft iris-dreg November 2002 8. IANA Considerations The following URN will need to be registered with IANA according to the IANA considerations defined in IRIS [5]: urn:ietf:params:xml:ns:dreg1 Newton Expires May 5, 2003 [Page 27] Internet-Draft iris-dreg November 2002 9. Security Considerations This document lays out no new considerations for security precautions beyond that specified in IRIS [5]. Newton Expires May 5, 2003 [Page 28] Internet-Draft iris-dreg November 2002 References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [2] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, . [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, . [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . [5] Newton, A., "Internet Registry Information Service", draft- ietf-crisp-iris-core-01 (work in progress), November 2002. [6] Newton, A., "Internet Registry Information Service (IRIS) over Blocks Exstensible Exchange Protocol (BEEP)", draft-ietf-crisp- iris-beep-01 (work in progress), November 2002. [7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [9] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD 2, October 1994. [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. [11] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-00 (work in progress), August 2002. [12] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. Newton Expires May 5, 2003 [Page 29] Internet-Draft iris-dreg November 2002 Author's Address Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@ecotroph.net URI: http://www.verisignlabs.com/ Newton Expires May 5, 2003 [Page 30] Internet-Draft iris-dreg November 2002 Appendix A. An Example Request and Response The following is an example of an IRIS request and response using this registry schema. --------------------------------------------------------------------- This XML instance is a request to search for domains by the registrant's name. com commonName The Cobbler Shoppe Figure 2: dreg-request.xml --------------------------------------------------------------------- --------------------------------------------------------------------- This XML instance is a response from Figure 2. Newton Expires May 5, 2003 [Page 31] Internet-Draft iris-dreg November 2002 thecobblershoppe.com iris://com/dreg1/host-handle/research7 iris://com/dreg1/host-handle/nso1184 iris://com/dreg1/contact-handle/beb140 iris://com/dreg1/contact-handle/mak21 technical iris://com/dreg1/service-definition/notice beb140 Bill Eckels The Cobbler Shoppe Newton Expires May 5, 2003 [Page 32] Internet-Draft iris-dreg November 2002 bille@bjmk.com
21 North Main Street
Britt IA 50423 US 515-843-3521
It is illegal to use information from this service for the purposes of sending unsolicited bulk email.
Figure 3: dreg-response.xml --------------------------------------------------------------------- Newton Expires May 5, 2003 [Page 33] Internet-Draft iris-dreg November 2002 Appendix B. An Example Database Serialization The following is an example of serializing domain data. --------------------------------------------------------------------- This example shows the serialization of a domain, a host, and some named queries. thecobblershoppe.com iris://com/dreg1/host-handle/research7 iris://com/dreg1/host-handle/nso1184 iris://net/dreg1/contact-handle/beb140 iris://net/dreg1/contact-handle/mak21 technical nsol184 ns1.netsol.com 216.168.224.200 iris://com/dreg1/contact-handle/dblacka net dblacka contact-handle iris://verisignlabs.com/dreg1/host-handle/nsol184 iris://verisignlabs.com/dreg1/host-handle/research7 Newton Expires May 5, 2003 [Page 35] Internet-Draft iris-dreg November 2002 iris://verisignlabs.com/dreg1/host-handle/scooter Figure 4: dreg-serialization.xml --------------------------------------------------------------------- Newton Expires May 5, 2003 [Page 36] Internet-Draft iris-dreg November 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Newton Expires May 5, 2003 [Page 37]