RFC 3840 - Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3840
タイトル : RFC 3840 - セッション開始プロトコル（SIP）のユーザーエージェント機能を示す
翻訳編集 : 自動生成

[要約] RFC 3840は、SIPにおけるユーザーエージェントの機能を示すための方法を提案しています。その目的は、通信セッションの開始時にユーザーエージェントの能力を明示することです。

Network Working Group                                       J. Rosenberg
Request for Comments: 3840                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                              P. Kyzivat
                                                           Cisco Systems
                                                             August 2004

Indicating User Agent Capabilities 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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The Internet Society（2004）。

Abstract

概要

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field.

この仕様は、セッション開始プロトコル（SIP）ユーザーエージェントがその機能と特性を他のユーザーエージェントに、およびそのドメインのレジストラに伝えることができるメカニズムを定義します。この情報は、コンタクトヘッダーフィールドのパラメーターとして伝えられます。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Usage of the Content Negotiation Framework . . . . . . . . . .  6
   5.  Computing Capabilities . . . . . . . . . . . . . . . . . . . .  7
   6.  Expressing Capabilities in a Registration  . . . . . . . . . . 10
   7.  Indicating Feature Sets in Remote Target URIs  . . . . . . . . 12
   8.  OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13
   10. Media Feature Tag Definitions  . . . . . . . . . . . . . . . . 14
       10.1.  Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15
       10.2.  Application . . . . . . . . . . . . . . . . . . . . . . 16
       10.3.  Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16
       10.4.  Control . . . . . . . . . . . . . . . . . . . . . . . . 17
       10.5.  Video . . . . . . . . . . . . . . . . . . . . . . . . . 17
       10.6.  Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18
       10.7.  Automata. . . . . . . . . . . . . . . . . . . . . . . . 18
       10.8.  Class . . . . . . . . . . . . . . . . . . . . . . . . . 19
       10.9.  Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20
       10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20
       10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21
       10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22
       10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22
       10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23
       10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24
       10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24
       10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25
       10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
       11.1.  Considerations for Media Feature Tags . . . . . . . . . 26
       11.2.  Considerations for Registrations. . . . . . . . . . . . 27
       11.3.  Considerations for OPTIONS Responses. . . . . . . . . . 28
       11.4.  Considerations for Dialog Initiating Messages . . . . . 28
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
       12.1.  SIP Media Feature Tag Registration Tree . . . . . . . . 28
       12.2.  Media Feature Tags. . . . . . . . . . . . . . . . . . . 29
       12.3.  SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
       14.1.  Normative References. . . . . . . . . . . . . . . . . . 31
       14.2.  Informative References. . . . . . . . . . . . . . . . . 31
   Appendix.  Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36

1. Introduction

1. はじめに

Session Initiation Protocol (SIP) [1] user agents vary widely in their capabilities and in the types of devices they represent. Frequently, it is important for another SIP element to learn the capabilities and characteristics of a SIP UA. Some of the applications of this information include:

セッション開始プロトコル（SIP）[1]ユーザーエージェントは、その機能とそれらが表すデバイスの種類が大きく異なります。多くの場合、別のSIP要素がSIP UAの機能と特性を学習することが重要です。この情報のアプリケーションには次のものがあります。

o One user agent, a PC-based application, is communicating with another that is embedded in a limited-function device. The PC would like to be able to "grey out" those components of the user interface that represent features or capabilities not supported by its peer. To do that, there needs to be a way to exchange capability information within a dialog.

o PCベースのアプリケーションである1人のユーザーエージェントが、限られた機能デバイスに埋め込まれた別のユーザーと通信しています。PCは、ピアによってサポートされていない機能または機能を表すユーザーインターフェイスのコンポーネントを「グレーアウト」できるようにしたいと考えています。そのためには、ダイアログ内で機能情報を交換する方法が必要です。

o A user has two devices at their disposal. One is a videophone, and the other, a voice-only wireless phone. A caller wants to interact with the user using video. As such, they would like their call preferentially routed to the device which supports video. To do this, the INVITE request can contain parameters that express a preference for routing to a device with the specified capabilities [11].

o ユーザーは、自由に使用できる2つのデバイスを持っています。1つはビデオ恐怖症で、もう1つは音声のみのワイヤレス電話です。発信者は、ビデオを使用してユーザーと対話したいと考えています。このように、彼らはビデオをサポートするデバイスに彼らの呼び出しを優先的にルーティングしたいと思っています。これを行うには、招待リクエストには、指定された機能を備えたデバイスへのルーティングの好みを表すパラメーターを含めることができます[11]。

o A network application would like to asynchronously send information to a user agent in a MESSAGE [16] request. However, before sending it, they would like to know if the UA has the capabilities necessary to receive the message. To do that, they would ideally query a user database managed by the domain which holds such information. Population of such a database would require that a UA convey its capabilities as part of its registration. Thus, there is a need for conveying capabilities in REGISTER requests.

o ネットワークアプリケーションでは、メッセージ[16]リクエストでユーザーエージェントに情報を非同期的に送信します。ただし、送信する前に、UAにメッセージを受信するために必要な機能があるかどうかを知りたいと思います。そのためには、そのような情報を保持するドメインによって管理されたユーザーデータベースを理想的に照会します。このようなデータベースの母集団では、登録の一部としてUAがその機能を伝える必要があります。したがって、レジスタリクエストで機能を伝える必要があります。

SIP has some support for expression of capabilities. The Allow, Accept, Accept-Language, and Supported header fields convey some information about the capabilities of a user agent. However, these header fields convey only a small part of the information that is needed. They do not provide a general framework for expression of capabilities. Furthermore, they only specify capabilities indirectly; the header fields really indicate the capabilities of the UA as they apply to this request. SIP also has no ability to convey characteristics, that is, information that describes a UA.

SIPには、機能の表現をサポートしています。許可、受け入れ、承認、およびサポートされているヘッダーフィールドは、ユーザーエージェントの機能に関する情報を伝えます。ただし、これらのヘッダーフィールドは、必要な情報のごく一部のみを伝えます。それらは、機能を表現するための一般的なフレームワークを提供しません。さらに、彼らは間接的に機能を指定するだけです。ヘッダーフィールドは、このリクエストに適用されるUAの機能を実際に示しています。SIPには、特性、つまりUAを説明する情報を伝える能力もありません。

As a result, this specification provides a more general framework for an indication of capabilities and characteristics in SIP. Capability and characteristic information about a UA is carried as parameters of the Contact header field. These parameters can be used within REGISTER requests and responses, OPTIONS responses, and requests and responses that create dialogs (such as INVITE).

その結果、この仕様は、SIPの機能と特性を示すためのより一般的なフレームワークを提供します。UAに関する能力と特徴的な情報は、コンタクトヘッダーフィールドのパラメーターとして運ばれます。これらのパラメーターは、登録要求と応答、オプションの応答、ダイアログ（招待など）を作成するリクエストと応答内で使用できます。

2. Terminology

2. 用語

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations.

このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "BCP 14、RFC 2119 [2]に記載されているように解釈され、準拠の実装の要件レベルを示します。

3. Definitions

3. 定義

Feature: As defined in RFC 2703 [17], a piece of information about the media handling properties of a message passing system component or of a data resource. For example, the SIP methods supported by a UA represent a feature.

機能：RFC 2703 [17]で定義されているように、メッセージを渡すシステムコンポーネントまたはデータリソースのメディア処理プロパティに関する情報。たとえば、UAでサポートされるSIPメソッドは機能を表します。

Feature Tag: As defined in RFC 2703 [17], a feature tag is a name that identifies a feature. An example is "sip.methods".

機能タグ：RFC 2703 [17]で定義されているように、機能タグは機能を識別する名前です。例は「sip.methods」です。

Media Feature: As defined in RFC 2703, [17], a media feature is information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.

メディア機能：RFC 2703 [17]で定義されているように、メディア機能は、メッセージコンテンツが適切にレンダリングまたは提示されるように利用可能であると想定される施設を示す情報です。メディア機能には、メッセージ伝達に影響を与える情報を含めることを意図したものではありません。

In the context of this specification, a media feature is information that indicates facilities for handling SIP requests, rather than specifically for content. In that sense, it is used synonymously with feature.

この仕様のコンテキストでは、メディア機能は、コンテンツ専用ではなく、SIPリクエストを処理するための機能を示す情報です。その意味で、それは機能と同義に使用されます。

Feature Collection: As defined in RFC 2533 [4], a feature collection is a collection of different media features and associated values. This might be viewed as describing a specific rendering of a specific instance of a document or resource by a specific recipient.

機能コレクション：RFC 2533 [4]で定義されているように、機能コレクションは、さまざまなメディア機能と関連する値のコレクションです。これは、特定の受信者によるドキュメントまたはリソースの特定のインスタンスの特定のレンダリングを説明すると見なされる場合があります。

Feature Set: As defined in RFC 2703 [17], a feature set is information about a sender, recipient, or other participant in a message transfer which describes the set of features that it can handle. Where a 'feature' describes a single identified attribute of a resource, a 'feature set' describes a full set of possible attributes.

機能セット：RFC 2703 [17]で定義されているように、機能セットは、処理できる機能のセットを説明するメッセージ転送の送信者、受信者、またはその他の参加者に関する情報です。「機能」がリソースの単一の識別された属性を記述する場合、「機能セット」は、可能な属性の完全なセットを記述します。

Feature Parameters: A set of SIP header field parameters that can appear in the Contact header field. The feature parameters represent an encoding of a feature set. Each set of feature parameters maps to a feature set predicate.

特徴パラメーター：コンタクトヘッダーフィールドに表示できるSIPヘッダーフィールドパラメーターのセット。機能パラメーターは、機能セットのエンコードを表します。機能パラメーターの各セットは、機能セットの述語にマップします。

Capability: As defined in RFC 2703 [17], a capability is an attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content. A capability is distinct from a characteristic in that a capability may or may not be utilized in any particular call, whereas a characteristic is a non-negotiable property of a UA. SIP itself will often negotiate whether or not capabilities are used in a call.

能力：RFC 2703 [17]で定義されているように、機能は、特定のタイプのメッセージコンテンツを生成または処理する機能を示す送信者または受信機（多くの場合レシーバー）の属性です。能力は、特定の呼び出しで機能を利用する場合と使用できない場合があるという点で特性とは異なりますが、特性はUAの交渉不可能な特性です。SIP自体は、多くの場合、コールで機能が使用されるかどうかを交渉します。

Characteristic: A characteristic is like a capability, but describes an aspect of a UA which is not negotiable. As an example, whether or not a UA is a mobile phone is a characteristic, not a capability. The semantics of this specification do not differentiate between capability and characteristic, but the distinction is useful for illustrative purposes. Indeed, in the text below, when we say "capability", it refers to both capabilities and characteristics, unless the text explicitly says otherwise.

特性：特性は能力のようなものですが、交渉できないUAの側面を説明します。例として、UAが携帯電話であるかどうかは、機能ではなく特徴です。この仕様のセマンティクスは、能力と特性を区別するものではありませんが、この区別は説明のために役立ちます。実際、以下のテキストでは、「能力」と言うとき、テキストが明示的に特に言わない限り、能力と特性の両方を指します。

Filter: A single expression in a feature set predicate.

フィルター：機能セットの述語の単一式。

Simple Filter: An expression in a feature set predicate which is a comparison (equality or inequality) of a feature tag against a feature value.

シンプルフィルター：機能値との特徴タグの比較（等式または不平等）である機能セット述語の式。

Disjunction: A boolean OR operation across some number of terms.

分離：いくつかの用語にわたるブールまたは操作。

Conjunction: A boolean AND operation across some number of terms.

接続詞：いくつかの用語にわたるブールと操作。

