RFC 6118
Update of Legacy IANA Registrations of Enumservices
RFC 6118 🌸 Update of Legacy IANA Registrations of Enumservices
Part 1 of 10 🧚
okay bestie, let's get into it 💅 this one is about cleaning up old Enumservice registrations at IANA, and the paperwork is giving main character energy 👑
- Who wrote it: B. Hoeneisen (Ucom.ch) and A. Mayrhofer (enum.at) ✨
- Published: March 2011 📅
- Category: Standards Track 🎀
- Stream: Internet Engineering Task Force (IETF) 🦋
- Updates: 3762, 3764, 3953, 4143, 4002, 4238, 4355, 4415, 4769, 4969, 4979, 5028, 5278, 5333 🫶
- ISSN: 2070-1721 🌈
Abstract
okay so the abstract is short and sweet 🍓 this doc revises all the Enumservices that were registered with IANA under the old Enumservice registry spec from RFC 3761. that spec is now obsolete, so these registrations need a glow-up 💖
Status of This Memo
this is an Internet Standards Track document 🔥 it's a product of the IETF and it represents the consensus of the IETF community. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨
more info on Internet Standards lives in Section 2 of RFC 5741 🧚 and you can check the current status, any errata, and send feedback at http://www.rfc-editor.org/info/rfc6118 💜
Copyright Notice
okay the legal bit, but make it cute 🎀 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜 read them carefully, because they spell out your rights and restrictions. any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 🦋
heads up: some material in this doc may come from IETF Documents or IETF Contributions published before November 10, 2008. the people who control the copyright on some of that stuff might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈
so, without getting an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside that process either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IESG Action . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Legacy Enumservice Registrations Converted to XML Chunks . . . 5
4.1. email:mailto . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ems:mailto . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. ems:tel . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. fax:tel . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. ft:ftp . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. h323 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. ical-access:http . . . . . . . . . . . . . . . . . . . . . 12
4.8. ical-access:https . . . . . . . . . . . . . . . . . . . . 13
4.9. ical-sched:mailto . . . . . . . . . . . . . . . . . . . . 14
4.10. ifax:mailto . . . . . . . . . . . . . . . . . . . . . . . 15
4.11. im . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.12. mms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 17
4.13. mms:tel . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.14. pres . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.15. pstn:sip . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.16. pstn:tel . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.17. sip . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.18. sms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 24
4.19. sms:tel . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.20. unifmsg:http . . . . . . . . . . . . . . . . . . . . . . . 26
4.21. unifmsg:https . . . . . . . . . . . . . . . . . . . . . . 27
4.22. unifmsg:sip . . . . . . . . . . . . . . . . . . . . . . . 28
4.23. unifmsg:sips . . . . . . . . . . . . . . . . . . . . . . . 29
4.24. vcard . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.25. videomsg:http . . . . . . . . . . . . . . . . . . . . . . 31
4.26. videomsg:https . . . . . . . . . . . . . . . . . . . . . . 32
4.27. videomsg:sip . . . . . . . . . . . . . . . . . . . . . . . 33
4.28. videomsg:sips . . . . . . . . . . . . . . . . . . . . . . 34
4.29. voice:tel . . . . . . . . . . . . . . . . . . . . . . . . 35
4.30. voicemsg:http . . . . . . . . . . . . . . . . . . . . . . 37
4.31. voicemsg:https . . . . . . . . . . . . . . . . . . . . . . 38
4.32. voicemsg:sip . . . . . . . . . . . . . . . . . . . . . . . 39
4.33. voicemsg:sips . . . . . . . . . . . . . . . . . . . . . . 40
4.34. voicemsg:tel . . . . . . . . . . . . . . . . . . . . . . . 41
4.35. vpim:ldap . . . . . . . . . . . . . . . . . . . . . . . . 42
4.36. vpim:mailto . . . . . . . . . . . . . . . . . . . . . . . 43
4.37. web:http . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.38. web:https . . . . . . . . . . . . . . . . . . . . . . . . 46
4.39. xmpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.1. Normative References . . . . . . . . . . . . . . . . . . . 48
8.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Former Content of the IANA Repository . . . . . . . . 491. Introduction ✨
okay so RFC 6117 already obsoleted the IANA registration section of RFC 3761 💅 the IANA Enumservice registry still has a bunch of Enumservices registered under the RFC 3761 rules, and those don't follow the new guidelines from [RFC6117] 🥺
to get everything consistent at IANA, this doc adds the elements that are now missing to those legacy registrations 🫶 it also converts every legacy Enumservice registration to the new XML-chunk format, and where it's needed, it makes minor editorial fixes ✨
but here's the tea 🍵 this doc only adds the missing elements to the XML chunks, as the IANA Considerations section of [RFC6117] specifies. it does NOT finish the missing sections of the Enumservice Specifications themselves. so those specs still need to be revised to match the new registration regime in [RFC6117] 🧚
and it's really important to note that this doc does not update the functional specification of the Enumservices involved 🌸
the following RFCs are updated by this doc:
- [RFC3762]
- [RFC3764]
- [RFC3953]
- [RFC4143]
- [RFC4002]
- [RFC4238]
- [RFC4355]
- [RFC4415]
- [RFC4769]
- [RFC4969]
- [RFC4979]
- [RFC5028]
- [RFC5278]
- [RFC5333]
2. Terminology 🎀
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💜
3. IESG Action 🦋
so back in RFC 3761 days, any Enumservice registration had to be published as a Standards Track, Experimental, or BCP (Best Current Practice) RFC 🍓 RFC 6117 dropped that requirement. now "Specification Required" is enough, which means a Designated Expert [RFC5226] is good enough 🙌
this doc changes the approval requirement for updates to Enumservice registrations to "Specification Required" too 🔥 so the specification and the request get reviewed by a Designated Expert, as [RFC6117] describes ✨
4. Legacy Enumservice Registrations Converted to XML Chunks 🌈
in the following, the legacy Enumservice Registrations get converted into XML chunks that include the new elements introduced by [RFC6117] 💖
(Note that references in Sections 4.1 - 4.39 refer to the references section within the respective Enumservice Specification.)
4.1. email:mailto 📧
<record>
<!-- email:mailto -->
<class>Application-Based, Common</class>
<type>email</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource can be
addressed by the associated URI in order to send an
email.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4355"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>4.2. ems:mailto 💌
<record>
<!-- ems:mailto -->
<class>Application-Based, Common</class>
<type>ems</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using an email protocol.
</paragraph>
<paragraph>
EMS content is sent over SMTP using the format
specified by TS 23.140 [15] Section 8.4.4 and TS
26.140 [16] Section 4, as an MMS message. Within
such a message, EMS content is carried as either a
text or application/octet-stream MIME sub-part (see
TS 26.140 [16], Section 4.1).
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
<paragraph>
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of <xref type="rfc" data="rfc4355"/> apply.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>4.3. ems:tel 💖
Okay so this one is for the texting crowd 📱✨ It's the record for the Enhanced Message Service (EMS) [14]. Here's the XML, verbatim, because the record has to be exact 🫶
<record>
<!-- ems:tel -->
<class>Application-Based, Common</class>
<type>ems</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using the Enhanced Message
Service (EMS) [14].
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
<paragraph>
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of <xref type="rfc" data="rfc4355"/> apply.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
<additionalinfo>
<paragraph>
Note that an indication of EMS can be taken as
implying that the recipient is capable of receiving
SMS messages at this address as well.
</paragraph>
</additionalinfo>
</record>So ems:tel basically says the number can take an EMS message. The security bit is a shrug: no special issues, but the general stuff in Section 6 of [RFC4355] still applies 🙈 And the additionalinfo is a fun one, because an EMS hint also means SMS should work at that address too 🌸
4.4. fax:tel 🎀
This one is a whole vibe 📠 It's the fax Enumservice, and the functional spec is giving "you have a fax program with PSTN access" energy 💅
<record>
<!-- fax:tel -->
<class>Application-Based, Subset</class>
<type>fax</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of being contacted to provide a communication
session during which facsimile documents can be
sent.
</paragraph>
<paragraph>
A client selecting this NAPTR will have support
for generating and sending facsimile documents to
the recipient using the PSTN session and transfer
protocols specified in [12] and [13] in
<xref type="rfc" data="rfc4355"/> -
in short, they will have a fax program with a local
or shared PSTN access over which they can send
faxes.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4355"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>The gist is that the number can be reached for a session where fax documents get sent. A client that picks this NAPTR is expected to be able to generate and send faxes over the PSTN protocols in [12] and [13] from [RFC4355]. Security is just "see [RFC4355], Section 6" 🦋
4.5. ft:ftp 🌈
Next up is ft:ftp, the file one 📁 It says the resource is a file service where you can grab a file or a file listing.
<record>
<!-- ft:ftp -->
<class>Application-Based, Subset</class>
<type>ft</type>
<subtype>ftp</subtype>
<urischeme>ftp</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is a file
service from which a file or file listing can be
retrieved.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4002"/>, Section 5.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4002"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>Security points you to [RFC4002], Section 5 ✨
4.6. h323 🧚
h323 is the protocol-based one, so it's a different energy from the rest 💜 Its functional spec and security both just point you to [RFC3762], and there's no subtype at all.
<record>
<!-- h323 -->
<class>Protocol-Based</class>
<type>h323</type>
<!-- No subtype -->
<urischeme>h323</urischeme>
<functionalspec>
See <xref type="rfc" data="rfc3762"/>, Section 3.
</functionalspec>
<security>
See <xref type="rfc" data="rfc3762"/>, Section 5.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc3762"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Orit_Levin"/>
</requesters>
</record>4.7. ical-access:http 📅
Calendar time 🗓️ This record lets you reach a user's calendar (free/busy status is the example given) over HTTP using CalDAV [7] for Internet calendaring.
<record>
<!-- ical-access:http -->
<class>Application-Based, Common</class>
<type>ical-access</type>
<subtype>http</subtype>
<urischeme>http</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified
can be addressed by the associated URI in order to access
a user's calendar (for example free/busy status) using
the CalDAV [7] protocol for Internet calendaring.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5333"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5333"/>, Section 4.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5333"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rohan_Mahy"/>
</requesters>
</record>4.8. ical-access:https 🔐
This is the exact same calendar record, just with the https scheme instead of http 💖 Same CalDAV [7] story, same security pointer to [RFC5333], Section 4.
<record>
<!-- ical-access:https -->
<class>Application-Based, Common</class>
<type>ical-access</type>
<subtype>https</subtype>
<urischeme>https</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified
can be addressed by the associated URI in order to access
a user's calendar (for example free/busy status) using
the CalDAV [7] protocol for Internet calendaring.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5333"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5333"/>, Section 4.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5333"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rohan_Mahy"/>
</requesters>
</record>4.9. ical-sched:mailto 📧
Scheduling is the vibe here 🗓️💌 It's for calendar scheduling over Internet mail using iMIP [6].
<record>
<!-- ical-sched:mailto -->
<class>Application-Based, Common</class>
<type>ical-sched</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified
can be addressed by the associated URI used for
scheduling using Internet calendaring via Internet mail
with the iMIP [6] protocol.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5333"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5333"/>, Section 4.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5333"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rohan_Mahy"/>
</requesters>
</record>4.10. ifax:mailto 📠
Ifax is the fax-over-email one 💌 The URI scheme is 'mailto' on purpose, since facsimile here is a profile of standard Internet mail that uses regular Internet mail addressing 🌸
<record>
<!-- ifax:mailto -->
<class>Application-Based, Subset</class>
<type>ifax</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
See <xref type="rfc" data="rfc4143"/>, Section 1.
</functionalspec>
<security>
See <xref type="rfc" data="rfc4143"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4143"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Kiyoshi_Toyoda"/>
<xref type="person" data="Dave_Crocker"/>
</requesters>
<additionalinfo>
<paragraph>
The URI Scheme is 'mailto' because facsimile is a
profile of standard Internet mail and uses standard
Internet mail addressing.
</paragraph>
</additionalinfo>
</record>4.11. im 💬
Last one in this batch, and it's a chat one 💜 The 'im:' URI doesn't name any one protocol for handling instant messages. Instead, the mechanism in RFC 3861 [4] is used to find out whether an IM protocol supported by the querying party is also supported by the target resource.
<record>
<!-- im -->
<class>Application-Based, Common</class>
<type>im</type>
<!-- No subtype -->
<urischeme>im</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified is an 'im:' URI. The 'im:' URI scheme
does not identify any particular protocol that will
be used to handle instant messaging receipt or
delivery, rather the mechanism in RFC 3861 [4] is
used to discover whether an IM protocol supported by
the party querying ENUM is also supported by the
target resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5028"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5028"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5028"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rohan_Mahy"/>
</requesters>
</record>4.12. mms:mailto 📨✨
<record>
<!-- mms:mailto -->
<class>Application-Based, Common</class>
<type>mms</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using an email protocol.
</paragraph>
<paragraph>
MMS messages are sent over SMTP using the format
specified by TS 23.140 [15] Section 8.4.4 and TS
26.140 [16] Section 4.
</paragraph>
<paragraph>
Within and between MMS Environments (MMSE,
network infrastructures that support the MultiMedia
Service), other pieces of state data (for example,
charging-significant information) are exchanged
between MMS Relay Servers. Thus, although these
servers use SMTP as the "bearer" for their
application exchanges, they map their internal state
to specialized header fields carried in the SMTP message
exchanges. The header fields used in such MMSE are
described in detail in [17].
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
<paragraph>
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of <xref type="rfc" data="rfc4355"/> apply.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
<additionalinfo>
<paragraph>
The MMS Architecture describes an interface
between the MMSE and "legacy messaging systems"
(labelled as MM3) that accepts "standard" SMTP
messages. Thus, although the MMS Relay Server that
supports this interface appears as a standard SMTP
server from the perspective of an Internet-based
mail server, it acts as a gateway and translator,
adding the internal state data that is used within
and between the MMS Environments. This mechanism is
described in [17], which also includes references to
the specifications agreed by those bodies
responsible for the design of the MMS.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</additionalinfo>
</record>4.13. mms:tel 📱💖
<record>
<!-- mms:tel -->
<class>Application-Based, Common</class>
<type>mms</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using the Multimedia
Messaging Service (MMS) [15].
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
<paragraph>
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of <xref type="rfc" data="rfc4355"/> apply.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
<additionalinfo>
<paragraph>
Note that MMS can be used as an alternative to
deliver an SMS RP-DATA RPDU if, for example, the
SMS bearer is not supported. If an entry includes
this Enumservice, then in effect this can be taken
as implying that the recipient is capable of
receiving EMS or SMS messages at this address. Such
choices on the end system design do have two small
caveats; whilst in practice all terminals supporting
MMS today support SMS as well, it might not
necessarily be the case in the future, and there may
be tariff differences in using the MMS rather than
using the SMS or EMS.
</paragraph>
</additionalinfo>
</record>4.14. pres 🌸
<record>
<!-- pres -->
<class>Application-Based, Common</class>
<type>pres</type>
<!-- No subtype -->
<urischeme>pres</urischeme>
<functionalspec>
See <xref type="rfc" data="rfc3953"/>, Section 4.
</functionalspec>
<security>
See <xref type="rfc" data="rfc3953"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc3953"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jon_Peterson"/>
</requesters>
<additionalinfo>
<paragraph>
See <xref type="rfc" data="rfc3953"/>, Section 3.
</paragraph>
</additionalinfo>
</record>4.15. pstn:sip ☎️🦋
<record>
<!-- pstn:sip -->
<class>Application-Based, Common</class>
<type>pstn</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
These Enumservices indicate that the
resource identified can be addressed by the
associated URI in order to initiate a
telecommunication session, which may include two-way
voice or other communications, to the PSTN.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4769"/>, Section 7.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4769"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Richard_Shockey"/>
</requesters>
<additionalinfo>
<paragraph>
A Number Portability Dip Indicator (npdi) should
be used in practice
(see <xref type="rfc" data="rfc4769"/>, Section 4).
</paragraph>
</additionalinfo>
</record>4.16. pstn:tel 🎀
<record>
<!-- pstn:tel -->
<class>Application-Based, Ancillary</class>
<type>pstn</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
These Enumservices indicate that the
resource identified can be addressed by the
associated URI in order to initiate a
telecommunication session, which may include two-way
voice or other communications, to the PSTN. These
URIs may contain number portability data as
specified in RFC4694 [10].
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4769"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4769"/>, Section 7.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4769"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Richard_Shockey"/>
</requesters>
<additionalinfo>
<paragraph>
A Number Portability Dip Indicator (npdi) should
be used in practice
(see <xref type="rfc" data="rfc4769"/>, Section 4).
</paragraph>
</additionalinfo>
</record>4.17. sip 🧚
<record>
<!-- sip -->
<class>Protocol-Based</class>
<type>sip</type>
<!-- No subtype -->
<urischeme>sip</urischeme>
<urischeme>sips</urischeme>
<functionalspec>
See <xref type="rfc" data="rfc3764"/>, Section 4.
</functionalspec>
<security>
See <xref type="rfc" data="rfc3764"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc3764"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jon_Peterson"/>
</requesters>
<additionalinfo>
<paragraph>
See <xref type="rfc" data="rfc3764"/>, Section 3.
</paragraph>
</additionalinfo>
</record>4.18. sms:mailto 💌
<record>
<!-- sms:mailto -->
<class>Application-Based, Common</class>
<type>sms</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using an email protocol.
</paragraph>
<paragraph>
SMS content is sent over SMTP using the format
specified by TS 23.140 [15] Section 8.4.4 and TS
26.140 [16] Section 4, as an MMS message. Within
such a message, SMS content is carried as either a
text or application/octet-stream MIME sub-part (see
TS 26.140 [16], Section 4.1)
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
<paragraph>
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of <xref type="rfc" data="rfc4355"/> apply.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>4.19. sms:tel ✨
okay bestie, this one is all about texting 📱💖 It's the SMS one: it says the resource behind the URI can receive a message over the Short Message Service [14]. The details live in RFC 4355, so no cap, go check that too 🎀
<record>
<!-- sms:tel -->
<class>Application-Based, Common</class>
<type>sms</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using the Short Message
Service (SMS) [14].
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4355"/>.
</paragraph>
</functionalspec>
<security>
<paragraph>
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of <xref type="rfc" data="rfc4355"/> apply.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>The security vibe here is chill 🫶 There are no specific security issues with this Enumservice, but the general considerations in Section 6 of [RFC4355] still apply, so don't skip them 💅
4.20. unifmsg:http 🦋
this one says the resource is a source of information 🌸 The kind of info can be all over the place, though. An 'http:' [11] URI usually gives you a document, and that doc can reference text, audio, video, executable code, or even video message files. So you can't be super specific about what you'll get, periodt 🙈
<record>
<!-- unifmsg:http -->
<class>Application-Based, Common</class>
<type>unifmsg</type>
<subtype>http</subtype>
<urischeme>http</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified by
the associated URI scheme is capable of being a source of
information.
</paragraph>
<paragraph>
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'http:' [11] URI
provides a document. This document can contain references
that will trigger the download of many different kinds of
information, such as text, audio, video, executable code, or
even video message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5278"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>Security-wise, see Section 3 of [RFC5278] 🔐 And if you're implementing this, the non-exclusive list of examples in Section 7 of [RFC5278] is worth a look ✨
4.21. unifmsg:https 🔥
same energy as the http one, just with TLS or the Secure Socket Layer protocol in the mix 🔐 The resource is a source of information that you can reach over that secure connection. Like the http version, one 'https:' [12] URI usually gives you a document, which can pull in all kinds of media, so the expected info is kinda wide open 🌈
<record>
<!-- unifmsg:https -->
<class>Application-Based, Common</class>
<type>unifmsg</type>
<subtype>https</subtype>
<urischeme>https</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified by
the associated URI scheme is capable of being a source of
information, which can be contacted using TLS or the Secure
Socket Layer protocol.
</paragraph>
<paragraph>
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'https:' [12] URI
provides a document. This document can contain references
that will trigger the download of many different kinds of
information, such as text, audio, video, executable code, or
even video message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5278"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.22. unifmsg:sip 🌟
this is the SIP one 📞 It says the resource can be addressed with the sip URI scheme so you can start a unified communication session with a unified messaging system. Serious connection energy 💜
<record>
<!-- unifmsg:sip -->
<class>Application-Based, Common</class>
<type>unifmsg</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a unified communication session to a unified
messaging system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.23. unifmsg:sips 🎀
the secure cousin of the one above 🔒 Same deal: the resource can be addressed with the sips URI scheme to start a unified communication session with a unified messaging system ✨
<record>
<!-- unifmsg:sips -->
<class>Application-Based, Common</class>
<type>unifmsg</type>
<subtype>sips</subtype>
<urischeme>sips</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a unified communication session to a unified
messaging system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.24. vcard 💅
this one is a Data Type-Based record 🧚 It says the resource is a plain vCard (according to RFC2426) that you can grab over HTTP or HTTPS [7]. Clients fetching it should expect the access to be restricted, and what they can understand may depend on who they are 🙈 Go check Section 5 of [RFC4969] for the security stuff 🫶
<record>
<!-- vcard -->
<class>Data Type-Based</class>
<type>vcard</type>
<!-- No subtype -->
<urischeme>http</urischeme>
<urischeme>https</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified is a plain vCard, according to RFC2426,
which may be accessed using HTTP / HTTPS [7].
</paragraph>
<paragraph>
Clients fetching the vCard from the resource
indicated should expect access to be
restricted. Additionally, the comprehension of the
data provided may vary depending on the client's
identity.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4969"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4969"/>, Section 5.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4969"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Alexander_Mayrhofer"/>
</requesters>
</record>4.25. videomsg:http 🌈
last one in this batch! 🎬 This is the video twin of unifmsg:http. The resource is a source of information, and contacting an 'http:' [11] URI usually gives you a document that can reference all sorts of stuff, including video message files. So once again, you can't be super specific about what to expect ⭐
<record>
<!-- videomsg:http -->
<class>Application-Based, Common</class>
<type>videomsg</type>
<subtype>http</subtype>
<urischeme>http</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified by
the associated URI scheme is capable of being a source of
information.
</paragraph>
<paragraph>
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'http:' [11] URI
provides a document. This document can contain references
that will trigger the download of many different kinds of
information, such as text, audio, video, executable code, or
even video message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5278"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.26. videomsg:https 🎬
okay bestie, this one's the secure version of the video message one 🔒✨
<record>
<!-- videomsg:https -->
<class>Application-Based, Common</class>
<type>videomsg</type>
<subtype>https</subtype>
<urischeme>https</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified by
the associated URI scheme is capable of being a source of
information, which can be contacted using TLS or the Secure
Socket Layer protocol.
</paragraph>
<paragraph>
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'https:' [12] URI
provides a document. This document can contain references
that will trigger the download of many different kinds of
information, such as text, audio, video, executable code, or
even video message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5278"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>so the vibe here is: the resource is reachable over TLS (aka the Secure Socket Layer protocol, the 🔐 one), and a plain https: document can totally pull in video message files plus a whole buffet of other stuff. Literally anything. So nobody can promise what you'll get back 💀
4.27. videomsg:sip 📞
this one is the SIP version. Same family, different door 🚪
<record>
<!-- videomsg:sip -->
<class>Application-Based, Common</class>
<type>videomsg</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a video communication session to a video messaging
system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>the gist: you can address the resource with a sip URI and kick off a video session with a video messaging system. Iconic 🎥💅
4.28. videomsg:sips 🔐
and this is the sips twin 👯♀️ same job, but the secure SIP scheme. Okay, I'm obsessed with how consistent these all are
<record>
<!-- videomsg:sips -->
<class>Application-Based, Common</class>
<type>videomsg</type>
<subtype>sips</subtype>
<urischeme>sips</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a video communication session to a video messaging
system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.29. voice:tel ☎️
ooh, now we're talking about actual phone calls 📱🧡 this is the "Interactive Voice" one, so picture a real back-and-forth conversation with audio flowing both ways. Main character energy fr
<record>
<!-- voice:tel -->
<class>Application-Based, Common</class>
<type>voice</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
The kind of communication indicated by this
Enumservice is "Interactive Voice". From a protocol
perspective, this communication is expected to
involve bidirectional media streams carrying audio
data.
</paragraph>
<paragraph>
A client may imply that the person controlling
population of a NAPTR holding this Enumservice
indicates their capability to engage in an
interactive voice session when contacted using the
URI generated by this NAPTR.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4415"/>, Section 5.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4415"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
<additionalinfo>
<paragraph>
This Enumservice indicates that the person
responsible for the NAPTR is accessible via the PSTN
(Public Switched Telephone Network) or PLMN (Public
Land Mobile Network) using the value of the
generated URI.
</paragraph>
<paragraph>The kind of subsystem required to initiate a
Voice Enumservice with this Subtype is a "Dialler".
This is a subsystem that either provides a local
connection to the PSTN or PLMN, or that provides an
indirect connection to those networks. The
subsystem will use the telephone number held in the
generated URI to place a voice call. The voice call
is placed to a network that uses E.164 numbers to
route calls to an appropriate destination.
</paragraph>
<paragraph>
Note that the PSTN/PLMN connection may be
indirect. The end user receiving this NAPTR may
have a relationship with a Communications Service
Provider that accepts call initiation requests from
that subsystem using an IP-based protocol such as
SIP or H.323, and places the call to the PSTN using
a remote gateway service. In this case, the Provider
may either accept requests using "tel:" URIs or has
a defined mechanism to convert "tel:" URI values
into a "protocol-native" form.
</paragraph>
<paragraph>
The "tel:" URI value SHOULD be fully qualified
(using the "global phone number" form of RFC 3966
[10]). A "local phone number" as defined in that
document SHOULD NOT be used unless the controller of
the zone in which the NAPTR appears is sure that it
can be distinguished unambiguously by all clients
that can access the resource record and that a call
from their network access points can be routed to
that destination.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc4415"/>.
</paragraph>
</additionalinfo>
</record>the Dialler is the subsystem that actually places the call over the PSTN or PLMN, using the number in the generated URI 📞 It's either wired straight into the phone network or reaches it indirectly. Also, the number should be the full "global phone number" form from RFC 3966, because local numbers are only safe if everyone who can see the record can tell which one is meant 🌍
4.30. voicemsg:http 🎙️
and now the voice message version over plain http, bestie 🎧 same deal as videomsg:http, but for audio files
<record>
<!-- voicemsg:http -->
<class>Application-Based, Common</class>
<type>voicemsg</type>
<subtype>http</subtype>
<urischeme>http</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified by
the associated URI scheme is capable of being a source of
information.
</paragraph>
<paragraph>
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'http:' [11] URI
provides a document. This document can contain references
that will trigger the download of many different kinds of
information, such as text, audio, video, executable code, or
even voice message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5278"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.31. voicemsg:https 🔒
last one in this batch, and it's the secure one 🌈✨ Same info, just wrapped in TLS, and it's giving consistency
<record>
<!-- voicemsg:https -->
<class>Application-Based, Common</class>
<type>voicemsg</type>
<subtype>https</subtype>
<urischeme>https</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified by
the associated URI scheme is capable of being a source of
information, which can be contacted using TLS or the Secure
Socket Layer protocol.
</paragraph>
<paragraph>
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'https:' [12] URI
provides a document. This document can contain references
that will trigger the download of many different kinds of
information, such as text, audio, video, executable code, or
even voice message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
</paragraph>
<paragraph>
References are contained in <xref type="rfc" data="rfc5278"/>.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>4.32. voicemsg:sip 🎀
<record>
<!-- voicemsg:sip -->
<class>Application-Based, Common</class>
<type>voicemsg</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a voice communication session to a voice messaging
system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>okay so voicemsg:sip is giving SIP vibes 📞✨ the record says it's for reaching a voice messaging system through the sip URI scheme, so you can start a voice session with it. The security pointer sends you to RFC 5278, Section 3, and the examples live in Section 7 of that same doc, so go peek at them bestie 🫶
4.33. voicemsg:sips 🔐
<record>
<!-- voicemsg:sips -->
<class>Application-Based, Common</class>
<type>voicemsg</type>
<subtype>sips</subtype>
<urischeme>sips</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a voice communication session to a voice messaging
system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>this is the sips twin of the one above 👯♀️ same class, same purpose, same security pointer, and the only difference is the scheme, which is sips instead of sip. Same examples, same RFC 5278 vibes 💜
4.34. voicemsg:tel 📱
<record>
<!-- voicemsg:tel -->
<class>Application-Based, Common</class>
<type>voicemsg</type>
<subtype>tel</subtype>
<urischeme>tel</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource identified can
be addressed by the associated URI scheme in order to
initiate a voice communication session to a voice messaging
system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc5278"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Don_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of examples
in Section 7 of <xref type="rfc" data="rfc5278"/>.
</paragraph>
</additionalinfo>
</record>same story but with the tel scheme 📞 it's the voicemail trio finale, all three sharing one purpose and one security pointer. Ngl the repetition is kind of iconic 💅
4.35. vpim:ldap 📇
<record>
<!-- vpim:ldap -->
<class>Data Type-Based</class>
<type>vpim</type>
<subtype>ldap</subtype>
<urischeme>ldap</urischeme>
<functionalspec>
See <xref type="rfc" data="rfc4238"/>, Section 3.2 - 3.3.
</functionalspec>
<security>
<paragraph>
Malicious Redirection:
One of the fundamental dangers related to any
service such as this is that a malicious entry in a
resolver's database will cause clients to resolve
the E.164 into the wrong LDAP URI. The possible
intent may be to cause the client to connect to a
rogue LDAP server and retrieve (or fail to retrieve)
a resource containing fraudulent or damaging
information.
</paragraph>
<paragraph>
Denial of Service:
By removing the URI to which the E.164 maps, a
malicious intruder may remove the client's ability
to access the LDAP directory server.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4238"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Greg_Vaudreuil"/>
</requesters>
</record>okay this one is a directory moment 🗂️ it's a Data Type-Based record for ldap, and the functional details are in RFC 4238, Sections 3.2 to 3.3. Now the security part is the spicy bit 😭 The first danger is malicious redirection: if someone sneaks a bad entry into a resolver's database, clients get sent from the E.164 number to the wrong LDAP URI. That could mean connecting to a rogue LDAP server and pulling back a resource that's fraudulent or damaging, or failing to get one at all. The second is denial of service, because if the URI the E.164 maps to gets removed, a sneaky intruder can cut the client off from the LDAP directory server. Yikes, protect your resolver bestie 🙈
4.36. vpim:mailto 📧
<record>
<!-- vpim:mailto -->
<class>Data Type-Based</class>
<type>vpim</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
See <xref type="rfc" data="rfc4238"/>, Section 4.2 - 4.4.
</functionalspec>
<security>
<paragraph>
Malicious Redirection:
One of the fundamental dangers related to any
service such as this is that a malicious entry in a
resolver's database will cause clients to resolve
the E.164 into the wrong email URI. The possible
intent may be to cause the client to send the
information to an incorrect destination.
</paragraph>
<paragraph>
Denial of Service:
By removing the URI to which the E.164 maps, a
malicious intruder may remove the client's ability
to access the resource.
</paragraph>
<paragraph>
Unsolicited Bulk Email:
The exposure of email addresses through the ENUM
service provides a bulk mailer access to large
numbers of email addresses where only the telephone
number was previously known.
</paragraph>
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4238"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Greg_Vaudreuil"/>
</requesters>
<additionalinfo>
<paragraph>
Error Conditions:
</paragraph>
<paragraph>
E.164 number not in the numbering plan
</paragraph>
<paragraph>
E.164 number in the numbering plan, but no
URIs exist for that number
</paragraph>
<paragraph>
E2U+vpim:mailto Service unavailable of email
addresses where only the telephone number was
previously known.
</paragraph>
</additionalinfo>
</record>the mailto version is the email cousin 💌 It's Data Type-Based, the functional details are in RFC 4238, Sections 4.2 to 4.4, and it's got three security worries. Malicious redirection means a bad resolver entry could send clients from the E.164 number to the wrong email URI, so the information ends up going to an incorrect destination. Denial of service is the same as before, where removing the mapped URI stops clients from reaching the resource. Then there's unsolicited bulk email, which is the big one 📬 because exposing email addresses through ENUM gives bulk mailers access to lots of addresses that used to be known only by phone number. The additional info lists error conditions too: a number that isn't in the numbering plan, a number that is in the plan but has no URIs, and the E2U+vpim:mailto service being unavailable for email addresses that were only ever known by phone number 🫠
4.37. web:http 🌐
<record>
<!-- web:http -->
<class>Application-Based, Common</class>
<type>web</type>
<subtype>http</subtype>
<urischeme>http</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of being a source of information. It has to be
noted that the kind of information retrieved can be
manifold. Usually, contacting a resource by an
"http:" URI provides a document. This document can
contain references that will trigger download of
many different kinds of information, like audio or
video or executable code. Thus, one cannot be more
specific about the kind of information that can be
expected when contacting the resource.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4002"/>, Section 5.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4002"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>web:http is the classic one 🕸️ The record says the resource behind the URI can be a source of information, and the kind of info is a total mystery. An http: URI usually gives you a document, and that document can point to all sorts of stuff, like audio, video, or executable code 👀 so you genuinely can't predict what you'll get. The security pointer goes to RFC 4002, Section 5.
4.38. web:https 🔒
<record>
<!-- web:https -->
<class>Application-Based, Common</class>
<type>web</type>
<subtype>https</subtype>
<urischeme>https</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified by the associated URI is capable
of being a source of information, which can be
contacted by using TLS or the Secure Socket Layer
protocol. It has to be noted that the kind of
information retrieved can be manifold. Usually,
contacting a resource by an "https:" URI provides a
document. This document can contain all different
kinds of information, like audio or video or
executable code. Thus, one cannot be more specific
what information to expect when contacting the
resource.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4002"/>, Section 5.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4002"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Rudolf_Brandner"/>
<xref type="person" data="Lawrence_Conroy"/>
<xref type="person" data="Richard_Stastny"/>
</requesters>
</record>the secure sibling 🔐 Same source-of-information idea, but this one says you contact the resource using TLS or the Secure Socket Layer protocol. Like the http one, an https: URI usually hands you a document, and that document can carry every kind of info, from audio and video to executable code, so you still can't be sure what's coming. Security pointer is the same: RFC 4002, Section 5 ✨
4.39. xmpp 💬
<record>
<!-- xmpp -->
<class>Protocol-Based</class>
<type>xmpp</type>
<!-- No subtype -->
<urischeme>xmpp</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified is an XMPP entity.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4979"/> (updated by RFC 6118)
<xref type="rfc" data="RFC 6118"/>
</registrationdocs>
<requesters>
<xref type="person" data="Alexander_Mayrhofer"/>
</requesters>
</record>last record of the bunch and it's a Protocol-Based one 🧚 It's just the xmpp type with no subtype, and it says the resource is an XMPP entity. The security details are in RFC 4979, Section 6, and the requester is Alexander Mayrhofer.
5. IANA Considerations 🏷️
Okay so IANA swapped out every legacy Enumservice Registration, and it did that following Section 4 💅
6. Security Considerations 🛡️
Since this document doesn't introduce any technology or protocol, there are no security issues to be considered for this document itself. Bestie, that's a relief 🫶
7. Acknowledgements 💜
The authors want to give a huge shoutout to these people, who gave feedback or made significant contributions to this document: Jari Arkko, Scott Bradner, Gonzalo Camarillo, Alfred Hoenes, Ari Keranen, and Alexey Melnikov 🌸
8. References ✨
8.1. Normative References ✨
okay bestie, these are the receipts the rest of the doc leans on 🧾💅 every single one is listed below, exactly as written 🫶
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3762] Levin, O., "Telephone Number Mapping (ENUM) Service
Registration for H.323", RFC 3762, April 2004.
[RFC3764] Peterson, J., "enumservice registration for Session
Initiation Protocol (SIP) Addresses-of-Record", RFC 3764,
April 2004.
[RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service
Registration for Presence Services", RFC 3953,
January 2005.
[RFC4002] Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservice 'web' and 'ft'", RFC 4002,
February 2005.
[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail
(IFAX) Service of ENUM", RFC 4143, November 2005.
[RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238,
October 2005.
[RFC4355] Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservices email, fax, mms, ems, and
sms", RFC 4355, January 2006.
[RFC4415] Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservice Voice", RFC 4415,
February 2006.
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network
(PSTN) Signaling Information", RFC 4769, November 2006.
[RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice",
RFC 4969, August 2007.
[RFC4979] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'",
RFC 4979, August 2007.
[RFC5028] Mahy, R., "A Telephone Number Mapping (ENUM) Service
Registration for Instant Messaging (IM) Services",
RFC 5028, October 2007.
[RFC5278] Livingood, J. and D. Troshynski, "IANA Registration of
Enumservices for Voice and Video Messaging", RFC 5278,
July 2008.
[RFC5333] Mahy, R. and B. Hoeneisen, "IANA Registration of
Enumservices for Internet Calendaring", RFC 5333,
October 2009.
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA
Considerations", RFC 6117, March 2011.8.2. Informative References 🦋
these ones are just extra reading, the vibe check for IANA Considerations 🧚
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.Appendix A. Former Content of the IANA Repository 🌈
okay this is the old IANA registry dump, the full tea ☕ it was last updated on 2009-10-13 and it's giving very vintage 📼
Enumservice Registrations
(last updated 2009-10-13)
Registries included below:
- Enumservice Registrations
Registry Name: Enumservice Registrations
Reference: [RFC3761]
Registration Procedures: Require an RFC approved by the IESG
Note:
Enumservice specifications contain the functional specification (i.e.
what it can be used for), the valid protocols, and the URI schemes
that may be returned.
Registry:
Service Name: "H323"
URI Scheme(s): "h323:"
Functional Specification:
See Section "3. The E2U+H323 ENUM Service" of [RFC3762]
Security considerations:
see section "5. Security Considerations" of [RFC3762]
Intended usage: COMMON
Author: Orit Levin
[RFC3762]
Service Name: "SIP"
Type(s): "SIP"
Subtype(s): N/A
URI Scheme(s): "sip", "sips:"
Functional Specification: see Section 4 of [RFC3764]
Security considerations: see Section 6 of [RFC3764]
Intended usage: COMMON
Author: Jon Peterson (jon.peterson&neustar.biz)
Any other information that the author deems interesting:
see Section 3 of [RFC3764]
[RFC3764]
Service Name: "ifax"
Type: "ifax"
Subtype: "mailto"
URI Scheme: "mailto"
The URI Scheme is "mailto" because facsimile is a profile of
standard Internet mail and uses standard Internet mail
addressing.
Functional Specification: see section 1 of [RFC4143]
Security Considerations: see section 3 of [RFC4143]
Intended usage: COMMON
Author: Kiyoshi Toyoda(toyoda.kiyoshi&jp.panasonic.com)
Dave Crocker(dcrocker&brandenburg.com)
[RFC4143]
Service Name: "pres"
URI Scheme(s): "pres:"
Functional Specification: see Section 4 of [RFC3953]
Security considerations: see Section 6 of [RFC3953]
Intended usage: COMMON
Author: Jon Peterson (jon.peterson&neustar.biz)
Any other information that the author deems interesting:
See Section 3 of [RFC3953]
[RFC3953]
Service Name: "web"
Type: "web"
Subtype: "http"
URI Scheme: 'http:'
Functional Specification:
This ENUMservice indicates that the resource identified by the
associated URI scheme is capable of being a source of
information. It has to be noted that the kind of information
retrieved can be manifold. Usually, contacting a resource by an
'http:' URI provides a document. This document can contain
references that will trigger download of many different kinds
of information, like audio or video or executable code. Thus,
one can not be more specific about the kind of information that
can be expected when contacting the resource.
Security Considerations:
See section 5 of [RFC4002].
Intended Usage: COMMON
Authors:
Rudolf Brandner (rudolf.brandner&siemens.com)
Lawrence Conroy (lwc&roke.co.uk)
Richard Stastny (richard.stastny&oefeg.at)
Any other information the author deems interesting: None
[RFC4002]
Service Name: "web"
Type: "web"
Subtype: "https"
URI Scheme: 'https:'
Functional Specification:
This ENUMservice indicates that the resource identified by the
associated URI scheme is capable of being a source of
information, which can be contacted by using TLS or Secure
Socket Layer protocol. It has to be noted that the kind of
information retrieved can be manifold. Usually, contacting a
resource by an 'https:' URI provides a document. This document
can contain all different kind of information, like audio or
video or executable code. Thus, one can not be more specific
what information to expect when contacting the resource.
Security Considerations:
See section 5 of [RFC4002].
Intended Usage: COMMON
Authors:
Rudolf Brandner (rudolf.brandner&siemens.com)
Lawrence Conroy (lwc&roke.co.uk)
Richard Stastny (richard.stastny&oefeg.at)
Any other information the author deems interesting: None
[RFC4002]
Service Name: "ft"
Type: "ft"
Subtype: "ftp"
URI Scheme: 'ftp:'
Functional Specification:
This ENUMservice indicates that the resource identified by the
associated URI scheme is a file service from which a file or
file listing can be retrieved.
Security Considerations:
See section 5 of [RFC4002].
Intended Usage: COMMON
Authors:
Rudolf Brandner (rudolf.brandner&siemens.com)
Lawrence Conroy (lwc&roke.co.uk)
Richard Stastny (richard.stastny&oefeg.at)
Any other information the author deems interesting: None
[RFC4002]
Enumservice Name: "email"
Enumservice Type: "email"
Enumservice Subtype: "mailto"
URI Scheme: 'mailto:'
Functional Specification:
This Enumservice indicates that the remote resource can be
addressed by the associated URI scheme in order to send an
email.
Security Considerations:
See Section 6 of [RFC4355]
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
None
Enumservice Name: "fax"
Enumservice Type: "fax"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of being contacted to provide
a communication session during which facsimile documents can be
sent.
A client selecting this NAPTR will have support for generating
and sending facsimile documents to the recipient using the PSTN
session and transfer protocols specified in [12] and [13] in
[RFC4355] - in short, they will have a fax
program with a local or shared PSTN access over which they can
send faxes.
Security Considerations:
See Section 6 of [RFC4355]
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
None
Enumservice Name: "sms"
Enumservice Type: "sms"
Enumservice Subtypes: "tel"
URI Scheme: 'tel:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of receiving a message using
the Short Message Service (SMS) [14] in [RFC4355].
Security Considerations:
There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 apply.
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
None
Enumservice Name: "sms"
Enumservice Type: "sms"
Enumservice Subtypes: "mailto"
URI Scheme: 'mailto:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of receiving a message using
an email protocol.
SMS content is sent over SMTP using the format specified by TS
23.140 [15] section 8.4.4 and TS 26.140 [16] section 4 (for
references see [RFC4355]), as an MMS message. Within such a
message, SMS content is carried as either a text or
application/octet-stream MIME sub-part (see TS 26.140 [16] ,
section 4.1)
For references see [RFC4355].
Security Considerations:
There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 apply, see
[RFC4355].
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
NoneOkay bestie, the registry entries are where things get really spicy 🌸 Every one of these is a NAPTR registration, so the exact wording matters. I'm keeping each block word for word and wrapping the vibes around it 💅
First up is the "ems" Enumservice for the tel: scheme. 💖
Enumservice Name: "ems"
Enumservice Type: "ems"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of receiving a message using
the Enhanced Message Service (EMS) [14] (For reference see
[RFC4355]).
Security Considerations:
There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 apply.
See [RFC4355]
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
Note that an indication of EMS can be taken as implying that
the recipient is capable of receiving SMS messages at this
address as well.Lowkey the best part here is that EMS quietly implies SMS too 🫶 If a number says it can take EMS, it can take SMS as well. Main character behaviour ✨
Next is the same "ems" name, but this time with the mailto: scheme 📬
Enumservice Name: "ems"
Enumservice Type: "ems"
Enumservice Subtypes: "mailto"
URI Scheme: 'mailto:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of receiving a message using
an email protocol.
EMS content is sent over SMTP using the format specified by TS
23.140 [15] section 8.4.4 and TS 26.140 [16] section 4, as an
MMS message. Within such a message, EMS content is carried as
either a text or application/octet-stream MIME sub-part (see
TS 26.140 [16] , section 4.1).
For references see [RFC4355]
Security Considerations:
There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
NoneOkay so this one is giving "EMS goes over email, but it's still wrapped up as an MMS message" 😭 The content rides along inside SMTP like a fancy envelope, with a text or application/octet-stream MIME sub-part holding the actual message 💌
Now the "mms" name with tel: 📱
Enumservice Name: "mms"
Enumservice Type: "mms"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of receiving a message using
the Multimedia Messaging Service (MMS) [15].
For references see [RFC4355]
Security Considerations:
There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
Note that MMS can be used as an alternative to deliver an SMS
RP-DATA RPDU if, for example, the SMS bearer is not supported.
If an entry includes this Enumservice, then in effect this can
be taken as implying that the recipient is capable of receiving
EMS or SMS messages at this address. Such choices on the end
system design do have two small caveats; whilst in practice all
terminals supporting MMS today support SMS as well, it might
not necessarily be the case in the future, and there may be
tariff differences in using the MMS rather than using the SMS
or EMS.Here's the tea ☕ MMS can stand in for an SMS RP-DATA RPDU when SMS isn't supported, and it implies the recipient can take EMS or SMS. The two caveats are real: terminals do support both today, but that might not last, and the tariffs can be different too 💀
Now "mms" with mailto: 💜
Enumservice Name: "mms"
Enumservice Type: "mms"
Enumservice Subtypes: "mailto"
URI Scheme: 'mailto:'
Functional Specification:
This Enumservice indicates that the resource identified by the
associated URI scheme is capable of receiving a message using
an email protocol.
MMS messages are sent over SMTP using the format specified by
TS 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4.
Within and between MMS Environments (MMSE, network
infrastructures that support the MultiMedia Service), other
pieces of state data (for example, charging-significant
information) are exchanged between MMS Relay Servers. Thus,
although these servers use SMTP as the "bearer" for their
application exchanges, they map their internal state to
specialised headers carried in the SMTP message exchanges.
The headers used in such MMSE are described in detail in [17].
For references see [RFC4355]
Security Considerations:
There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
Intended Usage: COMMON
Authors:
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
contact detail see [RFC4355])
Any other information the author deems interesting:
The MMS Architecture describes an interface between the MMSE and
"legacy messaging systems" (labelled as MM3) which accepts
"standard" SMTP messages. Thus although the MMS Relay Server
that supports this interface appears as a standard SMTP server
from the perspective of an Internet-based mail server, it acts
as a gateway and translator, adding the internal state data that
is used within and between the MMS Environments. This mechanism
is described in [17], which also includes references to the
specifications agreed by those bodies responsible for the design
of the MMS.Okay so the MMS Relay Server is giving "I look like a normal SMTP server, but secretly I'm a gateway and translator" 🦋 It stuffs the internal state data into specialised headers, and the MM3 interface is what makes it all work with legacy messaging systems 🫣
Next up is the VPIM mailto service, which is a service name and not an Enumservice 📧
Service Name: E.164 to VPIM MailTo: URL
URI Type: "Mailto:"
Type: VPIM
Subtype: MAILTO
Functional Specification: See section 4.2 through 4.4 of [RFC4238]
Intended Usage: COMMON
Author: Greg Vaudreuil (gregv&ieee.org)
Error Conditions:
o E.164 number not in the numbering plan
o E.164 number in the numbering plan, but no URLs exist for that
number
o E2U+VPIM:Mailto Service unavailable
Security Considerations:
o Malicious Redirection
One of the fundamental dangers related to any service such as
this is that a malicious entry in a resolver's database will
cause clients to resolve the E.164 into the wrong email URL.
The possible intent may be to cause the client to send the
information to an incorrect destination.
o Denial of Service
By removing the URL to which the E.164 maps, a malicious
intruder may remove the client's ability to access the
resource.
o Unsolicited Bulk Email
The exposure of email addresses through the ENUM
service provides a bulk mailer access to large numbers
of email addresses where only the telephone number was
previously known.Security alert 🚨 A malicious entry in a resolver's database can point clients at the wrong email URL, and removing the URL can cut a client off completely. Exposing email addresses through ENUM can also hand bulk mailers a huge list of addresses when they only had phone numbers before. Scary stuff, bestie 😭
Now the VPIM LDAP one 🗂️
Service Name: E.164 to VPIM LDAP URL
URI Type: "LDAP:"
Type: VPIM
Subtype: LDAP
Functional Specification: See section 3.2 through 3.3 of [RFC4238]
Intended Usage: COMMON
Author: Greg Vaudreuil (gregv&ieee.org)
Security Considerations:
o Malicious Redirection
One of the fundamental dangers related to any service
such as this is that a malicious entry in a resolver's
database will cause clients to resolve the E.164 into
the wrong LDAP URL. The possible intent may be to cause
the client to connect to a rogue LDAP server and
retrieve (or fail to retrieve) a resource containing
fraudulent or damaging information.
o Denial of Service
By removing the URL to which the E.164 maps, a
malicious intruder may remove the client's ability to
access the LDAP directory server.It's the same drama with a different sidekick 🎭 A poisoned resolver entry could send clients to a rogue LDAP server, which could hand back fraudulent or damaging info, or just nothing at all. Deleting the mapping cuts off access to the directory server 🙈
Next is the "voice" Enumservice 🎙️ This one has the most rules, so pay attention 👑
Enumservice Name: "voice"
Enumservice Type: "voice"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
Functional Specification:
The kind of communication indicated by this Enumservice is
"Interactive Voice". From a protocol perspective, this
communication is expected to involve bidirectional media streams
carrying audio data.
A client may imply that the person controlling population of a
NAPTR holding this Enumservice indicates their capability to
engage in an interactive voice session when contacted using the
URI generated by this NAPTR.
Security Considerations:
See Section 5 of [RFC4415]
Intended Usage: COMMON
Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for
author contact detail see Authors' Addresses section)
Any other information the author deems interesting:
o This Enumservice indicates that the person responsible for the
NAPTR is accessible via the PSTN (Public Switched Telephone
Network) or PLMN (Public Land Mobile Network) using the value of
the generated URI.
o The kind of subsystem required to initiate a Voice Enumservice
with this sub-type is a "Dialler". This is a subsystem that
either provides a local connection to the PSTN or PLMN, or that
provides an indirect connection to those networks. The
subsystem will use the telephone number held in the generated
URI to place a voice call. The voice call is placed to a
network that uses E.164 numbers to route calls to an appropriate
destination.
o Note that the PSTN/PLMN connection may be indirect. The end
user receiving this NAPTR may have a relationship with a
Communications Service Provider that accepts call initiation
requests from that subsystem using an IP-based protocol such as
SIP or H.323, and places the call to the PSTN using a remote
gateway service. In this case the Provider may either accept
requests using "tel:" URIs or has a defined mechanism to convert
"tel:" URI values into a "protocol-native" form.
o The "tel:" URI value SHOULD be fully qualified (using the
"global phone number" form of RFC3966 [10]). A "local phone
number" as defined in that document SHOULD NOT be used unless
the controller of the zone in which the NAPTR appears is sure
that it can be distinguished unambiguously by all clients that
can access the resource record and that a call from their
network access points can be routed to that destination.So for voice, the person behind the NAPTR can be reached over the PSTN or PLMN, and a "Dialler" subsystem does the calling 📞 The tel: value should be the fully qualified "global phone number" from RFC3966 🌍 Local numbers should be avoided unless the zone controller is totally sure every client can tell which number is meant and can route the call 🫶
Next up is the "pstn" Enumservice with tel: 🏠
Enumservice Name: "pstn"
Enumservice Type: "pstn"
Enumservice Subtype: "tel"
URI Scheme: 'tel:'
Functional Specification:
These Enumservices indicate that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a telecommunication session, which may include two-way
voice or other communications, to the PSTN. These URIs may
contain number portability data as specified in RFC 4694 [10].
Security Considerations: See Section 7 of [RFC4769].
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Richard Shockey (richard.shockey&neustar.biz)
Any other information the author deems interesting:
A Number Portability Dip Indicator (npdi) should be used in
practice (see examples below in Section 4 of [RFC4769]).Okay so these tel: URIs can carry number portability data from RFC 4694 📇 Also, a Number Portability Dip Indicator (npdi) should be used in practice, and the examples are in Section 4 of [RFC4769] 🧚
Last one, the "pstn" Enumservice with sip: 💅
Enumservice Name: "pstn"
Enumservice Type: "pstn"
Enumservice Subtype: "sip"
URI Scheme: 'sip:'
Functional Specification:
These Enumservices indicate that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a telecommunication session, which may include two-way
voice or other communications, to the PSTN.
Security Considerations: See Section 7 of [RFC4769].
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Richard Shockey (richard.shockey&neustar.biz)
Any other information the author deems interesting:
A Number Portability Dip Indicator (npdi) should be used in
practice (see examples below in Section 4 of [RFC4769]).Same vibe as the tel: one, just through sip: instead 🦋 The npdi advice and the Section 4 examples of [RFC4769] carry over too, so it's the same energy with a different scheme 🌈
vCard 💌 okay bestie, this one's a whole vibe. It's an Enumservice for a plain vCard (the RFC 2426 kind), and you grab it over HTTP/ HTTPS [7] 🎀
Enumservice Name: "vCard"
Enumservice Name: "vCard"
Enumservice Type: "vcard"
Enumservice Subtype: n/a
URI Schemes: "http", "https"
Security Considerations: see Section 5 [RFC4969]
Intended Usage: COMMON
Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at>So the resource is a plain vCard, and clients fetching it should expect access to be restricted 🔒 Also, what you get back can depend on who you are, so the same fetch might show different data to different clients ✨
XMPP 🦋 this one is simple and iconic: the resource is an XMPP entity 💜
Enumservice Name: "XMPP"
Enumservice Type: "xmpp"
Enumservice Subtype: n/a
URI Schemes: "xmpp"
Security Considerations: see Section 6 of [RFC4979]
Intended Usage: COMMON
Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at>im 💬 the im: URI scheme doesn't pick a specific protocol for handling instant message delivery. Instead, the mechanism in RFC 3861 [4] is used to figure out whether an IM protocol that the querying ENUM party supports is also supported by the target resource. Main character energy, no cap 👑
Enumservice Name: "im"
Enumservice Type: "im"
Enumservice Subtypes: N/A
URI scheme(s): "im:"
Security considerations: See section 3 of [RFC5028]
Intended usage: COMMON
Author: Rohan Mahy (rohan&ekabal.com)voicemsg, sip 📞 the remote resource can be reached through the sip: scheme so you can start a voice communication session with a voice messaging system. Super useful, ngl 🫶
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtypes: "sip"
URI Schemes: 'sip:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]voicemsg, sips 🔐 same energy as the sip: one, just over the secure sips: scheme. Still a voice session with a voice messaging system, periodt ✨
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtypes: "sips"
URI Schemes: 'sips:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]voicemsg, tel ☎️ the tel: scheme gets you to a voice messaging system too, through a voice communication session 🌸
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtype: "tel"
URI Schemes: 'tel:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]voicemsg, http 🌐 this one's a little different. The resource can be a source of information, and it's giving "anything could come back" 🙈 Contacting an 'http:' [11] URI usually gives you a document, and that document can link to all kinds of stuff: text, audio, video, executable code, or even voice message files. So you can't get too specific about what kind of info to expect 💅
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtype: "http"
URI Schemes: 'http:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]voicemsg, https 🔒 same story as the http: one, but this resource is reached over TLS or the Secure Socket Layer protocol. Same chaotic-document energy, and same "you can't be too specific" vibe 🫶
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtype: "https"
URI Schemes: 'https:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]videomsg, sip 🎥 okay, same vibe as the voice one, except it's a video communication session with a video messaging system 🦋
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
Enumservice Subtypes: "sip"
URI Schemes: 'sip:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]videomsg, sips 🔐 the secure version of the video one. You reach the video messaging system with a video communication session, just over sips: 🌈
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
Enumservice Subtypes: "sips"
URI Schemes: 'sips:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]videomsg, http 🎞️ the resource is a source of information, and contacting an 'http:' [11] URI usually gives you a document. That document can pull in text, audio, video, executable code, or even video message files, so you can't pin down the kind of info ahead of time 🙈
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
Enumservice Subtype: "http"
URI Schemes: 'http:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]videomsg, https 🔒 the TLS or Secure Socket Layer version of the one above. Same documents-that-link-to-everything situation, with video message files in the mix 💜
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
Enumservice Subtype: "https"
URI Schemes: 'https:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]unifmsg, sip 📬 the unified messaging one! The remote resource can be reached via sip: to start a unified communication session with a unified messaging system ✨
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
Enumservice Subtypes: "sip"
URI Schemes: 'sip:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]unifmsg, sips 🔐 last one in this batch! Same unified communication session with a unified messaging system, just over the secure sips: scheme 🫶🌸
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
Enumservice Subtypes: "sips"
URI Schemes: 'sips:'
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]Okay bestie, this is the last stretch of the registry stuff, and it's giving calendars and web links 🦋
Here's the first unifmsg one 💜
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
Enumservice Subtype: "http"
URI Schemes: 'http:'
Functional Specification:
This Enumservice indicates that the remote resource identified
by the associated URI scheme is capable of being a source of
information.
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'http:' [11] URI provides a
document. This document can contain references that will trigger
the download of many different kinds of information, such as
text, audio, video, executable code, or even video message
files. Thus, one cannot be more specific about the kind of
information expected when contacting the resource.
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]The https version is next, and it's basically the same energy 🌸
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
Enumservice Subtype: "https"
URI Schemes: 'https:'
Functional Specification:
This Enumservice indicates that the remote resource identified
by the associated URI scheme is capable of being a source of
information, which can be contacted using TLS or the Secure
Socket Layer protocol.
Note that the kind of information retrieved can be manifold.
Usually, contacting a resource by an 'https:' [12] URI provides
a document. This document can contain references that will
trigger the download of many different kinds of information,
such as text, audio, video, executable code, or even video
message files. Thus, one cannot be more specific about the kind
of information expected when contacting the resource.
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Authors:
Jason Livingood (jason_livingood&cable.comcast.com)
Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting:
Implementers should review a non-exclusive list of examples
below in Section 7 of [RFC5278]Now the calendar ones 🧚 ical-sched first, for scheduling via mail 📅
Enumservice Name: "ical-sched"
Enumservice Type: "ical-sched"
Enumservice Subtypes: "mailto"
URI scheme(s): 'mailto:'
Functional Specification:
This Enumservice indicates that the resource identified can be
addressed by the associated URI used for scheduling using
Internet calendaring via Internet mail with the iMIP [6]
protocol.
Security considerations: See Section 4 of [RFC5333].
Intended usage: COMMON
Author:
Rohan Mahy (rohan&ekabal.com)ical-access is next, and this one is all about checking someone's calendar, like free/busy status 🗓️✨
Enumservice Name: "ical-access"
Enumservice Type: "ical-access"
Enumservice Subtypes: "http"
URI scheme(s): 'http:'
Functional Specification:
This Enumservice indicates that the resource identified can be
addressed by the associated URI in order to access a user's
calendar (for example free/busy status) using the CalDAV [7]
protocol for Internet calendaring.
Security considerations: See Section 4 of [RFC5333].
Intended usage: COMMON
Author:
Rohan Mahy (rohan&ekabal.com)And the https one for ical-access, same vibe but over a secure connection 🔒🦋
Enumservice Name: "ical-access"
Enumservice Type: "ical-access"
Enumservice Subtypes: "https"
URI scheme(s): 'https:'
Functional Specification:
This Enumservice indicates that the resource identified can be
addressed by the associated URI in order to access a user's
calendar (for example free/busy status) using the CalDAV [7]
protocol for Internet calendaring.
Security considerations: See Section 4 of [RFC5333].
Intended usage: COMMON
Author:
Rohan Mahy (rohan&ekabal.com)Authors' Addresses 💌
Here are the authors' contact details, copied exactly so nothing gets lost in the vibes 🫶
Bernie Hoeneisen
Ucom Standards Track Solutions GmbH
CH-8000 Zuerich
Switzerland
Phone: +41 44 500 52 44
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/That's the whole document, periodt 🌈👑💖
📦 where this page comes from
- ietf: rfc6118 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms