RFC5367 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 5367                                      Ericsson
Updates: 3265                                                 A.B. Roach
Category: Standards Track                                        Tekelec
                                                                O. Levin
                                                   Microsoft Corporation
                                                            October 2008

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 5367のエリクソンアップデート: 3265年のA.B.ローチカテゴリ: 標準化過程Tekelec O.レヴィンマイクロソフト社2008年10月

           Subscriptions to Request-Contained Resource 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 specifies a way to create subscription to a list of
   resources in SIP.  This is achieved by including the list of
   resources in the body of a SUBSCRIBE request.  Instead of having a
   subscriber send a SUBSCRIBE request for each resource individually,
   the subscriber defines the resource list, subscribes to it, and gets
   notifications about changes in the resources' states using a single
   SUBSCRIBE dialog.

このドキュメントはSIPのリソースのリストの購読を作成する方法を指定します。 これは登録のボディーのリソースのリストが要求する包含で達成されます。 加入者に登録を送らせることの代わりに加入者が個別に、リソースリストを定義して、それに加入して、変化に関する通知を得るシングルを使用するリソースのものが述べる各リソースのために登録よう要求してください。対話。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. User Agent Client Procedures ....................................2
      3.1. Response Handling ..........................................2
      3.2. Subsequent SUBSCRIBE Requests ..............................3
   4. URI-List Document Format ........................................3
   5. Resource List Server Behavior ...................................4
      5.1. Subsequent SUBSCRIBE Requests ..............................4
   6. Providing a URI to Manipulate a Resource List ...................4
   7. Example .........................................................5
   8. Security Considerations .........................................6
   9. IANA Considerations .............................................6
      9.1. List-Management Purpose Parameter Value ....................6
      9.2. recipient-list-subscribe Option-Tag ........................7
   10. Acknowledgments ................................................7
   11. Normative References ...........................................7

1. 序論…2 2. 用語…2 3. ユーザエージェントクライアント手順…2 3.1. 応答取り扱い…2 3.2. その後、要求を申し込んでください…3 4. URIリストドキュメント・フォーマット…3 5. リソースリストサーバの振舞い…4 5.1. その後、要求を申し込んでください…4 6. リソースを操るためにURIを提供して、記載してください…4 7. 例…5 8. セキュリティ問題…6 9. IANA問題…6 9.1. リスト管理目的パラメタ価値…6 受取人リストが申し込まれた9.2Option-タグ…7 10. 承認…7 11. 標準の参照…7

Camarillo                   Standards Track                     [Page 1]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[1ページ]登録、-含まれた、リスト2008年10月

1.  Introduction

1. 序論

   [RFC4662] specifies how to establish subscriptions to a homogeneous
   resource list in SIP (which is specified in [RFC3261]) and defines
   the procedures for getting notifications about changes in the state
   of the associated resources.  Yet, list creation is outside the scope
   of [RFC4662].

[RFC4662]は、SIP([RFC3261]で指定される)の均質のリソースリストの購読を確立する方法を指定して、関連リソースの状態の変化に関する通知を得るための手順を定義します。 しかし、[RFC4662]の範囲の外にリスト作成があります。

   This document specifies a way to create a list with a set of
   resources and subscribe to it using a single SIP request.  This is
   achieved by including the list of resources (as defined in [RFC5363])
   in the body of the SUBSCRIBE request.

このドキュメントは1セットのリソースでリストを作成して、ただ一つのSIP要求を使用することでそれに加入する方法を指定します。 これがボディーにリソース([RFC5363]で定義されるように)のリストを含んでいることによって達成される、登録、要求。

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

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

3.  User Agent Client Procedures

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

   A UAC (User Agent Client) that wants to create a resource list and
   subscribe to it using the mechanism described in this document
   constructs a SUBSCRIBE request with at least one body, whose
   disposition is type "recipient-list" as defined in [RFC5363], that
   contains the URI list.  Additionally, the UAC MUST include the
   'recipient-list-subscribe' option-tag (which is registered with the
   IANA in Section 9) in a Require header field.  The UAC MUST build the
   rest of the SUBSCRIBE request following the rules in [RFC3265].

