Network Working Group G. Camarillo
Request for Comments: 4032 Ericsson
Updates: 3312 P. Kyzivat
Category: Standards Track Cisco Systems
March 2005
Update to the Session Initiation Protocol (SIP)
Preconditions Framework
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility.
このドキュメントは、SIPの前提条件のフレームワークを定義するRFC 3312を更新します。 新しい前提条件タイプの作成者にガイドラインを提供し、セッションモビリティが関係する状況でSIP前提条件を使用する方法を説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Defining New Precondition Types . . . . . . . . . . . . . . . 3
3.1. Precondition Type Tag . . . . . . . . . . . . . . . . . 3
3.2. Status Type . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Precondition Strength . . . . . . . . . . . . . . . . . 3
3.4. Suspending and Resuming Session Establishment . . . . . 3
4. Issues Related to Session Mobility . . . . . . . . . . . . . . 4
4.1. Update to RFC 3312 . . . . . . . . . . . . . . . . . . . 5
4.2. Desired Status . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
RFC 3312 [3] defines the framework for SIP [2] preconditions, which is a generic framework that allows SIP UAs (User Agents) to suspend the establishment of a session until a set of preconditions are met. Although only Quality of Service (QoS) preconditions have been defined so far, this framework supports different types of preconditions. (QoS preconditions are defined by RFC 3312 as well).
RFC 3312 [3]はSIP [2]前提条件のフレームワークを定義します。これは、一連の前提条件が満たされるまでSIP UA（ユーザーエージェント）がセッションの確立を一時停止できるようにする汎用フレームワークです。 これまでにサービスの品質（QoS）の前提条件のみが定義されていますが、このフレームワークはさまざまなタイプの前提条件をサポートしています。 （QoSの前提条件もRFC 3312で定義されています）。
This document updates RFC 3312, provides guidelines for authors of new precondition types and explains which topics they need to discuss when defining them. In addition, it updates some of the procedures in RFC 3312 for using SIP preconditions in situations that involve session mobility as described below.
このドキュメントはRFC 3312を更新し、新しい前提条件タイプの作成者にガイドラインを提供し、それらを定義するときに議論する必要があるトピックを説明します。 さらに、以下で説明するように、セッションモビリティが関係する状況でSIP前提条件を使用するためのRFC 3312の手順の一部を更新します。
RFC 3312 focuses on media sessions that do not move around. That is, media is sent between the same end-points throughout the duration of the session. Nevertheless, media sessions established by SIP are not always static.
RFC 3312は、動き回らないメディアセッションに焦点を当てています。 つまり、セッションの期間中、同じエンドポイント間でメディアが送信されます。 それでも、SIPによって確立されたメディアセッションは常に静的ではありません。
SIP offers mechanisms to provide session mobility, namely re-INVITEs and UPDATEs [5]. While existing implementations of RFC 3312 can probably handle session mobility, there is a need to explicitly point out the issues involved and make a slight update on some of the procedures defined there in. With the updated procedures defined in this document, messages carrying precondition information become more explicit about the current status of the preconditions.
SIPは、セッションモビリティ、つまりre-INVITEとUPDATE [5]を提供するメカニズムを提供します。 RFC 3312の既存の実装はおそらくセッションモビリティを処理できますが、関連する問題を明示的に指摘し、そこに定義されている手順の一部をわずかに更新する必要があります。 前提条件の現在の状態についてより明確になります。
Specifically, we now allow answers to downgrade current status values (this was disallowed by RFC 3312). We consider moving an existing stream to a new location as equivalent to establishing a new stream. Therefore, answers moving streams to new locations set all the current status values in their answers to "No" and start a new precondition negotiation from scratch.
具体的には、現在のステータス値をダウングレードするための回答を許可しています（これはRFC 3312で禁止されていました）。 新しいストリームを確立するのと同等として、既存のストリームを新しい場所に移動することを検討します。 したがって、ストリームを新しい場所に移動する回答では、回答の現在のステータス値がすべて「いいえ」に設定され、新しい前提条件ネゴシエーションがゼロから開始されます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」 、および「オプション」は、BCP 14、RFC 2119 [1]で説明されているように解釈され、準拠する実装の要件レベルを示します。
Specifications defining new precondition types need to discuss the topics described in this section. Having clear definitions of new precondition types is essential to ensure interoperability among different implementations.
新しい前提条件タイプを定義する仕様では、このセクションで説明するトピックについて議論する必要があります。 異なる実装間の相互運用性を確保するには、新しい前提条件タイプの明確な定義が不可欠です。
New precondition types MUST have an associated precondition type tag (e.g., "qos" is the tag for QoS preconditions). Authors of new preconditions MUST register new precondition types and their tags with the IANA by following the instructions in Section 15 of RFC 3312.
新しい前提条件タイプには、前提条件タイプタグが関連付けられている必要があります（たとえば、「qos」はQoS前提条件のタグです）。 新しい前提条件の作成者は、RFC 3312のセクション15の指示に従って、新しい前提条件タイプとそのタグをIANAに登録する必要があります。
RFC 3312 defines two status types: end-to-end and segmented. Specifications defining new precondition types MUST indicate which status applies to the new precondition. New preconditions can use only one status type or both. For example, the QoS preconditions defined in RFC 3312 can use both.
RFC 3312は、エンドツーエンドとセグメント化の2つのステータスタイプを定義しています。 新しい前提条件タイプを定義する仕様は、どのステータスが新しい前提条件に適用されるかを示さなければなりません。 新しい前提条件では、1つのステータスタイプのみ、または両方を使用できます。 たとえば、RFC 3312で定義されているQoS前提条件は両方を使用できます。
RFC 3312 defines optional and mandatory preconditions. Specifications defining new precondition types MUST describe whether or not optional preconditions are applicable, and in case they are, what is the expected behavior of a UA on reception of optional preconditions.
RFC 3312は、オプションおよび必須の前提条件を定義しています。 新しい前提条件タイプを定義する仕様は、オプションの前提条件が適用可能かどうかを記述しなければならず、適用される場合、オプションの前提条件の受信時のUAの予想される動作は何か。
Section 6 of RFC 3312 describes the behavior of UAs from the moment session establishment is suspended, due to a set of preconditions, until it is resumed when these preconditions are met. In general, the called user is not alerted until the preconditions are met.
RFC 3312のセクション6は、一連の前提条件によりセッションの確立が中断されてから、これらの前提条件が満たされたときに再開されるまでのUAの動作について説明しています。 一般に、前提条件が満たされるまで、呼び出されたユーザーは警告されません。
In addition to not alerting the user, each precondition type MUST define any extra actions UAs should perform or refrain from performing when session establishment is suspended. The behavior of media streams during session suspension is therefore part of the definition of a particular precondition type. Some precondition types may allow media streams to send and receive packets during session suspension; others may not. Consequently, the following paragraph from RFC 3312 only applies to QoS preconditions:
ユーザーに警告しないことに加えて、各前提条件タイプは、セッション確立が中断された場合にUAが実行する、または実行を控えるべき追加のアクションを定義する必要があります。 したがって、セッションの中断中のメディアストリームの動作は、特定の前提条件タイプの定義の一部です。 前提条件の種類によっては、セッションの中断中にメディアストリームがパケットを送受信できる場合があります。 他の人はそうではないかもしれません。 したがって、RFC 3312の次の段落はQoSの前提条件にのみ適用されます。
While session establishment is suspended, user agents SHOULD not send any data over any media stream. In the case of RTP, neither RTP nor RTCP packets are sent.
セッションの確立が一時停止されている間、ユーザーエージェントはメディアストリームを介してデータを送信しないでください。 RTPの場合、RTPパケットもRTCPパケットも送信されません。
To clarify the previous paragraph, the control messages used to establish connections in connection-oriented transport protocols (e.g., TCP SYNs) are not affected by the previous rule. So, user agents follow standard rules (e.g., the SDP 'setup' attribute [7]) to decide when to establish the connection, regardless of QoS preconditions.
前の段落を明確にするために、接続指向のトランスポートプロトコル（TCP TCPなど）で接続を確立するために使用される制御メッセージは、前のルールの影響を受けません。 そのため、ユーザーエージェントは、QoSの前提条件に関係なく、標準ルール（SDPの「セットアップ」属性[7]など）に従って接続を確立するタイミングを決定します。
New precondition types MUST also describe the behaviour of UAs on reception of a re-INVITE or an UPDATE with preconditions for an ongoing session.
新しい前提条件タイプは、進行中のセッションの前提条件を備えたre-INVITEまたはUPDATEの受信時のUAの動作も記述しなければなりません。
Section 5 of RFC 3312 describes how to use SIP [2] preconditions with the offer/answer model [4]. RFC 3312 gives a set of rules that allow a user agent to communicate changes in the current status of the preconditions to the remote user agent.
RFC 3312のセクション5では、オファー/アンサーモデル[4]でSIP [2]前提条件を使用する方法について説明しています。 RFC 3312は、ユーザーエージェントが前提条件の現在の状態の変化をリモートユーザーエージェントに伝達できるようにする一連のルールを提供します。
The idea is that a given user agent knows about the current status of some part of the preconditions (e.g., send direction of the QoS precondition) through local information (e.g., an RSVP RESV is received indicating that resource reservation was successful). The UAC (User Agent Client) informs the UAS (User Agent Server) about changes in the current status by sending an offer to the UAS. The UAS, in turn, could (if needed) send an offer to the UAC informing it about the status of the part of the preconditions the UAS has local information about.
アイデアは、特定のユーザーエージェントが、ローカル情報（たとえば、リソース予約が成功したことを示すRSVP RESVを受信する）を通じて、前提条件の一部（たとえば、QoS前提条件の送信方向）の現在の状態を知っているということです。 UAC（ユーザーエージェントクライアント）は、UASにオファーを送信することにより、現在のステータスの変化についてUAS（ユーザーエージェントサーバー）に通知します。 UASは、（必要に応じて）UACにローカル情報を持っている前提条件の一部のステータスについて通知するオファーをUACに送信できます。
Note, however, that UASs do not usually send updates about the current status to the UAC because UASs are the ones resuming session establishment when all the preconditions are met. Therefore, rather than performing an offer/answer exchange to inform the UAC that all the preconditions are met, they simply send a 180 (Ringing) response indicating that session establishment has been resumed.
ただし、UASはすべての前提条件が満たされたときにセッションの確立を再開するため、UASは通常、現在のステータスに関する更新をUACに送信しないことに注意してください。 したがって、オファー/アンサー交換を実行してすべての前提条件が満たされていることをUACに通知するのではなく、セッション確立が再開されたことを示す180（Ringing）応答を送信します。
While RFC 3312 allows updating current status information using the methods described above, it does not allow downgrading current status values in answers, as shown in the third row of Table 3 of RFC 3312. Figure 1 shows how performing such a downgrade in an answer would sometimes be needed.
RFC 3312では、上記の方法を使用して現在のステータス情報を更新できますが、RFC 3312の表3の3行目に示すように、回答内の現在のステータス値をダウングレードすることはできません。 時々必要です。
3pcc
A Controller B C
| | | |
|<-dialog 1->|<-dialog 2->| |
| | | |
| *********************** | |
|* MEDIA *| |
| *********************** | |
| | | |
| | | |
|<-dialog 1->|<------dialog 3----->|
| | | |
| ******************************** |
|* MEDIA *|
| ******************************** |
| | | |
| | | |
Figure 1: Session mobility using 3pcc
図1：3pccを使用したセッションモビリティ
The 3pcc (Third Party Call Control) [6] controller in Figure 1 has established a session between A and B using dialog 1 towards A and dialog 2 towards B. At that point, the controller wants A to have a session with C instead of B. To transfer A to C (configuration shown at the bottom of Figure 1), the controller sends an empty (no offer) re-INVITE to A. Since A does not know that the session will be moved, its offer in the 200 OK states that the current status of the media stream in the send direction is "Yes". After contacting C establishing dialog 3, the controller sends back an answer to A. This answer contains a new destination for the media (C) and should have downgraded the current status of the media stream to "No", since there is no reservation of resources between A and C.
図1の3pcc（Third Party Call Control）[6]コントローラーは、Aに向かってダイアログ1、Bに向かってダイアログ2を使用してAとBの間にセッションを確立しました。その時点で、コントローラーは B. AをCに転送するため（図1の下部に示す構成）、コントローラーは空の（オファーなし）re-INVITEをAに送信します。Aはセッションが移動されることを認識していないため、200 OKは、送信方向のメディアストリームの現在のステータスが「はい」であることを示します。 Cにダイアログ3を確立した後、コントローラーはAに回答を返します。この回答には、メディア（C）の新しい宛先が含まれ、メディアストリームの現在のステータスを「No」にダウングレードする必要があります。 AとCの間のリソース
Below is a set of new rules that update RFC 3312 to address the issues above.
以下は、RFC 3312を更新して上記の問題に対処する一連の新しいルールです。
The rule below applies to offerers moving a media stream to a new address:
以下のルールは、メディアストリームを新しいアドレスに移動する提供者に適用されます。
When a stream is being moved to a new transport address, the offerer MUST set all current status values about which it does not have local information about to "No".
ストリームを新しいトランスポートアドレスに移動する場合、提供者は、ローカル情報を持たない現在のすべてのステータス値を「いいえ」に設定する必要があります。
Note that for streams using segmented status (as opposed to end-to-end status), the fact that the address for the media stream at the local segment changes may or may not affect the status of preconditions at the remote segment. However, moving an existing stream to a new location, from the preconditions point of view, is like establishing a new stream. Therefore, it is appropriate to set all the current status values to "No" and start a new precondition negotiation from scratch.
エンドツーエンドステータスではなく、セグメント化されたステータスを使用するストリームの場合、ローカルセグメントのメディアストリームのアドレスが変更されるという事実は、リモートセグメントの前提条件のステータスに影響する場合と影響しない場合があります。 ただし、前提条件の観点から、既存のストリームを新しい場所に移動することは、新しいストリームを確立するようなものです。 したがって、すべての現在のステータス値を「いいえ」に設定し、新しい前提条件ネゴシエーションを最初から開始することが適切です。
The updated table and rules below apply to an answerer that is moving a media stream. The offerer was not aware of the move when it generated the offer.
以下の更新された表と規則は、メディアストリームを移動している回答者に適用されます。 申し出人は、申し出を生成したとき、その動きを認識していませんでした。
Table 3 of RFC 3312 needs to be updated to allow answerers to downgrade current status values. The following table shows the result.
回答者が現在のステータス値をダウングレードできるようにするには、RFC 3312の表3を更新する必要があります。 次の表に結果を示します。
Transac status table Local status table New values transac./local
____________________________________________________________________
no no no/no
yes yes yes/yes
yes no depends on local info
no yes depends on local info
An answerer MUST downgrade the current status values received in the offer if it has local information about them or if the media stream is being moved to a new transport address.
回答者は、オファーに関するローカル情報がある場合、またはメディアストリームが新しいトランスポートアドレスに移動される場合、オファーで受信した現在のステータス値をダウングレードする必要があります。
Note that for streams using segmented status, the address change at the answerer may or may not affect the status of the preconditions at the offerer's segment. However, as stated above, moving an existing stream to a new location, from the preconditions point of view, is like establishing a new stream. Therefore, it is appropriate to set all the current status values to "No" and start a new precondition negotiation from scratch.
セグメント化されたステータスを使用するストリームの場合、回答者でのアドレス変更は、提供者のセグメントでの前提条件のステータスに影響する場合と影響しない場合があります。 ただし、前述のように、前提条件の観点から、既存のストリームを新しい場所に移動することは、新しいストリームを確立するようなものです。 したがって、すべての現在のステータス値を「いいえ」に設定し、新しい前提条件ネゴシエーションを最初から開始することが適切です。
The new table below applies to an offerer that receives an answer that updates or downgrades its local status tables.
以下の新しい表は、ローカルステータステーブルを更新またはダウングレードする回答を受け取る提供者に適用されます。
Offerers should update their local status tables when they receive an answer as shown in the following table.
提供者は、次の表に示すように回答を受け取ったら、ローカルステータステーブルを更新する必要があります。
Transac. status table Local status table New value Local Status
_________________________________________________________________
no no no
yes yes yes
yes no yes
no yes no
The desired status that a UA wants for a media stream after the stream is moved to a new transport address may be different than the desired status negotiated for the stream originally. A UA, for instance, may require mandatory QoS over a low bandwidth link but be satisfied with optional QoS when the stream is moved to a high bandwidth link.
ストリームが新しいトランスポートアドレスに移動された後、UAがメディアストリームに必要とする望ましいステータスは、元々ストリームに対してネゴシエートされた望ましいステータスとは異なる場合があります。 たとえば、UAは、低帯域幅リンクで必須のQoSを必要とする場合がありますが、ストリームが高帯域幅リンクに移動されると、オプションのQoSで満足する場合があります。
If the new desired status is higher than the previous one (e.g., optional to mandatory), the UA, following RFC 3312 procedures, may upgrade its desired status in an offer or in an answer. If the new desired status is lower that the previous one (i.e., mandatory to optional), the UA, following RFC 3312 procedures as well, may downgrade its desired status only in an offer (i.e., not in an answer.)
新しい希望するステータスが前のステータスよりも高い場合（たとえば、オプションから必須）、UAは、RFC 3312の手順に従って、オファーまたはアンサーで希望するステータスをアップグレードできます。 新しい望ましいステータスが以前のステータスよりも低い場合（つまり、必須からオプション）、UAは、RFC 3312の手順に従って、オファーでのみ（つまり、回答ではなく）望ましいステータスをダウングレードする場合があります
An attacker adding preconditions to a session description or modifying existing preconditions could prevent establishment of sessions. An attacker removing preconditions from a session description could force sessions to be established without meeting mandatory preconditions.
攻撃者は、セッションの説明に前提条件を追加したり、既存の前提条件を変更したりして、セッションの確立を妨げる可能性があります。 攻撃者がセッションの説明から前提条件を削除すると、必須の前提条件を満たさずにセッションが強制的に確立される可能性があります。
Thus, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [2].
したがって、整合性保護をSDPセッションの説明に適用することを強くお勧めします。 S / MIMEは、RFC 3261 [2]で説明されているように、このようなエンドツーエンドの整合性保護を提供する自然な選択です。
The IANA registration requirements for the preconditions framework are defined in RFC 3312. Any new preconditions are governed by the IANA Considerations there.
前提条件フレームワークのIANA登録要件は、RFC 3312で定義されています。新しい前提条件は、IANAの考慮事項によって管理されています。
Dave Oran and Allison Mankin provided useful comments on this document.
デイブ・オランとアリソン・マンキンは、このドキュメントに関する有用なコメントを提供しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[3] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[3]カマリロ、G。、マーシャル、W。、およびJ.ローゼンバーグ、「リソース管理とセッション開始プロトコル（SIP）の統合」、RFC 3312、2002年10月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、2002年6月。
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[5]ローゼンバーグ、J。、「セッション開始プロトコル（SIP）更新メソッド」、RFC 3311、2002年10月。
[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[6] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、2004年4月。
[7] Yon, D. and Camarillo, G., "TCP-Based Media Transport in the Session Description Protocol (SDP)", Work In Progress, November 2004.
[7] Yon、D。およびCamarillo、G。、「セッション記述プロトコル（SDP）でのTCPベースのメディアトランスポート」、Work In Progress、2004年11月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール：Gonzalo.Camarillo@ericsson.com
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue, BXB500 C2-2 Boxborough, MA 01719 USA
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue、BXB500 C2-2 Boxborough、MA 01719 USA
EMail: pkyzivat@cisco.com
メール：pkyzivat@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（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.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。