RFC 3288 - Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3288
タイトル : RFC 3288 - ブロック拡張可能な交換プロトコル（BEEP）でSimple Object Accessプロトコル（SOAP）を使用
翻訳編集 : 自動生成

[要約] 要約：RFC 3288は、BEEPプロトコル内でSOAPを使用するためのガイドラインを提供しています。目的：SOAPをBEEPプロトコルに統合するための手順とベストプラクティスを提供し、相互運用性と拡張性を向上させることを目指しています。

Network Working Group                                      E. O'Tuathail
Request for Comments: 3288                                  Clipcode.com
Category: Standards Track                                        M. Rose
                                            Dover Beach Consulting, Inc.
                                                               June 2002

Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)

ブロック拡張可能な交換プロトコル（BEEP）でSimple Object Accessプロトコル（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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network.

このメモは、Simple Object Access Protocol（SOAP）Binding Binding Blocks Extensible Exchange Protocol Core（BEEP）を指定します。SOAPバインディングは、ネットワーク内でSOAPメッセージがどのように送信されるかを説明しています。

The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.

SOAPは、さまざまな分散メッセージングモデルを実装するために使用されるXMLベースの（拡張可能なマークアップ言語）メッセージングプロトコルです。メッセージ形式を定義し、RPC、非同期イベント通知、未充填メッセージ、SOAP仲介者による転送など、さまざまなメッセージパターンを説明しますが、これらに限定されません。

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    BEEP Profile Identification  . . . . . . . . . . . . . . . .  4
   2.1   Profile Initialization . . . . . . . . . . . . . . . . . . .  5
   3.    SOAP Message Packages  . . . . . . . . . . . . . . . . . . .  7
   4.    SOAP Message Patterns  . . . . . . . . . . . . . . . . . . .  9
   4.1   One-way Message  . . . . . . . . . . . . . . . . . . . . . .  9
   4.2   Request-Response Exchange  . . . . . . . . . . . . . . . . .  9
   4.3   Request/N-Responses Exchange . . . . . . . . . . . . . . . .  9
   5.    URL Schemes  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.1   The soap.beep URL Scheme . . . . . . . . . . . . . . . . . . 10
   5.1.1 Resolving IP/TCP Address Information . . . . . . . . . . . . 10
   5.2   The soap.beeps URL Scheme  . . . . . . . . . . . . . . . . . 11
   6.    Registration Templates . . . . . . . . . . . . . . . . . . . 12
   6.1   SOAP Profile Feature Registration Template . . . . . . . . . 12
   7.    Initial Registrations  . . . . . . . . . . . . . . . . . . . 13
   7.1   Registration: The SOAP Profile . . . . . . . . . . . . . . . 13
   7.2   Registration: The soap.beep URL Scheme . . . . . . . . . . . 14
   7.3   Registration: The soap.beeps URL Scheme  . . . . . . . . . . 15
   7.4   Registration: The System (Well-Known) TCP port number for
         SOAP over BEEP . . . . . . . . . . . . . . . . . . . . . . . 15
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
         IANA Considerations  . . . . . . . . . . . . . . . . . . . . 18
         Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 20

1. Introduction

1. はじめに

This memo specifies how SOAP 1.1 envelopes[1] are transmitted using a BEEP profile[2]. In the W3C, the XMLP effort is evolving SOAP. Accordingly, this memo provides a mechanism for negotiating the use of new features.

このメモは、SOAP 1.1エンベロープ[1]がビーププロファイル[2]を使用して送信される方法を指定します。W3Cでは、XMLPの取り組みが石鹸を進化させています。したがって、このメモは、新機能の使用を交渉するためのメカニズムを提供します。

Throughout this memo, the term "envelope" refers to the "SOAP-Env:Envelope" element defined in Section 4 of [1]. Further, the terms "peer", "client", "server", "one-to-one", and "one-to-many" are used in the context of BEEP. In particular, Sections 2.1 and 2.1.1 of [2] discuss BEEP roles and exchange styles.

このメモを通して、「エンベロープ」という用語は、[1]のセクション4で定義されている「石鹸ENV：エンベロープ」要素を指します。さらに、「ピア」、「クライアント」、「サーバー」、「1対1」、および「1対1〜」という用語がビープ音のコンテキストで使用されます。特に、[2]のセクション2.1および2.1.1は、ビープ音の役割と交換スタイルについて説明します。

