summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3982.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3982.txt')
-rw-r--r--doc/rfc/rfc3982.txt2803
1 files changed, 2803 insertions, 0 deletions
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. <findRegistrarsByName> Query . . . . . . . . . . 3
+ 3.1.2. <findDomainsByContact> Query . . . . . . . . . . 4
+ 3.1.3. <findDomainsByName> Query . . . . . . . . . . . 4
+ 3.1.4. <findDomainsByIDN> Query . . . . . . . . . . . . 4
+ 3.1.5. <findContacts> Query . . . . . . . . . . . . . . 5
+ 3.1.6. <findDomainsByHost> Query . . . . . . . . . . . 5
+ 3.1.7. Contact Search Group . . . . . . . . . . . . . . 5
+ 3.2. Result Derivatives . . . . . . . . . . . . . . . . . . . 6
+ 3.2.1. Privacy Labels . . . . . . . . . . . . . . . . . 6
+ 3.2.2. <domain> Result . . . . . . . . . . . . . . . . 7
+ 3.2.3. <host> Result . . . . . . . . . . . . . . . . . 10
+ 3.2.4. <contact> Result . . . . . . . . . . . . . . . . 11
+
+
+
+Newton & Sanz Standards Track [Page 1]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ 3.2.5. <registrationAuthority> . . . . . . . . . . . . 13
+ 3.3. Generic Code Derivatives . . . . . . . . . . . . . . . . 13
+ 3.3.1. <searchTooWide> . . . . . . . . . . . . . . . . 13
+ 3.3.2. <languageNotSupported> . . . . . . . . . . . . . 14
+ 3.4. Support for <iris:lookupEntity> . . . . . . . . . . . . 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. <findRegistrarsByName> Query
+
+ <findRegistrarsByName> searches for a registration authority
+ designated as a registrar for the registry of the server.
+
+ If present, the <baseDomain> 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 <namePart> element restricts the scope of the query with its
+ child elements. The <beginsWith> element specifies the beginning of
+ the registrar's name. The <endsWith> element specifies the end of
+ the registrar's name. The <exactMatch> element specifies equivalence
+ to the registrar's name.
+
+ If the <namePart> element is not present, the query MUST return all
+ registrars applicable (i.e., in consideration of <baseDomain>).
+
+ This query MUST return a result set of zero or more
+ <registrationAuthority> elements. See Section 3.2.5.
+
+
+
+
+
+Newton & Sanz Standards Track [Page 3]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+3.1.2. <findDomainsByContact> Query
+
+ <findDomainsByContact> finds domains by searches on fields associated
+ with a domain's contact. A search constraint of <baseDomain> 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
+ <contactHandle> element or one of the elements in the
+ "contactSearchGroup" (see Section 3.1.7). The <contactHandle>
+ 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
+ <role> element. The contents of this element signify the role the
+ contact has with the domain.
+
+ This query also provides optional <language> 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. <findDomainsByName> Query
+
+ The <findDomainsByName> query finds domains by the name of a domain
+ as it is known in DNS. The <namePart> element restricts the scope of
+ the query with its child elements. The <beginsWith> element
+ specifies the beginning of the domain name. The <endsWith> element
+ specifies the end of the domain name.
+
+3.1.4. <findDomainsByIDN> Query
+
+ This query differs from the <findDomainsByName> 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 <namePart> element restricts the scope of the query with its
+ child element. Its child, the <exactMatch> 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 <language> 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. <findContacts> Query
+
+ <findContacts> 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 <language> 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. <findDomainsByHost> 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.
+
+ <commonName> 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 <exactMatch> element, or by a subset of
+ the common name using the <beginsWith> and <endsWith> elements.
+
+ <organization> allows the query to be constrained based on the
+ organization name of the contact. It has the same semantics as the
+ <commonName> element.
+
+ <eMail> constrains the query based on the e-mail address of the
+ contact. This may be done by an exact e-mail address using the
+ <exactMatch> element or by any e-mail address in a domain using the
+ <inDomain> element. The <inDomain> 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 <inDomain> element or the domain part of the contents of the
+ <exactMatch> 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 <city>, <region>, and <postalCode> elements restrict the scope of
+ the query based on the city, region, or postal code of the contact,
+ respectively. Each must only contain an <exactMatch> 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
+ <appliedDate>, indicating the date and time when the status was
+ applied, and the optional element of <description> 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 <description> child
+ elements. Each <description> 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. <domain> Result
+
+ An example of a <domain> result:
+
+ <domain
+ authority="iana.org" registryType="dreg1"
+ entityClass="domain-handle" entityName="example-com-1">
+ <domainName>example.com</domainName>
+ <domainHandle>tcs-com-1</domainHandle>
+ <nameServer
+ iris:referentType="host"
+ authority="iana.org" registryType="dreg1"
+ entityClass="host-handle" entityName="research7" />
+ <nameServer
+ iris:referentType="host"
+ authority="iana.org" registryType="dreg1"
+ entityClass="host-handle" entityName="nsol184" />
+ <registry
+ iris:referentType="registrationAuthority"
+ authority="com"
+ registryType="dreg1"
+ entityClass="contact-handle"
+ entityName="VGRS" />
+ <registrar
+ iris:referentType="registrationAuthority"
+ authority="iana.org" registryType="dreg1"
+ entityClass="contact-handle" entityName="dbarton" />
+
+
+
+Newton & Sanz Standards Track [Page 7]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ <initialDelegationDateTime xsi:nil="true"/>
+ </domain>
+
+ The <domain> result represents an instance of a domain assignment.
+ The children of the <domain> element are as follows:
+
+ o <domainName> -- 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 <idn> -- the name of the domain in nameprep form, if applicable.
+ See RFC 3491 [15].
+
+ o <domainHandle> -- a registry unique assigned identifier for a
+ domain.
+
+ o <nameServer> -- MUST contain an entity reference to a referent of
+ type <host> (Section 3.2.3).
+
+ o <registrant> -- contains an entity reference to the registrant of
+ this domain. The referent MUST be a <contact> 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 <contact> (Section 3.2.4).
+ * <billingContacts>
+ * <technicalContacts>
+ * <administrativeContacts>
+ * <legalContacts>
+ * <zoneContacts>
+ * <abuseContacts>
+ * <securityContacts>
+ * <otherContacts>
+
+ o <status> -- 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.
+ * <reservedDelegation> -- permanently inactive
+ * <assignedAndActive> -- normal state
+ * <assignedAndInactive> -- registration assigned but delegation
+ inactive
+ * <assignedAndOnHold> -- dispute
+ * <revoked> -- database purge pending
+ * <transferPending> -- change of authority pending
+ * <registryLock> -- on hold by registry
+ * <registrarLock> -- on hold by registrar
+
+
+
+
+Newton & Sanz Standards Track [Page 8]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ o <domainVariant> -- contains an entity reference, the referent of
+ which MUST be a <domain> (Section 3.2.2).
+
+ o <registrationReference> -- contains an entity reference, the
+ referent of which MUST be a <domain> (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 <registry> -- contains an entity reference specifying the domain
+ registry operator for this domain, which MUST be a
+ <registrationAuthority> (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 <registrar> -- contains an entity reference specifying the domain
+ registrar operator for this domain, which MUST be a
+ <registrationAuthority> (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 <initialDelegationDateTime> -- contains the date and time of the
+ initial delegation of this domain.
+
+ o <lastRenewalDateTime> -- contains the date and time of last
+ renewal of this domain.
+
+ o <expirationDateTime> -- contains the date and time of the
+ expiration of this domain.
+
+ o <lastContactModificationDateTime> -- specifies the last time a
+ contact for the domain was added or removed.
+
+ o <lastContactModificationBy> -- contains an entity reference. The
+ referent MUST be a <contact> (Section 3.2.4) responsible for the
+ last addition or removal of a contact for this domain.
+
+ o <lastDelegationModificationDateTime> -- 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 <lastDelegationModificationBy> -- contains an entity reference.
+ The referent MUST be a <contact> result (Section 3.2.4) and MUST
+ be responsible for the last addition or removal of a nameserver
+ for this domain.
+
+ o <lastVerificationDateTime> -- contains the date and time of the
+ last time the data for this domain was verified by the responsible
+ registration authority.
+
+ o <iris:seeAlso> -- contains an entity reference specifying a
+ referent indirectly associated with this domain.
+
+3.2.3. <host> Result
+
+ An example of a <host> result:
+
+ <host
+ authority="iana.org" registryType="dreg1"
+ entityClass="host-handle" entityName="nsol184" >
+ <hostHandle>nsol184</hostHandle>
+ <hostName>a.iana-servers.net</hostName>
+ <ipV4Address>192.0.2.43</ipV4Address>
+ <hostContact
+ iris:referentType="contact"
+ authority="iana.org" registryType="dreg1"
+ entityClass="contact-handle" entityName="dbarton" />
+ </host>
+
+ The <host> element represents an instance of a host registration.
+ The children of the <host> element are as follows:
+
+ o <hostHandle> -- a registry unique assigned identifier for the
+ host.
+
+ o <hostName> -- 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 <ipV4Address> -- the content of this MUST conform to the a valid
+ IP version 4 host address, as specified by RFC 791 [8].
+
+ o <ipV6Address> -- the content of this MUST conform to the a valid
+ IP version 6 host address, as specified by RFC 3513 [7].
+
+ o <hostContact> -- contains an entity reference specifying a contact
+ associated with this host. The referent MUST be <contact>
+ (Section 3.2.4) results.
+
+
+
+
+Newton & Sanz Standards Track [Page 10]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ o <createdDateTime> -- contains the date and time when this host was
+ created.
+
+ o <lastModificationDateTime> -- contains the date and time when this
+ host was last modified.
+
+ o <lastVerificationDateTime> -- contains the date and time when this
+ data for this host was last verified to be correct by the
+ appropriate registration authority.
+
+ o <iris:seeAlso> -- contains an entity reference specifying a
+ referent indirectly associated with this host.
+
+3.2.4. <contact> Result
+
+ An example of a <contact> result:
+
+ <contact
+ authority="iana.org" registryType="dreg1"
+ entityClass="contact-handle" entityName="dbarton" >
+ <contactHandle>dbarton</contactHandle>
+ <commonName>IANA Manager</commonName>
+ <organization>Internet Assigned Numbers Authority</organization>
+ <eMail>res-dom@iana.org</eMail>
+ <postalAddress>
+ <address>4676 Admiralty Way, Suite 330</address>
+ <city>Marina del Rey</city>
+ <region>CA</region>
+ <postalCode>92092</postalCode>
+ <country>US</country>
+ </postalAddress>
+ <phone>+1.3108239358</phone>
+ </contact>
+
+ The <contact> element represents an instance of a contact
+ registration. The children of the <contact> element are as follows:
+
+ o <contactHandle> -- a registry unique assigned identifier for this
+ contact.
+
+ o <commonName> -- the name of the contact.
+
+ o <language> -- a specification of the language code to use to
+ localize the data in this result.
+
+ o <type> -- contains one of the following child elements: <person>,
+ <organization>, <role>, or <other>. 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 <organization> -- contains the organization name of the contact.
+
+ o <eMail> -- contains an e-mail address for this contact.
+
+ o <IDNeMail> -- contains an e-mail address within an
+ internationalized domain name [14].
+
+ o <sip> -- contains a SIP URI for this contact.
+
+ o <postalAddress> -- contains children representing a postal
+ address. <postalAddress> has the following children:
+ * <address> -- contains the street address for this contact.
+ * <city> -- contains the city for this contact.
+ * <region> -- contains the national region for this contact.
+ * <postalCode> -- contains the postal code for this contact.
+ * <country> -- contains the country for this contact. This
+ SHOULD be a two-letter country code compliant with ISO 3166
+ [11].
+
+ o <phone> -- 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 <fax> -- 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 <createdDateTime> -- contains the date and time when this contact
+ was created.
+
+ o <lastModificationDateTime> -- contains the date and time when this
+ contact was last modified.
+
+ o <lastVerificationDateTime> -- contains the date and time when this
+ data for this contact was last verified to be correct by the
+ appropriate registration authority.
+
+ o <translatedContacts> -- contains an entity reference specifying
+ equivalents of this contact that have been translated into other
+ languages. The referent MUST be <contact> results (Section
+ 3.2.4).
+
+ o <iris:seeAlso> -- 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. <registrationAuthority>
+
+ An example of a <registrationAuthority> result:
+
+ <registrationAuthority
+ authority="iana.org" registryType="dreg1"
+ entityClass="registration-authority" entityName="iana" >
+ <serviceInstance
+ iris:referentType="iris:serviceIdentification"
+ authority="iana.org" registryType="dreg1"
+ entityClass="iris" entityName="id" />
+ <organizationName>
+ Internet Assigned Numbers Authority
+ </organizationName>
+ <registrar />
+ </registrationAuthority>
+
+ The <registrationAuthority> result represents an entity capable of
+ registering domains.
+
+ The <serviceInstance> child element of <registrationAuthority>
+ 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 <organizationName> child element contains the name of the
+ registration authority.
+
+ The registration authority type child elements <registry>,
+ <registrar>, and <other> 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 <serviceInstance>
+ 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., <registry> or <registrar>).
+
+ The <domain> 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. <searchTooWide>
+
+ Servers MAY use the <searchTooWide> 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. <languageNotSupported>
+
+ The queries <findDomainsByRegistrant>, <findDomainsByIDNName>, and
+ <findContacts> 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 <unsupportedLanguage>.
+ 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 <iris:lookupEntity>
+
+ The following types of entity classes are recognized by the
+ <lookupEntity> query of IRIS for this registry:
+
+ o host-name -- The fully qualified domain name of a nameserver. It
+ yields a <host> (Section 3.2.3) in the response.
+
+ o host-handle -- The registry unique identifier given a nameserver.
+ It yields a <host> (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 <domain>
+ (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 <domain> (Section 3.2.2) in the
+ response.
+
+ o domain-handle -- The registry unique identifier given a domain.
+ It yields a <domain> (Section 3.2.2) in the response.
+
+ o contact-handle -- The registry unique identifier given a contact.
+ It yields a <contact> (Section 3.2.4) in the response.
+
+ o ipv4-address -- The IPv4 address of a nameserver. It yields a
+ <host> (Section 3.2.3) in the response.
+
+ o ipv6-address -- The IPv6 address of a nameserver. It yields a
+ <host> (Section 3.2.3) in the response.
+
+ o registration-authority -- The name of a registration authority.
+ It yields a <registrationAuthority> (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.
+
+ <?xml version="1.0"?>
+ <schema xmlns="http://www.w3.org/2001/XMLSchema"
+ xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
+ xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ targetNamespace="urn:ietf:params:xml:ns:dreg1"
+ elementFormDefault="qualified" >
+
+ <import namespace="urn:ietf:params:xml:ns:iris1" />
+
+ <annotation>
+ <documentation>
+ Domain registry schema
+ derived from IRIS schema
+ </documentation>
+ </annotation>
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- Query Types -->
+ <!-- -->
+ <!-- ========================================= -->
+
+ <!-- -->
+ <!-- Find Registrars By Name -->
+ <!-- -->
+
+ <complexType
+ name="findRegistrarsByNameType">
+ <complexContent>
+ <extension
+ base="iris:queryType">
+ <sequence>
+ <element
+ ref="dreg:baseDomain"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="namePart"
+ type="dreg:exactOrPartialMatchParameter"
+
+
+
+Newton & Sanz Standards Track [Page 15]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ minOccurs="0"
+ maxOccurs="1" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="findRegistrarsByName"
+ type="dreg:findRegistrarsByNameType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Domains By Contact -->
+ <!-- -->
+
+ <complexType
+ name="findDomainsByContactType">
+ <complexContent>
+ <extension
+ base="iris:queryType">
+ <sequence>
+ <element
+ ref="dreg:baseDomain"
+ minOccurs="0"
+ maxOccurs="1" />
+ <choice>
+ <group
+ ref="dreg:contactSearchGroup" />
+ <element
+ name="contactHandle"
+ type="dreg:exactMatchParameter" />
+ </choice>
+ <element
+ name="role"
+ minOccurs="0"
+ maxOccurs="1" >
+ <simpleType>
+ <restriction
+ base="string" >
+ <enumeration
+ value="registrant" />
+ <enumeration
+ value="billingContact" />
+ <enumeration
+ value="technicalContact" />
+ <enumeration
+ value="administrativeContact" />
+
+
+
+Newton & Sanz Standards Track [Page 16]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ <enumeration
+ value="legalContact" />
+ <enumeration
+ value="zoneContact" />
+ <enumeration
+ value="abuseContact" />
+ <enumeration
+ value="securityContact" />
+ <enumeration
+ value="otherContact" />
+ </restriction>
+ </simpleType>
+ </element>
+ <element
+ name="language"
+ type="language"
+ minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="findDomainsByContact"
+ type="dreg:findDomainsByContactType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Domains By Name -->
+ <!-- -->
+
+ <complexType
+ name="findDomainsByNameType">
+ <complexContent>
+ <extension
+ base="iris:queryType">
+ <sequence>
+ <element
+ name="namePart"
+ type="dreg:partialMatchParameter" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="findDomainsByName"
+
+
+
+Newton & Sanz Standards Track [Page 17]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ type="dreg:findDomainsByNameType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Domains By Internationalized Name -->
+ <!-- -->
+
+ <complexType
+ name="findDomainsByIDNType">
+ <complexContent>
+ <extension
+ base="iris:queryType">
+ <sequence>
+ <element
+ name="namePart"
+ type="dreg:exactMatchParameter" />
+ <element
+ name="language"
+ type="language"
+ minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="findDomainsByIDN"
+ type="dreg:findDomainsByIDNType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Contacts -->
+ <!-- -->
+
+ <complexType
+ name="findContactsType">
+ <complexContent>
+ <extension
+ base="iris:queryType">
+ <sequence>
+ <group
+ ref="dreg:contactSearchGroup" />
+ <element
+ name="language"
+ type="language"
+ minOccurs="0"
+ maxOccurs="unbounded"/>
+
+
+
+Newton & Sanz Standards Track [Page 18]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="findContacts"
+ type="dreg:findContactsType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Domains By Host -->
+ <!-- -->
+
+ <complexType
+ name="findDomainsByHostType">
+ <complexContent>
+ <extension
+ base="iris:queryType">
+ <sequence>
+ <element
+ ref="dreg:baseDomain"
+ minOccurs="0"
+ maxOccurs="1" />
+ <choice>
+ <element
+ name="hostName"
+ type="dreg:exactMatchParameter" />
+ <element
+ name="hostHandle"
+ type="dreg:exactMatchParameter" />
+ <element
+ name="ipV4Address"
+ type="dreg:exactMatchParameter" />
+ <element
+ name="ipV6Address"
+ type="dreg:exactMatchParameter" />
+ </choice>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="findDomainsByHost"
+ type="dreg:findDomainsByHostType"
+ substitutionGroup="iris:query" />
+
+
+
+
+Newton & Sanz Standards Track [Page 19]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ <!-- -->
+ <!-- Contact Search Group -->
+ <!-- -->
+
+ <group
+ name="contactSearchGroup">
+ <choice>
+ <element
+ name="commonName"
+ type="dreg:exactOrPartialMatchParameter" />
+ <element
+ name="organization"
+ type="dreg:exactOrPartialMatchParameter" />
+ <element
+ name="eMail"
+ type="dreg:domainResourceParameter" />
+ <element
+ name="city"
+ type="dreg:exactMatchParameter" />
+ <element
+ name="region"
+ type="dreg:exactMatchParameter" />
+ <element
+ name="postalCode"
+ type="dreg:exactMatchParameter" />
+ </choice>
+ </group>
+
+ <complexType
+ name="exactOrPartialMatchParameter">
+ <choice>
+ <group
+ ref="dreg:partialMatchGroup" />
+ <group
+ ref="dreg:exactMatchGroup" />
+ </choice>
+ </complexType>
+
+ <complexType
+ name="exactMatchParameter">
+ <group
+ ref="dreg:exactMatchGroup" />
+ </complexType>
+
+ <complexType
+ name="partialMatchParameter">
+ <sequence>
+ <group
+
+
+
+Newton & Sanz Standards Track [Page 20]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ ref="dreg:partialMatchGroup" />
+ </sequence>
+ </complexType>
+
+ <complexType
+ name="domainResourceParameter" >
+ <choice>
+ <group
+ ref="dreg:exactMatchGroup" />
+ <element
+ name="inDomain"
+ type="token" />
+ </choice>
+ </complexType>
+
+ <element
+ name="baseDomain"
+ type="normalizedString" />
+
+ <group
+ name="partialMatchGroup">
+ <choice>
+ <sequence>
+ <element
+ name="beginsWith">
+ <simpleType>
+ <restriction
+ base="token">
+ <minLength
+ value="1"/>
+ </restriction>
+ </simpleType>
+ </element>
+ <element
+ minOccurs="0"
+ name="endsWith">
+ <simpleType>
+ <restriction
+ base="token">
+ <minLength
+ value="1"/>
+ </restriction>
+ </simpleType>
+ </element>
+ </sequence>
+ <element
+ name="endsWith">
+ <simpleType>
+
+
+
+Newton & Sanz Standards Track [Page 21]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ <restriction
+ base="token">
+ <minLength
+ value="1"/>
+ </restriction>
+ </simpleType>
+ </element>
+ </choice>
+ </group>
+
+ <group
+ name="exactMatchGroup">
+ <sequence>
+ <element
+ name="exactMatch"
+ type="normalizedString" />
+ </sequence>
+ </group>
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- Result Types -->
+ <!-- -->
+ <!-- ========================================= -->
+
+ <!-- -->
+ <!-- Domain -->
+ <!-- -->
+
+ <complexType
+ name="domainType">
+ <complexContent>
+ <extension
+ base="iris:resultType">
+ <sequence>
+ <element
+ name="domainName"
+ type="token" />
+ <element
+ name="idn"
+ type="token"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="domainHandle"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+
+
+
+Newton & Sanz Standards Track [Page 22]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ maxOccurs="1" />
+ <element
+ name="nameServer"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="registrant"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="billingContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="technicalContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="administrativeContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="legalContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="zoneContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="abuseContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="securityContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="otherContact"
+
+
+
+Newton & Sanz Standards Track [Page 23]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="lastContactModificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastContactModificationBy"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="status"
+ minOccurs="0"
+ maxOccurs="1">
+ <complexType>
+ <all>
+ <element
+ name="reservedDelegation"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="assignedAndActive"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="assignedAndInactive"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="assignedAndOnHold"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="revoked"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="transferPending"
+ minOccurs="0"
+
+
+
+Newton & Sanz Standards Track [Page 24]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="registryLock"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="registrarLock"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ <element
+ name="other"
+ minOccurs="0"
+ maxOccurs="1"
+ type="dreg:domainStatusType" />
+ </all>
+ </complexType>
+ </element>
+ <element
+ name="domainVariant"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="registrationReference"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="registry"
+ minOccurs="0"
+ maxOccurs="1">
+ <complexType>
+ <complexContent>
+ <extension
+ base="iris:entityType">
+ <attribute
+ name="hosting"
+ type="boolean" />
+ </extension>
+ </complexContent>
+ </complexType>
+ </element>
+ <element
+ name="registrar"
+ minOccurs="0"
+
+
+
+Newton & Sanz Standards Track [Page 25]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ maxOccurs="1">
+ <complexType>
+ <complexContent>
+ <extension
+ base="iris:entityType">
+ <attribute
+ name="hosting"
+ type="boolean" />
+ </extension>
+ </complexContent>
+ </complexType>
+ </element>
+ <element
+ name="initialDelegationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastRenewalDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="expirationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastDelegationModificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastDelegationModificationBy"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastVerificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+
+
+
+Newton & Sanz Standards Track [Page 26]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ ref="iris:seeAlso"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="domain"
+ type="dreg:domainType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Host -->
+ <!-- -->
+
+ <complexType
+ name="hostType">
+ <complexContent>
+ <extension
+ base="iris:resultType">
+ <sequence>
+ <element
+ name="hostHandle"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="hostName"
+ type="normalizedString" />
+ <element
+ name="ipV4Address"
+ type="token"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="ipV6Address"
+ type="token"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="hostContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+
+
+
+Newton & Sanz Standards Track [Page 27]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ name="createdDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastModificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastVerificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ ref="iris:seeAlso"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="host"
+ type="dreg:hostType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Contact -->
+ <!-- -->
+
+ <complexType
+ name="contactType">
+ <complexContent>
+ <extension
+ base="iris:resultType">
+ <sequence>
+ <element
+ name="contactHandle"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+
+
+
+Newton & Sanz Standards Track [Page 28]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ name="commonName"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1"/>
+ <element
+ name="language"
+ type="language"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="type"
+ minOccurs="0"
+ maxOccurs="1">
+ <complexType>
+ <choice>
+ <element
+ name="person"
+ type="dreg:contactTypeType" />
+ <element
+ name="organization"
+ type="dreg:contactTypeType" />
+ <element
+ name="role"
+ type="dreg:contactTypeType" />
+ <element
+ name="other"
+ type="dreg:contactTypeType" />
+ </choice>
+ </complexType>
+ </element>
+ <element
+ name="organization"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="eMail"
+ type="dreg:stringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="IDNeMail"
+ type="dreg:stringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+
+
+
+Newton & Sanz Standards Track [Page 29]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ maxOccurs="unbounded" />
+ <element
+ name="sip"
+ type="dreg:stringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="postalAddress"
+ minOccurs="0"
+ maxOccurs="unbounded" >
+ <complexType>
+ <sequence>
+ <element
+ name="address"
+ type="dreg:stringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="city"
+ type="dreg:stringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="region"
+ type="dreg:stringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="postalCode"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="country"
+ type="dreg:tokenPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ </sequence>
+ </complexType>
+ </element>
+ <element
+ name="phone"
+
+
+
+Newton & Sanz Standards Track [Page 30]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="fax"
+ type="dreg:normalizedStringPrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="createdDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastModificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastVerificationDateTime"
+ type="dreg:dateTimePrivacyType"
+ nillable="true"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="translatedContact"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ ref="iris:seeAlso"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="contact"
+ type="dreg:contactType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+
+
+
+Newton & Sanz Standards Track [Page 31]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ <!-- Registration Authority -->
+ <!-- -->
+
+ <complexType
+ name="registrationAuthorityType">
+ <complexContent>
+ <extension
+ base="iris:resultType">
+ <sequence>
+ <element
+ name="serviceInstance"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="organizationName"
+ type="string"
+ minOccurs="0"
+ maxOccurs="1" />
+ <choice
+ minOccurs="0"
+ maxOccurs="3">
+ <element
+ name="registry">
+ <complexType/>
+ </element>
+ <element
+ name="registrar">
+ <complexType/>
+ </element>
+ <element
+ name="other">
+ <complexType/>
+ </element>
+ </choice>
+ <element
+ name="domain"
+ type="token"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="registrationAuthority"
+ type="dreg:registrationAuthorityType"
+
+
+
+Newton & Sanz Standards Track [Page 32]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Privacy Label Types -->
+ <!-- -->
+
+ <attributeGroup
+ name="privacyLabelAttributeGroup">
+ <attribute
+ name="private"
+ type="boolean" />
+ <attribute
+ name="denied"
+ type="boolean" />
+ <attribute
+ name="doNotRedistribute"
+ type="boolean" />
+ <attribute
+ name="specialAccess"
+ type="boolean" />
+ </attributeGroup>
+
+ <complexType
+ name="dateTimePrivacyType">
+ <simpleContent>
+ <extension
+ base="dateTime">
+ <attributeGroup
+ ref="dreg:privacyLabelAttributeGroup" />
+ </extension>
+ </simpleContent>
+ </complexType>
+
+ <complexType
+ name="stringPrivacyType">
+ <simpleContent>
+ <extension
+ base="string">
+ <attributeGroup
+ ref="dreg:privacyLabelAttributeGroup" />
+ </extension>
+ </simpleContent>
+ </complexType>
+
+ <complexType
+ name="normalizedStringPrivacyType">
+ <simpleContent>
+ <extension
+
+
+
+Newton & Sanz Standards Track [Page 33]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ base="normalizedString">
+ <attributeGroup
+ ref="dreg:privacyLabelAttributeGroup" />
+ </extension>
+ </simpleContent>
+ </complexType>
+
+ <complexType
+ name="tokenPrivacyType">
+ <simpleContent>
+ <extension
+ base="token">
+ <attributeGroup
+ ref="dreg:privacyLabelAttributeGroup" />
+ </extension>
+ </simpleContent>
+ </complexType>
+
+ <complexType
+ name="domainStatusType">
+ <sequence>
+ <element
+ name="appliedDate"
+ type="dateTime"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="description"
+ minOccurs="0"
+ maxOccurs="unbounded">
+ <complexType>
+ <simpleContent>
+ <extension
+ base="string">
+ <attribute
+ name="language"
+ type="language"
+ use="required" />
+ </extension>
+ </simpleContent>
+ </complexType>
+ </element>
+ </sequence>
+ <attributeGroup
+ ref="dreg:privacyLabelAttributeGroup" />
+ <attribute
+ name="scope"
+ type="string" />
+
+
+
+Newton & Sanz Standards Track [Page 34]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ </complexType>
+
+ <complexType
+ name="contactTypeType">
+ <sequence>
+ <element
+ name="description"
+ minOccurs="0"
+ maxOccurs="unbounded">
+ <complexType>
+ <simpleContent>
+ <extension
+ base="string">
+ <attribute
+ name="language"
+ type="language"
+ use="required" />
+ </extension>
+ </simpleContent>
+ </complexType>
+ </element>
+ </sequence>
+ <attributeGroup
+ ref="dreg:privacyLabelAttributeGroup" />
+ </complexType>
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- Error Codes -->
+ <!-- -->
+ <!-- ========================================= -->
+
+ <!-- -->
+ <!-- Search Too Wide -->
+ <!-- -->
+
+ <element
+ name="searchTooWide"
+ type="iris:codeType"
+ substitutionGroup="iris:genericCode" />
+
+ <!-- -->
+ <!-- Language Not Supported -->
+ <!-- -->
+
+ <complexType
+ name="languageNotSupportedType">
+ <complexContent>
+
+
+
+Newton & Sanz Standards Track [Page 35]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ <extension
+ base="iris:codeType">
+ <sequence>
+ <element
+ name="unsupportedLanguage"
+ type="language"
+ minOccurs="1"
+ maxOccurs="unbounded" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="languageNotSupported"
+ type="dreg:languageNotSupportedType"
+ substitutionGroup="iris:genericCode" />
+
+ </schema>
+
+ 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 <language> 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 <language> 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 <andy@hxr.us>
+ * Marcos Sanz <sanz@denic.de>
+ 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, <http://www.w3.org/TR/1998/REC-
+ xml-19980210>.
+
+ [2] World Wide Web Consortium, "Namespaces in XML", W3C XML
+ Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-
+ names-19990114>.
+
+ [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
+ XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
+ xmlschema-2-20010502/>.
+
+ [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
+ XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-
+ xmlschema-1-20010502/>.
+
+ [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] <http://www.unicode.org/reports/tr15/>
+
+
+
+
+
+
+
+
+
+
+
+
+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: <?xml version="1.0"?>
+ C: <request xmlns="urn:ietf:params:xml:ns:iris1"
+ C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
+ C:
+ C: <searchSet>
+ C:
+ C: <lookupEntity
+ C: registryType="urn:ietf:params:xml:ns:dreg1"
+ C: entityClass="domain-name"
+ C: entityName="example.com" />
+ C:
+ C: </searchSet>
+ C:
+ C: </request>
+
+ S: <?xml version="1.0"?>
+ S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ S:
+ S: <iris:resultSet>
+ S: <iris:answer>
+ S:
+ S: <domain xmlns="urn:ietf:params:xml:ns:dreg1"
+ S: authority="iana.org" registryType="dreg1"
+ S: entityClass="domain-handle" entityName="example-com-1">
+ S:
+ S: <domainName>example.com</domainName>
+ S: <domainHandle>tcs-com-1</domainHandle>
+ S:
+ S: <nameServer iris:referentType="host" authority="iana.org"
+ S: registryType="dreg1" entityClass="host-handle"
+ S: entityName="research7" />
+ S:
+ S: <nameServer iris:referentType="host" authority="iana.org"
+ S: registryType="dreg1" entityClass="host-handle"
+ S: entityName="nsol184" />
+
+
+
+Newton & Sanz Standards Track [Page 41]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ S:
+ S: <technicalContact iris:referentType="contact"
+ S: authority="iana.org" registryType="dreg1"
+ S: entityClass="contact-handle" entityName="dbarton" />
+ S:
+ S: <status>
+ S: <assignedAndActive denied="true" />
+ S: </status>
+ S:
+ S: <registry iris:referentType="registrationAuthority"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="contact-handle" entityName="VGRS" />
+ S:
+ S: <initialDelegationDateTime xsi:nil="true"/>
+ S:
+ S: <iris:seeAlso iris:referentType="ANY" authority="iana.org"
+ S: registryType="dreg1" entityClass="local"
+ S: entityName="notice" />
+ S:
+ S: </domain>
+ S:
+ S: </iris:answer>
+ S: </iris:resultSet>
+ S: </iris:response>
+
+ 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: <?xml version="1.0"?>
+ C: <request xmlns="urn:ietf:params:xml:ns:iris1"
+ C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
+ C:
+ C: <searchSet>
+ C:
+ C: <lookupEntity
+ C: registryType="urn:ietf:params:xml:ns:dreg1"
+ C: entityClass="contact-handle"
+ C: entityName="mak21" />
+ C:
+ C: </searchSet>
+ C:
+ C: </request>
+ S: <?xml version="1.0"?>
+
+
+
+Newton & Sanz Standards Track [Page 42]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ S: <response xmlns="urn:ietf:params:xml:ns:iris1"
+ S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ S:
+ S: <resultSet>
+ S: <answer>
+ S:
+ S: <contact xmlns="urn:ietf:params:xml:ns:dreg1"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="contact-handle" entityName="mak21" >
+ S:
+ S: <contactHandle>mak21</contactHandle>
+ S:
+ S: <commonName>
+ S: Mark Kosters
+ S: </commonName>
+ S:
+ S: <organization>
+ S: VeriSign, Inc.
+ S: </organization>
+ S:
+ S: <eMail>markk@verisignlabs.com</eMail>
+ S:
+ S: <phone private="true" xsi:nil="true" />
+ S:
+ S: </contact>
+ S:
+ S: </answer>
+ S: </resultSet>
+ S:
+ S: </response>
+
+ 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: <?xml version="1.0"?>
+ C: <request xmlns="urn:ietf:params:xml:ns:iris1"
+ C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
+ C:
+ C: <searchSet>
+ C:
+ C: <findDomainsByContact
+ C: xmlns="urn:ietf:params:xml:ns:dreg1" >
+ C: <baseDomain>com</baseDomain>
+
+
+
+Newton & Sanz Standards Track [Page 43]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ C: <commonName>
+ C: <beginsWith>
+ C: The Cobbler Shoppe
+ C: </beginsWith>
+ C: </commonName>
+ C: <role>registrant</role>
+ C: </findDomainsByContact>
+ C:
+ C: </searchSet>
+ C:
+ C: </request>
+
+ S: <?xml version="1.0"?>
+ S: <response xmlns="urn:ietf:params:xml:ns:iris1"
+ S: xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ S:
+ S: <resultSet>
+ S: <answer>
+ S: <dreg:domain
+ S: xmlns="urn:ietf:params:xml:ns:dreg1"
+ S: xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="domain-handle" entityName="tcs-com-1" >
+ S: <domainName>example.com</domainName>
+ S: <nameServer
+ S: iris:referentType="dreg:host"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="host-handle" entityName="research7" />
+ S: <nameServer
+ S: iris:referentType="dreg:host"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="host-handle" entityName="nsol184" />
+ S: <registrant
+ S: iris:referentType="dreg:contact"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="contact-handle" entityName="beb140">
+ S: <iris:displayName language="en">
+ S: Bill Eckels
+ S: </iris:displayName>
+ S: </registrant>
+ S: <technicalContact
+ S: bagRef="x1"
+ S: iris:referentType="dreg:contact"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="contact-handle" entityName="mak21">
+ S: <iris:displayName language="en">
+ S: Mark Kosters
+
+
+
+Newton & Sanz Standards Track [Page 44]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ S: </iris:displayName>
+ S: </technicalContact>
+ S: <status>
+ S: <transferPending denied="true" />
+ S: <assignedAndActive denied="true" />
+ S: </status>
+ S: <registry
+ S: iris:referentType="dreg:registrationAuthority"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="local" entityName="VRSN"
+ S: hosting="false" />
+ S: <iris:seeAlso
+ S: iris:referentType="ANY"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="local" entityName="notice" />
+ S: </dreg:domain>
+ S: </answer>
+ S: <additional>
+ S: <dreg:contact
+ S: xmlns="urn:ietf:params:xml:ns:dreg1"
+ S: xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
+ S: authority="com" registryType="dreg1"
+ S: entityClass="contact-handle" entityName="beb140" >
+ S: <contactHandle>beb140</contactHandle>
+ S: <commonName>
+ S: Bill Eckels
+ S: </commonName>
+ S: <language>en</language>
+ S: <type>
+ S: <person>
+ S: <description language="en">
+ S: Bill sells shoes down by the sea shore.
+ S: </description>
+ S: <description language="de">
+ S: Rechnung verkauft Schuhe unten durch das Seeufer.
+ S: </description>
+ S: </person>
+ S: </type>
+ S: <organization>
+ S: The Cobbler Shoppe
+ S: </organization>
+ S: <eMail private="true" xsi:nil="true" />
+ S: <postalAddress>
+ S: <address>
+ S: 21 North Main Street
+ S: </address>
+ S: <city>
+ S: Britt
+
+
+
+Newton & Sanz Standards Track [Page 45]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ S: </city>
+ S: <region>
+ S: IA
+ S: </region>
+ S: <postalCode>
+ S: 50423
+ S: </postalCode>
+ S: <country>
+ S: US
+ S: </country>
+ S: </postalAddress>
+ S: <phone>
+ S: +1.5158433521
+ S: </phone>
+ S: </dreg:contact>
+ S: <simpleEntity
+ S: authority="com" registryType="dreg1"
+ S: entityClass="local" entityName="notice" >
+ S: <property name="legal" language="en">
+ S: It is illegal to use information from this service
+ S: for the purposes of sending unsolicited bulk email.
+ S: </property>
+ S: </simpleEntity>
+ S: </additional>
+ S: </resultSet>
+ S: <bags>
+ S: <bag id="x1">
+ S: <simpleBag xmlns="http://example.com/">
+ S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ
+ S: c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn
+ S: T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48
+ S: Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8=
+ S: </simpleBag>
+ S: </bag>
+ S: </bags>
+ S:
+ S: </response>
+
+ 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.
+
+ <iris:serialization
+ xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+
+ <dreg:domain
+ xmlns="urn:ietf:params:xml:ns:dreg1"
+ authority="com" registryType="dreg1"
+ entityClass="domain-handle" entityName="tcs-com-1" >
+ <domainName>example.com</domainName>
+ <nameServer
+ iris:referentType="dreg:host"
+ authority="" registryType="dreg1"
+ entityClass="host-handle" entityName="research7" />
+ <nameServer
+ iris:referentType="dreg:host"
+ authority="" registryType="dreg1"
+ entityClass="host-handle" entityName="nsol184" />
+ <registrant
+ iris:referentType="dreg:contact"
+ authority="iana.org" registryType="dreg1"
+ entityClass="contact-handle" entityName="beb140" />
+ <technicalContact
+ iris:referentType="dreg:contact"
+ authority="net" registryType="dreg1"
+ entityClass="contact-handle"
+ entityName="mak21" >
+ <iris:displayName language="en">
+ IANA Administrator
+ </iris:displayName>
+ </technicalContact>
+ </dreg:domain>
+
+ <dreg:host
+ xmlns="urn:ietf:params:xml:ns:dreg1"
+ authority="com" registryType="dreg1"
+ entityClass="host-handle" entityName="nsol184" >
+ <hostHandle>nsol184</hostHandle>
+ <hostName>ns1.iana.org</hostName>
+ <ipV4Address>192.0.2.1</ipV4Address>
+ <hostContact
+
+
+
+Newton & Sanz Standards Track [Page 47]
+
+RFC 3982 IRIS-Dreg January 2005
+
+
+ iris:referentType="dreg:contact"
+ authority="com" registryType="dreg1"
+ entityClass="contact-handle"
+ entityName="dbarton" >
+ <iris:displayName language="en">
+ IANA Techie
+ </iris:displayName>
+ </hostContact>
+ </dreg:host>
+
+ <iris:serializedReferral>
+ <iris:source
+ authority="com" registryType="dreg1"
+ entityClass="contact-handle"
+ entityName="dbarton" />
+ <iris:searchContinuation
+ authority="net">
+
+ <dreg:findRegistrarsByName>
+ <dreg:baseDomain>com</dreg:baseDomain>
+ </dreg:findRegistrarsByName>
+
+ </iris:searchContinuation>
+ </iris:serializedReferral>
+
+ </iris:serialization>
+
+ 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]
+