ENUM Working Group                                            R.Brandner
Internet-Draft                                                 Siemens
                                                              L. Conroy
                                                               Siemens
Expires: September 22, 2002                           February 22, 2002


                     "The ENUM 'tel' enumservice"
                     draft-brandner-enum-tel-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.

   This Internet-Draft will expire on September 22, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract
This document describes the enumservice 'tel' and how it is used with an
ENUM application when indicated within a returned a NAPTR record. It
gives guidelines for the treatment of records having this sub-field
value, and for the onward processing of information gleaned from the
enclosing NAPTR record.












Brandner & Conroy        Expires August 22, 2002                [Page 1]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


1.  'tel' enumservice registration template

As defined in [1], the following is a template covering information
needed for the registration of the enumservice specified in this
document.

   Service Name: "tel"

   URI Scheme(s): "tel:"

   Functional Specification:
        see section 3 of this document

   Security considerations:
        see section 5 of this document

   Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
        COMMON

   Author: Rudolf Brandner

   Any other information that the author deems interesting:
        see sections 2 and 4 of this document


2.  Introduction

The ENUM application is defined in [1]. This takes an input E.164 number
and returns a URI (or set of URIs) by which communications services
associated with that E.164 number[2] can be contacted. This process is
called a "resolution service" provided by the client application. The
data for this information is stored within the DNS[3][4], inside NAPTR
resource records (defined in [5], section 4).

The ENUM application specification defines the structure for one of the
fields of the NAPTR records it will use; the "Services" field. ENUM
expects this field to be structured in two parts, the rs (or resolution
service) tag and the enumservice sub-field. This latter can in turn have
multiple values, each of which is preceded by a '+' character.

The "resolution service" for which a NAPTR record is intended for use is
indicated by the record rs sub-field value. In the case of records
intended for use with ENUM, this tag value will be "E2U" (meaning that
the record is designed for use when taking an E.164 number and results
in a URI).





Brandner & Conroy        Expires August 22, 2002                [Page 2]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


In addition to this tag, each NAPTR record for use by ENUM will include
at least one enumservice identifier. Each of the values in this
sub-field indicates a treatment that should be made of the returned URI,
together with the IP-based protocol that should be used to forward the
URI to an entity that can further a request for communication. This
document describes one such treatment, that indicated by the 'tel'
enumservice sub-field value.


  2.1.  ENUM enumservice sub-field

ENUM is designed to retrieve URIs associated with an E.164 number. Note
that each URI will be associated with its own set of enumservice
sub-field values. Each value specifies two features; the treatment of
the URI and the protocol to be used for onward processing. It is
necessary to indicate the intended treatment and protocol to be used, as
some user agents are capable of dealing with a number of different URI
scheme values, so that the scheme alone cannot necessarily be used to
distinguish what should be done with the URI; the URI is merely an
identifier.

For example, a URI with the scheme "mailto:" [6] implies that an email
service can be used to contact the destination. However, it is unclear
whether or not that user should be contacted using "basic" SMTP [7], or
instead requires a secure connection to be made (using TLS, over which
the SMTP protocol is carried, according to [8]). This might be indicated
by a distinct enumservice sub-field value (say "smtp" or "smtps"),
indicating the intended treatment and protocol to be used for the URI. 

In principle, these are NOT the same; the treatment is distinct from the
protocol used to forward the URI to an entity that can further the
communications processing, and, as just suggested, these may both differ
from the URI scheme. However, for current uses, a single enumservice
sub-field value, in conjunction with the URI scheme, will suffice.


3.  'tel' sub-field definition

When used with an ENUM application, a NAPTR record including the 
indicator 'tel' in the enumservice sub-field implies that the
URI can be treated as formatted according to [9], and includes a
telephone number. This implies that the communications service described
by this record will require a telephone connection to be made.







Brandner & Conroy        Expires August 22, 2002                [Page 3]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


This sub-field value differs from others that can be used with ENUM in
that it does not specify the protocol to be used for onward processing,
only the treatment of the URI with which it is associated. For example,
it is a valid response to apply the associated URI to a remote SIP User
Agent (and so to use SIP as the protocol by which the communication
session is initiated). That external user agent would use this "tel:"
URI to initiate a call (via a PSTN/IP Gateway as required).

