SIST-TS ETSI/TS 102 172 V1.1.1:2005

SLOVENSKI STANDARD
01-januar-2005
Storitve in protokoli za napredna omrežja (SPAN) – Najmanjše zahteve za preskuse
vzajemne obratovalnosti evropskega ENUM
Services and Protocols for Advanced Networks (SPAN); Minimun requirements for
interoperability of European ENUM trials
Ta slovenski standard je istoveten z: TS 102 172 Version 1.1.1
ICS:
33.040.30 Komutacijski in signalizacijski Switching and signalling
sistem systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Services and Protocols for Advanced Networks (SPAN);
Minimum requirements for interoperability of
European ENUM trials
2 ETSI TS 102 172 V1.1.1 (2003-03)

Reference
DTS/SPAN-110112
Keywords
ENUM, interoperability
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 102 172 V1.1.1 (2003-03)
Contents
Intellectual Property Rights.4
Foreword.4
1 Scope.5
2 References.5
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.7
4 Introduction.8
5 General objectives of ENUM trials within Europe .9
6 ENUM trial interoperability .10
6.1 Constraints in national trials.10
6.2 Interoperability in ENUM trials .12
6.3 Application recommendations to facilitate trial interoperability.13
7 Administrative requirements for interoperability of trials.13
8 DNS requirements for interoperability of trials.14
9 Harmonization of the "ENUMservice" field in the NAPTR Records .14
9.1 Background to minimum requirements for NAPTR use .14
9.2 General conditions.15
9.3 Format and processing of NAPTR records.16
9.4 "ENUMservices" and associated URI Schemes .17
9.4.1 Minimum set of "ENUMservices".17
9.4.1.1 "ENUMservices" for Interactive Media-stream Exchange.17
9.4.1.2 "ENUMservices" for Discrete (non-session related) Messages .17
9.4.1.3 "ENUMservices" for Information Source .18
9.4.1.4 "ENUMservices" for Service Resolution Services.18
9.4.1.5 "ENUMservices" for Session-oriented Message Exchanges.18
9.4.1.6 "ENUMservices" for Instant Information Display - Announcement.19
9.4.1.7 "ENUMservice" for Redirection .19
9.4.2 Additional "ENUMservices".20
9.4.2.1 "ENUMservices" for Location Information .20
9.4.2.2 "ENUMservices" for Public Key Information .20
10 Processing of retrieved information by ENUM Clients .20
10.1 Generic ENUM Clients .20
10.2 ENUM enabled Application Clients.21
10.3 Examples of specific ENUM enabled Application Clients .21
10.3.1 ENUM enabled SIP Client.21
10.3.2 ENUM enabled H323 Client.21
10.3.3 ENUM enabled Email Client.22
10.3.4 ENUM enabled Web Browser .22
10.3.5 ENUM enabled FTP Client.22
10.3.6 ENUM enabled FAX Client.22
10.3.7 ENUM enabled SMS Client .22
10.3.8 ENUM enabled Location Client .22
Annex A (informative): Background to NAPTR Resource Records.23
Annex B (informative): Bibliography.26
History .27

