INTERNET-DRAFT                                           A. Vaha-Sipila
Expires 24-Feb-2000                                               Nokia
                                                            19-Aug-1999

                        URLs for Telephone Calls
                   <draft-antti-telephony-url-09.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 February, 2000         FORMFEED[Page 1]


Internet-Draft          URLs for Telephone Calls             August 1999


Table of Contents
















































A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 2]


Internet-Draft          URLs for Telephone Calls             August 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 ";".

1.2 Formal definitions

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

1.3 Requirements




A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 3]


Internet-Draft          URLs for Telephone Calls             August 1999


   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
      global-phone-number  = "+" 1*phonedigit [isdn-subaddress]
                             [post-dial] *(area-specifier / future-extension)
      local-phone-number   = 1*(phonedigit / dtmf-digit /
                             pause-character) [isdn-subaddress]
                             [post-dial] *(area-specifier / future-extension)
      isdn-subaddress      = ";isub=" 1*phonedigit
      post-dial            = ";postd=" 1*(phonedigit /
                             dtmf-digit / pause-character)
      area-specifier       = ";area=" "+" 1*phonedigit
      future-extension     = ";" 1*(ALPHA / DIGIT) ["="
                             1*(ALPHA / DIGIT) ["?"
                             1*(ALPHA / DIGIT) ]]



A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 4]


Internet-Draft          URLs for Telephone Calls             August 1999


      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]
                         *(area-specifier / future-extension)
      fax-local-phone  = 1*(phonedigit / dtmf-digit /
                         pause-character) [isdn-subaddress]
                         [t33-subaddress] [post-dial]
                         *(area-specifier / 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"



A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 5]


Internet-Draft          URLs for Telephone Calls             August 1999


      vendor-name       = 1*(ALPHA / DIGIT / "-" / "+")
      modem-type        = 1*(ALPHA / DIGIT / "-" / "+")

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.

   If <area-specifier> is present, it defines the numbering area within
   which this number is valid. For example, if "area=+358", the given
   number (either a global or local number) is meaningful only within
   Finland, and if "area=+12345", the given number is only meaningful if
   the caller's global telephone number starts with "+12345". If <area-
   specifier> is present, the user agent MUST NOT call out if the user
   agent is not located within that numbering area.

   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



A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 6]


Internet-Draft          URLs for Telephone Calls             August 1999


   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 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
   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. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 7]


Internet-Draft          URLs for Telephone Calls             August 1999


   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.

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



A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 8]


Internet-Draft          URLs for Telephone Calls             August 1999


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

   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



A. Vaha-Sipila           Expires February, 2000         FORMFEED[Page 9]


Internet-Draft          URLs for Telephone Calls             August 1999


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

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 the
   specified number. It uses dots instead of hyphens as separators, but
   they have no effect on the functionality.



A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 10]


Internet-Draft          URLs for Telephone Calls             August 1999


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



A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 11]


Internet-Draft          URLs for Telephone Calls             August 1999


2.7.2 Why "tel" is "tel"?

   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



A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 12]


Internet-Draft          URLs for Telephone Calls             August 1999


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



A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 13]


Internet-Draft          URLs for Telephone Calls             August 1999


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

   [RFC2396] Uniform Resource Identifiers (URI): Generic Syntax.  August
   1998. T. Berners-Lee et al. RFC 2396.
   <URL:ftp://ftp.nordu.net/rfc/rfc2396.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



A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 14]


Internet-Draft          URLs for Telephone Calls             August 1999


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



A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 15]


Internet-Draft          URLs for Telephone Calls             August 1999


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.

8. Full Copyright Statement

   To be added to the final RFC.

























A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 16]


Internet-Draft          URLs for Telephone Calls             August 1999



   1. Introduction ................................................    3

   1.1 New URL schemes ............................................    3

   1.2 Formal definitions .........................................    3

   1.3 Requirements ...............................................    3

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

      2.5 Parsing telephone, fax and modem URLs
      .............................................................    6

      2.5.1 Call type
      .............................................................    6

   2.5.2 Phone numbers and their scope ............................    6

   2.5.3 Separators in phone numbers ..............................    7

   2.5.4 Converting the number to the local numbering scheme ......    7

   2.5.5 Sending post-dial sequence after call setup ..............    7

   2.5.6 Pauses in dialing and post-dial sequence .................    7

   2.5.7 ISDN subaddresses ........................................    8

   2.5.8 T.33 subaddresses ........................................    8

   2.5.9 Data call parameters .....................................    8

      2.5.10 Additional parameters
      .............................................................   10




A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 17]


Internet-Draft          URLs for Telephone Calls             August 1999


   2.6 Examples of Use ............................................   10

   2.7 Rationale behind the syntax ................................   11

   2.7.1 Why distinguish between call types?  .....................   11

   2.7.2 Why "tel" is "tel"?  .....................................   12

      2.7.3 Why to use E.164 numbering?
      .............................................................   12

   2.7.4 Not everyone has the same equipment as you ...............   12

      3. Comments on usage ........................................   13

      4. References ...............................................   14

   5. Security Considerations .....................................   15

   6. Acknowledgements ............................................   15

   7. Authors' Addresses ..........................................   16

   8. Full Copyright Statement ....................................   16

























A. Vaha-Sipila           Expires February, 2000        FORMFEED[Page 18]