idnits 2.17.1 draft-antti-telephony-url-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC1738' is defined on line 365, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Vaha-Sipila 2 Expires 24-Mar-1998 Nokia 3 19-Sep-1997 5 URLs for Telephony 6 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To learn the current status of any Internet-Draft, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document specifies URL (Uniform Resource Locator) schemes 30 "tel", "fax" and "modem" for specifying the location of a terminal 31 in the phone network and the connection types (modes of operation) 32 that can be used to connect to that entity. This specification 33 covers voice calls (normal phone calls, answering machines and 34 voice messaging systems), facsimile (telefax) calls and data 35 calls, both for POTS and digital/mobile subscribers. 37 Version History 39 > Changes to the previous versions are indicated by a bar in the 40 > left margin like in this section. 42 Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . 2 45 1.1 New URL Schemes . . . . . . . . . . . . . . . . . 2 46 1.2 Formal Definitions . . . . . . . . . . . . . . . . 2 47 1.3 Requirements . . . . . . . . . . . . . . . . . . . 2 48 2. URL Schemes for Telephone Calls . . . . . . . . . 2 49 2.1 Applicability . . . . . . . . . . . . . . . . . . 3 50 2.2 "tel" URL Scheme . . . . . . . . . . . . . . . . . 3 51 2.3 "fax" URL Scheme . . . . . . . . . . . . . . . . . 3 52 2.4 "modem" URL Scheme . . . . . . . . . . . . . . . . 4 53 2.5 Parsing tel, fax and modem URLs . . . . . . . . . 4 54 2.6 Examples of Use . . . . . . . . . . . . . . . . . 6 55 3. References . . . . . . . . . . . . . . . . . . . . 7 57 A. Vaha-Sipila URLs for Telephony September 1997 58 4. Security Considerations . . . . . . . . . . . . . 7 59 5. Authors' Addresses . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 1.1 New URL Schemes 65 URLs that designate phone or fax numbers that can be dialed have 66 been brought forward in other (currently expired) Internet-Drafts. 67 However, none of these has reached the RFC status. This document 68 tries to remedy the situation. All interested parties are invited 69 to submit comments on this Internet-Draft. Contact information can 70 be found at the end of this document. 72 > This specification defines three new URL schemes: "tel", "fax" 73 > and "modem". They are intended for describing a terminal that 74 > can be contacted using the telephone network. The description 75 > includes the subscriber (telephone) number of the terminal and 76 > the necessary parameters for successfully connecting to that 77 > terminal. 79 > The "tel" scheme describes a connection to a terminal that 80 > handles normal voice telephone calls, a voice mailbox or another 81 > voice messaging system or a service that can be operated using 82 > DTMF codes or any other telephone call that uses voice. 84 > The "fax" scheme describes a connection to a terminal that can 85 > handle telefaxes (facsimiles). 87 > The "modem" scheme describes a connection to a terminal that can 88 > handle incoming data calls. The term "modem" refers to a device 89 > that does digital-to-analog and analog-to-digital conversions; 90 > in addition to these, a "modem" scheme can describe a fully 91 > digital connection. 93 1.2 Formal Definitions 95 Rules are separated from definitions by an equal "=", literals are 96 quoted with double quotes "", parentheses "(" and ")" are used to 97 group elements and optional elements are enclosed in "[" and "]" 98 brackets. 100 Elements may be preceded with n* to designate n repetitions of the 101 following element; n defaults to 0. Single quotes '' are used to 102 indicate elements that are not formally specified and are 103 described in free text instead. Indentation indicates that the 104 definition continues from the previous line. 106 1.3 Requirements 108 Compliant software MUST follow this specification. Requirements 109 are indicated by capitalized words as specified in [RFC2119]. 111 2. URL Schemes for Telephone Calls 113 A. Vaha-Sipila URLs for Telephony September 1997 114 2.1 Applicability 116 > In this document, "user agent" means software that can detect 117 > and parse one or more of these URLs and place a call to the 118 > remote terminal using hardware at its disposal. 120 These URL schemes are used to direct the user agent to place a 121 call using the telephone network. The network in question may be a 122 landline or mobile phone network. If the phone network 123 differentiates between (for example) voice and data calls, or if 124 the user agent has several different telecommunications equipment 125 at its disposal, it is possible to specify which kind of call 126 (voice/fax/data) is requested. It is also possible to give 127 information about the capabilities of the remote entity, so that 128 the connection can be established successfully. 130 > None of the URL schemes do have a 'path' in them - they are 131 > always absolute. Everything is case-insensitive. 133 2.2 "tel" URL Scheme 135 > The URL syntax is formally described as follows: 137 > tel-url = scheme ":" scheme-specific-part 138 > scheme = "tel" 139 > scheme-specific-part = subscriber-id 140 > subscriber-id = ["+"] phone-number 141 > phone-number = 1*phonedigit 142 > [sub-address-separator 1*phonedigit] 143 > [pause-character *(phonedigit | 144 > dtmf-digit | pause-character)] 145 > phonedigit = digit | "-" | "." 146 > sub-address-separator = "i" 147 > pause-character = "p" | "w" 148 > digit = "0" | "1" | "2" | "3" | "4" | "5" | 149 > "6" | "7" | "8" | "9" 150 > dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" 152 2.3 "fax" URL Scheme 154 > The URL syntax is formally described as follows: 156 > fax-url = scheme ":" scheme-specific-part 157 > scheme = "fax" 158 > scheme-specific-part = subscriber-id [fax-params] 159 > subscriber-id = ["+"] phone-number 160 > phone-number = 1*phonedigit 161 > [sub-address-separator 1*phonedigit] 162 > [pause-character *(phonedigit | 163 > dtmf-digit | pause-character)] 164 > phonedigit = digit | "-" | "." 165 > sub-address-separator = "i" | "s" 166 > pause-character = "p" | "w" 168 A. Vaha-Sipila URLs for Telephony September 1997 169 > digit = "0" | "1" | "2" | "3" | "4" | "5" | 170 > "6" | "7" | "8" | "9" 171 > dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" 172 > fax-params = ";type=" fax-capabilities 173 > fax-capabilities = "T2" | "T3" | "T4" | "T6" 175 2.4 "modem" URL Scheme 177 > The "modem" URL scheme has two free-text fields, which contain 178 > the user name and password for authentication. Certain 179 > characters in these fields are marked as "reserved", and they 180 > MUST be escaped using URL-encoding if present in the free-text 181 > fields. Characters not present in 7-bit US ASCII, unprintable 182 > characters and whitespace MUST also be escaped. 184 > reserved = " " | ":" | "?" | ";" | "=" | "@" 185 > | "+" 187 > The URL syntax is formally described as follows: 189 > modem-url = scheme ":" scheme-specific-part 190 > scheme = "modem" 191 > scheme-specific-part = [user-name [":" password] "@"] 192 > subscriber-id *[modem-params] 193 > subscriber-id = ["+"] phone-number 194 > phone-number = 1*phonedigit 195 > [sub-address-separator 1*phonedigit] 196 > [pause-character *(phonedigit | 197 > dtmf-digit | pause-character)] 198 > phonedigit = digit | "-" | "." 199 > sub-address-separator = "i" 200 > pause-character = "p" | "w" 201 > digit = "0" | "1" | "2" | "3" | "4" | "5" | 202 > "6" | "7" | "8" | "9" 203 > dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" 204 > modem-params = ";type=" data-capabilities 205 > data-capabilities = modem-type ["?" data-bits parity 206 > stop-bits] 207 > modem-type = "V21" | "V22" | "V22b" | 208 > "V23" | "V26" | "V32" | 209 > "V32b" | "V34" | "V110" | 210 > "V120" | "B103" | "B212" | 211 > "X75" 212 > data-bits = "7" | "8" 213 > parity = "n" | "e" | "o" | "m" | "s" 214 > stop-bits = "1" | "2" 215 > user-name = 'a user name for authentication; 216 > in URL-encoded notation' 217 > password = 'a password for authentication; 218 > in URL-encoded notation' 220 2.5 Parsing tel, fax and modem URLs 222 A. The type of call is specified by the scheme specifier. "Tel" 224 A. Vaha-Sipila URLs for Telephony September 1997 225 means that a voice call is opened. "Fax" indicates that the call 226 should be a facsimile (telefax) call. "Modem" means that it should 227 be a data call. 229 > B. "Subscriber-id" is the phone number to be dialed. This phone 230 > number MUST be written in international notation with country 231 > (CC) and national (NSN) numbers, as specified in [E.123] and 232 > [E.164], unless the number only works from inside a certain 233 > geographical area or a network. Note that some numbers may work 234 > from several networks but not from the whole world - these 235 > SHOULD be written in international form. 237 The "subscriber-id" is extracted. If it begins with a "+", it is 238 an international number. This kind of a number is converted to the 239 user agent's local format (for example, if the agent is a browser 240 component that dials out, the "+" is replaced by the international 241 call prefix, or if the country code matches the country code of 242 user agent's home country, the "+" and the country code are 243 replaced by a trunk call prefix). 245 > International numbers MUST begin with "+", which indicates that 246 > the number begins with a country code (CC). Hyphens and dots in 247 > a phone number are only to aid readability; they MUST NOT have 248 > any other meaning. Although [E.123] recommends the use of space 249 > characters as the separators, spaces MUST NOT be used in these 250 > URLs. 252 A phone number may contain "p" or "w" characters which indicate a 253 pause of 1 second while dialing, or a wait for user input, 254 respectively. User agents SHOULD support this method of dialing. 255 If it is not supported, user agents MUST ignore everything after 256 the "p" or "w" characters. All digits after the first "p" or "w" 257 character MUST be sent to line using DTMF (Dual Tone 258 Multifrequency) in-band signaling, even if dialing is done using 259 direct network signaling (a digital subscriber loop or a mobile 260 phone). 262 > A phone number MAY also contain an "i" character which indicates 263 > the start of an ISDN subaddress. ISDN subaddresses are sent to 264 > the remote terminal during call setup by the caller's equipment. 265 > ISDN-connected user agents SHOULD support this method of dialing 266 > and if it is not supported, the "i" character and all subsequent 267 > digits MUST be ignored. 269 > A fax number MAY also contain a "s" character, which indicates 270 > the start of a T.33 subaddress [T.33]. User agents MAY support 271 > this method of dialing. Otherwise the "s" character and all 272 > subsequent digits MUST be ignored. 274 > Any telephone number must contain at least one digit, that is, 275 > numbers consisting only of non-numbers are not allowed. 277 > C. A "type" specifier after "subscriber-id" tells the user-agent 278 > which kind of telefax or modem can be used to contact the remote 280 A. Vaha-Sipila URLs for Telephony September 1997 281 > entity. The user agent MUST call out using compatible hardware, 282 > or request that the network provides such a service. For the 283 > "modem" URL, this also means that the number of data and stop 284 > bits and parity MUST be set according to the information given 285 > in the URL or to default values, if the information is not 286 > present. 288 The capability tokens are listed below. If parsed capabilities 289 suggest that it is impossible to create a connection, the 290 connection MUST NOT be created. 292 > D. After a data connection has been established, "user-name" and 293 > "password" parts instruct the user agent of how to identify 294 > itself to the remote entity. How this identifying information is 295 > used is outside the scope of this document. For example, they 296 > might be given as parameters to an autologin script. 298 > If new modem or fax types are standardized by ITU-T, this list 299 > can be extended with those capability tokens. Tokens are formed 300 > by taking the name of the standard and joining together the 301 > first letter, number and the first letter of the postfix. New 302 > capabilities SHOULD then be documented in an RFC. New non-ITU-T 303 > capabilities MUST be specified in an RFC. 305 Capability Explanation 307 V21 ITU-T V.21 308 V22 ITU-T V.22 309 V22b ITU-T V.22bis 310 V23 ITU-T V.23 311 V26t ITU-T V.26ter 312 V32 ITU-T V.32 313 V32b ITU-T V.32bis 314 V34 ITU-T V.34 315 V110 ITU-T V.110 316 V120 ITU-T V.120 317 X75 ITU-T X.75 318 B103 Bell 103 319 B212 Bell 212 320 > T2 ITU-T T.2 (G1) facsimile 321 > T3 ITU-T T.3 (G2) facsimile 322 > T4 ITU-T T.4 (G3) facsimile 323 > T6 ITU-T T.6 (G4) facsimile 324 Data bits: "8" or "7" The number of data bits. If not 325 specified, defaults to "8". 326 Parity: "n", "e", "o", Parity. None, even, odd, mark or 327 "m", "s" space parity, respectively. If 328 not specified, defaults to "n". 329 Stop bits: "1" or "2" The number of stop bits. If not 330 specified, defaults to "1". 332 2.4 Examples of Use 334 tel:+358-55-1234567 336 A. Vaha-Sipila URLs for Telephony September 1997 337 This URL instructs the user agent to place a voice call to the 338 specified number in Finland. The hyphens are included to make the 339 number more human-readable: country and area codes have been 340 separated from the subscriber number. 342 fax:+358.55.1234567 344 The above URL instructs the user agent to place a fax call to the 345 specified number. It uses dots instead of hyphens as separators. 347 modem:+358551234567;type=v34?7e1;type=v110 349 This URL instructs the user agent to place a data call to the 350 specified number. The user agent may opt to use either a ITU-T 351 V.34 modem (or a slower one, which is compatible with V.34), using 352 settings of 7 data bits, even parity and one stop bit, or an ISDN 353 connection using ITU-T V.110 protocol. 355 tel:+358-55-1234567pp22 357 The above URL instructs the user agent to place a voice call to 358 +358-55-1234567, then wait two seconds and emit two DMTF dialing 359 tones "2" on the line (for example, to choose a particular 360 extension number). As a side note, ost Hayes AT compatible modems 361 accept commas "," as the pause characters. 363 3. References 365 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 366 Berners-Lee et al. 368 [RFC2119] Key Words for Use in RFCs to Indicate Requirement 369 Levels. March 1997. S. Bradner. 370 372 > [E.123] ITU-T Recommendation E.123: Telephone Network and ISDN 373 > Operation, Numbering, Routing and Mobile Service: Notation for 374 > National and International Telephone Numbers. 1993. 376 > [E.164] ITU-T Recommendation E.164: Telephone Network and ISDN 377 > Operation, Numbering, Routing and Mobile Service: Numbering Plan 378 > for the ISDN Era. 1991. 380 > [T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing 381 > the Subaddress. 1996. 383 4. Security Considerations 385 It should be noted that the user agent SHOULD NOT call out without 386 the knowledge of the user because of associated risks, which 387 include 389 - call costs (including long calls, long distance calls, 391 A. Vaha-Sipila URLs for Telephony September 1997 392 international calls and prime rate calls) 393 - wrong numbers inserted on web pages by malicious users 394 - making the user's phone line unavailable (off-hook) for a 395 malicious purpose 396 - opening a data call to a remote host, thus possibly opening a 397 back door to the user's computer 399 The user agent SHOULD have some mechanism that the user can use to 400 filter out unwanted numbers. The user agent SHOULD NOT use rapid 401 redialing of the number if it is busy to avoid the congestion of 402 the (signaling) network. Also, the user agent SHOULD detect if the 403 number is unavailable or if the call is terminated before the 404 dialing string has been completely processed (for example, the 405 call is terminated while waiting for user input) and not try to 406 call again, unless instructed by the user. 408 5. Authors' Addresses 410 Contact person for this specification: 412 Nokia Mobile Phones 413 Antti Vaha-Sipila 414 P. O. Box 68 415 FIN-33721 Tampere 416 Finland 418 Electronic mail: antti.vaha-sipila@nmp.nokia.com 420 Please include your name and electronic mail address in all 421 communications. If you want to receive the newest version of this 422 specification electronically, send mail to the address above. 424 This document expires on the 24th of March, 1998, or when a 425 new version is released. 427 A. Vaha-Sipila URLs for Telephony September 1997