Network Working Group E. O'Tuathail
Request for Comments: 4227 Clipcode.com
Obsoletes: 3288 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
January 2006
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.
このメモは、ブロック拡張可能交換プロトコル（BEEP）コアへの結合のSOAP（Simple Object Access Protocol）を指定します。 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, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.
SOAPは、分散型メッセージングモデルの多種多様を実装するために使用されるXMLベースの（拡張マークアップ言語）メッセージングプロトコルです。これは、メッセージのフォーマットを定義を含むメッセージパターン、様々な説明するが、SOAP仲介者を介してリモートプロシージャ呼び出し（RPC）、非同期イベント通知、未確認メッセージ、および転送、これらに限定されません。
Table of Contents
目次
1. Introduction ....................................................3
2. BEEP Profile Identification .....................................3
2.1. Profile Initialization .....................................4
3. SOAP Message Packages ...........................................6
4. SOAP Message Patterns ...........................................8
4.1. One-Way Message ............................................8
4.2. Request-Response Exchange ..................................8
4.3. Request/N-Responses Exchange ...............................8
4.4. Error Handling .............................................9
5. SOAP Protocol Binding Framework Conformance .....................9
5.1. Binding Name ...............................................9
5.2. Base URI ...................................................9
5.3. Supported SOAP Message Exchange Patterns ...................9
5.4. Supported Features .........................................9
5.5. MEP Operation .............................................10
5.5.1. Behavior of Requesting SOAP Node ...................10
5.5.1.1. Init ......................................10
5.5.1.2. Requesting ................................10
5.5.1.3. Sending+Receiving .........................10
5.5.1.4. Success and Fail ..........................11
5.5.2. Behavior of Responding SOAP Node ...................11
5.5.2.1. Init ......................................11
5.5.2.2. Receiving .................................11
5.5.2.3. Receiving+Sending .........................11
5.5.2.4. Success and Fail ..........................11
6. URL Schemes ....................................................11
6.1. The soap.beep URL Scheme ..................................11
6.1.1. Resolving IP/TCP Address Information ...............12
6.2. The soap.beeps URL Scheme .................................13
7. Registration Templates .........................................13
7.1. SOAP Profile Feature Registration Template ................13
8. Initial Registrations ..........................................13
8.1. Registration: The SOAP Profile ............................13
8.2. Registration: The soap.beep URL Scheme ....................14
8.3. Registration: The soap.beeps URL Scheme ...................14
8.4. Registration: The System (Well-Known) TCP Port
Number for SOAP ...........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Changes from RFC 3288 .........................................16
12. Acknowledgements ..............................................17
13. References ....................................................17
13.1. Normative References .....................................17
13.2. Informative References ...................................18
A. Appendix - SOAP with Attachments (Informative) .................19
This memo specifies how SOAP envelopes [15] are transmitted using a BEEP profile [1]. Conforming implementations MUST support SOAP version 1.2 [15] and MAY support other versions, such as SOAP version 1.1 [17]. This memo specifies how SOAP envelopes [15] are transmitted using a BEEP profile [1]. Unlike its predecessor, RFC3288 [16], this memo does not mandate the use of SOAP version 1.1.
このメモは、SOAPエンベロープ[15] BEEPプロファイルを使用して送信される方法を指定する[1]。適合実装は、SOAPバージョン1.2 [15]をサポートしなければならないと、このようなSOAPバージョン1.1 [17]などの他のバージョンをサポートすることができます。このメモは、SOAPエンベロープ[15] BEEPプロファイルを使用して送信される方法を指定する[1]。その前身、RFC3288 [16]とは異なり、このメモはSOAPバージョン1.1の使用を強制しません。
Throughout this memo, the term "envelope" refers to the top-level element exchanged by SOAP senders and receivers. For example, when referring to SOAP version 1.2, the term "envelope" refers to the "Envelope" element defined in Section 5.1 of [2]. Furthermore, 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 [1] discuss BEEP roles and exchange styles.
このメモ全体を通して、用語「エンベロープ」は、SOAP送信者と受信機によって交換最上位の要素を指します。 SOAPバージョン1.2を参照する場合、例えば、用語「エンベロープ」は、[2]のセクション5.1で定義される「エンベロープ」要素を指します。さらに、用語「ピア」、「クライアント」、「サーバ」、「1対1」、および「1対多は」BEEPの文脈で使用されています。特に、セクション2.1及び2.1.1 [1] BEEPロールと交換スタイルを議論します。
The BEEP profile for SOAP is identified as
SOAPのためのBEEPプロフィールは次のように識別されます
http://iana.org/beep/soap/VERSION
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／そあｐ／ゔぇＲしおん
in the BEEP "profile" element during channel creation. where "VERSION" refers to the numeric version of the SOAP specification.
チャネルの作成中にBEEP「プロファイル」要素インチここで、「VERSION」はSOAP仕様の数値バージョンを指します。
For example,
例えば、
http://iana.org/beep/soap/1.2
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／そあｐ／１。２
refers to version 1.2.
バージョン1.2を指します。
Note that RFC 3288 [16] used
そのRFC 3288に注意してください[16]を用い
http://iana.org/beep/soap
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／そあｐ
for the purposes of profile identification for SOAP version 1.1 envelopes [17]. If an implementation of this memo chooses to implement SOAP version 1.1, then it should support both this Uniform Resource Identifier (URI) for profile identification as well as "http://iana.org/beep/soap/1.1".
SOAPバージョン1.1封筒[17]のプロファイル識別の目的のために。このメモの実装は、SOAPバージョン1.1を実装することを選択した場合、それは、プロファイル識別ならびに「http://iana.org/beep/soap/1.1」は、このユニフォームリソース識別子（URI）の両方をサポートしなければなりません。
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/1.2' />
</start>
The "serverName" attribute is analogous to HTTP's "Host" request-header field (cf. Section 14.23 of [4]).
「serverNameの」属性は、HTTPの「ホスト」リクエストヘッダフィールドに類似している（参照：セクションの14.23 [4]）。
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 an "RPY" message), then the "ready" state is entered
他のピアは、（チャネルの初期化中、または「RPY」メッセージのいずれかで）「bootrpy」を送信した場合*は、「準備完了」状態に入ります
* Otherwise, the other peer sends an "error" (either during channel initialization or in an "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 an "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 analogous to HTTP's "abs_path" Request-URI parameter (cf. Section 5.1.2 of [4]) and
HTTPの「腹筋_経路」のRequest-URIパラメータ（[4]の参照セクション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 7.1 defines a registration template for optional features.
7.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 is not recognized, the peer acting in the server role replies with an error message (cf. Section 7.1 of [1]). Typically, the boot message and its response are exchanged during channel initialization (cf. Section 2.3.1.2 of [1]).
要求されたリソースが認識されない場合、起動メッセージが不適切に形成されるか、またはそうでない場合、サーバーの役割で作用するピアはエラーメッセージ（[1]の参照セクション7.1）で応答します。典型的には、ブート・メッセージ及びその応答は、チャネル初期化（[1]の参照セクション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/1.2'>
C: <![CDATA[<bootmsg resource='/StockQuote' />]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/soap/1.2'> S: <![CDATA[<bootrpy />]]> S: </profile>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/soap/1.2'> 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/1.2'>
C: <![CDATA[<bootmsg resource='/StockPick' />]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/soap/1.2'> S: <![CDATA[<error code='550'>resource not S: supported</error>]]> S: </profile>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/soap/1.2'> 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 and SHOULD use the media type "application/soap+xml" [5], e.g.,
SOAPのためのBEEPプロフィールは、例えば、UTF-8としてエンコードされたエンベロープを送信し、メディアタイプ「アプリケーション/石鹸+ XML」を使用すべきである[5]
MSG 1 1 . 0 284 Content-Type: application/soap+xml
MSG 1 1。 0 284のContent-Type：アプリケーション/石鹸+ xmlの
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:GetLastTradePrice xmlns:m="Some-URI" /> </env:Header> <env:Body> <symbol xmlns:p="Some-URI" >DIS</symbol> </env:Body> </env:Envelope> END
<ENV：エンベロープのxmlns：ENV = "http://www.w3.org/2003/05/soap-envelope"> <ENV：ヘッダ> <M：GetLastTradePrice用のxmlns：M = "いくつか-URI" /> </ ENV：ヘッダー> <ENV：ボディ> <シンボルのxmlns：P = "いくつかの-URI"> DIS </記号> </ ENV：BODY> </ ENV：封筒> END
To provide compatibility with RFC 3288 [16], it MAY use the media type "application/xml" [6].
RFC 3288 [16]との互換性を提供するために、それはメディアタイプ "アプリケーション/ XML" を使用するかもしれ[6]。
In addition, an implementation of the BEEP profile for SOAP MAY support transmission of envelopes using the MTOM [7] / XOP [8] packaging technique, e.g.,
また、SOAPのためのBEEPプロファイルの実装は、例えば、MTOM [7] / XOP [8]パッケージング技術を用いて、エンベロープの送信をサポートするかもしれません
MSG 1 2 . 283 1436
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<mymessage.xml@example.org>";
startinfo="application/soap+xml; action=
Content-Description: A SOAP message with my pic and sig in it
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="application/soap+xml; action=
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'> <soap:Body> <m:data xmlns:m='http://example.org/stuff'> <m:photo xmlmime:contentType='image/png'><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.png'/></m:photo> <m:sig xmlmime:contentType='application/pkcs7-signature'><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/my.hsh'/></m:sig> </m:data> </soap:Body> </soap:Envelope>
<石鹸：封筒のxmlns：石鹸= 'のhttp：//www.w3.org/2003/05/soap-envelope' のxmlns：xmlmime = 'のhttp：//www.w3.org/2004/11/xmlmime'> <ソープ：ボディ> <M：データのxmlns：M = 'のhttp：//example.org/stuff'> <M：写真xmlmime：contentTypeの= '画像/ PNG'> <XOP：XOP = 'のhttp：/のxmlnsを含めます/www.w3.org/2004/08/xop/include」のhref = 'CIDます：http：//example.org/me.png'/> </ M：写真> <M：SIG xmlmime：contentTypeの=' アプリケーション/ PKCS7署名 '> <XOP：インクルードのxmlns：XOP =' はhttp：//www.w3.org/2004/08/xop/include」のhref = 'CIDます。http：//example.org/my.hsh' /> </ M：SIG> </ M：データ> </ SOAP：BODY> </ SOAP：エンベロープ>
--MIME_boundary Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: <http://example.org/me.png>
--MIME_boundaryコンテンツタイプ：image / pngのコンテンツ転送エンコード：バイナリコンテンツID：<http://example.org/me.png>
// binary octets for png
PNGのための//バイナリオクテット
--MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID: <http://example.org/my.hsh>
--MIME_boundaryコンテンツタイプ：アプリケーション/ PKCS7署名のコンテンツ転送エンコード：バイナリコンテンツID：<http://example.org/my.hsh>
// binary octets for signature
署名のため//バイナリオクテット
--MIME_boundary-- END
--MIME_boundary-- END
Consult Section 4.1 of XOP [8] for guidance on MIME Multipart/Related usage. Because BEEP provides an 8-bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Note that MIME [9] requires that the value of the "Content-ID" header be globally unique. As stated in Section 4 of XOP [8], XOP may be used with diverse packaging mechanisms. When an implementation of BEEP in SOAP does support MTOM/XOP, it SHOULD support the MIME Multipart/Related XOP Package format, and MAY support others. Additional formats could, in the future, include XOP package formats specific to BEEP (e.g., sending the attachments on a different channel to the SOAP channel, which would avoid searching for the MIME boundary tags and allows lazy delivery of attachments, delivering them only when really needed.)
MIMEマルチパート/関連使い方に関するガイダンスのためにXOP [8]のセクション4.1を参照してください。 BEEPは、8ビット幅の経路を提供するので、「変革」コンテンツ転送符号化（例えば、「BASE64」または「引用符で囲まれた印刷可能」）に使用されるべきではありません。 MIME [9]の「Content-ID」ヘッダの値はグローバルに一意であることを必要とすることに留意されたいです。 XOP [8]のセクション4で述べたように、XOPは、多様なパッケージング機構を使用することができます。 SOAPでBEEPの実装は、MTOM / XOPをサポートしていない場合は、MIMEマルチパート/関連XOPパッケージフォーマットをサポートする必要があり、他の人をサポートするかもしれません。追加のフォーマットは、将来的には、場合にのみ、それらを提供し、MIMEの境界タグの検索避け、添付ファイルの怠惰な送達を可能にするでしょうSOAPチャネルに異なるチャネル上の添付ファイルを送信して、（例えばビープ音が鳴り、特定のXOPパッケージ形式を含めることができます本当に必要としていました。）
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の交換を使用して、これを達成します。
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」のメッセージ。
The BEEP profile for SOAP does not use the "ERR" message for SOAP faults. When performing one-to-one exchanges, whatever SOAP response (including SOAP faults) generated by the server is always returned in the "RPY" message. When performing one-to-many exchanges, whatever SOAP response (including SOAP faults) generated by the server is always returned in the "ANS" messages.
SOAPのためのBEEPプロフィールは、SOAPフォルトのための「ERR」メッセージを使用していません。サーバによって生成されたSOAPレスポンス（SOAP障害を含む）どんな一対一の交換を行う場合は、必ず「RPY」メッセージで返されます。 1対多の交換を実行すると、サーバーによって生成された（SOAPフォルトを含む）どんなSOAP応答は常に「ANS」メッセージで返されます。
If there is an error with the BEEP message unrelated to the SOAP envelope (e.g., poorly formed MIME message or MIME Content-Type not supported), then the server responds with an ERR message (see Section 7.1 of [1]) with an appropriate reply code (e.g., see Section 8 of [1]).
SOAPエンベロープ（例えば、不完全に形成されたMIMEメッセージまたはMIMEのContent-Typeのサポートされていない）とは無関係のBEEPメッセージでエラーが発生した場合、サーバはERRメッセージで応答し、適切なと（[1]の7.1節を参照してください）コードを返信（例えば、[1]のセクション8を参照）。
This binding is identified by a URI that is exactly the same as the profile URI for BEEP in SOAP (see Section 2).
この正確SOAPでBEEPのプロファイルのURIと同じであるURIによって識別される結合（セクション2を参照）。
The Base URI for the SOAP envelope is the URI of the resource identified in the bootmsg.
SOAPエンベロープのベースURIはbootmsgで特定されたリソースのURIです。
An implementation of this binding MUST support the following SOAP Message Exchange Pattern (MEP):
このバインディングの実装には、次のSOAPメッセージ交換パターン（MEP）をサポートしなければなりません：
o "http://www.w3.org/2003/05/soap/mep/request-response/" (see Section 6.2 of [3])
O "http://www.w3.org/2003/05/soap/mep/request-response/"（[3]のセクション6.2を参照されたいです）
An implementation of this binding MAY support the following feature: "http://www.w3.org/2003/05/soap/features/action/" (see Section 6.5 of [3].)
このバインディングの実装には、次の機能をサポートしていることがあります。「http://www.w3.org/2003/05/soap/features/action/」（[3]のセクション6.5を参照してください。）
For binding instances conforming to this specification:
この仕様に準拠するバインディングインスタンスの場合：
o A SOAP node instantiated at the BEEP peer that initiates the message exchange may assume the role (i.e., the property http:// www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role ) of "RequestingSOAPNode".
O役割を引き受けることができるメッセージ交換を開始するBEEPピアでインスタンスSOAPノード（すなわち、プロパティのhttp：// www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role）「RequestingSOAPNode」の。
o A SOAP node instantiated at the other BEEP peer may assume the role (i.e., the property http://www.w3.org/2003/05/soap/ bindingFramework/ExchangeContext/Role) of "RespondingSOAPNode".
O他のBEEPピアでインスタンスSOAPノードは、「RespondingSOAPNode」の役割（すなわち、プロパティhttp://www.w3.org/2003/05/soap/ bindingFramework / ExchangeContext /ロール）をとることができます。
The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with Section 6.2 of [3].
要求SOAPノードの動作の全体の流れは、[3]のセクション6.2と一致する状態機械の説明に従います。
In order to avoid deadlock during streaming (see Section 6.2.3 of [3]), the requesting SOAP node MUST be able to process incoming SOAP response information while the SOAP request is still being transmitted.
（[3]のセクション6.2.3を参照）のストリーミング中にデッドロックを回避するために、要求元のSOAPノードはSOAPリクエストがまだ送信されている間に着信SOAP応答情報を処理できなければなりません。
In the "Init" state, a BEEP message is formulated according to Section 3, transmission of the message begins, and then the state changes to "Requesting".
「初期化」状態で、BEEPメッセージはセクション3に従って製剤化され、メッセージの送信が開始され、その後、状態変化は、「要求」します。
In the "Requesting" state, more of the request message is transmitted and the arrival of the response is awaited. When the beginning of the response message is received, if it is a BEEP ERR message, then the state transitions to "Fail"; otherwise, the state transitions to "Sending+Receiving".
「要求」状態では、要求メッセージの複数が送信され、応答の到着を待ちます。それはBEEPのERRメッセージ、その後、状態遷移を「失敗」である場合、応答メッセージの先頭には、受信した場合、それ以外の場合は、状態遷移は、「受信+送信」します。
In the "Sending+Receiving" state, the transmission of the request message and receiving of the response message are completed. The response message is assumed to contain a SOAP envelope serialized according to the rules for carrying SOAP messages in the media type given in the Content-Type header field. Once the receipt of the response is completed, the state transitions to "Success".
「送信、受信+」状態では、要求メッセージと応答メッセージの受信の送信が完了しています。応答メッセージは、Content-Typeヘッダフィールドで指定されたメディアタイプにSOAPメッセージを搬送するための規則に従ってシリアル化SOAPエンベロープを含むものとします。応答の受信が完了すると、状態が「成功」に遷移します。
"Success" and "Fail" are the terminal states for the state machine.
「成功」と「失敗」の状態マシン用の端子状態です。
The overall flow of the behavior of a responding SOAP node follows a state machine description consistent with Section 6.2 of [3]
応答SOAPノードの動作の全体の流れは、[3]のセクション6.2と一致する状態機械の説明を以下
In the "Init" state, the binding awaits the start of the inbound request. In this state, it may only generate ERR messages (in accordance with Section 4.4).
「初期化」状態では、バインディングは、インバウンド要求の開始を待ちます。この状態では、それだけ（セクション4.4に従って）ERRメッセージを生成してもよいです。
The binding begins to receive the request message and prepares the start of the response, in accordance with Section 3. When ready to transmit the response, the state transitions to "Receiving+Sending".
バインディングは、要求メッセージの受信を開始し、応答を送信する準備ができて、状態遷移は「送信+受信」する場合は第3節に従い、応答の開始を準備します。
The binding completes the receiving of the request and sending of the response and then transitions to "Success" state.
バインディングは、要求と応答の送信の受信を完了した後、「成功」状態に遷移します。
"Success" and "Fail" are the terminal states that indicate completion of the message exchange.
「成功」と「失敗」のメッセージ交換の完了を示す端末状態です。
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 Resource Records 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 Service Record 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 8.4.
サービスレコードアルゴリズム[11]「SOAP-ビープ」のサービスパラメータおよびIP / TCPアドレス情報を決定するために、「TCP」のプロトコルパラメータと共に使用されます。何の適切なSRV RRを（例えば、「_soap-beep._tcp.stockquoteserver.example.com」のために）見つからない場合は、DNSは、ドメイン名に対応するAのRRのために照会され、使用されるポート番号は、IANAによって割り当てられています8.4節で登録。
If the authority component contains an IP address, e.g.,
権限コンポーネントは、例えば、IPアドレスが含まれている場合
soap.beep://192.0.2.0:1026
soap.beep：//192.0.2.0：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 8.4.
その後、DNSが照会されていない、とIPアドレスが直接使用されます。ポート番号が存在する場合、それが直接使用されます。そうでなければ、使用されるポート番号は、セクション8.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 6.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 6.1.1 (e.g., the same service name for SRV lookups, the same port number for TCP, and so on).
URLスキームは前SOAPのためのBEEPプロフィールを開始する、BEEPセッションは、プライバシーのために調整しなければならないことを除いて、セクション6.1で指定された「soap.beep」URLスキームに、すべての方法では、同じである「soap.beeps」 。特に、セクション6.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 [1] for an example of how a BEEP peer may choose to issue different greetings based on whether privacy is in use.
かかわらず、交渉プロセスが完了すると、チューニングのリセットは、両方のBEEPピアが新しい挨拶を発行起こります。 BEEPピアは、プライバシーが使用されているかどうかに基づいて異なる挨拶を発行することもできます方法の例については、[1]のセクション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/VERSION
プロフィール同定：http://iana.org/beep/soap/VERSION
Messages exchanged during Channel Creation: bootmsg, bootrpy
メッセージはチャンネルの作成中に交換：bootmsg、bootrpyを
Messages starting one-to-one exchanges: bootmsg, a SOAP "envelope"
bootmsg、SOAP「エンベロープ」：1対1の交換を開始するメッセージ
Messages in positive replies: bootrpy, a SOAP "envelope"
正の返信のメッセージ：bootrpy、SOAP「エンベロープ」
Messages in negative replies: error
負の返信のメッセージ：エラー
Messages in one-to-many exchanges: a SOAP "envelope"
1対多の交換におけるメッセージ：SOAP「エンベロープ」
Message Syntax: a SOAP envelope
メッセージの構文：SOAPエンベロープ
Message Semantics: corresponds to the relevant SOAP specification, e.g., for SOAP version 1.2, cf. [2].
メッセージのセマンティクス：SOAPバージョン1.2、参照のために、例えば、関連するSOAP仕様に対応します[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>
URL scheme name: soap.beep
URLスキーム名：soap.beep
URL scheme syntax: cf. Section 6.1
URLスキームの構文：参照6.1節
Character encoding considerations: cf. the "generic URI" syntax defined in Section 3 of [10]
文字エンコーディングの考慮事項：参照[10]のセクション3で定義された「一般的なURI」構文
Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP
意図している用法：SOAPのためのBEEPプロファイルを使用して利用できるようにSOAPのリソースを識別する
Applications using this scheme: cf. "Intended usage", above
この方式を使用したアプリケーション：参照上記の「使用目的」、
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Security Considerations: cf. Section 9
セキュリティの考慮事項：参照第9節
Relevant Publications: cf. [2] for SOAP version 1.2
関連出版物：参照[2] SOAPバージョン1.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: cf. Section 6.2
URLスキームの構文：参照6.2節
Character encoding considerations: cf. the "generic URI" syntax defined in Section 3 of [10]
文字エンコーディングの考慮事項：参照[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
意図した使用方法は：BEEPセッションはプライバシーのために調整された後、SOAPのためのBEEPプロファイルを使用して利用できるようにSOAPのリソースを識別する
Applications using this scheme: cf. "Intended usage", above
この方式を使用したアプリケーション：参照上記の「使用目的」、
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Security Considerations: cf. Section 9
セキュリティの考慮事項：参照第9節
Relevant Publications: cf. [2] for SOAP version 1.2
関連出版物：参照[2] SOAPバージョン1.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
8.4. Registration: The System (Well-Known) TCP Port Number for SOAP over BEEP
8.4. 登録：BEEP上のSOAPのためのシステム（ウェルノウン）TCPポート番号
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: cf. Section 2.1
メッセージフォーマット、タイプ、オペコード、およびシーケンス：参照2.1節
Functions: cf. [2] for SOAP version 1.2
機能：参照[2] SOAPバージョン1.2用
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_AES_EDE_CBC_SHA cipher)
機密保持のために：http://iana.org/beep/TLS（TLS_RSA_WITH_AES_EDE_CBC_SHA暗号を使用して）
for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side certificates)
（クライアント側の証明書をサポートするTLS_RSA_WITH_AES_EDE_CBC_SHA暗号を使用して）http://iana.org/beep/TLS：両方のために
Furthermore, 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 [1]'s Section 9 for a discussion of BEEP-specific security issues.
かかわらず、BEEP固有のセキュリティ問題の議論のための[1]のセクション9を参照してください。
Previously, the IANA registered "http://iana.org/beep/soap" for use with RFC 3288 [16]. This memo requires that the IANA register a URI-prefix of
以前に、IANAは、RFC 3288 [16]で使用するために "http://iana.org/beep/soap" を記録しました。このメモはIANAがのURI接頭辞を登録することが必要です
http://iana.org/beep/soap/VERSION
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／そあｐ／ゔぇＲしおん
to correspond to the family of profiles defined Section 8.1.
8.1節の定義されたプロファイルの家族に対応します。
The IANA has registered "soap.beep" and "soap.beeps" as URL schemes, as specified in Section 8.2 and Section 8.3, respectively.
それぞれ、8.2節と8.3節で指定されるようにIANAは、URLスキームとして「soap.beep」と「soap.beeps」を登録しました。
The IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 8.4.
IANAはまた、セクション8.4で指定されているように、TCPポート番号として「BEEPの上にSOAP」を登録しました。
The IANA now broadens these three registries to support the family of BEEP profiles defined by this URI prefix.
IANAは現在、このURI接頭辞で定義されたBEEPプロファイルの家族をサポートするために、これらの3つのレジストリを広げます。
Finally, the IANA maintains a list of SOAP profile features, cf. Section 7.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プロファイル機能のリストを保持し、参照7.1節。 IESGは、IANAが割り当てを行う前に仕様を検討するために、指定の専門家を割り当てるための責任があります。 IESGを接触させる前に、SOAPプロファイル機能の開発者が解説を勧誘するメーリングリストbeepwg@lists.beepcore.orgを使用する必要があります。
This memo differs from RFC 3288 [16] in one substantive way: a URL prefix is defined to support a family of BEEP profiles corresponding to different versions of SOAP. Similarly, the IANA registrations in Section 8.1, Section 8.3, and Section 8.4 are updated to reflect this broadening.
このメモは1実質的な方法で、RFC 3288 [16]とは異なり：URL接頭辞は、SOAPの異なるバージョンに対応したBEEPプロファイルの家族をサポートするために定義されています。同様に、8.1節、8.3節、8.4節でIANA登録は、この広がりを反映するように更新されます。
Support for W3C MTOM/XOP packaging has been added.
W3C MTOM / XOPパッケージのサポートが追加されました。
A new section was added to discuss the distributed state machine of the Request-Response MEP.
新しいセクションは、要求 - 応答MEPの分散状態マシンを議論するために追加されました。
In non-substantive ways, a small number of typographical errors were corrected.
非実体的な方法では、誤植の小さな数が修正されました。
The authors gratefully acknowledge the contributions of: Christopher Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T. Fielding.
クリストファー・フェリス、ヒューストンフランクリン、アレクセイ・メルニコフ、ビル・ミルズ、とロイT.フィールディング：著者は感謝の貢献を認めます。
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[1]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[2] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, June 2003.
[2]ニールセン、H.、メンデルゾーン、N.、Gudgin、M.、ハドリー、M.、およびJ.モロー、 "SOAPバージョン1.2パート1：メッセージングフレームワーク"、W3C REC REC-SOAP12-part1-20030624 6月2003。
[3] Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC REC-soap12-part2-20030624, June 2003.
[3]ニールセン、H.、ハドリー、M.、モロー、J.、メンデルゾーン、N.、およびM. Gudgin、 "SOAPバージョン1.2パート2：補助剤"、W3C REC REC-SOAP12-part2-20030624 2003年6月。
[4] 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.
[4]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[5] Baker, M. and M. Nottingham, "The "application/soap+xml" media type", RFC 3902, September 2004.
[5]ベーカー、M.およびM.ノッティンガム、 " "アプリケーション/石鹸+ xmlの" メディアタイプ"、RFC 3902、2004年9月。
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[7] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "SOAP Message Transmission Optimization Mechanism", W3C REC REC-soap12-mtom-20050125, January 2005.
[7]ノッティンガム、M.、メンデルゾーン、N.、Gudgin、M.、およびH. Ruellan、 "SOAPメッセージ送信最適化メカニズム"、W3C REC REC-SOAP12-MTOM-20050125 2005年1月。
[8] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "XML-binary Optimized Packaging", W3C REC REC-xop10-20050125, January 2005.
[8]ノッティンガム、M.、メンデルゾーン、N.、Gudgin、M.、およびH. Ruellan、 "XMLバイナリ最適化パッケージ"、W3C REC REC-xop10-20050125 2005年1月。
[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 Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[10]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[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のSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[12] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[12]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[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., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[14] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[15] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C REC REC-soap12-part0-20030624, June 2003.
[15]ミトラ、N.、 "SOAPバージョン1.2パート0：入門"、W3C REC REC-SOAP12-part0-20030624、2003年6月。
[16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002.
[16] O'Tuathail、E.およびM.ローズ、 "ブロック拡張可能交換プロトコル（BEEP）でのSOAP（Simple Object Access Protocol）の使用"、RFC 3288、2002年6月。
[17] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-SOAP-20000508, May 2000.
[17]ボックス、D.、Ehnebuske、D.、Kakivaya、G.、素人、A.、メンデルゾーン、N.、ニールセン、H.、Thatte、S.、およびD.ワイナー、「シンプルオブジェクトアクセスプロトコル（SOAP ）1.1" 、W3C NOTEのNOTE-SOAP-20000508、2000年5月。
[18] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[18]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
[19] Barton, J., Thatte, S., and H. Nielsen, "SOAP Messages with Attachments", W3C NOTE NOTE-SOAP-attachments-20001211, December 2000.
[19]バートン、J.、Thatte、S.、およびH.ニールセン、 "添付ファイル付きSOAPメッセージ"、W3Cメモメモ-SOAP-添付-20001211、2000年12月。
[20] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[20]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[21] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[21]パルメ、J.、Hopmann、A.、およびN. Shelness、RFC 2557、1999年3月 "は、HTML（MHTML）として集約文書のMIMEカプセル化"。
Appendix A. SOAP with Attachments (Informative)
添付ファイル付きの付録A.のSOAP（参考情報）
To provide compatibility with RFC3288 [16], a BEEP profile for SOAP MAY allow envelopes to be transmitted as the root part of a "multipart/related" [18] content, and with subordinate parts referenced using the rules of Section 3 of [19] (i.e., using either the "Content-ID:" [20] or "Content-Location:" [21] headers), e.g.,
RFC3288 [16]との互換性を提供するために、SOAPのためのBEEPプロフィールは、封筒は、「関連/マルチパート」[18]コンテンツのルート部として、および第3の規則を使用して参照される下位部分で送信されることを可能にすることができる[19 （すなわち、 "コンテンツID：" いずれかを使用して[20]、または "コンテンツロケーション：" [21]ヘッダー）を、例えば、
MSG 1 2 . 278 657
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' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> .. </env:Header> <env:Body> <theSignedForm href="cid:claim061400a.tiff@claiming-it.com" /> .. </env:Body> </env:Envelope>
<？xmlのバージョン= '1.0'？> <ENV：封筒のxmlns：ENV = "http://www.w3.org/2003/05/soap-envelope"> .. </ ENV：ヘッダー> <ENV：ボディ> <theSignedFormのhref = "CID：claim061400a.tiff@claiming-it.com" /> .. </ ENV：BODY> </ 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 [19], 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.
ヘッダ：[19]のセクション2と一致し、マルチパートが「開始」パラメータが含まれていること、および根元部が「コンテンツID」が含まれていることを強く推奨されています。 BEEPは、8ビット幅のパス、「変革」コンテンツ転送符号化（例えば、「BASE64」または「引用符で囲まれた印刷可能」）を提供するため、ただし、使用されるべきではありません。 MIME [9]の「Content-ID」ヘッダの値はグローバルに一意であることが必要であることをさらに留意されたいです。
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 (2006).
著作権（C）インターネット協会（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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。