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