[要約] RFC 4479は、プレゼンス情報のデータモデルを定義するためのものであり、プレゼンス情報の共通の表現方法を提供します。目的は、異なるプレゼンスシステム間での相互運用性を向上させることです。
Network Working Group J. Rosenberg
Request for Comments: 4479 Cisco Systems
Category: Standards Track July 2006
A Data Model for Presence
存在のためのデータモデル
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion.
このドキュメントでは、インスタントメッセージングと存在感を活用するためにセッション開始プロトコル（SIP）で使用される基礎となる存在データモデルを定義します（シンプル）存在エージェント。データモデルは、さまざまな通信システムを一貫した方法で存在ドキュメントにマッピングする方法に関するガイダンスを提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
3. The Model .......................................................5
3.1. Presentity URI .............................................6
3.2. Person .....................................................7
3.3. Service ....................................................8
3.3.1. Characteristics .....................................9
3.3.2. Reach Information ..................................10
3.3.3. Relative Information ...............................13
3.3.4. Status .............................................13
3.4. Device ....................................................15
3.5. Modeling Ambiguity ........................................17
3.6. The Meaning of Nothing ....................................19
3.7. Status vs. Characteristics ................................19
3.8. Presence Document Properties ..............................20
4. Motivation for the Model .......................................21
5. Encoding .......................................................22
5.1. XML Schemas ...............................................24
5.1.1. Common Schema ......................................24
5.1.2. Data Model .........................................25
6. Extending the Presence Model ...................................26
7. Example Presence Document ......................................26
7.1. Basic IM Client ...........................................27
8. Security Considerations ........................................29
9. Internationalization Considerations ............................29
10. IANA Considerations ...........................................30
10.1. URN Sub-Namespace Registration ...........................30
10.2. XML Schema Registrations .................................31
10.2.1. Common Schema .....................................31
10.2.2. Data Model ........................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................32
Presence conveys the ability and willingness of a user to communicate across a set of devices. RFC 2778 [10] defines a model and terminology for describing systems that provide presence information. RFC 3863 [1] defines an XML [5] [6] [7] document format for representing presence information. In these specifications, presence information is modeled as a series of tuples, each of which contains a status, communications address, and other markup. However, neither specification gives guidance on exactly what a tuple is meant to model, or how to map real-world communications systems (and in particular, those built around the Session Initiation Protocol (SIP) [11]) into a presence document.
存在感は、ユーザーが一連のデバイスを介して通信する能力と意欲を伝えます。RFC 2778 [10]は、存在情報を提供するシステムを記述するためのモデルと用語を定義します。RFC 3863 [1]は、存在情報を表すためのXML [5] [6] [7]ドキュメント形式を定義します。これらの仕様では、存在情報は一連のタプルとしてモデル化されており、それぞれにステータス、通信アドレス、およびその他のマークアップが含まれています。ただし、どちらの仕様も、タプルがモデル化するものを正確にガイダンスしたり、実際の通信システム（特に、セッション開始プロトコル（SIP）[11]）を中心に構築されたものをマッピングする方法についてのガイダンスを提供しません。
In particular, several important concepts are not clearly modeled or well delineated by RFCs 2778 and 3863. These are the following:
特に、いくつかの重要な概念は、RFCS 2778および3863によって明確にモデル化されていないか、よく描写されていません。これらは次のとおりです。
Service: A communications service, such as instant messaging (IM) or telephony, is a system for interaction between users that provides certain modalities or content.
サービス：インスタントメッセージング（IM）やテレフォニーなどの通信サービスは、特定のモダリティまたはコンテンツを提供するユーザー間の対話のシステムです。
Device: A communications device is a physical component that a user interacts with in order to make or receive communications. Examples are a phone, PDA, or PC.
デバイス：通信デバイスは、ユーザーが通信を作成または受信するために対話する物理コンポーネントです。例は、電話、PDA、またはPCです。
Person: A person is the end user, and for the purposes of presence, is characterized by states, such as "busy" or "sad", that impact their ability and willingness to communicate.
人：人はエンドユーザーであり、存在の目的のために、「忙しい」や「悲しい」などの州によって特徴付けられ、それがコミュニケーションの能力と意欲に影響を与えます。
This specification defines these concepts more fully by means of a presence data model, and concretely defines how to take real-world systems and map them into presence documents using that model. This data model is defined in terms of an extension to RFC 3863.
この仕様は、これらの概念を存在データモデルを使用してより完全に定義し、実際のシステムを使用してそのモデルを使用して存在ドキュメントにマッピングする方法を具体的に定義します。このデータモデルは、RFC 3863の拡張に関して定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [9]に記載されているように解釈される。
This document makes use of many additional terms beyond those defined in RFC 2778 and RFC 3863. These new terms are as follows:
このドキュメントは、RFC 2778およびRFC 3863で定義されているものを超えた多くの追加の用語を使用しています。これらの新しい用語は次のとおりです。
Device: A device models the physical environment in which services manifest themselves for users. Devices have characteristics that are useful in allowing a user to make a choice about which communications service to use.
デバイス：デバイスは、サービスがユーザーに現れる物理環境をモデル化します。デバイスには、ユーザーが使用する通信サービスを選択できるようにするのに役立つ特性があります。
Service: A service models a form of communication that can be used to interact with the user.
サービス：サービスは、ユーザーと対話するために使用できる通信の形式をモデル化します。
Person: A person models the human user and their states that are relevant to presence systems.
人：人は、存在システムに関連する人間のユーザーとその状態をモデル化します。
Occurrence: A single description of a particular service, a particular device, or a person. There may be multiple occurrences for a particular service or device, or multiple person occurrences in a Presence Information Data Format (PIDF) document, in cases where there is ambiguity that is best resolved by the watcher.
発生：特定のサービス、特定のデバイス、または人の単一の説明。ウォッチャーが最もよく解決するあいまいさがある場合、特定のサービスまたはデバイス、または存在情報データ形式（PIDF）ドキュメントで複数の発生がある場合があります。
Presentity: A presentity combines devices, services, and person information for a complete picture of a user's presence status on the network.
プレゼンティー：プレゼンテーションは、ネットワーク上のユーザーの存在状態の完全な画像の完全な画像のために、デバイス、サービス、および個人情報を組み合わせます。
Presentity URI: A URI that acts as a unique identifier for a presentity and provides a handle for obtaining presence information about that presentity.
プレゼンティURI：プレゼンテーションのための一意の識別子として機能し、そのプレゼンテーションに関する存在情報を取得するためのハンドルを提供するURI。
Data Component: One of the device, service, or person parts of a presence document.
データコンポーネント：プレゼンスドキュメントのデバイス、サービス、または個人の一部の1つ。
Status: Presence information about a service, person, or device that typically changes over time, in contrast to characteristics, which are generally static.
ステータス：一般的に静的な特性とは対照的に、通常、時間の経過とともに変化するサービス、個人、またはデバイスに関する存在情報。
Characteristics: Presence information about a service, person, or device that is usually fixed over time, and descriptive in nature. Characteristics are useful in providing context that identifies the service or device as different from another service or device.
特性：通常は時間の経過とともに固定され、本質的に記述的なサービス、個人、またはデバイスに関する存在情報。特性は、サービスまたはデバイスを別のサービスまたはデバイスとは異なるものとして識別するコンテキストを提供するのに役立ちます。
Attribute: A status or characteristic. It represents a single piece of presence information.
属性：ステータスまたは特性。存在情報の単一の部分を表します。
Presence Attribute: A synonym for attribute.
存在属性：属性の同義語。
Composition: The act of combining a set of presence and event data about a presentity into a coherent picture of the state of that presentity.
構成：プレゼンテーションに関する一連の存在とイベントデータを、そのプレゼンテーションの状態の一貫した絵に組み合わせる行為。
+----------------------------------------------------------------+
| |
| +----------------+ |
| +----------------+| |
| | || |
| | || |
| | Person || |
| | ||\ |
| /| |+ \ |
| / +----------------+ \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| V V V |
| +----------------+ +----------------+ +----------------+ |
| +----------------+| +----------------+| +----------------+| |
| | || | || | || |
| | || | || | || |
| | Service || | Service || | Service || |
| | || | || | || |
| | |+ | |+ | |+ |
| +----------------+ +----------------+ +----------------+ |
| \ / \ |
| \ / \ |
| \ / \ |
| V V V |
| +----------------+ +----------------+ |
| +----------------+| +----------------+| |
| | || | || |
| | || | || |
| | Device || | Device || |
| | || | || |
| | |+ | |+ |
| +----------------+ +----------------+ |
| |
| |
| Presentity (URI) |
+----------------------------------------------------------------+
Figure 1
図1
The data model for presence is shown in Figure 1. The model seeks to describe the presentity, identified by a presentity URI. There are three components in the model: the person, the service, and the device. These three data components contain information (called attributes) that provide a description of some aspect of the service, person, or device. It is central to this model that each attribute is affiliated with the service, person, or device because they describe that service, presentity, or device. This is in contrast to a model whereby the attributes are associated with the service, presentity, or device because they were reported by that service, presentity, or device. As an example, if a cell phone reports that a user is in a meeting, this would be done by including an attribute as part of the person information, indicating a status of "in-a-meeting". The presence information may also include information on the cell phone as a device. However, even though it is the device that is reporting that the user is in a meeting, "in a meeting" is a fact that describes the human user, not their physical device. Consequently, this attribute is placed in the person component of the document.
存在のデータモデルを図1に示します。モデルは、プレゼンテーションURIによって識別されるプレゼントを説明しようとしています。モデルには、人、サービス、デバイスの3つのコンポーネントがあります。これらの3つのデータコンポーネントには、サービス、個人、またはデバイスのいくつかの側面の説明を提供する情報（属性と呼ばれる）が含まれています。各属性がサービス、プレゼンテーション、またはデバイスを説明するため、各属性がサービス、個人、またはデバイスに所属することがこのモデルの中心です。これは、属性がサービス、プレゼンテーション、またはデバイスに関連付けられるモデルとは対照的です。これは、そのサービス、プレゼンテーション、またはデバイスによって報告されたためです。例として、携帯電話がユーザーが会議に参加していると報告している場合、これは個人情報の一部として属性を含めることによって行われ、「In-A-Meeting」のステータスを示します。存在情報には、デバイスとしての携帯電話の情報も含まれる場合があります。ただし、ユーザーが会議中にいることを報告しているのはデバイスですが、「会議で」は、物理デバイスではなく、人間のユーザーを説明する事実です。その結果、この属性はドキュメントの人物コンポーネントに配置されます。
The identifier for the presentity is a URI. For each unique presentity in the network, there is one or more presentity URIs. A presentity may have multiple URIs because they are identified by both a URI from the Presence (pres) scheme [12] and a protocol-specific URI, such as a SIP URI [11] or an Extensible Messaging and Presence Protocol Internationalized Resource Identifier (XMPP IRI) [13]. Or, it can be because a user has several aliases in a domain, all of which are equivalent identifiers for the presentity.
プレゼンテーションの識別子はURIです。ネットワーク内のユニークなプレゼンテーションごとに、1つまたは複数のプレゼンテーションがあります。プレゼンス（PRES）スキーム[12]のURIと、SIP URI [11]または拡張可能なメッセージングおよび存在プロトコル国際化リソース識別子（XMPP IRI）[13]。または、ユーザーがドメインにいくつかのエイリアスを持っているためである可能性があります。これらはすべて、プレゼンテーションの同等の識別子です。
When a document is constructed, the presentity URI is ideally set to the identifier used to request the document in the first place. For example, if a document was requested through a SIP SUBSCRIBE request, the presentity URI would match the Request URI of the SUBSCRIBE request. This follows the principle of least surprise, since the entity requesting the document may not be aware of the other identifiers for the presentity.
ドキュメントが構築されると、プレゼンティURIは、そもそもドキュメントを要求するために使用される識別子に理想的に設定されます。たとえば、SIPサブスクライブリクエストを通じてドキュメントが要求された場合、プレゼンティURIは、サブスクライブリクエストのリクエストURIと一致します。これは、ドキュメントを要求するエンティティがプレゼンテーションの他の識別子を認識していない可能性があるため、最も驚きの原則に従います。
Irrespective of the scheme from which the URI is taken, the presentity URI is independent of any of the services or devices that the presentity possesses. However, the URI is not just a name - it represents a resource that can be subscribed to, in order to find out the status of the user. When the URI is a SIP URI, it will often be the Address of Record for the user, to which SIP calls can be directed. This equivalence is not mandated by this specification, but is a recommended configuration for easing the burden of remembering and storing identifiers for users.
URIが取られているスキームに関係なく、プレゼンテーションURIは、現在のサービスまたはデバイスのいずれかとは独立しています。ただし、URIは単なる名前ではありません。ユーザーのステータスを見つけるために、購読できるリソースを表します。URIがSIP URIである場合、それは多くの場合、ユーザーの記録のアドレスになり、SIPコールを指示できます。この同等性は、この仕様では義務付けられていませんが、ユーザーの識別子を記憶して保存する負担を緩和するための推奨される構成です。
The person data component models information about the user whom the presence data is trying to describe. This information consists of characteristics of the user, and their status.
個人データコンポーネントは、存在データが説明しようとしているユーザーに関する情報をモデル化します。この情報は、ユーザーの特性とそのステータスで構成されています。
Characteristics of a person are the static information about a user that does not change under normal circumstances. Such information might include physical characteristics, such as age and height. Another example of a person characteristic is an alias. An alias is a URI that identities the same user, but with a different presentity URI. For example, a presentity "sip:bob@example.com" might have a presence document with a person component that indicates an alias of "sip:robert@example.com" and "sip:r.smith@example.com".
人の特性は、通常の状況では変わらないユーザーに関する静的情報です。このような情報には、年齢や身長などの物理的特性が含まれる場合があります。人の特徴の別の例はエイリアスです。エイリアスは、同じユーザーをIDとするURIですが、異なるプレゼンティURIを使用しています。たとえば、「sip：sip：robert@example.com」と「sip：r.smith@example.com」のエイリアスを示す個人コンポーネントを含むプレゼンスドキュメントがある場合があります。
Status information about a presentity represents the dynamic information about a user. This typically consists of things the *user* is doing, places the *user* is at, feelings the *user* has, and so on. Examples of typical person status are "in a meeting", "on the phone", "out to lunch", "happy", and "writing Internet Drafts". The line between static status information and dynamic status information is fuzzy, and it is not important that a line be drawn. The model does not differentiate in a syntactically or semantically meaningful way between these two types of attributes.
提示に関するステータス情報は、ユーザーに関する動的な情報を表します。これは通常、 *ユーザー *がしていること、 *ユーザー *がある場所、 *ユーザー *が持っている感情などで構成されています。典型的な人のステータスの例は、「会議中」、「電話で」、「昼食から」、「ハッピー」、「インターネットドラフトの執筆」です。静的ステータス情報と動的ステータス情報の間の線はファジーであり、行を描画することは重要ではありません。このモデルは、これら2つのタイプの属性間で構文的または意味的に意味のある方法で区別されません。
In the model, there can be only one person component per presentity. In other words, the person component models a single human being, and includes characteristics and statuses that are related to the communication states for a single human being. Of course, the system has no way to verify that the human described by the person component is actually a single human being, as opposed to a group of users, or even a dog for that matter. As the saying goes, "on the Internet, no one knows you are a dog", and the same is true here. The person component is a facade for a single person; anything that can be made to look like a single person can be modeled with that facade.
モデルでは、プレゼンテーションごとに1人のコンポーネントしか存在できません。言い換えれば、人間コンポーネントは単一の人間をモデル化し、単一の人間のコミュニケーション状態に関連する特性とステータスを含んでいます。もちろん、システムには、人間の要素によって記述された人間が実際には、ユーザーのグループや犬でさえも、単一の人間であることを確認する方法はありません。「インターネットでは、あなたが犬であることを誰も知らない」ということわざにあるように、ここでも同じことが言えます。人コンポーネントは、一人のファサードです。一人の人のように見えるようにすることができるものはすべて、そのファサードでモデル化できます。
As an example, consider the task of using a presence document to describe a customer support help desk. The person component can be considered to be "busy" if none of the support staff are available, and "at lunch" if the help desk department has a group lunch together. The watcher that receives the document will consider the help desk to be a single person; nothing in the document (except perhaps the note element, should its value be "help desk" or something similar) conveys information that would indicate that the person in question is actually a help desk.
例として、プレゼンスドキュメントを使用してカスタマーサポートヘルプデスクを説明するタスクを検討してください。人物は、サポートスタッフがいない場合は「忙しい」と見なすことができます。ヘルプデスク部門が一緒にグループランチを持っている場合は、「昼食時」になります。ドキュメントを受け取るウォッチャーは、ヘルプデスクが一人であると考えるでしょう。ドキュメント内の（おそらくメモ要素を除く、その価値が「ヘルプデスク」または類似のものである場合）は、問題の人が実際にヘルプデスクであることを示す情報を伝えません。
However, there can be multiple occurrences of the person component. This happens in cases where the state of the person component is ambiguous, as discussed in Section 3.5.
ただし、個人コンポーネントの複数の発生があります。これは、セクション3.5で説明されているように、個人コンポーネントの状態が曖昧な場合に発生します。
Each presentity has access to a number of services. Each of these represents a point of reachability for communications that can be used to interact with the user. Examples of services are telephony (that is, traditional circuit-based telephone service), push-to-talk, instant messaging, Short Message Service (SMS), and Multimedia Message Service (MMS).
各プレゼンテーションには、多くのサービスにアクセスできます。これらはそれぞれ、ユーザーとの対話に使用できる通信の到達可能性のポイントを表しています。サービスの例は、テレフォニー（つまり、従来のサーキットベースの電話サービス）、プッシュツートーク、インスタントメッセージング、ショートメッセージサービス（SMS）、およびマルチメディアメッセージサービス（MMS）です。
It is difficult to give a precise definition for service. One reasonable approach is to model each software or hardware agent in the system as a service. If a user starts a softphone application on their PC, then that represents a service. If a user has a videophone device, then that represents another service. This is effectively a physical view of services. This definition, however, starts to fall apart when a service is spread across multiple software agents or devices. For example, a SIP URI representing an address-of-record can be routed to a softphone or a videophone, or both. In that case, one might attempt instead to define a service based on its address on the network. This definition also falls apart when modeling devices or applications that receive calls and dispatch them to different "helpers" based on potentially complex logic. For example, a cellular telephone might house multiple SIP applications, each of which can "register" different handlers based on the method or even body type of the request. Each of those applications or handlers can rightfully be considered a service, but it doesn't have an address on the network distinct from the others.
サービスの正確な定義を提供することは困難です。合理的なアプローチの1つは、システム内の各ソフトウェアまたはハードウェアエージェントをサービスとしてモデル化することです。ユーザーがPCでソフトフォンアプリケーションを起動する場合、それはサービスを表します。ユーザーがビデオフォンデバイスを持っている場合、それは別のサービスを表します。これは事実上、サービスの物理的な見方です。ただし、この定義は、複数のソフトウェアエージェントまたはデバイスにサービスが広がると、バラバラになり始めます。たとえば、レコードアドレスを表すSIP URIは、ソフトフォンまたはビデオ恐怖症、またはその両方にルーティングできます。その場合、ネットワーク上のアドレスに基づいてサービスを定義しようとする場合があります。この定義は、潜在的に複雑なロジックに基づいて、コールを受信してそれらを異なる「ヘルパー」に派遣するデバイスまたはアプリケーションをモデリングすると、バラバラになります。たとえば、携帯電話には複数のSIPアプリケーションが収容される場合があり、それぞれがリクエストのメソッドまたはボディタイプに基づいて異なるハンドラーを「登録」できます。これらのアプリケーションまたはハンドラーはそれぞれサービスと見なすことができますが、ネットワーク上に他のアプリケーションとは異なるアドレスがありません。
Because of this inherent difficulty in precisely defining a service, the data model doesn't try to constrain what can be considered a service. Rather, anything can be considered a service so long as it exhibits a set of key properties defined by this model. In particular, each service is associated with characteristics that identify the nature and capabilities of that service, with reach information that indicates how to connect to the service, with status information representing the state of that service, and relative information that describes the ways in which that service relates to others associated with the presentity.
サービスを正確に定義するのがこの固有の困難のため、データモデルはサービスと見なされるものを制約しようとはしません。むしろ、このモデルで定義された一連のキープロパティを示す限り、何でもサービスと見なすことができます。特に、各サービスは、そのサービスの性質と能力を識別する特性と、サービスに接続する方法を示すリーチ情報、そのサービスの状態を表すステータス情報、およびその方法を説明する相対的な情報に関連付けられています。そのサービスは、プレゼンテーションに関連する他者に関連しています。
As a consequence, in this model, services are not explicitly enumerated. There is no central registry where one finds identifiers for each service. Consequently, each service does not have a single "service" attribute with values such as "ptt" or "telephony". That doesn't mean that these consolidated monikers aren't useful; indeed, they represent an essential summary of what the service is. Such summarization is useful in creating icons that allow a user to choose one service over another. A watcher is free to create such summarization information from any of the information associated with a service. The reach information often provides valuable information for creating such a summarization. Oftentimes, the scheme of the URI is synonymous with the view of what a service is. An "sms" URI [14] clearly indicates SMS, for example. For some URIs, there may be many services available, for example, SIP or tel [15], in which case the scheme is less meaningful as a way of creating a summary. The reach information could also indicate that certain application software has to be invoked (such as a videogame), in which case that aspect of the reach information would be useful for generating an iconic representation of the game.
結果として、このモデルでは、サービスは明示的に列挙されていません。各サービスの識別子を見つける中央レジストリはありません。したがって、各サービスには、「PTT」や「テレフォニー」などの値を持つ単一の「サービス」属性がありません。それは、これらの統合されたモニカが役に立たないという意味ではありません。実際、それらはサービスが何であるかの本質的な要約を表しています。このような要約は、ユーザーが別のサービスよりも1つのサービスを選択できるアイコンを作成するのに役立ちます。ウォッチャーは、サービスに関連する情報のいずれかからそのような要約情報を無料で作成できます。リーチ情報は、多くの場合、このような要約を作成するための貴重な情報を提供します。多くの場合、URIのスキームは、サービスが何であるかの見解と同義です。たとえば、「SMS」URI [14]はSMSを明確に示しています。一部のURIでは、SIPやTel [15]など、多くのサービスが利用可能になる場合があります。その場合、スキームは要約を作成する方法としてあまり意味がありません。リーチ情報は、特定のアプリケーションソフトウェアを呼び出す必要があること（ビデオゲームなど）を示している可能性があります。その場合、リーチ情報の側面がゲームの象徴的な表現を生成するのに役立ちます。
Each service is adorned with characteristics that describe the nature and capabilities of the service that will be experienced when a watcher invokes that URI. The nature of a service is a set of properties that are relatively static across communication sessions established to that service. The nature of a service tends to be descriptive. Examples of the nature of a service are that it represents an interactive voice response or voicemail server, that it is an automaton, or that it is a telephony service used for the purposes of work. Capabilities, on the other hand, represent properties that might be exhibited, and whether they are exhibited depends on negotiation and other dynamic functions that take place during session establishment. Examples of such capabilities are the type of media that might be used, the directionality of communications that are permitted, the SIP extensions supported, and so on. Capabilities can be very complex; for example, RFC 2533 [16] describes a model for representing capabilities through N-ary boolean functions. It is difficult to differentiate a capability with one modality (e.g., this service only does voice) from a characteristic that represents the nature of a service. However, it is not important to do so.
各サービスは、ウォッチャーがそのURIを呼び出すときに経験されるサービスの性質と能力を説明する特性で飾られています。サービスの性質は、そのサービスに確立された通信セッション全体で比較的静的なプロパティのセットです。サービスの性質は説明的である傾向があります。サービスの性質の例は、インタラクティブな音声応答またはボイスメールサーバーを表し、オートマトンであること、または作業の目的に使用されるテレフォニーサービスであることです。一方、能力は、展示される可能性のあるプロパティを表し、それらが展示されるかどうかは、セッションの確立中に行われる交渉やその他の動的機能に依存します。このような機能の例は、使用される可能性のあるメディアのタイプ、許可されている通信の方向性、サポートされているSIP拡張機能などです。機能は非常に複雑になる可能性があります。たとえば、RFC 2533 [16]は、n-aryブール機能を介して機能を表現するためのモデルを説明しています。サービスの性質を表す特性から、1つのモダリティ（たとえば、このサービスのみが音声のみを行う）で機能を区別することは困難です。ただし、そうすることは重要ではありません。
Characteristics are important when multiple services are indicated. That is because the purpose of listing multiple services in a presence document is to give the watcher a *choice*. That is, the presentity is explicitly offering the watcher an opportunity to contact them using a multiplicity of different services. To help the watcher make a decision, the presence document includes characteristics of each service that help differentiate the services from each other and give the watcher the context in which to make a choice.
複数のサービスが示されている場合、特性は重要です。それは、プレゼンスドキュメントに複数のサービスをリストする目的は、ウォッチャーに *選択 *を与えることだからです。つまり、プレゼンテーションは、さまざまなサービスの多様性を使用して、ウォッチャーに連絡する機会を明示的に提供しています。ウォッチャーが決定を下すのを支援するために、存在ドキュメントには、サービスを相互に区別し、ウォッチャーに選択を行うためのコンテキストを提供する各サービスの特性が含まれています。
Because their purpose is primarily to facilitate choice, capabilities do not impose a requirement on the way in which a user reaches that service. For example, if a presence document includes two services, and one supports audio only while the other supports only video, this does not mean that, when contacting the first service, a user has to offer only an audio stream, or when contacting the second service, a user has to offer only a video stream. A user can use local policy at its discretion in determining what capabilities or communications modalities are offered when they choose to connect with a service. It is not necessary for a watcher to add SIP caller preferences [2] to request routing of the request to a service with the characteristics described in the presence document.
彼らの目的は主に選択を促進することであるため、能力はユーザーがそのサービスに到達する方法に要件を課しません。たとえば、プレゼンスドキュメントに2つのサービスが含まれており、1つはオーディオのみをサポートし、もう1つはビデオのみをサポートしている場合、これは最初のサービスに連絡するとき、ユーザーはオーディオストリームのみを提供するか、2番目のサービスに連絡するときは、サービス、ユーザーはビデオストリームのみを提供する必要があります。ユーザーは、サービスに接続することを選択したときに提供される機能または通信のモダリティを決定する際に、その裁量でローカルポリシーを使用できます。WatcherがSIP発信者の設定[2]を追加して、プレゼンスドキュメントで説明されている特性を使用してリクエストのルーティングをリクエストする必要はありません。
If, in order to reach a service, the user agent must generate a request that exhibits a particular capability or contains a specific header, then this is indicated separately in the reach information, described below.
サービスに到達するために、ユーザーエージェントが特定の機能を示すか、特定のヘッダーを含むリクエストを生成する必要がある場合、これは以下に説明するリーチ情報に個別に示されます。
One important characteristic of each service is the list of devices on which that service executes. Each device is identified uniquely by a device ID. As such, the service characteristics can include a list of device IDs. A presence document might also contain information on each device, but this is a separate part of the document. Indeed, the information on each device might not even be present in the document. In that case, the device IDs listed for each service are nothing more than correlation identifiers, useful for determining when two services run on the same device. The benefit of this model is that information on the devices can be filtered out of a presence document, yet the service information, which includes the device IDs, remains useful and meaningful.
各サービスの重要な特徴の1つは、そのサービスが実行されるデバイスのリストです。各デバイスは、デバイスIDによって一意に識別されます。そのため、サービスの特性には、デバイスIDのリストを含めることができます。プレゼンスドキュメントには各デバイスの情報も含まれている場合がありますが、これはドキュメントの別の部分です。実際、各デバイスの情報はドキュメントに存在することさえないかもしれません。その場合、各サービスにリストされているデバイスIDは、相関識別子にすぎず、同じデバイスで2つのサービスがいつ実行されるかを判断するのに役立ちます。このモデルの利点は、デバイスに関する情報をプレゼンスドキュメントからフィルタリングできるが、デバイスIDを含むサービス情報は有用で意味のあるものであることです。
It is perfectly valid for a presence document to contain just a single service. This is permitted even if the presentity actually has multiple services at their disposal. The lack of multiple services in the document merely means that the presentity is not offering a choice to the watcher. In such a case, the service characteristics are less important, but may be helpful in allowing a watcher to decide if they wish to communicate at all.
プレゼンスドキュメントが1つのサービスのみを含むことは完全に有効です。これは、実際に自由に使用できる複数のサービスを提供していても、これは許可されています。ドキュメントに複数のサービスが不足しているということは、単にプレゼンテーションがウォッチャーに選択肢を提供していないことを意味します。そのような場合、サービス特性はそれほど重要ではありませんが、ウォッチャーがコミュニケーションを希望するかどうかを決定できるようにするのに役立つ場合があります。
The reach information for a service provides the instructions for the recipient of a document on how to correctly contact that service.
サービスのリーチ情報は、そのサービスに正しく連絡する方法に関するドキュメントの受信者に指示を提供します。
When a service is accessible over a communications network, reach information includes a URI that can be "hit" to access the service. This URI is called the service URI. However, some services are not accessible over a communications network (such as in-person communications or a written letter), and as such, may not utilize a URI.
通信ネットワークでサービスにアクセスできる場合、リーチ情報には、サービスにアクセスするために「ヒット」できるURIが含まれています。このURIはサービスURIと呼ばれます。ただし、一部のサービスは、通信ネットワーク（対面通信や書面による手紙など）でアクセスできないため、URIを利用しない場合があります。
Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched for other body types. As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched.
通信ネットワークを介して到達可能なサービスであっても、URIだけでは十分ではない場合があります。たとえば、2つのアプリケーションが携帯電話内で実行されている場合がありますが、どちらもユーザーのSIPアドレスを介して到達可能です。ただし、招待リクエストに特定のタイプの本文が含まれている場合、1つのアプリケーションが起動され、もう1つのアプリケーションは他のボディタイプに対して起動されます。別の例として、サービスは、マッチングアプリケーションソフトウェアから連絡した場合にのみ正しく動作する複雑なアプリケーションロジックを提供する場合があります。このような場合、インスタンス間の通信が標準プロトコル（SIPなど）を利用している場合でも、アプリケーションが一致しない限り、ユーザーエクスペリエンスは正しくありません。
When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information.
URIで十分でない場合、サービスの追加属性が存在する可能性があり、サービスの到達方法に関する指示を定義できます。これらの属性は、サービスを利用するために理解する必要があります。ウォッチャーがリーチ情報を含むプレゼンスドキュメントを受け取った場合、それが理解していないリーチ情報を受け取った場合、サービス情報を破棄する必要があります。
The reach information is an important part of the service. When the watcher makes a decision about which service of the presentity they wish to access, the watcher utilizes the reach information for that service. For this reason, each service has to have a unique set of reach information. If this was not the case, the user would have no way to choose between the services. This means that the reach information represents a unique identifier for the service. However, a presence document can contain multiple occurrences of a particular service, each of which contains the same reach information, but differs in its occurrence identifier. Multiple occurrences of a service exist in a document when the state of the service is ambiguous, as discussed in Section 3.5.
リーチ情報はサービスの重要な部分です。ウォッチャーがアクセスを希望するサービスのどのサービスを決定すると、ウォッチャーはそのサービスのリーチ情報を利用します。このため、各サービスには一意のリーチ情報セットが必要です。そうでない場合、ユーザーはサービスを選択する方法がありません。これは、リーチ情報がサービスの一意の識別子を表すことを意味します。ただし、プレゼンスドキュメントには、特定のサービスの複数の発生を含めることができます。各サービスには同じリーチ情報が含まれていますが、その発生識別子は異なります。セクション3.5で説明したように、サービスの状態が曖昧な場合、ドキュメントにはサービスの複数の発生が存在します。
Because the reach information serves as an identifier for a service, it also serves as a way to figure out whether a communications capability should be represented as one service or more. Something cannot be a service unless there is a way to reach it separately from another service. As an example, consider a softphone application that is capable of audio and video. It is not possible to describe this softphone as two services - one capable of just audio, and one capable of just video. That's because there is no way to reach the video-only service; for example, sending a SIP INVITE with just a video stream doesn't suffice, since one can always add the audio stream later and it will work. Video and audio, in this case, represent capabilities for a single service.
リーチ情報はサービスの識別子として機能するため、通信機能を1つ以上のサービスとして表現する必要があるかどうかを把握する方法としても機能します。別のサービスとは別に到達する方法がない限り、何かがサービスになることはできません。例として、オーディオとビデオが可能なソフトフォンアプリケーションを検討してください。このソフトフォンを2つのサービスと表現することはできません。1つはオーディオだけで、もう1つはビデオだけです。それは、ビデオのみのサービスに到達する方法がないからです。たとえば、ビデオストリームだけでSIP Inviteを送信するだけでは十分ではありません。なぜなら、後でオーディオストリームを常に追加して機能するからです。この場合、ビデオとオーディオは、単一のサービスの機能を表しています。
The reach information represents a weak form of contract; the presentity tells the watcher that, if the watcher utilizes the reach information included in the presence document, the watcher might be connected to a service described by the characteristics included in the presence document. It is important to stress that this is not a guarantee in any way. It cannot be a guarantee for two reasons. First, the service in the document might actually be modelling a number of actual services used by the user, and it may not be possible to connect the watcher to a service with all of the characteristics described in the presence document. Second, the preferences of the presentity always take precedence. The caller might ask to be connected to the video service, but it is permissible to connect them to a different service if that is the wish of the presentity.
リーチ情報は、契約の弱い形式を表しています。プレゼントは、ウォッチャーがプレゼンスドキュメントに含まれるリーチ情報を利用している場合、ウォッチャーがプレゼンスドキュメントに含まれる特性によって記述されたサービスに接続される可能性があることをウォッチャーに伝えます。これが決して保証ではないことを強調することが重要です。2つの理由で保証することはできません。まず、ドキュメント内のサービスは実際にユーザーが使用する多くの実際のサービスをモデル化している可能性があり、WatcherをPresenceドキュメントで説明したすべての特性を使用してサービスに接続することはできない場合があります。第二に、プレゼントの好みが常に優先されます。発信者はビデオサービスに接続するように求めるかもしれませんが、それが現在の希望である場合、それらを別のサービスに接続することは許可されます。
This loose contract also provides some guidance on the type of URI that is most ideally suited for the service URI. A URN [3] can be used as the service URI. However, since a URN could be resolved to potentially any number of different URIs, the characteristics, status, and relative information need to be sensible for all of the URIs that can be resolved from the URN. As the URN becomes increasingly "vague" in terms of the service it identifies, the number of presence attributes that can be included decreases correspondingly.
このゆるい契約は、サービスURIに最も理想的なURIのタイプに関するガイダンスも提供します。ur [3]はサービスURIとして使用できます。ただし、URNは潜在的に任意の数の異なるURIに解決できるため、特性、ステータス、および相対的な情報は、URNから解決できるすべてのURIに対して賢明である必要があります。urが特定するサービスの観点からますます「曖昧」になると、含まれる存在属性の数はそれに応じて減少します。
The tel URI [11] shares similar properties with a URN, and the same considerations apply. If, for example, the telephone number exists in ENUM [18] and multiple ENUM services are defined, including voice and messaging, it is likely that very little characteristic information can be included in that service. If, however, a tel URI has only a single ENUM service defined, and it refers to a telephone service on the Public Switched Telephone Network (PSTN), more can be said about its characteristics, status, and relative priority.
Tel URI [11]は、同様のプロパティをURNと共有しており、同じ考慮事項が適用されます。たとえば、電話番号がEnum [18]に存在し、音声やメッセージングを含む複数の列挙サービスが定義されている場合、そのサービスにはほとんど特徴的な情報を含めることができない可能性があります。ただし、Tel URIには1つの列挙サービスのみが定義されており、公開された電話ネットワーク（PSTN）の電話サービスを指す場合、その特性、ステータス、および相対的な優先事項についてさらに言えます。
It is important to point out that there can be a many-to-one mapping of reach information to a service. That is, a particular service can potentially be reachable through an infinite number of reach information sets. This is true even if the reach information is just the service URI; it is permissible for multiple service URIs to reach the same service. Within any particular document, for a particular service, there will be a single service URI. However, it is allowed and even valuable to provide different service URIs to different watchers, or to change the service URIs provided to a particular watcher over time. Doing so affords many benefits, in fact. It can allow the recipient of a communications attempt to determine the context for that attempt - that the attempt was made as a result of trying to reach a particular service in a particular presence document. This can be used as a technique for preventing communications spam, for example [19].
サービスへのリーチ情報の多面マッピングがある可能性があることを指摘することが重要です。つまり、特定のサービスは、無限の数のリーチ情報セットを通じて到達可能になる可能性があります。リーチ情報が単なるサービスURIであっても、これは当てはまります。複数のサービスURIが同じサービスに到達することは許可されています。特定のドキュメント内では、特定のサービスの場合、単一のサービスURIがあります。ただし、異なるウォッチャーにさまざまなサービスを提供したり、特定のウォッチャーに提供されたサービスを時間の経過とともに変更することも許可されており、さらに価値があります。実際には、多くの利点が得られます。コミュニケーションの試みの受信者が、その試みのコンテキストを決定しようとすることができます - 特定のプレゼンスドキュメントで特定のサービスに到達しようとした結果として試みがなされました。これは、たとえば[19]などの通信スパムを防ぐための手法として使用できます。
It is also possible for a presence document to contain a service that has no reach information at all. In such a case, the presentity is indicating that the service exists, but is electing not to offer the watcher the opportunity to connect to it. One such example would be to let a watcher know that a user has a telephony service, and that they are busy, but in order to avoid receipt of a call, no reach information is provided.
また、プレゼンスドキュメントにリーチ情報がまったくないサービスを含めることもできます。そのような場合、プレゼンテーションはサービスが存在することを示していますが、ウォッチャーにそれに接続する機会を提供しないことを選択しています。そのような例の1つは、ユーザーがテレフォニーサービスを持っていること、そして忙しいことをウォッチャーに知らせることですが、通話の受信を避けるためには、リーチ情報が提供されません。
In an ideal system, the URI alone would represent sufficient reach information for each service. A URI is supposed to provide sufficient context for reaching the resource associated with the URI, and thus in theory there is no need for additional context. However, sometimes, additional information is needed. Since the reach information has to be understood in order for the service to be utilized, reach information beyond the URI should be defined and used sparingly. Extensions to PIDF that define attributes that are reach information should clearly call those attributes out as such.
理想的なシステムでは、URIだけが各サービスの十分なリーチ情報を表します。URIは、URIに関連するリソースに到達するための十分なコンテキストを提供することになっているため、理論的には追加のコンテキストは必要ありません。ただし、追加情報が必要な場合があります。サービスを利用するには、リーチ情報を理解する必要があるため、URIを超えたリーチ情報を定義し、控えめに使用する必要があります。到達情報である属性を定義するPIDFへの拡張は、そのようにそれらの属性を明確に呼び出す必要があります。
Each service is also associated with a priority, which represents the preference that the user has for usage of one service over another. This does not mean that, when a watcher wishes to communicate with the presentity, that they should always use the service with the highest priority. If that were the case, there would be no point in including multiple services in the presence document. Rather, the priority says, "If you, the watcher, cannot decide which of these to use, or if it is not important to you, this is the order in which I would like you to contact me. However, I am giving you a choice." The priorities are relative to each other, and have no meaning as absolute numbers. If there are two services, and they have priorities of 1 and .5, respectively, this is identical to giving them priorities of .2 and .1, respectively.
各サービスは優先事項にも関連付けられており、これはユーザーがあるサービスを別のサービスよりも使用することを好むことを表しています。これは、ウォッチャーがプレゼンテーションとのコミュニケーションを望んでいるとき、彼らは常に最優先事項でサービスを使用する必要があることを意味するものではありません。その場合、プレゼンスドキュメントに複数のサービスを含めることには意味がありません。むしろ、優先順位は、「ウォッチャーがこれらのどれを使用するかを決定できない場合、またはそれがあなたにとって重要ではない場合、これは私があなたに連絡してほしい順序です。しかし、私はあなたに与えています選択。"優先順位は互いに関連しており、絶対数として意味がありません。2つのサービスがあり、それぞれ1と.5の優先順位がある場合、これはそれぞれ.2と.1の優先順位を与えることと同じです。
Each service also has a status. Status represents generally dynamic information about the availability of communications using that service. This is in contrast to characteristics, which describe fairly static properties of the various services. The simplest form of status is the basic status, which is a binary indicator of availability for communications using that service. It can have values of either "closed" or "open". "Closed" means that communication to the service will, in all likelihood, fail, will not reach the intended party, or will not result in communications as described by the characteristics of the service. As an example, if a call is forwarded to voicemail if the user is busy or unavailable, the service is marked as "closed". Similarly, a presentity may include a hotel phone number as a service URI. After checkout, the phone number will still ring, but reach the chambermaid or the next guest. Thus, it would be declared "closed" by that presentity. As another example, if a user has a SIP URI as their service URI that points to a SIP softphone application, and the PC shuts down, calls to that SIP URI will return a 480 response code. This service would also be declared "closed". "Open" implies the opposite - that communications to this service will likely succeed and reach the desired target.
各サービスにもステータスがあります。ステータスは、一般に、そのサービスを使用した通信の可用性に関する動的な情報を表します。これは、さまざまなサービスのかなり静的特性を説明する特性とは対照的です。ステータスの最も単純な形式は基本的なステータスです。これは、そのサービスを使用した通信の可用性のバイナリインジケーターです。「閉じた」または「開いている」の値を持つことができます。「閉鎖」とは、サービスへのコミュニケーションは、おそらく、失敗し、意図した当事者に到達しないか、サービスの特性によって説明されているように通信につながらないことを意味します。例として、ユーザーがビジーまたは利用できない場合、コールがボイスメールに転送された場合、サービスは「クローズド」としてマークされます。同様に、プレゼンテーションには、サービスURIとしてのホテルの電話番号が含まれる場合があります。チェックアウト後、電話番号は引き続き鳴りますが、Chambermaidまたは次のゲストに到達します。したがって、そのプレゼンテーションによって「閉鎖」されると宣言されます。別の例として、ユーザーがSIP SoftPhoneアプリケーションを指すサービスURIとしてSIP URIを持っている場合、PCがシャットダウンする場合、そのSIP URIは480回の応答コードを返します。このサービスは「閉鎖」と宣言されます。「オープン」は反対を意味します - このサービスとの通信は成功し、望ましい目標に到達する可能性が高いことを意味します。
It is also possible to have status information that is dependent on the characteristics of the communications session that eventually gets set up. For example, a status attribute can be defined that indicates that a softphone service is available if instant messaging is used, but unavailable if audio is used.
また、最終的にセットアップされる通信セッションの特性に依存するステータス情報を持つことも可能です。たとえば、インスタントメッセージングが使用されている場合はソフトフォンサービスが利用可能であることを示すステータス属性を定義できますが、オーディオが使用されている場合は利用できません。
Other status information might indicate more details on why the service is available or unavailable. For example, a telephony service might have additional status to indicate that the user is on the phone, or that the user is handling 3 calls for that service.
その他のステータス情報は、サービスが利用可能または利用できない理由の詳細を示している場合があります。たとえば、テレフォニーサービスには、ユーザーが電話をかけていること、またはユーザーがそのサービスの3つの呼び出しを処理していることを示すための追加のステータスがある場合があります。
Services inherently have a lot of dynamic state associated with them. For example, consider a wireless telephony service (i.e., a cell phone). There are many dynamic statuses of this service - whether or not the phone is registered, whether or not it is roaming, which provider it has roamed into, its signal strength, how many calls it has, what the state of those calls are, how long the user has been in a call, and so on. As another example, consider an IM service. The statuses in this service include whether the user is registered, how long they have been registered, whether they have an IM conversation in progress, how many IM conversations are in progress, whether the user is typing, to whom they are typing, and so on.
サービスには、本質的に多くの動的状態があります。たとえば、ワイヤレステレフォニーサービス（つまり、携帯電話）を検討してください。このサービスには多くの動的なステータスがあります - 電話が登録されているかどうか、ローミングであるかどうか、どのプロバイダーがローミングしたか、その信号強度、それがどれだけの電話をかけているか、それらの呼び出しの状態、どのようにしているか、長い間、ユーザーは電話をかけています。別の例として、IMサービスを検討してください。このサービスのステータスには、ユーザーが登録されているかどうか、登録されている期間、IM会話が進行中のかどうか、IMの会話が進行中の数、ユーザーが入力しているかどうか、誰が入力しているかなどがあります。の上。
However, not all of this dynamic state is appropriate to include within a service data component of a presence document. Information is included only when it has a bearing on helping the watcher decide whether to initiate communications with that service, or helping the watcher decide when to initiate it, if not now. As an example, whether a cell phone has strong signal strength or just good signal strength does not pass the litmus test. Knowing this is not likely to have an impact on a decision to use this service.
ただし、この動的状態のすべてが、プレゼンスドキュメントのサービスデータコンポーネントに含めることが適切なわけではありません。情報は、ウォッチャーがそのサービスとのコミュニケーションを開始するかどうかを決定するのを支援することに関係している場合にのみ含まれています。例として、携帯電話の信号強度が強いか、信号強度が良好であるかどうかは、Litmusテストに合格しません。これを知ることは、このサービスを使用する決定に影響を与える可能性は低いです。
Devices model the physical operating environment in which services execute. Examples of devices include cell phones, PCs, laptops, PDAs, consumer telephones, enterprise PBX extensions, and operator dispatch consoles.
デバイスは、サービスが実行される物理的な動作環境をモデル化します。デバイスの例には、携帯電話、PC、ラップトップ、PDA、消費者電話、エンタープライズPBX拡張機能、オペレーターディスパッチコンソールが含まれます。
The mapping of services to devices are many to many. A single service can execute in multiple devices. Consider a SIP telephony service. Two SIP phones can register against a single Address of Record for this service. As a result, the SIP service is associated with two devices. Similarly, a single device can support a multiplicity of services. A cell phone can support a SIP telephony service, an SMS service, and an MMS service. Similarly, a PC can support a SIP telephony service and a SIP videophone service.
デバイスへのサービスのマッピングは、多くの人にとって多くのものです。単一のサービスは、複数のデバイスで実行できます。SIPテレフォニーサービスを検討してください。2つのSIP電話は、このサービスの単一の記録アドレスに対して登録できます。その結果、SIPサービスは2つのデバイスに関連付けられています。同様に、単一のデバイスは多数のサービスをサポートできます。携帯電話は、SIPテレフォニーサービス、SMSサービス、およびMMSサービスをサポートできます。同様に、PCはSIPテレフォニーサービスとSIPビデオフォンサービスをサポートできます。
Furthermore, a single device can support no services. In such a case, the device has no useful presence information by itself. However, when composed with other documents that describe this same device in relation to a service, a richer presence document can be created. For example, consider a Radio Frequency ID (RFID) tag as a device. This device does not execute any services. However, as a device, it has properties, such as location, and it may have network connectivity with which it can report its status and characteristics. If a video telephone were to report that it was running a video service, and one of its properties was that it was tagged with that RFID, a compositor could combine the two documents together, and use the location of the RFID to say something about the location of the video telephony device.
さらに、単一のデバイスはサービスをサポートできません。そのような場合、デバイスには単独で有用な存在情報がありません。ただし、サービスに関連してこの同じデバイスを説明する他のドキュメントで構成されている場合、より豊富なプレゼンスドキュメントを作成できます。たとえば、ラジオ周波数ID（RFID）タグをデバイスとして検討してください。このデバイスはサービスを実行しません。ただし、デバイスとしては、場所などのプロパティがあり、そのステータスと特性を報告できるネットワーク接続がある場合があります。ビデオ電話がビデオサービスを実行していることを報告し、そのプロパティの1つがそのRFIDでタグ付けされたことである場合、コンポジタは2つのドキュメントを一緒に組み合わせて、RFIDの場所を使用して何かを言うことができます。ビデオテレフォニーデバイスの場所。
Devices are identified with a device ID. A device ID is a URI that is a globally and temporally unique identifier for the device. In particular, a device ID is a URN. The URN has to be unique across all other devices for a particular presentity. However, it is also highly desirable that it be persistent across time, globally unique, and computable in a fashion so that different systems are likely to refer to the device using the same ID. With these properties, differing sources of presence information based on device status can be combined. The last of these three properties - readily computable - is particularly useful. It allows for a compositor to combine disparate sources of information about a device, all linked by a common device ID that each source has independently used to identify the device in question.
デバイスはデバイスIDで識別されます。デバイスIDは、デバイスのグローバルかつ時間的に一意の識別子であるURIです。特に、デバイスIDはurnです。URNは、特定のプレゼンテーションのために、他のすべてのデバイスでユニークでなければなりません。ただし、異なるシステムが同じIDを使用してデバイスを参照する可能性が高いため、時間の経過とともに持続的であり、グローバルに一意であり、ファッションで計算可能であることも非常に望ましいです。これらのプロパティを使用すると、デバイスのステータスに基づいた存在情報の異なるソースを組み合わせることができます。これら3つのプロパティの最後 - 容易に計算可能 - は特に便利です。これにより、コンポジタは、各ソースが問題のデバイスを識別するために独立して使用されている一般的なデバイスIDによってリンクされているデバイスに関するさまざまな情報源を組み合わせることができます。
Unfortunately, due to the variety of different devices in existence, it is difficult for a single URN scheme to be used that will have these properties. It is anticipated that multiple schemes will be defined, with different ones appropriate for different types of devices. For cellular telephones, the Electronic Serial Number (ESN), for example, is a good identifier. For IP devices, the MAC address is another good one. The MAC address has the property of being readily computable, but lacks persistence across time (it would change if the interface card on a device were to change). In any case, neither of these are associated with URN schemes at this time. In the interim, the Universally Unique IDentifier (UUID) URN [20] can be used. For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address. For devices without a MAC, a version 4 UUID is RECOMMENDED. This is a purely random identifier, providing uniqueness. The UUID for a device would typically be chosen at the time of fabrication in the device, and then persisted in the device within flash or some other kind of non-volatile storage. The UUID URN has the properties of being globally and temporally unique, but because of its random component, it is not at all readily computable, and therefore useless as a correlation ID with other presence sources on a network. It is anticipated that future specifications will be developed that provide additional, superior device IDs.
残念ながら、さまざまなデバイスが存在するため、これらのプロパティを持つ単一のURNスキームが使用されることは困難です。さまざまなタイプのデバイスに適した複数のスキームが定義され、複数のスキームが定義されることが予想されます。たとえば、携帯電話の場合、電子シリアル番号（ESN）は適切な識別子です。IPデバイスの場合、Macアドレスは別の優れたアドレスです。MACアドレスには、容易に計算可能であるというプロパティがありますが、時間の経過とともに持続性がありません（デバイス上のインターフェイスカードが変更されると変更されます）。いずれにせよ、これらはどちらも現時点ではuRNスキームに関連付けられていません。暫定的には、普遍的に一意の識別子（UUID）urn [20]を使用できます。MACアドレスを持つデバイスの場合、MACアドレスを使用する時間ベースの識別子になるため、バージョン1のUUIDが推奨されます。Macのないデバイスの場合、バージョン4 UUIDをお勧めします。これは純粋にランダムな識別子であり、一意性を提供します。通常、デバイスのUUIDは、デバイス内の製造時に選択され、フラッシュ内のデバイスまたは他の種類の不揮発性ストレージ内で持続します。UUID URNには、グローバルかつ時間的に一意であるという特性がありますが、そのランダムコンポーネントのため、ネットワーク上の他の存在ソースとの相関IDとしては、まったく容易に計算可能ではありません。追加の優れたデバイスIDを提供する将来の仕様が開発されることが予想されます。
Though each device is identified by a unique device ID, there can be multiple occurrences of a particular device represented in a document. Each one will share the same device ID, but differ in its occurrence identifier. Multiple occurrences of a device exist in a document when the state of the device is ambiguous, as discussed in Section 3.5.
各デバイスは一意のデバイスIDで識別されますが、ドキュメントに表される特定のデバイスの複数の発生があります。それぞれが同じデバイスIDを共有しますが、その発生識別子は異なります。セクション3.5で説明したように、デバイスの状態が曖昧な場合、ドキュメントにデバイスの複数の発生が存在します。
Though this document does not mandate a particular implementation approach, the device ID is most useful when all of the services on the device have a way to obtain the device ID and get the same value for it. This would argue for its placement as an operating system feature. Operating system developers interested in implementing this specification are encouraged to provide APIs that allow applications to obtain the device ID. Absent such APIs, applications that report presence information about their devices will have to generate their own device IDs. This leads to the possibility that the applications may choose different device IDs, using different algorithms or data. In the worst case, these may mean that two services that run on the same device, do not appear to.
このドキュメントは特定の実装アプローチを義務付けていませんが、デバイス上のすべてのサービスにデバイスIDを取得して同じ値を取得する方法がある場合、デバイスIDは最も便利です。これは、オペレーティングシステム機能としての配置を主張します。この仕様の実装に関心のあるオペレーティングシステム開発者は、アプリケーションがデバイスIDを取得できるようにするAPIを提供することをお勧めします。このようなAPIがなければ、デバイスに関する存在情報を報告するアプリケーションは、独自のデバイスIDを生成する必要があります。これにより、アプリケーションが異なるアルゴリズムまたはデータを使用して、異なるデバイスIDを選択できる可能性があります。最悪の場合、これらは同じデバイスで実行される2つのサービスが表示されないことを意味する場合があります。
Like services and person data components, device data components have generally static characteristics and generally dynamic status. Characteristics of a device include its physical dimensions and capabilities - the size of its display, the speed of its CPU, and the amount of memory. Status information includes dynamic information about the device. This includes whether the device is powered on or off, the amount of battery power that remains in the device, the geographic location of the device, and so on.
サービスや個人データコンポーネントと同様に、デバイスデータコンポーネントには一般に静的特性があり、一般に動的なステータスがあります。デバイスの特性には、物理的な寸法と機能など、ディスプレイのサイズ、CPUの速度、メモリの量が含まれます。ステータス情報には、デバイスに関する動的な情報が含まれています。これには、デバイスがオンまたはオフに電源を入れているか、デバイスに残っているバッテリー電源の量、デバイスの地理的位置などが含まれます。
The characteristics and status information reported about a device are for the purposes of choice - to allow the user to choose the service based on knowledge of what the device is. The device characteristics and status cannot, in any reliable way, be used to extract information about the nature of the service that will be received on the device. For example, if the device characteristics include the speed of the CPU, and the speed is sufficient to support high-quality video compression, this cannot be interpreted to mean that video quality would be good for a video service on that device. Other constraints on the system may reduce the amount of CPU available to that service. If there is a desire to indicate that higher-quality video is available on a device, that should be done by including service characteristics that say just that. The speed of the CPU might be useful in helping the watcher differentiate between a device that is a PC and one that is a cell phone, in the case where the watcher wishes to call the user's cell phone.
デバイスについて報告されている特性とステータス情報は、選択の目的のためです。ユーザーがデバイスの知識に基づいてサービスを選択できるようにします。デバイスの特性とステータスは、信頼できる方法で、デバイスで受信されるサービスの性質に関する情報を抽出するために使用することはできません。たとえば、デバイスの特性にCPUの速度が含まれており、高品質のビデオ圧縮をサポートするのに速度が十分である場合、これはビデオ品質がそのデバイスのビデオサービスに適していることを意味すると解釈することはできません。システム上のその他の制約により、そのサービスが利用できるCPUの量が減少する場合があります。高品質のビデオがデバイスで利用可能であることを示したい場合、それはまさにそれを言うサービス特性を含めることによって行う必要があります。CPUの速度は、Watcherがユーザーの携帯電話に電話をかけたい場合に、WatcherがPCであるデバイスと携帯電話であるデバイスを区別するのに役立つ可能性があります。
Similarly, if there is dynamic device status (such as whether the device is on or off), and this state impacts the state of the service, this is represented by adjusting the state of the service. Unless a consumer of a presence document has a priori knowledge indicating otherwise (note that presence agents often do), the state of a device has no bearing on the state of the service.
同様に、動的なデバイスステータス（デバイスがオンまたはオフになっているかなど）があり、この状態がサービスの状態に影響を与える場合、これはサービスの状態を調整することによって表されます。プレゼンスドキュメントの消費者が別の方法で示す先験的な知識を持っている場合を除き（プレゼンスエージェントはしばしばそうであることに注意してください）、デバイスの状態はサービスの状態に関係していません。
Just like services, there is no enumeration of device types - PCs, PDAs, cell phones, etc. Rather, the device is defined by its characteristics, from which a watcher can extrapolate whether the device is a PDA, cell phone, or what have you.
サービスと同様に、PC、PDA、携帯電話などのデバイスタイプの列挙はありません。むしろ、デバイスはその特性によって定義されます。そこから、ウォッチャーはデバイスがPDA、携帯電話、または持っているものであるかどうかを推定できます。あなた。
It is important to point out that the device is a *model* of the underlying physical systems in which services execute. There is nothing that says that this model cannot be used to talk about systems where services run in virtualized systems, rather than real ones. For example, if a PC is executing a virtual machine and running services within that virtual machine, it is perfectly acceptable to use this model to talk about that PC as being composed of two separate devices.
デバイスは、サービスが実行される基礎となる物理システムの *モデル *であることを指摘することが重要です。このモデルは、実際のシステムではなく仮想化システムでサービスが実行されるシステムについて話すために使用できないということは何もありません。たとえば、PCが仮想マシンを実行し、その仮想マシン内でサービスを実行している場合、このモデルを使用して、そのPCについて2つの別々のデバイスで構成されていると話すことは完全に受け入れられます。
Ambiguity is a reality of a presence system, and it is explicitly modeled by this specification. Ambiguity exists when there are multiple pieces of information about a person, a particular device, or a particular service. This ambiguity naturally arises when multiple elements publish information about the person, a particular service, or a particular device. In some cases, a compositor can resolve the ambiguity in an automated way, and combine the data about the person, device, or service into a single coherent description.
あいまいさは存在システムの現実であり、この仕様によって明示的にモデル化されています。人、特定のデバイス、または特定のサービスに関する複数の情報がある場合、あいまいさが存在します。このあいまいさは、複数の要素が人、特定のサービス、または特定のデバイスに関する情報を公開するときに自然に発生します。場合によっては、コンポジターは自動化された方法で曖昧さを解決し、その人、デバイス、またはサービスに関するデータを単一のコヒーレントな説明に組み合わせることができます。
In other cases, it cannot, perhaps because the compositor lacks the ability to do so.
他の場合には、おそらくコンポジターにそうする能力がないためにできません。
However, in many cases, the resolution of this ambiguity is best left to the watcher that consumes the document. This consumer could be an application with more information than the compositor, and thus be able to do a better job of resolving the ambiguity. Or, it may be presented to the human user, and the human can often resolve the ambiguity. Unsurprisingly, a human can often do this far better than an automaton can.
ただし、多くの場合、このあいまいさの解決は、ドキュメントを消費するウォッチャーに任されるのが最善です。この消費者は、コンポジタよりも多くの情報を持つアプリケーションである可能性があり、したがって、あいまいさを解決するためのより良い仕事をすることができます。または、それは人間のユーザーに提示される場合があり、人間はしばしば曖昧さを解決することができます。当然のことながら、人間はしばしばオートマトン缶よりもはるかに優れていることがよくあります。
To model ambiguity, the model allows each service, each device, or the person component to contain multiple occurrences. Each occurrence has a unique identifier, called the occurrence identifier. This identifier is unique across all other occurrence identifiers for any service, device, or person. That is, its uniqueness is scoped within all of the services, devices, and person elements for a particular presentity. The identifier ideally persists over time, since it serves as a valuable handle for setting composition and authorization policies. Even if there is a single occurrence for a particular device, service, or person, the occurrence has an occurrence identifier.
あいまいさをモデル化するために、モデルにより、各サービス、各デバイス、または個人コンポーネントが複数の発生を含めることができます。各発生には、発生識別子と呼ばれる一意の識別子があります。この識別子は、サービス、デバイス、または個人の他のすべての発生識別子にわたって一意です。つまり、そのユニークさは、特定のプレゼンテーションのために、すべてのサービス、デバイス、および個人の要素内でスコープされています。識別子は、構成と承認ポリシーを設定するための貴重なハンドルとして機能するため、時間の経過とともに持続します。特定のデバイス、サービス、または個人に単一の発生がある場合でも、発生には発生識別子があります。
The occurrence identifier is not to be confused with the instance ID defined in the SIP Outbound specification [27]. A user agent instance is best modeled as a service, and indeed, a Globally Routable User Agent URI (GRUU) [22], which is derived from the instance ID, represents a reasonable choice for a service URI. However, if the status of such a UA instance could not be determined unambiguously, a presence document could include two or more occurrences of the service modeling that UA instance. In such a case, each occurrence has a unique occurrence ID, but they share the same service URI, and consequently, the same instance ID.
発生識別子は、SIPアウトバウンド仕様[27]で定義されたインスタンスIDと混同しないでください。ユーザーエージェントインスタンスは、サービスとしてモデル化するのが最適であり、実際、インスタンスIDから派生したグローバルにルーティング可能なユーザーエージェントURI（Gruu）[22]は、サービスURIの合理的な選択を表しています。ただし、そのようなUAインスタンスのステータスを明確に決定できなかった場合、存在ドキュメントには、UAインスタンスのサービスモデリングの2つ以上の発生を含めることができます。このような場合、各発生には一意の発生IDがありますが、同じサービスURIを共有し、その結果、同じインスタンスIDを共有します。
When multiple occurrences exist in a document, it is important that some of the attributes of the device, service, or person help the recipient resolve the ambiguity. For humans, the note field and timestamp serve as valuable tools. For an automaton, nearly any attribute of the device, service, or person can be used to resolve the ambiguity. The timestamp in particular is very useful for both humans and automatons. As described in RFC 3863 [1], the timestamp provides the time of most recent change for the tuple. This specification defines the timestamp for person and device components as well, with the same meaning. Absent other information, the person, device, or service that most recently changed can be used as the more reliable source of data. However, such a resolution algorithm is not normatively required in any way.
ドキュメントに複数の発生が存在する場合、デバイス、サービス、または個人の属性の一部が、受信者が曖昧さを解決するのに役立つことが重要です。人間にとって、メモフィールドとタイムスタンプは貴重なツールとして機能します。オートマトンの場合、デバイス、サービス、または人のほぼすべての属性を使用して、あいまいさを解決できます。特にタイムスタンプは、人間とオートマトンの両方にとって非常に便利です。RFC 3863 [1]で説明されているように、タイムスタンプはタプルの最新の変更の時間を提供します。この仕様では、同じ意味のある人とデバイスのコンポーネントのタイムスタンプも定義されています。他の情報がなければ、最近変更された人、デバイス、またはサービスは、より信頼性の高いデータソースとして使用できます。ただし、このような解像度アルゴリズムは、いかなる方法でも規範的に必要ではありません。
It is clear that the existence of a presence attribute in a document tells something to a watcher about the value of that presence attribute. However, what does the absence of a presence attribute say? This data model follows the lead of RFC 3840 [17], which is used to define capabilities for SIP user agents. In that specification, if a capability declaration omits a particular feature tag, it means that the agent is making no definitive statement either way about whether this feature tag is supported. The same is true here - the absence of a presence attribute from a document means that a watcher cannot make any definitive statement about the value for that presence attribute. It may be absent because it is being withheld from the watcher, or it may be absent because that attribute is not supported by the presentity's software. Neither conclusion can be drawn.
ドキュメント内の存在属性の存在が、その存在属性の価値についてウォッチャーに何かを伝えることは明らかです。しかし、存在属性の欠如は何と言っていますか？このデータモデルは、SIPユーザーエージェントの機能を定義するために使用されるRFC 3840 [17]のリードに従います。その仕様では、機能宣言が特定の機能タグを省略している場合、この機能タグがサポートされているかどうかについて、エージェントが決定的なステートメントを作成していないことを意味します。ここにも同じことが言えます - ドキュメントからの存在属性がないということは、ウォッチャーがその存在属性の価値について決定的な声明を出すことができないことを意味します。ウォッチャーから差し控えられているため、存在しない場合があります。また、その属性がPresentityのソフトウェアによってサポートされていないため欠席する可能性があります。どちらの結論も引き出すことはできません。
Because the absence of a presence attribute conveys no information whatsoever, presence documents achieve their maximum value when they have as many presence attributes as possible. As such, it is RECOMMENDED that a presence document contain as many presence attributes as the presentity is willing to and able to provide to a watcher.
存在属性の欠如は情報をまったく伝えないため、存在ドキュメントにはできるだけ多くの存在属性がある場合、存在書類は最大値を達成します。そのため、プレゼンスドキュメントには、プレゼンテーションが喜んでウォッチャーに提供できるのと同じくらい多くの存在属性を含めることが推奨されます。
The data model tries to separate status information from characteristics, generally by defining status as a relatively dynamic state about a person, device, or service, whereas a characteristic is relatively static. However, this distinction is often artificial. Almost any characteristic can change over time, and sometimes characteristics can change relatively quickly. As a result, the distinction between status and characteristics is merely a conceptual one to facilitate understanding about the different types of presence information. Nothing in a presence document indicates whether an element is a characteristic vs. a status, and when a presence attribute is defined, there is no need for it to be declared one or the other. Presence documents allow any presence attribute, whether it can be thought of as a characteristic or a status, to change at any time.
データモデルは、一般に、人、デバイス、またはサービスに関する比較的動的な状態としてステータスを定義することにより、ステータス情報を特性から分離しようとしますが、特性は比較的静的です。ただし、この区別はしばしば人工的です。ほとんどすべての特性が時間とともに変化する可能性があり、時には特性が比較的速く変化する場合があります。その結果、ステータスと特性の区別は、さまざまな種類の存在情報についての理解を促進するための概念的なものにすぎません。存在ドキュメント内のドキュメントは、要素がステータス対ステータスであるかどうかを示すものではなく、存在属性が定義されている場合、どちらか一方と宣言する必要はありません。プレゼンスドキュメントにより、特徴的であろうとステータスと考えることができるかどうかにかかわらず、任意の存在属性がいつでも変更されます。
Unfortunately, the original PIDF specification did have a separate part of a tuple for describing status, and the basic status was defined to exist within that part of the tuple. This specification does not change PIDF; however, all future presence attributes MUST be defined as children of the <tuple> and not the <status> element. Furthermore, the schemas defined here do not contain a <status> element for either the <person> or <device> elements.
残念ながら、元のPIDF仕様には、ステータスを記述するためのタプルの個別の部分があり、基本的なステータスはタプルのその部分内に存在するように定義されていました。この仕様はPIDFを変更しません。ただし、すべての将来の存在属性は、<ステータス>要素ではなく、<tuple>の子供として定義する必要があります。さらに、ここで定義されているスキーマには、<sature>要素または<device>要素の<status>要素は含まれていません。
The overall presence document has several important properties that are essential to this model.
全体的な存在ドキュメントには、このモデルに不可欠ないくつかの重要な特性があります。
First, a presence document has a concrete meaning independent of how it is transported or where it is found. The semantics of a document are the same regardless of whether a document is published by a presence user agent to its compositor, or whether it is distributed from a presence agent to watchers. There are no required or implied behaviors for a recipient of a document. Rather, there are well-defined semantics for the document itself, and a recipient of a document can take whatever actions it chooses based on those semantics.
第一に、存在ドキュメントには、輸送方法や見つかった場所とは無関係に具体的な意味があります。ドキュメントのセマンティクスは、ドキュメントがコンポジタにプレゼンスユーザーエージェントによって公開されているかどうかに関係なく同じです。または、プレゼンスエージェントからウォッチャーに配布されるかどうか。ドキュメントの受信者には必要または黙示的な動作はありません。むしろ、ドキュメント自体に明確に定義されたセマンティクスがあり、ドキュメントの受信者は、これらのセマンティクスに基づいて選択したアクションを実行できます。
A corollary of this property is that presence systems are infinitely composeable. A presence user agent can publish a document to its presence server. That presence server can compose it with other documents, and place the result in a notification to a watcher. That watcher can actually be another presence agent, combining that document with others it has received, and placing those results in yet another notify.
このプロパティの結果は、存在システムが無限に構成可能であることです。プレゼンスユーザーエージェントは、そのプレゼンスサーバーにドキュメントを公開できます。そのプレゼンスサーバーは、他のドキュメントと一緒に構成し、結果をウォッチャーに通知することができます。そのウォッチャーは、実際には別のプレゼンスエージェントになることができ、そのドキュメントを受け取った他のドキュメントと組み合わせて、それらの結果をさらに別の通知に配置します。
Yet another corollary of this property is that implied behaviors in reaction to the document cannot ever be assumed. For example, just because a service indicates that it supports audio does not mean that a watcher will offer audio in a communications attempt to that service. If doing so is necessary to reach the service, this must be indicated explicitly through reach information.
このプロパティのもう1つの結果は、ドキュメントに反応する暗黙の行動を想定できないことです。たとえば、サービスがオーディオをサポートしていることを示しているからといって、ウォッチャーがそのサービスの通信試行でオーディオを提供するという意味ではありません。サービスに到達するために必要な場合は、これをリーチ情報を通じて明示的に示す必要があります。
It is also important to understand that the role of the presence document is to help a user make a choice amongst a set of services, and furthermore, to know ahead of time with as much certainty as possible whether a communications attempt will succeed or fail. Success is a combination of many factors: Does the watcher understand the service URI? Can it act on all of the reach information? Does it support a subset of the capabilities associated with the service? Does the person information indicate that the user is likely to answer? All of these checks should ideally be made before attempting communication.
また、プレゼンスドキュメントの役割は、ユーザーが一連のサービスの中から選択を行うのを支援し、さらに、コミュニケーションの試みが成功するか失敗するかどうかをできるだけ確実に知ることであることを理解することも重要です。成功は多くの要因の組み合わせです：ウォッチャーはサービスURIを理解していますか？すべてのリーチ情報に基づいて行動できますか？サービスに関連する機能のサブセットをサポートしていますか？個人情報は、ユーザーが答える可能性が高いことを示していますか？これらのチェックはすべて、コミュニケーションを試みる前に理想的に行う必要があります。
Because the presence document serves to help a user to choose and establish communications, the presentity URI - as the index to that document - represents a form of "one-number" communications. Starting from this URI, all of the communications modalities and their URIs for a user can be discovered, and then used to invoke a particular communications service. Rather than having to give out a separate phone number, email address, IM address, Voice over Internet Protocol (VoIP) address, and so on, the presentity URI can be provided, and all of the others can be learned from there.
プレゼンスドキュメントは、ユーザーが通信を選択して確立するのを支援するのに役立つため、そのドキュメントのインデックスとしてのプレゼンティURIは、「1つの」通信の形式を表します。このURIから始めて、ユーザーのすべての通信モダリティとそのURIを発見し、特定の通信サービスを呼び出すために使用できます。個別の電話番号、メールアドレス、IMアドレス、インターネットプロトコル（VOIP）アドレスなどの音声を提供する必要があるのではなく、プレゼンティURIを提供でき、他のすべてをそこから学習できます。
Presence is defined in [21] as the ability, willingness, or desire to communicate across a set of devices. The core of this definition is the conveyance of information about the ability, willingness, or desire for communications. Thus, the presence data model needs to be tailored around conveying information that achieves this goal.
[21]で存在は、一連のデバイス全体で通信したい能力、意欲、または欲求として定義されています。この定義の中核は、コミュニケーションへの能力、意欲、または欲求に関する情報の伝達です。したがって、この目標を達成する情報を伝えることを中心に、存在データモデルを調整する必要があります。
The person data component is targeted at conveying willingness and desire for communications. It is used to represent information about the users themselves that affects willingness and desire to communicate. Whether I am in a meeting, whether I am on the phone - each of these says something about my willingness to communicate, and thus makes sense for inclusion in a presence document.
個人データコンポーネントは、コミュニケーションへの意欲と欲求を伝えることを目的としています。これは、コミュニケーションを意欲と欲求に影響を与えるユーザー自身に関する情報を表すために使用されます。私が会議にいるかどうか、私が電話をしているかどうか - これらのそれぞれは、コミュニケーションの意欲について何かを言っているため、プレゼンスドキュメントに含めるのは理にかなっています。
The service component of the data model aims to convey information on the ability to communicate. The ability to communicate is defined by the services by which a user is reachable. Thus, including them is essential.
データモデルのサービスコンポーネントは、通信能力に関する情報を伝えることを目的としています。通信する機能は、ユーザーが到達可能なサービスによって定義されます。したがって、それらを含めることは不可欠です。
How do devices fit in? For many users, devices represent the ability to communicate, not services. Frequently, users make statements like, "Call me on my cell phone" or "I'm at my desk". These are statements for preference for communications using a specific device, as opposed to a service. Thus, it is our expectation that users will want to represent devices as part of the presence data.
デバイスはどのように適合しますか？多くのユーザーにとって、デバイスはサービスではなく通信能力を表しています。多くの場合、ユーザーは「私の携帯電話で私に電話してください」や「私は机にいる」などの声明を出します。これらは、サービスとは対照的に、特定のデバイスを使用した通信を好むためのステートメントです。したがって、ユーザーが存在データの一部としてデバイスを表現したいと思うのは私たちの期待です。
Furthermore, the concept of device adds the ability to correlate services together. The device models the underlying platform that supports all of the services on the phone. Its state therefore impacts all services. For example, if a presence server can determine that a cell phone is off, this says something about the services that run on that device: they are all not available. Thus, if services include indicators about the devices on which they run, device state can be obtained and thus used to compute the state of the services on the device.
さらに、デバイスの概念は、サービスを一緒に相関させる能力を追加します。このデバイスは、電話のすべてのサービスをサポートする基礎となるプラットフォームをモデル化します。したがって、その状態はすべてのサービスに影響を与えます。たとえば、プレゼンスサーバーが携帯電話がオフになっていると判断できる場合、これはそのデバイスで実行されるサービスについて何かを示しています。それらはすべて利用できません。したがって、サービスが実行されているデバイスに関するインジケーターが含まれている場合、デバイス状態を取得できるため、デバイス上のサービスの状態を計算するために使用できます。
The data model tries hard to separate device, service, and person as different concepts. Part of this differentiation is that many attributes will be applicable to some of these, but not others. For example, geographic location is a meaningful attribute of the person (the user has a location) and of a device (the device has a location), but not of a service (services don't inherently have locations). Based on this, geographic location information should only appear as part of device or person, never service. Furthermore, it is possible and meaningful for location information to be conveyed for both device and person, and for these locations to be different. The fact that the presence system might try to determine the location of the person by extrapolation from the location of one of the devices is irrelevant from a data modeling perspective. Person location and device location are not the same thing.
データモデルは、デバイス、サービス、および人を異なる概念として分離することを懸命に試みます。この差別化の一部は、多くの属性がこれらのいくつかに適用できるが、他の属性ではないことです。たとえば、地理的位置は、人（ユーザーには場所があります）とデバイス（デバイスには場所があります）の意味のある属性ですが、サービスはありません（サービスは本質的に場所を持っていません）。これに基づいて、地理的位置情報は、デバイスまたは個人の一部としてのみ表示され、決してサービスではありません。さらに、デバイスと個人の両方に位置情報を伝え、これらの場所が異なることが可能であり、意味があります。存在システムが、デバイスのいずれかの位置から外挿によって人の位置を決定しようとする可能性があるという事実は、データモデリングの観点からは無関係です。人の場所とデバイスの場所は同じものではありません。
[25] defines the <geopriv> XML element for conveying location information, and indicates that it is carried as a child of the <tuple> element in a PIDF document. [25] was developed prior to this specification, and unfortunately, its recommendation to include location objects underneath <tuple> runs contrary to the recommendations here. As such, implementations based on this specification SHOULD include <geopriv> location objects as part of person and/or device components of the document, but SHOULD be prepared to receive presence documents with that object as a child to <tuple>. A <geopriv> location object would be included in a person component when the document means to convey the location of the user, and within a device component when it means to convey the location of the device.
[25] 位置情報を伝えるための<geopriv> xml要素を定義し、PIDFドキュメントで<tuple>要素の子として運ばれていることを示します。[25]はこの仕様の前に開発されましたが、残念ながら、<tuple>の下に位置オブジェクトを含めることを推奨することは、ここでの推奨事項に反して実行されます。そのため、この仕様に基づく実装には、ドキュメントの個人および/またはデバイスコンポーネントの一部として<geopriv>ロケーションオブジェクトを含める必要がありますが、そのオブジェクトを子供として<tuple>に存在するドキュメントを受信する準備をする必要があります。<geopriv>ロケーションオブジェクトは、ドキュメントがユーザーの位置を伝えることを意味する場合、およびデバイスの場所を伝えることを意味する場合はデバイスコンポーネント内で個人コンポーネントに含まれます。
Information represented according to the data model described above needs to be mapped into an on-the-wire format for transport and storage. The Presence Information Data Format [1] is used for representation of presence data.
上記のデータモデルに従って表される情報は、輸送とストレージのためにワイヤ内の形式にマッピングする必要があります。存在情報データ形式[1]は、存在データの表現に使用されます。
The <presence> element contains the presence information for the presentity. The "entity" attribute of this element contains the presentity URI.
<pesconis>要素には、プレゼンテーションの存在情報が含まれています。この要素の「エンティティ」属性には、プレゼントURIが含まれています。
The existing <tuple> element in the PIDF document is used to represent the service. This is consistent with the original intent of RFC 2778 and RFC 3863, and achieves backward compatibility with implementations developed before the model described here was complete. The <contact> element in the <tuple> element is used to encode the service URI. New presence attributes, whether they represent dynamic status or static characteristics, appear directly as children of <tuple>. However, attributes defined prior to publication of this specification that were defined as children of <status> (such as <basic>) remain as children of <status>, for purposes of backward compatibility. Consequently, a presence attribute describing a service could appear as either a child of <status> or directly as a child of <tuple>, but never both.
PIDFドキュメントの既存の<tuple>要素は、サービスを表すために使用されます。これは、RFC 2778およびRFC 3863の元の意図と一致しており、ここで説明するモデルが完了する前に開発された実装との逆方向の互換性を達成しました。<tuple>要素の<Contact>要素は、サービスURIをエンコードするために使用されます。動的ステータスを表すか静的特性を表す新しい存在属性は、<tuple>の子供として直接表示されます。ただし、この仕様の公開前に定義された属性は、<ステータス>（<basic>など）の子供として定義されていました。したがって、サービスを記述する存在属性は、<status>の子として、または<tuple>の子として直接表示される可能性がありますが、両方ではありません。
The "id" attribute of the <tuple> element conveys the service occurrence. Each <tuple> element with the same <contact> URI represents a different occurrence of a particular service.
<tuple>要素の「ID」属性は、サービスの発生を伝えます。同じ<contact> uriを持つ各<tuple>要素は、特定のサービスの異なる発生を表します。
This specification introduces the <person> element, which can appear as a child to <presence>. There can be zero or more occurrences of this element per document. Each one has a mandatory "id" attribute, which contains the occurrence identifier for the person. Each <person> element contains any number of elements that indicate status and characteristic information. This is followed by zero or more optional <note> elements and an optional <timestamp>. Multiple <note> elements would appear to convey the same note in multiple languages.
この仕様では、<porsent>に子供の頃に表示される<パーソン>要素が紹介されます。ドキュメントごとにこの要素がゼロ以上の発生がある可能性があります。それぞれに必須の「ID」属性があり、その人の発生識別子が含まれています。各<パーソン>要素には、ステータスと特徴的な情報を示す要素が任意の数に含まれています。これに続いて、ゼロ以上のオプションの<note>要素とオプションの<タイムスタンプ>が続きます。複数の<note>要素は、複数の言語で同じ音符を伝えているように見えます。
RFC 3863 defines a <note> element, zero or more of which can be present as a child to <presence>. As it relates to the model defined here, these note elements, if present in a document, apply to all person occurrences that do not have any of their own <note> elements. In other words, if a <person> element has one or more <note> elements, those are the <note> elements for that <person> element. If a <person> element does not have any of its own <note> elements, the <note> elements that are the direct children of <presence> are the <note> elements for that <person>. If there are no <note> elements underneath the <person> element, and there are no <note> elements that are a direct child of <presence>, then that <person> element has no <note> elements.
RFC 3863は、<pesconient>の子供として存在する可能性があるゼロ以上の要素を定義します。ここで定義されているモデルに関連するように、これらのノート要素は、ドキュメントに存在する場合、独自の<ノート>要素を持っていないすべての人に適用されます。言い換えれば、<パーソン>要素に1つ以上の<note>要素がある場合、それらはその<パーソン>要素の<ノート>要素です。<パーソン>要素に独自の要素がない場合、<presence>の直接の子供である<ノート>要素は、その<パーソン>の<ノート>要素です。<person>要素の下に<nte>要素がなく、<pescole>の直接の子である<note>要素がない場合、<serson>要素には<note>要素がありません。
This specification also introduces the <device> element, which can appear as a child to <presence>. There can be zero or more occurrences of this element per document. The <device> element can appear either before or after the <person> element; there are no constraints on order. Each <device> element has a mandatory "id" attribute, which contains the occurrence identifier for the device. Like <person>, <device> contains any number of elements that indicate status and characteristic information. This is followed by <deviceID>, which contains the URN for the device ID for this device. This is followed by zero or more optional <note> elements and an optional <timestamp>. Multiple <note> elements would appear to convey the same note in multiple languages.
この仕様では、<device>要素も導入されます。これは、<clession>に子供の頃に表示される可能性があります。ドキュメントごとにこの要素がゼロ以上の発生がある可能性があります。<device>要素は、<person>要素の前または後に表示できます。注文に制約はありません。各<デバイス>要素には、デバイスの発生識別子が含まれる必須の「ID」属性があります。<person>のように、<device>には、ステータスと特徴的な情報を示す要素が任意あります。これに続いて、このデバイスのデバイスIDのURNが含まれている<deviceId>が続きます。これに続いて、ゼロ以上のオプションの<note>要素とオプションの<タイムスタンプ>が続きます。複数の<note>要素は、複数の言語で同じ音符を伝えているように見えます。
A client that receives a PIDF document containing the <device> and <person> elements, but does not understand them (because it doesn't implement this specification), will ignore them. Furthermore, since the semantics of service as defined here are aligned with the meaning of a tuple as defined in RFC 2778 and RFC 3863, documents incorporating the concepts defined in this model are compliant with older implementations.
<device>および<person>要素を含むPIDFドキュメントを受信したが、それらを理解していないクライアントは（この仕様を実装していないため）、それらを無視します。さらに、ここで定義されているサービスのセマンティクスは、RFC 2778およびRFC 3863で定義されているタプルの意味と一致しているため、このモデルで定義されている概念を組み込んだドキュメントは、古い実装に準拠しています。
It's important to note that the mapping of the presence data model into a PIDF document is merely an exercise in syntax.
PIDFドキュメントへの存在データモデルのマッピングは、単なる構文の演習であることに注意することが重要です。
Presence documents created according to this model MUST be valid, with the following exception. A compositor is permitted to create a presence document that it cannot fully validate but that otherwise validates when processed according to the lax processing rules allowed by the schema of the compositor. However, it is not expected that entities receiving these documents would perform schema validation; rather, they would merely access the information from the document in the places they were expecting it to be. Implementations SHOULD be prepared to receive documents that are not valid, and extract whatever information from them that they can parse.
このモデルに従って作成された存在ドキュメントは、次の例外を除き、有効でなければなりません。Compositorは、完全に検証できないが、それ以外の場合はコンポジタのスキーマで許可されているLAX処理ルールに従って処理されると検証する存在ドキュメントを作成することができます。ただし、これらのドキュメントを受け取るエンティティがスキーマ検証を実行することは予想されていません。むしろ、彼らはそれが期待していた場所のドキュメントからの情報に単にアクセスするだけでした。有効なドキュメントを受信し、解析できる情報を抽出するために実装を準備する必要があります。
The XML schemas are broken into a common schema, called common-schema.xsd, which contains common type definitions, and the rest of the data model, data-model.xsd.
XMLスキーマは、一般的なタイプ定義と、データモデルの残りのデータモデル.xsdを含むCommon-Schema.xsdと呼ばれる共通スキーマに分割されます。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="Timestamp_t">
<xs:annotation>
<xs:documentation>Timestamp type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>
<xs:simpleType name="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="Note_t">
<xs:annotation>
<xs:documentation>Note type</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:attributeGroup name="fromUntil">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:attributeGroup>
<xs:complexType name="empty"/>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:pidf:data-model"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/>
<xs:element name="deviceID" type="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="device">
<xs:annotation>
<xs:documentation>Contains information about the
device</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="deviceID"/>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="person">
<xs:annotation>
<xs:documentation>Contains information about the human
user</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Characteristic and status
information</xs:documentation>
</xs:annotation>
</xs:any>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
When new presence attributes are added, any such extension has to consider the following questions:
新しい存在属性が追加されると、そのような拡張機能は次の質問を考慮する必要があります。
1. Is the new attribute applicable to person, service, or device data components? If it is applicable to more than one, what is its meaning in each context? An extension should strive to have each attribute concisely defined for each area of applicability, so that a source can clearly determine to which type of data component it should be applied.
1. 新しい属性は、個人、サービス、またはデバイスデータコンポーネントに適用されますか？複数のものに適用できる場合、それぞれのコンテキストでその意味は何ですか？拡張機能は、各属性が適用可能性の各領域に対して簡潔に定義されるように努力する必要があります。そのため、ソースはどのタイプのデータコンポーネントを適用するかを明確に決定できます。
2. Does it belong in a new namespace, or an existing one? Generally, new presence attributes defined within the same specification SHOULD belong to the same namespace. Presence attributes defined in separate specifications, but produced in a coordinated way by a centralized administration, MAY be placed in the same namespace. Doing so, however, requires the centralized administration to ensure that there are no collisions of element names across those specifications. Furthermore, if a new extension has elements meant to be placed as the children of another element at a point of extensibility defined by <any namespace="##other">, the new extension MUST use a different namespace than that of its parent elements.
2. それは新しい名前空間に属しますか、それとも既存の名前空間に属しますか？一般に、同じ仕様内で定義された新しい存在属性は、同じ名前空間に属する必要があります。個別の仕様で定義されているが、集中管理によって調整された方法で生成される存在属性は、同じ名前空間に配置できます。ただし、そうすることでは、これらの仕様にわたって要素名の衝突がないことを確認するために、集中管理が必要です。さらに、新しい拡張機能には、<any namespace = "## other">で定義された拡張性のポイントに別の要素の子供として配置されることを意図した要素がある場合、新しい拡張機能は親要素とは異なる名前空間を使用する必要があります。。
3. Does the extension itself require extensibility? If so, points of extension MUST be defined in the schema, and SHOULD be done using the <any namespace="##other"> construct.
3. 拡張機能自体には拡張性が必要ですか？その場合、拡張ポイントはスキーマで定義する必要があり、<任意のnamespace = "## other"> constructを使用して実行する必要があります。
In this section, we give an example of a physical system, present the model of that system using the concepts described here, and then show the resulting presence document. The example makes use of presence attributes defined in [23] and [24].
このセクションでは、物理システムの例を示し、ここで説明する概念を使用してそのシステムのモデルを提示し、結果の存在文書を示します。この例では、[23]および[24]で定義されている存在属性を使用します。
In this scenario, a provider is offering a service very similar to the instant messaging services offered today by the public providers like AOL, Yahoo!, and MSN. In this service, each user has a "screen name" that identifies the user in the service. A single client, generally a PC application, connects to the service at a time. When the client connects, this fact is made available to other watchers of that user in the system. The user has the ability to set a textual note that describes what they are doing, and this note is seen by the watchers in the system. The user can set one of several status messages (busy, in a meeting, etc.), which are pre-defined notes that the system understands. If a user does not type anything on their keyboard for some time, the user's status changes to idle on the screens of the various watchers of the system. The system also indicates the amount of time that the user has been idle.
このシナリオでは、プロバイダーは、AOL、Yahoo！、MSNなどの公開プロバイダーが今日提供されているインスタントメッセージングサービスと非常によく似たサービスを提供しています。このサービスでは、各ユーザーには、サービス内のユーザーを識別する「画面名」があります。単一のクライアント、一般的にPCアプリケーションは、一度にサービスに接続します。クライアントが接続すると、この事実はシステム内のそのユーザーの他のウォッチャーが利用できるようになります。ユーザーは、自分が何をしているかを説明するテキストメモを設定する機能を備えており、このメモはシステム内のウォッチャーに見られます。ユーザーは、システムが理解している事前に定義されたメモであるいくつかのステータスメッセージのいずれか（会議など）を設定できます。ユーザーがしばらくの間キーボードに何も入力しない場合、システムのさまざまなウォッチャーの画面でユーザーのステータスがアイドル状態に変更されます。システムはまた、ユーザーがアイドル状態になっている時間を示します。
Whenever a user is connected to the system, they are capable of receiving instant messages. A user can set their status to "invisible", which means that they appear as offline to other users. However, if an IM is sent to them, it will still be delivered.
ユーザーがシステムに接続されているときはいつでも、インスタントメッセージを受信できます。ユーザーは自分のステータスを「目に見えない」に設定できます。つまり、他のユーザーにはオフラインとして表示されます。ただし、IMがそれらに送信された場合、それは引き続き配信されます。
This system is modeled by representing each presentity in the system with three data components: a person component, a service component, and a device component. The person component describes the state of the user, including the note and the pre-defined status messages. These represent information about the human user, so they are included in the person component. The service tuple represents the IM service. No characteristics are included. The service URI published by the client is set to the client's Address of Record (AOR). The device component is used to model the PC. The device component includes the <user-input> element [23], since the idleness refers to usage of the device, not the service.
このシステムは、システム内の各プレゼンティを、個人コンポーネント、サービスコンポーネント、デバイスコンポーネントの3つのデータコンポーネントを備えた各データコンポーネントを表すことによってモデル化されています。人コンポーネントは、メモや事前に定義されたステータスメッセージを含むユーザーの状態について説明します。これらは人間のユーザーに関する情報を表しているため、人間コンポーネントに含まれています。サービスタプルはIMサービスを表します。特性は含まれていません。クライアントが公開するサービスURIは、クライアントの記録アドレス（AOR）に設定されています。デバイスコンポーネントは、PCのモデル化に使用されます。デバイスコンポーネントには、<ユーザーインプット>要素[23]が含まれます。これは、IDLENESSはサービスではなくデバイスの使用を指しているためです。
The document published by the client would look like this:
クライアントが公開したドキュメントは次のようになります。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
<caps:servcaps>
<caps:extensions>
<caps:supported>
<caps:pref/>
</caps:supported>
</caps:extensions>
<caps:methods>
<caps:supported>
<caps:MESSAGE/>
<caps:OPTIONS/>
</caps:supported>
</caps:methods>
</caps:servcaps>
<contact>sip:someone@example.com</contact>
</tuple>
<dm:person id="p1">
<rp:activities>
<rp:on-the-phone/>
</rp:activities>
</dm:person>
<dm:device id="pc122">
<rp:user-input>idle</rp:user-input>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device>
</presence>
It is worth commenting further on the value of having a separate device element just to convey the idle indicator. The idle indication of interest is really an indicator that the device is idle. By making that explicit, the idle indicator can be used by the presence server to affect the state of other services running on the same device. For example, let's say there is a VoIP application running on the same device. This application reports its presence state separately, but indicates that it runs on the same device. Since it has indicated that it runs on the same device, the presence server can use the status of the service to further refine the idle indicator of the device. Specifically, if the user is using its VoIP application, the presence server knows that the device is in use, even if the IM application reports that the device is idle. Typically, idleness is determined by lack of keyboard or mouse input, neither of which might be used during a VoIP call.
アイドルインジケーターを伝えるためだけに別のデバイス要素を持つことの価値についてさらにコメントする価値があります。関心のアイドル兆候は、実際にデバイスがアイドル状態であることを示す指標です。その明示的なものにすることにより、アイドルインジケーターをプレゼンスサーバーで使用して、同じデバイスで実行されている他のサービスの状態に影響を与えます。たとえば、同じデバイスで実行されているVoIPアプリケーションがあるとしましょう。このアプリケーションは、その存在状態を個別に報告しますが、同じデバイスで実行されることを示します。同じデバイスで実行されることが示されているため、プレゼンスサーバーはサービスのステータスを使用して、デバイスのアイドルインジケーターをさらに絞り込むことができます。具体的には、ユーザーがVoIPアプリケーションを使用している場合、IMアプリケーションがデバイスがアイドル状態であると報告していても、プレゼンスサーバーはデバイスが使用されていることを知っています。通常、アイドル性はキーボードまたはマウスの入力の欠如によって決定されますが、どちらもVoIP呼び出し中に使用できません。
In a more simplistic case, reporting the idle indicator as part of the device status allows that indicator to be used for other services on the same device. Taking, again, the example of the VoIP application on the same device, if the VoIP application does not report any device information, and a watcher is not provided information on the IM service, the presence document sent to the watcher can include the device status. Because of the usage of the device IDs and the device information, the presence server can correlate the device status as reported by the IM application with the VoIP service, and use them together.
より単純なケースでは、デバイスステータスの一部としてアイドルインジケーターを報告すると、同じデバイスの他のサービスにそのインジケータを使用できます。繰り返しますが、VoIPアプリケーションがデバイス情報を報告せず、ウォッチャーにIMサービスに関する情報が提供されていない場合、同じデバイス上のVoIPアプリケーションの例を取ります。。デバイスIDとデバイス情報の使用により、IMアプリケーションがVOIPサービスと報告したように、存在するサーバーはデバイスステータスを相関させ、それらを一緒に使用できます。
The presence information described by the model defined here is very sensitive. It is for this reason that privacy filtering plays a key role in the processing of presence data. Privacy filtering is the act of applying permissions to a presence document for the purposes of removing information that a watcher is not authorized to see. In more general terms, privacy filtering is a form of authorization. Privacy filtering can also ensure that a watcher cannot see any presence data for a presentity, and indeed, it can even ensure that the presentity doesn't know that it is being blocked. The SIP presence specifications (RFC 3856 [21]) require that such authorization processing be performed before divulging presence information. Specifications have also been defined for conveying authorization policies to presence servers [26].
ここで定義されているモデルで説明されている存在情報は非常に敏感です。このため、プライバシーフィルタリングが存在データの処理に重要な役割を果たしています。プライバシーフィルタリングとは、ウォッチャーが確認する権限を与えられていない情報を削除する目的で、プレゼンスドキュメントに権限を適用する行為です。より一般的な用語では、プライバシーフィルタリングは許可の一形態です。また、プライバシーフィルタリングは、ウォッチャーがプレゼンテーションのために存在データを表示できないことを保証することもできます。実際、プレゼンテーションがブロックされていることを紹介していないことを保証することさえできます。SIPプレゼンス仕様（RFC 3856 [21]）では、そのような承認処理を実行する前に実行する必要があります。仕様は、存在サーバーに承認ポリシーを伝えるための定義も定義されています[26]。
Integrity of presence information is also critical. Modification of presence data by an attacker can lead to diverted communications, for example. Protocols used to transport presence data, such as SIP for presence, are used to provide necessary integrity functions.
存在情報の整合性も重要です。たとえば、攻撃者による存在データの変更により、通信の転用につながる可能性があります。SIPの存在などの存在データの輸送に使用されるプロトコルは、必要な整合性関数を提供するために使用されます。
This specification defines a data model that contains mostly tokens that are meant for consumption by programs, not directly by humans. Programs are expected to translate those tokens into language-appropriate text strings according to the preferences of the watcher.
この仕様では、人間が直接ではなく、プログラムによる消費用のトークンを含む主にトークンを含むデータモデルを定義します。プログラムは、ウォッチャーの好みに応じて、これらのトークンを言語に適したテキスト文字列に変換することが期待されています。
However, this specification defines a <note> element that can contain free text. This element and other ones defined by extensions to PIDF that can contain free text SHOULD be labeled with the 'xml:lang' attribute to indicate their language and script. This specification allows multiple occurrences of the <note> element so that the presentity can convey the note in multiple scripts and languages. If no 'xml:lang' attribute is provided, the default value is "i-default" [8].
ただし、この仕様では、無料のテキストを含めることができる<note>要素を定義します。この要素と、無料テキストを含むPIDFへの拡張機能によって定義された他の要素は、「XML：Lang」属性にラベルを付けて、言語とスクリプトを示す必要があります。この仕様により、<mote>要素の複数の発生が可能になり、プレゼンティが複数のスクリプトと言語でメモを伝えることができます。'xml：lang'属性が提供されていない場合、デフォルト値は「i-default」です[8]。
Since the presence model is represented in XML, it provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.
存在モデルはXMLで表されるため、Unicode文字セットとUTF-8を含むよりコンパクトな表現を使用して、情報をエンコードするためのネイティブサポートを提供します。コンフォーマントXMLプロセッサは、UTF-8とUTF-16の両方を認識します。XMLには、<？xml？>宣言で「エンコード」属性を使用して他の文字エンコーディングを特定して使用するための規定が含まれていますが、UTF-8の使用は、サポートの互換性が存在するパーサーエンコードが存在する環境で推奨されます。
There are several IANA considerations associated with this specification.
この仕様に関連するいくつかのIANAの考慮事項があります。
This section registers a new XML namespace, per the guidelines in [4]
このセクションは、[4]のガイドラインに従って、新しいXMLネームスペースを登録します
URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:data-model.
URI：この名前空間のURIはurn：ietf：params：xml：ns：pidf：data-modelです。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
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>A Data Model for Presence</title>
</head>
<body>
<h1>Namespace for Presence Data Model</h1>
<h2>urn:ietf:params:xml:ns:pidf:data-model</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4479.txt">
RFC4479</a>.</p>
</body>
</html>
END
This section registers two XML schemas per the procedures in [4].
このセクションでは、[4]の手順に従って2つのXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:pidf:common-schema.
uri：urn：ietf：params：xml：schema：pidf：commonschema。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
The XML for this schema can be found as the sole content of Section 5.1.1.
このスキーマのXMLは、セクション5.1.1の唯一の内容として見つけることができます。
URI: urn:ietf:params:xml:schema:pidf:data-model.
uri：urn：ietf：params：xml：schema：pidf：data-model。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
The XML for this schema can be found as the sole content of Section 5.1.2.
このスキーマのXMLは、セクション5.1.2の唯一の内容として見つけることができます。
This document is really a distillation of many ideas discussed over a long period of time. These ideas were contributed by many participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat, Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam Roach, Hisham Khartabil, and Jon Peterson contributed many of the concepts that are described here. Example presence documents came from Robert Sparks' example presence documents specification, and ideas on defining services through characteristics, rather than enumeration, came from Adam Roach's service features document. A special thanks to Steve Donovan for discussions on the topics discussed here, and to Elwyn Davies for his final review of the document.
このドキュメントは、実際に長い間議論されている多くのアイデアの蒸留です。これらのアイデアは、単純なワーキンググループの多くの参加者によって提供されました。Aki Niemi、Paul Kyzivat、Cullen Jennings、Ben Campbell、Robert Sparks、Dean Willis、Adam Roach、Hisham Khartabil、およびJon Petersonは、ここで説明する概念の多くを貢献しました。例の存在ドキュメントは、ロバートスパークスの例の存在ドキュメントの仕様から届き、列挙ではなく特性を通じてサービスを定義するためのアイデアは、Adam Roachのサービス機能ドキュメントから来ました。ここで説明したトピックについての議論をしてくれたSteve Donovanと、ドキュメントの最終レビューについてElwyn Daviesに感謝します。
[1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[1] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[2] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[5] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.
[5] Yergeau、F.、Paoli、J.、Sperberg-Mcqueen、C.、Bray、T.、およびE. Maler、「拡張マークアップ言語（XML）1.0（第3版）」、W3C Rec Rec-XML-20040204、2月2004年。
[6] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004.
[6] Maloney、M.、Beech、D.、Thompson、H。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C Rec Rec-XMLSchema-1-20041028、2004年10月。
[7] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[7] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、W3C Rec Rec-XMLSchema-20041028、2004年10月。
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[8] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[10] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[11] 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.
[11] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[12] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[12] ピーターソン、J。、「存在のための共通プロファイル（CPP）」、RFC 3859、2004年8月。
[13] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, December 2005.
[13] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）の国際化されたリソース識別子（IRIS）および統一されたリソース識別子（URI）」、2005年12月の作業。
[14] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message Service", Work in Progress, February 2006.
[14] Wilde、E。およびA. Vaha-Sipila、「GSMショートメッセージサービスのURIスキーム」、2006年2月、Work in Progress。
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[15] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[16] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[16] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[17] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[17] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[18] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[18] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, March 2006.
[19] Rosenberg、J。、「セッション開始プロトコル（SIP）およびスパム」、2006年3月、進行中の作業。
[20] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[20] Leach、P.、Mealling、M。、およびR. Salz、「普遍的にユニークな識別子（UUID）URNネームスペース」、RFC 4122、2005年7月。
[21] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[21] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[22] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
[22] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用している」、2005年10月、進行中の作業。
[23] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[23] Schulzrinne、H。、「RPID：Rich Expension拡張情報情報データ形式（PIDF）」、RFC 4480、2006年7月。
[24] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.
[24] Lonnfors、M。and K. Kiss、「セッション開始プロトコル（SIP）ユーザーエージェント機能存在情報データ形式（PIDF）への拡張機能」、2006年1月、進行中の作業。
[25] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[25] ピーターソン、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[26] Rosenberg, J., "Presence Authorization Rules", Work in Progress, March 2006.
[26] Rosenberg、J。、「プレゼンス認証ルール」、2006年3月、進行中の作業。
[27] Jennings C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, March 2006.
[27] Jennings C.およびR. Mahy、「マネージングクライアントは、セッション開始プロトコル（SIP）の接続を開始しました」、2006年3月、進行中の作業。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。