RFC3408 日本語訳
3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC)Profile. Z. Liu, K. Le. December 2002. (Format: TXT=14805 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Z. Liu Request for Comments: 3408 K. Le Category: Standards Track Nokia December 2002
コメントを求めるワーキンググループZ.リュウ要求をネットワークでつないでください: 3408年のK.Leカテゴリ: 標準化過程ノキア2002年12月
Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile
拡張リンクレイヤの双方向の信頼できるモード(R-モード)の無バイトサポートは(ROHC)が輪郭を描く体力を要しているヘッダー圧縮を促進しました。
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 defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242.
このドキュメントは2を超えてRFC3242で定義されていた状態でまた、無バイトプロフィールとして知られているリンクレイヤ補助RObust Header Compression(ROHC)プロフィールの追加モードを定義します。 無バイトヘッダー圧縮は、ただ一つの八重奏ROHCヘッダーがラジオのために次の、より高い固定パケットサイズにパケット声の流れを押し込むのを防ぐために存在しています。 それは広く配備されたあるより古い空気インタフェースで使用可能です。 このドキュメントはRFC3242のヘッダー圧縮のUnidirectional(U-モード)とBidirectional Optimistic(O-モード)モードに指定されたものにROHC Bidirectional Reliableモード(R-モード)のための無バイト操作を加えます。
1. Introduction
1. 序論
[RFC3242] defines a zero-byte solution for compression of IP/UDP/RTP packets only for Unidirectional (U-) and Bidirectional Optimistic (O-) modes [RFC3095]. The present specification extends the profile defined in [RFC3242] to provide zero-byte support for Bidirectional Reliable (R-) mode. This specification and [RFC3242] allow a header-free packet format to be used in all modes to replace the majority of the 1-octet headers of ROHC RTP packets sent during normal operation. Specifically, the compressor operating in R-mode is allowed to deliver a No-Header Packet (NHP) when [RFC3242] would have required it to deliver a ROHC Reliable Packet Type Zero (R-0) packet [RFC3095].
[RFC3242]はUnidirectional(U)とBidirectional Optimistic(O)モード[RFC3095]のためだけにIP/UDP/RTPパケットの圧縮の無バイト解決策を定義します。 現在の仕様はBidirectional Reliable(R)モードの無バイトサポートを提供するために[RFC3242]で定義されたプロフィールを広げています。 この仕様と[RFC3242]は、無ヘッダーのパケット・フォーマットがROHC RTPパケットのヘッダーが通常の操作の間に送った1八重奏の大部分を取り替えるのにすべてのモードで使用されるのを許容します。 [RFC3242]がROHC Reliable Packet Type Zero(R-0)パケット[RFC3095]を届けるためにそれを必要としただろうというとき、明確に、R-モードで作動するコンプレッサーはヘッダーがないPacket(NHP)を届けることができます。
Liu & Le Standards Track [Page 1] RFC 3408 0-byte Support for R-mode December 2002
リュウとLe規格は2002年12月にR-モードのRFC3408の0バイトのサポートを追跡します[1ページ]。
For simplification, this profile is defined in the form of the additions and exceptions to [RFC3242] that are required to extend the RFC 3242 profile with zero-byte support for R-mode. All terminology used in this document is the same as in [RFC3242].
簡素化において、このプロフィールはR-モードの無バイトサポートでRFC3242プロフィールを広げるのに必要である[RFC3242]への追加と例外の形で定義されます。 本書では使用されるすべての用語が[RFC3242]と同じです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. Extensions to the assisting layer (AL) interface
2. 補助層(AL)のインタフェースへの拡大
This section describes additions (some are optional) to the assisting layer interface as defined in [RFC3242, section 4.2].
このセクションは[RFC3242、セクション4.2]で定義されるように追加について補助層のインタフェースまで説明します(或るものは任意です)。
2.1. Additional parameters to the compressor to AL interface
2.1. ALへのコンプレッサーへの追加パラメタは連結します。
- Mode, indicating the mode in which the compressor is operating. The AL has slightly different logic depending on the mode value.
- コンプレッサーが作動しているモードを示すモード。 ALには、最頻値に依存するわずかに異なった論理があります。
- SN_ACKed, indicating the latest RTP SN that has been acknowledged. It is used only when Mode value = R-mode.
- SN_ACKed、最新のRTP SNを示して、それは承認されました。 Mode値がR-モードと等しいときにだけ、それは使用されています。
Note that these two parameters MUST always be attached to every packet delivered to the AL.
いつもALに届けられたあらゆるパケットにこれらの2つのパラメタを添付しなければならないことに注意してください。
2.2. Additional interface, assisting layer to compressor
2.2. コンプレッサーに層を補助する追加インタフェース
To improve the compression efficiency of this profile in some specific cases, e.g., when the AL operates in such a way that it often becomes unsafe to send NHPs, it is RECOMMENDED to implement this additional interface. Here, the word "unsafe" means that the compressor allows the AL to send NHP but the AL cannot guarantee that the RTP SN of the NHP will be correctly decompressed at the receiving side. The interface is used to carry update_request as described in section 3. Note that this interface is not required in the sense that the impossibility of implementing such an interface should not be an obstacle to implement this profile over a specific link.
例えば、ALがNHPsを送るのがしばしば危険になるような方法で作動するとき、いくつかの特定の場合における、このプロフィールの圧縮効率を高めるなら、それはこの追加インタフェースを実行するRECOMMENDEDです。 ここで、「危険である」という言葉は、ALがコンプレッサーでNHPを送ることができることを意味しますが、ALは、NHPのRTP SNが受信側で正しく減圧されるのを保証できません。 インタフェースは、セクション3で説明されるようにアップデート_要求を運ぶのに使用されます。 このインタフェースは特定のリンクの上にこのプロフィールを実行するのにそのようなインタフェースを実行する不可能が障害であるべきでないという意味で必要でないことに注意してください。
3. R-mode operation
3. R-モード操作
For the R-mode, this profile extends ROHC RTP by performing a mapping of the R-0 packet to the NHP packet. Note that R-0 is the only type of packets in R-mode that can be replaced with NHP.
R-モードのために、このプロフィールは、R-0パケットに関するマッピングをNHPパケットに実行することによって、ROHC RTPを広げています。 R-0がNHPに取り替えることができるR-モードで唯一のタイプのパケットであることに注意してください。
On the receiving side, the RTP SN of an NHP is determined by the decompressor as = SN_Ref_D + Offset_D, where SN_Ref_D is the RTP SN of the last update packet received by the decompressor, and Offset_D
受信側では、NHPのRTP SNが=SN_Ref+オフセットとして減圧装置で決定します。そこでは、SN_Refは減圧装置によって受け取られた、アップデートパケットのRTP SNと、Offsetです。
Liu & Le Standards Track [Page 2] RFC 3408 0-byte Support for R-mode December 2002
リュウとLe規格は2002年12月にR-モードのRFC3408の0バイトのサポートを追跡します[2ページ]。
the sequence number offset between the NHP and the last update packet. How to derive Offset_D depends on the implementation of this profile over a specific link technology and must be specified in the implementation document(s). For example, it can be calculated by counting the total number of non-context-updating packets (including NHPs) and packet loss indications received since the last successful context update. Alternatively, it can be derived using the link timing in the case where the linear mapping between RTP SN and link timing is maintained.
一連番号はNHPとアップデートパケットの間で相殺されました。 どうOffsetを引き出すかは特定のリンク技術の上でこのプロフィールの実現によって、実現ドキュメントで指定しなければなりません。 例えば、文脈をアップデートしないパケットの総数を数えることによって、それについて計算できるでしょう、そして、(NHPsを含んでいて)最近のうまくいっている文脈最新版以来パケット損失指摘は受信されました。 あるいはまた、RTP SNとリンクタイミングの間の線形写像が維持される場合にリンクタイミングを使用することでそれを引き出すことができます。
On the transmitting side, the AL follows the same rule defined in section 4.1.1 of [RFC3242] to determine whether it can send NHP or not, with one modification. That is, when the AL determines that it has become unsafe (see section 2.2) to send NHPs, the AL records the corresponding RTP SN as SN_break. Then it waits until the rule is satisfied again and SN_ACKed > SN_break before it resumes sending NHPs. The latter condition is essentially the counterpart of optimistic approach agreement [RFC3242, section 4.3] of U/O-mode which states that when the AL in U/O-mode determines it is unsafe to send NHP, it must send headers in the subsequent X packets, where X is some agreed number. There are two reasons for the difference: a) R-mode relies on acknowledgements to synchronize contexts, instead of optimistic approach principle as in U/O-mode; and b) R-0 packets do not update decompressor context while UO-0 packets do. To meet the condition SN_ACKed > SN_break, the AL can either wait passively for the compressor to send a context update packet (e.g., R-0-CRC triggered by 6-bit SN wrap-around), or send an update_request via the interface from AL to the compressor (section 2.2) to request the compressor to send a context updating packet. The update_request carries the last SN_break. Upon receiving an update_request, the compressor SHOULD use a context updating packet (e.g. R-0-CRC) when sending the next packet. Context updating packets are handled as in [RFC3095].
伝える側では、ALがそれがNHPを送ることができるかどうか決定するために.1セクション4.1[RFC3242]で定義された同じ規則に従います、1つの変更で。 _すなわち、ALが、SNとしてNHPs、AL記録に対応するRTP SNを送るのが危険に(セクション2.2を見ます)なったことを決定したら、壊れてください。 次に、規則が再び満たされるまで、待っています、そして、それの前のSN_ACKed>SN_中断はNHPsを送るのを再開します。 後者の状態は本質的にはO U/モードによるALが、NHPを送るのが危険であることを決定すると、その後のXパケットでヘッダーを送らなければならないと述べるO U/モードの楽観的なアプローチ協定[RFC3242、セクション4.3]の対応者です。そこでは、Xが何らかの同意された数です。 違いの2つの理由があります: a) R-モードは楽観的なアプローチ原則の代わりに文脈を同期させるようにO U/モードのように承認に依存します。 b) R-0パケットはUO-0パケットがアップデートしている間、減圧装置文脈をアップデートしません。 状態SN_ACKed>SN_中断を満たすために、ALは、コンプレッサーが文脈アップデートパケット(例えば6ビットのSN巻きつけて着るドレスによって引き起こされたR-0-CRC)を送るか、または文脈にパケットをアップデートさせるようコンプレッサーに要求するというALからコンプレッサー(セクション2.2)までのインタフェースを通したアップデート_要求を送るのを受け身に待つことができます。 アップデート_要求は最後のSN_中断を運びます。 アップデート_要求を受け取ると、コンプレッサーSHOULDは次のパケットを送るときパケット(例えば、R-0-CRC)をアップデートする文脈を使用します。 文脈アップデートパケットは[RFC3095]のように扱われます。
Note: the passive waiting as described above might take a long time in the worst case, during which NHPs cannot be sent. Therefore, sending update_request via the optional AL to compressor interface is RECOMMENDED to improve the worst case performance.
以下に注意してください。 上で説明される受け身の待ちはどのNHPsを送ることができないか間、最悪の場合には長くかかるかもしれません。 したがって、アップデート_を送って、コンプレッサーへの任意のAL経由でインタフェースがRECOMMENDEDであるよう要求して、最悪の場合性能を向上させてください。
Note: the update_request may be lost if the AL and compressor are at different locations and the channel between them is unreliable, but such a loss only delays the AL from resuming sending NHP. Therefore, how frequent the AL sends update_request is an implementation issue. For example, the AL may send one update_request for each packet it receives from the compressor until the conditions to send NHP are met.
以下に注意してください。 ALとコンプレッサーが別の場所にあって、それらの間のチャンネルが頼り無いなら、アップデート_要求は失われるかもしれませんが、NHPを送るのを再開するので、そのような損失はALを遅らせるだけです。 したがって、どのようにがALによく行くか。_が導入問題であるよう要求するアップデートを送ります。 例えば、NHPを送る条件が満たされるまで、ALはそれがコンプレッサーから受ける各パケットを求める1つのアップデート_要求を送るかもしれません。
Liu & Le Standards Track [Page 3] RFC 3408 0-byte Support for R-mode December 2002
リュウとLe規格は2002年12月にR-モードのRFC3408の0バイトのサポートを追跡します[3ページ]。
Note: as no CRC field is present in R-0 packets, only the function related to RTP SN and packet type identifier needs to be replaced. In addition, NHP packets and packet loss indications in R-mode do not update either the compressor or the decompressor context (as opposed to U/O-mode). Consequently, the secure reference principle [RFC3095, section 5.5] is not affected in any way and there is no loss of robustness in this profile compared to ROHC RTP.
以下に注意してください。 どんなCRC分野もR-0パケットに存在していないので、機能だけがRTP SNと取り替えられるべきパケットタイプ識別子の必要性に関係しました。 さらに、R-モードにおけるNHPパケットとパケット損失指摘はコンプレッサーか減圧装置文脈のどちらかをアップデートしません(O U/モードと対照的に)。 その結果、安全な参照原則[RFC3095、セクション5.5]は何らかの方法で影響を受けません、そして、ROHC RTPと比べて、このプロフィールには丈夫さの損失が全くありません。
4. Differences between R-mode and U/O-mode
4. R-モードとO U/モードの違い
This section clarifies some differences between R-mode and U/O-mode in this profile.
このセクションはこのプロフィールのR-モードとO U/モードのいくつかの違いをはっきりさせます。
a) CRC replacement Unlike U/O-mode, CRC replacement [RFC3242, section 3.3] is not an issue for R-mode since R-0 packets do not carry CRC field.
a) CRC交換O Unlike U/モード、R-0パケットがCRC野原を運ばないので、CRC交換[RFC3242、セクション3.3]はR-モードのための問題ではありません。
b) Periodic context verification For U/O-mode, periodic context verification [RFC3242, section 4.6] is RECOMMENDED to provide additional protection against damage propagation after CRC is replaced. For R-mode, since there is no CRC replacement (see above), no change to ROHC RTP is needed in this regard. In particular, R-mode has this feature naturally built-in, since the sending of R-0-CRC when 6-bit SN wraps around implicitly provides periodic context verification for R-mode.
b) 周期的な文脈検証O For U/モード、周期的な文脈検証[RFC3242、セクション4.6]はCRCを取り替えた後に損害伝播に対する追加保護を提供するRECOMMENDEDです。 R-モードにおいて、CRC交換が全くないので(上を見てください)、ROHC RTPへの変化は全くこの点で必要ではありません。 特に、R-モードでこの特徴は自然に内蔵になります、6ビットのSNがそれとなく巻きつけるとき、R-0-CRCの発信がR-モードのための周期的な文脈検証を提供するので。
c) CV-REQUEST option For the same reasons as above, the decompressor operating in R- mode SHOULD NOT send CV-REQUEST [RFC3242, section 4.5] to compressor. This is to avoid unnecessary overhead on the feedback channel.
c) 同じくらいが同じくらい上で推論するCV-REQUESTオプションFor、SHOULD NOTがコンプレッサーへのCV-REQUEST[RFC3242、セクション4.5]を送るRモードで作動する減圧装置。 これは、フィードバックチャンネルの上に不要なオーバーヘッドを避けるためのものです。
d) Context Check Packet (CCP) When CCP [RFC3242, section 4.1.3] is used, compressor operating in R-mode SHOULD set C-bit to 0 (zero) and not generate 7-bit CRC if computation cost at compressor and decompressor causes concern. The use of the CRC field in CCP to perform decompressor context verification is not critical in R-mode (see last note of section 3 and item b) above).
d) 文脈チェックパケット(CCP) CCP[RFC3242、セクション4.1.3]が使用されているとき、R-モードSHOULDでのコンプレッサー操作は、0(ゼロ)にC-ビットを設定して、コンプレッサーと減圧装置における計算費用が心配をかけるなら、7ビットのCRCを発生させません。 減圧装置文脈検証を実行するCCPにおけるCRC分野の使用はR-モードで批判的ではありません(上記をセクション3と項目b)の最後の注意見てください)。
e) Handling of Acknowledgements (ACKs) Special care in the realization of ACKs should be taken for R-mode implementations. It is RECOMMENDED to avoid the use of interspersed feedback packets [RFC3095, section 5.2.1] to carry ACK information. The reason is that interspersed feedback packets will interrupt the RTP SN sequencing and thus temporarily disable the sending of NHPs.
e) 承認(ACKs)の取り扱い ACKsの実現における特別な注意はR-モード実現に払われるべきです。 それはACK情報を運ぶために点在しているフィードバックパケット[RFC3095、セクション5.2.1]の使用を避けるRECOMMENDEDです。 理由は点在しているフィードバックパケットがRTP SN配列を中断して、その結果、一時NHPsの発信を無能にするということです。
Liu & Le Standards Track [Page 4] RFC 3408 0-byte Support for R-mode December 2002
リュウとLe規格は2002年12月にR-モードのRFC3408の0バイトのサポートを追跡します[4ページ]。
5. IANA Considerations
5. IANA問題
A ROHC profile identifier has been reserved by the IANA for the profile defined in this document (0x0105), where 0x0005 is the profile identifier assigned for LLA [RFC3242].
ROHCプロフィール識別子はこのドキュメント(0×0105)で定義されたプロフィールのためにIANAによって予約されました。そこでは、0×0005がLLA[RFC3242]のために割り当てられたプロフィール識別子です。
6. Security Considerations
6. セキュリティ問題
The security considerations of ROHC RTP [RFC3095, section 7] apply also to this document with one addition: in the case of a denial-of- service attack scenario where an intruder injects bogus CCP packets onto the link using random CRC values, the CRC check will fail for incorrect reasons at the decompressor side. This would obviously greatly reduce the advantages of ROHC and any extra efficiency provided by this profile due to unnecessary context invalidation, feedback messages and refresh packets. However, the same remarks related to the presence of such an intruder apply.
またROHC RTP[RFC3095、セクション7]の問題がこれに当てはまるセキュリティは1で添加を記録します: -不正確な理由で、侵入者が無作為のCRC値を使用することでにせのCCPパケットをリンクに注入するところでサービス攻撃シナリオでは、CRCチェックが減圧装置で失敗するという否定の場合では、面があってください。 これは、不要な文脈無効にするフィードバックメッセージのためROHCの利点とこのプロフィールによって提供されたどんな余分な効率も大いに明らかに減少させて、パケットをリフレッシュするでしょう。 しかしながら、そのような侵入者の存在に関連する同じ所見は適用されます。
7. Acknowledgements
7. 承認
The authors would like to thank Lars-Erik Jonsson and Ghyslain Pelletier for intriguing discussions on LLA that helped to nail down the R-mode operation. The authors also appreciate valuable input from Carsten Bormann, Christopher Clanton, Mark Cheng, and Thinh Nguyenphu.
作者は、R-モード操作を縛り付けるのを助けたLLAについての議論の好奇心をそそって頂いて、ラース-エリック・イェンソンとGhyslainペレティアに感謝したがっています。 また、作者はカルステン・ボルマン、クリストファーClanton、マーク・チェン、およびThinh Nguyenphuからの貴重な入力に感謝します。
8. References
8. 参照
[RFC3242] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[RFC3242] イェンソン、L.、およびG.ペレティア、「体力を要しているヘッダー圧縮(ROHC):」 「リンクレイヤはIP/UDP/RTPのためにプロフィールを補助した」RFC3242、2002年4月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
Liu & Le Standards Track [Page 5] RFC 3408 0-byte Support for R-mode December 2002
リュウとLe規格は2002年12月にR-モードのRFC3408の0バイトのサポートを追跡します[5ページ]。
9. Authors' Addresses
9. 作者のアドレス
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
ZhigangリュウノキアResearch Center6000接続Driveテキサス75039アービング(米国)
Phone: +1 972 894-5935 Fax: +1 972 894-4589 EMail zhigang.c.liu@nokia.com
以下に電話をしてください。 +1 972 894-5935Fax: +1 972 894-4589 zhigang.c.liu@nokia.com にメールしてください。
Khiem Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
Khiem Leノキアリサーチセンター6000接続Driveテキサス75039アービング(米国)
Phone: +1 972 894-4882 Fax: +1 972 894-4589 EMail: khiem.le@nokia.com
以下に電話をしてください。 +1 972 894-4882Fax: +1 972 894-4589 メールしてください: khiem.le@nokia.com
Liu & Le Standards Track [Page 6] RFC 3408 0-byte Support for R-mode December 2002
リュウとLe規格は2002年12月にR-モードのRFC3408の0バイトのサポートを追跡します[6ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Liu & Le Standards Track [Page 7]
リュウとLe標準化過程[7ページ]
一覧
スポンサーリンク