Predicate: A boolean expression.

述語：ブール式。

Feature Set Predicate: From RFC 2533 [4], a feature set predicate is a function of an arbitrary feature collection value which returns a Boolean result. A TRUE result is taken to mean that the corresponding feature collection belongs to some set of media feature handling capabilities defined by this predicate.

特徴セット述語：RFC 2533 [4]から、機能セットの述語は、ブールの結果を返す任意の機能収集値の関数です。真の結果は、対応する機能コレクションが、この述語によって定義されたメディア機能処理機能のセットに属していることを意味します。

Contact Predicate: The feature set predicate associated with a URI registered in the Contact header field of a REGISTER request. The contact predicate is derived from the feature parameters in the Contact header field.

連絡先の述語：レジスタリクエストのコンタクトヘッダーフィールドに登録されたURIに関連付けられた機能セット述語。コンタクト述語は、コンタクトヘッダーフィールドの特徴パラメーターから導出されます。

4. Usage of the Content Negotiation Framework

4. コンテンツネゴシエーションフレームワークの使用

This specification makes heavy use of the terminology and concepts in the content negotiation work carried out within the IETF, and documented in several RFCs. The ones relevant to this specification are RFC 2506 [3], which provides a template for registering media feature tags, RFC 2533 [4], which presents a syntax and matching algorithm for media feature sets, RFC 2738 [5], which provides a minor update to RFC 2533, and RFC 2703 [17], which provides a general framework for content negotiation.

この仕様により、IETF内で実施され、いくつかのRFCで文書化されたコンテンツ交渉作業の用語と概念を豊富に使用します。この仕様に関連するものはRFC 2506 [3]です。RFC2506[3]は、メディア機能タグを登録するためのテンプレートであるRFC 2533 [4]です。これは、メディア機能セットの構文と一致するアルゴリズム、RFC 2738 [5]を提示します。RFC 2533およびRFC 2703 [17]のマイナーアップデートは、コンテンツネゴシエーションの一般的なフレームワークを提供します。

In case the reader does not have the time to read those specifications, Appendix A provides a brief overview of the concepts and terminology in those documents that is critical for understanding this specification.

読者がそれらの仕様を読む時間がない場合、付録Aは、この仕様を理解するために重要なドキュメントの概念と用語の簡単な概要を提供します。

Since the content negotiation work was primarily meant to apply to documents or other resources with a set of possible renderings, it is not immediately apparent how it is used to model SIP user agents. A feature set is composed of a set of feature collections, each of which represents a specific rendering supported by the entity described by the feature set. In the context of a SIP user agent, a feature collection represents an instantaneous modality. That is, if you look at the run time processing of a SIP UA and take a snapshot in time, the feature collection describes what it is doing at that very instant.

コンテンツネゴシエーション作業は主に、可能なレンダリングのセットを備えたドキュメントやその他のリソースに適用することを意図していたため、SIPユーザーエージェントのモデル化に使用する方法はすぐにはわかりません。機能セットは、一連の機能コレクションで構成されており、それぞれが機能セットで説明されているエンティティによってサポートされる特定のレンダリングを表します。SIPユーザーエージェントのコンテキストでは、機能コレクションは瞬間的なモダリティを表します。つまり、SIP UAの実行時間処理を見て、時間内にスナップショットを取ると、機能コレクションはその瞬間に何をしているかを説明します。

This model is important, since it provides guidance on how to determine whether something is a value for a particular feature tag, or a feature tag by itself. If two properties can be exhibited by a UA simultaneously so that both are present in an instantaneous modality, they need to be represented by separate media feature tags. For example, a UA may be able to support some number of media types - audio, video, and control. Should each of these be different values for a single "media-types" feature tag, or should each of them be a separate boolean feature tag? The model provides the answer. Since, at any instance in time, a UA could be handling both audio and video, they need to be separate media feature tags. However, the SIP methods supported by a UA can each be represented as different values for the same media feature tag (the "sip.methods" tag), because fundamentally, a UA processes a single request at a time. It may be multi-threading, so that it appears that this is not so, but at a purely functional level, it is true.

このモデルは、何かが特定の機能タグの値であるか、それ自体が機能タグであるかを判断する方法に関するガイダンスを提供するため、重要です。2つのプロパティをUAによって同時に表示できる場合、両方が瞬時に存在するようにする場合、個別のメディア機能タグで表現する必要があります。たとえば、UAは、オーディオ、ビデオ、コントロールなど、いくつかのメディアタイプをサポートできる場合があります。これらのそれぞれは、単一の「メディアタイプ」機能タグの異なる値である必要がありますか、それともそれぞれが個別のブール機能タグである必要がありますか？モデルは答えを提供します。任意の例では、UAはオーディオとビデオの両方を処理している可能性があるため、個別のメディア機能タグである必要があります。ただし、UAでサポートされるSIPメソッドは、それぞれ同じメディア機能タグ（「sip.methods」タグ）の異なる値として表現できます。これは、基本的に、UAが一度に単一のリクエストを処理するためです。それはマルチスレッドである可能性があるため、これはそうではないように見えますが、純粋に機能的なレベルでは、それは真実です。

Clearly, there are weaknesses in this model, but it serves as a useful guideline for applying the concepts of RFC 2533 to the problem at hand.

明らかに、このモデルには弱点がありますが、RFC 2533の概念を手元の問題に適用するための有用なガイドラインとして機能します。

5. Computing Capabilities

5. コンピューティング機能

To construct a set of Contact header field parameters that indicate capabilities, a UA constructs a feature predicate for that contact. This process is described in terms of RFC 2533 [4] (and its minor update, RFC 2738 [5]) syntax and constructs, followed by a conversion to the syntax used in this specification. However, this represents a logical flow of processing. There is no requirement that an implementation actually use RFC 2533 syntax as an intermediate step.

機能を示す一連のコンタクトヘッダーフィールドパラメーターを構築するために、UAはその接触の特徴を構築します。このプロセスは、RFC 2533 [4]（およびそのマイナーアップデート、RFC 2738 [5]）の構文とコンストラクトの観点から説明され、その後、この仕様で使用される構文への変換が続きます。ただし、これは処理の論理的な流れを表しています。実装が実際にRFC 2533構文を中間ステップとして使用するという要件はありません。

A UA MAY use any feature tags that are registered through IANA in the SIP tree (Established in Section 12.1), IETF, or global trees [3]; this document registers several into the SIP tree. The feature tags discussed in this specification are referred to as base tags. While other tags can be used, in order to identify them as feature parameters (as opposed to parameters for another SIP extension), they are encoded with a leading "+" sign in the Contact header field. It is also permissible to use the URI tree [3] for expressing vendor-specific feature tags. Feature tags in any other trees created through IANA MAY also be used.

UAは、SIPツリーのIANAを介して登録されている機能タグ（セクション12.1、IETF、またはグローバルツリー[3]を使用する場合があります。このドキュメントは、いくつかをSIPツリーに登録します。この仕様で説明されている機能タグは、ベースタグと呼ばれます。他のタグを使用することができますが、それらを特徴パラメーターとして識別するために（別のSIP拡張機能のパラメーターとは対照的に）、連絡先ヘッダーフィールドの主要な ""サインでエンコードされます。また、ベンダー固有の機能タグを表現するためにURIツリー[3]を使用することも許可されています。IANAを介して作成された他のツリーの機能タグも使用できます。

When using the "sip.methods" feature tag, a UA MUST NOT include values that correspond to methods not standardized in IETF standards track RFCs. When using the "sip.events" feature tag, a UA MUST NOT include values that correspond to event packages not standardized in IETF standards track RFCs. When using the "sip.schemes" feature tag, a UA MUST NOT include values that correspond to schemes not standardized in IETF standards track RFCs. When using the "sip.extensions" feature tag, a UA MUST NOT include values that correspond to option tags not standardized in IETF standards track RFCs.

「sip.methods」機能タグを使用する場合、UAには、IETF標準トラックRFCSで標準化されていないメソッドに対応する値を含めてはなりません。「sip.events」機能タグを使用する場合、UAには、IETF標準トラックRFCSに標準化されていないイベントパッケージに対応する値を含めてはなりません。「sip.schemes」機能タグを使用する場合、UAには、IETF標準トラックRFCSに標準化されていないスキームに対応する値を含めてはなりません。「sip.extensions」機能タグを使用する場合、UAには、IETF標準トラックRFCSに標準化されていないオプションタグに対応する値を含めてはなりません。

Note that the "sip.schemes" feature tag does not indicate the scheme of the registered URI. Rather, it indicates schemes that a UA is capable of sending requests to, should such a URI be received in a web page or Contact header field of a redirect response.

「Sip.schemes」機能タグは、登録されたURIのスキームを示していないことに注意してください。むしろ、そのようなURIをWebページまたはリダイレクト応答の連絡先フィールドで受け取った場合、UAがリクエストを送信できるスキームを示します。

It is RECOMMENDED that a UA provide complete information in its contact predicate. That is, it SHOULD provide information on as many feature tags as possible. The mechanisms in this specification work best when user agents register complete feature sets. Furthermore, when a UA registers values for a particular feature tag, it MUST list all values that it supports. For example, when including the "sip.methods" feature tag, a UA MUST list all methods it supports.

UAは、連絡先の述語に完全な情報を提供することをお勧めします。つまり、できるだけ多くの機能タグに関する情報を提供する必要があります。この仕様のメカニズムは、ユーザーエージェントが完全な機能セットを登録するときに最適に機能します。さらに、UAが特定の機能タグの値を登録する場合、サポートするすべての値をリストする必要があります。たとえば、「sip.methods」機能タグを含める場合、UAはサポートするすべてのメソッドをリストする必要があります。

The contact predicate constructed by a UA MUST be an AND of terms (called a conjunction). Each term is either an OR (called a disjunction) of simple filters or negations of simple filters, or a single simple filter or negation of a single filter. In the case of a disjunction, each filter in the disjunction MUST indicate feature values for the same feature tag (i.e., the disjunction represents a set of values for a particular feature tag), while each element of the conjunction MUST be for a different feature tag. Each simple filter can be an equality, or in the case of numeric feature tags, an inequality or range. If a string (as defined in RFC 2533 [4]) is used as the value of a simple filter, that value MUST NOT include the "<" or ">" characters, the simple filter MUST NOT be negated, and it MUST be the only simple filter for that particular feature tag. This contact predicate is then converted to a list of feature parameters, following the procedure outlined below.

UAによって構築された接触述語は、条件（接続詞と呼ばれる）でなければなりません。各用語は、単純なフィルターまたは単純なフィルターの否定のanまたは（分離と呼ばれる）、または単一のシンプルなフィルターまたは単一のフィルターの否定のいずれかです。分離の場合、分離の各フィルターは同じ機能タグの機能値を示す必要があります（つまり、分離は特定の機能タグの値のセットを表します）。鬼ごっこ。各単純なフィルターは、等しいものである場合、または数値機能タグの場合、不平等または範囲です。文字列（RFC 2533 [4]で定義されている）が単純なフィルターの値として使用されている場合、その値は「<」または「>」文字を含めてはなりません。単純なフィルターを無効にする必要はありません。その特定の機能タグの唯一の単純なフィルター。次に、以下に概説する手順に従って、この連絡先述語は、機能パラメーターのリストに変換されます。