2. BEEP Profile Identification

2. ビーププロファイルの識別

The BEEP profile for SOAP is identified as

石鹸のビーププロファイルはとして識別されます

http://iana.org/beep/soap

in the BEEP "profile" element during channel creation.

チャネル作成中のビープ音の「プロファイル」要素。

In BEEP, when the first channel is successfully created, the "serverName" attribute in the "start" element identifies the "virtual host" associated with the peer acting in the server role, e.g.,

ビープ音では、最初のチャネルが正常に作成されると、「start」要素の「servername」属性は、サーバーの役割で行動するピアに関連する「仮想ホスト」を識別します。

       <start number='1' serverName='stockquoteserver.example.com'>
           <profile uri='http://iana.org/beep/soap' />
       </start>

The "serverName" attribute is analagous to HTTP's "Host" request-header field (c.f., Section 14.23 of [3]).

「servername」属性は、HTTPの「ホスト」リクエストヘッダーフィールド（C.F.、[3]のセクション14.23）に類似しています。

There are two states in the BEEP profile for SOAP, "boot" and "ready":

ソープのビープ音プロファイルには、「ブーツ」と「準備ができている」という2つの状態があります。

o In the "boot" state, the peer requesting the creation of the channel sends a "bootmsg" (either during channel initialization or in a "MSG" message).

o 「ブート」状態では、チャンネルの作成を要求するピアは、「ブートスグ」を送信します（チャネル初期化中または「MSG」メッセージのいずれか）。

* If the other peer sends a "bootrpy" (either during channel initialization or in a "RPY" message), then the "ready" state is entered

* 他のピアが「bootrpy」（チャネル初期化中または「rpy」メッセージのいずれか）を送信する場合、「準備ができた」状態が入力されます

* Otherwise, the other peer sends an "error" (either during channel initialization or in a "ERR" message), then no state change occurs.

* それ以外の場合、他のピアは「エラー」を送信します（チャネル初期化中または「ERR」メッセージのいずれか）、状態の変更は発生しません。

o In the "ready" state, either peer begins a SOAP message pattern by sending a "MSG" message containing an envelope. The other peer completes the message pattern either by:

o 「Ready」状態では、いずれかのPEERが封筒を含む「MSG」メッセージを送信することにより、SOAPメッセージパターンを開始します。他のピアは、次のいずれかでメッセージパターンを完成させます。

* sending back a "RPY" message containing an envelope; or,

* 封筒を含む「RPY」メッセージを送り返します。または、

* sending back zero or more "ANS" messages, each containing an envelope, followed by a "NUL" message.

* ゼロ以上の送信」と「メッセージ、それぞれが封筒を含み、その後に「null」メッセージが続きます。

Regardless, no state change occurs.

とにかく、状態の変更は発生しません。

2.1 Profile Initialization

2.1 プロファイルの初期化

The boot message is used for two purposes:

ブートメッセージは2つの目的で使用されます。

resource identification: each channel bound to the BEEP profile for SOAP provides access to a single resource (a network data object or service).

リソース識別：SOAPのビープ音プロファイルにバインドされた各チャネルは、単一のリソース（ネットワークデータオブジェクトまたはサービス）へのアクセスを提供します。

feature negotiation: if new features of SOAP (such as compression) emerge, their use can be negotiated.

機能交渉：石鹸の新機能（圧縮など）が出現する場合、それらの使用は交渉できます。

The DTD syntax for the boot message and its response are:

ブートメッセージのDTD構文とその応答は次のとおりです。

       <!ELEMENT bootmsg     EMPTY>
       <!ATTLIST bootmsg
                 resource    CDATA             #REQUIRED
                 features    NMTOKENS          "">

       <!ELEMENT bootrpy     EMPTY>
       <!ATTLIST bootrpy
                 features    NMTOKENS          "">

The boot message contains a mandatory and an optional attribute:

ブートメッセージには、必須の属性とオプションの属性が含まれています。

o the "resource" attribute, which is analagous to HTTP's "abs_path" Request-URI parameter (c.f., Section 5.1.2 of [3]); and,

