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