draft-ietf-crisp-iris-dchk-08.txt   draft-ietf-crisp-iris-dchk-09.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Standards Track M. Sanz Intended status: Standards Track M. Sanz
Expires: April 30, 2008 DENIC eG Expires: May 17, 2008 DENIC eG
Oct 28, 2007 Nov 14, 2007
A Domain Availability Check (DCHK) Registry Type for the Internet A Domain Availability Check (DCHK) Registry Type for the Internet
Registry Information Service (IRIS) Registry Information Service (IRIS)
draft-ietf-crisp-iris-dchk-08 draft-ietf-crisp-iris-dchk-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2008. This Internet-Draft will expire on May 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a lightweight domain availability service This document describes a lightweight domain availability service
using the Internet Registry Information Service (IRIS) framework and using the Internet Registry Information Service (IRIS) framework and
the data model of the IRIS Domain Registry (DREG) service. the data model of the IRIS Domain Registry (DREG) service.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4
3. Domain Availability Check Registry . . . . . . . . . . . . . . 5 3. Domain Availability Check Registry . . . . . . . . . . . . . . 5
3.1. Schema Description . . . . . . . . . . . . . . . . . . . . 5 3.1. Schema Description . . . . . . . . . . . . . . . . . . . . 5
3.1.1. The <domain> Result . . . . . . . . . . . . . . . . . 5 3.1.1. The <domain> Result . . . . . . . . . . . . . . . . . 5
3.1.2. Support for <iris:lookupEntity> . . . . . . . . . . . 8 3.1.2. Support for <iris:lookupEntity> . . . . . . . . . . . 8
3.2. DCHK Formal XML Syntax . . . . . . . . . . . . . . . . . . 8 3.2. DCHK Formal XML Syntax . . . . . . . . . . . . . . . . . . 8
3.3. BEEP Transport Compliance . . . . . . . . . . . . . . . . 13 3.3. BEEP Transport Compliance . . . . . . . . . . . . . . . . 13
3.3.1. Message Pattern . . . . . . . . . . . . . . . . . . . 13 3.3.1. Message Pattern . . . . . . . . . . . . . . . . . . . 13
3.3.2. Server Authentication . . . . . . . . . . . . . . . . 13 3.3.2. Server Authentication . . . . . . . . . . . . . . . . 13
3.4. URI Resolution . . . . . . . . . . . . . . . . . . . . . . 13 3.4. URI Resolution . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Application Service Label . . . . . . . . . . . . . . 13 3.4.1. Application Service Label . . . . . . . . . . . . . . 14
3.4.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . 14 3.4.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . 14
3.4.3. Top-Down Resolution . . . . . . . . . . . . . . . . . 14 3.4.3. Top-Down Resolution . . . . . . . . . . . . . . . . . 14
4. Internationalization Considerations . . . . . . . . . . . . . 15 4. Internationalization Considerations . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5.1. XML Namespace Registration . . . . . . . . . . . . . . . . 16 5.1. XML Namespace Registration . . . . . . . . . . . . . . . . 16
5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 16 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 16
5.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 16 5.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 16
5.4. BEEP Registration . . . . . . . . . . . . . . . . . . . . 17 5.4. BEEP Registration . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 34 skipping to change at page 3, line 34
(different port) or machine (different host). (different port) or machine (different host).
As an example, an operator may wish to deploy both types of service 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 on the same set of machines. As time goes on, the operator may then
decide to segregate the services, placing the domain availability decide to segregate the services, placing the domain availability
service on one set of machines and the DREG service on a separate set service on one set of machines and the DREG service on a separate set
of machines with a stricter set of controls. Either deployment of machines with a stricter set of controls. Either deployment
scenario is transparent to the end user and always appear to be scenario is transparent to the end user and always appear to be
seamlessly complementary. seamlessly complementary.
When coupled with [11], this domain availability service is When coupled with [9], this domain availability service is
lightweight and extremely efficient for high-volume, public-facing lightweight and extremely efficient for high-volume, public-facing
service. service.
2. Document Terminology 2. Document Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. document are to be interpreted as described in RFC2119 [2].
3. Domain Availability Check Registry 3. Domain Availability Check Registry
skipping to change at page 5, line 18 skipping to change at page 5, line 18
is a strict subset of the DREG data model. This section describes is a strict subset of the DREG data model. This section describes
the DCHK registry type. the DCHK registry type.
3.1. Schema Description 3.1. Schema Description
References to XML elements with no namespace qualifier are from the References to XML elements with no namespace qualifier are from the
schema defined in Section 3.2. References to elements and attributes schema defined in Section 3.2. References to elements and attributes
with the "iris" XML namespace qualifier are from the schema defined with the "iris" XML namespace qualifier are from the schema defined
in IRIS [6]. in IRIS [6].
The schema present in this document is tied to the protocol version
associated to 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
RFC3981 [6] for more details about versioning the IRIS protocol.
The descriptions contained within this section refer to XML elements The descriptions contained within this section refer to XML elements
and attributes and their relation to the exchange of data within the and attributes and their relation to the exchange of data within the
protocol. These descriptions also contain specifications outside the protocol. These descriptions also contain specifications outside the
scope of the formal XML syntax. Therefore, this section will use scope of the formal XML syntax. Therefore, this section will use
terms defined by RFC 2119 [2] to describe the specification outside terms defined by RFC 2119 [2] to describe the specification outside
the scope of the formal XML syntax. While reading this section, the scope of the formal XML syntax. While reading this section,
please reference Section 3.2 for needed details on the formal XML please reference Section 3.2 for needed details on the formal XML
syntax. syntax.
3.1.1. The <domain> Result 3.1.1. The <domain> Result
skipping to change at page 8, line 35 skipping to change at page 8, line 40
o domain-name - the fully qualified name of a domain. This a domain o domain-name - the fully qualified name of a domain. This a domain
name as specified by RFC 1035 [1]. Yields a <domain> name as specified by RFC 1035 [1]. Yields a <domain>
(Section 3.1.1) in the response. (Section 3.1.1) in the response.
o idn - the fully qualified name of a domain in nameprep form (see 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. RFC 3491 [3]). Yields a <domain> (Section 3.1.1) in the response.
3.2. DCHK Formal XML Syntax 3.2. DCHK Formal XML Syntax
This registry schema is specified in the XML Schema notation (see [9] This registry schema is specified in the XML Schema notation (see
and [10]). The formal syntax presented here is a complete schema [10] and [11]). The formal syntax presented here is a complete
representation suitable for automated validation of an XML instance schema representation suitable for automated validation of an XML
when combined with the formal schema syntax of IRIS. instance when combined with the formal schema syntax of IRIS.
<?xml version="1.0"?> <?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" <schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dchk="urn:ietf:params:xml:ns:dchk1" xmlns:dchk="urn:ietf:params:xml:ns:dchk1"
xmlns:iris="urn:ietf:params:xml:ns:iris1" xmlns:iris="urn:ietf:params:xml:ns:iris1"
targetNamespace="urn:ietf:params:xml:ns:dchk1" targetNamespace="urn:ietf:params:xml:ns:dchk1"
elementFormDefault="qualified" > elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" /> <import namespace="urn:ietf:params:xml:ns:iris1" />
<annotation> <annotation>
<documentation> <documentation>
Domain availability check schema Domain availability check schema
derived from IRIS schema derived from IRIS schema
</documentation> </documentation>
</annotation> </annotation>
<!-- ========================================= --> <!-- ========================================= -->
skipping to change at page 13, line 23 skipping to change at page 13, line 28
<attribute <attribute
name="scope" name="scope"
type="token" /> type="token" />
</complexType> </complexType>
</schema> </schema>
Figure 2: dchk.xsd Figure 2: dchk.xsd
3.3. BEEP Transport Compliance 3.3. BEEP Transport Compliance
Though it is envisioned that a DCHK service will be deployed with a All DCHK client and servers MUST implement the Lightweight UDP
lightweight transport such as [11], it is still possible to use DCHK Transport Protocol (IRIS-LWZ) [9]. The use of other transports like
with the BEEP transport [8]. The use of this transport is completely the XML Pipelining with Chunks (IRIS-XPC) transport [12] or the BEEP
at the discretion of the server operator. 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 IRIS allows several extensions of the core capabilities. This
section outlines those extensions allowable by IRIS-BEEP [8]. section outlines those extensions allowable by IRIS-BEEP [8].
3.3.1. Message Pattern 3.3.1. Message Pattern
This registry type uses the default message pattern as described in This registry type uses the default message pattern as described in
IRIS-BEEP [8]. IRIS-BEEP [8].
3.3.2. Server Authentication 3.3.2. Server Authentication
skipping to change at page 15, line 23 skipping to change at page 15, line 23
date and time information. The schema for this registry has been date and time information. The schema for this registry has been
designed so that clients need not interpret the content of elements designed so that clients need not interpret the content of elements
or attributes for localization, other than those elements containing or attributes for localization, other than those elements containing
date and time information. date and time information.
Clients should also make use of the <language> elements provided in Clients should also make use of the <language> elements provided in
many of the results. Results containing internationalized data can many of the results. Results containing internationalized data can
be accompanied by these elements in order to aid better localization be accompanied by these elements in order to aid better localization
of the data by the user of the data by the user
All date and time elements make use of the XML Schema [9] data type All date and time elements make use of the XML Schema [10] data type
"dateTime". If their contents are Coordinated Universal Time (UTC) "dateTime". If their contents are Coordinated Universal Time (UTC)
timestamps, they MUST be specified by using the capitalized 'Z' timestamps, they MUST be specified by using the capitalized 'Z'
indicator (instead of 'z'). indicator (instead of 'z').
5. IANA Considerations 5. IANA Considerations
5.1. XML Namespace Registration 5.1. XML Namespace Registration
This document makes use of the XML registry specified in RFC 3688 This document makes use of the XML registry specified in RFC 3688
[4]. Accordingly, the following registration information is provided [4]. Accordingly, the following registration information is provided
skipping to change at page 19, line 38 skipping to change at page 19, line 38
January 2005. January 2005.
[7] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type [7] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type
for the Internet Registry Information Service (IRIS)", for the Internet Registry Information Service (IRIS)",
RFC 3982, January 2005. RFC 3982, January 2005.
[8] Newton, A. and M. Sanz, "Using the Internet Registry [8] Newton, A. and M. Sanz, "Using the Internet Registry
Information Service (IRIS) over the Blocks Extensible Exchange Information Service (IRIS) over the Blocks Extensible Exchange
Protocol (BEEP)", RFC 3983, January 2005. Protocol (BEEP)", RFC 3983, January 2005.
[9] World Wide Web Consortium, "XML Schema Part 2: Datatypes", [9] Newton, A., "A Lightweight UDP Transfer Protocol for the
Internet Registry Information Service", RFC 4993, August 2007.
[10] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
W3C XML Schema, October 2004, W3C XML Schema, October 2004,
<http://www.w3.org/TR/xmlschema-2/>. <http://www.w3.org/TR/xmlschema-2/>.
[10] World Wide Web Consortium, "XML Schema Part 1: Structures", [11] World Wide Web Consortium, "XML Schema Part 1: Structures",
W3C XML Schema, October 2004, W3C XML Schema, October 2004,
<http://www.w3.org/TR/xmlschema-1/>. <http://www.w3.org/TR/xmlschema-1/>.
7.2. Informative References 7.2. Informative References
[11] Newton, A., "A Lightweight UDP Transfer Protocol for the [12] Newton, A., "XML Pipelining with Chunks for the Internet
Internet Registry Information Service", RFC 4993, August 2007. Registry Information Service", RFC 4992, August 2007.
Authors' Addresses Authors' Addresses
Andrew L. Newton Andrew L. Newton
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Sterling, VA 20166 Sterling, VA 20166
USA USA
Phone: +1 703 948 3382 Phone: +1 703 948 3382
 End of changes. 13 change blocks. 
20 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/