o 「リソース」属性は、HTTPの「ABS_PATH」リクエスト-URIパラメーター（C.F.、[3]のセクション5.1.2）に類似しています。そして、

o the "features" attribute, which, if present, contains one or more feature tokens, each indicating an optional feature of the BEEP profile for SOAP that is being requested for possible use over the channel.

o 「機能」属性は、存在する場合、1つ以上の機能トークンが含まれており、それぞれがチャネルでの使用の可能性が要求されている石鹸のビーププロファイルのオプションの機能を示しています。

Section 6.1 defines a registration template for optional features.

セクション6.1は、オプションの機能の登録テンプレートを定義します。

If the peer acting in the server role recognizes the requested resource, it replies with the boot response that contains one optional attribute:

サーバーの役割で行動するピアが要求されたリソースを認識した場合、1つのオプションの属性を含むブート応答で応答します。

o the "features" attribute, if present, contains a subset of the feature tokens in the boot message, indicating which features may be used over the channel. (If not present or empty, then no features may be used.)

o 存在する場合は、「機能」属性には、ブートメッセージに特徴トークンのサブセットが含まれており、チャネルで使用できる機能を示します。（存在していない場合も空でもない場合は、機能は使用できません。）

Otherwise, if the boot message is improperly formed, or if the requested resource isn't recognized, the peer acting in the server role replies with an error message (c.f., Section 7.1 of [2]).

それ以外の場合、ブートメッセージが不適切に形成されている場合、または要求されたリソースが認識されていない場合、サーバーの役割で作用するピアはエラーメッセージ（C.F.、[2]のセクション7.1）で応答します。

Typically, the boot message and its response are exchanged during channel initialization (c.f., Section 2.3.1.2 of [2]).

通常、ブートメッセージとその応答は、チャネル初期化中に交換されます（C.F.、[2]のセクション2.3.1.2）。

For example, here the boot message and its response are exchanged during channel initialization:

たとえば、ここでは、ブートメッセージとその応答は、チャネル初期化中に交換されます。

       C: <start number='1' serverName='stockquoteserver.example.com'>
       C:     <profile uri='http://iana.org/beep/soap'>
       C:         <![CDATA[<bootmsg resource='/StockQuote' />]]>
       C:     </profile>
       C: </start>

       S: <profile uri='http://iana.org/beep/soap'>
       S:     <![CDATA[<bootrpy />]]>
       S: </profile>

The channel bound to the BEEP profile for SOAP is now in the "ready" state.

石鹸のビーププロファイルに縛られたチャネルは、現在「準備が整った」状態にあります。

Alternatively, here is an example in which the boot exchange is unsuccessful:

または、ブート交換が失敗した例を次に示します。

       C: <start number='1' serverName='stockquoteserver.example.com'>
       C:     <profile uri='http://iana.org/beep/soap'>
       C:         <![CDATA[<bootmsg resource='/StockPick' />]]>
       C:     </profile>
       C: </start>

       S: <profile uri='http://iana.org/beep/soap'>
       S:     <![CDATA[<error code='550'>resource not
       S:                                supported</error>]]>
       S: </profile>

Although the channel was created successfully, it remains in the "boot" state.

チャネルは正常に作成されましたが、「ブート」状態にとどまります。

3. SOAP Message Packages

3. 石鹸メッセージパッケージ

The BEEP profile for SOAP transmits envelopes encoded as UTF-8 using the media type "application/xml"[4], e.g.,

メディアタイプ「アプリケーション/XML」[4]を使用して、UTF-8としてエンコードされたエンベロープを送信するSOAPのビーププロファイルは、例えば、

   MSG 1 1 . 0 364
   Content-Type: application/xml

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> END In addition, the BEEP profile for SOAP also allows envelopes to be transmitted as the root part of a "multipart/related"[5] content, and with subordinate parts referenced using the rules of Section 3 of [6] (i.e., using either the "Content-ID:"[7] or "Content-Location:"[8] headers), e.g.,

