RFC4480 日本語訳
4480 RPID: Rich Presence Extensions to the Presence Information DataFormat (PIDF). H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg. July 2006. (Format: TXT=74026 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 4480 Columbia U.
Category: Standards Track V. Gurbani
Lucent
P. Kyzivat
J. Rosenberg
Cisco
July 2006
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4480年のコロンビアU.カテゴリ: P.Kyzivat J.ローゼンバーグコクチマス2006年7月に透明な標準化過程V.Gurbani
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
Presence情報Data Format(PIDF)は、presentityのための存在情報を表すために基本形式を定義します。 この形式はコミュニケーションのために原文の注意、有用性(開いているか閉じている)のしるし、およびUniform Resource Identifier(URI)を定義します。 ここで説明されたリッシュPresence情報Data形式(RPID)はPresence情報Data Format(PIDF)に随意的な要素を加える拡大です。 これらの拡大はpresentityとその接触に関する追加情報を提供します。 情報は、自動的と、例えば、カレンダーファイルかユーザ活動からそれのそれだけを引き出すことができるように設計されています。
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.
この拡大は個人的に人がしていること、サービスかデバイスが最後に利用されたときの人がいる場所、メディアコミュニケーションが残るかもしれないことに関するタイプのtupleへの組分け識別子の情報を含んでいます、別のpresentityへのサービスtupleの関係、人のムード、それが位置している時間帯、それが提供するサービスのタイプ、アイコンがpresentityの状態、およびpresentityの総合的な役割を反映して。
These extensions include presence information for persons, services (tuples), and devices.
これらの拡大は人々への存在情報、サービス(tuples)、およびデバイスを含んでいます。
Schulzrinne, et al. Standards Track [Page 1] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[1ページ]。
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
1. 序論…2 2. 用語とコンベンション…4 3. RPID Elements…4 3.1. 概要…4 3.2. 活動要素…7 3.3. クラス要素…10 3.4. デバイス識別子…10 3.5. ムード要素…10 3.6. 場所存在、要素…12 3.7. 要素を場所でタイプしてください…13 3.8. プライバシー要素…14 3.9. 関係要素…15 3.10. クラスにサービスを提供してください…15 3.11. 球の要素…16 3.12. 状態アイコン要素…16 3.13. 時間は相殺されました…17 3.14. ユーザ入力要素…17 4. 例…18 5. XML図式定義…20 5.1つぼ:ietf:params:xml:ナノ秒:pidf:rpid…20 6. RPIDを広げています…30 7. IANA問題…31 7.1. つぼのサブ名前空間登録、…31 'つぼ:ietf:params:xml:ナノ秒:pidf:rpid'7.2。 図式のための図式登録…32 'つぼ:ietf:params:xml:ナノ秒:pidf:状態: rpid'8。 国際化問題…32 9. セキュリティ問題…32 10. 参照…33 10.1. 標準の参照…33 10.2. 有益な参照…34 付録A.承認…35
1. Introduction
1. 序論
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".
Presence情報Data Format(PIDF)定義[8]が拡張マークアップ言語(XML)[9]としてコード化された基本的な存在情報データの形式について説明する、(SCHEMA-1[10])、(存在とインスタントメッセージング[5]における、一般的なモデルに伴う対応することのシステムの存在情報を交換するためのSCHEMA-2[11])。 それが<存在>根の要素、ゼロから成るか、または他からのコミュニケーションかゼロか、より多くの<注意>要素と、ゼロか、より多くの拡大要素のためにUniform Resource Identifier(URI)を含む存在情報を運ぶより多くの<tuple>要素が空間を命名します。 各tupleは「開く」か「閉じられること」の基本的な状態を定義します。
Schulzrinne, et al. Standards Track [Page 2] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[2ページ]。
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ドキュメント・フォーマットと拡大を定義します。 一般に、拡大はこれを書いている時点で既存の存在システムで一般的な特徴を提供するために選ばれました、存在の既存の源から容易に自動的に得ることができた要素に加えて、システム、通信装置、またはユーザの現在の物理的環境について説明するソースをcalendaringするのなどように。
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]はpresentityの状態をモデル化するのに使用されるデータ要素とサービス、デバイス、および人の概念を定義します。 ("presentity"という用語は、RFC2778[5]で定義されて、存在実体を簡略化します。 presentityは存在情報を存在サービスに提供します。) サービスはPIDFで定義された<tuple>要素を使用することでコード化されます。 デバイスと人々は<デバイス>とデータモデル[16]でそれぞれ定義された<人の>XML要素によって代理をされます。 しかしながら、PIDFもデータモデルも<の基本的な>状態要素を超えて存在属性を定義しません。
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.
サービス、およびデバイスデータ要素は、「存在に、豊かなPresence情報Data形式」(RPID)としてこの仕様が人について説明するために追加存在属性を定義するのをまとめました。 これらの属性はPIDF<tuple>要素と<デバイス>について敷衍する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. 一般的であるのと少なくとも同じくらい強力な豊かな存在情報に市販の存在システムを提供してください。そのような特徴同等はInstant Messaging(CPIM)[14]のためにCommon Profileに従うシステムへの変遷を簡素化します、ユーザ承認とプロトコル変換で。
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
RPID要素の情報がどう発生しているかに関して私たちは仮定を全くしません。 経験は、ユーザが彼らの存在状態をアップデートすることに関していつも勤勉であるというわけではないことを示しました。 そしてしたがって、他の情報源からRPID情報を得るのをできるだけ簡単にしたいと思います、個人的なカレンダーなどのように、電話などの通信装置の状態、活動をタイプして。
Schulzrinne, et al. Standards Track [Page 3] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[3ページ]。
physical presence detectors as commonly found in energy-management systems.
現実の所在探知器はエネルギー管理でシステムを同じくらい一般的に設立します。
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].
要素の多くが個人的なカレンダーで一般的に見つけられたデータに対応しています。 したがって、私たちは、iCal[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.
すなわち、存在状態を発行するpresentity、および存在サーバで2つの異なった文脈でPIDFドキュメントとこの拡張子を使用できることに注意して、何らかのセットのウォッチャーに通知してください。 カスタム設計された存在情報をウォッチャーに提供する前に、存在サーバは、発行された存在状態を構成するか、翻訳するか、またはフィルターにかけるかもしれません。 例えば、それは、要素から複数の存在ユーザエージェントから存在情報を合併するか、全体の要素を取り除くか、要素の値を翻訳するか、または情報を取り除くかもしれません。 呼び出しと他のコミュニケーションをpresentityにフィルターにかけるメカニズムは、まさしくレギュラーのウォッチャーのようにこの存在情報に加入して、順番にpresentityの実際のコミュニケーション動きを治めるスクリプト[15]などの自動化された規則を生成することができます。 詳細はデータモデルドキュメントで説明されます。
Since RPID is a PIDF XML document, it also uses the content type application/pidf+xml.
RPIDがPIDF XMLドキュメントであるので、また、それはcontent typeアプリケーション/pidf+xmlを使用します。
2. Terminology and Conventions
2. 用語とコンベンション
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]で定義されたボキャブラリーを利用します。 メモによるCLOSEDや、INSTANT MESSAGEや、オープンや、PRESENCE SERVICEや、PRESENTITYや、WATCHERや、WATCHER USER AGENTなどの用語はそこに定義されるのと同じ意味で使用されます。
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].
キーワードが解釈しなければならない、BCP14(RFC2119[1])で説明されるように本書ではNOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりません。
3. RPID Elements
3. RPID Elements
3.1. Overview
3.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>、<デバイス>、または<人の>を広げます。 以下に、私たちはRPID要素をまとめます。 そして、次のセクションは、より詳細な記述を提供するでしょう。
Schulzrinne, et al. Standards Track [Page 4] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[4ページ]。
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: このデバイスがtupleによって説明されたサービスに寄付するtuple参照で<デバイス>要素であって、示しているデバイス識別子。
mood: The <mood> status element indicates the mood of the person.
ムード: <ムード>状態要素は人のムードを示します。
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.
場所存在、: <が場所であります。>状態要素は現在、presentityがいる場所の所有地に関して報告します、光のレベルや雑音のように。
place-type: The <place-type> status elements reports the type of
place the person is located in, such as 'classroom' or 'home'.
場所タイプ: -タイプ>状態要素が人が位置している場所のタイプを報告する'教室'か'ホーム'などの<場所。
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.
関係: サービスがpresentityに関連している人以外にユーザに届きそうなとき、関係はそのユーザがどう人に関連するかを示します。
service-class: The <service-class> element describes whether the
service is delivered electronically, is a postal or delivery
service, or describes in-person communications.
サービスクラス: サービスが電子的に提供されるか、郵便か配送サービスである、または自分でコミュニケーションについて説明することにかかわらず>要素が説明する<サービスクラス。
sphere: The <sphere> element characterizes the overall current role
of the presentity.
球: <球の>要素はpresentityの総合的な現在の役割を特徴付けます。
status-icon: The <status-icon> element depicts the current status of
the person or service.
状態アイコン: <状態、-アイコン>要素は現在の人の、または、サービスの状態について表現します。
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.
ユーザ入力: <ユーザによって入力された>要素は人間のユーザ入力に基づいてサービスかデバイスのユーザ入力か用法状態を記録します。
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
'中の'コラムまでの/から、Table1は'xを示し'要素が取ることができる'from'と'until'属性。 '注意?'コラムの'x'は<注意>要素を含むことができる要素をマークします。 <人の>、<tuple>、および<デバイス>要素の中のこれらの要素の使用法はコラム4〜6で示されます。 それぞれの'x'
Schulzrinne, et al. Standards Track [Page 5] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[5ページ]。
column indicates that the RPID element MAY appear as a child of that element.
コラムは、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 | +-----------------+------------+------+----------+---------+----------+
+-----------------+------------+------+----------+---------+----------+ | 要素| /| 注意| <人の>。| <tuple>。| <デバイス>。| | | ? | ? | | | | +-----------------+------------+------+----------+---------+----------+ | <活動>。| x| x| x| | | | <のクラス>。| | | x| x| x| | <deviceID>。| | | | x| | | <ムード>。| x| x| x| | | | <が場所である、>。| x| x| x| | | | <場所タイプ>。| x| x| x| | | | <プライバシー>。| x| x| x| x| | | <関係>。| | x| | x| | | <サービスクラス>。| | x| | x| | | <球の>。| x| | x| | | | <状態アイコン>。| x| | x| x| | | <時間オフセット>。| x| | x| | | | <ユーザ入力>。| | | 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.
一般に、presentityが同時にこれらの要素のすべてを発行するか、または発表するのが、ありそうもないです。 むしろ、これらの要素はpresentity最大の柔軟性を与えるために既存のソースからこの情報を得る際に選ばれました、また、ツール、デバイス活動センサ、または位置の追跡者を手動でこの情報を構成するほどcalendaringするのなどように。 どちらの場合には、情報が正確であるという保証が全くありません、ユーザがカレンダーをアップデートするのを忘れるというわけではありませんし、またいつも手動で存在情報を調整するというわけではないとき。
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はURNs[2]です、[4]によって定義されて、[6]によって広げられた名前空間識別子'ietf'を使用して:
urn:ietf:params:xml:ns:pidf:rpid
つぼ:ietf:params:xml:ナノ秒: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.
要素は、Table1に関するコラム2の'x'が説明する'from'と'until'属性で資格があるかもしれない値で要素がこの値を仮定した絶対時間とこの要素が期待される絶対時間が有効であるとマークしました。 SHOULD NOTが時間範囲を重ね合わせる同じタイプの複数の要素があることができることに注意してください。
Elements MAY contain an 'id' attribute that allows to uniquely reference the element.
Elementsは唯一参照に要素を許容する'イド'属性を含むかもしれません。
Schulzrinne, et al. Standards Track [Page 6] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[6ページ]。
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ドキュメントの中に任意です。
3.2. Activities Element
3.2. 活動要素
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].
活動について説明する要素の列挙として言い表されて、<活動>要素は人が現在していることについて説明します。 人は、同時にの複数の活動、例えば、旅行に従事していて、食事できます。 ウォッチャーにとって、成功して、人をいらいらさせないようにコミュニケーション試みがどれくらい適切であるか、そして、コミュニケーションの手段がどれであるかをたぶん判断する際に<活動>要素はかなり役立っている場合があります。 活動指摘はおよそカレンダーエントリーにおけるカテゴリ分野に対応している、セクション4.8.1としてのそのようなものは.2RFC2445[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).
活動列挙は他の名前空間(セクション7)からストリングが他の>要素の<に以下では、同封したリストから得られた要素、またはIANAによって登録された値を使用する1つ以上の要素から成ります。
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.
人が「永久的な不在」の活動を発行すると、すべてのサービスがCLOSEDの状態を報告しそうでしょう。 一般に、サービスはどんな活動値のためにもサービス状態の広告を出すかもしれません。
Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar information.
予定表から<アポイントメント>、<朝食>、<夕食>、<休日>、<昼食>、<食事>、<ミーティング>、<性能>、<旅行>、または<休暇>などの活動をしばしば得ることができます。
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
遠くへ: 人はすべての対話的な通信装置から肉体的に遠くにいます。 この活動要素は、セキュリティシステム、エネルギー制御システム、またはエントリーバッジシステムからそれをしばしば自動的に得ることができるので、入れられました。この活動はすべてのサービスの向こう側のCLOSEDの状態に通常関連しているでしょうが、自分か自分が遠くにいると人は、申告するかもしれません。
Schulzrinne, et al. Standards Track [Page 7] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[7ページ]。
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.
朝食: 人は通常、朝食べられた1日の最初の食事を食べています。
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.
忙しくします: 人は詳細なしで忙しいです。 この活動はすべてのサービスの向こう側のCLOSEDの状態に通常関連しているでしょうが、自分か自分がコミュニケーションに水をさしているために忙しいと人は、宣言するかもしれませんが、必要であるならまだその人に連絡できるのを示してください。
dinner: The person is having his or her main meal of the day, eaten
in the evening or at midday.
夕食: 人はその人の晩か正午に食べられた1日の夕食を食べています。
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.
トランジット: 人は、車などの車で乗りますが、操縦していません。 タイプ>を置いている<要素は人が使用している運送のタイプの、より特定の情報を提供します。
looking-for-work: The presentity is looking for (paid) work.
仕事を見ます: presentityは仕事を探しています(支払います)。
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.
性能: 性能は、アポイントメントのサブクラスであり、講演と同様に音楽の、そして、演劇公演の、そして、映画のような性能を含んでいます。 人が講義であるか聴衆にいるかもしれないという事実によってそれはミーティングと区別されます、潜在的に多くの他の人々と共に、中断を特にめぼしくして。
Schulzrinne, et al. Standards Track [Page 8] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[8ページ]。
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.
永久的な不在: 人は、例えば、もう会社で働いていないので、予見できる未来に戻らないでしょう。 この活動はすべてのサービスの向こう側のCLOSEDの状態に関連しています。
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.
tv: 人はテレビを見ています。
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.
働いています: presentityは職業か仕事の一部として従事していて、通常支払われた作業です。
worship: The presentity is participating in religious rites.
崇拝: presentityは宗教上の儀式に参加しています。
The <activities> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
<活動>要素はセクション3.1で説明されるように'from'と'until'属性で適切であるかもしれません。
Example:
例:
<activities>
<note>Enjoying the morning paper</note>
<vacation/>
<breakfast/>
<other>reading</other>
</activities>
<活動><注意>Enjoyingは朝刊</注意><休暇/><朝食/><他の>読書</他の></活動>です。
Schulzrinne, et al. Standards Track [Page 9] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[9ページ]。
3.3. Class Element
3.3. クラス要素
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.
<クラス>要素はサービス、デバイス、または人のクラスについて説明します。 複数の要素が存在ドキュメントの中に同じクラス名を持つことができますが、各人、サービス、またはデバイスが1個のクラスラベルしか持つことができません。 クラスの命名はpresentityに残されます。 presentityは、同様のサービス、デバイス、または人の要素を分類するか、または存在エージェントがフィルタリングか承認に使用できる情報を伝えるのにこの情報を使用できます。 一般に、この情報はウォッチャーユーザーインタフェースに提示されません。
The <class> element MUST NOT be qualified with the 'from' and 'until' attributes as described in Section 3.1.
セクション3.1で説明されるように'from'と'until'属性で<クラス>要素に資格があってはいけません。
3.4. Device Identifier
3.4. デバイス識別子
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]図式でシンタクス上定義されます。 複数のデバイスは、それぞれのサービスtupleがゼロか、より多くの<deviceID>要素を含むことができるように、1つのサービスを提供できます。 これらの要素の注文には意味が全くありません。
The <deviceID> element MUST NOT be qualified with the 'from' and 'until' attributes as described in Section 3.1.
セクション3.1で説明されるように'from'と'until'属性で<deviceID>要素に資格があってはいけません。
3.5. Mood Element
3.5. ムード要素
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]:
<ムード>要素はpresentityのムードについて説明します。 presentityによって選ばれて、ムード値は列挙されます。 <ムード>要素(例えば、<の幸福な/>)の定義された子供要素の要素名としてムード自体を提供します。 そのような要素の子供1つはREQUIREDです。 また、ユーザは、ムードのために<ムード>要素の<注意>子供で自然言語記述を指定するか、または推論するかもしれません。(要素はOPTIONALです)。 (この定義はJabber Extension JEP-107に続きます。) ムードが評価する実装サポートが順番に値と値がLisetti[17]によって定義されたAffective Knowledge Representationで列挙したWireless Village[18]ムードのスーパーセットであるJabber Extension JEP-0107で提案したのは、RECOMMENDEDです:
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).
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).
The <mood> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
The <mood> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
Schulzrinne, et al. Standards Track [Page 10] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 10] RFC 4480 RIPD July 2006
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 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
Schulzrinne, et al. Standards Track [Page 11] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 11] RFC 4480 RIPD July 2006
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 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
Example:
Example:
<mood>
<note>I'm ready for the bar BOF!</note>
<sleepy/>
<thirsty/>
</mood>
<mood> <note>I'm ready for the bar BOF!</note> <sleepy/> <thirsty/> </mood>
3.6. Place-is Element
3.6. Place-is Element
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.
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.
For audio, we define the following attributes:
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.
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: The environmental conditions are suitable for audio communications.
quiet: The person is in a place such as a library, restaurant, place
of worship, or theater that discourages noise, conversation, and
other distractions.
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.
unknown: The place attributes for audio are unknown.
For video, we define the following attributes:
For video, we define the following attributes:
toobright: The person is in a bright place, sufficient for good
rendering on video.
toobright: The person is in a bright place, sufficient for good rendering on video.
Schulzrinne, et al. Standards Track [Page 12] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 12] RFC 4480 RIPD July 2006
ok: The environmental conditions are suitable for video.
ok: The environmental conditions are suitable for video.
dark: The person is in a dark place, and thus the camera may not be
able to capture a good image.
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.
unknown: The place attributes for video are unknown.
For text (real-time text and instant messaging), we define
For text (real-time text and instant messaging), we define
uncomfortable: Typing or other text entry is uncomfortable.
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.
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: The environmental conditions are suitable for text-based communications.
unknown: The place attributes for text are unknown.
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).
This list can be augmented by free-text values in a note or additional IANA-registered values (Section 7).
The <place-is> element contains other elements, e.g.,
The <place-is> element contains other elements, e.g.,
<place-is>
<audio>
<noisy />
</audio>
<video>
<dark />
</video>
</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.
The <place-is> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
3.7. Place-type Element
3.7. Place-type Element
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].
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].
This list can be augmented by free-text values or additional IANA- registered values as described in RFC 4589.
This list can be augmented by free-text values or additional IANA- registered values as described in RFC 4589.
Schulzrinne, et al. Standards Track [Page 13] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 13] RFC 4480 RIPD July 2006
The <place-type> element is a choice of elements, as in
The <place-type> element is a choice of elements, as in
<place-type>
<pt:street/>
</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.
The <place-type> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
3.8. Privacy Element
3.8. Privacy Element
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.
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.
audio: Inappropriate individuals are not likely to overhear audio communications.
text: Inappropriate individuals are not likely to see text
communications.
text: Inappropriate individuals are not likely to see text communications.
unknown: This information is unknown.
unknown: This information is unknown.
video: Inappropriate individuals are not likely to see video
communications.
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 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.
The <privacy> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
Example:
Example:
<privacy>
<text/>
<audio/>
</privacy>
<privacy> <text/> <audio/> </privacy>
Schulzrinne, et al. Standards Track [Page 14] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 14] RFC 4480 RIPD July 2006
3.9. Relationship Element
3.9. Relationship Element
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".
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".
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.
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.
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".
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".
Example:
Example:
<relationship>
<friend/>
</relationship>
<relationship> <friend/> </relationship>
3.10. Service Class
3.10. Service Class
The <service-class> element extends <tuple> and designates the type of service offered.
The <service-class> element extends <tuple> and designates the type of service offered.
electronic: Delivery of information by electronic means, i.e.,
without delivering physical objects. Examples include telephone,
fax, email, instant messaging, and SMS.
electronic: Delivery of information by electronic means, i.e., without delivering physical objects. Examples include telephone, fax, email, instant messaging, and 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.
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.
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.
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.
in-person: Describes the coordinates for visits in person, as by a visitor, i.e., usually somebody's office or residence.
Schulzrinne, et al. Standards Track [Page 15] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 15] RFC 4480 RIPD July 2006
unknown: The type of service is unknown.
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.
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.
Example:
Example:
<service-class><postal/></service-class>
<service-class><postal/></service-class>
3.11. Sphere Element
3.11. Sphere Element
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".
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".
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.
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.
The <sphere> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
Example:
Example:
<sphere>
<home/>
</sphere>
<sphere> <home/> </sphere>
3.12. Status-Icon Element
3.12. Status-Icon Element
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
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
Schulzrinne, et al. Standards Track [Page 16] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 16] RFC 4480 RIPD July 2006
sizes and aspect ratios that are appropriate for rendering as an icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED.
sizes and aspect ratios that are appropriate for rendering as an icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED.
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.
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.
Example:
Example:
<status-icon>http://www.example.com/playing.gif</status-icon>
<status-icon>http://www.example.com/playing.gif</status-icon>
3.13. Time Offset
3.13. Time Offset
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.
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.
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.
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.
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.
Example:
Example:
<time-offset description="America/New_York">-300
</time-offset>
<time-offset description="America/New_York">-300 </time-offset>
3.14. User-Input Element
3.14. User-Input Element
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
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
Schulzrinne, et al. Standards Track [Page 17] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 17] RFC 4480 RIPD July 2006
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.
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.
(A two-state model was chosen since it would otherwise be necessary to send repeated last-input updates during continuous activity.)
(A two-state model was chosen since it would otherwise be necessary to send repeated last-input updates during continuous activity.)
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:
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>
<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.
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.
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.
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:
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>idle</user-input>
<user-input>idle</user-input>
Configuration MUST include the option to omit the 'last-input' attribute.
Configuration MUST include the option to omit the 'last-input' attribute.
4. Example
4. Example
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
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
Schulzrinne, et al. Standards Track [Page 18] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 18] RFC 4480 RIPD July 2006
assistant, sip:secretary@example.com, who happens to be available for communications.
assistant, sip:secretary@example.com, who happens to be available for communications.
<?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">
<?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="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="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>
<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>
<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: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>
Schulzrinne, et al. Standards Track [Page 19] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 19] RFC 4480 RIPD July 2006
<dm:note>PC</dm:note>
</dm:device>
<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>
<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>
<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>
5. XML Schema Definitions
5. XML Schema Definitions
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>.
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>.
5.1. urn:ietf:params:xml:ns:pidf:rpid
5.1. urn:ietf:params:xml:ns:pidf:rpid
<?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"
<?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"
Schulzrinne, et al. Standards Track [Page 20] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 20] RFC 4480 RIPD July 2006
elementFormDefault="qualified"
attributeFormDefault="unqualified">
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: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: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: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" />
Schulzrinne, et al. Standards Track [Page 21] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 21] RFC 4480 RIPD July 2006
<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="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 name="class" type="xs:token"> <xs:annotation> <xs:documentation> Describes the class of the service, device or person. </xs:documentation> </xs:annotation>
Schulzrinne, et al. Standards Track [Page 22] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 22] RFC 4480 RIPD July 2006
</xs:element>
</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="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" />
Schulzrinne, et al. Standards Track [Page 23] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 23] RFC 4480 RIPD July 2006
<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="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" />
Schulzrinne, et al. Standards Track [Page 24] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 24] RFC 4480 RIPD July 2006
<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: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"/>
Schulzrinne, et al. Standards Track [Page 25] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 25] RFC 4480 RIPD July 2006
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<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-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:element name="place-type"> <xs:annotation>
Schulzrinne, et al. Standards Track [Page 26] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 26] RFC 4480 RIPD July 2006
<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: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="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>
Schulzrinne, et al. Standards Track [Page 27] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 27] RFC 4480 RIPD July 2006
<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="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: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>
Schulzrinne, et al. Standards Track [Page 28] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 28] RFC 4480 RIPD July 2006
</xs:complexType>
</xs:element>
</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="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="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: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>
Schulzrinne, et al. Standards Track [Page 29] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 29] RFC 4480 RIPD July 2006
<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: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>
<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>
6. Extending RPID
6. Extending RPID
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.
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.
Schulzrinne, et al. Standards Track [Page 30] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 30] RFC 4480 RIPD July 2006
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.
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.
7. IANA Considerations
7. IANA Considerations
7.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf:rpid'
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
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
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
Schulzrinne, et al. Standards Track [Page 31] RFC 4480 RIPD July 2006
Schulzrinne, et al. Standards Track [Page 31] RFC 4480 RIPD July 2006
7.2. Schema Registration for Schema
'urn:ietf:params:xml:ns:pidf:status:rpid'
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
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.
Note that this document does not need a new content type. It inherits the content type from [8], namely, application/pidf+xml.
8. Internationalization Considerations
8. Internationalization Considerations
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 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.
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].
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].
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.
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.
A description of time-zone considerations can be found in Section 3.13.
A description of time-zone considerations can be found in Section 3.13.
9. Security Considerations
9. Security Considerations
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と比べて、この存在ドキュメント・フォーマットは非常に敏感である場合があるpresentitiesに関する追加情報を明らかにします。 秘密性と保全を保護する伝統的なセキュリティ対策を超えたところまで、システムは選択的に特定のウォッチャーに情報を明らかにして、発表されている情報を点検する手段を提供するはずです、特にそれが他のソースから自動的に発生するなら、カレンダーやセンサのように。
Schulzrinne, et al. Standards Track [Page 32] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[32ページ]。
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.
外部の物のどんな参照のようにも、<状態アイコン>はウォッチャーが第三者(満足している間接指定攻撃)からのデータを検索するのをpresentityを引き起こさせるかもしれません、その結果、有害コンテンツを検索するか、または参照をつけられたリソースのサーバ負荷に加えます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[4] モウツ、R.、「IETFドキュメントのためのつぼの名前空間」、RFC2648、1999年8月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
2000年2月の[5] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[6] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[7] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、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] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、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.、パオリ、J.、T.、およびE.Maler、「拡張マークアップ言語(XML)1.0(第3版)」をSperberg-マックィーン、C.はいななかせます、W3C REC REC-xml-20040204、2004年2月。
[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] マローニー、M.、ぶな、D.、トンプソン、H.、およびN.メンデルゾーン、「XML図式第1部:」 「構造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.ビロン、「XML図式第2部:」 「データ型式第2版」、W3C REC REC-xmlschema-2-20041028、2004年10月。
[12] Schulzrinne, H. and H. Tschofenig, "Location Types Registry",
RFC 4589, July 2006.
[12]SchulzrinneとH.とH.Tschofenig、「位置は登録をタイプする」RFC4589、2006年7月。
Schulzrinne, et al. Standards Track [Page 33] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[33ページ]。
10.2. Informative References
10.2. 有益な参照
[13] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[13] ドーソンとF.とD.Stenerson、「インターネットCalendaringとスケジューリングは物の仕様(iCalendar)の芯を取る」RFC2445、1998年11月。
[14] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
RFC 3860, August 2004.
[14] ピーターソン、J.、「インスタントメッセージング(CPIM)のための一般的なプロフィール」、RFC3860、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] レノックス、J.、ウー、X.、およびH.Schulzrinne、「言語(CPL)に処理に電話をしてください」 「インターネット電話サービスのユーザコントロールのための言語」、RFC3880、2004年10月。
[16] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
2006.
[16] ローゼンバーグ、J.、「存在のためのデータモデル」、RFC4479、2006年7月。
[17] Lisetti, C., "Personality, Affect, and Emotion Taxonomy for
Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002.
[17]Lisettiと、C.と、「社会的に知的なエージェントのための個性、感情、および感情分類学」、能力2002の議事、2002
[18] Open Mobile Alliance, "The Wireless Village Initiative:
Presence Attributes 1.1", Recommendation WV-29, 2004.
[18] モバイル同盟を開いてください、「無線の村のイニシアチブ:」 存在属性1.1インチ、推薦ウェストヴァージニア-29、2004。
Schulzrinne, et al. Standards Track [Page 34] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[34ページ]。
Appendix A. Acknowledgements
付録A.承認
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.
ドキュメントは多くの個人から貢献とのSIMPLEメーリングリストについての議論を反映します。 デヴィッドL.Black、ミゲル・ガルシア、Avshalom Houri、マーカスIsomaki、リック・ジョーンズ、Hisham Khartabil、ジョナサンレノックス、エバ-マリアLeppanen、ミッコLonnfors、Rohanマーイ、ミゲル・マーシャ、アンドリュー・ニュートン、アキNiemi、ジョン・ピーターソン、およびブライアン・ローゼンは詳細なコメントと提案を提供しました。 Xiaotaoウーは図式テストを助けました。 ヤリUrpalainenはXML図式問題で有益な助言を提供しました。
Schulzrinne, et al. Standards Track [Page 35] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[35ページ]。
Authors' Addresses
作者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7042 EMail: hgs+simple@cs.columbia.edu URI: http://www.cs.columbia.edu
以下に電話をしてください。 +1 7042年の212 939メール: 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
ビジェイGurbani透明な2000ナパービル通り 部屋6G-440不-60566-7033ナパービル(米国)
EMail: vkg@lucent.com
メール: vkg@lucent.com
Paul Kyzivat Cisco Systems BXB500 C2-2 1414 Massachusetts Avenue Boxborough, MA 01719 US
Boxborough、ポールKyzivatシスコシステムズBXB500 C2-2 1414MA01719米国マサチューセッツ通り
EMail: pkyzivat@cisco.com
メール: pkyzivat@cisco.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054-2711 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaパーシッパニー、ニュージャージー07054-2711米国
EMail: jdrosen@cisco.com
メール: jdrosen@cisco.com
Schulzrinne, et al. Standards Track [Page 36] RFC 4480 RIPD July 2006
Schulzrinne、他 規格はRIPD2006年7月にRFC4480を追跡します[36ページ]。
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)によって提供されます。
Schulzrinne, et al. Standards Track [Page 37]
Schulzrinne、他 標準化過程[37ページ]
一覧
スポンサーリンク
