idnits 2.17.1
draft-ietf-iptel-rfc2806bis-06.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 14.
-- 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 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?
** 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:
----------------------------------------------------------------------------
== Mismatching filename: the document gives the document name as
'draft-ietf-iptel-tel-rfc2806bis-06', but the file name used is
'draft-ietf-iptel-rfc2806bis-06'
== 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).
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (April 5, 2004) is 7317 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 (~~), 7 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: October 4, 2004 April 5, 2004
6 The tel URI for Telephone Numbers
7 draft-ietf-iptel-tel-rfc2806bis-06
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 3668.
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 October 4, 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 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
68 11. Security Considerations . . . . . . . . . . . . . . . . . . 14
69 12. Changes Since RFC 2806 . . . . . . . . . . . . . . . . . . . 15
70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
71 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
72 13.2 Informative References . . . . . . . . . . . . . . . . . . . 16
73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
74 Intellectual Property and Copyright Statements . . . . . . . . 18
76 1. Introduction
78 This document defines the URI scheme "tel". The "tel" URI describes
79 resources identified by telephone numbers. A telephone number is a
80 string of decimal digits that uniquely indicates the network
81 termination point. The number contains the information necessary to
82 route the call to this termination point. (This definition is
83 derived from [E.164], but encompasses both public and private
84 numbers.)
86 The "tel" URI telephone number is not restricted in the type of
87 termination point it refers to. The termination point can be in the
88 public telephone network, a private telephone network or the
89 Internet. The termination point can be fixed or wireless and address
90 a fixed wired, mobile or nomadic terminal. The terminal addressed
91 can support any electronic communication service (ECS) including
92 voice, data and fax. The URI can refer to resources identified by a
93 telephone number, including but not limited to originators or targets
94 of a telephone call.
96 The "tel" URI is a globally unique identifier ("name") only; it does
97 not describe the steps necessary to reach a particular number and
98 does not imply dialing semantics. Furthermore, it does not refer to a
99 specific physical device, only to a telephone number.
101 Telephone numbers as commonly understood actually comprise two
102 related, but distinct concepts: as a canonical address-of-record and
103 as a dial string. We define the concepts below:
105 Address-of-record or identifier: The telephone number is understood
106 here as the canonical address-of-record or identifier for a
107 termination point within a specific network. For the public
108 network, these numbers follow the rules in E.164 [E.164], while
109 private numbers follow the rules of the owner of the private
110 numbering plan. Subscribers publish such identifiers as a
111 universal means of being reached, independent of the location of
112 the caller. (Naturally, not all numbers are reachable from
113 everywhere, for a variety of technical and local policy reasons.
114 Also, a single termination point may be reachable from different
115 networks and may have multiple such identifiers.)
116 Dial string: "Dial strings" are the actual numbers, symbols and
117 pauses entered by a user to place a phone call. A dial-string is
118 consumed by one or more network entities, and understood in the
119 context of the configuration of these entities. It is used to
120 generate an address-of-record or identifier in the sense of the
121 previous paragraph so that a call can be routed. Dial-strings may
122 require pre-pended digits to egress the private branch exchange
123 (PBX) the end system is connected to, and they may include
124 post-dial dual-tone multi-frequency (DTMF) signaling that could
125 control an IVR or reach an extension. Dial strings are beyond the
126 scope of this document.
128 Both approaches can be encoded into a URI. For dial strings, this
129 URI is passed to an entity that can reproduce the actions specified
130 in the dial string. For example, in an analog phone system, a dialer
131 translates the dial string into a sequence of actions such as waiting
132 for dial tone, sending DTMF digits, pausing and generating post-dial
133 DTMF digits after the callee picks up. In an integrated services
134 digital network (ISDN) or ISDN user part (ISUP) environment, the
135 signaling elements receiving protocol messages containing the dial
136 string perform the appropriate protocol actions. As noted, this
137 approach is beyond the scope of this specification.
139 The approach described here has the URI specify the telephone number
140 as an identifier, which can be either globally unique or only be
141 valid within a local context. The dialing application is aware of
142 the local context, knowing, for example, whether special digits need
143 to be dialed to seize an outside line, whether network, pulse or tone
144 dialing is needed and what tones indicate call progress. The dialing
145 application then converts the telephone number into a dial sequence
146 and performs the necessary signaling actions. The document below
147 assumes the second model. The dialer does not have to be a user
148 application as found in traditional desktop operating systems, but
149 could well be part of an IP-to-PSTN gateway.
151 To reach a telephone number from a phone on a PBX, for example, the
152 user of that phone has to know how to convert the telephone number
153 identifier into a dial string appropriate for that phone. The
154 telephone number itself does not convey what needs to be done for a
155 particular terminal. Instructions may include dialing "9" before
156 placing a call or prepending a "00" to reach a number in a foreign
157 country. The phone may also need to strip area and country codes.
159 The identifier approach described in this document has the
160 disadvantage that certain services, such as electronic banking or
161 voicemail, cannot be specified in a URI.
163 The notation for phone numbers in this document is similar to that in
164 RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax
165 differs since this document describes URIs whereas RFC 3191 and RFC
166 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/"
167 to indicate parameters (qualifiers). Since URI use the forward slash
168 to describe path hierarchy, the URI scheme described here uses the
169 semicolon, in keeping with Session Initiation Protocol (SIP) URI
170 conventions [RFC3261].
172 The 'tel' URI can be used as a request URI in SIP [RFC3261] requests.
173 The SIP specification also inherits the 'subscriber' part of the
174 syntax as part of the 'user element' in the SIP URI. Other protocols
175 may use this URI for both query-based and prefix-based applications.
177 The "tel" URI does not specify the call type such as voice, fax, or
178 data call and does not provide the connection parameters for a data
179 call. The type and parameters are assumed to be negotiated either
180 in-band by the telephone device or through a signaling protocol such
181 as SIP.
183 2. Terminology
185 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
186 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
187 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
188 [RFC2119] and indicate requirement levels for compliant
189 implementations.
191 3. URI Syntax
193 The URI is defined using the ABNF (augmented Backus-Naur form)
194 described in RFC 2234 [RFC2234] and uses elements from the core
195 definitions (Appendix A of RFC 2234).
197 The syntax definition follows RFC 2396 [RFC2396], indicating the
198 actual characters contained in the URI. Note that the reserved
199 characters "+", ";", "=", and "?" MUST NOT be escaped as they are
200 delimiters for the "tel" URI scheme. These reserved characters MUST
201 be escaped if they appear in parameter values.
203 Characters other than those in the "reserved" and "unsafe" sets (see
204 RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" encoding.
206 The "tel" URI has the following syntax:
208 telephone-uri = "tel:" telephone-subscriber
209 telephone-subscriber = global-number / local-number
210 global-number = global-number-digits *par
211 local-number = local-number-digits *par context *par
212 par = parameter / extension / isdn-subaddress
213 isdn-subaddress = ";isub=" 1*uric
214 extension = ";ext=" 1*phonedigit
215 context = ";phone-context=" descriptor
216 descriptor = domainname / global-number-digits
217 global-number-digits = "+" 1*phonedigit
218 local-number-digits = 1*phonedigit-hex
219 domainname = *( domainlabel "." ) toplabel [ "." ]
220 domainlabel = alphanum
221 / alphanum *( alphanum / "-" ) alphanum
222 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
223 parameter = ";" pname ["=" pvalue ]
224 pname = 1*( alphanum / "-" )
225 pvalue = 1*paramchar
226 paramchar = param-unreserved / unreserved / escaped
227 unreserved = alphanum / mark
228 mark = "-" / "_" / "." / "!" / "~" / "*" /
229 "'" / "(" / ")"
230 escaped = "%" HEXDIG HEXDIG
231 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
232 phonedigit = DIGIT / [ visual-separator ]
233 phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
234 visual-separator = "-" / "." / "(" / ")"
235 alphanum = ALPHA / DIGIT
236 reserved = ";" | "/" | "?" | ":" | "@" | "&" |
237 "=" | "+" | "$" | ","
238 uric = reserved | unreserved | escaped
240 Each parameter name ("pname"), the ISDN subaddress, the 'extension'
241 and the 'context' MUST NOT appear more than once. The
242 'isdn-subaddress' or 'extension' MUST appear first, if present,
243 followed by the 'context' parameter, if present, followed by any
244 other parameters in lexicographical order.
246 This simplifies comparison when the "tel" URI is compared
247 character-by-character, such as in SIP URIs [RFC3261].
249 4. URI Comparisons
251 Two "tel" URIs are equivalent according to the following rules:
253 o Both must be either a 'local-number' or both must be a
254 'global-number', i.e., start with a '+'.
256 o The 'global-number-digits' and the 'local-number-digits' must be
257 equal, after removing all visual separators.
258 o For mandatory additional parameters (Section 5.4) and the
259 'phone-context' and 'extension' parameters defined in this
260 document, The 'phone-context' parameter value is compared as a
261 host name if it is a 'domainname' or digit-by-digit if it is
262 'global-number-digits'. The latter is compared after removing all
263 'visual-separator' characters.
264 o Parameters are compared according to 'pname', regardless of the
265 order they appeared in the URI. If one URI has a parameter name
266 not found in the other, the two URIs are not equal.
267 o URI comparisons are case-insensitive.
269 All parameter names and values SHOULD use lower-case characters since
270 tel URIs may be used within contexts where comparisons are
271 case-sensitive.
273 Section 19.1.4 in the SIP specification [RFC3261] discusses one
274 such case.
276 5. Phone Numbers and Their Context
278 5.1 Phone Numbers
280 The 'telephone-subscriber' part of the URI indicates the number. The
281 phone number can be represented in either global (E.164) or local
282 notation. All phone numbers MUST use the global form unless they
283 cannot be represented as such. Numbers from private numbering plans,
284 emergency ("911", "112") and some directory assistance numbers (e.g.,
285 "411") and other "service codes" (numbers of the form N11 in the
286 United States) cannot be represented in global (E.164) form, and need
287 to be represented as a local number with a context. Local numbers
288 MUST be tagged with a 'phone-context' (Section 5.1.5).
290 Implementations MUST NOT assume that telephone numbers have a
291 maximum, minimum or fixed length, or that they always begin with a
292 certain number.
294 5.1.1 Separators in Phone Numbers
296 Phone numbers MAY contain visual separators. Visual separators
297 ('visual-separator') merely aid readability and are not used for URI
298 comparison or placing a call.
300 Despite complicating comparisons, this specification retains the
301 visual separators to follow the spirit of RFC 2396 [RFC2396],
302 which remarks that "A URI often needs to be remembered by people,
303 and it is easier for people to remember a URI when it consists of
304 meaningful components." Also, ISBN URNs documented in RFC 3187
305 [RFC3187] use visual separators in a manner similar to this
306 specification.
308 Even though ITU-T E.123 [E.123] recommends the use of space
309 characters as visual separators in printed telephone numbers,
310 "tel" URIs cannot use spaces in visual separators to avoid
311 excessive escaping.
313 5.1.2 Alphabetic Characters Corresponding to Digits
315 In some countries, it is popular to write phone numbers using
316 alphabetic characters which correspond to certain numbers on the
317 telephone keypad. The URI format does not support this notation
318 since the mapping from alphabetic characters to digits is not
319 completely uniform internationally, although there are standards
320 [E.161][T1.703] addressing this issue.
322 5.1.3 Alphabetic, * and \\# Characters as Identifiers
324 Since called and calling terminal numbers (TNs) are encoded in BCD in
325 ISUP, six additional values per digit can be encoded, sometimes
326 represented as the hexadecimal characters A through F. Similarly,
327 DTMF allows for the encoding of the symbols *, \# and A through D.
328 However, in accordance with E.164, they may not be included in global
329 numbers. Their meaning in local numbers is not defined here, but they
330 are not prohibited.
332 5.1.4 Global Numbers
334 Globally unique numbers are identified by the leading "+" character.
335 Global numbers MUST be composed with the country (CC) and national
336 (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].
337 Globally unique numbers have the property of being unambiguous
338 everywhere in the world and SHOULD be used.
340 5.1.5 Local Numbers
342 Local numbers are unique only within a certain geographical area or a
343 certain part of the telephone network, e.g., a private branch
344 exchange (PBX), a state or province, a particular local exchange
345 carrier or a particular country. URIs with local phone numbers
346 should only appear in environments where all local entities can
347 successfully set up the call by passing the number to the dialing
348 software. Digits needed for accessing an outside line, for example,
349 are not included in local numbers. Local numbers SHOULD NOT be used
350 unless there is no way to represent the number as a global number.
352 Local numbers require that the originator and recipient are
353 configured appropriately, so that they can insert and recognize
354 the correct descriptors. Since there is no algorithm to
355 independently pick the same descriptor, labeling numbers with
356 their context increases the chances of mis-configuration, so that
357 valid identifiers are rejected by mistake. The algorithm to
358 select descriptors was chosen that accidental collisions should be
359 rare, but they cannot be ruled out.
361 Local numbers MUST have a 'phone-context' parameter that identifies
362 the scope of their validity. The parameter MUST be chosen to
363 unambiguously identify the local context within which the number is
364 unique. Thus, the combination of the descriptor in the
365 'phone-context' parameter and local number is again globally unique.
366 The parameter value is defined by the assignee of the local number.
367 It does NOT indicate a prefix that turns the local number into a
368 global (E.164) number.
370 There are two ways to label the context: via a global number or any
371 number of its leading digits (e.g., "+33") and via a domain name,
372 e.g., "houston.example.com". The choice between the two is left to
373 the "owner" of the local number and is governed by whether there is a
374 global number or domain name that is a valid identifier for a
375 particular local number.
377 The domain name does not have to resolve to any actual host, but MUST
378 be under the administrative control of the entity managing the local
379 phone context.
381 A global number context consists of the initial digits of a valid
382 global number. All global numbers matching these initial digits must
383 be assigned to the same organization that is describing the context
384 and no such matching number can be used by any other organization.
385 For example, +49-6151-16 would be a suitable context for the
386 Technical University of Darmstadt, as it uses all numbers starting
387 with those digits. If such an initial string of digits does not
388 exist, the organization SHOULD use the lowest number of the global
389 number range assigned to it. (This can occur if two organizations
390 share the same decimal block of numbers. For example, assume an
391 organization owns the number range +1-212-939-7000 through
392 +1-212-939-7199. +1-212-939-7 would not be a valid global number
393 context, but +1-212-939-7000 would work.) It is not required that
394 local numbers within the context actually begin with the chosen set
395 of initial numbers.
397 A context consisting of the initial digits of a global number does
398 not imply that adding these to the local number will generate a valid
399 E.164 number. It might do so by coincidence, but this cannot be
400 relied upon. (For example, "911" should be labeled with the context
401 "+1", but "+1-911" is not a valid E.164 number.)
403 National freephone numbers do not need a context, even though they
404 are not necessarily reachable from outside a particular country code
405 or numbering plan. Recall that "tel" URIs are identifiers; it is
406 sufficient that a global number is unique, but it is not required
407 that it be reachable from everywhere.
409 Even non-freephone numbers may be out of date or not be reachable
410 from a particular location. For example, premium services such as
411 "900" numbers in the North American numbering plan are often not
412 dialable from outside the particular country code.
414 The two label types were chosen so that, in almost all cases, a
415 local administrator can pick an identifier that is reasonably
416 descriptive and does not require a new IANA-managed assigned
417 number. It is up to the administrator to assign an appropriate
418 identifier and to use it consistently. Often, an organization can
419 choose among several different identifiers.
421 If the recipient of a "tel" URI uses the URI simply for
422 identification, the receiver does not need to know anything about the
423 context descriptor. It simply treats it as one part of a globally
424 unique identifier, with the other being the local number. If a
425 recipient of the URI intends to place a call to the local number, it
426 MUST verify that it is within the same context as one of the
427 descriptors. If it is not within the same context, it MUST NOT
428 initiate the call and treat the URI like an invalid destination.
430 5.2 ISDN Subaddresses
432 A phone number MAY also contain an 'isdn-subaddress' parameter which
433 indicates an ISDN subaddress.
435 ISDN subaddresses typically contain International Alphabet 5 (IA5
436 [T.50]) characters, but may contain any octet value.
438 5.3 Phone Extensions
440 Phone extensions identify stations behind a non-ISDN PBX and are
441 roughly equivalent in functionality to ISDN subaddresses. They are
442 identified with the 'extension' parameter. At most one of the
443 'isdn-subaddress' and 'extension' parameters can appear in a tel URI,
444 i.e., they cannot appear both at the same time.
446 5.4 Other Parameters
448 Future protocol extensions to this URI scheme may add other
449 parameters ('parameter' in the ABNF). Such parameters can be either
450 mandatory or optional. Mandatory parameters start with "m-". An
451 implementation MAY ignore optional parameters. An implementation
452 MUST NOT use the URI if it contains unknown mandatory parameters.
453 The "m-" prefix cannot be added to parameters that were already
454 registered (except to create a new, logically distinct parameter).
455 The "phone-context" parameter in this document is mandatory, "isub"
456 and "ext" are optional.
458 For example, 'parameter' parameters can be used to store
459 application-specific additional data about the phone number, its
460 intended use, or any conversions that have been applied to the
461 number.
463 Entities that forward protocol requests containing tel URIs with
464 optional parameters MUST NOT delete or modify parameters they do not
465 understand.
467 6. Examples
469 tel:+1-201-555-0123: This URI points to a phone number in the United
470 States. The hyphens are included to make the number more
471 human-readable; they separate country, area codes and subscriber
472 number.
473 tel:7042;phone-context=cs.columbia.edu: The URI describes a local
474 phone number valid within the context "cs.columbia.edu".
475 tel:863-1234;phone-context=+1-914-555: The URI describes a local
476 phone number that is valid within a particular phone prefix.
478 7. Rationale
480 7.1 Why Not Just Put Telephone Numbers in SIP URIs?
482 The "tel" URI describes a service, reaching a telephone number, that
483 is independent of the means of doing so, be it via a SIP-to-PSTN
484 gateway, a direct SIP call via E.164 number ("ENUM") translation
485 [RFC2916], some other signaling protocols such as H.323 or a
486 traditional circuit-switched call initiated on the client side via,
487 say, the Telephony Application Programming Interface (TAPI). It is
488 thus, in spirit, closer to the URN schemes that also leave the
489 resolution to an external mechanism. The same "tel" URI may get
490 translated to any number of other URIs in the process of setting up
491 the call.
493 7.2 Why Not Distinguish Between Call Types?
495 Signaling protocols such as SIP allow to negotiate the call type and
496 parameters, making the very basic indication within the URI scheme
497 moot. Also, since the call type can change frequently, any such
498 indication in a URI is likely to be out of date. If such designation
499 is desired for a device that directly places calls without a
500 signaling protocol such as SIP, mechanisms such as the "type"
501 attribute for the "A" element in HTML may be more appropriate.
503 7.3 Why tel?
505 "Tel" was chosen since it is widely recognized none of the other
506 suggestions appeared appropriate. "Callto" was discarded since URI
507 schemes locate a resource and do not specify an action to be taken.
508 "Telephone" and "phone" were considered too long and not as
509 internationally recognized.
511 7.4 Do Not Confuse Numbers with How They Are Dialed
513 As an example, the E.164 number "+1-212-555-3141" will be dialed in
514 many countries as 00-1-212-555-3141, where the leading "00" is a
515 prefix for international calls. (In general, a "+" symbol in E.164
516 indicates that an international prefix is required.)
518 8. Usage of Telephone URIs in HTML
520 Links using the "tel" URI SHOULD enclose the telephone number, so
521 that users can easily predict the action taken when following the
522 link.
524 Dial +1-212-555-0101
525 for assistance.
527 instead of
529 Dial this number
530 for assistance.
532 On a public HTML page, the telephone number in the URI SHOULD always
533 be in the global form, even if the text of the link uses some local
534 format.
536 Telephone (if dialing in the United States):
537 (201) 555-0111
539 or even
540 For having RFCs read aloud, call
541 1-555-IETF-RFC.
543 9. Use of tel URIs with SIP (Informative)
545 SIP can use the "tel" URI anywhere a URI is allowed, for example as a
546 Request-URI, along with "sip" and "sips" URIs. For brevity, we will
547 imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP
548 URIs can contain telephone numbers. In SIP URIs, they appear as the
549 user part, i.e., before the @ symbol (Section 19.1.6 in [RFC3261]).
551 Unless a SIP UA connects directly to a PSTN gateway, one of the SIP
552 proxy servers has to translate the tel URI to a SIP URI, with the
553 host part of that URI pointing to a gateway. Typically, the outbound
554 proxy server, as the first proxy server visited by a call request,
555 performs this translation. A proxy server can translate all tel URIs
556 to the same SIP host name or select a different gateway for different
557 tel prefixes, based, for example, on information learned from TRIP
558 [RFC3219]. However, a proxy server could also delegate this
559 translation task to any other proxy server since proxy servers are
560 free to apply whatever routing logic they desire. For local numbers,
561 the proxy MUST NOT translate "tel" URIs whose context it does not
562 understand.
564 As noted earlier, all phone numbers MUST use the global form unless
565 they cannot be represented as such. If the local-number format is
566 used, it MUST be qualified by the 'phone-context' parameter.
567 Effectively, the combination of local number and phone context makes
568 the tel URI globally unique.
570 While web pages, vCard business cards, address books and directories
571 can easily contain global tel URIs, users on twelve-button (IP)
572 phones cannot dial such numbers directly and are typically accustomed
573 to dialing shorter strings, e.g., for PBX extensions or local
574 numbers. These so-called dial-strings (Section 1) are not directly
575 represented by tel URIs, as noted. We refer to the rules that govern
576 the translation of dial strings into SIP and tel URIs, global or
577 local, as the dial plan. Currently, translations from dial strings
578 to tel URIs have to take place in end systems. Future efforts may
579 provide means to carry dial strings in a SIP URI, for example, but no
580 such mechanisms exist at the time of writing.
582 A SIP UA can use a dial plan to translate dial strings into SIP or
583 "tel" URIs. The dial plan can be manually configured or, preferably,
584 be downloaded as part of a device configuration mechanism. (At this
585 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, Andrew Main, Xavier Marjou, Jon
624 Peterson, Mike Pierce, Jonathan Rosenberg and James Yu provided
625 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.