RFC 4481

RFC 4481 is here, bestie! 🎀✨

Title block 📋: This is RFC 4481, a Standards Track doc from the Network Working Group, dated July 2006. It was written by H. Schulzrinne at Columbia U. It doesn't list any RFCs it obsoletes or updates. 🦋

The official title is Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals 💅

Status of This Memo 📜

okay so this doc is an Internet standards track protocol spec for the Internet community. It's also asking for discussion and suggestions 🫶 For the current standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed with no limits, which is so generous 🌸

Copyright Notice 💖

Copyright (C) The Internet Society (2006). 💜

Abstract ✨

okay, so PIDF is the basic XML format used to show presence info for a presentity 🧚 This doc extends PIDF with a timed status extension, the <timed-status> element. It lets a presentity declare its status for a time interval that's fully in the future or fully in the past. It's giving time travel 🕰️💅

Table of Contents 🍓

   1. Introduction ....................................................2
   2. Terminology and Conventions .....................................2
   3. Timed-Status Element ............................................3
   4. Example .........................................................4
   5. The XML Schema Definition .......................................5
   6. IANA Considerations .............................................6
      6.1. URN Sub-Namespace Registration for
           'urn:ietf:params:xml:ns:pidf:timed-status' .................6
      6.2. Schema Registration for Schema
           'urn:ietf:params:xml:ns:pidf:timed-status' .................7
   7. Security Considerations .........................................7
   8. References ......................................................7
      8.1. Normative References .......................................7
      8.2. Informative References .....................................7
   Contributor's Address ..............................................8
   Acknowledgements ...................................................8

---

1. Introduction 🌈

okay so presence info has traditionally been represented as PIDF [3], and then augmented with RPID [9] (Rich Presence Information Data format). It describes the presentity's current state. But honestly? A watcher can plan way better if they know what the presentity has coming up 🗓️ Like, if a watcher knows the presentity is about to travel, they might call earlier. Main character planning 💅

In this doc we use terms defined in RFC 2778 [7]. The big one is "presentity", short for presence entity, which is the thing that gives presence info to a presence service. It's usually a uniquely-identified person 🫶

RPID already lets a presentity say when a particular part of its presence is valid. BUT the <status> element in the PIDF <tuple> doesn't have that feature 😭 So there's no way to say a presentity will be OPEN or CLOSED in the future, for example.

Past info is lowkey useful too 🙈 It might be the only presence info anyone has, and it can give watchers a hint about the current status. For example, if the presentity was at an off-site meeting that ended an hour ago, that suggests they're probably in transit right now 🚗

You can't just slap time range attributes onto the PIDF <status> element, sadly. PIDF parsers that don't know about this would ignore those attributes, and then they couldn't tell current status apart from future status 💀

So this doc defines the <timed-status> element. It describes a presentity's status that's either no longer valid or covers some future time period. ✨

2. Terminology and Conventions 📖

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this doc are to be read as described in BCP 14, which is RFC 2119 [1]. 🔥

3. Timed-Status Element 🎀

The <timed-status> element is a child of the <tuple> element. It MUST NOT appear as a child of a PIDF <status> element or another <timed-status> element. More than one of these elements MAY appear inside a PIDF <tuple> element 🍓

Sources of <timed-status> info should avoid elements that overlap in time. BUT overlapping appointments are super common in calendars, for example, so receivers MUST be able to render those overlapping <timed-status> indications. Handle your business, receivers 💅

The <timed-status> element MUST be qualified with the 'from' attribute. It MAY also be qualified with an 'until' attribute. Together they say when the status took on this value and until when the element is expected to be valid 🦋 If the 'until' attribute is missing, the info is assumed valid until the tuple is explicitly overridden, or until it expires under whatever publication mechanism is being used.

The time range MUST NOT encompass the present time, meaning the PIDF <timestamp> value. Why? Because that would be an unnecessary and confusing second way to describe presence 🙅‍♀️ So the 'from' attribute for tuples without an 'until' attribute MUST refer to the future.

During composition, a presence agent (PA) may run into a stored <timed-status> element that covers the present time. The PA MAY either discard that element, or MAY convert it into a regular <status> element if it finds that info more credible 🤔

