RFC 4991 - A Common Schema for Internet Registry Information Service Transfer Protocols 日本語訳

URL : https://tools.ietf.org/html/rfc4991
タイトル : RFC 4991 - インターネットレジストリ情報サービスの転送プロトコルのための共通スキーマ
翻訳編集 : 自動生成

Network Working Group                                          A. Newton
Request for Comments: 4991                                VeriSign, Inc.
Category: Standards Track                                    August 2007

       A Common Schema for Internet Registry Information Service
                           Transfer Protocols

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）IETFトラスト（2007）。

Abstract

抽象

This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms.

この文書では、共通の特性を共有し、インターネットレジストリ情報サービス（IRIS）アプリケーション転送プロトコルで使用するためのXMLスキーマを記述する。それは、このようなバージョンとして、転送プロトコルに関する一般的な情報を記述し、拡張をサポートし、セキュリティ・メカニズムをサポートしていました。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Document Terminology . . . . . . . . . . . . . . . . . . . . .  2
   3.  Formal XML Syntax  . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Version Information  . . . . . . . . . . . . . . . . . . . . .  6
   5.  Size Information . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Authentication Success Information . . . . . . . . . . . . . .  8
   7.  Authentication Failure Information . . . . . . . . . . . . . .  8
   8.  Other Information  . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Internationalization Considerations  . . . . . . . . . . . . .  9
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     10.1.  XML Namespace URN Registration  . . . . . . . . . . . . . 10
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     12.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
     12.2.  Informative References  . . . . . . . . . . . . . . . . . 11
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 12

1. Introduction

1. はじめに

IRIS [8] has two transfer protocols, LWZ (lightweight using compression) [9] and XPC (XML pipelining with chunks) [10], that share common negotiation mechanisms. Both transfer protocols have a need for the server to provide rich status information to clients during protocol negotiation. In many cases, this status information would be too complex to describe using simple bit fields and length-specified octet sequences. This document defines an XML Schema for this rich status information and describes the usage of conformant XML for conveying this status information.

IRIS [8] 2つの転送プロトコルを有し、（軽量圧縮を使用して）LWZ [9]及びXPC（チャンクとXMLパイプライン）[10]、その共通のネゴシエーションメカニズム。両方の転送プロトコルは、プロトコルのネゴシエーション中にクライアントへの豊富なステータス情報を提供するためのサーバーを必要としています。多くの場合、このステータス情報は、単純なビットフィールドと長さが指定したオクテットのシーケンスを用いて説明するには複雑すぎるだろう。この文書では、この豊かなステータス情報のXMLスキーマを定義し、このステータス情報を伝えるための準拠XMLの使用方法を説明します。

This document defines five types of information used in the negotiation of protocol capabilities: version, size, authentication success, authentication failure, and other information. The version information is used to negotiate the versions and extensions to the transfer protocol, the application operations protocol, and data models used by the application operations. Size information is used to indicate request and response size capabilities and errors. Authentication success and failure information is used to indicate the outcome of an authentication action. Other types of information may also be conveyed that is generally a result of an error but cannot be corrected through defined protocol behavior.

バージョン、サイズ、認証成功、認証失敗、およびその他の情報：この文書では、5つのプロトコル機能のネゴシエーションで使用される情報の種類を定義します。バージョン情報は、アプリケーションの操作で使用される転送プロトコル、アプリケーションオペレーションプロトコル、及びデータモデルのバージョンと拡張機能をネゴシエートするために使用されます。サイズ情報は、要求と応答の大き機能やエラーを示すために使用されます。認証成功と失敗の情報は、認証アクションの結果を示すために使用されます。他のタイプの情報はまた、一般的にエラーの結果であるが、定義されたプロトコルの動作を介して補正することができない搬送することができます。