<Soap-env：Envelope Xmlns：Soap-env = "http://schemas.xmlsoap.org/soap/envelope/" Soap-env：encodingstyle = "http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV：body> <m：getLastTradePrice XMLNS：M = "Some-uri"> <symbol> dis </symbol> </m：getLasttradeprice> </soap-env：body> </soap-env：/soap-env：envelope> endさらに、石鹸のビーププロファイルでは、[マルチパート/関連]コンテンツのルート部分として封筒を送信することもできます。、「content-id」：[7]または「content-location：」のいずれかを使用します。

   MSG 1 2 . 364 668
   Content-Type: multipart/related; boundary="MIME_boundary";
                 type=application/xml;
                 start="<claim061400a.xml@claiming-it.com>"

   --MIME_boundary
   Content-Type: application/xml
   Content-ID: <claim061400a.xml@claiming-it.com>

   <?xml version='1.0' ?>
   <SOAP-ENV:Envelope
     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
   ..
   <theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
   ..
   </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>

   --MIME_boundary
   Content-Type: image/tiff
   Content-Transfer-Encoding: binary
   Content-ID: <claim061400a.tiff@claiming-it.com>

...binary TIFF image... --MIME_boundary-- END

...バイナリTIFF画像... - mime_boundary-エンド

Consistent with Section 2 of [6], it is strongly recommended that the multipart contain a "start" parameter, and that the root part contain a "Content-ID:" header. However, because BEEP provides an 8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Further note that MIME[9] requires that the value of the "Content-ID" header be globally unique.

[6]のセクション2と一致して、マルチパートには「start」パラメーターを含み、ルート部分に「コンテンツID」ヘッダーを含むことを強くお勧めします。ただし、ビープ音は8ビット幅のパスを提供するため、「変換される」コンテンツトランスファーエンコード（例：「base64」または「引用プリント可能」）を使用しないでください。さらに、MIME [9]では、「コンテンツID」ヘッダーの値がグローバルにユニークであることが必要であることに注意してください。

4. SOAP Message Patterns

4. 石鹸メッセージパターン

4.1 One-way Message

4.1 一方向のメッセージ

A one-way message involves sending a message without any response being returned.

一方向のメッセージには、応答を返さずにメッセージを送信することが含まれます。

The BEEP profile for SOAP achieves this using a one-to-many exchange, in which the client sends a "MSG" message containing an envelope, and the server immediately sends back a "NUL" message, before processing the contents of the envelope.

SOAPのビーププロファイルは、1対多数の交換を使用してこれを実現します。この交換では、クライアントがエンベロープを含む「MSG」メッセージを送信し、サーバーはエンベロープの内容を処理する前にすぐに「NUL」メッセージを送信します。

4.2 Request-Response Exchange

4.2 リクエスト応答交換

A request/response exchange involves sending a request, which results in a response being returned.

リクエスト/応答交換には、リクエストの送信が含まれ、その結果、応答が返されます。

The BEEP profile for SOAP achieves this using a one-to-one exchange, in which the client sends a "MSG" message containing an envelope, and the server sends back a "RPY" message containing an envelope.

SOAPのビーププロファイルは、1対1の交換を使用してこれを実現し、クライアントはエンベロープを含む「MSG」メッセージを送信し、サーバーはエンベロープを含む「RPY」メッセージを送り返します。

Finally, the BEEP profile for SOAP does not use the "ERR" message for SOAP faults when performing one-to-one exchanges -- whatever response is generated by the server is always returned in the "RPY" message.

最後に、SOAPのビーププロファイルは、1対1の交換を実行するときに石鹸障害に「ERR」メッセージを使用しません。サーバーによって生成される応答は、常に「RPY」メッセージで返されます。

4.3 Request/N-Responses Exchange

4.3 Request/n-responses Exchange

A request/N-responses exchange involves sending a request, which results in zero or more responses being returned.

リクエスト/n応答の交換には、リクエストの送信が含まれます。その結果、応答はゼロ以上になります。

The BEEP profile for SOAP achieves this using a one-to-many exchange, in which the client sends a "MSG" message containing an envelope, and the server sends back zero or more "ANS" messages, each containing an envelope, followed by a "NUL" message.

SOAPのビーププロファイルは、1対多数の交換を使用してこれを実現します。この交換では、クライアントがエンベロープを含む「MSG」メッセージを送信し、サーバーはそれぞれがエンベロープを含むゼロ以上の「Ans」メッセージを送り返し、その後に続きます。「nul」メッセージ。

