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