As an example, upon initiation of a connection, a server may send version information informing the client of the data models supported by the server and the security mechanisms supported by the server. The client may then respond appropriately. For example, the client may not recognize any of the data models supported by the server, and therefore close the connection. On the other hand, the client may recognize the data models and the security mechanisms and begin the procedure to initialize a security mechanism with the server before proceeding to query data according to a recognized data model.

一例として、接続の開始時に、サーバは、サーバと、サーバによってサポートされるセキュリティ・メカニズムによってサポートされるデータモデルのクライアントに通知するバージョン情報を送信することができます。次に、クライアントは適切に応答することができます。例えば、クライアントは、サーバによってサポートされるデータモデルのいずれかを認識し、そのため、接続を閉じないことがあります。一方、クライアントは、データモデルとセキュリティメカニズムを認識し、認識されたデータモデルに基づいてデータを照会するために進む前に、サーバーとのセキュリティ・メカニズムを初期化する手順を開始してもよいです。

Both LWZ [9] and XPC [10] provide examples of the usage of the XML Schema defined in this document.

両方LWZ [9]及びXPC [10]この文書で定義されたXMLスキーマの使用の例を提供します。

2. Document Terminology

2.ドキュメントの用語

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 [6].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[6]。

3. Formal XML Syntax

3.正式なXML構文

The following is the XML Schema used to define transfer protocol status information. See the following specifications: [2], [3], [4], [5]. Updates or changes to this schema require a document that UPDATES or OBSOLETES this document.

以下は、転送プロトコルステータス情報を定義するために使用されるXMLスキーマです。以下の仕様を参照してください[2]、[3]、[4]、[5]。このスキーマの更新や変更は、このドキュメントを更新または廃止文書が必要です。

<?xml version="1.0"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:iristrans="urn:ietf:params:xml:ns:iris-transport" targetNamespace="urn:ietf:params:xml:ns:iris-transport" elementFormDefault="qualified" >

<？xml version = "1.0"？> <スキーマのxmlns = "http://www.w3.org/2001/XMLSchema" のxmlns：iristransの= "壷：IETF：のparams：XML：NS：アイリス輸送" のtargetNamespace = > "URN：IETF：のparams：XML：：NSアイリス輸送" のelementFormDefault = "資格"

<annotation> <documentation> A schema for describing status information for use by multiple transfer protocols. </documentation> </annotation>

<注釈> <ドキュメンテーション>複数の転送プロトコルで使用するためのステータス情報を記述するためのスキーマ。 </ドキュメンテーション> </注釈>

<element name="versions"> <complexType> <sequence> <element name="transferProtocol" maxOccurs="unbounded"> <complexType> <sequence> <element name="application" minOccurs="0" maxOccurs="unbounded"> <complexType> <sequence> <element name="dataModel" minOccurs="0" maxOccurs="unbounded"> <complexType> <attribute name="protocolId" type="token" use="required" /> <attribute name="extensionIds" type="normalizedString" /> </complexType> </element> </sequence> <attribute name="protocolId" type="token" use="required" /> <attribute name="extensionIds" type="normalizedString" /> </complexType> </element> </sequence> <attribute name="protocolId" type="token" use="required"

<要素名= "バージョン"> <complexTypeの> <シーケンス> <要素名= "transferProtocol" のmaxOccurs = "無制限"> <complexTypeの> <シーケンス> <要素名= "アプリケーション" のminOccurs = "0" のmaxOccurs = "unbounded" を> <complexTypeの> <シーケンス> <要素名= "データモデル" のminOccurs = "0" のmaxOccurs = "無制限"> <complexTypeの> <= "トークン" 使用= "必須" /> <名前属性名= "protocolId" タイプ属性= "extensionIds" タイプ= "normalizedStringで" /> </ complexTypeの> </要素> </シーケンス> <属性名= "protocolId" タイプ= "トークン" 使用= "必要" /> <属性名= "extensionIds" タイプ= "normalizedStringで" /> </ complexTypeの> </要素> </シーケンス> <属性名= "protocolId" タイプ= "トークン" 使用= "必要"

