idnits 2.17.1 draft-antti-telephony-url-05.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 2 longer pages, the longest (page 4) being 116 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '...scriber glob...' == 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) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Normative reference to a draft: ref. 'CONV-URL' ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2303 (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2304 (Obsoleted by RFC 3192) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Vaha-Sipila 2 Expires 29-Dec-1998 Nokia 3 25-Jun-1998 5 URLs for Telephone Calls 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 view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 The distribution of this document before its expiry date is 29 unlimited. 31 Abstract 33 This document specifies URL (Uniform Resource Locator) schemes 34 ''tel'', ''fax'' and ''modem'' for specifying the location of a 35 terminal in the phone network and the connection types (modes of 36 operation) that can be used to connect to that entity. This 37 specification covers voice calls (normal phone calls, answering 38 machines and voice messaging systems), facsimile (telefax) calls 39 and data calls, both for POTS and digital/mobile subscribers. 41 Version History 43 | Changes to the previous versions are indicated by a bar in the 44 | left margin like in this section. 46 | In this file, the bars indicate changes since version 04. 48 Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1 New URL Schemes . . . . . . . . . . . . . . . . . . . . . 2 52 1.2 Formal Definitions . . . . . . . . . . . . . . . . . . . 2 53 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 3 54 2. URL Schemes for Telephone Calls . . . . . . . . . . . . . 3 55 2.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 3 56 | 2.2 "tel" URL Scheme . . . . . . . . . . . . . . . . . . . . 3 57 2.3 "fax" URL Scheme . . . . . . . . . . . . . . . . . . . . 3 59 A. Vaha-Sipila URLs for Telephone Calls June 1998 61 2.4 "modem" URL Scheme . . . . . . . . . . . . . . . . . . . 4 62 2.5 Parsing telephone, fax and modem URLs . . . . . . . . . . 4 63 2.6 Examples of Use . . . . . . . . . . . . . . . . . . . . . 7 64 2.7 The Choice of the Scheme Specifier . . . . . . . . . . . 8 65 3. References . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. Security Considerations . . . . . . . . . . . . . . . . . 9 67 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 1.1 New URL Schemes 73 URLs that designate phone or fax numbers that can be dialed have 74 been brought forward in other Internet-Drafts. However, none of 75 these has reached the RFC status. This document tries to remedy 76 the situation. All interested parties are invited to submit 77 comments on this Internet-Draft. Contact information can be found 78 at the end of this document. 80 See also [CONV-URL] for more discussion on conversational URLs. 82 | This specification defines three new URL schemes: "tel", 83 "fax" and "modem". They are intended for describing a terminal 84 that can be contacted using the telephone network. The 85 description includes the subscriber (telephone) number of the 86 terminal and the necessary parameters for successfully 87 connecting to that terminal. 89 | The "tel" scheme describes a connection to a terminal that 90 handles normal voice telephone calls, a voice mailbox or another 91 voice messaging system or a service that can be operated using 92 DTMF codes. 94 The "fax" scheme describes a connection to a terminal that can 95 handle telefaxes (facsimiles). The name (scheme specifier) for 96 the URL is "fax" as recommended by [E.123]. 98 The "modem" scheme describes a connection to a terminal that can 99 handle incoming data calls. The term "modem" refers to a device 100 that does digital-to-analog and analog-to-digital conversions; 101 in addition to these, a "modem" scheme can describe a fully 102 digital connection. 104 The notation for phone numbers is the same which is specified in 105 | [RFC2303] and [RFC2304]. However, the syntax definition is a 106 bit different due to the fact that this document specifies URLs 107 | whereas [RFC2303] and [RFC2304] specify electronic mail 108 addresses. For example, "/" (used in URLs to separate parts in a 109 hierarchical URL [RFC1738]) has been replaced by ";". 111 1.2 Formal Definitions 113 | Formal definitions follow [RFC2234]. This specification uses 114 elements from the 'core' definitions (Appendix A of [RFC2234]). 116 A. Vaha-Sipila URLs for Telephone Calls June 1998 117 1.3 Requirements 119 Compliant software MUST follow this specification. Requirements 120 are indicated by capitalized words as specified in [RFC2119]. 122 2. URL Schemes for Telephone Calls 124 2.1 Applicability 126 In this document, "user agent" means software that can detect and 127 parse one or more of these URLs and place a call to the remote 128 | terminal using hardware and software at its disposal after it has 129 | been properly configured. 131 These URL schemes are used to direct the user agent to place a 132 call using the telephone network. The network in question may be a 133 landline or mobile phone network. If the phone network 134 differentiates between (for example) voice and data calls, or if 135 the user agent has several different telecommunications equipment 136 at its disposal, it is possible to specify which kind of call 137 (voice/fax/data) is requested. The URL can also contain 138 information about the capabilities of the remote entity, so that 139 the connection can be established successfully. 141 None of the URL schemes do have a 'path' in them - they are 142 always absolute. The URLs are always case-insensitive. 144 2.2 "tel" URL Scheme 146 The URL syntax is formally described as follows. For the basis 147 of this syntax, see [RFC2303]. 149 telephone-url telephone-scheme ":" 150 telephone-subscriber 151 | telephone-scheme "tel" 152 telephone-subscriber global-phone-number / local-phone-number 153 global-phone-number "+" 1*phonedigit [isdn-subaddress] 154 [post-dial] 155 local-phone-number 1*(phonedigit / dtmf-digit / 156 pause-character) [isdn-subaddress] 157 [post-dial] 158 isdn-subaddress ";isub" 1*phonedigit 159 post-dial ";postd" 1*(phonedigit / dtmf-digit 160 / pause-character) 161 phonedigit DIGIT / visual-separator 162 visual-separator "-" / "." / "(" / ")" 163 pause-character one-second-pause / wait-for-dial-tone 164 one-second-pause "p" 165 wait-for-dial-tone "w" 166 dtmf-digit "*" / "#" / "A" / "B" / "C" / "D" 168 2.3 "fax" URL Scheme 170 A. Vaha-Sipila URLs for Telephone Calls June 1998 172 The URL syntax is formally described as follows (the definition 173 reuses nonterminals from the definition above). For the basis of 174 this syntax, see [RFC2303] and [RFC2304]. 176 fax-url fax-scheme ":" fax-subscriber 177 fax-scheme "fax" 178 fax-subscriber fax-global-phone / fax-local-phone 179 fax-global-phone "+" 1*phonedigit [isdn-subaddress] 180 [t33-subaddress] [post-dial] 181 fax-local-phone 1*(phonedigit / dtmf-digit / 182 pause-character) [isdn-subaddress] 183 [t33-subaddress] [post-dial] 184 t33-subaddress ";tsub" 1*phonedigit 186 2.4 "modem" URL Scheme 188 The URL syntax is formally described as follows. For the basis of 189 this syntax, see [RFC2303]. 191 modem-url modem-scheme ":" remote-host 192 modem-scheme "modem" 193 remote-host telephone-subscriber *modem-params 194 modem-params ";type" data-capabilities 195 data-capabilities accepted-modem ["?" data-bits parity 196 stop-bits] 197 accepted-modem "V21" / "V22" / "V22b" / 198 "V23" / "V26t" / "V32" / 199 "V32b" / "V34" / "V110" / 200 "V120" / "B103" / "B212" / 201 "X75" / "vnd." vendor-name "." 202 modem-type 203 data-bits "7" / "8" 204 parity "n" / "e" / "o" / "m" / "s" 205 stop-bits "1" / "2" 206 vendor-name 1*(ALPHA / DIGIT / "-" / "+") 207 modem-type 1*(ALPHA / DIGIT / "-" / "+") 209 2.5 Parsing telephone, fax and modem URLs 211 A. The type of call is specified by the scheme specifier. 212 | "Tel" means that a voice call is opened. "Fax" indicates 213 that the call should be a facsimile (telefax) call. "Modem" means 214 that it should be a data call. Not all networks differentiate 215 between the types of call; in this case, the scheme specifier 216 indicates the telecommunications equipment type to use. 218 B. and indicate the 219 phone number to be dialed. The phone number can be written in 220 either international or local notation. All phone numbers SHOULD 221 always be written in the international form if there is no good 222 reason to use the local form. 224 Any telephone number MUST contain at least one , that is, 225 subscriber numbers consisting only of non-numbers are not allowed. 227 A. Vaha-Sipila URLs for Telephone Calls June 1998 229 International numbers MUST begin with the "+" character. Local 230 numbers MUST NOT contain that character. International numbers 231 MUST be written with the country (CC) and national (NSN) numbers 232 | as specified in [E.123] and [E.164]. International numbers have 233 | the property of being totally unambiguous everywhere in the world 234 | if the user agent is properly configured. 236 Local numbers MAY be used if the number only works from inside a 237 certain geographical area or a network. Note that some numbers may 238 work from several networks but not from the whole world - these 239 | SHOULD be written in international form. URLs containing local 240 | phone numbers should only appear in an environment where all 241 | user agents can get the call successfully set up by passing the 242 | number to the dialing entity "as is". An example could be a 243 | company intranet, where all user agents are located under a 244 | the same private telephone exchange. If local phone numbers 245 | are used, the document in which they are present SHOULD contain 246 | an indication of the context in which they are intended to be 247 | used. 249 | In some regions, it is popular to write phone numbers using 250 | alphabetic characters which correspond to certain numbers on the 251 | telephone keypad. Letters in characters do not have 252 | anything to do with this, nor is this supported by this URL 253 | scheme. 255 C. All characters MUST be removed from the 256 phone number by the user agent before using it do dial out. 257 These cracaters are present only to aid readability: they MUST 258 NOT have any other meaning. Note that although [E.123] 259 recommends the use of space (SP) characters as the separators, 260 spaces MUST NOT be used in these URLs. 262 D. After the telephone number has been extracted, it is 263 converted to the format that the user agent can use to place the 264 call. (For example, the "+" character might be replaced by the 265 international call prefix, or the international and trunk 266 prefixes might be removed to place a local call.) Numbers that 267 have been specified using or 268 MUST be used by the user agent "as is", without any conversions. 270 E. The number may contain a sequence, which MUST be 271 dialled using Dual Tone Multifrequency (DTMF) in-band signalling 272 | or pulse dialing after the call setup is complete. If the user 273 | agent does not support DTMF or pulse dialing after the call has 274 | been set up, MUST be ignored. In that case, the user 275 SHOULD be notified. 277 F. A local phone number or a post-dial sequence may contain 278 characters which indicate a pause 279 while dialing ("p"), or a wait for dial tone ("w"). 281 | User agents MAY support this method of dialing, and the final 283 A. Vaha-Sipila URLs for Telephone Calls June 1998 285 | interpretation of these characters is left to the user agent. 287 If it is not supported, user agents MUST ignore everything in the 288 dial string after the first and the user SHOULD 289 be notified. The user or the user agent MAY opt not to place a 290 call if this feature is not supported and these characters are 291 present in the URL. 293 Any characters and all dial string characters after 294 the first or SHOULD be sent to line 295 using DTMF (Dual Tone Multifrequency) in-band signaling, even if 296 dialing is done using direct network signaling (a digital 297 | subscriber loop or a mobile phone). If the local infrastructure 298 | does not support DTMF codes, the user agent MAY opt to use pulse 299 | dialing. However, it should be noted that certain services which 300 | are controlled using DTMF tones cannot be controlled with pulse 301 | dialing. 303 G. A phone number MAY also contain an which 304 indicates an ISDN subaddress. User agent SHOULD support ISDN 305 subaddresses. These addresses are sent to the network by using a 306 method available to the user agent (typically, ISDN subscribers 307 send the address with the call setup signalling). If ISDN 308 subaddressing is not supported by the caller, 309 MUST be ignored and the user SHOULD be notified. The user or the 310 user agent MAY opt not to place a call if this feature is not 311 supported. 313 H. A fax number MAY also contain a , which 314 indicates the start of a T.33 subaddress [T.33]. User agents 315 SHOULD support this. Otherwise MUST be ignored 316 and the user SHOULD be notified. The user or the user agent MAY 317 opt not to place a call if this feature is not supported. 319 I. indicate the minimum compliance required from 320 the user agent to be able to connect to the remote entity. The 321 minimum compliance is defined as being equal to or a superset of 322 the capabilities of the listed modem type. 324 The user agent MUST call out using compatible hardware, or request 325 that the network provides such a service. 327 For example, if the user agent only has access to a V.22bis modem 328 and the URL indicates that the minimum acceptable connection is 329 V.32bis, the user agent MUST NOT try to connect to the remote host 330 since V.22bis is a subset of V.32bis. However, if the URL lists 331 V.32 as the minimum acceptable connection, the user agent can use 332 V.32bis to create a connection since V.32bis is a superset of 333 V.32. 335 This feature is present because modem pools often have separate 336 numbers for slow modems and fast modems, or have different numbers 337 for analog and ISDN connections, or may use proprietary modems 338 that are incompatible with standards. It is somewhat analogous to 340 A. Vaha-Sipila URLs for Telephone Calls June 1998 342 the connection type specifier (typecode) in FTP URLs [RFC1738]: it 343 provides the user agent with information that can not be deduced 344 from the scheme specifier, but is helpful for successful 345 operation. 347 This also means that the number of data and stop bits and parity 348 MUST be set according to the information given in the URL, or to 349 default values, if the information is not present. 351 The capability tokens are listed below. If capabilities 352 suggest that it is impossible to create a connection, the 353 connection MUST NOT be created. 355 If new modem types are standardized by ITU-T, this list can be 356 extended with those capability tokens. Tokens are formed by taking 357 the number of the standard and joining together the first letter 358 | (for example, "V"), number (for example, 22) and the first letter 359 | of the postfix (for example "bis" would become "b"). 361 | Proprietary modem types MUST be specified using the "vendor naming 362 | tree", which takes the form "vnd.x.y", in which "x" is the name of 363 | the entity from which the specifications for the modem type can be 364 | acquired and "y" is the type or model of the modem. Vendor names 365 | MUST share the same name space with vendor names used in MIME 366 | types [RFC2048]. Submitting the modem types to ietf-types list 367 | for review is strongly recommended. 369 | New capabilities MUST always be documented in an RFC. 371 Capability Explanation 373 V21 ITU-T V.21 374 V22 ITU-T V.22 375 V22b ITU-T V.22bis 376 V23 ITU-T V.23 377 V26t ITU-T V.26ter 378 V32 ITU-T V.32 379 V32b ITU-T V.32bis 380 V34 ITU-T V.34 381 V110 ITU-T V.110 382 V120 ITU-T V.120 383 X75 ITU-T X.75 384 B103 Bell 103 385 B212 Bell 212 386 Data bits: "8" or "7" The number of data bits. If not 387 specified, defaults to "8". 388 Parity: "n", "e", "o", Parity. None, even, odd, mark or 389 "m", "s" space parity, respectively. If 390 not specified, defaults to "n". 391 Stop bits: "1" or "2" The number of stop bits. If not 392 specified, defaults to "1". 394 2.6 Examples of Use 396 A. Vaha-Sipila URLs for Telephone Calls June 1998 398 | tel:+358-555-1234567 400 This URL instructs the user agent to place a voice call to the 401 specified number in Finland. The hyphens are included to make the 402 number more human-readable: country and area codes have been 403 separated from the subscriber number. 405 fax:+358.555.1234567 407 The above URL instructs the user agent to place a fax call to 408 the specified number. It uses dots instead of hyphens as 409 separators, but they have no effect on the functionality. 411 modem:+3585551234567;typev32b?7e1;typev110 413 This URL instructs the user agent to place a data call to the 414 specified number. The user agent may opt to use either a ITU-T 415 V.32bis modem (or a faster one, which is compatible with V.32bis), 416 using settings of 7 data bits, even parity and one stop bit, or an 417 ISDN connection using ITU-T V.110 protocol. 419 | tel:+358-555-1234567;postdpp22 421 The above URL instructs the user agent to place a voice call to 422 | +358-555-1234567, then wait for an implementation-dependent time 423 | (for example, two seconds) and emit two DTMF dialing 424 tones "2" on the line (for example, to choose a particular 425 extension number, or to invoke a particular service). 427 | tel:0w003585551234567 429 This URL places a voice call to the given number. The number 430 format is intended for local use: the first zero opens an 431 outside line, the "w" character waits for a second dial tone, 432 and the number already has the international access code 433 appended to it ("00"). This kind of phone number MUST NOT be 434 used in an environment where all users of this URL might not be 435 able to successfully dial out by using this number directly. 436 However, this might be appropriate for pages in a company 437 intranet. 439 2.7 The Choice of the Scheme Specifier 441 | There has been discussion on whether the scheme name "tel" is 442 | appropriate. To summarize, these are the points made against 443 | the other proposals. 445 | callto URL schemes locate a resource and do not specify 446 | an action to be taken. 447 | telephone Too long. Also, "tel" considered to be a more 448 | international form. 449 | phone Was countered on the basis that "tel" is more 450 | internationally acceptable. 452 A. Vaha-Sipila URLs for Telephone Calls June 1998 454 3. References 456 NOTE. References to Internet-Drafts will be removed from the final 457 document which will be submitted to the RFC-Editor. 459 [RFC2234] Augmented BNF for Syntax Specifications: ABNF. 460 November 1997. D. Crocker et al. RFC 2234. 461 463 [CONV-URL] Conversational Multimedia URLs. 1997. Pete Cordell. An 464 Internet-Draft (work in progress). 465 468 [RFC1738] Uniform Resource Locators (URL). December 1994. T. 469 Berners-Lee et al. RFC 1738. 470 472 [RFC2048] Multipurpose Internet Mail Extensions (MIME) Part Four: 473 Registration Procedures. November 1996. N. Freed et al. RFC 2048. 474 476 [RFC2119] Key Words for Use in RFCs to Indicate Requirement 477 Levels. March 1997. S. Bradner. RFC 2119. 478 480 [RFC2303] Minimal PSTN Address Format in Internet Mail. March 1998. 481 C. Allocchio. RFC 2303. 482 484 [RFC2304] Minimal FAX Address Format in Internet Mail. March 1998. 485 C. Allocchio. RFC 2304. 486 488 [E.123] ITU-T Recommendation E.123: Telephone Network and ISDN 489 Operation, Numbering, Routing and Mobile Service: Notation for 490 National and International Telephone Numbers. 1993. 492 [E.164] ITU-T Recommendation E.164: Telephone Network and ISDN 493 Operation, Numbering, Routing and Mobile Service: Numbering Plan 494 for the ISDN Era. 1991. 496 [T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing 497 the Subaddress. 1996. 499 4. Security Considerations 501 It should be noted that the user agent SHOULD NOT call out without 502 the knowledge of the user because of associated risks, which 503 include 505 - call costs (including long calls, long distance calls, 506 | international calls and premium rate calls) 507 - wrong numbers inserted on web pages by malicious users 509 A. Vaha-Sipila URLs for Telephone Calls June 1998 511 - making the user's phone line unavailable (off-hook) for a 512 malicious purpose 513 - opening a data call to a remote host, thus possibly opening a 514 back door to the user's computer 515 | - revealing the user's (possibly unlisted) phone number to the 516 | remote host in the caller identification data 518 All of these risks MUST be taken into consideration when 519 designing the user agent. 521 The user agent SHOULD have some mechanism that the user can use to 522 filter out unwanted numbers. The user agent SHOULD NOT use rapid 523 redialing of the number if it is busy to avoid the congestion of 524 the (signaling) network. Also, the user agent SHOULD detect if the 525 number is unavailable or if the call is terminated before the 526 dialing string has been completely processed (for example, the 527 call is terminated while waiting for user input) and not try to 528 call again, unless instructed by the user. 530 5. Authors' Addresses 532 Contact person and version control responsibility 533 for this specification: 535 Nokia Mobile Phones 536 Antti Vaha-Sipila 537 P. O. Box 68 538 FIN-33721 Tampere 539 Finland 541 Electronic mail: antti.vaha-sipila@nmp.nokia.com 543 Please include your name and electronic mail address in all 544 communications. If you want to receive the newest version of this 545 specification electronically, send mail to the address above. 547 This document expires on the 29th of December, 1998, or when a 548 new version is released. 550 A. Vaha-Sipila URLs for Telephone Calls June 1998