Internet Engineering Task Force Internet Draft Vaha-Sipila/Schulzrinne draft-antti-rfc2806bis-01.txt Nokia/Columbia U. January 1, 2002 Expires: June 2002 URIs for Telephone Calls STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Vaha-Sipila/Schulzrinne [Page 1]
Internet Draft RFC2806bis January 1, 2002 TABLEOFCONTENTS Vaha-Sipila/Schulzrinne [Page 2]
Internet Draft RFC2806bis January 1, 2002 Abstract This document is a revision of RFC 2806. This document specifies the URI (Uniform Resource Identifier) schemes "tel", "fax" and "modem" for specifying the address of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that terminal. This document covers voice calls (phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, for landline, ISDN and mobile subscribers. 1 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 2 URL Scheme Names The scheme names are "tel", "fax" and "modem". This specification defines three new URI schemes, "tel", "fax" and "modem", intended for describing terminals that can be contacted using the telephone network. The description includes the subscriber (telephone) number of the terminal and the parameters necessary to successfully connect to that terminal. The "tel" scheme describes a connection to a terminal that handles voice telephone calls, a voice mailbox or voice messaging system or a service that can be operated using DTMF tones. The "fax" scheme describes a connection to a terminal that handles telefaxes (facsimiles). The name (scheme specifier) for the URI is "fax" as recommended by ITU-T E.123 [2]. The "modem" scheme describes a connection to a terminal that handles incoming data calls. Here, "modem" describes "a device used for converting digital, signals into, and recovering them from, quasi- analog signals suitable for transmission over analog communications channels." [3]. The notation for phone numbers is the same as in RFC 2303 [4] and RFC 2304 [5]. However, the syntax differs since this document describes URIs whereas RFC 2303 and RFC 2304 specify electronic mail addresses. RFC 2303 and RFC 2304 use "/" to indicate parameters (qualifiers). Vaha-Sipila/Schulzrinne [Page 5]
Internet Draft RFC2806bis January 1, 2002 Since URI use the forward slash to describe path hierarchy, the URI schemes described here use the semicolon, in keeping with SIP URI conventions [6]. 3 Syntax Definitions The ABNF (augmented Backus-Naur form) notation used below for syntax definitions follows RFC 2234 [7] and uses elements from the core definitions (Appendix A of RFC 2234). Additional elements have been defined elsewhere and are referenced in the comments. The syntax definition follows RFC 2396, indicating the actual characters contained in the URI. Note that the reserved characters "+", ";", "=", and "?" MUST NOT be escaped if shown in the grammar definitions below as they are delimiters for the tel/fax/modem URI schemes. These reserved characters MUST be escaped if they appear in parameter values. 4 URI Comparisons URI comparisons are case-sensitive except that the scheme (tel, fax, modem) and parameter names are case-insensitive. Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396) are equivalent to their "% HEX HEX" encoding. 5 URI schemes for telephone calls A "client" is defined as software that can parse one or more of the URIs defined in this document and possibly place a call to a remote entity. These URI schemes are used to direct the client to place a call using the telephone network, or as a method to transfer or store a phone number plus other relevant data. The telephone network may be a landline or mobile phone network, or a combination of these. If the phone network differentiates between voice and data calls or if the client has several different types of telecommunications equipment, the URI scheme indicates which kind of call (voice, fax or data) is requested. The URI may also contain information about the capabilities of the remote entity. 5.1 The "tel" URI Scheme The "tel" URI has the following syntax: Vaha-Sipila/Schulzrinne [Page 6]
Internet Draft RFC2806bis January 1, 2002 telephone-uri = "tel:" subscriber subscriber = global-number / local-number global-number = "+" 1*phonedigit [isdn-subaddress] [post-dial] *(context / provider / other) local-number = 1*(phonedigit / dtmf-special / pause) [isdn-subaddress] [post-dial] area *(context / provider / other) isdn-subaddress = ";isub=" 1*phonedigit post-dial = ";postd=" 1*(phonedigit / dtmf / pause) context = ";phone-context=" global-prefix / local-prefix global-prefix = "+" 1*phonedigit local-prefix = 1*(phonedigit / dtmf / pause) provider = ";tsp=" host other = ";" oname "=" ovalue oname = 1*uric ovalue = *uric phonedigit = DIGIT / visual-separator visual-separator = "-" / "." / "(" / ")" pause = "p" / "w" dtmf-special = "*" / "#" / "A" / "B" / "C" / "D" 5.2 The "fax" URI Scheme The "fax" URI has the following syntax: fax-uri = "fax:" subscriber [t33-subaddress] t33-subaddress = ";tsub=" 1*phonedigit "fax" URIs differ from "tel" URIs by having an additional subaddress <t33-subaddress> parameter containing a T.33 subaddress [8]. Clients SHOULD support T.33 sub-addresses. Clients that do not support this feature SHOULD notify the user and give the user the option not to place the call. 5.3 The "modem" URI scheme The "modem" URI has the following syntax: modem-uri = "modem:" subscriber *(m-required / m-rec) m-required = ";type=" data-capabilities m-rec = ";rec=" data-capabilities data-capabilities = modem-type Vaha-Sipila/Schulzrinne [Page 7]
Internet Draft RFC2806bis January 1, 2002 ["?" data-bits parity stop-bits] modem-type = "V21" / "V22" / "V22b" / "V23" / "V26t" / "V32" / "V32b" / "V34" / "V90" / "V110" / "V120" / "B103" / "B212" / "X75" / modem-type data-bits = "7" / "8" parity = "n" / "e" / "o" / "m" / "s" stop-bits = "1" / "2" modem-type = "vnd." 1*(ALPHA / DIGIT / "-" ) The "modem" URI scheme adds to the "tel" URI the description of the capabilities of the remote modem. If present, instances of the <m-required> URI parameter describe the capabilities required by the client to connect to the remote modem indicated in the URI. If there are several <m-required> parameters, the client needs to be able to satisfy at least one. Each instance of the <m-rec> URI parameter lists a recommended configuration for the client. Typically, this is the fastest or most reliable modem type supported at the destination number. Each <m-rec> value MUST appear in one of the <m-required> parameters. Note that some modem standards incorporate others. For example, V.32bis is a superset of V.32, so that a client that supports V.32 can connect to the number listed in the URI modem:+1-212-555-0197;type=V32 This type selection feature makes it possible for the client to select an appropriate number among a set of numbers. Tokens and their corresponding modem type are listed below: Capability Modem Type 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 Vaha-Sipila/Schulzrinne [Page 8]
Internet Draft RFC2806bis January 1, 2002 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 If a new modem types is standardized by ITU-T, the <modem-type> token is formed by concatenating the first letter (for example, "V"), recommendation number (for example, 22) and the first letter of the postfix. For example, "bis" becomes "b" and "tre" becomes "t". The client MAY set the number of data bits, number of stop bits and the parity according to the <data-bits>, <stop-bits> and <parity> parameters, respectively. The parity values "none", "even", "odd", "mark" or "space" are indicated by "n", "e", "o", "m" or "s", respectively. If not specified, these values default to 8 data bits, no parity bits and one stop bit. Either none or all of these parameters must be specified. 6 Phone Numbers and Their Scope 6.1 Phone Numbers The <subscriber> part of the URI indicates the number to be dialed. The phone number can be written in either global (E.164) or local notation. All phone numbers SHOULD be written in the international form if there is no good reason to use the local form. Implementations MUST NOT assume that telephone numbers have a maximum, minimum or fixed length, or that they always begin with a certain number. 6.1.1 Pauses The "w" pause character instructs the client to wait for dial tone (primary or secondary), while the "p" character instructs the client to wait approximately one second before dialing the following digits. Any telephone number MUST contain at least one <phonedigit> or <dtmf-special>, that is, subscriber numbers consisting only of pause characters are not allowed. If a client does not support pauses, it MUST ignore everything in the dial string after the first <pause-character> and the user SHOULD be notified. The user or the client MAY opt not to place a call if this feature is not supported and these characters are present in the URI. Vaha-Sipila/Schulzrinne [Page 9]
Internet Draft RFC2806bis January 1, 2002 Any <dtmf-special> characters and all dial string characters after the first <pause-character> or <dtmf-special> SHOULD be sent to line using DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is done using direct network signaling such as via a digital subscriber loop or a mobile phone. If the local infrastructure does not support DTMF codes, the client MAY opt to use pulse dialing. Certain services which are controlled using DTMF tones cannot be controlled with pulse dialing. If pulse dialing is used, the user SHOULD be notified. 6.1.2 Separators in Phone Numbers Phone numbers MAY contain visual separators. Visual separators (<visual-separator>) merely aid readability and MUST be ignored by the client. Even though ITU-T E.123 [2] recommends the use of space characters as visual separators in printed telephone numbers, tel/modem/fax URIs MUST NOT use spaces. (Spaces require escaping in URIs, thus defeating the purpose of enhancing readability.) 6.1.3 Alphabetic Characters In some countries, it is popular to write phone numbers using alphabetic characters which correspond to certain numbers on the telephone keypad. The URI format does not support this since the mapping from alphabetic characters to digit is not standardized. Letters in <dtmf-special> elements indicate the DTMF digits with the high frequency of 1633 Hz. 6.1.4 Global and Local Numbers Global (international) numbers are identified by the "+" character prefix. International numbers MUST be written with the country (CC) and national (NSN) numbers as specified in E.123 and E.164 [2,9]. International numbers have the property of being unambiguous everywhere in the world if the client is properly configured and are RECOMMENDED. Local numbers only work within a certain geographical area or a certain part of the telephone network, e.g., a private branch exchange (PBX). Some numbers may work from several networks but not from the whole world; these SHOULD be written in international form, with a set of <phone-context> parameters to qualify their applicability. URIs with local phone numbers should only appear environments where all local entities can successfully set up the call by passing the number to the dialing software as written. If URIs with local phone numbers are used on a web page, the web page Vaha-Sipila/Schulzrinne [Page 10]
Internet Draft RFC2806bis January 1, 2002 SHOULD describe the context in which they are intended to be used, and the URI should contain an appropriate <phone-context> parameter. Section 6.1.5 describes the notion of contexts in more detail. 6.1.5 Number Contexts Some global numbers and all local numbers are only valid within certain numbering areas (contexts). The <phone-context> URI parameter is used to indicate where this number is valid or to qualify the phone number so that it may be used unambiguously. If the <phone-context> parameter is present, the client MUST NOT attempt to call out using the phone number if it cannot originate the call within the specified context. If a <local-number> is used, the <phone-context> parameter is REQUIRED. If there are multiple instances of <phone-context>, the number is valid in all of the contexts named. The <phone-context> value can take two forms, either a <local-prefix> or a <global-prefix>. The global prefix form is intended to act as the unambiguous context for a phone number. It starts with a "+", followed by some part of an E.164 number. It specifies the region in which the phone number is valid. For example, if <global-prefix> is "+358", the given number is valid only within Finland (country code 358), even if it is a <global-number>. The local prefix form is intended to act as a context in those situations where the unambiguous context for a phone number is given by other means. For example, if the client is known to originate calls only within the North American Number Plan Area, a global phone context of "+1" can be assumed. In that case, the local context could, for example, be used to indicate the area code within which an associated phone number is situated. Thus "tel:456-7890;phone- context=213" would suffice to deliver a call to the telephone number "+1-213-456-7890". The <phone-context> implies further that the call can only be originated within the "area code 213" region. 6.1.6 Converting a Global Number to the Local Dialing Scheme Before dialing, a global number must be converted to the local dialing convention. For example, the "+" character needs to be be replaced by the international call prefix, or the international and trunk prefixes might be removed to place a local call. Local numbers must be dialed as written, without conversion. 6.2 ISDN Subaddresses Vaha-Sipila/Schulzrinne [Page 11]
Internet Draft RFC2806bis January 1, 2002 A phone number MAY also contain an <isdn-subaddress> parameter which indicates an ISDN subaddress. The client SHOULD support ISDN subaddresses if it supports ISDN call setup. If ISDN subaddressing is not supported by the caller, <isdn-subaddress> MUST be ignored and the user SHOULD be notified. The user or the client MAY opt not to place a call if this feature is not supported. 6.3 Post-Dial Sequences The number may contain a <post-dial> parameter, which MUST be dialed 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, the <post-dial> parameter MUST be ignored and the user SHOULD be notified. 6.4 Other Parameters Future extensions to these URI schemes may add other parameters (<other> in the BNF). Such parameters can be either mandatory or optional. Optional parameters start with "x-". An implementation MAY ignore such parameters. Other parameters are mandatory; an implementation MUST NOT use the URI if it contains unknown mandatory parameters. For example, <other> parameters can be used to store application- specific additional data about the phone number, its intended use, or any conversions that have been applied to the number. All new parameters MUST be registered with IANA. 7 Examples tel:+358-555-1234567 This URI points to a phone number in Finland capable of receiving voice calls. The hyphens are included to make the number more human- readable; they separate country, area codes and subscriber number. fax:+358.555.1234567 This URI describes a phone number which can receive fax calls. It uses dots instead of hyphens as separators. modem:+3585551234567;type=v32b?7e1;type=v110 This phone number belongs to an entity which is able to Vaha-Sipila/Schulzrinne [Page 12]
Internet Draft RFC2806bis January 1, 2002 receive data calls. The client 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 the ITU-T V.110 protocol. tel:+358-555-1234567;postd=pp22 The URI instructs the client to place a voice call to +358-555-1234567, wait for two seconds and then 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;phone-context=+3585551234 This URI 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"). The context describes that the number is usable only in an environment where the client's phone number starts with the given string. tel:+1234567890;phone-context=+1234;x-parameter=foo The URI describes a phone number which, even if it is written in its international form, is only usable within the numbering area where phone numbers start with +1234. There is also a proprietary extension <parameter>, which has the value "foo". 8 Rationale 8.1 Why Distinguish Between Call Types? URIs 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 call type is placed in the scheme specifier to make the URI Vaha-Sipila/Schulzrinne [Page 13]
Internet Draft RFC2806bis January 1, 2002 simple to remember and use. Making it a parameter, much like the way modem parameters are handled now, would substantially reduce the human readability of the URI. 8.2 Why "tel"? "Tel" was chosen since it is widely recognized none of the other suggestions appeared appropriate. "Callto" was discarded since URI schemes locate a resource and do not specify an action to be taken. `Telephone" and "phone" were considered too long and not as internationally recognized. 8.3 Why Use E.164-style Numbering? E.164 refers to international telephone numbers, and the string of digits after the country code is usually a national matter. Phone numbers are usually written as a simple string of numbers everywhere. 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. Not all phone numbers can be expressed this way. Some numbers, such as emergency numbers, must always be dialled as written, without prepending area or country codes. 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 URI would be used (with a "/" character separating the parts of the phone numbers), the writer of the URI 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. 8.4 Equipment Diversity There are several ways for the subscriber to dial a phone number: Pulse dialing: Usually pulse 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 callee using DTMF, because it will typically be processed by the callee, not the telephone network. DTMF: Two-tone combinations are sent in-band to the telephone Vaha-Sipila/Schulzrinne [Page 14]
Internet Draft RFC2806bis January 1, 2002 switching equipment. Direct network signalling: ISDN subscribers and mobile phones usually signal via a separate packet (signaling) channel. There is no dial tone (or if there is, it is generated locally by the equipment). After setting up the call, post-dial sequences are usually sent using DTMF codes. 8.5 Do Not Confuse Numbers with How They Are Dialled As an example, +123456789 will be dialled in many countries as 00123456789, where the leading "00" is a prefix for international calls. However, if a URI contains the local phone number 00123456789, the user-agent MUST NOT assume that this number is equal to a global phone number +123456789. If a client receives a telephony URI with a local number in it, it MUST make sure that it knows the context in which the local phone number is to be processed, or else the number MUST NOT be used. Equally, the originator of a telephony URI must take into consideration that the recipient may have insufficient information about the phone number's context. 9 Usage of Telephone URIs in HTML The number SHOULD be visible to the end user if it is conceivable that the user might not have a client which is able to use these URIs. Telephone: <a href="tel:+3585551234567">+358-555-1234567</a> On a public HTML page, the telephone number in the URI 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>. Vaha-Sipila/Schulzrinne [Page 15]
Internet Draft RFC2806bis January 1, 2002 Moreover, if the number is a <local-number>, and the scope of the number is not clear from the context in which the URI is displayed, a human-readable explanation SHOULD be included. For customer service, dial <a href="tel:1234;phone-context=+358555">1234</a> (only from Acme Widget phones). 10 IANA Considerations <Other> parameters MUST be registered with IANA. Modem names for non-ITU-T modems MUST be registered with IANA. Modem names can either be simple names or be of the form "vnd.vendor.model". In the latter case, the vendor name SHOULD be the same as that used for Internet media type registrations [10]. 11 Security Considerations The security considerations parallel those for the mailto URL [11]. A client SHOULD NOT place calls without the consent of its owner. Placing calls automatically without appropriate user confirmation may incur a number of risks, such as those described below. o Calls may incur costs and may not terminate due to incorrect post-dial sequences. o The URI may be used to place malicious or annoying calls. o A call will take the user's phone line off-hook, thus preventing its use. o A modem call to a remote host may open the client's host to security breaches. o A call may reveal the user's, possibly unlisted, phone number to the remote host in the caller identification data, and may allow the attacker to correlate the client's phone number with other information such as the e-mail or IP address. o A call may use the same local number in different contexts, in which the number may have a different meaning. The client SHOULD NOT rapidly redial busy numbers to avoid the Vaha-Sipila/Schulzrinne [Page 16]
Internet Draft RFC2806bis January 1, 2002 congestion of the (signaling) network. The client 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. 12 Changes since RFC 2806 The specification is backwards-compatible with RFC 2806. o Editorial changes and clarifications. The document has been shortened and reorganized. Most paragraphs have been rewritten to be more concise. o Syntax now conforms to RFC 2396, in particular related to escaping. 13 Acknowledgements This document inherits a large amount of text from RFC 2806 [12]. 14 Authors' Addresses Antti Vaha-Sipila (quoted-printable: Antti V=E4h=E4-Sipil=E4) Nokia Mobile Phones P. O. Box 68 FIN-33721 Tampere Finland electronic mail: avs@iki.fi, antti.vaha-sipila@nokia.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu 15 Bibliography [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [2] International Telecommunication Union, "Notation for national and international phone numbers," Recommendation E.123, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1998. Vaha-Sipila/Schulzrinne [Page 17]
Internet Draft RFC2806bis January 1, 2002 [3] National Communications System, "Glosssary of telecommunications terms," Federal Standard FED-STD-1037C, National Communications System Technology and Standards Division, 1996. [4] C. Allocchio, "Minimal PSTN address format in internet mail," Request for Comments 2303, Internet Engineering Task Force, Mar. 1998. [5] C. Allocchio, "Minimal FAX address format in internet mail," Request for Comments 2304, Internet Engineering Task Force, Mar. 1998. [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [7] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," Request for Comments 2234, Internet Engineering Task Force, Nov. 1997. [8] International Telecommunication Union, "Facsimile routing utilizing the subaddress," Recommendation T.33, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 1996. [9] International Telecommunication Union, "The international public telecommunication numbering plan," Recommendation E.164, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1997. [10] N. Freed, J. Klensin, and J. Postel, "Multipurpose internet mail extensions (MIME) part four: Registration procedures," Request for Comments 2048, Internet Engineering Task Force, Nov. 1996. [11] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL scheme," Request for Comments 2368, Internet Engineering Task Force, July 1998. [12] A. Vaha-Sipila, "URLs for telephone calls," Request for Comments 2806, Internet Engineering Task Force, Apr. 2000. Full Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published Vaha-Sipila/Schulzrinne [Page 18]
Internet Draft RFC2806bis January 1, 2002 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Vaha-Sipila/Schulzrinne [Page 19]
Table of Contents 1 Terminology ......................................... 5 2 URL Scheme Names .................................... 5 3 Syntax Definitions .................................. 6 4 URI Comparisons ..................................... 6 5 URI schemes for telephone calls ..................... 6 5.1 The "tel" URI Scheme ................................ 6 5.2 The "fax" URI Scheme ................................ 7 5.3 The "modem" URI scheme .............................. 7 6 Phone Numbers and Their Scope ....................... 9 6.1 Phone Numbers ....................................... 9 6.1.1 Pauses .............................................. 9 6.1.2 Separators in Phone Numbers ......................... 10 6.1.3 Alphabetic Characters ............................... 10 6.1.4 Global and Local Numbers ............................ 10 6.1.5 Number Contexts ..................................... 11 6.1.6 Converting a Global Number to the Local Dialing Scheme ......................................................... 11 6.2 ISDN Subaddresses ................................... 11 6.3 Post-Dial Sequences ................................. 12 6.4 Other Parameters .................................... 12 7 Examples ............................................ 12 8 Rationale ........................................... 13 8.1 Why Distinguish Between Call Types? ................ 13 8.2 Why "tel"? ......................................... 14 8.3 Why Use E.164-style Numbering? ..................... 14 8.4 Equipment Diversity ................................. 14 8.5 Do Not Confuse Numbers with How They Are Dialled ................................................................ 15 9 Usage of Telephone URIs in HTML ..................... 15 10 IANA Considerations ................................. 16 11 Security Considerations ............................. 16 12 Changes since RFC 2806 .............................. 17 13 Acknowledgements .................................... 17 14 Authors' Addresses .................................. 17 15 Bibliography ........................................ 17 EOTOC Vaha-Sipila/Schulzrinne [Page 1]
