WDIFF

draft-ietf-iptel-rfc2806bis-09.txt --> rfc3966.txt

Network Working Group H. Schulzrinne
Internet-Draft
Request for Comments: 3966 Columbia U.
Expires: University
Obsoletes: 2806 December 25, 2004 June 26, 2004
Category: Standards Track

The tel URI for Telephone Numbers
draft-ietf-iptel-rfc2806bis-09

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of

This document specifies an Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
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 status of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

The list this protocol. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 25, 2004. this memo is unlimited.

Abstract

This document specifies the URI (Uniform Resource Identifier) scheme
"tel". The "tel" URI describes resources identified by telephone
numbers. This document obsoletes RFC 2806.

Schulzrinne Expires December 25, 2004 [Page 1]

Internet-Draft The tel URI June 2004

Table of Contents

1. Introduction . Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
3. URI Syntax Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 7
5.1 6
5.1. Phone Numbers . Numbers. . . . . . . . . . . . . . . . . . . . . . 7
5.1.1 6
5.1.1. Separators in Phone Numbers . . . . . . . . . . . . . 7
5.1.2
5.1.2. Alphabetic Characters Corresponding to Digits . . . . 8
5.1.3 7
5.1.3. Alphabetic, * *, and # Characters as Identifiers . . . . 8
5.1.4 Identifiers. 7
5.1.4. Global Numbers . . Numbers. . . . . . . . . . . . . . . . . . . 8
5.1.5 7
5.1.5. Local Numbers . . . . . . . . . . . . . . . . . . . . 8
5.2
5.2. ISDN Subaddresses Subaddresses. . . . . . . . . . . . . . . . . . . . . 10
5.3 9
5.3. Phone Extensions . . . . . . . . . . . . . . . . . . . . . 10
5.4
5.4. Other Parameters . . . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1
7.1. Why Not Just Put Telephone Numbers in SIP URIs? . . URIs?. . . . 11
7.2
7.2. Why Not Distinguish Between between Call Types? . Types?. . . . . . . . . 12
7.3 11
7.3. Why tel? . tel. . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4 11
7.4. Do Not Confuse Numbers with How They Are Dialed Dialed. . . . . . 12 11

Schulzrinne Standards Track [Page 1]

RFC 3966 The tel URI December 2004

8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . . 12 11
9. Use of "tel" URIs with SIP (Informative) (Informative). . . . . . . . . . . . 13 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . Changes Since RFC 2806. . . . . . . . . . . . . . . . . . . . 15 14
13. Changes Since RFC 2806 References. . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . 15
14.1 Normative
13.2. Informative References . . . . . . . . . . . . . . . . 16
Author's Address . . . . 15
14.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18

Schulzrinne Expires December 25, 2004 [Page 2]

Internet-Draft The tel URI June 2004

1. Introduction

This document defines the URI scheme "tel". The "tel" URI "tel", which describes resources
identified by telephone numbers. A telephone number is a string of
decimal digits that uniquely indicates the network termination point.
The number contains the information necessary to route the call to
this termination point. (This definition is derived from [E.164], [E.164] but encompasses
both public and private numbers.)

The termination point of the "tel" URI telephone number is not restricted in the type of
termination point it refers to. The termination point
restricted. It can be in the public telephone network, a private
telephone network network, or the Internet. The termination point It can be fixed or wireless and
address a fixed wired, mobile mobile, or nomadic terminal. The terminal
addressed can support any electronic communication service (ECS) (ECS),
including voice, data data, and fax. The URI can refer to resources
identified by a telephone number, including but not limited to
originators or targets of a telephone call.

The "tel" URI is a globally unique identifier ("name") only; it does
not describe the steps necessary to reach a particular number and
does not imply dialing dialling semantics. Furthermore, it does not refer to
a specific physical device, only to a telephone number.

Telephone numbers as

As commonly understood actually understood, telephone numbers comprise two
related, related but
distinct concepts: as a canonical address-of-record and
as a dial string.
We define the concepts below:

Address-of-record or identifier: The telephone number is understood
here as the canonical address-of-record or identifier for a
termination point within a specific network. For the public
network, these numbers follow the rules in E.164 [E.164], while
private numbers follow the rules of the owner of the private
numbering plan. Subscribers publish such these identifiers as a
universal means of being so that
they can be reached, independent regardless of the location of the caller.
(Naturally, not all numbers are reachable from everywhere, for a

Schulzrinne Standards Track [Page 2]

RFC 3966 The tel URI December 2004

variety of technical and local policy reasons. Also, a single
termination point may be reachable from different networks and may
have multiple such identifiers.)

Dial string: "Dial strings" are the actual numbers, symbols symbols, and
pauses entered by a user to place a phone call. A dial-string dial string is
consumed by one or more network entities, entities and understood in the
context of the configuration of these entities. It is used to
generate an address-of-record or identifier in (in the sense of the
previous paragraph
described above) so that a call can be routed. Dial-strings Dial strings may
require pre-pended prepended digits to egress exit the private branch exchange (PBX)
the end system is connected to, and they may include

Schulzrinne Expires December 25, 2004 [Page 3]

Internet-Draft The tel URI June 2004 post-dial
dual-tone multi-frequency (DTMF) signaling that could control an
interactive voice response (IVR) system or reach an extension.
Dial strings are beyond the scope of this document.

Both approaches can be expressed as a URI. For dial strings, this
URI is passed to an entity that can reproduce the actions specified
in the dial string. For example, in an analog phone system, a dialer
translates the dial string into a sequence of actions such as waiting
for dial tone, sending DTMF digits, pausing pausing, and generating post-dial
DTMF digits after the callee picks up. In an integrated services
digital network (ISDN) or ISDN user part (ISUP) environment, the
signaling elements receiving that receive protocol messages containing the dial
string perform the appropriate protocol actions. As noted, this
approach is beyond the scope of this specification.

The approach described here has the URI specify the telephone number
as an identifier, which can be either globally unique or only be valid
within a local context. The dialing dialling application is aware of the
local context, knowing, for example, whether special digits need to
be dialed to seize an outside line, line; whether network, pulse pulse, or tone
dialing
dialling is needed needed; and what tones indicate call progress. The dialing
dialling application then converts the telephone number into a dial
sequence and performs the necessary signaling actions. The document below
assumes the second model. The dialer
does not have to be a user application as found in traditional
desktop operating systems, systems but could well be part of an IP-to-PSTN
gateway.

To reach a telephone number from a phone on a PBX, for example, the
user of that phone has to know how to convert the telephone number
identifier into a dial string appropriate for that phone. The
telephone number itself does not convey what needs to be done for a
particular terminal. Instructions may include dialing dialling "9" before
placing a call or prepending a "00" to reach a number in a foreign
country. The phone may also need to strip area and country codes.

Schulzrinne Standards Track [Page 3]

RFC 3966 The tel URI December 2004

The identifier approach described in this document has the
disadvantage that certain services, such as electronic banking or
voicemail, cannot be specified in a "tel" URI.

The notation for phone numbers in this document is similar to that in
RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax
differs since as this document describes URIs whereas RFC 3191 and RFC 3192
specify electronic mail addresses. RFC 3191 and RFC 3192 use "/" to
indicate parameters (qualifiers). Since URI URIs use the forward slash
to describe path hierarchy, the URI scheme described here uses the
semicolon, in keeping with Session Initiation Protocol (SIP) URI
conventions [RFC3261].

Schulzrinne Expires December 25, 2004 [Page 4]

Internet-Draft The tel URI June 2004

The "tel" URI can be used as a request URI in SIP [RFC3261] requests.
The SIP specification also inherits the 'subscriber' part of the
syntax as part of the 'user element' in the SIP URI. Other protocols
may also use this URI for both query-based and prefix-based applications. scheme.