5. URL Schemes

5. URLスキーム

This memo defines two URL schemes, "soap.beep" and "soap.beeps", which identify the use of SOAP over BEEP over TCP. Note that, at present, a "generic" URL scheme for SOAP is not defined.

このメモは、TCPよりもビープ音を介した石鹸の使用を識別する2つのURLスキーム「Soap.Beep」と「Soap.Beeps」を定義します。現在、石鹸の「一般的な」URLスキームは定義されていないことに注意してください。

5.1 The soap.beep URL Scheme

5.1 SOAP.BEEP URLスキーム

The "soap.beep" URL scheme uses the "generic URI" syntax defined in Section 3 of [10], specifically:

「SOAP.BEEP」URLスキームは、[10]のセクション3で定義されている「ジェネリックURI」構文を使用します。

o the value "soap.beep" is used for the scheme component; and,

o 値「soap.beep」は、スキームコンポーネントに使用されます。そして、

o the server-based naming authority defined in Section 3.2.2 of [10] is used for the authority component.

o [10]のセクション3.2.2で定義されているサーバーベースの命名機関は、権限コンポーネントに使用されます。

o the path component maps to the "resource" component of the boot message sent during profile initialization (if absent, it defaults to "/").

o パスコンポーネントは、プロファイルの初期化中に送信されたブートメッセージの「リソース」コンポーネントにマップします（不在の場合、デフォルトは「/」になります）。

The values of both the scheme and authority components are case-insensitive.

スキームコンポーネントと権限コンポーネントの両方の値は、ケース非感受性です。

For example, the URL

たとえば、URL

soap.beep://stockquoteserver.example.com/StockQuote

soap.beep：//stockquoteserver.example.com/stockquote

might result in the example shown in Section 2.1.

セクション2.1に示されている例になる可能性があります。

5.1.1 Resolving IP/TCP Address Information

5.1.1 IP/TCPアドレス情報の解決

The "soap.beep" URL scheme indicates the use of the BEEP profile for SOAP running over TCP/IP.

「SOAP.BEEP」URLスキームは、TCP/IPを介して実行されるSOAPにビープ音プロファイルの使用を示しています。

If the authority component contains a domain name and a port number, e.g.,

当局コンポーネントにドメイン名とポート番号が含まれている場合、例えば、

soap.beep://stockquoteserver.example.com:1026

soap.beep：//stockquoteserver.example.com：1026

then the DNS is queried for the A RRs corresponding to the domain name, and the port number is used directly.

次に、DNSはドメイン名に対応するA RRSに対して照会され、ポート番号は直接使用されます。

If the authority component contains a domain name and no port number, e.g.,

当局コンポーネントにドメイン名とポート番号がない場合、例えば、

soap.beep://stockquoteserver.example.com

soap.beep：//stockquoteserver.example.com

the SRV algorithm[11] is used with a service parameter of "soap-beep" and a protocol parameter of "tcp" to determine the IP/TCP addressing information. If no appropriate SRV RRs are found (e.g., for "_soap-beep._tcp.stockquoteserver.example.com"), then the DNS is queried for the A RRs corresponding to the domain name and the port number used is assigned by the IANA for the registration in Section 7.4.

SRVアルゴリズム[11]は、「SOAP-Beep」のサービスパラメーターと「TCP」のプロトコルパラメーターで使用され、IP/TCPアドレス指定情報を決定します。適切なSRV RRが見つからない場合（例： "_soap-beep._tcp.stockquoteserver.example.com"の場合）、DNSはドメイン名に対応するA RRSに対して照会され、使用されるポート番号はianaによって割り当てられますセクション7.4の登録用。

If the authority component contains an IP address, e.g.,

当局コンポーネントにIPアドレスが含まれている場合、

soap.beep://10.0.0.2:1026

soap.beep：//10.0.0.2：1026

then the DNS is not queried, and the IP address is used directly. If a port number is present, it is used directly; otherwise, the port number used is assigned by the IANA for the registration in Section 7.4.