The contact predicate is a conjunction of terms. Each term indicates constraints on a single feature tag, and each term is represented by a separate feature parameter that will be present in the Contact header field. The syntax of this parameter depends on the feature tag. Each forward slash in the feature tag is converted to a single quote, and each colon are converted to an exclamation point. For the base tags - that is, those feature tags documented in this specification (sip.audio, sip.automata, sip.class, sip.duplex, sip.data, sip.control, sip.mobility, sip.description, sip.events, sip.priority, sip.methods, sip.extensions, sip.schemes, sip.application, sip.video, language, type, sip.isfocus, sip.actor and sip.text), the leading "sip.", if present, is stripped. For feature tags not in this list, the leading "sip." MUST NOT be stripped if present, and indeed, a plus sign ("+") MUST be added as the first character of the Contact header field parameter. The result is the feature parameter name. As a result of these rules, the base tags appear "naked" in the Contact header field - they have neither a "+" nor a "sip." prefix. All other tags will always have a leading "+" when present in the Contact header field, and will additionally have a "sip." if the tag is in the SIP tree.

連絡先述語は、用語の接続性です。各用語は、単一の機能タグの制約を示し、各用語は、コンタクトヘッダーフィールドに存在する個別の機能パラメーターで表されます。このパラメーターの構文は、機能タグに依存します。機能タグの各フォワードスラッシュは単一の引用符に変換され、各コロンは感嘆符に変換されます。ベースタグの場合 - つまり、この仕様に文書化された機能タグ（sip.audio、sip.automata、sip.class、sip.duplex、sip.data、sip.control、sip.mobility、sip.description、sip。イベント、sip.priority、sip.methods、sip.extensions、sip.schemes、sip.application、sip.video、言語、タイプ、sip.isfocus、sip.actor and sip.text）、主要な「sip.」存在する場合は、剥がされます。このリストにない機能タグの場合、主要な「SIP」。存在する場合は剥がれないでください。実際、プラス記号（ ""）をコンタクトヘッダーフィールドパラメーターの最初の文字として追加する必要があります。結果は、機能パラメーター名です。これらのルールの結果として、ベースタグはコンタクトヘッダーフィールドに「裸」に見えます - 「 "" sipも「sip」もありません。プレフィックス。他のすべてのタグには、コンタクトヘッダーフィールドに存在する場合、常に主要な「」があり、さらに「SIP」があります。タグがSIPツリーにある場合。

The value of the feature parameter depends on the term of the conjunction. If the term is a boolean expression with a value of true, i.e., (sip.audio=TRUE), the contact parameter has no value. If the term of the conjunction is a disjunction, the value of the contact parameter is a quoted string. The quoted string is a comma separated list of strings, each one derived from one of the terms in the disjunction. If the term of the conjunction is a negation, the value of the contact parameter is a quoted string. The quoted string begins with an exclamation point (!), and the remainder is constructed from the expression being negated.

機能パラメーターの値は、接続詞の用語に依存します。用語がtrue、つまり（sip.audio = true）の値を持つブール式である場合、連絡先パラメーターには値がありません。接続詞の用語が分離の場合、連絡先パラメーターの値は引用された文字列です。引用された文字列は、分離の用語の1つから派生した文字列のコンマ分離リストです。接続詞の用語が否定である場合、連絡先パラメーターの値は引用された文字列です。引用された文字列は感嘆符（！）で始まり、残りは否定される式から構築されます。