The "tel" URI does not specify the call type type, such as voice, fax, or
data call call, and does not provide the connection parameters for a data
call. The type and parameters are assumed to be negotiated either
in-band by the telephone device or through a signaling protocol such
as SIP.

This document obsoletes RFC 2806.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
2119, [RFC2119] and indicate requirement levels for compliant
implementations.

3. URI Syntax

The URI is defined using the ABNF (augmented Backus-Naur form)
described in RFC 2234 [RFC2234] and uses elements from the core
definitions (Appendix (appendix A of RFC 2234).

The syntax definition follows RFC 2396 [RFC2396], indicating the
actual characters contained in the URI. If the reserved characters
"+", ";", "=", and "?" are used as delimiters between components of
the "tel" URI, they MUST NOT percent-encoded. be percent encoded. These characters
MUST be percent-encoded percent encoded if they appear in tel URI parameter values.

Schulzrinne Standards Track [Page 4]

RFC 3966 The tel URI December 2004

Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX"
percent-encoding. percent
encoding.

The "tel" URI has the following syntax:

Schulzrinne Expires December 25, 2004 [Page 5]

Internet-Draft The tel URI June 2004

telephone-uri = "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
local-number = local-number-digits *par context *par
par = parameter / extension / isdn-subaddress
isdn-subaddress = ";isub=" 1*uric
extension = ";ext=" 1*phonedigit
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
global-number-digits = "+" 1*phonedigit *phonedigit DIGIT *phonedigit
local-number-digits = 1*phonedigit-hex
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname ["=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT
reserved = ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
uric = reserved / unreserved / pct-encoded

Each parameter name ("pname"), the ISDN subaddress, the 'extension' 'extension',
and the 'context' MUST NOT appear more than once. The
'isdn-subaddress' 'isdn-
subaddress' or 'extension' MUST appear first, if present, followed by
the 'context' parameter, if present, followed by any other parameters
in lexicographical order.

This simplifies comparison when the "tel" URI is compared
character-by-character,
character by character, such as in SIP URIs [RFC3261].

Schulzrinne Standards Track [Page 5]

RFC 3966 The tel URI December 2004

4. URI Comparisons

Two "tel" URIs are equivalent according to the following rules:

o Both must be either a 'local-number' or both must be a 'global-number', i.e.,
start with a '+'.

Schulzrinne Expires December 25, 2004 [Page 6]

Internet-Draft The tel URI June 2004
o The 'global-number-digits' and the 'local-number-digits' must be
equal, after removing all visual separators.
o For mandatory additional parameters (Section (section 5.4) and the
'phone-context' 'phone-
context' and 'extension' parameters defined in this document, the
'phone-context' parameter value is compared as a host name if it
is a 'domainname' or digit-by-digit digit by digit if it is
'global-number-digits'. 'global-number-
digits'. The latter is compared after removing all
'visual-separator' 'visual-
separator' characters.
o Parameters are compared according to 'pname', regardless of the
order they appeared in the URI. If one URI has a parameter name
not found in the other, the two URIs are not equal.
o URI comparisons are case-insensitive.

All parameter names and values SHOULD use lower-case characters since characters, as
tel URIs may be used within contexts where comparisons are
case-sensitive. case
sensitive.

Section 19.1.4 in the SIP specification [RFC3261] discusses one such
case.

5. Phone Numbers and Their Context

5.1

5.1. Phone Numbers

The 'telephone-subscriber' part of the URI indicates the number. The
phone number can be represented in either global (E.164) or local
notation. All phone numbers MUST use the global form unless they
cannot be represented as such. Numbers from private numbering plans,
emergency ("911", "112") "112"), and some directory assistance directory-assistance numbers
(e.g., "411") and other "service codes" (numbers of the form N11 in
the United States) cannot be represented in global (E.164) form, form and
need to be represented as a local number with a context. Local
numbers MUST be tagged with a 'phone-context' (Section (section 5.1.5).

Implementations MUST NOT assume that telephone numbers have a
maximum, minimum minimum, or fixed length, or that they always begin with a or
contain certain digits.

5.1.1

Schulzrinne Standards Track [Page 6]

RFC 3966 The tel URI December 2004

5.1.1. Separators in Phone Numbers

Phone numbers MAY contain visual separators. Visual separators
('visual-separator') merely aid readability and are not used for URI
comparison or placing a call.

Although it complicates comparisons, this specification retains
visual separators, separators in order to follow the spirit of RFC 2396
[RFC2396], which remarks that "A URI often needs to be remembered by
people, and it is easier for people to remember a URI when it

Schulzrinne Expires December 25, 2004 [Page 7]

Internet-Draft The tel URI June 2004
consists of meaningful components." components". Also, ISBN URNs documented in
RFC 3187 [RFC3187] use visual separators in a manner similar to this
specification.

However, even though ITU-T E.123 [E.123] recommends the use of space
characters as visual separators in printed telephone numbers, "tel"
URIs MUST NOT use spaces in visual separators to avoid excessive
escaping.

5.1.2

5.1.2. Alphabetic Characters Corresponding to Digits

In some countries, it is popular common to write phone numbers using with
alphabetic characters which correspond corresponding to certain numbers on the
telephone keypad. The URI format does not support this notation
since notation, as
the mapping from alphabetic characters to digits is not completely
uniform internationally, although there are standards [E.161][T1.703]
addressing this issue.

5.1.3

5.1.3. Alphabetic, * *, and # Characters as Identifiers

Since

As called and calling terminal numbers (TNs) are encoded in BCD in
ISUP, six additional values per digit can be encoded, sometimes
represented as the hexadecimal characters A through F. Similarly,
DTMF allows for the encoding of the symbols *, \# #, and A through D.
However, in accordance with E.164, they these may not be included in
global numbers. Their meaning in local numbers is not defined here,
but they are not prohibited.

5.1.4

5.1.4. Global Numbers

Globally unique numbers are identified by the leading "+" character.
Global numbers MUST be composed with the country (CC) and national
(NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].
Globally unique numbers have the property of being are unambiguous everywhere in the world and
SHOULD be used.

5.1.5

Schulzrinne Standards Track [Page 7]

RFC 3966 The tel URI December 2004

5.1.5. Local Numbers

Local numbers are unique only within a certain geographical area or a
certain part of the telephone network, e.g., a private branch
exchange (PBX), a state or province, a particular local exchange
carrier
carrier, or a particular country. URIs with local phone numbers
should only appear in environments where all local entities can
successfully set up the call by passing the number to the dialing dialling
software. Digits needed for accessing an outside line, for example,
are not included in local numbers. Local numbers SHOULD NOT be used
unless there is no way to represent the number as a global number.

Schulzrinne Expires December 25, 2004 [Page 8]

Internet-Draft The tel URI June 2004

There are several reason why local

Local numbers SHOULD NOT be used. used for several reasons. Local numbers
require that the originator and recipient are configured
appropriately,
appropriately so that they can insert and recognize the correct
context descriptors. Since there is no algorithm to independently pick the same descriptor, labeling
descriptor independently, labelling numbers with their context
increases the chances of mis-configuration, misconfiguration so that valid identifiers
are rejected by mistake. The algorithm to select descriptors was
chosen so that accidental collisions should would be rare, but they cannot
be ruled out.

Local numbers MUST have a 'phone-context' parameter that identifies
the scope of their validity. The parameter MUST be chosen to
unambiguously
identify the local context within which the number is
unique. unique
unambiguously. Thus, the combination of the descriptor in the
'phone-context' parameter and local number is again globally unique.
The parameter value is defined by the assignee of the local number.
It does NOT indicate a prefix that turns the local number into a
global (E.164) number.

There are two ways to label the context: via a global number or any
number of its leading digits (e.g., "+33") and via a domain name,
e.g., "houston.example.com". The choice between the two is left to
the "owner" of the local number and is governed by whether there is a
global number or domain name that is a valid identifier for a
particular local number.

The domain name does not have to resolve to any actual host, host but MUST
be under the administrative control of the entity managing the local
phone context.

A global number context consists of the initial digits of a valid
global number. All global numbers matching with these initial digits must be
assigned to the same organization that is describing the context organization, and no such matching number can be
used by any other organization. For example, +49-6151-16 would be a
suitable context for the Technical University of Darmstadt, as it
uses all numbers starting with those digits. If such an initial

Schulzrinne Standards Track [Page 8]

RFC 3966 The tel URI December 2004

string of digits does not exist, the organization SHOULD use the
lowest number of the global number range assigned to it. (This can
occur if two organizations share the same decimal block of numbers.
For example, assume an organization owns the number range +1-212-555-0100 +1-212-
555-0100 through +1-212-555-0149. +1-212-555-1 would not be a valid
global number context, but +1-212-555-0100 would work.) It is not
required that local numbers within the context actually begin with
the chosen set of initial numbers.

A context consisting of the initial digits of a global number does
not imply that adding these to the local number will generate a valid
E.164 number. It might do so by coincidence, but this cannot be

Schulzrinne Expires December 25, 2004 [Page 9]

Internet-Draft The tel URI June 2004
relied upon. (For example, "911" should be labeled with the context
"+1", but "+1-911" is not a valid E.164 number.)

National freephone numbers do not need a context, even though they
are not necessarily reachable from outside a particular country code
or numbering plan. Recall that "tel" URIs are identifiers; it is
sufficient that a global number is unique, but it is not required
that it be reachable from everywhere.

Even non-freephone numbers may be out of date or may not be
reachable from a particular location. For example, premium
services such as "900" numbers in the North American numbering
plan are often not dialable from outside the particular country
code.

The two label types were chosen so that, in almost all cases, a
local administrator can pick an identifier that is reasonably
descriptive and does not require a new IANA-managed assigned
number. It is up to the administrator to assign an appropriate
identifier and to use it consistently. Often, an organization can
choose among several different identifiers.

If the recipient of a "tel" URI uses the URI it simply for identification,
the receiver does not need to know anything about the context
descriptor. It simply treats it as one part of a globally unique
identifier, with the other being the local number. If a recipient of
the URI intends to place a call to the local number, it MUST
understand the context and be able to place calls within that
context.

5.2

5.2. ISDN Subaddresses

A phone number MAY also contain an 'isdn-subaddress' parameter which that
indicates an ISDN subaddress.

Schulzrinne Standards Track [Page 9]

RFC 3966 The tel URI December 2004

ISDN subaddresses typically contain International Alphabet 5 (IA5
[T.50]) characters, characters but may contain any octet value.

5.3

5.3. Phone Extensions

Phone extensions identify stations behind a non-ISDN PBX and are
functionally roughly equivalent in functionality to ISDN subaddresses. They are
identified with the 'extension' parameter. At most most, one of the
'isdn-subaddress' and 'extension' parameters can appear in a "tel"
URI, i.e., they cannot appear both at the same time.

5.4

5.4. Other Parameters

Future protocol extensions to this URI scheme may add other

Schulzrinne Expires December 25, 2004 [Page 10]

Internet-Draft The tel URI June 2004
parameters ('parameter' in the ABNF). Such parameters can be either
mandatory or optional. Mandatory parameters start with "m-". An
implementation MAY ignore optional parameters. An implementation parameters and MUST NOT use the
URI if it contains unknown mandatory parameters. The "m-" prefix
cannot be added to parameters that were already registered (except to
create a new, logically distinct parameter). The "phone-context"
parameter in this document is mandatory, and "isub" and "ext" are
optional.

New mandatory parameters must be described in a standards-track RFC,
while
but an informational RFC is sufficient for optional parameters.

For example, 'parameter' parameters can be used to store
application-specific additional data about the phone number, its
intended use, or any conversions that have been applied to the
number.

Entities that forward protocol requests containing "tel" URIs with
optional parameters MUST NOT delete or modify parameters they do not
understand.

6. Examples

tel:+1-201-555-0123: This URI points to a phone number in the United
States. The hyphens are included to make the number more
human-readable; human
readable; they separate country, area codes code and subscriber number.

tel:7042;phone-context=example.com: The URI describes a local phone
number valid within the context "example.com".

tel:863-1234;phone-context=+1-914-555: The URI describes a local
phone number that is valid within a particular phone prefix.

Schulzrinne Standards Track [Page 10]

RFC 3966 The tel URI December 2004

7. Rationale

7.1

7.1. Why Not Just Put Telephone Numbers in SIP URIs?

The "tel" URI describes a service, reaching a telephone number, that
is independent of the means of doing so, be it via a SIP-to-PSTN
gateway, a direct SIP call via E.164 number ("ENUM") translation
[RFC2916],
[RFC3761], some other signaling protocols such as H.323 H.323, or a
traditional circuit-switched call initiated on the client side via,
say, the Telephony Application Programming Interface (TAPI). It is
thus, Thus,
in spirit, it is closer to the URN schemes that also leave the
resolution to an external mechanism. The same "tel" URI may get
translated to any number of other URIs in the process of setting up
the call.

Schulzrinne Expires December 25, 2004 [Page 11]

Internet-Draft The tel URI June 2004

7.2

7.2. Why Not Distinguish Between between Call Types?

Signaling protocols such as SIP allow to negotiate negotiating the call type and
parameters, making the very basic indication within the URI scheme
moot. Also, since the call type can change frequently, any such
indication in a URI is likely to be out of date. If such designation
is desired for a device that directly places calls without a
signaling protocol such as SIP, mechanisms such as the "type"
attribute for the "A" element in HTML may be more appropriate.

7.3

7.3. Why tel?

"Tel" "tel"?

"tel" was chosen since because it is widely recognized that none of the
other suggestions appeared appropriate. "Callto" was discarded since
because URI schemes locate a resource and do not specify an action to
be taken. "Telephone" and "phone" were considered too long and not as
internationally recognized.

7.4
easily recognized internationally.

7.4. Do Not Confuse Numbers with How They Are Dialed

As an example, in many countries the E.164 number "+1-212-555-3141"
will be dialed in
many countries as 00-1-212-555-3141, where the leading "00" is a
prefix for international calls. (In general, a "+" symbol in E.164
indicates that an international prefix is required.)

8. Usage of Telephone URIs in HTML

Links using the "tel" URI SHOULD enclose the telephone number, number so that
users can easily predict the action taken when following the
link. link

Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for
assistance.

Schulzrinne Standards Track [Page 11]

RFC 3966 The tel URI December 2004

instead of

Dial <a href="tel:+1-212-555-0101">this number</a> for assistance.

On a public HTML page, the telephone number in the URI SHOULD always
be in the global form, even if the text of the link uses some local
format.
format:

Telephone (if dialing dialling in the United States):
<a href="tel:+1-201-555-0111">(201) 555-0111</a>

or even

Schulzrinne Expires December 25, 2004 [Page 12]

Internet-Draft The tel URI June 2004

For having RFCs read aloud, call <a
href="tel:+1-555-438-3732">1-555-IETF-RFC</a>.

9. Use of "tel" URIs with SIP (Informative)

SIP can use the "tel" URI anywhere a URI is allowed, for example as a
Request-URI, along with "sip" and "sips" URIs. For brevity, we will
imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP
URIs can contain telephone numbers. In SIP URIs, they appear as the
user part, i.e., before the @ symbol (Section (section 19.1.6 in [RFC3261]).

Unless a SIP UA connects directly to a PSTN gateway, one of the SIP
proxy servers has to translate the "tel" URI to a SIP URI, with the
host part of that URI pointing to a gateway. Typically, the outbound
proxy server, as the first proxy server visited by a call request,
performs this translation. A proxy server can translate all "tel"
URIs to the same SIP host name or select a different gateway for
different "tel" prefixes, based, for example, on information learned
from TRIP [RFC3219]. However, a proxy server could also delegate
this translation task to any other proxy server since server, as proxy servers are
free to apply whatever routing logic they desire. For local numbers,
the proxy MUST NOT translate "tel" URIs whose context contexts it does not
understand.

As noted earlier, all phone numbers MUST use the global form unless
they cannot be represented as such. If the local-number format is
used, it MUST be qualified by the 'phone-context' parameter.
Effectively, the combination of local number and phone context makes
the "tel" URI globally unique.

While

Although web pages, vCard business cards, address books books, and
directories can easily contain global "tel" URIs, users on twelve-button twelve-
button (IP) phones cannot dial such numbers directly and are
typically accustomed to dialing dialling shorter strings, e.g., for PBX
extensions or local numbers. These so-called dial-strings (Section dial strings (section

Schulzrinne Standards Track [Page 12]

RFC 3966 The tel URI December 2004

1) are not directly represented by "tel" URIs, as noted. We refer to
the rules that govern the translation of dial strings into SIP and
"tel" URIs, global or local, as the dial plan. Currently,
translations from dial strings to "tel" URIs have to take place in
end systems. Future efforts may provide means to carry dial strings
in a SIP URI, for example, but no such mechanisms exist at the time as of this
writing.

A SIP UA can use a dial plan to translate dial strings into SIP or
"tel" URIs. The dial plan can be manually configured or, preferably,
be
downloaded as part of a device configuration mechanism. (At this
time, there is no standardized mechanism for this.)

Schulzrinne Expires December 25, 2004 [Page 13]

Internet-Draft The tel URI June 2004

A mobile user can use at least two dial plans, namely the dial plan
for the network that he is currently visiting and the dial plan for
his home network. Generally, dialed numbers that are meant to represent
global numbers will look the same after the translation regardless of
the dial plan, even if, say, the visited network uses '0' for dialing
dialling an 'outside' number and the user's home network uses '9', as
long as the user is aware of the current dial plan. However, local
extensions that do not have without a direct global equivalent may well behave
differently. To avoid any ambiguity, the dial plan MUST insert a
suitable 'phone-context' string when performing the translation. If
the 'phone-context' is a domain name, there are three cases:

1. The outbound proxy recognizes the domain name in the "tel" or SIP
URI as its local context and can route the request to a gateway
that understands the local number.

2. The outbound proxy does not use the same phone context, context but can
route to a proxy that handles this phone context. This routing
can be done via a lookup table table, or the domain name of the phone
context might be set up to reflect the SIP domain name of a
suitable proxy. For example, a proxy may always route calls with
"tel" URIs like

tel:1234;phone-context=munich.example.com

to the SIP proxy located at munich.example.com. (Proxies that
receive
receiving a tel URI with a context they do not understand are
obligated to return a 404 (Not Found) status resonse, response so that an
outbound proxy may decide to attempt such a heuristic.)

3. The outbound proxy does not recognize the phone context and
cannot find the appropriate proxy cognizant of for that phone context. In
that case, the translation fails fails, and the outbound proxy returns
a 404 (Not Found) error response.

Schulzrinne Standards Track [Page 13]

RFC 3966 The tel URI December 2004

10. Acknowledgments

This document is derived from RFC 2806 [RFC2806], written by Antti
Vaehae-Sipilae. Mark Allman, Flemming Andreasen, Francois Audet,
Lawrence Conroy, Cullen Jennings, Michael Hammer, Paul Kyzivat,
Andrew Main, Xavier Marjou, Jon Peterson, Mike Pierce, Jonathan
Rosenberg
Rosenberg, and James Yu provided extensive comments.

11. Security Considerations

The security considerations parallel those for the mailto URL
[RFC2368].

Web clients and similar tools MUST NOT use the "tel" URI to place
telephone calls without the explicit consent of the user of that

Schulzrinne Expires December 25, 2004 [Page 14]

Internet-Draft The tel URI June 2004
client. Placing calls automatically without appropriate user
confirmation may incur a number of risks, such as those described
below:

o Calls may incur costs.
o The URI may be used to place malicious or annoying calls.
o A call will take the user's phone line off-hook, thus preventing
its use.
o A call may reveal the user's, user's possibly unlisted, unlisted phone number to the
remote host in the caller identification data, data and may allow the
attacker to correlate the user's phone number with other
information
information, such as the an e-mail or IP address.

This is particularly important for "tel" URIs embedded in HTML links links,
as a malicious party may hide the true nature of the URI in the link
text, as in

<a href="tel:+1-900-555-0191">Find free information here</a>
<a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a>

"tel" URIs may reveal private information, similar to including phone
numbers as text. However, the presence of the tel: schema identifier
may make it easier for an adversary using a search engine to discover
such
these numbers.

12. IANA Considerations

This document requires no IANA actions.

13. Changes Since RFC 2806

The specification is syntactically backwards-compatible with the
"tel" URI defined in RFC 2806 [RFC2806], [RFC2806] but has been completely
rewritten. This document more clearly distinguishes telephone
numbers as identifiers of network termination points from dial
strings and removes the latter from the purview of "tel" URIs.

Schulzrinne Standards Track [Page 14]

RFC 3966 The tel URI December 2004

Compared to RFC 2806, references to carrier selection, dial context,
fax and modem URIs, post-dial strings strings, and pause characters have been
removed. The URI syntax now conforms to RFC 2396 [RFC2396].

A section on using "tel" URIs in SIP was added.

14.

13. References

14.1

13.1. Normative References

[E.123] International Telecommunications Union, "Notation for
national and international telephone numbers, e-mail

Schulzrinne Expires December 25, 2004 [Page 15]

Internet-Draft The tel URI June 2004
addresses and web addresses", Recommendation E.123,
February 2001.

[E.161] International Telecommunications Union, "Arrangement of
digits, letters and symbols on telephones and other
devices that can be used for gaining access to a telephone
network", Recommendation E.161, May 1995.

[E.164] International Telecommunications Union, "The international
public telecommunication numbering plan", Recommendation
E.164, May 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[T1.703] ANSI, "Allocation of Letters to the Keys of Numeric
Keypads for Telecommunications", Standard T1.703-1995
(R1999), 1999.

14.2

Schulzrinne Standards Track [Page 15]

RFC 3966 The tel URI December 2004

13.2. Informative References

[I-D.yu-tel-url]
Yu, J., "New Parameters for the 'tel' URL to Support
Number Portability and Freephone Service",
draft-yu-tel-url-08 (work in progress), November 2003.

[RFC2368] Hoffman, P., Masinter, L. L., and J. Zawinski, "The mailto
URL scheme", RFC 2368, July 1998.

[RFC2396] Berners-Lee, T., Fielding, R. R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.

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

[RFC2916]

[RFC3761] Faltstrom, P., "E.164 number P. and DNS", M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 2916, September
2000. 3761, April 2004.

[RFC3187] Hakala, J. and H. Walravens, "Using International Standard
Book Numbers as Uniform Resource Names", RFC 3187, October

Schulzrinne Expires December 25, 2004 [Page 16]

Internet-Draft The tel URI June 2004
2001.

[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet
Mail", RFC 3191, October 2001.

[RFC3192] Allocchio, C., "Minimal FAX address format in Internet
Mail", RFC 3192, October 2001.

[RFC3219] Rosenberg, J., Salama, H. H., and M. Squire, "Telephony
Routing over IP (TRIP)", RFC 3219, January 2002.

[T.50] International Telecommunications Union, "International
Reference Alphabet (IRA) (Formerly International Alphabet
No. 5 or IA5) - Information technology - 7-bit coded
character set for information interchange", Recommendation
T.50, 1992.

Author's Address

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US

Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu

Schulzrinne Expires December 25, 2004 Standards Track [Page 17]

Internet-Draft 16]

RFC 3966 The tel URI June December 2004

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment ietf-
ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Schulzrinne Expires December 25, 2004 Standards Track [Page 18] 17]

----