組み立てるこれで説明されたメカニズムを使用することでリソースリストを作成して、それに加入したがっている(ユーザエージェントClient)が登録をドキュメントであるUACは、気質がタイプ「受取人リスト」である少なくとも1つのボディーでそれが[RFC5363]で定義されるようにURIリストを含むよう要求します。 さらに、UAC MUSTはRequireヘッダーフィールドに受取人リストが申し込まれた''オプションタグ(セクション9にIANAに登録される)を含んでいます。 UAC MUSTが残りを築き上げる、登録、[RFC3265]で約束を守りながら、要求します。

   The UAC MUST support the "rlmi+xml" format defined in [RFC4662] and
   signal this by including "rlmi+xml" in the Accept header.  The UAC
   MAY support additional formats and include them in the Accept header
   field of the SUBSCRIBE request.

UAC MUSTは、「rlmi+xml」が[RFC4662]で定義された書式であるとサポートして、Acceptヘッダーに「rlmi+xml」を含んでいることによって、これに合図します。 UAC MAYが追加形式をサポートして、Acceptヘッダーフィールドにおけるそれらを含んでいる、登録、要求。

3.1.  Response Handling

3.1. 応答取り扱い

   The status code in the response to the SUBSCRIBE request does not
   provide any information about whether or not the resource list server
   was able to successfully subscribe to the URIs in the URI list.  The
   UAC obtains this information in the notifications sent by the server.

登録、要求はそうしません。応答におけるステータスコード、リソースリストサーバが首尾よくURIに加入できたかどうかのあらゆる情報をURIリストに提供してください。 UACはサーバによって送られた通知におけるこの情報を得ます。

Camarillo                   Standards Track                     [Page 2]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[2ページ]登録、-含まれた、リスト2008年10月

3.2.  Subsequent SUBSCRIBE Requests

3.2. その後、要求を申し込んでください。

   The previous sections have specified how to include a URI list in an
   initial SUBSCRIBE request to a resource list server in order to
   subscribe to the state of a set of resources.  Once the subscription
   has been created and a dialog between the UAC and the resource list
   server has been established, the UAC can send subsequent SUBSCRIBE
   requests to, for example, extend the duration of the subscription.

登録に頭文字をつけてください。前項がURIリストを含むようにその方法を指定した、1セットのリソースの状態に加入するためにリソースリストにサーバを要求してください。 いったん購読を作成してあって、UACとリソースリストサーバの間の対話が確立されると、UACが発信できる、その後、登録、例えば購読の持続時間を広げるという要求。

   At this point, there are no semantics associated with resource-list
   bodies in subsequent SUBSCRIBE requests (although future extensions
   can define them).  Therefore, UACs SHOULD NOT include resource-list
   bodies in subsequent SUBSCRIBE requests to a resource list server.

ここに、関連している中のその後であるリソースリスト本体でどんな意味論もない、登録、要求(今後の拡大はそれらを定義できますが)。 したがって、UACs SHOULDがその後にリソースリスト本体を含んでいない、登録、リソースリストサーバへの要求。

      Note that a difference between an initial SUBSCRIBE request and
      subsequent ones is that while the initial request is sent to the
      public URI of the resource list, subsequent ones are sent to the
      URI provided by the server when the dialog is 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.

登録に頭文字をつけてください。間にそのa差に注意してください、要求とその後のものはリソースリストの公共のURIに初期の要求を送りますが、対話が確立されるサーバによって提供されたURIにその後のものを送るということです。 したがって、UACの観点から、前のURIによって特定されたリソースは受取人リスト本体を支えます、後者によって特定されたリソースがそれらをサポートしませんが。

4.  URI-List Document Format

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

   [RFC5363] mandates that each URI-list services specification, such as
   the subscription service defined here, specifies the default format
   for the recipient-list bodies used within the particular service.

[RFC5363]は、ここで定義された購読サービスなどのそれぞれのURIリストサービス仕様が特定のサービスの中で使用された受取人リスト本体に省略時書式を指定するのを強制します。

   The default format for the recipient-list bodies for the subscription
   service defined in this document is the resource list format defined
   in [RFC4826].  UAs (User Agents) generating recipient-list bodies
   MUST support this format and MAY support other formats.  Resource
   list servers able to handle recipient-list bodies MUST support this
   format and MAY support other formats.

