[要約] RFC 6050は、サービスの識別のためのSession Initiation Protocol（SIP）の拡張に関するものです。このRFCの目的は、SIPメッセージ内のサービスの識別情報を提供することです。
Internet Engineering Task Force (IETF) K. Drage
Request for Comments: 6050 Alcatel-Lucent
Category: Informational November 2010
ISSN: 2070-1721
A Session Initiation Protocol (SIP) Extension for the Identification of Services
サービスの識別のためのセッション開始プロトコル（SIP）拡張機能
Abstract
概要
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
このドキュメントでは、信頼できるSIPサーバーのネットワークが認証されたユーザーのサービスを主張できるようにするセッション開始プロトコル（SIP）へのプライベート拡張機能について説明します。これらの拡張機能の使用は、そのような情報の生成、輸送、および使用に関する以前に合意されたポリシーで、管理ドメイン内でのみ適用されます。このドキュメントでは、異なる信頼ドメイン間で使用したり、インターネット全体で使用したりするのに適した一般的なサービス識別モデルを提供していません。
The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs.
ドキュメントは、サービスとユーザーエージェント（UA）アプリケーションの両方を識別するURNも定義しています。このURNは、このドキュメントで定義されたSIPヘッダーフィールド内で、サービスを識別するために、また、エンドUA間のサービスとアプリケーションの両方の使用法とアプリケーションの両方の使用を特定するために、発信者の設定とCallee機能のために定義されたフレームワーク内でも使用できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6050.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6050で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Syntax of the Header Fields . . . . . . . . . . . . . . . . . 6
4.1. The P-Asserted-Service Header . . . . . . . . . . . . . . 6
4.2. The P-Preferred-Service Header . . . . . . . . . . . . . . 7
4.3. Service and Application Definition . . . . . . . . . . . . 8
4.4. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Usage of the P-Preferred-Service and P-Asserted-Service
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Requests . . . . . . . 10
5.1.1. Procedures at User Agent Clients (UAC) . . . . . . . . 10
5.1.2. Procedures at Intermediate Proxies . . . . . . . . . . 11
5.1.3. Procedures at User Agent Servers . . . . . . . . . . . 12
5.2. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Responses . . . . . . 12
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. P-Asserted-Service and P-Preferred-Service Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Definition of Service-ID Values . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service, possibly subject to the user being entitled to that service. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service model suitable for use between different trust domains or for use in the Internet at large.
このドキュメントでは、信頼できるSIPサーバーのネットワークがサービスを主張できるようにするセッション開始プロトコル（SIP）へのプライベート拡張機能について説明します。これらの拡張機能の使用は、そのような情報の生成、輸送、および使用に関する以前に合意されたポリシーで、管理ドメイン内でのみ適用されます。このドキュメントは、異なる信頼ドメイン間での使用やインターネット全体で使用するのに適した一般的なサービスモデルを提供していません。
The concept of "service" within SIP has no hard and fast rules. RFC 5897 [RFC5897] provides general guidance on what constitutes a service within SIP and what does not.
SIP内の「サービス」の概念には、難しいルールと高速なルールはありません。RFC 5897 [RFC5897]は、SIP内のサービスを構成するものとそうでないものに関する一般的なガイダンスを提供します。
This document also makes use of the terms "derived service identification" and "declarative service identification" as defined in RFC 5897 [RFC5897].
このドキュメントでは、RFC 5897 [RFC5897]で定義されている「派生サービス識別」および「宣言的サービス識別」という用語も使用しています。
It should be noted that RFC 5897 [RFC5897] clearly states that declarative service identification -- the process by which a user agent inserts a moniker into a message that defines the desired service, separate from explicit and well-defined protocol mechanisms -- is harmful.
RFC 5897 [RFC5897]は、宣言的なサービス識別（ユーザーエージェントが明示的で明確に定義されたプロトコルメカニズムとは別の目的のサービスを定義するメッセージにモニカーを挿入するプロセス）が有害であることを明確に述べていることに注意する必要があります。。
During a session setup, proxies may need to understand what service the request is related to in order to know what application server to contact or other service logic to invoke. The SIP INVITE request contains all of the information necessary to determine the service. However, the calculation of the service may be computational and database intensive. For example, a given trust domain's definition of a service might include request authorization. Moreover, the analysis may require examination of the Session Description Protocol (SDP).
セッションのセットアップ中、プロキシは、どのアプリケーションサーバーが連絡するアプリケーションサーバーまたは呼び出す他のサービスロジックを知るために、リクエストが関連しているサービスを理解する必要がある場合があります。SIP Inviteリクエストには、サービスを決定するために必要なすべての情報が含まれています。ただし、サービスの計算は計算およびデータベース集約的である可能性があります。たとえば、特定の信頼ドメインのサービスの定義には、リクエスト承認が含まれる場合があります。さらに、分析では、セッション説明プロトコル（SDP）の調査が必要になる場合があります。
For example, an INVITE request with video SDP directed to a video-on-demand Request-URI could be marked as an IPTV session. An INVITE request with push-to-talk over cellular (PoC) routes could be marked as a PoC session. An INVITE request with a Require header field containing an option tag of "foogame" could be marked as a foogame session.
たとえば、ビデオSDPを使用したビデオSDPを使用した招待状リクエストは、ビデオオンデマンドリクエストURIに向けられているため、IPTVセッションとしてマークできます。Cellular（POC）ルートを介したプッシュツートークの招待状リクエストは、POCセッションとしてマークされる可能性があります。「Foogame」のオプションタグを含む必要なヘッダーフィールドを使用した招待リクエストは、Foogameセッションとしてマークできます。
NOTE: If the information contained within the SIP INVITE request is not sufficient to uniquely identify a service, the remedy is to extend the SIP signaling to capture the missing element. RFC 5897 [RFC5897] provides further explanation.
注：SIP Invite Requestに含まれる情報がサービスを一意に識別するのに十分ではない場合、救済策はSIPシグナルを拡張して欠落要素をキャプチャすることです。RFC 5897 [RFC5897]はさらなる説明を提供します。
By providing a mechanism to compute and store the results of the domain-specific service calculation, i.e., the derived service identification, this optimization allows a single trusted proxy to perform an analysis of the request and authorize the requestor's permission to request such a service. The proxy may then include a service identifier that relieves other trusted proxies and trusted UAs from performing further duplicate analysis of the request for their service identification purposes. In addition, this extension allows user agent clients outside the trust domain to provide a hint of the requested service.
ドメイン固有のサービス計算の結果、つまり派生サービス識別の結果を計算して保存するメカニズムを提供することにより、この最適化により、単一の信頼できるプロキシがリクエストの分析を実行し、リクエスターのそのようなサービスを要求する許可を許可することができます。その後、プロキシには、他の信頼できるプロキシと信頼できるUAが、サービス識別目的の要求のさらに重複分析を実行することを緩和するサービス識別子を含めることができます。さらに、この拡張機能により、Trustドメイン外のユーザーエージェントクライアントは、要求されたサービスのヒントを提供できます。
This extension does not provide for the dialog or transaction to be rejected if the service is not supported end-to-end. SIP provides other mechanisms, such as the option-tag and use of the Require and Proxy-Require header fields, where such functionality is required. No explicitly signaled service identification exists, and the session proceeds for each node's definition of the service in use, on the basis of information contained in the SDP and in other SIP header fields.
この拡張機能は、サービスがエンドツーエンドでサポートされていない場合、ダイアログまたはトランザクションが拒否されるようには提供されません。SIPは、そのような機能が必要な場合、オプションタグや要件およびプロキシリクイアヘッダーフィールドの使用など、他のメカニズムを提供します。SDPおよびその他のSIPヘッダーフィールドに含まれる情報に基づいて、セッションは、セッションが使用されているサービスの各ノードの定義に対して存在することは明示的ではありません。
This mechanism is specifically for managing the information needs of intermediate routing devices between the calling user and the user represented by the Request-URI. In support of this mechanism, a URN is defined to identify the services. This URN has wider applicability to additionally identify services and terminal applications. Between end users, caller preferences and callee capabilities as specified in RFC 3840 [RFC3840] and RFC 3841 [RFC3841] provide an appropriate mechanism for indicating such service and application identification. These mechanisms have been extended by RFC 5688 [RFC5688] to provide further capabilities in this area.
このメカニズムは、呼び出しユーザーとリクエストURIで表されるユーザーの間の中間ルーティングデバイスの情報ニーズを管理するためのものです。このメカニズムをサポートするために、URNはサービスを識別するために定義されています。このurnは、サービスとターミナルアプリケーションをさらに識別するためのより広範な適用性を備えています。RFC 3840 [RFC3840]とRFC 3841 [RFC3841]で指定されているエンドユーザー、発信者の好み、Callee機能の間で、そのようなサービスとアプリケーションの識別を示すための適切なメカニズムを提供します。これらのメカニズムは、RFC 5688 [RFC5688]によって拡張されており、この領域でさらなる機能を提供しています。
The mechanism proposed in this document relies on a new header field called 'P-Asserted-Service' that contains a URN. This is supported by a further new header field called 'P-Preferred-Service' that also contains a URN and that allows the UA to express preferences regarding the decisions made on service within the trust domain.
このドキュメントで提案されているメカニズムは、urを含む「p-asserted-service」と呼ばれる新しいヘッダーフィールドに依存しています。これは、urnを含む「p-preferred-service」と呼ばれるさらに新しいヘッダーフィールドによってサポートされており、UAが信頼ドメイン内のサービスで行われた決定に関して選好を表現できます。
An example of the P-Asserted-Service header field is:
P asserted-serviceヘッダーフィールドの例は次のとおりです。
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
A proxy server that handles a request can, after authenticating the originating user in some way (for example: digest authentication) to ensure that the user is entitled to that service, insert such a P-Asserted-Service header field into the request and forward it to other trusted proxies. A proxy that is about to forward a request to a proxy server or UA that it does not trust removes all the P-Asserted-Service header field values.
リクエストを処理するプロキシサーバーは、何らかの方法で元のユーザーを認証した後（たとえば：消化認証）、ユーザーがそのサービスの権利を与えられるようにすることができます。他の信頼できるプロキシへ。プロキシサーバーまたはUAにリクエストを転送しようとしているプロキシは、すべてのP assert-serviceヘッダーフィールド値を削除することを信頼していません。
This document labels services by means of an informal URN. This provides a hierarchical structure for defining services and subservices, and provides an address that can be resolvable for various purposes outside the scope of this document, e.g., to obtain information about the service so described.
このドキュメントは、非公式のurを使用してサービスをラベル付けします。これにより、サービスとサブサービスを定義するための階層構造が提供され、説明されているサービスに関する情報を取得するために、このドキュメントの範囲外のさまざまな目的のために解決できるアドレスを提供します。
This document describes private extensions to SIP (see RFC 3261 [RFC3261]) that enable a network of trusted SIP servers to assert the service of end users or end systems. The use of these extensions is only applicable inside a 'trust domain' as defined in "Short Term Requirements for Network Asserted Identity" (see RFC 3324 [RFC3324]). Nodes in such a trust domain are explicitly trusted by its users and end systems to publicly assert the service of each party, and that they have common and agreed-upon definitions of services and homogeneous service offerings. The means by which the network determines the service to assert is outside the scope of this document (though it commonly entails some form of authentication).
このドキュメントでは、SIPへのプライベートエクステンション（RFC 3261 [RFC3261]を参照）について説明します。これにより、信頼できるSIPサーバーのネットワークがエンドユーザーまたはエンドシステムのサービスを主張できます。これらの拡張機能の使用は、「ネットワーク主張されたアイデンティティの短期的要件」で定義されている「信頼ドメイン」内でのみ適用されます（RFC 3324 [RFC3324]を参照）。このような信頼ドメインのノードは、ユーザーとエンドシステムによって明示的に信頼されており、各当事者のサービスを公に主張し、サービスと均質なサービス提供の共通と合意された定義があることを示しています。ネットワークが主張するサービスを決定する手段は、このドキュメントの範囲外であると判断します（ただし、一般に何らかの認証を伴います）。
The mechanism for defining a trust domain is to provide a certain set of specifications known as 'Spec(T)', and then specify compliance to that set of specifications. Spec(T) MUST specify behavior as documented in RFC 3324 [RFC3324].
信頼ドメインを定義するメカニズムは、「Spec（T）」として知られる特定の仕様セットを提供し、その仕様のセットへのコンプライアンスを指定することです。Spec（T）は、RFC 3324 [RFC3324]で文書化されているように動作を指定する必要があります。
This document does NOT offer a general service model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model whereby end users can independently assert their service by use of the extensions defined here. End users assert their service by including the SIP and SDP parameters that correspond to the service they require. Furthermore, since the asserted services are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of RFC 3324 [RFC3324].
このドキュメントは、インターネット全体でのドメイン間の使用または使用に適した一般サービスモデルを提供しません。ユーザーとネットワークの間の信頼関係に関する仮定は、多くのアプリケーションでは適用されない場合があります。たとえば、これらの拡張機能は、エンドユーザーがここで定義されている拡張機能を使用してサービスを独立して主張できるモデルに対応していません。エンドユーザーは、必要なサービスに対応するSIPおよびSDPパラメーターを含めることにより、サービスを主張します。さらに、主張されたサービスは暗号化された認定を受けていないため、RFC 3324 [RFC3324]の要件を満たさないアーキテクチャの偽造、リプレイ、および改ざんの対象となります。
The asserted services also lack an indication of who specifically is asserting the service, and so it must be assumed that a member of the trust domain is asserting the service. Therefore, the information is only meaningful when securely received from a node known to be a member of the trust domain.
また、主張されたサービスには、誰が具体的にサービスを主張しているかの兆候も欠いているため、信頼ドメインのメンバーがサービスを主張していると想定する必要があります。したがって、情報は、信頼ドメインのメンバーであることが知られているノードから安全に受信された場合にのみ意味があります。
Despite these limitations, there are sufficiently useful specialized deployments, that meet the assumptions described above and can accept the limitations that result, to warrant informational publication of this mechanism.
これらの制限にもかかわらず、このメカニズムの情報公開を保証するために、上記の仮定を満たし、結果の制限を受け入れることができる十分に有用な専門的な展開があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
Throughout this document, requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a trust domain (for example, back-to-back user agents (B2BUAs)).
このドキュメント全体で、プロキシサーバーまたはプロキシの動作の要件または参照は、信頼ドメイン内の他の仲介者（たとえば、連続したユーザーエージェント（B2BUA））に同様に適用されます。
The term trust domain in this document has the meaning as defined in RFC 3324 [RFC3324].
このドキュメントのTrustドメインという用語には、RFC 3324 [RFC3324]で定義されている意味があります。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234].
次の構文仕様では、RFC 5234 [RFC5234]に記載されているように、増強されたバックナウル形式（BNF）を使用しています。
The P-Asserted-Service header field is used among trusted SIP entities (typically intermediaries) to carry the service information of the user sending a SIP message.
P-Asserted-Serviceヘッダーフィールドは、信頼できるSIPエンティティ（通常は仲介者）の間で使用され、SIPメッセージを送信するユーザーのサービス情報を伝達します。
The P-Asserted-Service header field carries information that is derived service identification. While a declarative service identification can assist in deriving the value transferred in this header field, this should be in the form of streamlining the correct derived service identification.
P-Asserted-Serviceヘッダーフィールドには、派生したサービス識別である情報が届きます。宣言的なサービス識別は、このヘッダーフィールドで転送される値を導出するのに役立ちますが、これは正しい派生サービス識別を合理化する形である必要があります。
PAssertedService = "P-Asserted-Service" HCOLON PAssertedService-value
passertedservice = "p-asserted-service" hcolon passertedservice-value
PAssertedService-value = Service-ID *(COMMA Service-ID)
passertedservice-value = service-id *（comma service-id）
See Section 4.4 for the definition of Service-ID in ABNF.
ABNFのService-IDの定義については、セクション4.4を参照してください。
Proxies can (and will) add and remove this header field.
プロキシは、このヘッダーフィールドを追加および削除することができます。
Table 1 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in the reliability of provisional responses in SIP [RFC3262], Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for instant messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
表1に、このドキュメントで定義されているヘッダーフィールドは、SIP [RFC3261]の表2に、SIP固有のイベント通知[RFC3265]のセクション7.1、SIP情報方法[RFC2976]の表1と2、表1、表1、表1の表1と2の表1を追加します。SIP [RFC3262]、SIP更新法[RFC3311]の表1および2の暫定応答の信頼性、SIP拡張の表1および2のインスタントメッセージングの表1および2、SIP参照法[RFC3515]の表1、SIPパブリッシュメソッド[RFC3903]の表2および3：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Asserted-Service R admr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Asserted-Service - - - - o o o
Table 1
表1
Syntactically, there may be multiple P-Asserted-Service header fields in a request. The semantics of multiple P-Asserted-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST provide only one P-Asserted-Service header field value.
構文的には、リクエストに複数のP asserted-serviceヘッダーフィールドがある場合があります。同じリクエストに表示される複数のP asserted-serviceヘッダーフィールドのセマンティクスは、現時点では定義されていません。この仕様の実装では、P-Asserted-Serviceヘッダーフィールド値が1つだけ提供する必要があります。
The P-Preferred-Service header field is used by a user agent sending the SIP request to provide a hint to a trusted proxy of the preferred service that the user wishes to be used for the P-Asserted-Service field value that the trusted element will insert.
P-Referred-Service Headerフィールドは、SIPリクエストを送信するユーザーエージェントが使用して、ユーザーが信頼できる要素をP-Asserted-Serviceフィールド値に使用することを望んでいる優先サービスの信頼できるプロキシにヒントを提供します挿入します。
The P-Preferred-Service header field carries information that is declarative service identification. Such information should only be used to assist in deriving a derived service identification at the recipient entity.
P-Referred-Serviceヘッダーフィールドには、宣言的なサービス識別である情報が含まれています。そのような情報は、受信者エンティティで派生したサービス識別を導出するのを支援するためにのみ使用する必要があります。
PPreferredService = "P-Preferred-Service" HCOLON PPreferredService-value
ppreferredService = "p-preferred-service" hcolon ppreferredservice-value
PPreferredService-value = Service-ID *(COMMA Service-ID)
ppreferredservice-value = service-id *（comma service-id）
See Section 4.4 for the definition of Service-ID in ABNF.
ABNFのService-IDの定義については、セクション4.4を参照してください。
Table 2 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in Reliability of provisional responses in SIP [RFC3262], Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for Instant Messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
表2に、このドキュメントで定義されているヘッダーフィールドは、SIP [RFC3261]の表2に、SIP固有のイベント通知[RFC3265]のセクション7.1、SIP情報方法[RFC2976]の表1および2、表1、表1と2の表1、2の表1と2を追加します。SIP [RFC3262]、SIP更新法[RFC3311]の表1および2、SIP拡張の表1および2の即時メッセージの表1および2の暫定応答の信頼性[RFC3428]、SIP参照法[RFC3515]の表1、およびSIPパブリッシュメソッド[RFC3903]の表2および3：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Preferred-Service R dr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Preferred-Service - - - - o o o
Table 2
表2
Syntactically, there may be multiple P-Preferred-Service header fields in a request. The semantics of multiple P-Preferred-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST only provide one P-Preferred-Service header field value.
構文的に、リクエストには複数のp-referred-serviceヘッダーフィールドがある場合があります。同じリクエストに表示される複数のp-Referred-Serviceヘッダーフィールドのセマンティクスは、現時点では定義されていません。この仕様の実装では、P-Referred-Serviceヘッダーフィールド値が1つだけ提供する必要があります。
Service definitions and characteristics are outside the scope of this document. Other standards organizations, vendors, and operators may define their own services and register them.
サービスの定義と特性は、このドキュメントの範囲外です。他の標準組織、ベンダー、およびオペレーターは、独自のサービスを定義して登録することができます。
A hierarchical structure is defined consisting of service identifiers or application identifiers, and subservice identifiers.
階層構造は、サービス識別子またはアプリケーション識別子、およびサブサービス識別子で構成される定義されています。
The service and subservice identifiers are as described in Section 1. The URN may also be used to identify a service or an application between end users for use within the context of RFC 3840 [RFC3840] and RFC 3841 [RFC3841].
セクション1で説明されているように、サービスとサブサービスの識別子は、URNを使用して、RFC 3840 [RFC3840]およびRFC 3841 [RFC3841]のコンテキスト内で使用するエンドユーザー間のサービスまたはアプリケーションを特定することもできます。
IANA maintains a registry of service identifier values that have been assigned. This registry has been created by the actions of Section 8.2 of this document.
IANAは、割り当てられたサービス識別子値のレジストリを維持しています。このレジストリは、このドキュメントのセクション8.2のアクションによって作成されています。
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices.
サブサービス識別子はIANAによって管理されていません。サブサービスを管理するためにサービスを登録したのは、組織の責任です。
Below, we include the registration template for the URN scheme according to RFC 3406 [RFC3406]. The URN scheme is defined as an informal Namespace ID (NID).
以下に、RFC 3406 [RFC3406]に従って、URNスキームの登録テンプレートを含めます。URNスキームは、非公式の名前空間ID（NID）として定義されます。
Namespace ID: urn-7
名前空間ID：urn-7
Registration Information:
Registration version: 1; registration date: 2009-03-22
Declared registrant of the namespace: 3GPP Specifications Manager (3gppContact@etsi.org) (+33 (0)492944200)
名前空間の登録者と宣言：3GPP仕様マネージャー（3gppcontact@etsi.org）（33（0）492944200）
Declaration of syntactic structure: The URN consists of a hierarchical service identifier or application identifier, with a sequence of labels separated by periods. The leftmost label is the most significant one and is called 'top-level service identifier', while names to the right are called 'subservices' or 'sub-applications'. The set of allowable characters is the same as that for domain names (see RFC 1123 [RFC1123]) and a subset of the labels allowed in RFC 3958 [RFC3958]. Labels are case-insensitive and MUST be specified in all lowercase. For any given service identifier, labels can be removed right-to-left and the resulting URN is still valid, referring a more generic service, with the exception of the top-level service identifier and possibly the first subservice or sub-application identifier. Labels cannot be removed beyond a defined basic service; for example, the label w.x may define a service, but the label w may only define an assignment authority for assigning subsequent values and not define a service in its own right. In other words, if a service identifier 'w.x.y.z' exists, the URNs 'w.x' and 'w.x.y' are also valid service identifiers, but w may not be a valid service identifier if it merely defines who is responsible for defining x.
構文構造の宣言：urnは、期間で分離された一連のラベルを持つ階層サービス識別子またはアプリケーション識別子で構成されています。左端のラベルは最も重要なラベルであり、「トップレベルのサービス識別子」と呼ばれ、右側の名前は「サブサービス」または「サブアプリケーション」と呼ばれます。許容文字のセットは、ドメイン名のセットと同じです（RFC 1123 [RFC1123]を参照）、およびRFC 3958 [RFC3958]で許可されるラベルのサブセット。ラベルはケース感受性であり、すべての小文字で指定する必要があります。特定のサービス識別子の場合、ラベルは右から左に削除でき、結果として得られるURNは依然として有効であり、トップレベルのサービス識別子と場合によっては最初のサブサービスまたはサブアプリケーション識別子を除き、より一般的なサービスを参照してください。定義された基本サービスを超えてラベルを削除することはできません。たとえば、ラベルW.Xはサービスを定義する場合がありますが、ラベルWは、後続の値を割り当てるための割り当て機関のみを定義し、それ自体のサービスを定義しない場合があります。言い換えれば、サービス識別子 'w.x.y.z'が存在する場合、urns 'w.x'および 'w.x.y'も有効なサービス識別子ですが、wがxを定義する責任者だけを定義する場合、wは有効なサービス識別子ではない場合があります。
Service-ID = "urn:urn-7:" urn-service-id
urn-service-id = top-level *("." sub-service-id)
top-level = let-dig [ *26let-dig ]
sub-service-id = let-dig [ *let-dig ]
let-dig = ALPHA / DIGIT / "-"
While the naming convention above uses the term "service", all the constructs are equally applicable to identifying applications within the UA.
上記の命名規則では「サービス」という用語を使用していますが、すべてのコンストラクトはUA内のアプリケーションの識別に等しく適用できます。
Relevant ancillary documentation: None
関連する補助文書：なし
Identifier uniqueness considerations: A service identifier identifies a service, and an application identifier an application indicated in the service or application registration (see IANA Considerations (Section 8)). Uniqueness is guaranteed by the IANA registration.
識別子の一意性に関する考慮事項：サービス識別子はサービスを識別し、アプリケーション識別子サービスまたはアプリケーション登録に示されているアプリケーションを識別子にします（IANAの考慮事項（セクション8）を参照）。IANA登録によって一意性が保証されます。
Identifier persistence considerations: The service or application identifier for the same service or application is expected to be persistent, although there naturally cannot be a guarantee that a particular service will continue to be available globally or at all times.
識別子の持続性の考慮事項：同じサービスまたはアプリケーションのサービスまたはアプリケーション識別子は、永続的であると予想されますが、当然、特定のサービスが常にグローバルまたは常に利用可能になることを保証することはできません。
Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 8).
識別子割り当てのプロセス：識別子割り当てのプロセスは、IANAの考慮事項（セクション8）で説明されています。
Process for identifier resolution: There is no single global resolution service for service identifiers or application identifiers.
識別子解像度のプロセス：サービス識別子またはアプリケーション識別子のための単一のグローバル解像度サービスはありません。
Rules for lexical equivalence: 'service' identifiers are compared according to case-insensitive string equality.
語彙の等価性のルール：「サービス」識別子は、ケースに依存しない文字列等式に従って比較されます。
Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme.
URN構文への適合：上記の「構文構造の宣言」のBNFは、このURNスキームの構文を制約します。
Validation mechanism: Validation determines whether a given string is currently a validly assigned URN (see RFC 3406 [RFC3406]). Due to the distributed nature of usage and since not all services are available everywhere, validation in this sense is not possible.
検証メカニズム：検証指定された文字列が現在有効に割り当てられているURNであるかどうかを決定します（RFC 3406 [RFC3406]を参照）。分散された使用の性質があるため、すべてのサービスがどこでも利用できるわけではないため、この意味での検証は不可能です。
Scope: The scope for this URN can be local to a single domain, or may be more widely used.
範囲：このurnのスコープは、単一のドメインにローカルであるか、より広く使用される場合があります。
The UAC MAY insert a P-Preferred-Service in a request that creates a dialog, or a request outside of a dialog. This information can assist the proxies in identifying appropriate service capabilities to apply to the call. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present. Thus, if a service requires a video component, then the SDP has to include the media line associated with that video component; it cannot be assumed from the P-Preferred-Service header field value. Similarly, if the service requires particular SIP functionality for which a SIP extension and a Require header field value is defined, then the request has to include that SIP signaling as well as the P-Preferred-Service header field value.
UACは、ダイアログまたはダイアログの外側のリクエストを作成するリクエストにp-referred-serviceを挿入する場合があります。この情報は、コールに適用する適切なサービス機能を特定する際にプロキシを支援できます。この情報は、リクエストに含まれる他のSIPまたはSDP情報と矛盾してはなりません。さらに、このサービスの機能性を信号にするために必要なSIPまたはSDP情報が存在する必要があります。したがって、サービスにビデオコンポーネントが必要な場合、SDPはそのビデオコンポーネントに関連付けられたメディアラインを含める必要があります。P-Referred-Serviceヘッダーフィールド値から想定することはできません。同様に、サービスにSIP拡張機能と要求ヘッダーフィールド値が定義される特定のSIP機能が必要な場合、リクエストには、そのSIPシグナリングとP-Preferred-Serviceヘッダーフィールド値を含める必要があります。
A UAC that is within the same trust domain as the proxy to which it sends a request (e.g., a media gateway or application server) MAY insert a P-Asserted-Service header field in a request that creates a dialog, or a request outside of a dialog. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present.
リクエストを送信するプロキシ（メディアゲートウェイまたはアプリケーションサーバーなど）と同じトラストドメイン内にあるUACは、ダイアログまたは外部のリクエストを作成するリクエストにP asserted-serviceヘッダーフィールドを挿入できます。ダイアログの。この情報は、リクエストに含まれる他のSIPまたはSDP情報と矛盾してはなりません。さらに、このサービスの機能性を信号にするために必要なSIPまたはSDP情報が存在する必要があります。
A proxy in a trust domain can receive a request from a node that it trusts or a node that it does not trust. When a proxy receives a request from a node it does not trust and it wishes to add a P-Asserted-Service header field, the proxy MUST identify the service appropriate to the capabilities (e.g., SDP) in the request, MAY authenticate the originator of the request (in order to determine whether the user is subscribed for that service). Where the originator of the request is authenticated, the proxy MUST use the identity that results from this checking and authentication to insert a P-Asserted-Service header field into the request.
トラストドメインのプロキシは、信頼できるノードまたは信頼していないノードからリクエストを受信できます。プロキシが信頼していないノードからリクエストを受信し、P-Asserted-Serviceヘッダーフィールドを追加したい場合、プロキシはリクエストの機能（SDPなど）に適したサービスを特定する必要があります。リクエストの（ユーザーがそのサービスのために購読されているかどうかを判断するため）。リクエストのオリジネーターが認証されている場合、プロキシは、このチェックと認証から生じるIDを使用して、P-Asserted-Serviceヘッダーフィールドをリクエストに挿入する必要があります。
When a proxy receives a request containing a P-Preferred-Service header field, the Proxy MAY use the contents of that header field to assist in determining the service to be included in a P-Asserted-Service header field (for instance, to prioritize the order of comparison of filter criteria for potential services that the request could match). The proxy MUST NOT use the contents of the P-Preferred-Service header field to identify the service without first checking against the capabilities (e.g., SDP) contained in the request. If the proxy inserts a P-Asserted-Service header field in the request, the proxy MUST remove the P-Preferred-Service header field before forwarding the request; otherwise, the Proxy SHOULD include the P-Preferred-Service header field when forwarding the request.
プロキシがP-Referred-Serviceヘッダーフィールドを含むリクエストを受信した場合、プロキシはそのヘッダーフィールドの内容を使用して、P-Asserted-Serviceヘッダーフィールドに含まれるサービスを決定するのを支援することができます（たとえば、優先順位付け要求が一致する可能性のある潜在的なサービスのフィルター基準の比較の順序）。プロキシは、PREFERED-SERVICEヘッダーフィールドのコンテンツを使用して、リクエストに含まれる機能（例：SDP）に対して最初にチェックすることなくサービスを識別してはなりません。プロキシがリクエストにP asserted-serviceヘッダーフィールドを挿入する場合、プロキシはリクエストを転送する前にp-referred-serviceヘッダーフィールドを削除する必要があります。それ以外の場合、リクエストを転送するときに、プロキシにはP-Referred-Serviceヘッダーフィールドを含める必要があります。
If the proxy receives a request from a node that it trusts, it can use the information in the P-Asserted-Service header field, if any, as if it had authenticated the user itself.
プロキシが信頼するノードからリクエストを受信した場合、ユーザー自体を認証したかのように、P-Asserted-Serviceヘッダーフィールドの情報を使用できます。
If there is no P-Asserted-Service header field present, or it is not possible to match the request to a specific service as identified by the service identifier, a proxy MAY add one containing it using its own analysis of the information contained in the SIP request. If the proxy received the request from an element that it does not trust and there is a P-Asserted-Service header present, the proxy MUST replace that header field's contents with a new analysis or remove that header field.
P-Asserted-Serviceヘッダーフィールドが存在しない場合、またはサービス識別子によって識別された特定のサービスにリクエストを一致させることができない場合、プロキシは、SIPリクエスト。プロキシが信頼していない要素からリクエストを受け取り、P asserted-serviceヘッダーが存在する場合、プロキシはそのヘッダーフィールドの内容を新しい分析に置き換えるか、そのヘッダーフィールドを削除する必要があります。
The analysis performed to identify such service identifiers is outside the scope of this document. However, it is perfectly valid as a result of the analysis not to include any service identifier in the forwarded request, and thus not include a P-Asserted-Service header field.
このようなサービス識別子を識別するために実行された分析は、このドキュメントの範囲外です。ただし、分析の結果として完全に有効であり、転送された要求にサービス識別子を含めないため、P asserted-serviceヘッダーフィールドは含まれません。
If a proxy forwards a request to a node outside the proxy's trust domain, there MUST NOT be a P-Asserted-Service header field in the forwarded request.
プロキシがプロキシの信頼ドメインの外側のノードにリクエストを転送した場合、転送された要求にP asserted-serviceヘッダーフィールドがあるはずです。
For a User Agent Server (UAS) outside the trust domain, the P-Asserted-Service header is removed before it reaches this entity; therefore, there are no procedures for such a device.
Trustドメインの外側のユーザーエージェントサーバー（UAS）の場合、このエンティティに到達する前に、P asserted-serviceヘッダーが削除されます。したがって、そのようなデバイスの手順はありません。
However, if a UAS receives a request from a previous element that it does not trust, it MUST NOT use the P-Asserted-Service header field in any way.
ただし、UASが以前の要素から信頼していないという要求を受け取った場合、P-Asserted-Serviceヘッダーフィールドを何らかの形で使用してはなりません。
If a UA is part of the trust domain from which it received a request containing a P-Asserted-Service header field, then it can use the value freely, but it MUST ensure that it does not forward the information to any element that is not part of the trust domain.
UAがP-Asserted-Serviceヘッダーフィールドを含むリクエストを受け取ったTrustドメインの一部である場合、値を自由に使用できますが、そうでない要素に情報を転送しないようにする必要があります。信頼ドメインの一部。
There is no usage of these header fields in responses.
応答には、これらのヘッダーフィールドの使用はありません。
In this example, proxy.example.com creates a P-Asserted-Service header field from the user identity it discovered from SIP digest authentication, the list of services appropriate to that user, and the services that correspond to the SDP information included in the request. Note that F1 and F2 are about identifying the user and do not directly form part of the capability provided in this document. It forwards this information to a trusted proxy that forwards it to a trusted gateway. Note that these examples consist of partial SIP messages that illustrate only those header fields relevant to the authenticated identity problem.
この例では、proxy.example.comは、SIPダイジェスト認証から発見したユーザーID、そのユーザーに適したサービスのリスト、およびリクエスト。F1とF2はユーザーを識別することであり、このドキュメントで提供される機能の一部を直接形成しないことに注意してください。この情報を信頼できるプロキシに転送し、信頼できるゲートウェイに転送します。これらの例は、認証されたアイデンティティの問題に関連するヘッダーフィールドのみを示す部分的なSIPメッセージで構成されていることに注意してください。
* F1 useragent.example.com -> proxy.example.com
* f1 useragent.example.com-> proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
* F2 proxy.example.com -> useragent.example.com
* f2 proxy.example.com-> useragent.example.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.example.com"
* F3 useragent.example.com -> proxy.example.com
* F3 useragent.example.com-> proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Proxy-Authorization: realm="sip.example.com" user="fluffy"
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
* F4 proxy.example.com -> proxy.pstn.example (trusted)
* f4 proxy.example.com-> proxy.pstn.example（信頼できる）
INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
* F5 proxy.pstn.example -> gw.pstn.example (trusted)
* f5 proxy.pstn.example-> gw.pstn.example（信頼できる）
INVITE sip:+14085551212@gw.pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.example;branch=z9hG4bK-a1b2
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
The mechanism provided in this document is a partial consideration of the problem of service identification in SIP. For example, these mechanisms provide no means by which end users can securely share service information end-to-end without a trusted service provider. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust.
このドキュメントで提供されるメカニズムは、SIPでのサービス識別の問題を部分的に考慮しています。たとえば、これらのメカニズムは、エンドユーザーが信頼できるサービスプロバイダーなしでエンドツーエンドのサービス情報を安全に共有できる手段を提供しません。この情報は、トランスティブトラストによって保護されています。これは、信頼のチェーンで最も弱いリンクと同じくらい信頼できるものです。
The trust domain provides a set of servers where the characteristics of the service are agreed for that service identifier value, and where the calling user is entitled to use that service. RFC 5897 [RFC5897] identifies the impact of allowing such service identifier values to "leak" outside of the trust domain, including implications on fraud, interoperability, and stifling of service innovation.
Trustドメインは、サービスの特性がそのサービス識別子値に対して合意され、呼び出しユーザーがそのサービスを使用する権利があるサーバーのセットを提供します。RFC 5897 [RFC5897]は、詐欺、相互運用性、サービスイノベーションの息苦しさを含む、このようなサービス識別子値を信頼ドメインの外側に「リーク」することの影響を特定します。
This document specifies two new SIP header fields: P-Asserted-Service and P-Preferred-Service. Their syntax is given in Section 3. These header fields are defined by the following information, which has been added to the header sub-registry under http://www.iana.org.
このドキュメントは、P-Asserted-ServiceとP-Referred-Serviceの2つの新しいSIPヘッダーフィールドを指定します。それらの構文はセクション3に記載されています。これらのヘッダーフィールドは、http://www.iana.orgに基づいてヘッダーサブレジストリに追加された次の情報で定義されています。
Header Name compact Reference
----------------- ------- ---------
P-Asserted-Service RFC 6050
P-Preferred-Service RFC 6050
Top-level identifiers are identified by labels managed by IANA, according to the processes outlined in RFC 5226 [RFC5226], in a new registry called "Service-ID/Application-ID Labels". Thus, creating a new service at the top-level requires IANA action. The policy for adding service labels is 'specification required'. The following two identifiers are initially defined:
トップレベルの識別子は、RFC 5226 [RFC5226]で概説されているプロセスに従って、「Service-ID/Application-IDラベル」と呼ばれる新しいレジストリで、IANAが管理するラベルによって識別されます。したがって、トップレベルで新しいサービスを作成するには、IANAアクションが必要です。サービスラベルを追加するためのポリシーは「必要な仕様」です。次の2つの識別子が最初に定義されています。
3gpp-service
3GPP-Service
3gpp-application
3GPPアプリケーション
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices.
サブサービス識別子はIANAによって管理されていません。サブサービスを管理するためにサービスを登録したのは、組織の責任です。
Application identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the applicable applications.
アプリケーション識別子はIANAによって管理されません。該当するアプリケーションを管理するためにサービスを登録したのは、組織の責任です。
Entries in the registration table have the following format:
登録表のエントリには、次の形式があります。
Service/Application Description Reference
--------------------------------------------------------------------
3gpp-service Communication services defined by RFC 6050
3GPP for use by the IM CN subsystem
and its attached UAs. This value
in itself does not define a service
and requires subsequent labels to
define the service.
3gpp-application Applications defined by 3GPP for RFC 6050 use by UAs attached to the IM CN subsystem. This value in itself does not define a service and requires subsequent labels to define the service.
3GPPで定義された3GPPアプリケーションアプリケーションは、IM CNサブシステムに添付されたUASがRFC 6050を使用するために定義されています。この値自体はサービスを定義せず、サービスを定義するために後続のラベルを必要とします。
Here, the IM CN subsystem stands for the IP Multimedia Core Network subsystem.
ここでは、IM CNサブシステムはIPマルチメディアコアネットワークサブシステムの略です。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[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月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]ワトソン、M。、「ネットワーク主張されたアイデンティティの短期要件」、RFC 3324、2002年11月。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406] Daigle、L.、Van Gulik、D.、Iannella、R。、およびP. Faltstrom、「ユニフォームリソース名（URN）名前空間定義メカニズム」、BCP 66、RFC 3406、2002年10月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRSおよびThe Dynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「即座のメッセージのためのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）の発信者の好み」、RFC 3841、2004年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903] Niemi、A。、「イベント州の出版物のセッション開始プロトコル（SIP）拡張」、RFC 3903、2004年10月。
[RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688, January 2010.
[RFC5688] Rosenberg、J。、「MIMEアプリケーションサブタイプのセッション開始プロトコル（SIP）メディア機能タグ」、RFC 5688、2010年1月。
[RFC5897] Rosenberg, J., "Identification of Communications Services in the Session Initiation Protocol (SIP)", RFC 5897, June 2010.
[RFC5897] Rosenberg、J。、「セッション開始プロトコル（SIP）における通信サービスの識別」、RFC 5897、2010年6月。
Author's Address
著者の連絡先
Keith Drage Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon, Wilts UK
Keith Drage Alcatel-Lucent Quadrant、Stonehill Green、Westlea Swindon、Wilts UK
EMail: drage@alcatel-lucent.com