[要約] RFC 4480は、PIDF（Presence Information Data Format）に富んだプレゼンス拡張機能（RPID）を提供するための仕様です。このRFCの目的は、プレゼンス情報の拡張と豊かな表現を可能にすることです。
Network Working Group H. Schulzrinne
Request for Comments: 4480 Columbia U.
Category: Standards Track V. Gurbani
Lucent
P. Kyzivat
J. Rosenberg
Cisco
July 2006
RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
RPID：リッチなプレゼンス情報データ形式（PIDF）への拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.
存在情報データ形式（PIDF）は、プレゼンテーションの存在情報を表現するための基本形式を定義します。この形式は、テキストノート、可用性（オープンまたはクローズ）の指標、および通信用の均一なリソース識別子（URI）を定義します。ここで説明するリッチプレゼンス情報データ形式（RPID）は、オプションの要素を存在情報データ形式（PIDF）に追加する拡張機能です。これらの拡張機能は、プレゼントとその連絡先に関する追加情報を提供します。情報は、その多くがカレンダーファイルやユーザーアクティビティから自動的に導出できるように設計されています。
This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.
この拡張機能には、その人が何をしているか、タプルのグループ識別子、サービスまたはデバイスが最後に使用されたとき、人が入っている場所、メディアコミュニケーションがプライベートなままである可能性があること、サービスタプルとの関係に関する情報が含まれます。別のプレゼンテーション、その人の気分、それが位置するタイムゾーン、提供するサービスの種類、プレゼントのステータスを反映したアイコン、およびプレゼンテーションの全体的な役割。
These extensions include presence information for persons, services (tuples), and devices.
これらの拡張には、人、サービス（タプル）、およびデバイスの存在情報が含まれます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology and Conventions .....................................4
3. RPID Elements ...................................................4
3.1. Overview ...................................................4
3.2. Activities Element .........................................7
3.3. Class Element .............................................10
3.4. Device Identifier .........................................10
3.5. Mood Element ..............................................10
3.6. Place-is Element ..........................................12
3.7. Place-type Element ........................................13
3.8. Privacy Element ...........................................14
3.9. Relationship Element ......................................15
3.10. Service Class ............................................15
3.11. Sphere Element ...........................................16
3.12. Status-Icon Element ......................................16
3.13. Time Offset ..............................................17
3.14. User-Input Element .......................................17
4. Example ........................................................18
5. XML Schema Definitions .........................................20
5.1. urn:ietf:params:xml:ns:pidf:rpid ..........................20
6. Extending RPID .................................................30
7. IANA Considerations ............................................31
7.1. URN Sub-Namespace Registration for ........................31
'urn:ietf:params:xml:ns:pidf:rpid'
7.2. Schema Registration for Schema ............................32
'urn:ietf:params:xml:ns:pidf:status:rpid'
8. Internationalization Considerations ............................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
Appendix A. Acknowledgements .....................................35
The Presence Information Data Format (PIDF) definition [8] describes a basic presence information data format, encoded as an Extensible Markup Language (XML) [9] (SCHEMA-1 [10]) (SCHEMA-2 [11]), for exchanging presence information in systems compliant with the common model for presence and instant messaging [5]. It consists of a <presence> root element, zero or more <tuple> elements carrying presence information including a Uniform Resource Identifier (URI) for communication, zero or more <note> elements, and zero or more extension elements from other name spaces. Each tuple defines a basic status of either "open" or "closed".
存在情報データ形式（PIDF）定義[8]は、拡張可能なマークアップ言語（xml）[9]（schema-1 [10]）（schema-2 [11]）としてエンコードされた基本的な存在情報データ形式を説明しています。存在感とインスタントメッセージングの共通モデルに準拠したシステムの存在情報を交換します[5]。これは、通信用の均一なリソース識別子（URI）、ゼロ以上<ノート>要素、および他の名前スペースからのゼロ以上の拡張要素を含む存在情報を運ぶ<pesconis>ルート要素、ゼロ以上<tuple>要素で構成されています。各タプルは、「オープン」または「閉じた」の基本ステータスを定義します。
However, it is frequently useful to convey additional information about a user that needs to be interpreted by an automata, and is therefore not appropriate to be placed in the <note> element of the PIDF document, which is typically intended for the human observer. Therefore, this specification defines extensions to the PIDF document format for conveying richer presence information. Generally, the extensions have been chosen to provide features common in existing presence systems at the time of writing, in addition to elements that could readily be derived automatically from existing sources of presence, such as calendaring systems or communication devices, or sources describing the user's current physical environment.
ただし、オートマトンで解釈する必要があるユーザーに関する追加情報を伝えることが頻繁に便利であるため、通常、人間の観測者向けのPIDFドキュメントの要素に配置するのは適切ではありません。したがって、この仕様では、より豊かな存在情報を伝えるためのPIDFドキュメント形式への拡張機能を定義します。一般に、拡張機能は、カレンダーシステムや通信デバイス、ユーザーを説明するソースなど、既存の存在ソースから容易に導き出すことができる要素に加えて、既存の存在システムで既存の存在システムで共通の機能を提供するために選択されています。現在の物理的環境。
The presence data model [16] defines the concepts of service, device, and person as the data elements that are used to model the state of a presentity. (The term "presentity" is defined in RFC 2778 [5] and abbreviates presence entity. A presentity provides presence information to a presence service.) Services are encoded using the <tuple> element, defined in PIDF; devices and persons are represented by the <device> and <person> XML elements, respectively, defined in the data model [16]. However, neither PIDF nor the data model defines presence attributes beyond the <basic> status element.
存在データモデル[16]は、サービス、デバイス、および人の概念を、プレゼンテーションの状態をモデル化するために使用されるデータ要素として定義します。（「プレゼンティ」という用語は、RFC 2778 [5]で定義され、存在感のあるエンティティを略します。デバイスと人は、それぞれデータモデル[16]で定義されている<device>および<serson> XML要素で表されます。ただし、PIDFもデータモデルも、<basic>ステータス要素を超えて存在属性を定義していません。
This specification defines additional presence attributes to describe person, service, and device data elements, summarized as "Rich Presence Information Data format for presence" (RPID). These attributes are specified by XML elements that extend the PIDF <tuple> element and the <device> and <person> elements defined in the data model.
この仕様は、「存在のリッチな存在情報データ形式」（RPID）として要約された、個人、サービス、およびデバイスのデータ要素を記述する追加の存在属性を定義します。これらの属性は、PIDF <Tuple>要素を拡張し、データモデルで定義されている<device>および<person>要素を拡張するXML要素によって指定されます。
This extension has two main goals:
この拡張機能には2つの主な目標があります。
1. Provide rich presence information that is at least as powerful as common commercial presence systems. Such feature-parity simplifies transition to systems complying with the Common Profile for Instant Messaging (CPIM) [14], both in terms of user acceptance and protocol conversion.
1. 少なくとも一般的な商業的存在システムと同じくらい強力な豊富な存在情報を提供します。このような特異性は、ユーザーの受け入れとプロトコル変換の両方の観点から、インスタントメッセージング（CPIM）[14]の共通プロファイルに準拠するシステムへの移行を簡素化します。
2. Maintain backward-compatibility with PIDF, so that PIDF-only watchers and gateways can continue to function properly, naturally without access to the functionality described here.
2. PIDFを使用して後方互換性を維持します。これにより、PIDFのみのウォッチャーとゲートウェイが、ここで説明する機能にアクセスすることなく、適切に機能し続けることができます。
We make no assumptions as to how the information in the RPID elements is generated. Experience has shown that users are not always diligent about updating their presence status. Thus, we want to make it as easy as possible to derive RPID information from other information sources, such as personal calendars, the status of communication devices such as telephones, typing activity, and physical presence detectors as commonly found in energy-management systems.
RPID要素の情報がどのように生成されるかについては、仮定しません。経験によると、ユーザーは存在状態を更新することに常に熱心ではないことが示されています。したがって、個人のカレンダー、電話の入力、アクティビティの入力、エネルギー管理システムで一般的に見られる物理的存在検出器など、他の情報源からRPID情報を導き出すことができるようにできるようにしたいと考えています。
Many of the elements correspond to data commonly found in personal calendars. Thus, we attempted to align some of the extensions with the usage found in calendar formats such as iCal [13].
要素の多くは、個人カレンダーで一般的に見つかったデータに対応しています。したがって、いくつかの拡張機能を、ial [13]などのカレンダー形式で見つかった使用法に合わせようとしました。
The information in a presence document can be generated by a single entity or can be composed from information published by multiple entities.
プレゼンスドキュメント内の情報は、単一のエンティティによって生成されるか、複数のエンティティによって公開された情報から作成できます。
Note that PIDF documents and this extension can be used in two different contexts, namely, by the presentity to publish its presence status and by the presence server to notify some set of watchers. The presence server MAY compose, translate, or filter the published presence state before delivering customized presence information to the watcher. For example, it may merge presence information from multiple presence user agents, remove whole elements, translate values in elements, or remove information from elements. Mechanisms that filter calls and other communications to the presentity can subscribe to this presence information just like a regular watcher and in turn generate automated rules, such as scripts [15], that govern the actual communications behavior of the presentity. Details are described in the data model document.
PIDFドキュメントとこの拡張機能は、2つの異なるコンテキスト、つまり、プレゼンスステータスを公開するための現在のコンテキストと、Watchersのセットに通知するためにプレゼンスサーバーによって使用できることに注意してください。プレゼンスサーバーは、カスタマイズされたプレゼンス情報をウォッチャーに配信する前に、公開されたプレゼンス状態を構成、翻訳、またはフィルタリングする場合があります。たとえば、複数の存在ユーザーエージェントからの存在情報をマージしたり、要素全体を削除したり、要素の値を翻訳したり、要素から情報を削除したりする場合があります。呼び出しやその他の通信をプレゼンテーションにフィルタリングするメカニズムは、通常のウォッチャーと同じようにこの存在情報を購読し、プレゼンテーションの実際の通信行動を支配するスクリプト[15]などの自動化されたルールを生成できます。詳細については、データモデルのドキュメントで説明しています。
Since RPID is a PIDF XML document, it also uses the content type application/pidf+xml.
RPIDはPIDF XMLドキュメントであるため、コンテンツタイプアプリケーション/PIDF XMLも使用します。
This memo makes use of the vocabulary defined in the IMPP model document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are used in the same meaning as defined therein.
このメモは、IMPPモデルドキュメント[5]で定義されている語彙を使用しています。メモの閉じた、インスタントメッセージ、オープン、プレゼンスサービス、プレゼンテーション、ウォッチャー、およびウォッチャーユーザーエージェントなどの用語は、そこに定義されているのと同じ意味で使用されます。
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
キーワードは、このドキュメントでは、BCP 14、RFC 2119 [1]に記載されているように解釈されるように解釈する必要があります。
Some of the RPID elements describe services, some devices, and some the person. As such, they either extend <tuple>, <device>, or <person>, respectively. Below, we summarize the RPID elements. The next sections will then provide more detailed descriptions.
RPID要素の一部は、サービス、一部のデバイス、および一部の要素について説明しています。そのため、それぞれ<tuple>、<device>、または<パーソン>を拡張します。以下に、RPID要素を要約します。次のセクションでは、より詳細な説明を提供します。
activities: The <activities> status element enumerates what the person is doing.
アクティビティ：<アクティビティ>ステータス要素は、その人がしていることを列挙します。
class: An identifier that groups similar person elements, devices, or services.
クラス：同様の人物、デバイス、またはサービスをグループ化する識別子。
deviceID: A device identifier in a tuple references a <device> element, indicating that this device contributes to the service described by the tuple.
DeviceID：タプル参照A <device>要素のデバイス識別子は、このデバイスがタプルによって記述されたサービスに寄与していることを示しています。
mood: The <mood> status element indicates the mood of the person.
気分：<Mood>ステータス要素は、人のムードを示します。
place-is: The <place-is> status element reports on the properties of the place the presentity is currently at, such as the levels of light and noise.
place-is：<place-is>ステータス要素は、光とノイズのレベルなど、現在の場所のプロパティについてレポートします。
place-type: The <place-type> status elements reports the type of place the person is located in, such as 'classroom' or 'home'.
Place-Type：<Place-Type>ステータス要素は、「教室」や「ホーム」など、その人がある場所のタイプを報告しています。
privacy: The <privacy> element distinguishes whether the communication service is likely to be observable by other parties.
プライバシー：<プライバシー>要素は、コミュニケーションサービスが他の関係者が観察できるかどうかを区別します。
relationship: When a service is likely to reach a user besides the person associated with the presentity, the relationship indicates how that user relates to the person.
関係：サービスが提示に関連する人に加えてユーザーに到達する可能性が高い場合、関係はそのユーザーがその人とどのように関係するかを示します。
service-class: The <service-class> element describes whether the service is delivered electronically, is a postal or delivery service, or describes in-person communications.
サービスクラス：<Service-Class>要素は、サービスが電子的に配信されるか、郵便または配達サービスであるか、または対面通信を説明しているかどうかを説明します。
sphere: The <sphere> element characterizes the overall current role of the presentity.
球体：<sphere>要素は、プレゼンテーションの全体的な現在の役割を特徴づけます。
status-icon: The <status-icon> element depicts the current status of the person or service.
Status-Icon：<Satution-Icon>要素は、個人またはサービスの現在のステータスを示しています。
time-offset: The <time-offset> status element quantifies the time zone the person is in, expressed as the number of minutes away from UTC.
タイムオフセット：<タイムオフセット>ステータス要素は、UTCから数分数として表される人がいるタイムゾーンを定量化します。
user-input: The <user-input> element records the user-input or usage state of the service or device, based on human user input.
ユーザー入力：<user-input>要素は、ユーザーユーザーの入力に基づいて、サービスまたはデバイスのユーザー入力または使用状況を記録します。
The 'From/until?' column in Table 1 indicates by an 'x' that the element can take 'from' and 'until' attributes. An 'x' in the 'Note?' column marks elements that can include a <note> element. The usage of these elements within the <person>, <tuple>, and <device> elements is shown in columns 4 through 6. An 'x' in the respective column indicates that the RPID element MAY appear as a child of that element.
「from/uto？」表1の列は、要素が「 'から「'から」と属性をとることができる「x」で示されています。「メモ？」の「x」列を含む要素をマークします<note>要素。<person>、<tuple>、および<device>要素内のこれらの要素の使用は、列4〜6に示されています。それぞれの列の「x」は、RPID要素がその要素の子として表示される可能性があることを示しています。
+-----------------+------------+------+----------+---------+----------+
| Element | From/until | Note | <person> | <tuple> | <device> |
| | ? | ? | | | |
+-----------------+------------+------+----------+---------+----------+
| <activities> | x | x | x | | |
| <class> | | | x | x | x |
| <deviceID> | | | | x | |
| <mood> | x | x | x | | |
| <place-is> | x | x | x | | |
| <place-type> | x | x | x | | |
| <privacy> | x | x | x | x | |
| <relationship> | | x | | x | |
| <service-class> | | x | | x | |
| <sphere> | x | | x | | |
| <status-icon> | x | | x | x | |
| <time-offset> | x | | x | | |
| <user-input> | | | x | x | x |
+-----------------+------------+------+----------+---------+----------+
Table 1
表1
In general, it is unlikely that a presentity will publish or announce all of these elements at the same time. Rather, these elements were chosen to give the presentity maximum flexibility in deriving this information from existing sources, such as calendaring tools, device activity sensors, or location trackers, as well as to manually configure this information. In either case, there is no guarantee that the information is accurate, as users forget to update calendars or may not always adjust the presence information manually.
一般に、プレゼンテーションがこれらすべての要素を同時に公開または発表する可能性は低いです。むしろ、これらの要素は、カレンダーツール、デバイスアクティビティセンサー、ロケーショントラッカーなどの既存のソースからこの情報を導出する際に、プレゼンテーションに最大限の柔軟性を与え、この情報を手動で構成するために選択されました。どちらの場合でも、ユーザーがカレンダーを更新するのを忘れたり、常に存在情報を手動で調整するとは限らないため、情報が正確であるという保証はありません。
The namespace URIs for these elements defined by this specification are URNs [2], using the namespace identifier 'ietf' defined by [4] and extended by [6]:
この仕様で定義されたこれらの要素の名前空間URIは、[4]で定義され、[6]で拡張された名前空間識別子「IETF」を使用して、URN [2]です。
urn:ietf:params:xml:ns:pidf:rpid
The elements marked with the value 'x' in column 2 of Table 1 MAY be qualified with the 'from' and 'until' attributes to describe the absolute time when the element assumed this value and the absolute time until which this element is expected to be valid. Note that there can be multiple elements of the same type, whose time ranges SHOULD NOT overlap.
表1の列2の値「x」とマークされた要素は、要素がこの値を想定した絶対時間と、この要素が予想されるまでの絶対時間を記述するための「From」および 'till'属性で適格になる場合があります有効です。同じタイプの複数の要素が存在する場合があり、その時間範囲は重複しないでください。
Elements MAY contain an 'id' attribute that allows to uniquely reference the element.
要素には、要素を一意に参照できる「ID」属性が含まれる場合があります。
Enumerations can be extended by elements from other namespaces, as described in Section 6. The <activities>, <mood>, and <place-type> elements can also take <other> elements containing text, for custom free-text values specific to an application.
列挙は、セクション6で説明されているように、他の名前空間からの要素によって拡張できます。アプリケーション。
All elements described in this document are optional within PIDF documents.
このドキュメントで説明されているすべての要素は、PIDFドキュメント内でオプションです。
The <activities> element describes what the person is currently doing, expressed as an enumeration of activity-describing elements. A person can be engaged in multiple activities at the same time, e.g., traveling and having a meal. The <activities> element can be quite helpful to the watcher in judging how appropriate a communication attempt is and which means of communications is most likely to succeed and not annoy the person. The activity indications correspond roughly to the category field in calendar entries, such as Section 4.8.1.2 of RFC 2445 [13].
<アクティビティ>要素は、その人が現在行っていることを説明し、アクティビティで記録する要素の列挙として表現されています。人は、たとえば旅行や食事をするなど、複数の活動に同時に従事することができます。<アクティビティ>要素は、コミュニケーションの試みがどれほど適切であるか、どのコミュニケーションの手段が成功する可能性が高く、人を困らせないかを判断する際に、ウォッチャーにとって非常に役立ちます。アクティビティの適応症は、RFC 2445のセクション4.8.1.2 [13]など、カレンダーエントリのカテゴリフィールドにほぼ対応しています。
An activities enumeration consists of one or more elements using elements drawn from the list below, a string enclosed in the <other> element, or IANA-registered values from other namespaces (Section 7).
アクティビティの列挙は、以下のリストから描かれた要素を使用した1つ以上の要素、<other>要素に囲まれた文字列、または他の名前空間から登録された値（セクション7）で構成されています。
If a person publishes an activity of "permanent-absence", it is likely that all services will report a status of CLOSED. In general, services MAY advertise either service status for any activity value.
人が「永続的な違反」の活動を公開する場合、すべてのサービスが閉じたステータスを報告する可能性があります。一般に、サービスは、アクティビティ値のいずれかのサービスステータスを宣伝する場合があります。
Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar information.
<protivents>、<mastauf>、<diner>、<holiday>、<holiday>、<lune>、<meal>、<meeting>、<performance>、<tarver>、<factore>などのアクティビティは、カレンダー情報から派生することがよくあります。。
appointment: The person has a calendar appointment, without specifying exactly of what type. This activity is indicated if more detailed information is not available or the person chooses not to reveal more information.
予約：その人は、どのタイプを正確に指定することなく、カレンダーの予約を持っています。このアクティビティは、より詳細な情報が利用できない場合、またはその人がより多くの情報を明らかにしないことを選択した場合に示されます。
away: The person is physically away from all interactive communication devices. This activity element was included since it can often be derived automatically from security systems, energy management systems, or entry badge systems. Although this activity would typically be associated with a status of CLOSED across all services, a person may declare himself or herself away to discourage communication, but indicate that he or she still can be reached if needed. However, communication attempts might reach an answering service, for example.
アウェイ：その人は、すべてのインタラクティブな通信デバイスから物理的に離れています。このアクティビティ要素は、多くの場合、セキュリティシステム、エネルギー管理システム、またはエントリーバッジシステムから自動的に導出できるため、含まれていました。このアクティビティは通常、すべてのサービスにわたって閉鎖のステータスに関連付けられていますが、人はコミュニケーションを阻止するために自分自身を離れて宣言することができますが、必要に応じてまだ到達できることを示します。ただし、たとえば、コミュニケーションの試みは留守番電話に到達する可能性があります。
breakfast: The person is eating the first meal of the day, usually eaten in the morning.
朝食：その人はその日の最初の食事を食べています。通常は朝に食べます。
busy: The person is busy, without further details. Although this activity would typically be associated with a status of CLOSED across all services, a person may declare himself or herself busy to discourage communication, but indicate that he or she still can be reached if needed.
忙しい：その人は忙しいですが、詳細はありません。このアクティビティは通常、すべてのサービスにわたって閉鎖のステータスに関連付けられていますが、人はコミュニケーションを思いとどまらせるために忙しいと宣言することができますが、必要に応じて自分がまだ到達できることを示します。
dinner: The person is having his or her main meal of the day, eaten in the evening or at midday.
夕食：その人はその日のメインの食事を食べており、夕方や正午に食べます。
holiday: This is a scheduled national or local holiday.
休日：これは予定されている全国または地元の休日です。
in-transit: The person is riding in a vehicle, such as a car, but not steering. The <place-type> element provides more specific information about the type of conveyance the person is using.
輸送中：その人は車などの車両に乗っていますが、ステアリングではありません。<place-type>要素は、その人が使用している搬送の種類に関するより具体的な情報を提供します。
looking-for-work: The presentity is looking for (paid) work.
見てみる：プレゼンテーションは（有料）仕事を探しています。
lunch: The person is eating his or her midday meal.
昼食：その人は昼食を食べています。
meal: The person is scheduled for a meal, without specifying whether it is breakfast, lunch, or dinner, or some other meal.
食事：その人は、朝食、昼食、夕食、または他の食事のいずれかを指定することなく、食事の予定です。
meeting: The person is in an assembly or gathering of people, as for a business, social, or religious purpose. A meeting is a sub-class of an appointment.
会議：その人は、ビジネス、社会、または宗教的な目的と同様に、人々の集会または集まりにいます。会議は、予約のサブクラスです。
on-the-phone: The person is talking on the telephone. This activity is included since it can often be derived automatically.
オンフフォン：その人は電話で話している。しばしば自動的に導出できるため、このアクティビティは含まれています。
other: The person is engaged in an activity with no defined representation as an <activities> element. The enclosed string describes the activity in plain text.
その他：その人は、<アクティビティ>要素として定義された表現のないアクティビティに従事しています。囲まれた文字列は、プレーンテキストのアクティビティを説明しています。
performance: A performance is a sub-class of an appointment and includes musical, theatrical, and cinematic performances as well as lectures. It is distinguished from a meeting by the fact that the person may either be lecturing or be in the audience, with a potentially large number of other people, making interruptions particularly noticeable.
パフォーマンス：パフォーマンスは予約のサブクラスであり、音楽、演劇、映画のパフォーマンス、講義が含まれます。人が講義をしているか、聴衆の中にいる可能性があるという事実と、他の多くの人がいる可能性があるという事実によって、会議とは区別され、中断を特に顕著にしています。
permanent-absence: The person will not return for the foreseeable future, e.g., because it is no longer working for the company. This activity is associated with a status of CLOSED across all services.
永続的な違反：その人は、たとえば、それが会社のために働いていないため、近い将来に戻りません。このアクティビティは、すべてのサービスにわたるクローズドのステータスに関連付けられています。
playing: The person is occupying himself or herself in amusement, sport, or other recreation.
演奏：その人は、娯楽、スポーツ、またはその他のレクリエーションで自分自身を占領しています。
presentation: The person is giving a presentation, lecture, or participating in a formal round-table discussion.
プレゼンテーション：その人は、正式な円卓会議にプレゼンテーション、講義、または参加しています。
shopping: The person is visiting stores in search of goods or services.
ショッピング：その人は、商品やサービスを求めて店を訪れています。
sleeping: This activity category can often be generated automatically from a calendar, local time information, or biometric data.
睡眠：このアクティビティカテゴリは、多くの場合、カレンダー、現地時間情報、または生体認証データから自動的に生成できます。
spectator: The person is observing an event, such as a sports event.
観客：その人は、スポーツイベントなどのイベントを観察しています。
steering: The person is controlling a vehicle, watercraft, or plane.
ステアリング：その人は車両、船舶、または飛行機を制御しています。
travel: The person is on a business or personal trip, but not necessarily in-transit.
旅行：その人はビジネスや個人的な旅行をしていますが、必ずしも輸送中ではありません。
tv: The person is watching television.
テレビ：その人はテレビを見ています。
unknown: The activity of the person is unknown. This element is generally not used together with other activities.
不明：人の活動は不明です。この要素は通常、他のアクティビティと一緒に使用されません。
vacation: A period of time devoted to pleasure, rest, or relaxation.
休暇：喜び、休息、またはリラクゼーションに専念する期間。
working: The presentity is engaged in, typically paid, labor, as part of a profession or job.
作業：職業や仕事の一部として、現在、現在は労働に従事しています。
worship: The presentity is participating in religious rites.
礼拝：プレゼントは宗教的な儀式に参加しています。
The <activities> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<アクティビティ>要素には、セクション3.1で説明されているように、「From」および「Till」属性が適格である場合があります。
Example:
例：
<activities>
<note>Enjoying the morning paper</note>
<vacation/>
<breakfast/>
<other>reading</other>
</activities>
The <class> element describes the class of the service, device, or person. Multiple elements can have the same class name within a presence document, but each person, service, or device can only have one class label. The naming of classes is left to the presentity. The presentity can use this information to group similar services, devices, or person elements or to convey information that the presence agent can use for filtering or authorization. This information is not generally presented to the watcher user interface.
<class>要素は、サービス、デバイス、または人のクラスについて説明します。複数の要素には、プレゼンスドキュメント内で同じクラス名を持つことができますが、各人、サービス、またはデバイスにはクラスラベルが1つしかありません。クラスの命名は現在の任務に任されています。プレゼンテーションは、この情報を使用して、同様のサービス、デバイス、または個人要素をグループ化したり、プレゼンスエージェントがフィルタリングまたは承認に使用できる情報を伝えることができます。この情報は、一般にWatcherユーザーインターフェイスに提示されていません。
The <class> element MUST NOT be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<class>要素は、セクション3.1で説明されているように、「from」および 'till'属性を認定してはなりません。
The <deviceID> element in the <tuple> element references the device that provides a particular service. The element is defined syntactically in the data model [16] schema. One service can be provided by multiple devices, so that each service tuple may contain zero or more <deviceID> elements. There is no significance in the order of these elements.
<tuple>要素の<deviceId>要素は、特定のサービスを提供するデバイスを参照しています。要素は、データモデル[16]スキーマで構文的に定義されています。1つのサービスを複数のデバイスで提供できるため、各サービスタプルにはゼロ以上の<devicid>要素が含まれる場合があります。これらの要素の順序に重要なものはありません。
The <deviceID> element MUST NOT be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<deviceId>要素は、セクション3.1で説明されているように、「from」および 'till'属性を認定してはなりません。
The <mood> element describes the mood of the presentity. The mood values are enumerated chosen by the presentity. The mood itself is provided as the element name of a defined child element of the <mood> element (e.g., <happy/>); one such child element is REQUIRED. The user MAY also specify a natural-language description of, or reason for, the mood in the <note> child of the <mood> element, which is OPTIONAL. (This definition follows the Jabber Extension JEP-107.) It is RECOMMENDED that an implementation support the mood values proposed in Jabber Extension JEP-0107, which in turn are a superset of the Wireless Village [18] mood values and the values enumerated in the Affective Knowledge Representation that has been defined by Lisetti [17]:
<Mood>要素は、プレゼンテーションのムードを説明しています。気分の値は、プレゼンテーションによって選択されます。ムード自体は、<Mood>要素の定義された子要素の要素名として提供されます（例：<Happy/>）;そのような子要素の1つが必要です。また、ユーザーは、オプションである<mood>要素の<thildのムードの自然な言語の説明、または理由を指定することもできます。（この定義はJabber Extension JEP-107に従います。）実装では、Jabber Extension JEP-0107で提案された気分価値をサポートすることをお勧めします。Lisetti [17]によって定義された感情的な知識表現：
A mood enumeration consists of one or more elements using elements drawn from the list below, a string enclosed in the <other> element, or IANA-registered values from other namespaces (Section 7).
気分列挙は、以下のリストから描かれた要素を使用した1つ以上の要素、<other>要素に囲まれた文字列、または他の名前空間からのIANA登録値（セクション7）で構成されています。
The <mood> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<Mood>要素は、セクション3.1で説明されているように、「From」と「Till」属性の資格があります。
o afraid o amazed o angry o annoyed o anxious o ashamed o bored o brave o calm o cold o confused o contented o cranky o curious o depressed o disappointed o disgusted o distracted o embarrassed o excited o flirtatious o frustrated o grumpy o guilty o happy o hot o humbled o humiliated o hungry o hurt o impressed o in_awe o in_love o indignant o interested o invincible o jealous o lonely o mean o moody o nervous o neutral o offended o other o playful o proud o relieved o remorseful o restless o sad o sarcastic o serious o shocked o shy o sick o sleepy o stressed o surprised o thirsty o unknown o worried
o 驚いたo怒っているo怒っているo不安o恥ずかしいobored o brave o calm o cold o cold o conptused o conpanted o cranky o cranky o culsious o contress o sectressed o恥ずかしいo恥ずかしいo恥ずかしいo恥ずかしさホットo謙虚に屈辱的なhungly o hungry o hurt o in_awe o in_awe o in_love o in dignant o tongible o tongiable o jeale o lonely o mean o mean o meody o mean o vertarl o stard o other o other playful o誇りに思う皮肉なo深刻なOショック
Example:
例：
<mood>
<note>I'm ready for the bar BOF!</note>
<sleepy/>
<thirsty/>
</mood>
The <place-is> element describes properties of the place the person is currently at. This offers the watcher an indication of what kind of communication is likely to be successful. Each major media type has its own set of attributes. Omitting the element indicates that the property is unknown.
<place-is>要素は、その人が現在いる場所の特性を説明しています。これにより、ウォッチャーはどのようなコミュニケーションが成功する可能性が高いかを示しています。各主要なメディアタイプには、独自の属性セットがあります。要素を省略すると、プロパティが不明であることがわかります。
For audio, we define the following attributes:
オーディオについては、次の属性を定義します。
noisy: The person is in a place with a level of background noise that makes audio communications difficult.
ノイジー：その人は、オーディオ通信を困難にするバックグラウンドノイズのレベルのある場所にいます。
ok: The environmental conditions are suitable for audio communications.
OK：環境条件は、オーディオ通信に適しています。
quiet: The person is in a place such as a library, restaurant, place of worship, or theater that discourages noise, conversation, and other distractions.
静か：人は、騒音、会話、その他の気晴らしを思いとどまらせる図書館、レストラン、礼拝、劇場などの場所にいます。
unknown: The place attributes for audio are unknown.
不明：オーディオの場所の属性は不明です。
For video, we define the following attributes:
ビデオについては、次の属性を定義します。
toobright: The person is in a bright place, sufficient for good rendering on video.
Toobright：その人は明るい場所にいて、ビデオでの優れたレンダリングに十分です。
ok: The environmental conditions are suitable for video.
OK：環境条件はビデオに適しています。
dark: The person is in a dark place, and thus the camera may not be able to capture a good image.
暗い：その人は暗い場所にいるので、カメラは良い画像をキャプチャできないかもしれません。
unknown: The place attributes for video are unknown.
不明：ビデオの場所の属性は不明です。
For text (real-time text and instant messaging), we define
テキスト（リアルタイムテキストとインスタントメッセージング）については、定義します
uncomfortable: Typing or other text entry is uncomfortable.
不快：タイピングやその他のテキストエントリは不快です。
inappropriate: Typing or other text entry is inappropriate, e.g., since the user is in a vehicle or house of worship.
不適切：タイピングまたはその他のテキストエントリは不適切です。たとえば、ユーザーは車両や礼拝所にいるためです。
ok: The environmental conditions are suitable for text-based communications.
OK：環境条件は、テキストベースの通信に適しています。
unknown: The place attributes for text are unknown.
不明：テキストの場所の属性は不明です。
This list can be augmented by free-text values in a note or additional IANA-registered values (Section 7).
このリストは、メモのフリーテキスト値または追加のIANA登録値（セクション7）で拡張できます。
The <place-is> element contains other elements, e.g.,
<place-is>要素には、他の要素が含まれています。
<place-is>
<audio>
<noisy />
</audio>
<video>
<dark />
</video>
</place-is>
The <place-is> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<place-is>要素は、セクション3.1で説明されているように、「from」および 'till'属性の対象となる場合があります。
The <place-type> element describes the type of place the person is currently at. This offers the watcher an indication of what kind of communication is likely to be appropriate. The initial set of values is contained in RFC 4589 [12].
<place-type>要素は、その人が現在いる場所のタイプを説明しています。これにより、ウォッチャーはどのようなコミュニケーションが適切であるかを示しています。値の初期セットは、RFC 4589 [12]に含まれています。
This list can be augmented by free-text values or additional IANA-registered values as described in RFC 4589.
このリストは、RFC 4589で説明されているように、フリーテキスト値または追加のIANA登録値によって拡張できます。
The <place-type> element is a choice of elements, as in
<place-type>要素は、のように要素の選択です
<place-type>
<pt:street/>
</place-type>
The <place-type> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<clace-type>要素は、セクション3.1で説明されているように、「from」および 'till'属性で適格である場合があります。
The <privacy> element indicates which types of communication third parties in the vicinity of the presentity are unlikely to be able to intercept accidentally or intentionally. This does not in any way describe the privacy properties of the electronic communication channel, e.g., properties of the encryption algorithm or the network protocol used.
<プライバシー>要素は、プレゼンティの近くにあるどのタイプのコミュニケーションサードパーティが偶然または意図的に傍受できるかを示します。これは、電子通信チャネルのプライバシープロパティ、たとえば、暗号化アルゴリズムや使用されるネットワークプロトコルのプロパティを決して説明しません。
audio: Inappropriate individuals are not likely to overhear audio communications.
オーディオ：不適切な個人は、オーディオ通信を耳にする可能性は低いです。
text: Inappropriate individuals are not likely to see text communications.
テキスト：不適切な個人は、テキスト通信を見る可能性は低いです。
unknown: This information is unknown.
不明：この情報は不明です。
video: Inappropriate individuals are not likely to see video communications.
ビデオ：不適切な個人は、ビデオ通信を見ることはないでしょう。
The <privacy> element can be used by logic executing on the watcher or by a composer to filter, sort and label tuples. For example, a composer may have rules that limit the publication of tuples labeled "private" to a select subset of the watchers.
<プライバシー>要素は、ウォッチャーで実行するロジックまたは作曲家がタプルをフィルタリング、ソート、ラベル付けすることで使用できます。たとえば、作曲家には、「プライベート」とラベル付けされたタプルの公開をウォッチャーの一部のサブセットに制限するルールがある場合があります。
The <privacy> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<プライバシー>要素は、セクション3.1で説明されているように、「From」および「 'till'属性が適格である場合があります。
Example:
例：
<privacy>
<text/>
<audio/>
</privacy>
The <relationship> element extends <tuple> and designates the type of relationship an alternate contact has with the presentity. This element is provided only if the tuple refers to somebody other than the presentity. Relationship values include "family", "friend", "associate" (e.g., for a colleague), "assistant", "supervisor", "self", and "unknown". The default is "self".
<lationssion>要素は<tuple>を拡張し、代替接触がプレゼンテーションと持つ関係のタイプを指定します。この要素は、タプルが現在以外の誰かを指す場合にのみ提供されます。関係の値には、「家族」、「友人」、「アソシエイト」（同僚の場合）、「アシスタント」、「スーパーバイザー」、「自己」、および「不明」が含まれます。デフォルトは「自己」です。
If a relationship is indicated, the URI in the <contact> element refers to the entity, such as the assistant, that has a relationship to the presentity, not the presentity itself.
関係が示されている場合、<contact>要素のURIは、プレゼント自体ではなく、現在との関係を持つアシスタントなどのエンティティを指します。
Like tuples without a <relationship> qualifier, the <contact> element for tuples labeled with a relationship can contain either a communication URI such as "im", "sip", "sips", "h323", "tel", or "mailto", or a presence URI, such as "pres" or "sip".
<lationssion>修飾子のないタプルのように、関係にラベルを付けるタプルの<contact>要素には、「im」、「sip」、「sips」、「h323」、「tel」、または「tel」などの通信URIを含めることができます。mailto "、または「pres」や「sip」などの存在感。
Example:
例：
<relationship>
<friend/>
</relationship>
The <service-class> element extends <tuple> and designates the type of service offered.
<service-class>要素は<tuple>を拡張し、提供されるサービスの種類を指定します。
electronic: Delivery of information by electronic means, i.e., without delivering physical objects. Examples include telephone, fax, email, instant messaging, and SMS.
電子：電子手段による情報の配信、つまり、物理的なオブジェクトを配信することなく。例には、電話、FAX、電子メール、インスタントメッセージング、SMSが含まれます。
postal: Delivery by the postal service, e.g., as a letter, parcel, or postcard. Delivery could be to a post office box or central mailroom rather than the presentity's office location, for example.
郵便：郵便サービスによる配達、例えば、手紙、小包、またははがきとして。たとえば、郵便局のオフィスの場所ではなく、郵便局の箱や中央のメールルームに配達することができます。
courier: Delivery by messenger, overnight delivery, or courier. Courier-delivered messages are usually delivered to a receptionist rather than, say, a mailroom or receiving department.
宅配便：メッセンジャーによる配達、一晩配達、または宅配便。宅配便のメッセージは、通常、メールルームや受信部門ではなく、受付係に配信されます。
freight: Delivery by freight carrier, typically of larger objects that are not sent by postal mail or courier. The recipient is often the shipping department or a loading dock.
貨物：貨物輸送業者による配達、通常、郵便郵便または宅配便で送られていない大きなオブジェクトの配達。受信者は、多くの場合、海運部門または積み込みドックです。
in-person: Describes the coordinates for visits in person, as by a visitor, i.e., usually somebody's office or residence.
対面：訪問者、つまり、通常は誰かのオフィスまたは居住地のように、直接訪問のための座標について説明します。
unknown: The type of service is unknown.
不明：サービスの種類は不明です。
Electronic service is implied if omitted. The service types 'postal', 'courier', 'freight', and 'in-person' MUST NOT be used unless the contact URI is empty. Additional data elements defined elsewhere describe the physical service delivery address for the in-person, postal, or delivery services. Such addresses might be specified in geospatial coordinates, civic addresses, or some specialized address format, e.g., for interstellar addresses or a company-specific delivery system.
省略した場合、電子サービスが暗示されます。「郵便」、「宅配便」、「貨物」、「貨物」、および「対面」のサービスタイプは、連絡先URIが空でない限り使用してはなりません。他の場所で定義されている追加のデータ要素は、対面、郵便、または配達サービスの物理的なサービス提供アドレスを説明しています。このような住所は、地理座標、市民住所、またはいくつかの専門的な住所形式、例えば、星間アドレスまたは企業固有の配送システムで指定される場合があります。
Example:
例：
<service-class><postal/></service-class>
The <sphere> element designates the current state and role that the person plays. For example, it might describe whether the person is in a work mode, at home, or participating in activities related to some other organization such as the IETF or a church. This document does not define names for these spheres except for two common ones, "work" and "home", as well as "unknown".
<sphere>要素は、その人が演じる現在の状態と役割を指定します。たとえば、その人がワークモード、自宅で、またはIETFや教会などの他の組織に関連する活動に参加しているかどうかを説明する場合があります。このドキュメントは、2つの一般的な球体「作業」と「ホーム」、および「不明」を除くこれらの球体の名前を定義しません。
Spheres allow the person to easily turn on or off certain rules that depend on what groups of people should be made aware of the person's status. For example, if the person is a Boy Scout leader, he might set the sphere to "scouting" and then have a rule set that allows other scout masters in his troop to see his presence status. As soon as he switches his status to "work", "home", or some other sphere, the fellow scouts would lose access.
球体により、人は、どのグループがその人の状態を認識すべきかに依存する特定のルールを簡単にオンまたはオフにすることができます。たとえば、その人がボーイスカウトのリーダーである場合、彼は領域を「スカウティング」に設定し、彼の部隊の他のスカウトマスターが彼の存在状態を見ることができるルールセットを持つことができます。彼が自分のステータスを「仕事」、「家」、または他の球体に切り替えるとすぐに、仲間のスカウトはアクセスを失います。
The <sphere> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<Sphere>要素は、セクション3.1で説明されているように、「From」および「Till」属性で適格である場合があります。
Example:
例：
<sphere>
<home/>
</sphere>
The <status-icon> element includes a URI pointing to an image (icon) representing the current status of the person or service. The watcher MAY use this information to represent the status in a graphical user interface. Presentities SHOULD provide images of sizes and aspect ratios that are appropriate for rendering as an icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED.
<Satution-Icon>要素には、個人またはサービスの現在のステータスを表す画像（アイコン）を指すURIが含まれています。ウォッチャーは、この情報を使用して、グラフィカルユーザーインターフェイス内のステータスを表すことができます。プレゼンテーションは、アイコンとしてレンダリングするのに適したサイズとアスペクト比の画像を提供する必要があります。JPEG、PNG、およびGIF形式のサポートをお勧めします。
Watchers resolving the URI MUST validate whether the local copy of the icon is current when receiving a notification, using the standard cache control mechanism in the URI-identified retrieval protocol.
URIを解決するウォッチャーは、URIが特定した検索プロトコルで標準のキャッシュ制御メカニズムを使用して、通知を受信するときにアイコンのローカルコピーが最新かどうかを検証する必要があります。
Example:
例：
<status-icon>http://www.example.com/playing.gif</status-icon>
The <time-offset> element describes the number of minutes of offset from UTC at the person's current location. A positive number indicates that the local time-of-day is ahead (i.e., east of) Universal Time, while a negative number indicates that the local time-of-day is behind (i.e., west of) Universal Time. Transitions into and out of daylight savings time may temporarily cause a difference between the true offset from UTC and the time offset element.
<time-offset>要素は、人の現在の場所でのUTCからのオフセットの分数数を記述します。正の数は、現地の時刻が先に（すなわち、東の）普遍的な時間であることを示していますが、負の数は、地元の時刻が普遍的な時間（すなわち西）が遅れていることを示しています。夏時間への移行と脱出時間は、UTCからの真のオフセットとタイムオフセット要素の間に一時的に差を引き起こす可能性があります。
An optional attribute, description, can be used to describe the offset, e.g., by labeling the time zone. This description is meant for human consumption.
オプションの属性、説明は、タイムゾーンのラベルを付けることにより、オフセットを記述するために使用できます。この説明は、人間の消費を対象としています。
Publishers on mobile devices SHOULD NOT publish this information unless they know the time offset information to reflect the current location. (For example, many laptop users do not update their time zone when traveling.) Publishers SHOULD update the information whenever they discover that their UTC offset has changed.
モバイルデバイスのパブリッシャーは、現在の場所を反映するためのタイムオフセット情報を知っていない限り、この情報を公開しないでください。（たとえば、多くのラップトップユーザーは、旅行中にタイムゾーンを更新しません。）パブリッシャーは、UTCオフセットが変更されたことを発見したときはいつでも情報を更新する必要があります。
Example:
例：
<time-offset description="America/New_York">-300
</time-offset>
The <user-input> element records the user-input or usage state of the service or device, based on human user input, e.g., keyboard, pointing device, or voice. If contained in a <person> element, it summarizes any user input activity across all services and devices operated by the presentity. The mechanism for such aggregation is beyond the scope of this document, but generally reflects the most recent user input across all devices and services. The element can assume one of two values, namely, 'active' or 'idle', with an optional 'last-input' attribute that records when the last user input was received. An optional 'idle-threshold' element records how long the presentity will wait before reporting the service or device to be idle, measured in seconds.
<user-input>要素は、人間のユーザー入力、キーボード、ポインティングデバイス、音声に基づいて、サービスまたはデバイスのユーザー入力または使用状況を記録します。<パーソン>要素に含まれる場合、プレゼンテーションによって動作するすべてのサービスとデバイスにわたってユーザー入力アクティビティを要約します。このような集約のメカニズムはこのドキュメントの範囲を超えていますが、一般にすべてのデバイスとサービスにわたる最新のユーザー入力を反映しています。要素は、最後のユーザー入力が受信されたときに記録するオプションの「最終入力」属性を使用して、「アクティブ」または「アイドル」という2つの値のいずれかを想定できます。オプションの「アイドル控除」要素は、数秒で測定されたサービスまたはデバイスをアイドル状態にする前に、プレゼンテーションがどれくらい待つかを記録します。
(A two-state model was chosen since it would otherwise be necessary to send repeated last-input updates during continuous activity.)
（継続的な活動中に繰り返し最新の更新を送信する必要があるため、2つの状態モデルが選択されました。）
A service that wants to indicate user input activity sends a <user-input> 'active' indication when the user has provided user input within a configurable interval of time, the idle-threshold. If the user ceases to provide input and the idle-threshold has elapsed, the tuple is marked with a <user-input> 'idle' indication instead, optionally including the time of last activity in the 'last-input' attribute. An example is below:
ユーザー入力アクティビティを示したいサービスは、ユーザーが設定可能な時間間隔であるアイドル科目内でユーザー入力を提供したときに<ユーザーインプット>「アクティブ」表示を送信します。ユーザーが入力を停止し、アイドル閾値が経過した場合、タプルには代わりに<ユーザーインプット>「アイドル」表示がマークされています。例を以下に示します。
<user-input idle-threshold="600"
last-input="2004-10-21T13:20:00.000-05:00">idle</user-input>
Depending on device or service capabilities, user input may be detected only for a particular application, i.e., when the application has user focus or when a user has sent a message or placed a call, or can be based on user input across all applications running on one end system.
デバイスまたはサービス機能に応じて、ユーザー入力は特定のアプリケーション、つまり、アプリケーションにユーザーフォーカスがある場合、またはユーザーがメッセージを送信したり、電話をかけたりする場合、または実行中のすべてのアプリケーションでユーザー入力に基づいて検出される場合があります。一端システム。
The <user-input> element may be used by a watcher, typically in combination with other data, to estimate how likely a user is to answer when contacting the service. A tuple that has not been used in a while may still be OPEN, but a watcher may choose to first contact a URI in a tuple that is both OPEN and has been used more recently.
<ユーザーインプット>要素は、通常、他のデータと組み合わせてウォッチャーが使用することができ、サービスに連絡するときにユーザーが答える可能性を推定できます。しばらく使用されていないタプルはまだ開いているかもしれませんが、ウォッチャーは、最初に開いていて最近使用されたタプルでURIに接触することを選択する場合があります。
The <user-input> attribute can be omitted if the presentity wants to indicate that the device has not been used for a while, but does not want to reveal the precise duration, as in the following:
<user-input>属性は、デバイスがしばらく使用されていないことを示したいが、以下のように正確な持続時間を明らかにしたくない場合は省略できます。
<user-input>idle</user-input>
Configuration MUST include the option to omit the 'last-input' attribute.
構成には、「最終入力」属性を省略するオプションを含める必要があります。
The example below describes the presentity 'pres:someone@example.com', which has a SIP contact, 'sip:someone@example.com', representing a service. It also has a device contact, as an email box. The presentity is in a meeting, in a public office setting. The 'until' information indicates that he will be there until 5:30 pm local time. The presentity also has an assistant, sip:secretary@example.com, who happens to be available for communications.
以下の例では、SIP連絡先がある「pres：soney@example.com」のプレゼンテーションについて説明しています。また、電子メールボックスとしてデバイスの連絡先もあります。プレゼンテーションは、公職の環境での会議にあります。「まで」情報は、彼が現地時間の午後5時30分までそこにいることを示しています。プレゼンティには、たまたまコミュニケーションに利用できるアシスタントsip：secretary@example.comもいます。
<?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:lt="urn:ietf:params:xml:ns:location-type"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
</status>
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
<rpid:relationship><rpid:self/></rpid:relationship>
<rpid:service-class><rpid:electronic/></rpid:service-class>
<contact priority="0.8">im:someone@mobile.example.net</contact>
<note xml:lang="en">Don't Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
<timestamp>2005-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="ty4658">
<status>
<basic>open</basic>
</status>
<rpid:relationship><rpid:assistant/></rpid:relationship>
<contact priority="1.0">mailto:secretary@example.com</contact>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID>
<rpid:class>email</rpid:class>
<rpid:service-class><rpid:electronic/></rpid:service-class>
<rpid:status-icon>http://example.com/mail.png</rpid:status-icon>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
<note>I'll be in Tokyo next week</note>
<dm:device id="pc147">
<rpid:user-input idle-threshold="600"
last-input="2004-10-21T13:20:00-05:00">idle</rpid:user-input>
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
<dm:note>PC</dm:note>
</dm:device>
<dm:person id="p1">
<rpid:activities from="2005-05-30T12:00:00+05:00"
until="2005-05-30T17:00:00+05:00">
<rpid:note>Far away</rpid:note>
<rpid:away/>
</rpid:activities>
<rpid:class>calendar</rpid:class>
<rpid:mood>
<rpid:angry/>
<rpid:other>brooding</rpid:other>
</rpid:mood>
<rpid:place-is>
<rpid:audio>
<rpid:noisy/>
</rpid:audio>
</rpid:place-is>
<rpid:place-type><lt:residence/></rpid:place-type>
<rpid:privacy><rpid:unknown/></rpid:privacy>
<rpid:sphere>bowling league</rpid:sphere>
<rpid:status-icon>http://example.com/play.gif</rpid:status-icon>
<rpid:time-offset>-240</rpid:time-offset>
<dm:note>Scoring 120</dm:note>
<dm:timestamp>2005-05-30T16:09:44+05:00</dm:timestamp>
</dm:person>
</presence>
The RPID schema is shown below. Due to limitations in composing schemas, not all XML documents that validate against the schema below are semantically valid RPID documents. In particular, the schema allows each element to appear anyhere in PIDF or data-model elements; Table 1 restricts where these elements can appear for semantically valid RPID documents. Elements that do not have from/until parameters MUST NOT appear more than once in each <person>, <tuple>, or <device>.
RPIDスキーマを以下に示します。構成スキーマの制限により、以下のスキーマに対して検証するすべてのXMLドキュメントが意味的に有効なRPIDドキュメントではありません。特に、スキーマを使用すると、各要素がPIDFまたはデータモデル要素にどこからでも表示されます。表1は、これらの要素が意味的に有効なRPIDドキュメントに表示される場所を制限します。<super>、<tuple>、または<device>に1回以上表示されてはなりません。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:rpid"
xmlns="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="activeIdle">
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="idle"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="activities">
<xs:annotation>
<xs:documentation>
Describes what the person is currently doing, expressed as
an enumeration of activity-describing elements. A person
can be engaged in multiple activities at the same time,
e.g., traveling and having a meal.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="unknown" type="empty" minOccurs="0"/>
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="appointment"
type="empty" />
<xs:element name="away"
type="empty" />
<xs:element name="breakfast"
type="empty" />
<xs:element name="busy"
type="empty" />
<xs:element name="dinner"
type="empty" />
<xs:element name="holiday"
type="empty" />
<xs:element name="in-transit"
type="empty" />
<xs:element name="looking-for-work"
type="empty" />
<xs:element name="meal"
type="empty" />
<xs:element name="meeting"
type="empty" />
<xs:element name="on-the-phone"
type="empty" />
<xs:element name="performance"
type="empty" />
<xs:element name="permanent-absence"
type="empty" />
<xs:element name="playing"
type="empty" />
<xs:element name="presentation"
type="empty" />
<xs:element name="shopping"
type="empty" />
<xs:element name="sleeping"
type="empty" />
<xs:element name="spectator"
type="empty" />
<xs:element name="steering"
type="empty" />
<xs:element name="travel"
type="empty" />
<xs:element name="tv"
type="empty" />
<xs:element name="vacation"
type="empty" />
<xs:element name="working"
type="empty" />
<xs:element name="worship"
type="empty" />
<xs:element name="other"
type="Note_t" />
<xs:any namespace="##other"
maxOccurs="unbounded" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="class" type="xs:token">
<xs:annotation>
<xs:documentation>
Describes the class of the service, device or person.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="mood">
<xs:annotation>
<xs:documentation>
Describes the mood of the presentity.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="unknown" type="empty"/>
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="afraid"
type="empty"/>
<xs:element name="amazed"
type="empty"/>
<xs:element name="angry"
type="empty"/>
<xs:element name="annoyed"
type="empty"/>
<xs:element name="anxious"
type="empty" />
<xs:element name="ashamed"
type="empty" />
<xs:element name="bored"
type="empty" />
<xs:element name="brave"
type="empty" />
<xs:element name="calm"
type="empty" />
<xs:element name="cold"
type="empty" />
<xs:element name="confused"
type="empty" />
<xs:element name="contented"
type="empty" />
<xs:element name="cranky"
type="empty" />
<xs:element name="curious"
type="empty" />
<xs:element name="depressed"
type="empty" />
<xs:element name="disappointed"
type="empty" />
<xs:element name="disgusted"
type="empty" />
<xs:element name="distracted"
type="empty" />
<xs:element name="embarrassed"
type="empty" />
<xs:element name="excited"
type="empty" />
<xs:element name="flirtatious"
type="empty" />
<xs:element name="frustrated"
type="empty" />
<xs:element name="grumpy"
type="empty" />
<xs:element name="guilty"
type="empty" />
<xs:element name="happy"
type="empty" />
<xs:element name="hot"
type="empty" />
<xs:element name="humbled"
type="empty" />
<xs:element name="humiliated"
type="empty" />
<xs:element name="hungry"
type="empty" />
<xs:element name="hurt"
type="empty" />
<xs:element name="impressed"
type="empty" />
<xs:element name="in_awe"
type="empty" />
<xs:element name="in_love"
type="empty" />
<xs:element name="indignant"
type="empty" />
<xs:element name="interested"
type="empty" />
<xs:element name="invincible"
type="empty" />
<xs:element name="jealous"
type="empty" />
<xs:element name="lonely"
type="empty" />
<xs:element name="mean"
type="empty" />
<xs:element name="moody"
type="empty" />
<xs:element name="nervous"
type="empty" />
<xs:element name="neutral"
type="empty" />
<xs:element name="offended"
type="empty" />
<xs:element name="playful"
type="empty" />
<xs:element name="proud"
type="empty" />
<xs:element name="relieved"
type="empty" />
<xs:element name="remorseful"
type="empty" />
<xs:element name="restless"
type="empty" />
<xs:element name="sad"
type="empty" />
<xs:element name="sarcastic"
type="empty" />
<xs:element name="serious"
type="empty" />
<xs:element name="shocked"
type="empty" />
<xs:element name="shy"
type="empty" />
<xs:element name="sick"
type="empty" />
<xs:element name="sleepy"
type="empty" />
<xs:element name="stressed"
type="empty" />
<xs:element name="surprised"
type="empty" />
<xs:element name="thirsty"
type="empty" />
<xs:element name="worried"
type="empty" />
<xs:element name="other"
type="Note_t" />
<xs:any namespace="##other"
maxOccurs="unbounded" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="place-is">
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="audio" minOccurs="0">
<xs:complexType>
<xs:choice>
<xs:element name="noisy" type="empty" />
<xs:element name="ok" type="empty" />
<xs:element name="quiet" type="empty" />
<xs:element name="unknown" type="empty" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="video" minOccurs="0">
<xs:complexType>
<xs:choice>
<xs:element name="toobright" type="empty" />
<xs:element name="ok" type="empty" />
<xs:element name="dark" type="empty" />
<xs:element name="unknown" type="empty" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="text" minOccurs="0">
<xs:complexType>
<xs:choice>
<xs:element name="uncomfortable" type="empty" />
<xs:element name="inappropriate" type="empty" />
<xs:element name="ok" type="empty" />
<xs:element name="unknown" type="empty" />
</xs:choice>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="place-type">
<xs:annotation>
<xs:documentation>
Describes the type of place the person is currently at.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="other" type="Note_t"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="privacy">
<xs:annotation>
<xs:documentation>
Indicates which type of communication third parties in the
vicinity of the presentity are unlikely to be able to
intercept accidentally or intentionally.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="unknown" type="empty"/>
<xs:sequence minOccurs="1">
<xs:element name="audio" type="empty" minOccurs="0"/>
<xs:element name="text" type="empty" minOccurs="0"/>
<xs:element name="video" type="empty" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="relationship">
<xs:annotation>
<xs:documentation>
Designates the type of relationship an alternate contact
has with the presentity.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="assistant" type="empty" />
<xs:element name="associate" type="empty" />
<xs:element name="family" type="empty" />
<xs:element name="friend" type="empty" />
<xs:element name="other" type="Note_t" minOccurs="0" />
<xs:element name="self" type="empty" />
<xs:element name="supervisor" type="empty" />
<xs:element name="unknown" type="empty" />
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="service-class">
<xs:annotation>
<xs:documentation>
Designates the type of service offered.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="courier" type="empty" />
<xs:element name="electronic" type="empty" />
<xs:element name="freight" type="empty" />
<xs:element name="in-person" type="empty" />
<xs:element name="postal" type="empty" />
<xs:element name="unknown" type="empty" />
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="sphere">
<xs:annotation>
<xs:documentation>
Designates the current state and role that the person plays.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:choice minOccurs="0">
<xs:element name="home" type="empty" />
<xs:element name="work" type="empty" />
<xs:element name="unknown" type="empty" />
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>
</xs:choice>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="status-icon">
<xs:annotation>
<xs:documentation>
A URI pointing to an image (icon) representing the current
status of the person or service.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="time-offset">
<xs:annotation>
<xs:documentation>
Describes the number of minutes of offset from UTC at the
user's current location.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="description"
type="xs:string"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="user-input">
<xs:annotation>
<xs:documentation>
Records the user-input or usage state of the service or
device.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="activeIdle">
<xs:attribute name="idle-threshold"
type="xs:positiveInteger"/>
<xs:attribute name="last-input" type="xs:dateTime"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any"
processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
Any developer can introduce their own element names, avoiding conflict by choosing an appropriate namespace URI. To add new standardized elements to the enumerations <activities>, <mood>, <privacy>, <relationship> and <service-class>, the extension process described in PIDF [9] is followed, i.e., such extensions would use namespace designators such as urn:ietf:params:xml:ns:pidf:ext, where 'ext' is the name of the extension. Any new values for the <place-type> element are assigned according to [12] and are given a namespace designator at their time of registration.
開発者は、適切な名前空間URIを選択することで競合を避けて、独自の要素名を導入できます。列挙に新しい標準化された要素を追加する<アクティビティ>、<mood>、<mood>、<lationsse>、<service-class>には、PIDF [9]で説明されている拡張プロセスが続きます。urnなど：ietf：params：xml：ns：pidf：ext、 "ext 'は拡張機能の名前です。<place-type>要素の新しい値は[12]に従って割り当てられ、登録時に名前空間指定子が与えられます。
To avoid the unnecessary proliferation of XML namespaces containing a single element, groups of element registrations for each of these enumerations, such as <privacy>, SHOULD be bundled into a single namespace rather than assigning a new namespace to each new element.
単一の要素を含むXMLネームスペースの不必要な増殖を回避するには、<プライバシー>などのこれらの各列挙の要素登録のグループを、新しい名前空間を各新しい要素に割り当てるのではなく、単一の名前空間にバンドルする必要があります。
7.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid'
URI: urn:ietf:params:xml:ns:pidf:rpid
Description: This is the XML namespace for XML elements defined by
RFC 4480 to describe rich presence information extensions for the
status element in the PIDF presence document format in the
application/pidf+xml content type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu
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>RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)</title>
</head>
<body>
<h1>Namespace for rich presence extension</h1>
<h2>urn:ietf:params:xml:ns:pidf:rpid</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4480.txt">
RFC&4480;</a>.</p>
</body>
</html>
END
7.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:status:rpid'
URI: urn:ietf:params:xml:ns:pidf:status:rpid
Registrant Contact: IESG
XML: See Section 5
Note that this document does not need a new content type. It inherits the content type from [8], namely, application/pidf+xml.
このドキュメントでは、新しいコンテンツタイプは必要ないことに注意してください。[8]、つまりアプリケーション/PIDF XMLからコンテンツタイプを継承します。
RPID 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.
RPIDには、人間が直接ではなく、プログラムによる消費を目的とした主にトークンが含まれています。プログラムは、ウォッチャーの好みに応じて、これらのトークンを言語に適したテキスト文字列に変換することが期待されています。
Some elements may contain <note> and <other> elements that can contain free text. These elements SHOULD be labeled with the 'xml: lang' attribute to indicate their language and script. The specification allows multiple occurrences of these elements so that the presentity can convey <note> and <other> elements in multiple scripts and languages. If no 'xml:lang' attribute is provided, the default value is "i-default" [3].
一部の要素には、無料のテキストを含む<other <other>要素が含まれている場合があります。これらの要素には、「XML：Lang」属性にラベルを付けて、言語とスクリプトを示します。この仕様により、これらの要素の複数の発生が可能になり、複数のスクリプトと言語で<lote>および<other>要素を伝えることができます。'xml：lang'属性が提供されていない場合、デフォルト値は「i-default」です[3]。
Since RPID is represented in XML, it provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.
RPIDはXMLで表されるため、Unicode文字セットとUTF-8を含むよりコンパクトな表現を使用して、情報をエンコードするためのネイティブサポートを提供します。コンフォーマントXMLプロセッサは、UTF-8とUTF-16の両方を認識します。XMLには、<？xml？>宣言で「エンコード」属性を使用して他の文字エンコーディングを特定して使用するための規定が含まれていますが、UTF-8の使用は、サポートの互換性が存在するパーサーエンコードが存在する環境で推奨されます。
A description of time-zone considerations can be found in Section 3.13.
時間帯の考慮事項の説明は、セクション3.13に記載されています。
The security considerations in [8] apply, as well as [7]. Compared to PIDF, this presence document format reveals additional information about presentities that can be highly sensitive. Beyond traditional security measures to protect confidentiality and integrity, systems should offer a means to selectively reveal information to particular watchers and to inspect the information that is being published, particularly if it is generated automatically from other sources, such as calendars or sensors.
[8]のセキュリティ上の考慮事項は、[7]と同様に適用されます。PIDFと比較して、このプレゼンスドキュメント形式は、非常に敏感なプレゼンテーションに関する追加情報を明らかにしています。機密性と整合性を保護するための従来のセキュリティ対策を超えて、システムは特定のウォッチャーに情報を選択的に公開し、公開されている情報を検査する手段を提供し、特にカレンダーやセンサーなどの他のソースから自動的に生成される場合。
Like any reference to an external object, the <status-icon> may allow the presentity to induce the watcher to retrieve data from a third party (content indirection attack), thus either retrieving harmful content or adding to the server load of the referenced resource.
外部オブジェクトへの参照と同様に、<Satution-Icon>は、プレゼンティがウォッチャーにサードパーティ（コンテンツの間接攻撃）からデータを取得するように誘導することを可能にすることができます。。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[4] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[5] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[6] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[8] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[9] 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.
[9] Yergeau、F.、Paoli、J.、Sperberg-Mcqueen、C.、Bray、T.、およびE. Maler、「拡張マークアップ言語（XML）1.0（第3版）」、W3C Rec Rec-XML-20040204、2月2004年。
[10] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004.
[10] Maloney、M.、Beech、D.、Thompson、H。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C Rec Rec-XMLSchema-1-20041028、2004年10月。
[11] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[11] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、W3C Rec Rec-XMLSchema-20041028、2004年10月。
[12] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
[12] Schulzrinne、H。and H. Tschofenig、「Location Types Registry」、RFC 4589、2006年7月。
[13] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[13] Dawson、F。and D. Stenerson、「インターネットカレンダーとスケジューリングコアオブジェクト仕様（ICALENDAR）」、RFC 2445、1998年11月。
[14] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[14] ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、2004年8月。
[15] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[15] Lennox、J.、Wu、X。、およびH. Schulzrinne、「Call Processing Language（CPL）：インターネットテレフォニーサービスのユーザー制御のための言語」、RFC 3880、2004年10月。
[16] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[16] Rosenberg、J。、「存在のためのデータモデル」、RFC 4479、2006年7月。
[17] Lisetti, C., "Personality, Affect, and Emotion Taxonomy for Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002.
[17] Lisetti、C。、「社会的に知的なエージェントの性格、影響、感情の分類法」、Proceedings of Flairs 2002、2002。
[18] Open Mobile Alliance, "The Wireless Village Initiative: Presence Attributes 1.1", Recommendation WV-29, 2004.
[18] Open Mobile Alliance、「The Wireless Village Initiative：Presence属性1.1」、推奨WV-29、2004。
The document reflects the discussion on the SIMPLE mailing list, with contributions from many individuals. David L. Black, Miguel Garcia, Avshalom Houri, Markus Isomaki, Rick Jones, Hisham Khartabil, Jonathan Lennox, Eva-Maria Leppanen, Mikko Lonnfors, Rohan Mahy, Miguel Marcia, Andrew Newton, Aki Niemi, Jon Peterson, and Brian Rosen provided detailed comments and suggestions. Xiaotao Wu assisted with schema testing. Jari Urpalainen provided valuable advice on XML schema issues.
このドキュメントは、多くの個人からの貢献により、簡単なメーリングリストの議論を反映しています。デビッド・L・ブラック、ミゲル・ガルシア、アヴシャロム・ホイ、マルクス・イソマキ、リック・ジョーンズ、ヒシャム・ハルタビル、ジョナサン・レノックス、エヴァ・マリア・レパネン、ミッコ・ロンフォース、ロハン・マヒー、ミゲル・マルシア、アンドリュー・ニュートン、アキ・ニーミー、ジョン・ピーターソン、ブリャン・ルーザーは詳細なコメントと提案。Xiaotao Wuはスキーマテストを支援しました。Jari Urpalainenは、XMLスキーマの問題に関する貴重なアドバイスを提供しました。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7042
EMail: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.edu
Vijay Gurbani Lucent 2000 Naperville Rd. Room 6G-440 Naperville, IL 60566-7033 US
Vijay Gurbani Lucent 2000 Naperville Rd。ルーム6G-440ネーパービル、イリノイ州60566-7033 US
EMail: vkg@lucent.com
Paul Kyzivat Cisco Systems BXB500 C2-2 1414 Massachusetts Avenue Boxborough, MA 01719 US
Paul Kyzivat Cisco Systems BXB500 C2-2 1414 MASSACHUSETTS AVENUE BOXBOROUGH、MA 01719 US
EMail: pkyzivat@cisco.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054-2711 US
EMail: jdrosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。