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)
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 Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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）ブロック拡張可能交換プロトコルコア（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
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] BEEPプロファイル[2]を使用して送信される方法を指定します。 W3Cでは、XMLPの努力はSOAPを進化しています。したがって、このメモは、新しい機能の使用を交渉するためのメカニズムを提供します。
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で定義された要素：この文書全体を通して、用語「エンベロープ」は、「エンベロープSOAP-ENV」を指します。さらに、用語「ピア」、「クライアント」、「サーバ」、「1対1」、および「1は対多」のBEEPの文脈で使用されています。特に、セクション2.1及び2.1.1 [2] BEEPロールと交換スタイルを議論します。
The BEEP profile for SOAP is identified as
SOAPのためのBEEPプロフィールは次のように識別されます
http://iana.org/beep/soap
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／そあｐ
in the BEEP "profile" element during channel creation.
チャネルの作成中にBEEP「プロファイル」要素インチ
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.,
最初のチャンネルが正常に作成されBEEPでは、「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]).
「サーバ名」属性は、HTTPS「ホスト」リクエストヘッダフィールド（C.F.、[3]のセクション14.23）に類似しています。
There are two states in the BEEP profile for SOAP, "boot" and "ready":
SOAP、「ブート」と「準備」のためのBEEPプロファイルで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」メッセージのいずれかで）「bootmsg」を送信します。
* If the other peer sends a "bootrpy" (either during channel initialization or in a "RPY" message), then the "ready" state is entered
他のピアは、（チャネルの初期化中、または「RPY」メッセージのいずれかで）「bootrpy」を送信した場合*は、「準備完了」状態に入ります
* 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「準備完了」状態では、いずれかのピアは、エンベロープを含む「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.
*ゼロ個以上を送り返す「AND」メッセージ、エンベロープを含む各、「NULL」のメッセージが続きます。
Regardless, no state change occurs.
かかわらず、状態変化が発生しません。
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のためのBEEPプロファイルに結合し、各チャネルは、単一のリソース（ネットワーク・データ・オブジェクトまたはサービス）へのアクセスを提供します。
feature negotiation: if new features of SOAP (such as compression) emerge, their use can be negotiated.
機能のネゴシエーション：（圧縮など）SOAPの新機能が出てくる場合は、その使用を交渉することができます。
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 "">
<！ELEMENTのbootrpy EMPTY> <！ATTLISTのbootrpyは "" 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,
https "の腹筋_経路" のRequest-URIパラメータ（C.F.、[3]のセクション5.1.2）に類似して、 "リソース" 属性、O。そして、
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.
存在する場合、各チャネル上の可能な使用のために要求されているSOAPのためのBEEPプロフィールの任意の特徴を示す、一つ以上の特徴トークンが含ま、O「機能」属性。
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>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/soap'> S：<！[CDATA [<bootrpy />]]> S：</プロフィール>
The channel bound to the BEEP profile for SOAP is now in the "ready" state.
SOAPのためのBEEPプロファイルにバインドされたチャネルは「準備完了」状態になりました。
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>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/soap'> S：<！[CDATA [<エラーコード= '550'>リソースではないS：サポート</エラー>]]> S：< /プロフィール>
Although the channel was created successfully, it remains in the "boot" state.
チャンネルが正常に作成されたが、それは「ブート」状態のまま。
The BEEP profile for SOAP transmits envelopes encoded as UTF-8 using the media type "application/xml"[4], e.g.,
SOAPのためのBEEPプロフィールは、例えば、[4]メディアタイプ「アプリケーション/ XML」を使用してUTF-8としてエンコードされた封筒を送信します
MSG 1 1 . 0 364 Content-Type: application/xml
MSG 1 1。 0 364のContent-Type：アプリケーション/ 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
<SOAP-ENV：封筒の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 = "いくつか-URI"> <記号> DIS </記号> </ M：GetLastTradePrice> </ SOAP-ENV：body> </ SOAP-ENV：封筒> 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のためのBEEPプロフィールはまた、封筒及び[6]（すなわち、いずれかを使用しての第3のルールを使用して参照される下位部分と、「マルチパート/関連」[5]コンテンツのルート一部として送信されることを可能にします"コンテンツID：" [7]または "コンテンツの場所：" [8]ヘッダ）、例えば、
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>
--MIME_boundaryのContent-Type：アプリケーション/ XMLコンテンツ-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>
<？xmlのバージョン= '1.0'？> <SOAP-ENV：封筒のxmlns：SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV：ボディ> .. <theSignedForm href = "CID：claim061400a.tiff@claiming-it.com" /> .. </ SOAP-ENV：BODY> </ SOAP-ENV：封筒>
--MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID: <claim061400a.tiff@claiming-it.com>
--MIME_boundaryコンテンツタイプ：image / TIFFコンテンツ転送エンコード：バイナリコンテンツID：<claim061400a.tiff@claiming-it.com>
...binary TIFF image... --MIME_boundary-- END
...バイナリTIFF画像... --MIME_boundary-- END
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.
セクション2と一致し[6]、強くマルチパートが「開始」パラメータが含まれていること、および根元部が「コンテンツID：」を含むことが推奨されるヘッダ。 BEEPは、8ビット幅のパス、「変革」コンテンツ転送符号化（例えば、「BASE64」または「引用符で囲まれた印刷可能」）を提供するため、ただし、使用されるべきではありません。 MIME [9]の「Content-ID」ヘッダの値はグローバルに一意であることが必要であることをさらに留意されたいです。
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のためのBEEPプロフィールは、クライアントが封筒を含む「MSG」メッセージを送信し、サーバはすぐに封筒の中身を処理する前に、「NUL」メッセージを返信する1対多の交換を使用して、これを達成します。
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のためのBEEPプロフィールは、クライアントが封筒を含む「MSG」メッセージを送信し、サーバが封筒を含む「RPY」メッセージを返信した1対1の交換を使用して、これを達成します。
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.
常に「RPY」メッセージで返され、サーバによって生成されたものは何でも対応 - 一対一のやり取りを行うときに最後に、SOAPのためのBEEPプロフィールは、SOAPフォルトのための「ERR」メッセージを使用していません。
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のためのBEEPプロフィールは、クライアントが封筒を含む「MSG」メッセージを送信し、サーバは、続いてバックゼロまたはそれ以上の「ANS」メッセージ、エンベロープを含む各を送信する一対多の交換を使用して、これを達成します「NUL」のメッセージ。
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上でBEEPの上にSOAPを使用することを識別する2つのURLスキーム、「soap.beep」と「soap.beeps」を、定義されています。現時点では、SOAPのための「一般的な」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のセクション3.2.2で定義されたサーバーベースの命名権限が[10]権限コンポーネントのために使用されます。
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節で示した例になる可能性があります。
The "soap.beep" URL scheme indicates the use of the BEEP profile for SOAP running over TCP/IP.
「soap.beep」URLスキームは、TCP / IP経由のSOAP走行用BEEPプロファイルを使用することを示します。
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資源レコードを照会して、ポート番号をそのまま使用します。
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-ビープ」のサービスパラメータおよびIP / TCPアドレス情報を決定するために、「TCP」のプロトコルパラメータと共に使用されます。何の適切なSRV RRを（例えば、「_soap-beep._tcp.stockquoteserver.example.com」のために）見つからない場合は、DNSは、ドメイン名に対応するAのRRのために照会され、使用されるポート番号は、IANAによって割り当てられています7.4節で登録。
If the authority component contains an IP address, e.g.,
権限コンポーネントは、例えば、IPアドレスが含まれている場合
soap.beep://10.0.0.2:1026
soap.beep：1026：//10.0.0.2
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アドレスの使用が推奨されますが、リテラルIPv6アドレスが「soap.beep」URLで使用されている場合、それは[12]で指定された構文に準拠する必要があります。
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).
URLスキームは前SOAPのためのBEEPプロフィールを開始する、BEEPセッションは、プライバシーのために調整しなければならないことを除いて、セクション5.1で指定された「soap.beep」URLスキームに、すべての方法では、同じである「soap.beeps」 。特に、セクション5.1.1で指定されるように、両方のURLスキームは、アドレス解決のための同一のアルゴリズムおよびパラメータを使用することに注意してください（例えば、SRVルックアップのために同じサービス名、TCPに対して同じポート番号など）。
There are two ways to perform privacy tuning on a BEEP session, either:
どちらか、BEEPセッションにプライバシーのチューニングを実行する方法は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.
かかわらず、交渉プロセスが完了すると、チューニングのリセットは、両方のBEEPピアが新しい挨拶を発行起こります。 BEEPピアは、プライバシーが使用されているかどうかに基づいて異なる挨拶を発行することもできます方法の例については、[2]のセクション3を参照してください。
When a feature for the BEEP profile for SOAP is registered, the following information is supplied:
SOAPのためのBEEPプロファイルの機能が登録されている場合は、次の情報が提供されます。
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.
お問い合わせ先：機能の作者のための電子連絡先情報を指定します。
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
bootmsg、SOAP-ENV：封筒1対1の交換を開始するメッセージ
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
SOAP-ENV：1対多の交流のメッセージ封筒
Message Syntax: SOAP-Env:Envelope as defined in Section 4 of [1] and [6]
メッセージ構文：SOAP-ENV：エンベロープはセクション4で定義されるように[1]と[6]
Message Semantics: c.f., [1]
メッセージの意味：C.F.、[1]
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>, Marshall Rose <mrose@dbc.mtview.ca.us>
お問い合わせ先：イーモンO'Tuathail <eamon.otuathail@clipcode.com>、マーシャルローズ<mrose@dbc.mtview.ca.us>
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.、の3節で定義された「一般的なURI」構文[10]
Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP
意図している用法：SOAPのためのBEEPプロファイルを使用して利用できるように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>
お問い合わせ先：イーモンO'Tuathail <eamon.otuathail@clipcode.com>、マーシャルローズ<mrose@dbc.mtview.ca.us>
Author/Change controller: the IESG
著者/変更コントローラ：IESG
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.、の3節で定義された「一般的なURI」構文[10]
Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP after the BEEP session has been tuned for privacy
意図した使用方法は：BEEPセッションはプライバシーのために調整された後、SOAPのためのBEEPプロファイルを使用して利用できるように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>
お問い合わせ先：イーモンO'Tuathail <eamon.otuathail@clipcode.com>、マーシャルローズ<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登録：システム（ウェルノウン）BEEP上のSOAPのための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
提案名：BEEPの上にSOAP
Short name: soap-beep
ショート名：石鹸、ビープ音
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>, Marshall Rose <mrose@dbc.mtview.ca.us>
お問い合わせ先：イーモンO'Tuathail <eamon.otuathail@clipcode.com>、マーシャルローズ<mrose@dbc.mtview.ca.us>
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暗号を使用して）
for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
（クライアント側の証明書をサポートするTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して）http://iana.org/beep/TLS：両方のために
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.
かかわらず、BEEP固有のセキュリティ問題の議論のための[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]ボックス、D.、Ehnebuske、D.、Kakivaya、G.、素人、A.、メンデルゾーン、N.、ニールセン、H.、Thatte、S.及びD.ワイナー、「シンプルオブジェクトアクセスプロトコル（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]ローズ、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]フィールディング、R.、ゲティス、J.、モーグル、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[4] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4]村田、M.、St.Laurent、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[5] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[5]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、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]バートン、J.、Thatte、S.およびH.ニールセン、 "添付ファイル付きSOAPメッセージ"、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]レビンソン、E.、 "コンテンツIDとMessage-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]パルメ、F.、Hopmann、A.、Shelness、N.とE. Stefferud、RFC 2557、1999年3月 "は、HTML（MHTML）として集約文書のMIMEカプセル化"。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[9]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、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.及びL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[12] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[12] Haskin、D.およびE.アレン、 "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]エルキンズ、M.、デルTorto、D.、Levien、R.及びT.レスラー、 "OpenPGPのとMIMEセキュリティ"、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.
それぞれ、7.2節および第7.3節に指定されているIANAは、URLスキームとして「soap.beep」と「soap.beeps」を登録しました。
The IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 7.4.
IANAはまた、セクション7.4で指定されているように、TCPポート番号として「BEEPの上にSOAP」を登録しました。
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は、SOAPプロファイル機能、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
イーモンO'Tuathail Clipcode.com 24トーマスロードダンレアリーダブリンIE
Phone: +353 1 2350 424 EMail: eamon.otuathail@clipcode.com URI: http://www.clipcode.com/
電話：+353 1 2350 424 Eメール：eamon.otuathail@clipcode.com URI：http://www.clipcode.com/
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268米
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
電話：+1 916 483 8878 Eメール：mrose@dbc.mtview.ca.us
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。