summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5144.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5144.txt')
-rw-r--r--doc/rfc/rfc5144.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5144.txt b/doc/rfc/rfc5144.txt
new file mode 100644
index 0000000..5cfc1c8
--- /dev/null
+++ b/doc/rfc/rfc5144.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group A. Newton
+Request for Comments: 5144 American Registry for Internet Numbers
+Category: Standards Track M. Sanz
+ DENIC eG
+ February 2008
+
+
+ A Domain Availability Check (DCHK) Registry 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.
+
+Abstract
+
+ This document describes a lightweight domain availability service
+ using the Internet Registry Information Service (IRIS) framework and
+ the data model of the IRIS Domain Registry (DREG) service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 1]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Domain Availability Check Registry . . . . . . . . . . . . . . 3
+ 3.1. Schema Description . . . . . . . . . . . . . . . . . . . . 4
+ 3.1.1. The <domain> Result . . . . . . . . . . . . . . . . . 4
+ 3.1.2. Support for <iris:lookupEntity> . . . . . . . . . . . 7
+ 3.2. DCHK Formal XML Syntax . . . . . . . . . . . . . . . . . . 7
+ 3.3. Blocks Extensible Exchange Protocol (BEEP) Transport
+ Compliance . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 3.3.1. Message Pattern . . . . . . . . . . . . . . . . . . . 12
+ 3.3.2. Server Authentication . . . . . . . . . . . . . . . . 12
+ 3.4. URI Resolution . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.4.1. Application Service Label . . . . . . . . . . . . . . 13
+ 3.4.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . 13
+ 3.4.3. Top-Down Resolution . . . . . . . . . . . . . . . . . 13
+ 4. Internationalization Considerations . . . . . . . . . . . . . 13
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1. XML Namespace Registration . . . . . . . . . . . . . . . . 14
+ 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
+ 5.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 14
+ 5.4. BEEP Registration . . . . . . . . . . . . . . . . . . . . 15
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 2]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+1. Introduction
+
+ This document describes a lightweight service for checking the
+ availability of domain names. This service is based on the IRIS
+ framework and uses the data model defined by RFC 3982 [7]. By doing
+ this, the domain availability service has the advantages provided by
+ IRIS and DREG, such as well-known methods for server navigation,
+ structured queries and results, and layered extensibility.
+
+ The use of IRIS for this service also allows seamless integration
+ between the domain availability service and the service provided by
+ DREG. This allows a user to find the availability status of a domain
+ and reference the full registration information in DREG.
+
+ The data model in this service (called a registry schema in IRIS
+ terms) is a strict subset of the DREG data model. This enables
+ implementors to directly reuse DREG code paths and allows operators
+ to deploy the service in either the same server processes as a DREG
+ service (same host and port) or in a different server process
+ (different port) or machine (different host).
+
+ As an example, an operator may wish to deploy both types of service
+ on the same set of machines. As time goes on, the operator may then
+ decide to segregate the services, placing the domain availability
+ service on one set of machines and the DREG service on a separate set
+ of machines with a stricter set of controls. Either deployment
+ scenario is transparent to the end user and always appears to be
+ seamlessly complementary.
+
+ When coupled with [9], this domain availability service is
+ lightweight and extremely efficient for high-volume, public-facing
+ service.
+
+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 RFC 2119 [2].
+
+3. Domain Availability Check Registry
+
+ The data model used for the domain availability check (DCHK) service
+ is a strict subset of the DREG data model. This section describes
+ the DCHK registry type.
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 3]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+3.1. Schema Description
+
+ References to XML elements with no namespace qualifier are from the
+ schema defined in Section 3.2. References to elements and attributes
+ with the "iris" XML namespace qualifier are from the schema defined
+ in IRIS [6].
+
+ The schema present in this document is tied to the protocol version
+ associated with the XML namespace URI defined in Section 5.2.
+ Extensions to the present DCHK schema are allowed, though not
+ recommended, but would require a new version. Please refer to RFC
+ 3981 [6] for more details about versioning the IRIS protocol.
+
+ The descriptions contained within this section refer to XML elements
+ and attributes and their relation to the exchange of data within the
+ protocol. These descriptions also contain specifications outside the
+ scope of the formal XML syntax. Therefore, this section will use
+ terms defined by RFC 2119 [2] to describe the specification outside
+ the scope of the formal XML syntax. While reading this section,
+ please reference Section 3.2 for needed details on the formal XML
+ syntax.
+
+3.1.1. The <domain> Result
+
+ An example of a <domain> result:
+
+ <domain
+ authority="iana.org" registryType="dchk1"
+ entityClass="domain-name" entityName="example.com">
+ <domainName>example.com</domainName>
+ <status><active/></status>
+ </domain>
+
+ <domain> Example
+
+ 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 [1].
+
+ o <idn> - the name of the domain in nameprep form, if applicable.
+ See RFC 3491 [3].
+
+ o <status> - this element may contain child elements representing
+ domain status information. It defines the following status types:
+
+
+
+
+Newton & Sanz Standards Track [Page 4]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ * <active> - available via DNS (either via delegation or direct
+ publication).
+
+ * <inactive> - unavailable via DNS.
+
+ * <dispute> - registrant assignment is in dispute.
+
+ * <addPeriod> - the domain is in the grace period after creation
+ or activation (see RFC 3915 [5]).
+
+ * <renewPeriod> - the domain is in the grace period after renewal
+ (see RFC 3915 [5]).
+
+ * <autoRenewPeriod> - the domain is in the grace period after
+ automatic renewal (see RFC 3915 [5]).
+
+ * <transferPeriod> - the domain is in the grace period after
+ transfer (see RFC 3915 [5]).
+
+ * <redemptionPeriod> - the domain is in the grace period after
+ deletion (see RFC 3915 [5]).
+
+ * <policyCompliant> - the domain is considered compliant
+ according to a given policy specified by the substatus
+ identifier.
+
+ * <policyNoncompliant> - the domain is not considered compliant
+ according to a given policy specified by the substatus
+ identifier.
+
+ * <reserved> - the domain is reserved and is not available for
+ registration under normal registration procedures.
+
+ * <create> - specifies the creation of the domain in the
+ registration system. This status is usually further refined by
+ the disposition attribute.
+
+ * <delete> - specifies the deletion of the domain in the
+ registration system. This status is usually further refined by
+ the disposition attribute.
+
+ * <renew> - specifies the renewal of domain registration. This
+ status is usually further refined by the disposition attribute.
+
+ * <restore> - specifies the restoration to the previous state of
+ the domain before it was deleted. This status is usually
+ further refined by the disposition attribute.
+
+
+
+
+Newton & Sanz Standards Track [Page 5]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ * <transfer> - specifies the transfer of the domain from one
+ responsible or owning entity in the registration system to
+ another. This status is usually further refined by the
+ disposition attribute.
+
+ * <update> - specifies a general modification of the domain
+ information. This status is usually be further refined by the
+ disposition attribute.
+
+ * <other> - specifies a registration system specific status of
+ the domain.
+
+ o <registrationReference> - an element containing an entity
+ reference, the referent of which MUST be either a <domain>
+ (Section 3.1.1) or a <domain> as defined by RFC 3982 [7]. The
+ intent of this element is 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 <createdDateTime> - an element containing the date and time of the
+ creation of this domain.
+
+ o <initialDelegationDateTime> - an element containing the date and
+ time of the initial delegation of this domain.
+
+ o <expirationDateTime> - an element containing the date and time of
+ the expiration of this domain.
+
+ o <lastDatabaseUpdateDateTime> - an element containing the date and
+ time of the last actualization of the database that is the source
+ for this result.
+
+ o <iris:seeAlso> - an element containing an entity reference
+ specifying a referent that is indirectly associated with this
+ domain.
+
+3.1.1.1. Domain Status Type
+
+ Each element of type 'domainStatusType' has the following
+ composition:
+
+ o <appliedDate> - an optional child element containing the date
+ applicable to creation of the status.
+
+ o <ticket> - an optional child element containing a service ticket
+ identifier relevant to the status.
+
+
+
+
+Newton & Sanz Standards Track [Page 6]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ o <description> - zero or more child elements with text to describe
+ the status in natural language. Each of these elements MUST have
+ a 'language' attribute describing the language of the description
+ element.
+
+ o <subStatus> - a child element indicating further status
+ information. Values for this element are not defined by this
+ specification. This child element has a required 'authority'
+ attribute to indicate the origin of the specification of the value
+ of this element.
+
+ o 'actor' - an optional attribute indicating the acting entity for
+ which this status is applied. The values may be "registry",
+ "registrar", or "registrationServiceProvider".
+
+ o 'disposition' - an optional attribute indicating the nature of
+ this status. The values may be "pending" or "prohibited".
+
+ o 'scope' - an optional attribute indicating the context or origin
+ of the status value.
+
+3.1.2. Support for <iris:lookupEntity>
+
+ The following types of entity classes are recognized by the
+ <lookupEntity> query of IRIS for this registry:
+
+ o domain-name - the fully qualified name of a domain. This is a
+ domain name as specified by RFC 1035 [1]. Yields a <domain>
+ (Section 3.1.1) in the response.
+
+ o idn - the fully qualified name of a domain in nameprep form (see
+ RFC 3491 [3]). Yields a <domain> (Section 3.1.1) in the response.
+
+3.2. DCHK Formal XML Syntax
+
+ This registry schema is specified in the XML Schema notation (see
+ [10] and [11]). The formal syntax presented here is a complete
+ schema representation 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:dchk="urn:ietf:params:xml:ns:dchk1"
+ xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ targetNamespace="urn:ietf:params:xml:ns:dchk1"
+ elementFormDefault="qualified" >
+
+
+
+
+
+Newton & Sanz Standards Track [Page 7]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ <import namespace="urn:ietf:params:xml:ns:iris1" />
+
+ <annotation>
+ <documentation>
+ Domain availability check schema
+ derived from IRIS schema
+ </documentation>
+ </annotation>
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- 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="status"
+ minOccurs="0"
+ maxOccurs="1">
+ <complexType>
+ <choice minOccurs="0" maxOccurs="unbounded">
+ <element
+ name="active"
+ type="dchk:domainStatusType" />
+ <element
+ name="inactive"
+ type="dchk:domainStatusType" />
+ <element
+ name="dispute"
+ type="dchk:domainStatusType" />
+ <element
+
+
+
+Newton & Sanz Standards Track [Page 8]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ name="renew"
+ type="dchk:domainStatusType" />
+ <element
+ name="addPeriod"
+ type="dchk:domainStatusType" />
+ <element
+ name="renewPeriod"
+ type="dchk:domainStatusType" />
+ <element
+ name="autoRenewPeriod"
+ type="dchk:domainStatusType" />
+ <element
+ name="transferPeriod"
+ type="dchk:domainStatusType" />
+ <element
+ name="redemptionPeriod"
+ type="dchk:domainStatusType" />
+ <element
+ name="restore"
+ type="dchk:domainStatusType" />
+ <element
+ name="policyCompliant"
+ type="dchk:domainStatusType" />
+ <element
+ name="policyNoncompliant"
+ type="dchk:domainStatusType" />
+ <element
+ name="reserved"
+ type="dchk:domainStatusType" />
+ <element
+ name="create"
+ type="dchk:domainStatusType" />
+ <element
+ name="delete"
+ type="dchk:domainStatusType" />
+ <element
+ name="transfer"
+ type="dchk:domainStatusType" />
+ <element
+ name="update"
+ type="dchk:domainStatusType" />
+ <element
+ name="other"
+ type="dchk:domainStatusType" />
+ </choice>
+ </complexType>
+ </element>
+ <element
+
+
+
+Newton & Sanz Standards Track [Page 9]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ name="registrationReference"
+ type="iris:entityType"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="createdDateTime"
+ type="dateTime"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="initialDelegationDateTime"
+ type="dateTime"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="expirationDateTime"
+ type="dateTime"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="lastDatabaseUpdateDateTime"
+ type="dateTime"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ ref="iris:seeAlso"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element
+ name="domain"
+ type="dchk:domainType"
+ substitutionGroup="iris:result" />
+
+ <complexType
+ name="domainStatusType">
+ <sequence>
+ <element
+ name="appliedDate"
+ type="dateTime"
+ minOccurs="0"
+ maxOccurs="1" />
+ <element
+ name="ticket"
+
+
+
+Newton & Sanz Standards Track [Page 10]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ type="token"
+ minOccurs="0"
+ maxOccurs="unbounded" />
+ <element
+ name="description"
+ minOccurs="0"
+ maxOccurs="unbounded">
+ <complexType>
+ <simpleContent>
+ <extension
+ base="string">
+ <attribute
+ name="language"
+ type="language"
+ use="required" />
+ </extension>
+ </simpleContent>
+ </complexType>
+ </element>
+ <element
+ name="subStatus"
+ minOccurs="0"
+ maxOccurs="1">
+ <complexType>
+ <simpleContent>
+ <extension
+ base="token">
+ <attribute
+ type="token"
+ use="required"
+ name="authority"/>
+ </extension>
+ </simpleContent>
+ </complexType>
+ </element>
+ </sequence>
+ <attribute
+ name="actor">
+ <simpleType>
+ <restriction
+ base="string">
+ <enumeration
+ value="registry"/>
+ <enumeration
+ value="registrar"/>
+ <enumeration
+ value="registrationServiceProvider"/>
+ </restriction>
+
+
+
+Newton & Sanz Standards Track [Page 11]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ </simpleType>
+ </attribute>
+ <attribute
+ name="disposition">
+ <simpleType>
+ <restriction
+ base="string">
+ <enumeration
+ value="prohibited"/>
+ <enumeration
+ value="pending"/>
+ </restriction>
+ </simpleType>
+ </attribute>
+ <attribute
+ name="scope"
+ type="token" />
+ </complexType>
+ </schema>
+
+ Figure 1: dchk.xsd
+
+3.3. Blocks Extensible Exchange Protocol (BEEP) Transport Compliance
+
+ All DCHK clients and servers MUST implement the Lightweight UDP
+ Transport Protocol (IRIS-LWZ) [9]. The use of other transports like
+ the XML Pipelining with Chunks (IRIS-XPC) transport [12] or the BEEP
+ transport [8] is optional and completely at the discretion of the
+ server operator. The XPC transport is in any case preferable to the
+ BEEP transport.
+
+ IRIS allows several extensions of the core capabilities. This
+ section outlines those extensions allowable by IRIS-BEEP [8].
+
+3.3.1. Message Pattern
+
+ This registry type uses the default message pattern as described in
+ IRIS-BEEP [8].
+
+3.3.2. Server Authentication
+
+ This registry type uses the default server authentication method as
+ described in IRIS-BEEP [8].
+
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 12]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+3.4. URI Resolution
+
+3.4.1. Application Service Label
+
+ The application service label associated with this registry type MUST
+ be "DCHK1". This is the abbreviated form of the URN for this
+ registry type, urn:ietf:params:xml:ns:dchk1.
+
+3.4.2. Bottom-Up Resolution
+
+ The bottom-up alternative resolution method MUST be identified as
+ 'bottom' in IRIS URI's. Its process is identical to the 'bottom'
+ process described by RFC 3982 [7].
+
+3.4.3. Top-Down Resolution
+
+ The top-down alternative resolution method MUST be identified as
+ 'top' in IRIS URI's. Its process is identical to the 'top' process
+ described by RFC 3982 [7].
+
+4. Internationalization Considerations
+
+ Implementors should be aware of considerations for
+ internationalization in IRIS [6].
+
+ Clients needing to localize the data tags in this protocol should
+ take 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 those elements containing
+ date and time information.
+
+ Clients should also make use of the <language> elements provided in
+ many of the results. Results containing internationalized data can
+ be accompanied by these elements in order to aid better localization
+ of the data by the user.
+
+ All date and time elements make use of the XML Schema [10] data type
+ "dateTime". If their contents are Coordinated Universal Time (UTC)
+ timestamps, they MUST be specified by using the capitalized 'Z'
+ indicator (instead of 'z').
+
+
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 13]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+5. IANA Considerations
+
+5.1. XML Namespace Registration
+
+ This document makes use of the XML registry specified in RFC 3688
+ [4]. Accordingly, IANA has made the following registration:
+
+ o XML Namespace URN/URI:
+
+ * urn:ietf:params:xml:ns:dchk1
+
+ o Contact:
+
+ * Andrew Newton <andy@hxr.us>
+
+ * Marcos Sanz <sanz@denic.de>
+
+ o XML:
+
+ * None.
+
+5.2. XML Schema Registration
+
+ This document makes use of the XML registry specified in RFC 3688
+ [4]. Accordingly, IANA has made the following registration:
+
+ o XML Schema URN/URI:
+
+ * urn:ietf:params:xml:schema:dchk1
+
+ o Contact:
+
+ * Andrew Newton <andy@hxr.us>
+
+ * Marcos Sanz <sanz@denic.de>
+
+ o XML:
+
+ * The XML Schema specified in Section 3.2
+
+5.3. S-NAPTR Registration
+
+ The following Sraightforwarad-NAPTR (S-NAPTR) application service
+ label has been registered with IANA according to the IANA
+ considerations defined in IRIS [6]:
+
+ DCHK1
+
+
+
+
+Newton & Sanz Standards Track [Page 14]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+5.4. BEEP Registration
+
+ The following BEEP Profile URI has been registered with IANA, in
+ addition to the registration provided in IRIS-BEEP [8].
+
+ http://iana.org/beep/iris1/dchk1
+
+6. Security Considerations
+
+ Being a proper subset of RFC 3982 [7], the registry described in this
+ document introduces no security considerations beyond those
+ documented in RFC 3981 [6].
+
+7. References
+
+7.1. Normative References
+
+ [1] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
+ for Internationalized Domain Names (IDN)", RFC 3491,
+ March 2003.
+
+ [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ January 2004.
+
+ [5] Hollenbeck, S., "Domain Registry Grace Period Mapping for the
+ Extensible Provisioning Protocol (EPP)", RFC 3915,
+ September 2004.
+
+ [6] Newton, A. and M. Sanz, "IRIS: The Internet Registry
+ Information Service (IRIS) Core Protocol", RFC 3981,
+ January 2005.
+
+ [7] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type
+ for the Internet Registry Information Service (IRIS)",
+ RFC 3982, January 2005.
+
+ [8] Newton, A. and M. Sanz, "Using the Internet Registry
+ Information Service (IRIS) over the Blocks Extensible Exchange
+ Protocol (BEEP)", RFC 3983, January 2005.
+
+ [9] Newton, A., "A Lightweight UDP Transfer Protocol for the
+ Internet Registry Information Service", RFC 4993, August 2007.
+
+
+
+Newton & Sanz Standards Track [Page 15]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+ [10] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
+ W3C XML Schema, October 2004,
+ <http://www.w3.org/TR/xmlschema-2/>.
+
+ [11] World Wide Web Consortium, "XML Schema Part 1: Structures",
+ W3C XML Schema, October 2004,
+ <http://www.w3.org/TR/xmlschema-1/>.
+
+7.2. Informative References
+
+ [12] Newton, A., "XML Pipelining with Chunks for the Internet
+ Registry Information Service", RFC 4992, August 2007.
+
+Authors' Addresses
+
+ Andrew L. Newton
+ American Registry for Internet Numbers
+ 3635 Concorde Parkway, Suite 200
+ Chantilly, VA 20151
+ USA
+
+ Phone: +1 703 227 9884
+ EMail: andy@arin.net
+ URI: http://www.arin.net/
+
+
+ Marcos Sanz
+ DENIC eG
+ Kaiserstrasse 75-77
+ D-60329 Frankfurt
+ Germany
+
+ EMail: sanz@denic.de
+ URI: http://www.denic.de/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 16]
+
+RFC 5144 IRIS-DCHK February 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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 procedures with respect to rights in RFC 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Newton & Sanz Standards Track [Page 17]
+