The <timed-status> element may contain the <basic> and <note> elements. It can also hold any other element that works as a PIDF <status> extension and has a limited validity period. The PIDF-LO [8] extensions for location objects are one example 🗺️

This extension uses absolute times instead of relative ones, because relative times would be a nightmare to keep updated when, for example, spacing out notifications 😩 Originators of presence info MUST generate time values in the <timed-status> elements that are fully in the past or fully in the future. That's measured against local real (wallclock) time and against the time info in the optional PIDF <timestamp> element, if there is one. No vague times, periodt 💖

4. Example 🌸

Here's an example that combines PIDF and timed-status 🧚

   <presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"
       entity="pres:someone@example.com">

     <tuple id="c8dqui">
       <status>
         <basic>open</basic>
       </status>
       <ts:timed-status from="2005-08-15T10:20:00.000-05:00"
          until="2005-08-22T19:30:00.000-05:00">
          <ts:basic>closed</ts:basic>
       </ts:timed-status>
       <contact>sip:someone@example.com</contact>
     </tuple>
     <note>I'll be in Tokyo next week</note>
   </presence>

5. The XML Schema Definition 💅

The XML [4] schema [5][6] is shown below. It's the official blueprint, so no edits, bestie 🫶

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"
   xmlns:pidf="urn:ietf:params:xml:ns:pidf"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   targetNamespace="urn:ietf:params:xml:ns:pidf:timed-status"
   elementFormDefault="qualified" attributeFormDefault="unqualified">

     <xs:import namespace="urn:ietf:params:xml:ns:pidf"/>

     <xs:annotation>
        <xs:documentation>
          Describes timed-status tuple extensions for PIDF.
        </xs:documentation>
     </xs:annotation>
     <xs:element name="timed-status" type="ts:timed-status"/>
     <xs:complexType name="timed-status">
       <xs:sequence>
         <xs:element name="basic" type="pidf:basic" minOccurs="0"/>
         <xs:element name="note" type="pidf:note" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0"
           maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="from" type="xs:dateTime" use="required"/>
       <xs:attribute name="until" type="xs:dateTime"/>
     </xs:complexType>
   </xs:schema>

Author's Address ✨

Okay bestie, here's where you can find Henning Schulzrinne, the author! 🎓 He's at Columbia University in the Department of Computer Science, and his mailing address is:

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY  10027
US

Phone: +1 212 939 7004
EMail: hgs+simple@cs.columbia.edu
URI:   http://www.cs.columbia.edu

Literally the most professional contact card ever 💼🩷

---

Full Copyright Statement 🔐

Okay, legal stuff time, but make it cute 🎀. The copyright belongs to The Internet Society (2006). 📅

This document is subject to the rights, licenses and restrictions in BCP 78. Except for what BCP 78 says, the authors keep all of their rights. 🙌

Now the spicy part 🌶️ The document and everything in it are provided "AS IS". 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. 😭 So basically: no promises, no guarantees, just vibes. 💀

Heads up, this disclaimer is all-caps for a reason. Read it like it's the terms and conditions you never read.

---

Intellectual Property 💜

Okay so the IETF is not taking a side on whether any Intellectual Property Rights (or other rights) that might cover the tech in this document are valid, or how far they reach. 🤷‍♀️ It also isn't saying whether licenses for those rights are available. And it hasn't independently gone looking for any of them either. 🕵️‍♀️ If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79. 📚

Copies of IPR disclosures sent to the IETF Secretariat live in the IETF online IPR repository at http://www.ietf.org/ipr. You can also find any assurances of licenses that were offered there. 🗂️ And if someone tried to get a general license or permission to use the proprietary rights for implementers or users of this spec, the result of that attempt is posted there too. ✨

The IETF also genuinely wants you to speak up 📣 If you know about any copyrights, patents, patent applications, or other proprietary rights that could cover technology you'd need to implement this standard, tell the IETF! 🫶 Send that info to ietf-ipr@ietf.org. We love a helpful friend 💅

---

Acknowledgement 🌸

Huge thank-you to the people keeping the lights on! 💖 Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 🎉 Without them, none of these RFCs would get published, and honestly that would be a whole tragedy 😭