本書では定義された購読サービスのための受取人リスト本体のための省略時書式は[RFC4826]で定義されたリソースリスト形態です。 受取人リスト本体を生成するUAs(ユーザエージェント)はこの形式をサポートしなければならなくて、他の形式をサポートするかもしれません。 受取人リスト本体を扱うことができるリソースリストサーバは、この形式をサポートしなければならなくて、他の形式をサポートするかもしれません。

   The Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP) resource list document provides features, such as hierarchical
   lists and the ability to include entries by reference relative to the
   XCAP root URI, that are not needed by the subscription service
   defined here, which only needs to transfer a flat list of URIs
   between a UA and the resource list server.  Therefore, when using the
   default resource list document, UAs SHOULD use flat lists (i.e., no
   hierarchical lists) and SHOULD NOT use <entry-ref> elements.  A
   resource list server receiving a URI list with more information than
   what has just been described MAY discard all the extra information.

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

Camarillo                   Standards Track                     [Page 3]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[3ページ]登録、-含まれた、リスト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:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:bill@example.com" />
       <entry uri="sip:joe@example.org" />
       <entry uri="sip:ted@example.net" />
     </list>
   </resource-lists>

<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlns=「つぼ:ietf:params:xml:ナノ秒: リソースリスト」はxmlnsされます: xsiが「 http://www.w3.org/2001/XMLSchema-instance 「><リスト><エントリーuri=」一口: bill@example.com 」/と等しい、gt;、<エントリーuri=「一口: joe@example.org 」/><エントリーuriな=「一口: ted@example.net 」/></リスト></リソースリスト>。

                            Figure 1: URI list

図1: URIリスト

5.  Resource List Server Behavior

5. リソースリストサーバの振舞い

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

受信して、処理できるリソースリストサーバ、登録、受取人リストボディーSHOULDインクルードa'受取人リストで、-OPTIONS要求に応じるときにはSupportedヘッダーフィールドで'オプションタグを申し込むよう要求します。

   On reception of a SUBSCRIBE request with a URI list, a resource list
   server that chooses to accept the "rlmi+xml" format MUST comply with
   [RFC4662] for creating the subscription and reporting the changes in
   the resources within the created dialog.

登録のレセプションでは、URIリスト、リソースリストサーバでそれが、作成された対話の中で購読を作成して、リソースにおける変化を報告するために、形式が従わなければならない「rlmi+xml」[RFC4662]を受け入れるのを選ぶよう要求してください。

5.1.  Subsequent SUBSCRIBE Requests

5.1. その後、要求を申し込んでください。

   At this point, there are no semantics associated with resource-list
   bodies in subsequent SUBSCRIBE requests (although future extensions
   may define them).  Therefore, a resource list server receiving a
   subsequent SUBSCRIBE request with a resource-list body, following
   standard SIP procedures, rejects it with a 415 (Unsupported Media
   Type) response.

ここに、関連している中のその後であるリソースリスト本体でどんな意味論もない、登録、要求(今後の拡大はそれらを定義するかもしれませんが)。 したがって、aリソースリストサーバ受信aその後、登録、リソースリスト本体がある要求(次の標準のSIP手順)は415(サポートされないメディアType)応答でそれを拒絶します。

6.  Providing a URI to Manipulate a Resource List

6. リソースリストを操るためにURIを提供します。

   A UAC can manipulate a resource list at a resource list server.  The
   resource list server MAY provide a URI to manipulate the resource
   list associated with a subscription using the Call-Info header field
   in the NOTIFY request that establishes the subscription.  The
   "purpose" parameter of the Call-Info header field MUST have a value
   of 'list-management', which we register with the IANA in Section 9.
   The following is an example of such a header field.

UACはリソースリストサーバでリソースリストを操ることができます。リソースリストサーバは、購読を確立するNOTIFY要求でCall-インフォメーションヘッダーフィールドを使用する購読に関連しているリソースリストを操るためにURIを提供するかもしれません。 Call-インフォメーションヘッダーフィールドの「目的」パラメタには、私たちがセクション9にIANAに登録する'リスト管理'の値がなければなりません。 ↓これはそのようなヘッダーフィールドに関する例です。

   Call-Info: <http://xcap.example.com/your-list.xml>
              ;purpose=list-management

呼び出しインフォメーション: -list.xml>; =リスト管理を目標としてください。

Camarillo                   Standards Track                     [Page 4]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[4ページ]登録、-含まれた、リスト2008年10月

   The lifetime of a resource list to be manipulated by the URI provided
   by the server is bundled to the lifetime of the subscription.  That
   is, the resource list SHOULD be destroyed when the subscription
   expires or is otherwise terminated.

サーバによって提供されたURIによって操られるべきリソースリストの寿命は購読の生涯まで添付されます。 すなわち、リソースリストSHOULDは購読が期限が切れるとき、破壊されるか、または別の方法で終えられます。

   Section 7.1 of [RFC3265] does not list the Call-Info header field in
   the table of header fields that NOTIFY requests can carry.  This
   document updates that table so that the Call-Info header field can be
   optionally included in NOTIFY requests.

