RFC4077 日本語訳
4077 A Negative Acknowledgement Mechanism for Signaling Compression.A.B. Roach. May 2005. (Format: TXT=34250 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A.B. Roach Request for Comments: 4077 Estacado Systems Category: Standards Track May 2005
コメントを求めるワーキンググループA.B.ローチ要求をネットワークでつないでください: 4077年のエスタカードシステムカテゴリ: 標準化過程2005年5月
A Negative Acknowledgement Mechanism for Signaling Compression
シグナリング圧縮のための否定的承認メカニズム
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations.
このドキュメントはSignaling Compression(SigComp)実装が減圧できないメッセージを受け取り次第正確なエラー情報を報告できるメカニズムについて説明します。 受取人はそれを再送する前にきめ細かに粒状の調整を圧縮されたメッセージにするのにこの負のフィードバックを使用できます、エラー状態からの急速で効率的な回復を考慮して。
Roach Standards Track [Page 1] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
1.1. The Problem ................................................2
1.1.1. Compartment Disposal ................................3
1.1.2. Client Restart ......................................3
1.1.3. Server Failover .....................................3
1.2. The Solution ...............................................4
2. Node Behavior ...................................................4
2.1. Normal SigComp Message Transmission ........................4
2.2. Receiving a "Bad" SigComp Message ..........................5
2.3. Receiving a SigComp NACK ...................................6
2.3.1. Unreliable Transport ................................6
2.3.2. Reliable Transport ..................................6
2.4. Detecting Support for NACK .................................7
3. Message Format ..................................................7
3.1. Message Fields .............................................8
3.2. Reason Codes ...............................................9
4. Security Considerations ........................................13
4.1. Reflector Attacks .........................................13
4.2. NACK Spoofing .............................................13
5. IANA Considerations ............................................14
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
1. 序論…2 1.1. 問題…2 1.1.1. コンパートメント処分…3 1.1.2. クライアント再開…3 1.1.3. サーバフェイルオーバー…3 1.2. ソリューション…4 2. ノードの振舞い…4 2.1. 通常のSigCompメッセージ送信…4 2.2. 「悪い」SigCompメッセージを受け取ります…5 2.3. SigCompナックを受けます…6 2.3.1. 頼り無い輸送…6 2.3.2. 信頼できる輸送…6 2.4. ナックのサポートを検出します…7 3. メッセージ形式…7 3.1. メッセージ分野…8 3.2. コードを推論してください…9 4. セキュリティ問題…13 4.1. 反射鏡は攻撃されます…13 4.2. ナックSpoofing…13 5. IANA問題…14 6. 承認…14 7. 参照…14 7.1. 標準の参照…14 7.2. 有益な参照…14
1. Introduction
1. 序論
Signaling Compression [1], often called "SigComp", defines a protocol for transportation of compressed messages between two network elements. One of the key features of SigComp is the ability of the sending node to request that the receiving node store state objects for later retrieval.
しばしば"SigComp"と呼ばれたシグナリングCompression[1]は2つのネットワーク要素の間の圧縮されたメッセージの輸送のためにプロトコルを定義します。 SigCompに関する重要な特色の1つは送付ノードが、受信ノードが後の検索のために州のオブジェクトを保存するよう要求する能力です。
1.1. The Problem
1.1. 問題
While the "SigComp - Extended Operations" document [2] defines a mechanism that allows for confirmation of state creation, operational experience with the SigComp protocol has demonstrated that there are still several circumstances in which a sender's view of the shared state differs from the receiver's view. A non-exhaustive list detailing the circumstances in which such failures may occur is below.
「SigComp--操作を広げている」ドキュメント[2]はそれが州の作成の確認のために許容するメカニズムを定義しますが、SigCompプロトコルの運用経験は、送付者の共有された状態の視点が受信機の視点と異なっているまだいくつかの事情があるのを示しました。 そのような失敗が起こるかもしれない事情を詳しく述べる非完全なりストが以下にあります。
Roach Standards Track [Page 2] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[2ページ]。
1.1.1. Compartment Disposal
1.1.1. コンパートメント処分
In SigComp, stored states are associated with compartments. Conceptually, the compartments represent one instance of a remote application. These compartments are used to limit the amount of state that each remote application is allowed to store. Compartments are created upon receipt of a valid SigComp message from a remote application. In the current protocol, applications are expected to signal when they are finished with a compartment so that it can be deleted (by using the S-bit in requested feedback data).
SigCompでは、保存された州はコンパートメントに関連しています。 概念的に、コンパートメントはリモートアプリケーションの1つのインスタンスを表します。 これらのコンパートメントは、それぞれのリモートアプリケーションが保存できる状態の量を制限するのに使用されます。 コンパートメントはリモートアプリケーションからの有効なSigCompメッセージを受け取り次第作成されます。 現在のプロトコルでは、それを削除できる(要求されたフィードバックデータでS-ビットを使用することによって)ようにコンパートメントで終わっているとき、アプリケーションが合図すると予想されます。
Unfortunately, expecting the applications to be well-behaved is not sufficient to prevent state from piling up. Unexpected client failures, reboots, and loss of connectivity can cause compartments to become "stuck" and never removed. To prevent this situation, it becomes necessary to implement a scheme by which compartments that appear disused may eventually be discarded.
残念ながら、アプリケーションが品行方正であると予想するのは、状態が積もるのを防ぐために十分ではありません。 接続性の予期していなかったクライアント失敗、リブート、および損失によって、コンパートメントは「張り付け」て、決して取り除かないようになることができます。 この状況を防ぐために、不要であるように見えるコンパートメントが結局捨てられるかもしれない体系を実装するのは必要になります。
While the preceding facts make such a practice necessary, discarding compartments without explicit signaling can have the unfortunate side effect that active compartments are sometimes discarded. This leads to a different view of state between the server and the client.
そのような習慣が前の事実で必要になっている間、明白なシグナリングなしでコンパートメントを捨てると、捨てられて、時々アクティブなコンパートメントがそうである不幸な副作用を持つことができます。 これはサーバとクライアントの間の状態の異なった視点に通じます。
1.1.2. Client Restart
1.1.2. クライアント再開
The prime motivation for SigComp was compression of messages to be sent over a radio interface. Consequently, most deployments of SigComp will involve a mobile unit as one of the endpoints. Mobile terminals are generally not guaranteed to be available for extended durations of time. Node restarts (due to, for example, a battery running out) will induce situations in which the network-based server believes that the client contains several states that are no longer actually available.
SigCompに関する主要な動機はラジオインタフェースの上に送られるべきメッセージの要約でした。 その結果、SigCompのほとんどの展開が終点の1つとして機動隊にかかわるでしょう。 一般に、移動体端末は、時間の拡張持続時間に利用可能になるように保証されません。 ノード再開(例えばなくなるバッテリーによる)はネットワークベースのサーバが、クライアントがいくつかの実際にもう利用可能でない州を含むと信じている状況を引き起こすでしょう。
1.1.3. Server Failover
1.1.3. サーバフェイルオーバー
Many applications for which SigComp will be used (e.g., SIP [3]) use DNS SRV records for server lookup. One of the important features of DNS SRV records is the ability to specify multiple servers from which clients will select at random, with probabilities determined by the q-value weighting. The reason for defining this behavior for SRV records is to allow load distribution through a set of equivalent servers, and to permit clients to continue to function even if the server with which they are communicating fails. When using protocols that use SRV for such distribution, the traffic to a failed server is typically sent by the client to an equivalent server that can serve
どのSigCompが使用されるだろうか。多くのアプリケーション、(例えば、SIP[3])はサーバルックアップにDNS SRV記録を使用します。 DNS SRV記録の重要な特徴の1つはクライアントが無作為に選択する複数のサーバを指定する能力です、q-値の重さによって決定している確率で。 SRV記録のためのこの振舞いを定義する理由は、彼らが交信する予定であるサーバが失敗しても、1セットの同等なサーバに負荷分配の通ることを許して、クライアントが、機能し続けているのを許容することです。 そのような分配にSRVを使用するプロトコルを使用するとき、失敗したサーバへのトラフィックはクライアントによって役立つことができる同等なサーバに通常送られます。
Roach Standards Track [Page 3] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[3ページ]。
the same purpose. From an application perspective, this new server often appears to be the same endpoint as the failed server, and will consequently resolve to the same compartment.
同じ目的。 アプリケーション見解から、この新しいサーバは失敗したサーバと同じ終点であり、その結果、同じコンパートメントに決心を望んでいるようにしばしば見えます。
Although SigComp state can be replicated amongst such a cluster of servers, maintaining integrity of such states requires a two-phase commit process that adds a great deal of complexity to the server and can degrade performance significantly.
サーバのそのようなクラスタの中でSigComp状態を模写できますが、そのような州の保全が二相を必要とすると主張して、多くの複雑さをサーバに追加して、性能をかなり下げることができるプロセスを、遂行してください。
1.2. The Solution
1.2. ソリューション
Although SigComp allows returned SigComp parameters to signal that all states have been lost (by setting "state_memory_size" to 0 for one message in the reverse direction), such an approach provides an incomplete solution to the problem. In addition to wiping out an entire compartment when only one state is corrupt or missing, this approach suffers from the unfortunate behavior that it requires a message in the reverse direction that the remote application will authorize. Unless a lower-layer security mechanism is employed (e.g., TLS), this would typically mean that a compressed application-level message in the reverse direction must be sent before recovery can occur. In many cases (such as SIP-based mobile terminals), these messages won't be sent often; in others (pure client/server deployments), they won't ever be sent.
SigCompはすべての州が失われたのを(反対の方向による1つのメッセージのために「状態_メモリ_サイズ」を0に設定することによって)返されたSigCompパラメタを示させますが、そのようなアプローチは不完全な解決法を問題に提供します。 1つの州だけが不正であるか、またはなくなります、このアプローチが不幸な振舞いからそれを受けるということであるときに全体のコンパートメントを破壊することに加えて、それはリモートアプリケーションが認可する反対の方向によるメッセージを必要とします。 下層セキュリティー対策が採用していない場合(例えば、TLS)、これは、回復が起こることができる前に反対の方向による圧縮されたアプリケーションレベルメッセージを送らなければならないことを通常意味するでしょう。 多くの場合(SIPベースの移動体端末などの)では、しばしばこれらのメッセージを送るというわけではないでしょう。 他のもの(純粋なクライアント/サーバ展開)では、それらはかつて、送られないでしょう。
The proposed solution to this problem is a simple Negative Acknowledgement (NACK) mechanism which allows the recipient to communicate to the sender that a failure has occurred. This NACK contains a reason code that communicates the nature of the failure. For certain types of failures, the NACK will also contain additional details that might be useful in recovering from the failure.
この問題への提案された解決は受取人が失敗が起こるようにする送付者に交信できる簡単なNegative Acknowledgement(ナック)メカニズムです。 このナックは失敗の本質を伝える理由コードを含みます。 あるタイプの失敗によって、また、ナックは失敗から回復する際に役に立つかもしれない追加詳細を含むでしょう。
2. Node Behavior
2. ノードの振舞い
The following sections detail the behavior of nodes sending and receiving SigComp NACKs. The actual format and values are described in Section 3.
以下のセクションはノード送受信SigComp NACKsの動きを詳しく述べます。 実際の形式と値はセクション3で説明されます。
2.1. Normal SigComp Message Transmission
2.1. 通常のSigCompメッセージ送信
Although normal in all other respects, SigComp implementations that use the NACK mechanism need to calculate and store a SHA-1 hash for each SigComp message that they send. This must be stored in such a way that, given the SHA-1 hash, the implementation is able to locate the compartment with which the sent message was associated.
他のすべての点で正常ですが、ナックメカニズムを使用するSigComp実装は、発信するというそれぞれのSigCompメッセージのためにSHA-1ハッシュを計算して、保存する必要があります。 SHA-1ハッシュを考えて、実装が送信されたメッセージが関連していたコンパートメントの場所を見つけることができるような方法でこれを保存しなければなりません。
Roach Standards Track [Page 4] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[4ページ]。
In other words, if someone hands the SHA-1 hash back to the compressor, it needs to be able to find the compartment with which it was working when it sent the message with that hash. This only requires that the compressor knows with which compartment it is working when it sends a message (which is always the case), and that the SHA-1 hash, when stored, points to that compartment in some way.
言い換えれば、だれかがSHA-1ハッシュをコンプレッサーに返すなら、それは、そのハッシュでメッセージを送ったときそれが働いていたコンパートメントを見つけることができる必要があります。 これは、コンプレッサーが、それが扱っているどのコンパートメントでそれがいつメッセージ(いつもケースである)を送るかを知るか、そして、保存されるとSHA-1ハッシュが何らかの方法でそのコンパートメントを示すのを必要とするだけです。
2.2. Receiving a "Bad" SigComp Message
2.2. 「悪い」SigCompメッセージを受け取ります。
When a received SigComp message causes a decompression failure, the recipient forms and sends a SigComp NACK message. This NACK message contains a SHA-1 hash of the received SigComp message that could not be decompressed. It also contains the exact reason decompression failed, as well as any additional details that might assist the NACK recipient to correct any problems. See Section 3 for more information about formatting the NACK message and its fields.
受信されたSigCompメッセージが減圧失敗を引き起こすと、受取人は、SigCompナックメッセージを形成して、送ります。 このナックメッセージは減圧できなかった受信されたSigCompメッセージのSHA-1ハッシュを含んでいます。 また、それはナック受取人がどんな問題も修正するのを補助するかもしれないどんな追加詳細と同様に失敗された正確な理由減圧を含んでいます。ナックメッセージとその分野をフォーマットすることに関する詳しい情報に関してセクション3を見てください。
For a connection-oriented transport, such as TCP, the NACK message is sent back to the originator of the failed message over that same connection.
TCPなどの接続指向の輸送において、ナックメッセージはその同じ接続の上の失敗したメッセージの創始者に送り返されます。
For a stream-based transport, such as TCP, the standard SigComp delimiter of 0xFFFF is used to terminate the NACK message.
TCPなどのストリームベースの輸送において、0xFFFFの標準のSigCompデリミタは、ナックメッセージを終えるのに使用されます。
For a connectionless transport, such as UDP, the NACK message is sent back to the originator of the failed message at the port and IP address from which the message was sent. Note that this may or may not be the same port on which the application would typically receive messages. To accommodate implementations that use connect() or similar constructs, the NACK will be sent from the IP address and port to which the uninterpretable message was sent. From a practical perspective, this is probably easiest to determine by binding listening sockets to a specific interface; however, other mechanisms may also be employed.
UDPなどのコネクションレスな輸送において、ナックメッセージはメッセージが送られたポートとIPアドレスの失敗したメッセージの創始者に送り返されます。 これがアプリケーションがメッセージを通常受け取るのと同じポートであるかもしれないことに注意してください。 実装を収容するために、使用を「非-解明でき」メッセージが送られたIPアドレスとポートから()か同様の構造物、ナックに接させるでしょう。 実用的な見解から、これはたぶん特定のインタフェースまでソケットを聴きながら付きながら、最も自決しやすいです。 しかしながら、また、他のメカニズムは使われるかもしれません。
The behavior specified above is strictly necessary for any generally useful form of a NACK mechanism. In the most general case, when an implementation receives a message that it cannot decompress, it has exactly three useful pieces of information: (1) the contents of the message, (2) an indication of why the message cannot be decoded, and (3) the IP address and port from which the message originated. Note that none of these contains any indication of where the remote application is listening for messages, if it differs from the sending port.
上で指定された振舞いが厳密にナックメカニズムのどんな一般に役に立つフォームにも必要です。 実装が減圧できないというメッセージを受け取るときの最も一般的な場合では、まさに3つの役に立つ情報を持っています: (1) (3) メッセージが起因したメッセージのコンテンツ、(2) メッセージを解読できない理由のしるし、IPアドレス、およびポート。 これらのいずれもリモートアプリケーションがメッセージの聞こうとしているところのどんなしるしも含まないことに注意してください、送付ポートと異なっているなら。
Roach Standards Track [Page 5] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[5ページ]。
2.3. Receiving a SigComp NACK
2.3. SigCompナックを受けます。
The first action taken upon receipt of a NACK is an attempt to find the message to which the NACK corresponds. This search is performed using the 20-byte SHA-1 hash contained in the NACK. Once the matching message is located, further operations are performed based on the compartment that was associated with the sent message.
ナックを受け取り次第取られた最初の行動はナックが相当するメッセージを見つける試みです。 この検索は、ナックに含まれた20バイトのSHA-1ハッシュを使用することで実行されます。 合っているメッセージがいったん見つけられていると、さらなる操作は送信されたメッセージに関連したコンパートメントに基づいて実行されます。
Further behavior of a node upon receiving a SigComp NACK depends on whether a reliable or unreliable transport is being used.
SigCompナックを受けるときのノードのさらなる動きは信頼できるか頼り無い輸送が使用されているかどうかによります。
2.3.1. Unreliable Transport
2.3.1. 頼り無い輸送
When SigComp is used over an unreliable transport, the application has no reasonable expectation that the transport layer will deliver any particular message. It then becomes the application layer's responsibility to ensure that data is retransmitted as necessary. In these circumstances, the NACK mechanism relies on such behavior to ensure delivery of the message, and never performs retransmissions on the application's behalf.
SigCompが頼り無い輸送の上で使用されるとき、アプリケーションには、トランスポート層がどんな特定のメッセージも提供するどんな合理的な期待もありません。 そして、データが必要に応じて再送されるのを保証するのが応用層の責任になります。 こういう事情ですから、ナックメカニズムは、メッセージの配送を確実にするためにそのような振舞いに依存して、アプリケーションの利益に「再-トランスミッション」を決して実行しません。
When a NACK is received for a message sent over an unreliable transport, the NACK recipient uses the contained information to make appropriate adjustments to the compressor associated with the proper compartment. The exact nature of these adjustments are specific to the compression scheme being used, and will vary from implementation to implementation. The only requirement on these adjustments is that they must have the effect of compensating for the error that has been indicated (e.g., by removing the state that the remote node indicates it cannot retrieve).
頼り無い輸送の上に送られたメッセージのためにナックを受け取るとき、ナック受取人は、適当な調整を適切なコンパートメントに関連しているコンプレッサーにするのに含まれた情報を使用します。 これらの調整の正確な本質は、使用される圧縮技術に特定であり、実装によって異なるでしょう。 これらの調整に関する唯一の要件はそれらには示された(例えば、遠隔ノードが検索できないのを示す状態を取り除くことによって)誤りを補うという効果がなければならないということです。
In particular, when an unreliable transport is used, the original message must not be retransmitted by the SigComp layer upon receipt of a NACK. Instead, the next application-initiated transmission of a message will take advantage of the adjustments made as a result of processing the NACK.
頼り無い輸送が使用されているとき、特に、ナックを受け取り次第SigComp層のそばでオリジナルのメッセージを再送してはいけません。 代わりに、メッセージの次のアプリケーションで開始している伝達はナックを処理することの結果、された調整を利用するでしょう。
2.3.2. Reliable Transport
2.3.2. 信頼できる輸送
When a reliable transport is employed, the application makes a basic assumption that any message passed down the stack will be retransmitted as necessary to ensure that the remote node receives it, unless a failure is indicated by the transport layer. Because SigComp acts as a shim between the transport-layer and the application, it becomes the responsibility of the SigComp implementation to ensure that any failure to transmit a message is communicated to the application.
信頼できる輸送が採用しているとき、アプリケーションはスタックで通過されたどんなメッセージも遠隔ノードがそれを受けるのを保証するために必要に応じて再送されるという基本仮定をします、失敗がトランスポート層のそばで示されない場合。 SigCompがトランスポート層とアプリケーションの間の詰め物として機能するので、送信しない場合アプリケーションに伝えられるのを保証するのがSigComp実装の責任になります。
Roach Standards Track [Page 6] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[6ページ]。
When a NACK is received for a message sent over a reliable transport, the SigComp layer must indicate to the application that an error has occurred. In general, the application should react in the same way as it does for any other transport layer error, such as a TCP connection reset. For most applications, this reaction will initially be an attempt to reset and re-establish the connection, and re-initiate the failed transaction. The SigComp layer should also use the information contained in the NACK to make appropriate adjustments to the compressor associated with the proper compartment (similar to the adjustments made for unreliable transport). Thus, if the compartment is not reset by resetting the TCP connection, the next message will take advantage of the adjustments.
信頼できる輸送の上に送られたメッセージのためにナックを受け取るとき、SigComp層は、誤りが発生したのをアプリケーションに示さなければなりません。 一般に、同様に、アプリケーションはいかなる他のトランスポート層誤りによってもするように反応するべきです、TCP接続リセットのように。 ほとんどのアプリケーションのために、この反応は、接続をリセットして、復職させる初めは試みであり、失敗したトランザクションを再開始するでしょう。 また、SigComp層は適切なコンパートメントに関連しているコンプレッサーへの適当な調整を(頼り無い輸送のためにされた調整と同様)であるのにするようにナックに含まれた情報を使用するはずです。 したがって、コンパートメントがTCP接続をリセットすることによってリセットされないと、次のメッセージは調整を利用するでしょう。
2.4. Detecting Support for NACK
2.4. ナックのサポートを検出します。
Detection of support for the NACK mechanism may be beneficial in certain circumstances. For example, with the current definition of SigComp, acknowledgment of state receipt is required before a sender can reference such state. When multiple messages are sent before a response is received, the need to wait for such responses can cause significant decreases in message compression efficiency. If it is known that the receiver supports the NACK mechanism, the sender can instead optimistically assume that the state created by a sent message has been created, and is allowed to be referenced. If such an assumption turns out to be false (due to, for example, packet loss or packet reordering), the sender can recover upon receipt of a NACK.
ナックメカニズムのサポートの検出はある特定の状況では有益であるかもしれません。 例えば、SigCompの現在の定義で、送付者はそのようなものが述べる参照を必要とすることができる前に州の領収書の承認が必要です。 応答が受け取られている前に複数のメッセージを送るとき、そのような応答を待つ必要性はメッセージ圧縮効率のかなりの減少を引き起こす場合があります。 受信機がナックメカニズムをサポートするのが知られているなら、送付者は、代わりに送信されたメッセージによって創設された状態が創設して、参照をつけることができると楽観的に仮定できます。 そのような仮定が誤っていると(例えば、パケット損失かパケット再命令による)判明するなら、送付者はナックを受け取り次第回復できます。
In order to facilitate such detection, any implementation that will send NACK messages upon decompression failure will indicate a SigComp version number of 0x02 in its Universal Decompressor Virtual Machine (UDVM). The bytecodes sent to such an endpoint can check the version number, and send appropriate indication back to their compressor as requested feedback. Except for the NACK mechanism described in this document, implementations advertising a version of 0x02 behave exactly like those advertising a version number of 0x01.
そのような検出を容易にするために、減圧失敗でメッセージをナックに送るどんな実装もUniversal Decompressor Virtual Machine(UDVM)の0×02のSigCompバージョン番号を示すでしょう。 そのような終点に送られたバイトコードはバージョン番号をチェックできます、そして、要求された通り適切な指示をそれらのコンプレッサーに送り返してください。フィードバック。 このドキュメント、実装広告で説明されたナックメカニズムを除いて、0×02のバージョンはちょうど0×01のバージョン番号の広告を出すもののように振る舞います。
3. Message Format
3. メッセージ・フォーマット
SigComp NACK packets are syntactically valid SigComp messages which have been specifically designed to be safely ignored by implementations that do not support the NACK mechanism.
SigCompナックパケットはナックメカニズムをサポートしない実装によって安全に無視されるように明確に設計されているシンタクス上有効なSigCompメッセージです。
In particular, NACK messages are formatted as the second variant of a SigComp message (typically used for code upload) with a "code_len" field of zero. The NACK information (message identifier, reason for failure, and error details) is encoded in the "remaining SigComp
特に、ナックメッセージはSigCompメッセージ(コードアップロードに通常使用される)の2番目の異形としてゼロの「コード_len」分野でフォーマットされます。 ナック情報(メッセージ識別子、失敗の理由、および誤りの詳細)は「残っているSigComp」でコード化されます。
Roach Standards Track [Page 7] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[7ページ]。
message" area, typically used for input data. Further, the "destination" field is used as a version identifier to indicate which version of NACK is being employed.
入力データに通常使用される「メッセージ」領域。 さらに、「目的地」分野は、ナックのどのバージョンが就職であるかを示すのにバージョン識別子として使用されます。
3.1. Message Fields
3.1. メッセージ分野
The format of the NACK message and the use of the fields within it are shown in Figure 1.
ナックメッセージの書式とそれの中の分野の使用は図1に示されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item :
| |
+---+---+---+---+---+---+---+---+
| code_len = 0 |
+---+---+---+---+---+---+---+---+
| code_len = 0 | version = 1 |
+---+---+---+---+---+---+---+---+
| Reason Code |
+---+---+---+---+---+---+---+---+
| OPCODE of failed instruction |
+---+---+---+---+---+---+---+---+
| PC of failed instruction |
| |
+---+---+---+---+---+---+---+---+
| |
: SHA-1 Hash of failed message :
| |
+---+---+---+---+---+---+---+---+
| |
: Error Details :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 | T| 0 | +---+---+---+---+---+---+---+---+ | | : 返されたフィードバック項目: | | +---+---+---+---+---+---+---+---+ | コード_len=0| +---+---+---+---+---+---+---+---+ | コード_len=0| バージョン= 1| +---+---+---+---+---+---+---+---+ | 理由コード| +---+---+---+---+---+---+---+---+ | 失敗した指示のOPCODE| +---+---+---+---+---+---+---+---+ | 失敗した指示のPC| | | +---+---+---+---+---+---+---+---+ | | : 失敗したメッセージのSHA-1 Hash: | | +---+---+---+---+---+---+---+---+ | | : 誤りの詳細: | | +---+---+---+---+---+---+---+---+
Figure 1: SigComp NACK Message Format
図1: SigCompナックメッセージ・フォーマット
o "Reason Code" is a one-byte value that indicates the nature of the
decompression failure. The specific codes are given in
Section 3.2.
o 「理由Code」は減圧失敗の本質を示す1バイトの値です。 セクション3.2で特定のコードを与えます。
o "OPCODE of failed instruction" is a one-byte field that includes
the opcode to which the PC was pointing when the failure occurred.
If failure occurred before the UDVM began executing any code, this
field is set to 0.
o 「失敗した指示のOPCODE」は失敗が起こったときPCが指していたopcodeを含んでいる1バイトの分野です。 UDVMがどんなコードも実行し始める前に失敗が起こったなら、この分野は0に設定されます。
Roach Standards Track [Page 8] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[8ページ]。
o "PC of failed instruction" is a two-byte field containing the
value of the program counter when failure occurred (i.e., the
memory address of the failed UDVM instruction). The field is
encoded with the most significant byte of the PC first (i.e., in
network or big endian order). If failure occurred before the UDVM
began executing any code, this field is set to 0.
o 「失敗した指示のPC」は失敗が起こったときプログラムカウンタの値を含む2バイトの分野(すなわち、失敗したUDVM指示のメモリアドレス)です。 分野は最初に(すなわち、ネットワークかビッグエンディアンオーダーで)、PCの最も重要なバイトでコード化されます。 UDVMがどんなコードも実行し始める前に失敗が起こったなら、この分野は0に設定されます。
o "SHA-1 Hash of failed message" contains the full 20-byte SHA-1
hash of the SigComp message that could not be decompressed. This
information allows the NACK recipient to locate the message that
failed to decompress so that adjustments to the correct
compartment can be performed. When performing this hash, the
entire SigComp message is used, from the header byte (binary
11111xxx) to the end of the input. Any lower-level protocol
headers (such as UDP or IP) and message delimiters (the 0xFFFF
that marks message boundaries in stream protocols) are not
included in the hash. When used over a stream based protocol, any
0xFFxx escape sequences are un-escaped before performing the hash
operation.
o 「失敗したメッセージのSHA-1 Hash」は減圧できなかったSigCompメッセージの完全な20バイトのSHA-1ハッシュを含んでいます。 この情報で、ナック受取人は正しいコンパートメントへの調整を実行できるように減圧しなかったメッセージの場所を見つけることができます。 このハッシュを実行するとき、全体のSigCompメッセージはヘッダーバイト(2進の11111xxx)から入力の端まで使用されます。 どんな低レベルプロトコルヘッダー(UDPかIPなどの)とメッセージデリミタ(ストリームプロトコルにおけるメッセージ限界をマークする0xFFFF)もハッシュに含まれていません。 ベースのストリームの上で使用されたら、議定書を作ってください、そして、ハッシュ操作を実行する前に、どんな0xFFxxエスケープシーケンスも不-逃げられます。
o "Error Details" provides additional information that might be
useful in correcting the problem that caused decompression
failure. Its meaning is specific to the "Reason Code". See
Section 3.2 for specific information on what appears in this
field.
o 「誤りDetails」は減圧失敗を引き起こした問題を修正する際に役に立つかもしれない追加情報を提供します。 意味は「理由コード」に特定です。 この分野に現れることに関する特殊情報に関してセクション3.2を見てください。
o "Code_len" is the "code_len" field from a standard SigComp
message. It is always set to "0" for NACK messages.
o 「コード_len」は標準のSigCompメッセージからの「コード_len」分野です。 それはいつも「ナックメッセージのための0インチ」に設定されます。
o "Version" gives the version of the NACK mechanism being employed.
This document defines version 1.
o 「バージョン」はナックメカニズム就職のバージョンを与えます。 このドキュメントはバージョン1を定義します。
3.2. Reason Codes
3.2. 理由コード
Note that many of the status codes are more useful in debugging interoperability problems than with on-the-fly correction of errors. The "STATE_NOT_FOUND" error is a notable exception: it will generally cause the NACK recipient to encode future messages so as to not use the indicated state.
デバッグ相互運用性問題でステータスコードの多くが誤りの飛行中の修正より役に立つことに注意してください。 「どんな_も見つけなかった州の_」誤りは注目に値する例外です: 一般に、それで、ナック受取人は、示された状態を使用しないように将来のメッセージをコード化するでしょう。
Upon receiving the other status messages, an implementation would typically be expected either to use a different set of bytecodes or, if that is not an option, to send that specific message uncompressed.
他のステータスメッセージを受け取って、実装が異なったセットのバイトコードを使用すると通常予想されただろうか、またはその特定のメッセージを送るのはそれがオプションでないなら解凍しました。
Roach Standards Track [Page 9] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[9ページ]。
Error Code Details
-------------------------- ---- ---------------------------
STATE_NOT_FOUND 1 State ID (6 - 20 bytes)
CYCLES_EXHAUSTED 2 Cycles Per Bit (1 byte)
USER_REQUESTED 3
SEGFAULT 4
TOO_MANY_STATE_REQUESTS 5
INVALID_STATE_ID_LENGTH 6
INVALID_STATE_PRIORITY 7
OUTPUT_OVERFLOW 8
STACK_UNDERFLOW 9
BAD_INPUT_BITORDER 10
DIV_BY_ZERO 11
SWITCH_VALUE_TOO_HIGH 12
TOO_MANY_BITS_REQUESTED 13
INVALID_OPERAND 14
HUFFMAN_NO_MATCH 15
MESSAGE_TOO_SHORT 16
INVALID_CODE_LOCATION 17
BYTECODES_TOO_LARGE 18 Memory size (2 bytes)
INVALID_OPCODE 19
INVALID_STATE_PROBE 20
ID_NOT_UNIQUE 21 State ID (6 - 20 bytes)
MULTILOAD_OVERWRITTEN 22
STATE_TOO_SHORT 23 State ID (6 - 20 bytes)
INTERNAL_ERROR 24
FRAMING_ERROR 25
エラーコードの詳細-------------------------- ---- --------------------------- 州、___FOUND1州ID(6--20バイト)サイクルズ_EXHAUSTED2サイクルズPer Bit(1バイト)USER_REQUESTED3SEGFAULT4ではなくも、_MANY_州_REQUESTS5INVALID_州_ID_LENGTH6INVALID_州PRIORITY、7OUTPUT_OVERFLOW8STACK_UNDERFLOW9BAD_INPUT_BITORDER10DIV_BY_ZERO11SWITCH_VALUE、も_HIGH12、も_MANY_BITS_REQUESTED13; INVALID_OPERAND14ハフマン_いいえ_MATCH15MESSAGE、も_SHORT16INVALID_CODE_LOCATION17BYTECODES、も__UNIQUE21州ID(6--20バイト)MULTILOAD_OVERWRITTEN22州_ではなく、LARGE18Memoryサイズ(2バイト)INVALID_OPCODE19INVALID_州_PROBE20ID_、_SHORT23州ID(6--20バイト)INTERNAL_ERROR24FRAMING_ERROR25
Only the five errors "STATE_NOT_FOUND", "CYCLES_EXHAUSTED", "BYTECODES_TOO_LARGE", "ID_NOT_UNIQUE", and "STATE_TOO_SHORT" contain details; for all other error codes, the "Error Details" field has zero length.
5つの誤りだけ「どんな_も見つけなかった州の_」が「サイクルズ_を消耗させた」、「バイトコード_、_大き過ぎる、」、「ID_NOT_ユニークである」、詳細を含むように「__あまりに簡潔に、述べる」、。 他のすべてのエラーコードのために、「誤りの詳細」分野には、ゼロ・レングスがあります。
Figure 2: SigComp NACK Reason Codes
図2: SigCompナック理由コード
1. STATE_NOT_FOUND
A state that was referenced cannot be found. The state may have
been referenced by the UDVM executing a STATE-ACCESS
instruction; it also may have been referenced by the "partial
state identifier" field in a SigComp message. The "details"
field contains the state identifier for the state that could not
be found. This is also the proper error to return in the case
that a unique state item was matched but fewer bytes of state ID
were sent than required by the minimum_access_length.
1. _FOUND A状態ではなく、参照をつけられた州_は見つけることができません。 状態は州-ACCESS指示を実行するUDVMによって参照をつけられたかもしれません。 また、それはSigCompメッセージの「部分的な州の識別子」分野によって参照をつけられたかもしれません。 「詳細」分野は見つけられないかもしれない状態のための州の識別子を含んでいます。 また、ユニークな州の項目がIDが送られた状態の最小の_のアクセス_長さによって必要とされるより取り組むのにもかかわらずの、少ないバイトであっこれは返す適切な誤りです。
Roach Standards Track [Page 10] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[10ページ]。
2. CYCLES_EXHAUSTED
Decompression of the message has taken more cycles than were
allocated to it. The "details" field contains a one-byte value
that communicates the number of cycles per bit. The cycles per
bit is represented as an unsigned 8-bit integer (i.e., not
encoded).
2. メッセージのサイクルズ_EXHAUSTED Decompressionはそれに割り当てたより多くのサイクルかかりました。 「詳細」分野は1ビットあたりの繰返し数を伝える1バイトの値を含んでいます。 1ビットあたりのサイクルは未署名の8ビットの整数(すなわち、コード化されない)として表されます。
3. USER_REQUESTED
The DECOMPRESSION-FAILURE opcode has been executed.
3. USER_REQUESTED DECOMPRESSION-FAILURE opcodeは実行されました。
4. SEGFAULT
An attempt to read from or write to memory that is outside of
the UDVM's memory space has been attempted.
4. UDVMのメモリスペースの外にあるメモリに読み込むか、または書くSEGFAULT An試みを試みてあります。
5. TOO_MANY_STATE_REQUESTS
More than four requests to store or delete state objects have
been requested.
5. また、__MANY_州REQUESTS More、格納するか、または削除する州が要求されているのを反対させる4つの要求より。
6. INVALID_STATE_ID_LENGTH
A state id length less than 6 or greater than 20 has been
specified.
6. 6未満のイドの長さか20以上のINVALID_州_ID_LENGTH A状態は指定されました。
7. INVALID_STATE_PRIORITY
A state priority of 65535 has been specified when attempting to
store a state.
7. 状態を格納するのを試みるとき、65535のINVALID_州_PRIORITY A州の優先権は指定されました。
8. OUTPUT_OVERFLOW
The decompressed message is too large to be decoded by the
receiving node.
8. 減圧が通信させるOUTPUT_OVERFLOWは受信ノードで解読できないくらい大きいです。
9. STACK_UNDERFLOW
An attempt to pop a value off the UDVM stack was made with a
stack_fill value of 0.
9. 0のスタック_中詰め値でUDVMスタックで値を飛び出させるSTACK_UNDERFLOW An試みをしました。
10. BAD_INPUT_BITORDER
An INPUT-BITS or INPUT-HUFFMAN instruction was encountered with
the "input_bit_order" register set to an invalid value (i.e.,
one of the upper 13 bits is set).
10. BAD_INPUT_BITORDER An INPUT-BITSかINPUT-ハフマン指示は「入力_ビット_命令」レジスタ・セットで無効の値に遭遇しました(すなわち、上側の13ビットの1つは設定されます)。
11. DIV_BY_ZERO
A DIVIDE or REMAINDER opcode was encountered with a divisor of
0.
11. DIV_BY_ZERO AのDIVIDEかREMAINDER opcodeが0の除数で遭遇しました。
12. SWITCH_VALUE_TOO_HIGH
The input to a SWITCH opcode exceeds the number of branches
defined.
12. SWITCH_VALUE、も_HIGH、SWITCH opcodeへの入力は定義されたブランチの数を超えています。
Roach Standards Track [Page 11] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[11ページ]。
13. TOO_MANY_BITS_REQUESTED
An INPUT-BITS or INPUT-HUFFMAN instruction was encountered that
attempted to input more than 16 bits.
13. また、_16ビット以上を入力するのを試みたMANY_BITS_REQUESTED An INPUT-BITSかINPUT-ハフマン指示が遭遇しました。
14. INVALID_OPERAND
An operand for an instruction could not be resolved to an
integer value (e.g., a literal or reference operand beginning
with 11111111).
14. 整数値(例えば11111111で始まる文字通りか参照オペランド)に指示のためのINVALID_OPERAND Anオペランドを決議できませんでした。
15. HUFFMAN_NO_MATCH
The input string does not match any of the bitcodes in the
INPUT-HUFFMAN opcode.
15. ハフマン、_入力ストリングがするいいえ_MATCHはINPUT-ハフマンopcodeでbitcodesのいずれにも合っていません。
16. MESSAGE_TOO_SHORT
When attempting to decode a SigComp message, the recipient
determined that there were not enough bytes in the message for
it to be valid.
16. SigCompメッセージを解読するのを試みるSHORT When、受取人の_それが有効になるメッセージには十分なバイトがなかったと決心し過ぎるMESSAGE_。
17. INVALID_CODE_LOCATION
The "code location" field in the SigComp message was set to the
invalid value of 0.
17. INVALID_CODE_LOCATION「コード位置」分野はSigCompメッセージに0の無効の値に設定されました。
18. BYTECODES_TOO_LARGE
The bytecodes that a SigComp message attempted to upload exceed
the amount of memory available in the receiving UDVM. The
details field is a two-byte expression of the
DECOMPRESSION_MEMORY_SIZE of the receiving UDVM. This value is
communicated most-significant-byte first.
18. BYTECODES、も_LARGE、SigCompメッセージがアップロードするのを試みたバイトコードは受信UDVMで有効なメモリー容量を超えています。 詳細分野はDECOMPRESSION_MEMORY_SIZEの2バイトの表現です。受信UDVMについて。 最初に、この値はコミュニケートしている最も重要なバイトです。
19. INVALID_OPCODE
The UDVM attempted to identify an undefined byte value as an
instruction.
19. INVALID_OPCODE UDVMは、未定義のバイト値が指示であると認識するのを試みました。
20. INVALID_STATE_PROBE
When attempting to retrieve state, the state_length operand is
set to 0 but the state_begin operand is non-zero.
20. _INVALID_州PROBE Whenが、状態を検索するのを試みて、状態_長さのオペランドは0にもかかわらず、_が始める状態に設定されて、オペランドが非ゼロであるということです。
21. ID_NOT_UNIQUE
A partial state identifier that was used to access state matched
more than one state item. Note that this error might be
returned as the result of executing a STATE-ACCESS instruction
or attempting to locate a unique piece of state as identified by
the "partial state identifier" in a SigComp message. The
"details" field contains the partial state identifier that was
requested.
21. 状態にアクセスするのに使用された_のUNIQUEのA部分的な州の識別子ではなく、ID_が複数の州の項目に合っていました。 この誤りがSigCompメッセージの「部分的な州の識別子」によって特定されるように州-ACCESS指示を実行するか、またはユニークな状態の場所を見つけるのを試みるという結果として返されるかもしれないことに注意してください。 「詳細」分野は要求された部分的な州の識別子を含んでいます。
22. MULTILOAD_OVERWRITTEN
A MULTILOAD instruction attempted to overwrite itself.
22. MULTILOAD_OVERWRITTEN A MULTILOAD指示は、書き過ぎて文体を損なうのを試みました。
Roach Standards Track [Page 12] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[12ページ]。
23. STATE_TOO_SHORT
A STATE-ACCESS instruction has attempted to copy more bytes from
a state item than the state item actually contains. The
"details" field contains the partial state identifier that was
requested. Implementors are cautioned to return only the
partial state identifier that was requested; if the NACK
contains any state identifier in addition to what was requested,
attackers may be able to use that additional information to
access the state.
23. __また、SHORT A州-ACCESS指示は試みました。州、州の項目からの州の項目が実際に含んでいるより多くのバイトをコピーするのを試みました。 「詳細」分野は要求された部分的な州の識別子を含んでいます。 作成者が要求された部分的な州の識別子だけを返すと警告されます。 ナックが何か要求されたことに加えた州の識別子を含むなら、攻撃者は、状態にアクセスするのにその追加情報を使用できるかもしれません。
24. INTERNAL_ERROR
The UDVM encountered an unexpected condition that prevented it
from decompressing the message.
24. INTERNAL_ERROR UDVMはそれがメッセージを減圧するのを防いだ予期していなかった状態に遭遇しました。
25. FRAMING_ERROR
The UDVM encountered a framing error (unquoted 0xFF 80 .. 0xFF
FE in an input stream.) This error is applicable only to
messages received on a stream transport. In the case of a
framing error, a SHA-1 hash for a unique message cannot be
determined. Consequently, when a FRAMING_ERROR NACK is sent,
the "SHA-1 Hash of failed message" field should be set to all
zeros.
25. FRAMING_ERROR UDVMは縁どり誤りに遭遇しました(入力における引用を終わっている0xFF80.. 0xFF FEは流れます。)。 この誤りは流れの輸送に受け取られたメッセージだけに適切です。 縁どり誤りの場合では、ユニークなメッセージのためのSHA-1細切れ肉料理は決定できません。 FRAMING_ERROR NACKを送るとき、その結果、「失敗したメッセージのSHA-1 Hash」分野をすべてのゼロに設定するべきです。
4. Security Considerations
4. セキュリティ問題
4.1. Reflector Attacks
4.1. 反射鏡攻撃
Because SigComp NACK messages are by necessity sent in response to other messages, it is possible to trigger them by intentionally sending malformed messages to a SigComp implementation with a spoofed IP address. However, because such actions can only generate one message for each message sent, they don't serve as amplifier attacks. Further, due to the reasonably small size of NACK packets, there cannot be a significant increase in the size of the packet generated.
必要に迫られて他のメッセージに対応してSigCompナックメッセージを送るので、だまされたIPアドレスで故意に奇形のメッセージをSigComp実現に送ることによってそれらの引き金となるのは可能です。 しかしながら、そのような動作が送られた各メッセージへの1つのメッセージしか発生させることができないので、それらはアンプ攻撃として機能しません。 ナックパケットの合理的に小さいサイズのために、より遠くに、発生するパケットのサイズのかなりの増加があるはずがありません。
It is worth noting that nearly all deployed protocols exhibit this same behavior.
ほとんどすべて配備されたプロトコルがこの同じ振舞いを示すことに注意する価値があります。
4.2. NACK Spoofing
4.2. ナックSpoofing
Although it is possible to forge NACK messages as if they were generated by a different node, the damage that can be caused is minimal. Reporting a loss of state will typically result in nothing more than the re-transmission of that state in a subsequent message. Other failure codes would result in the next message being sent using an alternate compression mechanism, or possibly uncompressed.
ナックメッセージを作り出すのがまるで異なったノードで発生するかのように可能ですが、もたらすことができる損害は最小限です。 状態の損失を報告すると、ただその後のメッセージにおける、その状態の再トランスミッションは通常もたらされるでしょう。 他の失敗コードは交互の圧縮機構を使用させるか、またはことによると解凍する次のメッセージをもたらすでしょう。
Roach Standards Track [Page 13] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[13ページ]。
Although all of the above consequences result in slightly larger messages, none of them have particularly catastrophic implications for security.
上の結果のすべてがわずかに大きいメッセージをもたらしますが、それらのいずれにはも、セキュリティのための特に壊滅的な意味がありません。
5. IANA Considerations
5. IANA問題
This document defines a new value for the IANA registered attribute SigComp_version.
IANAが属性SigComp_バージョンを登録したので、このドキュメントは新しい値を定義します。
Value (in hex): 02
値(十六進法における): 02
Description: SigComp version 2 (NACK support)
記述: SigCompバージョン2(ナックのサポート)
Reference: [RFC4077]
参照: [RFC4077]
6. Acknowledgements
6. 承認
Thanks to Carsten Bormann, Zhigang Liu, Pekka Pessi, and Robert Sugar for their comments and suggestions. Special thanks to Abigail Surtees and Richard Price for several very detailed reviews and suggestions.
彼らのコメントと提案をカルステン・ボルマン、Zhigangリュウ、ペッカPessi、およびロバートSugarをありがとうございます。 アビゲール・サーティーズとリチャードPriceのおかげで、いくつかの非常に詳細なレビューと提案において、特別です。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z.,
and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
January 2003.
[1] 価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、リュウ、Z.、およびJ.ローゼンバーグ、「シグナリング圧縮(SigComp)」、RFC3320(2003年1月)。
[2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu,
Z., and R. Price, "Signaling Compression (SigComp) - Extended
Operations", RFC 3321, January 2003.
[2] ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.C.、リュウ、Z.、およびR.は「圧縮(SigComp)--操作を広げると合図すること」でのRFC3321(2003年1月)に値を付けます。
7.2. Informative References
7.2. 有益な参照
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Roach Standards Track [Page 14] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[14ページ]。
Author's Address
作者のアドレス
Adam Roach Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 US
アダムローチエスタカードSystems17210キャンベル道路Suite250テキサス75252ダラス(米国)
EMail: adam@estacado.net
メール: adam@estacado.net
Roach Standards Track [Page 15] RFC 4077 SigComp NACK May 2005
ローチStandardsはSigCompナック2005年5月にRFC4077を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Roach Standards Track [Page 16]
ローチ標準化過程[16ページ]
一覧
スポンサーリンク
