INTERNET-DRAFT                                           A. Vaha-Sipila
Expires 18-May-1998                                               Nokia
                                                            14-Nov-1997

                          URLs for Telephony
                  <draft-antti-telephony-url-02.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 learn the current status of any Internet-Draft, please check
    the "1id-abstracts.txt" listing contained in the Internet-Drafts
    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
    (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (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
    ''telephone'', ''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.

Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
   1.1 New URL Schemes . . . . . . . . . . . . . . . . . . . . . 2
   1.2 Formal Definitions  . . . . . . . . . . . . . . . . . . . 2
   1.3 Requirements  . . . . . . . . . . . . . . . . . . . . . . 2
   2. URL Schemes for Telephone Calls  . . . . . . . . . . . . . 3
   2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3
   2.2 "telephone" URL Scheme  . . . . . . . . . . . . . . . . . 3
   2.3 "fax" URL Scheme  . . . . . . . . . . . . . . . . . . . . 3
   2.4 "modem" URL Scheme  . . . . . . . . . . . . . . . . . . . 4
   2.5 Parsing telephone, fax and modem URLs . . . . . . . . . . 4

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  2]

   2.6 Examples of Use . . . . . . . . . . . . . . . . . . . . . 7
   3. References . . . . . . . . . . . . . . . . . . . . . . . . 7
   4. Security Considerations  . . . . . . . . . . . . . . . . . 8
   5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 8

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.

    > This specification defines three new URL schemes: "telephone",
    > "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 "telephone" 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 name (scheme specifier) for the URL is
    > "telephone" as recommended by [E.123].

    > 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
    > [FAX-ADDR]. However, the syntax definition is a bit different
    > due to the fact that this document specifies URLs whereas
    > [FAX-ADDR] specifies electronic mail addresses. For example,
    > "/" (used in URLs to delimit path) has been replaced by ";".

1.2 Formal Definitions

    > Formal definitions follow [ABNF]. This specification uses
    > elements from the 'core' definitions (Appendix A of [ABNF]).

1.3 Requirements

    Compliant software MUST follow this specification. Requirements
    are indicated by capitalized words as specified in [RFC2119].

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  3]


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 at its disposal.

    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, except
    > for the <user-name> and <password> in <modem-url>, which may
    > be case-sensitive, depending on the remote system.

2.2 "telephone" URL Scheme

    The URL syntax is formally described as follows:

    > telephone-url         = telephone-scheme ":"
    >                         telephone-subscriber
    > telephone-scheme      = "telephone"
    > telephone-subscriber  = global-phone-number / local-phone-number
    > 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 definition above):

    > fax-url               = fax-scheme ":" fax-subscriber
    >                         [fax-params]

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  4]

    > 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
    > fax-params            = ";type=" fax-capabilities
    > fax-capabilities      = "T2" / "T3" / "T4" / "T6"

2.4 "modem" URL Scheme

    The "modem" URL scheme has two free-text fields, which contain the
    user name and password for authentication. Certain characters in
    these fields are marked as "reserved", and they MUST be escaped
    using URL-encoding if present in the free-text fields. Characters
    not present in 7-bit US ASCII, unprintable characters and
    whitespace MUST also be escaped.

    reserved                = " " / ":" / "?" / ";" / "=" / "@" / "+"

    The URL syntax is formally described as follows:

    > modem-url             = modem-scheme ":" remote-host
    > modem-scheme          = "modem"
    > remote-host           = [user-name [":" password] "@"]
    >                         telephone-subscriber *modem-params
    > modem-params          = ";type=" data-capabilities
    > data-capabilities     = modem-type ["?" data-bits parity
    >                         stop-bits]
    > modem-type            = "V21" / "V22" / "V22b" /
    >                         "V23" / "V26" / "V32" /
    >                         "V32b" / "V34" / "V110" /
    >                         "V120" / "B103" / "B212" /
    >                         "X75"
    > data-bits             = "7" / "8"
    > parity                = "n" / "e" / "o" / "m" / "s"
    > stop-bits             = "1" / "2"
    > user-name             = *OCTET ;a user name for authentication,
    >                         ;in URL-encoded notation
    > password              = *OCTET ;a password for authentication,
    >                         ;in URL-encoded notation

