RFC5366 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 5366                                      Ericsson
Category: Standards Track                                    A. Johnston
                                                                   Avaya
                                                            October 2008

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 5366年のエリクソンカテゴリ: 標準化過程A.ジョンストンAvaya2008年10月

        Conference Establishment Using Request-Contained Lists
                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 describes how to create a conference using SIP URI-list
   services.  In particular, it describes a mechanism that allows a User
   Agent Client to provide a conference server with the initial list of
   participants using an INVITE-contained URI list.

このドキュメントはSIP URI-リストサービスを利用することで会議を創設する方法を説明します。 特に、それはUserエージェントClientがINVITEによって含まれたURIリストを使用することで関係者の初期のリストを会議サーバに提供できるメカニズムについて説明します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. User Agent Client Procedures ....................................2
      3.1. Response Handling ..........................................2
      3.2. Re-INVITE Request Generation ...............................3
   4. URI-List Document Format ........................................3
   5. Conference Server Procedures ....................................5
      5.1. Re-INVITE Request Handling .................................6
   6. Example .........................................................6
   7. Security Considerations ........................................10
   8. IANA Considerations ............................................10
   9. Acknowledgments ................................................11
   10. References ....................................................11
      10.1. Normative References .....................................11
      10.2. Informative References ...................................12

1. 序論…2 2. 用語…2 3. ユーザエージェントクライアント手順…2 3.1. 応答取り扱い…2 3.2. 要求世代を再招待してください…3 4. URIリストドキュメント・フォーマット…3 5. コンファレンスサーバ手順…5 5.1. 要求取り扱いを再招待してください…6 6. 例…6 7. セキュリティ問題…10 8. IANA問題…10 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…12

Camarillo & Johnston        Standards Track                     [Page 1]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[1ページ]。

1.  Introduction

1. 序論

   Section 5.4 of [RFC4579] describes how to create a conference using
   ad hoc SIP [RFC3261] methods.  The client sends an INVITE request to
   a conference factory URI and receives the actual conference URI,
   which contains the "isfocus" feature tag, in the Contact header field
   of a response -- typically a 200 (OK) response.

[RFC4579]のセクション5.4は臨時のSIP[RFC3261]メソッドを使用することで会議を創設する方法を説明します。 クライアントは、会議工場のURIにINVITE要求を送って、実際の会議URIを受けます、応答のContactヘッダーフィールドで--通常200(OK)応答。URIは"isfocus"特徴タグを含みます。

   Once the UAC (User Agent Client) obtains the conference URI, it can
   add participants to the newly created conference in several ways,
   which are described in [RFC4579].

UAC(ユーザエージェントClient)がいったん会議URIを得ると、それはいくつかの方法で新たに作成された会議に関係者を追加できます。(方法は[RFC4579]に述べられます)。

   Some environments have tough requirements regarding conference
   establishment time.  They require the UAC to be able to request the
   creation of an ad hoc conference and to provide the conference server
   with the initial set of participants in a single operation.  This
   document describes how to meet this requirement using the mechanism
   to transport URI lists in SIP messages described in [RFC5363].

いくつかの環境には、会議設立時間に関する厳しい要件があります。 彼らは、UACが臨時の会議の創設を要求して、ただ一つの操作の関係者の始発を会議サーバに提供できるのを必要とします。 このドキュメントは[RFC5363]で説明されたSIPメッセージのURIリストを輸送するのにメカニズムを使用することでこの必要条件を満たす方法を説明します。

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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  User Agent Client Procedures

3. ユーザエージェントクライアント手順

   A UAC that wants to include the set of initial participants in its
   initial INVITE request to create an ad hoc conference adds a body
   whose disposition type is 'recipient-list', as defined in [RFC5363],
   with a URI list that contains the participants that the UAC wants the
   conference server to invite.  Additionally, the UAC MUST include the
   'recipient-list-invite' option-tag (which is registered with the IANA
   in Section 8) in a Require header field.  The UAC sends this INVITE
   request to the conference factory URI.

臨時の会議を創設するという初期のINVITE要求の初期の関係者のセットを含みたがっているUACは気質タイプが'受取人リスト'であるボディーを加えます、[RFC5363]で定義されるように、UACが、会議サーバに招待して欲しい関係者を含むURIリストで。 さらに、UAC MUSTはRequireヘッダーフィールドに'リストが招待する受取人'オプションタグ(セクション8にIANAに登録される)を含んでいます。 UACはこのINVITE要求を会議工場のURIに送ります。

   The INVITE transaction is also part of an offer/answer exchange that
   will establish a session between the UAC and the conference server,
   as specified in [RFC4579].  Therefore, the INVITE request may need to
   carry a multipart body: a session description and a URI list.