その後、DNSは照会されず、IPアドレスが直接使用されます。ポート番号が存在する場合、直接使用されます。それ以外の場合、使用されるポート番号は、セクション7.4の登録のためにIANAによって割り当てられます。

While the use of literal IPv6 addresses in URLs is discouraged, if a literal IPv6 address is used in a "soap.beep" URL, it must conform to the syntax specified in [12].

URLでのリテラルIPv6アドレスの使用は落胆しますが、「SOAP.BEEP」URLでリテラルIPv6アドレスが使用されている場合、[12]で指定された構文に適合する必要があります。

5.2 The soap.beeps URL Scheme

5.2 SOAP.BEEPS URLスキーム

The "soap.beeps" URL scheme is identical, in all ways, to the "soap.beep" URL scheme specified in Section 5.1, with the exception that prior to starting the BEEP profile for SOAP, the BEEP session must be tuned for privacy. In particular, note that both URL schemes use the identical algorithms and parameters for address resolution as specified in Section 5.1.1 (e.g., the same service name for SRV lookups, the same port number for TCP, and so on).

「SOAP.BEEPS」URLスキームは、セクション5.1で指定された「SOAP.BEEP」URLスキームとあらゆる点で同一です。。特に、両方のURLスキームは、セクション5.1.1で指定されているように、アドレス解像度の同一のアルゴリズムとパラメーターを使用していることに注意してください（たとえば、SRVルックアップの同じサービス名、TCPの同じポート番号など）。

There are two ways to perform privacy tuning on a BEEP session, either:

ビープセッションでプライバシーチューニングを実行するには、次の2つの方法があります。

o a transport security profile may be successfully started; or,

o 輸送セキュリティプロファイルが正常に開始される場合があります。または、

o a user authentication profile that supports transport security may be successfully started.

o トランスポートセキュリティをサポートするユーザー認証プロファイルが正常に開始される場合があります。

Regardless, upon completion of the negotiation process, a tuning reset occurs in which both BEEP peers issue a new greeting. Consult Section 3 of [2] for an example of how a BEEP peer may choose to issue different greetings based on whether privacy is in use.

とにかく、交渉プロセスが完了すると、両方のビープ音が新しい挨拶をするチューニングリセットが発生します。ビープピアがプライバシーが使用されているかどうかに基づいて、さまざまな挨拶を発行することを選択する方法の例については、[2]のセクション3を参照してください。

6. Registration Templates

6. 登録テンプレート

6.1 SOAP Profile Feature Registration Template

6.1 SOAPプロファイル機能登録テンプレート

When a feature for the BEEP profile for SOAP is registered, the following information is supplied:

石鹸のビーププロファイルの機能が登録されると、次の情報が提供されます。

Feature Identification: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-".

機能識別：この機能を識別する文字列を指定します。機能がIANAに登録されていない限り、機能の識別は「x-」で開始する必要があります。

Feature Semantics: specify the semantics of the feature.

機能セマンティクス：機能のセマンティクスを指定します。

Contact Information: specify the electronic contact information for the author of the feature.

連絡先情報：機能の著者に電子連絡先情報を指定します。

7. Initial Registrations

7. 初期登録

7.1 Registration: The SOAP Profile

7.1 登録：石鹸プロファイル

Profile Identification: http://iana.org/beep/soap

プロフィール識別：http：//iana.org/beep/soap

Messages exchanged during Channel Creation: bootmsg, bootrpy

チャネル作成中に交換されるメッセージ：bootmsg、bootrpy

Messages starting one-to-one exchanges: bootmsg, SOAP-Env:Envelope

1対1の交換を開始するメッセージ：bootmsg、soap-env：envelope

Messages in positive replies: bootrpy, SOAP-Env:Envelope

肯定的な返信のメッセージ：bootrpy、soap-env：エンベロープ

Messages in negative replies: error

否定的な返信のメッセージ：エラー

Messages in one-to-many exchanges: SOAP-Env:Envelope

1対多くの交換のメッセージ：SOAP-ENV：エンベロープ

Message Syntax: SOAP-Env:Envelope as defined in Section 4 of [1] and [6]

メッセージ構文：SOAP-ENV：[1]および[6]のセクション4で定義されているエンベロープ

Message Semantics: c.f., [1]