/> <attribute name="extensionIds" type="normalizedString" /> <attribute name="authenticationIds" type="normalizedString" /> <attribute name="responseSizeOctets" type="positiveInteger" /> <attribute name="requestSizeOctets" type="positiveInteger" /> </complexType> </element> </sequence> </complexType> </element>

/> <属性名= "extensionIds" タイプ= "normalizedStringで" /> <属性名= "authenticationIds" タイプ= "normalizedStringで" /> <属性名= "responseSizeOctets" タイプ= "POSITIVEINTEGER" /> <名前= "requestSizeOctets属性"TYPE =" POSITIVEINTEGER」/> </ complexTypeの> </要素> </配列> </ complexTypeの> </要素>

<要素名= "サイズ"> <complexTypeの> <シーケンス> <要素名= "要求" のminOccurs = "0" タイプ= "iristrans：octetsType" /> <要素名= "応答" のminOccurs = "0" タイプ=」 iristrans：octetsType」/> </シーケンス> </ complexTypeの> </要素>

<complexTypeの名前= "octetsType"> <選択> <要素名= "exceedsMaximum"> <complexTypeの/> </要素> <要素名= "オクテット" タイプ= "POSITIVEINTEGER" /> </選択> </ complexTypeの>

<要素名= "authenticationSuccess"> <complexTypeの> <シーケンス> <要素名= "説明" のminOccurs = "0" のmaxOccurs = "無制限"> <complexTypeの> <simpleContentを> <拡張基地= "文字列"> <属性名= "言語" タイプ= "言語" 使用= "必須" /> </拡張> </ simpleContentを>

</complexType> </element> <element name="data" minOccurs="0" maxOccurs="1" type="base64Binary"/> </sequence> </complexType> </element>

</ complexTypeの> </要素> <要素名= "データ" のminOccurs = "0" のmaxOccurs = "1" タイプ= "base64Binaryの" /> </配列> </ complexTypeの> </要素>

<要素名= "のauthenticationFailure"> <complexTypeの> <シーケンス> <要素名= "説明" のminOccurs = "0" のmaxOccurs = "無制限"> <complexTypeの> <simpleContentを> <拡張基地= "文字列"> <属性名= "言語" タイプ= "言語" 使用= "必須" /> </拡張> </ simpleContentを> </ complexTypeの> </要素> </配列> </ complexTypeの> </要素>

<要素名= "その他"> <complexTypeの> <シーケンス> <要素名= "説明" のminOccurs = "0" のmaxOccurs = "無制限"> <complexTypeの> <simpleContentを> <拡張基地= "文字列"> <属性名= "言語" タイプ= "言語" 使用= "必須" /> </拡張> </ simpleContentを> </ complexTypeの> </要素> </シーケンス> <属性タイプ= "トークン" 名前= "タイプ" 使用=」必要な "/> </ complexTypeの> </要素>

</schema>

</スキーマ>

4. Version Information

4.バージョン情報

The <versions> element is used to describe version information about the transfer protocol, the application protocol, and data models used by the application protocol.

<バージョン>要素は、アプリケーションプロトコルによって使用される転送プロトコル、アプリケーションプロトコル、及びデータモデルのバージョン情報を記述するために使用されます。

The <versions> element has one or more <transferProtocol> child elements. <transferProtocol> elements have zero or more <application> child elements. And <application> elements have zero or more <dataModel> elements. Each of these element types has a 'protocolId' attribute identifying the protocol they represent and an optional 'extensionIds' attribute identifying the protocol extensions they support.

<バージョン>要素は、1つ以上の<transferProtocol>子要素を持っています。 <transferProtocol>要素はゼロ以上の<アプリケーション>子要素を持っています。そして、<アプリケーション>要素はゼロ以上の<データモデル>要素を持っています。これらの要素タイプのそれぞれは、それが表すプロトコルと、それらがサポートするプロトコル拡張を識別し、オプションの「extensionIds」属性を特定する「protocolId」属性を持っています。