また、INVITEトランザクションはUACと会議サーバとのセッションを確立する申し出/答え交換の一部です、[RFC4579]で指定されるように。 したがって、INVITE要求は、複合ボディーを運ぶ必要があるかもしれません: セッション記述とURIは記載します。

3.1.  Response Handling

3.1. 応答取り扱い

   The status code in the response to the INVITE request does not
   provide any information about whether or not the conference server
   was able to bring the users in the URI list into the conference.
   That is, a 200 (OK) response means that the conference was created
   successfully, that the UAC that generated the INVITE request is in

INVITE要求への応答におけるステータスコードは会議サーバがURIリストのユーザを会議に運び込むことができたかどうかの少しの情報も提供しません。 すなわち、200(OK)応答は会議が首尾よく創設されて、それが要求があるINVITEを生成したUACであることを意味します。

Camarillo & Johnston        Standards Track                     [Page 2]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[2ページ]。

   the conference, and that the server understood the URI list.  If the
   UAC wishes to obtain information about the status of other users in
   the conference, it SHOULD use general conference mechanisms, such as
   the conference package, which is defined in [RFC4575].

会議、そして、サーバはURIリストを理解していました。 UACがそうしたいなら、会議で他のユーザの状態の情報を得てください、それ。SHOULDは一般的な会議メカニズムを使用します、会議パッケージなどのように、[RFC4575]で定義されるどれ。

3.2.  Re-INVITE Request Generation

3.2. 要求世代を再招待してください。

   The previous sections have specified how to include a URI list in an
   initial INVITE request to a conference server.  Once the INVITE-
   initiated dialog between the UAC and the conference server has been
   established, the UAC can send subsequent INVITE requests (typically
   referred to as re-INVITE requests) to the conference server to, for
   example, modify the characteristics of the media exchanged with the
   server.

前項は初期のINVITE要求で会議サーバにURIリストを含める方法を指定しました。UACと会議サーバの間のINVITEの開始している対話がいったん確立されると、UACは、例えば、サーバで交換されたメディアの特性を変更するために、その後のINVITE要求(再INVITE要求と通常呼ばれる)を会議サーバに送ることができます。

   At this point, there are no semantics associated with 'recipient-
   list' bodies in re-INVITE requests (although future extensions may
   define them).  Therefore, UACs SHOULD NOT include 'recipient-list'
   bodies in re-INVITE requests sent to a conference server.

ここに、再INVITE要求には'受取人リスト'ボディーに関連しているどんな意味論もありません(今後の拡大はそれらを定義するかもしれませんが)。 したがって、UACs SHOULDは会議サーバに送られた再INVITE要求に'受取人リスト'ボディーを含んでいません。

      Note that a difference between an initial INVITE request and a
      re-INVITE request is that while the initial INVITE request is sent
      to the conference factory URI, the re-INVITE request is sent to
      the URI provided by the server in a Contact header field when the
      dialog was established.  Therefore, from the UAC's point of view,
      the resource identified by the former URI supports 'recipient-
      list' bodies, while the resource identified by the latter does not
      support them.

初期のINVITE要求と再INVITE要求の違いが初期のINVITE要求を会議工場のURIに送りますが、対話が確立されたときサーバによってContactヘッダーフィールドに提供されたURIに再INVITE要求を送るということであることに注意してください。 したがって、UACの観点から、前のURIによって特定されたリソースは'受取人リスト'ボディーを支えます、後者によって特定されたリソースはそれらをサポートしませんが。

4.  URI-List Document Format

4. URIリストドキュメント・フォーマット

   As described in [RFC5363], specifications of individual URI-list
   services, like the conferencing service described here, need to
   specify a default format for 'recipient-list' bodies used within the
   particular service.

[RFC5363]で説明されるように、ここで説明された会議サービスのように、個々にURIリストサービスの仕様は、特定のサービスの中で使用された'受取人リスト'ボディーに省略時書式を指定する必要があります。

   The default format for 'recipient-list' bodies for conferencing UAs
   (User Agents) is the XML resource list format (which is specified in
   [RFC4826]) extended with the "Extensible Markup Language (XML) Format
   Extension for Representing Copy Control Attributes in Resource Lists"
   [RFC5364].  Consequently, conferencing UACs generating 'recipient-
   list' bodies MUST support both of these formats and MAY support other
   formats.  Conferencing servers able to handle 'recipient-list' bodies
   MUST support both of these formats and MAY support other formats.

