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).
著作権（C）インターネット協会（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.
この文書では、インスタントメッセージングとプレゼンスを活用拡張機能（SIMPLE）プレゼンスエージェントのセッション開始プロトコル（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:
具体的には、いくつかの重要な概念が明確にモデル化されていないかだけでなく、これらは、以下の通りのRFC 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
プレゼンスのためのデータモデルは、モデルは、プレゼンティティURIによって識別されるプレゼンティティを記述しよう。図1に示されています。人、サービス、およびデバイス：モデル内の3つのコンポーネントがあります。これら3つのデータコンポーネントは、サービス、人、又はデバイスのいくつかの態様の説明を提供する情報（属性と呼ばれる）を含みます。それは彼らがそのサービス、プレゼン、またはデバイスを記述するため、各属性は、サービス、人、またはデバイスと提携しているこのモデルの中心です。これは、それらがそのサービス、プレゼン、又はデバイスによって報告されたので、属性は、サービス、プレゼン、またはデバイスに関連付けられていることにより、モデルとは対照的です。例として、ユーザーが会議中である携帯電話のレポートは、これは「イン・ザ・ミーティング」の状態を示す、人物情報の一部として属性を含めることによって行われるならば。プレゼンス情報は、デバイスとして携帯電話についての情報を含むことができます。しかし、それは、ユーザが会議中であることを報告しているデバイスであっても、「会議中」人間のユーザではなく、自分の物理デバイスを記述する事実です。そのため、この属性は、文書の人物コンポーネントに配置されます。
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です。ネットワーク内の各ユニークなプレゼンのために、一つ以上のプレゼンのURIがあります。それらはプレゼンス（PRES）方式[12]そのようなSIP URIなどのプロトコル固有のURI、[11]または拡張メッセージングおよびプレゼンスプロトコル国際化リソース識別子からURI（両方によって識別されるので、プレゼンティティが複数のURIを有していてもよいです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 SUBSCRIBEリクエストによって要求された場合、例えば、プレゼンティティURIは、SUBSCRIBEリクエストのリクエスト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：bob@example.comは」：と「SIP：r.smith@example.com」「robert@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.
モデルでは、プレゼンにつき一人だけの要素が存在することができます。すなわち、人のコンポーネントモデルの単一人間において、単一の人間のための通信状態に関連する特性および状態を含みます。もちろん、システムは、ユーザのグループ、またはそのことについても、犬とは対照的に、人コンポーネントによって記載されたヒトが、実際には単一の人間であることを確認する方法はありません。諺には、「インターネット上で、誰もあなたが犬です知っている」、と同じことが、ここで真です。人コンポーネントは一人のためのファサードです。一人の人間のように見えるようにすることができるものは、そのファサードでモデル化することができます。
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.
サービスの正確な定義を与えることは困難です。一つの合理的なアプローチは、サービスとして、システム内の各ソフトウェアまたはハードウェア・エージェントをモデル化することです。ユーザーが自分のPC上のソフトフォンアプリケーションを起動した場合は、そのサービスを表します。ユーザがテレビ電話装置がある場合、それは別のサービスを表します。これは、効果的なサービスの物理的な図です。この定義は、しかし、サービスは複数のソフトウェア・エージェントまたはデバイスに分散している時にバラバラにするために開始します。例えば、SIP URIは、ソフトフォン又はテレビ電話、あるいはその両方にルーティング可能なアドレス・オブ・レコードを表します。その場合、1は、ネットワーク上のアドレスに基づいてサービスを定義する代わりにしようとするかもしれません。コールを受信し、それらを潜在的に複雑なロジックに基づいて、異なる「ヘルパー」に派遣デバイスまたはアプリケーションをモデル化するとき、この定義はまた、崩壊してしまいます。例えば、携帯電話は、方法または要求のも身体タイプに基づいて異なるハンドラを「登録」することができ、それぞれが複数の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.
その結果、このモデルでは、サービスは、明示的に列挙されません。 1は、各サービスの識別子を見つけた何中央レジストリはありません。このため、各サービスは、「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進ブール関数を介して機能を表すためのモデルを記載しています。サービスの性質を表す特徴からの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は音声のみをサポートしている場合たとえば、これは最初のサービスに連絡する際、ユーザーは唯一のオーディオストリームを提供している、ということを意味する、または第二に接触したときにはありませんこのサービスは、ユーザーが唯一のビデオ・ストリームを提供しています。ユーザーがサービスに接続することを選択したときの能力やコミュニケーション様式が提供されているものを決定する際に、その裁量でローカルポリシーを使用することができます。ウォッチャーは、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.
各サービスの一つの重要な特徴は、そのサービスが実行されているデバイスのリストです。各デバイスは、デバイス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アドレスを介して到達可能である両方とも、携帯電話内で実行されてもよいです。しかし、一つのアプリケーションは、INVITEリクエストは、特定のタイプのボディを含み、他方は他のボディタイプのために起動したときに起動されます。別の例として、サービスが一致するアプリケーションソフトウェアから接触したときにのみ正しく動作する複雑なアプリケーションロジックを提供することができます。アプリケーションが一致しない限り、このような場合には、インスタンス間の通信は、（例えば、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は、常に後にオーディオストリームを追加することができ、それが動作しますので、例えば、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つの理由で保証することはできません。まず、ドキュメント内のサービスには、実際にユーザが使用する実際のサービスの数をモデリングすることがあり、存在する文書に記載した特徴の全てをサービスにウォッチャを接続することはできないかもしれません。第二に、プレゼンの好みは常に優先されます。呼び出し側は、ビデオサービスに接続するように頼むかもしれないが、それはプレゼンの願いがある場合は、別のサービスにそれらを接続することが許されます。
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のタイプのいくつかのガイダンスを提供します。 URN [3]サービスURIとして使用することができます。 URNは、潜在的に解決することができるので、異なるURIの任意の数、特性、状態、および相対情報がURNから解決することができるURIの全てのために賢明である必要があります。 URNは、サービスの点でますます「あいまい」になるように、それは、対応低下を含めることができるプレゼンス属性の数を識別する。
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]に存在し、複数のENUMサービスは、音声およびメッセージングなど、定義されている場合、非常に少ない特性情報は、そのサービスに含まれ得ることが考えられます。しかし、TEL URIが定義され、単一のENUMサービスを有し、それは公衆交換電話網（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].
サービスへのリーチ情報の多対1のマッピングがあり得ることを指摘することは重要です。すなわち、特定のサービスは、潜在的リーチ情報セットの無限の数を介して到達可能であることができるされています。これは、リーチ情報は単なるサービスURIである場合も同様です。複数のサービスのURIが同じサービスに到達することが許されます。任意の特定の文書の中で、特定のサービスのために、単一のサービスの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.
プレゼンス文書はまったくリーチ情報を持っていないサービスを含むことも可能です。このような場合には、プレゼンティティは、サービスが存在することを示しているが、ウォッチャにそれに接続するための機会を提供しないように選出されます。その一例は、ウォッチャーは、ユーザが電話サービスを持っていることを知っているようにすること、そして、彼らは忙しいですが、呼の受信を避けるために、何のリーチ情報が提供されていないということでしょう。
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.
各サービスは、ユーザが別の上の1つのサービスの利用のために有すること嗜好を表す優先度に関連しています。これは、彼らが常に最優先でサービスを使用する必要があることを、ウォッチャーがプレゼンと通信したいとき、という意味ではありません。それが事実であれば、プレゼンス文書で複数のサービスを含むにはポイントはないだろう。むしろ、優先順位は、あなたが、ウォッチャーは、使用するには、これらのかを決めることができない、またはそれはあなたにとって重要でない場合は、これは私はあなたが私に連絡したいと思いれる順番であれば」、と言います。しかし、私はあなたを与えています選択。"優先順位は、互いに相対的なものであり、絶対数としては意味を持ちません。そこに2つのサービスがあり、それらは1と0.5の優先順位を持っている場合は、それぞれ、これはそれぞれ、それらを0.2と0.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ソフトフォンアプリケーションを指し、そのサービス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.
しかしながら、この動的状態の全ては、プレゼンス文書のサービス・データ・コンポーネント内に含めることが適切ではありません。情報は、それはウォッチャーは、そのサービス、またはウォッチャーが今いない場合は、それをいつ開始するかを決定支援するとの通信を開始するかどうかを決定する手助けにベアリングがある場合にのみ含まれています。一例として、携帯電話が強い信号強度またはちょうど良い信号強度を有するかどうかリトマス試験に合格しません。これを知ることは、このサービスを使用するという決定に影響を与える可能性はほとんどありません。
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テレフォニーサービスを考えてみましょう。二つの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）タグを考えます。このデバイスは、すべてのサービスを実行しません。しかし、デバイスとして、そのような場所のような特性を有し、そしてそれは、そのステータスおよび特性を報告することが可能なネットワーク接続を有していてもよいです。テレビ電話は、それがビデオサービスを実行していたことを報告していた、とその性質の一つは、それがその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の速度はウォッチャーがユーザーの携帯電話を呼び出すしたい場合には、携帯電話で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.
動的（例えば、デバイスがONであるかOFFであるかのように）デバイスの状態、この状態の影響サービスの状態が存在する場合、同様に、これは、サービスの状態を調整することによって表されています。プレゼンス文書の消費者は、（プレゼンスエージェントが頻繁に行うことに留意されたい）そうでない場合を示す先験的な知識を持っていない限り、デバイスの状態は、サービスの状態に関係ありません。
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.
ただ、サービスのように、デバイスの種類のない列挙されていない - ウォッチャーは、デバイスは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は、仮想マシンを実行すると、その仮想マシン内のサービスを実行している場合、2つの個別の装置から構成されているように、そのPCの話にこのモデルを使用することは完全に可能です。
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ユーザエージェントの機能を定義するために使用される、[17] RFC 3840のリードに従います。機能の宣言は、特定の機能タグを省略した場合にその仕様では、それはエージェントが決定的な声明この機能タグがサポートされているかどうかについてのいずれかの方法で作っていないことを意味します。同じことが、ここで真である - 文書からのプレゼンス属性の不在はウォッチャーがそのプレゼンス属性の値についての決定的な声明を出すことができないことを意味します。それはウォッチャーから源泉徴収されている、またはその属性がプレゼンのソフトウェアでサポートされていないので、それが存在しなくてもよいので、それは存在しなくてもよいです。どちらの結論が引き出されることができます。
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は変更されません。しかし、将来のすべてのプレゼンス属性は、<組>ではなく<状態>要素の子として定義されなければなりません。さらに、ここで定義されたスキーマは、<人>や<デバイス>要素のいずれかのために、<ステータス>要素を含んでいません。
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.
このプロパティの帰結は、プレゼンスシステムは無限にcomposeableであるということです。プレゼンス・ユーザ・エージェントは、そのプレゼンスサーバに文書を公開することができます。そのプレゼンスサーバは、他の文書とそれを構成して、ウォッチャへの通知に結果を配置することができます。そのウォッチャーは、実際にはさらに別の通知にこれらの結果を、それが受信した他の人とその文書を組み合わせること、および配置、別のプレゼンス剤であり得ます。
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.
しかし、このプロパティの別の帰結は、文書への反応における暗黙の行動が今までと仮定することができないということです。例えば、サービスはウォッチャーがそのサービスへの通信の試みで、オーディオを提供することを意味するものではありませんオーディオをサポートしていることを示しているという理由だけで。そうするサービスに到達する必要がある場合、これはリーチ情報によって明示しなければなりません。
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
プレゼンス文書を選択し、通信を確立するためにユーザを助けるのに役立つので、プレゼンティティURI - そのドキュメントの指標としては、 - 「ワンナンバー」通信の形態を表します。このURIから始めて、利用者のためのコミュニケーション様式とそのURIのすべてを発見し、その後、特定の通信サービスを呼び出すために使用することができます。むしろ、インターネットを介して別の電話番号、電子メールアドレス、IMアドレス、声を与えることよりも
Protocol (VoIP) address, and so on, the presentity URI can be provided, and all of the others can be learned from there.
議定ように（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.
データモデルは異なる概念として、デバイス、サービス、および人を分離するのは難しいしようとします。この分化の一部は、多くの属性は、これらのいくつかではなく、他の人に適用できるということです。たとえば、地理的な位置は、意味のある人物の属性（ユーザーが場所を持っている）と、（デバイスが場所を持っている）デバイスのではなく、サービスの（サービスが本来の場所を持っていない）です。これに基づき、地理的位置情報は、唯一のデバイスや人、決してサービスの一部として表示されます。また、位置情報は、デバイスおよび人の両方のために搬送されるため可能と意味があり、そしてこれらの位置に異なることができます。プレゼンスシステムは、デバイスのうちの1つの位置からの外挿によって、人の位置を決定しようとするかもしれないという事実は、データモデリングの観点からは無関係です。人の場所やデバイスの場所は同じものではありません。
[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文書内の<タプル>の子要素として実施されることを示しています。 [25]前、本明細書に開発された、そして残念ながら、位置を含むように、その勧告は、下の<タプル>オブジェクトここで勧告に反します。このように、本明細書に基づく実装は、人及び/又は文書のデバイス部品の一部として<geopriv>位置オブジェクトを含むべきであるが、<タプル>の子としてそのオブジェクトにプレゼンス文書を受信するために準備されるべきです。 <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.
<存在>要素は、プレゼンティティのプレゼンス情報が含まれています。この要素の「実体」属性は、プレゼンティティ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文書の既存の<タプル>要素は、サービスを表すために使用されます。これは、RFC 2778およびRFC 3863の本来の意図と一致して、ここで説明したモデルが完了する前に開発された実装との後方互換性を実現しています。 <タプル>要素内の<接点>要素は、サービスURIをエンコードするために使用されます。彼らは、動的な状態や静特性を表す<タプル>の子として直接表示するかどうか新しい存在は、属性。しかし、前<状態>（例えば、<基本>など）の子として定義された本明細書の刊行物に定義された属性は、下位互換性のために、<状態>の子として残ります。そのため、サービスを記述するプレゼンス属性が<状態>または直接<タプル>の子としての子のいずれかのように見えるが、決して両方の可能性があります。
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.
<組>要素の「id」属性は、サービスの発生を伝えます。同じ<接点> URI各<タプル>要素は、特定のサービスの異なる発生を表します。
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.
この仕様は、<存在>の子として表示されます。<人>要素が導入されています。文書ごとに、この要素の0回以上の繰り返しが存在する場合があります。一人一人のために発生識別子が含まれている必須「id」属性を持っています。各<人>要素は、ステータスおよび特性情報を示す任意の数の要素が含まれています。これは、ゼロ以上の任意の<注意>要素およびオプションの<タイムスタンプ>が続きます。複数の<ノート>要素は、複数の言語で同じ音を伝えるように思われます。
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は<存在>の子として存在することができるの<注意>要素、ゼロまたはそれ以上を定義します。それがここで定義されたモデルに関連するように、これらのノート要素は、文書中に存在する場合、自分の<ノート>要素のいずれかを持っていないすべての人の出現に適用されます。 <人>要素は、1つまたは複数の<注意>要素を持っている場合に、他の言葉では、これらは、その<人>要素の<ノート>要素です。 <人>要素は、独自の<ノート>要素のいずれかを持っていない場合は、<存在>の直接の子である要素を<注意>そのため、<ノート>要素、<人>です。 <人>要素の下に何も<ノート>要素が存在しない、と<存在>の直接の子です何の<ノート>要素が存在しない場合は、<人>要素には、<ノート>要素を持っていないこと。
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.
また、この仕様は、<存在>の子として表示されます。<デバイス>要素が導入されています。文書ごとに、この要素の0回以上の繰り返しが存在する場合があります。 <デバイス>要素は、<人>要素の前または後に表示されます。順序には制約がありません。各<デバイス>要素は、デバイスの出現識別子が含まれている必須の「id」属性を有しています。 <人>のように、<デバイス>は、ステータスおよび特性情報を示す任意の数の要素が含まれています。これは、このデバイスのデバイスIDのためにURNを含む、<deviceIDの>が続きます。これは、ゼロ以上の任意の<注意>要素およびオプションの<タイムスタンプ>が続きます。複数の<ノート>要素は、複数の言語で同じ音を伝えるように思われます。
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.
<デバイス>と<人>要素を含む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.
これは、PDF文書に存在するデータモデルのマッピングは、単に構文の練習であることに注意することが重要です。
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.
このモデルに基づいて作成されたプレゼンス文書は、以下の例外を除いて、有効でなければなりません。合成器は、それが完全に検証できないプレゼンス文書を作成することを許可されるが、合成器のスキーマによって許さ緩い処理ルールに従って処理された場合には、そうでなければ検証します。しかし、これらの文書を受信エンティティがスキーマ検証を行うことが期待されていません。むしろ、彼らは単に彼らはそれがあることを期待していた場所で文書からの情報にアクセスします。実装が有効でない文書を受信し、それらが解析できることを彼らからどんな情報を抽出するために準備する必要があります。
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スキーマは、一般的なタイプの定義を含む共通schema.xsdと呼ばれる共通のスキーマ、データ・モデル、データmodel.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>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "修飾されていません" > <XS：インポートの名前空間= "http://www.w3.org/XML/1998/namespace" のschemaLocation = "http://www.w3.org/2001/xml.xsd" /> <XS：単純型の名前= "Timestamp_t"> <XS：注釈> <XS：ドキュメント>タイムスタンプ型</ XS：ドキュメント> </ XS：注釈> <XS：制限ベース= "XS：dateTimeの" /> </ XS：単純> <XS ：simpleTypeの名前= "deviceID_t"> <XS：注釈> <XS：ドキュメント>デバイスID、URN </ XS：ドキュメント> </ XS：注釈> <XS：制限ベース= "XS：anyURIの" /> </ XS：単純> <XS：complexTypeの名前= "Note_t"> <XS：注釈> <XS：ドキュメント>ノートタイプ</ XS：ドキュメンテーション> </ XS：注釈> <XS：simpleContentを> <XS：増設ベース=」 XS：文字列 "> <XS：属性REF =" XML：LANG "/> </ XS：拡張> </ 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>
</ XS：complexTypeの> <XS：attributeGroupの名= "fromUntil"> <XS：属性名=タイプ= "XS：dateTimeの" "から" /> <XS：属性名は= "になるまで" タイプ= "XS：dateTimeの" /> </ XS：attributeGroupの> <XS：complexTypeの名= "空" /> </ XS：スキーマ>
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：PIDF：データ・モデル" のxmlns：XS = "のhttp：// WWW .w3.org / 2001 / XMLスキーマ "のxmlns = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" のelementFormDefault = "修飾" attributeFormDefault = "非修飾"> <XS：のschemaLocation =含む" 共通スキーマ。 XSD "/> <XS：要素名=" deviceIDの」タイプ= "deviceID_t"> <XS：注釈> <XS：ドキュメント>デバイスID、URN </ XS：ドキュメント> </ XS：注釈> </ XS：要素> <XS：要素名= "デバイス"> <XS：注釈> <XS：ドキュメント>はデバイスに関する情報が含まれています。</ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：シーケンス> < XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：要素REF = "のdeviceID" /> <XS：要素名= "ノート" タイプ=」 "要素名= /> <XS "タイムスタンプ" タイプ= "Timestamp_t" のminOccurs = "0"/> </ XS：配列> <XS：属性名= "ID"「のminOccurs = "0" のmaxOccurs =" 無限Note_tタイプ= "XS：ID" 使用= "必要" /> </ XS：complexTypeの> </ XS：要素> <XS：要素NA私= "人"> <XS：注釈> <XS：=任意の名前空間：ドキュメンテーション> </ XS：：注釈> <XS：complexTypeの> <XS：シーケンス> <XSドキュメント>は、人間のユーザー</ XSについての情報が含まれています"##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限"> <XS：注釈>
<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>
<XS：ドキュメント>特性およびステータス情報</ XS：ドキュメンテーション> </ XS：注釈> </ XS：任意の> <XS：のminOccurs = "0" のmaxOccurs = "無制限 "Note_t" 要素名= "注意" タイプ=必要ID "使用= " "/> <XS：要素名=" タイムスタンプ" タイプ= "Timestamp_t" のminOccurs = "0"/> </ XS：配列> <XS：属性名= "ID" タイプ=" XS 「/> </ XS：complexTypeの> </ XS：要素> </ XS：スキーマ>
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.新しい属性は、人、サービス、またはデバイスのデータコンポーネントに適用されますか？それが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.それは新しい名前空間、または既存のいずれかに属していますか？一般的に、同じ仕様内で定義された新しいプレゼンス属性が同じ名前空間に属している必要があります。プレゼンス属性別の仕様で定義されていますが、集中管理による協調ようにして製造されたが、同じ名前空間に配置することができます。そう、しかし、それらの仕様全体で要素名の衝突がないことを確認するために集中管理を必要とします。新しい拡張は、<名前空間=「##その他」>で定義された拡張性の点で他の要素の子として配置されることを意味要素がある場合また、新たな拡張は、親要素とは異なる名前空間を使用しなければなりません。
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.拡張機能自体が拡張性を必要としていますか？もしそうであれば、拡張の点は、スキーマで定義する必要があり、そして<名前空間=「##その他」>構築物を使用して行われるべきです。
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、ヤフーや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]を含みます。
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>
<プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" <XMLバージョン= "1.0" エンコード= "UTF-8"？>のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF ：データ・モデル "のxmlns：RP = "壷：IETF：のparams：XML：NS：PIDF：RPID" のxmlns：キャップ= "壷：IETF：のparams：XML：NS：PIDF：キャップ" のxmlns：XSI =" のhttp： //www.w3.org/2001/XMLSchema-instance "> <タプルID =" sg89ae "> <状態> <基本>開く</塩基性> </状態>の<dm：のdeviceID> MAC：8asd7d7d70 </ DM： deviceID> <キャップ：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>
<キャップ：拡張> <キャップ：サポート> <キャップ：県/> </キャップ：サポート> </キャップ：拡張> <キャップ：メソッド> <キャップ：サポート> <キャップ：MESSAGE /> <キャップ：OPTIONS /> </キャップ：サポート> </キャップ：方法> </キャップ：servcaps> <接点> SIP：someone@example.com </接触> </タプル>の<dm：人物ID = "P1"> <RP：活動> <RP：オン電話/> </ RP：活動> </ DM：人>の<dm：デバイスID = "pc122"> <RP：ユーザ入力>アイドル</ RP：ユーザ入力> < DM：のdeviceID> MAC：8asd7d7d70 </ DM：のdeviceID> </ DM：デバイス> </プレゼンス>
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とデバイス情報の使用、プレゼンスサーバは、VoIPサービスとIMアプリケーションによって報告されたように、デバイスの状態を相関し、それらを一緒に使用することができます。
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].
しかし、この仕様は、フリーテキストを含めることができます。<ノート>要素を定義します。彼らの言語やスクリプトを示すために属性：この要素とフリーテキストを含めることができPIDFの拡張によって定義された他のものは「LANGのxml」でラベル付けされるべき。プレゼンは、複数のスクリプトや言語でノートを伝えることができるように、この仕様は、<ノート>要素の複数の発生を可能にします。 NO 'のxml：langの' の場合、属性が提供されていない場合、デフォルト値は "I-デフォルト" である[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
プレゼンスモデルはXMLで表現されているので、Unicode文字セットとUTF-8などのよりコンパクトな表現を用いて情報を符号化するためのネイティブサポートを提供します。準拠XMLプロセッサは、UTF-8とUTF-16の両方を認識する。 XMLは、<？xmlの？>宣言で「エンコーディング」属性を使用して他の文字エンコーディングを特定して使用するための条項が含まれますが、UTF-8を使用することです
RECOMMENDED in environments where parser encoding support incompatibility exists.
パーサーエンコーディングのサポートの非互換性が存在する環境では推奨。
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：データモデル。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（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
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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル>プレゼンス<ためのデータモデル/ TITLE> </ HEAD> <BODY> <H1>プレゼンスデータモデルの名前空間</ H1> <H2> URN：IETF：のparams：XML：NS： PIDF：データ・モデル</ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc4479.txt"> RFC4479 </a>を参照してください。</ P> </ボディ> </ 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：スキーマ：PIDF：共通のスキーマ。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（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：スキーマ：PIDF：データモデル。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（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.
この文書では、実際に長期間にわたって議論多くのアイデアの蒸留です。これらのアイデアは、SIMPLEワーキンググループの多くの参加者が貢献しました。安芸ニエミ、ポールKyzivat、カレン・ジェニングス、ベン・キャンベル、ロバート・スパークス、ディーンウィリス、アダムローチ、ヒシャムKhartabil、およびジョンピーターソンは、ここで説明されている概念の多くを貢献しました。例のプレゼンス文書はロバート・スパークス例のプレゼンス文書仕様から来て、というよりも、列挙、特性を通じてサービスを定義上のアイデアは、アダムローチのサービス機能文書から来ました。文書の彼の最終的なレビューのために、ここで説明する内容に、とエルウィン・デイヴィスへの議論のためのスティーブ・ドノバンに感謝します。
[1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[1]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3841 "セッション開始プロトコル（SIP）のための発呼側プリファレンス"、2004年8月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3]クロッカー、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.、パオリ、J.、Sperberg-マックィーン、C.、ブレイ、T.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第3版）"、W3C REC REC-XML- 20040204、2004年2月。
[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]マロニー、M.、ブナ、D.、トンプソン、H.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造第二版"、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]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型第二版"、W3C REC REC-XMLSCHEMA-2から20041028、2004年10月。
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[8] Alvestrand、H.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[10]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]サンアンドレ、P.、「国際化資源識別子（IRIを）および拡張メッセージングおよびプレゼンスプロトコル（XMPP）のためのユニフォームリソース識別子（URI）」、進歩、2005年12月に作業。
[14] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message Service", Work in Progress, February 2006.
[14]ワイルド、E.およびA. Vaha-Sipila、 "GSMショートメッセージサービスのためのURIスキーム"、進歩、2006年2月に作業。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[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.及びM. Mealling、RFC 3761、2004年4月 "ユニフォームリソース識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, March 2006.
[19]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）およびスパム"、進歩、2006年3月での作業。
[20] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[20]リーチ、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]ローゼンバーグ、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]ローゼンバーグ、J.、進歩、2005年10月に作品 "セッション開始プロトコル（SIP）におけるグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用" を参照してください。
[23] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[23] Schulzrinneと、H.、 "RPID：リッチプレゼンス機能拡張プレゼンス情報データフォーマット（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.とK.キス、「プレゼンス情報データフォーマット（PIDF）にセッション開始プロトコル（SIP）ユーザエージェントの機能拡張」、進歩、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]ローゼンバーグ、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]ジェニングスC.とR.マーイ、進歩、2006年3月に仕事「セッション開始プロトコル（SIP）でのクライアント開始された接続の管理」を参照してください。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。