[要約] RFC 5144は、IRISのためのドメインの可用性チェック（DCHK）レジストリタイプに関する規格であり、IRISを使用してドメインの可用性を確認するための方法を提供します。このRFCの目的は、ドメインの可用性情報を効率的に取得し、インターネットのドメイン名システムの運用を向上させることです。
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)
インターネットレジストリ情報サービス（IRIS）のドメイン可用性チェック（DCHK）レジストリタイプ
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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.
このドキュメントでは、Internet Registry Information Service（IRIS）フレームワークとIRISドメインレジストリ（DREG）サービスのデータモデルを使用した軽量ドメイン可用性サービスについて説明します。
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
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.
このドキュメントでは、ドメイン名の可用性をチェックするための軽量サービスについて説明します。このサービスはIRISフレームワークに基づいており、RFC 3982 [7]で定義されたデータモデルを使用しています。これを行うことにより、サーバーナビゲーションのよく知られた方法、構造化クエリと結果、階層化された拡張性など、IRISとDREGが提供するドメイン可用性サービスには利点があります。
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.
このサービスにIRISを使用すると、ドメイン可用性サービスとDREGが提供するサービス間のシームレスな統合も可能になります。これにより、ユーザーはドメインの可用性ステータスを見つけて、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).
このサービスのデータモデル（IRIS用語のレジストリスキーマと呼ばれる）は、DREGデータモデルの厳格なサブセットです。これにより、実装者はDREGコードパスを直接再利用でき、オペレーターはDREGサービス（同じホストおよびポート）と同じサーバープロセスまたは異なるサーバープロセス（異なるポート）またはマシン（異なるホスト）のいずれかでサービスを展開できます。
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.
例として、オペレーターは同じマシンのセットに両方のタイプのサービスを展開したい場合があります。時間が経つにつれて、オペレーターはサービスを分離し、ドメイン可用性サービスを1つのマシンに、DREGサービスをより厳格なコントロールセットのある個別のマシンに配置することを決定する場合があります。どちらの展開シナリオもエンドユーザーに対して透明であり、常にシームレスに補完的であるように見えます。
When coupled with [9], this domain availability service is lightweight and extremely efficient for high-volume, public-facing service.
[9]と組み合わせると、このドメイン可用性サービスは軽量で、大量の公開サービスに非常に効率的です。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。
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.
ドメイン可用性チェック（DCHK）サービスに使用されるデータモデルは、DREGデータモデルの厳格なサブセットです。このセクションでは、DCHKレジストリタイプについて説明します。
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].
名前空間予選のないXML要素への参照は、セクション3.2で定義されているスキーマからのものです。「IRIS」XML Namespace予選を使用した要素と属性への参照は、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.
このドキュメントに存在するスキーマは、セクション5.2で定義されているXMLネームスペースURIに関連付けられたプロトコルバージョンに関連付けられています。現在のDCHKスキーマへの拡張は許可されていますが、推奨されませんが、新しいバージョンが必要です。IRISプロトコルのバージョン化の詳細については、RFC 3981 [6]を参照してください。
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.
このセクションに含まれる説明は、XML要素と属性、およびプロトコル内のデータ交換との関係を参照しています。これらの説明には、正式なXML構文の範囲外の仕様も含まれています。したがって、このセクションでは、RFC 2119 [2]で定義された用語を使用して、正式なXML構文の範囲外の仕様を説明します。このセクションを読んでいる間、正式なXML構文の必要な詳細については、セクション3.2を参照してください。
An example of a <domain> result:
<domain>結果の例：
<domain
authority="iana.org" registryType="dchk1"
entityClass="domain-name" entityName="example.com">
<domainName>example.com</domainName>
<status><active/></status>
</domain>
<domain> Example
<domain>の例
The <domain> result represents an instance of a domain assignment. The children of the <domain> element are as follows:
<domain>結果は、ドメイン割り当てのインスタンスを表します。<domain>要素の子供は次のとおりです。
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 <domainname> - DNSのドメインのフルネーム。この要素の内容は、RFC 1035 [1]で指定されているドメイン名でなければなりません。
o <idn> - the name of the domain in nameprep form, if applicable. See RFC 3491 [3].
o <idn> - 該当する場合は、nameprep形式のドメインの名前。RFC 3491 [3]を参照してください。
o <status> - this element may contain child elements representing domain status information. It defines the following status types:
o <ステータス> - この要素には、ドメインステータス情報を表す子要素が含まれる場合があります。次のステータスタイプを定義します。
* <active> - available via DNS (either via delegation or direct publication).
* <Active> - DNS経由で利用可能（委任または直接発行のいずれか）。
* <inactive> - unavailable via DNS.
* <Inactive> - DNSで利用できません。
* <dispute> - registrant assignment is in dispute.
* <ippis> - 登録者の割り当ては論争中です。
* <addPeriod> - the domain is in the grace period after creation or activation (see RFC 3915 [5]).
* <AddPerioD> - ドメインは、作成または活性化後の猶予期間です（RFC 3915 [5]を参照）。
* <renewPeriod> - the domain is in the grace period after renewal (see RFC 3915 [5]).
* <neledperiod> - ドメインは更新後の猶予期間です（RFC 3915 [5]を参照）。
* <autoRenewPeriod> - the domain is in the grace period after automatic renewal (see RFC 3915 [5]).
* <autorenewperiod> - ドメインは自動更新後の猶予期間にあります（RFC 3915 [5]を参照）。
* <transferPeriod> - the domain is in the grace period after transfer (see RFC 3915 [5]).
* <TransferPeriod> - ドメインは、転送後の猶予期間です（RFC 3915 [5]を参照）。
* <redemptionPeriod> - the domain is in the grace period after deletion (see RFC 3915 [5]).
* <RedemptionPeriod> - ドメインは削除後の猶予期間です（RFC 3915 [5]を参照）。
* <policyCompliant> - the domain is considered compliant according to a given policy specified by the substatus identifier.
* <PolicyCompliant> - Subsatus Identifierによって指定された特定のポリシーに従ってドメインは準拠していると見なされます。
* <policyNoncompliant> - the domain is not considered compliant according to a given policy specified by the substatus identifier.
* <PolicyNonCompliant> - Subsatus Identifierによって指定された特定のポリシーに従ってドメインは準拠しているとは見なされません。
* <reserved> - the domain is reserved and is not available for registration under normal registration procedures.
* <Reserved> - ドメインは予約されており、通常の登録手順に基づいて登録には利用できません。
* <create> - specifies the creation of the domain in the registration system. This status is usually further refined by the disposition attribute.
* <create> - 登録システムでドメインの作成を指定します。このステータスは通常、気質属性によってさらに洗練されます。
* <delete> - specifies the deletion of the domain in the registration system. This status is usually further refined by the disposition attribute.
* <delete> - 登録システムのドメインの削除を指定します。このステータスは通常、気質属性によってさらに洗練されます。
* <renew> - specifies the renewal of domain registration. This status is usually further refined by the disposition attribute.
* <rening> - ドメイン登録の更新を指定します。このステータスは通常、気質属性によってさらに洗練されます。
* <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.
* <Restore> - 削除される前に、ドメインの前の状態の復元を指定します。このステータスは通常、気質属性によってさらに洗練されます。
* <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.
* <update> - ドメイン情報の一般的な変更を指定します。このステータスは通常、気質属性によってさらに洗練されます。
* <other> - specifies a registration system specific status of the domain.
* <other> - ドメインの登録システム固有のステータスを指定します。
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 <登録提案> - エンティティリファレンスを含む要素。その指示対象は、RFC 3982 [7]で定義されている<ドメイン>（セクション3.1.1）または<ドメイン>でなければなりません。この要素の意図は、ダウンストリーム登録リファレンスを指すことです。したがって、これがドメインレジストリによって返された結果である場合、ドメインレジストラまたは登録者サービスのドメインを指す必要があります。
o <createdDateTime> - an element containing the date and time of the creation of this domain.
o
o <initialDelegationDateTime> - an element containing the date and time of the initial delegation of this domain.
o <InitialDelegationDateTime> - このドメインの最初の委任の日付と時刻を含む要素。
o <expirationDateTime> - an element containing the date and time of the expiration of this domain.
o <ExpirationDateTime> - このドメインの有効期限の日付と時刻を含む要素。
o <lastDatabaseUpdateDateTime> - an element containing the date and time of the last actualization of the database that is the source for this result.
o
o <iris:seeAlso> - an element containing an entity reference specifying a referent that is indirectly associated with this domain.
o <iris：seealso> - このドメインに間接的に関連付けられている指示対象を指定するエンティティ参照を含む要素。
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 <AppliedDate> - ステータスの作成に適用される日付を含むオプションの子要素。
o <ticket> - an optional child element containing a service ticket identifier relevant to the status.
o <ticket> - ステータスに関連するサービスチケット識別子を含むオプションの子要素。
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 <説明> - 自然言語のステータスを説明するテキストを備えたゼロ以上の子要素。これらの各要素には、説明要素の言語を記述する「言語」属性が必要です。
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 <Subratus> - さらなるステータス情報を示す子要素。この要素の値は、この仕様では定義されていません。この子要素には、この要素の値の仕様の起源を示すために必要な「権限」属性があります。
o 'actor' - an optional attribute indicating the acting entity for which this status is applied. The values may be "registry", "registrar", or "registrationServiceProvider".
o 「Actor」 - このステータスが適用される演技エンティティを示すオプションの属性。値は、「レジストリ」、「レジストラ」、または「登録サービスプロバイダー」です。
o 'disposition' - an optional attribute indicating the nature of this status. The values may be "pending" or "prohibited".
o 「処分」 - このステータスの性質を示すオプションの属性。値は「保留中」または「禁止」される場合があります。
o 'scope' - an optional attribute indicating the context or origin of the status value.
o 「スコープ」 - ステータス値のコンテキストまたは原点を示すオプションの属性。
The following types of entity classes are recognized by the <lookupEntity> query of IRIS for this registry:
次のタイプのエンティティクラスは、このレジストリの虹彩の<lookupentity>クエリによって認識されます。
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 ドメイン名 - ドメインの完全に適格な名前。これは、RFC 1035 [1]で指定されているドメイン名です。応答で<ドメイン>（セクション3.1.1）を生成します。
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.
o IDN -NAMEPREP形式のドメインの完全に適格な名前（RFC 3491 [3]を参照）。応答で<ドメイン>（セクション3.1.1）を生成します。
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" >
<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
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
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"
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>
</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
図1：DCHK.XSD
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.
すべてのDCHKクライアントとサーバーは、軽量UDPトランスポートプロトコル（IRIS-LWZ）を実装する必要があります[9]。チャンク（IRIS-XPC）輸送[12]またはビープ輸送[8]を使用したXMLパイプラインなどの他の輸送の使用はオプションであり、サーバーオペレーターの裁量で完全にあります。XPC輸送は、いずれの場合でもビープ輸送よりも望ましいです。
IRIS allows several extensions of the core capabilities. This section outlines those extensions allowable by IRIS-BEEP [8].
IRISは、コア機能のいくつかの拡張を許可します。このセクションでは、Iris-Beep [8]によって許容される拡張機能の概要を説明します。
This registry type uses the default message pattern as described in IRIS-BEEP [8].
このレジストリタイプは、Iris-Beep [8]で説明されているように、デフォルトのメッセージパターンを使用します。
This registry type uses the default server authentication method as described in IRIS-BEEP [8].
このレジストリタイプは、IRIS-Beep [8]で説明されているように、デフォルトのサーバー認証方法を使用します。
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.
このレジストリタイプに関連付けられたアプリケーションサービスラベルは、「DCHK1」でなければなりません。これは、このレジストリタイプ、urn：ietf：params：xml：ns：dchk1のurnの省略形式です。
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].
ボトムアップの代替解像度方法は、Iris URIの「ボトム」として識別する必要があります。そのプロセスは、RFC 3982 [7]で記述された「ボトム」プロセスと同じです。
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].
トップダウンの代替解像度方法は、Iris URIの「トップ」として識別する必要があります。そのプロセスは、RFC 3982 [7]で記述された「TOP」プロセスと同じです。
Implementors should be aware of considerations for internationalization in IRIS [6].
実装者は、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.
このプロトコルでデータタグをローカライズする必要があるクライアントは、日付と時刻情報を含む要素を除き、XML要素と属性の名前にのみローカリゼーションが必要であることに注意する必要があります。このレジストリのスキーマは、クライアントが日付と時刻情報を含む要素以外の要素または属性の内容を解釈する必要がないように設計されています。
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').
すべての日付と時刻の要素は、XMLスキーマ[10]データ型「DateTime」を使用しています。その内容が調整されたユニバーサル時間（UTC）タイムスタンプである場合、大文字の「Z」インジケータ（「Z」の代わりに）を使用して指定する必要があります。
This document makes use of the XML registry specified in RFC 3688 [4]. Accordingly, IANA has made the following registration:
このドキュメントでは、RFC 3688 [4]で指定されたXMLレジストリを使用しています。したがって、IANAは次の登録を行いました。
o XML Namespace URN/URI:
o XMLネームスペースurn/uri：
* urn:ietf:params:xml:ns:dchk1
* urn：ietf：params：xml：ns：dchk1
o Contact:
o コンタクト：
* Andrew Newton <andy@hxr.us>
* アンドリュー・ニュートン<andy@hxr.us>
* Marcos Sanz <sanz@denic.de>
* Marcos Sanz <sanz@denic.de>
o XML:
o XML：
* None.
* なし。
This document makes use of the XML registry specified in RFC 3688 [4]. Accordingly, IANA has made the following registration:
このドキュメントでは、RFC 3688 [4]で指定されたXMLレジストリを使用しています。したがって、IANAは次の登録を行いました。
o XML Schema URN/URI:
o XMLスキーマurn/uri：
* urn:ietf:params:xml:schema:dchk1
* urn：ietf：params：xml：schema：dchk1
o Contact:
o コンタクト：
* Andrew Newton <andy@hxr.us>
* アンドリュー・ニュートン<andy@hxr.us>
* Marcos Sanz <sanz@denic.de>
*
o XML:
o XML：
* The XML Schema specified in Section 3.2
* セクション3.2で指定されたXMLスキーマ
The following Sraightforwarad-NAPTR (S-NAPTR) application service label has been registered with IANA according to the IANA considerations defined in IRIS [6]:
次のSraightforwarad-Naptr（S-NAPTR）アプリケーションサービスラベルは、IRIS [6]で定義されているIANAの考慮事項に従ってIANAに登録されています。
DCHK1
DCHK1
The following BEEP Profile URI has been registered with IANA, in addition to the registration provided in IRIS-BEEP [8].
次のビーププロファイルURIは、IRIS-Beep [8]で提供された登録に加えて、IANAに登録されています。
http://iana.org/beep/iris1/dchk1
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].
RFC 3982 [7]の適切なサブセットであるため、このドキュメントに記載されているレジストリは、RFC 3981 [6]に記載されているものを超えてセキュリティ上の考慮事項を導入しません。
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[1] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[3] Hoffman、P。and M. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、RFC 3491、2003年3月。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[5] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, September 2004.
[5] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）のドメインレジストリグレース期間マッピング」、RFC 3915、2004年9月。
[6] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[6] Newton、A。およびM. Sanz、「Iris：The Internet Registry Information Service（IRIS）Core Protocol」、RFC 3981、2005年1月。
[7] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
[7] Newton、A。、およびM. Sanz、「Iris：インターネットレジストリ情報サービス（IRIS）のドメインレジストリ（DREG）タイプ」、RFC 3982、2005年1月。
[8] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.
[8] Newton、A。およびM. Sanz、「ブロック拡張可能なExchangeプロトコル（BEEP）を介したインターネットレジストリ情報サービス（IRIS）を使用」、RFC 3983、2005年1月。
[9] Newton, A., "A Lightweight UDP Transfer Protocol for the Internet Registry Information Service", RFC 4993, August 2007.
[9] Newton、A。、「インターネットレジストリ情報サービス向けの軽量UDP転送プロトコル」、RFC 4993、2007年8月。
[10] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[10] World Wide Webコンソーシアム、「XML Schema Part 2：DataTypes」、W3C XML Schema、2004年10月、<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/>.
[11] World Wide Webコンソーシアム、「XMLスキーマパート1：構造」、W3C XMLスキーマ、2004年10月、<http://www.w3.org/tr/xmlschema-1/>。
[12] Newton, A., "XML Pipelining with Chunks for the Internet Registry Information Service", RFC 4992, August 2007.
[12] Newton、A。、「インターネットレジストリ情報サービスのチャンク付きXMLパイプライン」、RFC 4992、2007年8月。
Authors' Addresses
著者のアドレス
Andrew L. Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 USA
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
Marcos Sanz Denic EG Kaiserstrasse 75-77 D-60329フランクフルトドイツ
EMail: sanz@denic.de
URI: http://www.denic.de/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。