[要約] RFC 4032は、SIPの事前条件フレームワークの更新を提供しています。その目的は、SIPセッションの事前条件の管理と制御を改善することです。
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
セッション開始プロトコル（SIP）Preconditionsフレームワークの更新
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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 UAS（ユーザーエージェント）が一連の前提条件が満たされるまでセッションの確立を一時停止できる一般的なフレームワークです。これまでにサービス品質（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は、セッションのモビリティ、つまり再インバイトと更新を提供するメカニズムを提供します[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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、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では、これらの前提条件が満たされたときに再開されるまで、一連の前提条件により、モーメントセッションの確立からのUASの動作について説明します。一般に、前提条件が満たされるまで、呼び出されたユーザーは警告されません。
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:
ユーザーに警告しないことに加えて、各前提条件タイプは、セッションの確立が中断されたときに、UASが実行するか、実行しないようにするか、実行することを控える必要がある追加のアクションを定義する必要があります。したがって、セッション停止中のメディアストリームの動作は、特定の前提条件タイプの定義の一部です。一部の前処理タイプにより、メディアストリームはセッション停止中にパケットを送信および受信できる場合があります。他の人はそうではないかもしれません。その結果、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 Synなど）の接続を確立するために使用される制御メッセージは、前のルールの影響を受けません。したがって、ユーザーエージェントは標準ルール（例：SDP 'セットアップ'属性[7]）に従って、QoSの前提条件に関係なく、接続を確立するタイミングを決定します。
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.
また、新しい前提条件タイプは、継続的なセッションのための再インバイトの受信または更新時のUASの動作を記述する必要があります。
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では、SIP [2]前提条件をオファー/回答モデル[4]で使用する方法について説明します。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.
特定のユーザーエージェントは、ローカル情報を通じて前提条件の一部の現在のステータス（QoS前処理の指示を送信する）を知っているということです（たとえば、RSVP RESVが受信され、リソースの予約が成功したことを示します）。UAC（ユーザーエージェントクライアント）は、UASにオファーを送信することにより、現在のステータスの変更についてUAS（ユーザーエージェントサーバー）に通知します。順番に、UASは（必要に応じて）UACにオファーを送信して、UASがローカル情報を持っている前提条件のステータスについて通知することができます。
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.
ただし、UASSは通常、すべての前提条件が満たされたときにセッション設立を再開するものであるため、UASは通常、現在のステータスに関する更新をUACに送信しないことに注意してください。したがって、すべての前提条件が満たされていることをUACに通知するためにオファー/回答の交換を実行するのではなく、セッションの確立が再開されたことを示す180（リンギング）応答を送信するだけです。
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
3PCC Aコントローラー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（サードパーティのコールコントロール）[6]コントローラーは、AとBにダイアログ1を使用してBに向かってダイアログ2を使用してAとBの間のセッションを確立しました。B. aをC（図1の下部に表示する構成）に転送するには、コントローラーは空の（オファーなし）re inviteをAに送信します。OKは、送信方向のメディアストリームの現在のステータスは「はい」であると述べています。ダイアログ3の確立Cに連絡した後、コントローラーはAへの回答を送り返します。この回答には、メディアの新しい目的地が含まれており（c）、メディアストリームの現在のステータスを「いいえ」に格下げする必要があります。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.)
新しい希望のステータスが前のステータスよりも高い場合（例：必須からオプション）、RFC 3312手順に続くUAは、オファーまたは回答でその目的のステータスをアップグレードすることができます。新しい目的のステータスが以前のステータス（つまり、オプションに必須）が低い場合、RFC 3312手順に続くUAも、オファーでのみ目的のステータスを格下げする可能性があります（つまり、回答ではありません。）
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.
Preconditionsフレームワークの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 INIATIATION 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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（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] Rosenberg、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）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[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ベースのメディアトランスポート」、2004年11月、Work in Progress。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。