INTERNET-DRAFT A. Vaha-Sipila
Expires 09-Feb-1999 Nokia
04-Aug-1998
URLs for Telephone Calls
<draft-antti-telephony-url-06.txt>
Status of This Memo
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."
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
''tel'', ''fax'' and ''modem'' for specifying the location of a
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.
Version history
| Changes to the previous versions are indicated by a bar in the
| left margin like in this section.
| In this file, the bars indicate changes since version 05.
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 New URL Schemes . . . . . . . . . . . . . . . . . . . . . 2
1.2 Formal Definitions . . . . . . . . . . . . . . . . . . . 3
1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. URL Schemes for Telephone Calls . . . . . . . . . . . . . 3
2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2.2 "tel" URL Scheme . . . . . . . . . . . . . . . . . . . . 3
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 2]
2.3 "fax" URL Scheme . . . . . . . . . . . . . . . . . . . . 4
2.4 "modem" URL Scheme . . . . . . . . . . . . . . . . . . . 4
2.5 Parsing telephone, fax and modem URLs . . . . . . . . . . 5
2.5.1 Call type . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.2 Phone numbers and their scope . . . . . . . . . . . . . 5
2.5.3 Separators in phone numbers . . . . . . . . . . . . . . 6
2.5.4 Converting the number to the local numbering scheme . . 6
2.5.5 Sending post-dial sequence after call setup . . . . . . 6
2.5.6 Pauses in dialing and post-dial sequence . . . . . . . 6
2.5.7 ISDN subaddresses . . . . . . . . . . . . . . . . . . . 7
2.5.8 T.33 subaddresses . . . . . . . . . . . . . . . . . . . 7
2.5.9 Data call parameters . . . . . . . . . . . . . . . . . 7
2.6 Examples of Use . . . . . . . . . . . . . . . . . . . . . 8
2.7 Rationale behind the syntax . . . . . . . . . . . . . . . 9
2.7.1 Why distinguish between call types? . . . . . . . . . . 9
2.7.2 Why "tel" is "tel"? . . . . . . . . . . . . . . . . . . 9
2.7.3 Why to use E.164 numbering? . . . . . . . . . . . . . . 10
2.7.4 Not everyone has the same equipment as you . . . . . . 10
3. Comments on usage . . . . . . . . . . . . . . . . . . . . 11
4. References . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
8. Full Copyright Statement . . . . . . . . . . . . . . . . . 13
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 for successfully
connecting 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].
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 3]
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 [RFC1738]) has been replaced by ";".
1.2 Formal definitions
Formal definitions follow [RFC2234]. This specification uses
elements from the 'core' definitions (Appendix A of [RFC2234]).
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 place a call to the remote
terminal using hardware and software at its disposal after it has
been properly configured.
These URL schemes are used to direct the user agent to place a
call using the telephone network. The network in question may be a
landline or mobile phone network. 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.
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 ":"
telephone-subscriber
telephone-scheme = "tel"
telephone-subscriber = global-phone-number / local-phone-number
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 4]
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit / dtmf-digit
/ pause-character)
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
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 = "+" 1*phonedigit [isdn-subaddress]
[t33-subaddress] [post-dial]
fax-local-phone = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[t33-subaddress] [post-dial]
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 / "-" / "+")
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 5]
2.5 Parsing telephone, fax and modem URLs
2.5.1 Call type
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.
| 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 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.
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 supported by this URL
scheme.
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
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 6]
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 cracaters 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 these URLs.
2.5.4 Converting the number to the local numbering scheme
After the telephone number has been extracted, it is
converted to the format that the user agent can use to place the
call. (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>
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.
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 7]
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.
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, if the information is not present.
The capability tokens are listed below. If capabilities
suggest that it is impossible to create a connection, the
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 8]
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").
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.
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.6 Examples of Use
tel:+358-555-1234567
This URL instructs the user agent to place a voice call to the
specified number in Finland. 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 instructs the user agent to place a fax call to
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 9]
the specified number. It uses dots instead of hyphens as
separators, but they have no effect on the functionality.
modem:+3585551234567;type=v32b?7e1;type=v110
This URL instructs the user agent to place a data call to the
specified number. 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
+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.
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 URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 10]
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:
| - 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
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 11]
| 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.
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>
| 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>
[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.
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 12]
<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>
[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>
[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)
- 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
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
A. Vaha-Sipila URLs for Telephone Calls August 1998
INTERNET-DRAFT Expires February, 1999 [Page 13]
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
| 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: antti.vaha-sipila@nmp.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 9th of February, 1999, or when a
new version is released.
8. Full Copyright Statement
To be added to the final RFC.
A. Vaha-Sipila URLs for Telephone Calls August 1998