RFC4479 日本語訳
4479 A Data Model for Presence. J. Rosenberg. July 2006. (Format: TXT=88399 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 4479 Cisco Systems Category: Standards Track July 2006
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4479年のシスコシステムズカテゴリ: 標準化過程2006年7月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはSession Initiationプロトコル(SIP)によってInstant MessagingとPresence Leveraging Extensions(SIMPLE)存在エージェントに使用される基本的な存在データモデルを定義します。 データモデルはどう一貫したファッションによる存在ドキュメントに様々な通信網を写像するかにおける指導を提供します。
Rosenberg Standards Track [Page 1] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[1ページ]。
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
1. 序論…2 2. 定義…3 3. モデル…5 3.1. Presentity URI…6 3.2. 人…7 3.3. サービス…8 3.3.1. 特性…9 3.3.2. 情報に達してください…10 3.3.3. 相対的な情報…13 3.3.4. 状態…13 3.4. デバイス…15 3.5. モデルのあいまいさ…17 3.6. 無の意味…19 3.7. 状態対特性…19 3.8. 存在ドキュメントの特性…20 4. モデルに関する動機…21 5. コード化します。22 5.1. XML Schemas…24 5.1.1. 一般的な図式…24 5.1.2. データはモデル化されます…25 6. 存在を広げて、モデル化してください…26 7. 例の存在ドキュメント…26 7.1. 基本的な不-クライアント…27 8. セキュリティ問題…29 9. 国際化問題…29 10. IANA問題…30 10.1. つぼのサブ名前空間登録…30 10.2. XML図式登録証明書…31 10.2.1. 一般的な図式…31 10.2.2. データはモデル化されます…31 11. 承認…31 12. 参照…32 12.1. 標準の参照…32 12.2. 有益な参照…32
1. Introduction
1. 序論
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
存在はユーザが1セットのデバイスの向こう側に交信する能力と意欲を伝えます。 RFC2778[10]は、存在情報を提供するシステムについて説明するためにモデルと用語を定義します。 RFC3863[1]は、存在情報を表すためにXML[5][6][7]ドキュメント・フォーマットを定義します。 これらの仕様では、存在情報は一連のtuplesとしてモデル化されます。それはそれぞれ状態、コミュニケーションアドレス、および他のマークアップを含みます。 しかしながら、どちらの仕様もtupleがまさに何にモデル化することになっているか、そして、またはどのように本当の世界通信網を写像するかに関して指導を与えない、(コネ
Rosenberg Standards Track [Page 2] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[2ページ]。
particular, those built around the Session Initiation Protocol (SIP) [11]) into a presence document.
特定であることで、ものは存在ドキュメントへのSession Initiationプロトコル(SIP)[11])の周りに建てられました。
In particular, several important concepts are not clearly modeled or well delineated by RFCs 2778 and 3863. These are the following:
いくつかの重要な概念が、特に、明確にモデル化されていないか、またはRFCs2778と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.
この仕様は、存在データモデルによってこれらの概念をより完全に定義して、どのように実際の世界システムを連れて行って、存在ドキュメントにそれらを写像するかをそのモデルを使用することで具体的に定義します。 このデータモデルは拡大でRFC3863と定義されます。
2. Definitions
2. 定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[9]で説明されるように本書では解釈されることであるべきですか?
This document makes use of many additional terms beyond those defined in RFC 2778 and RFC 3863. These new terms are as follows:
このドキュメントはRFC2778とRFC3863で定義されたものを超えた多くの追加用語を利用します。 これらの新学期は以下の通りです:
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.
発生: 特定のサービス、特定のデバイス、または人のただ一つの記述。 特定のサービスかデバイスのための複数の発生、またはPresence情報Data Format(PIDF)ドキュメントにおける複数の人の発生があるかもしれません、すなわちあいまいさがある最善がウォッチャーで決議した場合で。
Rosenberg Standards Track [Page 3] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[3ページ]。
Presentity: A presentity combines devices, services, and person
information for a complete picture of a user's presence status on
the network.
Presentity: presentityはネットワークのユーザの存在状態の完全な画像のためのデバイス、サービス、および人の情報を結合します。
Presentity URI: A URI that acts as a unique identifier for a
presentity and provides a handle for obtaining presence
information about that presentity.
Presentity URI: presentityのためにユニークな識別子として機能して、そのpresentityの存在情報を得るのにハンドルを提供する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.
以下を結果と考えてください。 状態か特性。 それは1片の存在情報を表します。
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.
構成: 1セットのpresentityに関する存在とイベントデータをそのpresentityの状態の一貫性を持っている画像に結合する行為。
Rosenberg Standards Track [Page 4] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[4ページ]。
3. The Model
3. モデル
+----------------------------------------------------------------+
| |
| +----------------+ |
| +----------------+| |
| | || |
| | || |
| | Person || |
| | ||\ |
| /| |+ \ |
| / +----------------+ \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| V V V |
| +----------------+ +----------------+ +----------------+ |
| +----------------+| +----------------+| +----------------+| |
| | || | || | || |
| | || | || | || |
| | Service || | Service || | Service || |
| | || | || | || |
| | |+ | |+ | |+ |
| +----------------+ +----------------+ +----------------+ |
| \ / \ |
| \ / \ |
| \ / \ |
| V V V |
| +----------------+ +----------------+ |
| +----------------+| +----------------+| |
| | || | || |
| | || | || |
| | Device || | Device || |
| | || | || |
| | |+ | |+ |
| +----------------+ +----------------+ |
| |
| |
| Presentity (URI) |
+----------------------------------------------------------------+
+----------------------------------------------------------------+ | | | +----------------+ | | +----------------+| | | | || | | | || | | | 人|| | | | ||\ | | /| |+ \ | | / +----------------+ \ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | | V V V| | +----------------+ +----------------+ +----------------+ | | +----------------+| +----------------+| +----------------+| | | | || | || | || | | | || | || | || | | | サービス|| | サービス|| | サービス|| | | | || | || | || | | | |+ | |+ | |+ | | +----------------+ +----------------+ +----------------+ | | \ / \ | | \ / \ | | \ / \ | | V V V| | +----------------+ +----------------+ | | +----------------+| +----------------+| | | | || | || | | | || | || | | | デバイス|| | デバイス|| | | | || | || | | | |+ | |+ | | +----------------+ +----------------+ | | | | | | Presentity(URI)| +----------------------------------------------------------------+
Figure 1
図1
Rosenberg Standards Track [Page 5] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[5ページ]。
The data model for presence is shown in Figure 1. The model seeks to describe the presentity, identified by a presentity URI. There are three components in the model: the person, the service, and the device. These three data components contain information (called attributes) that provide a description of some aspect of the service, person, or device. It is central to this model that each attribute is affiliated with the service, person, or device because they describe that service, presentity, or device. This is in contrast to a model whereby the attributes are associated with the service, presentity, or device because they were reported by that service, presentity, or device. As an example, if a cell phone reports that a user is in a meeting, this would be done by including an attribute as part of the person information, indicating a status of "in-a-meeting". The presence information may also include information on the cell phone as a device. However, even though it is the device that is reporting that the user is in a meeting, "in a meeting" is a fact that describes the human user, not their physical device. Consequently, this attribute is placed in the person component of the document.
存在のためのデータモデルは図1で見せられます。 モデルはpresentity URIによって特定されたpresentityについて説明しようとします。 モデルには3つのコンポーネントがあります: 人、サービス、およびデバイス。 これらの3個のデータ構成要素がサービス、人、またはデバイスの何らかの局面の記述を提供する情報(属性と呼ばれる)を含んでいます。 このモデルに、それは主要です。彼らがそのサービス、presentity、またはデバイスについて説明するので、各属性はサービス、人、またはデバイスに加わられます。 これはそれらがそのサービス、presentity、またはデバイスによって報告されたので属性がサービス、presentity、またはデバイスに関連しているモデルと対照的になっています。 例として、携帯電話が、ユーザがミーティングでいると報告するなら、人の情報の一部として属性を含んでいることによって、これをするでしょう、「ミーティング」における状態を示して。 また、存在情報はデバイスとして携帯電話の情報を含むかもしれません。 しかしながら、それはユーザがミーティングでいると報告しているデバイスですが、「ミーティング」はそれらのフィジカル・デバイスではなく、人間のユーザについて説明する事実です。 その結果、この属性はドキュメントの人の部品に置かれます。
3.1. Presentity URI
3.1. Presentity URI
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.
presentityのための識別子はURIです。 ネットワークにおけるそれぞれのユニークなpresentityのために、1つ以上のpresentity URIがあります。 presentityには、それらがPresence(pres)体系[12]からのURIとプロトコル特有のURIの両方によって特定されるので、複数のURIがあるかもしれません、SIP URI[11]やExtensible MessagingとPresenceプロトコルInternationalized Resource Identifier(XMPP IRI)[13]のように。 またはそれはユーザがドメイン(それのすべてがpresentityに、同等な識別子である)にいくつかの別名を持っているからであることができます。
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.
ドキュメントが構成されるとき、presentity URIは理想的に第一にドキュメントを要求するのにおいて中古の識別子に設定されます。 例えば、ドキュメントがSIP SUBSCRIBE要求で要求されるなら、presentity URIがRequest URIに合っている、登録、要求。 これは少しの驚きの原則に従います、ドキュメントを要求する実体がpresentityのための他の識別子を意識していないかもしれないので。
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が取られる体系において関係ありません、presentity URIはpresentityが持っているサービスかデバイスのいずれからも独立しています。 しかしながら、URIは名前であるだけではありません--加入できるリソースを表します、ユーザの状態を見つけるために。 URIがSIP URIであるときに、それはしばしばユーザのためのRecordのAddressになるでしょう。(そのユーザにSIP呼び出しを向けることができます)。 この等価性は、この仕様で強制されませんが、覚えていることの負担をゆるめるためのお勧めの構成とユーザのために識別子を保存することです。
Rosenberg Standards Track [Page 6] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[6ページ]。
3.2. Person
3.2. 人
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".
人の特性は通常の状況下で変化しないユーザの静的な情報です。 そのような情報は時代や高さなどの物理的な特性を含むかもしれません。 人の特性に関する別の例は別名です。 別名はURIです。同じユーザの、しかし、aについて異なったアイデンティティはURIをpresentityします。 例えば、「一口: bob@example.com 」が別名を示す人のコンポーネントがある存在ドキュメントを持っているかもしれないpresentityは「: robert@example.com をちびちび飲ん」で、「: r.smith@example.com をちびちび飲みます」。
Status information about a presentity represents the dynamic information about a user. This typically consists of things the *user* is doing, places the *user* is at, feelings the *user* has, and so on. Examples of typical person status are "in a meeting", "on the phone", "out to lunch", "happy", and "writing Internet Drafts". The line between static status information and dynamic status information is fuzzy, and it is not important that a line be drawn. The model does not differentiate in a syntactically or semantically meaningful way between these two types of attributes.
presentityの状態情報はユーザに関する動的情報を表します。 これは*ユーザ*がしていること、*ユーザ*がいる場所、*ユーザ*が持っている気持ちなどから通常成ります。 典型的な人の状態に関する例は、「電話」で「馬鹿で」、「幸福である」「ミーティング」と、「インターネットDraftsに書きます」です。 静的な状態情報とダイナミックな状態情報の間の系列はあいまいです、そして、線が描かれるのは、重要ではありません。 モデルはこれらの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.
モデルには、1presentityあたり1つの人のコンポーネントしかあることができません。 言い換えれば、人のコンポーネントは、独身の人間をモデル化して、独身の人間のためのコミュニケーション州に関連する特性と状態を含んでいます。 もちろん、システムには、人のコンポーネントによって説明された人間が実際に独身の人間であることを確かめる方法が全くありません、ユーザー層、またはさらに言えば、犬と対照的にさえ。 諺にもあるとおり、「インターネットでは、だれも、あなたが犬であることを知らない」で、同じくらいはここで本当です。 人のコンポーネントは1人の人のための正面です。 その正面で1人の人に似させることができる何でもモデル化できます。
As an example, consider the task of using a presence document to describe a customer support help desk. The person component can be considered to be "busy" if none of the support staff are available, and "at lunch" if the help desk department has a group lunch together. The watcher that receives the document will consider the help desk to be a single person; nothing in the document (except perhaps the note element, should its value be "help desk" or something similar) conveys information that would indicate that the person in question is actually a help desk.
例として、説明する存在ドキュメントを使用するタスクが顧客サポートヘルプデスクであると考えてください。 補助スタッフのだれ一人手があかないなら人のコンポーネントが「忙しい」と考えることができて、「昼食」はヘルプデスク部であるならグループ昼食を一緒に食べます。 ドキュメントを受け取るウォッチャーは、ヘルプデスクが1人の人であると考えるでしょう。 ドキュメント(恐らく注意要素を除いてください、値が「ヘルプデスク」か何かであること同様のものなら)の何も問題の人が実際にヘルプデスクであることを示す情報を伝えません。
Rosenberg Standards Track [Page 7] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[7ページ]。
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で議論するようにあいまいである場合で起こります。
3.3. Service
3.3. サービス
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).
各presentityは多くのサービスに近づく手段を持っています。 それぞれのこれらはユーザと対話するのに使用できるコミュニケーションのために可到達性のポイントを表します。 サービスの例は、電話(すなわち、伝統的な回路ベースの電話サービス)と、プッシュから話と、インスタントメッセージングと、Short Message Service(SMS)と、Multimedia Message Service(MMS)です。
It is difficult to give a precise definition for service. One reasonable approach is to model each software or hardware agent in the system as a service. If a user starts a softphone application on their PC, then that represents a service. If a user has a videophone device, then that represents another service. This is effectively a physical view of services. This definition, however, starts to fall apart when a service is spread across multiple software agents or devices. For example, a SIP URI representing an address-of-record can be routed to a softphone or a videophone, or both. In that case, one might attempt instead to define a service based on its address on the network. This definition also falls apart when modeling devices or applications that receive calls and dispatch them to different "helpers" based on potentially complex logic. For example, a cellular telephone might house multiple SIP applications, each of which can "register" different handlers based on the method or even body type of the request. Each of those applications or handlers can rightfully be considered a service, but it doesn't have an address on the network distinct from the others.
サービスのための厳密な定義を与えるのは難しいです。 1つの合理的なアプローチはサービスとしてシステムのそれぞれのソフトウェアかハードウェアエージェントをモデル化することです。 ユーザがソフトフォンアプリケーションをそれらのPCに始めるなら、それはサービスを表します。 ユーザがテレビ電話デバイスを持っているなら、それは別のサービスを表します。 事実上、これは物理的なサービスの視点です。 しかしながら、サービスが複数のソフトウェアエージェントかデバイスの向こう側に広げられるとき、この定義はバラバラに壊れ始めます。 例えば、記録されている住所を表すSIP URIはソフトフォン、テレビ電話、または両方に発送できます。 その場合、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.
正確にサービスを定義することにおけるこの固有の苦労のために、データモデルはサービスであると考えることができることを抑制しようとしません。 むしろ、このモデルによって定義された1セットの基本性質を示す限り、サービスであると何でも考えることができます。 それぞれのサービスは自然を特定する特性とそのサービスの能力に特に、関連しています、サービスに接続する方法を示す範囲情報で、状態情報がそのサービスが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,
結果として、このモデルでは、サービスは明らかに列挙されません。 どんな中央の登録も1つが各サービスのための識別子を見つけるところにありません。 その結果、各サービスには、"ptt"か「電話」などの値があるただ一つの「サービス」属性がありません。 それは、これらの統合あだ名が役に立たないことを意味しません。 本当に
Rosenberg Standards Track [Page 8] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[8ページ]。
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つのサービスオーバーに別のものを選ぶことができるアイコンを作成する際に役に立ちます。 ウォッチャーはサービスに関連している情報のいずれからもそのような総括情報を自由に作成できます。 範囲情報はしばしばそのような総括を作成するための貴重な情報を提供します。 しばしば、URIの体系はサービスが何であるかに関する意見と同義です。 "sms"URI[14]は明確に例えばSMSを示します。 いくつかのURIのために、利用可能な多くのサービスがあるかもしれません、例えば、SIPかその場合、tel[15]、体系が概要を作成する方法としてそれほど重要ではありません。 また、範囲情報はソフトウェアが呼び出されるために持っているそのあるアプリケーション(テレビゲームなどの)を示すかもしれません、その場合、範囲情報のその局面がゲームの映像的表象を生成することの役に立つでしょう。
3.3.1. Characteristics
3.3.1. 特性
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を呼び出すとき、自然について説明する特性と経験されるサービスの能力は各サービスを飾られます。 サービスの本質は1セットのそのサービスに確立されたコミュニケーションセッションの向こう側に比較的静的な特性です。 サービスの本質は、描写的である傾向があります。 サービスの本質に関する例は対話的な声の応答かボイスメールサーバを表すか、それがオートマトンであるかそれが仕事の目的に利用された電話サービスであるということです。 他方では、能力は示されるかもしれない特性を表します、そして、それらが示されるかどうかが交渉とセッション設立の間に行われる他の動態関数に依存します。 そのような能力に関する例は、使用されるかもしれないメディアのタイプ、受入れられるコミュニケーション、拡大がサポートしたSIPの方向性などです。 能力は非常に複雑である場合があります。 例えば、RFC2533[16]は、N-ary論理演算子機能を通して能力を表すためにモデルについて説明します。 サービスの本質を表す特性からの1つの様式(例えば、このサービスは声をするだけである)がある能力を差別化するのは難しいです。 しかしながら、そうするのは重要ではありません。
Characteristics are important when multiple services are indicated. That is because the purpose of listing multiple services in a presence document is to give the watcher a *choice*. That is, the presentity is explicitly offering the watcher an opportunity to contact them using a multiplicity of different services. To help the watcher make a decision, the presence document includes characteristics of each service that help differentiate the services from each other and give the watcher the context in which to make a choice.
複数のサービスが示されるとき、特性は重要です。 それは存在ドキュメントにおける複数のサービスを記載する目的が*選択*をウォッチャーに与えることであるからです。すなわち、presentityは明らかに異なったサービスの多様性を使用することでそれらに連絡する機会をウォッチャーに提供しています。 ウォッチャーが決定するのを助けるために、存在ドキュメントは互いとサービスを区別するのを助けて、選択をする文脈をウォッチャーに与えるそれぞれのサービスの特性を含んでいます。
Rosenberg Standards Track [Page 9] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[9ページ]。
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つのサービスを含んで、もう片方が単にビデオだけを支えますが、人がオーディオを支えるなら、これが、ファーストサービスに連絡するとき、ユーザがオーディオストリームだけを提供しなければならないことを意味しないか、またはユーザはビデオストリームだけを申し出なければなりません。 サービスに接続するのを選ぶと様式がどんな能力かコミュニケーションに提供されるかを自己判断で決定する際にユーザはローカルの方針を使用できます。 ウォッチャーが特性が存在ドキュメントで説明されている状態で要求のルーティングをサービスに要求するためにSIP訪問者好み[2]を加えるのは必要ではありません。
If, in order to reach a service, the user agent must generate a request that exhibits a particular capability or contains a specific header, then this is indicated separately in the reach information, described below.
ユーザエージェントがサービスに達するように特定の能力を示すか、または特定のヘッダーを含む要求を生成しなければならないなら、これは別々に以下で説明された範囲情報で示されます。
One important characteristic of each service is the list of devices on which that service executes. Each device is identified uniquely by a device ID. As such, the service characteristics can include a list of device IDs. A presence document might also contain information on each device, but this is a separate part of the document. Indeed, the information on each device might not even be present in the document. In that case, the device IDs listed for each service are nothing more than correlation identifiers, useful for determining when two services run on the same device. The benefit of this model is that information on the devices can be filtered out of a presence document, yet the service information, which includes the device IDs, remains useful and meaningful.
それぞれのサービスの1つの重要な特性がデバイスのリストです。そのサービスが実行するものに関して。 各デバイスはデバイスIDによって唯一特定されます。 そういうものとして、サービスの特性はデバイスIDのリストを含むことができます。 また、存在ドキュメントはそれぞれのデバイスの情報を含むかもしれませんが、これはドキュメントの別々の部分です。 本当に、それぞれのデバイスの情報はドキュメントに存在してさえいないかもしれません。 その場合、各サービスのために記載されたデバイスIDはただ相関関係識別子です、2つのサービスがいつ同じデバイスで動くかを決定することの役に立ちます。 このモデルの利益が存在ドキュメントからデバイスの情報をフィルターにかけることができるということである、しかし、サービス情報(デバイスIDを含んでいる)は役に立って重要なままで残っています。
It is perfectly valid for a presence document to contain just a single service. This is permitted even if the presentity actually has multiple services at their disposal. The lack of multiple services in the document merely means that the presentity is not offering a choice to the watcher. In such a case, the service characteristics are less important, but may be helpful in allowing a watcher to decide if they wish to communicate at all.
存在ドキュメントがまさしくただ一つのサービスを含むのは、完全に有効です。 presentityに複数のサービスが彼らの自由に実際にあっても、これは受入れられます。 ドキュメントの複数のサービスの不足は、presentityをウォッチャーと好きなのを選んでよいといっていることを単に意味しません。 このような場合には、サービスの特性は、それほど重要ではありませんが、ウォッチャーが、それらがいったい交信したがっているかどうか決めるのを許容する際に役立っているかもしれません。
3.3.2. Reach Information
3.3.2. 情報に達してください。
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
サービスが通信網の上でアクセスしやすいときに、範囲情報はサービスにアクセスするために「当たることができる」URIを含んでいます。 このURIはサービスURIと呼ばれます。 しかしながら、いくつかのサービスはそうではありません。
Rosenberg Standards Track [Page 10] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[10ページ]。
accessible over a communications network (such as in-person communications or a written letter), and as such, may not utilize a 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つのアプリケーションが携帯電話の中に稼働しているかもしれません。その両方がユーザのRecordのSIP Addressを通して届いています。 しかしながら、INVITE要求が特定のタイプのボディーを含むとき、1つのアプリケーションが進水します、そして、もう片方が他のボディータイプのために始められます。 別の例として、サービスは合っているアプリケーション・ソフトから連絡される場合にだけ正しく作動する複雑なアプリケーション論理を提供するかもしれません。 このような場合には、インスタンスのコミュニケーションは標準プロトコル(SIPなどの)を利用しますが、アプリケーションが取り組んでいない場合、ユーザー・エクスペリエンスは正しくならないでしょう。
When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information.
URIが十分で、追加しているサービスの属性がそれを提示することであるかもしれないということでないときに、どう達するかに関するサービスがことである指示を定義してください。 サービスが利用されるのをこれらの属性を理解しなければなりません。 ウォッチャーが範囲情報を含む存在ドキュメントを受け取るなら、分からないで、サービス情報を捨てるべきです。
The reach information is an important part of the service. When the watcher makes a decision about which service of the presentity they wish to access, the watcher utilizes the reach information for that service. For this reason, each service has to have a unique set of reach information. If this was not the case, the user would have no way to choose between the services. This means that the reach information represents a unique identifier for the service. However, a presence document can contain multiple occurrences of a particular service, each of which contains the same reach information, but differs in its occurrence identifier. Multiple occurrences of a service exist in a document when the state of the service is ambiguous, as discussed in Section 3.5.
範囲情報はサービスの重要な部分です。 彼らがpresentityのどのサービスにアクセスしたがっているかに関してウォッチャーが決定すると、ウォッチャーはそのサービスのための範囲情報を利用します。 この理由で、各サービスには、ユニークな範囲情報がなければなりません。 これがそうでないなら、ユーザには、サービスを選ぶ方法が全くないでしょうに。 これは、範囲情報がサービスのためのユニークな識別子を表すことを意味します。 しかしながら、存在ドキュメントは複数の特定にそれのそれぞれが同じ範囲情報を含んでいますが、発生識別子において異なるサービスの発生を含むことができます。 サービスの状態があいまいであるときに、複数のサービスの発生がドキュメントに存在しています、セクション3.5で議論するように。
Because the reach information serves as an identifier for a service, it also serves as a way to figure out whether a communications capability should be represented as one service or more. Something cannot be a service unless there is a way to reach it separately from another service. As an example, consider a softphone application that is capable of audio and video. It is not possible to describe this softphone as two services - one capable of just audio, and one capable of just video. That's because there is no way to reach the video-only service; for example, sending a SIP INVITE with just a video stream doesn't suffice, since one can always add the audio stream later and it will work. Video and audio, in this case, represent capabilities for a single service.
範囲情報がサービスのための識別子として機能するので、また、それはコミュニケーション能力が1つ以上のサービスとして表されるべきであるかどうか理解する方法として機能します。 別々に別のサービスからそれに達する方法がない場合、何かがサービスであるはずがありません。 例として、ソフトフォンがオーディオができるアプリケーションとビデオであると考えてください。 2つのサービスとしてこのソフトフォンを記述するのは可能ではありません--まさしくオーディオができる1つ、およびまさしくビデオができる1つ。 それはビデオだけサービスに達する方法が全くないからです。 例えば、まさしくビデオストリームがあるSIP INVITEを送るのは十分ではありません、人が後でいつもオーディオストリームを加えることができて、働くので。 ビデオとオーディオはこの場合ただ一つのサービスのために能力を表します。
Rosenberg Standards Track [Page 11] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[11ページ]。
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.
範囲情報は契約の弱形を表します。 presentityは、存在ドキュメントに情報を含んでいて、ウォッチャーが範囲を利用するならウォッチャーが存在ドキュメントに特性を含んでいることによって説明されたサービスに接続されるかもしれないとウォッチャーに言います。 圧力に、これが何らかの方法で保証でないことは重要です。 それは2つの理由のための保証であるはずがありません。 まず最初に、ドキュメントにおけるサービスは実際にユーザによって使用された多くの就航をモデル化するかもしれません、そして、特性のすべてが存在ドキュメントで説明されている状態でウォッチャーをサービスに接続するのは可能でないかもしれません。 2番目に、presentityの好みはいつも優先します。 訪問者は、ビデオサービスに関連づけられるように頼むかもしれませんが、異なったサービスにそれらを接続するのはそれがpresentityの願望であるなら許されています。
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のタイプで何らかの指導を提供します。 サービスURIとしてURN[3]を使用できます。 しかしながら、潜在的にいろいろな異なったURIにURNを決議できたので、特性、状態、および相対的な情報は、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サービスが定義したシングルしかなくて、Public Switched Telephone Network(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
サービスへの範囲情報に関する1つへの多くマッピングがあることができると指摘するのは重要です。 すなわち、特定のサービスは無限の数の範囲一組の情報を通して潜在的に届いている場合があります。 これは範囲情報がただサービスURIであっても本当です。 複数のサービスURIが同じサービスに達するのは、許されています。 どんな特定のドキュメントの中にも、特定のサービスのために、ただ一つのサービスURIがあるでしょう。 しかしながら、異なったサービスURIを異なったウォッチャーに提供するか、または時間がたつにつれて特定のウォッチャーに提供されたサービスURIを変えるのが、許容されていて貴重でさえあります。 事実上、そうするのは多くの利益を都合します。 それはその試みのための文脈を決定するコミュニケーション試みの受取人を許容できます--その結果、試みをしました。
Rosenberg Standards Track [Page 12] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[12ページ]。
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].
特定の存在ドキュメントにおける特定のサービスに達しようとします。 コミュニケーションスパム、例えば、[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.
また、存在ドキュメントが範囲情報を全く持っていないサービスを含むのも、可能です。 このような場合には、presentityは、サービスが存在するのを示していますが、それに接続する機会をウォッチャーに提供しないのを選んでいます。 その一例がウォッチャーにユーザには電話サービスがあって、それらが忙しいのを知らせるだろうことですが、呼び出しの領収書を避けるために、範囲情報を全く提供しません。
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への拡張子は明確にそういうものとしてそれらの属性を呼び出すべきです。
3.3.3. Relative Information
3.3.3. 相対的な情報
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つのサービスオーバーの用法のために別のものを飼っています。 ウォッチャーがpresentityとコミュニケートしたがっているとき、これはそれを意味しないで、彼らはいつも最優先があるサービスを利用するべきです。 それがそうであるなら、存在ドキュメントには複数のサービスを含む意味が全くないでしょうに。 むしろ、優先権は言います、「あなた(ウォッチャー)は、これらのどれを使用するか、そして、またはあなたにとって、これが私が、私に連絡して欲しいオーダーであることが重要でないかどうか決めることができない」なら。 「しかしながら、選択を差し上げています。」 プライオリティには、互いに比例していて、無名数として意味がありません。 2つのサービスがあって、それらに1と.5のプライオリティがあるなら、それぞれ、これはそれらがそれぞれ.2と.1のプライオリティであるのと同じです。
3.3.4. Status
3.3.4. 状態
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
また、各サービスには、状態がいます。 状態は、そのサービスを利用することでコミュニケーションの有用性の一般にダイナミックな情報を表します。 これは特性と対照的になっています。特性は静的な色々とサービスの特性について公正に説明します。 最も簡単なフォームの状態は基本的な状態です。(その状態はそのサービスを利用するコミュニケーションのための有用性の2進のインディケータです)。 それは、どちらかの値が「閉じられること」を持っているか、または「開くことができます」。 サービスへのコミュニケーションがすべての見込み、やり損ないで望んでいる「閉じている」手段はそうしないでしょう。
Rosenberg Standards Track [Page 13] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[13ページ]。
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.
通話相手に届いてください、またはサービスの特性によって説明されるようにコミュニケーションをもたらさないでしょう。 例として、ユーザが忙しいか、または入手できないなら呼び出しをボイスメールに送るなら、「閉じられる」としてサービスをマークします。 同様に、presentityはサービスURIとしてホテルの電話番号を含むかもしれません。 それでも、チェックアウトの後に、電話番号は鳴るでしょうが、ルームメイドか次のゲストに届いてください。 したがって、そのpresentityによって「閉じられ」て、それは宣言されるでしょう。 ユーザが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.
しかしながら、この動態のすべては存在ドキュメントのサービスデータ構成要素の中に含んでいるのが適切であるというわけではありません。 ウォッチャーが、そのサービスとのコミュニケーションを開始するかどうか決めるのを助けるか、ウォッチャーが、いつそれを開始するかを決めるのを助ける、または現在ベアリングを持っている場合にだけ、情報は含まれています。 例として、携帯電話には強い信号強度かまさしく良い信号強度があるかどうかがリトマス試験に合格しません。 これを知っているのはこのサービスを利用するという決定に影響を与えそうにはありません。
Rosenberg Standards Track [Page 14] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[14ページ]。
3.4. Device
3.4. デバイス
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が電話をする2はこのサービスのためにRecordの独身のAddressに対して登録されることができます。 その結果、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.
その上、単一のデバイスはサービスを全くサポートすることができません。 このような場合には、デバイス自体には、どんな役に立つ存在情報もありません。 しかしながら、サービスと関連してこの同じデバイスについて説明する他のドキュメントで構成されると、より豊かな存在ドキュメントを作成できます。 例えば、Radio Frequency ID(RFID)タグをデバイスと考えてください。 このデバイスは少しのサービスも実行しません。 しかしながら、デバイスとして、それには、位置などの特性があります、そして、それがその状態と特性を報告できるネットワークの接続性を持っているかもしれません。 テレビ電話が、ビデオサービスを実行していたと報告することになっていて、特性の1つがそれがそのRFIDと共にタグ付けをされたということであるなら、植字工は、ビデオ電話デバイスの位置に関して何かを言うのに2通のドキュメントを一緒に結合して、RFIDの位置を使用できるでしょうに。
Devices are identified with a device ID. A device ID is a URI that is a globally and temporally unique identifier for the device. In particular, a device ID is a URN. The URN has to be unique across all other devices for a particular presentity. However, it is also highly desirable that it be persistent across time, globally unique, and computable in a fashion so that different systems are likely to refer to the device using the same ID. With these properties, differing sources of presence information based on device status can be combined. The last of these three properties - readily computable - is particularly useful. It allows for a compositor to combine disparate sources of information about a device, all linked by a common device ID that each source has independently used to identify the device in question.
デバイスはデバイスIDと同一視されています。 デバイスIDはデバイスのためのグローバルで時間的にユニークな識別子であるURIです。 デバイスIDは特に、URNです。 特定のpresentityに、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
残念ながら、これらの特性を持っている使用されるべきただ一つのURN体系には、現存する異なったデバイスのバラエティーのために、それは難しいです。 複数の体系が異なったタイプに、適切な異なったもので定義されると予期されます。
Rosenberg Standards Track [Page 15] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[15ページ]。
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.
デバイス。 携帯電話に関しては、例えば、Electronic Serial Number(ESN)は良い識別子です。 IPデバイスに関しては、MACアドレスは別の良い1つです。 MACアドレスは、容易に計算できることの特性を持っていますが、時間の向こう側に固執を欠いています(それは、デバイスの上のインタフェースカードが変化するつもりであったかどうかを変えるでしょう)。 どのような場合でも、これらのどちらもこのとき、URN体系に関連していません。 その間、Universally Unique IDentifier(UUID)URN[20]を使用できます。 MACアドレスがあるデバイスに関しては、バージョン1UUIDsはRECOMMENDEDです、彼らがMACアドレスを利用する時間ベースの識別子をもたらしている間。 MACのないデバイスに関しては、バージョン4UUIDはRECOMMENDEDです。 ユニークさを提供して、これは純粋に無作為の識別子です。 次に、デバイスのための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の速度、およびメモリー容量。 状態情報はデバイスに関する動的情報を含んでいます。 これはデバイスがオンかオフに動かされるかどうかデバイスに残っている電池残量の量、デバイスの地理的な位置などを含んでいます。
Rosenberg Standards Track [Page 16] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[16ページ]。
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の量を減少させるかもしれません。 より高い品質ビデオがデバイスで利用可能であることを示す願望があれば、まさしくそれを言うサービスの特性を含んでいることによって、それをするべきです。 ウォッチャーがPCであるデバイスと携帯電話であるものを区別するのを助ける際にCPUの速度は役に立つかもしれません、ウォッチャーがユーザの携帯電話と呼びたがっている場合で。
Similarly, if there is dynamic device status (such as whether the device is on or off), and this state impacts the state of the service, this is represented by adjusting the state of the service. Unless a consumer of a presence document has a priori knowledge indicating otherwise (note that presence agents often do), the state of a device has no bearing on the state of the service.
同様に、ダイナミックなデバイス状態(デバイスがオンであるか、またはオフであるかなどの)がいて、この州がサービスの状態に影響を与えるなら、これは、サービスの状態を調整することによって、表されます。 存在ドキュメントの消費者が先験的な知識表示をそうでなくしない場合(エージェントがしばしばするその存在に注意してください)、デバイスの州はサービスの状態に堪えることを持っていません。
Just like services, there is no enumeration of device types - PCs, PDAs, cell phones, etc. Rather, the device is defined by its characteristics, from which a watcher can extrapolate whether the device is a PDA, cell phone, or what have you.
まさしくサービスのように、装置タイプの列挙が全くありません--PC、PDA、携帯電話など むしろ、デバイスは特性によって定義されます。(ウォッチャーはデバイスがPDA、携帯電話またはなどであることにかかわらず特性から推定できます)。
It is important to point out that the device is a *model* of the underlying physical systems in which services execute. There is nothing that says that this model cannot be used to talk about systems where services run in virtualized systems, rather than real ones. For example, if a PC is executing a virtual machine and running services within that virtual machine, it is perfectly acceptable to use this model to talk about that PC as being composed of two separate devices.
サービスが実行するものでデバイスが基本的な物理的なシステムの*モデル*であると指摘するのは重要です。 何もシステムに関して話すのにこのモデルを使用できないと言うことがサービスが本当のものよりむしろvirtualizedシステムに立候補するところにありません。 例えば、PCが仮想計算機を実行して、その仮想計算機の中でサービスを実行しているなら、2台の別々のデバイスで構成されるとしてそのPCに関して話すのにこのモデルを使用するのは完全に許容できます。
3.5. Modeling Ambiguity
3.5. モデルのあいまいさ
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.
あいまいさは存在システムの現実のものです、そして、それはこの仕様で明らかにモデル化されます。 複数の人の情報、特定のデバイス、または特定のサービスがあるとき、あいまいさは存在しています。 複数の要素が人、特定のサービス、または特定のデバイスの情報を発表するとき、このあいまいさは自然に起こります。 いくつかの場合、植字工は、ただ一つの一貫性を持っている記述に自動化された方法であいまいさを取り除いて、人、デバイス、またはサービスに関してデータを結合できます。
Rosenberg Standards Track [Page 17] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[17ページ]。
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.
あいまいさをモデル化するために、モデルは各サービス、各デバイス、または人のコンポーネントに複数の発生を含ませます。 各発生には、発生識別子と呼ばれるユニークな識別子があります。 どんなサービス、デバイス、または人にとっても、この識別子は他のすべての発生識別子の向こう側にユニークです。 すなわち、ユニークさはサービス、デバイス、および人の要素のすべて中で特定のpresentityに関して見られます。 識別子は、構成と承認方針を設定するための貴重なハンドルとして機能するので、時間がたつにつれて、理想的に持続します。 特定のデバイス、サービス、または人にとって、ただ一つの発生があっても、発生には、発生識別子があります。
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.
発生識別子はIDがSIP Outbound仕様[27]に基づき定義したインスタンスに混乱しないことです。 サービス、および本当にGlobally Routable Userのエージェントのユリ(GRUU)の[22](インスタンスIDから得られる)がサービス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.
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.
Rosenberg Standards Track [Page 18] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 18] RFC 4479 Presence Data Model July 2006
3.6. The Meaning of Nothing
3.6. The Meaning of Nothing
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.
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.
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.
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.
3.7. Status vs. Characteristics
3.7. Status vs. Characteristics
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.
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.
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.
Rosenberg Standards Track [Page 19] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 19] RFC 4479 Presence Data Model July 2006
3.8. Presence Document Properties
3.8. Presence Document Properties
The overall presence document has several important properties that are essential to this model.
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.
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.
A corollary of this property is that presence systems are infinitely composeable. A presence user agent can publish a document to its presence server. That presence server can compose it with other documents, and place the result in a notification to a watcher. That watcher can actually be another presence agent, combining that document with others it has received, and placing those results in yet another notify.
Yet another corollary of this property is that implied behaviors in reaction to the document cannot ever be assumed. For example, just because a service indicates that it supports audio does not mean that a watcher will offer audio in a communications attempt to that service. If doing so is necessary to reach the service, this must be indicated explicitly through reach information.
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.
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.
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
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
Rosenberg Standards Track [Page 20] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 20] RFC 4479 Presence Data Model July 2006
Protocol (VoIP) address, and so on, the presentity URI can be provided, and all of the others can be learned from there.
Protocol (VoIP) address, and so on, the presentity URI can be provided, and all of the others can be learned from there.
4. Motivation for the Model
4. Motivation for the Model
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.
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.
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 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.
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.
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.
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,
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,
Rosenberg Standards Track [Page 21] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 21] RFC 4479 Presence Data Model July 2006
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.
it is possible and meaningful for location information to be conveyed for both device and person, and for these locations to be different. The fact that the presence system might try to determine the location of the person by extrapolation from the location of one of the devices is irrelevant from a data modeling perspective. Person location and device location are not the same thing.
[25] defines the <geopriv> XML element for conveying location information, and indicates that it is carried as a child of the <tuple> element in a PIDF document. [25] was developed prior to this specification, and unfortunately, its recommendation to include location objects underneath <tuple> runs contrary to the recommendations here. As such, implementations based on this specification SHOULD include <geopriv> location objects as part of person and/or device components of the document, but SHOULD be prepared to receive presence documents with that object as a child to <tuple>. A <geopriv> location object would be included in a person component when the document means to convey the location of the user, and within a device component when it means to convey the location of the device.
[25] 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.
5. Encoding
5. Encoding
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.
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.
The <presence> element contains the presence information for the presentity. The "entity" attribute of this element contains the presentity URI.
The <presence> element contains the presence information for the presentity. The "entity" attribute of this element contains the presentity 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.
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.
Rosenberg Standards Track [Page 22] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 22] RFC 4479 Presence Data Model July 2006
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
Rosenberg Standards Track [Page 23] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 23] RFC 4479 Presence Data Model July 2006
It's important to note that the mapping of the presence data model into a PIDF document is merely an exercise in syntax.
It's important to note that the mapping of the presence data model into a PIDF document is merely an exercise in syntax.
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.
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.
5.1. XML Schemas
5.1. XML Schemas
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.
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.
5.1.1. Common Schema
5.1.1. Common Schema
<?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" 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>
Rosenberg Standards Track [Page 24] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 24] RFC 4479 Presence Data Model July 2006
</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 name="fromUntil"> <xs:attribute name="from" type="xs:dateTime"/> <xs:attribute name="until" type="xs:dateTime"/> </xs:attributeGroup> <xs:complexType name="empty"/> </xs:schema>
5.1.2. Data Model
5.1.2. Data Model
<?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" 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>
Rosenberg Standards Track [Page 25] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 25] RFC 4479 Presence Data Model July 2006
<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: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>
6. Extending the Presence Model
6. Extending the Presence Model
When new presence attributes are added, any such extension has to consider the following questions:
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. 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.
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. 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.
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. 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.
7. Example Presence Document
7. Example Presence Document
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].
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].
Rosenberg Standards Track [Page 26] RFC 4479 Presence Data Model July 2006
Rosenberg Standards Track [Page 26] RFC 4479 Presence Data Model July 2006
7.1. Basic IM Client
7.1. Basic IM Client
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.
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.
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.
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.
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個のデータ構成要素があるシステムの各presentityを表すことによって、モデル化されます: 人のコンポーネント、サービスコンポーネント、およびデバイスの部品。 人のコンポーネントは注意と事前に定義されたステータスメッセージを含むユーザの状態について説明します。 これらが人間のユーザの情報を表すので、それらは人のコンポーネントに含まれています。 サービスtupleはIMサービスを表します。 どんな特性も含まれていません。 クライアントによって発行されたサービスURIはクライアントのRecord(AOR)のAddressに設定されます。 デバイスの部品は、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>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ存在..等しい..つぼ..つぼ..データ..モデル..つぼ..上限..等しい..つぼ..上限..イド..状態..基本的..開く..基本的..状態..上限
Rosenberg Standards Track [Page 27] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[27ページ]。
<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>
<上限: 拡大><上限: サポートしている><上限: pref/></上限: サポートしている></上限: 拡大><上限: メソッド><上限: サポートしている><上限: メッセージ/><上限: オプション/></上限: サポートしている></上限: メソッド></上限: servcaps><接触>一口: someone@example com</接触></tuple><dm: 人のイドが等しい、「p1"><rp: 活動><rp: 電話の/></rp: 活動></dm: 人の><dm: デバイスイドが等しい、「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
より安易な場合では、デバイス状態の一部として無駄なインディケータを報告するのは、そのインディケータが他のサービスに同じデバイスで使用されるのを許容します。 VoIPアプリケーションが少しのデバイス情報も報告しないで、またIMサービスの情報がウォッチャーに提供されないなら再び同じデバイスでVoIPアプリケーションに関する例を取って、ウォッチャーに送られた存在ドキュメントはデバイス状態を含むことができます。 用法
Rosenberg Standards Track [Page 28] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[28ページ]。
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.
デバイスIDとデバイス情報、存在サーバはVoIPサービスでIMアプリケーションで報告されるようにデバイス状態を関連させて、それらを一緒に使用できます。
8. Security Considerations
8. セキュリティ問題
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].
ここで定義されたモデルによって説明された存在情報は非常に機密です。 それはプライバシーフィルタリングが存在データの処理で重要な役割を果たすこの理由であります。 プライバシーフィルタリングはウォッチャーが見るのに権限を与えられないという情報を取り除く目的のための存在ドキュメントに許容を適用する行為です。 より一般的な用語で、プライバシーフィルタリングは承認のフォームです。 また、プライバシーフィルタリングは、ウォッチャーがpresentityのための少しの存在データも見ることができないのを確実にすることができます、そして、本当に、それはpresentityが、それが妨げられているのを知らないのを確実にすることさえできます。 SIP存在仕様、(RFC3856[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などのように、存在データを輸送するのに使用されるプロトコルは、必要な保全機能を提供するのに使用されます。
9. Internationalization Considerations
9. 国際化問題
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へのそうすることができる拡大で定義されたこの要素と他ののは無料のテキストSHOULDを含んでいます。それらの言語とスクリプトを示す'xml: lang'属性で、ラベルされます。 この仕様は、presentityが複数のスクリプトと言語の注意を伝えることができるように、<注意>要素の複数の発生を許容します。 '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で代理をされるので、それはユニコード文字集合とUTF-8を含むそのよりコンパクトな表現を使用することで符号化情報のネイティブのサポートを提供します。 Conformant XMLプロセッサはUTF-8とUTF-16の両方を認識します。 XMLは<--xml-->宣言における「コード化」属性の使用で他の文字符号化を特定して、使用するために条項を含んでいますが、UTF-8の使用は含んでいます。
Rosenberg Standards Track [Page 29] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[29ページ]。
RECOMMENDED in environments where parser encoding support incompatibility exists.
サポートの不一致をコード化するパーサが存在する環境におけるRECOMMENDED。
10. IANA Considerations
10. IANA問題
There are several IANA considerations associated with this specification.
この仕様に関連しているいくつかのIANA問題があります。
10.1. URN Sub-Namespace Registration
10.1. つぼのサブ名前空間登録
This section registers a new XML namespace, per the guidelines in [4]
このセクションは中に1ガイドラインあたり1つの新しいXML名前空間を登録します。[4]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:data-model.
URI: この名前空間のためのURIはつぼ: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 )。
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バージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「><html xmlnsが「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」内容=と等しい、「テキスト/html;、charset=iso8859、1インチ、/><タイトル>Aデータは存在データモデル</h1><h2>つぼのための存在</タイトル></ヘッド><ボディー><h1>名前空間のためにモデル化されます:、」; ietf:params:xml:ナノ秒:pidf: データモデル</h2><p>See<a hrefが等しい、「 http://www.rfc-editor.org/rfc/rfc4479.txt 「>RFC4479</a>。」; </p></ボディー></html>エンド
Rosenberg Standards Track [Page 30] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[30ページ]。
10.2. XML Schema Registrations
10.2. XML図式登録証明書
This section registers two XML schemas per the procedures in [4].
このセクションは[4]に1手順あたり2XML schemasを登録します。
10.2.1. Common Schema
10.2.1. 一般的な図式
URI: urn:ietf:params:xml:schema:pidf:common-schema.
URI: つぼ: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.
セクション5.1.1の唯一の内容としてこの図式のためのXMLを見つけることができます。
10.2.2. Data Model
10.2.2. データモデル
URI: urn:ietf:params:xml:schema:pidf:data-model.
URI: つぼ: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.
セクション5.1.2の唯一の内容としてこの図式のためのXMLを見つけることができます。
11. Acknowledgements
11. 承認
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ワーキンググループの多くの関係者によって寄付されました。 アキNiemi、ポールKyzivat、Cullenジョニングス、ベン・キャンベル、ロバート・スパークス、ディーン・ウィリス、アダム・ローチ、Hisham Khartabil、およびジョン・ピーターソンはここで説明される概念の多くを寄付しました。 例の存在ドキュメントは仕様、および列挙よりむしろ特性を通したサービスを定義することに関する考えがアダム・ローチのサービス特徴ドキュメントから来たロバート・スパークスの例の存在ドキュメントから来ました。 ここで議論した話題についての議論のためのスティーブ・ドノヴァンおかげと、彼のドキュメントの最終審査のためのElwynデイヴィースへの特別番組。
Rosenberg Standards Track [Page 31] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[31ページ]。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[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.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、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、「セッション開始プロトコル(一口)のための訪問者好み」、RFC3841、2004年8月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[4] 食事、M.、「IETF XML登録」、BCP81、RFC3688、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.、T.、およびE.Maler、「拡張マークアップ言語(XML)1.0(第3版)」をSperberg-マックィーン、C.はいななかせます、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部:」 「構造Second Edition」、W3C REC REC- xmlschema-1-20041028、2004年10月。
[7] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second
Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[7]Malhotra、A.、およびP.ビロン、「XML図式第2部:」 「データ型式第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.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
2000年2月の[10] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[12] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[12] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。
Rosenberg Standards Track [Page 32] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[32ページ]。
[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.)は「広げることができるメッセージングと存在プロトコル(XMPP)のために、リソース識別子(虹彩)とUniform Resource Identifier(URI)を国際的にしました」、処理中の作業、2005年12月。
[14] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message
Service", Work in Progress, February 2006.
[14] 「GSMの短いメッセージサービスのURI体系」というワイルド、E.、およびA.Vaha-Sipilaは進歩、2006年2月に働いています。
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[15]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
[16] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[16]Klyne、G.、「特徴が設定するメディアを説明するための構文」、RFC2533、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、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[18] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[18]FaltstromとP.とM.食事、「Uniform Resource Identifier(URI)ダイナミックな委譲発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", Work in Progress, March 2006.
[19] ローゼンバーグと、J.と、「セッション開始プロトコル(一口)とスパム」は進歩、2006年3月に働いています。
[20] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[20] リーチ、P.、食事、M.、およびR.ザルツ、「一般にユニークな識別子(UUID)つぼの名前空間」、RFC4122、2005年7月。
[21] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[21] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、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.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2005年10月)で働いています。
[23] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[23]Schulzrinne、H.、「RPID:」 「存在情報データの形式(PIDF)への豊かな存在拡大」、RFC4480、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] 「存在情報データの形式(PIDF)へのセッション開始プロトコル(一口)ユーザエージェント能力拡大」というLonnfors、M.、およびK.キスは進行中(2006年1月)で働いています。
[25] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[25] ピーターソン、J.、「存在ベースのGEOPRIV位置のオブジェクト形式」、RFC4119、2005年12月。
[26] Rosenberg, J., "Presence Authorization Rules", Work in
Progress, March 2006.
[26] ローゼンバーグ、J.、「存在承認規則」が進歩、2006年3月に働いています。
Rosenberg Standards Track [Page 33] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[33ページ]。
[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月)で働いています。
Author's Address
作者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Standards Track [Page 34] RFC 4479 Presence Data Model July 2006
ローゼンバーグStandardsは存在データモデル2006年7月にRFC4479を追跡します[34ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosenberg Standards Track [Page 35]
ローゼンバーグ標準化過程[35ページ]
一覧
スポンサーリンク