メッセージセマンティクス：C.F。、[1]

   Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
      Marshall Rose <mrose@dbc.mtview.ca.us>

7.2 Registration: The soap.beep URL Scheme

7.2 登録：SOAP.BEEP URLスキーム

URL scheme name: soap.beep

URLスキーム名：Soap.beep

URL scheme syntax: c.f., Section 5.1

URLスキーム構文：C.F。、セクション5.1

Character encoding considerations: c.f., the "generic URI" syntax defined in Section 3 of [10]

考慮事項の文字エンコード：C.F。、[10]のセクション3で定義されている「ジェネリックURI」構文

Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP

意図された使用法：石鹸のビーププロファイルを使用して利用可能になった石鹸リソースを識別します

Applications using this scheme: c.f., "Intended usage", above

このスキームを使用したアプリケーション：C.F。、「意図された使用法」、上記

Interoperability considerations: n/a

相互運用性の考慮事項：n/a

Security Considerations: c.f., Section 8

セキュリティ上の考慮事項：C.F。、セクション8

Relevant Publications: c.f., [1], [6], and [2]

関連する出版物：C.F。、[1]、[6]、および[2]

   Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
      Marshall Rose <mrose@dbc.mtview.ca.us>

Author/Change controller: the IESG

著者/変更コントローラー：IESG

7.3 Registration: The soap.beeps URL Scheme

7.3 登録：SOAP.BEEPS URLスキーム

URL scheme name: soap.beeps

URLスキーム名：Soap.beeps

URL scheme syntax: c.f., Section 5.2

URLスキーム構文：C.F。、セクション5.2

Character encoding considerations: c.f., the "generic URI" syntax defined in Section 3 of [10]

考慮事項の文字エンコード：C.F。、[10]のセクション3で定義されている「ジェネリックURI」構文

Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP after the BEEP session has been tuned for privacy

意図された使用法：ビープセッションがプライバシーのために調整された後、石鹸のビーププロファイルを使用して利用可能にされた石鹸リソースを識別します

Applications using this scheme: c.f., "Intended usage", above

このスキームを使用したアプリケーション：C.F。、「意図された使用法」、上記

Interoperability considerations: n/a

相互運用性の考慮事項：n/a

Security Considerations: c.f., Section 8

セキュリティ上の考慮事項：C.F。、セクション8

Relevant Publications: c.f., [1], [6], and [2]

関連する出版物：C.F。、[1]、[6]、および[2]

   Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
      Marshall Rose <mrose@dbc.mtview.ca.us>

Author/Change controller: the IESG

著者/変更コントローラー：IESG

7.4 Registration: The System (Well-Known) TCP port number for SOAP over BEEP

7.4 登録：システム（よく知られている）TCPポート番号

Protocol Number: TCP

プロトコル番号：TCP

Message Formats, Types, Opcodes, and Sequences: c.f., Section 2.1

メッセージフォーマット、タイプ、オプコード、およびシーケンス：C.F。、セクション2.1

Functions: c.f., [1]

機能：C.F。、[1]

Use of Broadcast/Multicast: none

ブロードキャスト/マルチキャストの使用：なし

Proposed Name: SOAP over BEEP

提案された名前：ビープ音の石鹸

Short name: soap-beep

短い名前：Soap-Beep

   Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
      Marshall Rose <mrose@dbc.mtview.ca.us>

8. Security Considerations

8. セキュリティに関する考慮事項

Although service provisioning is a policy matter, at a minimum, all implementations must provide the following tuning profiles:

サービスプロビジョニングはポリシーの問題ですが、少なくともすべての実装は次のチューニングプロファイルを提供する必要があります。

for authentication: http://iana.org/beep/SASL/DIGEST-MD5

認証用：http：//iana.org/beep/sasl/digest-md5

for confidentiality: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)

機密性について：http：//iana.org/beep/tls（tls_rsa_with_3des_ede_cbc_sha cipherを使用）

for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)

両方の場合：http：//iana.org/beep/tls（tls_rsa_with_3des_ede_cbc_sha ciphaを使用するクライアント側の証明書をサポートする）

Further, implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP[13] or S/MIME[14].

さらに、実装は、OpenPGP [13]やS/MIME [14]などのメッセージの完全性と機密性を提供するMIMEベースのセキュリティサービスを提供することを選択できます。

