idnits 2.17.1 draft-ietf-fax-capability-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 15 longer pages, the longest (page 1) being 60 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. ** The abstract seems to contain references ([4], [5], [2,3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 May 1998) is 9492 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: '6' is defined on line 613, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2305 (ref. '1') (Obsoleted by RFC 3965) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 821 (ref. '11') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2251 (ref. '15') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2303 (ref. '16') (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2304 (ref. '17') (Obsoleted by RFC 3192) -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet fax WG Graham Klyne 3 Internet draft Integralis Technology Ltd. 4 1 May 1998 5 Expires: 1 November 1998 7 Scenarios for Internet fax capability exchange 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or made obsolete by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as ``work in 21 progress''. 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Copyright (C) 1998, The Internet Society 32 Abstract 34 The simple mode for Internet fax described in [1] relies on 35 transmission of documents using a minimum feature set to achieve 36 interoperability between sender and receiver. Proposals for 37 extended Internet fax [2,3] aim to provide for transmission of 38 enhanced documents (e.g. higher resolutions, colour) by employing 39 mechanisms to identify recipient capabilities to the sender, in the 40 same fashion as traditional Group 3 fax [4]. 42 This memo describes some of the scenarios for capability exchange 43 in Internet fax, taking account of the particular nature and goals 44 of the application [5], with a view to informing the debate over 45 what mechanisms should be used for this purpose. 47 Scenarios for Internet fax capability exchange 49 Table of contents 51 1. Introduction.............................................2 52 1.1 Terminology ..........................................3 53 1.2 Structure of this document ...........................3 54 1.3 Discussion of this document ..........................3 55 1.4 Amendment history ....................................4 56 1.5 Unfinished business ..................................4 57 2. Capability exchange issues in Internet fax...............4 58 3. Scenarios................................................5 59 3.1 User scenarios .......................................6 60 3.2 Deployment scenarios .................................7 61 3.3 Traditional facsimile scenarios ......................9 62 3.3.1 Summary of T.30 DIS frame........................9 63 3.3.2 Fax polling......................................9 64 4. Implementation notes.....................................10 65 4.1 Identification of capabilities .......................10 66 4.2 Denotation of capabilities ...........................10 67 4.3 Mechanisms for capability exchange ...................10 68 5. Security considerations..................................11 69 6. Copyright................................................12 70 7. Acknowledgements.........................................12 71 8. References...............................................12 72 9. Author's address.........................................15 74 1. Introduction 76 The simple mode for Internet fax described in [1] relies on 77 transmission of documents using a minimum feature set to achieve 78 interoperability between sender and receiver. Proposals for 79 extended Internet fax [2,3] aim to provide for transmission of 80 enhanced documents (e.g. higher resolutions, colour) by employing 81 mechanisms to identify recipient capabilities to the sender. 83 Traditional facsimile employs a system of capability 84 identification, built in to the underlying facsimile transmission 85 protocol [4], so that documents can be transmitted with quality 86 greater than is provided by the base format capability common to 87 all facsimile machines. 89 A number of suggestions have been made [7,9, and others not 90 formally published] to provide similar facilities for facsimile 91 data transmitted using Internet e-mail. But, because Internet 92 e-mail is quite different to traditional facsimile transmission 93 technologies, the mechanisms used must be different. 95 Scenarios for Internet fax capability exchange 97 This memo describes some of the scenarios for capability exchange 98 in Internet fax, taking account of the particular nature and goals 99 of the application [5], with a view to informing the debate about 100 what mechanisms should be used for this purpose. 102 1.1 Terminology 104 Terminology used in this document that is specific to Internet fax 105 is taken from [5]. 107 1.2 Structure of this document 109 The main part of this memo addresses the following areas: 111 Section 2 discusses some of the technical issues that make 112 provision of traditional facsimile capability identification 113 somewhat problematic in Internet e-mail, and contrasts the features 114 of traditional fax transport mechanisms with Internet e-mail that 115 make this so. 117 Section 3 describes some scenarios for capability exchange in 118 Internet fax, from the viewpoints of system users, deployment and 119 traditional facsimile service offerings. 121 Section 4 discusses some general concepts that might have a bearing 122 on how capability identification might be implemented for Internet 123 fax. 125 1.3 Discussion of this document 127 Discussion of this document should take place on the Internet fax 128 mailing list hosted by the Internet Mail Consortium (IMC): 130 Please send comments regarding this document to: 132 ietf-fax@imc.org 134 To subscribe to this list, send a message with the body 'subscribe' 135 to "ietf-fax-request@imc.org". 137 To see what has gone on before you subscribed, please see the 138 mailing list archive at: 140 http://www.imc.org/ietf-fax/ 142 To unsubscribe from the ietf-fax mailing list, send a message to 143 "ietf-fax-request@imc.org" containing the message 'unsubscribe'. 145 Scenarios for Internet fax capability exchange 147 1.4 Amendment history 149 00a 31-Mar-1998 150 Document initially created. 152 00b 01-May-1998 153 Minor updates based on feedback received. Update 154 references. Extended security considerations section. 156 1.5 Unfinished business 158 . Add new scenarios identified by ongoing debate and review. 160 . Complete the T.30 scenarios with input from T.30 experts. 162 2. Capability exchange issues in Internet fax 164 Technical differences between the Internet e-mail SMTP transport 165 [11] and the facsimile T.30 transmission protocol [4] that tend to 166 dictate different approaches to capability exchange are: 168 . SMTP is a store-and-forward protocol, which means that the sender 169 of a message is generally disengaged from the message transfer 170 process at the time final delivery is accomplished. T.30, on the 171 other hand, is a session mode protocol in which the transmitter 172 of a message is directly involved in the process until final 173 delivery is accomplished and signalled back to the sender. 175 (There is a proposal to provide a session mode capability in SMTP 176 [10], but in its present form even this may be forced to fall 177 back to store-and-forward mode in some circumstances.) 179 Because SMTP is a store-and-forward protocol, there may be 180 arbitrary delays in the transfer of a message 182 . Being a store-and-forward Internet protocol, SMTP can service 183 occasionally connected correspondents; thus there is no 184 requirement or expectation for the ultimate recipient to be 185 accessible at the time a message is sent. Traditional facsimile, 186 on the other hand, relies on the fact that telephone devices are 187 always physically connected to the network and available to 188 receive calls (except when they are busy). 190 A related consideration is that SMTP senders do not have to be 191 concerned with the possibility that the recipient is busy at the 192 time a message is sent. But the next-hop MTA may be unavailable 193 for a variety of reasons, so some system of retries is required. 195 Scenarios for Internet fax capability exchange 197 . In T.30, the sender of a message connects directly to and 198 interacts with the receiver. Using SMTP, this is not generally 199 the case and an indeterminate number of intermediate relays 200 (MTAs) may be involved in the transmission process. The 201 capabilities of these intermediate systems is not generally known 202 or knowable. 204 . T.30 is a binary protocol; i.e. protocol elements and data are 205 represented as arbitrary bit streams. SMTP on the other hand is 206 a text-based protocol, and all protocol elements and data must be 207 represented in a stream of US-ASCII text; this imposes 208 restrictions on the way that protocol elements are coded. 210 (Similar restrictions also apply to the data in SMTP, but these 211 restrictions are generally made transparent through the use of 212 MIME transfer encoding of message data.) 214 . In general, there are significant per-message call setup and 215 volume-related transmission costs associated with traditional 216 facsimile. When using SMTP, there are generally no per-message 217 or volume-related transmission costs. (This is a simplification, 218 and there are exceptions in both cases, but holds widely enough 219 to be a good working model.) 221 . Traditional facsimile calls are placed using a dedicated physical 222 connection, and while that connection is in use for one message 223 transfer it cannot be used for any other purpose. SMTP message 224 transfers can share a physical connection between several 225 different activities. 227 This has implications for possible concurrent use of multiple 228 services or capability acquisition mechanisms. 230 3. Scenarios 232 In this section, scenarios are presented from three different 233 perspectives: 235 . User scenarios: capability identification scenarios based on the 236 resulting message transfer behaviour that would be visible to a 237 user of the system. 239 . Deployment scenarios: based on the effect that capability 240 identification has on the way that messages flow through the 241 network infrastructure. 243 Scenarios for Internet fax capability exchange 245 . Traditional facsimile scenarios: based on capability exchange 246 behaviours which have come to be associated with Group 3 247 facsimile. This section examines various commonly-used 248 capability identification mechanisms present in T.30 [4] and 249 considers their applicability to the Internet e-mail environment. 251 In all cases, the goal is to provide interoperability between 252 sender and receiver of a message; i.e. to achieve a message 253 transfer which can be processed by the recipient, or to advise the 254 sender that a desired transfer is not possible. 256 3.1 User scenarios 258 These scenarios focus on issues of presentation quality, as 259 evidenced by media features and a recipient's capability to handle 260 them. Many of the scenarios may extend to non-media capabilities 261 (e.g. encryption, language). 263 . Sender wishes to send a simple low-resolution monochrome image, 264 per "simple mode" [1]. This should always be sent regardless of 265 any capability exchange mechanisms available or employed. 267 . Sender wishes to send a high-resolution monochrome image, but the 268 information content would still be useful if sent at a lower 269 resolution. No capability information about the receiving system 270 is known or available. The sender has two options: (a) send the 271 image at reduced quality only, or (b) send a multipart/alternate 272 containing full quality and reduced quality [12]. 274 . Sender wishes to send a high-resolution monochrome image, but the 275 information content would still be useful if sent at a lower 276 resolution. Capability information of dubious reliability about 277 the receiving system available, suggesting that the recipient can 278 handle the full quality. The sender's options are the same as 279 above, but there is greater reason to send both formats. Sending 280 the high-quality image only is probably not a good idea (see 281 security considerations). 283 . Sender wishes to send a high-resolution monochrome image. 284 Available and trusted capability information indicates that the 285 receiving system is known or available to handle this format. 286 The image can be sent at full quality only. 288 . Sender has a high quality colour image (e.g. promotional 289 literature) which needs to be sent at full quality to be of any 290 use. 292 In the absence of any capability information, the sender may 293 either (a) send the message and hope, or (b) take steps to 294 acquire the receiver's capabilities. 296 Scenarios for Internet fax capability exchange 298 Having capability information of dubious reliability indicating 299 that the recipient can handle the image, the same options are 300 available but there is probably greater reason to send the image 301 straight away. 303 Having capability information of dubious reliability which 304 indicates that the recipient cannot handle the image, the sender 305 might follow either of the options suggested above, but possibly 306 with greater preference for acquiring capabilities before sending 307 the message. Alternatively, he might give up and not send the 308 message at all (probably not a good idea). 310 . Sender has an original document in different formats each 311 requiring a different set of enhanced recipient capabilities for 312 optimum display. One of the formats would also provide usable 313 information to a recipient with minimum capabilities, per [1], 314 but the other would provide optimum display for a recipient with 315 the required capabilities. Depending upon available capability 316 information the sender has options to send (a) the best format, 317 (b) the not-so-good format which will display with minimum 318 capabilities, (c) both formats. 320 In all the above cases, the sender's choice may be modified by the 321 cost of transmitting the message, which in turn will depend upon 322 the size of the various possible message formats and the ultimate 323 destination. For example, he may decline to send a multi-Megabyte 324 presentation graphic which would incur international offramp 325 charges without knowing that the recipient could process that data. 327 3.2 Deployment scenarios 329 This section discusses deployment scenarios, which have a bearing 330 on the kind of negotiation or capability identification mechanisms 331 that could prove useful. 333 . Corporate mail and Internet fax server with access to corporate 334 address book and fax offramp systems. Such a system might 335 conduct authoritative capability identification on behalf of the 336 users in its address book, with the idea that messages for users 337 that might be delivered by e-mail or fax transmission can be 338 handled. 340 . A combination of SMTP session mode and capability identification 341 extensions [9, 10] could provide a capability identification 342 mechanism that operates via the Internet to provide G3 fax like 343 negotiation. 345 In this scenario, security concerns about privacy and accuracy of 346 information are heightened, and these would need be addressed in 347 some way. 349 Scenarios for Internet fax capability exchange 351 . Capabilities can be sent with message disposition notification 352 (per [7]). Some form of capability information would be available 353 after a message had been sent to a given destination, but might 354 become stale if messages are sent infrequently to that recipient. 356 This has associated security concerns. Addressing the security 357 concerns discussed in [7] will go some way to addressing these. 359 . Capabilities can be sent with outgoing messages (e.g. per 360 [13,14]), to be used in any return message. These, too, can 361 become stale. Also, for communication between send-only and 362 receive-only systems, the capability information is of little use 363 (unless the receiving system can lodge it in some common area for 364 use by related sending systems). 366 . Capabilities might be cached on an MTA server which is close to 367 the recipient of a message and which can be made readily and 368 immediately available to sending parties. (Information held 369 closer to the receiving system is likely to be more reliable than 370 more remote information.) 372 . Multiple copies (multipart/alternate) could be sent to an 373 intervening MTA, which could then conduct negotiation on the 374 sender's behalf to select the best version to deliver. 376 . Format-converting gateways might be used to accept a variety of 377 formats which the receiver does not recognize. Declared receiver 378 capabilities would also include conversion capabilities of the 379 gateway. This may introduce secondary security concerns if 380 message integrity/authentication mechanisms are being employed. 382 . Capability identification can be used for Internet-to-Internet, 383 Internet-to-GSTN (via an offramp gateway) and GSTN-to-Internet 384 (via an onramp gateway). In the onramp/offramp cases, capability 385 information would relate to the gateway's ability to accept data 386 and pass it on in a form usable by the ultimate addressee, rather 387 than necessarily indicating the addressee's capabilities. 389 . Hunt groups: a given recipient address (phine number, etc.) may 390 connect to any of several receiving systems in a "hunt group". 391 If different systems in the group have different capabilities, a 392 possibility exists for capability identification information from 393 one exchange to cause a sending system to send unusable data in a 394 subsequent message transmission. 396 Scenarios for Internet fax capability exchange 398 3.3 Traditional facsimile scenarios 400 3.3.1 Summary of T.30 DIS frame 402 The following paraphrases an analysis of bits in the T.30 DIS frame 403 with a view to their relevance to capability identification, which 404 was posted to the IETF-FAX discussion list: 406 . The DIS bits up to about bit 45 are mainly concerned with 407 resolution, compression, width and size capabilities etc. Things 408 like transmission speed and scan line time capabilities are not 409 relevant in a store and forward environment, but would be dealt 410 with by the off-ramp transmitter. 412 Special image characteristics of the receiver cannot be so dealt 413 with and are best known in advance via negotiations. 415 Thus, DIS 1-45 are covered by [20], or are irrelevant to Internet 416 fax capability identification. 418 . Bits 47-64 deal with polling, sub-addressing, password, non-image 419 data (including BFT) and alternative negotiation methods. 421 Polling is discussed in a separate section below. 423 Sub-addressing can be handled by conversion to the format 424 described in [16,17] at the onramp and offramp gateways. 426 Non-image transfer is logically handled by MIME encapsulation 427 [18,12], though there are some issues about mapping Object Ids 428 (used by the Group 3 fax binary file envelope T.434 [19] 430 Security presents some real problems because of the impossibility 431 of passing a secured message through a gateway (which by the 432 nature of T.30 and SMTP must convert the data content in some 433 way) without possessing the relevant security keys. 435 [[Identify T.30 capability/negotiation options in greater detail, 436 and relevance to Internet fax operations]] 438 3.3.2 Fax polling 440 Polling raises the following issues: 442 (a) identifying whether or not polling is available (or, strictly 443 following the Group 3 facsimile model, to determine if data is 444 available to be polled), 446 (b) content selection for polled data, and 448 Scenarios for Internet fax capability exchange 450 (c) whether or not polling is required and appropriate in the 451 context of Internet fax (given the alternate methods 452 available), and the mechanisms appropriate for performing 453 polling. 455 It has been noted that although polling is commonly performed with 456 Group 3 facsimile, it is often used for special applications and 457 performed using special purpose features rather than the standard 458 T.30 facilities for this purpose. 460 4. Implementation notes 462 To define a deployable system for capability exchange in Internet 463 fax, the following issues must be addressed: 465 4.1 Identification of capabilities 467 The specific capabilities which can be exchanged must be identified 468 (or at least, some initial set). 470 The Group 3 facsimile protocol, T.30 [4], defines a number of such 471 capabilities, identified by bits in the DIS frame and in other 472 protocol frames. 474 A number of features related to media type and capability are 475 identified in [20]. This document has, by design, a high degree of 476 overlap with media features identified by T.30. 478 It may be desirable to also provide some higher-level 479 identification of capabilities, such as general support for 480 Internet fax. 482 4.2 Denotation of capabilities 484 A way to represent capabilities carried within the SMTP protocol 485 must be defined. The limitations of SMTP suggest that a textual 486 format should be used (as opposed to the binary formats used for 487 T.30). 489 4.3 Mechanisms for capability exchange 491 Mechanisms for capability exchange (i.e. carrying capability 492 information between correspondents) fall into two broad categories: 494 . Connected, using some form of direct client/server enquiry 495 protocol (e.g. LDAP [15], T.30 frames [4], SMTP capabilities 496 [9]). 498 Scenarios for Internet fax capability exchange 500 . Disconnected, carried by SMTP as message data (e.g. MDN 501 extensions [7], vCard with message [13,14]). 503 This does not address the ever-present possibility of using any 504 kind of out-of-band mechanism to supply information about a 505 recipient to the sending agent (e.g. user input). 507 5. Security considerations 509 The following are primary security concerns for capability exchange 510 mechanisms: 512 . Unintentional disclosure of private information through the 513 announcement of capabilities or user preferences. 515 . Disruption to system operation caused by accidental or malicious 516 provision of incorrect capability information. 518 . Use of a capability identification mechanism might be used to 519 probe a network (e.g. by identifying specific hosts used, and 520 exploiting their known weaknesses). 522 Security considerations relevant to Internet fax are discussed 523 further in [1,5]. 525 The most contentious security concerns are raised by mechanisms 526 which automatically send capability identification data in response 527 to a query from some unknown system. Use of directory services 528 (based on LDAP [15], etc.) seem to be less problematic because 529 proper authentication mechanisms are available. 531 Mechanisms which provide capability information when sending a 532 message are less contentious, presumably because some intention on 533 the part of the person whose details are disclosed to communicfate 534 with the recipient of those details can be inferred. This does 535 not, however, address spoofed supply of incorrect capability 536 information. 538 The use of format converting gateways may prove probelmatic because 539 such systems would tend to defeat any message integraty and 540 authenticity checking mechanisms that are employed. 542 Scenarios for Internet fax capability exchange 544 6. Copyright 546 Copyright (C) The Internet Society 1998. All Rights Reserved. 548 This document and translations of it may be copied and furnished to 549 others, and derivative works that comment on or otherwise explain 550 it or assist in its implementation may be prepared, copied, 551 published and distributed, in whole or in part, without restriction 552 of any kind, provided that the above copyright notice and this 553 paragraph are included on all such copies and derivative works. 554 However, this document itself may not be modified in any way, such 555 as by removing the copyright notice or references to the Internet 556 Society or other Internet organizations, except as needed for the 557 purpose of developing Internet standards in which case the 558 procedures for copyrights defined in the Internet Standards process 559 must be followed, or as required to translate it into languages 560 other than English. 562 The limited permissions granted above are perpetual and will not be 563 revoked by the Internet Society or its successors or assigns. 565 This document and the information contained herein is provided on 566 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 567 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 568 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 569 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 570 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 572 7. Acknowledgements 574 The ideas in this document came from a meeting with particular 575 contributions from James Rafferty, Larry Masinter, Richard Shockey. 577 Further ideas have been taken from postings to the IETF-FAX mailing 578 list. 580 8. References 582 [1] "A Simple Mode of Facsimile Using Internet Mail" 583 K. Toyoda, 584 H. Ohno 585 J. Murai, WIDE Project 586 D. Wing, Cisco 587 RFC 2305 588 March 1998 590 Scenarios for Internet fax capability exchange 592 [2] "Extended Facsimile Using Internet Mail" 593 Larry Masinter, Xerox Corporation 594 Dan Wing, Cisco Systems 595 Internet draft: 596 Work in progress, March 1998 598 [3] "Procedures for the Transfer of Facsimile Data via Internet Mail" 599 D. Crocker, Internet Mail Consortium 600 Internet draft: 601 Work in progress, October 1997 603 [4] ITU Recommendation T.30: 604 "Procedures for document facsimile transmission in the General 605 Switched Telephone Network" 606 International Telecommunications Union, 1996 608 [5] "Terminology and Goals for Internet Fax" 609 Larry Masinter, Xerox Corporation 610 Internet draft: 611 Work in progress, March 1998 613 [6] "Extensions to Delivery Status Notifications for Fax" 614 Dan Wing, Cisco Systems 615 Internet draft: 616 Work in progress, November 1997. 618 [7] "Using Message Disposition Notifications to Indicate Supported 619 Features" 620 Dan Wing, Cisco Systems 621 Internet draft: 622 Work in progress, March 1998 624 [8] "Operational Guidelines for Fax over SMTP" 625 Larry Masinter, Xerox Corporation 626 Dan Wing, Cisco Systems 627 Internet draft: 628 Work in progress, March 1998 630 [9] "SMTP Service Extension for Capabilities Exchange" 631 Dan Wing, 632 Neil Joffe, Cisco Systems 633 Internet draft: 634 Work in progress, November 1997 636 [10] "SMTP Service Extension for Immediate Delivery" 637 Dan Wing, 638 Neil Joffe, Cisco Systems 639 Larry Masinter, Xerox Corporation 640 Internet draft: 641 Work in progress, February 1998 643 Scenarios for Internet fax capability exchange 645 [11] RFC 821, "Simple Mail Transfer Protocol" 646 J. Postel, Information Sciences Institute, University of Southern 647 California 648 August 1982. 650 [12] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) 651 Part 2: Media types" 652 N. Freed, Innosoft 653 N. Borenstein, First Virtual 654 November 1996. 656 [13] vCard - The Electronic Business Card Version 2.1 657 Internet Mail Consortium 658 URL: 659 September 1996. 661 [14] vCard MIME Directory Profile 662 Frank Dawson, Lotus Development Corporation 663 Tim Howes, Netscape Communications 664 Internet draft 665 Work in progress: April 1998. 667 [15] RFC 2251, "Lightweight Directory Access Protocol (v3)" 668 M. Wahl, Critical Angle Inc. 669 T. Howes, Netscape Communications Corp. 670 S. Kille, Isode Limited 671 December 1997. 673 [16] RFC 2303, "Minimal PSTN address format in Internet Mail" 674 C. Allocchio, GARR-Italy 675 March 1998. 677 [17] RFC 2304, "Minimal FAX address format in Internet Mail" 678 C. Allocchio, GARR-Italy 679 March 1998. 681 [18] RFC 2045, "Multipurpose Internet Mail Extensions (MIME) 682 Part 1: Format of Internet message bodies" 683 N. Freed, Innosoft 684 N. Borenstein, First Virtual 685 November 1996. 687 [19] ITU-T Recommendation T.434, 688 "Binary file transfer format for the telematic services" 689 International Telecommunications Union 690 July 1996 692 Scenarios for Internet fax capability exchange 694 [20] "Media Features for Display, Print, and Fax" 695 Larry Masinter, Xerox Corporation 696 Koen Holtman, TUE 697 Andy Mutz, Hewlett Packard 698 Dan Wing, Cisco Systems 699 Internet draft: 700 Work in progress, March 1998 702 9. Author's address 704 Graham Klyne 705 Content Technologies Ltd 706 Forum 1 707 Station Road 708 Theale 709 Reading, RG7 4RA 710 United Kingdom 712 Telephone: +44 118 930 1300 714 Facsimile: +44 118 930 1301 716 E-mail: GK@ACM.ORG