会議UAs(ユーザエージェント)のための'受取人リスト'ボディーのための省略時書式は「リソースリストのコピーコントロール属性を表すための拡張マークアップ言語(XML)形式拡大」[RFC5364]で広げられたXMLリソースリスト形態([RFC4826]で指定される)です。 その結果、'受取人リスト'ボディーを生成する会議UACsはこれらの形式の両方をサポートしなければならなくて、他の形式をサポートするかもしれません。 '受取人リスト'ボディーを扱うことができる会議サーバは、これらの形式の両方をサポートしなければならなくて、他の形式をサポートするかもしれません。

   As described in "Extensible Markup Language (XML) Format Extension
   for Representing Copy Control Attributes in Resource Lists"
   [RFC5364], each URI can be tagged with a 'copyControl' attribute set

「リソースリストのコピーコントロール属性を表すための拡張マークアップ言語(XML)形式拡大」[RFC5364]で説明されるように、'copyControl'属性セットで各URIにタグ付けをすることができます。

Camarillo & Johnston        Standards Track                     [Page 3]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[3ページ]。

   to either "to", "cc", or "bcc", indicating the role in which the
   recipient will get the INVITE request.  Additionally, URIs can be
   tagged with the 'anonymize' attribute to prevent the conference
   server from disclosing the target URI in a URI list.

“to"、「cc」か受取人がINVITE要求を得る役割を示す"bcc"のどちらかに。 さらに、URIは'anonymizeする'属性でタグ付けをされて、会議サーバがURIリストの目標URIを明らかにするのを防ぐことができます。

   In addition, "Extensible Markup Language (XML) Format Extension for
   Representing Copy Control Attributes in Resource Lists" [RFC5364]
   defines a 'recipient-list-history' body that contains the list of
   recipients.  The default format for 'recipient-list-history' bodies
   for conferencing UAs is also the XML resource list document format
   specified in [RFC4826] extended with "Extensible Markup Language
   (XML) Format Extension for Representing Copy Control Attributes in
   Resource Lists" [RFC5364].  Consequently, conferencing UACs able to
   generate 'recipient-list-history' bodies MUST support these formats
   and MAY support others.  Conferencing UAs able to understand
   'recipient-list-history' MUST support these formats and MAY support
   others.  Conferencing servers able to handle 'recipient-list-history'
   bodies MUST support these formats and MAY support others.

さらに、「リソースリストのコピーコントロール属性を表すための拡張マークアップ言語(XML)形式拡大」[RFC5364]は受取人のリストを含む'受取人リスト歴史'ボディーを定義します。 また、会議UAsのための'受取人リスト歴史'ボディーのための省略時書式は「リソースリストのコピーコントロール属性を表すための拡張マークアップ言語(XML)形式拡大」[RFC5364]で広げられた[RFC4826]で指定されたXMLリソースリストドキュメント・フォーマットです。 その結果、'受取人リスト歴史'がボディーであると生成することができる会議UACsはこれらの形式をサポートしなければならなくて、他のものをサポートするかもしれません。 '受取人リスト歴史'を理解できる会議UAsはこれらの形式をサポートしなければならなくて、他のものをサポートするかもしれません。 '受取人リスト歴史'ボディーを扱うことができる会議サーバは、これらの形式をサポートしなければならなくて、他のものをサポートするかもしれません。

   Nevertheless, the XML resource list document specified in [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 conferencing
   service defined in this document, which only needs to transfer a flat
   list of URIs between a UA (User Agent) and the conference server.
   Therefore, when using the default resource list document,
   conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists)
   and SHOULD NOT use <entry-ref> elements.  A conference factory
   application receiving a URI list with more information than what has
   just been described MAY discard all the extra information.

それにもかかわらず、RFC4826で指定されたXMLリソースリストドキュメントは参照でXML Configuration Accessプロトコル(XCAP)根のURIに比例してエントリーを含む階層的なリストや能力などのしたがってこのドキュメント(UA(ユーザエージェント)と会議サーバの間にURIの平坦なリストを移す必要があるだけであるもの)で定義された会議サービスで必要でない特徴を提供します; デフォルトリソースリストドキュメントを使用するとき、会議UAs SHOULDは平坦なリスト(すなわち、階層的なリストがない)を使用します、そして、SHOULD NOTは<エントリー審判>に要素を使用します。 ちょうど説明されることより多くの情報でURIリストを受け取る会議工場のアプリケーションはすべてのその他の情報を捨てるかもしれません。

   Figure 1 shows an example of a flat list that follows the XML
   resource list document (specified in [RFC4826]) extended with
   "Extensible Markup Language (XML) Format Extension for Representing
   Copy Control Attributes in Resource Lists" [RFC5364].

図1は、XMLリソースリストドキュメント([RFC4826]では、指定される)に従う平坦なリストに関する例が「リソースリストのコピーコントロール属性を表すための拡張マークアップ言語(XML)形式拡大」[RFC5364]と共に広がったのを示します。

   <?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">
     <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>

