One document matched: draft-ietf-enum-enumservices-guide-06.xml
<?xml version='1.0' ?>
<!-- $Id: draft-ietf-enum-enumservices-guide-04.xml 219 2007-07-09 10:04:15Z axelm $ -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc category='bcp' ipr='full3978' docName='draft-ietf-enum-enumservices-guide-06' >
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<!-- <?rfc strict='yes' ?> -->
<front>
<date month='Nov' year='2007' day='14'/>
<title abbrev='BCP Enumservice Registrations'>
Guide and Template for IANA Registrations of Enumservices
</title>
<author initials='B.' surname='Hoeneisen' fullname='Bernie Hoeneisen'>
<organization abbrev='SWITCH'>
SWITCH
</organization>
<address>
<postal>
<street>Werdstrasse 2</street>
<city>CH-8004 Zuerich</city>
<country>Switzerland</country>
</postal>
<phone>+41 44 268 1515</phone>
<email>bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch</email>
<uri>http://www.switch.ch/</uri>
</address>
</author>
<author initials='A.' surname='Mayrhofer' fullname='Alexander Mayrhofer'>
<organization abbrev='enum.at'>
enum.at GmbH
</organization>
<address>
<postal>
<street>Karlsplatz 1/9</street>
<city>Wien</city>
<code>A-1010</code>
<country>Austria</country>
</postal>
<phone>+43 1 5056416 34</phone>
<email>alexander.mayrhofer@enum.at</email>
<uri>http://www.enum.at/</uri>
</address>
</author>
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>1500 Market Street</street>
<city>Philadelphia, PA 19102</city>
<country>USA</country>
</postal>
<phone>+1-215-981-7813</phone>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com/</uri>
</address>
</author>
<area>RAI</area>
<workgroup>ENUM -- Telephone Number Mapping Working Group</workgroup>
<keyword>ENUM</keyword>
<abstract>
<t>This document provides a guide to and template for the creation
of new IANA registrations of ENUM (E.164 Number Mapping) services.
It is also to be used for updates of existing IANA registrations.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<!-- <t>[ Note: This is work in progress - the ENUM crowd is invited
to contribute, since issues clarified in this document will save
the group time spent on each individual Enumservice registration.
Please mail your opinions/ideas to the WG list!! ]
</t>
-->
<t>This document provides a guide to and template for the
creation of new IANA registrations of Enumservices. This
document aims to enhance section 3 of <xref target = "RFC3761">
RFC 3761 </xref>, where the registration procedure for Enumservices
was initially documented at a high level. However, the IETF's ENUM
Working Group has encountered an unnecessary amount of variation in the
format of Enumservice drafts presented to the group. The ENUM Working
Group's view of what particular fields and information are required
and/or recommended has also evolved, and capturing these best current
practices is helpful in both the creation of new registrations, as well
as the revision or refinement of existing registrations.
</t>
<t>This document also aims at providing a registration process
which is more detached from the existance of the ENUM working
group.</t>
<t>For the purpose of this document, 'registration document' and
'registration' refer to an Internet-Draft proposing the IANA
registration of an Enumservice following the procedures outlined
herein.
</t>
<!-- <t>[-00 Note: This is an early draft version.]
</t>-->
</section>
<section title="Terminology">
<t>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 <xref target ="RFC2119">RFC 2119 </xref>.
</t>
</section>
<!--
<section title='History and Usage of Enumservice Registrations'>
<t>As mentioned above, <xref target = "RFC3761"> RFC 3761
</xref> describes the ... DO WE REALLY NEED THIS?
</t>
</section>
-->
<section title='Enumservice Creation Cookbook'>
<section title='General Enumservice Considerations'>
<t>ENUM is an extremely flexible identifier mapping mechanism,
using E.164 (phone) numbers as input identifiers, and returning
URIs as output identifiers. Because of this flexibility, almost
every use case for
ENUM could be implemented in several ways.
Because of the huge size of the Enumservice identifier namespace
(up to 32 alphanumeric characters for type and subtype field each),
it is very tempting to register a new Enumservice for each new
use case. However, this would obviously reduce interopability,
and increase confusion among implementors. Also, the space in the
protocol on which ENUM is based on (namely DNS packets) is
rather scarce compared to the huge identifier space that Enumservice
typing provides.
</t>
<t>Generally, before commencing work on a new Enumservice
registration, the following should be considered:
<vspace blankLines='1'/>
<list style='symbols'>
<t>Is there an existing Enumservice which could fulfill the
desired functionality without overloading it? Check the IANA
Enumservice registrations on
<http://www.iana.org/assignments/enum-services>.
<vspace blankLines='1'/></t>
<t>Is there work in progress on a similar Enumservice? Check
the <enum@ietf.org> mailing list archives on
<http://www.ietf.org/mail-archive/web/enum/index.html>,
and the Internet-Drafts Archive on
<http://tools.ietf.org/wg/enum/>.
</t>
<t><xref target='classification'/> provides three general
categories for Enumservice classification. In some cases, there
might be several options for designing an Enumservice. For
example, a mapping service using HTTP could be considered a
"protocol type" Enumservice (using HTTP as the protocol),
while it could also be viewed as
an "application type" Enumservice, with the application being
access to maps. In such a case where several options are
available, defining use cases before commencing work on
the Enumservice itself might be useful before making a
decision on whether the "protocol" or the "application"
aspect of the Enumservice is more important.
</t>
</list>
</t>
</section>
<section anchor='classification' title='Classification, Name, Type and Subtype'>
<t>Because of its flexibility, Enumservices can be and are used
in a lot of different ways. This section contains a classification
of Enumservices, and provides guidance for choosing suitable
'type' and 'subtype' strings for each individual Enumservice
class. The choice of a suitable 'name' is independent of the
classification.
</t>
<section anchor='choosename' title='Choosing a "name" string'>
<t>Advice for choosing a proper 'name' string is indepent of
the classificaton of the Enumservice.</t>
<t>Generally, the 'name' string used for registering an Enumservice
SHOULD give a clear indication of what the Enumservice is about.
The 'name' has no technical significance in the processing of
the NAPTR (it doesn't even appear in resource record instances
of the Enumservice). However, it
is likely to be used for labeling the
Enumservice to end users.
</t>
<t>Suitable 'names' are concise, distinctive, and clearly related
to the underlying service that a client is going to interact with.
</t>
</section>
<section anchor='protocolclass' title='Protocol-based Enumservices Class'>
<t>Such an Enumservice indicates that an interaction using the
named protocol will result for use of this NAPTR. The expected
behavior of a system using this Enumservice MUST be clear from
the protocol.</t>
<t>A good indication that an Enumservice belongs to this class is
the fact that a client does not need to understand the actual
application to make use of an instance of this Enumservice.
</t>
<section anchor='protobtype' title='Protocol-based Enumservice "type" strings'>
<t>
A protocol-based Enumservice SHOULD use the name of the protocol
(or the "base" URI scheme, where there are also secure variants)
as its 'type' name.
</t>
</section>
<section anchor='protobsubtype' title='Protocol-based Enumservice "subtype" strings'>
<t>
Where there is a single URI scheme associated with this protocol,
then the Enumservice SHOULD NOT use a subtype.
</t>
<t>Where a protocol is associated with a number of different
URI schemes, the registration SHOULD define which of these is
the default ("base") URI scheme, and register the empty subtype for use with this default scheme only. The only exception to this is the case
where a secure variant of the "base" URI scheme exists. Such an
URI scheme MAY also be used with the empty subtype string.
</t>
<t>The Enumservice registration SHOULD define subtypes for each
of the non-default URI schemes with which it can be associated.
The use of the URI schema name as subtype string is RECOMMENDED.
</t>
<t>Where a NAPTR includes the default URI scheme, the Enumservice
without a subtype SHOULD be used. Where a non-default scheme is
used, the Enumservice variant with type and respective sub-type
SHOULD be used.
</t>
</section>
</section>
<section anchor='applicationclass' title='Application-based Enumservices'>
<t>Application-based Enumservices are used when the kind of
service intended is not fully defined by a protocol specification.
There are three cases here:
<list style='symbols'>
<t>Common Application Enumservice:
<vspace blankLines='1'/>
The application reflects a kind of interaction that can be realized
by different protocols, but where the intent of the publisher is the
same. From a user's perspective, there is a common kind of interaction -
how that interaction is implemented is not important. The Enumservice
registration MUST describe the interaction and expected behavior in
enough detail that an implementation can decide if this activity is one
in which it can engage. However, it is RECOMMENDED that the Enumservice
is defined in a way that will allow others to use it at a later date. An
Enumservice that defines a generalized application is preferred to one
that has narrow use.
<vspace blankLines='1'/>
An example of this flavors of Enumservice is email. Whilst this might
appear to be a "pure" protocol scheme, it is not. The URI scheme is
mailto:, and does not identify the protocol used by the sender or the
recipient to offer or retrieve emails.
<vspace blankLines='1'/>
Another example is sms, where the presence of such an Enumservice
indicates that the publishing entity is capable of engaging in sending
or receiving a message according to the Short Messaging Service
specifications. The underlying protocol used and the URI-scheme for the
addressable end point can differ, but the "user visible" interaction of
sending and receiving an SMS is similar.
<vspace blankLines='1'/>
</t>
<t>Subset Enumservice:
<vspace blankLines='1'/>
The application interaction reflects a subset of the interactions
possible by use of a protocol. Use of this Enumservice indicates that
some options available by use of the protocol will not be accepted or
are not possible in this case. Any such Enumservice registration MUST
define the options available by use of this NAPTR in enough detail that
an implementation can decide whether or not it can use this Enumservice.
Examples of this kind of Enumservice are voice:tel and fax:tel. In both
cases the URI holds a telephone number. However, the essential feature
of these Enumservices is that the telephone number is capable of
receiving a voice call or of receiving a Facsimile transmission,
respectively. These form subsets of the interactions capable of using
the telephone number, and so have their own Enumservices. These allow an
end point to decide if it has the appropriate capability of engaging in
the advertised user service (a voice call or sending a fax) rather than
just being capable of making a connection to such a destination address.
This is especially important where there is no underlying mechanism
within the protocol to negotiate a different kind of user interaction.
</t>
<t>Ancillary Application Enumservice
<vspace blankLines='1'/>
Another variant on this is the Ancillary Application. This is one in
which further processing (potentially using a number of different
protocols or methods) is the intended result of using this Enumservice.
An example of this kind of application is the PSTN:tel Enumservice. This
indicates that the NAPTR holds Number Portability data. It implies that
the client should engage in number portability processing using the
associated URI.
Note that this Enumservice usually does not itself define the kind of
interaction available using the associated URI. That application is
negotiated with some other "out of band" means (either through prior
negotiation, or explicitly through the number portability process, or
through negotiation following the selection of the final destination
address).
</t>
</list>
</t>
<section anchor='apptype' title='Application-based Enumservice "type" strings'>
<t>It is RECOMMENDED that Application-class Enumservices use the
well known name of the abstract application as "type" name.
</t>
</section>
<section anchor='appsubtype' title='Application-based Enumservice "subtype" strings'>
<t>It is
RECOMMENDED to use the URI scheme(s) that the application uses as
"subtype" names. Subtype names SHOULD be shared only between
URI schemes that correspond to the "base" URI scheme of a protocol
and the secure variant of the same protocol.</t>
<t>If there is only one URI scheme used for the application, the
empty "subtype" string MAY be used.
</t>
</section>
</section>
<section anchor='dataclass' title='Data/Format Enumservice class'>
<t>"Data Format" Enumservices typically refer to a
specific data type or format, which may be addressed using
one or more URI schemes and protocols. It is RECOMMENDED
to use a well known name of the data type / format as the
Enumservice 'type'. An example of such an Enumservice is
<xref target='RFC4238'>'vpim' (RFC 4238)</xref> and
<xref target='RFC4969'>'vCard' (RFC 4969)</xref>
(work in progress).
</t>
<section anchor='datatype' title='Data/Format-based Enumservice "type" strings'>
<t>It is RECOMMENDED to use the well known name of the data/format
as the 'type' name.</t>
</section>
<section anchor='datasubtype' title='Data/Format based Enumservice "subtype" strings'>
<t>It is RECOMMENDED to use the URI schemes used to access the
service as 'subtype' name. Subtype names SHOULD be shared only
between URI schemes that correspond to the "base" URI scheme of
a protocol and its secure variant.</t>
<t>If there is only one URI scheme foreseen to access the data/format, the empty "subtype" string MAY be used.
</t>
</section>
</section>
</section>
<!-- <section anchor='CookbookType' title='About Type Names'>
<t>Generally, the 'type' name of an Enumservice is REQUIRED to
give a clear indication of what the Enumservice is about.
Usually, an Enumservice falls under one of the following
categories:
<vspace blankLines='1'/>
<list style='symbols'>
<t>"Protocol" Enumservices are exclusively tied to a
specific protocol. Such Enumservices typically use that
single protocol and it's respective <xref
target="RFC3986">Uniform Resource
Identifier (URI)</xref> scheme (sometimes
including a secure variant), and SHOULD use the protocol
name / URI scheme name as the 'type'. In case the secure
variant has a different URI scheme / protocol name, the
URI scheme name of the base protocol SHOULD be preferred.
Examples of such Enumservices include <xref
target='RFC3764'> 'SIP' (RFC 3764)</xref>, <xref
target='RFC3762'>'H323' (RFC 3762)</xref> and
<xref target='I-D.ietf-enum-xmpp'>'XMPP'
[draft-ietf-enum-xmpp]</xref>.
<vspace blankLines='1'/></t>
<t>"Application" Enumservices usually use the abstract
application name as the Enumservice 'type'. The name of
the actual protocol and URI scheme may differ from the
'type', but may also be identical (especially when <xref
target='RFC3958'>application service location</xref> is
used). If application name and URI scheme name are
identical, it is RECOMMENDED to use that name also as the
Enumservice 'type'. In case the actual protocol / URI
scheme differs from the application name, it is
RECOMMENDED to use that application name as Enumservice
'type'. Examples of such Enumservices are <xref
target='RFC4002'>'web' and 'ft' (RFC 4002) </xref> and
<xref target='RFC3953'>'pres' (RFC 3953)</xref>.
<vspace blankLines='1'/></t>
<t>"Data Format" Enumservices typically refer to a
specific data type or format, which may be addressed using
one or more URI schemes and protocols. It is RECOMMENDED
to use a well known name of the data type / format as the
Enumservice 'type'. An example of such an Enumservice is
<xref target='RFC4238'>'vpim' (RFC 4238)</xref> and
<xref target='RFC4969'>'vCard' (RFC 4969)</xref>
(work in progress).
</t>
</list>
</t>
<t>To avoid confusion, the name of an URI scheme MUST NOT be
used as a type name for an Enumservice which is not specifically
about the respective protocol / URI scheme - for example,
the type name 'imap' would be inadequate for use in an
Enumservice about Internet mapping services, because it
corresponds to an existing URI scheme / protocol for
something different.
</t>
</section>
<section anchor='CookbookSubtype' title='About Subtypes'>
<t>An Enumservice may optionally use a "subtype" to further
specify the service to which a ENUM record refers to. The
following recommendations apply to such Enumservices:
<vspace blankLines='1'/>
<list style='symbols'>
<t>Subtypes SHOULD NOT be used to curtail the negotiation
capabilities of the protocol used to contact the referred URI,
unless this limitation is specifically desired. If that is
the case, authors MUST describe the limitation, the
motivation for this, and
discuss potential problems arising from this.
<vspace blankLines='1'/></t>
<t>If subtypes are defined, the minimum number SHOULD be
two. The choice of just one possible subtype for a given type
does not add any information when selecting a ENUM record,
and hence can be left out completely.
However, potential future expansion of a type towards several
subtypes MAY justify the use of subtypes, even in the case
just one is currently defined.
<vspace blankLines='1'/></t>
<t>It is perfectly legal under a certain 'type' to mix the
Enumservice without a subtype with Enumservices containing
a subtype. In that case, however, the Enumservice with an
empty subtype SHOULD be used to reflect the base
service, while the other Enumservices SHOULD
be used to reflect variants.
</t>
</list>
</t>
</section> -->
</section>
<section anchor='requiredSections' title='Required Sections and Information'>
<t>In addition to the typical sections required for an RFC as
outlined in <xref target ="I-D.rfc-editor-rfc2223bis"> RFC
2223bis </xref> (Instructions to RFC Authors), there are several
sections which MUST appear in an IANA Registration for an
Enumservice. These sections are, as follows, and SHOULD be in
the same order.
</t>
<t><xref target='XML2RFCtempl'/> contains a template which can
be used to create Internet Drafts and RFC by means described on
<http://xml.resource.org/>.
This template contains a prototype for most of these sections.
</t>
<section title='Introduction (MANDATORY)'>
<t>An introductory section MUST be included. This section will
explain, in plain English, the purpose of and intended usage of the
proposed Enumservice registration.
</t>
<t>The Introduction SHOULD start with a short sentence about ENUM,
introduce the protocol used in the Enumservice, and discuss
the Enumservice as it refers from the E.164 number to the protocol
or service.
</t>
</section>
<section anchor='regexample' title='ENUM Service Registration (MANDATORY)'>
<t>This section MUST be included in an Enumservice registration.
In addition, where a given registration type has multiple subtypes,
there MUST be a separate registration section for each subtype.
The following lists the sections and order of an Enumservice
Registration section. All types and subtypes SHOULD be listed
in lower-case.
</t>
<t>Enumservice Class:
<vspace blankLines='1'/>
<list style='empty'>
<t>This section contains the class of the Enumservice as
defined in <xref target='classification'/>.
<vspace blankLines='1'/></t>
<t>e.g. "Application-based Enumservice"
</t>
</list>
</t>
<t>Enumservice Name:
<vspace blankLines='1'/>
<list style='empty'>
<t>A short word or stub sentence describing this
Enumservice. Often this is equivalent to the Enumservice Type
(see below), however, capitalization may be different from
it.
<vspace blankLines='1'/></t>
<t>e.g. "Foo"
</t>
</list>
</t>
<t>Enumservice Type:
<vspace blankLines='1'/>
<list style='empty'>
<t>The type of the Enumservice. Often this is equivalent to
the Enumservice Name (see above).
<vspace blankLines='1'/></t>
<t>e.g. "foo"
<vspace blankLines='1'/></t>
<!-- <t>For choosing a suitable type, see also <xref
target='CookbookType'/>.
</t> -->
</list>
</t>
<t>Enumservice Subtype:
<vspace blankLines='1'/>
<list style='empty'>
<t>The Subtype of the Enumservice.
<vspace blankLines='1'/></t>
<t>e.g. "bar"
<vspace blankLines='1'/></t>
<t>Many Enumservices do not require a subtype; use "N/A" in
this case.
<!-- For choosing a suitable subtype, see also
<xref target='CookbookSubtype'/>. -->
</t>
</list>
</t>
<t>URI Schemes:
<vspace blankLines='1'/>
<list style='empty'>
<t>The URI Schemes, which are used with the Enumservice.
<vspace blankLines='1'/></t>
<t>
e.g. "bar:", "sbar:"
<vspace blankLines='1'/></t>
<t>A URI scheme often matches the subtype (see above). Multiple
URI schemes can be listed here if they are used for the same
subtype, and provide almost identical functionality.
</t>
<t>Note well that a client cannot choose a specific
ENUM record in a record set based on the URI scheme - the
selection is only based on 'type' and 'subtype'.
</t>
</list>
</t>
<t>Functional Specification:
<vspace blankLines='1'/>
<list style='empty'>
<t>e.g. This Enumservice indicates that the remote resource
identified can be addressed by the associated URI scheme
in order to foo the bar.
</t>
</list>
</t>
<t>Security Considerations:
<vspace blankLines='1'/>
<list style='empty'>
<t>An internal reference to the 'Security Considerations'
section of a given registration document.
<vspace blankLines='1'/></t>
<t>e.g. "see Section 10"
</t>
</list>
</t>
<t>Intended Usage:
<vspace blankLines='1'/>
<list style='empty'>
<t>One of "COMMON", "LIMITED USE" or "OBSOLETE", as defined
in <xref target='RFC3761'>RFC 3761</xref>
<vspace blankLines='1'/></t>
<t>e.g. "COMMON"
</t>
</list>
</t>
<t>Author(s):
<vspace blankLines='1'/>
<list style='empty'>
<t>The author(s) of the Enumservice registration.
<vspace blankLines='1'/></t>
<t>e.g. John Doe <john.doe@example.com>
</t>
</list>
</t>
<t>Any other information the author(s) deem(s) interesting:
<vspace blankLines='1'/>
<list style='empty'>
<t>e.g. None
</t>
</list>
</t>
</section>
<section title='Examples (MANDATORY)'>
<t>This section MUST show one or more example(s) of the Enumservice
registration, for illustrative purposes. The example(s) shall in no
way limit the various forms that a given Enumservice may take, and this
should be noted at the beginning of this section of the document.
The example(s) MUST show the specific formatting of the intended NAPTRs
<xref target ="RFC3403"> RFC 3403</xref>, including one or more NAPTR example(s),
AND a brief textual description, consisting of one or more sentences
written in plain English, explaining the various parts or attributes
of the record(s).
</t>
<t>The example(s) SHOULD contain a brief description how a client
supporting this Enumservice could behave, if that description
was not already given in e.g. the Introduction.
</t>
<t>e.g.<vspace blankLines='1'/>
$ORIGIN 9.7.8.0.9.7.8.9.0.9.4.4.e164.arpa.
<vspace blankLines='0'/>
@ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" .
</t>
</section>
<section title='Implementation Recommendations / Notes (OPTIONAL)'>
<t>If at all possible, recommendations that pertain to implementation
and/or operations SHOULD be included. Such a section is helpful to
someone reading a registration and trying to understand how best to use
it to support their network or service.
</t>
</section>
<section anchor='sec' title='Security Considerations (MANDATORY)'>
<t>A section explaining any potential security threats that are unique
to the given registration MUST be included. This MUST also include any
information about access to Personally Identifiable Information (PII).
</t>
<t>However, this section is not intended as a general security
Best Current Practices (BCP) document and therefore it should
not include general and obvious security
recommendations, such as securing servers with strong password
authentication.
</t>
</section>
<section title='IANA Considerations (MANDATORY)'>
<t>Describe the task IANA needs to fulfill processing the
Enumservice registration document.
</t>
<t>e.g. This memo requests registration of the "foo" Enumservice with
the subtype "bar" according to the definitions in this
document and <xref target='RFC3761'>RFC 3761</xref>.
</t>
</section>
<section title='DNS Considerations (OPTIONAL)'>
<t>In case the inclusion of protocols and URI schemes into
ENUM specifically introduces new DNS issues, those MUST be
described within this section.
</t>
<t>Such DNS issues include, but are not limited to:
<vspace blankLines='1'/>
<list style='symbols'>
<t>Assumptions about the namespace below the owner
of the respective NAPTR RRSet.
<vspace blankLines='1'/></t>
<t>Demand to use DNS wildcards.
<vspace blankLines='1'/></t>
<t>Incompatibility with DNS wildcards.
<vspace blankLines='1'/></t>
<t>presence or absence of the respective NAPTR RRSet at
particular levels in the DNS hierarchy (e.g. only for 'full'
E.164 numbers, or number blocks only).
<vspace blankLines='1'/></t>
<t>use of any RRs (especially non-NAPTR) within or beyond
the e164.arpa namespace other than those needed to resolve
the domain names that appear in the 'replacement' URI.
</t>
</list>
</t>
<t>Rationale: some ENUM services try to exploit side effects
of the DNS that need to be explicitly discussed.
</t>
</section>
<section title='Other Sections (OPTIONAL)'>
<t>Other sections, beyond those required by the IETF and/or IANA, which
are cited or otherwise referenced here, MAY be included in an
Enumservice registration. These sections may relate to the specifics
of the intended usage of the Enumservice registration and associated
technical, operational, or administrative concerns.
</t>
</section>
</section>
<section title='The Process of Registering New Enumservices'>
<t>This section describes the process by which someone shall
submit a new Enumservice for review and comment, how such
proposed Enumservices shall be reviewed, and how they shall be
published.</t>
<t>The following <xref target='enum-service-reg-proc'/> depicts
an overview on the ENUM service registration process:
</t>
<figure anchor='enum-service-reg-proc'>
<!-- <preamble>ENUM Service Registration Process</preamble>-->
<artwork><![CDATA[
+--------------------+
| Step 1: |
| Read this document |
+--------------------+
V
+----------------------+
| Step 2: |
| Write I-D and submit |
+----------------------+
V
+--------------------------------------+
| Step 3: |<------+- - - -+
| Announce I-D to and solicit feedback | | |
+--------------------------------------+ |
| | |
V |
.^. | |
. . |
+------------+ . Feed- . +------------+ |
| Update I-D |<---------< back >------------>| Update I-D |
| and submit | non-sub- . results . substantial | and submit | |
+------------+ stantial . in: . changes +------------+
| changes . . needed |
| needed Y
| | no changes needed |
| V
| +-----------------------+ |
+------------>| Step 4: |<-------------+
| Request Expert Review | | |
+-----------------------+ |
| | |
V |
.^. | |
. . |
+---------+ . Expert . +------------+ |
| Appeal- |<-----------< review >------------>| Update I-D |-+
| process | rejection . results . issues | and submit |
+---------+ by expert(s) . in: . raised by +------------+
. . expert(s)
Y
| approval by expert(s)
V
+-----------------------------+
| Step 5: |
| Submit I-D for publication |
+-----------------------------+
]]></artwork>
</figure>
<section title='Step 1: Read This Document In Detail'>
<t>This document describes all of the necessary sections
required and recommended, makes suggestions on content, and
provides sample XML.
</t>
</section>
<section title='Step 2: Submit An Internet-Draft'>
<t>An Internet-Draft shall be submitted in accordance
with <xref target='RFC2026'>RFC 2026</xref> and <xref target
="I-D.rfc-editor-rfc2223bis"> RFC 2223bis </xref>, as well as
<xref target='RFC3761'>RFC 3761</xref>, and any other
documents applicable to the Internet-Draft process. This
Internet-Draft may be submitted as an "Individual
Submission".
</t>
</section>
<section title='Step 3: Request Comments from the IETF Community'>
<t>After the Internet-Draft has been published, the author(s)
shall send an email to <enum@ietf.org>, in which
comments on the Internet-Draft are requested.
</t>
<t>Suggested Format of Announcement:
<vspace blankLines='1'/>
<list style='empty'>
<t>To: enum@ietf.org</t>
<t>Subject: Comments on <I-D Name Here></t>
<t></t>
<t>The author is requesting comments and feedback from the
ENUM and IETF communities on the I-D listed below.</t>
<t></t>
<t>The I-D is available at: <INSERT URL to I-D ON IETF WEB
SITE HERE></t>
<t></t>
<t>Abstract of the I-D:</t>
<t><INSERT I-D ABSTRACT HERE></t>
<!-- <t><END OF EMAIL></t>-->
</list>
</t>
<t>The author(s) should allow a reasonable period of time to
elapse, such as two to four weeks, in order to collect any
feedback. The author(s) shall then consider whether or not
to take any of those comments into account, by making changes
to the Internet-Draft and submitting a revision to the I-D
editor, or otherwise proceeding. The following outcomes are
the ways the author(s) shall proceed, and it is up to the
authors' judgement as to which one to choose.
</t>
<section title='Outcome 1: No Changes Needed'>
<t>No changes to the draft are made, and the author(s)
proceed(s) to Step 4 below.</t>
<t>This outcome is recommended when the feedback received
does not lead to a new revision of the Internet-Draft.
</t>
</section>
<section title='Outcome 2: Changes, but no Further Comments Requested'>
<t>The author(s) update(s) the Internet-Draft and is/are
confident that all issues are resolved and do not require
further discussion. The author(s) proceed(s) to Step 4
below.
</t>
<t>This outcome is recommended when minor objections have
been raised, or minor changes have been suggested.
</t>
</section>
<section title='Outcome 3: Changes and Further Comments Requested'>
<t>The author(s) update(s) the Internet-Draft, and
proceed(s) to Step 3 above, which involves sending another
email to <enum@ietf.org> to request additional
comments for the updated version.
</t>
<t>This outcome is recommended when substantial objections
have been raised, or substantial changes have been
suggested.
</t>
</section>
</section>
<section title='Step 4: Request Expert Review'>
<t>In this step, the author(s) send(s) an email to the ENUM expert
review panel at <enumservice-expert-review@ietf.org>.
The Enumservice Expert Review Process shall then be followed
to conclusion. A later section of this document describes how
expert reviewers are selected (<xref target='ExpRevSel'/>) and
how the process of expert reviews takes place <xref
target='ExpRevProc'/>.
</t>
<section title='Outcome 1: Experts Approve Enumservice'>
<t>In this case, the proposed Enumservice has been endorsed
and approved by the experts, and the Internet-Draft proceeds
to Step 5 below.
</t>
</section>
<section title='Outcome 2: Experts Raise Issues, Changes Required'>
<t>The experts raise issues that prevent approval of the
proposed Enumservice. If they believe that, with changes,
the proposed Enumservice will be approved, then they may
recommend that the author(s) make changes and submit the draft
again. Depending on the nature of the changes the
Internet-Draft proceeds either to Step 4 or to Step 3 above,
which both involve update of the Internet-Draft and request
additional review and/or comments for the updated version.
</t>
</section>
<section title='Outcome 3: Experts Reject Enumservice'>
<t>The experts raise issues that result in rejection of the
proposed Enumservice. If they believe that, even with
changes, the proposed Enumservice will not be approved, the
process normally terminates. However, if the author(s)
disagrees(s) with this judgement, he has the possibility to
to appeal. In that case, the appeal process is initiated
according to <xref target='ExpRevAppeal'/>.
</t>
</section>
</section>
<section title='Step 5: Submit for Publication'>
<t>The Internet-Draft is submitted to be published as an
RFC. The IETF publication process includes IANA actions such
as adding the service to the IANA Enumservice
registry. According to <xref target='RFC3761'>RFC 3761</xref> an
Enumservice description can be published as either a Standards
Track, Best Current Practice (BCP), or Experimental RFC.
</t>
</section>
</section>
<section anchor='ExpRevSel' title='The Enumservice Expert Selection Process'>
<t>According to Section 3.2
of <xref target='I-D.narten-iana-considerations-rfc2434bis'></xref>,
experts are appointed by the IESG upon recommendation by the RAI
Area Directors. The RAI area directors are responsible that
there is always a sufficient amount of experts available.
<!-- The IESG may refine or change this ENUM experts' nomination process
at any time.-->
</t>
</section>
<section anchor='ExpRevProc' title='Enumservice Expert Reviews'>
<t>Generally, the expert review process of an Enumservice
MUST follow the guidelines
documented in section 3.3
of <xref target='I-D.narten-iana-considerations-rfc2434bis'></xref>.
</t>
<t>The expert SHOULD evaluate the criteria as set out in the draft
mentioned above, as well as consider the following:</t>
<list style='symbols'>
<vspace blanklines='1'/>
<t>Verify conformance with the ENUM specification (RFC 3761).
</t>
<t>Verify that the requirements set in
this document (<xref target='requiredSections'/>) are met. This
includes check for completeness and whether all the aspects
described in <xref target='requiredSections'/> are sufficiently
addressed.</t>
<t>If a use case is given by the author of the proposal (which
is RECOMMENDED), the expert SHOULD verify whether the proposed
Enumservice does actually fulfill the use case, and whether
the use case could be covered by an already existing Enumservice.
</t>
<t>Verify that the Enumservice proposed cannot be confused
with identical (or similar) other Enumservices already registered.
</t>
<t>If the Enumservice is classified according to
<xref target='classification'/>,
the expert MUST verify that the principles of the class in
question are followed.
</t>
<t>In case the Enumservice is not classified,
the expert MUST verify whether a
convincing reason for the deviation is
documented in the registration proposal.
</t>
<t>Investigate whether the proposed Enumservice has any negative
side effects on existing clients and infrastructure.
</t>
<t>If the output of processing an Enumservice may be used for input
to more ENUM processing (especially services returning 'tel' URIs),
the expert SHOULD verify that the author has adequately addressed
the issue of potential query loops.
</t>
</list>
</section>
<section anchor='ExpRevAppeal' title='Appeals against Expert Review Decisions'>
<t>Appeals follow the normal IETF appeal process as described in
section 7
of <xref target='I-D.narten-iana-considerations-rfc2434bis'></xref>
and section 6.5 of <xref target='RFC2026'>RFC 2026</xref>
<!--The RAI area directors are responsible for handling appeals
against decisions of the expert reviews. They can either assign
(a) new expert(s) or reject the appeal. The IESG may refine or
change this process regarding appeals at any time.-->
</t>
</section>
<!--
<section title='Example Enumservice Template with Comments'>
<section title='ENUM Service Registration for PSTN'>
<t>Enumservice Name: "pstn"</t>
<t>Enumservice Type: "pstn"</t>
<t>Enumservice Subtypes: "tel", "SIP"</t>
<t>URI Schemes: 'tel:', 'sip:'</t>
<t>Functional Specification:
<t>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.</t>
</t>
<t>Security Considerations: See Section 9.</t>
<t>Intended Usage: COMMON</t>
<t>Author(s):</t>
<t>John Doe <john.doe@example.com></t>
<t>Any other information the author(s) deem(s) interesting: None</t>
</section>
-->
<section title='Revision of Pre-Existing Enumservice RFCs'>
<t>Several Enumservice registrations, published via IETF RFCs,
already exist at the time of the development of this document.
The authors recommend that these existing registration documents
SHOULD be reviewed and, where necessary and appropriate, MAY be
revised in accordance with the recommendations contained herein.
All future Enumservice registrations SHOULD follow the recommendations
contained herein, where practical and applicable.
</t>
</section>
<section title='Extension of Existing Enumservice RFCs'>
<t>There are cases, where it is more sensible to extend an
existing Enumservice registrations rather than proposing a new
one. Such cases include adding a new subtype to an existing
type. Depending on the nature of the extension, the original
registration document needs to be extended (updates) or replaced
(obsoletes) <xref target ="I-D.rfc-editor-rfc2223bis"></xref>.
</t>
</section>
<section title='Security Considerations'>
<section title='Considerations regarding this Document'>
<t>Since this document does not introduce any technology or protocol,
there are no security issues to be considered for this memo itself.
<!-- However, this document provides general security considerations for
Enumservice registrations, which are to be referenced from document
defining or updating Enumservice registrations. -->
</t>
</section>
<section title='Enumservice Security Considerations Guideline'>
<t>Section 6 of RFC 3761 already outlines security considerations
affecting ENUM as a whole. Enumservice registration documents
do not need and SHOULD NOT repeat considerations already listed
there, but they SHOULD include a reference to that section.
</t>
<t>
ENUM refers to resources using preexisting URI schemes and protocols.
Enumservice registration documents do not need and SHOULD NOT repeat
security considerations affecting those protocols and URI schemes
itself.
</t>
<t>However, in case that the inclusion of those protocols and URI
schemes into ENUM specifically introduces new security issues,
those issues MUST be lined out in the 'Security Considerations'
section of the registration document.
</t>
</section>
</section>
<section title='IANA Considerations'>
<t>This document itself does not define a new protocol, and therefore
has no considerations for IANA. However, it contains a proposal for
the 'IANA Considerations' section of actual Enumservice registration
documents in <xref target='XML2RFCtempl'/>.
</t>
<t>Note: <xref target='regexample'/> is just an example of an
Enumservice registration. The Enumservice "foo" outlined there
MUST NOT be registered by IANA unless this memo is to be
published on April 1st.
</t>
</section>
<section title='Acknowledgements'>
<t>Lawrence Conroy provided extensive text for the Enumservice
Classification section. The authors also wish to thank Peter Koch
for his contribution to this document.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2026" ?>
<?rfc include="reference.RFC.3761" ?>
<?rfc include="reference.I-D.rfc-editor-rfc2223bis" ?>
<?rfc include="reference.RFC.3403" ?>
<?rfc include="reference.I-D.narten-iana-considerations-rfc2434bis" ?>
</references>
<references title='Informative References'>
<!-- <?rfc include="reference.RFC.3986" ?> -->
<!-- <?rfc include="reference.RFC.3764" ?> -->
<!-- <?rfc include="reference.I-D.ietf-enum-xmpp" ?> -->
<!-- <?rfc include="reference.RFC.3762" ?> -->
<?rfc include="reference.RFC.4238" ?>
<!-- <?rfc include="reference.RFC.3958" ?> -->
<!-- <?rfc include="reference.RFC.4002" ?> -->
<!-- <?rfc include="reference.RFC.3953" ?> -->
<?rfc include="reference.RFC.4969" ?>
</references>
<section anchor='XML2RFCtempl' title='XML2RFC Template for Enumservice Registration'>
<figure anchor='xml2rfc'>
<!-- <preamble>Template for XML2RFC</preamble>
<artwork src='layers.png'
alt='[picture of layers only]'>
-->
<artwork><![CDATA[
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr='full3978' docName='draft-mysurname-enum-foo-service-00' >
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<front>
<title abbrev='Foo Enumservice'>
IANA Registration for Enumservice Foo
</title>
<author initials='MyI.' surname='MySurname'
fullname='MyName MySurname'>
<organization abbrev='MyOrg'>
MyOrganization
</organization>
<address>
<postal>
<street>MyAddress</street>
<city>MyCity</city>
<code>MyZIP</code>
<country>MyCountry</country>
</postal>
<phone>Myphonenumber</phone>
<email>MyEmailAddress</email>
<uri>MyWebpage</uri>
</address>
</author>
<date month='ThisMonth' year='ThisYear' day='ThisDay'/>
<area>RAI</area>
<workgroup>ENUM -- Telephone Number Mapping Working Group</workgroup>
<keyword>ENUM</keyword>
<keyword>foo</keyword>
<keyword>bar</keyword>
<abstract>
<t>This memo registers the Enumservice "foo" with subtype "bar"
using the URI scheme "bar".
This Enumservice is to be used to refer from an ENUM domain
name to the foobar of the entity using the corresponding
E.164 number.
</t>
<t>A Client can use information gathered from a record using
this Enumservice to foo the bar.
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t><xref target='RFC3761'>E.164 Number Mapping (ENUM)</xref>
uses the <xref target='RFC1035'>Domain Name System
(DNS)</xref> to refer from <xref target='refs.E164'>E.164
numbers</xref> to <xref target='RFC3986'>Uniform Resource
Identifiers (URIs)</xref>.
</t>
<t>To distinguish between different services for a single E.164
number, section 2.4.2 of RFC 3761 specifies 'Enumservices',
which are to be registered with IANA according to section 3
of RFC 3761 and <xref target='RFCXXXX'>RFC XXXX</xref>.
</t>
<t>The 'foo' protocol is specified in ... and provides ...
</t>
<t>The Enumservice specified in this document refers from an
E.164 number to a foobar ... Clients use those foobars to foo
the bar.
</t>
</section>
<section anchor='terminology' title='Terminology'>
<t>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 <xref target='RFC2119'>RFC 2119</xref>.
</t>
</section>
<section anchor='reg' title='ENUM Service Registration - foo'>
<t>Enumservice Class: "Barfoo-based Enumservice"</t>
<t>Enumservice Name: "foo"</t>
<t>Enumservice Type: "foo"</t>
<t>Enumservice Subtypes: "bar"</t> <!-- Use N/A if none -->
<t>URI Schemes: "bar"</t>
<t>Functional Specification:
<list style='empty'>
<t>This Enumservice indicates that the resource identified is
a foobar ...
</t>
</list>
</t>
<t>Security Considerations: see <xref target='sec'/></t>
<t>Intended Usage: COMMON</t>
<t>Author(s): MyName MySurname, <myEmail></t>
<t>Any other information the author(s) deem(s) interesting:
None
</t>
</section>
<section anchor='examples' title='Examples'>
<t>An example ENUM record referencing to "foo" could look like:
<list style='empty'>
<vspace blankLines='1'/>
<t>$ORIGIN 9.7.8.0.9.7.8.9.0.9.4.4.e164.arpa.
<vspace blankLines='0'/>
@ IN NAPTR 50 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" .
</t>
<t>...
</t>
</list>
</t>
</section>
<section anchor='impl' title='Implementation Recommendations'>
<t>Implementers should consider that fooing the bar...
</t>
</section>
<section anchor='sec' title='Security Considerations'>
<t>As with any Enumservice, the security considerations of ENUM
itself (Section 6 of RFC 3761) apply.
</t>
<section anchor='secrecord' title='The ENUM Record Itself'>
<t>Since ENUM uses DNS - a publicly available database -
any information contained in records provisioned in ENUM
domains must be considered public as well. Even after revoking
the DNS entry and removing the referred resource, copies of the
information could still be available. </t>
<t>
Information published in ENUM records could reveal associations
between E.164 numbers and their owners - especially if URIs
contain personal identifiers or domain names for which
ownership information can be obtained easily.
For example, the following URI makes it easy to guess
the owner of an E.164 number as well as his location and
association by just examining the result from the ENUM lookup:
<vspace blankLines='1'/>
<list>
<t>http://sandiego.company.example.com/joe-william-user.vcf</t>
</list>
</t>
<t>However, it is important to note that the ENUM record itself
does not need to contain any personal information. It just
points to a location where access to personal information could
be granted. For example, the following URI only reveals the
service provider hosting the vCard (who probably even provides
anonymous hosting):
<vspace blankLines='1'/>
<list>
<t>http://anonhoster.example.org/file_adfa001.vcf</t>
</list>
</t>
<t>ENUM records pointing
to third party resources can easily be provisioned on purpose
by the ENUM domain owner - so any assumption
about the association between a number and an entity could
therefore be completely bogus unless some kind of identity
verification is in place. This verification is out of scope for
this memo.</t>
</section>
<section anchor='secresource' title='The Resource Identified'>
<t>
Users MUST therefore carefully consider information they
provide in the resource identified by the
ENUM record as well as in the record itself.
Considerations could include serving information only to
entities of the user's choice and/or limiting the comprehension
of the information provided based on the identity of the
requester.</t>
<t>(modify as appropriate - more about the specific
resource here)</t>
</section>
<section anchor='iana' title='IANA Considerations'>
<t>This memo requests registration of the "foo" Enumservice
with the subtype "bar" according to the template in
<xref section='reg'> of this
document and <xref target='RFC3761'>RFC 3761</xref>.
</t>
<t>...
</t>
</section>
<section anchor='dns' title='DNS Considerations'>
<t>This Enumservices does not introduce any
new considerations for the DNS.
</t>
<t>...
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3761" ?>
<?rfc include="reference.RFC.1035" ?>
</references>
<references title='Informative References'>
<reference anchor='refs.E164'>
<front>
<title abbrev='E.164 (02/05)'>The international public
telecommunication numbering plan</title>
<author initials='' surname='' fullname=''>
<organization abbrev='ITU-T'>ITU-T</organization>
</author>
<date month='Feb' year='2005'/>
</front>
<seriesInfo name='Recommendation' value='E.164 (02/05)'/>
</reference>
</references>
</back>
</rfc>
]]></artwork>
<!-- <postamble>End of Template for XML2RFC</postamble> -->
</figure>
</section>
<section title='Changes'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>draft-ietf-enum-enumservices-guide-06:
<list style='symbols'>
<t>bernie: Moved Terminology section in Template (now after Introduction)</t>
<t>bernie: Class is now part of the Enumservice registration and template</t>
<t>bernie: Individual Submission realaxed (comment Peter Koch)</t>
<t>bernie: updated vcard Ref (now RFC)</t>
</list>
</t>
<t>draft-ietf-enum-enumservices-guide-05:
<list style='symbols'>
<t>bernie/alex: added text for sections 'The Enumservice
Expert Selection Process' and 'The Process for Appealing
Expert Review Decisions'</t>
<t>bernie: added ASCII-art figure for registration process</t>
<t>bernie: adjusted registration process</t>
<t>jason: proposed registration process</t>
</list>
</t>
<t>draft-ietf-enum-enumservices-guide-04:
<list style='symbols'>
<t>bernie: added section about Extension of existing Enumservice RFCs</t>
<t>bernie: added open issue about future registration process</t>
<t>bernie: added category (bcp)</t>
<t>bernie: clean up in Security considerations</t>
<t>bernie: editorial stuff (mainly XML issues)</t>
</list>
</t>
<t>draft-ietf-enum-enumservices-guide-03:
<list style='symbols'>
<t>alex: moved terminology section</t>
<t>alex: removed note asking for feedback</t>
<t>bernie: added DNS consideration section</t>
<t>bernie: added Acknowledgments section</t>
<t>bernie: editorial stuff (nicer formating, fixing too long lines)</t>
<t>alex: added security considerations from vcard draft.</t>
</list>
</t>
<t>draft-ietf-enum-enumservices-guide-02:
<list style='symbols'>
<t>bernie: replaced numbers in examples by "Drama Numbers"</t>
<t>bernie: moved Change and Open Issues to Appendix.</t>
<t>bernie: major rewrite of section "6. Required Sections and
Information" incl. separating explanations and examples.</t>
<t>bernie: removed section 7 (was just a repetition of referencing to template)</t>
<t>bernie: extended Appendix with Open Issues.</t>
</list>
</t>
<t>draft-ietf-enum-enumservices-guide-01:
<list style='symbols'>
<t>alex: added Security Considerations section for the doc itself</t>
<t>alex: added IANA Considerations section for the doc itself</t>
<t>alex: added cookbook idea</t>
</list>
</t>
</section>
<section title='Open Issues'>
<t>[RFC Editor: This section should be empty before publication]
<list style='symbols'>
<t>Clarify the role of the expert(s) and the requirements
that apply for reviewing Enumservice registrations</t>
<t>Clarify what Process applies after Expert Review (before
publication)</t>
<t>Check whether alignment with RFC3761bis is needed
(e.g. Enumservice class)</t>
<!--
<t>Clarify, whether process for future Enumservice
registrations (after ENUM WG has been closed) belongs herein.</t>
<t>Clarify Status of document. Is BCP adequate?</t>
<t>Clarify dependencies and collisions with RFC 3761.
Should this document update RFC 3761?</t>
<t>Write something in the introduction about what the document
does not intend (no guarantee for surviving in the ENUM WG,
no change of the process itself).</t>
<t>Extension of an existing Enumservice (e.g. add new subtype
to existing type).</t>
<t>Write more about how to choose type/subtype/etc.</t>
<t>More about Subtype applicability.</t>
<t>Clarify Relation between Subtypes and URI schemes</t>
<t>Clarify mixing subtyped / non subtyped for a type</t>
<t>Explain Enumservice Name better</t>
-->
<t>Clarify IANA impact of this document.</t>
<!--
<t>Clarify whether experimental Enumservices should be
described herein.</t>
-->
<t>URL for template, so that it can be fetched without
header-/footer-lines of RFC.</t>
</list>
</t>
</section>
</back>
</rfc>
<!-- LocalWords: mailto sms PSTN vpim vCard XMPP xmpp imap sbar NAPTRs PII
-->
<!-- LocalWords: namespace RRSet wildcards RRs arpa stantial pstn MyAddress
-->
<!-- LocalWords: MyOrganization MyCity MyCountry Myphonenumber MyEmailAddress
-->
<!-- LocalWords: MyWebpage URIs XXXX MyName MySurname myEmail fooing ITU
-->
<!-- LocalWords: enumservices vcard formating subtyped
-->
| PAFTECH AB 2003-2026 | 2026-04-24 02:37:29 |