During capabilities negotiation, it is expected that both sides of the negotiation recognize the 'protocolId' value of the <transferProtocol> element and at least one of the <application> and <dataModel> elements. If the negotiation produces a situation where this is not possible, an error SHOULD be given and communication ended. It is not expected that each side must recognize the 'extensionIds' values, and unrecognized 'extensionIds' values MUST be ignored.

機能ネゴシエーション中には、ネゴシエーションの両側が<transferProtocol>要素と<アプリケーション>と<データモデル>要素の少なくとも1つの「protocolId」値を認識することが期待されます。交渉はこれが不可能な事態を生じた場合は、エラーが与えられるべきであるとの通信が終了します。それぞれの側は「extensionIdsの価値観を認識しなければならない、と認識されていない「extensionIds」の値は無視されなければならないことが期待されていません。

Additionally, the <transferProtocol> element has optional 'authenticationIds', 'responseSizeOctets', and 'requestSizeOctets' attributes. The 'authenticationIds' attribute identifies authentication mechanisms supported by the associated transfer protocol. The 'responseSizeOctets' attribute describes the maximum response size in octets the server will give. The 'requestSizeOctets' attribute describes the maximum request size in octets the server will accept.

また、<transferProtocol>要素には、オプションの 'authenticationIds'、 'responseSizeOctets'、および 'requestSizeOctetsの属性を持っています。「authenticationIds」属性は、関連する転送プロトコルによってサポートされる認証メカニズムを識別する。「responseSizeOctets」属性は、サーバーが与えるオクテットの最大応答サイズを記述する。「requestSizeOctets」属性は、サーバーが受け入れるオクテットの最大要求サイズを説明します。

The protocol, extension, and authentication mechanism identifiers are of no specific type, and this document defines none. Specifications using this XML Schema MUST define the identifiers for use with the <versions> element and its children.

プロトコル、拡張、および認証機構識別子はない特定のタイプのものであり、この文書はどれも定義しません。このXMLスキーマを使用しての仕様は、<バージョン>要素とその子で使用するための識別子を定義しなければなりません。

The meaning of octets for the transfer of data is counted in different ways for different transfer protocols. Some transfer protocols need only to specify the octets of the data being transferred, while other transfer protocols need to account for additional octets used to transfer the data. Specifications using this XML Schema MUST describe how these octet counts are calculated.

データの転送のためのオクテットの意味は異なる転送プロトコルのためのさまざまな方法でカウントされます。他の転送プロトコルは、データを転送するために使用される追加のオクテットを考慮する必要がありながら、いくつかの転送プロトコルは、転送されるデータのオクテットを指定するだけで済みます。このXMLスキーマを使用しての仕様は、これらのオクテット数を計算する方法を説明しなければなりません。

The following is example XML describing version information.

以下は、バージョン情報を記述した例示的XMLです。

<バージョンのxmlns = "URN：IETF：paramsは：XML：NS：虹彩輸送"> <transferProtocol protocolId = authenticationIds = "PLAIN EXTERNAL" "iris.lwz"> <アプリケーションprotocolId = "URN：IETF：paramsは：XML：NS ：iris1" extensionIds = "http://example.com/SIMPLEBAG"> <データモデルprotocolId = "URN：IETF：paramsは：XML：NS：dchk1" /> <データモデルprotocolId = "URN：IETF：paramsは：XML：NS ：DREG1" /> </アプリケーション> </ transferProtocol> </バージョン>

Version Information Example

バージョン情報の例

5. Size Information

5.サイズ情報

The <size> element provides a means for a server to communicate to a client that a given request has exceeded a negotiated size (<request>) or that a response to a given request will exceed a negotiated size (<response>).

<サイズ>要素は、サーバーが指定された要求がネゴシエートサイズを超えているクライアントと通信するための手段を提供する（<要求>）、または指定された要求に対する応答がネゴシエートサイズを超えること（<応答>）。

