RFC5368 日本語訳
5368 Referring to Multiple Resources in the Session InitiationProtocol (SIP). G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin,H. Khartabil. October 2008. (Format: TXT=29389 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo
Request for Comments: 5368 Ericsson
Category: Standards Track A. Niemi
M. Isomaki
Nokia
M. Garcia-Martin
Ericsson
H. Khartabil
Ericsson Australia
October 2008
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 5368年のエリクソンカテゴリ: 標準化過程A.Niemi M.IsomakiノキアM.ガルシア-マーチンエリクソンH.Khartabilエリクソンオーストラリア2008年10月
Referring to Multiple Resources in the Session Initiation Protocol (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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag.
このドキュメントは、ただ一つの要求における複数のリソースを示すのにそれを使用できるようにSIP REFERメソッドと拡大を定義します。 これらの拡大が(URI)が記載するUniform Resource Identifierに指針の使用を含んでいる、Refer、-、ヘッダーフィールドと「倍数参照してください」SIPオプションタグ。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4
5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4
6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5
7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 6
8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 6
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 操作. . . . . . . . . . . . . . . . . . . . 3 4の概要。 倍数参照しているSIP Option-タグ.4 5。 抑圧して、参照してください、暗黙の購読. . . . . . . . . . 4 6です。 URIリスト形態.5 7。 一口発行人を参照している. . . . . . . . . . . . . . . . 6 8の振舞い。 受取人を参照している.6 9の振舞い。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 11。 IANA問題. . . . . . . . . . . . . . . . . . . . . 10 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1。 引用規格. . . . . . . . . . . . . . . . . . 10 12.2。 有益な参照. . . . . . . . . . . . . . . . . 11
Camarillo, et al. Standards Track [Page 1] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[1ページ]RFC5368一口倍数は2008年10月に参照されます。
1. Introduction
1. 序論
RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with a REFER method that allows a user agent (UA) to request a second UA to send a SIP request to a third party. For example, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP UA to send a REFER request to Bob's UA providing Carol's SIP Contact information. Assuming Bob has given it permission, Bob's UA will attempt to call Carol using that contact. That is, it will send an INVITE request to that contact.
RFC3261(SIP)[RFC3261]はユーザエージェント(UA)がSIP要求を第三者に送るよう第2のUAに要求できるREFERメソッドでRFC3515[RFC3515]によって広げられます。 例えば、アリスが、ボブとの呼び出しでいて、ボブが、キャロルと話す必要であると決めるなら、アリスは、キャロルのSIP Contact情報を提供しながら、REFER要求をボブのUAに送るよう彼女のSIP UAに命令できます。 ボブが許可をそれに与えたと仮定すると、ボブのUAは、キャロルをその接触を使用すると呼ぶのを試みるでしょう。 すなわち、それはINVITE要求をその接触に送るでしょう。
A number of applications need to request this second UA to initiate transactions towards a set of destinations. In one example, the moderator of a conference may want the conference server to send BYE requests to a group of participants. In another example, the same moderator may want the conference server to INVITE a set of new participants.
応募件数は、1セットの目的地に向かってトランザクションを開始するようこの第2UAに要求する必要があります。 1つの例では、会議の議長は、会議サーバに関係者のグループへの要求をBYEに送って欲しいかもしれません。 別の例では、同じ議長は新しい関係者のINVITE aセットに会議サーバが欲しいかもしれません。
We define an extension to the REFER method so that REFER requests can be used to refer other user agents (such as conference servers) to multiple destinations. In addition, this mechanism uses the suppression of the REFER method implicit subscription specified in RFC 4488 [RFC4488].
私たちは、他のユーザエージェント(会議サーバなどの)を複数の目的地に差し向けるのにREFER要求を使用できるようにREFERメソッドと拡大を定義します。 さらに、このメカニズムはRFC4488[RFC4488]で指定されたREFERのメソッドの暗黙の購読の抑圧を使用します。
2. Terminology
2. 用語
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 [RFC2119] and indicate requirement levels for compliant implementations.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが本書ではこと解釈されるのは中でBCP14について説明しました、RFC2119[RFC2119]であり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
This document reuses the following terminology defined in RFC 3261 [RFC3261]:
このドキュメントはRFC3261[RFC3261]で定義された以下の用語を再利用します:
o User Agent (UA) o User Agent Client (UAC) o User Agent Server (UAS)
o ユーザエージェント(UA)o UserエージェントClient(UAC)o UserエージェントServer(UAS)
This document defines the following new terms:
このドキュメントは次の新学期を定義します:
REFER-Issuer: a user agent issuing a REFER request.
発行人を参照します: REFER要求を出すユーザエージェント。
REFER-Recipient: an entity receiving a REFER request and forwarding
a SIP request to a number of REFER-Targets. The REFER-Recipient
is typically a network entity, such as a URI-list server, that
acts as a UAS for REFER requests and as a UAC for other SIP
requests.
受取人を参照します: 多くのREFER-目標にREFER要求を受け取って、SIP要求を転送する実体。 通常、REFER-受取人は他のSIPのためのREFER要求とUACとしてのUASが要求するように行動するURIリストサーバなどのネットワーク実体です。
Camarillo, et al. Standards Track [Page 2] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[2ページ]RFC5368一口倍数は2008年10月に参照されます。
REFER-Target: a UA of the intended final recipient of a SIP request
generated by the REFER-Recipient.
目標を参照します: REFER-受取人によって生成されたSIP要求の意図している最終的な受取人のUA。
3. Overview of Operation
3. 操作の概要
This document describes an application of URI-list services [RFC5363] that allows a URI-list service to receive a SIP REFER request containing a list of targets. The URI-list service invokes the requested SIP method to each of the targets contained in the list. This type of URI-list service is referred to as a REFER-Recipient throughout this document.
このドキュメントはURIリストサービスが目標のリストを含むSIP REFER要求を受け取ることができるURIリストサービス[RFC5363]の応用について説明します。 URIリストサービスはリストに含まれたそれぞれの目標へ要求されたSIPメソッドを呼び出します。 このタイプのURIリストサービスはこのドキュメント中にREFER-受取人と呼ばれます。
This document defines an extension to the SIP REFER method specified in RFC 3515 [RFC3515] that allows a SIP UAC to include a URI list as specified in RFC 4826 [RFC4826] of REFER-Targets in a REFER request and send it to a REFER-Recipient. The REFER-Recipient creates a new SIP request for each entry in the URI list and sends it to each REFER-Recipient.
このドキュメントはSIP UACにREFER要求で4826個のRFC REFER-目標[RFC4826]の指定されるとしてのURIリストを含めて、REFER-受取人にそれを送らせるRFC3515[RFC3515]で指定されたSIP REFERメソッドと拡大を定義します。 REFER-受取人は、URIリストにおける各エントリーに新しいSIP要求を作成して、各REFER-受取人にそれを送ります。
The URI list that contains the list of targets is used in conjunction with RFC 5364 [RFC5364] to allow the sender indicate the role (e.g., 'to', 'cc', or anonymous) in which the REFER-Target is involved in the signalling.
目標のリストを含むURIリストは許容するRFC5364[RFC5364]に関連して使用されて、送付者がREFER-目標が合図にかかわる役割(例えば、'cc'の、または、匿名の'to')を示すということです。
We represent multiple targets of a REFER request using a URI list as specified in RFC 4826 [RFC4826]. A REFER-Issuer that wants to refer a REFER-Recipient to a set of destinations creates a SIP REFER request. The Refer-To header contains a pointer to a URI list, which is included in a body part, and an option-tag in the Require header field: "multiple-refer". This option-tag indicates the requirement to support the functionality described in this specification.
私たちは、RFC4826[RFC4826]で指定されているとしてURIリストを使用することでREFER要求のマルチターゲットを表します。 REFER-受取人を1セットの目的地に差し向けたがっているREFER-発行人はSIP REFER要求を作成します。 Refer、-、ヘッダー、Requireヘッダーフィールドに身体の部分に含まれているURIリストとオプションタグに指針を含んでいます: 「倍数参照してください。」 このオプションタグはこの仕様で説明された機能性をサポートするという要件を示します。
When the REFER-Recipient receives such a request, it creates a new request per REFER-Target and sends them, one to each REFER-Target.
REFER-受取人がそのような要求を受け取るとき、それは、REFER-目標あたり1つの新しい要求を作成して、それら(各REFER-目標への1)を送ります。
This document does not provide any mechanism for REFER-Issuers to find out about the results of a REFER request containing multiple REFER-Targets. Furthermore, it does not provide support for the implicit subscription mechanism that is part of the SIP REFER method. The way REFER-Issuers are kept informed about the results of a REFER is service specific. For example, a REFER-Issuer sending a REFER request to invite a set of participants to a conference can discover which participants were successfully brought into the conference by subscribing to the conference state event package specified in RFC 4575 [RFC4575].
REFER-発行人が複数のREFER-目標を含むREFER要求の結果を見つけるように、このドキュメントはどんなメカニズムも提供しません。 その上、それはSIP REFERメソッドの一部である内在している購読メカニズムのサポートを提供しません。 REFER-発行人がREFERの結果に関して知識があるように維持される方法はサービス特有です。 例えば、1セットの関係者を会議に招待するというREFER要求を送るREFER-発行人は、どの関係者がRFC4575[RFC4575]で指定された会議州のイベントパッケージに加入することによって会議に首尾よく連れて来られたかを発見できます。
Camarillo, et al. Standards Track [Page 3] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[3ページ]RFC5368一口倍数は2008年10月に参照されます。
4. The multiple-refer SIP Option-Tag
4. 倍数参照しているSIP Option-タグ
We define a new SIP option-tag for the Require and Supported header fields: "multiple-refer".
私たちはRequireとSupportedヘッダーフィールドのために新しいSIPオプションタグを定義します: 「倍数参照してください。」
A user agent including the "multiple-refer" option-tag in a Supported header field indicates compliance with this specification.
Supportedヘッダーフィールドに「倍数参照している」オプションタグを含むユーザエージェントはこの仕様へのコンプライアンスを示します。
A user agent generating a REFER with a pointer to a URI list in its Refer-To header field MUST include the "multiple-refer" option-tag in the Require header field of the REFER.
中にURIリストへの指針がある状態でREFERを生成するユーザエージェント、それ、Refer、-、ヘッダーフィールド、REFERのRequireヘッダーフィールドに「倍数参照している」オプションタグを含まなければなりません。
5. Suppressing REFER's Implicit Subscription
5. 抑圧して、参照してください、暗黙の購読です。
REFER requests with a single REFER-Target establish implicitly a subscription to the refer event. The REFER-Issuer is informed about the result of the transaction towards the REFER-Target through this implicit subscription. As described in RFC 3515 [RFC3515], NOTIFY requests sent as a result of an implicit subscription created by a REFER request contain a body of type "message/sipfrag", RFC 3420 [RFC3420], that describes the status of the transaction initiated by the REFER-Recipient.
ただ一つのREFER-目標とのREFER要求がそれとなく購読を確立する、イベントを参照してください。 REFER-発行人はこの暗黙の購読によるREFER-目標に向かったトランザクションの結果に関して知識があります。 RFC3515[RFC3515]で説明されるように、REFER要求で作成された暗黙の購読の結果、送られたNOTIFY要求はタイプ「メッセージ/sipfrag」、REFER-受取人によって開始されたトランザクションの状態について説明するRFC3420[RFC3420]のボディーを含んでいます。
In the case of a REFER-Issuer that generates a REFER with multiple REFER-targets, the REFER-Issuer is typically already subscribed to other event packages that can provide the information about the result of the transactions towards the REFER-Targets. For example, a moderator instructing a conference server to send a BYE request to a set of participants is usually subscribed to the conference state event package for the conference. Notifications to this event package will keep the moderator and the rest of the subscribers informed of the current list of conference participants.
複数のREFER-目標があるREFERを生成するREFER-発行人の場合では、REFER-発行人は既にREFER-目標に向かってトランザクションの結果の情報を供給できる他のイベントパッケージに通常申し込まれます。 例えば、通常、1セットの関係者にBYE要求を送るよう会議サーバに命令している議長は会議のために会議州のイベントパッケージに申し込まれます。 このイベントパッケージへの通知は議長と会議の参加者の現在のリストにおいて知識がある加入者の残りを保つでしょう。
Most of the applications using the multiple REFER technology described in this memo do not need its implicit subscription. Consequently, a SIP REFER-Issuer generating a REFER request with multiple REFER-Targets SHOULD include the "norefersub" option-tag in a Require header field and SHOULD include a Refer-Sub header field set to "false" to indicate that no notifications about the requests should be sent to the REFER-Issuer. The REFER-Recipient SHOULD honor the suggestion and also include a Refer-Sub header field set to "false" in the 200 (OK) response. The "norefersub" SIP option-tag and the Refer-Sub header field are specified in RFC 4488 [RFC4488].
このメモで説明された複数のREFER技術を使用するアプリケーションの大部分は暗黙の購読を必要としません。 その結果、SHOULDが含む複数のREFER-目標"norefersub"オプションタグでRequireヘッダーフィールドでREFER要求を生成するSIP REFER-発行人とSHOULDは要求に関する通知が全くREFER-発行人に送られるべきでないのを示すために「誤っていること」にRefer-潜水艦ヘッダーフィールドセットを含めます。 REFER-受取人SHOULDは提案を光栄に思って、また、200で「誤った」(OKの)応答にRefer-潜水艦ヘッダーフィールドセットを含めます。 "norefersub"SIPオプションタグとRefer-潜水艦ヘッダーフィールドはRFC4488[RFC4488]で指定されます。
RFC 4488 [RFC4488] indicates that a condition for the REFER-Issuer
to include a Refer-Sub header is that the REFER-Issuer is sure
that the REFER request will not fork.
RFC4488[RFC4488]は、REFER-発行人がRefer-潜水艦ヘッダーを含む状態がREFER-発行人がREFER要求が分岐しないのを確信しているということであることを示します。
Camarillo, et al. Standards Track [Page 4] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[4ページ]RFC5368一口倍数は2008年10月に参照されます。
At the time of writing, there is no extension that allows to report the status of several transactions over the implicit subscription associated with a REFER dialog. That is the motivation for this document to recommend the usage of the "norefersub" option-tag. If in the future such an extension is defined, REFER-Issuers using it could refrain from using the "norefersub" option-tag and use the new extension instead.
これを書いている時点で、REFER対話に関連している暗黙の購読の上でそれでいくつかのトランザクションの状態を報告する拡大が全くありません。 それはこのドキュメントが"norefersub"オプションタグの使用法を推薦する動機です。 そのような拡大が将来定義されるなら、それを使用するREFER-発行人は、"norefersub"オプションタグを使用するのを控えて、代わりに新しい拡張子を使用するかもしれません。
6. URI-List Format
6. URIリスト形態
As described in RFC 5363 [RFC5363], specifications of individual URI- list services need to specify a default format for 'recipient-list' bodies used within the particular service.
RFC5363[RFC5363]で説明されるように、個々にURIリストサービスの仕様は、特定のサービスの中で使用された'受取人リスト'ボディーに省略時書式を指定する必要があります。
The default format for 'recipient-list' bodies for REFER-Issuers and REFER-Recipients is RFC 4826 [RFC4826] extended with RFC 5364 [RFC5364]. REFER-Recipients handling 'recipient-list' bodies MUST support both of these formats. Both REFER-Issuers and REFER- Recipients MAY support other formats.
REFER-発行人とREFER-受取人のための'受取人リスト'ボディーのための省略時書式はRFC5364[RFC5364]と共に広げられたRFC4826です[RFC4826]。 REFER-受取人取り扱い'受取人リスト'ボディーはこれらの形式の両方を支えなければなりません。 REFER-発行人とREFER受取人の両方が他の形式をサポートするかもしれません。
As described in RFC 5364 [RFC5364], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the target will get the referred SIP request. However, depending on the target SIP method, a 'copyControl' attribute lacks sense. For example, while a 'copyControl' attribute can be applied to INVITE requests, it does not make sense with mid-dialog requests such as BYE requests.
RFC5364[RFC5364]で説明されるように、“to"、「cc」か"bcc"のどちらかに設定された'copyControl'属性で各URIにタグ付けをすることができます、目標が参照されたSIP要求を得る役割を示して。 しかしながら、目標SIPメソッドによって、'copyControl'属性は感覚を欠いています。 例えば、'copyControl'属性をINVITE要求に適用できる間、それはBYE要求などの中間の対話要求で理解できません。
In addition to the 'copyControl' attribute, URIs can be tagged with the 'anonymize' attribute (also specified in RFC 5364 [RFC5364]) to prevent that the REFER-Recipient discloses the target URI in a URI list.
'copyControl'属性に加えて、URIは'anonymizeする'属性(また、RFC5364[RFC5364]では、指定される)でタグ付けをされて、それを防いで、REFER-受取人がURIリストの目標URIを明らかにするということであるかもしれません。
Additionally, RFC 5364 [RFC5364] defines a 'recipient-list-history' body that contains the list of targets. The default format for 'recipient-list-history' bodies for conference services is also RFC 4826 [RFC4826] extended with RFC 5364 [RFC5364]. REFER-Recipients supporting this specification MUST support both of these formats; REFER-Targets MAY support these formats. Both REFER-Recipients and REFER-Targets MAY support other formats.
さらに、RFC5364[RFC5364]は目標のリストを含む'受取人リスト歴史'ボディーを定義します。 また、会議サービスのための'受取人リスト歴史'ボディーのための省略時書式はRFC5364[RFC5364]と共に広げられたRFC4826です[RFC4826]。 この仕様をサポートするREFER-受取人はこれらの形式の両方をサポートしなければなりません。 REFER-目標はこれらの形式をサポートするかもしれません。 REFER-受取人とREFER-目標の両方が他の形式をサポートするかもしれません。
Nevertheless, RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XML Configuration Access Protocol (XCAP) root URI, that are not needed by the multiple REFER service defined in this document.
それにもかかわらず、RFC4826[RFC4826]は参照でXML Configuration Accessプロトコル(XCAP)根のURIに比例してエントリーを含む階層的なリストや能力などの本書では定義された複数のREFERサービスで必要でない特徴を提供します。
Camarillo, et al. Standards Track [Page 5] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[5ページ]RFC5368一口倍数は2008年10月に参照されます。
Figure 1 shows an example of a flat list that follows the resource list document.
図1はリソースリストドキュメントに従う平坦なリストに関する例を示しています。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ「つぼ:ietf:params:xml:ナノ秒: リソースリスト」がxmlnsする><リソースリストxmlns=: cpが等しい、「つぼ:ietf:params: xml:ナノ秒:copycontrol">"
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
</list>
</resource-lists>
<リスト><エントリーuriは「一口: bill@example.com 」cpと等しいです: copyControl="to"/><エントリーuriは「一口: joe@example.org 」cpと等しいです: 「cc」/><copyControl=エントリーuriは「一口: ted@example.net 」cpと等しいです: copyControlは"bcc"/></リスト></リソースリスト>と等しいです。
Figure 1: URI list
図1: URIリスト
7. Behavior of SIP REFER-Issuers
7. 振舞い、発行人を参照して、ちびちび飲んでください。
As indicated in Sections 4 and 5, a SIP REFER-Issuer that creates a REFER request with multiple REFER-Targets includes a "multiple-refer" and "norefersub" option-tags in the Require header field and, if appropriate, a Refer-Sub header field set to "false". The REFER- Issuer includes the set of REFER-Targets in a recipient-list body whose disposition type is 'recipient-list', as defined in RFC 5363 [RFC5363]. The URI-list body is further described in Section 6.
セクション4と5にみられるように、複数のREFER-目標とのREFER要求を作成するSIP REFER-発行人は「倍数参照してください」とRequireヘッダーフィールドと適切でありRefer-潜水艦ヘッダーフィールドにおけるオプションタグが「誤っていること」に設定する"norefersub"を含んでいます。 REFER発行人は気質タイプが'受取人リスト'である受取人リスト本体にREFER-目標のセットを含んでいます、RFC5363[RFC5363]で定義されるように。 URIリスト本体はセクション6でさらに説明されます。
The Refer-To header field of a REFER request with multiple REFER- Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part that carries the URI list. The REFER-Issuer SHOULD NOT include any particular URI more than once in the URI list.
Refer、-、複数のREFER目標とのREFER要求のヘッダーフィールドはURIリストを運ぶ身体の部分を示す指針(すなわち、RFC2392[RFC2392]に従ってコンテントID Uniform Resource Locator(URL))を含まなければなりません。 REFER-発行人SHOULD NOTはURIリストに一度より多くのどんな特定のURIも含んでいます。
RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple REFER service defined in this document. Therefore, when using the default resource list document, SIP REFER-Issuers generating REFER requests with multiple REFER-Targets SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
RFC4826[RFC4826]は特徴を提供します、階層的なリストや参照でXCAP根のURIに比例してエントリーを含む能力のように。 しかしながら、これらの特徴は本書では定義された複数のREFERサービスで必要ではありません。 したがって、デフォルトリソースリストドキュメントを使用するとき、複数のREFER-目標SHOULD使用によるREFER要求に平坦なリスト(すなわち、階層的なリストがない)を生成するSIP REFER-発行人とSHOULD NOTは<エントリー審判>に要素を使用します。
8. Behavior of REFER-Recipients
8. 受取人を参照する振舞い
The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 [RFC3515] to determine the status code of the response to the REFER.
REFER-受取人は、REFERへの応答のステータスコードを決定するために.2セクション2.4RFC3515[RFC3515]で約束を守ります。
The REFER-Recipient SHOULD not create an implicit subscription, and SHOULD add a Refer-Sub header field set to "false" in the 200 OK response.
REFER-受取人SHOULDは暗黙の購読を作成しません、そして、SHOULDはRefer-潜水艦ヘッダーフィールドが200OK応答で「誤っていること」にセットしたと言い足します。
Camarillo, et al. Standards Track [Page 6] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[6ページ]RFC5368一口倍数は2008年10月に参照されます。
The incoming REFER request typically contains a URI-list document or reference with the actual list of targets. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", and if the request is appropriate for the service, e.g., it is not received mid-dialog, the REFER-Recipient SHOULD include a URI list in each of the outgoing requests. This list SHOULD be formatted according to RFC 4826 [RFC4826] and RFC 5364 [RFC5364]. The REFER-Recipient MUST follow the procedures specified in RFC 4826 [RFC4826] with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes.
入って来るREFER要求は目標の実際のリストがあるURIリストドキュメントか参照を通常含んでいます。 このURIリストが'copyControl'属性セットで“to"の値にタグ付けをされたリソースか「cc」を含んで、サービスに、要求が適切であるなら、例えばそれが対話する状態で中間の受け取られないなら、REFER-受取人SHOULDはそれぞれの送信する要求にURIリストを含んでいます。 これはSHOULDを記載します。RFC4826[RFC4826]とRFC5364[RFC5364]に従って、フォーマットされてください。 REFER-受取人はRFC4826[RFC4826]で'anonymizeする'、'カウント'、および'copyControl'属性の取り扱いに関して指定された手順に従わなければなりません。
Section 4 of RFC 5363 [RFC5363] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, REFER-Recipients MUST take those actions specified in RFC 5363 [RFC5363] into account to avoid sending a duplicated request to the same target.
コピーされたURIがURIリストで見つけられるとき、RFC5363[RFC5363]のセクション4はケースについて論じます。 コピーされた要求を避けるために、REFER-受取人はコピーされた要求を同じ目標に送るのを避けるためにRFC5363[RFC5363]でアカウントに指定されたそれらの行動を取らなければなりません。
If the REFER-Recipient includes a URI list in an outgoing request, it MUST include a Content-Disposition header field, specified in RFC 2183 [RFC2183], with the value set to 'recipient-list-history' and a 'handling' parameter, specified in RFC 3204 [RFC3204], set to "optional".
REFER-受取人が送信する要求でURIリストを入れるなら、それは選択値群でRFC2183[RFC2183]で指定されたContent-気質ヘッダーフィールドを'受取人リスト歴史'に含めなければなりません、そして、RFC3204[RFC3204]で指定された'取り扱い'パラメタは「任意に」セットしました。
Since the multiple REFER service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a REFER-Recipient receiving a URI list with more information than what has been described in Section 6 MAY discard all the extra information.
複数のREFERサービスが階層的なリストを使用しないで、それを記載するので、XCAP根のURI(5月6日がセクションで説明されることよりすべてのその他の情報を捨てるかというさらに多くの情報でURIリストを受け取るREFER-受取人)の参照でエントリーを含めてください。
The REFER-Recipient follows the rules in RFC 3515 [RFC3515] to generate the necessary requests towards the REFER-Targets, acting as if it had received a regular (no URI list) REFER per each URI in the URI list.
REFER-受取人はREFER-目標に向かって必要な要求を生成するためにRFC3515[RFC3515]で約束を守ります、まるでURIリストで各URIあたり1通常(URIリストがない)のREFERを受けたかのように行動して。
9. Example
9. 例
Figure 2 shows an example flow where a REFER-Issuer sends a multiple- REFER request to the focus of a conference, which acts as the REFER- Recipient. The REFER-Recipient generates a BYE request per REFER- Target. Details for using REFER request to remove participants from a conference are specified in RFC 4579 [RFC4579].
図2は、REFER-発行人がどこでREFER受取人として機能する会議の焦点に複数のREFER要求を送るかを例の流動に示します。 REFER-受取人はREFER目標あたり1つのBYE要求を生成します。 REFERが会議から関係者を外すよう要求する使用のための詳細はRFC4579[RFC4579]で指定されます。
Camarillo, et al. Standards Track [Page 7] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[7ページ]RFC5368一口倍数は2008年10月に参照されます。
+--------+ +---------+ +--------+ +--------+ +--------+
| REFER | | REFER | | REFER | | REFER | | REFER |
| issuer | |recipient| |target 1| |target 2| |target 3|
| | | | | | | | | |
| Carol | | (focus) | | Bill | | Joe | | Ted |
+--------+ +---------+ +--------+ +--------+ +--------+
| 1. REFER | | | |
| ---------------->| | | |
| 2. 202 Accepted | | | |
|<---------------- | 3. BYE | | |
| | ----------->| | |
| | 4. BYE | | |
| | ----------------------->| |
| | 5. BYE | | |
| | ----------------------------------->|
| | 6. 200 OK | | |
| |<----------- | | |
| | 7. 200 OK | | |
| |<----------------------- | |
| | 8. 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
+--------+ +---------+ +--------+ +--------+ +--------+ | 参照してください。| | 参照してください。| | 参照してください。| | 参照してください。| | 参照してください。| | 発行人| |受取人| |目標1| |目標2| |目標3| | | | | | | | | | | | キャロル| | (焦点) | | ビル| | ジョー| | テッド| +--------+ +---------+ +--------+ +--------+ +--------+ | 1. 参照してください。| | | | | ---------------->|、|、|、|、| 2. 202は受け入れました。| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 3. さようなら| | | | | ----------->|、|、|、|、| 4. さようなら| | | | | ----------------------->|、|、|、| 5. さようなら| | | | | ----------------------------------->|、|、| 6. 200 OK| | | | | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 7. 200 OK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 8. 200 OK| | | | |<----------------------------------- | | | | | | | | | | | | | | | |
Figure 2: Example flow of a REFER request containing
multiple REFER-Targets
図2: 複数のREFER-目標を含むREFER要求の例の流動
The REFER request (1) contains a Refer-To header field that includes a pointer to the message body, which carries a list with the URIs of the REFER-Targets. In this example, the URI list does not contain the 'copyControl' attribute extension. The REFER's Require header field carries the "multiple-refer" and "norefersub" option-tags. The Request-URI is set to a Globally Routable User Agent URI (GRUU) [SIP-GRUU] (as a guarantee that the REFER request will not fork). The Refer-Sub header field is set to "false" to request the suppression of the implicit subscription. Figure 3 shows an example of this REFER request. The resource list document contains the list of REFER-Target URIs along with the method of the SIP request that the REFER-Recipient generates.
REFERが、(1)がaを含むよう要求する、Refer、-、REFER-目標のURIでリストを運ぶメッセージ本体に指針を含んでいるヘッダーフィールド。 この例では、URIリストは'copyControl'属性拡大を含んでいません。 REFERのRequireヘッダーフィールドは「倍数参照してください」と"norefersub"オプションタグを運びます。 Request-URIはGlobally Routable Userエージェントのユリ(GRUU)[SIP-GRUU]に設定されます(REFERが要求する保証が分岐しないとき)。 Refer-潜水艦ヘッダーフィールドは暗黙の購読の抑圧を要求するために「誤っていること」に設定されます。 図3はこのREFER要求に関する例を示しています。 リソースリストドキュメントはREFER-受取人が生成するSIP要求のメソッドに伴うREFER-目標URIのリストを含んでいます。
Camarillo, et al. Standards Track [Page 8] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[8ページ]RFC5368一口倍数は2008年10月に参照されます。
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 2 REFER
Contact: <sip:carol@client.chicago.example.com>
Refer-To: <cid:cn35t8jf02@example.com>
Refer-Sub: false
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 362
Content-ID: <cn35t8jf02@example.com>
REFER一口: conf-123@example.com;gruu;opaque はhha9s8d-999a SIP/2.0Viaと等しいです: SIP/2.0/TCP client.chicago.example.com; ブランチは前方へz9hG4bKhjhs8ass83マックスと等しいです: 70 To: 「コンファレンス123」<一口: conf-123@example.com 、gt;、From: キャロル<一口: carol@chicago.example.com 、gt;、; タグは32331呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 2 接触を参照してください: <一口: carol@client.chicago.example.com 、gt;、To:を参照します。 <Cid: cn35t8jf02@example.com 、gt;、潜水艦を参照します: 偽のRequire: norefersub Allow、倍数参照してください: 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、イベントを許容して通知してください: 対話Accept: アプリケーション/sdp、メッセージ/sipfragコンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リストのContent-長さ: 362コンテントID: <cn35t8jf02@example.com>。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" />
</list>
</resource-lists>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsは「つぼ:ietf:params:xml:ナノ秒: リソースリスト」xmlnsと等しいです: 「一口: http://www.w3.org/2001/XMLSchema-instance 「><リスト><エントリーuri=」 bill@example.com?method =BYE」/><xsi=エントリーuri=「ちびちび飲んでください: joe@example.org?method はBYEと等しく」/><エントリーuriが「ちびちび飲んでください: ted@example.net?method はBYEと等しく」/></リスト></リソースリスト>と等しいです。
Figure 3: REFER request with multiple REFER-Targets
図3: 複数のREFER-目標とのREFER要求
Figure 4 shows an example of the BYE request (3) that the REFER- Recipient sends to the first REFER-Target.
図4は、(3) REFER受取人が最初のREFER-目標に発信するのをBYE要求に関する例に示します。
BYE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8assmm
Max-Forwards: 70
From: "Conference 123" <sip:conf-123@example.com>;tag=88734
To: <sip:bill@example.com>;tag=29872
Call-ID: d432fa84b4c34098s812
CSeq: 34 BYE
Content-Length: 0
BYE一口: bill@example.com SIP/2.0Via: SIP/2.0/TCP conference.example.com; ブランチは前方へz9hG4bKhjhs8assmmマックスと等しいです: 70 From: 「コンファレンス123」<一口: conf-123@example.com 、gt;、;=88734To:にタグ付けをしてください <一口: bill@example.com 、gt;、; タグは29872呼び出しIDと等しいです: d432fa84b4c34098s812 CSeq: 34 さようならコンテンツの長さ: 0
Figure 4: BYE request
図4: BYE要求
Camarillo, et al. Standards Track [Page 9] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[9ページ]RFC5368一口倍数は2008年10月に参照されます。
10. Security Considerations
10. セキュリティ問題
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Given that a REFER-Recipient accepting REFER requests with multiple REFER-targets acts as a URI-list service, implementations of this type of server MUST follow the security-related rules in RFC 5363 [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
RFC5363[RFC5363]はSIP URI-リストサービスに関連する問題について議論します。 複数のREFER-目標によるREFER要求を受け入れるREFER-受取人がURIリストサービスとして務めるなら、このタイプのサーバの実装はRFC5363[RFC5363]のセキュリティ関連の規則に従わなければなりません。 これらの規則はクライアントのオプトインリスト、義務的な認証、および承認を含んでいます。
Additionally, REFER-Recipients SHOULD only accept REFER requests within the context of an application that the REFER-Recipient understands (e.g., a conferencing application). This implies that REFER-Recipients MUST NOT accept REFER requests for methods they do not understand. The idea behind these two rules is that REFER- Recipients are not used as dumb servers whose only function is to fan-out random messages they do not understand.
さらに、REFER-受取人SHOULDはREFER-受取人が(例えば、会議アプリケーション)を理解しているというアプリケーションの文脈の中のREFER要求を受け入れるだけです。 これは、REFER-受取人が彼らが理解していないメソッドを求めるREFER要求を受け入れてはいけないのを含意します。 これらの2つの規則の後ろの考えはそれらがする無作為のメッセージを四方八方に広げる唯一の機能がことである馬鹿なサーバが分からないようにREFER受取人が使用されていないということです。
11. IANA Considerations
11. IANA問題
This document defines a new SIP option-tag: "multiple-refer". This option-tag has been registered in the SIP Parameters registry.
このドキュメントは新しいSIPオプションタグを定義します: 「倍数参照してください。」 このオプションタグはSIP Parameters登録に登録されました。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
SIP Parameter Registryの「オプションタグ」セクションに以下の行を追加してあります:
+-----------------+-------------------------------------+-----------+ | Name | Description | Reference | +-----------------+-------------------------------------+-----------+ | multiple-refer | This option tag indicates support | [RFC5368] | | | for REFER requests that contain a | | | | resource list document describing | | | | multiple REFER targets. | | +-----------------+-------------------------------------+-----------+
+-----------------+-------------------------------------+-----------+ | 名前| 記述| 参照| +-----------------+-------------------------------------+-----------+ | 倍数参照してください。| このオプションタグはサポートを示します。| [RFC5368]| | | aを含むREFER要求のために| | | | リソースリストドキュメント説明| | | | 複数のREFER目標。 | | +-----------------+-------------------------------------+-----------+
Table 1: Registration of the 'multiple-refer' option-tag in SIP
テーブル1: SIPでの'倍数参照している'オプションタグの登録
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年8月。
Camarillo, et al. Standards Track [Page 10] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[10ページ]RFC5368一口倍数は2008年10月に参照されます。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[RFC2392] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2392、1998年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001.
[RFC3204] Zimmerer、E.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.、およびM.Zonoun、「ISUPとQSIG ObjectsのためのMIMEメディアタイプ」、RFC3204(2001年12月)。
[RFC3261] 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.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
RFC 3420, November 2002.
[RFC3420]はR.、「インターネットメディアTypeメッセージ/sipfrag」、RFC3420 2002年11月にスパークします。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3515] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol
(SIP) REFER Method Implicit Subscription", RFC 4488,
May 2006.
[RFC4488]レヴィン(O.、「セッション開始プロトコル(一口)の抑圧は方法の暗黙の購読を参照する」RFC4488)は2006がそうするかもしれません。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ(J.、「リソースリストを表すための拡張マークアップ言語(XML)形式」、RFC4826)は2007がそうするかもしれません。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-
List Services", RFC 5363, October 2008.
[RFC5363] キャマリロ、G.、およびA.B.ローチ、「セッション開始のための枠組みとセキュリティ問題はURIリストサービスについて議定書の中で述べ(ちびちび飲みます)」、RFC5363、2008年10月。
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup
Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists", RFC 5364,
October 2008.
[RFC5364]ガルシア-マーチン、M.、およびG.キャマリロ、「拡張マークアップ言語(XML)はリソースリストのコピーコントロール属性を表すための拡大をフォーマットします」、RFC5364、2008年10月。
12.2. Informative References
12.2. 有益な参照
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC4575] ローゼンバーグ、J.、Schulzrinne、H.、およびO.レヴィン、「コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ」、RFC4575(2006年8月)。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC4579] ジョンストン、A.、およびO.レヴィン、「セッション開始プロトコル(一口)は、ユーザエージェントのためにコントロール--会議を召集します」、BCP119、RFC4579、2006年8月。
[SIP-GRUU] Rosenberg, J., "Obtaining and Using Globally Routable
User Agent (UA) URIs (GRUU) in the Session Initiation
Protocol (SIP)", Work in Progress, October 2007.
[一口GRUU] ローゼンバーグ、J.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2007年10月)で働いています。
Camarillo, et al. Standards Track [Page 11] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[11ページ]RFC5368一口倍数は2008年10月に参照されます。
Authors' Addresses
作者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland
アキNiemiノキア私書箱321Nokia Group、FIN00045フィンランド
EMail: Aki.Niemi@nokia.com
メール: Aki.Niemi@nokia.com
Markus Isomaki Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland
マーカスIsomakiノキア私書箱100Nokia Group、FIN00045フィンランド
EMail: markus.isomaki@nokia.com
メール: markus.isomaki@nokia.com
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
ミゲルA.ガルシア-マーチンエリクソンVia de los Poblados13マドリード28033スペイン
EMail: miguel.a.garcia@ericsson.com
メール: miguel.a.garcia@ericsson.com
Hisham Khartabil Ericsson Australia
Hisham Khartabilエリクソンオーストラリア
EMail: hisham.khartabil@gmail.com
メール: hisham.khartabil@gmail.com
Camarillo, et al. Standards Track [Page 12] RFC 5368 SIP Multiple REFER October 2008
キャマリロ、他 標準化過程[12ページ]RFC5368一口倍数は2008年10月に参照されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Camarillo, et al. Standards Track [Page 13]
キャマリロ、他 標準化過程[13ページ]
一覧
スポンサーリンク