When a 'tel' enumservice sub-field value is present, the interpretation
of the URI that results from processing with the enclosing NAPTR record
is that it is a telephone number. This means that the URI MUST have a
scheme of "tel:", or the client will treat the NAPTR as being in error.

In such an error situation, the client SHOULD report this error and MUST
NOT attempt to infer the treatment from the URI scheme.

The client MAY use the email contact address held in the SOA record for
the current DNS zone to report the mis-configuration of the NAPTR. By
implication, there SHOULD be a SOA record with a valid email contact
address available within the DNS zone holding NAPTR records.


4.  Recommendations on the use of 'tel' NAPTR records

The 'tel: URL scheme (RFC2806 [8]) allows considerable flexibility.
Where a URI is to hold a telephone number and is to be used by ENUM,
however, there are some issues that should be considered. These are
recommendations on the information to be encoded into NAPTR records that
hold the 'tel' enumservice sub-field. If these recommendations are not
followed, the results when such NAPTRs are processed by an ENUM client
may not be acceptable.

  4.1.  Locality of caller

ENUM is designed to allow information to be returned to clients
regardless of their location. Thus, although RFC2806 allows for both
"internationally significant" global-phone-subscriber or
local-phone-subscriber formats for telephone numbers, the person
authoritative for the content of a NAPTR record has no way of knowing
the locality of the person who subsequently will request information
associated with this data. It is therefore important that only the
global-phone-subscriber form SHOULD be used. In those cases where a
local-phone-subscriber form cannot be avoided, then there MUST be a
global-area-specifier parameter included within the URI. This differs
from RFC2806, in which this is of SHOULD strength.





Brandner & Conroy        Expires August 22, 2002                [Page 4]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


Thus these are acceptable forms:
    <tel:+12125554321> -- global phone subscriber form
    <tel:18001234654;phone-context=+1> -- local phone subscriber form

whilst the following is not acceptable:
    <tel:18001234567>

  4.2.  Use of Telephone Service Provider parameter

It is recommended that, where a NAPTR output is to be treated according
to this document, the Telephone Service Provider (TSP) parameter SHOULD
be included within the tel: URI. This parameter indicates the telephone
service provider that is associated with the telephone number. This
parameter is specified as including a value that is a fully qualified
domain name.

There are several reasons for doing this. It allows a "hint" at the
organization responsible for providing telephone service to that
destination user. This information might be used by the caller, for
example, to select an appropriate PSTN/IP Gateway, if needed and the
caller has no preference. Note that this service provider information is
distinct from the identity of the administrative or technical contacts
for the zone or its parent.

This parameter may also be useful if, for example, there is a problem
with calling that user, or there is reason to believe that problem calls
are made from a phone number that (when passed to ENUM) has returned
this URI.

In these last two cases, the tsp domain name could either be used by the
calling user to guess at the web server for that provider, or instead
the web site could be found by submitting the domain name to DNS (using
a SRV query). Having found this, the web site could be used to get
contact information for that provider.

As an alternative use of the tsp parameter domain name value, the DNS
zone indicated by this tsp domain might have communications contact
information (using an application similar to ENUM, but operating with
records not in the ".e164.arpa." domain). As an aside, it would also be
possible to include another NAPTR record inside that domain with a tel:
URI holding the "prefix dial string" for use with this provider. Again,
these would be returned by a query NOT in the "e164.arpa" domain space,
and so would not use the ENUM application.







Brandner & Conroy        Expires August 22, 2002                [Page 5]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


  4.3.  Use of "tel:" URIs within ENUM for Redirection Teleservices

Having received a tel: URI as the result of an ENUM query it is possible
for a client node to re-submit the resulting telephone number (held
inside the tel: URI) back into ENUM as a new query. This might be
considered, for example, to deal with telephone service redirection.
Configuring a set of tel: URIs in different zones, the contents of each
of which "points" to others in the set, could be used to support a range
of "follow-me" services. It is a very powerful feature, and reflects a
number of "real-world" PSTN services. However, this feature does not
come without risk. That risk is looping.

    4.3.1.  Looping of ENUM queries