[RFC3265]のセクション7.1はNOTIFY要求が運ぶことができるヘッダーフィールドのテーブルにCall-インフォメーションヘッダーフィールドを記載しません。 このドキュメントは、NOTIFY要求に任意にCall-インフォメーションヘッダーフィールドを含むことができるようにそのテーブルをアップデートします。

7.  Example

7. 例

   The following is an example of a SUBSCRIBE request, which carries a
   URI list in its body, sent by a UAC to a resource list server.

↓これはリソースリストサーバへの登録に関する要求(ボディーでURIリストを運ぶ)がUACで送った例です。

   SUBSCRIBE  sip:rls@example.com SIP/2.0
   Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
   Max-Forwards: 70
   To: RLS <sip:rls@example.com>
   From: <sip:adam@example.com>;tag=ie4hbb8t
   Call-ID: cdB34qLToC@terminal.example.com
   CSeq: 1 SUBSCRIBE
   Contact: <sip:terminal.example.com>
   Event: presence
   Expires: 7200
   Require: recipient-list-subscribe
   Supported: eventlist
   Accept: application/cpim-pidf+xml
   Accept: application/rlmi+xml
   Accept: multipart/related
   Accept: multipart/signed
   Accept: multipart/encrypted
   Content-Type: application/resource-lists+xml
   Content-Disposition: recipient-list
   Content-Length: 337

一口: 登録、 rls@example.com SIP/2.0Via: 一口/2.0/TCP terminal.example.com; ブランチは前方へz9hG4bKwYb6QREiCLマックスと等しいです: 70 To: RLS<一口: rls@example.com 、gt;、From: <一口: adam@example.com 、gt;、; =ie4hbb8t呼び出しIDにタグ付けをしてください: cdB34qLToC@terminal.example.com CSeq: 1 接触を申し込んでください: <一口: terminal.example.com>イベント: 存在Expires: 7200 必要です: 受取人リストが申し込まれたSupported: eventlist Accept: アプリケーション/cpim-pidf+xml Accept: アプリケーション/rlmi+xml Accept: 複合の、または、関連するAccept: 複合の、または、署名しているAccept: 複合の、または、暗号化されたコンテントタイプ: アプリケーション/リソースリスト+xml Content気質: 受取人リストのContent-長さ: 337

   <?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" />
       <entry uri="sip:joe@example.org" />
       <entry uri="sip:ted@example.net" />
     </list>
   </resource-lists>

<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlns=「つぼ:ietf:params:xml:ナノ秒: リソースリスト」はxmlnsされます: xsiが「 http://www.w3.org/2001/XMLSchema-instance 「><リスト><エントリーuri=」一口: bill@example.com 」/と等しい、gt;、<エントリーuri=「一口: joe@example.org 」/><エントリーuriな=「一口: ted@example.net 」/></リスト></リソースリスト>。

                        Figure 2: SUBSCRIBE request

図2: 登録、要求

Camarillo                   Standards Track                     [Page 5]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[5ページ]登録、-含まれた、リスト2008年10月

8.  Security Considerations

8. セキュリティ問題

   The Security Considerations section of [RFC4662] discusses security
   issues related to resource list servers.  Resource list servers
   accepting request-contained URI lists MUST also follow the security
   guidelines given in [RFC4662].

[RFC4662]のSecurity Considerations部はリソースリストサーバに関連する安全保障問題について論じます。 また、要求で含まれたURIリストを受け入れるリソースリストサーバは[RFC4662]で与えられた安全ガイドラインに従わなければなりません。

   "Framework and Security Considerations for Session Initiation
   Protocol (SIP) URI-List Services" [RFC5363] discusses issues related
   to SIP URI-list services.  Given that a resource list server sending
   SUBSCRIBE requests to a set of users acts as a URI-list service,
   implementations of resource list servers that handle request-
   contained URI 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-リストサービスに関連する問題について議論します。 登録、URIリストサービスとしてのユーザ条例一式への要求、要求の含まれたURIリストを扱うリソースリストサーバの実装はそうしなければなりません。リソースがサーバ発信を記載する、[RFC5363]のセキュリティ関連の規則に従ってください。 これらの規則はクライアントのオプトインリスト、義務的な認証、および承認を含んでいます。

