idnits 2.17.1 draft-antti-telephony-url-04.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-25) 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 8 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) == Missing Reference: 'CONV-URL' is mentioned on line 397, but not defined == Missing Reference: 'ABNF' is mentioned on line 108, but not defined ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Unexpected draft version: The latest known version of draft-ietf-fax-minaddrfax is -00, but you're referring to -01. -- Unexpected draft version: The latest known version of draft-ietf-fax-minaddrgen is -01, but you're referring to -02. ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Vaha-Sipila 2 Expires 27-Aug-1998 Nokia 3 23-Feb-1998 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 The distribution of this document before its expiry date is 28 unlimited. 30 Abstract 32 This document specifies URL (Uniform Resource Locator) schemes 33 ''phone'', ''fax'' and ''modem'' for specifying the location of a 34 terminal in the phone network and the connection types (modes of 35 operation) that can be used to connect to that entity. This 36 specification covers voice calls (normal phone calls, answering 37 machines and voice messaging systems), facsimile (telefax) calls 38 and data calls, both for POTS and digital/mobile subscribers. 40 Version History 42 | Changes to the previous versions are indicated by a bar in the 43 | left margin like in this section. 45 Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 48 1.1 New URL Schemes . . . . . . . . . . . . . . . . . . . . . 2 49 1.2 Formal Definitions . . . . . . . . . . . . . . . . . . . 2 50 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 2 51 2. URL Schemes for Telephone Calls . . . . . . . . . . . . . 3 52 2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3 53 | 2.2 "phone" URL Scheme . . . . . . . . . . . . . . . . . . . 3 54 2.3 "fax" URL Scheme . . . . . . . . . . . . . . . . . . . . 3 55 2.4 "modem" URL Scheme . . . . . . . . . . . . . . . . . . . 4 56 2.5 Parsing telephone, fax and modem URLs . . . . . . . . . . 4 58 A. Vaha-Sipila URLs for Telephony February 1998 59 2.6 Examples of Use . . . . . . . . . . . . . . . . . . . . . 7 60 3. References . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . 8 62 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 1.1 New URL Schemes 68 URLs that designate phone or fax numbers that can be dialed have 69 been brought forward in other Internet-Drafts. However, none of 70 these has reached the RFC status. This document tries to remedy 71 the situation. All interested parties are invited to submit 72 comments on this Internet-Draft. Contact information can be found 73 at the end of this document. 75 | See also [CONV-URL] for more discussion on conversational URLs. 77 | This specification defines three new URL schemes: "phone", 78 "fax" and "modem". They are intended for describing a terminal 79 that can be contacted using the telephone network. The 80 description includes the subscriber (telephone) number of the 81 terminal and the necessary parameters for successfully 82 connecting to that terminal. 84 | The "phone" scheme describes a connection to a terminal that 85 handles normal voice telephone calls, a voice mailbox or another 86 voice messaging system or a service that can be operated using 87 | DTMF codes. 89 The "fax" scheme describes a connection to a terminal that can 90 handle telefaxes (facsimiles). The name (scheme specifier) for 91 the URL is "fax" as recommended by [E.123]. 93 The "modem" scheme describes a connection to a terminal that can 94 handle incoming data calls. The term "modem" refers to a device 95 that does digital-to-analog and analog-to-digital conversions; 96 in addition to these, a "modem" scheme can describe a fully 97 digital connection. 99 The notation for phone numbers is the same which is specified in 100 | [PSTN-ADDR] and [FAX-ADDR]. However, the syntax definition is a 101 bit different due to the fact that this document specifies URLs 102 | whereas [PSTN-ADDR] and [FAX-ADDR] specify electronic mail 103 addresses. For example, "/" (used in URLs to separate parts in a 104 hierarchical URL [RFC1738]) has been replaced by ";". 106 1.2 Formal Definitions 108 Formal definitions follow [ABNF]. This specification uses 109 elements from the 'core' definitions (Appendix A of [RFC2234]). 111 1.3 Requirements 113 A. Vaha-Sipila URLs for Telephony February 1998 114 Compliant software MUST follow this specification. Requirements 115 are indicated by capitalized words as specified in [RFC2119]. 117 2. URL Schemes for Telephone Calls 119 2.1 Applicability 121 In this document, "user agent" means software that can detect and 122 parse one or more of these URLs and place a call to the remote 123 terminal using hardware at its disposal. 125 These URL schemes are used to direct the user agent to place a 126 call using the telephone network. The network in question may be a 127 landline or mobile phone network. If the phone network 128 differentiates between (for example) voice and data calls, or if 129 the user agent has several different telecommunications equipment 130 at its disposal, it is possible to specify which kind of call 131 (voice/fax/data) is requested. The URL can also contain 132 information about the capabilities of the remote entity, so that 133 the connection can be established successfully. 135 None of the URL schemes do have a 'path' in them - they are 136 always absolute. The URLs are always case-insensitive. 138 2.2 "phone" URL Scheme 140 The URL syntax is formally described as follows. For the basis 141 of this syntax, see [PSTN-ADDR]. 143 telephone-url = telephone-scheme ":" 144 telephone-subscriber 145 | telephone-scheme = "phone" 146 telephone-subscriber = global-phone-number / local-phone-number 147 global-phone-number = "+" 1*phonedigit [isdn-subaddress] 148 [post-dial] 149 local-phone-number = 1*(phonedigit / dtmf-digit / 150 pause-character) [isdn-subaddress] 151 [post-dial] 152 isdn-subaddress = ";isub=" 1*phonedigit 153 post-dial = ";postd=" 1*(phonedigit / dtmf-digit 154 / pause-character) 155 phonedigit = DIGIT / visual-separator 156 visual-separator = "-" / "." 157 pause-character = one-second-pause / wait-for-dial-tone 158 one-second-pause = "p" 159 wait-for-dial-tone = "w" 160 dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D" 162 2.3 "fax" URL Scheme 164 The URL syntax is formally described as follows (the definition 165 reuses nonterminals from the definition above). For the basis of 166 this syntax, see [PSTN-ADDR] and [FAX-ADDR]. 168 A. Vaha-Sipila URLs for Telephony February 1998 169 fax-url = fax-scheme ":" fax-subscriber 170 fax-scheme = "fax" 171 fax-subscriber = fax-global-phone / fax-local-phone 172 fax-global-phone = "+" 1*phonedigit [isdn-subaddress] 173 [t33-subaddress] [post-dial] 174 fax-local-phone = 1*(phonedigit / dtmf-digit / 175 pause-character) [isdn-subaddress] 176 [t33-subaddress] [post-dial] 177 t33-subaddress = ";tsub=" 1*phonedigit 179 2.4 "modem" URL Scheme 181 The URL syntax is formally described as follows. For the basis of 182 this syntax, see [PSTN-ADDR]. 184 modem-url = modem-scheme ":" remote-host 185 modem-scheme = "modem" 186 remote-host = telephone-subscriber *modem-params 187 modem-params = ";type=" data-capabilities 188 data-capabilities = accepted-modem ["?" data-bits parity 189 stop-bits] 190 accepted-modem = "V21" / "V22" / "V22b" / 191 "V23" / "V26" / "V32" / 192 "V32b" / "V34" / "V110" / 193 "V120" / "B103" / "B212" / 194 "X75" 195 data-bits = "7" / "8" 196 parity = "n" / "e" / "o" / "m" / "s" 197 stop-bits = "1" / "2" 199 2.5 Parsing telephone, fax and modem URLs 201 A. The type of call is specified by the scheme specifier. 202 | "phone" means that a voice call is opened. "Fax" indicates 203 that the call should be a facsimile (telefax) call. "Modem" means 204 that it should be a data call. Not all networks differentiate 205 between the types of call; in this case, the scheme specifier 206 indicates the telecommunications equipment type to use. 208 B. and indicate the 209 phone number to be dialed. The phone number can be written in 210 either international or local notation. All phone numbers SHOULD 211 always be written in the international form if there is no good 212 reason to use the local form. 214 Any telephone number must contain at least one , that is, 215 subscriber numbers consisting only of non-numbers are not allowed. 217 International numbers MUST begin with the "+" character. Local 218 numbers MUST NOT contain that character. International numbers 219 MUST be written with the country (CC) and national (NSN) numbers 220 as specified in [E.123] and [E.164]. Local numbers MAY be used 221 if the number only works from inside a certain geographical area 222 or a network. Note that some numbers may work from several 224 A. Vaha-Sipila URLs for Telephony February 1998 225 networks but not from the whole world - these SHOULD be written 226 in international form. 228 C. All characters MUST be removed from the 229 phone number by the user agent before using it do dial out. 230 These cracaters are present only to aid readability: they MUST 231 NOT have any other meaning. Note that although [E.123] 232 recommends the use of space (SP) characters as the separators, 233 spaces MUST NOT be used in these URLs. 235 D. After the telephone number has been extracted, it is 236 converted to the format that the user agent can use to place the 237 call. (For example, the "+" character might be replaced by the 238 international call prefix, or the international and trunk 239 prefixes might be removed to place a local call.) Numbers that 240 have been specified using or 241 MUST be used by the user agent "as is", without any conversions. 243 E. The number may contain a sequence, which MUST be 244 dialled using Dual Tone Multifrequency (DTMF) in-band signalling 245 after the call setup is complete. If the user agent does not 246 support DTMF, MUST be ignored. In that case, the 247 user SHOULD be notified. 249 F. A local phone number or a post-dial sequence may contain 250 characters which indicate a pause of 1 second 251 while dialing ("p"), or a wait for dial tone ("w"). User agents 252 SHOULD support this method of dialing. If it is not supported, 253 user agents MUST ignore everything in the dial string after the 254 first and the user SHOULD be notified. The user 255 or the user agent MAY opt not to place a call if this feature is 256 not supported. 258 Any characters and all dial string characters after 259 the first or MUST be sent to line 260 using DTMF (Dual Tone Multifrequency) in-band signaling, even if 261 dialing is done using direct network signaling (a digital 262 subscriber loop or a mobile phone). 264 G. A phone number MAY also contain an which 265 indicates an ISDN subaddress. User agent SHOULD support ISDN 266 subaddresses. These addresses are sent to the network by using a 267 method available to the user agent (typically, ISDN subscribers 268 send the address with the call setup signalling). If ISDN 269 subaddressing is not supported by the caller, 270 MUST be ignored and the user SHOULD be notified. The user or the 271 user agent MAY opt not to place a call if this feature is not 272 supported. 274 H. A fax number MAY also contain a , which 275 indicates the start of a T.33 subaddress [T.33]. User agents 276 SHOULD support this. Otherwise MUST be ignored 277 and the user SHOULD be notified. The user or the user agent MAY 278 opt not to place a call if this feature is not supported. 280 A. Vaha-Sipila URLs for Telephony February 1998 281 I. indicate the minimum compliance required from 282 the user agent to be able to connect to the remote entity. The 283 minimum compliance is defined as being equal to or a superset of 284 the capabilities of the listed modem type. 286 The user agent MUST call out using compatible hardware, or request 287 that the network provides such a service. 289 For example, if the user agent only has access to a V.22bis modem 290 and the URL indicates that the minimum acceptable connection is 291 V.32bis, the user agent MUST NOT try to connect to the remote host 292 since V.22bis is a subset of V.32bis. However, if the URL lists 293 V.32 as the minimum acceptable connection, the user agent can use 294 V.32bis to create a connection since V.32bis is a superset of 295 V.32. 297 This feature is present because modem pools often have separate 298 numbers for slow modems and fast modems, or have different numbers 299 for analog and ISDN connections, or may use proprietary modems 300 that are incompatible with standards. It is somewhat analogous to 301 the connection type specifier (typecode) in FTP URLs [RFC1738]: it 302 provides the user agent with information that can not be deduced 303 from the scheme specifier, but is helpful for successful 304 operation. 306 This also means that the number of data and stop bits and parity 307 MUST be set according to the information given in the URL or to 308 default values, if the information is not present. 310 The capability tokens are listed below. If capabilities 311 suggest that it is impossible to create a connection, the 312 connection MUST NOT be created. 314 If new modem types are standardized by ITU-T, this list can 315 be extended with those capability tokens. Tokens are formed by 316 taking the name of the standard and joining together the first 317 letter, number and the first letter of the postfix. New 318 capabilities SHOULD then be documented in an RFC. New non-ITU-T 319 capabilities (such as vendor-proprietary modem types) 320 MUST be specified in a separate RFC. 322 Capability Explanation 324 V21 ITU-T V.21 325 V22 ITU-T V.22 326 V22b ITU-T V.22bis 327 V23 ITU-T V.23 328 V26t ITU-T V.26ter 329 V32 ITU-T V.32 330 V32b ITU-T V.32bis 331 V34 ITU-T V.34 332 V110 ITU-T V.110 333 V120 ITU-T V.120 335 A. Vaha-Sipila URLs for Telephony February 1998 336 X75 ITU-T X.75 337 B103 Bell 103 338 B212 Bell 212 339 Data bits: "8" or "7" The number of data bits. If not 340 specified, defaults to "8". 341 Parity: "n", "e", "o", Parity. None, even, odd, mark or 342 "m", "s" space parity, respectively. If 343 not specified, defaults to "n". 344 Stop bits: "1" or "2" The number of stop bits. If not 345 specified, defaults to "1". 347 2.6 Examples of Use 349 | phone:+358-55-1234567 351 This URL instructs the user agent to place a voice call to the 352 specified number in Finland. The hyphens are included to make the 353 number more human-readable: country and area codes have been 354 separated from the subscriber number. 356 fax:+358.55.1234567 358 The above URL instructs the user agent to place a fax call to 359 the specified number. It uses dots instead of hyphens as 360 separators, but they have no effect on the functionality. 362 modem:+358551234567;type=v32b?7e1;type=v110 364 This URL instructs the user agent to place a data call to the 365 specified number. The user agent may opt to use either a ITU-T 366 V.32bis modem (or a faster one, which is compatible with V.32bis), 367 using settings of 7 data bits, even parity and one stop bit, or an 368 ISDN connection using ITU-T V.110 protocol. 370 | phone:+358-55-1234567;postd=pp22 372 The above URL instructs the user agent to place a voice call to 373 +358-55-1234567, then wait two seconds and emit two DMTF dialing 374 tones "2" on the line (for example, to choose a particular 375 extension number). 377 | phone:0w00358551234567 379 This URL places a voice call to the given number. The number 380 format is intended for local use: the first zero opens an 381 outside line, the "w" character waits for a second dial tone, 382 and the number already has the international access code 383 appended to it ("00"). This kind of phone number MUST NOT be 384 used in an environment where all users of this URL might not be 385 able to successfully dial out by using this number directly. 386 However, this might be appropriate for pages in a company 387 intranet. 389 3. References 391 A. Vaha-Sipila URLs for Telephony February 1998 393 [RFC2234] Augmented BNF for Syntax Specifications: ABNF. 394 November 1997. D. Crocker et al. RFC 2234. 395 397 | [CONV-URL] Conversational Multimedia URLs. 1997. Pete Cordell. An 398 | Internet-Draft (work in progress). 399 | 402 [FAX-ADDR] Minimal FAX Address Format in Internet Mail. 1998. 403 C. Allocchio. An Internet-Draft (work in progress). 404 407 [PSTN-ADDR] Minimal PSTN Address Format in Internet Mail. 1998. 408 C. Allocchio. An Internet-Draft (work in progress). 409 412 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 413 Berners-Lee et al. RFC 1738. 414 416 [RFC2119] Key Words for Use in RFCs to Indicate Requirement 417 Levels. March 1997. S. Bradner. RFC 2119. 418 420 [E.123] ITU-T Recommendation E.123: Telephone Network and ISDN 421 Operation, Numbering, Routing and Mobile Service: Notation for 422 National and International Telephone Numbers. 1993. 424 [E.164] ITU-T Recommendation E.164: Telephone Network and ISDN 425 Operation, Numbering, Routing and Mobile Service: Numbering Plan 426 for the ISDN Era. 1991. 428 [T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing 429 the Subaddress. 1996. 431 4. Security Considerations 433 It should be noted that the user agent SHOULD NOT call out without 434 the knowledge of the user because of associated risks, which 435 include 437 - call costs (including long calls, long distance calls, 438 international calls and prime rate calls) 439 - wrong numbers inserted on web pages by malicious users 440 - making the user's phone line unavailable (off-hook) for a 441 malicious purpose 442 - opening a data call to a remote host, thus possibly opening a 443 back door to the user's computer 445 The user agent SHOULD have some mechanism that the user can use to 447 A. Vaha-Sipila URLs for Telephony February 1998 448 filter out unwanted numbers. The user agent SHOULD NOT use rapid 449 redialing of the number if it is busy to avoid the congestion of 450 the (signaling) network. Also, the user agent SHOULD detect if the 451 number is unavailable or if the call is terminated before the 452 dialing string has been completely processed (for example, the 453 call is terminated while waiting for user input) and not try to 454 call again, unless instructed by the user. 456 5. Authors' Addresses 458 Contact person for this specification: 460 Nokia Mobile Phones 461 Antti Vaha-Sipila 462 P. O. Box 68 463 FIN-33721 Tampere 464 Finland 466 Electronic mail: antti.vaha-sipila@nmp.nokia.com 468 Please include your name and electronic mail address in all 469 communications. If you want to receive the newest version of this 470 specification electronically, send mail to the address above. 472 This document expires on the 27th of August, 1998, or when a 473 new version is released. 475 A. Vaha-Sipila URLs for Telephony February 1998