A server may indicate one of two size conditions by specifying the following child elements:

サーバーは、以下の子要素を指定することにより、2つのサイズのいずれかの条件を示すことがあります。

<exceedsMaximum> - this child element simply indicates that the size exceeded the negotiated size.

<exceedsMaximum> - この子要素は、単にサイズが交渉のサイズを超えたことを示しています。

<octets> - this child element indicates that the size exceeded the negotiated size and conveys the number of octets that is the maximum for a request if the parent element is a <request> element or the number of octets needed to provide the response if the parent element is a <response> element.

<オクテット> - この子要素は、サイズが交渉のサイズを超えたことを示し、親要素は<要求>要素または場合、応答を提供するために必要なオクテットの数である場合には、要求のために最大であるオクテットの数を伝えます親要素は<応答>要素です。

The following is example XML describing size information.

以下は、サイズ情報を記述したサンプルのXMLです。

<サイズのxmlns = "URN：IETF：paramsは：XML：NS：虹彩輸送"> <レスポンス> <オクテット> 1211 </オクテット> </レスポンス> </サイズ>

Size Information Example

サイズ情報の例

6. Authentication Success Information

6.認証成功情報

The <authenticationSuccess> element indicates that a client has successfully authenticated to a server. Along with this indication, it can provide text that may be presented to a user with regard to this successful authentication using child <description> elements.

<authenticationSuccess>要素は、クライアントがサーバーに正常に認証されていることを示しています。この表示と共に、それは子の<description>要素を使用して、この認証が成功に関して、ユーザに提示することができるテキストを提供することができます。

Each <description> element MUST have a 'language' attribute describing the language of the content of the <description> element. Clients are not expected to concatenate multiple descriptions; therefore, servers MUST NOT provide multiple <description> elements with the same language descriptor.

各<description>要素は、<description>要素の内容の記述言語「言語」属性を持たなければなりません。クライアントは、複数の記述を連結することが期待されていません。そのため、サーバは同じ言語記述子を持つ複数の<説明>要素を提供してはなりません。

Finally, additional security data may be sent back with the authentication success message using the <data> element. The content of this element is of the base64Binary simple type.

最後に、追加のセキュリティデータは、<data>要素を使用して認証成功メッセージを送り返すことができます。この要素の内容は、base64Binaryのシンプルなタイプです。

The following is example XML describing authentication success information.

以下は、認証成功の情報を記述した例をXMLです。

<authenticationSuccess xmlns="urn:ietf:params:xml:ns:iris-transport"> <description language="en"> user 'bob' authenticates via password </description> </authenticationSuccess>

<authenticationSuccessのxmlns = "壷：IETF：のparams：XML：NS：アイリス輸送"> <記述言語= "EN">ユーザーボブ」は、パスワードを経由して認証します。</記述> </ authenticationSuccess>

Authentication Success Example

認証の成功例

7. Authentication Failure Information

7.認証失敗情報

The <authenticationFailure> element indicates that a client has failed to properly authenticate to a server. Along with this indication, it can provide text that may be presented to a user with regard to this authentication failure using child <description> elements.

<のauthenticationFailure>要素は、クライアントがサーバーに正しく認証するために失敗したことを示しています。この表示と共に、それは子の<description>要素を使用して、この認証の失敗に関して、ユーザに提示することができるテキストを提供することができます。

The following is example XML describing authentication failure information.

以下は、認証失敗情報を記述した例示的XMLです。

<authenticationFailure xmlns="urn:ietf:params:xml:ns:iris-transport"> <description language="en"> please consult your admin if you have forgotten your password </description> </authenticationFailure>

<のauthenticationFailureのxmlns = "壷：IETF：のparams：XML：NS：アイリス輸送"> <記述言語= "EN">あなたは</記述> </のauthenticationFailure>パスワードを忘れてしまった場合は、あなたの管理者に相談してください

Authentication Failure Example

認証の失敗例

8. Other Information

