idnits 2.17.1 draft-antti-telephony-url-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1866' is defined on line 759, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'CONV-URL' ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2303 (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2304 (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Vaha-Sipila 2 Expires 8-Apr-2000 Nokia 3 8-Oct-1999 5 URLs for Telephone Calls 6 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 The distribution of this document before its expiry date is 36 unlimited. 38 Abstract 40 This document specifies URL (Uniform Resource Locator) schemes 41 terminal in the phone network and the connection types (modes of 42 operation) that can be used to connect to that entity. This 43 specification covers voice calls (normal phone calls, answering 44 machines and voice messaging systems), facsimile (telefax) calls and 45 data calls, both for POTS and digital/mobile subscribers. 47 Table of Contents 49 1. Introduction ................................................ 3 50 1.1 New URL schemes ............................................ 3 51 1.2 Formal definitions ......................................... 3 52 1.3 Requirements ............................................... 4 53 2. URL schemes for telephone calls ............................. 4 54 2.1 Applicability .............................................. 4 55 2.2 "tel" URL scheme ........................................... 4 56 2.3 "fax" URL scheme ........................................... 5 57 2.4 "modem" URL scheme ......................................... 6 58 2.5 Parsing telephone, fax and modem URLs ...................... 6 59 2.5.1 Call type ................................................ 6 60 2.5.2 Phone numbers and their scope ............................ 7 61 2.5.3 Separators in phone numbers .............................. 9 62 2.5.4 Converting the number to the local numbering scheme ...... 9 63 2.5.5 Sending post-dial sequence after call setup .............. 9 64 2.5.6 Pauses in dialing and post-dial sequence ................. 10 65 2.5.7 ISDN subaddresses ........................................ 10 66 2.5.8 T.33 subaddresses ........................................ 10 67 2.5.9 Data call parameters ..................................... 11 68 2.5.10 Telephony service provider identification ............... 12 69 2.5.11 Additional parameters ................................... 12 70 2.6 Examples of Use ............................................ 13 71 2.7 Rationale behind the syntax ................................ 14 72 2.7.1 Why distinguish between call types? ..................... 14 73 2.7.2 Why "tel" is "tel"? ..................................... 14 74 2.7.3 Why to use E.164 numbering? .............................. 15 75 2.7.4 Not everyone has the same equipment as you ............... 15 76 2.7.5 Do not confuse global and local contexts ................. 16 77 3. Comments on usage ........................................... 16 78 4. References .................................................. 17 79 5. Security Considerations ..................................... 18 80 6. Acknowledgements ............................................ 19 81 7. Authors' Addresses .......................................... 19 82 8. Full Copyright Statement .................................... 20 84 1. Introduction 86 1.1 New URL schemes 88 URLs that designate phone or fax numbers that can be dialed have been 89 brought forward in other Internet-Drafts. However, none of these has 90 reached the RFC status. This document tries to remedy the situation. 91 All interested parties are invited to submit comments on this 92 Internet-Draft. Contact information can be found at the end of this 93 document. 95 See also [CONV-URL] for more discussion on conversational URLs. 97 This specification defines three new URL schemes: "tel", "fax" and 98 "modem". They are intended for describing a terminal that can be 99 contacted using the telephone network. The description includes the 100 subscriber (telephone) number of the terminal and the necessary 101 parameters to be able to successfully connect to that terminal. 103 The "tel" scheme describes a connection to a terminal that handles 104 normal voice telephone calls, a voice mailbox or another voice 105 messaging system or a service that can be operated using DTMF codes. 107 The "fax" scheme describes a connection to a terminal that can handle 108 telefaxes (facsimiles). The name (scheme specifier) for the URL is 109 "fax" as recommended by [E.123]. 111 The "modem" scheme describes a connection to a terminal that can 112 handle incoming data calls. The term "modem" refers to a device that 113 does digital-to-analog and analog-to-digital conversions; in addition 114 to these, a "modem" scheme can describe a fully digital connection. 116 The notation for phone numbers is the same which is specified in 117 [RFC2303] and [RFC2304]. However, the syntax definition is a bit 118 different due to the fact that this document specifies URLs whereas 119 [RFC2303] and [RFC2304] specify electronic mail addresses. For 120 example, "/" (used in URLs to separate parts in a hierarchical URL 121 [RFC2396]) has been replaced by ";". In addition, this URL scheme has 122 been synchronized with [RFC2543]. 124 When these URLs are used, the number of parameters should be kept to 125 minimum. This is especially important if the URL is intended to be 126 shown to the end user, printed, or otherwise distributed so that it 127 is visible. 129 1.2 Formal definitions 130 Formal definitions follow [RFC2234]. This specification uses elements 131 from the 'core' definitions (Appendix A of [RFC2234]). Some elements 132 have been defined in previous RFCs. If this is the case, the RFC in 133 question has been referenced in comments. 135 1.3 Requirements 137 Compliant software MUST follow this specification. Requirements are 138 indicated by capitalized words as specified in [RFC2119]. 140 2. URL schemes for telephone calls 142 2.1 Applicability 144 In this document, "user agent" means software that can detect and 145 parse one or more of these URLs and possibly place a call to the 146 remote terminal using hardware and software at its disposal after it 147 has been properly configured, or otherwise utilize the contents of 148 the URL. 150 These URL schemes are used to direct the user agent to place a call 151 using the telephone network, or as a method to transfer or store a 152 phone number plus other relevant data. The network in question may be 153 a landline or mobile phone network, or a combination of these. If the 154 phone network differentiates between (for example) voice and data 155 calls, or if the user agent has several different telecommunications 156 equipment at its disposal, it is possible to specify which kind of 157 call (voice/fax/data) is requested. The URL can also contain 158 information about the capabilities of the remote entity, so that the 159 connection can be established successfully. 161 None of the URL schemes do have a 'path' in them - they are always 162 absolute. The URLs are always case-insensitive, except for the 163 parameter (see below), whose case-sensitivity is 164 application specific. 166 All unsafe and reserved characters (when not used for their reserved 167 purpose) MUST be URL-encoded as explained in [RFC1738]. All 8-bit 168 characters MUST be URL-encoded. 170 2.2 "tel" URL scheme 172 The URL syntax is formally described as follows. For the basis of 173 this syntax, see [RFC2303]. 175 telephone-url = telephone-scheme ":" 176 telephone-subscriber 177 telephone-scheme = "tel" 178 telephone-subscriber = global-phone-number / local-phone-number 179 global-phone-number = "+" base-phone-number [isdn-subaddress] 180 [post-dial] *(area-specifier / service-provider / 181 future-extension) 182 base-phone-number = 1*phonedigit 183 local-phone-number = 1*(phonedigit / dtmf-digit / 184 pause-character) [isdn-subaddress] 185 [post-dial] *(area-specifier / service-provider / 186 future-extension) 187 isdn-subaddress = ";isub=" 1*phonedigit 188 post-dial = ";postd=" 1*(phonedigit / 189 dtmf-digit / pause-character) 190 area-specifier = ";" phone-context-tag "=" phone-context-ident 191 phone-context-tag = "phone-context" 192 phone-context-ident = network-prefix / private-prefix 193 network-prefix = global-network-prefix / local-network-prefix 194 global-network-prefix = "+" 1*phonedigit 195 local-network-prefix = 1*(phonedigit / dtmf-digit / pause-character) 196 private-prefix = (%x21-22 / %x24-29 / %x2C-2F / %x3A / %x3C-40 / 197 %x45-60 / %x65-7E) *(%x21-3A / %x3C-7E) 198 ; Unsafe and reserved characters must be encoded 199 ; as explained in [RFC1738] 200 service-provider = ";" provider-tag "=" provider-hostname 201 provider-tag = "tsp" 202 provider-hostname = domain ; is defined in [RFC1035] 203 future-extension = ";" 1*(token-char) ["=" ((1*(token-char) 204 ["?" 1*(token-char)]) / quoted-string )] 205 token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 206 / %x41-5A / %x5E-7A / %x7C / %x7E) 207 ; Unsafe and reserved characters must 208 ; be encoded as explained in [RFC1738] 209 quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7E / %80-FF ) %x22 210 ; Unsafe, reserved, and 8-bit characters must 211 ; be encoded as explained in [RFC1738] 212 phonedigit = DIGIT / visual-separator 213 visual-separator = "-" / "." / "(" / ")" 214 pause-character = one-second-pause / wait-for-dial-tone 215 one-second-pause = "p" 216 wait-for-dial-tone = "w" 217 dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D" 219 2.3 "fax" URL scheme 221 The URL syntax is formally described as follows (the definition 222 reuses nonterminals from the above definition). For the basis of this 223 syntax, see [RFC2303] and [RFC2304]. 225 fax-url = fax-scheme ":" fax-subscriber 226 fax-scheme = "fax" 227 fax-subscriber = fax-global-phone / fax-local-phone 228 fax-global-phone = "+" base-phone-number [isdn-subaddress] 229 [t33-subaddress] [post-dial] 230 *(area-specifier / service-provider / 231 future-extension) 232 fax-local-phone = 1*(phonedigit / dtmf-digit / 233 pause-character) [isdn-subaddress] 234 [t33-subaddress] [post-dial] 235 *(area-specifier / service-provider / 236 future-extension) 237 t33-subaddress = ";tsub=" 1*phonedigit 239 2.4 "modem" URL scheme 241 The URL syntax is formally described as follows (the definition 242 reuses nonterminals from the above definitions). For the basis of 243 this syntax, see [RFC2303]. 245 modem-url = modem-scheme ":" remote-host 246 modem-scheme = "modem" 247 remote-host = telephone-subscriber *modem-params 248 modem-params = ";type=" data-capabilities 249 data-capabilities = accepted-modem ["?" data-bits parity 250 stop-bits] 251 accepted-modem = "V21" / "V22" / "V22b" / 252 "V23" / "V26t" / "V32" / 253 "V32b" / "V34" / "V90" / 254 "V110" / "V120" / "B103" / 255 "B212" / "X75" / 256 "vnd." vendor-name "." modem-type 257 data-bits = "7" / "8" 258 parity = "n" / "e" / "o" / "m" / "s" 259 stop-bits = "1" / "2" 260 vendor-name = 1*(ALPHA / DIGIT / "-" / "+") 261 modem-type = 1*(ALPHA / DIGIT / "-" / "+") 263 2.5 Parsing telephone, fax and modem URLs 265 2.5.1 Call type 267 The type of call is specified by the scheme specifier. "Tel" means 268 that a voice call is opened. "Fax" indicates that the call should be 269 a facsimile (telefax) call. "Modem" means that it should be a data 270 call. Not all networks differentiate between the types of call; in 271 this case, the scheme specifier indicates the telecommunications 272 equipment type to use. 274 2.5.2 Phone numbers and their scope 276 and indicate the phone number 277 to be dialed. The phone number can be written in either international 278 or local notation. All phone numbers SHOULD always be written in the 279 international form if there is no good reason to use the local form. 281 Not all numbers are valid within all numbering areas. An optional 282 parameter is used to indicate the locale within 283 which this number is valid, or to qualify the phone number so that it 284 may be used unambiguously. The can take three 285 forms: , or . 288 If is present, the user agent MUST NOT attempt to 289 call out using the phone number if it cannot originate the call 290 within the specified locale. 292 There can be multiple instances of . In this case, 293 the number is valid in all of the given numbering areas. 295 The global prefix form is intended to act as the outermost context 296 for a phone number, so it will start with a "+", followed by some 297 part of an E.164 number. It also specifies the region in which the 298 phone number is valid. For example, if is 299 "+358", the given number is valid only within Finland (even if it is 300 a ). 302 The local prefix form is intended to act as an intermediate context 303 in those situations where the outermost context for a phone number is 304 given by another means. One example of use is where the user agent is 305 known to originate calls within the North American Number Plan Area, 306 so an "outermost" phone context can be assumed. The local context 307 could, for example, be used to indicate the area code within which an 308 associated phone number is situated. Thus "tel:456-7890;phone- 309 context=213" would suffice to deliver a call to the telephone number 310 "+1-213-456-7890". Note that the version including the implies further that the call should be originated within 312 the "area code 213" region. 314 The form is intended for use in those situations 315 where a publically accessible phone number is not provided, or some 316 other context is intended in which the sender and the recipient of 317 the telephony URL share an understanding of the private phone context 318 token, but differ in the digit string that this token represents. For 319 example, a private network numbering plan may be indicated by the 320 token "X-COMPANY-NET", but the private dialling plan from the locales 321 of the sender of the telephony URL and the user agent are different. 322 The syntax of these tokens will be left for future specification. 324 Unless the sender is absolutely sure that they share the same private 325 network access digit string with the user agent, then they SHOULD NOT 326 use a dialling plan number (a local phone number, or one qualified by 327 a local context), as the result may be incorrect. Instead, they 328 SHOULD use a private context; if the user agent does not support 329 dialling into the private network indicated by that context, then the 330 request can be rejected. If it does, then it will use the access 331 digit string appropriate for its locale. 333 Note that the use of is orthogonal to use of the 334 telephony service provider parameter (see 2.5.10); it qualifies the 335 phone number, whilst the parameter indicates the 336 carrier to be used for the call attempt. 338 For example, a large company may have private network 339 interconnections between its sites, as well as connections to the 340 Global Switched Telephone Network. A phone number may be given in 341 "public network" form, but with a indicating that 342 the call should be carried over the corporate network. 344 Conversely, it would be possible to represent a phone number in 345 private network form, with a private context to indicate this, but 346 indicate a public telephony service provider. This would request that 347 the user agent convert the private network number plan address into a 348 form that can be carried using the selected service provider. 350 Any telephone number MUST contain at least one or 351 , that is, subscriber numbers consisting only of pause 352 characters are not allowed. 354 International numbers MUST begin with the "+" character. Local 355 numbers MUST NOT contain that character. International numbers MUST 356 be written with the country (CC) and national (NSN) numbers as 357 specified in [E.123] and [E.164]. International numbers have the 358 property of being totally unambiguous everywhere in the world if the 359 user agent is properly configured. 361 Local numbers MAY be used if the number only works from inside a 362 certain geographical area or a network. Note that some numbers may 363 work from several networks but not from the whole world - these 364 SHOULD be written in international form, either with a set of 365 global-phone-prefixes or with a parameter to 366 specify the regions within which the numbers are valid. URLs 367 containing local phone numbers should only appear in an environment 368 where all user agents can get the call successfully set up by passing 369 the number to the dialing entity "as is". An example could be a 370 company intranet, where all user agents are located under a the same 371 private telephone exchange. If local phone numbers are used, the 372 document in which they are present SHOULD contain an indication of 373 the context in which they are intended to be used, and an appropriate 374 SHOULD be present in the URL. 376 In some regions, it is popular to write phone numbers using 377 alphabetic characters which correspond to certain numbers on the 378 telephone keypad. Letters in characters do not have 379 anything to do with this, nor is this method supported by these URL 380 schemes. 382 It should also be noted that implementations MUST NOT assume that 383 telephone numbers have a maximum, minimum or fixed length, or that 384 they would always begin with a certain number. Implementors are 385 encouraged to familiarize themselves with the international 386 standards. 388 2.5.3 Separators in phone numbers 390 All characters MUST be removed from the phone 391 number by the user agent before using it do dial out. These 392 characters are present only to aid readability: they MUST NOT have 393 any other meaning. Note that although [E.123] recommends the use of 394 space (SP) characters as the separators, spaces MUST NOT be used in 395 phone numbers. 397 2.5.4 Converting the number to the local numbering scheme 399 After the telephone number has been extracted, it can be converted to 400 the local dialing convention. (For example, the "+" character might 401 be replaced by the international call prefix, or the international 402 and trunk prefixes might be removed to place a local call.) Numbers 403 that have been specified using or 404 MUST be used by the user agent "as is", without any conversions. 406 2.5.5 Sending post-dial sequence after call setup 407 The number may contain a sequence, which MUST be dialled 408 using Dual Tone Multifrequency (DTMF) in-band signalling or pulse 409 dialing after the call setup is complete. If the user agent does not 410 support DTMF or pulse dialing after the call has been set up, MUST be ignored. In that case, the user SHOULD be notified. 413 2.5.6 Pauses in dialing and post-dial sequence 415 A local phone number or a post-dial sequence may contain characters which indicate a pause while dialing ("p"), or 417 a wait for dial tone ("w"). 419 User agents MAY support this method of dialing, and the final 420 interpretation of these characters is left to the user agent. It is 421 recommended that the length of the pause is about one second. 423 If it is not supported, user agents MUST ignore everything in the 424 dial string after the first and the user SHOULD be 425 notified. The user or the user agent MAY opt not to place a call if 426 this feature is not supported and these characters are present in the 427 URL. 429 Any characters and all dial string characters after the 430 first or SHOULD be sent to line using 431 DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is 432 done using direct network signaling (a digital subscriber loop or a 433 mobile phone). If the local infrastructure does not support DTMF 434 codes, the user agent MAY opt to use pulse dialing. However, it 435 should be noted that certain services which are controlled using DTMF 436 tones cannot be controlled with pulse dialing. If pulse dialing is 437 used, the user SHOULD be notified. 439 2.5.7 ISDN subaddresses 441 A phone number MAY also contain an which indicates 442 an ISDN subaddress. User agent SHOULD support ISDN subaddresses. 443 These addresses are sent to the network by using a method available 444 to the user agent (typically, ISDN subscribers send the address with 445 the call setup signalling). If ISDN subaddressing is not supported by 446 the caller, MUST be ignored and the user SHOULD be 447 notified. The user or the user agent MAY opt not to place a call if 448 this feature is not supported. 450 2.5.8 T.33 subaddresses 452 A fax number MAY also contain a , which indicates the 453 start of a T.33 subaddress [T.33]. User agents SHOULD support this. 454 Otherwise MUST be ignored and the user SHOULD be 455 notified. The user or the user agent MAY opt not to place a call if 456 this feature is not supported. 458 2.5.9 Data call parameters 460 indicate the minimum compliance required from the user 461 agent to be able to connect to the remote entity. The minimum 462 compliance is defined as being equal to or a superset of the 463 capabilities of the listed modem type. 465 The user agent MUST call out using compatible hardware, or request 466 that the network provides such a service. 468 For example, if the user agent only has access to a V.22bis modem and 469 the URL indicates that the minimum acceptable connection is V.32bis, 470 the user agent MUST NOT try to connect to the remote host since 471 V.22bis is a subset of V.32bis. However, if the URL lists V.32 as the 472 minimum acceptable connection, the user agent can use V.32bis to 473 create a connection since V.32bis is a superset of V.32. 475 This feature is present because modem pools often have separate 476 numbers for slow modems and fast modems, or have different numbers 477 for analog and ISDN connections, or may use proprietary modems that 478 are incompatible with standards. It is somewhat analogous to the 479 connection type specifier (typecode) in FTP URLs [RFC1738]: it 480 provides the user agent with information that can not be deduced from 481 the scheme specifier, but is helpful for successful operation. 483 This also means that the number of data and stop bits and parity MUST 484 be set according to the information given in the URL, or to default 485 values given in this document, if the information is not present. 487 The capability tokens are listed below. If capabilities suggest that 488 it is impossible to create a connection, the connection MUST NOT be 489 created. 491 If new modem types are standardized by ITU-T, this list can be 492 extended with those capability tokens. Tokens are formed by taking 493 the number of the standard and joining together the first letter (for 494 example, "V"), number (for example, 22) and the first letter of the 495 postfix (for example "bis" would become "b"). 497 Proprietary modem types MUST be specified using the 'vendor naming 498 tree', which takes the form "vnd.x.y", in which "x" is the name of 499 the entity from which the specifications for the modem type can be 500 acquired and "y" is the type or model of the modem. Vendor names MUST 501 share the same name space with vendor names used in MIME types 502 [RFC2048]. Submitting the modem types to ietf-types list for review 503 is strongly recommended. 505 New capabilities MUST always be documented in an RFC, and they MUST 506 refer to this document or a newer version of it. 508 Capability Explanation 510 V21 ITU-T V.21 511 V22 ITU-T V.22 512 V22b ITU-T V.22bis 513 V23 ITU-T V.23 514 V26t ITU-T V.26ter 515 V32 ITU-T V.32 516 V32b ITU-T V.32bis 517 V34 ITU-T V.34 518 V90 ITU-T V.90 519 V110 ITU-T V.110 520 V120 ITU-T V.120 521 X75 ITU-T X.75 522 B103 Bell 103 523 B212 Bell 212 524 Data bits: "8" or "7" The number of data bits. If not 525 specified, defaults to "8". 526 Parity: "n", "e", "o", Parity. None, even, odd, mark or 527 "m", "s" space parity, respectively. If 528 not specified, defaults to "n". 529 Stop bits: "1" or "2" The number of stop bits. If not 530 specified, defaults to "1". 532 2.5.10 Telephony service provider identification 534 It is possible to indicate the identity of the telephony service 535 provider for the given phone number. MAY be used 536 by the user-agent to place the call using this network, to enhance 537 the user interface, for billing estimates or to otherwise optimize 538 its functionality. It MAY also be ignored by the user-agent. 539 consists of a fully qualified Internet domain name 540 of the telephony service provider, for example 541 ";tsp=terrifictelecom.com". The syntax of the domain name follows 542 Internet domain name rules and is defined in [RFC1035]. 544 2.5.11 Additional parameters 545 In addition to T.33 and ISDN subaddresses, modem types and area 546 specifiers, future extensions to this URL scheme may add other 547 additional parameters ( in the BNF) to these URLs. 548 These parameters are added to the URL after a semicolon (";"). 549 Implementations MUST be prepared to handle additional and/or unknown 550 parameters gracefully. Implementations MAY opt not to use the URL if 551 it contains unknown parameters. 553 For example, can be used to store application- 554 specific additional data about the phone number, its intended use, or 555 any conversions that have been applied to the number. Whenever a 556 is used in an open environment, its syntax and 557 usage MUST be properly documented in an RFC. 559 nonterminal a rephrased version of, and compatible 560 with the as defined in [RFC2543] (which actually 561 borrows BNF from an earlier version of this specification). 563 2.6 Examples of Use 565 tel:+358-555-1234567 567 This URL points to a phone number in Finland capable of receiving 568 voice calls. The hyphens are included to make the number more human- 569 readable: country and area codes have been separated from the 570 subscriber number. 572 fax:+358.555.1234567 574 The above URL describes a phone number which can receive fax calls. 575 It uses dots instead of hyphens as separators, but they have no 576 effect on the functionality. 578 modem:+3585551234567;type=v32b?7e1;type=v110 580 This phone number belongs to an entity which is able to receive data 581 calls. The user agent may opt to use either a ITU-T V.32bis modem (or 582 a faster one, which is compatible with V.32bis), using settings of 7 583 data bits, even parity and one stop bit, or an ISDN connection using 584 ITU-T V.110 protocol. 586 tel:+358-555-1234567;postd=pp22 588 The above URL instructs the user agent to place a voice call to 589 +358-555-1234567, then wait for an implementation-dependent time (for 590 example, two seconds) and emit two DTMF dialing tones "2" on the line 591 (for example, to choose a particular extension number, or to invoke a 592 particular service). 594 tel:0w003585551234567 596 This URL places a voice call to the given number. The number format 597 is intended for local use: the first zero opens an outside line, the 598 "w" character waits for a second dial tone, and the number already 599 has the international access code appended to it ("00"). This kind of 600 phone number MUST NOT be used in an environment where all users of 601 this URL might not be able to successfully dial out by using this 602 number directly. However, this might be appropriate for pages in a 603 company intranet. 605 tel:+1234567890;phone-context=+1234;vnd.company.option=foo 607 The URL describes a phone number which, even if it is written in its 608 international form, is only usable within the numbering area where 609 phone numbers start with +1234. There is also a proprietary extension 610 "vnd.company.option", which has the value "foo". The meaning of this 611 extension is application-specific. Note that the order of these 612 parameters (phone-context and vnd.company.option) is irrelevant. 614 2.7 Rationale behind the syntax 616 2.7.1 Why distinguish between call types? 618 URLs locate resources, which in this case is some telecommunications 619 equipment at a given phone number. However, it is not necessarily 620 enough to know the subscriber number in order to successfully 621 communicate with that equipment. Digital phone networks distinguish 622 between voice, fax and data calls (and possibly other types of calls, 623 not discussed in this specification). To be able to successfully 624 connect to, say, a fax machine, the caller may have to specify that a 625 fax call is being made. Otherwise the call might be routed to the 626 voice number of the subscriber. In this sense, the call type is an 627 integral part of the 'location' of the target resource. 629 The reason to have the call type in the scheme specifier is to make 630 the URL simple to remember and use. Making it a parameter, much like 631 the way modem parameters are handled now, will substantially reduce 632 the human readability of this URL. 634 2.7.2 Why "tel" is "tel"? 636 There has been discussion on whether the scheme name "tel" is 637 appropriate. To summarize, these are the points made against the 638 other proposals. 640 callto URL schemes locate a resource and do not specify 641 an action to be taken. 642 telephone Too long. Also, "tel" considered to be a more 643 international form. 644 phone Was countered on the basis that "tel" is more 645 internationally acceptable. 647 2.7.3 Why to use E.164 numbering? 649 It should be noted that phone numbers may have 'hierarchical' 650 characteristics, so that one could build a 'forest' of phone numbers 651 with country codes as roots, area codes as branches and subscriber 652 numbers as leaves. However, this is not always the case. Not all 653 areas have area codes; some areas may have different area codes 654 depending on how one wants to route the call; some numbers must 655 always be dialled "as is", without prepending area or country codes; 656 and area codes can and do change. 658 Usually, if something has a hierarchical structure, the URL syntax 659 should reflect that fact. These URLs are an exception. 661 Phone numbers are written almost always in some form which resembles 662 the E.164 notation. Because of this, the syntax in this specification 663 is intuitively clear to most people. This is the usual way to write 664 phone numbers in business cards, advertisements, telephone books and 665 so on. 667 Also, when writing the phone number in the form described in this 668 specification, the writer does not need to know which part of the 669 number is the country code and which part is the area code. If a 670 hierarchical URL would be used (with a "/" character separating the 671 parts of the phone numbers), the writer of the URL would have to know 672 which parts are which. 674 Finally, when phone numbers are written in the international form as 675 specified here, they are unambiguous and can always be converted to 676 the local dialing convention, given that the user agent has the 677 knowledge of the local country and area codes. 679 2.7.4 Not everyone has the same equipment as you 681 There are several ways for the subscriber to dial a phone number: 683 - By pulse dialing. Typically old telephone exchanges. Usually 684 this dialing method has only to be used to set up the call; after 685 connecting to the remote entity, can be sent to the 686 line using DTMF, because it will typically be processed by the 687 remote entity, not the telephone network. 689 - By DTMF. These are the 'beeps' that you hear when you dial on 690 most phones. 692 - By direct network signalling. ISDN subscribers and mobile phone 693 users usually have this. There is no dial tone (or if there is, it 694 is generated locally by the equipment), and the number of the 695 called party is communicated to the telephone network using some 696 network signalling method. After setting up the call, 697 sequences are usually sent using DTMF codes. 699 2.7.5 Do not confuse global and local contexts 701 As an example, +123456789 will be dialled in many countries as 702 00123456789, where the leading "00" is a prefix for international 703 calls. However, if a URL contains a local phone number 00123456789, 704 the user-agent MUST NOT assume that this number is equal to a global 705 phone number +123456789. If a user-agent received a telephony URL 706 with a local number in it, it must make sure that it knows the 707 context in which the local phone number is to be processed. Equally, 708 anyone sending a telephony URL should take into consideration that 709 the recipient may have insufficient information about the phone 710 number's context. 712 3. Comments on usage 714 These are examples of the recommended usage of this URL in HTML 715 documents. 717 First of all, the number SHOULD be visible to the end user, if it is 718 conceivable that the user might not have a user agent which is able 719 to use these URLs. 721 Telephone: +358-555-1234567 723 Second, on a public HTML page, the telehone number in the URL SHOULD 724 always be in the international form, even if the text of the link 725 uses some local format. 727 Telephone: (0555) 1234567 729 or even 731 For more info, call 1-555-IETF- 732 RULZ-OK. 734 Moreover, if the number is a , and the scope of 735 the number is not clear from the context in which the URL is 736 displayed, a human-readable explanation SHOULD be included. 738 For customer service, dial 1234 (only from 739 Terrific Telecom mobile phones). 741 4. References 743 NOTE. References to Internet-Drafts will be removed from the final 744 document which will be submitted to the RFC-Editor. 746 [CONV-URL] Conversational Multimedia URLs. 1997. Pete Cordell. An 747 Internet-Draft (work in progress). 748 751 [RFC1035] Domain Names - Implementation and Specification. November 752 1987. P. Mockapetris. RFC 1035. 753 755 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 756 Berners-Lee et al. RFC 1738. 757 759 [RFC1866] Hypertext Markup Language - 2.0. November 1995. T. 760 Berners-Lee & D. Connolly. RFC 1866. 761 763 [RFC2048] Multipurpose Internet Mail Extensions (MIME) Part Four: 764 Registration Procedures. November 1996. N. Freed et al. RFC 2048. 765 767 [RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels. 768 March 1997. S. Bradner. RFC 2119. 769 771 [RFC2234] Augmented BNF for Syntax Specifications: ABNF. November 772 1997. D. Crocker et al. RFC 2234. 773 775 [RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998. 776 C. Allocchio. RFC 2303. 778 [RFC2304] Minimal FAX Address Format in Internet Mail. March 1998. 779 C. Allocchio. RFC 2304. 781 [RFC2396] Uniform Resource Identifiers (URI): Generic Syntax. August 782 1998. T. Berners-Lee et al. RFC 2396. 783 785 [RFC2543] SIP: Session Initiation Protocol. March 1999. M. Handley et 786 al. RFC 2543. 788 [E.123] ITU-T Recommendation E.123: Telephone Network and ISDN 789 Operation, Numbering, Routing and Mobile Service: Notation for 790 National and International Telephone Numbers. 1993. < [E.164] ITU-T 791 Recommendation E.164: Telephone Network and ISDN Operation, 792 Numbering, Routing and Mobile Service: Numbering Plan for the ISDN 793 Era. 1991. 795 [T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing the 796 Subaddress. 1996. 798 5. Security Considerations 800 It should be noted that the user agent SHOULD NOT call out without 801 the knowledge of the user because of associated risks, which include 803 - call costs (including long calls, long distance calls, 804 international calls and premium rate calls, or calls which do 805 not terminate due to sequences that have been left 806 out 807 by the user agent) 809 - wrong numbers inserted on web pages by malicious users 811 - making the user's phone line unavailable (off-hook) for a 812 malicious purpose 814 - opening a data call to a remote host, thus possibly opening a 815 back door to the user's computer 817 - revealing the user's (possibly unlisted) phone number to the 818 remote host in the caller identification data 820 All of these risks MUST be taken into consideration when designing 821 the user agent. 823 The user agent SHOULD have some mechanism that the user can use to 824 filter out unwanted numbers. The user agent SHOULD NOT use rapid 825 redialing of the number if it is busy to avoid the congestion of the 826 (signaling) network. Also, the user agent SHOULD detect if the number 827 is unavailable or if the call is terminated before the dialing string 828 has been completely processed (for example, the call is terminated 829 while waiting for user input) and not try to call again, unless 830 instructed by the user. 832 6. Acknowledgements 834 Writing this specification would not have been possible without 835 extensive support from many people. 837 Contributors include numerous people from IETF FAX, PINT, URI and 838 URLREG mailing lists, as well as from World Wide Web Consortium and 839 several companies, plus several individuals. Thanks to all people who 840 offered criticism, corrections and feedback. 842 All phone numbers and company names used in the examples of this 843 specification are fictional. Any similarities to real entities are 844 coincidental. 846 7. Authors' Addresses 848 Contact person and version control responsibility for this 849 specification: 851 Nokia Mobile Phones 852 Antti Vaha-Sipila 853 P. O. Box 68 854 FIN-33721 Tampere 855 Finland 857 Electronic mail: avs@iki.fi 858 antti.vaha-sipila@nokia.com 859 Please include your name and electronic mail address in all 860 communications. If you want to receive the newest version of this 861 specification electronically, send mail to the address above. 863 This document expires on the 8th of April, 2000, or when a new 864 version is released. 866 8. Full Copyright Statement 868 To be added to the final RFC.