<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsは「つぼ:ietf:params:xml:ナノ秒: リソースリスト」xmlnsと等しいです: cpは「つぼ:ietf:params: xml:ナノ秒:copycontrol「><リスト><エントリー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リスト

Camarillo & Johnston        Standards Track                     [Page 4]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[4ページ]。

5.  Conference Server Procedures

5. コンファレンスサーバ手順

   Conference servers that are able to receive and process INVITE
   requests with a 'recipient-list' body SHOULD include a 'recipient-
   list-invite' option-tag in a Supported header field when responding
   to OPTIONS requests.

OPTIONS要求に応じるとき、受信して、'受取人リスト'ボディーSHOULDと共に含むことができるプロセスINVITEが'受取人を要求するコンファレンスサーバが、'Supportedのオプションタグヘッダーフィールドをリストで招待します。

   On reception of an INVITE request containing a 'recipient-list' body
   as described in Section 3, a conference server MUST follow the rules
   described in [RFC4579] to create ad hoc conferences.  Once the ad hoc
   conference is created, the conference server SHOULD attempt to add
   the participants in the URI list to the conference as if their
   addition had been requested using any of the methods described in
   [RFC4579].

セクション3で説明されるように'受取人リスト'ボディーを含むINVITE要求のレセプションでは、会議サーバは臨時の会議を創設するために[RFC4579]で説明された規則に従わなければなりません。 臨時の会議がいったん創設されると、会議サーバSHOULDは、まるで彼らの追加が[RFC4579]で説明されたメソッドのどれかを使用することで要求されたかのようにURIリストの関係者を会議に追加するのを試みます。

   The INVITE transaction is also part of an offer/answer exchange that
   will establish a session between the UAC and the conference server,
   as specified in [RFC4579].  Therefore, the INVITE request may carry a
   multipart body: a session description and a URI list.

また、INVITEトランザクションはUACと会議サーバとのセッションを確立する申し出/答え交換の一部です、[RFC4579]で指定されるように。 したがって、INVITE要求は複合ボディーを運ぶかもしれません: セッション記述とURIは記載します。

   Once the conference server has created the ad hoc conference and has
   attempted to add the initial set of participants, the conference
   server behaves as a regular conference server and MUST follow the
   rules in [RFC4579].

会議サーバが、いったん臨時の会議を創設して、関係者の始発を加えるのを試みると、会議サーバは、通常の会議サーバとして振る舞って、[RFC4579]で約束を守らなければなりません。

   The incoming INVITE request will contain a URI-list body or reference
   (as specified in [RFC5363]) with the actual list of recipients.  If
   this URI list includes resources tagged with the 'copyControl'
   attribute set to a value of "to" or "cc", the conference server
   SHOULD include a URI list in each of the outgoing INVITE requests.
   This list SHOULD be formatted according to the XML format for
   representing resource lists (specified in [RFC4826]) and the
   copyControl extension specified in [RFC5364].

入って来るINVITE要求は受取人の実際のリストでURIリスト本体か参照を含むでしょう([RFC5363]で指定されるように)。 このURIリストが'copyControl'属性セットで“to"の値にタグ付けをされたリソースか「cc」を含んでいるなら、会議サーバSHOULDはそれぞれの送信するINVITE要求にURIリストを含んでいます。 これはSHOULDを記載します。XML形式に従って、リソースリスト([RFC4826]では、指定される)と[RFC5364]で指定されたcopyControl拡張子を表すためにフォーマットされてください。

   The URI-list service MUST follow the procedures specified in
   [RFC5364] with respect to the handling of the 'anonymize', 'count',
   and 'copyControl' attributes.

URIリストサービスは[RFC5364]で'anonymizeする'、'カウント'、および'copyControl'属性の取り扱いに関して指定された手順に従わなければなりません。

   If the conference server includes a URI list in an outgoing INVITE
   request, it MUST include a Content-Disposition header field (which is
   specified in [RFC2183]) with the value set to 'recipient-list-
   history' and a 'handling' parameter (as specified in [RFC3204]) set
   to "optional".

会議サーバが送信するINVITE要求にURIリストを含んでいるなら、それは「任意に」設定された'受取人リスト歴史と''取り扱い'パラメタ([RFC3204]で指定されるように)に選択値群があるContent-気質ヘッダーフィールド([RFC2183]で指定される)を含めなければなりません。

Camarillo & Johnston        Standards Track                     [Page 5]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[5ページ]。

5.1.  Re-INVITE Request Handling

