[要約] RFC 5367は、SIPにおける要求に含まれるリソースリストの購読に関する規格です。その目的は、SIPセッション中にリソースの変更を監視するための効果的なメカニズムを提供することです。
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
Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のリクエストコンテン付きリソースリストへのサブスクリプション
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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
[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.
このドキュメントは、一連のリソースを使用してリストを作成し、単一のSIPリクエストを使用してそれを購読する方法を指定します。これは、購読要求の本文にリソースのリスト（[RFC5363]で定義されている）を含めることによって達成されます。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
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].
このドキュメントで説明されているメカニズムを使用してリソースリストを作成し、それを購読したいUAC（ユーザーエージェントクライアント）は、[RFC5363]で定義されているように、少なくとも1つのボディでサブスクライブリクエストを構築します。、それにはURIリストが含まれています。さらに、UACには、「受信者リストサブスクライブ」オプションタグ（セクション9のIANAに登録されている）を必要なヘッダーフィールドに含める必要があります。UACは、[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は、[RFC4662]で定義されている「RLMI XML」形式をサポートし、Acceptヘッダーに「RLMI XML」を含めることでこれを合図する必要があります。UACは、追加の形式をサポートし、サブスクライブリクエストのAcceptヘッダーフィールドにそれらを含めることができます。
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.
サブスクライブリクエストへの応答のステータスコードは、Resource List ServerがURIリストのURIを正常にサブスクライブできるかどうかについての情報を提供しません。UACは、サーバーから送信された通知でこの情報を取得します。
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リストを含める方法を指定しました。サブスクリプションが作成され、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.
この時点で、その後のサブスクライブリクエストには、リソースリストボディに関連するセマンティクスはありません（ただし、将来の拡張機能はそれらを定義できます）。したがって、UACは、リソースリストサーバーへの後続のサブスクライブリクエストにリソースリストボディを含めるべきではありません。
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.
初期サブスクライブリクエストと後続の要求の違いは、最初のリクエストがリソースリストの公開URIに送信される間、ダイアログが確立されたときにサーバーが提供するURIに後続のリクエストが送信されることに注意してください。したがって、UACの観点からは、前の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）構成アクセスプロトコル（XCAP）リソースリストドキュメントは、階層リストやXCAPルートURIに関連する参照によってエントリを含める機能を提供します。UAとリソースリストサーバーの間にURIのフラットリストを転送する必要があります。したがって、デフォルトのリソースリストドキュメントを使用する場合、UASはフラットリスト（つまり、階層リストなし）を使用する必要があり、<Entre-Ref>要素を使用しないでください。RESOATEリストサーバーは、説明されていることよりも多くの情報を含むURIリストを受信している場合、すべての追加情報を破棄する場合があります。
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>
Figure 1: URI list
図1：URIリスト
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.
受信者リストボディを使用してリクエストを受信および処理できるリソースリストサーバーには、オプションリクエストに応答するときに、サポートされているヘッダーフィールドに「受信者リストサブスクライブ」オプションタグを含める必要があります。
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]に準拠する必要があります。
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.
この時点で、その後のサブスクライブリクエストには、リソースリストボディに関連するセマンティクスはありません（ただし、将来の拡張はそれらを定義する場合があります）。したがって、リソースリストサーバーは、標準のSIP手順に従って、リソースリストボディを使用して後続のサブスクライブリクエストを受信し、415（サポートされていないメディアタイプ）応答で拒否します。
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リクエストでコールINFOヘッダーフィールドを使用して、サブスクリプションに関連付けられたリソースリストを操作するためのURIを提供する場合があります。Call-INFOヘッダーフィールドの「目的」パラメーターには、「リスト管理」の値が必要です。これは、セクション9でIANAに登録しています。以下は、このようなヘッダーフィールドの例です。
Call-Info: <http://xcap.example.com/your-list.xml>
;purpose=list-management
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によって操作されるリソースリストの寿命は、サブスクリプションの寿命にバンドルされます。つまり、サブスクリプションの有効期限が切れるか、それ以外の場合は終了したときにリソースリストを破壊する必要があります。
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は、要求を通知できるヘッダーフィールドのテーブルに、コールINFOヘッダーフィールドをリストしていません。このドキュメントは、そのテーブルを更新して、通話INFOヘッダーフィールドをオプションで通知リクエストに含めることができます。
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.
以下は、UACからリソースリストサーバーに送信される本文内にURIリストを掲載しているサブスクライブリクエストの例です。
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
<?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>
Figure 2: SUBSCRIBE request
図2：サブスクライブリクエスト
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]のセキュリティに関する考慮事項セクションでは、リソースリストサーバーに関連するセキュリティ問題について説明します。リクエストで構成された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.
「セッション開始プロトコル（SIP）URI-Listサービスのフレームワークとセキュリティ上の考慮事項」[RFC5363]は、SIP URIリストサービスに関連する問題について説明しています。リソースリストサーバーのサブスクライブリクエストを一連のユーザーに送信すると、URIリストサービスとして機能することを考えると、リクエストで入ったURIリストを処理するリソースリストサーバーの実装は、[RFC5363]のセキュリティ関連のルールに従う必要があります。これらのルールには、オプトインリストとクライアントの必須認証と承認が含まれます。
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-INFOヘッダーフィールドの「目的」パラメーターの「リスト管理」値のIANA登録と、「Reciontient-List-Subscribe」SIPオプションタグについて説明します。
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-INFOヘッダーフィールドの「目的」パラメーターの「リスト管理」値を定義します。このRFCへの参照（ダブルブラケット）は、SIPパラメーターレジストリの既存の「目的」コールINFOパラメーターエントリに追加されました。現在、次のように見えます。
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Call-Info purpose Yes [RFC3261]
This document defines the SIP option tag "recipient-list-subscribe".
このドキュメントでは、SIPオプションタグ「Reciontient-List-Subscribe」を定義します。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
次の行は、SIPパラメーターレジストリの「オプションタグ」セクションに追加されました。
+--------------------------+----------------------------+-----------+
| 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. | |
+-------------------------------------------------------+-----------+
Cullen Jennings and Jonathan Rosenberg provided useful comments on this document.
Cullen JenningsとJonathan Rosenbergは、この文書に有用なコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A.B。、「セッション開始プロトコル（SIP）固有イベント通知」、RFC 3265、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] Roach、A.B.、Campbell、B。、およびJ. Rosenberg、「セッション開始プロトコル（SIP）イベント通知リソースリストの拡張機能」、RFC 4662、2006年8月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826] Rosenberg、J。、「リソースリストを表すための拡張マークアップ言語（XML）形式」、RFC 4826、2007年5月。
[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.Roach、「セッション開始プロトコル（SIP）URI-List Servicesのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Adam Roach Tekelec 17210 Campbell Rd Ste 250 Dallas, TX 75252 USA
Adam Roach Tekelec 17210 Campbell Rd Ste 250ダラス、テキサス75252 USA
EMail: Adam.Roach@tekelec.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
Orit Levin Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: oritl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。