Internet DRAFT - draft-brandner-enumservices-compendium
draft-brandner-enumservices-compendium
ENUM Working Group R. Brandner
Internet-Draft Siemens
L. Conroy
Siemens
R. Stastny
OeFEG
Expires: March, 2003 September 13th, 2002
"A compendium of enumservice registrations"
<draft-brandner-enumservices-compendium-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.
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document includes a basic set of enumservice descriptions that
are intended for use in deployments of ENUM. These descriptions form
a set of enumservice registration requests, as laid out in section 3
of draft-ietf-enum-rfc2916bis-01.txt.
The enumservice names are 'talk', 'voice', 'ivoice', 'video', 'msg',
'fax', 'sms', 'ems', 'mms', 'email', 'chat', 'tp', 'im', 'info', 'web',
'ft', 'srs', and 'all'.
1. Background
ENUM is a system consisting of two main elements; it defines an algorithm
by which an E.164 number can be mapped to a domain name, together with a
means of storing URI information in domain space rooted within a reserved
domain label.
The URI information is stored within NAPTR Resource Records [1]. Their
overall structure and use with ENUM is defined in RFC2916-bis [2]. As
defined there, the service field of a NAPTR may have a set of one or more
enumservice elements. These enumservice elements are not defined in that
document; instead, the enumservices are described separately.
This current document specifies a set of such enumservices and requests
IANA registration of the enumservice identifiers "under" the ENUM service
tree, as laid out in section 3 of RFC2916-bis.
2. Introduction
An enumservice acts as a hint, indicating the kind of service with which
the URI constructed using the regexp field is associated. There can be
more than one enumservice included within a single NAPTR; this indicates
that there is more than one service that can be achieved using the
associated URI.
The common thread with this set of definitions is that they reflect the
kind of service that the end user will hope to achieve with the
communication session using the associated URI. They also do not require a
sub-field to further qualify them; the definition is complete with the
main enumservice tag.
Services
The set of services defined here is intended NOT to specify the protocol
or even method of connection that MUST be used to achieve each service.
Instead they define the kind of interactive behaviour that an end user
will expect, leaving the end system to decide (based on policies outside
the remit of this specification) how to execute the service.
There are a set of services that may be achieved using telephone
connections (where the associated URI scheme is likely to be 'tel:' as
described in [3]); several of these service can, however, be achieved
using other means.
For example, a voice call could be initiated by driving a local PSTN
interface, or by connecting to an Internet Telephony Gateway (using an IP
network connection) that in turn has a connection to the PSTN. It may be
that the destination end point described in the URI is not connected
directly to the PSTN but is instead a VoIP end point that is merely
identified using a telephone number. In these cases the same service (from
the end user's perspective) is achieved by using different methods of
connection.
It may matter to the end user whether or not their voice call is arranged
using a Voice over IP session or using a PSTN connection (for example,
there may be a cost to this choice), so it is recommended that the
querying User Agent terminal should report the choices to the end user.
However, this is a matter for local policy and is outside the scope of
this specification.
Service Categories
For ENUM to be successful, there is an implied cooperation between the
registrant who specifies the information to be stored within the ENUM
domain space and the querying User Agent that retrieves this data from the
DNS. When the registrant specifies the enumservice tag values, the User
Agent must share a common understanding of the enumservice tags. The
enumservice sub-fields act as a filter, and if the User Agent is
"interested in" one set of enumservice tags whilst the Registrant has
specified another (disjoint) set of tags, then the NAPTR containing these
will be filtered out of consideration.
It is possible for an enumservice tag to be too specific; if a querying
end user is interested in sending a message to a correspondent, then they
may not care whether this message is sent using email, or fax, or SMS
(Short Message Service) text, assuming that the equipment they use is
capable of sending a message using these services.
In this case, a "service category" that subsumes the more specific
services is appropriate; this category acts like one of the more specific
services and has its own unique tag; the behaviour differs in that it will
match both with the same tag but also with the individual services that
fall into the category. The querying end user can specify the service
category and this will match against a NAPTR that the registrant has
specified as supporting one (or more) of the specific services in that
category.
In the enumservices described in the rest of this document, the "specific"
services each fall into a discrete category; thus each category has its
own comprised services.
For each service description, the enclosing category into which it falls
is listed, whilst for each category, the comprised services are listed.
Other than this, each definition includes an initial description section,
a section on the expected client behaviour if the enumservice is selected
by the end system, a section on the URIs that may be associated with the
service or category, a definition of the tag string used to identify the
enumservice, and the security issues that have been considered for use of
the enumservice.
3. talk categorical enumservice
This enumservice indicates that the associated resource can be used for
interactive (media stream exchange) calls; it can be used to "talk" to the
owner.
3.1. Comprised Services
This category comprises three services. These are voice and its variant
ivoice, plus video. This implies that if 'talk' is listed by the end user
as being an "enumservice of interest" it will match with itself and also
with 'voice', 'ivoice', or 'video' if these are listed within a NAPTR in
the queried domain. Likewise, if the Registrant has listed only 'talk'
whist the end user has specified 'voice', 'ivoice', or 'video' as being
of interest, then again there will be a match.
3.2. Expected Client Behaviour
The end user, having selected the talk category as being of interest, will
expect their client agent to filter the NAPTRs to those that include
either this categorical service or the specific services that it implies.
Given that this category is concerned with interactive calls, the querying
client's agent should present the options available and supported locally
to the end user. This is particularly important for calls that are
delivered via a local PSTN connection, as there may well be a cost
involved.
Note also that, where this category is associated with a "tel:" URI, the
expected behaviour is to place a call using the URI. Although possible,
the end system SHOULD NOT use the E.164 number that is within the URI to
re-submit a request to ENUM. The ENUM DDDS Application describes the
standard method for re-submission; this is to mark the NAPTR as being
"non-terminal" (i.e. to have an empty flag field), with the resulting
processed replacement number being used in the "next round" of the domain
discovery process. In such non-terminal NAPTRs there will still be a
populated service field, and so this can be used to filter each returned
NAPTR record appropriately.
3.3. Appropriate URIs
This sub-section describes the URI-schemes for which this category would
be appropriate, together with a description of any special issues with
each URI scheme used with this category. In principle, the category can
be associated with any URI that is appropriate for one of its comprised
services.
Note that, although it is possible that VPIM voice messages or video clips
could be sent, this is NOT the meaning of the 'talk' category. Thus the
URI schemes appropriate for this enumservice category include only those
usable to exchange interactive media.
3.3.1. Use with "sip:" URI
This combination implies that the associated URI may be used to initiate
interactive telephony calls to the destination using SIP [6]. Note that
SIP has its own negotiation method within the protocol, so that the client
MAY be offered another kind of communication session after negotiation.
However, this combination gives more information to the querying user than
would be the case for the 'srs' enumservice category.
The implication of the NAPTR with the 'talk' and "sip:" combination is
that, if selected, the querying user can engage in an interactive call;
thus the registrant SHOULD include such an entry only for those cases
where this is possible.
3.3.2. Use with "tel:" URI
The talk category is one of the two main uses for the "tel:" URI [3]. In
this case, the querying client might use this to trigger a voice call via
local "dialer" software that controls a PSTN interface (such as a software
controlled telephone). If the client has no support for local PSTN
connection, then it may submit the "tel:" URI to a local SIP user agent,
if the user has a relationship with an external gateway provider that can
support "tel:" URIs as destination end points. However, a "tel:" URI is
intended for use where the destination party is connected via the PSTN or
a network that uses E.164 numbers natively, and by preference the client
should attempt to make a PSTN connection if possible.
Note that the "tel:" URI may include a 'svc' parameter (see [4]) that
specifies the teleservices the resource supports. The 'talk' category
implies either voice or video services may be used; if one of these is
specified in the 'svc' parameter then this defines which service can be
used. If there is no such parameter, or it lists both video and voice
as supported, then the client is able to choose.
However, it is recommended that voice be considered the default service
and the one to be attempted first, in lack of further information.
3.3.3. Use with "h323:" URI
In principle, interactive calls could be made using the H.323 set of
protocols. Within the ENUM system, this requires a URI-scheme to be
defined for this protocol set, but once this is done, the talk category
may be used with such an "h323:" URI.
3.4. Tag String
The unique enumservice tag string for the talk categorical service is
'talk'.
3.5. Security Issues
The security issues reflect those of its comprised services. Thus the
issues are discussed under the 'voice', 'ivoice' and 'video' enumservices.
4. voice service
4.1. Description
This indicates that the resource identified by the associated URI is
capable of being contacted to provide a communication session during
which interactive media streams carrying voice data can be exchanged.
4.2. Enclosing Service Category
This service falls into the 'talk' service category. Thus, if the voice
service is included either in the end user's list of "enumservices of
interest" or in the registrant's list of enumservices supported, it will
be matched with the category 'talk' where specified in the corresponding
list.
4.3. Expected Client Behaviour
The expected client behaviour on selecting this enumservice is to
use the URI to contact the remote resource identified by the associated
URI (either directly or indirectly) to initiate an interactive voice call.
4.4. Appropriate URIs
There are several URI schemes that are appropriate for use with the
voice service. These are "tel:", "sip:", and (potentially) "h323:".
In each case, the implication is that the resource identified with
the URI is capable of engaging in a voice call.
4.5. Tag String
The unique enumservice tag string for the voice service is 'voice'.
4.6. Security Requirements
The intent of this enumservice is to initiate a voice call. There may be
cost implications in this, and particularly where a particular method is
used to execute the service. For example, use of the GSTN may incur a cost
for the calling (and/or called) user. This cost may vary depending on the
destination and the teleservice invoked by initiating the voice call, and
the cost may be considerable (as in calls to "information" teleservices).
Where the NAPTR generates a "tel:" URI, this cost may not be known by the
end user a priori. The end user's expectation of cost may be conditioned
by the E.164 number that is input to the ENUM process rather than the
E.164 number contained in the "tel:" URI that is its result.
Thus it is important either to report the eventual E.164 number to the end
user so that they can decide whether or not to proceed with the session,
or to employ some pre-arranged policy by which the end system is aware of
the user's choices.
Where a "sip:" or "h323:" URI is generated, the situation may be more
complex; it is possible that the end user incurs a cost in proceeding
with a voice call even if the "first step" is carried using a VoIP
session over an IP network. With SIP, the initial negotiation included
in that protocol may result in a re-direction, providing a new URI that
is then processed further. Again, it is important to either present the
URI to the end user or to implement some pre-arranged policy.
Where the resulting URI holds an E.164 number, there is a risk of looping
if this is used to re-submit a query to the ENUM infrastructure. This
issue only arises where an associated "tel:" URI is present. To avoid this
risk, the E.164 number held in a "tel:" URI that is associated with a
NAPTR that results from an ENUM query SHOULD NOT be used to re-submit a
query to the ENUM infrastructure.
This risk is also present in the basic DDDS algorithm, as a non-terminal
NAPTR may either have a mis-configured replacement field that, when
processed, results in a loop, or a mis-configured regexp field that, once
processed, has a similar effect. The recommendation that a "tel:" URI
not be used to re-submit a query to ENUM removes one avenue for mistake
or attack.
5. ivoice service
5.1. Description
This is a variant on the voice service. It can be used as a convenient
way of indicating that the resource indicated by the associated URI is
connected to an IP network, and that it can be used to engage in a voice
call (i.e. it is otherwise identical in operation to the voice service).
5.2. Enclosing Service Category
This service falls into the 'talk' service category. Thus, if included
either in the end user's list of "enumservices of interest" or in the
registrant's list of enumservices supported, it will be matched with
the category 'talk' where specified in the corresponding list.
5.3. Expected Client Behaviour
The expected client behaviour on selecting this enumservice is to
use the URI to contact the remote resource identified by the associated
URI to initiate an interactive voice call.
In particular, if the end system is capable of using a Voice over IP
method of communication rather than delivering the call request to the
PSTN, then this may result in better voice quality (through minimizing
the number of media transcodings the voice traffic encounters). It acts
as a "hint" only, and can be considered otherwise identical to the voice
service, and can be matched against this.
5.4. Appropriate URIs
There are several URI schemes that are appropriate for use with the
ivoice service. These are "tel:", "sip:", and (potentially) "h323:".
In each case, the implication is that the resource identified with
the URI is capable of engaging in a voice call.
This service differs from the voice service only in that, in the case
of an end system that is capable both of initiating a call via a local
GSTN interface and using an IP connection to a service provider, the
ivoice service hints that the latter approach should be used.
Some service providers may use E.164 numbers natively, even though the
destination is actually an IP connected resource. If the end user has
an association with such a service provider, then they may choose to
initiate the call via that provider rather than attempting to place the
call via a local GSTN interface.
5.5. Tag String
The unique enumservice tag string for the ivoice service is 'ivoice'.
5.6. Security Requirements
The security issues for this enumservice are believed to be identical to
those for the voice enumservice.
6. video service
6.1. Description
This indicates that the resource identified by the associated URI is
capable of being contacted to provide a communication session during
which interactive media streams carrying video data can be exchanged.
6.2. Enclosing Service Category
This service falls into the 'talk' service category. Thus, if included
either in the end user's list of "enumservices of interest" or in the
registrant's list of enumservices supported, it will be matched with
the category 'talk' where specified in the corresponding list.
6.3. Expected Client Behaviour
The expected client behaviour on selecting this enumservice is to
use the URI to contact the remote resource identified by the associated
URI to initiate an interactive video call. For further details, see the
specific comments in the URI section, next.
6.4. Appropriate URIs
Several URI schemes may be used with this service. These are "sip:",
potentially "h323:", and "tel:". If a URI has been included within a
NAPTR indicating this service, then it can be assumed that the resource
so identified is capable of exchanging video data.
In the "tel:" case, the PSTN-based video teleservice also includes a
channel for voice communications, so that this enumservice, when it
occurs with a "tel:" URI, can be assumed to provide voice as well as
video communications.
This is not necessarily the case for "sip:" and "h323:", where the
registrant is asserting only that the resource identified is capable of
supporting video communications. Whether or not this resource also
supports voice media exchange will be uncovered during the negotiation
phase associated with those protocols.
6.5. Tag String
The unique enumservice tag string for the video service is 'video'.
6.6. Security Requirements
The security issues for this enumservice subsume those for the voice
service.
In addition, if the associated URI addresses a remote resource that is
capable only of providing video stream exchange, there MAY be a privacy
issue. Where voice calls are to be initiated, it is normal to alert the
called user; however, for video only exchanges, this is less common.
If contact addressing information is published within ENUM domain space,
then it is available globally, and there is an implication that this
addressing information can be used to initiate a video call from anywhere.
Thus it is important that the registrant is aware of the configuration of
their equipment and that, having told everyone how to contact their video
camera, this information may be used to make such a call.
7. msg categorical service
7.1. Description
The msg enumservice is intended to indicate that the associated resource
is capable of receiving a discrete (non-session related) message or
document. This category may be selected by a querying client if they want
to deliver a message (such as a Fax) to a correspondent.
7.2. Comprised Services
This category comprises the 'fax', 'sms', 'ems', 'mms' and 'email'
services. Thus, if either the Registrant or the user lists one of these
services as being supported or of interest, whilst the other lists the
'msg' enumservice, then these lists will match.
7.3. Expected Client Behaviour
When the end user selects the msg category as being of interest and
there is a match within the queried domain, the URI that results from
regexp processing of the NAPTR can be used as the destination address
of a remote resource that is capable of receiving a (non-session related)
message. Thus the end system can initiate a connection to that resource
and can transfer a message or document to it.
The detailed end system behaviour depends on the associated URI scheme.
This is described in more detail under the Appropriate URIs sub-section.
There are two main behaviours; if the URI scheme is "mailto:" (defined
in [5]) then the behaviour will be similar to that of the 'email' service.
However, if the URI scheme is "tel:" then the end system may have to
evaluate the URI in order to choose which program (and communication
method) it must activate.
The "tel:" URI can include a 'svc' parameter. If so, this parameter value
can identify the kind of teleservice the resource supports. This might be
'fax', or 'sms', 'ems', or 'mms'. If there is no such parameter, then
Fax service may be assumed to be "the default", and a fax program can be
started using the associated URI as the destination address. Only if the
svc parameter exists and includes 'sms', 'ems', or 'mms' should an attempt
be made to send such a message towards the remote terminal.
7.4. Appropriate URIs
As just mentioned, there are two URIs associated with this category; these
are "tel:" and "mailto:".
7.5. Tag String
The unique enumservice tag string for the talk categorical service is
'msg'.
7.6. Security Issues
The security issues reflect those of its comprised services. Thus the
issues are discussed under the 'fax', 'sms', 'ems', 'mms', and 'email'
enumservices.
8. fax service
8.1. Description
This indicates that the resource identified by the associated URI is
capable of being contacted to provide a communication session during
which facsimile documents can be sent.
8.2 Enclosing Service Category
This service falls into the 'msg' service category. Thus, if included
either in the end user's list of "enumservices of interest" or in the
registrant's list of enumservices supported, it will be matched with
the category 'msg' where specified in the corresponding list.
8.3. Expected Client Behaviour
The expected client behaviour on selecting this enumservice is to
use the URI to contact the remote resource identified by the associated
URI to initiate an interactive fax call, during which it can send
documents to that remote resource.
8.4. Appropriate URIs
There is one URI scheme that is appropriate for use with the fax service.
This is "tel:".
Under some circumstances, it may be possible to use another URI scheme to
send a fax document, such as "sip:", (potentially) "h323:", or even
"mailto:". However, these schemes are not considered in this document.
8.5. Tag String
The unique enumservice tag string for the voice service is 'fax'.
8.6. Security Requirements
There are similar security concerns here to those associated with voice.
9. sms service
9.1. Description
This indicates that the resource identified by the associated URI is
capable of receiving a message using the Short Message Service (SMS).
9.2. Enclosing Service Category
This service falls into the 'msg' service category. Thus, if included
either in the end user's list of "enumservices of interest" or in the
registrant's list of enumservices supported, it will be matched with
the category 'msg' where specified in the corresponding list.
9.3. Expected Client Behaviour
The expected client behaviour on selecting this enumservice is to
use the URI to contact the remote resource identified by the associated
URI to send a message using SMS. For further details, see the
specific comments in the URI section, next.
9.4. Appropriate URIs
Only the "tel:" URI scheme may be used with this service. Potentially
the "sip:" or "mailto:" schemes might be used, IF the end user has a
relationship with a service provider that can gateway to an SMS-capable
destination. Such gateway services are not specified in this document.
If a URI has been included within a NAPTR indicating this service, then
it can be assumed that the resource so identified is capable of receiving
and processing SMS messages.
9.5. Tag String
The unique enumservice tag string for the SMS service is 'sms'.
9.6. Security Requirements
The security issues for this enumservice subsume those for the voice
service.
There is a further issue with privacy. ENUM is a globally accessible
system, and indication that a resource is used only for sms may expose
the fact that the registrant may have hearing difficulties.
10. ems service
10.1. Description
This indicates that the resource identified by the associated URI is
capable of receiving "enhanced message service" (EMS) messages. This
is a variant on SMS, and shares many features with it.
10.2. Enclosing Service Category
This service falls into the 'msg' category. Thus it can be matched with
an entry of 'msg' in the corresponding list of enumservices supported or
"of interest". In addition, support for EMS implies support for SMS as
EMS is a superset of the basic Short Message Service. Thus if EMS is
shown as a service supported by a registrant's resource, then it will
match with SMS if that is included in an end users list of "enumservices
of interest".
10.3. Expected Client Behaviour
On selecting this enumservice (and its enclosing NAPTR) the client is
expected to contact the remote resource (indirectly) to send an Enhanced
Message to it, using the associated URI to address the destination.
However, the end system MAY report to the user that SMS is available at
the remote resource even though the user has selected EMS as being of
interest - SMS is a sub-set of EMS and so may form a valid communication
method.
10.4. Appropriate URIs
The EMS service is a superset of SMS, and also may only be used with a
"tel:" URI.
10.5. Tag String
The unique enumservice tag string for the EMS service is 'ems'.
10.6. Security Requirements
The security issues are identical to those for the SMS enumservice.
11. mms service
11.1. Description
This indicates that the remote resource identified by the associated URI
is capable of receiving Multimedia Messaging Service (MMS) messages. In
this specification, it is assumed that the destination is connected to a
Mobile Service Provider and has an MMS-capable terminal.
Current deployments of MMS allow a Multimedia Message to be sent to a
destination email address via a Service provider operated gateway.
They also allow MMS messages to be sent when these are addressed to
terminals that can only receive SMS messages; the MMS message is processed
and stored at a Gateway, with a notification SMS message being sent to the
intended destination along with authorisation codes for access to the
storage portal. These are part of a developing infrastructure, but this
service is intended solely to indicate that the remote resource is capable
of receiving an MMS and of processing it itself.
11.2. Enclosing Service Category
This service falls into the 'msg' category. This means that it will match
against an entry in the corresponding service list that holds 'msg'.
Where indicated in a NAPTR, the mms service will also match against EMS
and SMS services requested by the end user, as MMS-capable terminals can
process both Enhanced and Short Message Service messages.
11.3. Expected Client Behaviour
When this service is selected by the end user, the end system is expected
to use the associated URI to address the remote resource to transfer an
MMS message (via the local Service Provider's MMS Service Centre) to the
destination device.
11.4. Appropriate URIs
This document considers only a remote destination that is an MMS-capable
mobile terminal. At present these are addressed using E.164 numbers, so
that the only appropriate URI that can be associated with this service is
the "tel:" URI.
In future, this may need to be re-considered, as the MMS architecture is
still under development and the current documents suggest that ENUM may
be used to expand the possible list of addressing modes. It is not yet
clear how the gateway systems will be developed, so that email addressing
may allow other URI schemes to be used later.
11.5. Tag String
The unique enumservice tag string for the MMS service is 'mms'.
11.6. Security Requirements
The security issues are identical to those for the SMS enumservice, when
used with a "tel:" URI. If other methods are used to deliver MMS messages,
then there may be further issues. As the MMS architecture (and way in
which these messages can be delivered) becomes clear with deployment,
this may need to be re-considered.
12. email service
12.1. Description
This service indicates that a remote resource can be addressed by the
associated URI in order to send emails.
12.2. Enclosing Service Category
This service falls into the 'msg' service category. Thus, if included
either in the end user's list of "enumservices of interest" or in the
registrant's list of enumservices supported, it will be matched with
the category 'msg' where specified in the corresponding list.
12.3. Expected Client Behaviour
If the end user system has selected the email service, then it is expected
to use its chosen local application to send an email towards the remote
email address held in the "mailto:" URI.
Note that the inclusion of this service in a NAPTR implies that the
registrant's resource is capable of receiving an email; the connection
method and protocol chosen by the registrant and by the sending end user
need not be related.
For example, the registrant may have access to a Service Provider portal
that displays incoming emails in a Web browser window, whilst the sender
uses a proprietary scheme like MAPI to deliver the mail to their local
server. Assuming that the destination is capable of receiving SMTP emails,
then this service will function.
12.4. Appropriate URIs
This service is associated only with the "mailto:" URI.
12.5. Tag String
The unique enumservice tag string for the email service is 'email'.
12.6. Security Requirements
If a registrant populates their domain with a NAPTR indicating this
service, then, as ENUM is a globally accessible system, this listing
may be harvested by "junk email" senders. Thus the registrant should
be aware that such a listing is likely to expose them to a great deal
of junk email.
13. chat categorical service
13.1. Description
This service category indicates that the remote resource is capable of
engaging in chat sessions (i.e. session-oriented message exchanges). It
differs from the 'msg' category in that this category implies a session
-oriented message exchange, whilst 'msg' implies a discrete message can
be sent to the resource at this contact address.
13.2. Comprised Services
There are two services that are included within this category. These are
the 'tp' and 'im' services. This means that, if an end user has indicated
interest in the chat category, then this will match with a NAPTR that
includes either the 'tp' or 'im' service tags (as well as with itself).
Similarly, if the end user has registered an interest in a 'tp' or 'im'
session but the registrant lists the 'chat' category, then this will match
as well; thus the end system may have to carry out further evaluation of
the NAPTR to decide if it is appropriate.
13.3. Expected Client Behaviour
The use of a category can imply some further evaluation is needed.
If the registrant lists only the chat category within a NAPTR whilst
the end user has specified either of the enclosed services, then the
end system may need to evaluate the associated URI to decide if they
have local support for this protocol and so can use it for their
communication session.
Conversely, if the end user has specified only that they are interested
in a chat session, whilst the registrant has specified support for
either 'tp' or 'im', then as the end system is aware of its capabilities,
it can decide without further evaluation whether or not this NAPTR is
appropriate.
Finally, if both end user and registrant have specified only the
chat category, then the end system must evaluate the NAPTR to decide
if the resulting URI matches its capabilities for protocol handling.
It is possible to duplicate the URI scheme string as the sub-field for
this categorical enumservice as a convenience for the end system, so
avoiding the regexp processing step before the usability of the NAPTR
can be decided. This is optional, but should be considered by registrants
when populating their domain with NAPTRs.
13.4. Associated URIs
This category matches with the services it comprises. Thus, it may be
encountered with any of the URIs that the 'tp' or 'im' services may
use.
13.5. Tag String
The unique enumservice tag string for the chat service category is 'chat'.
13.6. Security Requirements
The security issues for this category include those of the services it
comprises. This category may be chosen as a way of obscuring the presence
of a textphone resource. Given the simple evaluation mentioned in the
Client Behaviour section above, this is not particularly opaque, but it
may make the registrant more comfortable with a listing in the globally
accessible ENUM infrastructure.
14. textphone service
14.1. Description
This service indicates that a remote resource addressed by the associated
URI is capable of involvement in a textphone session. This is a group of
systems that use the telephone network to transfer character data between
compatible terminals. These are commonly used by users who have hearing
problems.
14.2. Enclosing Service Category
This service falls into the chat category. This means that if either the
Registrant or the end user lists 'tp' whilst the corresponding person
lists 'chat', a match will be considered to occur.
14.3. Expected Client Behaviour
When this service is selected by the user, the end system can activate
its local textphone terminal and initiate a call to the remote terminal
addressed using the associated URI.
14.4. Appropriate URIs
Textphone systems all use the telephone network, and so the appropriate
URI is "tel:".
There are several kinds of textphone in use. For example, in the United
Kingdom, the variant is the 'minicom' system, whilst elsewhere there are
systems that conform to the "Telecommunications Device for the Deaf" (TDD)
scheme. The "tel:" URI can include a svc parameter, and one of the values
for this parameter is 'tdd'. This can be used to indicate that the remote
resource interoperates to this system.
[Note - it is intended to update the specification document for the
"tel:" 'svc' parameter to include other values to help delineate
between the different textphone systems - any help in identifying
the discrete textphone systems in use would be appreciated]
Thus, it may be necessary for the end system to evaluate the URI before
it can be sure whether it supports the particular textphone system
"advertised" in the NAPTR.
14.5. Tag String
The unique service tag string for the textphone service is 'textphone'.
14.6. Security Requirements
Textphone terminals tend to be dedicated devices, and so there do not
seem to be many security concerns (from an Internet perspective).
However, there may be a privacy issue. A registrant may not feel
comfortable in specifying this service is a directory that is globally
accessible, even if they are willing to indicate support for this service
in other places. Thus, under no circumstances should they be forced to
list this capability.
One option is to obscure this slightly by being less specific in the
services listed in the NAPTRs; thus, the 'chat' category might be listed
instead of the more specific 'tp'. Such a choice adds no security at all,
but may be considered preferable by the Registrant.
15. im service
15.1. Description
This service indicates that the remote resource is capable of engaging in
a session-oriented "instant message" exchange.
15.2. Enclosing Service Category
This service falls into the chat category. Thus if one party lists this
service whilst the other lists the chat category, there will be a match.
15.3. Expected Client Behaviour
If this service is selected by the user, then their end system can try
to initiate an instant messaging session to the remote messaging entity
addressed by the associated URI.
15.4. Appropriate URIs
At present, the only URI scheme that is appropriate for this service is
"sip:", as specified for the SIMPLE instant messaging scheme.
As other (session-oriented) messaging URI schemes are standardised, so the
user might expect their end system to evaluate the URI and decide whether
or not this scheme can be supported.
Note that the listing of an im service within a NAPTR does not indicate
whether or not the registrant (or their terminal) is actually available
for an instant messaging session at any given time. The particular IM
protocol will include its own procedures to initiate the session.
15.5. Tag String
The unique enumservice tag string for the im service is 'im'.
15.6. Security Requirements
The inclusion of a listing within the ENUM system does not seem to add
new security issues over those for any use of instant messaging.
16. info categorical service
16.1. Description
The info enumservice indicates that the associated resource can act as a
source for information. It acts as the "opposite" of the msg enumservice,
in that this indicates a source for data whilst that indicates a sink for
data.
16.2. Comprised Services
The info category comprises the services 'web', 'ft'. This means that, if
either of these is selected by the end user (or listed by the registrant)
then there will be a match with 'info' if it is within the corresponding
list.
16.3. Expected Client Behaviour
The 'info' enumservice is used by the registrant to indicate to potential
correspondents a source of information. The implication for a client is
that the registrant will allow any data indicated by the URI to be passed
to the client.
The end system may have to perform further evaluation of the associated
URI to decide whether or not it can support the URI scheme. As an option,
the registrant may choose to duplicate the URI scheme tag by using this as
the content of the "protocol" sub-field of this enumservice field; doing
so may allow the end system to select the appropriateness of the NAPTR
without performing a regexp operation.
Note that one use of this enumservice is to indicate an announcement or
information line. This is particularly convenient when used with the
"tel:" URI, but might be used with other URI schemes. However, it may
require further evaluation of the associated URI before the appropriate
action can be performed. The "tel:" URI may include an 'svc' parameter
(described in [4]), and this may need to be evaluated before appropriate
action can be performed.
Note also, an entry of this kind states that information is available
from this URI. It does not guarantee access to everyone. The client may
be called on to authenticate itself before access is granted.
16.4. Appropriate URIs
This enumservice can be used with several URI schemes. The behaviour in
these cases is listed next.
16.4.1. Use with an "http:" or "https:" URI
This will perform identically to the 'web' enumservice.
16.4.2. Use with an "ftp:" URI
This will perform identically to the 'ft' enumservice.
16.4.3. Use with a "tel:" URI
This combination may seem strange at first, but might be used where a
recorded announcement or "information line" can be reached by dialling a
particular telephone number. This is not an interactive call in that the
recording is being played to the client rather than the client talking
with a correspondent.
From the perspective of client software, it seems likely that this
combination will be treated very similarly to a normal 'talk' enumservice;
the difference lies in the user and registrant's intent for this contact
and the communication that will result.
16.5. Tag String
The unique enumservice tag string for the info category is 'info'.
16.6. Security Requirements
Security issues for this category have not been fully analysed yet.
Some issues are immediately clear, however, when it is used with certain
URI schemes.
For example, when used with the "tel:" URI, it is important to display
the destination URL to the querying end user before acting on it.
Telephone information services are often charged at a higher rate from
other calls, and so the end user should have the chance to confirm the
action.
17. web service
17.1. Description
This enumservice indicates that the remote resource identified by the
associated URI is capable of providing documents when contacted using web
protocols; in short, it acts as a web server for the data addressed by the
associated URL.
17.2. Enclosing Service Category
This service falls into the 'info' category. This means that if included
in either the end user's list of "services of interest" or in the listings
specified by the registrant, it will match with the 'info' category in the
corresponding list.
17.3. Expected Client Behaviour
When the web service is selected, the end system can use a web protocol to
contact the remote resource addressed by the content of the associated URI.
In practice, this normally means that a local Web Browser will be activated
with the URI as the target to be returned.
17.4. Appropriate URIs
This service is associated with the two URI schemes "http:" and "https:".
If the end system is not capable of dealing with an SSL/TLS session, it
may be necessary for it to evaluate the associated URI before deciding
whether or not it can support the service. Whilst this is not an issue for
personal computers, it may well be an issue for small devices (such as
mobile phones).
It is possible for the registrant to duplicate the URI scheme tag as the
content of the 'web' enumservice protocol sub-field. In so doing, the
end system would be saved from having to perform the regexp processing
before deciding on whether or not the URI would be appropriate.
17.5. Tag String
The unique enumservice tag string for the web service is 'web'.
17.6. Security Requirements
Whilst in principle the security issues are similar to any use of HTTP
or SSL/TLS, there are some issues in performance and on automatic web
download.
For example, it is possible for a terminal that receives "Calling Line
Identity Presentation" teleservice to use ENUM to find further information
on the caller, automatically downloading and displaying the 'web' content.
Whilst this "Super Caller Display" may be a useful service, it does open
the end system to the risks of insecure Web Browser implementations
without the end user being given any hint of what's going on. It is
important, therefore, that the kind of content automatically downloaded
is limited.
Similarly, some terminals that perform ENUM queries may have a limited
data bandwidth. Thus it is recommended that the data size for the resource
addressed by the URI be limited, and that this potential behaviour should
be considered by the registrant. Not every user will have a broadband
connection.
Finally, there are situations in which there is a cost implication to
data download; the end user may be charged per unit of data transferred.
Thus, if the end system is set to download automatically the resource
indicated by the associated URI, then the registrant's choice of large
resources may have a significant cost implication on the end user.
18. file transfer service
18.1. Description
This service implies that the associated URI identifies a remote resource
provides a file service from which an addressed document (or file listing)
can be retrieved.
18.2. Enclosing Service Category
This enumservice falls into the info category. This means that if either
the Registrant or the End user lists the 'ft' tag, whilst the other lists
the 'info' tag, then there will be a match.
18.3. Expected Client Behaviour
If this service is selected then the end system can start a file transfer
client program, using the associated URI as the address of the remote item
to be retrieved.
18.4. Appropriate URIs
At present, the only URI specified for use with this is "ftp:".
It is possible in the future that other URIs might be used, for other file
transfer schemes (such as the proprietary "afp:" or "smb:"). However, it
is unclear yet whether these are useful for a system that is accessible
globally; they are used mostly in corporate environments and are unlikely
to be (intentionally) available across the Internet.
18.5. Tag String
The unique enumservice tag string for the file transfer service is 'ft'.
18.6. Security Requirements
The file transfer service suffers from the same security considerations
as for any use of the FTP protocol. The inclusion of a listing in the
ENUM system does not appear to add any further issues.
19. srs categorical enumservice
19.1. Description
This category is used where the Registrant wants to use a specialised
"Service Resolution Service" above and beyond ENUM. It can be used where
the services available depend on factors that cannot be covered in the
global ENUM system; for example, the services "advertised" may depend on
the person asking, and so requires authentication to be performed before
any detailed information is returned.
19.2. Comprised Services
This category comprises two main services; dap and sip. Of these, the
'sip' service has a rich feature set and will be described in a separate
document.
19.3. Expected Client Behaviour
If the end user has selected this as an "enumservice of interest" then
the client should filter out all NAPTRs but those containing either the
'srs', 'sip', or 'dap' tags, together with any NAPTRs showing the 'all'
category and where the processed URIs indicate either "sip:" or "ldap:".
If the Registrant has chosen to include only a NAPTR with either the 'srs'
tag or that of one if its constituent enumservices, then the client can
either initiate the "next stage" of service resolution directly, or report
that this is required and await the end user's response.
In either case, this is the end of ENUM processing; further evaluation
continues using the features of the constructed URI.
19.4. Associated URIs
At present, there are expected to be two URIs that can be associated with
this category; "sip:" and "ldap:".
19.5. Tag String
The unique enumservice tag string for this category is 'srs'.
19.6. Security Requirements
The security issues of this category reflect the services of which it is
comprised. There is intended to be a separate document to specify the sip
enumservice and this will address the security issues of the evaluation
and session initiation process.
20. dap service
20.1. Description
This service indicates that further evaluation and addressing information
for sessions can be obtained using the "ldap:" associated URI.
20.2. Enclosing Service Category
This service falls into the srs category.
20.3. Expected Client Behaviour
--- TBC ---
20.4. Associated URIs
This service is associated only with the "ldap:" URI scheme.
20.5. Tag String
The unique enumservice tag string for the dap service is 'dap'.
20.6. Security Requirements
--- TBC ---
21. 'all' categorical enumservice
21.1. Description
This category is a special case in that it includes all other enumservices
within it. The goal is to provide a default category. This may be used to
indicate that the services supported with a NAPTR are not specified in any
more detail. In effect, the Registrant is asserting that this NAPTR
supports ALL enumservices. However, in practice it means that further
processing (by evaluating the regexp and so constructing the associated
URI) is needed before the end system can be sure whether to discard the
record or not.
When the end user specifies this category as the "enumservice of interest"
they are stating that ANY returned NAPTR is acceptable to them.
21.2. Comprised Services
This category comprises all other enumservices.
21.3. Expected Client Behaviour
When processing a NAPTR that indicates the 'all' enumservice, the client
will have to evaluate the NAPTR to extract the URI, as there is no other
information in the service field to help it filter the returned NAPTR set.
Of course, the normal order and preference field values can be used to
prioritise processing of the NAPTRs, but further processing may be needed
to decide whether or not the NAPTRs meet the interests of the end user.
However, if the end user has specified their "enumservices of interest"
to include this category, then the end system ENUM client has little
choice but to pass the returned NAPTRs to the calling client application
for it to handle using its own decision process.
21.4. Appropriate URIs
This compendium category can be used with all URIs listed as appropriate
for use with any other enumservice.
21.5. Tag String
The unique enumservice tag string for the "all" category is 'all'.
21.6. Security Issues
The security issues in the use of this category have not been analysed yet.
22. General Security Issues
There are not thought to be any more security issues over and above those
described in RFC2916-bis or in the descriptions above.
Note that there is a privacy issue in the use of enumservice identifiers.
Including category information within the NAPTR makes it accessible to any
querying user without authentication, and so exposes data that the
registrant may consider sensitive.
23. IANA Considerations
The services and categories described in this document are enumservices
within the meaning of RFC2916-bis, and so this document forms a request for
registration of these enumservice labels under the ENUM tree, as specified
in sections 2.4.2.1 and 3 of RFC2916-bis.
24. Acknowledgments
Many thanks to the correspondents on the ENUM WG mailing list for their
assistance and cajoling to come out with "concrete proposals". Arnoud
van Wijk pointed out sms as being important for non-hearing people, and
that it is useful to indicate "sms only!" for a mobile phone number.
Clive Feather pointed out that TDD phones are used for a session oriented
text "chat" system.
25. Bibliography
[1] M. Mealling, "DDDS - The DNS Database", May 2002,
draft-ietf-urn-dns-ddds-database-09.txt - Work In Progress
[2] P. Faltstrom, M.Mealling, "The E.164 to URI DDDS Application",
June 2002, draft-ietf-enum-rfc2916bis-01.txt - Work In Progress
[3] H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls",
draft-antti-RFC2806bis-04.txt,
Work in progress, May 2002
[4] R. Brandner, L.Conroy, R. Stastny, "The 'tel:' URI 'svc' parameter",
draft-brandner-tel-svc-00.txt,
Work in Progress, June 2002
[5] P.Hoffmann, L. Masinter, J. Zawinski, "The mailto URL scheme",
RFC2368, Internet Engineering Task Force, July 1998
[6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,
R. Sparks,M. Handley,E. Schooler, "SIP: session initiation
protocol", RFC3261, Internet Engineering task Force, June 2002
26. Authors' Addresses
Rudolf Brandner
Siemens ICN
Hofmannstrasse 51
Munich
Germany
Msg - <mailto:rudolf.brandner@siemens.com>
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>
- <tel:+44-796-7609505;svc=sms>
Talk - <tel:+44-1794-833666>
Richard Stastny
OeFEG
Postbox 147
1103 Vienna
Austria
Msg - <mailto:richard.stastny@oefeg.at>
Talk - <tel:+43-664-420-4100>
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
