idnits 2.17.1 draft-ietf-iptel-rfc2806bis-00.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 the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 88 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 150: '...;", "=", and "?" MUST NOT be escaped i...' RFC 2119 keyword, line 152: '...erved characters MUST be escaped if th...' RFC 2119 keyword, line 188: '... the context MUST NOT appear more th...' RFC 2119 keyword, line 189: '...he ISDN subaddress or extension SHOULD...' RFC 2119 keyword, line 214: '...names and values SHOULD use lower-case...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (June 22, 2003) is 7615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 727 looks like a reference -- Missing reference section? '4' on line 740 looks like a reference -- Missing reference section? '5' on line 745 looks like a reference -- Missing reference section? '6' on line 748 looks like a reference -- Missing reference section? '7' on line 751 looks like a reference -- Missing reference section? '2' on line 730 looks like a reference -- Missing reference section? '3' on line 734 looks like a reference -- Missing reference section? '8' on line 756 looks like a reference -- Missing reference section? '9' on line 760 looks like a reference -- Missing reference section? '10' on line 764 looks like a reference -- Missing reference section? '11' on line 770 looks like a reference -- Missing reference section? '12' on line 773 looks like a reference -- Missing reference section? '13' on line 776 looks like a reference -- Missing reference section? '14' on line 780 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Schulzrinne/A. Vaha-Sipila 4 Columbia U./Nokia 5 draft-ietf-iptel-rfc2806bis-00.txt 6 June 22, 2003 7 Expires: December 2003 9 The tel URI for Telephone Calls 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies the URI (Uniform Resource Identifier) scheme 35 "tel". The "tel" URI describes resources identified by telephone 36 numbers. 38 1 Terminology 40 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 41 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 42 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 43 indicate requirement levels for compliant implementations. 45 2 Introduction 47 This document defines the URI scheme "tel". The "tel" URI describes 48 resources identified by telephone numbers. A telephone number is "a 49 string of decimal digits that uniquely indicates the public network 50 termination point. The number contains the information necessary to 51 route the call to this termination point." [4] 53 The "tel" URI telephone number is not restricted in the type of 54 termination point it refers to. The termination point can be in the 55 public telephone network, a private circuit-switched network or the 56 Internet. The termination point can be a mobile terminal or a 57 landline circuit. The terminal addressed can support voice, data or 58 fax. The URI can refer to originators or targets of a telephone call. 60 The "tel" URI is a globally unique identifier ("name") only; it does 61 not describe the steps necessary to reach a particular number and 62 does not imply dialing semantics. 64 Telephone numbers as commonly understood actually comprise two 65 related, but distinct concepts: as a canonical address-of-record and 66 as a dial-string. We define the concepts below: 68 Address-of-record or identifier: The telephone number is 69 understood here as the canonical address-of-record or 70 identifier for a public network termination point. 71 Generally, these numbers follow the rules in E.164 [4]. 72 Subscribers publish such identifiers phone number as a 73 universal means of being reached, independent of the 74 location of the caller. (Naturally, not all numbers are 75 reachable from everywhere, for a variety of technical and 76 local policy reasons.) 78 Dial string: "Dial strings" are the actual numbers, symbols and 79 pauses entered by a user to place a phone call. A dial- 80 string is consumed by one or more network entities, and 81 understood in the context of the configuration of these 82 entities. It is used to generate a telephone number so that 83 a call can be routed. Dial-strings may require pre-pended 84 digits to handle local PBXs, and they may include post-dial 85 DTMF signaling that could control an IVR or reach an 86 extension. Dial strings are beyond the scope of this 87 document. 89 To reach a telephone number from a particular terminal, the user of 90 the terminal or the terminal itself has to know how to convert that 91 the telephone number as identifier into a dial string appropriate for 92 that terminal. The telephone number itself does not convey what needs 93 to be done for a particular terminal. Instructions may include 94 dialing "9" before placing a call or prepending a "00" to reach a 95 number in a foreign country. The terminal may also need to strip area 96 and country codes. 98 The notation for phone numbers in this document is similar to that in 99 RFC 3191 [5] and RFC 3192 [6]. However, the syntax differs since 100 this document describes URIs whereas RFC 3191 and RFC 3192 specify 101 electronic mail addresses. RFC 3191 and RFC 3192 use "/" to indicate 102 parameters (qualifiers). Since URI use the forward slash to describe 103 path hierarchy, the URI scheme described here uses the semicolon, in 104 keeping with Session Initiation Protocol (SIP) URI conventions [7]. 106 There are at least two ways one can envision making a telephone 107 connection. In the first approach, a URI contains the dial string, 108 which is then passed to an entity that can reproduce the actions 109 specified in the dial string, by sending DTMF digits, waiting for 110 dial tone, pausing and generating post-dial DTMF digits after the 111 callee picks up. Another approach has the URI specify the telephone 112 number, which can be either globally unique or only be valid within a 113 local context. A dialer application is aware of the local context, 114 knowing, for example, whether special digits need to be dialed to 115 seize an outside line, whether network, pulse or tone dialing is 116 needed and what tones indicate call progress. The dialer then 117 converts the telephone number into a dial string and performs the 118 necessary signaling actions. The document below assumes the second 119 model. The dialer does not have to be a user application as found in 120 traditional desktop operating systems, but could well be part of an 121 IP-to-PSTN gateway. 123 The approach pursued here has the disadvantage that certain services, 124 such as extensions on a PBX (when direct inward dialing is not used) 125 or electronic banking, cannot be specified in a URI. 127 The URI can be used as a request URI in SIP [7] requests. The SIP 128 specification also inherits the subscriber part of the syntax as part 129 of the user element in the SIP URI. Other protocols may use this URI 130 for both query-based and prefix-based applications. 132 The "tel" URI does not specify the call type such as voice, fax, or 133 data call and does not provide the connection parameters for a data 134 call. The type and parameters are assumed to be negotiated either 135 in-band by the telephone device or through a signaling protocol such 136 as SIP. 138 2.1 Resolution 140 TBD 142 3 URI Syntax 144 The URI is defined using the ABNF (augmented Backus-Naur form) 145 described in RFC 2234 [2] and uses elements from the core definitions 146 (Appendix A of RFC 2234). 148 The syntax definition follows RFC 2396 [3], indicating the actual 149 characters contained in the URI. Note that the reserved characters 150 "+", ";", "=", and "?" MUST NOT be escaped if shown in the grammar 151 definitions below as they are delimiters for the "tel" URI scheme. 152 These reserved characters MUST be escaped if they appear in parameter 153 values. 155 Characters other than those in the "reserved" and "unsafe" sets (see 156 RFC 2396 [3]) are equivalent to their "% HEX HEX" encoding. 158 The "tel" URI has the following syntax: 160 telephone-uri = "tel:" subscriber | 161 subscriber = global-number / local-number | 162 global-number = global-number-digits *par | 163 local-number = local-number-digits *par context *par | 164 par = parameter / extension / isdn-subaddress | 165 isdn-subaddress = ";isub=" 1*uric | 166 extension = ";ext=" 1*phonedigit | 167 context = ";phone-context=" descriptor | 168 descriptor = domainname / global-number-digits | 169 global-number-digits = "+" 1*phonedigit | 170 local-number-digits = 1*phonedigit-hex | 171 domainname = *( domainlabel "." ) toplabel [ "." ] | 172 domainlabel = alphanum | 173 / alphanum *( alphanum / "-" ) alphanum | 174 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum | 175 parameter = ";" pname ["=" pvalue ] | 176 pname = 1*( alphanum / "-" ) | 177 pvalue = 1*paramchar | 178 paramchar = param-unreserved / unreserved / escaped | 179 unreserved = alphanum / mark | 180 escaped = "%" HEXDIG HEXDIG | 181 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" | 182 phonedigit = DIGIT [ visual-separator ] | 183 phonedigit-hex = HEXDIG [ visual-separator ] | 184 visual-separator = "-" / "." / "(" / ")" | 185 alphanum = ALPHA / DIGIT | 187 Each parameter name ("pname"), the ISDN subaddress, the extension and 188 the context MUST NOT appear more than once. The order of the URL 189 parameters is immaterial. The ISDN subaddress or extension SHOULD 190 appear first, if present, followed by the context parameter, if 191 present, followed by any other parameters in lexicographical order. 193 This simplifies comparison when the "tel" URI is compared 194 character-by-character, such as in SIP URIs [7]. 196 4 URI Comparisons 198 Two "tel" URIs are equivalent according to the following rules: 200 o URI are not equal if one is a and the other a 201 . 203 o For mandatory extension parameters and the and 204 parameters defined in this document, parameter values are compared digit-by-digit after 206 removing all s from consideration. 208 o Parameters are compared according to , regardless of 209 the order they appeared in the URI. If one URI has a parameter 210 name not found in the other, the two URIs are not equal. 212 o URI comparisons are case-insensitive. 214 All parameter names and values SHOULD use lower-case characters since 215 tel URIs may be used within contexts where comparisons are case- 216 sensitive. 218 Section 19.1.4 in the SIP specification [7] discusses one 219 such case. 221 5 Phone Numbers and Their Context 223 5.1 Phone Numbers 225 The part of the URI indicates the number. The phone 226 number can be represented in either global (E.164) or local notation. 227 All phone numbers MUST use the global form unless they cannot be 228 represented as such. Numbers from private numbering plans, emergency 229 ("911", "112") and some directory assistance numbers (e.g., "411") 230 and other "service codes" (numbers of the form N11 in the United 231 States) cannot be represented in global (E.164) form, and need to be 232 represented as a local number with a context. Local numbers MUST be 233 tagged with a phone-context (Section 5.1.4). 235 Implementations MUST NOT assume that telephone numbers have a 236 maximum, minimum or fixed length, or that they always begin with a 237 certain number. 239 E.164 limits numbers to 15 digits. For geographic numbers, 240 one to three digits are the country code, with the 241 remainder divided into area or city code (national 242 destination code) and subscriber number. Alternatively, 243 there is a global three-digit service code, followed by a 244 global subscriber number of up to 12 digits. Finally, a 245 "international public telecommunication number for networks 246 is composed of decimal digits arranged in three code 247 fields. The code fields are the 3-digit shared Country Code 248 (CC) field, the IC field, which varies in length between 1 249 to 4 digits, and the Subscriber Number (SN) which can be up 250 to 15 minus the number of digits in the CC and IC fields." 251 [4] 253 5.1.1 Separators in Phone Numbers 255 Phone numbers MAY contain visual separators. Visual separators 256 () merely aid readability and are not used for URI 257 comparison or placing a call. 259 Despite complicating comparisons, this specification 260 retains the visual separators to follow the spirit of RFC 261 2396 [3], which remarks that "A URI often needs to be 262 remembered by people, and it is easier for people to 263 remember a URI when it consists of meaningful components." 264 Also, ISBN URNs documented in RFC 3187 [8] use visual 265 separators in a manner similar to this specification. 267 Even though ITU-T E.123 [9] recommends the use of space 268 characters as visual separators in printed telephone 269 numbers, "tel" URIs cannot use spaces to avoid excessive 270 escaping. 272 5.1.2 Alphabetic Characters 274 In some countries, it is popular to write phone numbers using 275 alphabetic characters which correspond to certain numbers on the 276 telephone keypad. The URI format does not support this notation 277 since the mapping from alphabetic characters to digits is not 278 completely uniform internationally, although there are standards 279 [10,11] addressing this issue. 281 Since called and calling terminal numbers (TNs) are encoded in BCD in 282 ISUP, this allows for six additional values per digit, sometimes 283 represented as the hexadecimal characters A through F. However, in 284 accordance with E.164, they may not be included in global numbers. 285 Their use in local numbers is not defined, but is not prohibited. 287 5.1.3 Global Numbers 289 Globally unique numbers are identified by the leading "+" character. 290 Global numbers MUST be composed with the country (CC) and national 291 (NSN) numbers as specified in E.123 and E.164 [9,4]. Globally unique 292 numbers have the property of being unambiguous everywhere in the 293 world and are RECOMMENDED. 295 5.1.4 Local Numbers | 297 Local numbers are unique only within a certain geographical area or a | 298 certain part of the telephone network, e.g., a private branch | 299 exchange (PBX), a state or province, a particular local exchange | 300 carrier or a particular country. URIs with local phone numbers should | 301 only appear in environments where all local entities can successfully | 302 set up the call by passing the number to the dialing software. Digits | 303 needed for accessing an outside line, for example, are not included | 304 in local numbers. Local numbers SHOULD NOT be used. | 306 Local numbers require that the originator and recipient are | 307 configured appropriately, so that they can insert and | 308 recognize the correct descriptors. Since there is no | 309 algorithm to independently pick the same descriptor, | 310 labeling numbers with their context increases the chances | 311 of mis-configuration, so that valid identifiers are | 312 rejected by mistake. The algorithm to select descriptors | 313 was chosen that accidental collisions should be rare, but | 314 they cannot be ruled out. | 316 Local numbers MUST have a phone-context parameter that identifies the | 317 scope of their validity. The parameter MUST be chosen to | 318 unambiguously identify the local context within which the number is | 319 unique. Thus, the combination of the descriptor in the phone-context | 320 parameter and local number is again globally unique. The parameter | 321 value is defined by the assignee of the local number. It does NOT | 322 indicate a prefix that turns the local number into a global (E.164) | 323 number. | 325 There are two ways to label the context: via a global number or any | 326 number of its leading digits (e.g., "+33") and via a domain name, | 327 e.g., "houston.example.com". The choice between the two is left to | 328 the "owner" of the local number and is governed by whether there is a | 329 global number or domain name that is a valid identifier for a | 330 particular local number. | 332 The domain name does not have to resolve to any actual host, but MUST | 333 be under the administrative control of the entity managing the local | 334 phone context. | 336 A global number context consists of the initial digits of a valid | 337 global number. All global numbers matching these initial digits must | 338 be assigned to the same organization that is describing the context | 339 and no such matching number can be used by any other organization. If | 340 such an initial string of digits does not exist, the organization | 341 should use the lowest number of the global number range assigned to | 342 it. (This can occur if two organizations share the same decimal block | 343 of numbers. For example, assume an organization owns the number range | 344 +1-212-939-7000 through +1-212-939-7199. +1-212-939-7 would not be a | 345 valid global number context, but +1-212-939-7000 would work.) It is | 346 not required that local numbers within the context actually begin | 347 with the chosen set of initial numbers. | 349 For a local number defined within a PBX, the organization can choose | 350 any number under its control to identify the context. For example, a | 351 context consisting of any of the organization's global numbers may be | 352 suitable, or a substring that is completely occupied by the | 353 organization. For example, +49-6151-16 would be a suitable context | 354 for the TU Darmstadt, as it uses all numbers starting with those | 355 digits. | 357 A context consisting of the initial digits of a global number does | 358 not imply that adding these to the local number will generate a valid | 359 E.164 number. It might do so by coincidence, but this cannot be | 360 relied upon. (For example, "911" should be labeled with the context | 361 "+1", but "+1-911" is not a valid E.164 number.) | 363 National freephone numbers do not need a context, even though they | 364 are not necessarily reachable from outside a particular country code | 365 or numbering plan. Recall that "tel" URIs are identifiers; it is | 366 sufficient that a global number is unique, but it is not required | 367 that it be reachable from everywhere. | 369 Even non-freephone numbers may be out of date or not be | 370 reachable from a particular location. For example, premium | 371 services such as "900" numbers in the North American | 372 numbering plan are often not dialable from outside the | 373 particular country code. 375 The two label types were chosen so that, in almost all 376 cases, a local administrator can pick an identifier that is 377 reasonably descriptive and does not require a new IANA- 378 managed assigned number. It is up to the administrator to 379 assign an appropriate identifier and to use it 380 consistently. Often, an organization can choose among 381 several different identifiers. 383 If the recipient of a "tel" URI uses the URI simply for 384 identification, the receiver does not need to know anything about the 385 context descriptor. It simply treats it as one part of a globally 386 unique identifier, with the other being the local number. If a 387 recipient of the URI intends to place a call to the local number, it 388 MUST verify that it is within the same context as one of the 389 descriptors. If it is not within the same context, it MUST NOT 390 initiate the call and treat the URI like an invalid destination. 392 5.2 ISDN Subaddresses 394 A phone number MAY also contain an parameter which 395 indicates an ISDN subaddress. 397 ISDN subaddresses typically contain IA5 characters, but may contain 398 any octet value. 400 5.3 Extensions | 402 Extensions identify stations behind a PBX and are roughly equivalent | 403 to ISDN subaddresses. They are identified with the | 404 parameter. At most one of the and | 405 parameters can appear in a tel URI, i.e., they cannot appear both at | 406 the same time. | 408 5.4 Other Parameters 410 Future extensions to this URI scheme may add other parameters 411 ( in the ABNF). Such parameters can be either mandatory or 412 optional. Mandatory parameters start with "m-". An implementation MAY 413 ignore optional parameters. An implementation MUST NOT use the URI if 414 it contains unknown mandatory parameters. The "m-" prefix cannot be 415 added to parameters that were already registered (except to create a 416 new, logically distinct parameter). The "phone-context" parameter in 417 this document is mandatory. 419 For example, parameters can be used to store 420 application-specific additional data about the phone number, its 421 intended use, or any conversions that have been applied to the 422 number. 424 All new parameters MUST be registered with IANA. 426 6 Examples 428 tel:+358-555-1234567 430 This URI points to a phone number in Finland. The hyphens 431 are included to make the number more human-readable; they 432 separate country, area codes and subscriber number. 434 tel:7042;phone-context=cs.columbia.edu 436 The URI describes a local phone number valid within the 437 context "cs.columbia.edu". 439 tel:863-1234;phone-context=+1-914-784 441 The URI describes a local phone number that is valid within 442 a particular phone prefix. 444 7 Rationale 446 7.1 Why Not Just Put Telephone Numbers in SIP URIs? 448 The "tel" URI describes a service, reaching a telephone number, that 449 is independent of the means of doing so, be it via a SIP-to-PSTN 450 gateway, a direct SIP call via ENUM translation, some other signaling 451 protocols such as H.323 or a traditional circuit-switched call 452 initiated on the client side via, say, TAPI. It is thus, in spirit, 453 closer to the URN schemes that also leave the resolution to an 454 external mechanism. The same "tel" URI may get translated to any 455 number of other URIs in the process of setting up the call. 457 7.2 Why Not Distinguish Between Call Types? 459 Signaling protocols such as SIP allow to negotiate the call type and 460 parameters, making the very basic indication within the URL scheme 461 moot. Also, since the call type can change frequently, any such 462 indication in a URI is likely to be out of date. If such designation 463 is desired for a device that directly places calls without a 464 signaling protocol such as SIP, mechanisms such as the "type" 465 attribute for the "A" element in HTML may be more appropriate. 467 7.3 Why "tel"? 469 "Tel" was chosen since it is widely recognized none of the other 470 suggestions appeared appropriate. "Callto" was discarded since URI 471 schemes locate a resource and do not specify an action to be taken. 472 "Telephone" and "phone" were considered too long and not as 473 internationally recognized. 475 7.4 Do Not Confuse Numbers with How They Are Dialed 477 As an example, the E.164 number "+1-212-555-3141" will be dialed in 478 many countries as 00-1-212-555-3141, where the leading "00" is a 479 prefix for international calls. (In general, "+" in E.164 indicates 480 that an international prefix is required.) Tel URIs MUST NOT contain 481 the local dialing prefixes in numbers such as +1-212-555-3141, as the 482 transformation back to an international number is not guaranteed to 483 be correct or unique. 485 If a network entity receives a "tel" URI containing a local number, 486 it MUST make sure that it knows the context in which the local phone 487 number is to be processed, or else the number MUST NOT be used. 488 Equally, the originator of a "tel" URI must take into consideration 489 that the recipient may have insufficient information about the phone 490 number's context. 492 8 Usage of Telephone URIs in HTML 494 Links using the "tel" URL SHOULD enclose the telephone number, so 495 that users can easily predict the action taken when following the 496 link. 498 Dial +358-555-1234567 for assistance. 500 instead of 502 Dial this number for assistance. 504 On a public HTML page, the telephone number in the URI SHOULD always 505 be in the global form, even if the text of the link uses some local 506 format. 508 Telephone (if dialing in Finland): 509 (0555) 1234567 511 or even 513 For having RFCs read aloud, call 514 1-555-IETF-RFC. 516 9 IANA Considerations 518 "Tel" URI parameters () MUST be registered with IANA. 519 Mandatory parameters must be described in a standards-track RFC, 520 while an informational RFC is sufficient for other parameters. 522 The registration must indicate: 524 o the parameter name; 526 o a description of its applicability; 528 o whether the parameter is mandatory or not ( Only the names of 529 mandatory parameters must start with "m-" as described in 530 Section 5.4.); 532 o restrictions on the syntax of the parameter value in ABNF 533 form; 535 o a reference to the specification that defines it. 537 10 Security Considerations 539 The security considerations parallel those for the mailto URL [12]. 541 A recipient of a "tel" URI SHOULD NOT place calls without the consent 542 of its owner. Placing calls automatically without appropriate user 543 confirmation may incur a number of risks, such as those described 544 below. 546 o Calls may incur costs. 548 o The URI may be used to place malicious or annoying calls. 550 o A call will take the user's phone line off-hook, thus 551 preventing its use. 553 o A call may reveal the user's, possibly unlisted, phone number 554 to the remote host in the caller identification data, and may 555 allow the attacker to correlate the user's phone number with 556 other information such as the e-mail or IP address. 558 o A call may use the same local number in different contexts, in 559 which the number may have a different meaning. 561 A Use of "tel" URIs with SIP (Informative) 563 SIP can use the "tel" URI as a Request-URI, along with "sip" and 564 "sips" URIs. For brevity, we will imply "sips" URIs when talking 565 about SIP URIs. Both tel and `SIP URIs can contain telephone numbers. 566 In SIP URIs, they appear as the user part, i.e., in front of the @ 567 symbol. While 569 Unless a SIP UA connects directly to a PSTN gateway, one of the SIP 570 proxy servers has to translate the tel URI to a SIP URI, with the 571 host part of that URI pointing to a gateway. Typically, the outbound 572 proxy server, as the first proxy server visited by a call request, 573 performs this translation. A proxy server can translate all tel URIs 574 to the same SIP host name or select a different gateway for different 575 tel prefixes, based, for example, on information learned from TRIP. 576 However, a proxy server could also delegate this translation task to 577 any other proxy server since proxy servers are free to apply whatever 578 routing logic they desire. 580 As noted earlier, all phone numbers MUST use the global form unless 581 they cannot be represented as such. If the local-number format is 582 used, it MUST be qualified by the phone-context parameter. 583 Effectively, the combination of local number and phone context makes 584 the tel URI globally unique. 586 While web pages, vCard business cards, address books and directories 587 can easily contain global tel URIs, users on twelve-button (IP) 588 phones cannot dial such numbers directly and are typically accustomed 589 to dialing shorter strings, e.g., for PBX extensions or local 590 numbers. These so-called dial-strings (Section refsec:intro) are not 591 directly represented by tel URIs, as noted. We refer to the 592 translation of dial strings into SIP and tel URIs, global or local, 593 as the dial plan. There are at least two appropriate ways to deal 594 with dial strings in SIP terminals: 596 Local translation: A SIP UA can use a dial plan to translate 597 dial strings into SIP or tel URIs. The dial plan can be 598 manually configured or, preferably, be downloaded as part 599 of a device configuration mechanism. (At this time, there 600 is no standardized mechanism for this.) 602 A mobile user can use at least two dial plans, namely the 603 dial plan for the network that he is currently visiting and 604 the dial plan for the user's home network. Generally, 605 dialed numbers that are meant to represent global numbers 606 will look the same after the translation regardless of the 607 dial plan, even if, say, the visited network uses '0' for 608 dialing an 'outside' number and the user's home network 609 uses '9', as long as the user is aware of the current dial 610 plan. However, local extensions that do not have a direct 611 global equivalent may well behave differently. To avoid any 612 ambiguity, the dial plan MUST insert a suitable phone- 613 context string when performing the translation. If the 614 phone-context is a domain name, there are three cases: 616 1. The outbound proxy recognizes the domain name as its 617 local context and can route the request to a gateway 618 that understands the local number. 620 2. The outbound proxy does not use the same phone 621 context, but can route to a proxy that handles this 622 phone context. This routing can be done via a lookup 623 table or the domain name of the phone context might be 624 set up to reflect the SIP domain name of a suitable 625 proxy. For example, a proxy may always route calls 626 with tel URIs like 628 tel:1234;phone-context=munich.example.com 630 to the SIP proxy located at munich.example.com. 632 (Proxies that receive a tel URI with a context they do 633 not understand are obligated to return a 404 (Not 634 Found) status resonse, so that an outbound proxy may 635 decide to attempt such a heuristic.) 637 3. The outbound proxy does not recognize the phone 638 context and cannot find the appropriate proxy 639 cognizant of that phone context. In that case, the 640 translation fails and the outbound proxy returns a 404 641 (Not Found) error response. 643 Proxy translation: In proxy translation mode, the SIP UA simply 644 turns the dialed digits into the user part of the SIP URI 645 and appends a ;user=phone parameter. The host name or IP 646 address of the outbound proxy becomes the host part of the 647 SIP request URI. The outbound proxy can then apply its 648 local dial plan to translate the SIP URI into a tel URI or 649 other SIP URI. Translation into a tel URI makes sense only 650 if the proxy wants to delegate finding the PSTN gateway to 651 another proxy. 653 B Change History 655 B.1 Changes Since -07 657 o Added section on using tel URIs in SIP. 659 B.2 Changes Since -06 661 o Clarified semantics. 663 o Removed context from freephone numbers. 665 o Added phone extensions. 667 B.3 Changes Since -05 669 o URI comparisons are case-insensitive. 671 o Specified recommended order of parameters to simplify use 672 within SIP URIs. 674 B.4 Changes Since -04 676 o ISDN subaddresses can contain any IA5 character or even binary 677 data; represented now as "uric". 679 B.5 Changes Since -03 681 o Clarified use of multiple contexts and how to express this, as 682 a comma-separated list. 684 B.6 Changes Since -02 685 o Clarifications and editorial fixes. 687 o Now, mandatory parameters are labeled, to avoid making [13] 688 obsolete. 690 B.7 Changes Since -01 692 The draft has been greatly simplified to reflect parts that have 693 actually been implemented. 695 o Removed references to carrier selection. 697 o Removed dial context. 699 o Removed fax and modem URIs. 701 o Removed post-dial strings. 703 o Removed pause characters. 705 B.8 Changes Since RFC 2806 707 The specification is backwards-compatible with RFC 2806. 709 o Editorial changes and clarifications. The document has been 710 shortened and reorganized. Most paragraphs have been rewritten 711 to be more concise. 713 o Syntax now conforms to RFC 2396 [3], in particular related to 714 escaping. 716 C Acknowledgments 718 This document inherits a large amount of text from RFC 2806 [14]. 719 Flemming Andreasen, Francois Audet, Lawrence Conroy, Andrew Main, 720 Michael Hammer, Jon Peterson, Mike Pierce, Jonathan Rosenberg and 721 James Yu provided extensive comments. 723 D References 725 E Normative References 727 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 728 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 730 [2] D. Crocker and P. Overell, eds., "Augmented BNF for syntax 731 specifications: ABNF," RFC 2234, Internet Engineering Task Force, 732 Nov. 1997. 734 [3] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 735 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 736 Task Force, Aug. 1998. 738 F Informative References 740 [4] International Telecommunication Union, "The international public 741 telecommunication numbering plan," Recommendation E.164, 742 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 743 May 1997. 745 [5] C. Allocchio, "Minimal GSTN address format in internet mail," RFC 746 3191, Internet Engineering Task Force, Oct. 2001. 748 [6] C. Allocchio, "Minimal FAX address format in internet mail," RFC 749 3192, Internet Engineering Task Force, Oct. 2001. 751 [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 752 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 753 initiation protocol," RFC 3261, Internet Engineering Task Force, June 754 2002. 756 [8] J. Hakala and H. Walravens, "Using international standard book 757 numbers as uniform resource names," RFC 3187, Internet Engineering 758 Task Force, Oct. 2001. 760 [9] International Telecommunication Union, "Notation for national and 761 international phone numbers," Recommendation E.123, Telecommunication 762 Standardization Sector of ITU, Geneva, Switzerland, 1998. 764 [10] International Telecommunication Union, "Arrangement of digits, 765 letters and symbols on telephones and other devices that can be used 766 for gaining access to a telephone network," Recommendation E.161, 767 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 768 May 1995. 770 [11] ANSI, "Allocation of letters to the keys of numeric keypads for 771 telecommunications," Standard T1.703-1995 (R1999), ANSI, 1999. 773 [12] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL 774 scheme," RFC 2368, Internet Engineering Task Force, July 1998. 776 [13] J. Yu, "Extensions to the 'tel' URL to support number 777 portability and freephone service," Internet Draft, Internet 778 Engineering Task Force, Aug. 2002. Work in progress. 780 [14] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet 781 Engineering Task Force, Apr. 2000. 783 G Authors' Addresses 785 Henning Schulzrinne 786 Dept. of Computer Science 787 Columbia University 788 1214 Amsterdam Avenue 789 New York, NY 10027 790 USA 791 electronic mail: schulzrinne@cs.columbia.edu 793 Antti Vaha-Sipila 794 (ISO 8859-15 quoted-printable: Antti V=E4h=E4-Sipil=E4) 795 Nokia Mobile Phones 796 P. O. Box 321 797 FIN-00045 Nokia Group 798 Finland 799 electronic mail: avs@iki.fi, antti.vaha-sipila@nokia.com 801 H Full Copyright Notice 803 The IETF takes no position regarding the validity or scope of any 804 intellectual property or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; neither does it represent that it 808 has made any effort to identify any such rights. Information on the 809 IETF's procedures with respect to rights in standards-track and 810 standards-related documentation can be found in BCP-11. Copies of 811 claims of rights made available for publication and any assurances of 812 licenses to be made available, or the result of an attempt made to 813 obtain a general license or permission for the use of such 814 proprietary rights by implementors or users of this specification can 815 be obtained from the IETF Secretariat. 817 The IETF invites any interested party to bring to its attention any 818 copyrights, patents or patent applications, or other proprietary 819 rights which may cover technology that may be required to practice 820 this standard. Please address the information to the IETF Executive 821 Director. 823 This document and translations of it may be copied and furnished to 824 others, and derivative works that comment on or otherwise explain it 825 or assist in its implmentation may be prepared, copied, published and 826 distributed, in whole or in part, without restriction of any kind, 827 provided that the above copyright notice and this paragraph are 828 included on all such copies and derivative works. However, this 829 document itself may not be modified in any way, such as by removing 830 the copyright notice or references to the Internet Society or other 831 Internet organizations, except as needed for the purpose of 832 developing Internet standards in which case the procedures for 833 copyrights defined in the Internet Standards process must be 834 followed, or as required to translate it into languages other than 835 English. 837 The limited permissions granted above are perpetual and will not be 838 revoked by the Internet Society or its successors or assigns. 840 This document and the information contained herein is provided on an 841 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 842 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 843 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 844 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 845 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 847 Table of Contents 849 1 Terminology ......................................... 2 850 2 Introduction ........................................ 2 851 2.1 Resolution .......................................... 4 852 3 URI Syntax .......................................... 4 853 4 URI Comparisons ..................................... 5 854 5 Phone Numbers and Their Context ..................... 6 855 5.1 Phone Numbers ....................................... 6 856 5.1.1 Separators in Phone Numbers ......................... 6 857 5.1.2 Alphabetic Characters ............................... 7 858 5.1.3 Global Numbers ...................................... 7 859 5.1.4 Local Numbers .....7................................. | 860 5.2 ISDN Subaddresses ................................... 9 861 5.3 Extensions .....9.................................... | 862 5.4 Other Parameters .................................... 10 863 6 Examples ............................................ 10 864 7 Rationale ........................................... 10 865 7.1 Why Not Just Put Telephone Numbers in SIP URIs? 866 ................................................................ 10 867 7.2 Why Not Distinguish Between Call Types? ............ 11 868 7.3 Why "tel"? ......................................... 11 869 7.4 Do Not Confuse Numbers with How They Are Dialed ..... 11 870 8 Usage of Telephone URIs in HTML ..................... 11 871 9 IANA Considerations ................................. 12 872 10 Security Considerations ............................. 12 873 A Use of "tel" URIs with SIP (Informative) ............ 13 874 B Change History ...................................... 15 875 B.1 Changes Since -07 ................................... 15 876 B.2 Changes Since -06 ................................... 15 877 B.3 Changes Since -05 ................................... 15 878 B.4 Changes Since -04 ................................... 15 879 B.5 Changes Since -03 ................................... 15 880 B.6 Changes Since -02 ................................... 15 881 B.7 Changes Since -01 ................................... 16 882 B.8 Changes Since RFC 2806 .............................. 16 883 C Acknowledgments ..................................... 16 884 D References .......................................... 16 885 E Normative References ................................ 16 886 F Informative References .............................. 17 887 G Authors' Addresses .................................. 18 888 H Full Copyright Notice ............................... 18