RFC3420 日本語訳
3420 Internet Media Type message/sipfrag. R. Sparks. November 2002. (Format: TXT=14745 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Sparks Request for Comments: 3420 dynamicsoft Category: Standards Track November 2002
スパークがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3420dynamicsoft Category: 標準化過程2002年11月
Internet Media Type message/sipfrag
インターネットメディアTypeメッセージ/sipfrag
Status of this Memo
この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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request.
このドキュメントはメッセージ/sipfragマルチパーパスインターネットメールエクステンション(MIME)メディアタイプを示します。 このタイプは、メッセージ/一口と同様ですが、完全なSIPメッセージを必要とすることの代わりに表されるべきよく形成されたSession Initiationプロトコル(SIP)メッセージのある部分集合を許容します。 終わりから終わりへのセキュリティ用途に加えて、メッセージ/sipfragは参照をつけられた要求の状態の周りで情報を伝達するREFER方法で使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition: message/sipfrag . . . . . . . . . . . . . . . . . 2
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Valid message/sipfrag parts . . . . . . . . . . . . . . . 3
3.2 Invalid message/sipfrag parts . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . . 7
Non-Normative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 定義: メッセージ/sipfrag.2 3。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1のValidメッセージ/sipfragパート. . . . . . . . . . . . . . . 3 3.2Invalidメッセージ/sipfragパート. . . . . . . . . . . . . . 4 4。 議論. . . . . . . . . . . . . . . . . . . . . . . . . . 5 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . 6 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 6引用規格. . . . . . . . . . . . . . . . . . . . . 7非引用規格.7作者のアドレスの.7の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 8
Sparks Standards Track [Page 1] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[1ページ]RFC3420をかきたてます。
1. Introduction
1. 序論
The message/sip MIME media type defined in [1] carries an entire well formed SIP message. Section 23.4 of [1] describes the use of message/sip in concert with S/MIME to enhance end-to-end security. The concepts in that section can be extended to allow SIP entities to make assertions about a subset of a SIP message (for example, as described in [6]). The message/sipfrag type defined in this document is used to represent this subset.
[1]で定義されたメッセージ/一口MIMEメディアタイプはよく形成された全体のSIPメッセージを伝えます。 [1]のセクション23.4は、S/MIMEと協力して終わりから終わりへのセキュリティを高めるためにメッセージ/一口の使用について説明します。 SIP実体がSIPメッセージの部分集合に関して主張をするのを許容するためにそのセクションの概念について敷衍できます。(例えば[6])で説明されるように。 本書では定義されたメッセージ/sipfragタイプは、この部分集合を表すのに使用されます。
A subset of a SIP message is also used by the REFER method defined in [5] to carry the status of referenced requests. Allowing only a portion of a SIP message to be carried allows information that could compromise privacy and confidentiality to be protected by removal.
また、SIPメッセージの部分集合は参照をつけられた要求の状態を運ぶために[5]で定義されたREFER方法で使用されます。 運ばれるべきSIPメッセージの部分だけを許容するのは、プライバシーと秘密性で妥協できた情報が取り外しで保護されるのを許容します。
This document does NOT provide a mechanism to segment a SIP message into multiple pieces for separate transport and later reassemble. The message/partial type defined in [2] provides a solution for that problem.
このドキュメントは、倍数へのSIPメッセージが別々の輸送のためにつなぎあわせるセグメントにメカニズムを提供して、後で組み立て直されません。 [2]で定義されたメッセージ/部分的なタイプはその問題の解決法を提供します。
The key words "MUST", "MUST NOT", REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMEND", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4].
「キーワード“MUST"、「必須NOT」が必要です」、“SHALL"、「」、“SHOULD"、「」、「推薦」、「5月」、および「任意」のコネは[4]で説明されるように解釈されるこれが、記録することであるべきです。
2. Definition: message/sipfrag
2. 定義: メッセージ/sipfrag
A valid message/sipfrag part is one that could be obtained by starting with some valid SIP message and deleting any of the following:
有効なメッセージ/sipfrag部分は何らかの有効なSIPメッセージから始まって、以下のどれかを削除することによって得ることができるだろうものです:
o the entire start line
o 全体のスタート線
o one or more entire header fields
o 1つ以上の全体のヘッダーフィールド
o the body
o ボディー
The following Augmented Backus-Naur Form (ABNF) [3] rule describes a message/sipfrag part using the SIP grammar elements defined in [1]. The expansion of any element is subject to the restrictions on valid SIP messages defined there.
以下のAugmented BN記法(ABNF)[3]規則は、[1]で定義されたSIP文法要素を使用することでメッセージ/sipfrag部分について説明します。 どんな要素の膨張もそこで定義された有効なSIPメッセージにおける制限を受けることがあります。
sipfrag = [ start-line ]
*message-header
[ CRLF [ message-body ] ]
sipfragは*メッセージヘッダーと等しいです[スタート線]。[CRLF[メッセージ本体]]
Sparks Standards Track [Page 2] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[2ページ]RFC3420をかきたてます。
If the message/sipfrag part contains a body, it MUST also contain the appropriate header fields describing that body (such as Content- Length) as required by Section 7.4 of [1] and the null-line separating the header from the body.
また、メッセージ/sipfrag部分がボディーを含んでいるなら、それは必要に応じて、ボディーからヘッダーを分離しながら[1]のセクション7.4と空行でそのボディー(Contentの長さなどの)について説明する適切なヘッダーフィールドを含まなければなりません。
3. Examples
3. 例
3.1 Valid message/sipfrag parts
3.1 有効なメッセージ/sipfragの部品
This section uses a vertical bar and a space to the left of each example to illustrate the example's extent. Each line of the message/sipfrag element begins with the first character after the "|" pair.
このセクションは縦棒とスペースを例の範囲を例証するそれぞれの例の左まで使用します。 「メッセージ/sipfrag要素の各線が最初のキャラクタと共に始まった後、」|「対にしてください。」
The first two examples show that a message/sipfrag part can consist of only a start line.
最初の2つの例が、メッセージ/sipfrag部分がスタート線だけから成ることができるのを示します。
| INVITE sip:alice@atlanta.com SIP/2.0
or
| SIP/2.0 603 Declined
または| INVITE一口: alice@atlanta.com SIP/2.0。| 一口/2.0 603は減退しました。
The next two show that Subsets of a full SIP message may be represented.
次の2は、完全なSIPメッセージのSubsetsが表されるかもしれないのを示します。
| REGISTER sip:atlanta.com SIP/2.0
| To: sip:alice@atlanta.com
| Contact: <sip:alicepc@atlanta.com>;q=0.9,
| <sip:alicemobile@atlanta.com>;q=0.1
| REGISTER一口: atlanta.com SIP/2.0| To: 一口: alice@atlanta.com | 接触: <一口: alicepc@atlanta.com 、gt;、; q=0.9| <一口: alicemobile@atlanta.com 、gt;、;、q=0.1
| SIP/2.0 400 Bad Request
| Warning: 399 atlanta.com Your Event header field was malformed
| 一口/2.0 400の悪い要求| 警告: 399 atlanta.com Your Eventヘッダーフィールドは奇形でした。
A message/sipfrag part does not have to contain a start line. This example shows a part that might be signed to make assertions about a particular message. (See [6].)
メッセージ/sipfrag部分はスタート線を含む必要はありません。 この例は特定のメッセージに関して主張をするようにサインされるかもしれない部分を示しています。 ([6]を見てください。)
| From: Alice <sip:alice@atlanta.com>
| To: Bob <sip:bob@biloxi.com>
| Contact: <sip:alice@pc33.atlanta.com>
| Date: Thu, 21 Feb 2002 13:02:03 GMT
| Call-ID: a84b4c76e66710
| Cseq: 314159 INVITE
| From: アリス<一口: alice@atlanta.com 、gt。| To: ボブ<一口: bob@biloxi.com 、gt。| 接触: <一口: alice@pc33.atlanta.com 、gt。| 日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒| 呼び出しID: a84b4c76e66710| Cseq: 314159 招待
Sparks Standards Track [Page 3] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[3ページ]RFC3420をかきたてます。
The next two examples show message/sipfrag parts that contain bodies.
次の2つの例がボディーを含むメッセージ/sipfragの部品を示しています。
| SIP/2.0 200 OK
| Content-Type: application/sdp
| Content-Length: 247
|
| v=0
| o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
| s=
| c=IN IP4 host.anywhere.com
| t=0 0
| m=audio 49170 RTP/AVP 0
| a=rtpmap:0 PCMU/8000
| m=video 51372 RTP/AVP 31
| a=rtpmap:31 H261/90000
| m=video 53000 RTP/AVP 32
| a=rtpmap:32 MPV/90000
| 一口/2.0 200に、OK| コンテントタイプ: アプリケーション/sdp| コンテンツの長さ: 247 | | v=0| o=alice2890844526 2890844526IN IP4 host.anywhere.com| s=| cはIN IP4 host.anywhere.comと等しいです。| tは0 0と等しいです。| mはオーディオの49170RTP/AVP0と等しいです。| a=rtpmap: 0PCMU/8000| mはビデオ51372RTP/AVP31と等しいです。| a=rtpmap: 31H261/90000| mはビデオ53000RTP/AVP32と等しいです。| a=rtpmap: 32MPV/90000
| Content-Type: text/plain
| Content-Length: 11
|
| Hi There!
| コンテントタイプ: テキスト/平野| コンテンツの長さ: 11 | | やあ!
3.2 Invalid message/sipfrag parts
3.2 無効のメッセージ/sipfragの部品
This section uses the character "X" followed by a space to the left of each example to illustrate the example's extent. Each line of the invalid message/sipfrag element begins with the first character after the "X " pair.
このセクションはキャラクタ「X」を使用します、続いて、例の範囲を例証するそれぞれの例の左にスペースを使用します。 無効のメッセージ/sipfrag要素の各線は「X」組の後に最初のキャラクタと共に始まります。
The start line, if present, must be complete and valid per [1].
存在しているなら、スタート線は、完全であって、[1]単位で有効であるに違いありません。
X INVITE
X招待
X INVITE sip:alice@atlanta.com SIP/1.09
X INVITE一口: alice@atlanta.com SIP/1.09
X SIP/2.0
X一口/2.0
X 404 Not Found
見つけられなかったX404
All header fields must be valid per [1].
すべてのヘッダーフィールドが[1]単位で有効であるに違いありません。
X INVITE sip:alice@atlanta.com SIP/2.0
X Via: SIP/2.0/UDP ;branch=z9hG4bK29342a
X To: <>;tag=39234
X INVITE一口: alice@atlanta.com SIP/2.0X Via: 一口/2.0/UDP; ブランチ=z9hG4bK29342a X To: <>; タグ=39234
X To: sip:alice@atlanta.com
X From: sip:bob@biloxi.com;tag=1992312
X To: 一口: alice@atlanta.com X From: 一口: bob@biloxi.com;tag =1992312
Sparks Standards Track [Page 4] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[4ページ]RFC3420をかきたてます。
X Call-ID: this is invalid
X呼び出しID: これは無効です。
X INVITE sip:alice@atlanta.com SIP/2.0
X From: <sip:bob@biloxi.com>;tag=z9hG4bK2912;tag=z9hG4bK99234
X INVITE一口: alice@atlanta.com SIP/2.0X From: <一口: bob@biloxi.com 、gt;、;=z9hG4bK2912にタグ付けをしてください; =z9hG4bK99234にタグ付けをしてください
If a body is present in the message/sipfrag part, the headers required by Section 7.4 of [1] and the null-line separating the header from the body.
ボディーがメッセージ/sipfrag部分に存在しているなら、ヘッダーが[1]のセクション7.4とボディーからヘッダーを分離する空行が必要です。
X MESSAGE sip:alice@atlanta.com SIP/2.0
X Hi There!
X MESSAGE一口: alice@atlanta.com SIP/2.0X Hi There!
4. Discussion
4. 議論
Section 23 of [1], and memos [5] and [6] provide motivation and detailed examples of carrying all or part of a SIP message in a MIME part. Briefly, using this representation along with S/MIME enables protecting and making assertions about portions of a SIP message header. It also enables applications to describe the messaging involved in a SIP transaction using portions of the messages themselves.
[1]のセクション23、メモ[5]、および[6]はすべてを運ぶ動機と詳細な例かSIPメッセージの一部をMIME部分に提供します。 簡潔に、S/MIMEに伴うこの表現を使用すると、保護と作成主張はSIPメッセージヘッダーの一部に関して可能にされます。 また、それは、アプリケーションがメッセージ自体の部分を使用することでSIP取引にかかわるメッセージングについて説明するのを可能にします。
The SIP REFER method [5], for instance, uses this to report the result of a SIP request to an authorized third party. However, as that document details, it is rarely desirable to include the entire SIP response message in this report as a message/sip MIME part. Doing so has significant negative security implications. The message/sipfrag type, on the other hand, allows a sender to select what information is exposed. Further, it allows information required in a full SIP message that is not pertinent to a description of that message to be elided, reducing message size. For instance, this allows a SIP element responding to a REFER to say "I got a 400 Bad Request with this Warning header field" without having to include the Via, To, From, Call-ID, CSeq and Content-Length header fields mandatory in a full SIP message.
例えば、SIP REFER方法[5]は、SIP要求の結果を認可された第三者に報告するのにこれを使用します。 しかしながら、それが詳細を記録するので、メッセージ/一口MIME部分としてこのレポートに全体のSIP応答メッセージを含んでいるのはめったに望ましくはありません。 そうするのにおいて、重要な否定的セキュリティ意味があります。 他方では、メッセージ/sipfragタイプはどんな情報が露出されているかを送付者を選択させます。 さらに、その削除されるべきメッセージの記述に適切でない完全なSIPメッセージで必要である情報を許容します、メッセージサイズを減少させて。 例えば、Via(完全なSIPメッセージで義務的なTo、From、Call-ID、CSeq、およびContent-長さのヘッダーフィールド)を含む必要はなくて、これは「私はこのWarningヘッダーフィールドがある400Bad Requestを手に入れました」と言うためにREFERに応じるSIP要素を許容します。
The message protection mechanism discussed in Section 23 of [1] assumes an entire SIP message is being protected. However, there are several header fields in a full SIP message that necessarily change during transport. [1] discusses how to inspect and ignore those changes. This idea is refined in [6] to allow protection of a subset of the entire message, avoiding the extra work and potential errors involved in ignoring parts of the message that may legitimately change in transit. That document also describes constructing cryptographic assertions about pertinent subsets of a SIP message header before the full header (including hop-by-hop transport specific information) may be available.
[1]のセクション23で議論したメッセージ保護メカニズムは、全体のSIPメッセージが保護されていると仮定します。 しかしながら、完全なSIPメッセージの必ず輸送の間に変化するいくつかのヘッダーフィールドがあります。 [1]はどのようにそれらの変化を点検して、無視するかを議論します。 この考えは全体のメッセージの部分集合の保護を許すために[6]で洗練されます、トランジットで合法的に変化するかもしれないメッセージの部分を無視するのにかかわる時間外労働と潜在的誤りを避けて。 また、そのドキュメントは、完全なヘッダー(ホップごとの輸送特殊情報を含んでいる)が手があくかもしれない前にSIPメッセージヘッダーの適切な部分集合に関して暗号の主張を構成すると説明します。
Sparks Standards Track [Page 5] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[5ページ]RFC3420をかきたてます。
5. IANA Considerations
5. IANA問題
The message/sipfrag media type is defined by the following information:
メッセージ/sipfragメディアタイプは以下の情報によって定義されます:
Media type name: message
Media subtype name: sipfrag
Required parameters: none
Optional parameters: version
Version: The SIP-Version number of the enclosed message (e.g.,
"2.0"). If not present, the version defaults to "2.0".
Encoding scheme: SIP messages consist of an 8-bit header optionally
followed by a binary MIME data object. As such, SIP messages must
be treated as binary. Under normal circumstances SIP messages are
transported over binary-capable transports, no special encodings
are needed.
Security considerations: see below
メディア型名: メッセージメディア「副-タイプ」名: sipfrag Requiredパラメタ: なにも、Optionalパラメタ: バージョンバージョン: 同封のメッセージのSIP-バージョン番号、(例えば、「2インチ)」 プレゼントでないなら、バージョンは「2インチ」をデフォルトとします。 コード化計画: SIPメッセージは2進のMIMEデータ・オブジェクトが任意に支えた8ビットのヘッダーから成ります。 そういうものとして、SIPメッセージをバイナリーとして扱わなければなりません。 通常の状況下でSIPメッセージは2進にできる輸送の上で輸送されて、どんな特別なencodingsも必要ではありません。 セキュリティ問題: 以下を見てください。
6. Security Considerations
6. セキュリティ問題
A message/sipfrag mime-part may contain sensitive information or information used to affect processing decisions at the receiver. When exposing that information or modifying it during transport would do harm, its level of protection can be improved using the S/MIME mechanisms described in section 23 of [1], with the limitations described in section 26 of that document, and the mechanisms described in [6].
sipfragパントマイムメッセージ/部分が機密情報を含むかもしれませんか、または情報は受信機で処理決定に影響していました。それを露出するとき、情報か輸送の間、それを変更するのに危害を加えて、[1]のセクション23で説明されたS/MIMEメカニズムを使用することで保護のレベルは改良できます、制限がそのドキュメントのセクション26で説明されて、メカニズムが[6]で説明されている状態で。
Applications using message/sipfrag to represent a subset of the header fields from a SIP message must consider the implications of the message/sipfrag part being captured and replayed and include sufficient information to mitigate risk. Any SIP extension which uses message/sipfrag MUST describe the replay and cut and paste threats unique to its particular usage. For example, [6] discusses how a subset of a SIP message can be used to assert the identity of the entity making a SIP request. The draft details what information must be contained in the subset to bind the assertion to the request.
SIPメッセージからヘッダーフィールドの部分集合を表すメッセージ/sipfragを使用するアプリケーションは、危険を緩和するために十分な情報を得られるメッセージ/sipfrag部分の含意を考えて、再演して、含まなければなりません。 メッセージ/sipfragを使用するどんなSIP拡張子も特定の用法にユニークな再生とカットアンドペーストの脅威について説明しなければなりません。 例えば、[6]はSIP要求をする実体のアイデンティティについて断言するのにどうSIPメッセージの部分集合を使用できるかについて議論します。 草稿は、要求に主張を縛るために部分集合にどんな情報を含まなければならないかを詳しく述べます。
Sparks Standards Track [Page 6] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[6ページ]RFC3420をかきたてます。
Normative References
引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3265, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3265、2002年6月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[2]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Non-Normative References
非引用規格
[5] Sparks, R., "The SIP Refer Method", Work in Progress.
[5] R.、「一口は方法を参照する」というスパークが進行中で働いています。
[6] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Work in
Progress.
[6] ピーターソン、J.、「セッション開始プロトコル(一口)における認証されたアイデンティティ管理のための増進」が進行中で働いています。
Author's Address
作者のアドレス
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
プラノ、ロバートJ.スパークスdynamicsoft5100テニソンパークウェイSuite1200テキサス 75024
EMail: rsparks@dynamicsoft.com
メール: rsparks@dynamicsoft.com
Sparks Standards Track [Page 7] RFC 3420 Internet Media Type message/ipfrag November 2002
インターネットメディアTypeメッセージ/ipfrag2002年11月にStandards Track[7ページ]RFC3420をかきたてます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sparks Standards Track [Page 8]
標準化過程をかきたてます。[8ページ]
一覧
スポンサーリンク
