From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3982.txt | 2803 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2803 insertions(+) create mode 100644 doc/rfc/rfc3982.txt (limited to 'doc/rfc/rfc3982.txt') diff --git a/doc/rfc/rfc3982.txt b/doc/rfc/rfc3982.txt new file mode 100644 index 0000000..ea7754c --- /dev/null +++ b/doc/rfc/rfc3982.txt @@ -0,0 +1,2803 @@ + + + + + + +Network Working Group A. Newton +Request for Comments: 3982 VeriSign, Inc. +Category: Standards Track M. Sanz + DENIC eG + January 2005 + + + IRIS: A Domain Registry (dreg) Type for the + Internet Registry Information Service (IRIS) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes an Internet Registry Information Service + (IRIS) 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 3 + 3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Query Derivatives . . . . . . . . . . . . . . . . . . . 3 + 3.1.1. Query . . . . . . . . . . 3 + 3.1.2. Query . . . . . . . . . . 4 + 3.1.3. Query . . . . . . . . . . . 4 + 3.1.4. Query . . . . . . . . . . . . 4 + 3.1.5. Query . . . . . . . . . . . . . . 5 + 3.1.6. Query . . . . . . . . . . . 5 + 3.1.7. Contact Search Group . . . . . . . . . . . . . . 5 + 3.2. Result Derivatives . . . . . . . . . . . . . . . . . . . 6 + 3.2.1. Privacy Labels . . . . . . . . . . . . . . . . . 6 + 3.2.2. Result . . . . . . . . . . . . . . . . 7 + 3.2.3. Result . . . . . . . . . . . . . . . . . 10 + 3.2.4. Result . . . . . . . . . . . . . . . . 11 + + + +Newton & Sanz Standards Track [Page 1] + +RFC 3982 IRIS-Dreg January 2005 + + + 3.2.5. . . . . . . . . . . . . 13 + 3.3. Generic Code Derivatives . . . . . . . . . . . . . . . . 13 + 3.3.1. . . . . . . . . . . . . . . . . 13 + 3.3.2. . . . . . . . . . . . . . 14 + 3.4. Support for . . . . . . . . . . . . 14 + 4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 15 + 5. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 36 + 5.1. Message Pattern . . . . . . . . . . . . . . . . . . . . 36 + 5.2. Server Authentication . . . . . . . . . . . . . . . . . 36 + 6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 36 + 6.1. Application Service Label . . . . . . . . . . . . . . . 36 + 6.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . . 37 + 6.3. Top-Down Resolution . . . . . . . . . . . . . . . . . . 37 + 7. Internationalization Considerations . . . . . . . . . . . . . 38 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 8.1. XML Namespace URN Registration . . . . . . . . . . . . . 38 + 8.2. S-NAPTR Registration . . . . . . . . . . . . . . . . . . 39 + 8.3. BEEP Registration . . . . . . . . . . . . . . . . . . . 39 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 10.2. Informative References . . . . . . . . . . . . . . . . . 40 + A. Examples of Requests and Responses . . . . . . . . . . . . . . 41 + A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 41 + A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 42 + A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 43 + B. An Example of Database Serialization . . . . . . . . . . . . . 47 + C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 50 + +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 [17]. + + The schema given is this document is specified by 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]. + + Examples of client/server XML exchanges with this registry type are + available in Appendix A. + + + + + + +Newton & Sanz Standards Track [Page 2] + +RFC 3982 IRIS-Dreg January 2005 + + +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 BCP 14, RFC 2119 [10]. + +3. Schema Description + + IRIS requires the derivation of both query and result elements by a + registry schema. These descriptions follow. + + References to XML elements without a namespace qualifier are from the + schema defined in Section 4. References to elements and attributes + 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. This section will use terms defined + by RFC 2119 [10] to describe these. While reading this section, + please reference Section 4 for needed details on the formal XML + syntax. + +3.1. Query Derivatives + +3.1.1. Query + + searches for a registration authority + designated as a registrar for the registry of the server. + + If present, the element MUST restrict the results of the + search to registrars capable of registering subdomains in the domain + signified by the content of this element. + + The element restricts the scope of the query with its + child elements. The element specifies the beginning of + the registrar's name. The element specifies the end of + the registrar's name. The element specifies equivalence + to the registrar's name. + + If the element is not present, the query MUST return all + registrars applicable (i.e., in consideration of ). + + This query MUST return a result set of zero or more + elements. See Section 3.2.5. + + + + + +Newton & Sanz Standards Track [Page 3] + +RFC 3982 IRIS-Dreg January 2005 + + +3.1.2. Query + + finds domains by searches on fields associated + with a domain's contact. A search constraint of MUST + restrict the results to domains underneath the domain specified by + its content, if it is present. + + The allowable search fields are handled with either the + element or one of the elements in the + "contactSearchGroup" (see Section 3.1.7). The + element allows the domains to be selected based on the contact having + the specified contact handle. + + The query MAY also be constrained further by using the optional + element. The contents of this element signify the role the + contact has with the domain. + + This query also provides optional elements containing + language tags. Clients MAY use these elements to hint about the + natural language(s) of the affected element. Servers MAY use this + information in processing the query, such as in tailoring + normalization routines to aid in more effective searches. + +3.1.3. Query + + The query finds domains by the name of a domain + as it is known in DNS. The element restricts the scope of + the query with its child elements. The element + specifies the beginning of the domain name. The element + specifies the end of the domain name. + +3.1.4. Query + + This query differs from the query by allowing the + scope of the query to take internationalized domain names into + consideration. This query will return the union of the desired + domain and any associated variants, therefore differing from a lookup + in the "idn" entity class (Section 3.4) (which only returns the + domain or no results). + + The element restricts the scope of the query with its + child element. Its child, the element, is designed to + contain IDNs and not ACE labels, and thus MUST match only against + equivalent IDNs, according to the notion of equivalence defined in + RFC 3490 [14]. + + This query also provides optional elements containing + language tags. Clients MAY use these elements to hint about the + + + +Newton & Sanz Standards Track [Page 4] + +RFC 3982 IRIS-Dreg January 2005 + + + natural language(s) of the affected element. Servers MAY use this + information in processing the query, such as in tailoring + normalization routines to aid in more effective searches. + +3.1.5. Query + + searches for contacts given search constraints. The + allowable search fields are handled by one of the elements in the + "contactSearchGroup" (see Section 3.1.7). + + This query also provides optional elements containing + language tags. Clients MAY use these elements to hint about the + natural language(s) of the affected element. Servers MAY use this + information in processing the query, such as in tailoring + normalization routines to aid in more effective searches. + +3.1.6. Query + + This query does a simple search for the domains being hosted by a + name server. The search is constrained by using either the host name + [12], host handle, IPv4 address, or IPv6 address of the name server. + +3.1.7. Contact Search Group + + Some of the queries above have similar query constraints for + searching on contacts. This section describes those common + parameters. + + allows the query to be constrained based on the common + name of the contact. The constraint can constrain the query either + by an exact match using the element, or by a subset of + the common name using the and elements. + + allows the query to be constrained based on the + organization name of the contact. It has the same semantics as the + element. + + constrains the query based on the e-mail address of the + contact. This may be done by an exact e-mail address using the + element or by any e-mail address in a domain using the + element. The element MUST only contain a valid + domain name (i.e., without an '@' symbol), and the matching SHOULD + take place only on the domain given (i.e., no partial matches with + respect to substrings or parent domains). If either the contents of + the element or the domain part of the contents of the + element contain a name with non-ASCII characters, they + MUST be normalized according to the processes of RFC 3491 [15]. + + + + +Newton & Sanz Standards Track [Page 5] + +RFC 3982 IRIS-Dreg January 2005 + + + The , , and elements restrict the scope of + the query based on the city, region, or postal code of the contact, + respectively. Each must only contain an element + containing the exact city, region, or postal code (i.e., no substring + searches). + +3.2. Result Derivatives + +3.2.1. Privacy Labels + + Several of the results in this registry type have values that cannot + be given but must be specified as present or must be flagged so that + clients do not divulge them. In order to achieve this, some of the + results use the following element types: + + o "dateTimePrivacyType" -- contains the XML Schema [3] data type + "dateTime". The contents of this element MUST be specified by + using the 'Z' indicator for Coordinated Universal Time (UTC). + + o "stringPrivacyType" -- contains the XML Schema [3] data type + "string". + + o "normalizedStringPrivacyType" -- contains the XML Schema [3] data + type "normalizedString". + + o "tokenPrivacyType" -- contains the XML Schema [3] data type + "token". + + o "domainStatusType" -- contains the optional element of + , indicating the date and time when the status was + applied, and the optional element of with the + required attribute 'language', indicating a description of the + status. This element also has the optional attribute 'scope', + indicating the scope or origin of the status value. + + o "contactTypeType" -- contains optional child + elements. Each child element requires a 'language' + attribute. + + As specified, these elements can have nil values and therefore may be + present with empty content or present with their specified content. + The use of these elements is also optional. + + If present without content, each of these element types MUST have one + or more of the following boolean attributes: + + o 'private' -- If true, this specifies that the content is absent + because it may never be published. + + + +Newton & Sanz Standards Track [Page 6] + +RFC 3982 IRIS-Dreg January 2005 + + + o 'denied' -- If true, this specifies that the content is absent + because policy does not allow it to be given at the current level + of access. + + If present with content, each of these element types MAY have one or + more of the following boolean attributes: + + o 'doNotRedistribute' -- If true, this specifies that the content is + not to be redistributed. + + o 'specialAccess' -- If true, this specifies that the content has + been provided due to special access rights. + + These boolean attributes SHOULD be used in accordance with the level + of access granted to the recipient of the data. For example, marking + data as 'private' or 'denied' is to be expected if the user is + anonymous or has some other low level of access that does not warrant + viewing that particular data. Likewise, data marked with + 'doNotRedistribute' or 'specialAccess' is to be expected if the user + is authenticated and has a high level of access. + +3.2.2. Result + + An example of a result: + + + example.com + tcs-com-1 + + + + + + + +Newton & Sanz Standards Track [Page 7] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + 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 [9]. + + o -- the name of the domain in nameprep form, if applicable. + See RFC 3491 [15]. + + o -- a registry unique assigned identifier for a + domain. + + o -- MUST contain an entity reference to a referent of + type (Section 3.2.3). + + o -- contains an entity reference to the registrant of + this domain. The referent MUST be a result (Section + 3.2.4). + + o Domain contacts -- the following elements contain an entity + reference with a relationship to the domain. The referent of each + MUST be a (Section 3.2.4). + * + * + * + * + * + * + * + * + + o -- This may contain at least one of the following + elements of type 'domainStatusType' (see Section 3.2.1), but none + of these elements may appear more than once. + * -- permanently inactive + * -- normal state + * -- registration assigned but delegation + inactive + * -- dispute + * -- database purge pending + * -- change of authority pending + * -- on hold by registry + * -- on hold by registrar + + + + +Newton & Sanz Standards Track [Page 8] + +RFC 3982 IRIS-Dreg January 2005 + + + o -- contains an entity reference, the referent of + which MUST be a (Section 3.2.2). + + o -- contains an entity reference, the + referent of which MUST be a (Section 3.2.2). This + element is intended to point to the downstream registration + 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 an entity reference specifying the domain + registry operator for this domain, which MUST be a + (Section 3.2.5). This element has an + optional boolean 'hosting' attribute. When the value of this + attribute is positive, it indicates that the registry is + responsible for authoritatively answering DNS queries for this + domain. + + o -- contains an entity reference specifying the domain + registrar operator for this domain, which MUST be a + (Section 3.2.5). This element has an + optional boolean 'hosting' attribute. When the value of this + attribute is positive, it indicates that the registrar is + responsible for authoratively answering DNS queries for this + domain. + + o -- contains the date and time of the + initial delegation of this domain. + + o -- contains the date and time of last + renewal of this domain. + + o -- contains the date and time of the + expiration of this domain. + + o -- specifies the last time a + contact for the domain was added or removed. + + o -- contains an entity reference. The + referent MUST be a (Section 3.2.4) responsible for the + last addition or removal of a contact for this domain. + + o -- contains the date and time + of the last time one of the nameservers was added or removed for + the delegation of this domain. + + + + + + +Newton & Sanz Standards Track [Page 9] + +RFC 3982 IRIS-Dreg January 2005 + + + o -- contains an entity reference. + The referent MUST be a result (Section 3.2.4) and MUST + be responsible for the last addition or removal of a nameserver + for this domain. + + o -- contains the date and time of the + last time the data for this domain was verified by the responsible + registration authority. + + o -- contains an entity reference specifying a + referent indirectly associated with this domain. + +3.2.3. Result + + An example of a result: + + + nsol184 + a.iana-servers.net + 192.0.2.43 + + + + The element represents an instance of a host registration. + The children of the element are as follows: + + o -- a registry unique assigned identifier for the + host. + + o -- the fully qualified domain name of the host. The + contents of this element are a domain name and MUST conform to RFC + 1035 [9]. + + o -- the content of this MUST conform to the a valid + IP version 4 host address, as specified by RFC 791 [8]. + + o -- the content of this MUST conform to the a valid + IP version 6 host address, as specified by RFC 3513 [7]. + + o -- contains an entity reference specifying a contact + associated with this host. The referent MUST be + (Section 3.2.4) results. + + + + +Newton & Sanz Standards Track [Page 10] + +RFC 3982 IRIS-Dreg January 2005 + + + o -- contains the date and time when this host was + created. + + o -- contains the date and time when this + host was last modified. + + o -- contains the date and time when this + data for this host was last verified to be correct by the + appropriate registration authority. + + o -- contains an entity reference specifying a + referent indirectly associated with this host. + +3.2.4. Result + + An example of a result: + + + dbarton + IANA Manager + Internet Assigned Numbers Authority + res-dom@iana.org + +
4676 Admiralty Way, Suite 330
+ Marina del Rey + CA + 92092 + US + + +1.3108239358 + + + The element represents an instance of a contact + registration. The children of the element are as follows: + + o -- a registry unique assigned identifier for this + contact. + + o -- the name of the contact. + + o -- a specification of the language code to use to + localize the data in this result. + + o -- contains one of the following child elements: , + , , or . Each of these elements is a + "contactTypeType" as defined in Section 3.2.1. + + + +Newton & Sanz Standards Track [Page 11] + +RFC 3982 IRIS-Dreg January 2005 + + + o -- contains the organization name of the contact. + + o -- contains an e-mail address for this contact. + + o -- contains an e-mail address within an + internationalized domain name [14]. + + o -- contains a SIP URI for this contact. + + o -- contains children representing a postal + address. has the following children: + *
-- contains the street address for this contact. + * -- contains the city for this contact. + * -- contains the national region for this contact. + * -- contains the postal code for this contact. + * -- contains the country for this contact. This + SHOULD be a two-letter country code compliant with ISO 3166 + [11]. + + o -- contains a voice phone number for this contact. If it + begins with a '+' (plus) character, it MUST be a number defined by + E164 [13]. The format number defined in E164 [13] is RECOMMENDED. + + o -- contains a facsimile phone number for this contact. If + it begins with a '+' (plus) character, it MUST be a number defined + by E164 [13]. The format number defined in E164 [13] is + RECOMMENDED. + + o -- contains the date and time when this contact + was created. + + o -- contains the date and time when this + contact was last modified. + + o -- contains the date and time when this + data for this contact was last verified to be correct by the + appropriate registration authority. + + o -- contains an entity reference specifying + equivalents of this contact that have been translated into other + languages. The referent MUST be results (Section + 3.2.4). + + o -- contains an entity reference specifying a + referent indirectly associated with this contact. + + + + + + +Newton & Sanz Standards Track [Page 12] + +RFC 3982 IRIS-Dreg January 2005 + + +3.2.5. + + An example of a result: + + + + + Internet Assigned Numbers Authority + + + + + The result represents an entity capable of + registering domains. + + The child element of + contains an entity reference pointing to the entity "id" in the + entity class "iris". The authority areas found in the referent MUST + be domains for which a given registration authority has control. + + The child element contains the name of the + registration authority. + + The registration authority type child elements , + , and determine the role this registration + authority plays in the process of registering domains. This element + is intended to explain the various roles a registration authority may + have in the authority areas pointed to by the + element. A client MAY understand the relationship of a registration + authority with respect to a domain by the placement of the reference + in the domain (e.g., or ). + + The child elements each contain one domain name signifying + the domains for which this registration authority may register sub- + domains. + +3.3. Generic Code Derivatives + +3.3.1. + + Servers MAY use the error code when a query must be + narrowed to yield a result set acceptable under the policies of the + server operator. + + + +Newton & Sanz Standards Track [Page 13] + +RFC 3982 IRIS-Dreg January 2005 + + +3.3.2. + + The queries , , and + support optional language tags that allow a client to + suggest to a server the languages in which to scope the queries. If + a client passes to the server a language that the server does not + support, the server MAY use this error code to indicate that one of + the languages is not supported. + + This element contains child elements named . + Each of these child elements specifies a language not supported by + the server. When a server returns this error, it MUST give the + languages from the query which are not supported. + +3.4. Support for + + The following types of entity classes are recognized by the + query of IRIS for this registry: + + o host-name -- The fully qualified domain name of a nameserver. It + yields a (Section 3.2.3) in the response. + + o host-handle -- The registry unique identifier given a nameserver. + It yields a (Section 3.2.3) in the response. + + o domain-name -- The fully qualified name of a domain. This a + domain name as specified by RFC 1035 [9]. It yields a + (Section 3.2.2) in the response. + + o idn -- The fully qualified name of a domain in nameprep form (see + RFC 3491 [15]). It yields a (Section 3.2.2) in the + response. + + o domain-handle -- The registry unique identifier given a domain. + It yields a (Section 3.2.2) in the response. + + o contact-handle -- The registry unique identifier given a contact. + It yields a (Section 3.2.4) in the response. + + o ipv4-address -- The IPv4 address of a nameserver. It yields a + (Section 3.2.3) in the response. + + o ipv6-address -- The IPv6 address of a nameserver. It yields a + (Section 3.2.3) in the response. + + o registration-authority -- The name of a registration authority. + It yields a (Section 3.2.5) in the + response. + + + +Newton & Sanz Standards Track [Page 14] + +RFC 3982 IRIS-Dreg January 2005 + + + All names in these entity classes are case insensitive. + +4. 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 & Sanz Standards Track [Page 16] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 18] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 19] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 21] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 31] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 34] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 35] + +RFC 3982 IRIS-Dreg January 2005 + + + + + + + + + + + + + + + Figure 5: dreg.xsd + +5. BEEP Transport Compliance + + IRIS allows several extensions of the core capabilities. This + section outlines extensions allowable by IRIS-BEEP [6]. + +5.1. Message Pattern + + This registry type uses the default message pattern described in + IRIS-BEEP [6]. + +5.2. Server Authentication + + This registry type only uses the basic TLS server authentication + method, as described in IRIS-BEEP [6]. + +6. URI Resolution + +6.1. Application Service Label + + The application service label associated with this registry type MUST + be "DREG1". This is the abbreviated form of the URN for this + registry type: urn:ietf:params:xml:ns:dreg1. + + + + + + + +Newton & Sanz Standards Track [Page 36] + +RFC 3982 IRIS-Dreg January 2005 + + +6.2. Bottom-Up Resolution + + The bottom-up alternative resolution method MUST be identified as + 'bottom' in IRIS URI's. + + The process for this resolution method differs from the direct- + resolution method if the authority is only a domain name (i.e., + without the port number). The process for this condition is as + follows: + + 1. The IRIS [5] direct-resolution process is tried on the domain name + (e.g., "example.com"). + + 2. If the direct-resolution process yields no server for which a + connection can be made, then the leftmost label of the domain name + is removed, and the first step is repeated again (e.g., "com"). + + 3. If all the labels of the domain name are removed and no server + connections have been made, then the DNS is queried for the + address records corresponding to the original domain name, and the + port used is the well-known port for the default protocol of IRIS. + +6.3. Top-Down Resolution + + The top-down alternative resolution method MUST be identified as + 'top' in IRIS URIs. + + The process for this resolution method differs from the direct- + resolution method if the authority is only a domain name (i.e., + without the port number). The process for this condition is as + follows: + + 1. The domain name is reduced to its rightmost label. This is always + '.'. + + 2. The IRIS [5] direct-resolution process is tried on the domain + name. + + 3. If the direct-resolution process yields no server for which a + connection can be made, then the original label to the left of the + rightmost label of the domain name is prepended, and the second + step is repeated again (e.g., if ".", then "com"; if "com", then + "example.com"). + + 4. If all the labels of the original domain are present and no server + connections have been made, then the DNS is queried for the + address records corresponding to the original domain name, and the + port used is the well-known port for the default protocol of IRIS. + + + +Newton & Sanz Standards Track [Page 37] + +RFC 3982 IRIS-Dreg January 2005 + + +7. Internationalization Considerations + + Implementers should be aware of considerations for + internationalization in IRIS [5]. + + This document specifies the lookup of domain names, both the + traditional ASCII form and the IDN form. In addition, the social + data associated with contacts may also be non-ASCII and could contain + virtually any Unicode character. The element is provided + in queries that have the potential to traverse such data. Clients + should use this element to indicate the desired target languages to + the server, and servers should use this element to better enable + normalization and search processes (see [18]). + + For clients needing to localize the data tags in this protocol, note + that localization is only needed on the names of XML elements and + attributes with the exception of elements containing date and time + information. The schema for this registry has been designed so that + clients need not interpret the content of elements or attributes for + localization, other than that of elements containing date and time + information. + + Clients should also make use of the elements provided in + many of the results. Results containing data that may be in Unicode + are accompanied by these elements in order to aid better presentation + of the data to the user. + + The "dateTimePrivacyType" element type contains the XML Schema [3] + data type "dateTime". The contents of this element MUST be specified + by using the 'Z' indicator for Coordinated Universal Time (UTC). + +8. IANA Considerations + +8.1. XML Namespace URN Registration + + This document makes use of a proposed XML namespace and schema + registry specified in XML_URN [16]. Accordingly, the following + registration information is provided for the IANA: + + o URN/URI: + * urn:ietf:params:xml:ns:dreg1 + o Contact: + * Andrew Newton + * Marcos Sanz + o XML: + * The XML Schema specified in Section 4 + + + + + +Newton & Sanz Standards Track [Page 38] + +RFC 3982 IRIS-Dreg January 2005 + + +8.2. S-NAPTR Registration + + The following S-NAPTR application service label has been registered + with IANA according to the IANA considerations defined in IRIS [5]: + + DREG1 + +8.3. BEEP Registration + + The following BEEP Profile URI has been registered with IANA, in + addition to the registration provided in IRIS-BEEP [6]. + + http://iana.org/beep/iris1/dreg1 + +9. Security Considerations + + This document lays out no new considerations for security precautions + beyond that specified in IRIS [5]. + +10. References + +10.1. Normative 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. and M. Sanz, "IRIS: The Internet Registry Information + Service (IRIS) Core Protocol", RFC 3981, December 2005. + + [6] Newton, A. and M. Sanz, "Using the Internet Registry Information + Service (IRIS) over the Blocks Extensible Exchange Protocol + (BEEP)", RFC 3983, December 2005. + + + + + + +Newton & Sanz Standards Track [Page 39] + +RFC 3982 IRIS-Dreg January 2005 + + + [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. + + [9] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [11] International Organization for Standardization, "Codes for the + representation of names of countries, 3rd edition", ISO Standard + 3166, August 1988. + + [12] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, October 1989. + + [13] International Telecommunications Union, "The International + Public Telecommunication Numbering Plan", ITU-T Recommendation + E.164, 1991. + + [14] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing + Domain Names in Applications (IDNA)", RFC 3490, March 2003. + + [15] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for + Internationalized Domain Names (IDN)", RFC 3491, March 2003. + + [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January + 2004. + +10.2. Informative References + + [17] Newton, A., "Cross Registry Internet Service Protocol (CRISP) + Requirements", RFC 3707, February 2004. + +URIs + + [18] + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 40] + +RFC 3982 IRIS-Dreg January 2005 + + +Appendix A. Examples of Requests and Responses + + The examples in this section use the string "C:" to denote data sent + by a client to a server and the string "S:" to denote data sent by a + server to a client. + +A.1. Example 1 + + The following is an example of an entity lookup in a dreg1 registry + for the domain-name of 'example.com'. The response shows the ability + to specify data as being withheld because it is private. + + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: + + S: + S: + S: + S: + S: + S: + S: + S: + S: example.com + S: tcs-com-1 + S: + S: + S: + S: + + + +Newton & Sanz Standards Track [Page 41] + +RFC 3982 IRIS-Dreg January 2005 + + + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + + Figure 6: Example 1 + +A.2. Example 2 + + The following is an example of an entity lookup in a dreg1 registry + for the contact-handle of 'mak21'. The response shows the ability to + specify data as being withheld because it is private. + + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: + S: + + + +Newton & Sanz Standards Track [Page 42] + +RFC 3982 IRIS-Dreg January 2005 + + + S: + S: + S: + S: + S: + S: + S: + S: mak21 + S: + S: + S: Mark Kosters + S: + S: + S: + S: VeriSign, Inc. + S: + S: + S: markk@verisignlabs.com + S: + S: + S: + S: + S: + S: + S: + S: + S: + + Figure 7: Example 2 + +A.3. Example 3 + + The following is an example of a domain search based on a + registrant's name beginning with the string 'The Cobbler Shoppe'. + This example also shows the use of bags. + + C: + C: + C: + C: + C: + C: + C: com + + + +Newton & Sanz Standards Track [Page 43] + +RFC 3982 IRIS-Dreg January 2005 + + + C: + C: + C: The Cobbler Shoppe + C: + C: + C: registrant + C: + C: + C: + C: + C: + + S: + S: + S: + S: + S: + S: + S: example.com + S: + S: + S: + S: + S: Bill Eckels + S: + S: + S: + S: + S: Mark Kosters + + + +Newton & Sanz Standards Track [Page 44] + +RFC 3982 IRIS-Dreg January 2005 + + + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: + S: beb140 + S: + S: Bill Eckels + S: + S: en + S: + S: + S: + S: Bill sells shoes down by the sea shore. + S: + S: + S: Rechnung verkauft Schuhe unten durch das Seeufer. + S: + S: + S: + S: + S: The Cobbler Shoppe + S: + S: + S: + S:
+ S: 21 North Main Street + S:
+ S: + S: Britt + + + +Newton & Sanz Standards Track [Page 45] + +RFC 3982 IRIS-Dreg January 2005 + + + S: + S: + S: IA + S: + S: + S: 50423 + S: + S: + S: US + S: + S: + S: + S: +1.5158433521 + S: + S: + S: + S: + S: It is illegal to use information from this service + S: for the purposes of sending unsolicited bulk email. + S: + S: + S: + S: + S: + S: + S: + S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ + S: c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn + S: T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48 + S: Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8= + S: + S: + S: + S: + S: + + Figure 8: Example 3 + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 46] + +RFC 3982 IRIS-Dreg January 2005 + + +Appendix B. An Example of Database Serialization + + The following is an example of serializing domain data. + + This example shows the serialization of a domain, a host, and a + referral. + + + + + example.com + + + + + + IANA Administrator + + + + + + nsol184 + ns1.iana.org + 192.0.2.1 + + + IANA Techie + + + + + + + + + + com + + + + + + + + Figure 9: dreg-serialization.xml + +Appendix C. Acknowledgements + + Many of the concepts concerning the use of SRV records for step-wise + refinement toward finding authoritative servers and many of the + details of result objects in this document were originally created by + Eric A. Hall in his memos regarding the use of LDAP to satisfy the + CRISP requirements. These concepts have contributed significantly to + the development of this protocol. + + David Blacka made many technical contributions based on his work on + IRIS implementation and his experienced judgment. He also + contributed many editorial clarifications. + + + + + + + + + + +Newton & Sanz Standards Track [Page 48] + +RFC 3982 IRIS-Dreg January 2005 + + +Authors' Addresses + + Andrew L. Newton + VeriSign, Inc. + 21345 Ridgetop Circle + Sterling, VA 20166 + USA + + Phone: +1 703 948 3382 + EMail: anewton@verisignlabs.com; andy@hxr.us + URI: http://www.verisignlabs.com/ + + + Marcos Sanz + DENIC eG + Wiesenhuettenplatz 26 + D-60329 Frankfurt + Germany + + EMail: sanz@denic.de + URI: http://www.denic.de/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newton & Sanz Standards Track [Page 49] + +RFC 3982 IRIS-Dreg January 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Newton & Sanz Standards Track [Page 50] + -- cgit v1.2.3