ENUM -- Telephone Number Mapping B. Hoeneisen
Working Group Swisscom
Internet-Draft A. Mayrhofer
Updates: 3762, 3764, 3953, 4143, enum.at
4002, 4238, 4355, 4415, 4769, Aug 18, 2009
4969, 4979, 5028, 5278
(if approved)
Intended status: BCP
Expires: February 19, 2010
Update of legacy IANA Registrations of Enumservices
draft-ietf-enum-enumservices-transition-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2010.
Copyright Notice
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 1]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document revises all Enumservices that were IANA registered
under the now obsolete specification of the Enumservice registry
defined in [RFC3761].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IESG Action . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4.1. Enumservice Registrations . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
7. Normative References . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Former Content of the IANA Repository . . . . . . . . 43
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 2]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
1. Introduction
[I-D.ietf-enum-enumservices-guide] has obsoleted the IANA
registration section of [RFC3761]. Since the IANA Enumservice
registry contains various Enumservices registered under the regime of
RFC 3761, those registrations do not conform to the new guidelines as
specified in [I-D.ietf-enum-enumservices-guide]. To ensure
consistency among all Enumservice registrations at IANA, this
document adds the (nowadays) missing elements to those existing
registrations. Furthermore, all existing Enumservice registrations
are converted to the new XML chunk format, and, where deemed
necessary, minor editorial corrections are applied.
However, this document does only add the missing elements from the
IANA Registration Template as specified in the IANA Considerations
section of [I-D.ietf-enum-enumservices-guide], but does not complete
the (nowadays) missing sections of the corresponding Enumservice
Specifications. In order to conform with the new registration regime
as specified in [I-D.ietf-enum-enumservices-guide], those Enumservice
Specifications still have to be revised.
It is important to note that this document does not update the
functional specification of the concerned Enumservices.
The following RFCs are updated by this document:
o [RFC3762]
o [RFC3764]
o [RFC3953]
o [RFC4143]
o [RFC4002]
o [RFC4238]
o [RFC4355]
o [RFC4415]
o [RFC4769]
o [RFC4969]
o [RFC4979]
o [RFC5028]
o [RFC5278]
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].
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 3]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
3. IESG Action
According to [RFC3761], any Enumservice registration had to be
published as RFC on the Standards Track, Experimental RFC, or as a
BCP. [I-D.ietf-enum-enumservices-guide] no longer has this
requirement, i.e. Expert Review and Specification Required are
sufficient. As any update to an existing specification must have at
least the same Maturity Level (see [RFC2026]) as the document it
updates, an IETF action (approval of this document) is required to
override this requirement.
This document changes the approval required for updates of
Enumservice registrations to Specification Required including that
the specification and request are reviewed by a Designated Expert as
described in [I-D.ietf-enum-enumservices-guide].
4. IANA Considerations
4.1. Enumservice Registrations
IANA are to replace all the existing Enumservice Registrations as
follows; as per [I-D.ietf-enum-enumservices-guide] these are in the
form of XML chunks:
[Note for RFC Editor: Please replace any instance of RFCTHIS with
the RFC number of this document before publication]
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 4]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
email
mailto
mailto
This Enumservice indicates that the resource can be
addressed by the associated URI in order to send an
email.
See , Section 6.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 5]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
ems
mailto
mailto
This Enumservice indicates that the resource
identified by the associated URI 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 .
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of apply.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 6]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
ems
tel
tel
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using the Enhanced Message
Service (EMS) [14] (For reference see
).
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of apply.
COMMON
(updated by RFCTHIS)
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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 7]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Subset
fax
tel
tel
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.
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
-
in short, they will have a fax program with a local
or shared PSTN access over which they can send
faxes.
See , Section 6.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 8]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Subset
ft
ftp
ftp
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.
See , Section 5.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 9]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Protocol-Based
h323
h323
See , Section 3.
See , Section 5.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 10]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Subset
ifax
mailto
mailto
See , Section 1.
See , Section 3.
COMMON
(updated by RFCTHIS)
The URI Scheme is 'mailto' because facsimile is a
profile of standard Internet mail and uses standard
Internet mail addressing.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 11]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
im
im
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 RFC3861 [4] is
used to discover whether an IM protocol supported by
the party querying ENUM is also supported by the
target resource.
See , Section 3.
COMMON
(updated by RFCTHIS)
Application-Based, Common
mms
mailto
mailto
This Enumservice indicates that the resource
identified by the associated URI 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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 12]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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].
For references see .
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of apply.
COMMON
(updated by RFCTHIS)
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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 13]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
mms
tel
tel
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using the Multimedia
Messaging Service (MMS) [15].
For references see .
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of apply.
COMMON
(updated by RFCTHIS)
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 de do have two small
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 14]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
Application-Based, Common
pres
pres
See , Section 4.
See , Section 6.
COMMON
(updated by RFCTHIS)
See , Section 3.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 15]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
pstn
sip
sip
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.
See , Section 7.
COMMON
(updated by RFCTHIS)
A Number Portability Dip Indicator (npdi) should
be used in practice
(see , Section 4).
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 16]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Ancillary
pstn
tel
tel
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].
See , Section 7.
COMMON
(updated by RFCTHIS)
A Number Portability Dip Indicator (npdi) should
be used in practice
(see , Section 4).
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 17]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Protocol-Based
sip
sip, sips
See , Section 4.
See , Section 6.
COMMON
(updated by RFCTHIS)
See , Section 3.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 18]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
sms
mailto
mailto
This Enumservice indicates that the resource
identified by the associated URI 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, 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
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of apply.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 19]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
sms
tel
tel
This Enumservice indicates that the resource
identified by the associated URI is capable
of receiving a message using the Short Message
Service (SMS) [14] in .
There are no specific security issues with this
Enumservice. However, the general considerations of
Section 6 of apply.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 20]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
unifmsg
http
http
This Enumservice indicates that the 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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 21]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
unifmsg
https
https
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.
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 22]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
unifmsg
sip
sip
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 23]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
unifmsg
sips
sips
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 24]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Data Type-Based
vcard
http, https
This Enumservice indicates that the resource
identified is a plain vCard, according to RFC2426,
which may be accessed using HTTP / HTTPS [7].
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.
See , Section 5.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 25]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
videomsg
http
http
This Enumservice indicates that the 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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 26]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
videomsg
https
https
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.
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 27]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
videomsg
sip
sip
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 28]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
videomsg
sips
sips
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Application-Based, Common
voice
tel
tel
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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 29]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
See , Section 5.
COMMON
(updated by RFCTHIS)
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.
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.
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
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 30]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
may either accept requests using "tel:" URIs or has
a defined mechanism to convert "tel:" URI values
into a "protocol-native" form.
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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 31]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
voicemsg
http
http
This Enumservice indicates that the 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 voice message files. Thus, one cannot be more specific
about the kind of information expected when contacting the
resource.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 32]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
voicemsg
https
https
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.
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 33]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
voicemsg
sip
sip
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 34]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
voicemsg
sips
sips
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 35]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
voicemsg
tel
tel
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.
See , Section 3.
COMMON
(updated by RFCTHIS)
Implementers should review a non-exclusive list of examples
in Section 7 of .
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 36]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
vpim
ldap
ldap
See , Section 3.2 - 3.3.
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.
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.
COMMON
(updated by RFCTHIS)
Application-Based, Common
vpim
mailto
mailto
See , Section 4.2 - 4.4.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 37]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
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.
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.
COMMON
(updated by RFCTHIS)
Error Conditions:
E.164 number not in the numbering plan
E.164 number in the numbering plan, but no
URIs exist for that number
E2U+vpim:mailto Service unavailable of email
addresses where only the telephone number was
previously known.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 38]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
web
http
http
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 can not be more
specific about the kind of information that can be
expected when contacting the resource.
See , Section 5.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 39]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Application-Based, Common
web
https
https
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 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.
See , Section 5.
COMMON
(updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 40]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Protocol-Based
xmpp
xmpp
This Enumservice indicates that the resource
identified is an XMPP entity.
See , Section 6.
COMMON
(updated by RFCTHIS)
5. Security Considerations
Since this document does not introduce any technology or protocol,
there are no security issues to be considered for this document
itself.
6. Acknowledgements
The authors would like to thank the following people who have
provided feedback or significant contributions to the development of
this document: Alfred Hoenes, and Scott Bradner
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 41]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
[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.
[I-D.ietf-enum-enumservices-guide]
Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template and IANA
Considerations", draft-ietf-enum-enumservices-guide-16
(work in progress), February 2009.
[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.
[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail
(IFAX) Service of ENUM", RFC 4143, November 2005.
[RFC4002] Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservice 'web' and 'ft'", RFC 4002,
February 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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 42]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
[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.
Appendix A. Former Content of the IANA Repository
Enumservice Registrations
(last updated 2009-07-29)
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)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 43]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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)
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 44]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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"
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 45]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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:
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 46]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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:
None
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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 47]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
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:
None
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.
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 48]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
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
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 49]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
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.
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
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 50]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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.
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
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 51]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
"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.
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]).
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]).
Enumservice Name: "vCard"
Enumservice Name: "vCard"
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 52]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Enumservice Type: "vcard"
Enumservice Subtype: n/a
URI Schemes: "http", "https"
Functional Specification:
This Enumservice indicates that the resource identified is a
plain vCard, according to RFC 2426, which may be accessed using
HTTP/ HTTPS [7].
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.
Security Considerations: see Section 5 [RFC4969]
Intended Usage: COMMON
Author: Alexander Mayrhofer
Enumservice Name: "XMPP"
Enumservice Type: "xmpp"
Enumservice Subtype: n/a
URI Schemes: "xmpp"
Functional Specification:
This Enumservice indicates that the resource identified is an
XMPP entity.
Security Considerations: see Section 6 of [RFC4979]
Intended Usage: COMMON
Author: Alexander Mayrhofer
Enumservice Name: "im"
Enumservice Type: "im"
Enumservice Subtypes: N/A
URI scheme(s): "im:"
Functional Specification:
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.
Security considerations: See section 3 of [RFC5028]
Intended usage: COMMON
Author: Rohan Mahy (rohan&ekabal.com)
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtypes: "sip"
URI Schemes: 'sip:'
Functional Specification:
This Enumservice indicates that the remote resource identified
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 53]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
can be addressed by the associated URI scheme in order to
initiate a voice communication session to a voice messaging
system.
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]
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtypes: "sips"
URI Schemes: 'sips:'
Functional Specification:
This Enumservice indicates that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a voice communication session to a voice messaging
system.
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]
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
Enumservice Subtype: "tel"
URI Schemes: 'tel:'
Functional Specification:
This Enumservice indicates that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a voice communication session to a voice messaging
system.
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]
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 54]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
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 voice 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]
Enumservice Name: "voicemsg"
Enumservice Type: "voicemsg"
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 voice
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]
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 55]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
Enumservice Subtypes: "sip"
URI Schemes: 'sip:'
Functional Specification:
This Enumservice indicates that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a video communication session to a video messaging
system.
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]
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
Enumservice Subtypes: "sips"
URI Schemes: 'sips:'
Functional Specification:
This Enumservice indicates that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a video communication session to a video messaging
system.
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]
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
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
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 56]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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]
Enumservice Name: "videomsg"
Enumservice Type: "videomsg"
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]
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
Enumservice Subtypes: "sip"
URI Schemes: 'sip:'
Functional Specification:
This Enumservice indicates that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a unified communication session to a unified messaging
system.
Security Considerations: See Section 3 of [RFC5278]
Intended Usage: COMMON
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 57]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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]
Enumservice Name: "unifmsg"
Enumservice Type: "unifmsg"
Enumservice Subtypes: "sips"
URI Schemes: 'sips:'
Functional Specification:
This Enumservice indicates that the remote resource identified
can be addressed by the associated URI scheme in order to
initiate a unified communication session to a unified messaging
system.
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]
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]
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 58]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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]
Appendix B. Document Changelog
[RFC Editor: This section is to be removed before publication]
draft-ietf-enum-enumservices-transition-02:
o bernie: Temporarily removed calendaring Enumservices (will be
added again, once these are fixed)
o bernie: added current state of IANA repository
draft-ietf-enum-enumservices-transition-01:
o bernie: Added 13 new Enumservices (RFC 5278)
o bernie: Updated 'Open Issues' section
o bernie: Updated ipr attribute to 'pre5378Trust200902' according to
http://www.ietf.org/mail-archive/web/syslog/current/msg02333.html
o alex: Added missing classifications
o alex: Editorial improvements
o bernie: More editorials
o bernie: Changed status to bcp, to avoid downref problem with
enumservice-guide
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 59]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
o bernie: Rewrite of IESG Action
draft-ietf-enum-enumservices-transition-00:
o bernie: Updated affiliation: Switch -> Swisscom
o bernie: Revised all Enumservices to the form of XML chunks
o bernie: Added statement for IESG Actions to downgrade existing all
Enumservice specifications
o bernie: Updated 'Open Issues' section
draft-hoeneisen-enum-enumservices-transition-01:
o bernie: Fixed wrong reference
draft-hoeneisen-enum-enumservices-transition-01:
o bernie: integrated feedback from Alfred Hoenes
* Typos / corrections
* Removed the words "remote" and "scheme" in existing
registrations
* changed "URL" to "URI" in existing registrations
* changed "headers" to "header fields" in existing "mms:mailto"
registration
o bernie: Added Acknowledgments section
draft-hoeneisen-enum-enumservices-transition-00:
o bernie: Initial version
o bernie: Imported and adjusted existing IANA Enumservice
registrations
o bernie: Removed Name and added Class fields
o bernie: Put caption to each Enumservice
o bernie: Sorted alphabetically
o bernie: All URI Schemes without colon
o alex: Added classification
Authors' Addresses
Bernie Hoeneisen
Swisscom
Hardturmstrasse 3
CH-8005 Zuerich
Switzerland
Phone: +41 44 2747111
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT swisscom.com)
URI: http://www.swisscom.ch/
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 60]
Internet-Draft Update legacy Enumservice Registrations Aug 2009
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/
Hoeneisen & Mayrhofer Expires February 19, 2010 [Page 61]