If re-submitting a tel: URI content to ENUM, mis-configuration of the
NAPTR contents may cause a loop, in which the re-submission results in
the same tel: URI, that is re-submitted, and so on. Likewise, a loop may
exist with more than one domain involved. For example, an ENUM query
with telephone number aa retrieves a NAPTR from domain A resulting in a
tel: URI with telephone number bb; if this is resubmitted to ENUM, 
domain B (associated with this number) has a NAPTR that results in a
tel: URI holding telephone number aa. If this is re-submitted, then the
process repeats. This condition is an error, and the client that calls
the ENUM application SHOULD report this to the end user and terminate
the re-submission.

The condition may have been caused by the remote administrator's
mistake, but it is the client's problem; the ENUM application cannot
detect the problem, as from its perspective each query returns
correctly. For this reason, the client of an ENUM application should
take extra care when re-submitting the telephone number contained in a
tel: URI back into the ENUM application. It is exclusively the
responsibility of the client of the ENUM application to keep track of
prior queries and detect this condition.

Any client behavior in the face of this problem is possible. However,
it is recommended that:

  (i)   the client does not re-submit a query to the ENUM application 
        if it detects a loop.

  (ii)  the client keeps track of the number of requests it has made in
        attempting to find information on an initial E.164 number; 
        if this count exceeds a "reasonable maximum" value of 
        10 attempts, then it SHOULD treat the request chain as a loop.





Brandner & Conroy        Expires August 22, 2002                [Page 6]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


  (iii) if it has good reason to do so, the client MAY treat the most
        recent distinct telephone number retrieved in the sequence as 
        the one to be used to place a call. However, a loop condition IS 
        an error, and so this behavior is not recommended. 
        Instead, clients SHOULD be expected to abort the procedure that 
        started the chain of requests and report the error to the end 
        user, where possible.


    4.3.2.  Alternatives to tel: URI chains for Redirection Teleservices

ENUM (and the tel enumservice), use DNS. As a result, all DNS facilities
are available. This includes the use of CNAME resource records within a
zone. It is possible to install a CNAME record in the parent of the zone
associated with a particular E.164 number. If that CNAME points at
another zone within the ".e164.arpa." domain, then the effect is to
continue the DNS lookup chain at that point in the domain space.
This is similar in effect; a redirection can be arranged by inserting a
CNAME record into a parent zone.

The effect is not quite the same as provision of a chain of "tel:" URIs.
In the CNAME case, the process is transparent to the ENUM client; the
lookup is merely continued at a different point in the DNS tree. It is
less flexible, in that it precludes other records being stored within
the zone associated with the donor number; the whole zone is bypassed.
In contrast, a chain of tel: URIs still allows other records, and so
allows a rich set of teleservices to be provisioned.

Both configurations suffer from similar risks of looping, but in the
case of CNAME loops these are either within the ENUM application or the
DNS recursive resolver it uses.

Despite its lack of flexibility, CNAME redirection can provide a simple
method that may be appropriate for longer term fixed forwarding for
administrators with the right to modify resource records within the
parent of a zone associated with a number.

Another issue with CNAME redirection is that it places some restrictions
on the REGEXP content. At present, DDDS allows a regular expression to
match against the AUS, and if there is no match then the record is
discarded. Where a query is made on a zone associated with a phone
number then NAPTR records within that zone could have RegExp fields that
pattern matched against the whole number.

Thus, if the number in its AUS format were "+441794833666", then a query
on the zone "6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa." might return a NAPTR
with a RegExp field of "!^(441794833666)$!\+\1!". This would match
perfectly, and processing would continue.


Brandner & Conroy        Expires August 22, 2002                [Page 7]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


If, however, the query had been made starting with a phone number, in
its AUS format, of "+494012345678", AND a CNAME record points from
8.7.6.5.4.3.2.1.0.4.9.4.e164.arpa. to 6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa.,
then the same NAPTR returned from the query would NOT match with the AUS.

This means that administrators of ENUM zones should be careful about
specifying the RegExp match rules too tightly. There are reasons to do
this, however. For example, two NAPTR records might exist in the
destination zone, with different priority. The record with the higher
priority might match against an AUS holding any fully qualified phone
number, whilst that with the lower priority might have a tight match
against the phone number associated directly with that zone.