5.1. 要求取り扱いを再招待してください。

   At this point, there are no semantics associated with 'recipient-
   list' bodies in re-INVITE requests (although future extensions may
   define them).  Therefore, a conference server receiving a re-INVITE
   request with a 'recipient-list' body and, consequently, a
   'recipient-list-invite' option-tag, following standard SIP
   procedures, rejects it with a 420 (Bad Extension), which carries an
   Unsupported header field listing the 'recipient-list-invite' option-
   tag.

ここに、再INVITE要求には'受取人リスト'ボディーに関連しているどんな意味論もありません(今後の拡大はそれらを定義するかもしれませんが)。 したがって、標準のSIP手順に従って、'受取人リスト'ボディーとその結果'リストが招待する受取人'オプションタグで再INVITE要求を受け取る会議サーバは420(悪いExtension)でそれを拒絶します('リストが招待する受取人'オプションタグを記載するUnsupportedヘッダーフィールドを運びます)。

      This is because the resource identified by the conference URI does
      not actually support this extension.  On the other hand, the
      resource identified by the conference factory URI does support
      this extension and, consequently, would include the 'recipient-
      list-invite' option-tag in, for example, responses to OPTIONS
      requests.

これは会議URIによって特定されたリソースが実際にこの拡大をサポートしないからです。 他方では、会議工場のURIによって特定されたリソースは、この拡大をサポートして、その結果、中と、例えば'受取人リスト招待'オプションタグを含んでいるでしょう、OPTIONS要求への応答。

6.  Example

6. 例

   Figure 2 shows an example of operation.  A UAC sends an INVITE
   request (F1) that contains an SDP body and a URI list to the
   conference server.  The conference server answers with a 200 (OK)
   response and generates an INVITE request to each of the UASs (User
   Agent Servers) identified by the URIs included in the URI list.  The
   conference server includes SDP and a manipulated URI list in each of
   the outgoing INVITE requests.

図2は操作に関する例を示しています。 UACはSDPボディーとURIリストを会議サーバに含むINVITE要求(F1)を送ります。会議サーバは、URIリストにURIを含んでいることによって特定されたそれぞれのUASs(ユーザエージェントServers)に200(OK)応答で答えて、INVITE要求を生成します。 会議サーバはそれぞれの送信するINVITE要求にSDPと操られたURIリストを含んでいます。

Camarillo & Johnston        Standards Track                     [Page 6]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[6ページ]。

   +--------+        +---------+      +--------+ +--------+ +--------+
   |SIP UAC |        | confer. |      |SIP UAS | |SIP UAS | |SIP UAS |
   |        |        | server  |      |   1    | |   2    | |   n    |
   +--------+        +---------+      +--------+ +--------+ +--------+
       |                  |               |          |          |
       | F1 INVITE        |               |          |          |
       | ---------------->|               |          |          |
       | F2 200 OK        |               |          |          |
       |<---------------- |  F3 INVITE    |          |          |
       |                  | ------------->|          |          |
       |                  |  F4 INVITE    |          |          |
       |                  | ------------------------>|          |
       |                  |  F5 INVITE    |          |          |
       |                  | ----------------------------------->|
       |                  |  F6 200 OK    |          |          |
       |                  |<------------- |          |          |
       |                  |  F7 200 OK    |          |          |
       |                  |<------------------------ |          |
       |                  |  F8 200 OK    |          |          |
       |                  |<----------------------------------- |
       |                  |               |          |          |
       |                  |               |          |          |
       |                  |               |          |          |

+--------+ +---------+ +--------+ +--------+ +--------+ |一口UAC| | 協議してください。 | |一口UAS| |一口UAS| |一口UAS| | | | サーバ| | 1 | | 2 | | n| +--------+ +---------+ +--------+ +--------+ +--------+ | | | | | | F1招待| | | | | ---------------->|、|、|、|、| F2 200OK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| F3招待| | | | | ------------->|、|、|、|、| F4招待| | | | | ------------------------>|、|、|、| F5招待| | | | | ----------------------------------->|、|、| F6 200OK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| F7 200OK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| F8 200OK| | | | |<----------------------------------- | | | | | | | | | | | | | | | |

                      Figure 2: Example of operation

図2: 操作に関する例

   Figure 3 shows an example of the INVITE request F1, which carries a
   multipart/mixed body composed of two other bodies: an application/sdp
   body that describes the session and an application/resource-lists+xml
   body that contains the list of target URIs.

図3は他の2つのボディーで構成された複合の、または、混ぜられたボディーを運ぶINVITE要求F1に関する例を示しています: セッションについて説明するアプリケーション/sdpボディーと目標URIのリストを含むアプリケーション/リソースリスト+xmlボディー。

   INVITE sip:conf-fact@example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com
       ;branch=z9hG4bKhjhs8ass83
   Max-Forwards: 70
   To: "Conf Factory" <sip:conf-fact@example.com>
   From: Alice <sip:alice@example.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 1 INVITE
   Contact: <sip:alice@atlanta.example.com>
   Allow: INVITE, ACK, CANCEL, BYE, REFER
   Allow-Events: dialog
   Accept: application/sdp, message/sipfrag
   Require: recipient-list-invite
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 690

