RFC 4480
RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
RFC 4480: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) ✨
Okay bestie, this is RFC 4480 📜 Its full title is RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF). It came from the Network Working Group in July 2006 and is a Standards Track document. The authors are H. Schulzrinne (Columbia U.), V. Gurbani (Lucent), P. Kyzivat, and J. Rosenberg (Cisco). Its title block has no Obsoletes or Updates entries, so it doesn't list any RFC it replaces or changes 💅
Status of This Memo 📢
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🌸 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2006).
Abstract 🧚
The Presence Information Data Format (PIDF) gives a basic format for representing presence information about a presentity. It has 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) is an extension that adds optional elements to PIDF. These extensions tell you more about the presentity and its contacts. The info is designed so that a lot of it can be derived automatically, e.g., from calendar files or user activity 🗓️
RPID covers 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 stay private, how a service tuple relates to another presentity, the person's mood, the time zone they're in, the type of service they offer, an icon showing the presentity's status, and the overall role of the presentity. It's giving main character energy 👑
These extensions cover presence information for persons, services (tuples), and devices 💜
Table of Contents 📚
1. Introduction ....................................................2
2. Terminology and Conventions .....................................4
3. RPID Elements ...................................................4
3.1. Overview ...................................................4
3.2. Activities Element .........................................7
3.3. Class Element .............................................10
3.4. Device Identifier .........................................10
3.5. Mood Element ..............................................10
3.6. Place-is Element ..........................................12
3.7. Place-type Element ........................................13
3.8. Privacy Element ...........................................14
3.9. Relationship Element ......................................15
3.10. Service Class ............................................15
3.11. Sphere Element ...........................................16
3.12. Status-Icon Element ......................................16
3.13. Time Offset ..............................................17
3.14. User-Input Element .......................................17
4. Example ........................................................18
5. XML Schema Definitions .........................................20
5.1. urn:ietf:params:xml:ns:pidf:rpid ..........................20
6. Extending RPID .................................................30
7. IANA Considerations ............................................31
7.1. URN Sub-Namespace Registration for ........................31
'urn:ietf:params:xml:ns:pidf:rpid'
7.2. Schema Registration for Schema ............................32
'urn:ietf:params:xml:ns:pidf:status:rpid'
8. Internationalization Considerations ............................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
Appendix A. Acknowledgements .....................................351. Introduction 🎀
The Presence Information Data Format (PIDF) definition [8] describes a basic presence information data format. It's encoded as an Extensible Markup Language (XML) [9] (SCHEMA-1 [10]) (SCHEMA-2 [11]) for exchanging presence information in systems that follow the common model for presence and instant messaging [5]. It has a <presence> root element, zero or more <tuple> elements that carry 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" 🦋
But it's often really useful to share extra info about a user that a machine needs to interpret. That kind of info doesn't belong in the <note> element, which is usually meant for a human to read. So this spec defines extensions to the PIDF document format for sharing richer presence info 🤓 The extensions were picked to cover features that existing presence systems had at the time of writing, plus things that could easily be derived automatically from existing presence sources, like calendaring systems, communication devices, or sources that describe the user's physical environment 🌈
The presence data model [16] defines service, device, and person as the data elements 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 with the <tuple> element defined in PIDF. Devices and persons are represented by the <device> and <person> XML elements, respectively, which are defined in the data model [16]. But neither PIDF nor the data model defines presence attributes beyond the <basic> status element 🙈
This spec adds more presence attributes to describe person, service, and device data elements. Together they're 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 from the data model 💅
This extension has two main goals:
- Provide rich presence information that is at least as powerful as common commercial presence systems. Feature parity like this makes it easier to move over to systems that comply with the Common Profile for Instant Messaging (CPIM) [14], both for user acceptance and for protocol conversion ✨
- Maintain backward-compatibility with PIDF, so PIDF-only watchers and gateways can keep working properly, naturally without access to the functionality described here 🫶
We make no assumptions about how the info in RPID elements gets generated. Experience has shown that users aren't always diligent about updating their presence status 😭 So we want it to be as easy as possible to derive RPID info from other sources, like personal calendars, the status of communication devices such as telephones, typing activity, and physical presence detectors like the ones commonly found in energy-management systems ⚡
A lot of the elements match data commonly found in personal calendars. So we tried to line up some of the extensions with the usage found in calendar formats such as iCal [13] 🗓️
The info in a presence document can be generated by a single entity, or it can be composed from info published by multiple entities 🧩
PIDF documents and this extension can be used in two different contexts. The presentity can use them to publish its presence status, and the presence server can use them to notify a set of watchers. The presence server MAY compose, translate, or filter the published presence state before delivering customized presence info to the watcher. For example, it may merge presence info from multiple presence user agents, remove whole elements, translate values in elements, or remove info from elements. Mechanisms that filter calls and other communications to the presentity can subscribe to this presence info just like a regular watcher. They can then generate automated rules, such as scripts [15], that govern the presentity's actual communications behavior. Details are in the data model document 🔥
Since RPID is a PIDF XML document, it also uses the content type application/pidf+xml 💖
2. Terminology and Conventions 📖
This memo uses the vocabulary defined in the IMPP model document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT mean the same thing here as they do there 🌸
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]. Yes, those capitals are the real deal, so respect them 👑
3. RPID Elements 🦄
Part 2 picks up right here, so stay tuned 🫶
3.1. Overview ✨
Okay bestie, so some of the RPID elements describe services, some describe devices, and some describe the person 💅 That's why they extend <tuple>, <device>, or <person>, respectively. Below is the quick tour, and the next sections dive deeper 🫶
activities: The<activities>status element lists what the person is doing.class: An identifier that groups similar person elements, devices, or services.deviceID: A device identifier in a tuple points to a<device>element, saying this device helps deliver the service the tuple describes.mood: The<mood>status element shows the person's mood 🌈place-is: The<place-is>status element reports on the properties of the place the presentity is at right now, like how bright or noisy it is.place-type: The<place-type>element says what kind of place the person is in, like'classroom'or'home'🏠privacy: The<privacy>element tells you whether the communication service is likely to be seen by other parties 👀relationship: When a service might reach someone besides the person tied to the presentity, this shows how that other user is related to the person 💜service-class: The<service-class>element says whether the service is electronic, a postal or delivery service, or in-person communication 📬sphere: The<sphere>element captures the overall current role of the presentity ✨status-icon: The<status-icon>element shows the current status of the person or service, like a little icon 🎀time-offset: The<time-offset>status element measures the time zone the person is in, as the number of minutes away from UTC ⏰user-input: The<user-input>element records the user-input or usage state of the service or device, based on human input 🫧
The 'From/until?' column in Table 1 has an 'x' for any element that can take 'from' and 'until' attributes. An 'x' in the 'Note?' column marks elements that can include a <note> element. Columns 4 through 6 show where each element can live inside <person>, <tuple>, and <device>. An 'x' in those columns means the RPID element MAY appear as a child of that element. Basically, the table is your cheat sheet 🍓
+-----------------+------------+------+----------+---------+----------+
| Element | From/until | Note | <person> | <tuple> | <device> |
| | ? | ? | | | |
+-----------------+------------+------+----------+---------+----------+
| <activities> | x | x | x | | |
| <class> | | | x | x | x |
| <deviceID> | | | | x | |
| <mood> | x | x | x | | |
| <place-is> | x | x | x | | |
| <place-type> | x | x | x | | |
| <privacy> | x | x | x | x | |
| <relationship> | | x | | x | |
| <service-class> | | x | | x | |
| <sphere> | x | | x | | |
| <status-icon> | x | | x | x | |
| <time-offset> | x | | x | | |
| <user-input> | | | x | x | x |
+-----------------+------------+------+----------+---------+----------+
Table 1Honestly, it's really unlikely that a presentity will publish or announce all of these elements at the same time 😭 These elements were picked to give presentities maximum flexibility. They can pull the info from existing sources like calendar apps, device activity sensors, or location trackers, or set it manually. Either way, there is no guarantee the information is accurate, because people forget to update calendars or don't always fix their presence info by hand 🙈
The namespace URIs for these elements are URNs [2], using the namespace identifier 'ietf' defined by [4] and extended by [6]:
urn:ietf:params:xml:ns:pidf:rpidElements marked with an 'x' in column 2 of Table 1 MAY be qualified with the 'from' and 'until' attributes. These describe the absolute time when the element took on this value and the absolute time until which it's expected to stay valid ⏳ Also, if there are multiple elements of the same type, their time ranges SHOULD NOT overlap. Main character energy means no overlapping timelines 💅
Elements MAY contain an 'id' attribute so they can be uniquely referenced 🔖
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 🧚
All elements described in this document are optional within PIDF documents 🌸
3.2. Activities Element ✨
The <activities> element describes what the person is currently doing, written as an enumeration of activity-describing elements. A person can be doing multiple activities at once, like traveling and having a meal 🍽️ This element is super helpful for the watcher, because it helps them judge how appropriate a communication attempt is and which method is most likely to work without annoying the person. The activity indications roughly match the category field in calendar entries, such as Section 4.8.1.2 of RFC 2445 [13] 📅
An activities enumeration is made of one or more elements from the list below, a string enclosed in the <other> element, or IANA-registered values from other namespaces (Section 7).
If a person publishes an activity of "permanent-absence", all services will likely report a status of CLOSED 🚪 In general, services MAY advertise either service status for any activity value.
Activities like <appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar info 🗓️
Here's the full activity list, bestie:
appointment: The person has a calendar appointment, but it doesn't say exactly what kind. This is shown if more detailed info isn't available or the person chooses not to share more.away: The person is physically away from all interactive communication devices. This one was included because it can often be figured out automatically from security systems, energy management systems, or entry badge systems. This activity usually goes with a status of CLOSED across all services, but a person might say they're away to discourage contact while still being reachable if needed. Communication attempts might still reach an answering service, for example 📞breakfast: The person is eating the first meal of the day, usually in the morning 🥞busy: The person is busy, with no further details. This usually goes with a status of CLOSED across all services, but a person might say they're busy to discourage contact while still being reachable if needed 🐝dinner: The person is having their main meal of the day, eaten in the evening or at midday 🍝holiday: A scheduled national or local holiday 🎉in-transit: The person is riding in a vehicle, like a car, but isn't steering. The<place-type>element gives more specific info about the type of conveyance 🚗looking-for-work: The presentity is looking for (paid) work 💼lunch: The person is eating their midday meal 🥪meal: The person is scheduled for a meal, without saying whether it's breakfast, lunch, dinner, or some other meal 🍱meeting: The person is in an assembly or gathering of people, for business, social, or religious purposes. A meeting is a sub-class of an appointment 🤝on-the-phone: The person is talking on the telephone. This is included because it can often be detected automatically 📱other: The person is doing 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's different from a meeting because the person might be lecturing or sitting in the audience with lots of other people, which makes interruptions especially noticeable 🙉permanent-absence: The person won't be back for the foreseeable future, for example because they're no longer working for the company 👋 This activity goes with a status of CLOSED across all services.playing: The person is occupying themselves with amusement, sport, or other recreation 🎮presentation: The person is giving a presentation or lecture, or taking part in a formal round-table discussion 📊shopping: The person is visiting stores looking for goods or services 🛍️sleeping: This activity category can often be generated automatically from a calendar, local time info, or biometric data 😴spectator: The person is watching an event, like a sports event 🏟️steering: The person is controlling a vehicle, watercraft, or plane 🛳️travel: The person is on a business or personal trip, but not necessarily in-transit ✈️tv: The person is watching television 📺unknown: The person's activity 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 labor, typically paid, as part of a profession or job 💻worship: The presentity is taking part in religious rites 🙏
The <activities> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1.
Example:
<activities>
<note>Enjoying the morning paper</note>
<vacation/>
<breakfast/>
<other>reading</other>
</activities>3.3. Class Element ✨
The <class> element describes the class of the service, device, or person 🏷️ Multiple elements can share the same class name within a presence document, but each person, service, or device can only have one class label. The presentity gets to name the classes. The presentity can use this to group similar services, devices, or person elements, or to pass along info the presence agent can use for filtering or authorization. This info generally doesn't show up in the watcher's user interface 🫣
The <class> element MUST NOT be qualified with the 'from' and 'until' attributes as described in Section 3.1.
3.4. Device Identifier 🎀
okay so the <deviceID> element lives inside <tuple> and tells you which device is actually providing a service 📱. it's defined syntactically in the data model [16] schema. one service can be provided by multiple devices, so each service tuple may hold zero or more <deviceID> elements. the order doesn't mean anything, so nobody gets bumped to the top 💅.
the main rule here: the <deviceID> element MUST NOT be qualified with the 'from' and 'until' attributes as described in Section 3.1. no time-stamping these, bestie 🙅♀️
3.5. Mood Element 🌈
the <mood> element describes the presentity's mood 🥹. the mood values are enumerated and chosen by the presentity. the mood itself shows up as the element name of a defined child element of <mood> (like <happy/>), and one such child element is REQUIRED. so you can't just leave it empty, periodt 💅.
the user MAY also add a natural-language description of the mood, or the reason behind it, in the <note> child of <mood>. that <note> is OPTIONAL, so it's totally your call 🫶. (this definition follows Jabber Extension JEP-107, which is where the vibes come from ✨)
it is RECOMMENDED that an implementation support the mood values proposed in Jabber Extension JEP-0107. those values are a superset of the Wireless Village [18] mood values, plus the values enumerated in the Affective Knowledge Representation that Lisetti [17] defined 🧠. so JEP-0107 is basically the whole squad 👑
a mood enumeration can be made of one or more elements drawn from the list below. it can also be a string enclosed in the <other> element, or an IANA-registered value from another namespace (Section 7) 🍓
the <mood> element MAY be qualified with the 'from' and 'until' attributes as described in Section 3.1 ⏰
here's the list of mood elements 👇
afraid
amazed
angry
annoyed
anxious
ashamed
bored
brave
calm
cold
confused
contented
cranky
curious
depressed
disappointed
disgusted
distracted
embarrassed
excited
flirtatious
frustrated
grumpy
guilty
happy
hot
humbled
humiliated
hungry
hurt
impressed
in_awe
in_love
indignant
interested
invincible
jealous
lonely
mean
moody
nervous
neutral
offended
other
playful
proud
relieved
remorseful
restless
sad
sarcastic
serious
shocked
shy
sick
sleepy
stressed
surprised
thirsty
unknown
worriedand an example, because examples are everything 💖
<mood>
<note>I'm ready for the bar BOF!</note>
<sleepy/>
<thirsty/>
</mood>3.6. Place-is Element 🦋
the <place-is> element describes the properties of the place the person is currently at 📍. it's giving "here's what kind of communication will probably land" ✨. each major media type has its own set of attributes. if you leave the element out, that means the property is unknown 🤷♀️
for audio, we define these attributes:
noisy: the person is somewhere with enough background noise that audio communication is difficult 🔊ok: the environmental conditions are suitable for audio communications 👌quiet: the person is in a place like a library, restaurant, place of worship, or theater, where noise, conversation, and other distractions are discouraged 🤫unknown: the place attributes for audio are unknown 🙈
for video, we define these attributes:
toobright: the person is in a bright place, enough for good rendering on video ☀️ok: the environmental conditions are suitable for video 🎥dark: the person is in a dark place, so the camera may not be able to capture a good image 🌙unknown: the place attributes for video are unknown 🙈
for text (real-time text and instant messaging), we define:
uncomfortable: typing or other text entry is uncomfortable 😬inappropriate: typing or other text entry is inappropriate, e.g., because the user is in a vehicle or house of worship 🚗⛪ok: the environmental conditions are suitable for text-based communications 💬unknown: the place attributes for text are unknown 🙈
this list can be augmented by free-text values in a note, or by additional IANA-registered values (Section 7) 🍓
the <place-is> element contains other elements, like this:
<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 ⏰
3.7. Place-type Element 🏡
the <place-type> element describes the type of place the person is currently at 🗺️. this gives the watcher a hint about 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 🌸
the <place-type> element is a choice of elements, like this:
<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 ⏰
3.8. Privacy Element 🤫
the <privacy> element indicates which types of communication third parties in the presentity's vicinity are unlikely to accidentally or intentionally intercept 🕵️♀️. this does NOT describe the privacy properties of the electronic channel itself, like the encryption algorithm or the network protocol being used. so don't get it twisted 🙅♀️
audio: inappropriate individuals are not likely to overhear audio communications 🎧text: inappropriate individuals are not likely to see text communications 👀unknown: this information is unknown 🙈video: inappropriate individuals are not likely to see video communications 📹
the <privacy> element can be used by logic running on the watcher, or by a composer, to filter, sort, and label tuples 🏷️. for example, a composer may have rules that limit publishing 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 ⏰
example time 💅
<privacy>
<text/>
<audio/>
</privacy>3.9. Relationship Element 💜
the <relationship> element extends <tuple> and designates what kind of relationship an alternate contact has with the presentity 👯. this element is only provided 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 (like the assistant) that has the relationship to the presentity, NOT the presentity itself 🫣
just 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" 📞
<relationship>
<friend/>
</relationship>3.10. Service Class 🎁
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 📧postal: delivery by the postal service, e.g., as a letter, parcel, or postcard. delivery could go 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 handed to a receptionist rather than, say, a mailroom or receiving department 🛵freight: delivery by freight carrier, typically of larger objects that aren't sent by postal mail or courier. the recipient is often the shipping department or a loading dock 🚚in-person: describes the coordinates for visits in person, as by a visitor, i.e., usually somebody's office or residence 🚪unknown: the type of service is unknown 🙈
electronic service is implied if it's omitted 💻. the service types 'postal', 'courier', 'freight', and 'in-person' MUST NOT be used unless the contact URI is empty. the additional data elements defined elsewhere describe the physical service delivery address for the in-person, postal, or delivery services. those addresses might be given as geospatial coordinates, civic addresses, or some specialized address format, e.g., for interstellar addresses or a company-specific delivery system 🛸
example:
<service-class><postal/></service-class>3.11. Sphere Element 🌙
the <sphere> element designates the current state and role the person plays 🎭. for example, it might say whether the person is in work mode, at home, or taking part in activities related to some other organization, like the IETF or a church ⛪. this document does not define names for these spheres, except for two common ones, "work" and "home", plus "unknown" 🏠
spheres let the person easily turn certain rules on or off, depending on which groups of people should be aware of their status 🔁. for example, if someone is a Boy Scout leader, he might set the sphere to "scouting" and then have a rule set that lets the other scout masters in his troop 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 ⏰
example:
<sphere>
<home/>
</sphere>3.12. Status-Icon Element 🖼️
the <status-icon> element includes a URI pointing to an image (an icon) that represents the current status of the person or service ✨. the watcher MAY use this to show the status in a graphical user interface. presentities SHOULD provide images in 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 their local copy of the icon is current when they receive a notification, using the standard cache control mechanism in the URI-identified retrieval protocol 🔄. no stale icons allowed, bestie 💅
example:
<status-icon>http://www.example.com/playing.gif</status-icon>
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 means the local time-of-day is ahead of Universal Time (i.e., east of it), while a negative number means it's behind (i.e., west of it) 🧭. transitions into and out of daylight savings time may temporarily cause a difference between the true offset from UTC and the time offset element 🌞🌛
there's an optional attribute, description, that can describe the offset, e.g., by labeling the time zone. this description is meant for humans to read 🫶
publishers on mobile devices SHOULD NOT publish this information unless they know the time offset information reflects the current location. (for example, many laptop users don't update their time zone when traveling ✈️) publishers SHOULD update the information whenever they discover that their UTC offset has changed. 🌟
example:
<time-offset description="America/New_York">-300
</time-offset>3.14. User-Input Element ✨
okay so the <user-input> element is basically the "are they actually at the keyboard rn?" signal 👀🎀 It records the user-input or usage state of a service or device, based on real human input like keyboard, pointing device, or voice. If it lives inside a <person> element, it sums up input activity across every service and device that presentity operates 💅 How that aggregation works is beyond this document 🙈 but it generally reflects the most recent input across all devices and services.
The element can be either 'active' or 'idle' 🔥 and it can carry an optional 'last-input' attribute that records when the last input came in. There's also an optional 'idle-threshold' element that says how many seconds the presentity will wait before calling the service or device idle 🧚
(A two-state model was chosen since it would otherwise be necessary to send repeated last-input updates during continuous activity. Genius, honestly 🌸)
A service that wants to show user input activity sends a <user-input> 'active' indication when the user has given input within a configurable interval, the idle-threshold 💖 If the user stops typing and the idle-threshold has passed, the tuple gets marked with a <user-input> 'idle' indication instead. It can optionally include the time of last activity in the 'last-input' attribute ⏰ Here's an example:
<user-input idle-threshold="600"
last-input="2004-10-21T13:20:00.000-05:00">idle</user-input>Depending on what the device or service can do, user input might only be detected for one particular application, like when that app has user focus or when someone sent a message or placed a call 📱 Or it can be based on user input across every application running on one end system. Both are valid, bestie 🫶
The <user-input> element may be used by a watcher, usually alongside other data, to estimate how likely a user is to answer when contacted through the service 📞 A tuple that hasn't been used in a while may still be OPEN, but a watcher may choose to contact a URI in a tuple that is both OPEN and has been used more recently ✨ main character energy for the recently-used one, ngl 😭
The <user-input> attribute can be omitted if the presentity wants to say the device hasn't been used for a while, without revealing the exact duration 🙈 like this:
<user-input>idle</user-input>Configuration MUST include the option to omit the 'last-input' attribute. This one's a must, no cap 💅
4. Example
The example below describes the presentity 'pres:someone@example.com' 🦋 It has a SIP contact, 'sip:someone@example.com', representing a service, and a device contact, an email box. The presentity is in a meeting, in a public office setting. The 'until' information says he'll be there until 5:30 pm local time 🕠 The presentity also has an assistant, sip:secretary@example.com, who happens to be available for communications. Iconic assistant behavior 👑
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:lt="urn:ietf:params:xml:ns:location-type"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
</status>
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
<rpid:relationship><rpid:self/></rpid:relationship>
<rpid:service-class><rpid:electronic/></rpid:service-class>
<contact priority="0.8">im:someone@mobile.example.net</contact>
<note xml:lang="en">Don't Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
<timestamp>2005-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="ty4658">
<status>
<basic>open</basic>
</status>
<rpid:relationship><rpid:assistant/></rpid:relationship>
<contact priority="1.0">mailto:secretary@example.com</contact>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID>
<rpid:class>email</rpid:class>
<rpid:service-class><rpid:electronic/></rpid:service-class>
<rpid:status-icon>http://example.com/mail.png</rpid:status-icon>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
<note>I'll be in Tokyo next week</note>
<dm:device id="pc147">
<rpid:user-input idle-threshold="600"
last-input="2004-10-21T13:20:00-05:00">idle</rpid:user-input>
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
<dm:note>PC</dm:note>
</dm:device>
<dm:person id="p1">
<rpid:activities from="2005-05-30T12:00:00+05:00"
until="2005-05-30T17:00:00+05:00">
<rpid:note>Far away</rpid:note>
<rpid:away/>
</rpid:activities>
<rpid:class>calendar</rpid:class>
<rpid:mood>
<rpid:angry/>
<rpid:other>brooding</rpid:other>
</rpid:mood>
<rpid:place-is>
<rpid:audio>
<rpid:noisy/>
</rpid:audio>
</rpid:place-is>
<rpid:place-type><lt:residence/></rpid:place-type>
<rpid:privacy><rpid:unknown/></rpid:privacy>
<rpid:sphere>bowling league</rpid:sphere>
<rpid:status-icon>http://example.com/play.gif</rpid:status-icon>
<rpid:time-offset>-240</rpid:time-offset>
<dm:note>Scoring 120</dm:note>
<dm:timestamp>2005-05-30T16:09:44+05:00</dm:timestamp>
</dm:person>
</presence>
5. XML Schema Definitions
Okay, the schema time 🤓 The RPID schema is shown below. Schemas can't compose perfectly, so not every XML document that validates against it is semantically valid RPID 🙃 In particular, the schema lets each element appear anyhere in PIDF or data-model elements. Table 1 restricts where these elements can actually show up for semantically valid RPID documents 📋 And elements that don't have from/until parameters MUST NOT appear more than once in each <person>, <tuple>, or <device>. Rules are rules, babe 💅
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"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="activeIdle">
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="idle"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="activities">
<xs:annotation>
<xs:documentation>
Describes what the person is currently doing, expressed as
an enumeration of activity-describing elements. A person
can be engaged in multiple activities at the same time,
e.g., traveling and having a meal.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="unknown" type="empty" minOccurs="0"/>
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="appointment"
type="empty" />
<xs:element name="away"
type="empty" />
<xs:element name="breakfast"
type="empty" />
<xs:element name="busy"
type="empty" />
<xs:element name="dinner"
type="empty" />
<xs:element name="holiday"
type="empty" />
<xs:element name="in-transit"
type="empty" />
<xs:element name="looking-for-work"
type="empty" />
<xs:element name="meal"
type="empty" />
<xs:element name="meeting"
type="empty" />
<xs:element name="on-the-phone"
type="empty" />
<xs:element name="performance"
type="empty" />
<xs:element name="permanent-absence"
type="empty" />
<xs:element name="playing"
type="empty" />
<xs:element name="presentation"
type="empty" />
<xs:element name="shopping"
type="empty" />
<xs:element name="sleeping"
type="empty" />
<xs:element name="spectator"
type="empty" />
<xs:element name="steering"
type="empty" />
<xs:element name="travel"
type="empty" />
<xs:element name="tv"
type="empty" />
<xs:element name="vacation"
type="empty" />
<xs:element name="working"
type="empty" />
<xs:element name="worship"
type="empty" />
<xs:element name="other"
type="Note_t" />
<xs:any namespace="##other"
maxOccurs="unbounded" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="class" type="xs:token">
<xs:annotation>
<xs:documentation>
Describes the class of the service, device or person.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="mood">
<xs:annotation>
<xs:documentation>
Describes the mood of the presentity.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="unknown" type="empty"/>
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="afraid"
type="empty"/>
<xs:element name="amazed"
type="empty"/>
<xs:element name="angry"
type="empty"/>
<xs:element name="annoyed"
type="empty"/>
<xs:element name="anxious"
type="empty" />
<xs:element name="ashamed"
type="empty" />
<xs:element name="bored"
type="empty" />
<xs:element name="brave"
type="empty" />
<xs:element name="calm"
type="empty" />
<xs:element name="cold"
type="empty" />
<xs:element name="confused"
type="empty" />
<xs:element name="contented"
type="empty" />
<xs:element name="cranky"
type="empty" />
<xs:element name="curious"
type="empty" />
<xs:element name="depressed"
type="empty" />
<xs:element name="disappointed"
type="empty" /><xs:element name="disgusted" type="empty" /> <xs:element name="distracted" type="empty" /> <xs:element name="embarrassed" type="empty" /> <xs:element name="excited" type="empty" /> <xs:element name="flirtatious" type="empty" /> <xs:element name="frustrated" type="empty" /> <xs:element name="grumpy" type="empty" /> <xs:element name="guilty" type="empty" /> <xs:element name="happy" type="empty" /> <xs:element name="hot" type="empty" /> <xs:element name="humbled" type="empty" /> <xs:element name="humiliated" type="empty" /> <xs:element name="hungry" type="empty" /> <xs:element name="hurt" type="empty" /> <xs:element name="impressed" type="empty" /> <xs:element name="in_awe" type="empty" /> <xs:element name="in_love" type="empty" /> <xs:element name="indignant" type="empty" /> <xs:element name="interested" type="empty" /> <xs:element name="invincible" type="empty" /> <xs:element name="jealous" type="empty" /> <xs:element name="lonely" type="empty" /> <xs:element name="mean" type="empty" /> <xs:element name="moody" type="empty" />
<xs:element name="nervous" type="empty" /> <xs:element name="neutral" type="empty" /> <xs:element name="offended" type="empty" /> <xs:element name="playful" type="empty" /> <xs:element name="proud" type="empty" /> <xs:element name="relieved" type="empty" /> <xs:element name="remorseful" type="empty" /> <xs:element name="restless" type="empty" /> <xs:element name="sad" type="empty" /> <xs:element name="sarcastic" type="empty" /> <xs:element name="serious" type="empty" /> <xs:element name="shocked" type="empty" /> <xs:element name="shy" type="empty" /> <xs:element name="sick" type="empty" /> <xs:element name="sleepy" type="empty" /> <xs:element name="stressed" type="empty" /> <xs:element name="surprised" type="empty" /> <xs:element name="thirsty" type="empty" /> <xs:element name="worried" type="empty" /> <xs:element name="other" type="Note_t" /> <xs:any namespace="##other" maxOccurs="unbounded" processContents="lax"/> </xs:choice> </xs:sequence> </xs:choice> </xs:sequence> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> </xs:element>
<xs:element name="place-is"> <xs:complexType> <xs:sequence> <xs:element name="note" type="Note_t" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="audio" minOccurs="0"> <xs:complexType> <xs:choice> <xs:element name="noisy" type="empty" /> <xs:element name="ok" type="empty" /> <xs:element name="quiet" type="empty" /> <xs:element name="unknown" type="empty" /> </xs:choice> </xs:complexType> </xs:element> <xs:element name="video" minOccurs="0"> <xs:complexType> <xs:choice> <xs:element name="toobright" type="empty" /> <xs:element name="ok" type="empty" /> <xs:element name="dark" type="empty" /> <xs:element name="unknown" type="empty" /> </xs:choice> </xs:complexType> </xs:element> <xs:element name="text" minOccurs="0"> <xs:complexType> <xs:choice> <xs:element name="uncomfortable" type="empty" /> <xs:element name="inappropriate" type="empty" /> <xs:element name="ok" type="empty" /> <xs:element name="unknown" type="empty" /> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> </xs:element>
<xs:element name="place-type"> <xs:annotation>
<xs:documentation> Describes the type of place the person is currently at. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="note" type="Note_t" minOccurs="0" maxOccurs="unbounded" /> <xs:choice> <xs:element name="other" type="Note_t"/> <xs:any namespace="##other" maxOccurs="unbounded" processContents="lax"/> </xs:choice> </xs:sequence> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> </xs:element>
<xs:element name="privacy"> <xs:annotation> <xs:documentation> Indicates which type of communication third parties in the vicinity of the presentity are unlikely to be able to intercept accidentally or intentionally. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="note" type="Note_t" minOccurs="0" maxOccurs="unbounded" /> <xs:choice> <xs:element name="unknown" type="empty"/> <xs:sequence minOccurs="1"> <xs:element name="audio" type="empty" minOccurs="0"/> <xs:element name="text" type="empty" minOccurs="0"/> <xs:element name="video" type="empty" minOccurs="0"/> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> </xs:sequence> </xs:choice> </xs:sequence> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="relationship"> <xs:annotation> <xs:documentation> Designates the type of relationship an alternate contact has with the presentity. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="note" type="Note_t" minOccurs="0" maxOccurs="unbounded" /> <xs:choice> <xs:element name="assistant" type="empty" /> <xs:element name="associate" type="empty" /> <xs:element name="family" type="empty" /> <xs:element name="friend" type="empty" /> <xs:element name="other" type="Note_t" minOccurs="0" /> <xs:element name="self" type="empty" /> <xs:element name="supervisor" type="empty" /> <xs:element name="unknown" type="empty" /> <xs:any namespace="##other" maxOccurs="unbounded" processContents="lax"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element>
<xs:element name="service-class"> <xs:annotation> <xs:documentation> Designates the type of service offered. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="note" type="Note_t" minOccurs="0" maxOccurs="unbounded" /> <xs:choice> <xs:element name="courier" type="empty" /> <xs:element name="electronic" type="empty" /> <xs:element name="freight" type="empty" /> <xs:element name="in-person" type="empty" /> <xs:element name="postal" type="empty" /> <xs:element name="unknown" type="empty" /> <xs:any namespace="##other" maxOccurs="unbounded" processContents="lax"/> </xs:choice> </xs:sequence>
</xs:complexType> </xs:element>
<xs:element name="sphere"> <xs:annotation> <xs:documentation> Designates the current state and role that the person plays. </xs:documentation> </xs:annotation> <xs:complexType> <xs:choice minOccurs="0"> <xs:element name="home" type="empty" /> <xs:element name="work" type="empty" /> <xs:element name="unknown" type="empty" /> <xs:any namespace="##other" maxOccurs="unbounded" processContents="lax"/> </xs:choice> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> </xs:element>
<xs:element name="status-icon"> <xs:annotation> <xs:documentation> A URI pointing to an image (icon) representing the current status of the person or service. </xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name="time-offset"> <xs:annotation> <xs:documentation> Describes the number of minutes of offset from UTC at the user's current location. </xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:integer"> <xs:attributeGroup ref="fromUntil"/> <xs:attribute name="description" type="xs:string"/> <xs:attribute name="id" type="xs:ID"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
</xs:element>
</xs:schema>6. Extending RPID ✨
Okay so, any developer can invent their own element names 🧚 and avoid clashes by picking a namespace URI that's theirly. Adding new standardized elements to the enumerations <activities>, <mood>, <privacy>, <relationship> and <service-class> is a different story. You follow the extension process described in PIDF [9], which means those extensions use namespace designators like urn:ietf:params:xml:ns:pidf:ext, where ext is the name of the extension. 💅 New values for <place-type> get assigned according to [12], and each one gets its own namespace designator when it's registered.
Now, the no-clutter rule 🫶 To avoid a flood of XML namespaces that each hold just one element, groups of element registrations for each of these enumerations, such as <privacy>, SHOULD be bundled into a single namespace instead of getting a fresh namespace for every new element. Main character energy for organized namespaces, periodt 🎀
7. IANA Considerations 🌸
7.1. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:pidf:rpid'
URI: urn:ietf:params:xml:ns:pidf:rpid
Description: This is the XML namespace for XML elements defined by RFC 4480 to describe rich presence information extensions for the status element in the PIDF presence document format in the application/pidf+xml content type.
Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, Henning Schulzrinne, hgs@cs.columbia.edu
XML:
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>
END7.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
Quick note 📝 this document doesn't need a new content type. It borrows the one from [8], which is application/pidf+xml. Easy peasy 🦋
8. Internationalization Considerations 🌈
RPID is mostly full of tokens meant for programs to read, not for humans to read directly. Programs are expected to turn those tokens into text strings in the right language, based on the watcher's preferences. 💜
Some elements may contain <note> and <other> elements that hold free text. These elements SHOULD be labeled with the xml:lang attribute to say what language and script they're in. The spec lets you have multiple of these elements, so the presentity can share <note> and <other> in several scripts and languages at once, which is so inclusive 😭 If there's no xml:lang attribute, the default value is "i-default" [3].
Since RPID is written in XML, it has built-in support for encoding info with Unicode, including the more compact UTF-8 form. Conformant XML processors recognize both UTF-8 and UTF-16. XML does have a way to use other character encodings through an "encoding" attribute in the <?xml?> declaration, but UTF-8 is RECOMMENDED in environments where parser encoding support is incompatible. ✨
For time-zone stuff, check out Section 3.13 🕰️
9. Security Considerations 🔐
The security considerations in [8] apply, and so does [7]. Compared to PIDF, this presence document format reveals additional information about presentities that can be super sensitive 🙈 Beyond the usual measures to protect confidentiality and integrity, systems should offer a way to selectively reveal information to particular watchers, and a way to inspect the information being published. That matters most when it's generated automatically from other sources, like calendars or sensors.
Heads up, bestie 💀 Like any reference to an external object, the <status-icon> may let the presentity trick the watcher into fetching data from a third party (a content indirection attack). That could mean pulling in harmful content, or piling extra server load onto the referenced resource.
10. References 📚
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[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.
[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.
[11] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[12] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
10.2. Informative References
[13] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[14] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[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.
[16] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[17] Lisetti, C., "Personality, Affect, and Emotion Taxonomy for Socially Intelligent Agents", Proceedings of FLAIRS 2002, 2002.
[18] Open Mobile Alliance, "The Wireless Village Initiative: Presence Attributes 1.1", Recommendation WV-29, 2004.
Appendix A. Acknowledgements 💖
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. Legends. 🫶
Authors' Addresses 🦋
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
EMail: hgs+simple@cs.columbia.edu
URI: http://www.cs.columbia.eduVijay Gurbani
Lucent
2000 Naperville Rd.
Room 6G-440
Naperville, IL 60566-7033
US
EMail: vkg@lucent.comPaul Kyzivat
Cisco Systems
BXB500 C2-2
1414 Massachusetts Avenue
Boxborough, MA 01719
US
EMail: pkyzivat@cisco.comJonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054-2711
US
EMail: jdrosen@cisco.comFull Copyright Statement ©
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌸
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
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.
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.
Acknowledgement 🎀
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
📦 where this page comes from
- ietf: rfc4480 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms