Internet Draft R. Stastny
Document: draft-stastny-enum-services-analysis-00.txt OeFEG
Category: Informational R. Brandner
Siemens
L. Conroy
Siemens
Expires: December 2002 June 2002
Analysis of the Usage of ENUM and ENUM Services
<draft-stastny-enum-services-analysis-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document analyzes the usage of the URI-schemes, services and
"enumservices" under discussion for the ENUM System. It tries to
combine the existing proposals for "enumservices" and proposes
examples of a compatible approach as a way forward for the definition
of the "enumservices" to be used in the ENUM trials planned.
Stastny Expires - December 2002 [Page 1]
Analysis of the Usage of ENUM and ENUM Services June 2002
Table of Contents
1. The Usage of ENUM..............................................2
2. Usage of the URI schemes only to identify services.............3
3. The Usage of "enumservices"....................................3
3.1 Simple URI Schemes............................................3
3.2 Combined URI Schemes and Services.............................4
3.3 Functional grouping of "enumservices".........................4
4. Examples of "enumservices".....................................5
4.1 The URI-schemes to be used in ENUM............................5
4.2 The Services to be used in ENUM...............................5
4.3 Simple and combined "enumservices"............................6
4.4 Functional groups of "enumservices"...........................7
4.5 Informational enumservices....................................8
5. Maximum Packet Size Considerations.............................8
6. Conclusion.....................................................9
7. Security Considerations........................................9
8. Acknowlegdements...............................................9
9. References....................................................10
10. Author's Addresses...........................................10
1. The Usage of ENUM
The ENUM System as defined in Draft RFC2916bis [2] allows an ENUM End
User to use the DNS to connect services on the Internet to an E.164
number. Each service is identified with an URI contained in a NAPTR
record, as described in the DDDS/URI Application in [3]. Any user on
the Internet may contact the ENUM End User by retrieving this
information via a DNS query.
The ENUM End User may indicate his preferred services to be contacted
by using the preference field in the NAPTR record. This may either be
the primarily preferred service to be contacted in general, or the
preferred service of similar or equivalent services listed.
Note: The order field in the NAPTR record is used if more than one
NAPTR record is necessary to evaluate the entries in the DNS.
Currently no example of the usage of such a construct has been given.
To indicate that a NAPTR record belongs to the ENUM System, the non-
optional parameter "E2U" in the service field is used. The "U" flag
in the flag field indicates, that this NAPTR record (rule) is the
last one and the final outcome of the evaluated regexp field will be
an URI.
A user on the Internet may now query the domain related to the E.164
number and retrieve the information contained within. In principle,
the querying user or the application used by the user needs to match
Stastny Expires - December 2002 [Page 2]
Analysis of the Usage of ENUM and ENUM Services June 2002
the services offered by the ENUM End User and eventually the given
preferences with the services he has available, is able to use and/or
intends to use.
2. Usage of the URI schemes only to identify services
As already mentioned, the NAPTR records are used to indicate services
and these services are identified with an URI in the regexp field.
Since an end-point indicated by a given URI may provide multiple
services, or the same URI scheme used in different NAPTR records may
provide different services, it is necessary to provide the querying
user with additional information.
This information may be given by additional parameters provided with
the URI, e.g. the svc parameter. To select the proper service to be
used, the user may retrieve the NAPTR records by querying the DNS for
the given E.164 related domain, evaluate all retrieved NAPTR records
to get the URIs and eventually the services (svc) and other
parameters provided with a given URI.
Some services may even require (or allow) to contact the end-point
given with the URI to negotiate the services required and/or
available.
The advantage of this "peek-ahead" approach is, that no additional
information is required in the NAPTR records, which reduces the size
of the NAPTR records and therefore the size of the information to be
transmitted or cached. Regarding the maximum UDP packet size
limitation see also section 6.
The disadvantage of this approach may be the additional processing
power and time needed to evaluate the URI fitting to the service
required and offered.
It is therefore proposed in RFC2916bis to indicate the service(s)
offered with a given NAPTR record in the service field of the NAPTR
record in addition to the mandatory "E2U".
3. The Usage of "enumservices"
3.1 Simple URI Schemes
The simplest proposal is, as hinted in the examples of RFC2916bis, to
indicate the scheme of the resulting URI of the regexp, by using the
same name for the enumservice as for the URI-scheme: +mailto, +sip,
+h323, +tel, etc.
Stastny Expires - December 2002 [Page 3]
Analysis of the Usage of ENUM and ENUM Services June 2002
Since some URI schemes may point to different services or one URI may
provide more then one service, additional information may be required
to select the proper NAPTR record and to eliminate false positives.
3.2 Combined URI Schemes and Services
It was therefore proposed to define a combination of the URI-scheme
and the service provided by this URI-scheme as enumservice, e.g.:
+telvoice, +telfax, +telsms, +sipvoice, +sipvideo, etc.
The names for these enumservices may be defined easily by using on
one side the names of the URI-schemes and on the other side the names
of the services, provided that the names used for the services are
different from the URI-schemes. Also the same service names shall be
used for the equivalent services with different URI-schemes. This
implies, that the names of this enumservices should be self-
explaining, even if the exact functions still have to be described in
in the URI-schemes and in the ENUM registration template.
All enumservices related to one URI may be defined in one template
(as defined in RFC2816bis) and preferably by the specialists and/or
workgroup dealing with this URI-scheme.
These two approaches of enumservice definitions could be used
together, since different names are used. So the enumservices +sip,
+tel, +mailto, +h323, etc. may be used in addition to the
enumservices +telfax, +telvoice, etc.
3.3 Functional grouping of "enumservices"
It was pointed out during the discussions, that some functional
grouping of the enumservices may be helpful for evaluating,
especially from the user point of view.
If this is not considered as an alternative, but as additional
information to the selection process, all three approaches to the
definitions of enumservices may exist and may be used in parallel.
So the definitions of the functional groups of services may be added
to the above mentioned simple and combined enumservices, provided
that different names are used e.g.:
+talk, +message, +info, +chat, +srs, +certificate, etc.,.
The functional groups of enumservices may be defined based on already
defined enumservices, re-using their definitions, so it may be not
necessary to define them based on the URI-schemes themselves, e.g.:
Stastny Expires - December 2002 [Page 4]
Analysis of the Usage of ENUM and ENUM Services June 2002
talk may be defined using the enumservice definitions +tel, +sip,
+telvoice, +sipvoice, +h323voice, etc.
4. Examples of "enumservices"
4.1 The URI-schemes to be used in ENUM
In principle any URI-Scheme may potentially be used in ENUM.
Nevertheless, at least for the ENUM trials and also for compatibility
of the ENUM client-SW, it does make sense to define the URI-schemes
valid for ENUM, e.g.:
mailto:
ldap:
smtp:
sip:
h323:
tel:
http:
https:
ftp:
sftp:
enum:
etc.
Of course, the list may be expanded at any time.
Note: For the use and purpose of the URI Scheme enum, see <draft-
stastny-enum-scenarios-00.txt>, section 7.2 [4].
4.2 The Services to be used in ENUM
If an URI-Scheme may provide different services, either separate or
in parallel, the services and how they are indicated need to be
defined. This shall be done in the definition of the URI-scheme.
In addition, there need to be defined, which of these services may be
used with ENUM.
The URI tel: may e.g. point to a voice-only phone number, to a fax-
only phone number, to a sms-only phone number, or to a phone number
providing all three services (see also [5]).
The definitions of the services are URI specific, so only examples
are given here:
Stastny Expires - December 2002 [Page 5]
Analysis of the Usage of ENUM and ENUM Services June 2002
voice, fax, sms, ems, mms, tdd, ivoice, etc. for tel:
mail, key, etc. for ldap:
voice, video, etc. for sip: and h323:
etc.
Remark: it should be noted, that e.g a sip- or h323-client may use
tel, sip and h323 URIs, if the application service provider allows
it. This may also be valid for other URI-schemes.
4.3 Simple and combined "enumservices"
Now for each URI-scheme the simple and/or combined enumservices are
defined.
For all URI-schemes providing (currently) only one service within
ENUM, the same name for the enumservice as for the URI-scheme may be
sufficient, e.g. "mailto".
For all URI-schemes allowing potentially more than one service to be
used, combined enumservices are defined e.g.:
telvoice, telfax, telsms, telems, telmms, telivoice, etc.
telrn, telcic, teldn, etc.
sipvoice, sipvideo, etc.
h323voice, h323video, etc.
ldapmail, ldapkey, etc.
etc.
Each block of enumservices related to one URI-scheme could be defined
in one template.
Note: the enumservices telrn, telcic and teldn are primarily required
for infrastructure ENUM-like Systems and may be defined separately
(see also [4]).
An open question is whether the definition of a simple enumservice is
required in addition, if combined enumservices are defined for an
URI-scheme and what the functional specification of such an simple
enumservice should be.
There are some choices of definitions possible:
a. All possible services of the URI-scheme are implemented with this
enumservice.
Stastny Expires - December 2002 [Page 6]
Analysis of the Usage of ENUM and ENUM Services June 2002
b. All possible services of the URI-scheme that are not implemented
with another enumservice explicitely are implemented with this
enumservice.
c. The services related to this URI-scheme may be negotiated.
d. A default service is defined in the functional specification of
the related enumservice.
e. The service is obvious together with the functional group used in
conjunction with this simple enumservice(see below)
There may even exist different approaches for different simple
enumservices, described in the functional description.
4.4 Functional groups of "enumservices"
The functional groups proposed so far are:
"talk" (or "phone" or "rtc") used with:
tel, telvoice, sipvoice, sipvideo, h323voice, h323video, etc.,
for any kind of two-way realtime mediastream communication.
"msg" (or "message") used with:
mailto, smtp, ldap, ldapmail, telsms, telems, telmms, etc.,
for any kind of store-and-forward or instant messaging application.
"info" (or "file") used with:
http, https, ftp, sftp, etc.,
to point to any kind of information, either on a web-page or at
document.
"cert" (or "certificate") used with
"ldap, ldapkey, etc.,
to point to any kind of certificate, eg. a public key.
Note: Is there a possibility to store a public key directly in DNS?
"srs" (or "enquire/inquire") used with:
sip, h323, etc.,
if the services are not defined explicitly, but need to be
negotiated.
"pres" (or "presence") used with:
sip, etc.,
for any kind of presence or location information.
"chat" (or "textchat") used with:
sip, etc.,
Stastny Expires - December 2002 [Page 7]
Analysis of the Usage of ENUM and ENUM Services June 2002
to be used for real-time text communication.
"streaming" (or "broadcast") used with:
rtsp, etc.,
for any kind of one-way streaming broadcast, e.g audio or video
broadcast. This may also be used for announcements.
"any" used with:
enum, or any other functional group, if a user wants to redirect all
or parts or the services to another number.
For each functional group a template needs to be defined, but since
these templates may refer to the already defined templates of the
simple and/or combined enumservices, the creation of these templates
may be simple.
This may also solve some of the above mentioned problems of the
definition of single-URI enumservices, e.g.:
a. a functional group enumservice may only be defined if a related
simple or combined enumservice exists.
b. a simple enumservice may be used, if it is selfexplaining together
with a functional group enumservice, e.g.: "E2U+talk+tel".
c. if the services are to be negotiated, the functional group
enumservice "srs" has to be used, e.g. "E2U+srs+sip"
4.5 Informational enumservices
Customers may require additional optional enumservices to tag certain
NAPTR records for specific use.
One example may be derived from the convention how to put different
phone numbers on a business card, e.g. "Home", "Office", "Mobile",
etc.
Therefore an enumservice field may look like "E2U+talk+sip+home" or
"E2U+msg+mailto+office"
5. Maximum Packet Size Considerations
DNS uses primarily UDP to transmit requests and responses. As per
RFC1035 [6] the maximum UDP packet size for DNS is 512 Octets.
Stastny Expires - December 2002 [Page 8]
Analysis of the Usage of ENUM and ENUM Services June 2002
The UDP max packet size limit for UDP has implications on two
parameters, which are not independent. Up to some 7 NAPTRs can be
transmitted in a single DNS response, dependent on how long the RR
is. The longer the NAPTR is the fewer NAPTRs RR can be put into a
domain, if UDP has be used. Thus, long enumservice fields like
"E2U+tel+telvoice+telvideo+telfax+telsms+telems+telmms"
are highly discouraged. In defining the enumservices for ENUM this
has to be taken into account.
The DNS UDP maximum packet size limit can be overcome by using TCP.
However using TCP additional latency is introduced due to
establishing a TCP connection prior to the data transfer.
6. Conclusion
This draft may show a way forward in the definition of enumservices,
at least for the planned ENUM trial period.
The examples of the enumservices given are compatible and usable in
the ENUM trials either independently or combined, even if finally the
experience of the ENUM trials may show, that not all of the
enumservices described here may be required or some combinations of
enumservices may be redundant.
The ENUM trials will also provide information on the number of NAPTR
RR and "enumservices" used by the typical ENUM End Users and if there
are any problems with the above mentioned packet size limitations.
7. Security Considerations
This document does not introduce new security implications other than
those associated with the ENUM Service as defined in Draft
RFC2916bis.
If there are specific security considerations related to an URI-
scheme, service or an "enumservice", this should be covered with the
definition of the URI-scheme or the "enumservice".
8. Acknowlegdements
The author would like to thank Rich Shockey, Patrik Faltstrom,
Michael Mealling, Andrew Zmolek and Clive Feather for their comments
and invaluable help.
Stastny Expires - December 2002 [Page 9]
Analysis of the Usage of ENUM and ENUM Services June 2002
9. References
1 Scott Bradner, RFC2026, "The Internet Standards Process รป
Revision 3," October 1996.
2 P. Faltstrom, "The E.164 to URI DDDS Application",
draft-ietf-enum-rfc2916bis-01.txt,
Work in Progress, March 2002.
3 M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database"
draft-ietf-urn-dns-ddds-database-08.txt,
Work in Progress, February 2002.
4 R. Stastny, "Scenarios for ENUM and ENUM-like Systems",
draft-stastny-enum-scenarios-00.txt,
Work in Progress, June 2002.
5 R. Brandner, "The 'tel:' URI 'svc' parameter",
draft-brandner-tel-svc-00.txt,
Work in Progress, June 2002.
6 P. Mockapetris, RFC1035, "Domain Names - Implementation and
Specification", November 1987.
10. Author's Addresses
Rudolf Brandner
Siemens ICN
Hofmannstrasse 51
Munich
Germany
Msg: <mailto:rudolf.brandner@icn.siemens.de>
Talk: <tel:+49-89-72251003>
Info: <http://www.siemens.com>
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
U.K.
Msg: <mailto:lwc@roke.co.uk>
Talk: <tel:+44-1794-833666>
Stastny Expires - December 2002 [Page 10]
Analysis of the Usage of ENUM and ENUM Services June 2002
Richard Stastny
OeFEG
Postbox 147
1103 Vienna
Austria
Msg: <mailto:richard.stastny@oefeg.at>
Talk: <tel:+43-664-420-4100>
Stastny Expires - December 2002 [Page 11]