ETSI
4 ETSI TS 102 172 V1.1.1 (2003-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
All published ETSI deliverables shall include information which directs the reader to the above source of information.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for
Advanced Networks (SPAN).
ETSI
5 ETSI TS 102 172 V1.1.1 (2003-03)
1 Scope
The present document contains general guidance on European ENUM trials and the specification for:
• The format, contents and meaning of the information in the NAPTR records that are held by the ENUM Tier 2
Nameserver providers and accessible by DNS.
• The ways in which ENUM client software should interpret and act upon information obtained from NAPTR
records.
The present document is intended to enable interoperability between ENUM trials that are organized in different
countries. This interoperability enables:
• The same ENUM client software to work with NAPTR records generated by different national trials and this
in turn will enable applications that use ENUM to access details of ENUM subscribers in more than one
country without additional modifications.
• Organizations to function as ENUM Registrars and ENUM Tier 2 Nameserver Provider in more than one
national trial.
The present document will therefore add economies of scope to the ENUM trials that will benefit ENUM subscribers,
trial participants, application service providers and ENUM users.
The present document is published as a Technical Specification (TS) at this stage as the contents are unproven. The
intention is to update and upgrade the present document in the light of the results obtained from the trials.
These requirements are therefore specified for the trial phase only, and as such impose no constraints on ENUM when
implemented on a commercial basis following completion of the trial.
Although the present document is focused towards European ENUM trials its use could facilitate interoperability with
ENUM trials in other parts of the world.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE 1: The present document is based additionally on "Work in Progress" at the IETF, documented in Internet
Drafts. This is especially valid for the syntax of the "ENUMservice" field in the NAPTR RR, which is
based on the definitions in Internet Draft , which will supersede
RFC 2916. Within the present document this Internet Draft is referenced as RFC 2916bis.
[1] ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[2] ETSI TS 102 051: "ENUM Administration in Europe".
[3] IETF RFC 1034: "Domain Names - Concepts and Facilities".
[4] IETF RFC 1035: "Domain Names - Implementation and Specification".
[5] IETF RFC 1123: "Requirements for Internet Hosts -- Application and Support".
ETSI
6 ETSI TS 102 172 V1.1.1 (2003-03)
[6] IETF RFC 1591: "Domain Name System Structure and Delegation".
[7] IETF RFC 1738: "Uniform Resource Locators (URL)".
[8] IETF RFC 2181: "Clarifications to the DNS Specification", Updates: 1034, 1035, 1123.
[9] IETF RFC 2182: "Selection and Operation of Secondary DNS Servers".
[10] IETF RFC 2255: "The LDAP URL Format".
[11] IETF RFC 2368: "The mailto URL scheme".
[12] IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax".
[13] IETF RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1".
[14] IETF RFC 2806: "URLs for Telephone Calls".
[15] IETF RFC 2818: "HTTP Over TLS".
[16] IETF RFC 2916: "E.164 number and DNS".
[17] IETF RFC 3261: "SIP: Session Initiation Protocol".
[18] IETF RFC 3401: "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive
DDDS".
[19] IETF RFC 3402: "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm".
[20] IETF RFC 3403: "Dynamic Delegation Discovery System (DDDS). Part Three: The Domain
Name System (DNS) Database".
[21] IETF RFC 3405: "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
Assignment Procedures".
NOTE 2: Also some of the above referenced URI Schemes are currently updated.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TS 102 051 [2], with the exception of
ENUM End User and ENUM Subscriber and the following apply:
NOTE: The term ENUM End user is not used within the present document, ENUM User and ENUM Subscriber
are defined as follows:
ENUM Subscriber: assignee of an E.164 number who has agreed to insert its E.164 number in the ENUM DNS-based
architecture and who requests population of an ENUM domain
NOTE: The ENUM subscriber has full control over the provision and content of the NAPTR Resource Records in
the ENUM Tier 2 Nameserver provider. The ENUM Subscriber is called ENUM End User in
TS 102 051 [2].
ENUM User: person or entity who is querying the ENUM DNS-based architecture using an ENUM-enabled
Application Client or an ENUM Client
NOTE: The ENUM User may be aware only of the application and not of the use of ENUM by the application.
In addition, the following terms and definitions apply:
Application Client: function that provides a user access to the Application Server, e.g. a VoIP client or e-mail client
Application Server: function provided by an Application Service Provider to communicate with the Application Client
ETSI
7 ETSI TS 102 172 V1.1.1 (2003-03)
ENUM Client: function that provides access to the DNS which will then return information in the form of NAPTR
records
NOTE: This could take several forms e.g. it may reside as client software on an intelligent terminal used directly
by the ENUM User or be network based, provided upstream as part of the facilities offered by an
Application Service Provider.
ENUM Client Supplier: entity supplying the ENUM Client
ENUM enabled Application Client: Application Client querying ENUM directly for NAPTR Resource Records
ENUM enabled Application Server: Application Server that is using ENUM Clients as part of their application,
e.g. an email server that translates phone numbers in the To:/RCPT fields into their ENUM stored mailto: values
"ENUMservice": parameter held in the Service Field of a NAPTR Resource Record associated with the ENUM DDDS
Application that indicates the class of functionality a given URI Scheme offers
NOTE: According to RFC 2916bis an "ENUMservice" must be registered with the IANA via a description in an
RFC.
Naming Authority Pointer Resource Record (NAPTR): The Naming Authority Pointer Resource Record is specified
in RFC 3403 [20] and a way to encode rule-sets in DNS.
Resource Record: element within the Domain Names System (DNS) containing a data item associated with a domain
name
Uniform Resource Identifier (URI): compact string of characters for identifying an abstract or physical resource
(e.g. an application)
NOTE: An URI is used within a NAPTR Resource Record to point to a specific application.
Uniform Resource Identifier (URI) Schemes: In the Uniform Resource Identifier (URI) definition (RFC 2396,
RFC 1738) there is a field, called "scheme", to identify the type of resource.
NOTE: URI Schemes are defined in RFCs and officially registered with the IANA
(see http://www.iana.org/assignments/uri-schemes).
The following registered URI Schemes are used within the present document:
ftp File Transfer Protocol   RFC 1738 [7]
http Hypertext Transfer Protocol   RFC 2616 [13]
mailto Electronic mail address   RFC 2368 [11]
sip Session Initiation Protocol   RFC 3261 [17]
tel Telephone     RFC 2806 [14]
ldap Lightweight Directory Access Protocol RFC 2255 [10]
https Hypertext Transfer Protocol Secure RFC 2818 [15]
In addition, the not yet registered URI Schemes "h323" and "ENUM" are used. The "tel" URI Schemes is also currently
undergoing modifications. For more information see the related Internet Drafts (work in progress).
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
+NNN Any E.164 number e.g. in the format +12345678900
CNAME Canonical Name DNS Resource Record
DDDS Dynamic Delegation Discovery System
DNAME DNS RR for non-terminal DNS Name Redirection
DNS Domain Name System
DNSSEC DNS SECurity extension
EDNS Enhanced Domain Name System
EMS Enhanced Message Service
FAX Facsimile Service
FTP File Transfer Protocol
ETSI
8 ETSI TS 102 172 V1.1.1 (2003-03)
H323 Protocol defined in ITU-Recommendation H.323
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IP Internet Protocol
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
LDAP Lightweight Directory Access Protocol
MMS Multimedia Messaging Service
NAPTR Naming Authority PoinTeR
NICNAME Unique Identifier ("handle") pointing to personal information in WHOIS
NRA National Regulatory Authority
PC-Phones Phone Clients running on Personal Computers
POSIX Portable Operating System Interface
PSTN Public Switched Telephone Network
RegExp Regular Expression
RFC Request For Comment
RIPE NCC Reseaux IP Europeens Network Control Center
RR (DNS) Resource Record
SIP Session Initiation Protocol
SMS Short Message Service
SW Software
URI Uniform Resource Identifier
VoIP Voice over IP
WHOIS A tool (program) to look up domain names and related information in a database
4 Introduction
Following initial work on the national ENUM trials that are either being planned or taking place in several European
countries, it has been recognized that additional benefits can be gained by facilitating interoperability of the various
trials. The present document aims to assist those countries who wish to expand their trials on a pan-European basis. It
proposes a minimum set of requirements for interoperability.
ENUM Trial interoperability would enable benefits to be gained by sharing experience of different administrative,
technical, operational and user aspects relating to the provision of ENUM capabilities between countries. Each country
will have its own particular architectural, administrative, security and authentication requirements along with its
particular implementation rules. Therefore linking the trials together will enable the various approaches to be evaluated
on a broad basis. This approach would also widen the range of applications and services available to end users as it will
enable them to access those provided by other trialists.
Without commonality of some aspects especially as the format of the NAPTRs designed to support applications,
attempts to link trials together are likely to result in difficulties when trying to access user information in more than one
country.
The results collected from pan-European trials should enable participants to gain valuable information and experience
that will assist when commercial deployment is considered at a later stage.
Involved parties are interested in carrying out trials for ENUM implementation in order to further the resolution of
technical, administrative and operation issues that may define the rules for the commercial deployment in that country.
In order not to presume any implementation solution, it is necessary that the minimum sets of requirements will not
limit the freedom of individual trials and the possibility to take different approaches.
The range of functional entities participating in a national trial depends on the choice of the administrative model in the
country involved. The preferred model in a given country, in turn, depends on, among other things, the national
arrangements for the management of domain names and E.164 numbers. TS 102 051 [2] outlines a number of options
for the administrative model and explains the functions of these roles. Nonetheless, most of the roles (functional
entities) listed are expected to be present in all European trials irrespective of the chosen administrative model:
• ENUM Tier 0 Registry
• ENUM Tier 1 Registry
• ENUM Tier 2 Nameserver Provider
ETSI
9 ETSI TS 102 172 V1.1.1 (2003-03)
• ENUM Registrar
• Application Service Provider
• Authentication Agency
• ENUM Subscriber
• ENUM User
For more general information on ENUM see TS 102 051 [2].
5 General objectives of ENUM trials within Europe
Although the objectives for ENUM trials undertaken within any European country must remain totally a national
matter, it should be recognized that additional benefits may be gained from shared experience if some of the general
objectives are shared. Such experience can be further enhanced if different implementations are linked together.
The following list of objectives identifies those that fall into this category and is recommended for trials that are linked
together within Europe in order to share their ENUM experience:
• Understanding the ENUM technology and its potential in providing new applications and services to
customers.
• Evaluating basic DNS infrastructure in relation to ENUM architecture models (for example ENUM Tier 1
Registry, ENUM Registrar, ENUM Tier 2 Nameserver Provider, Authentication and Validation procedures).
• Evaluate and refine the economic benefits and costs of introducing the ENUM capability.
• Exchange of information related to processes e.g. provide process, change process, cessation process, dispute
process.
• Increase the overall size and thereby the benefits of European trials.
• Provide feedback to the relevant standard bodies.
• Provide feedback to NRA/Governments.
Additionally the following list identifies aspects where additional benefits are likely to be gained, although their
inclusion should be dependent upon each specific case and should remain a national issue:
• Experience of registering the ENUM domain name related to the E.164 number and the entry of the necessary
data into DNS zone files.
• Validation initiated by the ENUM Registrar (that the correct delegation is made to the ENUM Subscriber).
• Gaining experience in provisioning ENUM delegation processes between ENUM Registrars and ENUM Tier 1
Registries.
• Exploring options for harmonized provisioning protocols across different countries as well as for unified
validation processes.
• Experience of sharing a common set of applications (e.g. VoIP) from a wider set of users.
ETSI
10 ETSI TS 102 172 V1.1.1 (2003-03)
6 ENUM trial interoperability
This clause analyses the issues of interoperability and the constraints on the different roles of the parties involved in
ENUM trials.
6.1 Constraints in national trials
The ENUM Subscriber in a national trial needs to have an E.164 number in the country concerned. Subscribers outside
the countries running ENUM trials have no possibility of involvement as they will not have an E.164 number that can
be supported in the .e164.arpa part of DNS. Since DNS is open, the data relating to all ENUM subscribers is visible to
any Application Service Provider or ENUM User in any country.
The ENUM Registrar acts as an agent to input the ENUM Subscriber's ENUM domain name (E.164 number) into the
ENUM Tier 1 Registry so that the Registry points to the correct ENUM Tier 2 Nameserver Provider in DNS. The
ENUM Registrar needs to be appointed or recognized by the ENUM Tier 1 Registry. The ENUM Registrar may also
have access to the ENUM Tier 2 nameserver to load, amend and delete NAPTR records in the format being used by the
country concerned, or the ENUM Subscriber may load, amend and delete the NAPTR records directly with the
nameserver themselves. Thus the ENUM Registrar's role is nationally specific, although the Registrar may be located
anywhere.
The ENUM Tier 2 Nameserver Provider holds the NAPTR records in the format being used by the country
concerned. The ENUM Tier 1 Registry for the country concerned needs to point to that nameserver. The nameserver
may be located anywhere.
The ENUM Client Supplier is tied to the format of the NAPTR records for the national trial because their ENUM
Clients need to be compatible with the NAPTR records. ENUM Clients may be embedded in Application Clients or
Application Server or may be run as simple stand-alone applications. If the NAPTR records have different formats for
different trials then different versions of the application would be needed to work with ENUM Subscribers in more than
one country.
The Application Service Provider may use ENUM Clients as part of their application. The Application Service
Provider using ENUM may be located anywhere, even in a country that is not running an ENUM trial at all. An
Application Service Provider not using ENUM is out of scope of this specification.
The ENUM User may be located anywhere but, depending on the application, may need special Application Client
software.
Figure 1 shows the relationships involved for two different national trials and for a common model of the relationship
between ENUM Tier 1 Registry, ENUM Registrar and ENUM Tier 2 Nameserver Provider. The ENUM Subscriber
establishes their ENUM entry through the ENUM Registrar who loads this information into the NAPTR records held by
the ENUM name server at Tier 2 level. (Alternatively the ENUM Subscriber may give this information directly to the
ENUM Tier 2 Nameserver Provider). The ENUM Registrar then asks the ENUM Tier 1 Registry to create NS records
for the ENUM Subscriber's ENUM domain name (associated with their assigned E.164 number) to point to the
nameserver that holds the NAPTR records. An ENUM User uses an ENUM Client, either directly or as part of an
ENUM enabled Application, to query the NAPTR records to find the information for the ENUM Subscriber with whom
they wish to communicate. After obtaining the NAPTR records the ENUM User or their application may use this
information to establish the communications between the ENUM User and the ENUM Subscriber.
An ENUM User may either use the ENUM Client directly or use an Application Client. The Application Client in turn
may either use the ENUM Client directly or forward the request to an Application Server, who may use an ENUM
Client to query ENUM on behalf of the user.
ETSI
11 ETSI TS 102 172 V1.1.1 (2003-03)
National Trial A National Trial B
ENUM Tier 1 ENUM Tier 1
Registry
Registry
Enters
ENUM ENUM
Updates
Enters
Registrar Registrar
ENUM ENUM
Updates
Tier 2 Name Tier 2 Name
Server Server
NAPTR records NAPTR records
ENUM
ENUM
Subscriber
Subscriber
Queries to NAPTR records
Any location
ENUM Client software
Communications Application Application Communications
established by application established by application
Server Client software
ENUM
User
Figure 1: Relationships involved for ENUM Trial Interoperability
Thus there are two constraints on interworking that can be removed by further action:
• Recognition of an ENUM Registrar in more than one national trial. This would enable an ENUM Registrar to
participate in multiple trials. It would not, however, allow the ENUM subscribers who are customers of the
ENUM Registrar in Trial A to be ENUM Subscribers in a Trial B if their E.164 number is in the national
numbering plan for the country of Trial A. In other words, participation as an ENUM Subscriber is linked to
the number range for which the ENUM Tier 1 Registry and ENUM Registrar are responsible.
• Lack of standardization of the NAPTR records, which:
- Ties ENUM Clients to specific national trials. Standardization would enable applications with a single
version of client software to work with all trials.
- Ties the operation of the name server on the Tier 2 level and its data entry and updating to specific
national trials. Standardization would facilitate the use of the same name server in more than one trial.
The present document focuses on the standardization of the NAPTR records because:
• Recognition of the ENUM Registrar is a non-technical and national matter. In the longer term, consideration
could be given to the potential benefits of harmonizing the interfaces between the ENUM Registrar and the
ENUM Tier 1 Registry and ENUM Tier 2 Name Server.
• Removing the constraint does not remove the limitation imposed by the E.164 number being linked to a
particular national numbering plan.
ETSI
12 ETSI TS 102 172 V1.1.1 (2003-03)
6.2 Interoperability in ENUM trials
Thus the main problem for interoperability arises from the lack of standardization of the "ENUMservice" field of the
NAPTR records. If different formats and information are used in different trials, then the client software will work with
only one national trial and this will limit the use of the applications or cause them to incur additional costs in running
multiple versions of client software.
The situation is summarized in the following table:
Constraint on Relationship to Benefits of Value of
location national trial standardizing the standardization of
NAPTR records NAPTR records
ENUM Subscriber Participation in a Trial participant The data held in DNS Medium
national trial is linked is usable by more
to having an E.164 ENUM clients
number in the number
range covered by the
trial and for national
numbers this implies
being located in the
country of the trial
ENUM Registrar Anywhere in the world Trial participant If the registrar updates Medium
the NAPTR records
Needs technical then it can work with
compatibility with other nameservers in more
trial participants than one country and
so can act as registrar
for more than one trial
ENUM Tier 2 Anywhere in the world Trial participant The nameserver can Medium
Nameserver Provider support trials in more
Needs technical than one country
compatibility with other
trial participants
Needs compatibility
with the ENUM client
software
ENUM Client Supplier Not relevant Not necessarily a trial Client software can High
participant work without
modifications in all trial
Client software needs countries
to be compatible with
the ENUM Tier 2
nameserver
Application Service Anywhere in the world Not necessarily a trial Application can be High
Provider that uses participant compatible with all
ENUM trials with the same
Needs to use client client software
software compatible
with the ENUM Tier 2
nameserver
ENUM User Anywhere in the world Not a trial participant Can use the Medium
application with a
Needs either: larger group of ENUM
Client software subscribers
compatible with the
ENUM Tier 2
nameserver, or
software compatible
with the application
ETSI
13 ETSI TS 102 172 V1.1.1 (2003-03)
6.3 Application recommendations to facilitate trial
interoperability
The following are proposed as minimum common application recommendations for ENUM trials:
• To make trials most beneficial, it is envisaged to have ENUM Subscribers who are subscribed to e-mail, web
and/or VoIP applications and who are provided with identifiers which may be used in the URI-Schemes listed
in clause 9.4.
• It is further envisaged to have ENUM users who are provided with generic ENUM Clients or ENUM enabled
Application Clients as described in clause 10. It is not necessary for ENUM Users to have support for all
applications.
7 Administrative requirements for interoperability of
trials
The following is set out as basic administrative requirements that have the objective of engendering a high level of
confidence between different implementations of ENUM trials:
For each trial:
• national ENUM domains SHALL have been delegated from Tier 0 level to Tier 1 level according to the
interim procedures determined by the ITU-T.
• operational and administrative processes SHALL be in place according to clause 11 of TS 102 051 [2].
• an open interface between ENUM Tier 1 Registry and ENUM Registrar
NOTE 1: Interface likely to be different in different trials.
• all ENUM domain names (associated with assigned E.164 numbers) inserted SHALL have been validated in
accordance with the principles in TS 102 051 [2].
• ability to insert as a minimum geographic numbers in ENUM.
• WHOIS type capability:
NOTE 2: WHOIS is a tool that is used to look up domain names and related information in a database. It is used
within gTLDs and ccTLDs Registries to look up e.g. second-level domain information. The primary use
is to look up the availability of a domain name. The additional information provides e.g. domain name
holder, administrative contact, technical contact, zone contact, billing contact, nameservers used and
unique identifiers pointing to personal information (NICNAME).
Within ENUM (e164.arpa) a WHOIS type capability SHALL be used to provide similar information for delegated
full ENUM domain names (associated with assigned E.164 numbers) at the ENUM Tier 1 Registry level. This is
considered as required during the trials and shall be harmonized. Whether all or parts of this information conforms
with the elements stated in the note above or is made publicly available is a national matter.
• Adequate data protection safeguards are essential in the interoperating trials. In countries that implement EU
legislation, trials SHALL implement procedures that ensure compliance with national laws corresponding to
the EU Data Protection Directives. In other countries, trials SHOULD implement procedures that are
consistent with the EU Data Protection Directives except where this conflicts with national laws
NOTE 3: All ENUM subscribers within the trials must be made aware that once the contents of their registration
are inserted within ENUM, they may be publicly available.
• all ENUM trials SHALL define policy objectives and SHALL adhere to the procedures defined for the
national ENUM trial.
ETSI
14 ETSI TS 102 172 V1.1.1 (2003-03)
8 DNS requirements for interoperability of trials
The following are proposed as minimum common DNS requirements for ENUM trials:
• For interoperability of European ENUM Trials, the global DNS server hierarchy SHALL be used, so they
should use public DNS servers within the normal hierarchy; these are ENUM Trials using delegations by
RIPE/NCC according to the interim procedures defined by ITU- and according to TS 102 051 [2] and the
present document.
• ENUM DNS Nameserver operation SHALL be implemented according to RFC 1034 [3], RFC 1123 [5],
RFC 1591 [6], RFC 2181 [8] and RFC 2182 [9].
• ENUM delegations at the ENUM Tier 1 Registry point to the ENUM Tier 2 name servers which must be
authoritative for that zone.
• Name servers MUST not run insecure name server software and SHALL be protected against security
penetration attacks.
• DNS Servers used in ENUM Trials are not required to support TCP requests
• To ensure a basic level of conformance, adherence to the following points is recommended:
- Name servers should have sufficient capacity to support reasonably high query rates.
- Name servers should be protected against denial of service attacks.
- Appropriate logging and audit trails should be established for name servers.
- Name servers should be installed in co-located facilities with 24x7 monitoring, backup power supplies,
etc.
9 Harmonization of the "ENUMservice" field in the
NAPTR Records
9.1 Background to minimum requirements for NAPTR use
As described and explained in annex A, there is not a single "ENUMservice" field yet defined according to RFC
2916bis in an RFC and registered with IANA. Even RFC 2916bis is still an Internet draft and not an RFC.
Therefore an ENUM trial needs to make assumptions about the "ENUMservice" fields and "URI Schemes" used with a
given ENUM application. If different ENUM trials are making independent assumptions, it may happen that different
and eventually incompatible assumptions are made. This may result in incompatible ENUM trial implementations.
To avoid this, a consistent set of "ENUMservices" fields are defined within the present document. Any ENUM trial and
ENUM Client SW implementing this set of "ENUMservices" fields is guarantied to be compatible to any other ENUM
trial and ENUM Client SW also implementing this set.
The "ENUMservice" fields defined in the present document will be forwarded to the IETF ENUM WG as Internet
drafts containing registration templates according to RFC 2916bis to be discussed and approved as RFCs for
registration of the "ENUMservice" fields with IANA.
A Registration Template needs to contain the following information.
ENUMservice Name:
Type(s):
Subtype(s):
URI Scheme(s):
Functional Specification:
Security considerations:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
ETSI
15 ETSI TS 102 172 V1.1.1 (2003-03)
Author:
Any other information that the author deems interesting:
Since the Internet Drafts forwarded to the IETF may be modified during the following discussion, there is no guarantee
that the "ENUMservices" finally registered with IANA are identical with the "ENUMservices" in the European trials as
specified within the present document.
On the other hand, the experience gathered during the trials may also lead to modifications of the "ENUMservices"
defined for the usage during the trials.
Consideration may be given to updating the present document after a certain time period if necessary and to align it to
the "ENUMservice" fields finally registered RFC with IANA, either to be used in a second phase of ENUM trials or
finally for a commercial application.
9.2 General conditions
The minimum requirements for interoperability are:
• ENUM clients SHALL assume that the DNS Infrastructure for ENUM is available in the domain e164.arpa.
• The ENUM domain names associated with any given E.164 number SHALL be accessible from any client
using the standard technical mechanisms specified in RFC 2916bis and RFC 1035 [4].
• The ENUM Subscribers participating in the ENUM Trial SHALL provide at least one URI (e.g. e-mail, web),
using any Application Service Provider.
• The ENUM client SHALL be able to query the domain evaluated for recordtype NAPTR.
• NAPTR records SHALL be formatted according to RFC 3403 [20]/RFC 2916bis and the "ENUMservice" field
SHALL be used as defined in the present document.
• The NAPTR Resource Records SHALL be understandable (and be capable of being processed) by any ENUM
Client. This has several aspects:
- The entity publishing the Resource Record and the entity querying the Resource Record SHALL have a
common understanding of the meaning stored in that Resource Record.
- To achieve this, within the ENUM trials a common (basic) set of "ENUMservices" is agreed that MAY
be expected within the service field of an ENUM NAPTR Record. The "ENUMservices" define also a
common (basic) set of URI Schemes.
- The list of "ENUMservices" and "URI Schemes" used is limited to the set defined in clause 9.4.
- This does NOT mean that every ENUM Client SHALL support all of the "ENUMservice" fields that are
in this set, but instead that it SHALL recognize the meaning of these values and common defined
behaviour (see note below) SHALL be provided for "ENUMservices" and URI Schemes which are not
recognized by the ENUM Clients.
Note that this list is a requirement for interoperation. However, it is perfectly valid for other applications to be
tested within individual Trials and thus for Resource Records indicating these applications to exist within an
ENUM domain that is part of such a Trial. As the content of the ENUM domain is physically accessible from
anywhere, an ENUM Client may receive Resource Records containing application indicators that it does not
support or recognize, complex RegExp fields, or even non-terminal NAPTRs.
Clients should be designed to expect receipt of such records. They should have a defined behaviour when
encountering Resource Records that they cannot understand, a defined behaviour when encountering Resource
Records that indicate service features that they cannot support, and defined behaviour when encountering
non-terminal NAPTRs or problems. It is important that an ENUM Client should be able to recognize a
complex RegExp field, and should not attempt to use the partially evaluated result if it does not support fully
regular expression processing.
• An ENUM client SHALL be able to convert an entered E.164 number in the format +NNN according to the
rules given in RFC 2916bis clause 2 into a domain name ending in e164.arpa.
ETSI
16 ETSI TS 102 172 V1.1.1 (2003-03)
• The DNS Resolver used by the ENUM Client will process any CNAME or DNAME Resource Records
transparently.
9.3 Format and processing of NAPTR records
• The NAPTR records SHALL be in the format as defined in RFC 3403 [20] and contain the following fields:
order, preference, flags, services, regexp and replacement (see annex A).
• For interoperability of the ENUM trials, the following simplifications are recommended:
- The ENUM clients MAY ignore all NAPTR rec
...