[要約] RFC 5196は、SIPユーザーエージェントの機能拡張を目的としたPIDFの形式に関するものです。このRFCの目的は、SIPユーザーエージェントがPIDFを使用してプレゼンス情報を交換するための拡張を提供することです。
Network Working Group M. Lonnfors
Request for Comments: 5196 K. Kiss
Category: Standards Track Nokia
September 2008
Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)
セッション開始プロトコル（SIP）ユーザーエージェント機能存在情報データ形式（PIDF）への拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities.
存在情報データ形式（PIDF）は、存在の共通プロファイル（CPP）に準拠した存在プロトコルの共通の存在データ形式を定義します。このメモは、SIPユーザーエージェント機能を表すPIDF拡張機能を定義します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Scope ......................................................4
2. Conventions .....................................................4
3. Extension for "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)" in PIDF Documents ............4
3.1. Overview of Operation ......................................4
3.2. Service capabilities .......................................5
3.2.1. <servcaps> Element ..................................5
3.2.2. <audio> Element .....................................5
3.2.3. <application> Element ...............................5
3.2.4. <data> Element ......................................6
3.2.5. <control> Element ...................................6
3.2.6. <video> Element .....................................6
3.2.7. <text> Element ......................................6
3.2.8. <message> Element ...................................7
3.2.9. <type> Element ......................................7
3.2.10. <automata> Element .................................7
3.2.11. <class> Element ....................................7
3.2.12. <duplex> Element ...................................8
3.2.13. <description> Element ..............................8
3.2.14. <event-packages> Element ...........................9
3.2.15. <priority> Element .................................9
3.2.16. <methods> Element .................................10
3.2.17. <extensions> Element ..............................11
3.2.18. <schemes> Element .................................11
3.2.19. <actor> Element ...................................12
3.2.20. <isfocus> Element .................................12
3.2.21. <languages> Element ...............................13
3.3. Device Capabilities .......................................13
3.3.1. <devcaps> Element ..................................13
3.3.2. <mobility> Element .................................14
3.3.3. <description> Element ..............................14
4. Usage Guidelines ...............................................15
4.1. Use of <supported> and <notsupported> Elements ............15
5. Examples .......................................................16
6. XML Schema Definitions .........................................17
7. IANA Considerations ............................................26
7.1. URN Sub-Namespace Registration for ........................26
7.2. Schema Registration for Schema ............................27
8. Security Considerations ........................................27
9. Acknowledgments ................................................27
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................28
Common Profile for Presence (CPP) [RFC3859] and Common Profile for Instant Messaging (CPIM) [RFC3860] define common operations and formats that all presence and instant messaging services must agree upon so that basic interoperability is possible. The actual base format for the presence is defined in the Presence Information Document Format (PIDF) [RFC3863]. The PIDF has been designed to reduce the need for gatewaying and to allow end-to-end security of presence information. It has taken a very minimalistic approach to support such operations. In order to make the PIDF usable by different presence applications, these applications usually must extend the basic PIDF by standard XML mechanisms as defined in PIDF [RFC3863].
インスタントメッセージングの共通プロファイル（CPP）[RFC3859]およびインスタントメッセージング（CPIM）[RFC3860]の共通プロファイルは、基本的な相互運用性が可能になるように、すべての存在とインスタントメッセージングサービスが一致しなければならない共通の操作と形式を定義します。存在の実際のベース形式は、存在情報ドキュメント形式（PIDF）[RFC3863]で定義されます。PIDFは、ゲートウェイの必要性を減らし、存在情報のエンドツーエンドのセキュリティを可能にするように設計されています。このような操作をサポートするために、非常にミニマルなアプローチを採用しています。PIDFを異なる存在アプリケーションで使用できるようにするために、これらのアプリケーションは通常、PIDF [RFC3863]で定義されている標準XMLメカニズムによって基本的なPIDFを拡張する必要があります。
The aim of this memo is to introduce a SIP-specific extension mechanism to the PIDF that conveys the same SIP media feature tags as described in [RFC3840]. With this extension, presence applications based on SIP can have richer and more usable presence information compared to the baseline PIDF.
このメモの目的は、[RFC3840]で説明されているのと同じSIPメディア機能タグを伝えるPIDFにSIP固有の拡張メカニズムをPIDFに導入することです。この拡張機能により、SIPに基づく存在アプリケーションは、ベースラインPIDFと比較して、より豊かで使用可能な存在情報を持つことができます。
The PIDF [RFC3863] defines a <contact> element that may appear once inside every <tuple> element. The content of the <contact> element encodes the CONTACT ADDRESS and CONTACT MEANS as defined in [RFC2778]. The <contact> element is defined to be a URI of any scheme. In some implementations, the URI scheme can uniquely identify the service the tuple intends to describe (e.g., im: URI scheme usually represents Instant Messaging service). However, this may not be the case in all implementations. For example in SIP, a SIP URI scheme can represent different kinds of services. A SIP URI scheme can be used to contact voice services, video services, or messaging services. If it is not known by other means, it might be hard for applications processing the presence information containing only a SIP URI contact addresses to know what particular service the tuple intends to describe. Also, watchers receiving presence information would probably benefit from getting more descriptive information about what particular communication means or services are supported by the presentity.
PIDF [RFC3863]は、すべての<Tuple>要素内に一度表示される可能性のある<コンタクト>要素を定義します。<contact>要素の内容は、[RFC2778]で定義されているように、連絡先アドレスと連絡先の手段をエンコードします。<contact>要素は、あらゆるスキームのURIであると定義されています。いくつかの実装では、URIスキームは、タプルが説明する意図したサービスを一意に識別できます（例えば、IM：URIスキームは通常、インスタントメッセージングサービスを表します）。ただし、これはすべての実装では当てはまらない場合があります。たとえば、SIPでは、SIP URIスキームはさまざまな種類のサービスを表すことができます。SIP URIスキームを使用して、音声サービス、ビデオサービス、またはメッセージングサービスに連絡できます。他の手段で知られていない場合、SIP URI連絡先のみを含む存在情報を処理して、Tupleが説明しようとしている特定のサービスを知るアプリケーションが難しい場合があります。また、プレゼンス情報を受け取るウォッチャーは、おそらく、特定のコミュニケーションの意味やサービスが現在によってサポートされていることについてより多くの説明的な情報を取得することから利益を得るでしょう。
The User Agent Capabilities extension [RFC3840] defines a set of extensions that allow user agents to express preferences about request handling in SIP servers. The same information can provide value to watchers as well so that they can make more rational decisions on how a presentity should be contacted if a presence document contained this information.
ユーザーエージェント機能拡張[RFC3840]は、ユーザーエージェントがSIPサーバーでのリクエスト処理に関する好みを表現できる拡張機能のセットを定義します。同じ情報がウォッチャーにも価値を提供できるため、プレゼンスドキュメントにこの情報が含まれている場合、プレゼンテーションにどのように連絡するかについて、より合理的な決定を下すことができます。
This document defines a PIDF extension, which enables SIP presence implementations to represent User Agent Capabilities [RFC3840] within presence information.
This extension does not replace media negotiation mechanisms defined for SIP (e.g., SDP [RFC4566]). The purpose of this extension is for a presentity to give watchers hints about the presentity's preferences, willingness, and capabilities to communicate before watchers initiate communication with the presentity.
この拡張機能は、SIPに対して定義されたメディア交渉メカニズムを置き換えません（例：SDP [RFC4566]）。この拡張機能の目的は、ウォッチャーがプレゼンテーションとのコミュニケーションを開始する前に、プレゼントの好み、意欲、コミュニケーション能力についてウォッチャーにヒントを与えることです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This memo makes use of the vocabulary defined in [RFC2778] and [RFC3863].
このメモは、[RFC2778]および[RFC3863]で定義されている語彙を使用しています。
This section presents the extension elements, attributes, their values, and semantics. This section also describes how this extension can be further extended.
このセクションでは、拡張要素、属性、その値、およびセマンティクスを示します。このセクションでは、この拡張機能をさらに拡張する方法についても説明します。
This extension is intended to be used within the PIDF [RFC3863] and that particular usage is described here. This extension may also be used with other XML documents if appropriate.
この拡張機能は、PIDF [RFC3863]内で使用することを目的としており、その特定の使用法について説明します。この拡張機能は、必要に応じて他のXMLドキュメントでも使用できます。
This document defines how the features presented in [RFC3840] can be provided as part of presence information. Additionally, this memo includes the "type" feature tag [RFC2913], "message" media type feature tag [RFC4569], and the "language" feature tag [RFC4646] definitions. Adding these features to the PIDF means mapping them to an XML formatted structure.
このドキュメントでは、[RFC3840]で提示された機能を存在情報の一部として提供する方法を定義しています。さらに、このメモには、「タイプ」機能タグ[RFC2913]、「メッセージ」メディアタイプ機能タグ[RFC4569]、および「言語」機能タグ[RFC4646]定義が含まれます。これらの機能をPIDFに追加すると、それらをXMLフォーマット構造にマッピングすることを意味します。
The presence data model [RFC4479] defines presence information consisting of three types of data elements: person, service, and device. This memo follows this model so that one XML extension is defined to describe device capabilities and another one to describe service capabilities.
存在データモデル[RFC4479]は、個人、サービス、デバイスの3種類のデータ要素で構成される存在情報を定義します。このメモはこのモデルに従っているため、1つのXML拡張機能がデバイス機能を記述するために定義され、別のXML拡張機能がサービス機能を記述します。
The namespace URIs for elements defined by this document are URNs using the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688].
このドキュメントで定義された要素の名前空間URIは、[RFC2648]で定義され、[RFC3688]によって拡張された名前空間識別子「IETF」を使用したURNです。
When these extension namespaces are congregated with the PIDF document, the combined document MUST follow the same general formatting rules as specified in Section 4.1 of [RFC3863].
これらの拡張ネームスペースにPIDFドキュメントが集まる場合、[RFC3863]のセクション4.1で指定されているのと同じ一般的なフォーマットルールに従う必要があります。
Elements belonging to service capabilities are used to describe dynamic characteristics of a service. These capabilities are enclosed within the <servcaps> element which SHOULD be located in the PIDF document as a child element of urn:ietf:params:xml:ns:pidf namespace <tuple> [RFC3863] element.
サービス機能に属する要素は、サービスの動的特性を記述するために使用されます。これらの機能は、<servcaps>要素内に囲まれています。<servcaps>要素は、pidfドキュメントにurnの子要素として配置する必要があります。
The namespace identifier for these elements is:
これらの要素の名前空間識別子は次のとおりです。
urn:ietf:params:xml:ns:pidf:caps
The root element of service capabilities is <servcaps>. The root element always has to be present. This element can contain the following child elements: <audio>, <application>, <data>, <control>, <video>, <text>, <message>, <type>, <automata>, <class>, <duplex>, <description>, <event-packages>, <priority>, <methods>, <extensions>, <schemes>, <actor>, <isfocus>, and <languages> followed by any number of optional extension elements from other namespaces.
サービス機能のルート要素は<servcaps>です。ルート要素は常に存在する必要があります。この要素には、次の子要素を含めることができます：<audio>、<application>、<data>、<control>、<video>、<text>、<message>、<type>、<class>、<class>、<duplex>、<description>、<Event-Packages>、<priority>、<methods>、<extensions>、<schemes>、<cator>、<言語>、<言語>他の名前空間。
A <servcaps> element can contain any number of optional extension attributes from other namespaces.
A <Servcaps>要素には、他の名前空間からのオプションの拡張属性を任意の数に含めることができます。
The <audio> element indicates that the service supports audio as a streaming media type as defined in [RFC3840].
<Audio>要素は、[RFC3840]で定義されているように、サービスがストリーミングメディアタイプとしてオーディオをサポートしていることを示しています。
The <audio> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports audio media type, and the value 'false' indicates that service does not support audio media type.
<Audio>要素はブール型であり、属性はありません。値「true」は、サービスがオーディオメディアタイプをサポートしていることを示し、値「false」は、サービスがオーディオメディアタイプをサポートしていないことを示します。
The <application> element indicates that the service supports application as a streaming media type as defined in [RFC3840].
<application>要素は、[RFC3840]で定義されているように、サービスがストリーミングメディアタイプとしてアプリケーションをサポートしていることを示しています。
The <application> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports application media type, and the value 'false' indicates that service does not support application media type.
<アプリケーション>要素はブール型であり、属性はありません。値「true」は、サービスがアプリケーションメディアタイプをサポートしていることを示し、値「false」は、サービスがアプリケーションメディアタイプをサポートしていないことを示します。
The <data> element indicates that the service supports data as a streaming media type as defined in [RFC3840].
<data>要素は、[RFC3840]で定義されているように、サービスがストリーミングメディアタイプとしてデータをサポートしていることを示しています。
The <data> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports data media type, and the value 'false' indicates that service does not support data media type.
<data>要素はブール型であり、属性はありません。値「true」は、サービスがデータメディアタイプをサポートしていることを示し、値「false」は、サービスがデータメディアタイプをサポートしていないことを示します。
The <control> element indicates that the service supports control as a streaming media type as defined in [RFC3840].
<control>要素は、[RFC3840]で定義されているように、サービスがストリーミングメディアタイプとしてコントロールをサポートすることを示しています。
The <control> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports control media type, and the value 'false' indicates that service does not support control media type.
<control>要素はブール型であり、属性はありません。値「true」は、サービスがコントロールメディアタイプをサポートしていることを示し、値「false」は、サービスがコントロールメディアタイプをサポートしていないことを示します。
The <video> element indicates that the service supports video as a streaming media type as defined in [RFC3840].
<video>要素は、[RFC3840]で定義されているように、サービスがストリーミングメディアタイプとしてビデオをサポートしていることを示しています。
The <video> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports video media type, and the value 'false' indicates that service does not support video media type.
<video>要素はブール型であり、属性はありません。値「true」は、サービスがビデオメディアタイプをサポートしていることを示し、値「false」は、サービスがビデオメディアタイプをサポートしていないことを示します。
The <text> element indicates that the service supports text as a streaming media type as defined in [RFC3840].
<text>要素は、[RFC3840]で定義されているように、サービスがストリーミングメディアタイプとしてテキストをサポートしていることを示しています。
The <text> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports text media type, and the value 'false' indicates that service does not support text media type.
The <message> element indicates that the service supports messaging as a streaming media type as defined in [RFC4569].
<メッセージ>要素は、[RFC4569]で定義されているように、サービスがストリーミングメディアタイプとしてのメッセージングをサポートしていることを示しています。
The <message> element is a boolean type and does not have any attributes. The value 'true' indicates that service supports message media type, and the value 'false' indicates that service does not support message media type.
The <type> element indicates a MIME media content type (i.e., that appears in a 'Content-type:' header of the corresponding MIME-formatted data) as defined in [RFC2913].
<Type>要素は、[RFC2913]で定義されているように、MIMEメディアコンテンツタイプ（つまり、「コンテンツタイプ：「対応するMIME形式のデータ」に表示される）に表示される）を示します。
The <type> element is a string type and does not have any attributes. It MUST be a string of the form "type/subtype", where 'type' and 'subtype' are defined by the MIME specification [RFC2045]. Only lowercase letters SHOULD be used.
<type>要素は文字列型であり、属性はありません。「タイプ/サブタイプ」の形式でなければなりません。ここで、「タイプ」と「サブタイプ」はMIME仕様[RFC2045]によって定義されます。小文字のみを使用する必要があります。
The <automata> element indicates whether the service represents an automaton (such as a voicemail server, conference server, or recording device) or a human as defined in [RFC3840].
<automata>要素は、サービスが[RFC3840]で定義されているように、サービスがオートマトン（ボイスメールサーバー、会議サーバー、レコーディングデバイスなど）を表すか、人間を表すかを示します。
The <automata> element is a boolean type and does not have any attributes. The value 'true' indicates that the service represents an automaton, and the value 'false' indicates that it represents a human.
<automata>要素はブール型であり、属性はありません。値「真」は、サービスがオートマトンを表すことを示し、値「false」は人間を表すことを示します。
The <class> element indicates the setting, business or personal, in which a communications service is used as defined in [RFC3840].
<class>要素は、[RFC3840]で定義されているように、通信サービスが使用される設定、ビジネスまたは個人を示します。
The <class> element can contain two elements: <supported> and <notsupported>. Classes that are supported by the service can be listed under the <supported> element, and classes that are not supported by the service can be listed under the <notsupported> element.
<class>要素には、2つの要素を含めることができます：<supported>と<notsupted>。サービスでサポートされているクラスは、<supported>要素の下にリストされ、サービスでサポートされていないクラスは<notsupported>要素の下にリストできます。
<supported> and <notsupported> elements can contain <business> and <personal> elements followed by any number of optional extension elements from other namespaces. The semantics of business and personal are defined in [RFC3840] as: o <business>: The service is used for business communications.
<Supported>および<notSupported>要素には、<business>および<パーソナル>要素が含まれ、その後、他の名前空間からのオプションの拡張要素が数多く含まれています。ビジネスと個人のセマンティクスは、[RFC3840]で次のように定義されています。O<business>：サービスはビジネスコミュニケーションに使用されます。
o <personal>: The service is used for personal communications.
o <パーソナル>：サービスは個人的なコミュニケーションに使用されます。
Any value that is registered with IANA for the SIP media feature tag registration tree as a sip.class media feature tag can be used as a value of an extension element. If the appropriate value is not registered, it SHOULD be registered as defined in [RFC3840].
SIPメディア機能タグ登録ツリーのIANAに登録されている値は、拡張要素の値として使用できます。適切な値が登録されていない場合は、[RFC3840]で定義されているように登録する必要があります。
The <duplex> element lists whether a communications service can simultaneously send and receive media ("full"), alternate between sending and receiving ("half"), only receive ("receive-only"), or only send ("send-only") as defined in [RFC3840].
<duplex>要素は、通信サービスがメディア（ "full"）を同時に送信して受信できるか、送信と受信（ "half"）の代替（ "receid-only"）のみ、または送信（ "send-のみを受信（" receid-send-）を受け取ることができるかどうかを一覧表示します。[RFC3840]で定義されているように。
The <duplex> element can contain two elements: <supported> and <notsupported>. Duplex modes that are supported by the service can be listed under the <supported> element, and duplex modes that are not supported by the service can be listed under the <notsupported> element.
<duplex>要素には、2つの要素を含めることができます。<supported>と<notsupported>。サービスでサポートされているデュプレックスモードは<supported>要素の下にリストでき、サービスでサポートされていないデュプレックスモードは、<notsupported>要素の下にリストできます。
<supported> and <notsupported> elements can contain <full>, <half>, <receive-only>, and <send-only> elements followed by any number of optional extension elements from other namespaces. The semantics of these elements are defined in [RFC3840] as:
<Supported>および<notsupported>要素には、<full>、<half>、<eceim-only>、および<send-only>要素が含まれ、その後、他の名前空間からのオプションの拡張要素が数多く含まれています。これらの要素のセマンティクスは、[RFC3840]で次のように定義されています。
o <full>: The service can simultaneously send and receive media.
o <Full>：サービスは同時にメディアを送信および受信できます。
o <half>: The service can alternate between sending and receiving media.
o <half>：このサービスは、メディアの送信と受信を交互に行うことができます。
o <receive-only>: The service can only receive media.
o <受信のみ>：サービスはメディアのみを受け取ることができます。
o <send-only>: The service can only send media.
o <送信専用>：サービスはメディアのみを送信できます。
Any value that is registered with IANA for the SIP media feature tag registration tree as a sip.duplex media feature tag can be used as a value of an extension element. If the appropriate value is not registered, it SHOULD be registered as defined in [RFC3840].
SIPメディア機能タグ登録ツリーのIANAに登録されている任意の値。Duplexメディア機能タグは、拡張要素の値として使用できます。適切な値が登録されていない場合は、[RFC3840]で定義されているように登録する必要があります。
The <description> element provides a textual description of the service as defined in [RFC3840].
<説明>要素は、[RFC3840]で定義されているサービスのテキストの説明を提供します。
The <description> element is of string type and does not have any attributes.
<説明>要素は文字列型であり、属性はありません。
The <description> element SHOULD be labeled with the 'xml:lang' attribute to indicate its language and script. The specification allows multiple occurrences of this elements so that the presentity can convey <description> elements in multiple scripts and languages. If no 'xml:lang' attribute is provided, the default value is "i-default" as defined in [RFC2277].
<説明>要素は、「XML：Lang」属性にラベルを付けて、その言語とスクリプトを示す必要があります。この仕様により、この要素の複数の発生が可能になるため、複数のスクリプトと言語で<説明>要素を伝えることができます。'xml：lang'属性が提供されない場合、[RFC2277]で定義されているように、デフォルト値は「i-default」です。
The <event-packages> element lists the event packages supported by a service.
<Event-Packages>要素は、サービスでサポートされているイベントパッケージをリストします。
The <event-packages> element can contain two elements: <supported> and <notsupported>. Event packages that are supported by the service can be listed under the <supported> element, and event packages that are not supported by the service can be listed under the <notsupported> element.
<Event-Packages>要素には、2つの要素を含めることができます。サービスでサポートされているイベントパッケージは、<supported>要素の下にリストできます。サービスでサポートされていないイベントパッケージは、<notsupported>要素の下にリストできます。
The <supported> and <notsupported> elements can contain any values from the IANA SIP event types namespace registry followed by any number of optional extension elements from other namespaces. As of this writing, the IANA SIP event types namespace registry includes the following packages: <conference>, <dialog>, <kpml>, <message-summary>, <poc-settings>, <presence>, <reg>, <refer>, <Siemens-RTP-Stats>, <spirits-INDPs>, <spirits-user-prof>, and <winfo>.
<Supported>および<notSupported>要素には、IANA SIPイベントタイプの名前空間レジストリからの値を含めることができます。この記事の執筆時点で、IANA SIPイベントタイプの名前空間レジストリには、次のパッケージが含まれます。<conference>、<dialog>、<kpml>、<message-summary>、<poc-settings>、<poression>、<reg>、<参照>、<siemens-rtp-stats>、<sirits-indps>、<sirits-user-prof>、および<winfo>。
The <priority> element indicates the call priorities the service is willing to handle as defined in [RFC3840].
<Priority>要素は、[RFC3840]で定義されているように、サービスが処理する意思のあるコール優先順位を示します。
The <priority> element can contain two elements: <supported> and <notsupported>. Priority values that are supported by the service can be listed under the <supported> element, and priority values that are not supported by the service can be listed under the <notsupported> element.
<priority>要素には、<supported>と<notsupported>の2つの要素を含めることができます。サービスでサポートされている優先値は、<supported>要素の下にリストでき、サービスでサポートされていない優先順位値は、<notsupported>要素の下にリストできます。
The <supported> and <notsupported> elements can contain any number of <lowerthan>, <higherthan>, <equals>, and <range> elements followed by any number of optional extension elements from other namespaces.
<Supported>および<notsupported>要素には、任意の数の<lowerthan>、<higherthan>、<range>要素、その後、他の名前空間からのオプションの拡張要素が任意の数の任意の数を含めることができます。
The <lowerthan> element has a single attribute called "maxvalue". The "maxvalue" attribute is used to give the highest priority value that the service is willing to support. All values equal and below that value are supported.
<lowerthan>要素には、「maxvalue」と呼ばれる単一の属性があります。「MaxValue」属性は、サービスが喜んでサポートする最高の優先度値を与えるために使用されます。すべての値は等しく、その値を下回っています。
The <higherthan> element has a single attribute called "minvalue". The "minvalue" attribute is used to give the lowest priority value that the service is willing to support. All values equal and above that value are supported.
<higherthan>要素には、「minvalue」と呼ばれる単一の属性があります。「MinValue」属性は、サービスが喜んでサポートする最低の優先順位値を与えるために使用されます。その値を上回るすべての値はサポートされています。
The <equals> element is used to indicate the exact priority value that the service is willing to handle. The <equals> element has a single attribute called "value". The "value" attribute is used to indicate the exact supported priority value.
<Equals>要素は、サービスが喜んで処理する正確な優先度値を示すために使用されます。<equals>要素には、「値」と呼ばれる単一の属性があります。「値」属性は、正確なサポートされている優先度値を示すために使用されます。
The <range> element is used to indicate the priority range that the service is willing to handle. The <range> element has two attributes called "minvalue" and "maxvalue". The value of the "minvalue" attribute indicates the lowest priority value supported by the service, and the value of the "maxvalue" attribute indicates the highest priority value supported by the service.
<range>要素は、サービスが喜んで処理する優先範囲範囲を示すために使用されます。<range>要素には、「minvalue」と「maxvalue」と呼ばれる2つの属性があります。「MinValue」属性の値は、サービスによってサポートされている最低の優先度値を示し、「MaxValue」属性の値は、サービスによってサポートされる最高の優先度値を示します。
The <methods> element indicates the SIP methods supported by a service. In this case, "supported" means that the service can receive requests with this method. In that sense, it has the same connotation as the Allow header field as defined in [RFC3840].
<method>要素は、サービスによってサポートされるSIPメソッドを示します。この場合、「サポート」とは、サービスがこの方法でリクエストを受信できることを意味します。その意味で、[RFC3840]で定義されているように、許容ヘッダーフィールドと同じ意味合いがあります。
The <methods> element can contain two elements: <supported> and <notsupported>. Methods that are supported by the service can be listed under the <supported> element, and methods that are not supported by the service can be listed under the <notsupported> element.
<method>要素には、<supported>と<notsported>の2つの要素を含めることができます。サービスによってサポートされる方法は、<supported>要素の下にリストできます。サービスでサポートされていない方法は、<notsupported>要素の下にリストできます。
The <supported> and <notsupported> elements can contain any values from the methods table of the IANA SIP parameters registry table followed by any number of optional extension elements from other namespaces. As of this writing, the IANA SIP parameters registry includes the following methods:<ACK>, <BYE>, <CANCEL>, <INFO>, <INVITE>, <MESSAGE>, <NOTIFY>, <OPTIONS>, <PRACK>, <PUBLISH>, <REFER>, <REGISTER>, <SUBSCRIBE>, and <UPDATE>.
<Supported>および<notSupported>要素には、IANA SIPパラメータレジストリテーブルのメソッドテーブルからの値を含めることができます。この記事の執筆時点で、IANA SIPパラメーターレジストリには次の方法が含まれています：<ack>、<bye>、<cancel>、<infite>、<invite>、<sessake>、<notify>、<options>、<prack>、<publish>、<ferion>、<copride>、<Subscribe>、および<update>。
The <extensions> element is a list of SIP extensions (each of which is defined by an option-tag registered with IANA) that are understood by the service. Understood, in this context, means that the option tag would be included in a Supported header field in a request as defined in [RFC3840].
<extensions>要素は、SIP拡張機能（それぞれがIANAに登録されているオプションタグによって定義されます）のリストであり、サービスが理解しています。このコンテキストでは、[RFC3840]で定義されているように、オプションタグがリクエストのサポートされているヘッダーフィールドに含まれることを理解しています。
The <extensions> element can contain two elements: <supported> and <notsupported>. Extensions that are supported by the service can be listed under the <supported> element, and extensions that are not supported by the service can be listed under the <notsupported> element.
<extensions>要素には、<supported>と<notsupported>の2つの要素を含めることができます。サービスでサポートされている拡張機能は、<supported>要素の下にリストできます。サービスでサポートされていない拡張機能は、<notsupported>要素の下にリストできます。
The <supported> and <notsupported> elements can contain any values from the option tags table of the IANA SIP parameters registry table followed by any number of optional extension elements from other namespaces. As of this writing, the IANA SIP parameters registry includes the following option tags: <rel100>, <early-session>, <eventlist>, <from-change>, <gruu>, <histinfo>, <join>, <norefersub>, <path>, <precondition>, <pref>, <privacy>, <recipient-list-invite>, <recipient-list-subscribe>, <replaces>, <resource-priority>, <sdp-anat>, <sec-agree>, <tdialog>, and <timer>.
<Supported>および<notSupported>要素には、IANA SIPパラメーターレジストリテーブルのオプションタグテーブルからの値を含めることができます。この記事の執筆時点で、IANA SIPパラメーターレジストリには、次のオプションタグが含まれています：<REL100>、<tare-session>、<Eventlist>、<from-change>、<gruu>、<histinfo>、<join>、<norefersub>、<ath>、<precondition>、<fread>、<privacy>、<reciontient-list-invite>、<reciont-list-subscribe>、<代替>、<soress-priority>、<sdp-anat>、<sec-agree>、<tdialog>、および<timer>。
The <schemes> element provides the set of URI schemes that are supported by a service. "Supported" implies, for example, that the service would know how to handle a URI of that scheme in the Contact header field of a redirect response as defined in [RFC3840].
<schemes>要素は、サービスによってサポートされているURIスキームのセットを提供します。「サポート」は、たとえば、[RFC3840]で定義されているように、リダイレクト応答のコンタクトヘッダーフィールドでそのスキームのURIを処理する方法を知っていることを意味します。
The <schemes> element can contain two elements: <supported> and <notsupported>. Schemes that are supported by the service can be listed under the <supported> element, and schemes that are not supported by the service can be listed under the <notsupported> element.
<schemes>要素には、2つの要素を含めることができます：<supported>と<notsupported>。サービスでサポートされているスキームは<supported>要素の下にリストされ、サービスでサポートされていないスキームは<notsupported>要素の下にリストできます。
<supported> and <notsupported> elements can contain any number of <s> elements, which can be used to describe individual schemes supported by the service.
<Supported>および<notSupported>要素には、サービスでサポートされている個々のスキームを説明するために使用できます。
The <s> element is of string type and is used to describe an individual scheme supported by the service. Values that can be used here are scheme names that are registered to the IANA URI scheme registry.
<s>要素は文字列型であり、サービスでサポートされている個々のスキームを記述するために使用されます。ここで使用できる値は、IANA URIスキームレジストリに登録されているスキーム名です。
The <actor> element indicates the type of entity that is available at this URI as defined in [RFC3840].
<actor>要素は、[RFC3840]で定義されているこのURIで利用可能なエンティティのタイプを示します。
The <actor> element can contain two elements: <supported> and <notsupported>. Actor types that are supported by the service can be listed under the <supported> element, and actor types that are not supported by the service can be listed under the <notsupported> element.
<actor>要素には、2つの要素を含めることができます：<supported>と<notsupted>。サービスでサポートされている俳優の種類は、<supported>要素の下にリストされ、サービスによってサポートされていないアクタータイプは、<notsupported>要素の下にリストできます。
The <supported> and <notsupported> elements can contain <principal>, <attendant>, <msg-taker>, and <information> elements followed by any number of optional extension elements from other namespaces.
<supported>および<notsupported>要素には、<prictile>、<aterterant>、<msg-taker>、および<情報>要素が含まれ、その後に他の名前空間からのオプションの拡張要素が数多く含まれています。
The semantics of these elements are defined in [RFC3840] as:
これらの要素のセマンティクスは、[RFC3840]で次のように定義されています。
o <principal>: The service provides communication with the principal that is associated with the service. Often this will be a specific human being, but it can be an automaton (for example, when calling a voice portal).
o <プリンシパル>：サービスは、サービスに関連付けられているプリンシパルとのコミュニケーションを提供します。多くの場合、これは特定の人間になりますが、オートマトンになる可能性があります（たとえば、音声ポータルを呼び出すとき）。
o <attendant>: The service provides communication with an automaton or a person that will act as an intermediary in contacting the principal associated with the service, or a substitute.
o <Attultant>：このサービスは、サービスに関連するプリンシパルまたは代替品に連絡する際に仲介者として機能するオートマトンまたは人とのコミュニケーションを提供します。
o <msg-taker>: The service provides communication with an automaton or a person that will take messages and deliver them to the principal.
o <MSG-Taker>：サービスは、オートマトンまたはメッセージを受け取り、校長に配信する人とのコミュニケーションを提供します。
o <information>: The service provides communication with an automaton or a person that will provide information about the principal.
o <情報>：このサービスは、オートマトンまたはプリンシパルに関する情報を提供する人との通信を提供します。
Any value that is registered with IANA for the SIP media feature tag registration tree as a sip.actor media feature tag can be used as a value of an extension element. If the appropriate value is not registered, it SHOULD be registered as defined in [RFC3840].
SIPメディア機能タグ登録ツリーのIANAに登録されている値は、extension要素の値として使用できます。適切な値が登録されていない場合は、[RFC3840]で定義されているように登録する必要があります。
The <isfocus> element indicates that the service is a conference server, also known as a focus as defined in [RFC3840].
<isfocus>要素は、サービスが[RFC3840]で定義されているとも焦点としても知られている会議サーバーであることを示しています。
The <isfocus> element is of boolean type and does not have any attributes. The value 'true' indicates that service is a conference server and the value 'false' indicates that service does not support conferencing.
<isfocus>要素はブール型であり、属性はありません。値「真」は、サービスが会議サーバーであり、値「false」が会議サーバーであることを示しています。サービスが会議をサポートしていないことを示します。
The <languages> element indicates the ability to display particular human languages as defined in [RFC4646].
<言語>要素は、[RFC4646]で定義されている特定の人間言語を表示する能力を示しています。
The <languages> element can contain two elements: <supported> and <notsupported>. Languages that are supported by the service can be listed under the <supported> element, and languages that are not supported by the service can be listed under the <notsupported> element.
<言語>要素には、2つの要素を含めることができます：<supported>と<notsupted>。サービスでサポートされている言語は、<supported>要素の下にリストできます。サービスでサポートされていない言語は、<notsupported>要素の下にリストできます。
<supported> and <notsupported> elements can contain any number of <l> elements which can be used to describe individual languages supported by the service.
<Supported>および<notSupported>要素には、サービスでサポートされている個々の言語を記述するために使用できる<l>要素を任意に含めることができます。
The <l> element is of string type and is used to describe an individual language supported by the service. Values that can be used here are language subtags that are registered to the IANA language subtag registry as per [RFC4646].
<l>要素は文字列型であり、サービスでサポートされている個々の言語を記述するために使用されます。ここで使用できる値は、[RFC4646]に従ってIANA言語サブタグレジストリに登録されている言語サブタグです。
Elements belonging to device capabilities are used to describe dynamic characteristics of a device. These capabilities are enclosed within the <devcaps> element, which SHOULD be located in the PIDF document as a child element of the urn:ietf:params:xml:ns:pidf:data-model namespace <device> element [RFC4479].
デバイス機能に属する要素は、デバイスの動的特性を記述するために使用されます。これらの機能は、<DevCaps>要素内に囲まれています。これは、PIDFドキュメントにurnの子要素として配置する必要があります。
The namespace identifier for these elements is urn:
これらの要素の名前空間識別子はurnです。
ietf:params:xml:ns:pidf:caps
The root element of device capabilities is <devcaps>. The root element always has to be present. This element can contain the following child elements: <mobility> and <description> followed by any number of optional extension elements from other namespaces.
デバイス機能のルート要素は<DevCaps>です。ルート要素は常に存在する必要があります。この要素には、次の子要素を含めることができます。<mobility>および<説明>に続いて、他の名前空間からの任意の数のオプションの拡張要素が続きます。
A <devcaps> element can contain any number of optional extension attributes from other namespaces.
The <mobility> element 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 as defined in [RFC3840].
<mobility>要素は、デバイスが固定されているか（ネットワークとの固定的な接触点に関連付けられていることを意味する）またはモバイル（つまり、接触点が固定されていないことを意味します）を示します。[RFC3840]で定義されているこの定義に基づいて、コードレス電話はモバイルではなく固定されていることに注意してください。
The <mobility> element can contain two elements: <supported> and <notsupported>. Mobility modes that are supported by the device can be listed under the <supported> element and mobility modes that are not supported by the device can be listed under the <notsupported> element.
<mobility>要素には、2つの要素を含めることができます：<supported>と<notsupported>。デバイスでサポートされているモビリティモードは、デバイスでサポートされていない<supported>要素およびモビリティモードの下にリストできます。
The <supported> and <notsupported> elements can contain <fixed> and <mobile> elements followed by any number of optional extension elements from other namespaces.
<Supported>および<notSupported>要素には、<Fixed>および<mobile>要素を含めることができます。
The semantics of these elements are defined in [RFC3840] as:
これらの要素のセマンティクスは、[RFC3840]で次のように定義されています。
o <fixed>: The device is stationary.
o <Fixed>：デバイスは静止しています。
o <mobile>: The device can move around with the user.
o <mobile>：デバイスはユーザーと一緒に動き回ることができます。
Any value that is registered with IANA to the SIP media feature tag registration tree as sip.mobility media feature tag can be used as a value of an extension element. If the appropriate value is not registered, it SHOULD be registered as defined in [RFC3840].
IANAにSIPメディア機能タグ登録ツリーに登録されている値は、sip.mobilityメディア機能タグを拡張要素の値として使用できます。適切な値が登録されていない場合は、[RFC3840]で定義されているように登録する必要があります。
The <description> element provides a textual description of the device as defined in [RFC3840].
<説明>要素は、[RFC3840]で定義されているデバイスのテキスト説明を提供します。
The <description> element is of string type and does not have any attributes.
<説明>要素は文字列型であり、属性はありません。
The <description> element SHOULD be labeled with the 'xml:lang' attribute to indicate its language and script. The specification allows multiple occurrences of this element so that the presentity can convey <description> elements in multiple scripts and languages. If no 'xml:lang' attribute is provided, the default value is "i-default" as defined in [RFC2277].
<説明>要素は、「XML：Lang」属性にラベルを付けて、その言語とスクリプトを示す必要があります。この仕様により、この要素の複数の発生が可能になるため、プレゼンテーションは複数のスクリプトと言語で<説明>要素を伝えることができます。'xml：lang'属性が提供されない場合、[RFC2277]で定義されているように、デフォルト値は「i-default」です。
The User Agent Capabilities extension [RFC3840] recommends that a UA provides complete information in its contact predicate. However, it may be that the presentity is not willing to publish presence information that would be consistent with actual device or service capabilities (e.g., presentity may not want to indicate that he/she supports voice when the service actually is able to support it). Authorization rules or policies in the presence server may limit or modify the presence information published by the presentity. Also, combining presence information from multiple sources may result in loss or mismatch of information.
ユーザーエージェント機能拡張[RFC3840]は、UAが連絡先の述語に完全な情報を提供することを推奨しています。ただし、プレゼンテーションは、実際のデバイスまたはサービス機能と一致するプレゼンス情報を公開する意思がない可能性があります（たとえば、プレゼンテーションは、サービスが実際にそれをサポートできるときに彼/彼女が音声をサポートしていることを示すことを望まないかもしれません）。存在するサーバーの承認ルールまたはポリシーは、プレゼンテーションによって公開された存在情報を制限または変更する場合があります。また、複数のソースからの存在情報を組み合わせると、情報の喪失または不一致が発生する場合があります。
It is RECOMMENDED that Presence User Agents (PUAs) using this extension provide as complete presence information as they can. If the PUA is publishing sensitive information using this extension, it SHOULD obtain permission from the presentity. PUAs can indicate the explicitly supported capabilities using the <supported> element, and the capabilities that are explicitly not supported using the <notsupported> element.
この拡張機能を使用して、プレゼンスユーザーエージェント（PUA）ができる限り完全な存在情報を提供することをお勧めします。PUAがこの拡張機能を使用して機密情報を公開している場合、現在から許可を得る必要があります。PUAは、<supported>要素を使用して明示的にサポートされている機能と、<notsupported>要素を使用して明示的にサポートされていない機能を示すことができます。
It is not mandated that presence information be consistent with actual service or device capabilities. However, it is in the presentity's best interest to avoid publishing false presence information and provide accurate information to help minimize unsuccessful communication invitations. Otherwise, watchers may conclude that communication cannot be established with the presentity, but in reality it would be possible; or watchers may conclude that certain communication capabilities are available, but in reality a communication establishment attempt would fail using those capabilities. In any case, watchers should not expect the presence information represented by this extension to be fully aligned with the actual presentity's service or device capabilities. As explained in Section 1.2, presence of this extension does not replace the use of SIP signaling for capability negotiation.
存在情報が実際のサービスまたはデバイスの機能と一致することは義務付けられていません。ただし、誤った存在情報の公開を避け、正確な情報を提供して、コミュニケーションの失敗を最小限に抑えるのに役立つ正確な情報を提供することは、プレゼンティの最大の関心です。そうでなければ、ウォッチャーは、コミュニケーションをプレゼンテーションで確立することはできないと結論付けるかもしれませんが、実際にはそれは可能です。または、ウォッチャーは特定の通信機能が利用可能であると結論付けることができますが、実際には、通信施設の試みはそれらの機能を使用して失敗するでしょう。いずれにせよ、ウォッチャーは、この拡張機能で表される存在情報が、実際のプレゼンティのサービスまたはデバイス機能と完全に整合することを期待してはなりません。セクション1.2で説明したように、この拡張の存在は、能力交渉のためのSIPシグナル伝達の使用に置き換わるものではありません。
PUAs should add information under <supported> and <notsupported> elements only when they believe it may affect the decision making in the watcher's end, i.e., information should be relevant and valuable for the watcher. Listing all possible information under <supported> and <notsupported> is rarely needed.
PUAは、<supported>および<notsupported>要素の下に情報を追加する必要があります。それがウォッチャーの終わりの意思決定に影響を与える可能性があると考えている場合にのみ、つまり、情報はウォッチャーにとって関連性が高く価値があるはずです。<supported>および<notsupported>の下にあるすべての可能な情報をリストすることはめったに必要ありません。
For example, if the PUA wants to advertise a message service that supports the MESSAGE method, it should add it under the <supported> element in the <methods> element. Even if the service does not support other methods, it is unlikely that listing all the methods not supported under the <notsupported> element would provide any value to the watcher.
たとえば、PUAがメッセージメソッドをサポートするメッセージサービスを宣伝したい場合、<メソッド>要素の<supported>要素の下に追加する必要があります。サービスが他の方法をサポートしていなくても、<notSupported>要素の下でサポートされていないすべてのメソッドをリストすると、ウォッチャーにあらゆる価値が提供される可能性は低いです。
In case of conflicting information, i.e., the same child element appears under the <supported> and <notsupported> elements with the same value, the watcher can safely assume that the listed capability is supported regardless of the inclusion of the capability under the <notsupported> element.
競合する情報、つまり、同じ子要素が同じ値を持つ<supported>および<notsupported>要素の下に同じ子要素が表示される場合、ウォッチャーは、リストされた機能が<notsupportedの下での機能を含めることに関係なくサポートされていると安全に想定できます。>要素。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:mod="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com">
<tuple id="joi9877866786ua9">
<status>
<basic>open</basic>
</status>
<caps:servcaps>
<caps:audio>true</caps:audio>
<caps:description xml:lang="en">
Example service
</caps:description>
<caps:description xml:lang="hu">
Pe'lda szolga'ltata's
</caps:description>
<caps:duplex>
<caps:supported>
<caps:full/>
</caps:supported>
</caps:duplex>
<caps:message>true</caps:message>
<caps:methods>
<caps:supported>
<caps:ACK/>
<caps:BYE/>
<caps:INVITE/>
<caps:MESSAGE/>
</caps:supported>
</caps:methods>
<caps:priority>
<caps:supported>
<caps:lowerthan maxvalue="10"/>
</caps:supported>
</caps:priority>
<caps:schemes>
<caps:supported>
<caps:s>sip</caps:s>
</caps:supported>
</caps:schemes>
<caps:video>false</caps:video>
</caps:servcaps>
<contact>sip:someone@example.com</contact>
</tuple>
<mod:device id="hgt67">
<caps:devcaps>
<caps:mobility>
<caps:supported>
<caps:mobile/>
</caps:supported>
</caps:mobility>
</caps:devcaps>
<mod:deviceID
>urn:uuid:d27459b7-8213-4395-aa77-ed859a3e5b3a</mod:deviceID>
</mod:device>
</presence>
This section gives the XML schema definitions for the extensions defined in this document. The namespace identifier for this schema is urn:ietf:params:xml:ns:pidf:caps.
このセクションでは、このドキュメントで定義されている拡張機能のXMLスキーマ定義を示します。このスキーマの名前空間識別子はurn：ietf：params：xml：ns：pidf：capsです。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:pidf:caps"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language
attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- ROOT -->
<xs:element name="servcaps" type="tns:servcapstype"/>
<xs:complexType name="servcapstype">
<xs:sequence>
<xs:element name="actor" type="tns:actortype"
minOccurs="0"/>
<xs:element name="application" type="tns:applicationtype"
minOccurs="0"/>
<xs:element name="audio" type="tns:audiotype" minOccurs="0"/>
<xs:element name="automata" type="tns:automatatype"
minOccurs="0"/>
<xs:element name="class" type="tns:classtype"
minOccurs="0"/>
<xs:element name="control" type="tns:controltype"
minOccurs="0"/>
<xs:element name="data" type="tns:datatype"
minOccurs="0"/>
<xs:element name="description" type="tns:descriptiontype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="duplex" type="tns:duplextype"
minOccurs="0"/>
<xs:element name="event-packages" type="tns:event-packagestype"
minOccurs="0"/>
<xs:element name="extensions" type="tns:extensionstype"
minOccurs="0"/>
<xs:element name="isfocus" type="tns:isfocustype"
minOccurs="0"/>
<xs:element name="message" type="tns:messagetype"
minOccurs="0"/>
<xs:element name="methods" type="tns:methodstype"
minOccurs="0"/>
<xs:element name="languages" type="tns:languagestype"
minOccurs="0"/>
<xs:element name="priority" type="tns:prioritytype"
minOccurs="0"/>
<xs:element name="schemes" type="tns:schemestype"
minOccurs="0"/>
<xs:element name="text" type="tns:texttype"
minOccurs="0"/>
<xs:element name="type" type="tns:typetype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="video" type="tns:videotype"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:element name="devcaps" type="tns:devcaps"/>
<xs:complexType name="devcaps">
<xs:sequence>
<xs:element name="description" type="tns:descriptiontype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="mobility" type="tns:mobilitytype"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<!-- AUDIO -->
<xs:simpleType name="audiotype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- APPLICATION -->
<xs:simpleType name="applicationtype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- DATA -->
<xs:simpleType name="datatype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- CONTROL -->
<xs:simpleType name="controltype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- VIDEO -->
<xs:simpleType name="videotype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- TEXT -->
<xs:simpleType name="texttype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- MESSAGE -->
<xs:simpleType name="messagetype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- TYPE -->
<xs:simpleType name="typetype">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!-- AUTOMATA -->
<xs:simpleType name="automatatype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- CLASS -->
<xs:complexType name="classtype">
<xs:sequence>
<xs:element name="supported" type="tns:classtypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:classtypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="classtypes">
<xs:sequence>
<xs:element name="business" type="xs:string"
minOccurs="0"/>
<xs:element name="personal" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- DUPLEX -->
<xs:complexType name="duplextype">
<xs:sequence>
<xs:element name="supported" type="tns:duplextypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:duplextypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="duplextypes">
<xs:sequence>
<xs:element name="full" type="xs:string"
minOccurs="0"/>
<xs:element name="half" type="xs:string"
minOccurs="0"/>
<xs:element name="receive-only" type="xs:string"
minOccurs="0"/>
<xs:element name="send-only" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- DESCRIPTION -->
<xs:complexType name="descriptiontype">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- EVENT-PACKAGES -->
<xs:complexType name="event-packagestype">
<xs:sequence>
<xs:element name="supported" type="tns:eventtypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:eventtypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="eventtypes">
<xs:sequence>
<xs:element name="conference" type="xs:string"
minOccurs="0"/>
<xs:element name="dialog" type="xs:string"
minOccurs="0"/>
<xs:element name="kpml" type="xs:string"
minOccurs="0"/>
<xs:element name="message-summary" type="xs:string"
minOccurs="0"/>
<xs:element name="poc-settings" type="xs:string"
minOccurs="0"/>
<xs:element name="presence" type="xs:string"
minOccurs="0"/>
<xs:element name="reg" type="xs:string"
minOccurs="0"/>
<xs:element name="refer" type="xs:string"
minOccurs="0"/>
<xs:element name="Siemens-RTP-Stats"
type="xs:string" minOccurs="0"/>
<xs:element name="spirits-INDPs"
type="xs:string" minOccurs="0"/>
<xs:element name="spirits-user-prof"
type="xs:string" minOccurs="0"/>
<xs:element name="winfo" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- PRIORITY -->
<xs:complexType name="prioritytype">
<xs:sequence>
<xs:element name="supported" type="tns:prioritytypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:prioritytypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="prioritytypes">
<xs:sequence>
<xs:element name="equals" type="tns:equalstype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="higherhan" type="tns:higherthantype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="lowerthan" type="tns:lowerthantype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="range" type="tns:rangetype"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="lowerthantype">
<xs:attribute name="maxvalue" type="xs:integer"
use="required"/>
</xs:complexType>
<xs:complexType name="higherthantype">
<xs:attribute name="minvalue" type="xs:integer"
use="required"/>
</xs:complexType>
<xs:complexType name="equalstype">
<xs:attribute name="value" type="xs:integer"
use="required"/>
</xs:complexType>
<xs:complexType name="rangetype">
<xs:attribute name="minvalue" type="xs:integer"
use="required"/>
<xs:attribute name="maxvalue" type="xs:integer"
use="required"/>
</xs:complexType>
<!-- METHODS -->
<xs:complexType name="methodstype">
<xs:sequence>
<xs:element name="supported" type="tns:methodtypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:methodtypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="methodtypes">
<xs:sequence>
<xs:element name="ACK" type="xs:string" minOccurs="0"/>
<xs:element name="BYE" type="xs:string" minOccurs="0"/>
<xs:element name="CANCEL" type="xs:string" minOccurs="0"/>
<xs:element name="INFO" type="xs:string" minOccurs="0"/>
<xs:element name="INVITE" type="xs:string" minOccurs="0"/>
<xs:element name="MESSAGE" type="xs:string" minOccurs="0"/>
<xs:element name="NOTIFY" type="xs:string" minOccurs="0"/>
<xs:element name="OPTIONS" type="xs:string" minOccurs="0"/>
<xs:element name="PRACK" type="xs:string" minOccurs="0"/>
<xs:element name="PUBLISH" type="xs:string" minOccurs="0"/>
<xs:element name="REFER" type="xs:string" minOccurs="0"/>
<xs:element name="REGISTER" type="xs:string" minOccurs="0"/>
<xs:element name="SUBSCRIBE" type="xs:string" minOccurs="0"/>
<xs:element name="UPDATE" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- EXTENSIONS -->
<xs:complexType name="extensionstype">
<xs:sequence>
<xs:element name="supported" type="tns:extensiontypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:extensiontypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="extensiontypes">
<xs:sequence>
<xs:element name="rel100" type="xs:string" minOccurs="0"/>
<xs:element name="early-session" type="xs:string" minOccurs="0"/>
<xs:element name="eventlist" type="xs:string" minOccurs="0"/>
<xs:element name="from-change" type="xs:string" minOccurs="0"/>
<xs:element name="gruu" type="xs:string" minOccurs="0"/>
<xs:element name="hist-info" type="xs:string" minOccurs="0"/>
<xs:element name="join" type="xs:string" minOccurs="0"/>
<xs:element name="norefersub" type="xs:string" minOccurs="0"/>
<xs:element name="path" type="xs:string" minOccurs="0"/>
<xs:element name="precondition" type="xs:string" minOccurs="0"/>
<xs:element name="pref" type="xs:string" minOccurs="0"/>
<xs:element name="privacy" type="xs:string" minOccurs="0"/>
<xs:element name="recipient-list-invite" type="xs:string"
minOccurs="0"/>
<xs:element name="recipient-list-subscribe" type="xs:string"
minOccurs="0"/>
<xs:element name="replaces" type="xs:string" minOccurs="0"/>
<xs:element name="resource-priority" type="xs:string" minOccurs="0"/>
<xs:element name="sdp-anat" type="xs:string" minOccurs="0"/>
<xs:element name="sec-agree" type="xs:string" minOccurs="0"/>
<xs:element name="tdialog" type="xs:string" minOccurs="0"/>
<xs:element name="timer" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- SCHEMES -->
<xs:complexType name="schemestype">
<xs:sequence>
<xs:element name="supported" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="s" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="notsupported" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="s" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!-- ACTOR -->
<xs:complexType name="actortype">
<xs:sequence>
<xs:element name="supported" type="tns:actortypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:actortypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="actortypes">
<xs:sequence>
<xs:element name="attendant" type="xs:string" minOccurs="0"/>
<xs:element name="information" type="xs:string" minOccurs="0"/>
<xs:element name="msg-taker" type="xs:string" minOccurs="0"/>
<xs:element name="principal" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- ISFOCUS -->
<xs:simpleType name="isfocustype">
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<!-- LANGUAGES -->
<xs:complexType name="languagestype">
<xs:sequence>
<xs:element name="supported" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="l" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="notsupported" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="l" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!-- MOBILITY -->
<xs:complexType name="mobilitytype">
<xs:sequence>
<xs:element name="supported" type="tns:mobilitytypes"
minOccurs="0"/>
<xs:element name="notsupported" type="tns:mobilitytypes"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="mobilitytypes">
<xs:sequence>
<xs:element name="fixed" type="xs:string"
minOccurs="0"/>
<xs:element name="mobile" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
IANA has registered one new XML namespace URN and one schema as defined in [RFC3688].
IANAは、[RFC3688]で定義されている1つの新しいXMLネームスペースURNと1つのスキーマを登録しています。
7.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:caps'
URI:
urn:ietf:params:xml:ns:pidf:caps
Description: This is the XML namespace for XML elements defined by RFC 5196 to describe service and device capabilities in application/pidf+xml content type.
説明：これは、アプリケーション/PIDF XMLコンテンツタイプのサービスとデバイス機能を記述するために、RFC 5196で定義されたXML要素のXMLネームスペースです。
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Mikko Lonnfors, <mikko.lonnfors@nokia.com>
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html> xmlns="http://www.w3.org/1999/xhtml"
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Namespace for PIDF user agent capability
extension</title>
</head>
<body>
<h1>Namespace for PIDF service capability extension</h1>
<h2>urn:ietf:params:xml:ns:pidf:caps</h2>
<p>
See <a href="http://www.rfc-editor.org/rfc/rfc5196.txt">RFC
5196</a>.
</p>
</body>
</html> END
</html>終了
7.2. Schema Registration for Schema
'urn:ietf:params:xml:schema:pidf:caps'
URI:
urn:ietf:params:xml:schema:pidf:caps
Registrant Contact: IESG
登録者の連絡先：IESG
XML: See Section 6
XML：セクション6を参照してください
All security considerations specified in [RFC3859] and [RFC3863] apply to this document. Compared to PIDF [RFC3863], this presence document format may reveal additional information about user's service and device capabilities. Thus, the PUA SHOULD always obtain permission from the presentity when publishing sensitive information using this extension.
[RFC3859]および[RFC3863]で指定されたすべてのセキュリティ上の考慮事項は、このドキュメントに適用されます。PIDF [RFC3863]と比較して、この存在ドキュメント形式は、ユーザーのサービスとデバイス機能に関する追加情報を明らかにする可能性があります。したがって、PUAは、この拡張機能を使用して機密情報を公開する際に、常にプレゼントから許可を得る必要があります。
Authors of this document would like to thank the following people for their contributions and valuable comments: Paul Kyzivat, Jonathan Rosenberg, Markus Isomaki, Eva Leppanen, Miguel Garcia, Jari Urpalainen, and Hisham Khartabil.
この文書の著者は、ポール・キジバット、ジョナサン・ローゼンバーグ、マルクス・イソマキ、エヴァ・レパネン、ミゲル・ガルシア、ジャリ・ウルパレーネン、ヒシャム・ハルタビルなど、次の人々に貢献と貴重なコメントに感謝したいと思います。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) part one: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2913] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.
[RFC2913] Klyne、G。、「メディア機能表現のMIMEコンテンツタイプ」、RFC 2913、2000年9月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3840] Schulzrinne, H., Rosenberg, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Schulzrinne、H.、Rosenberg、J。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]ピーターソン、J。、「存在の共通プロファイル（CPP）」、RFC 3859、2004年8月。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[RFC3863] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「存在情報データ形式（PIDF）」、RFC 3863、2004年8月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 4646、2006年9月。
[RFC2648] Moats, R., "A URN namespace for IETF documents", RFC 2648, August 1999.
[RFC2648] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[RFC3860]ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、2004年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4569] Camarillo, G., "Internet Assigned Numbers Authority (IANA) Registration of the Message Media Feature Tag", RFC 4569, July 2006.
[RFC4569] Camarillo、G。、「インターネットが割り当てられた番号局（IANA）メッセージメディア機能タグの登録」、RFC 4569、2006年7月。
Authors' Addresses
著者のアドレス
Mikko Lonnfors Nokia P.O. Box 321 Helsinki Finland
Mikko Lonfors Nokia P.O.ボックス321ヘルシンキフィンランド
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Krisztian Kiss Nokia 313 Fairchild Dr Mountain View, CA 94043 US
Krisztian Kiss Nokia 313 Fairchild Dr Mountain View、CA 94043 US
Phone: +1 650 391 5969
EMail: krisztian.kiss@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。