9.  IANA Considerations

9. IANA問題

   The following sections describe the IANA registration of the 'list-
   management' value for the "purpose" parameter of the Call-Info header
   field and the 'recipient-list-subscribe' SIP option-tag.

以下のセクションはCall-インフォメーションヘッダーフィールドと'受取人リストは申し込み'SIPオプションタグの「目的」パラメタのために'リスト管理'価値のIANA登録について説明します。

9.1.  List-Management Purpose Parameter Value

9.1. リスト管理目的パラメタ価値

   This document defines the 'list-management' value for the "purpose"
   parameter of the Call-Info header field.  A reference to this RFC (in
   double brackets) has been added to the existing "purpose" Call-Info
   parameter entry in the SIP Parameters registry, which currently looks
   as follows:

このドキュメントはCall-インフォメーションヘッダーフィールドの「目的」パラメタのために'リスト管理'値を定義します。 このRFC(二重括弧の)の参照は現在以下の通りに見えるSIP Parameters登録の既存の「目的」Call-インフォメーションパラメタエントリーに加えられます:

                                                  Predefined
   Header Field                  Parameter Name     Values     Reference
   ----------------------------  ---------------   ---------   ---------
   Call-Info                     purpose             Yes       [RFC3261]

事前に定義されたヘッダーフィールドパラメタ名は参照を評価します。---------------------------- --------------- --------- --------- 呼び出しインフォメーションは、はいを目標とします。[RFC3261]

Camarillo                   Standards Track                     [Page 6]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[6ページ]登録、-含まれた、リスト2008年10月

9.2.  recipient-list-subscribe Option-Tag

9.2. 受取人リストが申し込まれたOption-タグ

   This document defines the SIP option tag "recipient-list-subscribe".

このドキュメントはSIPオプションタグ「リストが申し込む受取人」を定義します。

   The following row has been added to the "Option Tags" section of the
   SIP Parameter Registry:

SIP Parameter Registryの「オプションタグ」セクションに以下の行を追加してあります:

   +--------------------------+----------------------------+-----------+
   | Name                     | Description                | Reference |
   +--------------------------+----------------------------+-----------+
   | recipient-list-subscribe | This option tag is used to | [RFC5367] |
   |                          | ensure that a server can   |           |
   |                          | process the recipient-list |           |
   |                          | body used in a SUBSCRIBE   |           |
   |                          | request.                   |           |
   +-------------------------------------------------------+-----------+

+--------------------------+----------------------------+-----------+ | 名前| 記述| 参照| +--------------------------+----------------------------+-----------+ | 受取人リストは申し込まれます。| タグが使用されているこのオプション| [RFC5367]| | | サーバがそうすることができるのを確実にしてください。| | | | 受取人リストを処理してください。| | | | 登録で使用されるボディー| | | | 要求します。 | | +-------------------------------------------------------+-----------+

10.  Acknowledgments

10. 承認

   Cullen Jennings and Jonathan Rosenberg provided useful comments on
   this document.

カレンのジョニングスとジョナサン・ローゼンバーグはこのドキュメントの役に立つコメントを提供しました。

11.  Normative References

11. 引用規格

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

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

   [RFC3265]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

[RFC3265]ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。

   [RFC4662]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
              Initiation Protocol (SIP) Event Notification Extension for
              Resource Lists", RFC 4662, August 2006.

[RFC4662]ローチ、A.B.、キャンベル、B.、およびJ.ローゼンバーグ、「リソースのためのセッション開始プロトコル(一口)イベント通知拡張子は記載します」、RFC4662、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月。

Camarillo                   Standards Track                     [Page 7]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[7ページ]登録、-含まれた、リスト2008年10月

Authors' Addresses

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

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

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

   Adam Roach
   Tekelec
   17210 Campbell Rd Ste 250
   Dallas, TX  75252
   USA

アダムローチTekelec17210キャンベル第Ste250テキサス75252ダラス(米国)

   EMail: Adam.Roach@tekelec.com

メール: Adam.Roach@tekelec.com

   Orit Levin
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052

Oritレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052

   EMail: oritl@microsoft.com

メール: oritl@microsoft.com

Camarillo                   Standards Track                     [Page 8]

RFC 5367               SUBSCRIBE-Contained Lists            October 2008

キャマリロ規格がRFC5367を追跡する、[8ページ]登録、-含まれた、リスト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                   Standards Track                     [Page 9]

キャマリロ標準化過程[9ページ]