Regardless, consult [2]'s Section 9 for a discussion of BEEP-specific security issues.

とにかく、ビープ特有のセキュリティ問題の議論については、[2]のセクション9に相談してください。

References

参考文献

[1] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", May 2000, <http://www.w3.org/TR/2000/ NOTE-SOAP-20000508>.

[1] Box、D.、Ehnebuske、D.、Kakivaya、G.、Layman、A.、Mendelsohn、N.、Nielsen、H.、Thatte、S.、D。Winer、 "Simple Object Access Protocol（SOAP）1.1"、2000年5月、<http://www.w3.org/tr/2000/ note-soap-20000508>。

[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.

[2] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。

[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[3] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。

[4] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[4] Murata、M.、St.Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。

[5] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.

[5] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。

[6] Barton, J., Thatte, S. and H. Nielsen, "SOAP Messages with Attachments", December 2000, <http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211>.

[6] Barton、J.、Thatte、S。and H. Nielsen、「添付ファイル付き石鹸メッセージ」、2000年12月、<http://www.w3.org/tr/2000/note-soap-attachments-20001211>。

[7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.

[7] Levinson、E。、「コンテンツIDおよびメッセージIDユニフォームリソースロケーター」、RFC 2392、1998年8月。

[8] Palme, F., Hopmann, A., Shelness, N. and E. Stefferud, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.

[8] Palme、F.、Hopmann、A.、Shelness、N。and E. Stefferud、「HTML（MHTML）などの集計文書のMIMEカプセル化」、RFC 2557、1999年3月。

[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[9] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。

[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[10] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。

[11] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[11] Gulbrandsen、A.、Vixie、P。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、RFC 2782、2000年2月。

[12] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.

[12] Haskin、D.およびE. Allen、「PPP上のIPバージョン6」、RFC 2472、1998年12月。

[13] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.

[13] Elkins、M.、Del Torto、D.、Levien、R。and T. Roessler、「Mime Security with OpenPGP」、RFC 3156、2001年8月。

[14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

[14] Ramsdell、B。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。

IANA Considerations

IANAの考慮事項

The IANA has registered the profile specified in Section 7.1 as:

IANAは、セクション7.1で指定されたプロファイルを次のように登録しています。

http://iana.org/beep/soap

The IANA has registered "soap.beep" and "soap.beeps" as URL schemes, as specified in Section 7.2 and Section 7.3, respectively.

IANAは、セクション7.2とセクション7.3でそれぞれ指定されているように、「Soap.beep」および「soap.beeps」をURLスキームとして登録しています。

The IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 7.4.

IANAは、セクション7.4で指定されているように、「石鹸上のビープ音」をTCPポート番号として登録しています。

Finally, the IANA maintains a list of SOAP profile features, c.f., Section 6.1. The IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. Prior to contacting the IESG, developers of SOAP profile features must use the mailing list beepwg@lists.beepcore.org to solicit commentary.

最後に、IANAは石鹸プロファイル機能のリスト、C.F。、セクション6.1を維持しています。IESGは、IANAが割り当てを行う前に、指定された専門家を割り当てて仕様を確認する責任があります。IESGに連絡する前に、SOAPプロファイル機能の開発者は、メーリングリストBeepwg@lists.beepcore.orgを使用して解説を求める必要があります。

Acknowledgements

謝辞

The authors gratefully acknowledge the contributions of: Christopher Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T. Fielding.

著者は、クリストファー・フェリス、ヒューストン・フランクリン、アレクセイ・メルニコフ、ビル・ミルズ、ロイ・T・フィールディングの貢献に感謝します。

Authors' Addresses

著者のアドレス

Eamon O'Tuathail Clipcode.com 24 Thomastown Road Dun Laoghaire Dublin IE

   Phone: +353 1 2350 424
   EMail: eamon.otuathail@clipcode.com
   URI:   http://www.clipcode.com/

Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US

マーシャルT.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US

   Phone: +1 916 483 8878
   EMail: mrose@dbc.mtview.ca.us

Full Copyright Statement

完全な著作権声明

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

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

RFCエディター機能の資金は現在、インターネット協会によって提供されています。