Network Working Group R. Sparks
Request for Comments: 3892 Xten
Category: Standards Track September 2004
The Session Initiation Protocol (SIP) Referred-By Mechanism
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present.
セッション開始プロトコル（SIP）は、この方法は、一方の当事者（リファラ）を基準に第二者（審判）任意のURIを与える機構を提供するREFER。そのURIがSIP URIであるならば、レフリーは、多くの場合、（ターゲットを参照してください）そのURIに、INVITE、SIPリクエストを送信します。この文書では、リファラーを媒介として審判を使用して参照対象を参照要求についての情報を提供できるように、REFERメソッドを拡張します。この情報は、リファラが呼ばれたリファラー及びURIの識別を含みます。メカニズムが、悪質な仲介者からこの情報を保護するためにS / MIMEを利用しています。この保護はオプションですが、受信者は、それが存在しない限り、要求を受け入れることを拒否することができます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 3
2.1. Referrer Behavior . . . . . . . . . . . . . . . . . . . 4
2.2. Referee Behavior . . . . . . . . . . . . . . . . . . . . 4
2.3. Refer Target Behavior . . . . . . . . . . . . . . . . . 5
3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6
4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7
4.1. Refer Target Inspection of a Referred-By Token . . . . . 8
5. The 429 Provide Referrer Identity Error Response . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Identifying the Referee in the Referred-by Token . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Basic REFER . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
7.3. Requiring Referrer Identity . . . . . . . . . . . . . . 14
7.4. Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
The SIP REFER method [2] provides a mechanism where one party (the referrer) provides a second party (the referee) with an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). Nothing provided in [2] distinguishes this referenced request from any other request the referee might have sent to the refer target.
SIPメソッド参照[2]一方の当事者（リファラ）を参照に、任意のURIを有する第2のパーティ（審判）を提供するメカニズムを提供します。そのURIがSIP URIであるならば、レフリーは、多くの場合、（ターゲットを参照してください）そのURIに、INVITE、SIPリクエストを送信します。 [2]で提供何も審判が参照するターゲットに送信された可能性のある他の要求から、この参照要求を区別しません。
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
|----------------->| INVITE target |
| |------------------->|
There are applications of REFER, such as call transfer [8], where it is desirable to provide the refer target with particular information about the referrer and the REFER request itself. This information may include, but is not limited to, the referrer's identity, the referred to URI, and the time of the referral. The refer target can use this information when deciding whether to admit the referenced request. This document defines one set of mechanisms to provide that information.
リファラー及びREFER要求自体に関する特定の情報を参照ターゲットを提供することが望ましいような呼転送などのREFERのアプリケーション、[8]は、存在しています。この情報には含まれるが、参照元の身元、URIと呼ばれ、紹介の時間が、これらに限定されません。参照要求を認めるかどうかを決定する際に参照するターゲットは、この情報を使用することができます。この文書では、その情報を提供するための機構の一組を定義します。
All of the mechanisms in this document involve placing information in the REFER request that the referee copies into the referenced request. This necessarily establishes the referee as an eavesdropper and places the referee in a position to launch man-in-the-middle attacks on that information.
この文書に記載されているメカニズムのすべては、参照要求にその審判コピーREFERリクエストに情報を置く伴います。これは、必ずしも盗聴者として審判を確立し、その情報にman-in-the-middle攻撃を起動する立場に審判を配置します。
At the simplest level, this document defines a mechanism for carrying the referrer's identity, expressed as a SIP URI in a new header: Referred-By. The refer target can use that information, even if it has not been protected from the referee, at the perils and with the limitations documented here. The document proceeds to define an S/MIME based mechanism for expressing the identity of the referrer and capturing other information about the REFER request, allowing the refer target to detect tampering (and other undesirable behaviors) by the referee.
いうバイ：最も単純なレベルで、この文書は参照元のアイデンティティを搬送するためのメカニズムを定義し、新たなヘッダにSIP URIとして表さ。参照するターゲットは、それが危険で、ここで文書化の限界で、審判から保護されていない場合でも、その情報を使用することができます。文書は、参照元のアイデンティティを表現し、REFER要求に関する他の情報を捕捉する、審判によって改ざん（および他の望ましくない行動）を検出する参照対象を可能にするため、S / MIMEベースのメカニズムを定義するために進みます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
The following figure summarizes how Referred-By information is carried to the Refer Target. The Referrer provides a Referred-By header with its SIP address-of-record, optionally associating an S/MIME protected token reflecting the identity of the referrer and the details of the REFER request. The Referee copies this header and the token, if provided, into the triggered request (shown here as an INVITE).
次の図は、言及することにより、情報参照してくださいターゲットに運ばれる方法をまとめたものです。リファラーは、必要に応じてS / MIMEは、リファラーのアイデンティティとREFER要求の詳細を反映するトークンを保護関連付け、そのSIPアドレスのレコードと呼ば-Byヘッダーを提供します。審判コピートリガ要求に、設けられている場合、このヘッダとトークンは、（INVITEとしてここに示されています）。
Referrer Referee Refer Target
| | |
| REFER | |
| Refer-To: target | |
| Referred-By: referrer;cid=X | |
| | |
| (one of the body parts is) | |
| Content-ID: X | |
| <Referred-By Token> | |
|----------------------------->| |
| | INVITE target |
| | Referred-By: referrer;cid=X |
| | |
| | (one of the body parts is) |
| | Content-ID: X |
| | <Referred-By token> |
| |---------------------------->|
A UA sending a REFER request (a referrer) MAY provide a Referred-By header field value in the request. A REFER request MUST NOT contain more than one Referred-By header field value.
REFERリクエスト（リファラー）を送信するUAは、要求において参照することにより、ヘッダフィールド値を提供することができます。 REFER要求は、複数呼ばバイヘッダフィールド値を含んではなりません。
A referrer MAY include a Referred-By token in a REFER request. A REFER request containing a Referred-By token MUST contain a Referred-By header field value with a cid parameter value equal to the Content-ID of the body part containing the token.
リファラはREFERリクエストに言及することで、トークンを含むかもしれません。いうバイ・トークンを含むREFER要求は、トークンを含む身体部分のコンテンツIDに等しいCIDパラメータ値と呼ば-Byヘッダーフィールド値を含まなければなりません。
The referrer will receive a NOTIFY with a message/sipfrag [4] body indicating a final response of 429 "Provide Referrer Identity" to the referenced request if the refer target requires a valid Referred-By token to accept the request. This can occur when either no token is provided or a provided token is invalid.
リファラーは、メッセージ/ sipfragターゲットを参照する場合、参照要求に429「リファラーIDを提供」の最終的な応答を示す[4]本体とNOTIFY受信要求を受け入れるために有効なReferred-Byトークンを必要とするであろう。どちらか全くトークンが提供されていない場合に発生することがありますまたは提供トークンが無効です。
The referrer will receive a 429 "Provide Referrer Identity" response to the REFER if the referee requires a Referred-By token to be present in order to accept the REFER.
リファラは審判がREFERを受け入れるために存在することが呼ば・バイ・トークンを必要とする場合に参照するために429「リファラーのアイデンティティを提供する」レスポンスを受信します。
If a referrer wishes to re-attempt to refer a referee after receiving a 429 response or a NOTIFY containing a 429, it MAY submit a new REFER request containing a Referred-By token.
リファラは429応答を受信した後、審判を参照するか、または429を含むNOTIFYを再試行することを希望する場合は、それが呼ばバイ・トークンを含む新しいREFER要求を提出することができます。
A UA accepting a REFER request (a referee) to a SIP URI (using either the sip: or sips: scheme) MUST copy any Referred-By header field value and token into the referenced request without modification.
（：またはSIPS：SIPのいずれかを使用してスキーム）をSIP URIに要求（審判）を参照してください受付UAは、任意のヘッダーフィールド値で換算し、変更することなく、参照要求にトークンをコピーする必要があります。
A referee MAY reject a REFER request that does not contain a Referred-By token with a 429 "Provide Referrer Identity" response. A referee SHOULD NOT reject a request that contains a Referred-By token encrypted to a key it does not possess simply because it cannot decrypt the token. (One scenario where such rejection would be appropriate is when the referee is attempting to remain anonymous (see Section 6.1).) Note that per [3], the referee should still be able to verify the signature of such an encrypted token.
審判は429応答「リファラーのアイデンティティを提供する」と呼ば・バイ・トークンが含まれていないREFER要求を拒否することがあります。審判はそれがトークンを解読することはできませんので、それは単に所有していない鍵で暗号化呼ば・バイ・トークンを含む要求を拒否すべきではありません。 （審判が匿名のままにしようとしたとき、そのような拒絶が適切であろう1つのシナリオは（セクション6.1を参照）である。）ごとなお、[3]、審判はまだそのような暗号化されたトークンの署名を検証することができなければなりません。
A referee SHOULD present the same identity to the referrer and the refer target.
審判はリファラと参照するターゲットに同じIDを提示しなければなりません。
A UA receiving a non-REFER SIP request MAY inspect the request for a Referred-By header field and token.
UAは、非SIP REFER要求はヘッダフィールドごと呼ばれ、トークンの要求を検査することができる受信します。
If a Referred-By header field value is not present, this UA cannot distinguish this request from any other the UA acting as the referee might have sent. Thus, the UA would apply exactly the admissions policies and processing described in [5] to the request.
呼ば-Byヘッダーフィールド値が存在しない場合は、このUAは審判として動作するUAが送信されたかもしれない他のどのから、この要求を区別することはできません。したがって、UAは正確に要求する[5]に記載の入学ポリシーおよび処理を適用します。
If a Referred-By header field value is present, the receiving UA can consider itself a refer target and MAY apply additional admission policies based on the contents of the Referred-By header field and token.
いうバイヘッダフィールド値が存在する場合、受信UAは、それ自体がターゲットを参照考慮することができると呼ばれるバイヘッダフィールドとトークンの内容に基づいて追加のアドミッションポリシーを適用することができます。
The referee is in a position to modify the contents of the Referred-By header field value, or falsely provide one even if no REFER actually exists. If such behavior could affect admission policy (including influencing the agent's user by rendering misleading content), the refer target SHOULD require that a valid Referred-By token be present.
審判は、何が実際に存在REFERても呼ばバイヘッダフィールド値の内容を変更していない、または誤っいずれかを提供する位置にあります。そのような行動は、（誤解を招くようなコンテンツをレンダリングすることで、エージェントのユーザーに影響を与えることを含む）入場政策に影響を与える可能性がある場合は、参照してください。ターゲットが有効呼ばバイトークンが存在することを要求すべきです。
The refer target MAY reject a request if no Referred-By token is present or if the token is stale using the 429 "Provide Referrer Identity" error response defined in Section 5. The 428 error response from [7] is not appropriate for this purpose - it is needed for the refer target to request an authentication token from the referee.
トークンは、[7]この目的のために適切ではないから428エラー応答5.セクションで定義429「リファラーIDを提供」エラー応答を使用して古くなっている場合は何も呼ばバイトークンが存在しない場合、または参照ターゲットは、要求を拒否するかもしれ - 審判から認証トークンを要求するために参照するターゲットのために必要とされています。
If no Referred-By token is present, the refer target MAY proceed with processing the request. If the agent provides any information from the Referred-By header to its user as part of processing the request, it MUST notify the user that the information is suspect.
何と呼ばバイトークンが存在しない場合、参照ターゲットは、要求の処理に進むことができます。エージェントは、要求の処理の一部として、そのユーザと呼ばれるバイヘッダからの情報を提供する場合、それは情報が疑わしいことをユーザに通知しなければなりません。
The refer target MUST reject an otherwise well-formed request with an invalid Referred-By token (see Section 4) with a 429 error response.
参照ターゲットは、429エラー応答で無効呼ばバイトークン（セクション4を参照）とそうでない場合は、十分に形成された要求を拒絶しなければなりません。
Referred-By is a request header field as defined by [5]. It can appear in any request. It carries a SIP URI representing the identity of the referrer and, optionally, the Content-ID of a body part (the Referred-By token) that provides a more secure statement of that identity.
[5]で定義されるように呼ばれるバイリクエストヘッダフィールドです。これは、任意の要求に表示されます。それは、必要に応じて、参照元のアイデンティティを示すSIP URIを担持し、そのアイデンティティのより安全なステートメントを与える身体部分のコンテンツID（以下バイトークン）。
Referred-By = ("Referred-By" / "b") HCOLON referrer-uri *( SEMI (referredby-id-param / generic-param) )
いうバイ=（ "と呼ばバイ" / "B"）HCOLONリファラー-URI *（SEMI（referredby-ID-PARAM /ジェネリック-PARAM））
referrer-uri = ( name-addr / addr-spec )
リファラ-URI =（名前、アドレス/ ADDR-SPEC）
referredby-id-param = "cid" EQUAL sip-clean-msg-id
referredby-ID-paramが= EQUAL SIP-クリーン-MSG-IDを "CID"
sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
SIP-クリーン-MSG-ID = LDQUOTドット原子 "@"（ドット原子/ホスト）RDQUOT
dot-atom = atom *( "." atom )
ドットアトム=原子*（「」原子）
atom = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "'" / "`" / "~" )
原子= 1 *（alphanum / " - " "！" / / "％" / "*" / "_" / "+" / "'" / "`"/ "〜"）
Since the Content-ID appears as a SIP header parameter value which must conform to the expansion of the gen-value defined in [5], this grammar produces values in the intersection of the expansions of gen-value and msg-id from [9]. The double-quotes surrounding the sip-clean-msg-id MUST be replaced with left and right angle brackets to derive the Content-ID used in the message's MIME body. For example,
コンテンツIDは、で定義されたGEN-値の拡張に適合しなければならないSIPヘッダパラメータ値として現れるので、[5]、この文法[9からGEN-値とMSG-IDの拡張の交点の値を生成します]。 SIP-クリーン-MSG-IDを囲む二重引用符は、メッセージのMIMEボディに使用されるのContent-IDを導き出すために、左と右の角括弧に置き換える必要があります。例えば、
Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example" indicates the token is in the body part containing
いうバイ：SIP：r@ref.example; CID =「2UWQFN309shb3@ref.example」はトークンを含む身体の部分であることを示し
Content-ID: <2UWQFN309shb3@ref.example>
コンテンツID：<2UWQFN309shb3@ref.example>
If the referrer-uri contains a comma, question mark, or semicolon, (for example, if it contains URI parameters) the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
リファラURIがカンマ、疑問符、またはセミコロンが含まれている場合（これは、URIパラメータを含む場合など）、URIは、山括弧（<と>）で囲む必要があります。任意のURIパラメータは、これらの括弧内に収容されています。 URIは、角括弧で囲まれていない場合、任意のセミコロンで区切られたパラメータは、ヘッダパラメータはなく、URIパラメータです。
The Referred-By header field MAY appear in any SIP request, but is meaningless for ACK and CANCEL. Proxies do not need to be able to read Referred-By header field values and MUST NOT remove or modify them.
いうバイヘッダフィールドは、任意のSIPリクエストに現れるが、ACKのための無意味であり、取り消すことができます。プロキシはヘッダーフィールド値によって-呼ばれ、それらを削除するか、変更してはいけません読み取ることができる必要はありません。
The following row should be interpreted as if it appeared in Table 3 of RFC 3261.
それはRFC 3261の表3に表示された場合のように、次の行が解釈されるべきです。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Referred-By R - o - o o o
The Referred-By token is an Authenticated Identity Body as defined by [3]. This body part MUST be identified with a MIME [6] Content-ID: field.
いうバイトークンは[3]によって定義されるように認証された識別体です。フィールド：この本体部分は、MIME [6]のContent-IDで識別されなければなりません。
The sipfrag inside a Referred-By token MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request.
いうバイトークン内のsipfragはREFER要求から参照バイ参照-のコピー、および日付ヘッダフィールドを含まなければなりません。
The token SHOULD NOT contain the Call-ID header field from the REFER request as that information is not useful to the refer target and may even be an information leak. The token SHOULD NOT contain the From header field from the REFER request since the identity being claimed is represented in the Referred-By header field.
その情報が参照ターゲットに有用ではないとも情報漏洩であってもよいようにトークンがREFERリクエストからのCall-IDヘッダフィールドを含むべきではありません。記載されているアイデンティティをいうバイヘッダフィールドに示されているので、トークンは、REFERリクエストからからヘッダフィールドを含むべきではありません。
The token MAY contain the To header field from the REFER request, but it SHOULD NOT be included unless the referrer has cryptographically identified the referee. Some ways this authentication can be achieved include inspecting the certificates used in a TLS association between the referrer and the referee or encrypting the Refer-To header in the REFER request using the S/MIME encryption techniques detailed in [5].
トークンは、REFERリクエストからヘッダーフィールドを含むことができるが、リファラは、暗号審判を特定していない限り、それが含まれるべきではありません。この認証を達成することができるいくつかの方法は、リファラー及び審判又は参照の-〜[5]に詳述S / MIME暗号化技術を使用して、REFERリクエストのヘッダを暗号化する間のTLS関連して使用される証明書を検査含みます。
When inspecting the certificates used to establish TLS associations, the identity asserted in the token's To header field URI is compared to the subjectAltNames from the referee's certificate. The sip and sips URI schemes MUST be treated as equivalent for this comparison. If the URI is an exact match, confidence in the authentication is high and the To header field MAY be added to the token. If the certificate subjects contain only a hostname matching the hostname portion of the URI, an application level warning SHOULD be issued to the referrer agent's user seeking that user's consent before including the To header field in the token.
TLSの関連付けを確立するために使用される証明書を検査すると、アイデンティティはフィールドURI Toヘッダートークン年代にアサート審判の証明書からsubjectAltNamesを比較します。 SIPおよびURIスキームは、この比較のために同等に扱わなければならないすすります。 URIは完全一致である場合には、認証の信頼性が高く、Toヘッダーフィールドは、トークンに添加してもよいです。証明書の対象者は、URIのホスト名の部分に一致するホスト名のみが含まれている場合は、アプリケーションレベルの警告は、トークンにToヘッダーフィールドに含める前に、そのユーザーの同意を求めているリファラエージェントの利用者に発行する必要があります。
Including the To header field in the token significantly strengthens the claim being asserted by the token, but may have privacy implications as discussed in Section 6.1.
トークンにToヘッダーフィールドに含めるとかなりのトークンによってアサートされている主張を強化しますが、6.1節で述べたように、プライバシーへの影響を有することができます。
Additional header fields and body parts MAY be included in the token.
追加のヘッダーフィールドと体の部分は、トークンに含まれるかもしれません。
As described in [3], a Referred-By token MAY be encrypted as well as signed. The subjectAltName of the certificate used for these operations SHOULD exactly match the identity claimed in the referrer-uri in the Referred-By header field in the token.
[3]に記載のように、呼ばれるバイ・トークンは、暗号化と同様に署名されるかもしれません。正確アイデンティティと一致している必要があり、これらの操作のために使用される証明書のsubjectAltNameはリファラURIトークンで呼ば-Byヘッダーフィールド内に記載しました。
A refer target MUST treat a Referred-By token with an invalid signature as an invalid token. A target SHOULD treat a token with an aged Date header field value as invalid.
参照ターゲットは、無効なトークンとして無効な署名と呼ばれるバイ・トークンを処理しなければなりません。ターゲットは無効として高齢者Dateヘッダフィールド値でトークンを扱うべきです。
A target SHOULD verify that the request it receives matches the reference in the Refer-To header field in the token. This verification SHOULD include at least the request method and any indicated end-to-end header field values. Note that the URI in the Refer-To header field may not match the request URI in the received request due to request re-targeting between the referee and the refer target.
ターゲットは、受信要求がトークンに参照のために、ヘッダフィールド内の基準と一致することを確認する必要があります。この検証は、少なくともリクエストメソッドと任意示されたエンドツーエンドのヘッダフィールド値を含むべきです。参照のために、ヘッダフィールド内のURIが原因要求は審判と参照ターゲットとの間の再ターゲティングに受信された要求で要求URIと一致しなくてもよいことに留意されたいです。
The target SHOULD verify that the identity in the Referred-By header field in the token exactly matches the SubjectAltName from the signing certificate, reporting discrepancies to its user as described in [3].
ターゲットは、[3]に記載されているように、そのユーザーに矛盾を報告し、トークンで呼ば-Byヘッダーフィールドの識別が正確に署名証明書からのSubjectAltNameと一致することを確認する必要があります。
If the token contains a To header field, the target SHOULD verify that the identity it expresses matches the referrer. One way of verifying this is to exactly match the identity in the token's To header field with the subjectAltName of the certificate used by the referee to sign the aib protecting the request itself. The 428 response defined in [7] can be used to request such an aib if one is not already present.
トークンはToヘッダーフィールドが含まれている場合は、ターゲットは、それが表現するアイデンティティがリファラと一致することを確認する必要があります。これを検証する一つの方法は、正確に要求自体を保護するAIBに署名する審判で使用される証明書ののsubjectAltNameとToヘッダーフィールドにトークンの中でアイデンティティを一致させることです。 [7]で定義された428レスポンスは1つが存在しない場合、そのようなAIBを要求するために使用することができます。
The 429 client error response code is used by a refer target to indicate that the referee must provide a valid Referred-By token. As discussed in the behavior section, the referee will forward this error response to the referrer in a NOTIFY as the result of the REFER. The suggested text phrase for the 429 error response is "Provide Referrer Identity".
429クライアントエラー応答コードは、審判が有効なReferred-Byトークンを提供しなければならないことを示すために参照するターゲットが使用されます。動作の項で説明したように、審判は、REFERの結果NOTIFYでリファラに、このエラー応答を転送します。 429エラー応答のために提案されたテキストフレーズは、「リファラーIDを提供」です。
The mechanism defined in this specification relies on an intermediary (the referee) to forward information from the referrer to the refer target. This necessarily establishes the referee as an eavesdropper of that information and positions him perfectly to launch man-in-the-middle attacks using the mechanism.
本明細書で定義されたメカニズムは、参照ターゲットにリファラーから情報を転送する中間（審判）に依存しています。これは、必ずしもその情報の盗聴者として審判を確立し、メカニズムを使用してman-in-the-middle攻撃を起動するために、完全に彼を配置します。
A SIP proxy is similarly positioned. Protecting SIP messaging from malicious proxy implementations is discussed in [5]. In contrast to a proxy, the referee's agent is an endpoint. Proxies will typically be managed and monitored by service providers. Malicious behavior by a proxy is more likely to be noticed and result in negative repercussions for the provider than malicious behavior by an endpoint would be. The behavior of an endpoint can be entirely under the control of a single user. Thus, it is more feasible for an endpoint acting as referee to behave maliciously than it is for a proxy being operated by a service provider.
SIPプロキシは同様に配置されています。悪意のあるプロキシ実装からSIPメッセージを保護するには、[5]に記載されています。プロキシとは対照的に、審判のエージェントがエンドポイントです。プロキシは通常、サービスプロバイダによって管理および監視されます。代理人による悪意のある動作は、エンドポイントによって、悪意のある動作が可能であろうよりも気づき、プロバイダの負の影響が発生する可能性が高いです。エンドポイントの動作は完全に単一のユーザの制御下に置くことができます。したがって、それは、サービスプロバイダによって運営されているプロキシのためであるよりも、悪意を持って動作するように審判として機能するエンドポイントより実現可能です。
This specification uses an S/MIME based mechanism to enable the refer target to detect manipulation of the Referred-By information by the referee. Use of this protection is optional! The community has asserted that there are systems where trust in the validity of this information is either not important or can be established through other means. Any implementation choosing not to use this optional mechanism needs to provide its own defense to the following risks:
本明細書では呼ば-BY情報審判によっての操作を検出するための参照対象を有効にするS / MIMEベースのメカニズムを使用します。この保護機能の使用はオプションです！コミュニティはこの情報の妥当性への信頼がどちらかは重要ではないか、他の手段によって確立することができるシステムがあると主張しています。このオプションのメカニズムを使用しないことを選択し、任意の実装には、次のリスクに、独自の防御を提供する必要があります：
o The Referred-By information is highly likely to influence request admission policy. For instance, it may be displayed to the user of the agent with a "This call was transferred to you by X. Accept?" prompt. A malicious referee can unduly influence that policy decision by providing falsified referred-by information. This includes falsely claiming to have been referred in the first place. (The S/MIME mechanism protects the information with a signature, hampering the referee's ability to inject or modify information without knowing the key used for that signature.)
O呼ば-ことで情報が要求アドミッションポリシーに影響を与える可能性が高いです。例えば、それはとエージェントのユーザに表示することができる「このコールは受け入れXであなたに移されたのですか？」促す。悪質な審判が不当に改ざんさ呼び-で情報を提供することにより、その政策決定に影響を与えることができます。これは誤って最初の場所で呼ばれてきたと主張しています。 （S / MIME機構は注入又はその署名のために使用される鍵を知らなくても情報を変更する審判の能力を妨げる、署名付き情報を保護します。）
o A referee is by definition an eavesdropper of the referred-by information. Parts of that information may be sensitive. (The S/MIME mechanism allows encryption.)
O審判は呼ば-による情報の盗聴者が定義することによるものです。その情報の一部は感受性がある可能性があります。 （S / MIME機構は、暗号化を可能にします。）
o The referee may store any referred-by information it sees and paste it into future unrelated requests. (The S/MIME mechanism allows detection of stale assertions by covering a timestamp with the signature and allows detection of use in unrelated requests by covering the Refer-To header field with the signature.)
O審判はいかなる言及-によって情報、それは見て保存し、将来の無関係な要求に貼り付けることがあります。 （S / MIME機構は、署名とタイムスタンプを覆うことにより、失効アサーションの検出を可能にし、参照のために、署名付きフィールドヘッダを覆うことにより、無関係な要求に使用の検出を可能にします。）
The mechanisms in this specification do NOT prevent the referee from deleting ALL referred-by information from the referenced request. A refer target can not detect such deletion. This introduces no new problems since removing all referred-by information from a referenced request transforms it into an ordinary SIP request as described in [5]. Thus the referee gains no new influence over processing logic at the refer target by removing the referred-by information.
本明細書における機構は、参照要求からALL呼ば-によって情報を削除から審判を妨げません。参照するターゲットは、このような削除を検出することはできません。これは、[5]に記載されているように、通常のSIP要求に変換し、参照要求からすべて呼ば-によって情報を削除するので新たな問題を導入しません。いう-によって情報を除去することによりこのよう審判ゲイン参照対象の処理ロジックを超える新たな影響を。
Refer targets can protect themselves from the possibility of a malicious referee removing a token (leaving an unsecured identity in the Referred-By header field) by using the 429 error response.
参照ターゲットは429エラー応答を使用して（以下バイヘッダフィールドに保護されていないIDを残して）トークンを除去悪意のある審判の可能性から身を守ることができます。
Applications using the mechanisms in this document may be able to take advantage of pre-existing relationships between the participants to mitigate the risks of its use. In some transfer scenarios, A has the choice of referring B to C or referring C to B. If A and B have a pre-existing trust relationship, leading A to have greater confidence that B will not behave maliciously (B is A's administrative assistant for example), referring B to C may make more sense.
この文書でメカニズムを使用するアプリケーションは、その使用のリスクを軽減するために、参加者間の既存の関係を利用することができるかもしれません。 AとBは、Bが悪意を持って動作しませんという大きな自信を持つようにAをリードし、既存の信頼関係を持っている場合は、いくつかの転送のシナリオでは、AはCにBを参照するか、BにCを参照の選択肢を持っている（BはAの管理アシスタントです）、例えば、CにBを参照すると、より意味をなすことができます。
This mechanism involves two SIP requests between three endpoints, the REFER and the referenced request. The content of those messages (including the referred-by information) is subject to the security considerations and protection mechanisms documented in [5].
この機構は、3つのエンドポイント間の2つのSIPリクエスト、REFERと参照要求を含みます。 （呼ぶ-によって情報を含む）これらのメッセージの内容は、[5]に記載されたセキュリティ上の考慮事項と保護機構の対象となります。
Proxies between the participants may collect referred-by information and re-insert it in future requests or make it available to hostile endpoints. The end-to-end confidentiality capabilities discussed in [5] can help reduce the risk of exposing sensitive referred-by information to these proxies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referee and the refer target are identical to the abuse by the referee, and the considerations discussed for a malicious referee applies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referrer and the referee are similar to those discussed for the presentation of Authenticated Identity Bodies in [7].
参加者間のプロキシは、情報により-呼ばれ、将来のリクエストでそれを再挿入するか、敵対的エンドポイントが使用できるようにし収集することがあります。 [5]で説明したエンドツーエンドの機密性機能は露出のリスクを減らすことができ敏感呼ば-することにより、これらのプロキシへの情報。審判と参照ターゲットとの間の（それらが情報のリークが発生することがあり、またはエンドポイント）プロキシによって後続の要求に乱用の可能性は、審判によって乱用と同一であり、悪意のある審判を適用するための考慮事項が議論します。リファラーと審判の間（それらが情報のリークが発生することがあり、またはエンドポイント）プロキシによって後続の要求に乱用の可能性がで認証されたアイデンティティ機関の提示のために説明したものと類似している[7]。
To a refer target, a Referred-By token minimally asserts "The identity expressed by this Referred-By header field asked at the time indicated in this Date header field that the request indicated by this Refer-To header field be sent". This assertion makes no claims at all about who is being asked to send the request. This is sufficient to enable policies such as "Accept any requests referred by Alice", but not "Only accept requests from Bob if he can prove that Alice referred him to us". Thus, there is an opportunity for a cut-and-paste attack. If Mallory sees Alice refer Carol to us using a minimal token, he can copy that token into his own request (as long as it matches what is indicated in the embedded Refer-To header), and it will appear to us that Alice referred Mallory to us. This risk is best mitigated by protecting the REFER Alice sends to Carol from eavesdropping, using TLS or the S/MIME mechanisms detailed in [5].
参照ターゲットに、呼ば-によっては最小トークン「で、この呼ば-Byヘッダーフィールドによって表さアイデンティティがこの参照の-Toヘッダーフィールドによって示される要求が送信されることを、この日付ヘッダフィールドで示された時間に尋ね」アサート。この主張は全く要求を送信するように要求されている者についての主張を行いません。これは、「アリスによって呼ばあらゆる要求を受け入れる」ではなく、「彼はアリスが私たちに彼を呼ばれていることを証明できる場合にのみ、ボブからの要求を受け入れる」などのポリシーを有効にするのに十分です。このように、カットアンドペースト攻撃の機会があります。マロリーがアリスが最小限のトークンを使用して私たちにキャロルを参照してください見れば、彼は彼自身のリクエストにそのトークンをコピーすることができます（それが中に示されているものと一致している限り、埋め込み参照してくださいするにはヘッダー）、そして、アリスがマロリーを言及することを私たちに表示されます私たちに。このリスクは、最良アリスはTLSまたは[5]に詳述S / MIMEメカニズムを使用して、盗聴からキャロルへ送信REFER保護することによって緩和されます。
Including the To header field from the REFER request in the Referred-by token enables the "Only accept requests from Bob if he can prove that Alice referred him to us". Alice is constrained to add this header to the token only if she is sure she is sending the REFER request to Bob. We, in turn, ensure it was Bob that sent the referenced request to us, in addition to validating Alice's signature of the token. Mallory's earlier attack is not effective with this token.
呼ば-によってトークンができます「と彼はアリスが私たちに彼を呼ばれていることを証明できる場合にのみ、ボブからの要求を受け入れる」にREFERリクエストからToヘッダーフィールドを含みます。アリスは、彼女がボブにREFERリクエストを送信していることを確認された場合にのみトークンにこのヘッダーを追加するために制約されています。私たちは、順番に、それはトークンのアリスの署名の検証に加えて、私たちに参照要求を送信したボブだったことを確認してください。マロリーの以前の攻撃は、このトークンを使用して効果的ではありません。
Including the To header field in the Referred-By token has privacy implications, however. Carol, above, might wish to contact us anonymously. That wish would be defeated if Carol's identity appeared in the token Alice created. If Alice encrypted the token to us, Carol will not even be aware of the information leak. To protect herself when she wishes anonymity, Carol will have to reject any REFER requests containing a Referred-By token she can not inspect.
いうバイトークンにToヘッダーフィールドを含むことが、プライバシーの意味を有します。キャロルは、上記、匿名で私達に連絡することを望むかもしれません。キャロルのアイデンティティは、アリスが作成されたトークンに登場した場合にその願いは敗北するだろう。アリスは、私たちにトークンを暗号化した場合、キャロルも、情報漏洩を認識しません。彼女が匿名を希望する際に自分自身を保護するために、キャロルは彼女が検査できません呼ば・バイ・トークンを含む任意のREFER要求を拒否しなければなりません。
This example shows the secured Referred-By mechanism applied to a REFER to an SIP INVITE URI.
この例では、URIをSIP INVITEを参照するために適用される保護された呼ばバイ機構を示します。
Details are shown only for those messages involved in exercising the mechanism defined in this document.
詳細は、このドキュメントだけで定義されたメカニズムを行使に関与し、それらのメッセージのために示されています。
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
F1 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 To: sip:referee@referee.example From: sip:referrer@referrer.example;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: <sip:referrer.example> Refer-To: <sip:refertarget@target.example> Referred-By: <sip:referrer@referrer.example> ;cid="20398823.2UWQFN309shb3@referrer.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value)
F1、SIP REFER：referee@referee.exampleのSIP / 2.0経由：SIP / 2.0 / UDP referrer.example;ブランチ= z9hG4bK392039842へ：SIP：referee@referee.exampleから：SIP：referrer@referrer.example;タグ= 39092342 Call- ID：2203900ef0299349d9209f023aののCSeq：1239930は、マックス・フォワード参照：70お問い合わせ：<SIP：referrer.example>参照してください-TO：<SIP：refertarget@target.example>と呼ばバイ：<SIP：referrer@referrer.example>; CID =を"20398823.2UWQFN309shb3@referrer.example" のContent-Type：multipart / mixedの。境界=ユニーク-境界-1のContent-Length：（適切な値）
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional
--dragons39のContent-Type：メッセージ/ sipfragのContent-処分：AIB。取り扱い=オプション
Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: <sip:refertarget@target.example> Referred-By: <sip:referrer@referrer.example> ;cid="20398823.2UWQFN309shb3@referrer.example"
日付：木、2002年2月21日13時02分〇三秒GMT参照してください-TO：<SIP：refertarget@target.example>と呼ばバイ：<SIP：referrer@referrer.example>; CID = "20398823.2UWQFN309shb3@referrer.example"
--dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--dragons39のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature goes here)
（適切な署名がここに入ります）
--dragons39-- --unique-boundary-1--
--dragons39-- --unique境界-1--
F2 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: <sip:refertarget@target.example> From: <sip:referee@referee.example>;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70
F2、SIP INVITE：refertarget@target.exampleのSIP / 2.0経由：SIP / 2.0 / UDP referee.example;ブランチ= z9hG4bKffe209934aacへ：<SIP：refertarget@target.example>から<SIP：referee@referee.example>;タグ= 2909034023コールID：fe9023940-a3465@referee.exampleのCSeq：889823409マックス-前方にINVITE：70
Contact: <sip:referee@referee.example> Referred-By: <sip:referrer@referrer.example> ;cid="20398823.2UWQFN309shb3@referrer.example" Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: (appropriate value)
連絡先：<SIP：referee@referee.example>と呼ばバイ：<SIP：referrer@referrer.example>; CID = "20398823.2UWQFN309shb3@referrer.example" のContent-Type：multipart / mixedの。境界=私の境界-9のContent-Length：（適切な値）
--my-boundary-9 Content-Type: application/sdp Content-Length: (appropriate value)
--my境界-9コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：（適切な値）
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 0 = IP4のreferee.example S =セッションSDP cで審判2890844526 2890844526 = IP4 IN referee.exampleさt = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <20398823.2UWQFN309shb3@referrer.example>
Content-Length: (appropriate value)
--dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional
--dragons39のContent-Type：メッセージ/ sipfragのContent-処分：AIB。取り扱い=オプション
Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: <sip:refertarget@target.example> Referred-By: <sip:referrer@referrer.example> ;cid="20398823.2UWQFN309shb3@referrer.example"
日付：木、2002年2月21日13時02分〇三秒GMT参照してください-TO：<SIP：refertarget@target.example>と呼ばバイ：<SIP：referrer@referrer.example>; CID = "20398823.2UWQFN309shb3@referrer.example"
--dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--dragons39のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature goes here)
（適切な署名がここに入ります）
--dragons39-- --my-boundary-9--
--dragons39-- --my-境界9--
The flow for this example is the same as that of Section 7.1. Here, the referrer has opted to not include a Referred-By token, and the refer target is willing to accept the referenced request without one.
この例のフローは、7.1節と同じです。ここでは、リファラが呼ばバイトークンを含めると、参照するターゲットは1なしで参照要求を受け入れることを望んでいないことにしました。
F1 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 To: <sip:referee@referee.example> From: <sip:referrer@referrer.example>;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: <sip:referrer.example> Refer-To: <sip:refertarget@target.example> Referred-By: <sip:referrer@referrer.example> Content-Length: 0
F1、SIP REFER：referee@referee.exampleのSIP / 2.0経由：SIP / 2.0 / UDP referrer.example;ブランチ= z9hG4bK392039842へ：<SIP：referee@referee.example>から<SIP：referrer@referrer.example>;タグ= 39092342コールID：2203900ef0299349d9209f023aののCSeq：1239930マックス・フォワード参照：70お問い合わせ：<SIP：referrer.example>参照してください-TO：<SIP：refertarget@target.example>と呼ばバイ：<一口：referrer@referrer.exampleを>コンテンツの長さ：0
F2 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: <sip:refertarget@target.example> From: <sip:referee@referee.example>;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Contact: <sip:referee@referee.example> Referred-By: <sip:referrer@referrer.example> Content-Type: application/sdp Content-Length: (appropriate value)
F2、SIP INVITE：refertarget@target.exampleのSIP / 2.0経由：SIP / 2.0 / UDP referee.example;ブランチ= z9hG4bKffe209934aacへ：<SIP：refertarget@target.example>から<SIP：referee@referee.example>;タグ= 2909034023コールID：fe9023940-a3465@referee.exampleのCSeq：889823409 INVITEマックス・フォワード：70お問い合わせ：<SIP：referee@referee.example>と呼ばバイ：<SIP：referrer@referrer.example>のContent-Type：アプリケーション/ SDPのContent-Length：（適切な値）
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 0 = IP4のreferee.example S =セッションSDP cで審判2890844526 2890844526 = IP4 IN referee.exampleさt = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
In contrast to the example in Section 7.2, the refer target requires a Referred-By token to accept the referenced request. The referrer chooses to provide an encrypted token (note that the block surrounded by asterisks represents encrypted content). F1 and F2 are identical to the messages detailed in Section 7.2.
セクション7.2の例とは対照的に、参照ターゲットは、参照要求を受け付けると呼ばれるバイ・トークンを必要とします。リファラーは、暗号化されたトークン（アスタリスクで囲まれたブロックは暗号化されたコンテンツを表すことに注意）を提供することを選択しました。 F1及びF2は、セクション7.2に詳述メッセージと同一です。
Referrer Referee Refer Target
| F1 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F2 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| F3 429 Provide Referrer Identity
| |<---------------------------|
| | ACK |
| F4 NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| F5 REFER | |
|-------------------------->| |
| 202 Accepted | |
|<--------------------------| |
| NOTIFY | |
|<--------------------------| F6 INVITE |
| 200 OK |--------------------------->|
|-------------------------->| 200 OK |
| |<---------------------------|
| | ACK |
| NOTIFY |--------------------------->|
|<--------------------------| |
| 200 OK | |
|-------------------------->| |
| | |
F3 SIP/2.0 429 Provide Referrer Identity Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: <sip:refertarget@target.example>;tag=392093422302334 From: <sip:referee@referee.example>;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Content-Length: 0
F3 SIP / 2.0 429提供リファラーアイデンティティ経由：SIP / 2.0 / UDP referee.example;ブランチ= z9hG4bKffe209934aacへ：<SIP：refertarget@target.example>;タグ= 392093422302334から：<SIP：referee@referee.example>;タグ= 2909034023コールID：fe9023940-a3465@referee.exampleのCSeq：889823409は、コンテンツの長さをINVITE：0
F4 NOTIFY sip:referrer@referrer.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390 To: <sip:referrer@referrer.example>;tag=39092342 From: <sip:referee@referee.example>;tag=199949923 Call-ID: 2203900ef0299349d9209f023a CSeq: 3920390 NOTIFY Event: refer;id=1239930 Subscription-State: terminated Content-Type: message/sipfrag Content-Length: (appropriate value)
referrer@referrer.example SIP / 2.0経由：F4は、SIP NOTIFY SIP / 2.0 / UDP referee.exampleを、ブランチ= z9hG4bK2934209da390へ：<SIP：referrer@referrer.example>;タグ= 39092342から：<SIP：審判@審判。例>;タグ= 199949923のCall-ID：2203900ef0299349d9209f023a用のCSeq：3920390イベントを通知する：参照; ID = 1239930サブスクリプションステートは：コンテンツタイプを終了：メッセージ/ sipfragのコンテンツ長：（適切な値）
SIP/2.0 429 Provide Referrer Identity
SIP / 2.0 429は、リファラーのアイデンティティを提供
F5 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423 To: <sip:referee@referee.example> From: <sip:referrer@referrer.example>;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239931 REFER Max-Forwards: 70 Contact: <sip:referrer.example> Refer-To: <sip:refertarget@target.example> Referred-By: <sip:referrer@referrer.example> ;cid="20342EFXEI.390sdefn2@referrer.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value)
F5、SIP REFER：referee@referee.exampleのSIP / 2.0経由：SIP / 2.0 / UDP referrer.example;ブランチ= z9hG4bK98823423へ：<SIP：referee@referee.example>から<SIP：referrer@referrer.example>;タグ= 39092342コールID：2203900ef0299349d9209f023aののCSeq：1239931マックス・フォワード参照：70お問い合わせ：<SIP：referrer.example>参照してください-TO：<SIP：refertarget@target.example>と呼ばバイ：<一口：referrer@referrer.exampleを>; CID = "20342EFXEI.390sdefn2@referrer.example" のContent-Type：multipart / mixedの。境界=ユニーク-境界-1のContent-Length：（適切な値）
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
*********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Refer-To: <sip:refertarget@target.example> * * Referred-By: <sip:referrer@referrer.example> * * ;cid="20342EFXEI.390sdefn2@referrer.example" * ***********************************************************
************************************************** ********* *のContent-Type：メッセージ/ sipfrag * *コンテンツディスポジション：AIB。取り扱い=オプション* * * *日：木、2002年2月21日午後01時02分03秒GMT * *ご参照ください-た：<SIP：refertarget@target.example> * *呼ばバイ：<SIP：referrer@referrer.example> * *; CID = "20342EFXEI.390sdefn2@referrer.example" * *********************************** ************************
--boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--boundary42のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature)
（適切な署名）
--boundary42--
--boundary42--
F6 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423 To: <sip:refertarget@target.example> From: <sip:referee@referee.example>;tag=1342093482342 Call-ID: 23499234-9239842993@referee.example CSeq: 19309423 INVITE Max-Forwards: 70 Referred-By: <sip:referrer@referrer.example> ;cid="20342EFXEI.390sdefn2@referrer.example" Contact: <sip:referee@referee.example> Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: (appropriate value)
F6、SIP INVITE：refertarget@target.exampleのSIP / 2.0経由：SIP / 2.0 / UDP referee.example;ブランチ= z9hG4bK3920390423へ：<SIP：refertarget@target.example>から<SIP：referee@referee.example>;タグ= 1342093482342コールID：23499234-9239842993@referee.exampleのCSeq：19309423マックス-前方にINVITE：70と呼ば・バイ：<SIP：referrer@referrer.example>; CID = "20342EFXEI.390sdefn2@referrer.example" 連絡先：< SIP：referee@referee.example>のContent-Type：multipart / mixedの。境界=私の境界-9のContent-Length：（適切な値）
--my-boundary-9 Content-Type: application/sdp Content-Length: (appropriate value)
--my境界-9コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：（適切な値）
v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 0 = IP4のreferee.example S =セッションSDP cで審判2890844526 2890844526 = IP4 IN referee.exampleさt = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
--my-boundary-9
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-ID: <20342EFXEI.390sdefn2@referrer.example>
Content-Length: (appropriate value)
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m;
handling=required
Content-Length: (appropriate value)
*********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Refer-To: <sip:refertarget@target.example> * * Referred-By: <sip:referrer@referrer.example> * * ;cid="20342EFXEI.390sdefn2@referrer.example" * ***********************************************************
************************************************** ********* *のContent-Type：メッセージ/ sipfrag * *コンテンツディスポジション：AIB。取り扱い=オプション* * * *日：木、2002年2月21日午後01時02分03秒GMT * *ご参照ください-た：<SIP：refertarget@target.example> * *呼ばバイ：<SIP：referrer@referrer.example> * *; CID = "20342EFXEI.390sdefn2@referrer.example" * *********************************** ************************
--boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--boundary42のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature)
（適切な署名）
--boundary42-- --my-boundary-9--
--boundary42-- --my-境界9--
The Refer-To URI may be a SIP URI indicating the REFER method. Consider The following URI which A uses to refer B to send a REFER request to C which refers C to send an INVITE to D.
参照の対URI REFERメソッドを示すSIP URIであってもよいです。 D.にINVITEを送信するためにCを意味Cを参照して要求を送信するために、AがBを参照するために使用する次のURIを検討
Note that A provides a Referred-By token which gets passed through B and C to D. In particular, B does not provide its own Referred-By token to C. Also note that A is notified of the outcome of the request it triggered at B (the REFER), not at C (the INVITE).
Aは、特に、DにBとCを介して渡される呼ばバイ・トークンを提供することに注意し、BがCに独自呼ばバイトークンを提供しない。また、Aは、それがでトリガ要求の結果が通知されることに注意してくださいB（参照）ではなく、Cで（INVITE）。
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
参照してください-TO：<SIP：C.example;方法= REFER参照してください-TO = "<一口：D.example>"？>
This reference would result in the following flow:
このリファレンスでは、以下の流れになります：
A B C D
| F1 REFER | | |
|------------------>| | |
| 202 Accepted | | |
|<------------------| | |
| NOTIFY | | |
|<------------------| F2 REFER | |
| 200 OK |------------------>| |
|------------------>| 202 Accepted | |
| F3 NOTIFY |<------------------| |
|<------------------| NOTIFY | |
| 200 OK |<------------------| F4 INVITE |
|------------------>| 200 OK |------------------>|
| |------------------>| 200 OK |
| | NOTIFY |<------------------|
| |<------------------| ACK |
| | 200 OK |------------------>|
| |------------------>| |
| | | |
F1 REFER sip:B SIP/2.0 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 To: <sip:B.example> From: <sip:A.example>;tag=23490234 Call-ID: 2304098023@A.example CSeq: 2342093 REFER Max-Forwards: 70 Contact: <sip:A.example> Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D>.example"> Referred-By: <sip:A.example>; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value)
F1、SIP REFER：BのSIP / 2.0経由：SIP / 2.0 / UDP A.example;ブランチ= z9hG4bK3802394232へ：<SIP：B.example>：<SIP：A.example>から、タグ= 23490234のCall-ID：2304098023 @ A.exampleのCSeq：2342093 REFERマックス・フォワード：70お問い合わせ：<SIP：A.example>参照してください-TO：<SIP：？C.example;方法= REFER参照してください-TO = "<一口：D>。実施例">呼ばバイ：<SIP：A.example>。 CID = "23094202342.10123091233@A.example" のContent-Type：マルチパート/混合。境界=ユニーク-境界-1のContent-Length：（適切な値）
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional
--dragons39のContent-Type：メッセージ/ sipfragのContent-処分：AIB。取り扱い=オプション
Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>"> Referred-By: <sip:A.example>; cid="23094202342.10123091233@A.example"
日付：木、2002年2月21日13時02分〇三秒GMT参照してください-TO：<SIP：C.example;方法= REFER = "<一口：D.example>"-を参照してください？>と呼ば-から：<SIP：A 。実施例>; CID = "23094202342.10123091233@A.example"
--dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--dragons39のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature goes here)
（適切な署名がここに入ります）
--dragons39-- --unique-boundary-1--
--dragons39-- --unique境界-1--
F2 REFER sip:C.example SIP/2.0 Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842 To: <sip:C.example> From: <sip:B.example>;tag=2934u23 Call-ID: 203942834@B.example CSeq: 8321039 REFER Max-Forwards: 70 Contact: <sip:B.example> Refer-To: <sip:D.example> Referred-By: <sip:A.example>; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value)
<一口：C.example>から<SIP：B.example>;：C.example SIP / 2.0経由：ブランチ= z9hG4bK00239842に、SIP / 2.0 / UDP B.example F2は、SIPをREFERタグ= 2934u23コールID： 203942834@B.exampleのCSeq：8321039は、マックス・フォワード参照：70お問い合わせ：<SIP：B.example>参照してください-TO：<SIP：D.example>と呼ばバイ：<SIP：A.example>を。 CID = "23094202342.10123091233@A.example" のContent-Type：マルチパート/混合。境界=ユニーク-境界-1のContent-Length：（適切な値）
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional
--dragons39のContent-Type：メッセージ/ sipfragのContent-処分：AIB。取り扱い=オプション
Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>"> Referred-By: <sip:A.example>;cid="23094202342.1012309123@A.example"
日付：木、2002年2月21日13時02分〇三秒GMT参照してください-TO：<SIP：C.example;方法= REFER = "<一口：D.example>"-を参照してください？>と呼ば-から：<SIP：A 。実施例>; CID = "23094202342.1012309123@A.example"
--dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--dragons39のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature goes here)
（適切な署名がここに入ります）
--dragons39-- --unique-boundary-1--
--dragons39-- --unique境界-1--
F3 NOTIFY sip:A.example SIP/2.0 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 To: <sip:A.example>;tag=23490234 From: <sip:B.example>;tag=5923020 Call-ID: 2304098023@A.example CSeq: 29420342 NOTIFY Event: refer;id=2342093 Subscription-State: terminated Max-Forwards: 70 Contact: <sip:B.example> Content-Type: message/sipfrag Content-Length: (appropriate value)
<一口：A.example>;タグ= 23490234から：<SIP：B.example>;;：A.example SIP / 2.0経由：ブランチ= z9hG4bK3802394232にSIP / 2.0 / UDP A.example F3は、SIPのNOTIFYタグ= 5923020コールIDを：2304098023@A.exampleのCSeq：29420342イベントをNOTIFY：参照してください; ID = 2342093のサブスクリプション・ステート：マックス・フォワードを終了：70お問い合わせ：<SIP：B.example>のContent-Type：メッセージ/ sipfragのコンテンツ長を： （適切な値）
SIP/2.0 202 Accepted
SIP / 2.0 202受け入れ
F4 INVITE sip:D.example SIP/2.0 Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234 To: <sip:D.example> From: <sip:C.example>;tag=023942334 Call-ID: 23489020352@C.example CSeq: 1230934 INVITE Max-Forwards: 70 Contact: <sip:C.example> Referred-By: <sip:A.example>; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value)
D.example SIP / 2.0経由：F4は、SIP INVITE SIP / 2.0 / UDP C.exampleを、ブランチ= z9hG4bK29348234へ：<SIP：D.example>から<SIP：C.example>;タグ= 023942334コールID： 23489020352@C.exampleのCSeq：1230934は、マックス・フォワードをINVITE：70お問い合わせ：<SIP：C.example>と呼ばバイ：<SIP：A.example>。 CID = "23094202342.10123091233@A.example" のContent-Type：マルチパート/混合。境界=ユニーク-境界-1のContent-Length：（適切な値）
--unique-boundary-1 Content-Type: application/sdp Content-Length: (appropriate value) v=0 o=C 2890844526 2890844526 IN IP4 C.example s=Session SDP c=IN IP4 C.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
--unique境界-1コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：（適正値）V = 0、O = C 2890844526 2890844526 IN IP4 C.example S =セッションのSDP C = IN IP4 C.example T = 0 M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=dragons39
Content-ID: <23094202342.10123091233@A.example>
Content-Length: (appropriate value)
--dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional
--dragons39のContent-Type：メッセージ/ sipfragのContent-処分：AIB。取り扱い=オプション
Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D.example>"> Referred-By: <sip:A.example>; cid="23094202342.1012309123@A.example"
日付：木、2002年2月21日13時02分〇三秒GMT参照してください-TO：<SIP：C.example;方法= REFER = "<一口：D.example>"-を参照してください？>と呼ば-から：<SIP：A 。実施例>; CID = "23094202342.1012309123@A.example"
--dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required
--dragons39のContent-Type：アプリケーション/ PKCS7署名。名前= smime.p7sコンテンツ転送 - エンコード：base64でコンテンツディスポジション：添付ファイル;ファイル名= smime.p7s。ハンドリング=必要
(appropriate signature goes here)
（適切な署名がここに入ります）
--dragons39-- --unique-boundary-1--
--dragons39-- --unique境界-1--
This document defines a new SIP header field name with a compact form (Referred-By and b respectively). It also defines a new SIP client error response code (429).
この文書は、コンパクトな形態（以下、BYおよびBにそれぞれ）と新しいSIPヘッダフィールド名を定義します。また、新しいSIPクライアントエラー応答コード（429）を定義します。
The following changes are reflected at:
以下の変更がで反射されています。
http:///www.iana.org/assignments/sip-parameters
http：///www.iana.org/assignments/sip-parameters
The following row has been added to the header field section (replacing any existing row for Referred-By).
次の行は、（以下バイための任意の既存の行を置換する）ヘッダーフィールドセクションに追加されました。
Header Name Compact Form Reference Referred-By b [RFC3892]
呼ば-BY B [RFC3892]ヘッダー名コンパクトなフォームリファレンス
The following row has been added to the response code section under the Request Failure 4xx heading.
次の行は、要求失敗4XXの見出しの下にレスポンスコードセクションに追加されています。
429 Provide Referrer Identity [RFC3892]
429リファラーアイデンティティ[RFC3892]を提供
Rohan Mahy distilled RFC2822's msg-id into this document's definition of sip-clean-msg-id.
ロハンマーイは、SIP-クリーン-MSG-IDのこの文書の定義にRFC2822のMSG-IDを蒸留しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[2] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[3] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[3]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4]、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月スパークス。
[5] 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.
[5]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[7]ピーターソン、J.が、進歩、2003年3月に仕事「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化」。
[8] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2003.
、進歩、2003年2月における作業 - [8]、R.とA.ジョンストン、「転送セッション開始プロトコル呼制御を」スパークス。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
Robert J. Sparks Xten 5100 Tennyson Parkway Suite 1000 Plano, TX 75024
ロバート・J・スパークスXTEN 5100テニソンパークウェイスイート1000年プラノ、テキサス州75024
EMail: RjS@xten.com
メールアドレス：RjS@xten.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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/S HE 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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されています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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。