8.その他の情報

The <other> element conveys status information that may require interpretation by a human to be meaningful. This element has a required 'type' attribute, which contains an identifier regarding the nature of the information. This document does not define any identifiers for use in this attribute, but the intent is that these identifiers are well-known so that clients may take different classes of action based on the content of this attribute. Therefore, specifications making use of this XML Schema MUST define these identifiers.

<その他>要素は有意義であることが、人間による解釈を必要とするかもしれないステータス情報を伝えます。この要素は、情報の性質に関する識別子を含む必要な「タイプ」属性を持っています。この文書では、この属性で使用するための任意の識別子を定義していませんが、その意図は、クライアントがこの属性の内容に基づいてアクションの異なるクラスを取ることができるようにこれらの識別子は、よく知られているということです。したがって、このXMLスキーマを利用する仕様は、これらの識別子を定義しなければなりません。

The <other> element may have zero or more <description> elements. Each <description> element MUST have a 'language' attribute describing the language of the content of the <description> element. Servers may use these child elements to convey textual information to clients regarding the class (or type) of status information being specified by the <other> element. Clients are not expected to concatenate multiple descriptions; therefore, servers MUST NOT provide multiple <description> elements with the same language descriptor.

<その他>要素は、ゼロまたはそれ以上の<description>要素を有していてもよいです。各<description>要素は、<description>要素の内容の記述言語「言語」属性を持たなければなりません。サーバーは、<その他>要素で指定されたステータス情報のクラス（またはタイプ）に関するクライアントにテキスト情報を伝えるために、これらの子要素を使用することができます。クライアントは、複数の記述を連結することが期待されていません。そのため、サーバは同じ言語記述子を持つ複数の<説明>要素を提供してはなりません。

The following is example XML describing other information.

以下は、他の情報を記述した例示的XMLです。

<other xmlns="urn:ietf:params:xml:ns:iris-transport" type="system"> <description language="en">unavailable, come back later</description> </other>

<他のxmlns = "URN：IETF：paramsは：XML：NS：虹彩輸送" タイプ= "システム"> <記述言語= "EN">利用できないが、後で戻ってくる</記述> </その他>

Other Information Example

その他の情報の例

9. Internationalization Considerations

9.国際化に関する注意事項

XML processors are obliged to recognize both UTF-8 and UTF-16 [1] encodings. XML provides for mechanisms to identify and use other character encodings. Application transfer protocols MUST define which additional character encodings, if any, are to be allowed in the use of the XML defined in this document.

XMLプロセッサは、[1]エンコードUTF-8およびUTF-16の両方を認識するように義務付けられています。 XMLは、識別し、他の文字エンコーディングを使用するためのメカニズムを提供します。アプリケーションの転送プロトコルがあれば、この文書で定義されたXMLの使用で許可されるべきである、どの追加の文字エンコーディングを定義しなければなりません。

10. IANA Considerations

10. IANAの考慮事項

10.1. XML Namespace URN Registration

10.1. XML名前空間URN登録

This document makes use of the XML namespace and schema registry specified in XML_URN [7]. Accordingly, the following registrations have been made by IANA:

この文書では、XML_URN [7]で指定されたXML名前空間とスキーマレジストリを使用しています。したがって、以下の登録はIANAによって行われています。

o XML Namespace URN/URI:

おＸＭＬなめｓぱせうＲん／うり：

* urn:ietf:params:xml:ns:iris-transport

* URN：IETF：のparams：XML：NS：アイリス輸送

o Contact:

Oの連絡先：

* Andrew Newton <andy@hxr.us>

*アンドリュー・ニュートン<andy@hxr.us>

o XML:

おＸＭＬ：

* None

* 無し

o XML Schema URN/URI:

おＸＭＬＳちぇまうＲん／うり：

* urn:ietf:params:xml:schema:iris-transport

* URN：IETF：のparams：XML：スキーマ：アイリス輸送

o Contact:

Oの連絡先：