INVITE一口: conf-fact@example.com SIP/2.0Via: SIP/2.0/TCP atlanta.example.com; ブランチは前方へz9hG4bKhjhs8ass83マックスと等しいです: 70 To: 「Conf工場」<一口: conf-fact@example.com 、gt;、From: アリス<一口: alice@example.com 、gt;、; タグは32331呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 1 接触を招いてください: <一口: alice@atlanta.example.com 、gt;、許容します: さようなら、招待、ACK、取り消してください、そして、イベントを許容して参照してください: 対話Accept: アプリケーション/sdp、メッセージ/sipfrag Require: リストが招待する受取人コンテントタイプ: 複合か混ぜられる;、境界=、「boundary1" Content-長さ:」 690

Camarillo & Johnston        Standards Track                     [Page 7]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[7ページ]。

   --boundary1
   Content-Type: application/sdp

--boundary1コンテントタイプ: アプリケーション/sdp

   v=0
   o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
   s=-
   c=IN IP4 192.0.2.1
   t=0 0
   m=audio 20000 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 20002 RTP/AVP 31
   a=rtpmap:31 H261/90000

v=0 o=alice2890844526 2890842807IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1tは0 0m=オーディオの20000RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ20002RTP/AVP31a=rtpmap: 31H261/90000と等しいです。

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: recipient-list

--boundary1コンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リスト

   <?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">
     <list>
       <entry uri="sip:bill@example.com" cp:copyControl="to" />
       <entry uri="sip:randy@example.net" cp:copyControl="to"
                                          cp:anonymize="true"/>
       <entry uri="sip:eddy@example.com" cp:copyControl="to"
                                         cp:anonymize="true"/>
       <entry uri="sip:joe@example.org" cp:copyControl="cc" />
       <entry uri="sip:carol@example.net" cp:copyControl="cc"
                                          cp:anonymize="true"/>
       <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
       <entry uri="sip:andy@example.com" cp:copyControl="bcc" />
     </list>
   </resource-lists>
   --boundary1--

<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsは「つぼ:ietf:params:xml:ナノ秒: リソースリスト」xmlnsと等しいです: cpは「つぼ:ietf:params: xml:ナノ秒:copyControl「><リスト><エントリーuri=」一口: bill@example.com 」cpと等しいです: copyControl="to"/><エントリーuriは「一口: randy@example.net 」cp: copyControl="to" cpと等しいです:、anonymizeする、= 「本当」/><エントリーuriは「一口: eddy@example.com 」cp: copyControl="to" cpと等しいです:; 本当..エントリー..等しい..一口..エントリー..等しい..一口..本当..エントリー..等しい..一口..エントリー..等しい..一口..等しい..リスト..リソースリスト

        Figure 3: INVITE request received at the conference server

図3: 会議サーバで受け取られたINVITE要求

   The INVITE requests F3, F4, and F5 are similar in nature.  All those
   INVITE requests contain a multipart/mixed body that is composed of
   two other bodies: an application/sdp body describing the session and
   an application/resource-lists+xml containing the list of recipients.
   The application/resource-lists+xml bodies are not equal to the
   application/resource-lists+xml included in the received INVITE
   request F1, because the conference server has anonymized those URIs
   tagged with the 'anonymize' attribute and has removed those URIs
   tagged with a "bcc" 'copyControl' attribute.  Figure 4 shows an
   example of the message F3.

INVITE要求のF3、F4、およびF5は同様です。 それらのすべてのINVITE要求が他の2つのボディーで構成される複合の、または、混ぜられたボディーを含んでいます: セッションについて説明するアプリケーション/sdpボディーと受取人のリストを含むアプリケーション/リソースリスト+xml。 容認されたINVITE要求F1に+ xmlを含んでいて、アプリケーション/リソースリスト+xmlボディーはアプリケーション/リソースリストと等しくはありません、会議サーバが'anonymizeする'属性でタグ付けをされたそれらのURIをanonymizedして、"bcc"'copyControl'属性でタグ付けをされたそれらのURIを取り除いたので。 図4はメッセージF3に関する例を示しています。

