rfc2806.txt

RFC 的详细文档！

Network Working Group                                    A. Vaha-Sipila
Request for Comments: 2806                                        Nokia
Category: Standards Track                                    April 2000


                        URLs for Telephone Calls

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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.

Table of 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 ...........................................    4
   2.3 "fax" URL scheme ...........................................    6
   2.4 "modem" URL scheme .........................................    6
   2.5 Parsing telephone, fax and modem URLs ......................    7
   2.5.1 Call type ................................................    7
   2.5.2 Phone numbers and their scope ............................    7
   2.5.3 Separators in phone numbers ..............................   10
   2.5.4 Converting the number to the local numbering scheme ......   10
   2.5.5 Sending post-dial sequence after call setup ..............   10
   2.5.6 Pauses in dialing and post-dial sequence .................   11
   2.5.7 ISDN subaddresses ........................................   11



Vaha-Sipila                 Standards Track                     [Page 1]

RFC 2806                URLs for Telephone Calls              April 2000


   2.5.8 T.33 subaddresses ........................................   11
   2.5.9 Data call parameters .....................................   12
   2.5.10 Telephony service provider identification ...............   13
   2.5.11 Additional parameters ...................................   14
   2.6 Examples of Use ............................................   14
   2.7 Rationale behind the syntax ................................   15
   2.7.1 Why distinguish between call types?  .....................   15
   2.7.2 Why "tel" is "tel"?  .....................................   16
   2.7.3 Why to use E.164-style numbering? ........................   16
   2.7.4 Not everyone has the same equipment as you ...............   17
   2.7.5 Do not confuse numbers with how they are dialled .........   17
   3. Comments on usage ...........................................   17
   4. References ..................................................   18
   5. Security Considerations .....................................   19
   6. Acknowledgements ............................................   20
   7. Author's Address ............................................   20
   8. Full Copyright Statement ....................................   21

1. Introduction

1.1 New URL schemes

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

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



Vaha-Sipila                 Standards Track                     [Page 2]

RFC 2806                URLs for Telephone Calls              April 2000


   When these URLs are used, the number of parameters should be kept to
   the minimum, unless this would make the context of use unclear.
   Having a short URL 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

   The ABNF (augmented Backus-Naur form) notation used in formal
   definitions follows [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.

   Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this
   document specifies strings of raw, unescaped characters. If those
   characters are present in a URL, and are not unreserved [RFC2396],
   they MUST be escaped as explained in [RFC2396] prior to using the
   URL.  In addition, when parsing a URL, it must be noted that some
   characters may have been escaped.

   An example: ABNF notation "%x20" means a single octet with a
   hexadecimal value of "20" (in US-ASCII, a space character). This must
   be escaped in a URL, and it becomes "%20".

   In addition, the ABNF in this document only uses lower case. The URLs
   are case-insensitive (except for the <future-extension> parameter,
   whose case-sensitivity is application-specific).

1.3 Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Compliant software MUST follow this specification.

2. URL schemes for telephone calls

2.1 Applicability

   In this document, "local entity" means software and hardware that can
   detect and parse one or more of these URLs and possibly place a call
   to a remote entity, or otherwise utilize the contents of the URL.

   These URL schemes are used to direct the local entity 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



Vaha-Sipila                 Standards Track                     [Page 3]

RFC 2806                URLs for Telephone Calls              April 2000


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

   The "tel", "fax" and "modem" URL schemes defined here do not use the
   hierarchical URL syntax; there are no applicable relative URL forms.
   The URLs are always case-insensitive, except for the <future-
   extension> parameter (see below), whose case-sensitivity is
   application specific. Characters in the URL MUST be escaped when
   needed as explained in [RFC2396].

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   = "+" 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
                        *(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-27 / %x2C / %x2F / %x3A /
                        %x3C-40 / %x45-4F / %x51-56 / %x58-60 /
                        %x65-6F / %x71-76 / %x78-7E)
                        *(%x21-3A / %x3C-7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]



Vaha-Sipila                 Standards Track                     [Page 4]

RFC 2806                URLs for Telephone Calls              April 2000


                        ; See sections 1.2 and 2.5.2
service-provider      = ";" provider-tag "=" provider-hostname
provider-tag          = "tsp"
provider-hostname     = domain ; <domain> is defined in [RFC1035]
                        ; See section 2.5.10
future-extension      = ";" 1*(token-char) ["=" ((1*(token-char)
                        ["?" 1*(token-char)]) / quoted-string )]
                        ; See section 2.5.11 and [RFC2543]
token-char            = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                        / %x41-5A / %x5E-7A / %x7C / %x7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]
                        ; See sections 1.2 and 2.5.11
quoted-string         = %x22 *( "\" CHAR / (%x20-21 / %x23-7E
                        / %x80-FF )) %x22
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]
                        ; See sections 1.2 and 2.5.11
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"

   The URL starts with <telephone-scheme>, which tells the local entity
   that what follows is a URL that should be parsed as described in this
   document. After that, the URL contains the phone number of the remote
   entity. Phone numbers can also contain subaddresses, which are used
   to identify different remote entities under the same phone number. If
   a subaddress is present, it is appended to the phone number after
   ";isub=". Phone numbers can also contain a post-dial sequence. This
   is what is often used with voice mailboxes and other services that
   are controlled by dialing numbers from your phone keypad while the
   call is in progress. The <post-dial> sequence describes what and when
   the local entity should send to the phone line.

   Phone numbers can be either "global" or "local". Global numbers are
   unambiguous everywhere. Local numbers are usable only within a
   certain area, which is called "context", see section 2.5.2.

   Local numbers always have an <area-specifier>, which specifies the
   context in which the number is usable (the same number may have
   different interpretation in different network areas). The context can
   be indicated with three different prefixes. A <global-network-prefix>
   indicates that the number is valid within a numbering area whose
   global numbers start with <global-network-prefix>. Similarly,
   <local-network-prefix> means that the number is valid within a



Vaha-Sipila                 Standards Track                     [Page 5]

RFC 2806                URLs for Telephone Calls              April 2000


   numbering area whose numbers (or dial strings) start with it. A
   <private-prefix> is a name of a context. The local entity must have
   knowledge of this private context to be able to deduce whether it can
   use the number, see section 2.5.2. Additional information about the
   phone number's usage can be included by adding the name of the
   telephony services provider in <service-provider>, see section
   2.5.10.

   The <future-extension> mechanism makes it possible to add new