[要約] RFC 4538は、SIPにおけるダイアログ識別を通じた要求認証に関する規格です。その目的は、SIPセッション中の要求の正当性を確保し、セキュリティを向上させることです。
Network Working Group J. Rosenberg
Request for Comments: 4538 Cisco Systems
Category: Standards Track June 2006
Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）でのダイアログ識別による承認を要求する
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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness.
この仕様は、セッション開始プロトコル（SIP）のターゲットダイアログヘッダーフィールドと、対応するオプションタグTdialogを定義します。このヘッダーフィールドは、SIPダイアログを作成するリクエストで使用されます。これは、送信者がそのダイアログの反対側にあるか、ダイアログ識別子にアクセスできるため、送信者が受信者との既存のダイアログを認識していることを受信者に示します。その後、受信者はこの認識に基づいてリクエストを承認できます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview of Operation ...........................................4
3. User Agent Client (UAC) Behavior ................................5
4. User Agent Server Behavior ......................................7
5. Proxy Behavior ..................................................8
6. Extensibility Considerations ....................................8
7. Header Field Definition .........................................9
8. Security Considerations .........................................9
9. Relationship with In-Reply-To ..................................10
10. Example Call Flow .............................................10
11. IANA Considerations ...........................................13
11.1. Header Field .............................................13
11.2. Header Field Parameters ..................................13
11.2.1. local-tag .........................................13
11.2.2. remote-tag ........................................13
11.3. SIP Option Tag ...........................................14
12. Acknowledgements ..............................................14
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................15
The Session Initiation Protocol (SIP) [2] defines the concept of a dialog as a persistent relationship between a pair of user agents. Dialogs provide context, including sequence numbers, proxy routes, and dialog identifiers. Dialogs are established through the transmission of SIP requests with particular methods. Specifically, the INVITE, REFER [8], and SUBSCRIBE [3] requests all create dialogs.
セッション開始プロトコル（SIP）[2]は、ダイアログの概念を、ユーザーエージェントのペア間の永続的な関係として定義しています。ダイアログは、シーケンス番号、プロキシルート、ダイアログ識別子などのコンテキストを提供します。ダイアログは、特定の方法を使用したSIPリクエストの送信によって確立されます。具体的には、招待、参照[8]、および購読[3]要求はすべて、すべてのダイアログを作成します。
When a user agent receives a request that creates a dialog, it needs to decide whether to authorize that request. For some requests, authorization is a function of the identity of the sender, the request method, and so on. However, many situations have been identified in which a user agent's authorization decision depends on whether the sender of the request is currently in a dialog with that user agent, or whether the sender of the request is aware of a dialog the user agent has with another entity.
ユーザーエージェントがダイアログを作成するリクエストを受信した場合、そのリクエストを承認するかどうかを決定する必要があります。一部のリクエストでは、承認は、送信者の身元、リクエスト方法などの関数です。ただし、ユーザーエージェントの承認決定が、リクエストの送信者が現在そのユーザーエージェントとのダイアログにあるかどうか、またはリクエストの送信者がユーザーエージェントが別のダイアログを認識しているかどうかに依存する多くの状況が特定されています。実在物。
One such example is call transfer, accomplished through REFER. If user agents A and B are in an INVITE dialog, and user agent A wishes to transfer user agent B to user agent C, user agent A needs to send a REFER request to user agent B, asking user agent B to send an INVITE request to user agent C. User agent B needs to authorize this REFER. The proper authorization decision is that user agent B should accept the request if it came from a user with whom B currently has an INVITE dialog relationship. Current implementations deal with this by sending the REFER on the same dialog as the one in place between user agents A and B. However, this approach has numerous problems [12]. These problems include difficulties in determining the lifecycle of the dialog and its usages and in determining which messages are associated with each application usage. Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog. In that case, a means is needed for user agent B to authorize the REFER.
そのような例の1つは、紹介を通じて達成されるコール転送です。ユーザーエージェントAとBが招待状のダイアログで、ユーザーエージェントAがユーザーエージェントBをユーザーエージェントCに転送したい場合、ユーザーエージェントAはユーザーエージェントBに紹介リクエストを送信する必要があります。ユーザーエージェントCへ。ユーザーエージェントBは、この紹介を承認する必要があります。適切な承認の決定は、ユーザーエージェントBが現在招待されたダイアログ関係を持っているユーザーから来た場合、リクエストを受け入れる必要があることです。現在の実装は、ユーザーエージェントAとBの間にあるダイアログと同じダイアログで紹介を送信することにより、これに対処しますが、このアプローチには多くの問題があります[12]。これらの問題には、ダイアログのライフサイクルとその使用法を決定し、各アプリケーションの使用に関連付けられているメッセージを決定する際の困難が含まれます。代わりに、より良いアプローチは、ユーザーエージェントAがダイアログ外でユーザーエージェントBに紹介要求を送信することです。その場合、ユーザーエージェントBが紹介を承認するために手段が必要です。
Another example is the application interaction framework [14]. In that framework, proxy servers on the path of a SIP INVITE request can place user interface components on the user agent that generated or received the request. To do this, the proxy server needs to send a REFER request to the user agent, targeted to its Globally Routable User Agent URI (GRUU) [13], asking the user agent to fetch an HTTP resource containing the user interface component. In such a case, a means is needed for the user agent to authorize the REFER. The application interaction framework recommends that the request be authorized if it was sent from an entity on the path of the original dialog. This can be done by including the dialog identifiers in the REFER, which prove that the user agent that sent the REFER is aware of those dialog identifiers (this needs to be secured against eavesdroppers through the sips mechanism, of course).
別の例は、アプリケーションインタラクションフレームワークです[14]。そのフレームワークでは、SIP Inviteリクエストのパス上のプロキシサーバーは、リクエストを生成または受信したユーザーエージェントにユーザーインターフェイスコンポーネントを配置できます。これを行うには、プロキシサーバーは、グローバルにルーティング可能なユーザーエージェントURI（GRUU）[13]をターゲットにしたユーザーエージェントに紹介要求を送信する必要があります。そのような場合、ユーザーエージェントが紹介を承認するために手段が必要です。アプリケーションインタラクションフレームワークでは、元のダイアログのパス上のエンティティから送信された場合、リクエストが承認されることを推奨します。これは、紹介にダイアログ識別子を含めることで実行できます。これは、紹介を送信したユーザーエージェントがそれらのダイアログ識別子を認識していることを証明します（もちろん、これはSIPSメカニズムを介して盗聴者に対して保護する必要があります）。
Another example is if two user agents share an INVITE dialog, and an element on the path of the INVITE request wishes to track the state of the INVITE. In such a case, it sends a SUBSCRIBE request to the GRUU of the user agent, asking for a subscription to the dialog event package. If the SUBSCRIBE request came from an element on the INVITE request path, it should be authorized.
別の例は、2人のユーザーエージェントが招待状のダイアログを共有している場合、および招待リクエストのパス上の要素が招待状の状態を追跡したい場合です。そのような場合、それはユーザーエージェントのGruuにサブスクライブリクエストを送信し、ダイアログイベントパッケージのサブスクリプションを要求します。購読要求が招待要求パスの要素から来た場合、それは承認されるべきです。
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 RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
+--------+ +--------+
| | INVITE | |
| Server |----------->| Server |
| A | | B |
| |...........>| |
+--------+ +--------+
^ REFER . \
/ . \
/ . \
/ . \
/ . \
/ V V
+--------+ +--------+
| | | |
| User | | User |
| Agent | | Agent |
| A | | B |
+--------+ +--------+
Figure 1
図1
Figure 1 shows the basic model of operation. User agent A sends an INVITE to user agent B, traversing two servers, server A and server B. Both servers act as proxies for this transaction. User B sends a 200 OK response to the INVITE. This 200 OK includes a Supported header field indicating support for this specification (through the presence of the tdialog option tag). The 200 OK response establishes a dialog between the two user agents.
図1は、操作の基本モデルを示しています。ユーザーエージェントAは、ユーザーエージェントBに招待を送信し、2つのサーバー、サーバーAとサーバーBを通過します。両方のサーバーは、このトランザクションのプロキシとして機能します。ユーザーBは、招待に200のOK応答を送信します。この200 OKには、この仕様のサポートを示すサポートされているヘッダーフィールドが含まれています（TDialogオプションタグの存在を通じて）。200 OK応答は、2つのユーザーエージェント間のダイアログを確立します。
Next, an entity that was present along the request path (server A, for example) wishes to send a dialog-forming request (such as REFER) to user agent A or B (user B for example). So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the URI of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. If this URI has the GRUU [11] property (it can be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE), then the mechanism will work across NAT boundaries.
次に、リクエストパスに沿って存在していたエンティティ（サーバーAなど）は、ユーザーエージェントAまたはB（ユーザーBなど）にダイアログ形成リクエスト（参照など）を送信したいと考えています。したがって、エンティティはユーザーエージェントとして機能し、リクエストをユーザーエージェントBに送信します。このリクエストは、ユーザーエージェントBのURIに宛てられます。このURIにgruu [11]プロパティ（サーバーAなどのインターネット上の任意の要素が使用できる場合、招待者に200 OKを生成した特定のユーザーエージェントインスタンスに到達するため）は、メカニズムが機能します。NAT境界。
The request generated by server A will contain a Target-Dialog header field. This header field contains the dialog identifiers for the INVITE dialog between user agents A and B, composed of the Call-ID, local tag, and remote tag. Server A knew to include the Target-Dialog header field in the REFER request because it knows that user agent B supports it.
サーバーAによって生成された要求には、ターゲットダイアログヘッダーフィールドが含まれます。このヘッダーフィールドには、ユーザーエージェントAとBの間の招待ダイアログのダイアログ識別子が含まれています。サーバーAは、ユーザーエージェントBがサポートしていることを知っているため、regureリクエストにターゲットダイアログヘッダーフィールドを含めることを知っていました。
When the request arrives at user agent B, it needs to make an authorization decision. Because the INVITE dialog was established using a sips URI, and because the dialog identifiers are cryptographically random [2], no entity except for user agent A or the proxies on the path of the initial INVITE request can know the dialog identifiers. Thus, because the request contains those dialog identifiers, user agent B can be certain that the request came from user agent A, the two proxies, or an entity to whom the user agent or proxies gave the dialog identifiers. As such, it authorizes the request and performs the requested actions.
リクエストがユーザーエージェントBに到着すると、許可決定を下す必要があります。招待ダイアログはSIPS URIを使用して確立されたため、ダイアログ識別子は暗号化的にランダム[2]であるため、ユーザーエージェントAまたは最初の招待要求のパス上のプロキシを除くエンティティはダイアログ識別子を知ることはできません。したがって、リクエストにはこれらのダイアログ識別子が含まれているため、ユーザーエージェントBは、リクエストがユーザーエージェントA、2つのプロキシ、またはユーザーエージェントまたはプロキシがダイアログ識別子に与えたエンティティから来たことを確信できます。そのため、リクエストを許可し、要求されたアクションを実行します。
A UAC SHOULD include a Target-Dialog header field in a request if the following conditions are all true:
UACには、次の条件がすべて真である場合は、ターゲットダイアログヘッダーフィールドをリクエストに含める必要があります。
1. The request is to be sent outside of any existing dialog.
1. リクエストは、既存のダイアログの外部で送信されます。
2. The user agent client believes that the request may not be authorized by the user agent server unless the user agent client can prove that it is aware of the dialog identifiers for some other dialog. Call this dialog the target dialog.
2. ユーザーエージェントクライアントは、ユーザーエージェントクライアントが他のダイアログのダイアログ識別子を認識していることを証明できない限り、リクエストがユーザーエージェントサーバーによって許可されない可能性があると考えています。このダイアログをターゲットダイアログと呼びます。
3. The request does not otherwise contain information that indicates that the UAC is aware of those dialog identifiers.
3. それ以外の場合、リクエストには、UACがこれらのダイアログ識別子を認識していることを示す情報は含まれていません。
4. The user agent client knows that the user agent server supports the Target-Dialog header field. It can know this if it has seen a request or response from the user agent server within the target dialog that contained a Supported header field that included the tdialog option tag.
4. ユーザーエージェントクライアントは、ユーザーエージェントサーバーがターゲットダイアログヘッダーフィールドをサポートしていることを知っています。TDialogオプションタグを含むサポートされているヘッダーフィールドを含むターゲットダイアログ内のユーザーエージェントサーバーからのリクエストまたは応答が表示されている場合、これを知ることができます。
If the fourth condition is not met, the UAC SHOULD NOT use this specification. Instead, if it is currently within a dialog with the User Agent Server (UAS), it SHOULD attempt to send the request within the existing target dialog.
4番目の条件が満たされていない場合、UACはこの仕様を使用しないでください。代わりに、現在、ユーザーエージェントサーバー（UAS）とのダイアログ内にある場合、既存のターゲットダイアログ内でリクエストを送信しようとする必要があります。
The following are examples of use cases in which these conditions are met:
以下は、これらの条件が満たされているユースケースの例です。
o A REFER request is sent according to the principles of [14]. These REFER are sent outside of a dialog and do not contain any other information that indicates awareness of the target dialog. [14] also mandates that the REFER be sent only if the UA indicates support for the target dialog specification.
o [14]の原則に従って参照要求が送信されます。これらの参照はダイアログの外部で送信され、ターゲットダイアログの認識を示す他の情報は含まれていません。[14]は、UAがターゲットダイアログ仕様のサポートを示している場合にのみ、紹介が送信されることを義務付けています。
o User A is in separate calls with users B and C. User A decides to start a three way call, and so morphs into a focus [17]. User B would like to learn the other participants in the conference. So, it sends a SUBSCRIBE request to user A (who is now acting as the focus) for the conference event package [16]. It is sent outside of the existing dialog between user B and the focus, and it would be authorized by A if user B could prove that it knows the dialog identifiers for its existing dialog with the focus. Thus, the Target-Dialog header field would be included in the SUBSCRIBE.
o ユーザーAは、ユーザーBとC.と個別の呼び出しであり、ユーザーAは3ウェイコールを開始することを決定し、そのためフォーカスに変形します[17]。ユーザーBは、会議の他の参加者を学びたいと考えています。そのため、会議イベントパッケージ[16]のユーザーA（現在はフォーカスとして機能している）に購読リクエストを送信します。ユーザーBとフォーカスの間の既存のダイアログの外に送信され、A Aによって承認されます。ユーザーBは、フォーカスを備えた既存のダイアログのダイアログ識別子を知っていることを証明できます。したがって、ターゲットダイアログヘッダーフィールドはサブスクライブに含まれます。
The following are examples of use cases in which these conditions are not met:
以下は、これらの条件が満たされないユースケースの例です。
o A server acting as a proxy is a participant in an INVITE dialog that establishes a session. The server would like to use the Keypad Markup Language (KPML) event package [18] to find out about keypresses from the originating user agent. To do this, it sends a SUBSCRIBE request. However, the Event header field of this SUBSCRIBE contains event parameters that indicate the target dialog of the subscription. As such, the request can be authorized without additional information.
o プロキシとして機能するサーバーは、セッションを確立する招待ダイアログの参加者です。サーバーは、キーパッドマークアップ言語（KPML）イベントパッケージ[18]を使用して、元のユーザーエージェントのキープレスについて調べたいと考えています。これを行うには、購読リクエストを送信します。ただし、このサブスクライブのイベントヘッダーフィールドには、サブスクリプションのターゲットダイアログを示すイベントパラメーターが含まれています。そのため、リクエストは追加情報なしで承認できます。
o A server acting as a proxy is a participant in an INVITE dialog that establishes a session. The server would like to use the dialog event package [15] to find out about dialogs at the originating user agent. To do this, it sends a SUBSCRIBE request. However, the Event header field of this SUBSCRIBE contains event parameters that indicate the target dialog of the subscription.
o プロキシとして機能するサーバーは、セッションを確立する招待ダイアログの参加者です。サーバーは、ダイアログイベントパッケージ[15]を使用して、元のユーザーエージェントでのダイアログについて調べたいと考えています。これを行うには、購読リクエストを送信します。ただし、このサブスクライブのイベントヘッダーフィールドには、サブスクリプションのターゲットダイアログを示すイベントパラメーターが含まれています。
As such, the request can be authorized without additional information.
そのため、リクエストは追加情報なしで承認できます。
Specifications that intend to make use of the Target-Dialog header field SHOULD discuss specific conditions in which it is to be included.
ターゲットダイアログヘッダーフィールドを使用することを意図した仕様は、含めるべき特定の条件を議論する必要があります。
Assuming it is to be included, the value of the callid production in the Target-Dialog header field MUST be equal to the Call-ID of the target dialog. The "remote-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the remote tag from the perspective of the recipient of the new request. The "local-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the local tag from the perspective of the recipient of the new request.
含めると仮定すると、ターゲットダイアログヘッダーフィールドでのCallID生産の値は、ターゲットダイアログのコールIDと等しくなければなりません。「リモートタグ」ヘッダーフィールドパラメーターが存在する必要があり、新しいリクエストの受信者の観点からリモートタグとして表示されるタグを含める必要があります。「ローカルタグ」ヘッダーフィールドパラメーターが存在する必要があり、新しいリクエストの受信者の観点からローカルタグとして表示されるタグを含める必要があります。
The request sent by the UAC SHOULD include a Require header field that includes the tdialog option tag. This request should, in principle, never fail with a 420 (Bad Extension) response, because the UAC would not have sent the request unless it believed the UAS supported the extension. If a Require header field was not included, and the UAS didn't support the extension, it would normally reject the request because it was unauthorized, probably with a 403. However, without the Require header field, the UAC would not be able to differentiate between the following:
UACから送信された要求には、TDialogオプションタグを含む要求ヘッダーフィールドを含める必要があります。このリクエストは、原則として、UASが拡張機能をサポートしているとは思わない限り、UACがリクエストを送信しなかったため、420（拡張機能）応答で失敗しないでください。必要なヘッダーフィールドが含まれておらず、UASが拡張機能をサポートしなかった場合、おそらく403で不正であるため、通常、リクエストを拒否します。以下を区別します。
o a 403 that arrived because the UAS didn't actually understand the Target-Dialog header field (in which case the client should send the request within the target dialog if it can)
o UASがターゲットダイアログヘッダーフィールドを実際に理解していなかったために到着した403
o a 403 that arrived because the UAS understood the Target-Dialog header field, but elected not to authorize the request despite the fact that the UAC proved its awareness of the target dialog (in which case the client should not resend the request within the target dialog, even if it could).
o UASがTarget-Dialogヘッダーフィールドを理解したために到着した403は、UACがターゲットダイアログの認識を証明したという事実にもかかわらず、リクエストを承認しないことを選択しました（その場合、クライアントはターゲットダイアログ内でリクエストを再送信してはなりません、たとえ可能であっても）。
If a user agent server receives a dialog-creating request and wishes to authorize the request, and if that authorization depends on whether or not the sender has knowledge of an existing dialog with the UAS, and information outside of the Target-Dialog header field does not provide proof of this knowledge, the UAS SHOULD check the request for the existence of the Target-Dialog header field. If this header field is not present, the UAS MAY still authorize the request by other means.
ユーザーエージェントサーバーがダイアログ作成リクエストを受信し、リクエストを承認したい場合、およびその承認が、送信者がUASとの既存のダイアログの知識を持っているかどうか、およびターゲットダイアログヘッダーフィールドの外側の情報を持っているかどうかに依存する場合この知識の証拠を提供しないでください。UASは、ターゲットダイアログヘッダーフィールドの存在の要求を確認する必要があります。このヘッダーフィールドが存在しない場合、UASは他の手段で要求を承認する場合があります。
If the header field is present, and the value of the callid production, the "remote-tag", and "local-tag" values match the Call-ID, remote tag, and local tag of an existing dialog, and the dialog that they match was established using a sips URI, the UAS SHOULD authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog.
ヘッダーフィールドが存在し、CallID生産の値が存在する場合、「リモートタグ」と「ローカルタグ」値は、既存のダイアログのコールアイド、リモートタグ、およびローカルタグ、およびダイアログと一致します。SIPS URIを使用してマッチが確立され、UASは、そのダイアログを作成したリクエストのパス上のエンティティ、またはそのダイアログを作成したリクエストのパスでエンティティによって信頼されるエンティティを承認する場合、リクエストを承認する必要があります。
If the dialog identifiers match, but they match a dialog not created with a sips URI, the UAS MAY authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog. However, in this case, any eavesdropper on the original dialog path would have access to the dialog identifiers, and thus the authorization is optional.
ダイアログ識別子が一致しているが、SIPS URIで作成されていないダイアログと一致する場合、UASは、そのダイアログを作成したリクエストのパスでエンティティを許可する場合、または、そのダイアログを作成したリクエストのパス。ただし、この場合、元のダイアログパス上の盗聴者はダイアログ識別子にアクセスできるため、許可はオプションです。
If the dialog identifiers don't match, or if they don't contain both a "remote-tag" and "local-tag" parameter, the header field MUST be ignored, and authorization MAY be determined by other means.
ダイアログ識別子が一致しない場合、または「リモートタグ」と「ローカルタグ」パラメーターの両方が含まれていない場合、ヘッダーフィールドは無視する必要があり、許可は他の手段によって決定される場合があります。
Proxy behavior is unaffected by this specification.
プロキシの動作は、この仕様の影響を受けません。
This specification depends on a user agent client knowing, ahead of sending a request to a user agent server, whether or not that user agent server supports the Target-Dialog header field. As discussed in Section 3, the UAC can know this because it saw a request or response sent by that UAS within the target dialog that contained the Supported header field whose value included the tdialog option tag.
この仕様は、ユーザーエージェントサーバーにリクエストを送信する前に、ユーザーエージェントサーバーがターゲットダイアログヘッダーフィールドをサポートするかどうかにかかわらず、ユーザーエージェントクライアントに依存します。セクション3で説明したように、UACはこれを知ることができます。これは、TDialogオプションタグを含む値を含むサポートされているヘッダーフィールドを含むターゲットダイアログ内のUASから送信されたリクエストまたは応答を見たためです。
Because of this requirement, it is especially important that user agents compliant to this specification include a Supported header field in all dialog forming requests and responses. Inclusion of the Supported header fields in requests is at SHOULD strength per RFC 3261. This specification does not alter that requirement. However, implementers should realize that, unless the tdialog option tag is placed in the Supported header field of requests and responses, this extension is not likely to be used, and instead, the request is likely to be re-sent within the existing target dialog (assuming the sender is the UA on the other side of the target dialog). As such, the conditions in which the SHOULD would not be followed would be those rare cases in which the UA does not want to enable usage of this extension.
この要件のため、この仕様に準拠したユーザーエージェントには、すべてのダイアログのリクエストと応答を形成するすべてのダイアログにサポートされているヘッダーフィールドが含まれることが特に重要です。リクエストにサポートされているヘッダーフィールドを含めることは、RFC 3261あたりの強度になります。この仕様はその要件を変更しません。ただし、実装者は、TDialogオプションタグがリクエストと応答のサポートされているヘッダーフィールドに配置されていない限り、この拡張機能が使用される可能性が高く、代わりに、リクエストが既存のターゲットダイアログ内で再配置される可能性が高いことを認識する必要があります。（送信者がターゲットダイアログの反対側のUAであると仮定）。そのため、従わない条件は、UAがこの拡張機能の使用を有効にしたくないまれな場合です。
The grammar for the Target-Dialog header field is defined as follows:
ターゲットダイアログヘッダーフィールドの文法は、次のように定義されています。
Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI
td-param) ;callid from RFC 3261
td-param = remote-param / local-param /
generic-param
remote-param = "remote-tag" EQUAL token
local-param = "local-tag" EQUAL token
;token and generic-param from RFC 3261
Figures 3 and 4 are an extension of Tables 2 and 3 in RFC 3261 [2] for the Target-Dialog header field. The column "INF" is for the INFO method [4], "PRA" is for the PRACK method [5], "UPD" is for the UPDATE method [6], "SUB" is for the SUBSCRIBE method [3], "NOT" is for the NOTIFY method [3], "MSG" is for the MESSAGE method [7], "REF" is for the REFER method [8], and "PUB" is for the PUBLISH method [9].
図3および4は、ターゲットダイアログヘッダーフィールドのRFC 3261 [2]の表2および3の拡張です。列「inf」は情報方法[4]用、「pra」はプラック法[5]用です。「NOT」はNotify Method [3]のためのものであり、「MSG」はメッセージメソッド[7]、「REF」は参照方法[8]、「PUB」は公開方法[9]用です。
Header field where proxy ACK BYE CAN INV OPT REG PUB
プロキシACK ByeがINV Opt Reg Pubができるヘッダーフィールド
Target-Dialog R - - - - o - - -
Figure 3: Allowed Methods for Target-Dialog
図3：ターゲットダイアログの許可方法
Header field where proxy PRA UPD SUB NOT INF MSG REF
プロキシPRA UPD SUB NOT INFSMSG REFを使用するヘッダーフィールド
Target-Dialog R - - - o - - - o
Figure 4: Allowed Methods for Target-Dialog
図4：ターゲットダイアログの許可方法
The Target-Dialog header field is used to authorize requests based on the fact that the sender of the request has access to information that only certain entities have access to. In order for such an authorization decision to be secure, two conditions have to be met. Firstly, no eavesdroppers can have access to this information. That requires the original SIP dialog to be established using a sips URI, which provides TLS on each hop. With a sips URI, only the user agents and proxies on the request path will be able to know the dialog identifiers. The second condition is that the dialog identifiers be sufficiently cryptographically random that they cannot be guessed. RFC 3261 requires global uniqueness for the Call-ID and 32 bits of cryptographic randomness for each tag (there are two tags for a dialog). Given the short duration of a typical dialog (perhaps as long as a day), this amount of randomness appears adequate for preventing guessing attacks. However, it's important to note that this specification requires true cryptographic randomness as set forth in RFC 4086 [11]. Weaker pseudorandom identifiers reduce the probability of collision, but because they are guessable, they are not sufficient to prevent an attacker from observing a sequence of identifiers, guessing the next one, and then using this specification to launch an attack.
Target-Dialogヘッダーフィールドは、リクエストの送信者が特定のエンティティのみがアクセスできる情報にアクセスできるという事実に基づいて、リクエストを承認するために使用されます。このような許可決定が安全であるためには、2つの条件を満たす必要があります。第一に、この情報にアクセスできる盗聴者はいません。これには、各ホップでTLSを提供するSIPS URIを使用して、元のSIPダイアログを確立する必要があります。SIPS URIを使用すると、リクエストパス上のユーザーエージェントとプロキシのみがダイアログ識別子を知ることができます。2番目の条件は、ダイアログ識別子が推測できないほど暗号化的にランダムであることです。RFC 3261には、コールIDのグローバルな一意性と、各タグに32ビットの暗号化ランダム性が必要です（ダイアログには2つのタグがあります）。典型的なダイアログの短い期間（おそらく1日と同じくらい）を考えると、この量のランダム性は、推測攻撃を防ぐのに適切であると思われます。ただし、この仕様にはRFC 4086 [11]に記載されている真の暗号ランダム性が必要であることに注意することが重要です。擬似ランダムの識別子が弱くなると、衝突の可能性が低下しますが、推測可能であるため、攻撃者が一連の識別子を観察し、次の識別子を推測し、この仕様を使用して攻撃を開始するのを防ぐのに十分ではありません。
RFC 3261 defines the In-Reply-To header field. It provides a list of Call-IDs for calls that the current request references or returns. It was meant to serve a similar purpose as the Reply-To in email: to facilitate the construction of "threads" of conversations in a user interface. Target-Dialog is similar, in that it also references a previous session. Due to their similarities, it is important to understand the differences, as these two header fields are not substitutes for each other.
RFC 3261は、リプリーからヘッダーへのフィールドを定義します。現在のリクエストが参照または返されるコール用のcall-idのリストを提供します。これは、ユーザーインターフェイスでの会話の「スレッド」の構築を促進するために、電子メールの返信と同様の目的を果たすことを意図していました。Target-Dialogは、以前のセッションも参照するという点で似ています。これらの2つのヘッダーフィールドはお互いの代替品ではないため、それらの類似点のため、違いを理解することが重要です。
Firstly, In-Reply-To is meant for consumption by a human or a user interface widget, for providing the user with a context that allows them to decide what a call is about and whether they should take it. Target-Dialog, on the other hand, is meant for consumption by the user agent itself, to facilitate authorization of session requests in specific cases where authorization is not a function of the user, but rather the underlying protocols. A UA will authorize a call containing Target-Dialog based on a correct value of the Target-Dialog header field.
第一に、In-Reply-toは、人間またはユーザーのインターフェイスウィジェットによる消費を目的としており、ユーザーに電話が何であるか、それを取るべきかどうかを決定できるコンテキストを提供します。一方、Target-Dialogは、ユーザーエージェント自体による消費を目的としており、認可がユーザーの関数ではなく、基礎となるプロトコルである特定の場合のセッション要求の承認を促進します。UAは、ターゲットダイアログヘッダーフィールドの正しい値に基づいて、ターゲットダイアログを含むコールを承認します。
Secondly, Target-Dialog references a specific dialog that must be currently in progress. In-Reply-To references a previous call attempt, most likely one that did not result in a dialog. This is why In-Reply-To uses a Call-ID, and Target-Dialog uses a set of dialog identifiers.
第二に、ターゲットダイアログは、現在進行中でなければならない特定のダイアログを参照します。繰り返し参照して、以前のコールの試み、おそらくダイアログにならなかったものではありません。これが、InReplyがCall-IDを使用する理由であり、Target-Dialogが一連のダイアログ識別子を使用します。
Finally, In-Reply-To implies cause and effect. When In-Reply-To is present, it means that the request is being sent because of the previous request that was delivered. Target-Dialog does not imply cause and effect, merely awareness for the purposes of authorization.
最後に、繰り返しの原因と結果を意味します。In Reply-toが存在する場合、これは以前のリクエストが配信されたためにリクエストが送信されていることを意味します。ターゲットダイアログは、承認の目的に対する単なる認識を意味するものではありません。
In this example, user agent A and user agent B establish an INVITE-initiated dialog through Server-A and Server-B, each of which acts as a proxy for the INVITE. Server B would then like to use the application interaction framework [14] to request that user agent A fetch an HTML user interface component. To do that, it sends a REFER request to A's URI. The flow for this is shown in Figure 5. The conventions of [19] are used to describe representation of long message lines.
この例では、ユーザーエージェントAとユーザーエージェントBは、サーバーAとサーバーBを介して招待状が開始したダイアログを確立します。それぞれが招待のプロキシとして機能します。サーバーBは、アプリケーションインタラクションフレームワーク[14]を使用して、ユーザーエージェントAにHTMLユーザーインターフェイスコンポーネントを取得するように要求します。そのために、AのURIへの紹介要求を送信します。このためのフローを図5に示します。[19]の規則は、長いメッセージ行の表現を記述するために使用されます。
A Server-A Server-B B
|(1) INVITE | | |
|----------->| | |
| |(2) INVITE | |
| |----------->| |
| | |(3) INVITE |
| | |----------->|
| | |(4) 200 OK |
| | |<-----------|
| |(5) 200 OK | |
| |<-----------| |
|(6) 200 OK | | |
|<-----------| | |
|(7) ACK | | |
|------------------------------------->|
| |(8) REFER | |
| |<-----------| |
|(9) REFER | | |
|<-----------| | |
|(10) 200 OK | | |
|----------->| | |
| |(11) 200 OK | |
| |----------->| |
Figure 5
図5
First, the caller sends an INVITE, as shown in message 1.
まず、メッセージ1に示すように、発信者は招待状を送信します。
INVITE sips:B@example.com SIP/2.0
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Supported: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Accept: application/sdp, text/html
<allOneLine>
Contact: <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;schemes="http,sip,sips"
</allOneLine>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--
-SDPが表示されていない -
The INVITE indicates that the caller supports GRUU (note its presence in the Contact header field of the INVITE) and the Target-Dialog header field. This INVITE is forwarded to the callee (messages 2-3), which generates a 200 OK response that is forwarded back to the caller (message 4-5). Message 5 might look like:
招待状は、発信者がGruuをサポートしていることを示しています（招待のコンタクトヘッダーフィールドに存在することに注意してください）とターゲットダイアログヘッダーフィールド。この招待は、Callee（メッセージ2-3）に転送され、発信者に転送される200 OK応答を生成します（メッセージ4-5）。メッセージ5は次のように見えるかもしれません：
SIP/2.0 200 OK
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>;tag=6544
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Contact: <sips:B@pc.example.org>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--
-SDPが表示されていない -
In this case, the called party does not support GRUU or the Target-Dialog header field. The caller generates an ACK (message 7). Server B then decides to send a REFER to user A:
この場合、呼び出された当事者は、GruuまたはTarget-Dialogヘッダーフィールドをサポートしていません。発信者はACKを生成します（メッセージ7）。サーバーBは、ユーザーaを参照することを決定しました。
<allOneLine>
REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0
</allOneLine>
Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10
From: Server B <sip:serverB.example.org>;tag=mreysh
<allOneLine>
To: Caller <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>
</allOneLine>
Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com
;local-tag=kkaz-
;remote-tag=6544
Refer-To: http://serverB.example.org/ui-component.html
Call-ID: 86d65asfklzll8f7asdr@host.example.com
CSeq: 1 REFER
Max-Forwards: 70
Require: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY
Contact: <sips:serverB.example.org>
Content-Length: 0
This REFER will be delivered to server A because it was sent to the
GRUU. From there, it is forwarded to user agent A (message 9) and
authorized because of the presence of the Target-Dialog header field.
This specification registers a new SIP header field, a new option tag according to the processes of RFC 3261 [2], and two new header field parameters according to the processes of RFC 3968 [10].
この仕様は、新しいSIPヘッダーフィールド、RFC 3261 [2]のプロセスに従って新しいオプションタグ、およびRFC 3968 [10]のプロセスに従って2つの新しいヘッダーフィールドパラメーターを登録します。
RFC Number: RFC 4538
RFC番号：RFC 4538
Header Field Name: Target-Dialog
ヘッダーフィールド名：ターゲットダイアログ
Compact Form: none
コンパクトフォーム：なし
This section registers two header field parameters according to the processes of RFC 3968 [10].
このセクションでは、RFC 3968のプロセスに従って2つのヘッダーフィールドパラメーターを登録します[10]。
Header Field: Target-Dialog
ヘッダーフィールド：ターゲットダイアログ
Header Field Parameter: local-tag
ヘッダーフィールドパラメーター：ローカルタグ
Predefined Values: None
事前定義された値：なし
RFC: RFC 4538
RFC：RFC 4538
Header Field: Target-Dialog
ヘッダーフィールド：ターゲットダイアログ
Header Field Parameter: remote-tag
ヘッダーフィールドパラメーター：リモートタグ
Predefined Values: None
事前定義された値：なし
RFC: RFC 4538
RFC：RFC 4538
This specification registers a new SIP option tag per the guidelines in Section 27.1 of RFC 3261.
この仕様は、RFC 3261のセクション27.1のガイドラインに従って新しいSIPオプションタグを登録します。
Name: tdialog
名前：Tdialog
Description: This option tag is used to identify the target dialog header field extension. When used in a Require header field, it implies that the recipient needs to support the Target-Dialog header field. When used in a Supported header field, it implies that the sender of the message supports it.
説明：このオプションタグは、ターゲットダイアログヘッダーフィールド拡張機能を識別するために使用されます。必要なヘッダーフィールドで使用する場合、受信者がターゲットダイアログヘッダーフィールドをサポートする必要があることを意味します。サポートされているヘッダーフィールドで使用する場合、メッセージの送信者がサポートすることを意味します。
This specification is based on a header field first proposed by Robert Sparks in the dialog usage draft [12]. John Elwell provided helpful comments.
この仕様は、ダイアログ使用ドラフト[12]でロバートスパークスによって最初に提案されたヘッダーフィールドに基づいています。ジョン・エルウェルは有益なコメントを提供しました。
[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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[4] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[6] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[7] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[8] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[9] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[9] Niemi、A。、「イベント州の出版物のセッション開始プロトコル（SIP）拡張」、RFC 3903、2004年10月。
[10] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[10] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字局（IANA）ヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[11] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[12] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", Work in Progress, March 2006.
[12] Sparks、R。、「セッション開始プロトコルでの複数のダイアログ使用」、2006年3月、進行中の作業。
[13] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, May 2006.
[13] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用している」、2006年5月の作業。
[14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005.
[14] Rosenberg、J。、「セッション開始プロトコル（SIP）におけるアプリケーションインタラクションのフレームワーク」、2005年7月の作業。
[15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[15] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待状のダイアログイベントパッケージ」、RFC 4235、2005年11月。
[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", Work in Progress, July 2005.
[16] Rosenberg、J。、「会議状態向けのセッション開始プロトコル（SIP）イベントパッケージ」、2005年7月、進行中の作業。
[17] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[17] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[18] Burger, E., "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Work in Progress, December 2004.
[18] Burger、E。、「キープレス刺激（KPML）のセッション開始プロトコル（SIP）イベントパッケージ」、2004年12月、進行中の作業。
[19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[19] Sparks、R.、ed。、Hawrylyshen、A.、Johnston、A.、Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）拷問テストメッセージ」、RFC 4475、2006年5月。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。