Camarillo & Johnston        Standards Track                     [Page 8]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[8ページ]。

   INVITE sip:bill@example.com SIP/2.0
   Via: SIP/2.0/TCP conference.example.com
       ;branch=z9hG4bKhjhs8as454
   Max-Forwards: 70
   To: <sip:bill@example.com>
   From: Conference Server <sip:conf34@example.com>;tag=234332
   Call-ID: 389sn189dasdf
   CSeq: 1 INVITE
   Contact: <sip:conf34@conference.example.com>;isfocus
   Allow: INVITE, ACK, CANCEL, BYE, REFER
   Allow-Events: dialog, conference
   Accept: application/sdp, message/sipfrag
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 690

INVITE一口: bill@example.com SIP/2.0Via: SIP/2.0/TCP conference.example.com; ブランチは前方へz9hG4bKhjhs8as454マックスと等しいです: 70 To: <一口: bill@example.com 、gt;、From: コンファレンスサーバ<一口: conf34@example.com 、gt;、; タグは234332呼び出しIDと等しいです: 389sn189dasdf CSeq: 1 接触を招いてください: <一口: conf34@conference.example.com 、gt;、;isfocusが以下を許容する さようなら、招待、ACK、取り消してください、そして、イベントを許容して参照してください: 対話、会議Accept: アプリケーション/sdp、メッセージ/sipfragコンテントタイプ: 複合か混ぜられる;、境界=、「boundary1" Content-長さ:」 690

   --boundary1
   Content-Type: application/sdp

--boundary1コンテントタイプ: アプリケーション/sdp

   v=0
   o=conf 2890844343 2890844343 IN IP4 conference.example.com
   s=-
   c=IN IP4 192.0.2.5
   t=0 0
   m=audio 40000 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 40002 RTP/AVP 31
   a=rtpmap:31 H261/90000

v=0 o=conf2890844343 2890844343IN IP4 conference.example.com s=c=IN IP4 192.0.2.5tは0 0m=オーディオの40000RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ40002RTP/AVP31a=rtpmap: 31H261/90000と等しいです。

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: recipient-list-history; handling=optional

--boundary1コンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リスト歴史。 取り扱い=任意です。

   <?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">
     <list>
       <entry uri="sip:bill@example.com" cp:copyControl="to" />
       <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
                                                    cp:count="2"/>
       <entry uri="sip:joe@example.org" cp:copyControl="cc" />
       <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
                                                    cp:count="1"/>
     </list>
   </resource-lists>
   --boundary1--

<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsは「つぼ:ietf:params:xml:ナノ秒: リソースリスト」xmlnsと等しいです: cpは「つぼ:ietf:params: xml:ナノ秒:copycontrol「><リスト><エントリーuri=」一口: bill@example.com 」cpと等しいです: copyControl="to"/><エントリーuriは「一口: anonymous@anonymous.invalid 」cpと等しいです:; 「cc」/><「copyControl="to" cp: カウント=「2インチ/><エントリーuri=」一口: joe@example.org 」cp: copyControl=エントリーuriは「一口: anonymous@anonymous.invalid 」cpと等しいです: copyControlは「cc」cpと等しいです: 数えてください。= 「1インチ/>の</リスト></は>--boundary1をリソースで記載します」。

          Figure 4: INVITE request sent by the conference server

図4: 会議サーバによって送られたINVITE要求

Camarillo & Johnston        Standards Track                     [Page 9]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[9ページ]。

7.  Security Considerations

7. セキュリティ問題

   This document discusses setup of SIP conferences using a request-
   contained URI list.  Both conferencing and URI-list services have
   specific security requirements, which are summarized here.
   Conferences generally have authorization rules about who can or
   cannot join a conference, what type of media can or cannot be used,
   etc.  This information is used by the focus to admit or deny
   participation in a conference.  It is RECOMMENDED that these types of
   authorization rules be used to provide security for a SIP conference.

このドキュメントは、要求の含まれたURIリストを使用することでSIP会議のセットアップについて議論します。 会議とURIリストサービスの両方には、特定のセキュリティ要件があります。(要件はここへまとめられます)。 一般に、コンファレンスには、だれは接合できるか、会議、メディアのタイプが接合できることを接合できない、または使用できないかに関する承認規則などがあります。 会議への参加をこの情報は焦点によって使用されて、認めるか、または否定します。 これらのタイプの承認規則がSIP会議にセキュリティを提供するのに使用されるのは、RECOMMENDEDです。

   For this authorization information to be used, the focus needs to be
   able to authenticate potential participants.  Normal SIP mechanisms,
   including Digest authentication and certificates, can be used.  These
   conference-specific security requirements are discussed further in
   the requirements and framework documents -- [RFC4245] and [RFC4353].