The result would be that two different NAPTRs would match, depending on
whether or not that phone number was the subject of the query, or
instead the redirected, or donor, number. This would allow different
treatment of requests, depending on which number was queried. This is
not specific to 'tel' enumservice, but it does show the flexibility
possible.


5.  Security Considerations

[Including but not limited to...]
Any system that places calls should not automatically dial out to a
number included in ENUM. The calling user should be given a chance to
express policy. For example, a NAPTR output treated as a 'tel' value may
result in a call being placed to a long distance, international, or
premium rate number.

Any dialer system that is passed the telephone number and uses it to
dial out should be act carefully; accidental or malicious
mis-configuration of a NAPTR record may result in calls being placed
either to an innocent third party or to an otherwise inappropriate
destination. Any system that places a call automatically (i.e. without
the end user actually dialing the number themselves) runs the risk of
those calls being incorrect. The end user should be involved in the call
process, if only so that they can veto a call dialed to a "wrong"
number or at the "wrong" time.

This is particularly important if the ENUM infrastructure is ever used
to allow "follow-me" service listing, possibly based on automatic "time
of day" changes. [Ask any European whether or not they have received a
call whilst in the US that was placed during European work hours]






Brandner & Conroy        Expires August 22, 2002                [Page 8]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


There might be an issue with Telephone Service Provider (TSP) privacy.
If the ";tsp=" parameter (RFC 2806) is used in a tel: URI resulting from
an ENUM query, an exhaustive lookup of ENUM will reveal data about how
many ENUM users a TSP has. It is yet unclear how to distinguish between
"normal" ENUM request behavior and an exhaustive lookup and how to
prevent an exhaustive lookup.

Particularly for a "niche" TSP providing services to a particular group,
information on the user may be revealed by presence of the TSP field in
a "tel:" URI.


6.  IANA Considerations

This document specifies the enumservice 'tel', i.e. the treatment of a
URI within a NAPTR record that is intended for use by the ENUM
application, when that NAPTR record includes the 'tel' enumservice
sub-field value.

To ensure that this sub-field value does not collide with other uses, it
is necessary to register this NAPTR sub-field value, when used within
ENUM. Thus this requests that this document be considered a
specification for the sub-field value with the identifier 'tel', and
that a registration be made for this within the ENUM enumservice name
space, as specified in [1].


7. Acknowledgements






















Brandner & Conroy        Expires August 22, 2002                [Page 9]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


8. References

[1] P. Faltstrom, "The E.164 to URI DDDS Application",
    draft-ietf-enum-rfc2916bis-01.txt,
    Work In Progress, March 2002

[2] ITU-T Recommendation E.164/I.331 (05/97): The International
    Public Telecommunication Numbering Plan.
    1997.

[3] Mockapetris, P., "Domain names - implementation and specification",
    RFC 1035, STD 13, Nov 1987.

[4] Mockapetris, P., "Domain names - concepts and facilities",
    RFC 1034, STD 13, Nov 1987.

[5] 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

[6] Hoffman, et. al., "The mailto URL scheme",
    RFC2368, July 1998

[7] Klensin, J., "Simple Mail Transfer Protocol",
    RFC821, August 1982

[8] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS",
    RFC2847, January 1999

[9] Vaha-Sipila, A., "URLs for Telephone Calls",
    RFC2806, April 2000


















Brandner & Conroy        Expires August 22, 2002               [Page 10]

Internet-Draft          The ENUM 'tel' enumservice         February 2002


9.  Authors' Addresses

   Rudolf Brandner
   Siemens ICN
   Hofmannstrasse 51
   Munich
   Germany

   Email:  rudolf.brandner@icn.siemens.de
   URI:    http://www.siemens.de

   Lawrence Conroy
   Siemens Roke Manor Research
   Roke Manor
   Romsey
   U.K.
   
   email:  lwc@roke.co.uk
   phone:  <tel:+44-1794-833666;tsp=bt.com>


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.


Brandner & Conroy        Expires August 22, 2002               [Page 11]