RFC4227 日本語訳
4227 Using the Simple Object Access Protocol (SOAP) in BlocksExtensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. January 2006. (Format: TXT=39112 bytes) (Obsoletes RFC3288) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
O'Tuathailがコメントのために要求するワーキンググループE.をネットワークでつないでください: 4227Clipcode.comは以下を時代遅れにします。 3288年のM.バラカテゴリ: Inc.2006年1月に相談する標準化過程ドーヴァービーチ
Using the Simple Object Access Protocol (SOAP)
in Blocks Extensible Exchange Protocol (BEEP)
ブロックの広げることができるSimple Object Access Protocol(SOAP)を使用して、プロトコルを交換してください。(ビープ音)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このメモはSimple Object Access Protocol(SOAP)のBlocks Extensible Exchangeプロトコルに拘束力がある(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, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.
SOAPはさまざまな分配されたメッセージングがモデルであると実装するのに使用されるXMLベースの(eXtensible Markup Language)メッセージング・プロトコルです。 それは、メッセージ・フォーマットを定義して、SOAP仲介者を通してさまざまなメッセージパターン、包含、他、Remote Procedure Calling(RPC)、非同期的なイベント通知、不承認のメッセージ、および推進について説明します。
O'Tuathail & Rose Standards Track [Page 1] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[1ページ]RFC4227
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
1. 序論…3 2. プロフィール識別を鳴らしてください…3 2.1. 初期設定の輪郭を描いてください…4 3. SOAPメッセージパッケージ…6 4. SOAPメッセージは型に基づいて作ります…8 4.1. 一方向メッセージ…8 4.2. 要求応答交換…8 4.3. N要求/応答の交換…8 4.4. エラー処理…9 5. SOAPのプロトコルの拘束力があるフレームワーク順応…9 5.1. 拘束力がある名前…9 5.2. URIを基礎づけてください…9 5.3. サポートしているSOAP交換処理は型に基づいて作ります…9 5.4. 特徴であるとサポートされます…9 5.5. MEP操作…10 5.5.1. SOAPノードを要求する振舞い…10 5.5.1.1. イニット…10 5.5.1.2. 要求します。10 5.5.1.3. + 受信を送ります…10 5.5.1.4. 成功とやり損ない…11 5.5.2. 応じているSOAPノードの動き…11 5.5.2.1. イニット…11 5.5.2.2. 受信します…11 5.5.2.3. + 発信を受けます…11 5.5.2.4. 成功とやり損ない…11 6. URL体系…11 6.1. soap.beep URL Scheme…11 6.1.1. IP/TCPアドレス情報を決議します…12 6.2. soap.beeps URL Scheme…13 7. 登録テンプレート…13 7.1. SOAPプロフィール特徴登録テンプレート…13 8. 登録証明書に頭文字をつけてください…13 8.1. 登録: SOAPプロフィール…13 8.2. 登録: soap.beep URL Scheme…14 8.3. 登録: soap.beeps URL Scheme…14 8.4. 登録: システムの(よく知られる)のTCPはSOAPの数を移植します…15 9. セキュリティ問題…15 10. IANA問題…16 11. RFC3288からの変化…16 12. 承認…17 13. 参照…17 13.1. 標準の参照…17 13.2. 有益な参照…18 A. 付録--付属が(有益)で石けんでこすります。19
O'Tuathail & Rose Standards Track [Page 2] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[2ページ]RFC4227
1. Introduction
1. 序論
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の役割と交換スタイルについて議論してください。
2. BEEP Profile Identification
2. ビープ音プロフィール識別
The BEEP profile for SOAP is identified as
SOAPのためのプロフィールが特定されるBEEP
http://iana.org/beep/soap/VERSION
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はチャンネルの間、要素の「輪郭を描きます」。作成「バージョン」がSOAP仕様の数値バージョンを呼ぶところ。
For example,
例えば
http://iana.org/beep/soap/1.2
http://iana.org/beep/soap/1.2
refers to version 1.2.
バージョン1.2を示します。
Note that RFC 3288 [16] used
[16]が使用したそのRFC3288に注意してください。
http://iana.org/beep/soap
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 "と同様にプロフィール識別のために両方がこのUniform Resource Identifier(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.,
第1代チャンネルが首尾よく創造されるとき、BEEPでは、「始め」要素の"serverName"属性は例えばサーバーの役割で行動する同輩に関連している「事実上のホスト」を特定します。
O'Tuathail & Rose Standards Track [Page 3] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[3ページ]RFC4227
<start number='1' serverName='stockquoteserver.example.com'>
<profile uri='http://iana.org/beep/soap/1.2' />
</start>
<スタート番号は'1'serverNameは'stockquoteserver.example.comと等しく'><プロフィールuriが' http://iana.org/beep/soap/1.2 '/></スタート>と等しいこと'と等しいです。
The "serverName" attribute is analogous to HTTP's "Host" request- header field (cf. Section 14.23 of [4]).
"serverName"属性はHTTPの「ホスト」要求ヘッダーフィールドに類似しています。(Cf。 セクション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 「ブーツ」状態では、チャンネルの作成を要求する同輩は"bootmsg"(チャンネル初期化か「エムエスジー」メッセージの)を送ります。
* 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.
* さもなければ、もう片方の同輩は「誤り」(チャンネル初期化か「間違えてください」というメッセージの)を送って、次に、州の変化は全く起こりません。
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 「準備ができる」状態では、どちらの同輩も、封筒を含む「エムエスジー」メッセージを送ることによって、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.
* "NUL"メッセージでそれぞれ封筒を含んでいて、ゼロか、より多くの「ANS」メッセージを返送するということになりました。
Regardless, no state change occurs.
不注意に、州の変化は全く起こりません。
2.1. Profile Initialization
2.1. プロフィール初期設定
The boot message is used for two purposes:
ブーツメッセージは2つの目的に使用されます:
resource identification: each channel bound to the BEEP profile
for SOAP provides access to a single resource (a network data
object or service).
リソース識別: SOAPにBEEPプロフィールに向かっている各チャンネルはただ一つのリソース(ネットワークデータ・オブジェクトかサービス)へのアクセスを提供します。
feature negotiation: if new features of SOAP (such as compression)
emerge, their use can be negotiated.
交渉を特徴としてください: SOAP(圧縮などの)に関する新機能が現れるなら、彼らの使用を交渉できます。
O'Tuathail & Rose Standards Track [Page 4] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[4ページ]RFC4227
The DTD syntax for the boot message and its response are:
ブーツメッセージのためのDTD構文とその応答は以下の通りです。
<!ELEMENT bootmsg EMPTY>
<!ATTLIST bootmsg
resource CDATA #REQUIRED
features NMTOKENS "">
<!ELEMENT bootmsg EMPTY><!ATTLIST bootmsgリソースCDATA#REQUIREDが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
o 「リソース」属性。(その属性はHTTPの「腹筋_経路」Request-URIパラメタに類似しています)。(Cf。 [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つを含んでいるか、そして、以上がトークンを特徴とします、それぞれチャンネルの上の活用可能性のために要求されているSOAPのためのBEEPプロフィールに関するオプション機能を示して。
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]).
さもなければ、ブーツメッセージが不適切に形成されるか、または要求されたリソースが認識されないなら、サーバーの役割で行動している同輩はエラーメッセージで返答します。(Cf。 セクション7.1 [1]について). 通常、チャンネル初期化の間、ブーツメッセージとその応答を交換します。(Cf。 セクション2.3 .1 .2、[1]).
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>
C: <スタート番号=''1serverNameが'stockquoteserver.example.com'>Cと等しいです'。 <プロフィールuriは' http://iana.org/beep/soap/1.2 '>Cと等しいです:、' '<[CDATA[<bootmsgリソース='/StockQuote'/>]]!>C: </プロフィール>C: </スタート>。
O'Tuathail & Rose Standards Track [Page 5] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[5ページ]RFC4227
S: <profile uri='http://iana.org/beep/soap/1.2'>
S: <![CDATA[<bootrpy />]]>
S: </profile>
S: ' http://iana.org/beep/soap/1.2 '<プロフィールuri=>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>
C: <スタート番号=''1serverNameが'stockquoteserver.example.com'>Cと等しいです'。 <プロフィールuriは' http://iana.org/beep/soap/1.2 '>Cと等しいです:、' '<[CDATA[<bootmsgリソース='/StockPick'/>]]!>C: </プロフィール>C: </スタート>。
S: <profile uri='http://iana.org/beep/soap/1.2'>
S: <![CDATA[<error code='550'>resource not
S: supported</error>]]>
S: </profile>
S: ' http://iana.org/beep/soap/1.2 '<プロフィールuri=>S:、' <[CDATA[<エラーコードはSではなく、'550'>リソースと等しいです: </誤り>であるとサポートされる]]!>S:、' </プロフィール>。
Although the channel was created successfully, it remains in the "boot" state.
チャンネルは首尾よく創造されましたが、それは「ブーツ」州に残っています。
3. SOAP Message Packages
3. SOAPメッセージパッケージ
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とSHOULDが例えばメディアタイプ「アプリケーション/石鹸+xml」[5]を使用するのでコード化された封筒を送ります。
MSG 1 1 . 0 284 Content-Type: application/soap+xml
MSG1 1.0284コンテントタイプ: アプリケーション/石鹸+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
xmlns: <env: 封筒envが等しい、「 http://www.w3.org/2003/05/soap-envelope 、「><env: ヘッダー><m:GetLastTradePrice xmlns:m=」、いくつか、-、URI、」 /></env: ヘッダー><はenvします: ボディー><がxmlns: p=を象徴する、「いくつか、-、URI、></env: 」 >DIS</シンボル></env: ボディー封筒>END
To provide compatibility with RFC 3288 [16], it MAY use the media type "application/xml" [6].
RFC3288[16]を互換性に提供するために、それはメディアタイプ「アプリケーション/xml」[6]を使用するかもしれません。
O'Tuathail & Rose Standards Track [Page 6] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[6ページ]RFC4227
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]を使用して、SOAPのためのBEEPプロフィールの実装は封筒のトランスミッションをサポートするかもしれません。
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
エムエスジー1 2.2831436MIMEバージョン: 1.0コンテントタイプ: 複合である、または関連です; 境界=MIME_境界;。 =「アプリケーション/xop+xml」をタイプしてください。 「= "<mymessage.xml@example.org を始動してください、gt;、」、。 startinfoは「+ アプリケーション/石鹸xml」と等しいです。 動作は満足している記述と等しいです: 私の映画があるSOAPメッセージとそれのsig
--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>
--_境界コンテントタイプをまねてください: アプリケーション/xop+xml。 charset=UTF-8。 =「+ アプリケーション/石鹸xml」をタイプしてください。 動作は満足している転送コード化と等しいです: 8はコンテント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: ' http://www.w3.org/2004/11/xmlmime '><xmlmime=石鹸: ボディー><m: データxmlns: m=' http://example.org/stuff '><m: フォトxmlmime: contentTypeは'イメージ/png'><xopと等しいです: xmlnsを含めてください: xopは' http://www.w3.org/2004/08/xop/include 'href='Cid: http://example 'と等しいです; 'org/me.png'/></m: フォト><m:sig xmlmime:contentType='pkcs7アプリケーション/署名/></m: '><xop: xmlnsを含めてください: xopは'' http://www.w3.org/2004/08/xop/include 'href=Cid: http://example.org/my.hsh と等しく'sig></m: データ></石鹸: ボディー></石鹸: 封筒>'
--MIME_boundary Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: <http://example.org/me.png>
--_境界コンテントタイプをまねてください: png Content転送イメージ/コード化: 2進のコンテントID: <http://example.org/me.png>。
// binary octets for png
pngにおける//2進の八重奏
--MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID: <http://example.org/my.hsh>
--_境界コンテントタイプをまねてください: pkcs7-署名Content転送アプリケーション/コード化: 2進のコンテントID: <http://example.org/my.hsh>。
O'Tuathail & Rose Standards Track [Page 7] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[7ページ]RFC4227
// binary octets for signature
署名のための//2進の八重奏
--MIME_boundary-- END
--MIME_境界--終わってください。
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に相談してください。 BEEPは幅8ビットの経路、「変形させる」Content転送コード化を提供します。(例えば、「base64"か「引用されて印刷可能」) 使用するべきではありません」。 MIME[9]が、「コンテントID」ヘッダーの値がグローバルにユニークであることを必要とすることに注意してください。 XOP[8]のセクション4に述べられているように、XOPはさまざまのパッケージメカニズムと共に使用されるかもしれません。BEEPの実装であるときに、SOAPでは、サポートMTOM/XOPはしていて、それはMIME Multipart/関連のXOPパッケージが他のものをフォーマットして、サポートするかもしれないSHOULDサポートです。 追加形式は将来、BEEPに特定のXOPパッケージ形式を含むかもしれません。(例えば、異なったチャンネルの上の付属をSOAPチャンネルに送って、本当に必要である場合にだけそれらを提供して、どれが、MIME限界を捜し求めるのを避けるだろうかが、付属の怠惰な配送にタグ付けをして、許します。)
4. SOAP Message Patterns
4. SOAPメッセージパターン
4.1. One-Way Message
4.1. 一方向メッセージ
A one-way message involves sending a message without any response being returned.
一方向メッセージは、返される少しも応答なしでメッセージを送ることを伴います。
The BEEP profile for SOAP achieves this using a one-to-many exchange, in which the client sends a "MSG" message containing an envelope, and the server immediately sends back a "NUL" message, before processing the contents of the envelope.
SOAPのためのBEEPプロフィールは多くへの1回の交換を使用することでこれを達成します、そして、サーバはすぐに"NUL"メッセージを返送します、封筒のコンテンツを処理する前に。そこでは、クライアントが封筒を含む「エムエスジー」メッセージを送ります。
4.2. Request-Response Exchange
4.2. 要求応答交換
A request/response exchange involves sending a request, which results in a response being returned.
要求/応答交換は、要求を送ることを伴います。(要求は返される応答をもたらします)。
The BEEP profile for SOAP achieves this using a one-to-one exchange, in which the client sends a "MSG" message containing an envelope, and the server sends back a "RPY" message containing an envelope.
SOAPのためのBEEPプロフィールはクライアントが封筒を含む「エムエスジー」メッセージを送る1〜1回の交換を使用することでこれを達成します、そして、サーバは封筒を含む"RPY"メッセージを返送します。
4.3. Request/N-Responses Exchange
4.3. N要求/応答の交換
A request/N-responses exchange involves sending a request, which results in zero or more responses being returned.
N要求/応答の交換は、要求、どれがゼロをもたらすか、そして、または、より多くの応答を返させることを伴います。
O'Tuathail & Rose Standards Track [Page 8] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[8ページ]RFC4227
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プロフィールは多くへの1回の交換を使用することでこれを達成します、そして、サーバはゼロか、より多くの「ANS」メッセージを返送します、それぞれ"NUL"メッセージがあとに続いた封筒を含んでいて。そこでは、クライアントが封筒を含む「エムエスジー」メッセージを送ります。
4.4. Error Handling
4.4. エラー処理
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欠点に「間違えてください」というメッセージを使用しません。 1〜1回の交換を実行するとき、"RPY"メッセージでいつも応答(SOAP欠点を含んでいる)がサーバで生成したどんなSOAPも返します。 多くへの1回の交換を実行するとき、「ANS」メッセージでいつも応答(SOAP欠点を含んでいる)がサーバで生成したどんなSOAPも返します。
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]).
適切な回答コードで[1])のセクション7.1を見てください。SOAP封筒(例えば、不十分に形成されたMIMEメッセージかコンテントタイプがサポートしなかったMIME)に関係ないBEEPメッセージがある誤りがあればサーバがERRメッセージで反応する、((例えば、[1])のセクション8を見てください。
5. SOAP Protocol Binding Framework Conformance
5. SOAPのプロトコルの拘束力があるフレームワーク順応
5.1. Binding Name
5.1. 拘束力がある名前
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を見てください)。
5.2. Base URI
5.2. 基地のURI
The Base URI for the SOAP envelope is the URI of the resource identified in the bootmsg.
SOAP封筒のための基地のURIはbootmsgで特定されたリソースのURIです。
5.3. Supported SOAP Message Exchange Patterns
5.3. SOAP交換処理パターンであるとサポートされます。
An implementation of this binding MUST support the following SOAP Message Exchange Pattern (MEP):
この結合の実装は以下のSOAP Message Exchange Pattern(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を見てください。
5.4. Supported Features
5.4. 特徴であるとサポートされます。
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を見てください。)
O'Tuathail & Rose Standards Track [Page 9] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[9ページ]RFC4227
5.5. MEP Operation
5.5. MEP操作
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ノードは、役割が"RequestingSOAPNode"の(すなわち、特性のhttp://www.w3.org/2003/05/石鹸/bindingFramework/ExchangeContext/役割)であると仮定するかもしれません。
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/役割)であると仮定するかもしれません。
5.5.1. Behavior of Requesting SOAP Node
5.5.1. SOAPノードを要求する振舞い
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応答情報を処理できなければなりません。
5.5.1.1. Init
5.5.1.1. イニット
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".
「イニット」状態では、セクション3によると、BEEPメッセージは定式化されます、そして、メッセージの伝達は始まります、そして、次に、状態は「要求」に変化します。
5.5.1.2. Requesting
5.5.1.2. 要求
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メッセージであるなら、状態は「失敗する」ように移行します。 さもなければ、状態は「発信+受信」に移行します。
5.5.1.3. Sending+Receiving
5.5.1.3. 発信+受信
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".
「発信+受信」では、状態、応答メッセージの要求メッセージと受信のトランスミッションは終了しています。 応答メッセージがコンテントタイプヘッダーフィールドでメディアタイプで与えられたSOAPメッセージを伝えるための規則に従って連載されたSOAP封筒を含むと思われます。 応答の領収書がいったん完成されると、状態は「成功」に移行します。
O'Tuathail & Rose Standards Track [Page 10] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[10ページ]RFC4227
5.5.1.4. Success and Fail
5.5.1.4. 成功とやり損ない
"Success" and "Fail" are the terminal states for the state machine.
「成功」と「失敗してください」は州のマシンのための端末の州です。
5.5.2. Behavior of Responding SOAP Node
5.5.2. 応じているSOAPノードの動き
The overall flow of the behavior of a responding SOAP node follows a state machine description consistent with Section 6.2 of [3]
SOAPノードがセクション6.2と一致した州のマシン記述に続く応じることの振舞いの総合的な流れ[3]
5.5.2.1. Init
5.5.2.1. イニット
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に生成するだけであるかもしれません。
5.5.2.2. Receiving
5.5.2.2. 受信します。
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によると、応答の始まりを準備します。 応答を伝える準備ができているとき、状態は「受信+発信」に移行します。
5.5.2.3. Receiving+Sending
5.5.2.3. 受信+発信
The binding completes the receiving of the request and sending of the response and then transitions to "Success" state.
結合は、要求の受信と応答の発信を完成して、次に、「成功」状態への変遷を完成します。
5.5.2.4. Success and Fail
5.5.2.4. 成功とやり損ない
"Success" and "Fail" are the terminal states that indicate completion of the message exchange.
「成功」と「失敗してください」は交換処理の完成を示す端末の州です。
6. URL Schemes
6. URL体系
This memo defines two URL schemes, "soap.beep" and "soap.beeps", which identify the use of SOAP over BEEP over TCP. Note that, at present, a "generic" URL scheme for SOAP is not defined.
このメモは2つのURL体系、"soap.beep"、および"soap.beeps"を定義します。(それは、TCPの上のBEEPの上でSOAPの使用を特定します)。 現在のところSOAPの「ジェネリック」URL体系が定義されないことに注意してください。
6.1. The soap.beep URL Scheme
6.1. soap.beep URL Scheme
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'Tuathail & Rose Standards Track [Page 11] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[11ページ]RFC4227
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に示された例をもたらすかもしれません。
6.1.1. Resolving IP/TCP Address Information
6.1.1. IP/TCPアドレス情報を決議します。
The "soap.beep" URL scheme indicates the use of the BEEP profile for SOAP running over TCP/IP.
"soap.beep"URL体系はBEEPプロフィールの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 Resource Recordsのために質問されます、そして、ポートナンバーは直接使用されます。
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.
Service Recordアルゴリズム[11]は、IP/TCPアドレス指定情報を決定するのに「石鹸ビープ音」のサービスパラメタと"tcp"のプロトコルパラメタと共に使用されます。 適切でないなら、SRV RRsは見つけられます。「(」 例えば、_石鹸ビープ音のために_tcp.stockquoteserver.example.com、」、)、次に、DNSはドメイン名に対応するA RRsのために質問されて、数が使用したポートはセクション8.4における登録のためにIANAによって割り当てられます。
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によって割り当てられます。
O'Tuathail & Rose Standards Track [Page 12] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[12ページ]RFC4227
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]で指定された構文に従わなければなりません。
6.2. The soap.beeps URL Scheme
6.2. soap.beeps URL Scheme
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体系に、SOAPのためのBEEPプロフィール、BEEPセッションを始める前にプライバシーのために調整しなければならない例外で。 特に、両方のURL体系がセクション6.1.1(例えば、SRVルックアップのためのTCPのための同じポートナンバーと、など同じサービス名)における指定されるとしてのアドレス解決に同じアルゴリズムとパラメタを使用することに注意してください。
There are two ways to perform privacy tuning on a BEEP session, either
そこでは、働く2つの方法がBEEPセッションでのプライバシーチューニングですか?
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に相談してください。
7. Registration Templates
7. 登録テンプレート
7.1. SOAP Profile Feature Registration Template
7.1. SOAPプロフィール特徴登録テンプレート
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.
問い合わせ先: 特徴の作者に電子問い合わせ先を指定してください。
8. Initial Registrations
8. 初期の登録証明書
8.1. Registration: The SOAP Profile
8.1. 登録: SOAPプロフィール
Profile Identification: http://iana.org/beep/soap/VERSION
識別の輪郭を描いてください: http://iana.org/beep/soap/VERSION
O'Tuathail & Rose Standards Track [Page 13] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[13ページ]RFC4227
Messages exchanged during Channel Creation: bootmsg, bootrpy
メッセージはChannel Creationの間、交換しました: bootmsg、bootrpy
Messages starting one-to-one exchanges: bootmsg, a SOAP "envelope"
始めが1〜1に以下を交換するというメッセージ bootmsg、SOAP「封筒」
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仕様、例えば、SOAPバージョン1.2、Cfのために、対応しています。 [2].
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
問い合わせ先: Eamon O' Tuathail <eamon.otuathail@clipcode.com 、gt;、マーシャルが上昇した、lt;、 mrose@dbc.mtview.ca.us 、gt;、'
8.2. Registration: The soap.beep URL Scheme
8.2. 登録: soap.beep URL Scheme
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「ジェネリックURI」構文はセクション3で定義しました。[10]
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
これを使用するアプリケーションが計画されます: Cf。 上の「意図している用法」
Interoperability considerations: 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>
問い合わせ先: Eamon O' Tuathail <eamon.otuathail@clipcode.com 、gt;、マーシャルが上昇した、lt;、 mrose@dbc.mtview.ca.us 、gt;、'
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
8.3. Registration: The soap.beeps URL Scheme
8.3. 登録: soap.beeps URL Scheme
URL scheme name: soap.beeps
URL体系名: soap.beeps
URL scheme syntax: cf. Section 6.2
URL体系構文: Cf。 セクション6.2
O'Tuathail & Rose Standards Track [Page 14] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[14ページ]RFC4227
Character encoding considerations: cf. the "generic URI" syntax
defined in Section 3 of [10]
文字符号化問題: Cf「ジェネリックURI」構文はセクション3で定義しました。[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: cf. "Intended usage", above
これを使用するアプリケーションが計画されます: Cf。 上の「意図している用法」
Interoperability considerations: 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>
問い合わせ先: Eamon O' Tuathail <eamon.otuathail@clipcode.com 、gt;、マーシャルが上昇した、lt;、 mrose@dbc.mtview.ca.us 、gt;、'
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
8.4. Registration: The System (Well-Known) TCP Port Number for SOAP
over BEEP
8.4. 登録: ビープ音の上のSOAPのためのシステムの(よく知られる)のTCPポートナンバー
Protocol Number: TCP
数について議定書の中で述べてください: TCP
Message Formats, Types, Opcodes, and Sequences: cf. Section 2.1
メッセージ・フォーマット、タイプ、Opcodes、および系列: 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
提案された名前: ビープ音の上のSOAP
Short name: soap-beep
省略名: 石鹸ビープ音
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
問い合わせ先: Eamon O' Tuathail <eamon.otuathail@clipcode.com 、gt;、マーシャルが上昇した、lt;、 mrose@dbc.mtview.ca.us 、gt;、'
9. Security Considerations
9. セキュリティ問題
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暗号を使用します)
O'Tuathail & Rose Standards Track [Page 15] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[15ページ]RFC4227
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暗号を使用します)
Furthermore, implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [13] or S/MIME [14].
その上、実装は、メッセージの保全と秘密性を提供しながらMIMEベースのセキュリティー・サービスを提供するのを選ぶかもしれません、OpenPGP[13]やS/MIME[14]のように。
Regardless, consult [1]'s Section 9 for a discussion of BEEP-specific security issues.
不注意に、相談してください。BEEP特有の安全保障問題の議論のための[1]によるセクション9です。
10. IANA Considerations
10. IANA問題
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は使用のためにRFC3288[16]に" http://iana.org/beep/soap "を登録しました。 このメモは、IANAがURI接頭語を登録するのを必要とします。
http://iana.org/beep/soap/VERSION
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は"soap.beep"を登録しました、そして、URLとしての"soap.beeps"はセクション8.2とセクション8.3で指定されるようにそれぞれ計画されます。
The IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 8.4.
また、IANAはセクション8.4で指定されるようにTCPポートナンバーとしての「ビープ音の上の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プロフィール機能のリスト、Cfを維持します。 セクション7.1。 IESGは課題をしながらIANAの前で仕様を再検討するために指定された専門家を選任するのに責任があります。 IESGに連絡する前に、SOAPプロフィール機能の開発者は、論評に請求するのにメーリングリスト beepwg@lists.beepcore.org を使用しなければなりません。
11. Changes from RFC 3288
11. RFC3288からの変化
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つの実質的な方法でRFC3288[16]と異なっています: URL接頭語は、SOAPの異なった見解に対応するBEEPプロフィールのファミリーを養うために定義されます。 同様に、この広くなることを反映するためにセクション8.1、セクション8.3、およびセクション8.4におけるIANA登録証明書をアップデートします。
Support for W3C MTOM/XOP packaging has been added.
W3C MTOM/XOPパッケージのサポートは加えられます。
O'Tuathail & Rose Standards Track [Page 16] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[16ページ]RFC4227
A new section was added to discuss the distributed state machine of the Request-Response MEP.
新しいセクションは、Request-応答MEPの分配された州のマシンについて議論するために加えられました。
In non-substantive ways, a small number of typographical errors were corrected.
非実質的な方法で、少ない数の誤字が修正されました。
12. Acknowledgements
12. 承認
The authors gratefully acknowledge the contributions of: Christopher Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T. Fielding.
作者は感謝して以下の貢献を承諾します。 クリストファー・フェリー、ヒューストン・フランクリン、Alexeyメリニコフ、ビル工場、およびロイT.フィールディング。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[1] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、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.モロー、「バージョン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] ニールセン、H.、ハドリー、M.、モロー、J.、メンデルゾーン、N.、およびM.Gudgin、「バージョン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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[5] Baker, M. and M. Nottingham, "The "application/soap+xml" media
type", RFC 3902, September 2004.
[5] ベイカーとM.とM.ノッティンガム、「「+ アプリケーション/石鹸xml」メディアはタイプする」RFC3902、2004年9月。
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[6] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
O'Tuathail & Rose Standards Track [Page 17] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[17ページ]RFC4227
[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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、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)」、RFC2782(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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[13] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001.
2001年8月の[13] エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。
[14] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[14]、RFC3851、2004年7月。
13.2. Informative References
13.2. 有益な参照
[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.ローズ、「ブロックの広げることができるSimple Object Access Protocol(SOAP)を使用して、プロトコルを交換してください(鳴ってください)」、RFC3288、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.ワイナー、「Simple Object Access Protocol(SOAP)1.1インチ、W3Cは注意SOAP20000508に注意します、2000年5月。」
[18] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[18] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
[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 Uniform Resource Locator」、RFC2392、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.シェル、「HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation」RFC2557(1999年3月)。
O'Tuathail & Rose Standards Track [Page 18] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[18ページ]RFC4227
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]内容、および[19]のセクション3の規則を使用することで参照をつけられる下位の部品で送られるのを許容するかもしれない、(すなわち、どちらかを使用する、「満足している位置:」 「コンテントID:」 [20]か[21]ヘッダー、)、例えば。
MSG 1 2 . 278 657
Content-Type: multipart/related; boundary="MIME_boundary";
type=application/xml;
start="<claim061400a.xml@claiming-it.com>"
MSG1 2.278 657コンテントタイプ: 複合か関連する。 境界は「MIME_境界」と等しいです。 =アプリケーション/xmlをタイプしてください。 「= "<claim061400a.xml@claiming-it.com を始動してください、gt;、」
--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>
--_境界コンテントタイプをまねてください: アプリケーション/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>
xmlns: <--xmlバージョン='1.0'--><env: 封筒envが等しい、「 http://www.w3.org/2003/05/soap-envelope ">"。 </env: ヘッダー><はenvします: ボディー><theSignedForm hrefが「Cid: claim061400a.tiff@claiming-it.com 」/と等しい、gt。 </env: ボディー></env: 封筒>。
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>
--_境界コンテントタイプをまねてください: いさかいContent転送イメージ/コード化: 2進のコンテントID: <claim061400a.いさかい@claiming-it.com、>。
...binary TIFF image...
--MIME_boundary--
END
...2進のTIFFイメージ… --MIME_境界--終わってください。
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と一致しています、複合が「始め」パラメタを含んでいて、根の部分がaを含むことが強く勧められる、「コンテントID:」 ヘッダー。 ContentはaどんなにBEEPが幅8ビットの経路を提供するので「変形し」てもコード化を移します。(例えば、「base64"か「引用されて印刷可能」) 使用するべきではありません」。 MIME[9]が、「コンテントID」ヘッダーの値がグローバルにユニークであることを必要とすることにさらに注意してください。
O'Tuathail & Rose Standards Track [Page 19] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[19ページ]RFC4227
Authors' Addresses
作者のアドレス
Eamon O'Tuathail Clipcode.com 24 Thomastown Road Dun Laoghaire Dublin IE
Eamon O'Tuathail Clipcode.com24Thomastown道路ダンリアラダブリンIE
Phone: +353 1 2350 424 EMail: eamon.otuathail@clipcode.com URI: http://www.clipcode.com/
以下に電話をしてください。 +353 1 2350 424 メール: eamon.otuathail@clipcode.com ユリ: http://www.clipcode.com/
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
O'Tuathail & Rose Standards Track [Page 20] RFC 4227 Using SOAP in BEEP January 2006
2006年1月にビープ音にSOAPを使用するO'Tuathailとバラ標準化過程[20ページ]RFC4227
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
O'Tuathail & Rose Standards Track [Page 21]
O'Tuathailとバラ標準化過程[21ページ]
一覧
スポンサーリンク
