One document matched: draft-hoeneisen-enum-enumservices-transition-00.txt
ENUM -- Telephone Number Mapping B. Hoeneisen
Working Group SWITCH
Internet-Draft A. Mayrhofer
Updates: enum.at
3762,3764,3953,4143,4002,4238,4355, May 19, 2008
4415,4769,4969,4979,5028
(if approved)
Intended status: Standards Track
Expires: November 14, 2008
Update of legacy IANA Registrations of Enumservices
draft-hoeneisen-enum-enumservices-transition-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 November 14, 2008.
Abstract
This document specifies a revision of all Enumservices that have been
registered at IANA under the nowadays obsolete regime of [RFC3761].
It mainly adds the new fields to the IANA Registration Template as
specified in [I-D.ietf-enum-enumservices-guide], and makes at the
same time some corrections of editorial nature.
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 1]
Internet-Draft Update legacy Enumservice Registrations May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
3.1. Enumservice Registrations . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Former Content of the IANA Repository . . . . . . . . 19
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 19
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 2]
Internet-Draft Update legacy Enumservice Registrations May 2008
1. Introduction
[I-D.ietf-enum-enumservices-guide] has obsoleted the IANA
registration section of [RFC3761]. In the IANA registry for
Enumservices, there are several entries that had been made under RFC
3761 regime. Those do not conform to the new guidelines as specified
in [I-D.ietf-enum-enumservices-guide]. To ensure consisteny among
the Enumservice registrations, the document adds the new fields to
the existing IANA registrations and make some editorial corrections
at the same time.
However, this document does only add the missing fields from the IANA
Registration Template as spcified in the IANA cConsiderations of
[I-D.ietf-enum-enumservices-guide], but does complete the (nowadays)
missing sections of the corresponding Registration Documents. These
documents have to be revised in order to conform with the new regime
for Enumservice registrations as specified in
[I-D.ietf-enum-enumservices-guide].
This document updates the following RFCs:
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 [I-D.ietf-enum-calendar-service]
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. IANA Considerations
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 3]
Internet-Draft Update legacy Enumservice Registrations May 2008
3.1. Enumservice Registrations
IANA replaces the existing Enumservice Registrations by the
following:
[Note for RFC Editor: Please replace any instance of RFCTHIS with the
RFC number of this document before publication]
Assigned Enumservice Values
---------------------------
email:mailto
o Enumservice Class: Application-based, Common
o Enumservice Type: "email"
o Enumservice Subtype: "mailto"
o URI Scheme(s): 'mailto'
o Functional Specification:
* This Enumservice indicates that the remote resource can be
addressed by the associated URI scheme in order to send an
email.
o Security Considerations: See Section 6 of [RFC4355]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
ems:mailto
o Enumservice Class: Application-based, Common
o Enumservice Type: "ems"
o Enumservice Subtype: "mailto"
o URI Scheme(s): 'mailto'
o 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).
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 4]
Internet-Draft Update legacy Enumservice Registrations May 2008
* For references see [RFC4355].
o Security Considerations:
* There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
ems:tel
o Enumservice Class: Application-based, Common
o Enumservice Type: "ems"
o Enumservice Subtype: "tel"
o URI Scheme(s): 'tel'
o 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]).
o Security Considerations:
* There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information:
* 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.
fax:tel
o Enumservice Class: Application-based, Subset
o Enumservice Type: "fax"
o Enumservice Subtype: "tel"
o URI Scheme(s): 'tel'
o Functional Specification:
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 5]
Internet-Draft Update legacy Enumservice Registrations May 2008
* 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.
o Security Considerations: See Section 6 of [RFC4355]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
ft:ftp
o Enumservice Class: Application-based, Subset
o Enumservice Type: "ft"
o Enumservice Subtype: "ftp"
o URI Scheme(s): 'ftp'
o 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.
o Security Considerations: See Section 5 of [RFC4002]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4002] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
h323
o Enumservice Class: Protocol-based
o Enumservice Type: "h323"
o Enumservice Subtype: N/A
o URI Scheme(s): 'h323'
o Functional Specification: See Section 3 of [RFC3762]
o Security Considerations: See section 5 of [RFC3762]
o Intended Usage: COMMON
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 6]
Internet-Draft Update legacy Enumservice Registrations May 2008
o Registration Document(s):
* [RFC3762] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Orit Levin
o Further Information: N/A
ical:access
o Enumservice Class: Data- / Format-based
o Enumservice Type: "ical"
o Enumservice Subtype: "access"
o URI Scheme(s): 'http', 'https'
o Functional Specification:
* This Enumservice indicates that the resource identified is a
URI used for Internet Calendaring which is available to access
a user's calendar (for example free/busy status). Supported
URI Schemes are 'http:' or 'https:' URIs for the CalDAV [7]
protocol.
o Security Considerations: See Section 3 of [RFC-ietf-enum-calendar-
service-04.txt]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC-ietf-enum-calendar-service-04.txt] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Author: Rohan Mahy
o Further Information: N/A
ical:sched
o Enumservice Class: Data- / Format-based
o Enumservice Type: "ical"
o Enumservice Subtype: "sched"
o URI Scheme(s): 'mailto', 'http', 'https'
o Functional Specification:
* This Enumservice indicates that the resource identified is a
URI used for scheduling using Internet Calendaring. Supported
URI Schemes are the 'mailto:' URI for the iMIP [6] protocol,
and 'http:' or 'https:' URIs for a planned scheduling extension
[15] to the CalDAV [7] protocol.
o Security Considerations: See Section 3 of [RFC-ietf-enum-calendar-
service-04.txt]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC-ietf-enum-calendar-service-04.txt] (Updated by RFCTHIS)
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 7]
Internet-Draft Update legacy Enumservice Registrations May 2008
* [RFCTHIS]
o Author(s): Rohan Mahy
o Further Information: N/A
ifax:mailto
o Enumservice Class: Application-based, Subset
o Enumservice Type: "ifax"
o Enumservice Subtype: "mailto"
o URI Scheme(s): 'mailto'
o Functional Specification: See Section 1 of [RFC4143]
o Security Considerations: See Section 3 of [RFC4143]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC3413] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Kiyoshi Toyoda, Dave Crocker
o Further Information:
* The URI Scheme is "mailto" because facsimile is a profile of
standard Internet mail and uses standard Internet mail
addressing.
im
o Enumservice Class: Application-based, Common
o Enumservice Type: "im"
o Enumservice Subtype: N/A
o URI Scheme(s): 'im'
o 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 RFC3861
[4] is used to discover whether an IM protocol supported by the
party querying ENUM is also supported by the target resource.
o Security Considerations: See Section 3 of [RFC5028]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC5028] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rohan Mahy
o Further Information: N/A
mms:mailto
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 8]
Internet-Draft Update legacy Enumservice Registrations May 2008
o Enumservice Class: Application-based, Common
o Enumservice Type: "mms"
o Enumservice Subtype: "mailto"
o URI Scheme(s): 'mailto'
o 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]
o Security Considerations:
* There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information:
* 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.
mms:tel
o Enumservice Class: Application-based, Common
o Enumservice Type: "mms"
o Enumservice Subtype: "tel"
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 9]
Internet-Draft Update legacy Enumservice Registrations May 2008
o URI Scheme(s): 'tel'
o 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].
o Security Considerations:
* There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
* For references see [RFC4355].
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information:
* 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 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.
pres
o Enumservice Class: Application-based, Common
o Enumservice Type: "pres"
o Enumservice Subtype: N/A
o URI Scheme(s): 'pres'
o Functional Specification: See Section 4 of [RFC3953]
o Security Considerations: See Section 6 of [RFC3953]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC3953] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Jon Peterson
o Further Information: See Section 3 of [RFC3953]
pstn:sip
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 10]
Internet-Draft Update legacy Enumservice Registrations May 2008
o Enumservice Class: Application-based, Subset (??)
o Enumservice Type: "pstn"
o Enumservice Subtype: "sip"
o URI Scheme(s): 'sip'
o 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.
o Security Considerations: See Section 7 of [RFC4769]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4769] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Jason Livingood, Richard Shockey
o Further Information:
* A Number Portability Dip Indicator (npdi) should be used in
practice (see examples below in Section 4 of [RFC4769]).
pstn:tel
o Enumservice Class: Application-based, Ancillary
o Enumservice Type: "pstn"
o Enumservice Subtype: "tel"
o URI Scheme(s): 'tel'
o 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 RFC4694 [10].
o Security Considerations: See Section 7 of [RFC4769]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4769] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Jason Livingood, Richard Shockey
o Further Information:
* A Number Portability Dip Indicator (npdi) should be used in
practice (see examples below in Section 4 of [RFC4769]).
sip
o Enumservice Class: Protocol-based
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 11]
Internet-Draft Update legacy Enumservice Registrations May 2008
o Enumservice Type: "sip"
o Enumservice Subtype: N/A
o URI Scheme(s): 'sip', 'sips'
o Functional Specification: See Section 4 of [RFC3764]
o Security Considerations: See Section 6 of [RFC3764]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC3764] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Jon Peterson
o Further Information: See Section 3 of [RFC3764]
sms:mailto
o Enumservice Class: Application-based, Common
o Enumservice Type: "sms"
o Enumservice Subtype: "mailto"
o URI Scheme(s): 'mailto'
o 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, 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].
o Security Considerations:
* There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
sms:tel
o Enumservice Class: Application-based, Common
o Enumservice Type: "sms"
o Enumservice Subtype: "tel"
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 12]
Internet-Draft Update legacy Enumservice Registrations May 2008
o URI Scheme(s): 'tel'
o 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].
o Security Considerations:
* There are no specific security issues with this Enumservice.
However, the general considerations of Section 6 of [RFC4355]
apply.
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4355] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
vcard
o Enumservice Class: Data- / Format-based
o Enumservice Type: "vcard"
o Enumservice Subtype: N/A
o URI Scheme(s): 'http', 'https'
o Functional Specification:
* This Enumservice indicates that the resource dentified 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.
o Security Considerations: See Section 5 [RFC4969]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4969] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Alexander Mayrhofer
o Further Information:
voice:tel
o Enumservice Class: Application-based, Common
o Enumservice Type: "voice"
o Enumservice Subtype: "tel"
o URI Scheme(s): 'tel'
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 13]
Internet-Draft Update legacy Enumservice Registrations May 2008
o 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.
o Security Considerations: See Section 5 of [RFC4415]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4415] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information:
* 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 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.
vpim:ldap
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 14]
Internet-Draft Update legacy Enumservice Registrations May 2008
o Enumservice Class: Application-based, Common (??)
o Enumservice Type: "vpim"
o Enumservice Subtype: "ldap"
o URI Scheme(s): 'ldap'
o Functional Specification: See Sections 3.2 - 3.3 of [RFC4238]
o Security Considerations:
* 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.
* 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.
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4238] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Greg Vaudreuil
o Further Information: N/A
vpim:mailto
o Enumservice Class: Application-based, Common
o Enumservice Type: "vpim"
o Enumservice Subtype: "mailto"
o URI Scheme(s): 'mailto'
o Functional Specification: See Sections 4.2 - 4.4 of [RFC4238]
o Security Considerations:
* 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.
* 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.
* 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.
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 15]
Internet-Draft Update legacy Enumservice Registrations May 2008
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4238] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Greg Vaudreuil
o Further Information:
* Error Conditions:
+ E.164 number not in the numbering plan
+ E.164 number in the numbering plan, but no URLs exist for
that number
+ E2U+vpim:mailto Service unavailable of email addresses where
only the telephone number was previously known.
web:http
o Enumservice Class: Application-based, Common
o Enumservice Type: "web"
o Enumservice Subtype: "http"
o URI Scheme(s): 'http'
o 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.
o Security Considerations: See Section 5 of [RFC4002]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4002] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
web:https
o Enumservice Class: Application-based, Common
o Enumservice Type: "web"
o Enumservice Subtype: "https"
o URI Scheme(s): 'https'
o Functional Specification:
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 16]
Internet-Draft Update legacy Enumservice Registrations May 2008
* 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.
o Security Considerations: See Section 5 of [RFC4002]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4002] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny
o Further Information: N/A
xmpp
o Enumservice Class: Protocol-based
o Enumservice Type: "xmpp"
o Enumservice Subtype: N/A
o URI Scheme(s): 'xmpp'
o Functional Specification:
* This Enumservice indicates that the resource identified is an
XMPP entity.
o Security Considerations: See Section 6 of [RFC4979]
o Intended Usage: COMMON
o Registration Document(s):
* [RFC4979] (Updated by RFCTHIS)
* [RFCTHIS]
o Author(s): Alexander Mayrhofer
o Further Information: N/A
4. Security Considerations
Since this document does not introduce any technology or protocol,
there are no security issues to be considered for this document
itself.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 17]
Internet-Draft Update legacy Enumservice Registrations May 2008
[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-09
(work in progress), May 2008.
[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 November 14, 2008 [Page 18]
Internet-Draft Update legacy Enumservice Registrations May 2008
[RFC5028] Mahy, R., "A Telephone Number Mapping (ENUM) Service
Registration for Instant Messaging (IM) Services",
RFC 5028, October 2007.
[I-D.ietf-enum-calendar-service]
Mahy, R., "A Telephone Number Mapping (ENUM) Service
Registration for Internet Calendaring Services",
draft-ietf-enum-calendar-service-04 (work in progress),
March 2008.
Appendix A. Former Content of the IANA Repository
Todo: Copy-Paste from existing IANA Repository
Appendix B. Document Changelog
[RFC Editor: This section is to be removed before publication]
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
o bernie: Put caption to each Enumservice
o bernie: Sorted alphabetically
o bernie: All URI Schemes without colon
Appendix C. Open Issues
[RFC Editor: This section should be empty before publication]
o How can these Enumservices be changed in future?
o Authors of Enumservices to review the changes
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 19]
Internet-Draft Update legacy Enumservice Registrations May 2008
Authors' Addresses
Bernie Hoeneisen
SWITCH
Werdstrasse 2
CH-8004 Zuerich
Switzerland
Phone: +41 44 268 1515
Email: bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch
URI: http://www.switch.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/
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 20]
Internet-Draft Update legacy Enumservice Registrations May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hoeneisen & Mayrhofer Expires November 14, 2008 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:28 |