Network Working Group T. Goddard
Request for Comments: 4743 ICEsoft Technologies Inc.
Category: Standards Track December 2006
Using NETCONF over the Simple Object Access Protocol (SOAP)
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF.
ネットワーク構成プロトコル（NETCONF）は、さまざまな環境での幅広いデバイスに適用されます。 Webサービスは、そのような環境であり、現在のSOAP（Simple Object Access Protocol）を使用することを特徴としています。 NETCONFは、この環境で多くの利点を見つける：既存の規格の再利用から、展開システムとの統合に、ソフトウェア開発の容易にします。ここで、我々はブロック取引所拡張プロトコル（BEEP）NETCONFのバインディング上でHTTPやSOAP経由のSOAPを記述する。
Table of Contents
目次
1. Introduction ....................................................2
2. SOAP Background for NETCONF .....................................3
2.1. Use and Storage of WSDL and XSD ............................4
2.2. SOAP over HTTP .............................................4
2.3. HTTP Drawbacks .............................................4
2.4. BCP56: On the Use of HTTP as a Substrate ...................5
2.5. Important HTTP 1.1 Features ................................6
2.6. SOAP over BEEP .............................................7
2.7. SOAP Implementation Considerations .........................7
2.7.1. SOAP Feature Exploitation ...........................7
2.7.2. SOAP Headers ........................................7
2.7.3. SOAP Faults .........................................8
3. A SOAP Service for NETCONF ......................................9
3.1. Fundamental Use Case .......................................9
3.2. NETCONF Session Establishment ..............................9
3.3. NETCONF Capabilities Exchange ..............................9
3.4. NETCONF Session Usage .....................................11
3.5. NETCONF Session Teardown ..................................11
3.6. A NETCONF over SOAP Example ...............................11
3.7. NETCONF SOAP WSDL .........................................13
3.8. Sample Service Definition WSDL ............................14
4. Security Considerations ........................................15
4.1. Integrity, Privacy, and Authentication ....................15
4.2. Vulnerabilities ...........................................16
4.3. Environmental Specifics ...................................16
5. IANA Considerations ............................................17
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................18
Given the use of Extensible Markup Language (XML) [2] and the remote procedure call characteristics, it is natural to consider a binding of the NETCONF [1] operations to a SOAP [3] application protocol. This document proposes a binding of this form.
拡張マークアップ言語（XML）の使用[2]、リモート・プロシージャ・コールの特性を考えると、SOAPにNETCONF [1]の操作の結合[3]アプリケーションプロトコルを考えるのが自然です。この文書では、このフォームの結合を提案しています。
In general, SOAP is a natural messaging scheme for NETCONF, essentially because of the remote procedure call character of both. However, care must be taken with SOAP over HTTP as it is inherently synchronous and client-driven. SOAP over BEEP [11] is technically superior, but is not as widely adopted.
一般的には、SOAPは、本質的にあるため、両方のリモート・プロシージャ・コールの文字の、NETCONFのための自然なメッセージングスキームです。それは本質的に、同期およびクライアント主導型であるしかし、ケアは、HTTP上でSOAPを取らなければなりません。 BEEP [11]上のSOAPは、技術的に優れているが、として広く採用されていません。
Four basic topics are presented: SOAP specifics of interest to NETCONF, specifics on implementing NETCONF as a SOAP-based web service, security considerations, and functional Web Services
四つの基本的なトピックが提示されていますNETCONFへの関心のSOAPの仕様を、SOAPベースのWebサービス、セキュリティ上の考慮事項、および機能的なWebサービスとしてNETCONFを実装上の詳細
Description Language (WSDL) definitions. In some sense, the most important part of the document is the brief WSDL document presented in Section 3.7. With the right tools, the WSDL combined with the base NETCONF XML Schemas provides machine-readable descriptions sufficient for the development of software applications using NETCONF.
記述言語（WSDL）の定義。ある意味では、文書の最も重要な部分は、3.7節で提示簡単なWSDL文書です。適切なツールを使用すると、ベースNETCONF XMLスキーマと組み合わせたWSDLは、NETCONFを使用してソフトウェアアプリケーションを開発するための十分な機械読み取り可能な説明を提供します。
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 [8].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[8]。
Why introduce SOAP as yet another wrapper around what is already a remote procedure call message? There are, in fact, both technical and practical reasons. The technical reasons are perhaps less compelling, but let's examine them first.
なぜ、すでにリモートプロシージャコールメッセージが何であるかを周りのさらに別のラッパーとしてSOAPをご紹介！ 、実際には、両方の技術的、実用的な理由があります。技術的な理由は、おそらくあまり説得力ですが、まずはそれらを調べてみましょう。
The use of SOAP does offer a few technical advantages. SOAP is fundamentally an XML messaging scheme (which is capable of supporting remote procedure call), and it defines a simple message format composed of a "header" and a "body" contained within an "envelope". The "header" contains meta-information relating to the message and can be used to indicate such things as store-and-forward behaviour or transactional characteristics. In addition, SOAP specifies an optional encoding for the "body" of the message. However, this encoding is not applicable to NETCONF as one of the goals is to have highly readable XML, and SOAP-encoding is optimized instead for ease of automated de-serialization. These benefits of the SOAP message structure are simple, but worthwhile because they are already standardized.
SOAPを使用すると、いくつかの技術的な利点を提供しません。 「エンベロープ」内に含まれるSOAPは、基本的に（リモート・プロシージャ・コールをサポートすることができる）XMLメッセージング方式であり、それは「ヘッダ」と「本体」から構成される単純なメッセージフォーマットを定義します。 「ヘッダ」は、メッセージに関連するメタ情報を含み、ストアアンドフォワード動作またはトランザクションの特性のようなものを示すために使用することができます。また、SOAPは、メッセージの「ボディ」のための任意のエンコーディングを指定します。目標の一つは、可読性の高いXMLを持つことである、とSOAPエンコードではなく、自動化され、デシリアライズを容易にするために最適化されているようしかし、このエンコーディングは、NETCONFには適用されません。彼らはすでに標準化されているので、SOAPメッセージの構造のこれらの利点はシンプルですが、価値があります。
It is the practical reasons that truly make SOAP an interesting choice for device management. It is not difficult to invent a mechanism for exchanging XML messages over TCP, but what is difficult is getting that mechanism supported in a wide variety of tools and operating systems and having that mechanism understood by a great many developers. SOAP over HTTP (with WSDL) is seeing good success at this, and this means that a device management protocol making use of these technologies has advantages in being implemented and adopted. Admittedly, there are interoperability problems with SOAP and WSDL, but such problems have wide attention and can be expected to be resolved.
それは本当にSOAPデバイス管理のための興味深い選択肢となって実用的な理由です。 TCP上のXMLメッセージを交換するためのメカニズムを発明することは困難ではないが、何が難しいのは、ツールおよびオペレーティングシステムの多種多様でサポートされているそのメカニズムを取得し、非常に多くの開発者が理解されている機構を備えています。 （WSDLで）HTTP上のSOAPは、この時に良好な成功を見て、これは、これらの技術を利用したデバイス管理プロトコルが実装され、採用されている利点を有することを意味します。確かに、そこにSOAPとWSDLとの相互運用性の問題があるが、そのような問題が広く注目を持ち、解決することが期待できます。
One of the advantages of using machine-readable formats (such as Web Services Description Language (WSDL) [16] and XML Schemas [4]) is that they can be used automatically in the software development process. With appropriate tools, WSDL and XSD can be used to generate classes that act as remote interfaces or application-specific data structures. Other uses, such as document generation and service location, are also common. A great innovation found with many XML-based definition languages is the use of hyperlinks for referring to documents containing supporting definitions.
機械可読形式を使用する利点の1つ（例えば、Webサービス記述言語（WSDL）として[16]及びXMLスキーマ[4]）は、ソフトウェア開発プロセスにおいて自動的に使用することができることです。適切なツールを用いて、WSDLおよびXSDは、リモートインタフェースまたはアプリケーション固有のデータ構造として働くクラスを生成するために使用することができます。このような文書生成及びサービス場所のような他の用途もまた一般的です。多くのXMLベースの定義言語で見つかった偉大な技術革新は、支持の定義を含む文書を参照するためのハイパーリンクを使用することです。
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" location="http://www.iana.org/assignments/xml-registry/ schema/netconf.xsd" />
<インポート名前空間= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" 場所= "http://www.iana.org/assignments/xml-registry/スキーマ/ netconf.xsd" />
For instance, in WSDL, the above import statement imports the definitions of XML types and elements from the base NETCONF schema. Ideally, the file containing that schema is hosted on a web server under the authority of the standards body that defined the schema. In this way, dependent standards can be built up over time, and all are accessible to automated software tools that ensure adherence to the standards. The IANA-maintained registry for this purpose is described in "The IETF XML Registry" [13].
例えば、WSDLに、上記のインポートステートメントは、ベースNETCONFスキーマからXMLタイプおよび要素の定義をインポートします。理想的には、そのスキーマを含むファイルは、スキーマを定義した標準化団体の権限の下でのWebサーバー上でホストされています。このように、依存基準が時間をかけて構築することができ、すべてが基準の遵守を確保するため、自動化ソフトウェアツールにアクセスできます。この目的のためのIANA-維持レジストリは「IETF XMLレジストリ」[13]に記載されています。
Note that WSDL declarations for SOAP over BEEP bindings are not yet standardized.
BEEPバインディング上のSOAPのWSDL宣言はまだ標準化されていないことに注意してください。
Although SOAP focuses on messages and can be bound to different underlying protocols such as HTTP, SMTP, or BEEP, most existing SOAP implementations support only HTTP or HTTP/TLS.
SOAPメッセージに焦点を当て、そのようなHTTP、SMTP、またはBEEPなど、さまざまな基本的なプロトコルにバインドすることができますが、ほとんどの既存のSOAP実装はHTTPまたはHTTP / TLSをサポートしています。
There are a number of advantages to considering SOAP over protocols other than HTTP, as HTTP assigns the very distinct client and server roles by connection initiation. This causes difficulties in supporting asynchronous notification and can be relieved in many ways by replacing HTTP with BEEP.
HTTPは、接続開始することにより、非常に明確なクライアントとサーバーの役割を割り当てて、HTTP以外のプロトコル上のSOAPを考慮することに多くの利点があります。これは、非同期通知をサポートするのに困難を引き起こし、BEEPでHTTPを置き換えることにより、多くの方法で緩和することができます。
HTTP is not the ideal transport for messaging, but it is adequate for the most basic interpretation of "remote procedure call". HTTP is based on a communication pattern whereby the client (which initiates the TCP connection) makes a "request" to the server. The server returns a "response", and this process is continued (possibly over a persistent connection, as described below). This matches the basic idea of a remote procedure call where the caller invokes a procedure on a remote server and waits for the return value.
HTTPは、メッセージングのための理想的な輸送ではありませんが、それは、「リモートプロシージャコール」の最も基本的な解釈のために適切です。 HTTPは（TCP接続を開始）クライアントがサーバへの「要求」を作ることにより、通信パターンに基づいています。サーバは、「応答」を返し、（後述のように、おそらく永続的な接続を介して）、この処理を継続します。これは、呼び出し側がリモートサーバー上の手続きを呼び出し、戻り値を待機するリモート・プロシージャ・コールの基本的な考え方と一致します。
Potential criticisms of HTTP could include the following:
HTTPの潜在的な批判には、以下を含めることができます：
o Server-initiated data flow is awkward to provide.
Oサーバ起動データフローが提供する厄介です。
o Headers are verbose and text-based
Oヘッダは冗長であり、テキストベース
o Idle connections may be closed by intermediate proxies
Oアイドル接続は、中間プロキシによって閉じることができます
o Data encapsulation must adhere to Multipurpose Internet Mail Extensions (MIME) [15].
Oデータのカプセル化は、MIME（Multipurpose Internet Mail Extensions）の[15]に準拠する必要があります。
o Bulk transfer relies on stream-based ordering.
Oバルク転送は、ストリームベースの順序に依存しています。
In many ways, these criticisms are directed at particular compromises in the design of HTTP. As such, they are important to consider, but it is not clear that they result in fatal drawbacks for a device management protocol.
多くの点では、これらの批判は、HTTPの設計における特定の妥協に向けられています。そのため、彼らは考慮することが重要ですが、彼らが、デバイス管理プロトコルのための致命的な欠点になることは明らかではありません。
Best Current Practice 56 [6] presents a number of important considerations on the use of HTTP in application protocols. In particular, it raises the following concerns:
最も良い現在の練習56 [6]はアプリケーションプロトコルでのHTTPの使用に関する重要な検討事項の数を示します。特に、以下の問題が発生します。
o HTTP may be more complex than is necessary for the application.
O HTTPは、アプリケーションのために必要であるよりも、より複雑であってもよいです。
o The use of HTTP may mask the application from some firewalls.
O HTTPの使用は、いくつかのファイアウォールからアプリケーションをマスクしてもよいです。
o A substantially new service should not reuse port 80 as assigned to HTTP.
HTTPに割り当てられたとして、O、実質的に新しいサービスは、ポート80を再利用してはなりません。
o HTTP caching may mask connection state.
O HTTPキャッシングは、接続状態をマスクすることができます。
Fundamentally, these concerns lie directly with common usage of SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF. As BCP 56 indicates, it is debatable whether HTTP is an appropriate protocol for SOAP at all, and it is likely that BEEP would be a superior protocol for most SOAP applications. Unfortunately, SOAP over HTTP is in common use and must be supported if the practical benefits of SOAP are to be realized. Note that the verbose nature of SOAP actually makes it more readily processed by firewalls, albeit firewalls designed to process SOAP messages.
基本的に、これらの懸念は、一般的なHTTP経由のSOAPの使用ではなく、NETCONFにHTTP経由のSOAPのアプリケーションと直接横たわります。 BCP 56が示すように、HTTPはまったくSOAPに適したプロトコルであり、ビープ音が最もSOAPアプリケーションのための優れたプロトコルであろう可能性があるかどうか議論の余地があります。残念ながら、HTTP上のSOAPは、一般的に使用されているとSOAPの実用的な利点が実現される場合にサポートされなければなりません。 SOAPの詳細な性質は、実際にSOAPメッセージを処理するために設計されたファイアウォールとはいえ、それはより容易に、ファイアウォールによって処理されますので注意してください。
HTTP caches SHOULD NOT be inserted between NETCONF managers and agents as NETCONF session state is tied to the state of the underlying transport connection. Three defensive actions can be taken:
NETCONFセッション状態は、基礎となるトランスポート接続の状態に接続されるようにHTTPキャッシュはNETCONFマネージャとエージェントとの間に挿入されるべきではありません。三つの守備のアクションをとることができます。
o Caching MUST be prohibited through the use of HTTP headers Cache-Control and Pragma: no-cache.
キャッシュなし：OキャッシングはHTTPヘッダのCache-Controlおよびプラグマを使用して禁止されなければなりません。
o HTTP proxies SHOULD NOT be deployed within the management network.
O HTTPプロキシは、管理ネットワーク内に配置されるべきではありません。
o Use HTTPS.
O HTTPSを使用してください。
It is also possible to respond to the concern on the reuse of port 80. Any NETCONF SOAP service MUST always be supported over the new standard port for NETCONF over SOAP, and all conforming implementations MUST default to attempting connections over this new standard port for NETCONF. A standard port for NETCONF over SOAP (over HTTP) has been assigned in the IANA considerations of this document.
ポート80の任意のNETCONFのSOAPサービスは常に、SOAP経由NETCONFのための新しい標準ポート上でサポートされなければならないの再利用上の懸念に対応することも可能であり、すべての準拠した実装がNETCONFのために、この新しい標準ポート上で試みる接続をデフォルトとしなければなりません。 （HTTP経由）SOAP経由NETCONFの標準ポートは、このドキュメントのIANA問題に割り当てられています。
HTTP 1.1 [5] includes two important features that provide for relatively efficient transport of SOAP messages. These features are "persistent connections" and "chunked transfer-coding".
HTTP 1.1 [5] SOAPメッセージの比較的効率的な輸送のために提供する2つの重要な機能を有しています。これらの機能は、「持続的な接続」と「チャンク転送コーディング」です。
Persistent connections allow a single TCP connection to be used across multiple HTTP requests. This permits multiple SOAP request/ response message pairs to be exchanged without the overhead of creating a new TCP connection for each request. Given that a single stream is used for both requests and responses, it is clear that some form of framing is necessary. For messages whose length is known in advance, this is handled by the HTTP header "Content-length". For messages of dynamic length, "Chunking" is required.
持続的接続は、単一のTCP接続が複数のHTTPリクエストにまたがって使用することができます。これは、複数のSOAPリクエスト/レスポンスのメッセージペアは、要求ごとに新しいTCP接続を作成するオーバーヘッドなしに交換することを可能にします。単一ストリームは、要求と応答の両方のために使用されていることを考えると、フレーミングのいくつかのフォームが必要であることは明らかです。長さが予め分かっているメッセージについては、これは、HTTPヘッダの「Content-Length」が処理されます。動的な長さのメッセージについては、「チャンキング」が必要です。
HTTP "Chunking" or "chunked transfer-coding" allows the sender to send an indefinite amount of binary data. This is accomplished by informing the receiver of the size of each "chunk" (substring of the data) before the chunk is transmitted. The last chunk is indicated by a chunk of zero length. Chunking can be effectively used to transfer a large XML document where the document is generated on-line from a non-XML form in memory.
HTTP「チャンキング」または「転送コーディングのチャンクは、」送信者がバイナリデータの不定量を送信することを可能にします。これは、チャンクが送信される前に、各「チャンク」（データのサブストリング）の大きさの受信機に通知することによって達成されます。最後のチャンクは、ゼロ長のチャンクで示されています。チャンキングを効果的に文書をメモリ内の非XML形式からオンラインで生成された大規模なXML文書を転送するために使用することができます。
In terms of its application to SOAP message exchanges, persistent connections are clearly important for performance reasons and are particularly important when the persistence of authenticated connections is at stake. When one considers that messages of dynamic length are the rule rather than the exception for SOAP messages, it is also clear that Chunking is very useful. In some cases, it is possible to buffer a SOAP response and determine its length before sending, but the storage requirements for this are prohibitive for many devices. Together, these two features provide a good foundation for device management using SOAP over HTTP. HTTP chunking and persistent connections [5] SHOULD be used.
認証された接続の持続性が危機に瀕しているとき、SOAPメッセージ交換への応用の観点では、持続的接続は、パフォーマンス上の理由から明らかに重要であり、特に重要です。 1のダイナミック長のメッセージはルールではなく、SOAPメッセージの例外であることを考えると、チャンキングは非常に有用であることも明らかです。いくつかの例では、SOAP応答をバッファリングし、送信する前にその長さを決定することが可能であるが、このためのストレージ要件は、多くのデバイスのために法外です。一緒に、これら2つの機能は、SOAP over HTTPを使用して、デバイス管理のための優れた基盤を提供します。 HTTPのチャンクと永続的な接続[5]使用されてください。
Although not widely adopted by the Web Services community, BEEP is an excellent substrate for SOAP [12]. In particular, it provides for request/response message exchanges initiated by either BEEP peer and allows the number of response messages to be arbitrary (including zero). The BEEP profile for SOAP simply makes use of a single BEEP channel for exchanging SOAP messages and benefits from BEEP's inherent strengths for message exchange over a single transport connection.
広くWebサービスコミュニティによって採用されていないが、BEEPはSOAP [12]のための優れた基質です。特に、それは、いずれかのBEEPピアによって開始された要求/応答メッセージ交換を提供し、応答メッセージの数（ゼロを含む）を任意にすることができます。 SOAPのためのBEEPプロフィールは、単純に単一のトランスポート接続を介してメッセージ交換のためのBEEPの本来の強みからSOAPメッセージと利益を交換するための単一BEEPチャンネルを利用します。
It is not the goal of this document to cover the SOAP [3] specification in detail. Instead, we provide a few comments that may be of interest to an implementor of NETCONF over SOAP.
詳細にSOAP [3]仕様をカバーするために、このドキュメントの目的ではありません。代わりに、我々は、SOAP経由NETCONFの実装に関心のあるいくつかのコメントを提供しています。
NETCONF over SOAP does not make extensive use of SOAP features. For instance, NETCONF operations are not broken into SOAP message parts, and the SOAP header is not used to convey <rpc> metadata. This is a deliberate design decision as it allows the implementor to provide NETCONF over multiple substrates easily while handling the messages over those different substrates in a common way.
SOAP経由NETCONFは、SOAPの機能を広範囲に使用しません。例えば、NETCONF操作がSOAPメッセージの部分に分割されていない、とSOAPヘッダは、<RPC>メタデータを伝えるために使用されていません。それは一般的な方法でそれらの異なる基板の上にメッセージを処理しながら、実装が簡単に複数の基板の上にNETCONFを提供することができますので、これは意図的な設計上の決定です。
Implementers of NETCONF over SOAP should be aware of the following characteristic of SOAP headers: a SOAP header may have the attribute "mustUnderstand", and, if it does, the recipient must either process the header block or not process the SOAP message at all, and instead generate a fault. A "mustUnderstand" header must not be silently discarded.
SOAP上NETCONFの実装は、SOAPヘッダの以下の特徴に注意してください。SOAPヘッダは、それがない場合は、受信者がヘッダブロックを処理するか、または全くSOAPメッセージを処理してはならないのいずれかで、属性「のmustUnderstand」を有していてもよく代わりに、障害を発生させます。 「のmustUnderstand」ヘッダーは黙って捨ててはいけません。
In general, however, SOAP headers are intended for application-specific uses. The NETCONF SOAP binding does not make use of SOAP headers.
しかしながら、一般に、SOAPヘッダは、アプリケーション固有の用途のために意図されています。 NETCONF SOAP SOAPヘッダーを使用しない結合。
A SOAP Fault is returned in the event of a NETCONF <rpc-error>. It is constructed essentially as a wrapper for the <rpc-error>, but it allows SOAP processors to propagate the <rpc-error> to application code using a language-appropriate exception mechanism.
SOAP障害は、NETCONF <RPC-エラー>の場合に返されます。それは、<RPCエラー>のラッパーとして本質的に構成され、それは、SOAPプロセッサは言語に適切な例外メカニズムを使用してアプリケーションコードに<RPCエラー>を伝播することを可能にします。
A SOAP Fault is constructed from an <rpc-error> as follows: the SOAP Fault Code Value is "Receiver" in the SOAP envelope namespace, the SOAP Fault Reason Text is the contents of the NETCONF <rpc-error> "error-tag", and the SOAP Fault detail is the original <rpc-error> structure.
SOAPフォルトコードの値は、SOAPエンベロープの名前空間に「レシーバー」で、SOAP障害理由テキストは、NETCONF <RPC-エラー>「エラー・タグの内容です：次のようにSOAPフォールトは、<RPC-エラー>から構成され、 」、およびSOAP障害の詳細は、元の<RPCエラー>構造です。
For instance, given the following <rpc-error>,
例えば、次の<RPCエラー>を与え、
<rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
the associated SOAP Fault message is
関連するSOAPフォルトメッセージであります
<soapenv:Envelope
xmlns:soapenv=
"http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>env:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text
xml:lang="en">MISSING_ATTRIBUTE</soapenv:Text>
</soapenv:Reason>
<detail>
<rpc-error xmlns=
"urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element> </error-info> </rpc-error> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>
<悪い要素> RPC </悪い要素> </エラー・インフォメーション> </ RPC-エラー> </詳細> </ soapenv：障害> </ soapenv：BODY> </ soapenv：封筒>
The fundamental use case for NETCONF over SOAP is that of a management console ("manager" role) managing one or more devices running NETCONF agents ("agent" role). The manager initiates an HTTP or BEEP connection to an agent and drives the NETCONF session via a sequence of SOAP messages. When the manager closes the connection, the NETCONF session is also closed.
SOAP経由NETCONFのための基本的なユースケースは、NETCONFエージェント（「エージェント」役割を）実行している1つ以上のデバイスを管理する管理コンソール（「管理者」役割）のことです。マネージャはエージェントにHTTPまたはBEEP接続を開始し、SOAPメッセージの配列を介してNETCONFセッションを駆動します。管理者が接続を閉じると、NETCONFセッションも閉じています。
A NETCONF over SOAP session is established by the initial message exchange on the underlying substrate. For HTTP, a NETCONF session is established once a SOAP message is POSTed to the NETCONF web application URI. For BEEP, a NETCONF session is established once the BEEP profile for SOAP handshake establishes the SOAP channel.
SOAPセッション上NETCONFは、下地基板上に最初のメッセージ交換によって確立されます。 SOAPメッセージは、NETCONF WebアプリケーションURIにPOSTされるとHTTPの場合は、NETCONFセッションが確立されています。 SOAPハンドシェイクのためにBEEPプロファイルはSOAPチャネルを確立後BEEPため、NETCONFセッションが確立されます。
Capabilities exchange and session ID establishment are performed through the exchange of <hello> messages. In the case of SOAP over HTTP, the HTTP client MUST send the first <hello> message. The case of SOAP over BEEP imposes no ordering constraints. For instance, the following example shows the exchange of <hello> messages and establishes a session ID value of 4. Observe that the management client initiates the exchange and the server agent assigns the session ID.
機能交換とセッションIDの確立は、<ハロー>メッセージの交換を介して行われます。 HTTP上のSOAPの場合は、HTTPクライアントは、最初の<こんにちは>メッセージを送らなければなりません。 BEEP上のSOAPの場合には順序制約を課しません。例えば、次の例では、<ハロー>メッセージの交換を示し、4のセッションID値は、管理クライアントが交換を開始し、サーバ・エージェントは、セッションIDを割り当てることを確認し確立します。
C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache
C: Pragma: no-cache
C: Content-Length: 376
C:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body>
C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <capabilities>
C: <capability>
C: urn:ietf:params:netconf:base:1.0
C: </capability>
C: </capabilities>
C: </hello>
C: </soapenv:Body>
C: </soapenv:Envelope>
S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 600
S:
S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body>
S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <capabilities>
S: <capability>
S: urn:ietf:params:netconf:base:1.0
S: </capability>
S: <capability>
S: urn:ietf:params:netconf:capability:startup:1.0
S: </capability>
S: <capability>
S: http:/example.net/router/2.3/myfeature
S: </capability>
S: </capabilities>
S: <session-id>4</session-id>
S: </hello>
S: </soapenv:Body>
S: </soapenv:Envelope>
NETCONF sessions are persistent for both performance and semantic reasons. NETCONF session state contains the following:
NETCONFセッションは、パフォーマンスとセマンティック上の理由の両方のための永続的です。 NETCONFセッション状態には、次のものが含まれています。
Authentication must be maintained throughout a session due to the fact that it is expensive to establish. Capability Information is maintained so that appropriate operations can be applied during a session. Locks are released upon termination of a session as this makes the protocol more robust. Pending operations come and go from existence during the normal course of remote procedure call (RPC) operations. Operation sequence numbers provide the small but necessary state information to refer to operations during the session.
認証が原因確立するのに高価であるという事実のために、セッション全体を通して維持されなければなりません。適切な操作は、セッション中に適用できるように能力情報が維持されています。このプロトコルは、より堅牢になりようロックは、セッションの終了時に放出されています。保留中の操作が来て、リモートプロシージャコール（RPC）操作の通常の過程の間に存在するから行きます。動作シーケンス番号は、セッション中に動作を参照するために、小さいが必要な状態情報を提供します。
In the case of SOAP over HTTP, a NETCONF session is supported by an HTTP connection with an authenticated user. For SOAP over BEEP, a NETCONF session is supported by a BEEP channel operating according to the BEEP profile for SOAP [12].
HTTP上のSOAPの場合、NETCONFセッションは、認証されたユーザとのHTTP接続によって支持されています。 BEEP上SOAPため、NETCONFセッションはSOAP [12]のためのBEEPプロファイルに従って動作BEEPチャンネルによってサポートされています。
To allow automated cleanup, NETCONF over SOAP session teardown takes place when the underlying connection (in the case of HTTP) or channel (in the case of BEEP) is closed. Note that the root cause of such teardown may be the closure of the TCP connection under either HTTP or BEEP as the case may be. NETCONF managers and agents must be capable of programatically closing the transport connections associated with NETCONF sessions, such as in response to a <close-session> operation; thus, the HTTP or BEEP substrate implementation must expose this appropriately.
（BEEPの場合）またはチャネル（HTTPの場合）基になる接続が閉じられたときに自動クリーンアップを可能にするには、NETCONFは、SOAPセッションのティアダウンを介して行われます。場合によっては、このようなティアダウンの根本的な原因は、HTTPまたはBEEPのいずれかの下のTCPコネクションの閉鎖であってもよいことに注意してください。 NETCONFマネージャおよびエージェントは、プログラム的に、このような<クローズセッション>操作に応じてとしてNETCONFセッションに関連付けられたトランスポート接続を閉じることができなければなりません。このように、HTTPまたはBEEP基板の実装が適切にこれを公開しなければなりません。
Since the proposed WSDL (in Section 3.7) uses document/literal encoding, the use of a SOAP header and body has little impact on the representation of a NETCONF operation. This example shows HTTP/1.1 for simplicity. An example for BEEP would be similar.
（セクション3.7）で提案されたWSDLは、ドキュメント/リテラルエンコードを使用するので、SOAPヘッダと本体を使用することは、NETCONF動作の表現にほとんど影響しません。この例では、簡単のためにHTTP / 1.1を示しています。 BEEPのための例は同様であろう。
C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache
C: Pragma: no-cache
C: Content-Length: 465
C:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body>
C: <rpc message-id="101"
C: xmlns="xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config>
C: <filter type="subtree">
C: <top xmlns="http://example.com/schema/1.2/config">
C: <users/>
C: </top>
C: </filter>
C: </get-config>
C: </rpc>
C: </soapenv:Body>
C: </soapenv:Envelope>
The HTTP/1.1 response is also straightforward:
HTTP / 1.1レスポンスも簡単です。
S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 917 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <rpc-reply message-id="101" S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> S: <data> S: <top xmlns="http://example.com/schema/1.2/config"> S: <users> S: <user> S: <name>root</name> S: <type>superuser</type> S: <full-name>Charlie Root</full-name> S: <dept>1</dept> S: <id>1</id> S: </company-info> S: </user>
S：HTTP / 1.1 200 OK S：コンテンツタイプ：アプリケーション/石鹸+ xmlの;文字セット= UTF-8 S：コンテンツの長さ：917 S：S：の<？xml version = "1.0" エンコード= "UTF-8"？> S：<soapenv：封筒S：のxmlns：soapenv = "のhttp：// www.w3.org/2003/05/soap-envelope "> S <soapenv：BODY> S <RPC応答メッセージ-ID =" 101" S：のxmlns = "URN：IETF：paramsは：XML：NS： NETCONF：ベース：1.0 "> S：<データ> S：<トップのxmlns =" http://example.com/schema/1.2/config "> S：<ユーザー> S：<ユーザー> S：<名前>ルート</名前> S <タイプ>スーパーユーザー</タイプ> S <フルネーム>チャーリー・ルート</フル名> S <DEPT> 1 </ DEPT> S：<ID> 1 </ ID> S ：</会社情報> S：</ユーザー>
S: <user> S: <name>fred</name> S: <type>admin</type> S: <full-name>Fred Flintstone</full-name> S: <dept>2</dept> S: <id>2</id> S: </company-info> S: </user> S: </users> S: </top> S: </data> S: </rpc-reply> S: </soapenv:Body> S: </soapenv:Envelope>
S：<ユーザー> S：<名前>フレッド</名前> S：<タイプ>管理者</入力> S：<フルネーム>フレッド・フリントストーン</フル名> S：<DEPT> 2 </ DEPT> S：<ID> 2 </ ID> S：</会社情報> S：</ユーザー> S：</ユーザー> S：</トップ> S：</データ> S：</ RPC-返信> S：</ soapenv：ボディ> S：</ soapenv：封筒>
<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" xmlns:netb="urn:ietf:params:xml:ns:netconf:base:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0" name="netconf-soap_1.0.wsdl">
<？xml version = "1.0" エンコード= "UTF-8"？> <定義のxmlns = "http://schemas.xmlsoap.org/wsdl/" のxmlns：SOAP = "http://schemas.xmlsoap.org/ WSDL / SOAP / "のxmlns：TNS = "URN：IETF：paramsは：XML：NS：NETCONF：石けん：1.0" のxmlns：NETB = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のtargetNamespace =" URN：IETF：のparams：XML：NS：NETCONF：石鹸：1.0" 名前= "NETCONF-soap_1.0.wsdl">
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" location="http://www.iana.org/assignments/xml-registry/ schema/netconf.xsd" />
<インポート名前空間= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" 場所= "http://www.iana.org/assignments/xml-registry/スキーマ/ netconf.xsd" />
<message name="helloRequest"> <part name="in" element="netb:hello"/> </message> <message name="helloResponse"> <part name="out" element="netb:hello"/> </message>
<メッセージ名= "helloRequest"> <部品名=要素 "に" = "NETB：こんにちは" /> </メッセージ> <メッセージ名= "helloResponse"> <部品名= "アウト" 要素= "NETB：こんにちは" /> </メッセージ>
<message name="rpcRequest"> <part name="in" element="netb:rpc"/> </message> <message name="rpcResponse"> <part name="out" element="netb:rpc-reply"/> </message>
<メッセージ名= "rpcRequest"> <部品名=要素= "中" "NETB：RPC" /> </メッセージ> <メッセージ名= "rpcResponse"> <部品名= "アウト" 要素= "NETB：RPC-返信 "/> </メッセージ>
<portType name="netconfPortType"> <operation name="rpc"> <input message="tns:rpcRequest"/> <output message="tns:rpcResponse"/>
<portTypeの名前= "netconfPortType"> <操作名= "RPC"> <入力メッセージ= "TNS：rpcRequest" /> <出力メッセージ= "TNS：rpcResponse" />
</operation> <operation name="hello"> <input message="tns:helloRequest"/> <output message="tns:helloResponse"/> </operation> </portType>
</動作> <操作名= "こんにちは"> <入力メッセージ= "TNS：helloRequest" /> <出力メッセージ= "TNS：helloResponse" /> </動作> </ portTypeの>
<binding name="netconfBinding" type="tns:netconfPortType"> <SOAP:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="hello"> <SOAP:operation/> <input> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/> </input> <output> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/> </output> </operation> <operation name="rpc"> <SOAP:operation/> <input> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/> </input> <output> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/> </output> </operation> </binding>
<バインディング名= "netconfBinding" タイプ= "TNS：netconfPortType"> <SOAP：結合スタイル= "文書" トランスポート= "http://schemas.xmlsoap.org/soap/http" /> <操作名= "こんにちは" > <SOAP：操作/> <入力> <SOAP：ボディ使用= "リテラル" 名前空間= "URN：IETF：paramsは：XML：NS：NETCONF：石けん：1.0" /> </入力> <出力> <SOAP：ボディ使用= "リテラル" 名前空間= "壷：IETF：のparams：XML：NS：NETCONF：石鹸：1.0" /> </出力> </操作> <操作名= "RPC"> <SOAP：操作/> <入力> <SOAP：ボディ使用= "リテラル" 名前空間= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" /> </入力> <出力> <SOAP：ボディ使用= "リテラル" 名前空間= "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" /> </出力> </動作> </結合>
</definitions>
</定義>
The following WSDL document assumes a local location for the NETCONF over SOAP WSDL definitions. A typical deployment of a device manageable via NETCONF over SOAP would provide a service definition similar to the following to identify the address of the device.
次のWSDL文書は、SOAP、WSDL定義の上にNETCONFのためのローカルの場所を想定しています。 SOAP経由NETCONFを経由して管理可能デバイスの典型的な展開は、デバイスのアドレスを識別するために、次のようなサービス定義を提供します。
<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:nets="urn:ietf:params:xml:ns:netconf:soap:1.0" targetNamespace="urn:myNetconfService" name="myNetconfService.wsdl">
<？xml version = "1.0" エンコード= "UTF-8"？> <定義のxmlns = "http://schemas.xmlsoap.org/wsdl/" のxmlns：SOAP = "http://schemas.xmlsoap.org/ WSDL / SOAP /」のxmlns：ネット= "壷：IETF：のparams：XML：NS：NETCONF：石鹸：1.0" のtargetNamespace = "壷：myNetconfService" 名前= "myNetconfService.wsdl">
<import namespace="urn:ietf:params:xml:ns:netconf:soap:1.0" location="http://localhost:8080/netconf/ schema/netconf-soap_1.0.wsdl"/>
<インポート名前空間= "壷：IETF：のparams：XML：NS：NETCONF：石鹸：1.0" 場所= "にhttp：// localhost：8080 / NETCONF /スキーマ/ NETCONF-soap_1.0.wsdl" />
<service name="netconf"> <port name="netconfPort" binding="nets:netconfBinding"> <SOAP:address location="http://localhost:8080/netconf"/> </port> </service>
<サービス名= "NETCONF"> <ポート名= "netconfPort" 結合= "ネット：netconfBinding"> <SOAP：アドレス場所= "にhttp：// localhost：8080 / NETCONF" /> </ポート> </サービス>
</definitions>
</定義>
NETCONF is used to access and modify configuration information, so the ability to access this protocol should be limited to users and systems that are authorized to view or modify the agent's configuration data.
NETCONFは、アクセスして設定情報を変更するために使用されているので、このプロトコルにアクセスする能力は、ユーザとエージェントのコンフィギュレーションデータを表示または変更することが許可されているシステムに限定されるべきです。
Because configuration information is sent in both directions, it is not sufficient for just the client or user to be authenticated with the server. The identity of the server should also be authenticated with the client.
構成情報が両方向に送信されるため、それはサーバーで認証するだけで、クライアントやユーザーには十分ではありません。サーバーのIDは、クライアントで認証する必要があります。
Configuration data may include sensitive information, such as user names or security keys. So, NETCONF should only be used over communications channels that provide strong encryption for data privacy.
コンフィギュレーション・データは、ユーザー名またはセキュリティキーとして、機密情報を含むことができます。だから、NETCONFはデータのみのプライバシーのための強力な暗号化を提供し、通信チャネルを介して使用する必要があります。
If the NETCONF server provides remote access through insecure protocols, such as HTTP, care should be taken to prevent execution of the NETCONF program when strong user authentication or data privacy is not available.
NETCONFサーバは、HTTPなどの安全でないプロトコルを介したリモートアクセスを提供している場合、強力なユーザー認証やデータのプライバシーが利用できない場合、注意がNETCONFプログラムの実行を防ぐために取られるべきです。
The IANA assigned port SHOULD be used, as this provides a means for efficient firewall filtering during possible denial-of-service attacks.
これが可能でサービス拒否攻撃の間に効率的なファイアウォールフィルタリングするための手段を提供するようにIANAに割り当てられたポートを使用すべきです。
The NETCONF SOAP binding relies on an underlying secure transport for integrity and privacy. Such transports are expected to include TLS [9] (which, when combined with HTTP, is referred to as HTTPS) and IPsec. There are a number of options for authentication (some of which are deployment-specific): o within the transport (such as with TLS client certificates)
バインディングNETCONF SOAPは、整合性とプライバシーのための基盤となる安全な輸送に依存しています。そのような輸送は、TLS [9]（HTTPと組み合わせた場合、HTTPSと呼ばれる）およびIPsecを含むことが期待されます。 （デプロイメント固有のいくつかは）認証のための多くのオプションがあります。輸送中のO（例えばTLSクライアント証明書のように）
o within HTTP (such as Digest Access Authentication [7])
HTTP内のO（例えば、ダイジェストアクセス認証[7]）
o within SOAP (such as a digital signature in the header [17])
SOAP内のO（例えばヘッダ内のデジタル署名として[17]）
HTTP, BEEP, and SOAP level authentication can be integrated with Remote Authentication Dial-In User Service (RADIUS) [10] to support remote authentication databases.
HTTP、BEEP、およびSOAPレベルの認証は、リモート認証データベースをサポートするために、リモート認証ダイヤルインユーザーサービス（RADIUS）[10]と統合することができます。
At a miniumum, all conforming NETCONF over SOAP implementations MUST support TLS. Specifically, NETCONF over SOAP over HTTP MUST support NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST support NETCONF over SOAP over BEEP over TLS.
miniumumでは、SOAP実装の上にすべての適合NETCONFは、TLSをサポートしなければなりません。 BEEPは、TLS上でBEEPの上にSOAP上でNETCONFをサポートしなければならない上具体的には、HTTP上のSOAP経由NETCONFは、SOAP上でHTTPS上のSOAP経由NETCONF、およびNETCONFをサポートしなければなりません。
The above protocols may have various vulnerabilities, and these may be inherited by NETCONF over SOAP.
上記のプロトコルは、様々な脆弱性を有していてもよく、そしてこれらは、SOAP上NETCONFによって継承されてもよいです。
NETCONF itself may have vulnerabilities because an authorization model is not currently specified.
承認モデルが現在指定されていないので、NETCONF自体が脆弱性を有することができます。
It is important that device capabilities and authorization remain constant for the duration of any outstanding NETCONF session. In the case of NETCONF, it is important to consider that device management may be taking place over multiple substrates (in addition to SOAP), and it is important that the different substrates have a common authentication model.
デバイスの機能と承認が未処理のNETCONFセッションの間、一定のままであることが重要です。 NETCONFの場合は、そのデバイスの管理は、（SOAPに加えて）複数の基板上で行われていることも考慮することが重要であり、別の基板が共通の認証モデルを持っていることが重要です。
Some deployments of NETCONF over SOAP may choose to use transports without encryption. This presents vulnerabilities but may be selected for deployments involving closed networks or debugging scenarios.
SOAP経由NETCONFのいくつかの展開は、暗号化せずにトランスポートを使用することもできます。これは、脆弱性を提示したが、閉じたネットワークやデバッグのシナリオを含む展開するために選択することができます。
A device managed by NETCONF may interact (over protocols besides NETCONF) with devices managed by other protocols, all of differing security. Each point of entry brings with it a potential vulnerability.
NETCONFによって管理されるデバイスは、他のプロトコル、異なるセキュリティのすべてが管理するデバイスで（NETCONF以外のプロトコルを介して）相互作用することができます。エントリの各点は、それを潜在的な脆弱性をもたらします。
IANA assigned TCP port (833) for NETCONF over SOAP over BEEP, and TCP port (832) for NETCONF over SOAP over HTTPS.
BEEP上のSOAP経由NETCONFのためのIANA割り当てられたTCPポート（833）、およびHTTPS上のSOAP経由NETCONFのためのTCPポート（832）。
IANA will allow for the assignment of an XML namespace within the NETCONF namespace "urn:ietf:params:xml:ns:netconf" for the NETCONF over SOAP WSDL definitions. Following the policies outlined in RFC 2434 [14], assigned values in this subordinate namespace are requested to be allocated according to the "Specification Required" policy.
"：IETF：のparams：XML：NS：NETCONF骨壷" NETCONFのSOAP WSDL定義を超えるIANAはNETCONF名前空間内のXML名前空間の割り当てが可能になります。 [14] RFC 2434に概説された方針に続いて、この下位の名前空間に割り当てられた値は、「仕様が必要である」というポリシーに応じて割り当てられるように要求されています。
URI: urn:ietf:params:xml:ns:netconf:soap
URI：URN：IETF：のparams：XML：NS：NETCONF：石鹸
[1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[1]エンス、R.、エド。、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[2] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[2]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第二版）"、W3C REC REC-XML-20001006、2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>。
[3] Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C Recommendation REC-soap12-part1-20030624, June 2002, <http://www.w3.org/TR/soap12-part1/>.
[3] Gudgin、M.、ハドレー、M.、モロー、JJ、およびH.ニールセン、 "SOAPバージョン1.2パート1：メッセージングフレームワーク"。、W3C勧告REC-SOAP12-part1-20030624、2002年6月、<のhttp： //www.w3.org/TR/soap12-part1/>。
[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation REC-xmlschema-1-20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[4]トンプソン、H.、ブナ、D.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C勧告REC-XMLSCHEMA-1から20010502、2001年5月、<のhttp：// www.w3.org/TR/2001/REC-xmlschema-1-20010502/>。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[6] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, February 2002.
[6]、RFC 3205、2002年2月 "基材としてHTTPを使用するには、" ムーア、K.、。
[7] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[7]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、シンク、E.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[8]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月を。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[9]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤルイン" [10] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン。
[11] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[11]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[12] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 4227, January 2006.
[12] O'Tuathail、E.およびM.ローズ、 "ブロック拡張可能交換プロトコル（BEEP）でのSOAP（Simple Object Access Protocol）の使用"、RFC 4227、2006年1月。
[13] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[13] Mealling、M.、 "IETF XMLレジストリ"、RFC 3688、2004年1月。
[14] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[14] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、RFC 2434、1998年10月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[15]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[16] Christensen, E., Curbera, F., Meredith, G., and S. Weerawarana, "Web Services Description Language (WSDL) 1.1", W3C Note NOTE-wsdl-20010315, March 2001, <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
[16]クリステンセン、E.、Curbera、F.、メレディス、G.、およびS. Weerawarana氏、 "Webサービス記述言語（WSDL）1.1"、W3CノートNOTE-WSDL-20010315、2001年3月、<のhttp：// www.w3.org/TR/2001/NOTE-wsdl-20010315>。
[17] Brown, A., Fox, B., Hada, S., LaMacchia, B., and H. Maruyama, "SOAP Security Extensions: Digital Signature", W3C Note NOTE-SOAP-dsig-20010206, Feb 2001, <http://www.w3.org/TR/SOAP-dsig/>.
[17]ブラウン、A.、フォックス、B.、羽田、S.、LaMacchia、B.、およびH.丸山、 "SOAPのセキュリティ拡張機能：デジタル署名"、W3CノートNOTE-SOAP-DSIG-20010206、2001年2月、 <http://www.w3.org/TR/SOAP-dsig/>。
Author's Address
著者のアドレス
Ted Goddard ICEsoft Technologies Inc. Suite 300, 1717 10th St. NW Calgary, AB T2M 4S2 Canada
テッド・ゴダードICEsoftテクノロジーズ株式会社スイート300、1717年10セントNWカルガリー、AB T2M 4S2カナダ
Phone: (403) 663-3322 EMail: ted.goddard@icesoft.com URI: http://www.icesoft.com
電話：（403）663-3322 Eメール：ted.goddard@icesoft.com URI：http://www.icesoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
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彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
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機能のための基金は現在、インターネット協会によって提供されます。