One document matched: draft-antti-telephony-url-10.txt
Differences from draft-antti-telephony-url-09.txt
INTERNET-DRAFT A. Vaha-Sipila
Expires 24-Mar-2000 Nokia
22-Sep-1999
URLs for Telephone Calls
<draft-antti-telephony-url-10.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. 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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
The distribution of this document before its expiry date is
unlimited.
Abstract
This document specifies URL (Uniform Resource Locator) schemes
terminal in the phone network and the connection types (modes of
operation) that can be used to connect to that entity. This
specification covers voice calls (normal phone calls, answering
machines and voice messaging systems), facsimile (telefax) calls and
data calls, both for POTS and digital/mobile subscribers.
A. Vaha-Sipila Expires March, 2000 [Page 1]
Internet-Draft URLs for Telephone Calls September 1999
Table of Contents
1. Introduction ................................................ 3
1.1 New URL schemes ............................................ 3
1.2 Formal definitions ......................................... 3
1.3 Requirements ............................................... 4
2. URL schemes for telephone calls ............................. 4
2.1 Applicability .............................................. 4
2.2 "tel" URL scheme ........................................... 4
2.3 "fax" URL scheme ........................................... 5
2.4 "modem" URL scheme ......................................... 6
2.5 Parsing telephone, fax and modem URLs ...................... 6
2.5.1 Call type ................................................ 6
2.5.2 Phone numbers and their scope ............................ 7
2.5.3 Separators in phone numbers .............................. 8
2.5.4 Converting the number to the local numbering scheme ...... 8
2.5.5 Sending post-dial sequence after call setup .............. 9
2.5.6 Pauses in dialing and post-dial sequence ................. 9
2.5.7 ISDN subaddresses ........................................ 9
2.5.8 T.33 subaddresses ........................................ 10
2.5.9 Data call parameters ..................................... 10
2.5.10 Telephony service provider identification ............... 11
2.6 Examples of Use ............................................ 12
2.7 Rationale behind the syntax ................................ 13
2.7.1 Why distinguish between call types? ..................... 13
2.7.2 Why "tel" is "tel"? ..................................... 13
2.7.3 Why to use E.164 numbering? .............................. 14
2.7.4 Not everyone has the same equipment as you ............... 14
2.7.5 Do not confuse global and local contexts ................. 15
3. Comments on usage ........................................... 15
4. References .................................................. 16
5. Security Considerations ..................................... 17
6. Acknowledgements ............................................ 18
7. Authors' Addresses .......................................... 18
8. Full Copyright Statement .................................... 19
A. Vaha-Sipila Expires March, 2000 [Page 2]
Internet-Draft URLs for Telephone Calls September 1999
1. Introduction
1.1 New URL schemes
URLs that designate phone or fax numbers that can be dialed have been
brought forward in other Internet-Drafts. However, none of these has
reached the RFC status. This document tries to remedy the situation.
All interested parties are invited to submit comments on this
Internet-Draft. Contact information can be found at the end of this
document.
See also [CONV-URL] for more discussion on conversational URLs.
This specification defines three new URL schemes: "tel", "fax" and
"modem". They are intended for describing a terminal that can be
contacted using the telephone network. The description includes the
subscriber (telephone) number of the terminal and the necessary
parameters to be able to successfully connect to that terminal.
The "tel" scheme describes a connection to a terminal that handles
normal voice telephone calls, a voice mailbox or another voice
messaging system or a service that can be operated using DTMF codes.
The "fax" scheme describes a connection to a terminal that can handle
telefaxes (facsimiles). The name (scheme specifier) for the URL is
"fax" as recommended by [E.123].
The "modem" scheme describes a connection to a terminal that can
handle incoming data calls. The term "modem" refers to a device that
does digital-to-analog and analog-to-digital conversions; in addition
to these, a "modem" scheme can describe a fully digital connection.
The notation for phone numbers is the same which is specified in
[RFC2303] and [RFC2304]. However, the syntax definition is a bit
different due to the fact that this document specifies URLs whereas
[RFC2303] and [RFC2304] specify electronic mail addresses. For
example, "/" (used in URLs to separate parts in a hierarchical URL
[RFC2396]) has been replaced by ";". In addition, this URL scheme has
been synchronized with [RFC2543].
When these URLs are used, the number of parameters should be kept to
minimum. This is especially important if the URL is intended to be
shown to the end user, printed, or otherwise distributed so that it
is visible.
1.2 Formal definitions
A. Vaha-Sipila Expires March, 2000 [Page 3]
Internet-Draft URLs for Telephone Calls September 1999
Formal definitions follow [RFC2234]. This specification uses elements
from the 'core' definitions (Appendix A of [RFC2234]). Some elements
have been defined in previous RFCs. If this is the case, the RFC in
question has been referenced in comments.
1.3 Requirements
Compliant software MUST follow this specification. Requirements are
indicated by capitalized words as specified in [RFC2119].
2. URL schemes for telephone calls
2.1 Applicability
In this document, "user agent" means software that can detect and
parse one or more of these URLs and possibly place a call to the
remote terminal using hardware and software at its disposal after it
has been properly configured, or otherwise utilize the contents of
the URL.
These URL schemes are used to direct the user agent to place a call
using the telephone network, or as a method to transfer or store a
phone number plus other relevant data. The network in question may be
a landline or mobile phone network, or a combination of these. If the
phone network differentiates between (for example) voice and data
calls, or if the user agent has several different telecommunications
equipment at its disposal, it is possible to specify which kind of
call (voice/fax/data) is requested. The URL can also contain
information about the capabilities of the remote entity, so that the
connection can be established successfully.
None of the URL schemes do have a 'path' in them - they are always
absolute. The URLs are always case-insensitive, except for the
<future-extension> parameter (see below), whose case-sensitivity is
application specific.
All unsafe and reserved characters (when not used for their reserved
purpose) MUST be URL-encoded as explained in [RFC1738]. All 8-bit
characters MUST be URL-encoded.
2.2 "tel" URL scheme
The URL syntax is formally described as follows. For the basis of
this syntax, see [RFC2303].
telephone-url = telephone-scheme ":"
A. Vaha-Sipila Expires March, 2000 [Page 4]
Internet-Draft URLs for Telephone Calls September 1999
telephone-subscriber
telephone-scheme = "tel"
telephone-subscriber = global-phone-number / local-phone-number
global-phone-number = "+" base-phone-number [isdn-subaddress]
[post-dial] *(area-specifier / service-provider /
future-extension)
base-phone-number = 1*phonedigit
local-phone-number = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[post-dial] *(area-specifier / service-provider /
future-extension)
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit /
dtmf-digit / pause-character)
area-specifier = ";" phone-context-tag "=" phone-context-ident
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
network-prefix = global-network-prefix / local-network-prefix
global-network-prefix = "+" 1*phonedigit
local-network-prefix = 1*(phonedigit / dtmf-digit / pause-character)
private-prefix = (%x21-22 / %x24-29 / %x2C-2F / %x3A / %x3C-40 /
%x45-4F / %x51-56 / %x58-60 / %x65-6F / %x71-76 /
%x78-7E) *(%x21-3A / %x3C-7E)
; Unsafe and reserved characters must be encoded
; as explained in [RFC1738]
service-provider = ";" provider-tag "=" provider-hostname
provider-tag = "tsp"
provider-hostname = domain ; <domain> is defined in [RFC1035]
future-extension = ";" 1*(token-char) ["=" ((1*(token-char)
["?" 1*(token-char)]) / quoted-string )]
token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; Unsafe and reserved characters must
; be encoded as explained in [RFC1738]
quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7E /
%80-FF ) %x22
; Unsafe, reserved, and 8-bit characters must
; be encoded as explained in [RFC1738]
phonedigit = DIGIT / visual-separator
visual-separator = "-" / "." / "(" / ")"
pause-character = one-second-pause / wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D"
2.3 "fax" URL scheme
A. Vaha-Sipila Expires March, 2000 [Page 5]
Internet-Draft URLs for Telephone Calls September 1999
The URL syntax is formally described as follows (the definition
reuses nonterminals from the above definition). For the basis of this
syntax, see [RFC2303] and [RFC2304].
fax-url = fax-scheme ":" fax-subscriber
fax-scheme = "fax"
fax-subscriber = fax-global-phone / fax-local-phone
fax-global-phone = "+" base-phone-number [isdn-subaddress]
[t33-subaddress] [post-dial]
*(area-specifier / service-provider /
future-extension)
fax-local-phone = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[t33-subaddress] [post-dial]
*(area-specifier / service-provider /
future-extension)
t33-subaddress = ";tsub=" 1*phonedigit
2.4 "modem" URL scheme
The URL syntax is formally described as follows (the definition
reuses nonterminals from the above definitions). For the basis of
this syntax, see [RFC2303].
modem-url = modem-scheme ":" remote-host
modem-scheme = "modem"
remote-host = telephone-subscriber *modem-params
modem-params = ";type=" data-capabilities
data-capabilities = accepted-modem ["?" data-bits parity
stop-bits]
accepted-modem = "V21" / "V22" / "V22b" /
"V23" / "V26t" / "V32" /
"V32b" / "V34" / "V90" /
"V110" / "V120" / "B103" /
"B212" / "X75" /
"vnd." vendor-name "." modem-type
data-bits = "7" / "8"
parity = "n" / "e" / "o" / "m" / "s"
stop-bits = "1" / "2"
vendor-name = 1*(ALPHA / DIGIT / "-" / "+")
modem-type = 1*(ALPHA / DIGIT / "-" / "+")
2.5 Parsing telephone, fax and modem URLs
2.5.1 Call type
A. Vaha-Sipila Expires March, 2000 [Page 6]
Internet-Draft URLs for Telephone Calls September 1999
The type of call is specified by the scheme specifier. "Tel" means
that a voice call is opened. "Fax" indicates that the call should be
a facsimile (telefax) call. "Modem" means that it should be a data
call. Not all networks differentiate between the types of call; in
this case, the scheme specifier indicates the telecommunications
equipment type to use.
2.5.2 Phone numbers and their scope
<telephone-subscriber> and <fax-subscriber> indicate the phone number
to be dialed. The phone number can be written in either international
or local notation. All phone numbers SHOULD always be written in the
international form if there is no good reason to use the local form.
Not all numbers are valid within all numbering areas. An optional
parameter <area-specifier> is used to indicate the numbering area
within which this number is valid. The <area-specifier> can take
three forms: <global-network-prefix>, <local-network-prefix> or
<private-prefix>. The interpretation of this field is as follows: the
number is valid in the user-agent's numbering area if the user-
agent's own number starts with one of the given prefixes. For
example, if <global-network-prefix> is "+358", the given number is
valid only within Finland (even if it is a <global-phone-number>). If
<local-network-prefix> is "80", the number is valid in an environment
where the user-agent's own number starts with "80" - possibly a
company internal phone number.
There can be multiple instances of <area-specifier>. In this case,
the number is valid in all of the given numbering areas.
The interpretation of <private-prefix> is left for future
specification within IETF PINT working group and shall be documented
in an RFC. <private-prefix> SHOULD start with a token which
identifies its syntax.
If <area-specifier> is present, the user agent MUST NOT call out if
the user agent is not located within that numbering area. Also, if
<area-specifier> is present, <global-network-prefix> SHOULD be used
whenever possible.
Any telephone number MUST contain at least one <phonedigit> or
<dtmf-digit>, that is, subscriber numbers consisting only of pause
characters are not allowed.
International numbers MUST begin with the "+" character. Local
numbers MUST NOT contain that character. International numbers MUST
A. Vaha-Sipila Expires March, 2000 [Page 7]
Internet-Draft URLs for Telephone Calls September 1999
be written with the country (CC) and national (NSN) numbers as
specified in [E.123] and [E.164]. International numbers have the
property of being totally unambiguous everywhere in the world if the
user agent is properly configured.
Local numbers MAY be used if the number only works from inside a
certain geographical area or a network. Note that some numbers may
work from several networks but not from the whole world - these
SHOULD be written in international form. URLs containing local phone
numbers should only appear in an environment where all user agents
can get the call successfully set up by passing the number to the
dialing entity "as is". An example could be a company intranet, where
all user agents are located under a the same private telephone
exchange. If local phone numbers are used, the document in which they
are present SHOULD contain an indication of the context in which they
are intended to be used, and an appropriate <area-specifier> SHOULD
be present in the URL.
In some regions, it is popular to write phone numbers using
alphabetic characters which correspond to certain numbers on the
telephone keypad. Letters in <dtmf-digit> characters do not have
anything to do with this, nor is this method supported by these URL
schemes.
It should also be noted that implementations MUST NOT assume that
telephone numbers have a maximum, minimum or fixed length, or that
they would always begin with a certain number. Implementors are
encouraged to familiarize themselves with the international standards
for telephone number notation.
2.5.3 Separators in phone numbers
All <visual-separator> characters MUST be removed from the phone
number by the user agent before using it do dial out. These
characters are present only to aid readability: they MUST NOT have
any other meaning. Note that although [E.123] recommends the use of
space (SP) characters as the separators, spaces MUST NOT be used in
phone numbers.
2.5.4 Converting the number to the local numbering scheme
After the telephone number has been extracted, it can be converted to
the local dialing convention. (For example, the "+" character might
be replaced by the international call prefix, or the international
and trunk prefixes might be removed to place a local call.) Numbers
that have been specified using <local-phone> or <fax-local-phone>
A. Vaha-Sipila Expires March, 2000 [Page 8]
Internet-Draft URLs for Telephone Calls September 1999
MUST be used by the user agent "as is", without any conversions.
2.5.5 Sending post-dial sequence after call setup
The number may contain a <post-dial> sequence, which MUST be dialled
using Dual Tone Multifrequency (DTMF) in-band signalling or pulse
dialing after the call setup is complete. If the user agent does not
support DTMF or pulse dialing after the call has been set up, <post-
dial> MUST be ignored. In that case, the user SHOULD be notified.
2.5.6 Pauses in dialing and post-dial sequence
A local phone number or a post-dial sequence may contain <pause-
character> characters which indicate a pause while dialing ("p"), or
a wait for dial tone ("w").
User agents MAY support this method of dialing, and the final
interpretation of these characters is left to the user agent.
If it is not supported, user agents MUST ignore everything in the
dial string after the first <pause-character> and the user SHOULD be
notified. The user or the user agent MAY opt not to place a call if
this feature is not supported and these characters are present in the
URL.
Any <dtmf-digit> characters and all dial string characters after the
first <pause-character> or <dtmf-digit> SHOULD be sent to line using
DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is
done using direct network signaling (a digital subscriber loop or a
mobile phone). If the local infrastructure does not support DTMF
codes, the user agent MAY opt to use pulse dialing. However, it
should be noted that certain services which are controlled using DTMF
tones cannot be controlled with pulse dialing. If pulse dialing is
used, the user SHOULD be notified.
2.5.7 ISDN subaddresses
A phone number MAY also contain an <isdn-subaddress> which indicates
an ISDN subaddress. User agent SHOULD support ISDN subaddresses.
These addresses are sent to the network by using a method available
to the user agent (typically, ISDN subscribers send the address with
the call setup signalling). If ISDN subaddressing is not supported by
the caller, <isdn-subaddress> MUST be ignored and the user SHOULD be
notified. The user or the user agent MAY opt not to place a call if
this feature is not supported.
A. Vaha-Sipila Expires March, 2000 [Page 9]
Internet-Draft URLs for Telephone Calls September 1999
2.5.8 T.33 subaddresses
A fax number MAY also contain a <t33-subaddress>, which indicates the
start of a T.33 subaddress [T.33]. User agents SHOULD support this.
Otherwise <t33-subaddress> MUST be ignored and the user SHOULD be
notified. The user or the user agent MAY opt not to place a call if
this feature is not supported.
2.5.9 Data call parameters
<modem-params> indicate the minimum compliance required from the user
agent to be able to connect to the remote entity. The minimum
compliance is defined as being equal to or a superset of the
capabilities of the listed modem type.
The user agent MUST call out using compatible hardware, or request
that the network provides such a service.
For example, if the user agent only has access to a V.22bis modem and
the URL indicates that the minimum acceptable connection is V.32bis,
the user agent MUST NOT try to connect to the remote host since
V.22bis is a subset of V.32bis. However, if the URL lists V.32 as the
minimum acceptable connection, the user agent can use V.32bis to
create a connection since V.32bis is a superset of V.32.
This feature is present because modem pools often have separate
numbers for slow modems and fast modems, or have different numbers
for analog and ISDN connections, or may use proprietary modems that
are incompatible with standards. It is somewhat analogous to the
connection type specifier (typecode) in FTP URLs [RFC1738]: it
provides the user agent with information that can not be deduced from
the scheme specifier, but is helpful for successful operation.
This also means that the number of data and stop bits and parity MUST
be set according to the information given in the URL, or to default
values given in this document, if the information is not present.
The capability tokens are listed below. If capabilities suggest that
it is impossible to create a connection, the connection MUST NOT be
created.
If new modem types are standardized by ITU-T, this list can be
extended with those capability tokens. Tokens are formed by taking
the number of the standard and joining together the first letter (for
example, "V"), number (for example, 22) and the first letter of the
postfix (for example "bis" would become "b").
A. Vaha-Sipila Expires March, 2000 [Page 10]
Internet-Draft URLs for Telephone Calls September 1999
Proprietary modem types MUST be specified using the 'vendor naming
tree', which takes the form "vnd.x.y", in which "x" is the name of
the entity from which the specifications for the modem type can be
acquired and "y" is the type or model of the modem. Vendor names MUST
share the same name space with vendor names used in MIME types
[RFC2048]. Submitting the modem types to ietf-types list for review
is strongly recommended.
New capabilities MUST always be documented in an RFC, and they MUST
refer to this document or a newer version of it.
Capability Explanation
V21 ITU-T V.21
V22 ITU-T V.22
V22b ITU-T V.22bis
V23 ITU-T V.23
V26t ITU-T V.26ter
V32 ITU-T V.32
V32b ITU-T V.32bis
V34 ITU-T V.34
V90 ITU-T V.90
V110 ITU-T V.110
V120 ITU-T V.120
X75 ITU-T X.75
B103 Bell 103
B212 Bell 212
Data bits: "8" or "7" The number of data bits. If not
specified, defaults to "8".
Parity: "n", "e", "o", Parity. None, even, odd, mark or
"m", "s" space parity, respectively. If
not specified, defaults to "n".
Stop bits: "1" or "2" The number of stop bits. If not
specified, defaults to "1".
2.5.10 Telephony service provider identification
It is possible to indicate the identity of the telephony service
provider for the given phone number. <service-provider> MAY be used
by the user-agent to enhance the user interface, for billing
estimates or to otherwise optimize its functionality. It MAY also be
ignored by the user-agent. <service-provider> consists of a fully
qualified Internet domain name of the telephony service provider, for
example ";tsp=terrifictelecom.com". The syntax of the domain name
follows Internet domain name rules and is defined in [RFC1035].
A. Vaha-Sipila Expires March, 2000 [Page 11]
Internet-Draft URLs for Telephone Calls September 1999
2.5.11 Additional parameters
In addition to T.33 and ISDN subaddresses, modem types and area
specifiers, future extensions to this URL scheme may add other
additional parameters (<future-extension> in the BNF) to these URLs.
These parameters are added to the URL after a semicolon (";").
Implementations MUST be prepared to handle additional and/or unknown
parameters gracefully. Implementations MAY opt not to use the URL if
it contains unknown parameters.
For example, <future-extension> 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. Whenever a
<future-extension> is used in an open environment, its syntax and
usage MUST be properly documented in an RFC.
<future-extension> nonterminal a rephrased version of, and compatible
with the <other-param> as defined in [RFC2543] (which actually
borrows BNF from an earlier version of this specification).
2.6 Examples of Use
tel:+358-555-1234567
This URL points to a phone number in Finland capable of receiving
voice calls. The hyphens are included to make the number more human-
readable: country and area codes have been separated from the
subscriber number.
fax:+358.555.1234567
The above URL describes a phone number which can receive fax calls.
It uses dots instead of hyphens as separators, but they have no
effect on the functionality.
modem:+3585551234567;type=v32b?7e1;type=v110
This phone number belongs to an entity which is able to receive data
calls. The user agent may opt to use either a ITU-T V.32bis modem (or
a faster one, which is compatible with V.32bis), using settings of 7
data bits, even parity and one stop bit, or an ISDN connection using
ITU-T V.110 protocol.
tel:+358-555-1234567;postd=pp22
The above URL instructs the user agent to place a voice call to
A. Vaha-Sipila Expires March, 2000 [Page 12]
Internet-Draft URLs for Telephone Calls September 1999
+358-555-1234567, then wait for an implementation-dependent time (for
example, two seconds) and emit two DTMF dialing tones "2" on the line
(for example, to choose a particular extension number, or to invoke a
particular service).
tel:0w003585551234567
This URL places a voice call to the given number. The number format
is intended for local use: the first zero opens an outside line, the
"w" character waits for a second dial tone, and the number already
has the international access code appended to it ("00"). This kind of
phone number MUST NOT be used in an environment where all users of
this URL might not be able to successfully dial out by using this
number directly. However, this might be appropriate for pages in a
company intranet.
tel:+1234567890;phone-context=+1234;vnd.foo.ext=foo
The URL describes a phone number which, even if it is written in its
international form, is only usable within the numbering area where
phone numbers start with +1234. There is also a proprietary extension
"vnd.foo.ext", which has the value "foo". The meaning of this
extension is application-specific. Note that the order of these
parameters (phone-context and vnd.foo.ext) is irrelevant.
2.7 Rationale behind the syntax
2.7.1 Why distinguish between call types?
URLs locate resources, which in this case is some telecommunications
equipment at a given phone number. However, it is not necessarily
enough to know the subscriber number in order to successfully
communicate with that equipment. Digital phone networks distinguish
between voice, fax and data calls (and possibly other types of calls,
not discussed in this specification). To be able to successfully
connect to, say, a fax machine, the caller may have to specify that a
fax call is being made. Otherwise the call might be routed to the
voice number of the subscriber. In this sense, the call type is an
integral part of the 'location' of the target resource.
The reason to have the call type in the scheme specifier is to make
the URL simple to remember and use. Making it a parameter, much like
the way modem parameters are handled now, will substantially reduce
the usability of this URL (to the humans).
2.7.2 Why "tel" is "tel"?
A. Vaha-Sipila Expires March, 2000 [Page 13]
Internet-Draft URLs for Telephone Calls September 1999
There has been discussion on whether the scheme name "tel" is
appropriate. To summarize, these are the points made against the
other proposals.
callto URL schemes locate a resource and do not specify
an action to be taken.
telephone Too long. Also, "tel" considered to be a more
international form.
phone Was countered on the basis that "tel" is more
internationally acceptable.
2.7.3 Why to use E.164 numbering?
It should be noted that phone numbers may have 'hierarchical'
characteristics, so that one could build a 'forest' of phone numbers
with country codes as roots, area codes as branches and subscriber
numbers as leaves. However, this is not always the case. Not all
areas have area codes; some areas may have different area codes
depending on how one wants to route the call; some numbers must
always be dialled "as is", without prepending area or country codes;
and area codes can and do change.
Usually, if something has a hierarchical structure, the URL syntax
should reflect that fact. These URLs are an exception.
Phone numbers are written almost always in some form which resembles
the E.164 notation. Because of this, the syntax in this specification
is intuitively clear to most people. This is the usual way to write
phone numbers in business cards, advertisements, telephone books and
so on.
Also, when writing the phone number in the form described in this
specification, the writer does not need to know which part of the
number is the country code and which part is the area code. If a
hierarchical URL would be used (with a "/" character separating the
parts of the phone numbers), the writer of the URL would have to know
which parts are which.
Finally, when phone numbers are written in the international form as
specified here, they are unambiguous and can always be converted to
the local dialing convention, given that the user agent has the
knowledge of the local country and area codes.
2.7.4 Not everyone has the same equipment as you
There are several ways for the subscriber to dial a phone number:
A. Vaha-Sipila Expires March, 2000 [Page 14]
Internet-Draft URLs for Telephone Calls September 1999
- By pulse dialing. Typically old telephone exchanges. Usually
this dialing method has only to be used to set up the call; after
connecting to the remote entity, <post-dial> can be sent to the
line using DTMF, because it will typically be processed by the
remote entity, not the telephone network.
- By DTMF. These are the 'beeps' that you hear when you dial on
most phones.
- By direct network signalling. ISDN subscribers and mobile phone
users usually have this. There is no dial tone (or if there is, it
is generated locally by the equipment), and the number of the
called party is communicated to the telephone network using some
network signalling method. After setting up the call, <post-dial>
sequences are usually sent using DTMF codes.
2.7.5 Do not confuse global and local contexts
As an example, +123456789 will be dialled in many countries as
00123456789, where the leading "00" is a prefix for international
calls. However, if a URL contains a local phone number 00123456789,
the user-agent MUST NOT assume that this number is equal to a global
phone number +123456789. If a user-agent received a telephony URL
with a local number in it, it must make sure that it knows the
context in which the local phone number is to be processed. Equally,
anyone sending a telephony URL should take into consideration that
the recipient may have insufficient information about the phone
number's context.
3. Comments on usage
These are examples of the recommended usage of this URL in HTML
documents.
First of all, the number SHOULD be visible to the end user, if it is
conceivable that the user might not have a user agent which is able
to use these URLs.
Telephone: <a href="tel:+3585551234567">+358-555-1234567</a>
Second, on a public HTML page, the telehone number in the URL SHOULD
always be in the international form, even if the text of the link
uses some local format.
Telephone: <a href="tel:+3585551234567">(0555) 1234567</a>
A. Vaha-Sipila Expires March, 2000 [Page 15]
Internet-Draft URLs for Telephone Calls September 1999
or even
For more info, call <a href="tel:+15554383785965">1-555-IETF-
RULZ-OK</a>.
Moreover, if the number is a <local-phone-number>, and the scope of
the number is not clear from the context in which the URL is
displayed, a human-readable explanation SHOULD be included.
For customer service, dial <a href="tel:1234">1234</a> (only from
Terrific Telecom mobile phones).
4. References
NOTE. References to Internet-Drafts will be removed from the final
document which will be submitted to the RFC-Editor.
[CONV-URL] Conversational Multimedia URLs. 1997. Pete Cordell. An
Internet-Draft (work in progress).
<URL:ftp://ftp.nordu.net/internet-drafts/ draft-cordell-sg16-conv-
url-00.txt>
[RFC1035] Domain Names - Implementation and Specification. November
1987. P. Mockapetris. RFC 1035.
<URL:ftp://ftp.nordu.net/rfc/rfc1035.txt>
[RFC1738] Uniform Resource Locators (URL). December 1994. T.
Berners-Lee et al. RFC 1738.
<URL:ftp://ftp.nordu.net/rfc/rfc1738.txt>
[RFC1866] Hypertext Markup Language - 2.0. November 1995. T.
Berners-Lee & D. Connolly. RFC 1866.
<URL:ftp://ftp.nordu.net/rfc/rfc1866.txt>
[RFC2048] Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures. November 1996. N. Freed et al. RFC 2048.
<URL:ftp://ftp.nordu.net/rfc/rfc2048.txt>
[RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels.
March 1997. S. Bradner. RFC 2119.
<URL:ftp://ftp.nordu.net/rfc/rfc2119.txt>
[RFC2234] Augmented BNF for Syntax Specifications: ABNF. November
1997. D. Crocker et al. RFC 2234.
<URL:ftp://ftp.nordu.net/rfc/rfc2234.txt>
A. Vaha-Sipila Expires March, 2000 [Page 16]
Internet-Draft URLs for Telephone Calls September 1999
[RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998.
C. Allocchio. RFC 2303. <URL:ftp://ftp.nordu.net/rfc/rfc2303.txt>
[RFC2304] Minimal FAX Address Format in Internet Mail. March 1998.
C. Allocchio. RFC 2304. <URL:ftp://ftp.nordu.net/rfc/rfc2304.txt>
[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax. August
1998. T. Berners-Lee et al. RFC 2396.
<URL:ftp://ftp.nordu.net/rfc/rfc2396.txt>
[RFC2543] SIP: Session Initiation Protocol. March 1999. M. Handley et
al. RFC 2543. <URL:ftp://ftp.nordu.net/rfc/rfc2543.txt>
[E.123] ITU-T Recommendation E.123: Telephone Network and ISDN
Operation, Numbering, Routing and Mobile Service: Notation for
National and International Telephone Numbers. 1993.
[E.164] ITU-T Recommendation E.164: Telephone Network and ISDN
Operation, Numbering, Routing and Mobile Service: Numbering Plan for
the ISDN Era. 1991.
[T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing the
Subaddress. 1996.
5. Security Considerations
It should be noted that the user agent SHOULD NOT call out without
the knowledge of the user because of associated risks, which include
- call costs (including long calls, long distance calls,
international calls and premium rate calls, or calls which do
not terminate due to <post-dial> sequences that have been left
out
by the user agent)
- wrong numbers inserted on web pages by malicious users
- making the user's phone line unavailable (off-hook) for a
malicious purpose
- opening a data call to a remote host, thus possibly opening a
back door to the user's computer
- revealing the user's (possibly unlisted) phone number to the
remote host in the caller identification data
A. Vaha-Sipila Expires March, 2000 [Page 17]
Internet-Draft URLs for Telephone Calls September 1999
All of these risks MUST be taken into consideration when designing
the user agent.
The user agent SHOULD have some mechanism that the user can use to
filter out unwanted numbers. The user agent SHOULD NOT use rapid
redialing of the number if it is busy to avoid the congestion of the
(signaling) network. Also, the user agent SHOULD detect if the number
is unavailable or if the call is terminated before the dialing string
has been completely processed (for example, the call is terminated
while waiting for user input) and not try to call again, unless
instructed by the user.
6. Acknowledgements
Writing this specification would not have been possible without
extensive support from many people.
Contributors include numerous people from IETF FAX, PINT, URI and
URLREG mailing lists, as well as from World Wide Web Consortium and
several companies, plus several individuals. Thanks to all people who
offered criticism, corrections and feedback.
All phone numbers and company names used in the examples of this
specification are fictional. Any similarities to real entities are
coincidental.
7. Authors' Addresses
Contact person and version control responsibility for this
specification:
Nokia Mobile Phones
Antti Vaha-Sipila
P. O. Box 68
FIN-33721 Tampere
Finland
Electronic mail: avs@iki.fi
antti.vaha-sipila@nokia.com
Please include your name and electronic mail address in all
communications. If you want to receive the newest version of this
specification electronically, send mail to the address above.
This document expires on the 24th of February, 2000, or when a new
version is released.
A. Vaha-Sipila Expires March, 2000 [Page 18]
Internet-Draft URLs for Telephone Calls September 1999
8. Full Copyright Statement
To be added to the final RFC.
A. Vaha-Sipila Expires March, 2000 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 22:23:46 |