idnits 2.17.1 draft-antti-telephony-url-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 1) being 59 lines 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 2 instances of lines with control characters 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 611, 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) Summary: 14 errors (**), 0 flaws (~~), 4 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 09-Feb-1999 Nokia 3 04-Aug-1998 5 URLs for Telephone Calls 6 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 The distribution of this document before its expiry date is 29 unlimited. 31 Abstract 33 This document specifies URL (Uniform Resource Locator) schemes 34 ''tel'', ''fax'' and ''modem'' for specifying the location of a 35 terminal in the phone network and the connection types (modes of 36 operation) that can be used to connect to that entity. This 37 specification covers voice calls (normal phone calls, answering 38 machines and voice messaging systems), facsimile (telefax) calls 39 and data calls, both for POTS and digital/mobile subscribers. 41 Version history 43 | Changes to the previous versions are indicated by a bar in the 44 | left margin like in this section. 46 | In this file, the bars indicate changes since version 05. 48 Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1 New URL Schemes . . . . . . . . . . . . . . . . . . . . . 2 52 1.2 Formal Definitions . . . . . . . . . . . . . . . . . . . 3 53 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 3 54 2. URL Schemes for Telephone Calls . . . . . . . . . . . . . 3 55 2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2 "tel" URL Scheme . . . . . . . . . . . . . . . . . . . . 3 58 A. Vaha-Sipila URLs for Telephone Calls August 1998 59 2.3 "fax" URL Scheme . . . . . . . . . . . . . . . . . . . . 4 60 2.4 "modem" URL Scheme . . . . . . . . . . . . . . . . . . . 4 61 2.5 Parsing telephone, fax and modem URLs . . . . . . . . . . 5 62 2.5.1 Call type . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.5.2 Phone numbers and their scope . . . . . . . . . . . . . 5 64 2.5.3 Separators in phone numbers . . . . . . . . . . . . . . 6 65 2.5.4 Converting the number to the local numbering scheme . . 6 66 2.5.5 Sending post-dial sequence after call setup . . . . . . 6 67 2.5.6 Pauses in dialing and post-dial sequence . . . . . . . 6 68 2.5.7 ISDN subaddresses . . . . . . . . . . . . . . . . . . . 7 69 2.5.8 T.33 subaddresses . . . . . . . . . . . . . . . . . . . 7 70 2.5.9 Data call parameters . . . . . . . . . . . . . . . . . 7 71 2.6 Examples of Use . . . . . . . . . . . . . . . . . . . . . 8 72 2.7 Rationale behind the syntax . . . . . . . . . . . . . . . 9 73 2.7.1 Why distinguish between call types? . . . . . . . . . . 9 74 2.7.2 Why "tel" is "tel"? . . . . . . . . . . . . . . . . . . 9 75 2.7.3 Why to use E.164 numbering? . . . . . . . . . . . . . . 10 76 2.7.4 Not everyone has the same equipment as you . . . . . . 10 77 3. Comments on usage . . . . . . . . . . . . . . . . . . . . 11 78 4. References . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . 12 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13 81 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 82 8. Full Copyright Statement . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 1.1 New URL schemes 88 URLs that designate phone or fax numbers that can be dialed have 89 been brought forward in other Internet-Drafts. However, none of 90 these has reached the RFC status. This document tries to remedy 91 the situation. All interested parties are invited to submit 92 comments on this Internet-Draft. Contact information can be found 93 at the end of this document. 95 See also [CONV-URL] for more discussion on conversational URLs. 97 This specification defines three new URL schemes: "tel", 98 "fax" and "modem". They are intended for describing a terminal 99 that can be contacted using the telephone network. The 100 description includes the subscriber (telephone) number of the 101 terminal and the necessary parameters for successfully 102 connecting to that terminal. 104 The "tel" scheme describes a connection to a terminal that 105 handles normal voice telephone calls, a voice mailbox or another 106 voice messaging system or a service that can be operated using 107 DTMF codes. 109 The "fax" scheme describes a connection to a terminal that can 110 handle telefaxes (facsimiles). The name (scheme specifier) for 111 the URL is "fax" as recommended by [E.123]. 113 A. Vaha-Sipila URLs for Telephone Calls August 1998 114 The "modem" scheme describes a connection to a terminal that can 115 handle incoming data calls. The term "modem" refers to a device 116 that does digital-to-analog and analog-to-digital conversions; 117 in addition to these, a "modem" scheme can describe a fully 118 digital connection. 120 The notation for phone numbers is the same which is specified in 121 [RFC2303] and [RFC2304]. However, the syntax definition is a 122 bit different due to the fact that this document specifies URLs 123 whereas [RFC2303] and [RFC2304] specify electronic mail 124 addresses. For example, "/" (used in URLs to separate parts in a 125 hierarchical URL [RFC1738]) has been replaced by ";". 127 1.2 Formal definitions 129 Formal definitions follow [RFC2234]. This specification uses 130 elements from the 'core' definitions (Appendix A of [RFC2234]). 132 1.3 Requirements 134 Compliant software MUST follow this specification. Requirements 135 are indicated by capitalized words as specified in [RFC2119]. 137 2. URL schemes for telephone calls 139 2.1 Applicability 141 In this document, "user agent" means software that can detect and 142 parse one or more of these URLs and place a call to the remote 143 terminal using hardware and software at its disposal after it has 144 been properly configured. 146 These URL schemes are used to direct the user agent to place a 147 call using the telephone network. The network in question may be a 148 landline or mobile phone network. If the phone network 149 differentiates between (for example) voice and data calls, or if 150 the user agent has several different telecommunications equipment 151 at its disposal, it is possible to specify which kind of call 152 (voice/fax/data) is requested. The URL can also contain 153 information about the capabilities of the remote entity, so that 154 the connection can be established successfully. 156 None of the URL schemes do have a 'path' in them - they are 157 always absolute. The URLs are always case-insensitive. 159 2.2 "tel" URL scheme 161 The URL syntax is formally described as follows. For the basis 162 of this syntax, see [RFC2303]. 164 telephone-url = telephone-scheme ":" 165 telephone-subscriber 166 telephone-scheme = "tel" 167 telephone-subscriber = global-phone-number / local-phone-number 169 A. Vaha-Sipila URLs for Telephone Calls August 1998 170 global-phone-number = "+" 1*phonedigit [isdn-subaddress] 171 [post-dial] 172 local-phone-number = 1*(phonedigit / dtmf-digit / 173 pause-character) [isdn-subaddress] 174 [post-dial] 175 isdn-subaddress = ";isub=" 1*phonedigit 176 post-dial = ";postd=" 1*(phonedigit / dtmf-digit 177 / pause-character) 178 phonedigit = DIGIT / visual-separator 179 visual-separator = "-" / "." / "(" / ")" 180 pause-character = one-second-pause / wait-for-dial-tone 181 one-second-pause = "p" 182 wait-for-dial-tone = "w" 183 dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D" 185 2.3 "fax" URL scheme 187 The URL syntax is formally described as follows (the definition 188 | reuses nonterminals from the above definition). For the basis of 189 this syntax, see [RFC2303] and [RFC2304]. 191 fax-url = fax-scheme ":" fax-subscriber 192 fax-scheme = "fax" 193 fax-subscriber = fax-global-phone / fax-local-phone 194 fax-global-phone = "+" 1*phonedigit [isdn-subaddress] 195 [t33-subaddress] [post-dial] 196 fax-local-phone = 1*(phonedigit / dtmf-digit / 197 pause-character) [isdn-subaddress] 198 [t33-subaddress] [post-dial] 199 t33-subaddress = ";tsub=" 1*phonedigit 201 2.4 "modem" URL scheme 203 | The URL syntax is formally described as follows (the definition 204 | reuses nonterminals from the above definitions). For the basis of 205 this syntax, see [RFC2303]. 207 modem-url = modem-scheme ":" remote-host 208 modem-scheme = "modem" 209 remote-host = telephone-subscriber *modem-params 210 modem-params = ";type=" data-capabilities 211 data-capabilities = accepted-modem ["?" data-bits parity 212 stop-bits] 213 accepted-modem = "V21" / "V22" / "V22b" / 214 "V23" / "V26t" / "V32" / 215 "V32b" / "V34" / "V90" / 216 "V110" / "V120" / "B103" / 217 "B212" / "X75" / 218 "vnd." vendor-name "." modem-type 219 data-bits = "7" / "8" 220 parity = "n" / "e" / "o" / "m" / "s" 221 stop-bits = "1" / "2" 222 vendor-name = 1*(ALPHA / DIGIT / "-" / "+") 223 modem-type = 1*(ALPHA / DIGIT / "-" / "+") 225 A. Vaha-Sipila URLs for Telephone Calls August 1998 226 2.5 Parsing telephone, fax and modem URLs 228 2.5.1 Call type 230 The type of call is specified by the scheme specifier. 231 "Tel" means that a voice call is opened. "Fax" indicates 232 that the call should be a facsimile (telefax) call. "Modem" means 233 that it should be a data call. Not all networks differentiate 234 between the types of call; in this case, the scheme specifier 235 indicates the telecommunications equipment type to use. 237 2.5.2 Phone numbers and their scope 239 and indicate the 240 phone number to be dialed. The phone number can be written in 241 either international or local notation. All phone numbers SHOULD 242 always be written in the international form if there is no good 243 reason to use the local form. 245 | Any telephone number MUST contain at least one or 246 | , that is, subscriber numbers consisting only of pause 247 | characters are not allowed. 249 International numbers MUST begin with the "+" character. Local 250 numbers MUST NOT contain that character. International numbers 251 MUST be written with the country (CC) and national (NSN) numbers 252 as specified in [E.123] and [E.164]. International numbers have 253 the property of being totally unambiguous everywhere in the world 254 if the user agent is properly configured. 256 Local numbers MAY be used if the number only works from inside a 257 certain geographical area or a network. Note that some numbers may 258 work from several networks but not from the whole world - these 259 SHOULD be written in international form. URLs containing local 260 phone numbers should only appear in an environment where all 261 user agents can get the call successfully set up by passing the 262 number to the dialing entity "as is". An example could be a 263 company intranet, where all user agents are located under a 264 the same private telephone exchange. If local phone numbers 265 are used, the document in which they are present SHOULD contain 266 an indication of the context in which they are intended to be 267 used. 269 In some regions, it is popular to write phone numbers using 270 alphabetic characters which correspond to certain numbers on the 271 telephone keypad. Letters in characters do not have 272 anything to do with this, nor is this supported by this URL 273 scheme. 275 It should also be noted that implementations MUST NOT assume 276 that telephone numbers have a maximum, minimum or fixed length, 277 or that they would always begin with a certain number. 278 Implementors are encouraged to familiarize themselves with 280 A. Vaha-Sipila URLs for Telephone Calls August 1998 281 the international standards for telephone number notation. 283 2.5.3 Separators in phone numbers 285 All characters MUST be removed from the 286 phone number by the user agent before using it do dial out. 287 These cracaters are present only to aid readability: they MUST 288 NOT have any other meaning. Note that although [E.123] 289 recommends the use of space (SP) characters as the separators, 290 spaces MUST NOT be used in these URLs. 292 2.5.4 Converting the number to the local numbering scheme 294 After the telephone number has been extracted, it is 295 converted to the format that the user agent can use to place the 296 call. (For example, the "+" character might be replaced by the 297 international call prefix, or the international and trunk 298 prefixes might be removed to place a local call.) Numbers that 299 have been specified using or 300 MUST be used by the user agent "as is", without any conversions. 302 2.5.5 Sending post-dial sequence after call setup 304 The number may contain a sequence, which MUST be 305 dialled using Dual Tone Multifrequency (DTMF) in-band signalling 306 or pulse dialing after the call setup is complete. If the user 307 agent does not support DTMF or pulse dialing after the call has 308 been set up, MUST be ignored. In that case, the user 309 SHOULD be notified. 311 2.5.6 Pauses in dialing and post-dial sequence 313 A local phone number or a post-dial sequence may contain 314 characters which indicate a pause 315 while dialing ("p"), or a wait for dial tone ("w"). 317 User agents MAY support this method of dialing, and the final 318 interpretation of these characters is left to the user agent. 320 If it is not supported, user agents MUST ignore everything in the 321 dial string after the first and the user SHOULD 322 be notified. The user or the user agent MAY opt not to place a 323 call if this feature is not supported and these characters are 324 present in the URL. 326 Any characters and all dial string characters after 327 the first or SHOULD be sent to line 328 using DTMF (Dual Tone Multifrequency) in-band signaling, even if 329 dialing is done using direct network signaling (a digital 330 subscriber loop or a mobile phone). If the local infrastructure 331 does not support DTMF codes, the user agent MAY opt to use pulse 332 dialing. However, it should be noted that certain services which 333 are controlled using DTMF tones cannot be controlled with pulse 334 dialing. 336 A. Vaha-Sipila URLs for Telephone Calls August 1998 337 2.5.7 ISDN subaddresses 339 A phone number MAY also contain an which 340 indicates an ISDN subaddress. User agent SHOULD support ISDN 341 subaddresses. These addresses are sent to the network by using a 342 method available to the user agent (typically, ISDN subscribers 343 send the address with the call setup signalling). If ISDN 344 subaddressing is not supported by the caller, 345 MUST be ignored and the user SHOULD be notified. The user or the 346 user agent MAY opt not to place a call if this feature is not 347 supported. 349 2.5.8 T.33 subaddresses 351 A fax number MAY also contain a , which 352 indicates the start of a T.33 subaddress [T.33]. User agents 353 SHOULD support this. Otherwise MUST be ignored 354 and the user SHOULD be notified. The user or the user agent MAY 355 opt not to place a call if this feature is not supported. 357 2.5.9 Data call parameters 359 indicate the minimum compliance required from 360 the user agent to be able to connect to the remote entity. The 361 minimum compliance is defined as being equal to or a superset of 362 the capabilities of the listed modem type. 364 The user agent MUST call out using compatible hardware, or request 365 that the network provides such a service. 367 For example, if the user agent only has access to a V.22bis modem 368 and the URL indicates that the minimum acceptable connection is 369 V.32bis, the user agent MUST NOT try to connect to the remote host 370 since V.22bis is a subset of V.32bis. However, if the URL lists 371 V.32 as the minimum acceptable connection, the user agent can use 372 V.32bis to create a connection since V.32bis is a superset of 373 V.32. 375 This feature is present because modem pools often have separate 376 numbers for slow modems and fast modems, or have different numbers 377 for analog and ISDN connections, or may use proprietary modems 378 that are incompatible with standards. It is somewhat analogous to 379 the connection type specifier (typecode) in FTP URLs [RFC1738]: it 380 provides the user agent with information that can not be deduced 381 from the scheme specifier, but is helpful for successful 382 operation. 384 This also means that the number of data and stop bits and parity 385 MUST be set according to the information given in the URL, or to 386 default values, if the information is not present. 388 The capability tokens are listed below. If capabilities 389 suggest that it is impossible to create a connection, the 391 A. Vaha-Sipila URLs for Telephone Calls August 1998 392 connection MUST NOT be created. 394 If new modem types are standardized by ITU-T, this list can be 395 extended with those capability tokens. Tokens are formed by taking 396 the number of the standard and joining together the first letter 397 (for example, "V"), number (for example, 22) and the first letter 398 of the postfix (for example "bis" would become "b"). 400 Proprietary modem types MUST be specified using the 'vendor naming 401 tree', which takes the form "vnd.x.y", in which "x" is the name of 402 the entity from which the specifications for the modem type can be 403 acquired and "y" is the type or model of the modem. Vendor names 404 MUST share the same name space with vendor names used in MIME 405 types [RFC2048]. Submitting the modem types to ietf-types list 406 for review is strongly recommended. 408 New capabilities MUST always be documented in an RFC. 410 Capability Explanation 412 V21 ITU-T V.21 413 V22 ITU-T V.22 414 V22b ITU-T V.22bis 415 V23 ITU-T V.23 416 V26t ITU-T V.26ter 417 V32 ITU-T V.32 418 V32b ITU-T V.32bis 419 V34 ITU-T V.34 420 | V90 ITU-T V.90 421 V110 ITU-T V.110 422 V120 ITU-T V.120 423 X75 ITU-T X.75 424 B103 Bell 103 425 B212 Bell 212 426 Data bits: "8" or "7" The number of data bits. If not 427 specified, defaults to "8". 428 Parity: "n", "e", "o", Parity. None, even, odd, mark or 429 "m", "s" space parity, respectively. If 430 not specified, defaults to "n". 431 Stop bits: "1" or "2" The number of stop bits. If not 432 specified, defaults to "1". 434 2.6 Examples of Use 436 tel:+358-555-1234567 438 This URL instructs the user agent to place a voice call to the 439 specified number in Finland. The hyphens are included to make the 440 number more human-readable: country and area codes have been 441 separated from the subscriber number. 443 fax:+358.555.1234567 445 The above URL instructs the user agent to place a fax call to 447 A. Vaha-Sipila URLs for Telephone Calls August 1998 448 the specified number. It uses dots instead of hyphens as 449 separators, but they have no effect on the functionality. 451 modem:+3585551234567;type=v32b?7e1;type=v110 453 This URL instructs the user agent to place a data call to the 454 specified number. The user agent may opt to use either a ITU-T 455 V.32bis modem (or a faster one, which is compatible with V.32bis), 456 using settings of 7 data bits, even parity and one stop bit, or an 457 ISDN connection using ITU-T V.110 protocol. 459 tel:+358-555-1234567;postd=pp22 461 The above URL instructs the user agent to place a voice call to 462 +358-555-1234567, then wait for an implementation-dependent time 463 (for example, two seconds) and emit two DTMF dialing 464 tones "2" on the line (for example, to choose a particular 465 extension number, or to invoke a particular service). 467 tel:0w003585551234567 469 This URL places a voice call to the given number. The number 470 format is intended for local use: the first zero opens an 471 outside line, the "w" character waits for a second dial tone, 472 and the number already has the international access code 473 appended to it ("00"). This kind of phone number MUST NOT be 474 used in an environment where all users of this URL might not be 475 able to successfully dial out by using this number directly. 476 However, this might be appropriate for pages in a company 477 intranet. 479 2.7 Rationale behind the syntax 481 2.7.1 Why distinguish between call types? 483 | URLs locate resources, which in this case is some 484 | telecommunications equipment at a given phone number. However, it 485 | is not necessarily enough to know the subscriber number in order 486 | to successfully communicate with that equipment. Digital phone 487 | networks distinguish between voice, fax and data calls (and 488 | possibly other types of calls, not discussed in this 489 | specification). To be able to successfully connect to, say, a fax 490 | machine, the caller may have to specify that a fax call is being 491 | made. Otherwise the call might be routed to the voice number of 492 | the subscriber. In this sense, the call type is an integral part 493 | of the 'location' of the target resource. 495 | The reason to have the call type in the scheme specifier is to 496 | make the URL simple to remember and use. Making it a parameter, 497 | much like the way modem parameters are handled now, will 498 | substantially reduce the usability of this URL (to the humans). 500 2.7.2 Why "tel" is "tel"? 502 A. Vaha-Sipila URLs for Telephone Calls August 1998 503 There has been discussion on whether the scheme name "tel" is 504 appropriate. To summarize, these are the points made against 505 the other proposals. 507 callto URL schemes locate a resource and do not specify 508 an action to be taken. 509 telephone Too long. Also, "tel" considered to be a more 510 international form. 511 phone Was countered on the basis that "tel" is more 512 internationally acceptable. 514 2.7.3 Why to use E.164 numbering? 516 | It should be noted that phone numbers may have 'hierarchical' 517 | characteristics, so that one could build a 'forest' of phone 518 | numbers with country codes as roots, area codes as branches and 519 | subscriber numbers as leaves. However, this is not always the 520 | case. Not all areas have area codes; some areas may have different 521 | area codes depending on how one wants to route the call; some 522 | numbers must always be dialled "as is", without prepending area or 523 | country codes; and area codes can and do change. 525 | Usually, if something has a hierarchical structure, the URL 526 | syntax should reflect that fact. These URLs are an exception. 528 | Phone numbers are written almost always in some form which 529 | resembles the E.164 notation. Because of this, the syntax in this 530 | specification is intuitively clear to most people. This is the 531 | usual way to write phone numbers in business cards, advertisements, 532 | telephone books and so on. 534 | Also, when writing the phone number in the form described in this 535 | specification, the writer does not need to know which part of the 536 | number is the country code and which part is the area code. If a 537 | hierarchical URL would be used (with a "/" character separating 538 | the parts of the phone numbers), the writer of the URL would have 539 | to know which parts are which. 541 | Finally, when phone numbers are written in the international form 542 | as specified here, they are unambiguous and can always be 543 | converted to the local dialing convention, given that the user 544 | agent has the knowledge of the local country and area codes. 546 2.7.4 Not everyone has the same equipment as you 548 | There are several ways for the subscriber to dial a phone number: 550 | - By pulse dialing. Typically old telephone exchanges. Usually 551 | this dialing method has only to be used to set up the call; 552 | after connecting to the remote entity, can be 553 | sent to the line using DTMF, because it will typically be 554 | processed by the remote entity, not the telephone network. 556 | - By DTMF. These are the 'beeps' that you hear when you dial on 558 A. Vaha-Sipila URLs for Telephone Calls August 1998 559 | most phones. 561 | - By direct network signalling. ISDN subscribers and mobile phone 562 | users usually have this. There is no dial tone (or if there is, 563 | it is generated locally by the equipment), and the number 564 | of the called party is communicated to the telephone network 565 | using some network signalling method. After setting up the 566 | call, sequences are usually sent using DTMF codes. 568 3. Comments on usage 570 | These are examples of the recommended usage of this URL in 571 | HTML documents. 573 | First of all, the number SHOULD be visible to the end user, if 574 | it is conceivable that the user might not have a user agent which 575 | is able to use these URLs. 577 | Telephone: +358-555-1234567 579 | Second, on a public HTML page, the telehone number in the URL 580 | SHOULD always be in the international form, even if the text of 581 | the link uses some local format. 583 | Telephone: (0555) 1234567 585 | or even 587 | For more info, call 588 | 1-555-IETF-RULZ-OK. 590 | Moreover, if the number is a , and the scope 591 | of the number is not clear from the context in which the URL 592 | is displayed, a human-readable explanation SHOULD be included. 594 | For customer service, dial 1234 595 | (only from Terrific Telecom mobile phones). 597 4. References 599 NOTE. References to Internet-Drafts will be removed from the final 600 document which will be submitted to the RFC-Editor. 602 [CONV-URL] Conversational Multimedia URLs. 1997. Pete Cordell. An 603 Internet-Draft (work in progress). 604 607 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 608 Berners-Lee et al. RFC 1738. 609 611 [RFC1866] Hypertext Markup Language - 2.0. November 1995. T. 612 Berners-Lee & D. Connolly. RFC 1866. 614 A. Vaha-Sipila URLs for Telephone Calls August 1998 615 617 [RFC2048] Multipurpose Internet Mail Extensions (MIME) Part Four: 618 Registration Procedures. November 1996. N. Freed et al. RFC 2048. 619 621 [RFC2119] Key Words for Use in RFCs to Indicate Requirement 622 Levels. March 1997. S. Bradner. RFC 2119. 623 625 [RFC2234] Augmented BNF for Syntax Specifications: ABNF. 626 November 1997. D. Crocker et al. RFC 2234. 627 629 [RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998. 630 C. Allocchio. RFC 2303. 631 633 [RFC2304] Minimal FAX Address Format in Internet Mail. March 1998. 634 C. Allocchio. RFC 2304. 635 637 [E.123] ITU-T Recommendation E.123: Telephone Network and ISDN 638 Operation, Numbering, Routing and Mobile Service: Notation for 639 National and International Telephone Numbers. 1993. 641 [E.164] ITU-T Recommendation E.164: Telephone Network and ISDN 642 Operation, Numbering, Routing and Mobile Service: Numbering Plan 643 for the ISDN Era. 1991. 645 [T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing 646 the Subaddress. 1996. 648 5. Security Considerations 650 It should be noted that the user agent SHOULD NOT call out without 651 the knowledge of the user because of associated risks, which 652 include 654 - call costs (including long calls, long distance calls, 655 international calls and premium rate calls) 656 - wrong numbers inserted on web pages by malicious users 657 - making the user's phone line unavailable (off-hook) for a 658 malicious purpose 659 - opening a data call to a remote host, thus possibly opening a 660 back door to the user's computer 661 - revealing the user's (possibly unlisted) phone number to the 662 remote host in the caller identification data 664 All of these risks MUST be taken into consideration when 665 designing the user agent. 667 The user agent SHOULD have some mechanism that the user can use to 668 filter out unwanted numbers. The user agent SHOULD NOT use rapid 670 A. Vaha-Sipila URLs for Telephone Calls August 1998 671 redialing of the number if it is busy to avoid the congestion of 672 the (signaling) network. Also, the user agent SHOULD detect if the 673 number is unavailable or if the call is terminated before the 674 dialing string has been completely processed (for example, the 675 call is terminated while waiting for user input) and not try to 676 call again, unless instructed by the user. 678 6. Acknowledgements 680 | Contributors include numerous people from IETF FAX, PINT, URI and 681 | URLREG mailing lists, as well as from World Wide Web Consortium 682 | and several companies, plus several individuals. Thanks to all 683 | people who offered criticism, corrections and feedback. 685 | All phone numbers and company names used in the examples of this 686 | specification are fictional. Any similarities to real entities 687 | are coincidental. 689 7. Authors' Addresses 691 Contact person and version control responsibility 692 for this specification: 694 Nokia Mobile Phones 695 Antti Vaha-Sipila 696 P. O. Box 68 697 FIN-33721 Tampere 698 Finland 700 Electronic mail: antti.vaha-sipila@nmp.nokia.com 702 Please include your name and electronic mail address in all 703 communications. If you want to receive the newest version of this 704 specification electronically, send mail to the address above. 706 This document expires on the 9th of February, 1999, or when a 707 new version is released. 709 8. Full Copyright Statement 711 To be added to the final RFC. 713 A. Vaha-Sipila URLs for Telephone Calls August 1998