* Andrew Newton <andy@hxr.us>

*アンドリュー・ニュートン<andy@hxr.us>

o XML:

おＸＭＬ：

* The XML Schema specified in Section 3

第3節で指定された* XMLスキーマ

11. Security Considerations

11.セキュリティについての考慮事項

Transfer protocols using XML conformant to the XML Schema in this document and offering security properties such as authentication and confidentiality SHOULD offer an initial message from the server to the client using the <versions> element. This <versions> element SHOULD contain all relevant authentication identifiers in its 'authenticationId' attribute. The purpose of providing this initial message is to help thwart downgrade attacks.

このドキュメントのXMLスキーマに準拠したXMLを使用して、認証や機密性などのセキュリティプロパティを提供する転送プロトコルは、<バージョン>要素を使用して、サーバーからクライアントへの最初のメッセージを提供する必要があります。この<バージョン>要素は、その「authenticationId」属性で、関連するすべての認証識別子を含むべきです。この最初のメッセージを提供する目的は、ダウングレード攻撃を阻止できるようにすることです。

12. References

12.参考文献

12.1. Normative References

12.1. 引用規格

[1] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.

[1]ユニコードコンソーシアム、 "Unicode規格、バージョン3"、ISBN 0-201-61633-5、2000年、<Unicode標準、バージョン3>。

[2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.

[2]ワールド・ワイド・ウェブ・コンソーシアム、 "拡張マークアップ言語（XML）1.0"、W3C XML、1998年2月、<http://www.w3.org/TR/1998/REC-xml-19980210>。

[3] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

[3]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLにおける名前空間" を、W3C XML名前空間、1999年1月、<http://www.w3.org/TR/1999/REC-xml-names-19990114>。

[4] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2004, <http://www.w3.org/TR/xmlschema-2/>.

[4]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLスキーマパート2：データ型"、W3C XML Schemaの、2004年10月、<http://www.w3.org/TR/xmlschema-2/>。

[5] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2004, <http://www.w3.org/TR/xmlschema-1/>.

[5]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLスキーマパート1：構造"、W3C XML Schemaの、2004年10月、<http://www.w3.org/TR/xmlschema-1/>。

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.

[6]ブラドナーのは、S.は、RFC 2119、BCP 14、1997年3月 "のRFCsにおける使用のためのレベルを示すために"。

[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[7] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

12.2. Informative References

12.2. 参考文献

[8] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.

[8]ニュートン、A.とM.サンス、 "IRIS：インターネットレジストリ情報サービス（IRIS）コアプロトコル"、RFC 3981、2005年1月。

[9] Newton, A., "A Lightweight UDP Transfer Protocol for the Internet Registry Information Service", RFC 4993, August 2007.

[9]ニュートン、A.、RFC 4993、2007年8月 "インターネットレジストリ情報サービスのための軽量のUDP転送プロトコル"。

[10] Newton, A., "XML Pipelining with Chunks for the Internet Registry Information Service", RFC 4992, August 2007.

[10]ニュートン、A.、 "インターネットレジストリ情報サービスのためのチャンクを含むXMLパイプライン"、RFC 4992、2007年8月。

Appendix A. Contributors

付録A.協力者

Substantive contributions to this document have been provided by the members of the IETF's CRISP Working Group, especially Robert Martin-Legene, Milena Caires, and David Blacka.

このドキュメントへの実質的な貢献はIETFのCRISPワーキンググループのメンバー、特にロバート・マーティン・Legene、ミレーナCaires、とDavid Blackaによって提供されています。

Author's Address

著者のアドレス

Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA

アンドリュー・L.ニュートンベリサイン社21345 Ridgetopサークルスターリング、VA 20166 USA

Phone: +1 703 948 3382 EMail: andy@hxr.us URI: http://www.verisignlabs.com/

電話：+1 703 948 3382 Eメール：andy@hxr.us URI：http://www.verisignlabs.com/

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2007）。

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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。