RFC 3953

Telephone Number Mapping (ENUM) Service Registration for Presence Services 🎀

Network Working Group ✨ RFC 3953 ✨ (January 2005)

Okay so this one is by Jon Peterson from NeuStar, and it's a Standards Track doc 🔥 It's about registering an ENUM service for presence. The title block doesn't say it obsoletes or updates any other RFC, so nothing to report there 🌸

---

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.

Copyright Notice 🌈

Copyright (C) The Internet Society (2005).

Abstract ⭐

This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM.

Table of Contents 📚

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ENUM Service Registration  . . . . . . . . . . . . . . . . . . . 2
3. Presence for E.164 Numbers . . . . . . . . . . . . . . . . . . . 2
4. The 'E2U+pres' Enumservice . . . . . . . . . . . . . . . . . . . 3
5. Example of E2U+pres Enumservice  . . . . . . . . . . . . . . . . 4
6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.1.  Normative References . . . . . . . . . . . . . . . . . . . 5
   8.2.  Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction ✨

Okay so ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name Service, RFC 1034 [8]) to translate telephone numbers, like +12025332600, into URIs (Uniform Resource Identifiers, RFC 2396 [9]), like pres:user@host.com. ENUM exists mainly so that systems built around telephone numbers can talk to systems that use URIs to identify resources. It's giving connection 💖

Presence is a service defined in RFC 2778 [2] that lets users of a communications service keep an eye on one another's availability and disposition so they can decide whether to reach out 👀 Presence info is super dynamic. It usually tells you whether someone is online or offline, busy or idle, away from their communications devices or nearby, and stuff like that 🦋

The IETF has defined a generic URI for identifying a presence service for a particular resource: the 'pres' URI scheme (defined in CPP [4]). This document describes an enumservice for advertising presence information tied to an E.164 number 🎀

2. ENUM Service Registration 💅

As defined in [1], here's the template covering the info needed to register the enumservice in this document:

   Service name: "E2U+pres"

   URI scheme(s): "pres:"

   Functional Specification: See section 4.

   Security considerations: See section 6.

   Intended usage: COMMON

   Author: Jon Peterson (jon.peterson@neustar.biz)

   Any other information that the author deems interesting: See
   section 3.

3. Presence for E.164 Numbers 🧚

This section is the main character 🎀 It specifies an enumservice field that lets presence information be provided for an E.164 number. That can include presence states tied to telephones, or presence for non-telephony communications services advertised through ENUM 💜

Okay, so endpoints in a presence setup are called watchers and presentities (following the framework in RFC 2778 [2]). Watchers subscribe to presentities' presence and get notified whenever it changes. Watchers usually keep tabs on a whole group of presentities they have an ongoing relationship with 🫶 Picture a telephony example: most cellular phones today have an address-book-like feature, a little database of names and phone numbers. That phone could act as a watcher, subscribing to the presence of some or all of the numbers in its address book. When a presence-enabled number gets selected, the display could show the user whether the destination is available. With that info, the user might change their calling habits to match when their people are free 📞✨ Literally so smart.

Presence info varies by communications service. The IETF has defined a Presence Information Data Format (or PIDF [6]) for describing the presence data associated with a presentity 🌸 The baseline PIDF spec only declares two presence states: OPEN and CLOSED (these terms are defined in RFC 2778 [2]). OPEN suggests the destination resource can accept communication requests, and CLOSED suggests it can't. Those two states give useful but basic insight into a presentity's communications status, so PIDF is extensible, and new kinds of statuses can be defined for specific communications services. For example, a telephony-based presence service might define a status for 'busy' 📱 Extending PIDF for telephony services is, however, outside the scope of this document 🙈

4. The 'E2U+pres' Enumservice 🔥

Traditionally, the services field of a NAPTR record (as defined in [10]) holds a string made of two subfields: a 'protocol' subfield and a 'resolution service' subfield. ENUM specifically defines an 'E2U' (E.164 to URI) resolution service. This document defines an 'E2U+pres' enumservice for presence 💖

The scheme of the URI that shows up in the regexp field of a NAPTR record using the 'E2U+pres' enumservice SHOULD be the 'pres' URI scheme. Other URI schemes appropriate to presence services MAY be used. Still, using the 'pres' URI scheme gives a greater level of compatibility than using any URI specific to a particular presence protocol, so it's the move 👑 The whole point of a pres URI is to provide a generic way to locate a presence service. Techniques for dereferencing the pres URI to find a presence service are given in [5] 🦋

The 'pres' URI scheme doesn't identify any particular protocol for handling presence operations (like subscriptions and notifications). Instead, the mechanism in [5] details a way to discover whether the presence protocol(s) supported by the watcher is/are also supported by the presentity 🫶 SIP [7] is one protocol that can be used to convey presence information and manage subscriptions/notifications ✨

To be continued in part 2 with the example, security, IANA, references, and the author's address 🎀💜

Intellectual Property ✨

Okay bestie, the IETF is being super careful here 💅 It takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether a license for those rights is available, and it doesn't claim to have done any independent hunt for such rights 🕵️‍♀️ If you want the IETF's rules on rights in IETF Documents, look at BCP 78 and BCP 79 📚

If you want copies of IPR disclosures sent to the IETF Secretariat, or assurances of licenses that will be available, or the results of anyone trying to get a general license or permission to use those proprietary rights, you can find them in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔎

And the IETF invites any interested party to tell them about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 💜 Send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🫶

The RFC Editor function is currently funded by the Internet Society 🌈 Thank you to them for keeping the lights on for the RFCs we all love ✨