The remaining operation is to compute a string from a primitive filter. If the filter is a simple filter that is performing a numeric comparison, the string starts with an octothorpe (#), followed by the comparator in the filter (=, >=, or <=), followed by the value from the filter. If the value from the filter is expressed in rational form (X / Y), then X and Y are divided, yielding a decimal number, and this decimal number is output to the string.

残りの操作は、プリミティブフィルターから文字列を計算することです。フィルターが数値比較を実行している単純なフィルターである場合、文字列はOctothorpe（＃）で始まり、その後フィルター（=、> =、または<=）に比較が続き、その後フィルターから値が続きます。フィルターからの値が合理的な形式（x / y）で表される場合、xとyは分割され、小数数が生成され、この小数数は文字列に出力されます。

RFC 2533 uses a fractional notation to describe rational numbers. This specification uses a decimal form. The above text merely converts between the two representations. Practically speaking, this conversion is not needed since the numbers are the same in either case. However, it is described in case implementations wish to directly plug the predicates generated by the rules in this section into an RFC 2533 implementation.

RFC 2533は、合理的な数値を記述するために分数表記を使用します。この仕様では、小数点形を使用します。上記のテキストは、単に2つの表現間を変換します。実際には、この変換はどちらの場合でも同じであるため、この変換は必要ありません。ただし、実装が、このセクションのルールによって生成された述語をRFC 2533実装に直接プラグインしたい場合に説明されています。

If the filter is a range (foo=X..Y), the string is equal to X:Y, where X and Y have been converted from fractional numbers (A / B) to their decimal equivalent.

フィルターが範囲（foo = x..y）の場合、文字列はx：yに等しくなります。ここで、xとyは分数数（a / b）から小数等価に変換されています。

If the filter is an equality over a token or boolean, then that token or boolean value ("TRUE" or "FALSE") is output to the string.

フィルターがトークンまたはブールの均等である場合、そのトークンまたはブール値（「true」または「false」）が文字列に出力されます。

If the filter is an equality over a quoted string, the output is a less than (<), followed by the quoted string, followed by a greater than (>).

フィルターが引用された文字列上の等式である場合、出力は（<）未満であり、引用された文字列が続き、続いて（>）が続きます。

As an example, this feature predicate:

一例として、この機能は述べています：

   (& (sip.mobility=fixed)
      (| (! (sip.events=presence)) (sip.events=message-summary))
      (| (language=en) (language=de))
      (sip.description="PC")
      (sip.newparam=TRUE)
      (rangeparam=-4..5125/1000))

would be converted into the following feature parameters:

次の機能パラメーターに変換されます。

   mobility="fixed";events="!presence,message-summary";language="en,de"
      ;description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"

These feature tags would then appear as part of the Contact header field:

これらの機能タグは、コンタクトヘッダーフィールドの一部として表示されます。

   Contact: <sip:user@pc.example.com>
             ;mobility="fixed";events="!presence,message-summary"
             ;language="en,de";description="<PC>"
             ;+sip.newparam;+rangeparam="#-4:+5.125"

Notice how the leading "sip." was stripped from the sip.mobility, sip.events and sip.description feature tags before encoding them in the Contact header field. This is because these feature tags are amongst the base tags listed above. It is for this reason that these feature tags were not encoded with a leading "+" either. However, the sip.newparam feature tag was encoded with both the "+" and its leading "sip.", and the rangeparam was also encoded with a leading "+". This is because neither of these feature tags are defined in this specification. As such, the leading "sip." is not stripped off, and a "+" is added.

主要な「SIP」がどのようになっているかに注意してください。sip.mobility、sip.events、sip.description機能タグから剥がされてから、コンタクトヘッダーフィールドでそれらをエンコードしました。これは、これらの機能タグが上記のベースタグの1つであるためです。このため、これらの機能タグは、主要な ""でエンコードされていません。ただし、sip.newparamの機能タグは、「」とその主要な「sip」の両方でエンコードされており、レンジパラムも主要な「」でエンコードされました。これは、これらの機能タグのいずれもこの仕様で定義されていないためです。そのため、主要な「SIP」。剥奪されず、「」が追加されます。

6. Expressing Capabilities in a Registration

6. 登録で機能を表現します

When a UA registers, it can choose to indicate a feature set associated with a registered contact. Whether or not a UA does so depends on what the registered URI represents. If the registered URI represents a UA instance (the common case in registrations), a UA compliant to this specification SHOULD indicate a feature set using the mechanisms described here. If, however, the registered URI represents an address-of-record, or some other resource that is not representable by a single feature set, it SHOULD NOT include a feature set. As an example, if a user wishes to forward calls from sip:user1@example.com to sip:user2@example.org, it could generate a registration that looks like, in part:

UAが登録すると、登録された連絡先に関連付けられた機能セットを示すことを選択できます。UAがそうするかどうかは、登録されたURIが何を表すかによって異なります。登録されたURIがUAインスタンス（登録の一般的なケース）を表す場合、この仕様に準拠したUAは、ここで説明するメカニズムを使用して機能セットを示す必要があります。ただし、登録されたURIが、単一の機能セットで表現できない他のリソースを表している場合、機能セットを含めるべきではありません。例として、ユーザーがsip：user1@example.comからsip：user2@example.orgに電話を転送したい場合、部分的には次のように見える登録を生成できます。

   REGISTER sip:example.com SIP/2.0
   To: sip:user1@example.com
   Contact: sip:user2@example.org

In this case, the registered contact is not identifying a UA, but rather, another address-of-record. In such a case, the registered contact would not indicate a feature set.

この場合、登録された連絡先はUAを識別するのではなく、別の記録アドレスを識別しています。そのような場合、登録された連絡先は機能セットを示しません。

However, in some cases, a UA may wish to express feature parameters for an address-of-record. One example is an AOR which represents a multiplicity of devices in a home network, and routes to a proxy server in the user's home. Since all devices in the home are for personal use, the AOR itself can be described with the ;class="personal" feature parameter. A registration that forwards calls to this home AOR could make use of that feature parameter. Generally speaking, a feature parameter can only be associated with an address-of-record if all devices bound to that address-of-record share the exact same set of values for that feature parameter.

ただし、場合によっては、UAは、レコードアドレスの機能パラメーターを表現したい場合があります。1つの例は、ホームネットワーク内の多数のデバイスを表すAORと、ユーザーの自宅のプロキシサーバーへのルーティングです。家庭内のすべてのデバイスは個人的な使用のためであるため、AOR自体は; class = "personal"機能パラメーターで説明できます。このホームAORへの呼び出しを転送する登録は、その機能パラメーターを使用する可能性があります。一般的に、機能パラメーターは、そのアドレスに縛られたすべてのデバイスがその機能パラメーターの値のまったく同じセットを共有している場合にのみ、レコードアドレスに関連付けます。

Similarly, in some cases, a UA can exhibit one characteristic or another, but the characteristic is not known in advance. For example, a UA could represent a device that is a phone with an embedded answering machine. The ideal way to treat such devices is to model them as if they were actually a proxy fronting two devices - a phone (which is never an answering machine), and an answering machine (which is never a phone). The registration from this device would be constructed as if it were an AOR, as per the procedures above. Generally, this means that, unless the characteristic is identical between the logical devices, that characteristic will not be present in any registration generated by the actual device.

同様に、場合によっては、UAは1つの特性を示すことができますが、特性は事前に知られていません。たとえば、UAは、埋め込まれた留守番電話を備えた携帯電話であるデバイスを表すことができます。そのようなデバイスを処理する理想的な方法は、それらが実際に2つのデバイスに面したプロキシであるかのようにモデル化することです - 電話（これは留守番電話ではない）と留守番電話（これは決して電話ではありません）です。このデバイスからの登録は、上記の手順に従って、AORであるかのように構築されます。一般に、これは、論理デバイス間で特性が同一でない限り、その特性が実際のデバイスによって生成された登録に存在しないことを意味します。

The remainder of this section assumes that a UA would like to associate a feature set with a contact that it is registering. This feature set is constructed and converted to a series of Contact header field parameters, as described in Section 5, and those feature parameters are added to the Contact header field value containing the URI to which the parameters apply. The Allow, Accept, Accept-Language and Allow-Events [9] header fields are allowed in REGISTER requests, and also indicate capabilities. However, their semantic in REGISTER is different, indicating capabilities, used by the registrar, for generation of the response. As such, they are not a substitute or an alternate for the Contact feature parameters, which indicate the capabilities of the UA generally speaking.

このセクションの残りの部分では、UAが登録している機能セットを連絡先に関連付けることを想定しています。この機能セットは構築され、セクション5で説明されている一連のコンタクトヘッダーフィールドパラメーターに変換され、それらの機能パラメーターは、パラメーターが適用されるURIを含む接点ヘッダーフィールド値に追加されます。許可、受け入れ、承認、および許可イベント[9]ヘッダーフィールドは、レジスタリクエストで許可されており、能力も示しています。ただし、レジスタでのセマンティックは異なるため、レジストラが使用する能力が応答の生成に使用されます。そのため、それらは一般的に言えば、UAの機能を示す接触特徴パラメーターの代替または代替ではありません。

The REGISTER request MAY contain a Require header field with the value "pref" if the client wants to be sure that the registrar understands the extensions defined in this specification. This means that the registrar will store the feature parameters, and make them available to elements accessing the location service within the domain. In the absence of the Require header field, a registrar that does not understand this extension will simply ignore the Contact header field parameters.

レジスタリクエストには、クライアントがこの仕様で定義されている拡張機能を登録官が理解していることをクライアントが確認したい場合、値「pref」の要求ヘッダーフィールドを含めることができます。これは、レジストラが機能パラメーターを保存し、ドメイン内のロケーションサービスにアクセスする要素に使用できるようにすることを意味します。要求ヘッダーフィールドがない場合、この拡張機能を理解していないレジストラは、単に連絡先ヘッダーフィールドパラメーターを無視します。

If a UA registers against multiple separate addresses-of-record, and the contacts registered for each have different capabilities, a UA MUST use different URIs in each registration. This allows the UA to uniquely determine the feature set that is associated with the request URI of an incoming request.

UAが複数の個別のアドレスアドレスに対して登録され、それぞれに登録されている連絡先に異なる機能が異なる場合、UAは各登録で異なるURIを使用する必要があります。これにより、UAは、着信要求のリクエストURIに関連付けられている機能セットを一意に決定できます。

As an example, a voicemail server that is a UA that supports audio and video media types and is not mobile would construct a feature predicate like this:

例として、オーディオおよびビデオメディアの種類をサポートし、モバイルではないUAであるボイスメールサーバーは、次のような機能を構築します。

   (& (sip.audio=TRUE)
      (sip.video=TRUE)
      (sip.actor=msg-taker)
      (sip.automata=TRUE)
      (sip.mobility=fixed)
      (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
         (sip.methods=ACK) (sip.methods=CANCEL)))

These would be converted into feature parameters and included in the REGISTER request:

これらは機能パラメーターに変換され、レジスタリクエストに含まれます。

   REGISTER sip:example.com SIP/2.0
   From: sip:user@example.com;tag=asd98
   To: sip:user@example.com
   Call-ID: hh89as0d-asd88jkk@host.example.com
   CSeq: 9987 REGISTER
   Max-Forwards: 70
   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
   Contact: <sip:user@host.example.com>;audio;video
     ;actor="msg-taker";automata;mobility="fixed"
     ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
   Content-Length: 0

Note that a voicemail server is usually an automata and a message taker.

ボイスメールサーバーは通常、オートマトンとメッセージテイカーであることに注意してください。

When a UAC refreshes its registration, it MUST include its feature parameters in that refresh if it wishes for them to remain active. Furthermore, when a registrar returns a 200 OK response to a REGISTER request, each Contact header field value MUST include all of the feature parameters associated with that URI.

UACが登録を再表示する場合、アクティブのままにしたい場合は、その更新に機能パラメーターを含める必要があります。さらに、レジストラがレジスタリクエストに200 OK応答を返す場合、各連絡先ヘッダーフィールド値には、そのURIに関連付けられたすべての機能パラメーターを含める必要があります。

7. Indicating Feature Sets in Remote Target URIs

7. リモートターゲットURIの機能セットを示す

Target refresh requests and responses are used to establish and modify the remote target URI in a dialog. The remote target URI is conveyed in the Contact header field. A UAC or UAS MAY add feature parameters to the Contact header field value in target refresh requests and responses for the purpose of indicating the capabilities of the UA. To do that, it constructs a set of feature parameters according to Section 5. These are then added as Contact header field parameters in the request or response.

ターゲットの更新リクエストと応答は、ダイアログ内のリモートターゲットURIを確立および変更するために使用されます。リモートターゲットURIは、コンタクトヘッダーフィールドに伝えられます。UACまたはUASは、UAの機能を示す目的で、ターゲット更新リクエストと応答のコンタクトヘッダーフィールド値に特徴パラメーターを追加する場合があります。そのために、セクション5に従って一連の機能パラメーターを構築します。これらは、リクエストまたは応答の接触ヘッダーフィールドパラメーターとして追加されます。

The feature parameters can be included in both initial requests and mid-dialog requests, and MAY change mid-dialog to signal a change in UA capabilities.

機能パラメーターは、初期リクエストとMid-Dialogリクエストの両方に含めることができ、Mid-Dialogを変更してUA機能の変更を示す場合があります。

There is overlap in the callee capabilities mechanism with the Allow, Accept, Accept-Language, and Allow-Events [9] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and "sip.methods" feature tag indicate the same information. The Accept header field and the "type" feature tag indicate the same information. The Accept-Language header field and the "language" feature tag indicate the same information. The Allow-Events header field and the "sip.events" feature tag indicate the same information. It is possible that other header fields and feature tags defined in the future may also overlap. When there exists a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. A UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag.

Callee機能メカニズムには、Allow、Accept、Accept-Language、およびAllow-Ievents [9]ヘッダーフィールドと重複しています。これは、ターゲット更新リクエストでも使用できます。具体的には、許容ヘッダーフィールドと「sip.methods」機能タグは、同じ情報を示しています。Accept Headerフィールドと「タイプ」機能タグは、同じ情報を示しています。Accept-Language Headerフィールドと「言語」機能タグは、同じ情報を示しています。Allow-Eventsヘッダーフィールドと「SIP.Events」機能タグは、同じ情報を示しています。将来定義されている他のヘッダーフィールドと機能タグも重複する可能性があります。SIPヘッダーフィールドで表現できる機能を記述する機能タグが存在する場合、UAはヘッダーフィールドを使用して機能を説明する必要があります。ヘッダーフィールドと機能タグの両方を含むメッセージを受信するUAは、機能タグではなくヘッダーフィールドを使用する必要があります。

8. OPTIONS Processing

8. オプション処理

When a UAS compliant to this specification receives an OPTIONS request, it MAY add feature parameters to the Contact header field in the OPTIONS response for the purpose of indicating the capabilities of the UA. To do that, it constructs a set of feature parameters according to Section 5. These are then added as Contact header field parameters in OPTIONS response. Indeed, if feature parameters were included in the registration generated by that UA, those same parameters SHOULD be used in the OPTIONS response.

この仕様に準拠しているUASがオプションリクエストを受信すると、UAの機能を示す目的で、オプション応答に連絡先ヘッダーフィールドに特徴パラメーターを追加する場合があります。そのために、セクション5に従って一連の機能パラメーターを構築します。これらは、オプション応答の接触ヘッダーフィールドパラメーターとして追加されます。実際、そのUAによって生成された登録に特徴パラメーターが含まれている場合、それらの同じパラメーターをオプション応答で使用する必要があります。

The guidelines in Section 7 regarding the overlap of the various callee capabilities feature tags with SIP header fields applies to the generation of OPTIONS responses as well. In particular, they apply when a Contact header field is describing the UA which generated the OPTIONS response. When a Contact header field in the OPTIONS response is identifying a different UA, there is no overlap.

さまざまなCallee機能のオーバーラップに関するセクション7のガイドラインは、SIPヘッダーフィールドを備えたタグがオプション応答の生成にも適用されます。特に、コンタクトヘッダーフィールドがオプション応答を生成したUAを説明している場合に適用されます。オプション応答のコンタクトヘッダーフィールドが異なるUAを識別している場合、オーバーラップはありません。

9. Contact Header Field

9. ヘッダーフィールドにお問い合わせください

This specification extends the Contact header field. In particular, it allows for the Contact header field parameters to include feature-param. Feature-param is a feature parameter that describes a feature of the UA associated with the URI in the Contact header field. Feature parameters are identifiable because they either belong to the well known set of base feature tags, or they begin with a plus sign.

この仕様により、コンタクトヘッダーフィールドが拡張されます。特に、Contact-HeaderフィールドパラメーターがFeature-Paramを含むことができます。Feature-Paramは、コンタクトヘッダーフィールドのURIに関連付けられたUAの機能を説明する機能パラメーターです。機能パラメーターは、よく知られているベース機能タグに属しているか、プラス記号から始まるため、識別可能です。

   feature-param    =  enc-feature-tag [EQUAL LDQUOT (tag-value-list
                       / string-value ) RDQUOT]
   enc-feature-tag  =  base-tags / other-tags
   base-tags        =  "audio" / "automata" /
                       "class" / "duplex" / "data" /
                       "control" / "mobility" / "description" /
                       "events" / "priority" / "methods" /
                       "schemes" / "application" / "video" /
                       "language" / "type" / "isfocus" /
                       "actor" / "text" / "extensions"
   other-tags      =  "+" ftag-name
   ftag-name       =  ALPHA *( ALPHA / DIGIT / "!" / "'" /
                      "." / "-" / "%" )

   tag-value-list  =  tag-value *("," tag-value)
   tag-value       =  ["!"] (token-nobang / boolean / numeric)
   token-nobang    =  1*(alphanum / "-" / "." / "%" / "*"
                      / "_" / "+" / "`" / "'" / "~" )
   boolean         =  "TRUE" / "FALSE"
   numeric         =  "#" numeric-relation number
   numeric-relation  =  ">=" / "<=" / "=" / (number ":")
   number          =  [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
   string-value    =  "<" *(qdtext-no-abkt / quoted-pair ) ">"
   qdtext-no-abkt  =  LWS / %x21 / %x23-3B / %x3D
                           / %x3F-5B / %x5D-7E / UTF8-NONASCII

Note that the tag-value-list uses an actual comma instead of the COMMA construction because it appears within a quoted string, where line folding cannot take place.

Tag-Value-Listは、線の折りたたみが行われない引用文字列内に表示されるため、コンマ構造の代わりに実際のコンマを使用することに注意してください。

The production for qdtext can be found in RFC 3261 [1].

QDTextの生産は、RFC 3261 [1]にあります。

There are additional constraints on the usage of feature-param that cannot be represented in a BNF. There MUST only be one instance of any feature tag in feature-param. Any numbers present in a feature parameter MUST be representable using an ANSI C double.

BNFで表現できない機能パラムの使用には、追加の制約があります。Feature-Paramには、機能タグのインスタンスが1つしかない必要があります。機能パラメーターに存在する数字は、ANSI Cダブルを使用して表現できる必要があります。

The following production updates the one in RFC 3261 [1] for contact-params:

次の制作では、コンタクトパラムのRFC 3261 [1]のプロダクションが更新されます。

   contact-params    =  c-p-q / c-p-expires / feature-param
                        / contact-extension

10. Media Feature Tag Definitions

10. メディア機能タグ定義

This specification defines an initial set of media feature tags for use with this specification. This section serves as the IANA registration for these feature tags, which are made into the SIP media feature tag tree. New media feature tags are registered in the IETF or global trees based on the process defined for feature tag registrations [3], or in the SIP tree based on the process defined in Section 12.1.

この仕様では、この仕様で使用するメディア機能タグの初期セットを定義します。このセクションでは、これらの機能タグのIANA登録として機能し、SIPメディア機能タグツリーに作成されます。新しいメディア機能タグは、機能タグ登録[3]で定義されたプロセスに基づいて、IETFまたはグローバルツリーに登録されています。

Any registered feature tags MAY be used with this specification. However, several existing ones appear to be particularly applicable. These include the language feature tag [6], which can be used to specify the language of the human or automata represented by the UA, and the type feature tag [7], which can be used to specify the MIME types that a SIP UA can receive in a SIP message. The audio, video, application, data, and control feature tags in the SIP tree (each of which indicate a media type, as defined in RFC 2327 [8]) are different. They do not indicate top level MIME types which can be received in SIP requests. Rather, they indicate media types that can be used in media streams, and as a result, match up with the types defined in RFC 2327 [8].

登録された機能タグは、この仕様で使用できます。ただし、いくつかの既存のものは特に適用可能であるように見えます。これらには、UAで表される人間またはオートマトンの言語を指定するために使用できる言語機能タグ[6]と、sip UAであるMIMEタイプを指定するために使用できるタイプ機能タグ[7]が含まれます。SIPメッセージで受信できます。SIPツリーのオーディオ、ビデオ、アプリケーション、データ、および制御機能タグ（RFC 2327 [8]で定義されているメディアタイプを示しています）は異なります。SIPリクエストで受信できるトップレベルのMIMEタイプを示していません。むしろ、メディアストリームで使用できるメディアタイプを示し、その結果、RFC 2327 [8]で定義されたタイプと一致します。

If a new SDP media type were to be defined, such as "message", a new feature tag registration SHOULD be created for it in the SIP tree. The name of the feature tag MUST equal "sip." concatenated with the name of the media type, unless there is an unlikely naming collision between the new media type and an existing feature tag registration. As a result, implementations can safely construct caller preferences and callee capabilities for the new media type before it is registered, as long as there is no naming conflict.

「メッセージ」などの新しいSDPメディアタイプを定義する場合、SIPツリーに新しい機能タグ登録を作成する必要があります。機能タグの名前は「SIP」に等しくなければなりません。新しいメディアタイプと既存の機能タグ登録との間に命名の可能性が低い場合を除き、メディアタイプの名前と連結されています。その結果、実装は、登録する前に、新しいメディアタイプの発信者の好みとCallee機能を安全に構築できます。

If a new media feature tag is registered with the intent of using that tag with this specification, the registration is done for the unencoded form of the tag (see Section 5). In other words, if a new feature tag "foo" is registered in the IETF tree, the IANA registration would be for the tag "foo" and not "+foo". Similarly, if a new feature tag "sip.gruu" is registered in the SIP tree, the IANA registration would be for the tag "sip.gruu" and not "+sip.gruu" or "gruu". As such, all registrations into the SIP tree will have the "sip." prefix.

新しいメディア機能タグがこの仕様でそのタグを使用する意図で登録されている場合、登録はタグの非エンエンコード形式に対して行われます（セクション5を参照）。言い換えれば、新機能タグ「Foo」がIETFツリーに登録されている場合、IANA登録は「Foo」ではなくタグ「Foo」のものになります。同様に、新機能タグ「sip.gruu」がSIPツリーに登録されている場合、IANA登録は「sip.gruu」または「gruu」ではなくタグ「sip.gruu」のものになります。そのため、SIPツリーへのすべての登録には「SIP」があります。プレフィックス。

The feature tags in this section are all registered in the SIP media feature tag tree created by Section 12.1.

このセクションの機能タグはすべて、セクション12.1によって作成されたSIPメディア機能タグツリーに登録されています。

10.1. Audio

10.1. オーディオ

Media feature tag name: sip.audio

メディア機能タグ名：sip.audio

ASN.1 Identifier: 1.3.6.1.8.4.1

ASN.1識別子：1.3.6.1.8.4.1

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports audio as a streaming media type.

このタグで示されるメディア機能の概要：この機能タグは、デバイスがストリーミングメディアタイプとしてオーディオをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.

機能タグは、主に以下のアプリケーション、プロトコル、サービス、またはネゴシエーションメカニズムで使用するためのものです。この機能タグは、電話やPDAなどのデバイスの機能を説明するための通信アプリケーションで最も役立ちます。

Examples of typical use: Routing a call to a phone that can support audio.

典型的な使用の例：音声をサポートできる電話に通話をルーティングします。

Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

関連標準またはドキュメント：RFC 3840セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項は、RFC 3840のセクション11.1で説明されています。

10.2. Application

10.2. 応用

Media feature tag name: sip.application

メディア機能タグ名：sip.application

ASN.1 Identifier: 1.3.6.1.8.4.2

ASN.1識別子：1.3.6.1.8.4.2

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports application as a streaming media type. This feature tag exists primarily for completeness. Since so many MIME types are underneath application, indicating the ability to support applications provides little useful information.

このタグで示されるメディア機能の概要：この機能タグは、デバイスがストリーミングメディアタイプとしてアプリケーションをサポートしていることを示しています。この機能タグは、主に完全性のために存在します。非常に多くのMIMEタイプがアプリケーションの下にあるため、アプリケーションをサポートする能力がほとんど有用な情報を提供しないことを示しています。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.

機能タグは、主に以下のアプリケーション、プロトコル、サービス、またはネゴシエーションメカニズムで使用するためのものです。この機能タグは、電話やPDAなどのデバイスの機能を説明するために、通信アプリケーションで最も役立ちます。

Examples of typical use: Routing a call to a phone that can support a media control application.

典型的な使用の例：メディア制御アプリケーションをサポートできる電話への呼び出しをルーティングします。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.3. Data

10.3. データ

Media feature tag name: sip.data

メディア機能タグ名：sip.data

ASN.1 Identifier: 1.3.6.1.8.4.3

ASN.1識別子：1.3.6.1.8.4.3

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports data as a streaming media type.

このタグで示されるメディア機能の概要：この機能タグは、デバイスがストリーミングメディアタイプとしてデータをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

Examples of typical use: Routing a call to a phone that can support a data streaming application.

典型的な使用の例：データストリーミングアプリケーションをサポートできる電話に通話をルーティングします。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.4. Control

10.4. コントロール

Media feature tag name: sip.control

メディア機能タグ名：sip.control

ASN.1 Identifier: 1.3.6.1.8.4.4

ASN.1識別子：1.3.6.1.8.4.4

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports control as a streaming media type.

このタグで示されるメディア機能の概要：この機能タグは、デバイスがストリーミングメディアタイプとしてコントロールをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

Examples of typical use: Routing a call to a phone that can support a floor control application.

典型的な使用の例：フロアコントロールアプリケーションをサポートできる電話に通話をルーティングします。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.5. Video

10.5. ビデオ

Media feature tag name: sip.video

メディア機能タグ名：sip.video

ASN.1 Identifier: 1.3.6.1.8.4.5

ASN.1識別子：1.3.6.1.8.4.5

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports video as a streaming media type.

このタグで示されるメディア機能の概要：この機能タグは、デバイスがストリーミングメディアタイプとしてビデオをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

Examples of typical use: Routing a call to a phone that can support video.

典型的な使用の例：ビデオをサポートできる電話に通話をルーティングします。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.6. Text

10.6. 文章

Media feature tag name: sip.text

メディア機能タグ名：sip.text

ASN.1 Identifier: 1.3.6.1.8.4.6

ASN.1識別子：1.3.6.1.8.4.6

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports text as a streaming media type.

このタグで示されるメディア機能の概要：この機能タグは、デバイスがストリーミングメディアタイプとしてテキストをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

Examples of typical use: Routing a call to a phone that can support text.

典型的な使用の例：テキストをサポートできる電話に通話をルーティングします。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.7. Automata

10.7. オートマトン

Media feature tag name: sip.automata

メディア機能タグ名：sip.automata

ASN.1 Identifier: 1.3.6.1.8.4.7

ASN.1識別子：1.3.6.1.8.4.7

Summary of the media feature indicated by this tag: The sip.automata feature tag is a boolean value that indicates whether the UA represents an automata (such as a voicemail server, conference server, IVR, or recording device) or a human.

このタグで示されるメディア機能の概要：sip.automata機能タグは、UAがオートマトン（ボイスメールサーバー、会議サーバー、IVR、または録音デバイスなど）を表すかどうかを示すブール値です。

Values appropriate for use with this feature tag: Boolean. TRUE indicates that the UA represents an automata.

この機能タグで使用するのに適した値：boolean。TRUEは、UAがオートマトンを表していることを示しています。

Examples of typical use: Refusing to communicate with an automata when it is known that automated services are unacceptable.

典型的な使用の例：自動化されたサービスが受け入れられないことが知られている場合、オートマトンとの通信を拒否します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.8. Class

10.8. クラス

Media feature tag name: sip.class

メディア機能タグ名：sip.class

ASN.1 Identifier: 1.3.6.1.8.4.8

ASN.1識別子：1.3.6.1.8.4.8

Summary of the media feature indicated by this tag: This feature tag indicates the setting, business or personal, in which a communications device is used.

このタグで示されるメディア機能の概要：この機能タグは、通信デバイスが使用されるビジネスまたは個人の設定を示しています。

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

この機能タグで使用するのに適した値：平等関係を持つトークン。典型的な値は次のとおりです。

business: The device is used for business communications.

ビジネス：デバイスはビジネスコミュニケーションに使用されます。

personal: The device is used for personal communications.

個人：デバイスは個人的なコミュニケーションに使用されます。

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.

Examples of typical use: Choosing between a business phone and a home phone.

典型的な使用の例：ビジネス電話と自宅の電話の選択。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.9. Duplex

10.9. 二重

Media feature tag name: sip.duplex

メディア機能タグ名：sip.duplex

ASN.1 Identifier: 1.3.6.1.8.4.9

ASN.1識別子：1.3.6.1.8.4.9

Summary of the media feature indicated by this tag: The sip.duplex media feature tag indicates whether a communications device can simultaneously send and receive media ("full"), alternate between sending and receiving ("half"), can only receive ("receive-only") or only send ("send-only").

このタグで示されるメディア機能の概要：sip.duplexメディア機能タグは、通信デバイスが同時にメディア（「フル」）を送信および受信できるかどうかを示します。受信のみ "）または送信のみ（" send-only "）。

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

この機能タグで使用するのに適した値：平等関係を持つトークン。典型的な値は次のとおりです。

full: The device can simultaneously send and receive media.

完全：デバイスは同時にメディアを送信および受信できます。

half: The device can alternate between sending and receiving media.

半分：デバイスは、メディアの送信と受信を交互に行うことができます。

receive-only: The device can only receive media.

受信のみ：デバイスはメディアのみを受信できます。

send-only: The device can only send media.

送信専用：デバイスはメディアのみを送信できます。

Examples of typical use: Choosing to communicate with a broadcast server, as opposed to a regular phone, when making a call to hear an announcement.

典型的な使用の例：発表を聞くために電話をかけるときに、通常の電話とは対照的に、ブロードキャストサーバーと通信することを選択します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.10. Mobility

10.10. 可動性

Media feature tag name: sip.mobility

メディア機能タグ名：sip.mobility

ASN.1 Identifier: 1.3.6.1.8.4.10

ASN.1識別子：1.3.6.1.8.4.10

Summary of the media feature indicated by this tag: The sip.mobility feature tag indicates whether the device is fixed (meaning that it is associated with a fixed point of contact with the network), or mobile (meaning that it is not associated with a fixed point of contact). Note that cordless phones are fixed, not mobile, based on this definition.

このタグで示されたメディア機能の概要：sip.mobility機能タグは、デバイスが固定されているか（ネットワークとの固定点に関連付けられていることを意味します）、またはモバイル（つまり、それはAに関連付けられていないことを意味します。固定点の連絡先）。この定義に基づいて、コードレス電話はモバイルではなく固定されていることに注意してください。

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

この機能タグで使用するのに適した値：平等関係を持つトークン。典型的な値は次のとおりです。

fixed: The device is stationary.

修正：デバイスは静止しています。

mobile: The device can move around with the user.

モバイル：デバイスはユーザーと一緒に移動できます。

Examples of typical use: Choosing to communicate with a wireless phone instead of a desktop phone.

典型的な使用の例：デスクトップ電話の代わりにワイヤレス電話と通信することを選択します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.11. Description

10.11. 説明

Media feature tag name: sip.description

メディア機能タグ名：sip.description

ASN.1 Identifier: 1.3.6.1.8.4.11

ASN.1識別子：1.3.6.1.8.4.11

Summary of the media feature indicated by this tag: The sip.description feature tag provides a textual description of the device.

このタグで示されるメディア機能の概要：sip.description機能タグは、デバイスのテキストの説明を提供します。

Values appropriate for use with this feature tag: String with an equality relationship.

この機能タグで使用するのに適した値：等式関係を持つ文字列。

Examples of typical use: Indicating that a device is of a certain make and model.

典型的な使用の例：デバイスが特定のメーカーとモデルのものであることを示します。

Related standards or documents: RFC 3840 Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

10.12. Event Packages

10.12. イベントパッケージ

Media feature tag name: sip.events

メディア機能タグ名：sip.events

ASN.1 Identifier: 1.3.6.1.8.4.12

ASN.1識別子：1.3.6.1.8.4.12

Summary of the media feature indicated by this tag: Each value of the sip.events (note the plurality) feature tag indicates a SIP event package [9] supported by a SIP UA. The values for this tag equal the event package names that are registered by each event package.

このタグで示されるメディア機能の概要：sip.eventsの各値（複数の注）機能タグは、SIP UAでサポートされるSIPイベントパッケージ[9]を示しています。このタグの値は、各イベントパッケージによって登録されているイベントパッケージ名に等しくなります。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the IANA SIP Event types namespace registry.

この機能タグで使用するのに適した値：平等関係を持つトークン。値は、IANA SIPイベントタイプの名前空間レジストリから取得されます。

Examples of typical use: Choosing to communicate with a server that supports the message waiting event package, such as a voicemail server [12].

典型的な使用の例：ボイスメールサーバーなどのメッセージ待機イベントパッケージをサポートするサーバーと通信することを選択します[12]。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.13. Priority

10.13. 優先度

Media feature tag name: sip.priority

メディア機能タグ名：sip.priority

ASN.1 Identifier: 1.3.6.1.8.4.13

ASN.1識別子：1.3.6.1.8.4.13

Summary of the media feature indicated by this tag: The sip.priority feature tag indicates the call priorities the device is willing to handle. A value of X means that the device is willing to take requests with priority X and higher. This does not imply that a phone has to reject calls of lower priority. As always, the decision on handling of such calls is a matter of local policy.

このタグで示されるメディア機能の概要：sip.priority機能タグは、デバイスが喜んで処理するコール優先順位を示しています。Xの値は、デバイスが優先X以上のリクエストを喜んで取ることを意味します。これは、電話が優先度の低い呼び出しを拒否しなければならないことを意味するものではありません。いつものように、そのような呼び出しの処理に関する決定は、現地のポリシーの問題です。

Values appropriate for use with this feature tag: An integer. Each integral value corresponds to one of the possible values of the Priority header field as specified in SIP [1]. The mapping is defined as:

この機能タグ：整数で使用するのに適した値。各積分値は、SIPで指定されているように、優先ヘッダーフィールドの可能な値の1つに対応します[1]。マッピングは次のように定義されます。

non-urgent: Integral value of 10. The device supports non-urgent calls.

非緊急：10の積分値。デバイスは非緊急コールをサポートします。

normal: Integral value of 20. The device supports normal calls.

通常：20の積分値。デバイスは通常の呼び出しをサポートします。

urgent: Integral value of 30. The device supports urgent calls.

緊急：30の統合値。デバイスは緊急の呼び出しをサポートします。

emergency: Integral value of 40. The device supports calls in the case of an emergency situation.

緊急事態：40の積分値。このデバイスは、緊急事態の場合の呼び出しをサポートします。

Examples of typical use: Choosing to communicate with the emergency cell phone of a user.

典型的な使用の例：ユーザーの緊急携帯電話と通信することを選択します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.14. Methods

10.14. 方法

Media feature tag name: sip.methods

メディア機能タグ名：sip.methods

ASN.1 Identifier: 1.3.6.1.8.4.14

ASN.1識別子：1.3.6.1.8.4.14

Summary of the media feature indicated by this tag: Each value of the sip.methods (note the plurality) feature tag indicates a SIP method supported by this UA. In this case, "supported" means that the UA can receive requests with this method. In that sense, it has the same connotation as the Allow header field.

このタグで示されるメディア機能の概要：sip.methods（注）機能タグの各値は、このUAでサポートされているSIPメソッドを示しています。この場合、「サポート」とは、UAがこの方法でリクエストを受信できることを意味します。その意味で、それは許容ヘッダーフィールドと同じ意味合いを持っています。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the Methods table defined in the IANA SIP parameters registry.

この機能タグで使用するのに適した値：平等関係を持つトークン。値は、IANA SIPパラメータレジストリで定義されたメソッドテーブルから取得されます。

Examples of typical use: Choosing to communicate with a presence application on a PC, instead of a PC phone application.

典型的な使用の例：PCの電話アプリケーションではなく、PC上のプレゼンスアプリケーションと通信することを選択します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.15. Extensions

10.15. 拡張機能

Media feature tag name: sip.extensions

メディア機能タグ名：sip.extensions

ASN.1 Identifier: 1.3.6.1.8.4.15

ASN.1識別子：1.3.6.1.8.4.15

Summary of the media feature indicated by this tag: Each value of the sip.extensions feature tag (note the plurality) is a SIP extension (each of which is defined by an option-tag registered with IANA) that is understood by the UA. Understood, in this context, means that the option tag would be included in a Supported header field in a request.

このタグで示されるメディア機能の概要：sip.extensions機能タグの各値（複数に注意）は、sip拡張機能（それぞれがianaに登録されたオプションタグによって定義されます）がUAによって理解されます。このコンテキストでは、オプションタグがリクエストでサポートされているヘッダーフィールドに含まれることを理解しています。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the option tags table in the IANA SIP parameters registry.

この機能タグで使用するのに適した値：平等関係を持つトークン。値は、IANA SIPパラメータレジストリのオプションタグテーブルから取得されます。

Examples of typical use: Choosing to communicate with a phone that supports quality of service preconditions instead of one that does not.

典型的な使用の例：そうではないものではなく、サービス品質の前提条件をサポートする電話と通信することを選択します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.16. Schemes

10.16. スキーム

Media feature tag name: sip.schemes

メディア機能タグ名：sip.schemes

ASN.1 Identifier: 1.3.6.1.8.4.16

ASN.1識別子：1.3.6.1.8.4.16

Summary of the media feature indicated by this tag: Each value of the sip.schemes (note the plurality) media feature tag indicates a URI scheme [10] that is supported by a UA. Supported implies, for example, that the UA would know how to handle a URI of that scheme in the Contact header field of a redirect response.

このタグで示されるメディア機能の概要：sip.schemesの各値（複数性に注意）メディア機能タグは、URIスキーム[10]がUAによってサポートされていることを示しています。サポートされたことは、たとえば、UAがリダイレクト応答のコンタクトヘッダーフィールドでそのスキームのURIを処理する方法を知っていることを意味します。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the IANA URI scheme registry.

この機能タグで使用するのに適した値：平等関係を持つトークン。値は、IANA URIスキームレジストリから取得されます。

Examples of typical use: Choosing to get redirected to a phone number when a called party is busy, rather than a web page.

典型的な使用の例：電話番号にリダイレクトされることを選択すると、電話番号がWebページではなく忙しい場合。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.17. Actor

10.17. 俳優

Media feature tag name: sip.actor

メディア機能タグ名：sip.actor

ASN.1 Identifier: 1.3.6.1.8.4.17

ASN.1識別子：1.3.6.1.8.4.17

Summary of the media feature indicated by this tag: This feature tag indicates the type of entity that is available at this URI.

このタグで示されるメディア機能の概要：この機能タグは、このURIで利用可能なエンティティのタイプを示しています。

Values appropriate for use with this feature tag: Token with an equality relationship. The following values are defined:

この機能タグで使用するのに適した値：平等関係を持つトークン。次の値が定義されています。

principal: The device provides communication with the principal that is associated with the device. Often this will be a specific human being, but it can be an automata (for example, when calling a voice portal).

プリンシパル：デバイスは、デバイスに関連付けられているプリンシパルと通信を提供します。多くの場合、これは特定の人間になりますが、オートマトンになる可能性があります（たとえば、音声ポータルを呼び出すとき）。

attendant: The device provides communication with an automaton or person that will act as an intermediary in contacting the principal associated with the device, or a substitute.

アテンダント：デバイスは、デバイスに関連するプリンシパルまたは代替品に連絡する際に仲介者として機能するオートマトンまたは人との通信を提供します。

msg-taker: The device provides communication with an automaton or person that will take messages and deliver them to the principal.

MSG-Taker：デバイスは、メッセージを受け取り、プリンシパルに配信するオートマトンまたは人との通信を提供します。

information: The device provides communication with an automaton or person that will provide information about the principal.

情報：デバイスは、プリンシパルに関する情報を提供するオートマトンまたは人との通信を提供します。

Examples of typical use: Requesting that a call not be routed to voicemail.

典型的な使用の例：コールをボイスメールにルーティングしないように要求します。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

10.18. Is Focus

10.18. フォーカスです

Media feature tag name: sip.isfocus

メディア機能タグ名：sip.isfocus

ASN.1 Identifier: 1.3.6.1.8.4.18

ASN.1識別子：1.3.6.1.8.4.18

Summary of the media feature indicated by this tag: This feature tag indicates that the UA is a conference server, also known as a focus, and will mix together the media for all calls to the same URI [13].

このタグで示されるメディア機能の概要：この機能タグは、UAがフォーカスとも呼ばれる会議サーバーであり、同じURIへのすべての呼び出しに対してメディアを混合することを示しています[13]。

Values appropriate for use with this feature tag: Boolean.

この機能タグで使用するのに適した値：boolean。

Examples of typical use: Indicating to a UA that the server to which it has connected is a conference server.

典型的な使用の例：それが接続しているサーバーが会議サーバーであることをUAに示す。

Related standards or documents: RFC 3840

関連標準またはドキュメント：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティ上の考慮事項：このメディア機能タグのセキュリティ上の考慮事項については、RFC 3840のセクション11.1で説明しています。

11. Security Considerations

11. セキュリティに関する考慮事項

11.1. Considerations for Media Feature Tags

11.1. メディア機能タグの考慮事項

This section discusses security considerations for the media feature tags, including, but not limited to, this specification.

このセクションでは、この仕様を含むがこれらに限定されないメディア機能タグのセキュリティに関する考慮事項について説明します。

The media feature tags defined in Section 10 reveal sensitive information about a user or the user agent they are describing. Some of the feature tags convey capability information about the agent - for example, the media types it can support, the SIP methods it can support, and the SIP extensions it can support. This capability information might be used for industrial espionage, for example, and so its protection may be important. Other attributes, such as the mobility, priority, and isfocus attributes, reveal characteristics of the user agent. These attributes are more sensitive than the capability information. They describe the way in which a user agent is utilized by a user, and thus reveal information about user preferences and the ways in which they want calls handled. Some feature tags, such as languages, reveal information about the user themself. As a result, applications which utilize these media feature tags SHOULD provide a means for ensuring their confidentiality.

セクション10で定義されているメディア機能タグは、説明しているユーザーまたはユーザーエージェントに関する機密情報を明らかにしています。機能タグの一部は、エージェントに関する機能情報を伝えます。たとえば、サポートできるメディアタイプ、サポートできるSIPメソッド、およびサポートできるSIP拡張機能です。この機能情報は、たとえば産業用スパイに使用される可能性があるため、その保護が重要になる可能性があります。モビリティ、優先度、ISFOCUS属性などの他の属性は、ユーザーエージェントの特性を明らかにします。これらの属性は、機能情報よりも敏感です。ユーザーエージェントがユーザーによって使用される方法を説明し、ユーザーの好みと、コールを処理する方法に関する情報を明らかにします。言語などの一部の機能タグは、ユーザー自身に関する情報を明らかにします。その結果、これらのメディア機能タグを利用するアプリケーションは、機密性を確保するための手段を提供する必要があります。

The media feature tags can be used in ways which affect application behaviors. For example, the SIP caller preferences extension [11] allows for call routing decisions to be based on the values of these parameters. Therefore, if an attacker can modify the values of these feature tags, they may be able to affect the behavior of applications. As a result of this, applications which utilize these media feature tags SHOULD provide a means for ensuring their integrity. Similarly, media feature tags should only be trusted as valid when they come from the user or user agent described by those feature tags. As a result, mechanisms for conveying feature tags SHOULD provide a mechanism for guaranteeing authenticity.

メディア機能タグは、アプリケーションの動作に影響を与える方法で使用できます。たとえば、SIP発信者の設定拡張[11]により、これらのパラメーターの値に基づいて、通話ルーティングの決定が可能になります。したがって、攻撃者がこれらの機能タグの値を変更できる場合、アプリケーションの動作に影響を与える可能性があります。この結果、これらのメディア機能タグを利用するアプリケーションは、その完全性を確保するための手段を提供する必要があります。同様に、メディア機能タグは、それらの機能タグで説明されているユーザーまたはユーザーエージェントから来る場合にのみ有効であると信頼する必要があります。その結果、機能タグを伝えるためのメカニズムは、信頼性を保証するメカニズムを提供する必要があります。

11.2. Considerations for Registrations

11.2. 登録に関する考慮事項

As per the general requirements in Section 11.1, when media feature tags are carried in a registration, authenticity, confidentiality, and integrity need to be provided. To accomplish this, registrations containing capability information SHOULD be made by addressing the registration to a SIPS URI (in other words, the Request URI of the request would be sips:example.com when creating a registration in the example.com domain). Furthermore, the registrar SHOULD challenge the UA using digest over TLS, to verify its authenticity. The combination of TLS and digest provide integrity, confidentiality, and authenticity, as required.

セクション11.1の一般的な要件によると、メディア機能タグが登録に掲載されている場合、信頼性、機密性、および整合性を提供する必要があります。これを達成するには、登録を含む登録をSIPS URIに登録することで行う必要があります（言い換えれば、リクエストのリクエストはsips：Example.comのembly.comドメインで登録を作成するとき）。さらに、レジストラは、TLSを介したダイジェストを使用してUAに挑戦して、その信頼性を確認する必要があります。TLSとダイジェストの組み合わせは、必要に応じて完全性、機密性、および信頼性を提供します。

It is not necessary for the Contact in the registration to itself contain a sips URI, since the feature tags are not carried in incoming requests sent to the UA.

登録の連絡先自体がSIPS URIを含む必要はありません。これは、UAに送信された着信リクエストで機能タグが携帯されていないためです。

11.3. Considerations for OPTIONS Responses

11.3. オプションの応答に関する考慮事項

When including information on capabilities in a response to an OPTIONS request, a UA SHOULD verify with the user (either through a user interface or though prior configuration) whether or not capability information should be divulged to the requester. If the identity of the requester cannot be cryptographically verified (using digest or the SIP identity enhancements [15]), the user SHOULD also be alerted to this fact, and be allowed to choose whether such information should be divulged.

オプションリクエストへの応答に機能に関する情報を含める場合、UAはユーザー（ユーザーインターフェイスを介して、または以前の構成を介して）で検証する必要があります。要求者の身元を暗号化して検証できない場合（DigestまたはSIP Identy Enhancements [15]）、ユーザーはこの事実に警告する必要があり、そのような情報を明かすべきかどうかを選択することができます。

If the user does wish to reveal capability information to the requester, and wishes to guarantee its confidentiality, but the request did not arrive using SIPS, the UAS SHOULD redirect the request to a sips URI. This will cause the UAC to send the OPTIONS request using SIPS instead, and therefore provide confidentiality of any responses sent over the secure connections.

ユーザーがリクエスターに機能情報を表示し、その機密性を保証したいが、リクエストがSIPを使用して到着しなかった場合、UASはリクエストをSIPS URIにリダイレクトする必要があります。これにより、UACは代わりにSIPを使用してオプションリクエストを送信し、したがって、安全な接続を介して送信される応答の機密性を提供します。

Furthermore, S/MIME MAY be used in the OPTIONS response. In that case, the capability information would be contained only in the secured S/MIME body, and not in the header fields of the OPTIONS response.

さらに、S/MIMEはオプション応答で使用できます。その場合、機能情報は、セキュリティされたS/MIME本体にのみ含まれ、オプション応答のヘッダーフィールドには含まれません。

11.4. Considerations for Dialog Initiating Messages

11.4. メッセージを開始するダイアログの考慮事項

When a UAS generates a response that will initiate a dialog, and they wish to include capability information in the Contact header field, the same considerations as described in Section 11.3 apply.

UASがダイアログを開始する応答を生成し、連絡先ヘッダーフィールドに機能情報を含めることを希望する場合、セクション11.3の適用と同じ考慮事項が適用されます。

When a UAC generates a request that will initiate a dialog, it SHOULD obtain permission from the user (either through a user interface or apriori configuration) before including capability information in the Contact header field of the request. Confidentiality and integrity of the information SHOULD be provided using SIPS. S/MIME MAY be used.

UACがダイアログを開始するリクエストを生成すると、リクエストの連絡先ヘッダーフィールドに機能情報を含める前に、ユーザー（ユーザーインターフェイスまたはApriori構成のいずれか）から許可を取得する必要があります。SIPを使用して、情報の機密性と整合性を提供する必要があります。S/MIMEを使用できます。

12. IANA Considerations

12. IANAの考慮事項

There are a number of IANA considerations associated with this specification.

この仕様に関連する多くのIANAの考慮事項があります。

12.1. SIP Media Feature Tag Registration Tree

12.1. SIPメディア機能タグ登録ツリー

This specification serves to create a new media feature tag registration tree, per the guidelines of Section 3.1.4 of RFC 2506 [3]. The name of this tree is the "SIP Media Feature Tag Registration Tree", and its prefix is "sip.". It is used for the registration of media feature tags that are applicable to the Session Initiation Protocol, and whose meaning is only defined within that usage.

この仕様は、RFC 2506のセクション3.1.4のガイドラインに従って、新しいメディア機能タグ登録ツリーを作成するのに役立ちます[3]。このツリーの名前は「SIPメディア機能タグ登録ツリー」で、そのプレフィックスは「SIP」です。セッション開始プロトコルに適用されるメディア機能タグの登録に使用され、その意味はその使用法の中でのみ定義されます。

The addition of entries into this registry occurs through IETF consensus, as defined in RFC 2434 [18]. This requires the publication of an RFC that contains the registration. The information required in the registration is identical to the IETF tree. As such, specifications adding entries to the registry should use the template provided in Section 3.4 of RFC 2506. Note that all media feature tags registered in the SIP tree will have names with a prefix of "sip.". No leading "+" is used in the registrations in any of the media feature tag trees.

このレジストリへのエントリの追加は、RFC 2434 [18]で定義されているように、IETFコンセンサスを通じて発生します。これには、登録を含むRFCの公開が必要です。登録に必要な情報は、IETFツリーと同一です。そのため、レジストリにエントリを追加する仕様は、RFC 2506のセクション3.4に記載されているテンプレートを使用する必要があります。SIPツリーに登録されているすべてのメディア機能タグには、「SIP」の接頭辞が付いていることに注意してください。メディア機能タグツリーのいずれかの登録には、先頭の「」は使用されていません。

12.2. Media Feature Tags

12.2. メディア機能タグ

This specification registers a number of new Media feature tags according to the procedures of RFC 2506 [3]. These registrations are all made in the newly created SIP tree for media feature tags. These registrations are:

この仕様は、RFC 2506の手順に従って、多数の新しいメディア機能タグを登録します[3]。これらの登録はすべて、メディア機能タグ用に新しく作成されたSIPツリーで作成されています。これらの登録は次のとおりです。

sip.audio: The information for registering the sip.audio media feature tag is contained in Section 10.1.

sip.audio：sip.audioメディア機能タグを登録するための情報は、セクション10.1に含まれています。

sip.application: The information for registering the sip.application media feature tag is contained in Section 10.2.

sip.application：sip.applicationメディア機能タグを登録するための情報は、セクション10.2に含まれています。

sip.data: The information for registering the sip.data media feature tag is contained in Section 10.3.

sip.data：sip.dataメディア機能タグを登録するための情報は、セクション10.3に含まれています。

sip.control: The information for registering the sip.control media feature tag is contained in Section 10.4.

sip.control：sip.controlメディア機能タグを登録するための情報は、セクション10.4に含まれています。

sip.video: The information for registering the sip.video media feature tag is contained in Section 10.5.

sip.video：sip.videoメディア機能タグを登録するための情報は、セクション10.5に含まれています。

sip.text: The information for registering the sip.text media feature tag is contained in Section 10.6.

sip.text：sip.textメディア機能タグを登録するための情報は、セクション10.6に含まれています。

sip.automata: The information for registering the sip.automata media feature tag is contained in Section 10.7.

sip.automata：sip.automataメディア機能タグを登録するための情報は、セクション10.7に含まれています。

sip.class: The information for registering the sip.class media feature tag is contained in Section 10.8.

sip.class：sip.classメディア機能タグを登録するための情報は、セクション10.8に含まれています。

sip.duplex: The information for registering the sip.duplex media feature tag is contained in Section 10.9.

sip.duplex：sip.duplexメディア機能タグを登録するための情報は、セクション10.9に含まれています。

sip.mobility: The information for registering the sip.mobility media feature tag is contained in Section 10.10.

sip.mobility：sip.mobilityメディア機能タグを登録するための情報は、セクション10.10に含まれています。

sip.description: The information for registering the sip.description media feature tag is contained in Section 10.11.

sip.description：sip.descriptionメディア機能タグを登録するための情報は、セクション10.11に含まれています。

sip.events: The information for registering the sip.events media feature tag is contained in Section 10.12.

sip.events：sip.eventsメディア機能タグを登録するための情報は、セクション10.12に含まれています。

sip.priority: The information for registering the sip.priority media feature tag is contained in Section 10.13.

sip.priority：sip.priorityメディア機能タグを登録するための情報は、セクション10.13に含まれています。

sip.methods: The information for registering the sip.methods media feature tag is contained in Section 10.14.

sip.methods：sip.methodsメディア機能タグを登録するための情報は、セクション10.14に含まれています。

sip.extensions: The information for registering the sip.extensions media feature tag is contained in Section 10.15.

sip.extensions：sip.extensionsメディア機能タグを登録するための情報は、セクション10.15に含まれています。

sip.schemes: The information for registering the sip.schemes media feature tag is contained in Section 10.16.

SIP.SCHEMES：SIP.SCHEMESメディア機能タグを登録するための情報は、セクション10.16に含まれています。

sip.actor: The information for registering the sip.actor media feature tag is contained in Section 10.17.

sip.actor：sip.actorメディア機能タグを登録するための情報は、セクション10.17に含まれています。

sip.isfocus: The information for registering the sip.isfocus media feature tag is contained in Section 10.18.

Sip.isfocus：sip.isfocusメディア機能タグを登録するための情報は、セクション10.18に含まれています。

12.3. SIP Option Tag

12.3. SIPオプションタグ

This specification registers a single SIP option tag, pref. The required information for this registration, as specified in RFC 3261 [1], is:

この仕様は、単一のSIPオプションタグを登録します。RFC 3261 [1]で指定されているように、この登録に必要な情報は次のとおりです。

Name: pref

名前：PREF

Description: This option tag is used in a Require header field of a registration to ensure that the registrar supports the caller preferences extensions.

説明：このオプションタグは、レジストラが発信者の設定拡張機能をサポートすることを確認するために、登録の要求ヘッダーフィールドで使用されます。

13. Acknowledgments

13. 謝辞

The initial set of media feature tags used by this specification were influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty provided helpful comments. Graham Klyne provided assistance on the usage of RFC 2533. Thanks to Allison Mankin for her comments and support, and to Ted Hardie for his guidance on usage of the media feature tags.

この仕様で使用されるメディア機能タグの初期セットは、Scott PetrackのCMAデザインの影響を受けました。ジョナサン・レノックス、ボブ・ペンフィールド、ベン・キャンベル、メアリー・バーンズ、ロハン・マヒー、ジョン・ハーティは有益なコメントを提供しました。Graham Klyneは、RFC 2533の使用に関する支援を提供しました。アリソンマンキンのコメントとサポート、およびメディア機能タグの使用に関するガイダンスについてテッドハーディに感謝します。

14. References

14. 参考文献

14.1. Normative References

14.1. 引用文献

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

[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.

[3] Holtman、K.、Mutz、A。、およびT. Hardie、「メディア機能タグ登録手順」、BCP 31、RFC 2506、1999年3月。

[4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.

[4] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。

[5] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, December 1999.

[5] Klyne、G。、「メディア機能セットを説明するための構文」の修正」、RFC 2738、1999年12月。

[6] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.

[6] Hoffman、P。、「Charset and Languages Media機能の登録タグ」、RFC 2987、2000年11月。

[7] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.

[7] Klyne、G。、「メディア機能表現のMIMEコンテンツタイプ」、RFC 2913、2000年9月。

[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[8] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。

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

[9] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。

[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[10] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。

14.2. Informative References

14.2. 参考引用

[11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.

[11] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。

[12] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.

[12] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、2004年8月。

[13] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003.

[13] Rosenberg、J。、「セッション開始プロトコルとの会議のためのフレームワーク」、2003年5月、進行中の作業。

[14] Howes, T. and M. Smith, "LDAP: String Representation of Search Filters", Work in Progress, March 2003.

[14] Howes、T。およびM. Smith、「LDAP：検索フィルターの文字列表現」、2003年3月、Work in Progress。

[15] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.

[15] Peterson、J。、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、2003年3月、進行中の作業。

[16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.

[16] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。

[17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.

[17] Klyne、G。、「プロトコルに依存しないコンテンツネゴシエーションフレームワーク」、RFC 2703、1999年9月。

[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[18] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。

Appendix A. Overview of RFC 2533

付録A. RFC 2533の概要

This section provides a brief overview of RFC 2533 and related specifications that form the content negotiation framework. This section does not represent normative behavior. In the event of any conflict between the tutorial material here and the normative text in RFC 2533, RFC 2533 takes precedence.

このセクションでは、RFC 2533とコンテンツネゴシエーションフレームワークを形成する関連する仕様の簡単な概要を説明します。このセクションは、規範的な行動を表していません。ここのチュートリアル資料とRFC 2533の規範的なテキストとの間に競合がある場合、RFC 2533が優先されます。

A critical concept in the framework is that of a feature set. A feature set is information about an entity (in our case, a UA), which describes a set of features it can handle. A feature set can be thought of as a region in N-dimensional space. Each dimension in this space is a different media feature, identified by a media feature tag. For example, one dimension (or axis) might represent languages, another might represent methods, and another, MIME types. A feature collection represents a single point in this space. It represents a particular rendering or instance of an entity (in our case, a UA). For example, a "rendering" of a UA would define an instantaneous mode of operation that it can support. One such rendering would be processing the INVITE method, which carried the application/sdp MIME type, sent to a UA for a user that is speaking English.

フレームワークの重要な概念は、機能セットの概念です。機能セットは、エンティティ（私たちの場合はUA）に関する情報で、処理できる一連の機能を説明しています。機能セットは、N次元空間の領域と考えることができます。このスペースの各寸法は、メディア機能タグで識別される別のメディア機能です。たとえば、1つの次元（または軸）は言語を表す場合があり、もう1つはメソッドを表す場合があり、別の次のMIMEタイプを表す場合があります。機能コレクションは、このスペースの単一のポイントを表します。これは、エンティティの特定のレンダリングまたはインスタンスを表します（この場合、UA）。たとえば、UAの「レンダリング」は、サポートできる瞬間的な動作モードを定義します。そのようなレンダリングの1つは、英語を話しているユーザーのためにUAに送信されたアプリケーション/SDP MIMEタイプを搭載したInviteメソッドを処理することです。

A feature set can therefore be defined as a set of feature collections. In other words, a feature set is a region of N-dimensional feature-space, that region being defined by the set of points - feature collections - that make up the space. If a particular feature collection is in the space, it means that the rendering described by that feature collection is supported by the device with that feature set.

したがって、機能セットは、機能コレクションのセットとして定義できます。言い換えれば、特徴セットはN次元の特徴空間の領域であり、その領域は、スペースを構成するポイントのセット（機能コレクション）によって定義されています。特定の機能コレクションがスペースにある場合、その機能コレクションで説明されているレンダリングが、その機能セットを備えたデバイスによってサポートされていることを意味します。

How does one represent a feature set? There are many ways to describe an N-dimensional space. One way is to identify mathematical functions which identify its contours. Clearly, that is too complex to be useful. The solution taken in RFC 2533 is to define the space with a feature set predicate. A feature predicate defines a relation over an N-dimensional space; its input is any point in that space (i.e., a feature collection), and is true for all points that are in the region thus defined.

機能セットをどのように表していますか？N次元空間を説明する方法はたくさんあります。1つの方法は、その輪郭を識別する数学的関数を識別することです。明らかに、それは複雑すぎて役に立たない。RFC 2533で撮影されたソリューションは、機能セットの述語でスペースを定義することです。特徴は、N次元空間をめぐる関係を定義します。その入力は、そのスペースの任意のポイント（つまり、機能コレクション）であり、このように定義されている領域にあるすべてのポイントに当てはまります。

RFC 2533 describes a syntax for writing down these N-dimensional boolean functions, borrowed from LDAP [14]. It uses a prolog-style syntax which is fairly self-explanatory. This representation is called a feature set predicate. The base unit of the predicate is a filter, which is a boolean expression encased in round brackets. A filter can be complex, where it contains conjunctions and disjunctions of other filters, or it can be simple. A simple filter is one that expresses a comparison operation on a single media feature tag.

RFC 2533は、LDAPから借りたこれらのN次元ブール機能を書き留めるための構文を説明しています[14]。かなり自明のPrologスタイルの構文を使用しています。この表現は、特徴セット述語と呼ばれます。述語のベースユニットはフィルターで、丸いブラケットに包まれたブール式の式です。フィルターは複雑になる可能性があり、他のフィルターの接続詞と分離が含まれている場合や、単純な場合もあります。単純なフィルターは、単一のメディア機能タグで比較操作を表すものです。

For example, consider the feature set predicate:

たとえば、機能セットの述語を検討してください。

      (& (foo=A)
         (bar=B)
         (| (baz=C) (& (baz=D) (bif=E))))

This defines a function over four media features - foo, bar, baz, and bif. Any point in feature space with foo equal to A, bar equal to B, and baz equal to either C or D, and bif equal to E, is in the feature set defined by this feature set predicate.

これは、Foo、bar、baz、およびbifの4つのメディア機能を介した関数を定義します。fooがaに等しく、bに等しいbar、およびbazがcまたはdに等しい機能スペースの任意のポイントは、この機能セットの述語で定義された機能セットにあります。

Note that the predicate doesn't say anything about the number of dimensions in feature space. The predicate operates on a feature space of any number of dimensions, but only those dimensions labeled foo, bar, baz, and bif matter. The result is that values of other media features don't matter. The feature collection {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the predicate, even though the media feature tag "bop" isn't mentioned. Feature set predicates are therefore inclusive by default. A feature collection is present unless the boolean predicate rules it out. This was a conscious design choice in RFC 2533.

述語は、機能空間の寸法の数について何も言っていないことに注意してください。述語は、任意の数の寸法の特徴空間で動作しますが、Foo、bar、baz、およびbif物質とラベル付けされた寸法のみです。その結果、他のメディア機能の値は重要ではありません。メディア機能「bop」が言及されていない場合でも、機能コレクション{foo = a、bar = b、baz = c、bop = f}は、Predicateで記述された機能セットにあります。したがって、機能セットの述語は、デフォルトで包括的です。ブールの述語がそれを支配しない限り、機能コレクションが存在します。これは、RFC 2533の意識的な設計の選択でした。

RFC 2533 also talks about matching a preference with a capability set. This is accomplished by representing both with a feature set. A preference is a feature set - its a specification of a number of feature collections, any one of which would satisfy the requirements of the sender. A capability is also a feature set - its a specification of the feature collections that the recipient supports. There is a match when the spaces defined by both feature sets overlap. When there is overlap, there exists at least one feature collection that exists in both feature sets, and therefore a modality or rendering desired by the sender which is supported by the recipient.

RFC 2533は、設定を機能セットと一致させることについても話しています。これは、両方を機能セットで表現することによって達成されます。選好は機能セットです。多くの機能コレクションの仕様であり、そのいずれかが送信者の要件を満たすものです。機能も機能セットです。これは、受信者がサポートする機能コレクションの仕様です。両方の機能セットで定義されたスペースが重複すると一致します。オーバーラップがある場合、両方の機能セットに存在する少なくとも1つの機能コレクションが存在するため、受信者がサポートする送信者が望むモダリティまたはレンダリングが存在します。

This leads directly to the definition of a match. Two feature sets match if there exists at least one feature collection present in both feature sets.

これは、一致の定義に直接つながります。両方の機能セットに存在する少なくとも1つの機能コレクションが存在する場合、2つの機能セットが一致します。

Computing a match for two general feature set predicates is not easy. Section 5 of RFC 2533 presents an algorithm for doing it by expanding an arbitrary expression into disjunctive normal form. However, the feature set predicates used by this specification are constrained. They are always in conjunctive normal form, with each term in the conjunction describing values for different media features. This makes computation of a match easy. It is computed independently for each media feature, and then the feature sets overlap if media features specified in both sets overlap. Computing the overlap of a single media feature is very straightforward, and is a simple matter of computing whether two finite sets overlap.

2つの一般的な機能セットの述語の一致を計算するのは簡単ではありません。RFC 2533のセクション5では、任意の式を分離法の正常形式に拡大することにより、それを行うためのアルゴリズムを示します。ただし、この仕様で使用される機能セットの述語は制約されています。それらは常に組み合わせた通常の形であり、各用語は、さまざまなメディア機能の値を説明しています。これにより、試合の計算が簡単になります。メディア機能ごとに個別に計算され、両方のセットで指定されたメディア機能がオーバーラップすると、機能が重複します。単一のメディア機能のオーバーラップを計算することは非常に簡単であり、2つの有限セットが重複するかどうかを計算する簡単な問題です。

Authors' Addresses

著者のアドレス

Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US

Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054 US

   Phone: +1 973 952-5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net

Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US

ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US

   EMail: schulzrinne@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~hgs

Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US

Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 BOXBORO、MA 01719 US

   EMail: pkyzivat@cisco.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004). 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.

著作権（c）The Internet Society（2004）。この文書は、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 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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への情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。