idnits 2.17.1 draft-ietf-iptel-rfc2806bis-05.txt: -(692): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 849), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 20, 2004) is 7313 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) == Unused Reference: 'I-D.yu-tel-url' is defined on line 761, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2368 (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2806 (Obsoleted by RFC 3966) -- Obsolete informational reference (is this intentional?): RFC 2916 (Obsoleted by RFC 3761) -- Obsolete informational reference (is this intentional?): RFC 3187 (Obsoleted by RFC 8254) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: September 18, 2004 March 20, 2004 6 The tel URI for Telephone Numbers 7 draft-ietf-iptel-rfc2806bis-05 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3667. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 18, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document specifies the URI (Uniform Resource Identifier) scheme 40 "tel". The ``tel'' URI describes resources identified by telephone 41 numbers. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 47 3. URI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . 6 49 5. Phone Numbers and Their Context . . . . . . . . . . . . . . 7 50 5.1 Phone Numbers . . . . . . . . . . . . . . . . . . . . . . . 7 51 5.1.1 Separators in Phone Numbers . . . . . . . . . . . . . . . . 7 52 5.1.2 Alphabetic Characters Corresponding to Digits . . . . . . . 8 53 5.1.3 Alphabetic, * and \\# Characters as Identifiers . . . . . . 8 54 5.1.4 Global Numbers . . . . . . . . . . . . . . . . . . . . . . . 8 55 5.1.5 Local Numbers . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.2 ISDN Subaddresses . . . . . . . . . . . . . . . . . . . . . 10 57 5.3 Phone Extensions . . . . . . . . . . . . . . . . . . . . . . 10 58 5.4 Other Parameters . . . . . . . . . . . . . . . . . . . . . . 11 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7.1 Why Not Just Put Telephone Numbers in SIP URIs? . . . . . . 11 62 7.2 Why Not Distinguish Between Call Types? . . . . . . . . . . 12 63 7.3 Why tel? . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 7.4 Do Not Confuse Numbers with How They Are Dialed . . . . . . 12 65 8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . 12 66 9. Use of tel URIs with SIP (Informative) . . . . . . . . . . . 13 67 9.1 Local Translation . . . . . . . . . . . . . . . . . . . . . 13 68 9.2 Proxy Translation . . . . . . . . . . . . . . . . . . . . . 14 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 70 10.1 Initial Parameter Registrations . . . . . . . . . . . . . . 15 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 72 12. Security Considerations . . . . . . . . . . . . . . . . . . 16 73 13. Changes Since RFC 2806 . . . . . . . . . . . . . . . . . . . 16 74 Normative References . . . . . . . . . . . . . . . . . . . . 16 75 Informative References . . . . . . . . . . . . . . . . . . . 17 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 77 Intellectual Property and Copyright Statements . . . . . . . 19 79 1. Introduction 81 This document defines the URI scheme "tel". The "tel" URI describes 82 resources identified by telephone numbers. A telephone number is a 83 string of decimal digits that uniquely indicates the network 84 termination point. The number contains the information necessary to 85 route the call to this termination point. (This definition is 86 derived from [E.164], but encompasses both public and private 87 numbers.) 89 The "tel" URI telephone number is not restricted in the type of 90 termination point it refers to. The termination point can be in the 91 public telephone network, a private telephone network or the 92 Internet. The termination point can be fixed or wireless and address 93 a fixed wired, mobile or nomadic terminal. The terminal addressed 94 can support any electronic communication service (ECS) including 95 voice, data and fax. The URI can refer to resources identified by a 96 telephone number, including but not limited to originators or targets 97 of a telephone call. 99 The "tel" URI is a globally unique identifier ("name") only; it does 100 not describe the steps necessary to reach a particular number and 101 does not imply dialing semantics. Furthermore, it does not refer to a 102 specific physical device, only to a telephone number. 104 Telephone numbers as commonly understood actually comprise two 105 related, but distinct concepts: as a canonical address-of-record and 106 as a dial string. We define the concepts below: 108 Address-of-record or identifier: The telephone number is understood 109 here as the canonical address-of-record or identifier for a 110 termination point within a specific network. For the public 111 network, these numbers follow the rules in E.164 [E.164], while 112 private numbers follow the rules of the owner of the private 113 numbering plan. Subscribers publish such identifiers as a 114 universal means of being reached, independent of the location of 115 the caller. (Naturally, not all numbers are reachable from 116 everywhere, for a variety of technical and local policy reasons. 117 Also, a single termination point may be reachable from different 118 networks and may have multiple such identifiers.) 119 Dial string: "Dial strings" are the actual numbers, symbols and 120 pauses entered by a user to place a phone call. A dial-string is 121 consumed by one or more network entities, and understood in the 122 context of the configuration of these entities. It is used to 123 generate an address-of-record or identifier in the sense of the 124 previous paragraph so that a call can be routed. Dial-strings may 125 require pre-pended digits to egress the private branch exchange 126 (PBX) the end system is connected to, and they may include 127 post-dial dual-tone multi-frequency (DTMF) signaling that could 128 control an IVR or reach an extension. Dial strings are beyond the 129 scope of this document. 131 Both approaches can be encoded into a URI. For dial strings, this 132 URI is passed to an entity that can reproduce the actions specified 133 in the dial string. For example, in an analog phone system, a dialer 134 translates the dial string into a sequence of actions such as waiting 135 for dial tone, sending DTMF digits, pausing and generating post-dial 136 DTMF digits after the callee picks up. In an integrated services 137 digital network (ISDN) or ISDN user part (ISUP) environment, the 138 signaling elements receiving protocol messages containing the dial 139 string perform the appropriate protocol actions. As noted, this 140 approach is beyond the scope of this specification. 142 The approach described here has the URI specify the telephone number 143 as an identifier, which can be either globally unique or only be 144 valid within a local context. The dialing application is aware of 145 the local context, knowing, for example, whether special digits need 146 to be dialed to seize an outside line, whether network, pulse or tone 147 dialing is needed and what tones indicate call progress. The dialing 148 application then converts the telephone number into a dial sequence 149 and performs the necessary signaling actions. The document below 150 assumes the second model. The dialer does not have to be a user 151 application as found in traditional desktop operating systems, but 152 could well be part of an IP-to-PSTN gateway. 154 To reach a telephone number from a phone on a PBX, for example, the 155 user of that phone has to know how to convert the telephone number 156 identifier into a dial string appropriate for that phone. The 157 telephone number itself does not convey what needs to be done for a 158 particular terminal. Instructions may include dialing "9" before 159 placing a call or prepending a "00" to reach a number in a foreign 160 country. The phone may also need to strip area and country codes. 162 The identifier approach described in this document has the 163 disadvantage that certain services, such as electronic banking or 164 voicemail, cannot be specified in a URI. 166 The notation for phone numbers in this document is similar to that in 167 RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax 168 differs since this document describes URIs whereas RFC 3191 and RFC 169 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/" 170 to indicate parameters (qualifiers). Since URI use the forward slash 171 to describe path hierarchy, the URI scheme described here uses the 172 semicolon, in keeping with Session Initiation Protocol (SIP) URI 173 conventions [RFC3261]. 175 The 'tel' URI can be used as a request URI in SIP [RFC3261] requests. 176 The SIP specification also inherits the 'subscriber' part of the 177 syntax as part of the 'user element' in the SIP URI. Other protocols 178 may use this URI for both query-based and prefix-based applications. 180 The "tel" URI does not specify the call type such as voice, fax, or 181 data call and does not provide the connection parameters for a data 182 call. The type and parameters are assumed to be negotiated either 183 in-band by the telephone device or through a signaling protocol such 184 as SIP. 186 2. Terminology 188 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 189 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 190 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 191 [RFC2119] and indicate requirement levels for compliant 192 implementations. 194 3. URI Syntax 196 The URI is defined using the ABNF (augmented Backus-Naur form) 197 described in RFC 2234 [RFC2234] and uses elements from the core 198 definitions (Appendix A of RFC 2234). 200 The syntax definition follows RFC 2396 [RFC2396], indicating the 201 actual characters contained in the URI. Note that the reserved 202 characters "+", ";", "=", and "?" MUST NOT be escaped as they are 203 delimiters for the "tel" URI scheme. These reserved characters MUST 204 be escaped if they appear in parameter values. 206 Characters other than those in the "reserved" and "unsafe" sets (see 207 RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" encoding. 209 The "tel" URI has the following syntax: 211 telephone-uri = "tel:" telephone-subscriber 212 telephone-subscriber = global-number / local-number 213 global-number = global-number-digits *par 214 local-number = local-number-digits *par context *par 215 par = parameter / extension / isdn-subaddress 216 isdn-subaddress = ";isub=" 1*uric 217 extension = ";ext=" 1*phonedigit 218 context = ";phone-context=" descriptor 219 descriptor = domainname / global-number-digits 220 global-number-digits = "+" 1*phonedigit 221 local-number-digits = 1*phonedigit-hex 222 domainname = *( domainlabel "." ) toplabel [ "." ] 223 domainlabel = alphanum 224 / alphanum *( alphanum / "-" ) alphanum 225 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 226 parameter = ";" pname ["=" pvalue ] 227 pname = 1*( alphanum / "-" ) 228 pvalue = 1*paramchar 229 paramchar = param-unreserved / unreserved / escaped 230 unreserved = alphanum / mark 231 mark = "-" / "_" / "." / "!" / "~" / "*" / 232 "'" / "(" / ")" 233 escaped = "%" HEXDIG HEXDIG 234 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" 235 phonedigit = DIGIT / [ visual-separator ] 236 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] 237 visual-separator = "-" / "." / "(" / ")" 238 alphanum = ALPHA / DIGIT 239 reserved = ";" | "/" | "?" | ":" | "@" | "&" | 240 "=" | "+" | "$" | "," 241 uric = reserved | unreserved | escaped 243 Each parameter name ("pname"), the ISDN subaddress, the 'extension' 244 and the 'context' MUST NOT appear more than once. The 245 'isdn-subaddress' or 'extension' MUST appear first, if present, 246 followed by the 'context' parameter, if present, followed by any 247 other parameters in lexicographical order. 249 This simplifies comparison when the "tel" URI is compared 250 character-by-character, such as in SIP URIs [RFC3261]. 252 4. URI Comparisons 254 Two "tel" URIs are equivalent according to the following rules: 256 o Both must be either a 'local-number' or both must be a 257 'global-number', i.e., start with a '+'. 259 o The 'global-number-digits' and the 'local-number-digits' must be 260 equal, after removing all visual separators. 261 o For mandatory additional parameters (Section 5.4) and the 262 'phone-context' and 'extension' parameters defined in this 263 document, The 'phone-context' parameter value is compared as a 264 host name if it is a 'domainname' or digit-by-digit if it is 265 'global-number-digits'. The latter is compared after removing all 266 'visual-separator' characters. 267 o Parameters are compared according to 'pname', regardless of the 268 order they appeared in the URI. If one URI has a parameter name 269 not found in the other, the two URIs are not equal. 270 o URI comparisons are case-insensitive. 272 All parameter names and values SHOULD use lower-case characters since 273 tel URIs may be used within contexts where comparisons are 274 case-sensitive. 276 Section 19.1.4 in the SIP specification [RFC3261] discusses one 277 such case. 279 5. Phone Numbers and Their Context 281 5.1 Phone Numbers 283 The 'telephone-subscriber' part of the URI indicates the number. The 284 phone number can be represented in either global (E.164) or local 285 notation. All phone numbers MUST use the global form unless they 286 cannot be represented as such. Numbers from private numbering plans, 287 emergency ("911", "112") and some directory assistance numbers (e.g., 288 "411") and other "service codes" (numbers of the form N11 in the 289 United States) cannot be represented in global (E.164) form, and need 290 to be represented as a local number with a context. Local numbers 291 MUST be tagged with a 'phone-context' (Section 5.1.5). 293 Implementations MUST NOT assume that telephone numbers have a 294 maximum, minimum or fixed length, or that they always begin with a 295 certain number. 297 5.1.1 Separators in Phone Numbers 299 Phone numbers MAY contain visual separators. Visual separators 300 ('visual-separator') merely aid readability and are not used for URI 301 comparison or placing a call. 303 Despite complicating comparisons, this specification retains the 304 visual separators to follow the spirit of RFC 2396 [RFC2396], 305 which remarks that "A URI often needs to be remembered by people, 306 and it is easier for people to remember a URI when it consists of 307 meaningful components." Also, ISBN URNs documented in RFC 3187 308 [RFC3187] use visual separators in a manner similar to this 309 specification. 311 Even though ITU-T E.123 [E.123] recommends the use of space 312 characters as visual separators in printed telephone numbers, 313 "tel" URIs cannot use spaces to avoid excessive escaping. 315 5.1.2 Alphabetic Characters Corresponding to Digits 317 In some countries, it is popular to write phone numbers using 318 alphabetic characters which correspond to certain numbers on the 319 telephone keypad. The URI format does not support this notation 320 since the mapping from alphabetic characters to digits is not 321 completely uniform internationally, although there are standards 322 [E.161][T1.703] addressing this issue. 324 5.1.3 Alphabetic, * and \\# Characters as Identifiers 326 Since called and calling terminal numbers (TNs) are encoded in BCD in 327 ISUP, six additional values per digit can be encoded, sometimes 328 represented as the hexadecimal characters A through F. Similarly, 329 DTMF allows for the encoding of the symbols *, \# and A through D. 330 However, in accordance with E.164, they may not be included in global 331 numbers. Their meaning in local numbers is not defined here, but they 332 are not prohibited. 334 5.1.4 Global Numbers 336 Globally unique numbers are identified by the leading "+" character. 337 Global numbers MUST be composed with the country (CC) and national 338 (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164]. 339 Globally unique numbers have the property of being unambiguous 340 everywhere in the world and SHOULD be used. 342 5.1.5 Local Numbers 344 Local numbers are unique only within a certain geographical area or a 345 certain part of the telephone network, e.g., a private branch 346 exchange (PBX), a state or province, a particular local exchange 347 carrier or a particular country. URIs with local phone numbers 348 should only appear in environments where all local entities can 349 successfully set up the call by passing the number to the dialing 350 software. Digits needed for accessing an outside line, for example, 351 are not included in local numbers. Local numbers SHOULD NOT be used 352 unless there is no way to represent the number as a global number. 354 Local numbers require that the originator and recipient are 355 configured appropriately, so that they can insert and recognize 356 the correct descriptors. Since there is no algorithm to 357 independently pick the same descriptor, labeling numbers with 358 their context increases the chances of mis-configuration, so that 359 valid identifiers are rejected by mistake. The algorithm to 360 select descriptors was chosen that accidental collisions should be 361 rare, but they cannot be ruled out. 363 Local numbers MUST have a 'phone-context' parameter that identifies 364 the scope of their validity. The parameter MUST be chosen to 365 unambiguously identify the local context within which the number is 366 unique. Thus, the combination of the descriptor in the 367 'phone-context' parameter and local number is again globally unique. 368 The parameter value is defined by the assignee of the local number. 369 It does NOT indicate a prefix that turns the local number into a 370 global (E.164) number. 372 There are two ways to label the context: via a global number or any 373 number of its leading digits (e.g., "+33") and via a domain name, 374 e.g., "houston.example.com". The choice between the two is left to 375 the "owner" of the local number and is governed by whether there is a 376 global number or domain name that is a valid identifier for a 377 particular local number. 379 The domain name does not have to resolve to any actual host, but MUST 380 be under the administrative control of the entity managing the local 381 phone context. 383 A global number context consists of the initial digits of a valid 384 global number. All global numbers matching these initial digits must 385 be assigned to the same organization that is describing the context 386 and no such matching number can be used by any other organization. 387 For example, +49-6151-16 would be a suitable context for the 388 Technical University of Darmstadt, as it uses all numbers starting 389 with those digits. If such an initial string of digits does not 390 exist, the organization SHOULD use the lowest number of the global 391 number range assigned to it. (This can occur if two organizations 392 share the same decimal block of numbers. For example, assume an 393 organization owns the number range +1-212-939-7000 through 394 +1-212-939-7199. +1-212-939-7 would not be a valid global number 395 context, but +1-212-939-7000 would work.) It is not required that 396 local numbers within the context actually begin with the chosen set 397 of initial numbers. 399 A context consisting of the initial digits of a global number does 400 not imply that adding these to the local number will generate a valid 401 E.164 number. It might do so by coincidence, but this cannot be 402 relied upon. (For example, "911" should be labeled with the context 403 "+1", but "+1-911" is not a valid E.164 number.) 405 National freephone numbers do not need a context, even though they 406 are not necessarily reachable from outside a particular country code 407 or numbering plan. Recall that "tel" URIs are identifiers; it is 408 sufficient that a global number is unique, but it is not required 409 that it be reachable from everywhere. 411 Even non-freephone numbers may be out of date or not be reachable 412 from a particular location. For example, premium services such as 413 "900" numbers in the North American numbering plan are often not 414 dialable from outside the particular country code. 416 The two label types were chosen so that, in almost all cases, a 417 local administrator can pick an identifier that is reasonably 418 descriptive and does not require a new IANA-managed assigned 419 number. It is up to the administrator to assign an appropriate 420 identifier and to use it consistently. Often, an organization can 421 choose among several different identifiers. 423 If the recipient of a "tel" URI uses the URI simply for 424 identification, the receiver does not need to know anything about the 425 context descriptor. It simply treats it as one part of a globally 426 unique identifier, with the other being the local number. If a 427 recipient of the URI intends to place a call to the local number, it 428 MUST verify that it is within the same context as one of the 429 descriptors. If it is not within the same context, it MUST NOT 430 initiate the call and treat the URI like an invalid destination. 432 5.2 ISDN Subaddresses 434 A phone number MAY also contain an 'isdn-subaddress' parameter which 435 indicates an ISDN subaddress. 437 ISDN subaddresses typically contain International Alphabet 5 (IA5 438 [T.50]) characters, but may contain any octet value. 440 5.3 Phone Extensions 442 Phone extensions identify stations behind a non-ISDN PBX and are 443 roughly equivalent in functionality to ISDN subaddresses. They are 444 identified with the 'extension' parameter. At most one of the 445 'isdn-subaddress' and 'extension' parameters can appear in a tel URI, 446 i.e., they cannot appear both at the same time. 448 5.4 Other Parameters 450 Future protocol extensions to this URI scheme may add other 451 parameters ('parameter' in the ABNF). Such parameters can be either 452 mandatory or optional. Mandatory parameters start with "m-". An 453 implementation MAY ignore optional parameters. An implementation 454 MUST NOT use the URI if it contains unknown mandatory parameters. 455 The "m-" prefix cannot be added to parameters that were already 456 registered (except to create a new, logically distinct parameter). 457 The "phone-context" parameter in this document is mandatory, "isub" 458 and "ext" are optional. 460 For example, 'parameter' parameters can be used to store 461 application-specific additional data about the phone number, its 462 intended use, or any conversions that have been applied to the 463 number. 465 Entities that forward protocol requests containing tel URIs with 466 optional parameters MUST NOT delete or modify parameters they do not 467 understand. 469 All new parameters MUST be registered with IANA. 471 6. Examples 473 tel:+1-201-555-0123: This URI points to a phone number in the United 474 States. The hyphens are included to make the number more 475 human-readable; they separate country, area codes and subscriber 476 number. 477 tel:7042;phone-context=cs.columbia.edu: The URI describes a local 478 phone number valid within the context "cs.columbia.edu". 479 tel:863-1234;phone-context=+1-914-555: The URI describes a local 480 phone number that is valid within a particular phone prefix. 482 7. Rationale 484 7.1 Why Not Just Put Telephone Numbers in SIP URIs? 486 The "tel" URI describes a service, reaching a telephone number, that 487 is independent of the means of doing so, be it via a SIP-to-PSTN 488 gateway, a direct SIP call via E.164 number ("ENUM") translation 489 [RFC2916], some other signaling protocols such as H.323 or a 490 traditional circuit-switched call initiated on the client side via, 491 say, the Telephony Application Programming Interface (TAPI). It is 492 thus, in spirit, closer to the URN schemes that also leave the 493 resolution to an external mechanism. The same "tel" URI may get 494 translated to any number of other URIs in the process of setting up 495 the call. 497 7.2 Why Not Distinguish Between Call Types? 499 Signaling protocols such as SIP allow to negotiate the call type and 500 parameters, making the very basic indication within the URI scheme 501 moot. Also, since the call type can change frequently, any such 502 indication in a URI is likely to be out of date. If such designation 503 is desired for a device that directly places calls without a 504 signaling protocol such as SIP, mechanisms such as the "type" 505 attribute for the "A" element in HTML may be more appropriate. 507 7.3 Why tel? 509 "Tel" was chosen since it is widely recognized none of the other 510 suggestions appeared appropriate. "Callto" was discarded since URI 511 schemes locate a resource and do not specify an action to be taken. 512 "Telephone" and "phone" were considered too long and not as 513 internationally recognized. 515 7.4 Do Not Confuse Numbers with How They Are Dialed 517 As an example, the E.164 number "+1-212-555-3141" will be dialed in 518 many countries as 00-1-212-555-3141, where the leading "00" is a 519 prefix for international calls. (In general, a "+" symbol in E.164 520 indicates that an international prefix is required.) 522 8. Usage of Telephone URIs in HTML 524 Links using the "tel" URI SHOULD enclose the telephone number, so 525 that users can easily predict the action taken when following the 526 link. 528 Dial +1-212-555-0101 529 for assistance. 531 instead of 533 Dial this number 534 for assistance. 536 On a public HTML page, the telephone number in the URI SHOULD always 537 be in the global form, even if the text of the link uses some local 538 format. 540 Telephone (if dialing in the United States): 541 (201) 555-0111 543 or even 544 For having RFCs read aloud, call 545 1-555-IETF-RFC. 547 9. Use of tel URIs with SIP (Informative) 549 SIP can use the "tel" URI anywhere a URI is allowed, for example as a 550 Request-URI, along with "sip" and "sips" URIs. For brevity, we will 551 imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP 552 URIs can contain telephone numbers. In SIP URIs, they appear as the 553 user part, i.e., before the @ symbol (Section 19.1.6 in [RFC3261]). 555 Unless a SIP UA connects directly to a PSTN gateway, one of the SIP 556 proxy servers has to translate the tel URI to a SIP URI, with the 557 host part of that URI pointing to a gateway. Typically, the outbound 558 proxy server, as the first proxy server visited by a call request, 559 performs this translation. A proxy server can translate all tel URIs 560 to the same SIP host name or select a different gateway for different 561 tel prefixes, based, for example, on information learned from TRIP 562 [RFC3219]. However, a proxy server could also delegate this 563 translation task to any other proxy server since proxy servers are 564 free to apply whatever routing logic they desire. For local numbers, 565 the proxy MUST NOT translate "tel" URIs whose context it does not 566 understand. 568 As noted earlier, all phone numbers MUST use the global form unless 569 they cannot be represented as such. If the local-number format is 570 used, it MUST be qualified by the 'phone-context' parameter. 571 Effectively, the combination of local number and phone context makes 572 the tel URI globally unique. 574 While web pages, vCard business cards, address books and directories 575 can easily contain global tel URIs, users on twelve-button (IP) 576 phones cannot dial such numbers directly and are typically accustomed 577 to dialing shorter strings, e.g., for PBX extensions or local 578 numbers. These so-called dial-strings (Section 1) are not directly 579 represented by tel URIs, as noted. We refer to the rules that govern 580 the translation of dial strings into SIP and tel URIs, global or 581 local, as the dial plan. There are at least two appropriate ways to 582 deal with dial strings in SIP terminals, local translation and proxy 583 translation, described in turn below. 585 9.1 Local Translation 587 A SIP UA can use a dial plan to translate dial strings into SIP or 588 "tel" URIs. The dial plan can be manually configured or, preferably, 589 be downloaded as part of a device configuration mechanism. (At this 590 time, there is no standardized mechanism for this.) 591 A mobile user can use at least two dial plans, namely the dial plan 592 for the network that he is currently visiting and the dial plan for 593 the user's home network. Generally, dialed numbers that are meant to 594 represent global numbers will look the same after the translation 595 regardless of the dial plan, even if, say, the visited network uses 596 '0' for dialing an 'outside' number and the user's home network uses 597 '9', as long as the user is aware of the current dial plan. However, 598 local extensions that do not have a direct global equivalent may well 599 behave differently. To avoid any ambiguity, the dial plan MUST 600 insert a suitable 'phone-context' string when performing the 601 translation. If the 'phone-context' is a domain name, there are 602 three cases: 603 1. The outbound proxy recognizes the domain name in the SIP URI as 604 its local context and can route the request to a gateway that 605 understands the local number. 606 2. The outbound proxy does not use the same phone context, but can 607 route to a proxy that handles this phone context. This routing 608 can be done via a lookup table or the domain name of the phone 609 context might be set up to reflect the SIP domain name of a 610 suitable proxy. For example, a proxy may always route calls with 611 tel URIs like 613 tel:1234;phone-context=munich.example.com 615 to the SIP proxy located at munich.example.com. (Proxies that 616 receive a tel URI with a context they do not understand are 617 obligated to return a 404 (Not Found) status resonse, so that an 618 outbound proxy may decide to attempt such a heuristic.) 619 3. The outbound proxy does not recognize the phone context and 620 cannot find the appropriate proxy cognizant of that phone 621 context. In that case, the translation fails and the outbound 622 proxy returns a 404 (Not Found) error response. 624 9.2 Proxy Translation 626 In proxy translation mode, the SIP UA simply turns the "tel" URI into 627 the user part of the SIP URI and appends a ';user=phone' parameter 628 and provides an appropriate phone context reflecting the local 629 dialing plan. The host name or IP address of the outbound proxy is 630 made the host part of the SIP request URI. The outbound proxy can 631 then apply the dial plan indicated by the phone context in the URI to 632 translate the SIP URI into a "tel" URI or other SIP URI. Translation 633 into a "tel" URI makes sense only if the proxy wants to delegate 634 finding the PSTN gateway to another proxy. For example, after the 635 user with a location-specified dial plan located in domain 636 "munich.example.com" dials the digits "1234", the device converts 637 this into a SIP URI: 639 sip:1234;phone-context=munich.example.com@example.com;user=phone 641 Alternatively, the SIP UA can issue a call with a "tel" URI. For this 642 example, it might be: 644 tel:1234;phone-context=munich.example.com 646 Using a SIP URI is more robust and is thus the preferred approach. 648 Since a single proxy may receive calls from many different 649 locations with different local dial plans, devices that rely on 650 the proxy for number translation SHOULD always be configured with 651 a context. Otherwise, for example, a provider or enterprise would 652 have to provision a separate proxy for each branch office or 653 geographic area with its own dial plan. (Alternatively, a 654 provider could use the identity of the caller to select the dial 655 plan appropriate for that individual. However, most dial plans are 656 currently specific to a location, not a person.) 658 10. IANA Considerations 660 IANA is requested to update the reference to RFC 2806 in the URI 661 scheme registry for the 'tel' scheme to this document. 663 "Tel" URI parameters (ABNF 'parameter') MUST be registered with IANA. 664 Mandatory parameters must be described in a standards-track RFC, 665 while an informational RFC is sufficient for other parameters. 667 The registration must indicate: 669 Parameter name: The name used for the parameter, according to the BNF 670 in Section 3. 671 Applicability: A brief description of its use. 672 Mandatory? Whether the parameter is mandatory or not; only the names 673 of mandatory parameters must start with "m-" as described in 674 Section 5.4.; 675 Specification: A reference to the specification that defines the 676 parameter and its syntax. 678 10.1 Initial Parameter Registrations 680 +----------------+-----------------+-----------+---------------+ 681 | Parameter name | Applicability | Mandatory | Specification | 682 +----------------+-----------------+-----------+---------------+ 683 | isub | ISDN subaddress | no | RFCXXXX | 684 | ext | phone extension | no | RFCXXXX | 685 | phone-context | phone context | yes | RFCXXXX | 686 +----------------+-----------------+-----------+---------------+ 687 Table 1 689 11. Acknowledgments 691 This document is derived from RFC 2806 [RFC2806], written by Antti 692 V�h�-Sipil�. Flemming Andreasen, Francois Audet, Lawrence Conroy, 693 Cullen Jennings, Michael Hammer, Andrew Main, Xavier Marjou, Jon 694 Peterson, Mike Pierce, Jonathan Rosenberg and James Yu provided 695 extensive comments. 697 12. Security Considerations 699 The security considerations parallel those for the mailto URL 700 [RFC2368]. 702 A recipient of a "tel" URI SHOULD NOT place calls without the consent 703 of its owner. Placing calls automatically without appropriate user 704 confirmation may incur a number of risks, such as those described 705 below. 707 o Calls may incur costs. 708 o The URI may be used to place malicious or annoying calls. 709 o A call will take the user's phone line off-hook, thus preventing 710 its use. 711 o A call may reveal the user's, possibly unlisted, phone number to 712 the remote host in the caller identification data, and may allow 713 the attacker to correlate the user's phone number with other 714 information such as the e-mail or IP address. 716 13. Changes Since RFC 2806 718 The specification is syntactically backwards-compatible with the 719 "tel" URI defined in RFC 2806 [RFC2806], but has been completely 720 rewritten. This document more clearly distinguishes telephone 721 numbers as identifiers of network termination points from dial 722 strings and removes the latter from the purview of "tel" URIs. 723 Compared to RFC 2806, references to carrier selection, dial context, 724 fax and modem URIs, post-dial strings and pause characters have been 725 removed. The URI syntax now conforms to RFC 2396 [RFC2396]. 727 A section on using tel URIs in SIP was added. 729 Normative References 731 [E.123] International Telecommunications Union, "Notation for 732 national and international telephone numbers, e-mail 733 addresses and web addresses", Recommendation E.123, 734 February 2001. 736 [E.161] International Telecommunications Union, "Arrangement of 737 digits, letters and symbols on telephones and other 738 devices that can be used for gaining access to a telephone 739 network", Recommendation E.161, May 1995. 741 [E.164] International Telecommunications Union, "The international 742 public telecommunication numbering plan", Recommendation 743 E.164, May 1997. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 749 Specifications: ABNF", RFC 2234, November 1997. 751 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 752 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 753 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 755 [T1.703] ANSI, "Allocation of Letters to the Keys of Numeric 756 Keypads for Telecommunications", Standard T1.703-1995 757 (R1999), 1999. 759 Informative References 761 [I-D.yu-tel-url] 762 Yu, J., "New Parameters for the 'tel' URL to Support 763 Number Portability and Freephone Service", 764 draft-yu-tel-url-08 (work in progress), November 2003. 766 [RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL 767 scheme", RFC 2368, July 1998. 769 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 770 Resource Identifiers (URI): Generic Syntax", RFC 2396, 771 August 1998. 773 [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, 774 April 2000. 776 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 777 2000. 779 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 780 Book Numbers as Uniform Resource Names", RFC 3187, October 781 2001. 783 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet 784 Mail", RFC 3191, October 2001. 786 [RFC3192] Allocchio, C., "Minimal FAX address format in Internet 787 Mail", RFC 3192, October 2001. 789 [RFC3219] Rosenberg, J., Salama, H. and M. Squire, "Telephony 790 Routing over IP (TRIP)", RFC 3219, January 2002. 792 [T.50] International Telecommunications Union, "International 793 Reference Alphabet (IRA) (Formerly International Alphabet 794 No. 5 or IA5) - Information technology - 7-bit coded 795 character set for information interchange", Recommendation 796 T.50, 1992. 798 Author's Address 800 Henning Schulzrinne 801 Columbia University 802 Department of Computer Science 803 450 Computer Science Building 804 New York, NY 10027 805 US 807 Phone: +1 212 939 7042 808 EMail: hgs@cs.columbia.edu 809 URI: http://www.cs.columbia.edu 811 Intellectual Property Statement 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the IETF's procedures with respect to rights in IETF Documents can 820 be found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at 833 ietf-ipr@ietf.org. 835 Disclaimer of Validity 837 This document and the information contained herein are provided on an 838 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 839 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 840 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 841 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 842 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 845 Copyright Statement 847 Copyright (C) The Internet Society (2004). This document is subject 848 to the rights, licenses and restrictions contained in BCP 78, and 849 except as set forth therein, the authors retain all their rights. 851 Acknowledgment 853 Funding for the RFC Editor function is currently provided by the 854 Internet Society.