HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:33:24 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 27 Jun 1998 01:33:00 GMT ETag: "2e7d0c-637d-35944bcc" Accept-Ranges: bytes Content-Length: 25469 Connection: close Content-Type: text/plain INTERNET-DRAFT A. Vaha-Sipila Expires 29-Dec-1998 Nokia 25-Jun-1998 URLs for Telephone Calls 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 04. Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 New URL Schemes . . . . . . . . . . . . . . . . . . . . . 2 1.2 Formal Definitions . . . . . . . . . . . . . . . . . . . 2 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2. URL Schemes for Telephone Calls . . . . . . . . . . . . . 3 2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3 | 2.2 "tel" URL Scheme . . . . . . . . . . . . . . . . . . . . 3 2.3 "fax" URL Scheme . . . . . . . . . . . . . . . . . . . . 3 A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 2] 2.4 "modem" URL Scheme . . . . . . . . . . . . . . . . . . . 4 2.5 Parsing telephone, fax and modem URLs . . . . . . . . . . 4 2.6 Examples of Use . . . . . . . . . . . . . . . . . . . . . 7 2.7 The Choice of the Scheme Specifier . . . . . . . . . . . 8 3. References . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . 9 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10 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]. 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]). A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 3] 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 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 A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 4] The URL syntax is formally described as follows (the definition reuses nonterminals from the definition above). 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. 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" / "V110" / "V120" / "B103" / "B212" / "X75" / "vnd." vendor-name "." modem-type data-bits "7" / "8" parity "n" / "e" / "o" / "m" / "s" stop-bits "1" / "2" vendor-name 1*(ALPHA / DIGIT / "-" / "+") modem-type 1*(ALPHA / DIGIT / "-" / "+") 2.5 Parsing telephone, fax and modem URLs A. 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. B. and 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 , that is, subscriber numbers consisting only of non-numbers are not allowed. A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 5] 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 characters do not have | anything to do with this, nor is this supported by this URL | scheme. C. All 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 or MUST be used by the user agent "as is", without any conversions. E. The number may contain a 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, MUST be ignored. In that case, the user SHOULD be notified. F. A local phone number or a post-dial sequence may contain 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 A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 6] | 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 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 characters and all dial string characters after the first or 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. G. A phone number MAY also contain an 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, 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. H. A fax number MAY also contain a , which indicates the start of a T.33 subaddress [T.33]. User agents SHOULD support this. Otherwise 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. I. 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 A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 7] 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 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 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 A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 8] | 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. modem:+3585551234567;typev32b?7e1;typev110 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;postdpp22 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 The Choice of the Scheme Specifier | 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. A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 9] 3. References NOTE. References to Internet-Drafts will be removed from the final document which will be submitted to the RFC-Editor. [RFC2234] Augmented BNF for Syntax Specifications: ABNF. November 1997. D. Crocker et al. RFC 2234. [CONV-URL] Conversational Multimedia URLs. 1997. Pete Cordell. An Internet-Draft (work in progress). [RFC1738] Uniform Resource Locators (URL). December 1994. T. Berners-Lee et al. RFC 1738. [RFC2048] Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. November 1996. N. Freed et al. RFC 2048. [RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels. March 1997. S. Bradner. RFC 2119. [RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998. C. Allocchio. RFC 2303. [RFC2304] Minimal FAX Address Format in Internet Mail. March 1998. C. Allocchio. RFC 2304. [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 premium rate calls) - wrong numbers inserted on web pages by malicious users A. Vaha-Sipila URLs for Telephone Calls June 1998 INTERNET-DRAFT Expires December, 1998 [Page 10] - 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. 5. 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 29th of December, 1998, or when a new version is released. A. Vaha-Sipila URLs for Telephone Calls June 1998