2.5 Parsing telephone, fax and modem URLs

    > A. The type of call is specified by the scheme specifier.
    > "Telephone" 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.

    > B. <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

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  5]

    > 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 <DIGIT>, that is,
    numbers consisting only of non-numbers 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]. 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.

    > C. 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.

    > D. 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.

    > E. The number may contain a <post-dial> sequence, which MUST be
    > dialled using Dual Tone Multifrequency (DTMF) in-band signalling
    > after the call setup is complete. If the user agent does not
    > support DTMF, <post-dial> MUST be ignored. In that case, the
    > user SHOULD be notified.

    > F. A local phone number or a post-dial sequence may contain
    > <pause-character> characters which indicate a pause of 1 second
    > while dialing ("p"), or a wait for dial tone ("w"). User agents
    > SHOULD support this method of dialing. 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.

    > Any <dtmf-digit> characters and all dial string characters after
    > the first <pause-character> or <dtmf-digit> MUST 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).

    > G. 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

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  6]

    > subaddressing is not supported by the caller, <isdn-subaddress>
    > MUST be ignored and the user SHOULD be notified.

    > H. 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.

    > I. <fax-params> or <modem-params> indicate which kind of telefax
    > or modem can be used to contact the remote entity. The user
    > agent MUST call out using compatible hardware, or request that
    > the network provides such a service. For the "modem" URL, 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 parsed capabilities
    suggest that it is impossible to create a connection, the
    connection MUST NOT be created.

    If new modem or fax types are standardized by ITU-T, this list can
    be extended with those capability tokens. Tokens are formed by
    taking the name of the standard and joining together the first
    letter, number and the first letter of the postfix. New
    capabilities SHOULD then be documented in an RFC. New non-ITU-T
    capabilities MUST be specified 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
    V110                              ITU-T V.110
    V120                              ITU-T V.120
    X75                               ITU-T X.75
    B103                              Bell 103
    B212                              Bell 212
    T2                                ITU-T T.2 (G1) facsimile
    T3                                ITU-T T.3 (G2) facsimile
    T4                                ITU-T T.4 (G3) facsimile
    T6                                ITU-T T.6 (G4) facsimile
    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".


A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  7]

    J. After a data connection has been established, <user-name> and
    <password> parts instruct the user agent of how to identify itself
    to the remote entity. How this identifying information is used is
    outside the scope of this document. For example, they might be
    given as parameters to an autologin script.

2.6 Examples of Use

    > telephone:+358-55-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.55.1234567

    > The above URL instructs the user agent to place a fax call to
    > the specified number. It uses dots instead of hyphens as
    > separators, but they have no effect on the functionality.

      modem:+358551234567;type=v34?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.34 modem (or a slower one, which is compatible with V.34), using
    settings of 7 data bits, even parity and one stop bit, or an ISDN
    connection using ITU-T V.110 protocol.

    > telephone:+358-55-1234567;postd=pp22

    The above URL instructs the user agent to place a voice call to
    +358-55-1234567, then wait two seconds and emit two DMTF dialing
    tones "2" on the line (for example, to choose a particular
    extension number).

    > telephone:0w00358551234567

    > 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.

3. References

    > [ABNF] Augmented BNF for Syntax Specifications: ABNF. 1997. D.
    > Crocker et al. An Internet-Draft (work in progress).
    > <URL:ftp://ftp.ds.internic.net/internet-drafts/
    > draft-drums-abnf-05.txt>

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  8]


    > [FAX-ADDR] PSTN and Fax Address Format in E-Mail Services. 1997.
    > C. Allocchio. An Internet-Draft (work in progress).
    > <URL:ftp://ftp.ds.internic.net/internet-drafts/
    > draft-ietf-fax-addressing-01.txt>

    [RFC1738] Uniform Resource Locators (URL). December 1994. T.
    Berners-Lee et al. <URL:ftp://ftp.ds.internic.net/rfc/rfc1738.txt>

    [RFC2119] Key Words for Use in RFCs to Indicate Requirement
    Levels. March 1997. S. Bradner.
    <URL:ftp://ftp.ds.internic.net/rfc/rfc2119.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.

4. 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 prime 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

    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.

5. Authors' Addresses

    Contact person for this specification:

        Nokia Mobile Phones
        Antti Vaha-Sipila
        P. O. Box 68

A. Vaha-Sipila             URLs for Telephony             November 1997
INTERNET-DRAFT              Expires May, 1998               [Page  9]

        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 18th of May, 1998, or when a
    new version is released.












































A. Vaha-Sipila             URLs for Telephony             November 1997