この承認情報が使用されるために、焦点は、潜在的関係者を認証できる必要があります。 Digest認証と証明書を含む正常なSIPメカニズムは使用できます。 要件とフレームワークドキュメントで、より詳しくこれらの会議特有のセキュリティ要件について議論します--[RFC4245]と[RFC4353。]

   For conference creation using a list, there are some additional
   security considerations.  "Framework and Security Considerations for
   Session Initiation Protocol (SIP) URI-List Services" [RFC5363]
   discusses issues related to SIP URI-list services.  Given that a
   conference server sending INVITE requests to a set of users acts as a
   URI-list service, implementations of conference servers that handle
   lists MUST follow the security-related rules in [RFC5363].  These
   rules include opt-in lists and mandatory authentication and
   authorization of clients.

リストを使用する会議作成のために、いくつかの追加担保問題があります。 「Session Initiationプロトコル(SIP)URIリストServicesのためのフレームワークとSecurity Considerations」[RFC5363]はSIP URI-リストサービスに関連する問題について議論します。 1セットのユーザへの要求をINVITEに送る会議サーバがURIリストサービスとして機能するなら、リストを扱う会議サーバの実装は[RFC5363]のセキュリティ関連の規則に従わなければなりません。 これらの規則はクライアントのオプトインリスト、義務的な認証、および承認を含んでいます。

8.  IANA Considerations

8. IANA問題

   This document defines the 'recipient-list-invite' SIP option-tag.  It
   has been registered in the Option Tags subregistry under the SIP
   parameter registry.  The following is the description used in the
   registration:

このドキュメントは'リストが招待する受取人'SIPオプションタグを定義します。 SIPパラメタ登録の下のOption Tags subregistryにそれを登録してあります。 ↓これは登録に使用される記述です:

   +------------------------+------------------------------+-----------+
   | Name                   | Description                  | Reference |
   +------------------------+------------------------------+-----------+
   | recipient-list-invite  | The body contains a list of  | [RFC5366] |
   |                        | URIs that indicates the      |           |
   |                        | recipients of the SIP INVITE |           |
   |                        | request                      |           |
   +------------------------+------------------------------+-----------+

+------------------------+------------------------------+-----------+ | 名前| 記述| 参照| +------------------------+------------------------------+-----------+ | リストが招待する受取人| ボディーはリストを含みます。| [RFC5366]| | | それが示すURI| | | | SIP INVITEの受取人| | | | 要求| | +------------------------+------------------------------+-----------+

     Table 1: Registration of the 'recipient-list-invite' option-tag
                                  in SIP

テーブル1: SIPでの'リストが招待する受取人'オプションタグの登録

Camarillo & Johnston        Standards Track                    [Page 10]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[10ページ]。

9.  Acknowledgments

9. 承認

   Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, and Keith
   Drage provided useful comments on this document.  Miguel Garcia-
   Martin assembled the dependencies to the 'copyControl' attribute
   extension.

カレンのジョニングス、Hisham Khartabil、ジョナサン・ローゼンバーグ、およびキースDrageはこのドキュメントの役に立つコメントを提供しました。 ミゲル・ガルシアマーチンは'copyControl'属性拡大への依存を組み立てました。

10.  References

10. 参照

10.1.  Normative References

10.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, Ed., "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183, August 1997.

[RFC2183] TroostとR.とデルナー、S.とK.ムーア、エド、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年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月。

   [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月。

   [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月。

Camarillo & Johnston        Standards Track                    [Page 11]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[11ページ]。

10.2.  Informative References

10.2. 有益な参照

   [RFC4245]  Levin, O. and R. Even, "High-Level Requirements for
              Tightly Coupled SIP Conferencing", RFC 4245, November
              2005.

[RFC4245]レヴィン、O.、およびR.、同等である、「密結合一口会議のためのハイレベルの要件」、RFC4245、11月2005日

   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353, February
              2006.

[RFC4353] 2006年2月のローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のための枠組み」RFC4353。

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
              Session Initiation Protocol (SIP) Event Package for
              Conference State", RFC 4575, August 2006.

[RFC4575] ローゼンバーグ、J.、Schulzrinne、H.、およびO.レヴィン(エド)、「セッション開始は(一口)イベントパッケージについてコンファレンス状態に議定書の中で述べます」、RFC4575、2006年8月。

Authors' Addresses

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

   Alan Johnston
   Avaya
   St. Louis, MO  63124
   USA

アラン・ジョンストン・Avaya MO63124セントルイス(米国)

   EMail: alan@sipstation.com

メール: alan@sipstation.com

Camarillo & Johnston        Standards Track                    [Page 12]

RFC 5366                 INVITE-Contained Lists             October 2008

キャマリロとジョンストンStandardsは招待で含まれたリスト2008年10月にRFC5366を追跡します[12ページ]。

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 & Johnston        Standards Track                    [Page 13]

キャマリロとジョンストン標準化過程[13ページ]