[要約] RFC 4227は、BEEPでSOAPを使用するためのガイドラインを提供しています。このRFCの目的は、BEEPプロトコルを使用してSOAPメッセージを交換するための標準化と一貫性を確保することです。
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)
ブロック拡張可能な交換プロトコル（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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このメモは、Simple Object Access Protocol（SOAP）Binding Binding Blocks Extensible Exchange Protocol（BEEP）Coreを指定します。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ベースの（拡張可能なマークアップ言語）メッセージングプロトコルです。メッセージ形式を定義し、リモートプロシージャコール（RPC）、非同期イベント通知、未充填メッセージ、SOAP仲介者による転送など、さまざまなメッセージパターンを説明しますが、これらに限定されません。
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.
このメモは、BEEPプロファイル[1]を使用してSOAPエンベロープ[15]がどのように送信されるかを指定します。適合の実装は、SOAPバージョン1.2 [15]をサポートする必要があり、SOAPバージョン1.1 [17]などの他のバージョンをサポートする場合があります。このメモは、BEEPプロファイル[1]を使用してSOAPエンベロープ[15]がどのように送信されるかを指定します。前任者の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バージョン1.2を参照する場合、「エンベロープ」という用語は、[2]のセクション5.1で定義されている「エンベロープ」要素を指します。さらに、「ピア」、「クライアント」、「サーバー」、「1対1」、および「1対1」という用語が、ビープ音のコンテキストで使用されます。特に、[1]のセクション2.1および2.1.1は、ビープ音の役割と交換スタイルについて説明します。
The BEEP profile for SOAP is identified as
石鹸のビーププロファイルはとして識別されます
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.
チャネル作成中のビープ音の「プロファイル」要素。ここで、「バージョン」とは、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を実装することを選択した場合、プロファイル識別のためにこの均一なリソース識別子（URI）と「http://iana.org/beep/soap/1.1」の両方をサポートする必要があります。
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/1.2' />
</start>
The "serverName" attribute is analogous to HTTP's "Host" request-header field (cf. Section 14.23 of [4]).
「servername」属性は、HTTPの「ホスト」リクエストヘッダーフィールドに類似しています（[4]のセクション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 an "RPY" message), then the "ready" state is entered
* 他のピアが「bootrpy」（チャネル初期化中または「rpy」メッセージのいずれか）を送信する場合、「準備ができた」状態が入力されます
* 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 「Ready」状態では、いずれかのPEERが封筒を含む「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.
* ゼロ以上の送信」と「メッセージ、それぞれが封筒を含み、その後に「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のビーププロファイルにバインドされた各チャネルは、単一のリソース（ネットワークデータオブジェクトまたはサービス）へのアクセスを提供します。
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 analogous to HTTP's "abs_path" Request-URI parameter (cf. Section 5.1.2 of [4]) and
o HTTPの「ABS_PATH」リクエスト-URIパラメーター（[4]のセクション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 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>
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/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>
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.,
石鹸のビーププロファイルは、UTF-8としてエンコードされた封筒を送信し、メディアタイプ「アプリケーション/ソープXML」[5]を使用する必要があります。
MSG 1 1 . 0 284 Content-Type: application/soap+xml
MSG 1 1。0 284 Content-Type：アプリケーション/SOAP 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
To provide compatibility with RFC 3288 [16], it MAY use the media type "application/xml" [6].
RFC 3288 [16]との互換性を提供するために、メディアタイプ「Application/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.,
さらに、石鹸のビーププロファイルの実装は、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>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-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>
// 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 MultiPart/関連する使用に関するガイダンスについては、XOP [8]のセクション4.1を参照してください。ビープ音は8ビット幅のパスを提供するため、「変換される」コンテンツ移動エンコード（例：「base64」または「引用プリント可能」）を使用しないでください。MIME [9]では、「コンテンツID」ヘッダーの値がグローバルに一意であることを要求することに注意してください。XOP [8]のセクション4で述べたように、XOPは多様なパッケージングメカニズムで使用される場合があります。石鹸でビープ音の実装がMTOM/XOPをサポートする場合、MIME MultiPart/関連XOPパッケージ形式をサポートし、他のものをサポートする必要があります。追加の形式は、将来的にはビープ音に固有のXOPパッケージ形式を含めることができます（たとえば、別のチャンネルの添付ファイルをソープチャネルに送信します。これにより、MIME境界タグの検索を避け、添付ファイルの怠zyな配信が可能になり、それらを配信します。本当に必要でした。）
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」メッセージを送信します。
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」メッセージを送り返します。
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」メッセージ。
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.
石鹸のビーププロファイルは、石鹸障害に「ERR」メッセージを使用しません。1対1の交換を実行するとき、サーバーによって生成されたSOAP応答（石鹸障害を含む）は、常に「RPY」メッセージで返されます。1対多くの交換を実行するとき、サーバーによって生成された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]).
ソープエンベロープとは関係のないビープメッセージにエラーがある場合（たとえば、形成されていないMIMEメッセージまたはMIMEコンテンツタイプがサポートされていない）、サーバーはERRメッセージ（[1]のセクション7.1を参照）で応答します（[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).
この結合は、石鹸のビープ音のプロファイルURIとまったく同じURIによって識別されます（セクション2を参照）。
The Base URI for the SOAP envelope is the URI of the resource identified in the bootmsg.
石鹸エンベロープのベースURIは、bootmsgで識別されたリソースのURIです。
An implementation of this binding MUST support the following SOAP Message Exchange Pattern (MEP):
このバインディングの実装は、次の石鹸メッセージ交換パターン（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 「RequestingSoaPnode」」のメッセージ交換を開始するSOAPノードがビープピアにインスタンス化されたSOAPノードが役割（つまり、プロパティhttp：// www.w3.org/2003/soap/bindindingframewark/exchangecontext/role）を想定する場合があります。
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 他のビープピアにインスタンス化された石鹸ノードは、「ResponsingSoapNode」」の役割（つまり、プロパティhttp://www.w3.org/2003/05/soap/ bindingframework/exchangeContext/role）を想定する場合があります。
The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with Section 6.2 of [3].
要求する石鹸ノードの動作の全体的な流れは、[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リクエストがまだ送信されている間に着信石鹸の応答情報を処理できる必要があります。
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".
「init」状態では、セクション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".
「要求」状態では、要求メッセージの多くが送信され、応答の到着が待っています。応答メッセージの開始が受信されると、それがビープエラーメッセージの場合、状態は「失敗」に移行します。それ以外の場合、州は「受信の送信」に移行します。
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".
「受信」状態では、要求メッセージの送信と応答メッセージの受信が完了します。応答メッセージは、コンテンツタイプのヘッダーフィールドに与えられたメディアタイプに石鹸メッセージを運ぶためのルールに従ってシリアル化された石鹸エンベロープを含むと想定されています。応答の受領が完了すると、州は「成功」に移行します。
"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]
応答する石鹸ノードの動作の全体的な流れは、[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).
「init」状態では、バインディングがインバウンドリクエストの開始を待ちます。この状態では、ERRメッセージのみを生成する場合があります（セクション4.4に従って）。
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よりもビープ音を介した石鹸の使用を識別する2つのURLスキーム「Soap.Beep」と「Soap.Beeps」を定義します。現在、石鹸の「一般的な」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に示されている例になる可能性があります。
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 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-Beep」のサービスパラメーターと「TCP」のプロトコルパラメーターで使用され、IP/TCPアドレス指定情報を決定します。適切なSRV RRが見つからない場合（例： "_soap-beep._tcp.stockquoteserver.example.com"の場合）、DNSはドメイン名に対応するA RRSに対して照会され、使用されるポート番号は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).
「SOAP.BEEPS」URLスキームは、セクション6.1で指定された「SOAP.BEEP」URLスキームとあらゆる点で同一です。。特に、両方のURLスキームは、セクション6.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 [1] for an example of how a BEEP peer may choose to issue different greetings based on whether privacy is in use.
とにかく、交渉プロセスが完了すると、両方のビープ音が新しい挨拶をするチューニングリセットが発生します。ビープピアがプライバシーが使用されているかどうかに基づいて、さまざまな挨拶を発行することを選択する方法の例については、[1]のセクション3を参照してください。
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.
連絡先情報：機能の著者に電子連絡先情報を指定します。
Profile Identification: http://iana.org/beep/soap/VERSION
Messages exchanged during Channel Creation: bootmsg, bootrpy
Messages starting one-to-one exchanges: bootmsg, a SOAP "envelope"
1対1の交換を開始するメッセージ：bootmsg、石鹸「エンベロープ」
Messages in positive replies: bootrpy, a SOAP "envelope"
肯定的な返信のメッセージ：bootrpy、石鹸「エンベロープ」
Messages in negative replies: error
否定的な返信のメッセージ：エラー
Messages in one-to-many exchanges: a SOAP "envelope"
1対多くの交換のメッセージ：石鹸「エンベロープ」
Message Syntax: a SOAP envelope
メッセージ構文：石鹸封筒
Message Semantics: corresponds to the relevant SOAP specification, e.g., for SOAP version 1.2, cf. [2].
メッセージセマンティクス：関連するSOAP仕様、たとえばSOAPバージョン1.2、cf。[2]。
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
URL scheme name: soap.beep
URLスキーム名：Soap.beep
URL scheme syntax: cf. Section 6.1
URLスキーム構文：Cf。セクション6.1
Character encoding considerations: cf. the "generic URI" syntax defined in Section 3 of [10]
考慮事項のキャラクターエンコーディング：cf。[10]のセクション3で定義されている「ジェネリックURI」構文
Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP
意図された使用法：石鹸のビーププロファイルを使用して利用可能になった石鹸リソースを識別します
Applications using this scheme: cf. "Intended usage", above
このスキームを使用したアプリケーション：cf。上記の「意図された使用」
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Security Considerations: cf. Section 9
セキュリティ上の考慮事項：cf。セクション9
Relevant Publications: cf. [2] for SOAP version 1.2
関連する出版物：cf。[2] SOAPバージョン1.2の場合
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <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 Character encoding considerations: cf. the "generic URI" syntax defined in Section 3 of [10]
URLスキーム構文：Cf。セクション6.2文字エンコーディングの考慮事項：cf。[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: cf. "Intended usage", above
このスキームを使用したアプリケーション：cf。上記の「意図された使用」
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Security Considerations: cf. Section 9
セキュリティ上の考慮事項：cf。セクション9
Relevant Publications: cf. [2] for SOAP version 1.2
関連する出版物：cf。[2] SOAPバージョン1.2の場合
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Author/Change controller: the IESG
著者/変更コントローラー：IESG
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: cf. Section 2.1
メッセージ形式、タイプ、オペコード、およびシーケンス：cf。セクション2.1
Functions: cf. [2] for SOAP version 1.2
関数：cf。[2] SOAPバージョン1.2の場合
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>
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 cipherを使用）
for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side certificates)
両方の場合：http：//iana.org/beep/tls（TLS_RSA_WITH_AES_EDE_CBC_SHA CIPHAを使用するクライアント側の証明書をサポートする）
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.
とにかく、ビープ特有のセキュリティ問題の議論については、[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-Prefixを登録する必要があります
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.
IANAは、セクション8.2とセクション8.3でそれぞれ指定されているように、「Soap.beep」と「soap.beeps」をURLスキームとして登録しています。
The IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 8.4.
IANAは、セクション8.4で指定されているように、「石鹸上のビープ音」をTCPポート番号として登録しています。
The IANA now broadens these three registries to support the family of BEEP profiles defined by this URI prefix.
IANAは現在、これら3つのレジストリを広げて、このURIプレフィックスで定義されたビーププロファイルのファミリをサポートしています。
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は石鹸プロファイル機能のリストを維持しています。セクション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の異なるバージョンに対応するビーププロファイルのファミリーをサポートするために定義されます。同様に、セクション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] Rose、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] Nielsen、H.、Mendelsohn、N.、Gudgin、M.、Hadley、M.、およびJ. Moreau、「SOAPバージョン1.2パート1：メッセージングフレームワーク」、W3C REC REC-SOAP12-PART1-20030624、2003年6月。
[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] Nielsen、H.、Hadley、M.、Moreau、J.、Mendelsohn、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[5] Baker, M. and M. Nottingham, "The "application/soap+xml" media type", RFC 3902, September 2004.
[5] Baker、M。and M. Nottingham、「アプリケーション/ソープXML」メディアタイプ」、RFC 3902、2004年9月。
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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] Nottingham、M.、Mendelsohn、N.、Gudgin、M.、およびH. Ruellan、「SOAPメッセージ送信最適化メカニズム」、W3C 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] Nottingham、M.、Mendelsohn、N.、Gudgin、M.、およびH. Ruellan、「XML-Binary Optimized Packaging」、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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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 RR（DNS SRV）」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「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。、「Secure/Multipurpose Internet Mail拡張機能（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] Mitra、N。、「SOAPバージョン1.2パート0：プライマー」、W3C 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. Rose、「ブロック拡張可能な交換プロトコル（BEEP）のSimple Object Access Protocol（SOAP）を使用」、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] Box、D.、Ehnebuske、D.、Kakivaya、G.、Layman、A.、Mendelsohn、N.、Nielsen、H.、Thatte、S。、およびD. Winer、「Simple Object Access Protocol（SOAP）1.1」、W3CノートNote-SOAP-2005508、2000年5月。
[18] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[18] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、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] Barton、J.、Thatte、S。、およびH. Nielsen、「添付ファイル付き石鹸メッセージ」、W3CノートNote-Soap-Attachments-20001211、2000年12月。
[20] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[20] Levinson、E。、「コンテンツIDおよびメッセージ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] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集計ドキュメントのMIMEカプセル化」、RFC 2557、1999年3月。
Appendix A. SOAP with Attachments (Informative)
付録A. 添付ファイル付き石鹸（有益）
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]との互換性を提供するために、石鹸のビーププロファイルにより、封筒を「マルチパート/関連」[18]コンテンツのルート部分として送信することができます。]（すなわち、「コンテンツID」：[20]または「コンテンツロケーション：」のいずれかを使用してください）、例えば、
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>
<?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>
--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 [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と一致して、マルチパートには「start」パラメーターを含み、ルート部分に「コンテンツID」ヘッダーが含まれることを強くお勧めします。ただし、ビープ音は8ビット幅のパスを提供するため、「変換される」コンテンツトランスファーエンコード（例：「base64」または「引用プリント可能」）を使用しないでください。さらに、MIME [9]では、「コンテンツID」ヘッダーの値がグローバルにユニークであることが必要であることに注意してください。
Authors' Addresses
著者のアドレス
Eamon O'Tuathail Clipcode.com 24 Thomastown Road Dun Laoghaire Dublin IE
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
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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）によって提供されます。