IETF fax WG G. Klyne (editor), Content Technologies Internet draft R. Iwazaki, Toshiba TEC D. Crocker, Brandenburg Consulting 14 July 2000 Expires: December 2000 Content Negotiation for Internet Messaging Services Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet e-mail. Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet e-mail. Klyne, Iwazaki, Crocker Internet draft [Page 1] Content Negotiation for Internet Fax 14 July 2000 Table of contents 1. Introduction.............................................3 1.1 Structure of this document ...........................4 1.2 Document terminology and conventions .................4 1.2.1 Terminology......................................4 1.2.2 Design goals.....................................5 1.2.3 Other document conventions.......................5 1.3 Discussion of this document ..........................5 2. Background and goals.....................................6 2.1 Background ...........................................6 2.1.1 Fax and e-mail...................................6 2.1.2 Current facilities in Internet Fax...............6 2.2 Closing the loop .....................................7 2.3 Goals for content negotiation ........................8 3. Framework for content negotiation........................10 3.1 Send data with an indication of alternatives .........11 3.1.1 Choice of default data format....................12 3.1.2 MDN request indicating alternate data formats....12 3.1.3 Information about alternative data formats.......13 3.2 Receiver options .....................................14 3.2.1 Alternatives not recognized......................15 3.2.2 Alternative not desired..........................15 3.2.3 Alternative preferred............................15 3.3 Send alternative message data ........................16 3.4 Implementation issues ................................17 3.4.1 Receiver state...................................17 3.4.2 Receiver buffering of message data...............19 3.4.x Other issues.....................................19 4. The Content-alternative header...........................20 5. MDN extension for alternative data.......................20 5.1 Indicating readiness to send alternative data ........21 5.2 Indicating a preference for alternative data .........22 6. Internet Fax Considerations..............................23 7. Examples.................................................23 7.1 Sending enhanced Internet Fax image ..................23 7.2 Internet fax with initial data usable ................26 7.3 Other example??? .....................................28 8. IANA Considerations......................................28 9. Internationalization considerations......................28 10. Security considerations.................................28 11. Acknowledgements........................................28 12. References..............................................29 13. Authors' addresses......................................31 Appendix A: Amendment history...............................32 Full copyright statement....................................34 Klyne, Iwazaki, Crocker Internet draft [Page 2] Content Negotiation for Internet Fax 14 July 2000 1. Introduction This memo describes a mechanism for e-mail based content negotiation to provide an Internet fax facility comparable to that of traditional facsimile, which may be used by other messaging services that need similar facilities. "Extended Facsimile using Internet Mail" [1] specifies the transfer of image data using Internet e-mail protocols. "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] describes a mechanism for providing the sender with details of a receiver's capabilities. The capability information thus provided, if stored by the sender, can be used in subsequent transfers between the same sender and receiver. Many communications are one-off or infrequent transfers between a given sender and receiver, and cannot benefit from this "do better next time" approach. An alternative facility available in e-mail (though not widely implemented) is for the sender to use 'multipart/alternative' [15] to send a message in several different formats, and allow the receiver to choose. Apart from the obvious drawback of network bandwidth use, this approach does not of itself allow the sender to truly tailor its message to a given receiver, or to obtain confirmation that any of the alternatives sent was usable by the receiver. This memo describes a mechanism that allows better-than-baseline data formats to be sent in the first communication between a sender and receiver. The same mechanism can also achieve a usable message transfer when the sender has stored incorrect information about the receiver's capabilities. It allows the sender of a message to indicate availability of alternative formats, and the receiver to indicate that an alternative format should be provided to replacing the message data originally transmitted. When the sender does not have correct information about a receiver's capabilities, the mechanism described here may incur an additional message round trip. An important goal of this mechanism is to allow enough information to be provided to determine whether or not the extra round trip is required. Klyne, Iwazaki, Crocker Internet draft [Page 3] Content Negotiation for Internet Fax 14 July 2000 1.1 Structure of this document The main part of this memo addresses the following areas: Section 2 describes some of the background, and sets out some specific goals that are addressed this specification. Section 3 describes the proposed content negotiation framework, indicating the flow of information between a sender and receiver. Section 4 contains a detailed description of the 'Content- alternative' header that is used to convey information about alternative available formats. This description is intended to stand independently of the rest of this specification, with a view to being usable conjunction with other content negotiation protocols. This may be moved to a separate document. Section 5 describes extensions to the Message Disposition Notification (MDN) framework [4] that are used to allow negotiation between the communicating parties. 1.2 Document terminology and conventions 1.2.1 Terminology Capability exchange An exchange of information between communicating parties indicating the kinds of information they can generate or consume. Capability identification Provision of information by the a receiving agent that indicates the kinds of message data that it can accept for presentation to a user. Content negotiation An exchange of information (negotiation metadata) which leads to selection of the appropriate representation (variant) when transferring a data resource.Content negotiation [[[Others?]]] RFC 2703 [17] introduces several other terms related to content negotiation. Klyne, Iwazaki, Crocker Internet draft [Page 4] Content Negotiation for Internet Fax 14 July 2000 1.2.2 Design goals In discussing the goals for content negotiation, {1}, {2}, {3} notation is used, per RFC 2542, "Terminology and Goals for Internet Fax" [3]. The meanings associated with these notations are: {1} there is general agreement that this is a critical characteristic of any definition of content negotiation for Internet Fax. {2} most believe that this is an important characteristic of content negotiation for Internet Fax. {3} there is general belief that this is a useful feature of content negotiation for Internet Fax, but that other factors might override; a definition that does not provide this element is acceptable. 1.2.3 Other document conventions NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth. [[[Editorial comments and questions about outstanding issues are provided in triple brackets like this. These working comments should be resolved and removed prior to final publication.]]] 1.3 Discussion of this document Discussion of this document should take place on the Internet fax mailing list hosted by the Internet Mail Consortium (IMC). Please send comments regarding this document to: ietf-fax@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org". To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-fax/ Klyne, Iwazaki, Crocker Internet draft [Page 5] Content Negotiation for Internet Fax 14 July 2000 2. Background and goals 2.1 Background 2.1.1 Fax and e-mail One of the goals of the work to define a facsimile service using Internet mail has been to deliver benefits of the traditional Group 3 Fax service in an e-mail environment. Traditional Group 3 Fax leans heavily on the idea that an online exchange of information discloses a receiver's capabilities to the sender before any message data is transmitted. By contrast, Internet mail has been developed to operate in a different fashion, without any expectation that the sender and receiver will exchange information prior to message transfer. One consequence of this is that all mail messages must contain some kind of meaningful message data: messages that are sent simply to elicit information from a receiving message handling agent are not generally acceptable in the Internet mail environment. To guarantee some level of interoperability, Group 3 Fax and Internet mail rely on all receivers being able to deal with some baseline format (i.e. a basic image format or plain ASCII text, respectively). The role of capability exchange or content negotation is to permit better-than baseline capabilities to be employed where available. One of challenges addressed by this specification is how to adapt the e-mail environment to provide a fax-like service. A sender must not make any a priori assumption that the receiver can recognize anything other than a simple e-mail message. There are some important uses of e-mail that are fundamentally incompatible with the fax model of message passing and content negotiation (notably mailing lists). So we need to have a way of recognizing when content negotiation is possible, without breaking the existing e-mail model. 2.1.2 Current facilities in Internet Fax "Extended Facsimile using Internet Mail" [1] provides for limited provision of receiver capability information to the sender of a message, using an extension to Message Disposition Notifications [2,4], employing media feature tags [5] and media feature expressions [6]. This mechanism provides for receiver capabilities to be disclosed after a message has been received and processed. This information can be used for subsequent transmissions to the same receiver. But Klyne, Iwazaki, Crocker Internet draft [Page 6] Content Negotiation for Internet Fax 14 July 2000 many communications are one-off messages from a given sender to a given receiver, and cannot benefit from this. 2.2 Closing the loop Classic Internet mail is an "open loop" process: no information is returned back to the point from which the message is sent. This has been unkindly --but accurately-- characterized as "send and pray", since it lacks confirmation. Sending a message and obtaining confirmation that the message has been received is a "closed loop" process: the confirmation sent back to the sender creates a loop around which information is passed. Many Internet e-mail agents are not designed to participate in a closed loop process, and thus have no responsibility to respond to receipt of a message. Later additions to Internet standards, notably Delivery Service Notification [18] and Message Disposition Notification [4], specify means for certain confirmation responses to be sent back to the sender, thereby closing the loop. However conformance to these enhancements is optional and full deployment is in the future. DSN must be fully implemented by the entire infrastructure; further when support is lacking, the message is still sent on in open-loop fashion. Sometimes, transmission and delivery should, instead, be aborted and the fact be reported to the sender. Due to privacy considerations for end-users, MDN usage is entirely voluntary. Content negotiation is a closed loop function (for the purposes of this proposal -- see section 2.3, item (f)), and requires that the recipient of a message makes some response to the sender. Since content negotiation must retro-fit a closed-loop function over Internet mail's voluntary and high-latency environment, a challenge for content negotiation in e-mail is to establish that consenting parties can recognize a closed loop situation, and hence their responsibilities to close the loop. Klyne, Iwazaki, Crocker Internet draft [Page 7] Content Negotiation for Internet Fax 14 July 2000 Three different loops can be identified in a content negotiation: Sender Receiver | | Initial message ------>------------ v | | (1) ------------<--- Request alternative data | | Send alternative ------>------------ (2) | | (3) ------------<------ Confirm receipt of usable data (1) Sender receives acknowledgement that negotiable content has been received (2) Receiver receives confirmation that its request for data has been received. (3) Sender receives confirmation that received data is processable, or has been processed. Although the content negotiation process is initiated by the sender, it is not established until loop (1) is closed with an indication that the receiver desires alternative content. If content sent with the original message from the sender is processable by the receiver, and a confirmation is sent, then the entire process is reduced to a simple send/confirm loop: Sender Receiver | | Initial message ------>------------ v | | (3) ------------<------ Confirm receipt of usable data 2.3 Goals for content negotiation The primary goal {1} is to provide a mechanism that allows arbitrary enhanced content features to be used with Internet fax systems. The mechanism should {2} support introduction of new features over time, particularly those that are adopted for Group 3 fax. Klyne, Iwazaki, Crocker Internet draft [Page 8] Content Negotiation for Internet Fax 14 July 2000 Further goals are: (a) Must {1} interwork with existing simple mode Internet fax systems. (b) Must {1} interwork with existing e-mail clients. The term "interwork" used above means that the mechansism must be introduced in a way that may be ignored by existing systems, and systems enhanced to use the negotiation mechanisms will behave in a fashion that is expected by existing systems. (I.e. existing clients are not expected in any way to participate in or be aware of content negotiation.) (c) Must {1} avoid transmission of "administrative non messages". (I.e. only messages that contain meaningful content for the end user may be sent unless it is known that the receiving system will interpret them, and not attempt to display them.) This requirement has been stated very strongly by the e-mail community. This means that a sender must not assume that a receiver can understand the capability exchange protocol elements, so must always start by sending some meaningful message data. (d) Avoid {1} multiple renderings of a message. In situations where multiple versions of a message are transferred, the receiver must be able to reliably decide a single version to be displayed. (e) Minimize {2} round trips needed to complete a transmission. Ideally {3} every enhanced trasmission will result in simply sending data that the recipient can process, and receiving a confirmation response. (f) The solution adopted should not {3} transmit multiple versions of the same data. In particular, it must not {1} rely on routinely sending multiple instances of the same data in a single message. This does not prohibit sending multiple versions of the same data, but it must not be a requirement to do so. A sender may choose to send multiple versions together (e.g. TIFF-S and some other format), but the capability exchange mechanism selected must not depend on such behaviour. (g) The solution adopted should {2} be consistemt with and applicable to other Internet e-mail based applications; e.g. regular e-mail, voice messaging, unified messaging, etc. Klyne, Iwazaki, Crocker Internet draft [Page 9] Content Negotiation for Internet Fax 14 July 2000 (h) Graceful recovery from stale cache information. A sender might use historic information to send non-baseline data with an initial message. If this turns out to be unusable by the recipient, it should still be possible {3} for the baseline data, or some other acceptable format, to be selected and transferred. (i) The mechanism defined should {2} operate cleanly in conjunction with the mechanisms already defined for extended mode Internet fax (extended DSN and MDN [2], etc.). (j) As far as possible, existing e-mail mechanisms should {3} be used rather than inventing new ones. (It is clear that some new mechanisms will be needed, but they should be defined cautiously.) (k) The mechanism should {2} be implementable in low memory devices. That is, it should not depend on any party being able to buffer arbitrary amounts of message data. (It may be not possible to completely satisfy this goal in a sending system. But if the sender does not have enough memory to buffer some given message, it can choose to not offer content negotiation.) 3. Framework for content negotiation This section starts with an outline of the negotiation process, and provides greater detail about each stage in following sub-sections. 1. Sender sends initial message data with an indication of alternative formats available (section 3.1). Initial data may be a baseline or other best guess of what the recipient can handle. 2. The receiver has three main options: (a) Does not recognize the optional alternative formats, and passively accepts the data as sent (section 3.2.1). (b) Does recognize the alternatives offered, and actively accepts the data as sent (section 3.2.2). (c) Recognizes the alternatives offered, and determines that it prefers to receive an alternative format. An MDN response is sent (i) indicating that the original data was not processed, and (ii) containing receiver capability information so that the sender may select a suitable alternative (section 3.2.3). Klyne, Iwazaki, Crocker Internet draft [Page 10] Content Negotiation for Internet Fax 14 July 2000 3. On receipt of an MDN response indicating preference for an alternative data format, the sender MUST select and transmit message data matched to the receiver's declared capabilities, or send an indication that the receiver's request cannot be honoured. When sending alternative data, the sender suppresses the indication that alternative data is available, so the negotiation process cannot loop. NOTE: the receiver does not choose the particular data format to be received; that choice rests with the sender. We find that this approach is simpler than having the receiver choose an alternative, because it builds upon existing mechanisms in e-mail, and follows the same pattern as traditional Group 3 fax. Further, it deals with situations where the range of alternatives may be difficult to describe. This approach is similar to server driven negotiation in HTTP using "Accept" headers [13]. This is distinct to the agent-driven style of negotiation provided for HTTP as part of Transparent Content Negotiation [14], or which might be constructed in e-mail using "multipart/alternative" and "message/external-body" MIME types [15]. [[[?Require use of Original-recipient header. Only receivers that match this may request alternative data formats. This reinforces the 1:1 nature of a negotiation transaction? (This is spec.ed for gateways and may be inappropriate here.)]]] [[[?Consider whether to handle case of forwarded message?]]] [[[?To ensure consistency of results, require content-id with body part to which alternative capabilities are attached, to be noted in MDN response?]]] 3.1 Send data with an indication of alternatives A sender that is prepared to provide alternative message data formats sends: (a) a default message data format, (b) message identification, in the form of a Message-ID header. (c) appropriate 'Content-features' header(s) [7] describing the default message data sent, (d) a request for Message Disposition Notification [4], Klyne, Iwazaki, Crocker Internet draft [Page 11] Content Negotiation for Internet Fax 14 July 2000 (e) an indication that it is prepared to send different message data, using an 'Alternative-available' MDN option field [9], and (f) an indication of the alternative data formats available, in the form of 'Content-alternative' header(s) [8]. NOTE: more than one Content-alternative' header may be specified; see section 3.1.3 for more information. Having indicated the availability of alternative data formats, the sender will presumably hold the necessary information for some time, to allow the receiver an opportunity to request such data. But the sender is not expected to hold this information indefinitely; the exact length of time such information should be held is not specified here. Thus, the possibility exists that a request for alternative information may arrive too late, and the sender will then send an indication that the data is no longer avalable. If message transfer is being completed within a predetermined time interval (e.g. using [21]), then the sender should normally maintain the data for at least that period. [[[Use feature expression parameter to indicate TTL? Or use parameter on MDN request?]]] 3.1.1 Choice of default data format Choice of the default format sent is essentially the same as that available to a simple mode Internet Fax sender, per RFC 2305 [12]. This essentially requires that TIFF Profile S [11] be sent unless the sender has prior knowledge of other TIFF fields or values supported by the recipient. "Extended Facsimile Using Internet Mail" [1] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] indicate a possible mechanism for a sender to have prior knowledge of receiver capabilities. This specification builds upon the mechanism described there. As always, the sender may gather information about the receiver in other ways beyond the scope of this document (e.g. a directory service or the suggested RESCAP protocol). 3.1.2 MDN request indicating alternate data formats When a sender is indicating preparedness to send alternative message data, it must request a Message Disposition Notification (MDN) [4]. Klyne, Iwazaki, Crocker Internet draft [Page 12] Content Negotiation for Internet Fax 14 July 2000 It indicates its readiness to send alternative message data by including the MDN option 'Alternative-available' [9] with the MDN request. Presence of this MDN request option simply indicates that the sender is prepared to send some different data format if it has more accurate or up-to-date information about the receiver's capabilities. Of itself, this option does not indicate whether the alternatives are likely to be better or worse than the default data sent -- that information is provided by the "Content-alternative" header(s) [8]. When using the 'Alternative-available' option in an MDN request, the message MUST also contain a 'Message-ID:' header with a unique message identifier. 3.1.3 Information about alternative data formats A sender can provide information about the alternative message data available by applying one or more 'Content-alternative' headers to message body parts for which alternative data is available, each indicating media features [5,6] of an available alternative. The purpose of this information to allow a receiver to decide whether any of the available alternatives are preferable, or likely to be preferable, to the default message data provided. Not every available alternative is required to be described in this way, but the sender should include enough information to allow a receiver to determine whether or not it can expect more useful message data if it chooses to indicate a preference for some alternative that matches its capabilities. NOTE: the sender is not necessarily expected to describe every single alternative format that is avalable -- indeed, in cases where content is generated on-the-fly rather than simply selected from an enumeration of possibilities, this may be infeasible. The sender is expected to use one or more 'Content-alternative' headers to reasonably indicate the range of alternative formats avalable. The final format actually sent will always be selected by the sender, based on the receiver's capabilities. The 'Content-alternative' headers are provided here simply to allow the receiver to make a reasonable decision about whether to request an alternative format that better matches its capabilities. Klyne, Iwazaki, Crocker Internet draft [Page 13] Content Negotiation for Internet Fax 14 July 2000 ALSO NOTE: this header is intended to be usable independently of the MDN extension that indicates the sender is prepared to send alternative formats. It might be used with some completely different content negototiation protocol that is nothing to do with e-mail or MDN. Thus, the 'Content-alternative' header provides information about alternative data formats without actually indicating if and how they might be obtained. Further, the 'Content-alternative' header applies to a MIME body part, where the MDN 'Alternative-available' option applies to the message as a whole. The example sections of this memo shows how the 'Content-features:' and 'Content-alternative:' MIME headers may be used to describe the content provided and available alternatives. [[[Q-factor values, per RFC 2533, in the 'Content-alternative:' expressions might be used to distinguish between "definitive" and "approximate" alternatives.]]] [[[Expiration time on alternatives list. Else recipient is in non- deterministic position. Also, cache control on recipient capabilities?]]] 3.2 Receiver options A negotiation-aware system receiving message data without an indication of alternative data formats MUST process that message in the same way as a standard Internet fax system or e-mail user agent. Given an indication of alternative data format options, the receiver has three primary options: (a) do not recognize the alternatives: passively accept what is provided, (b) do not prefer the alternatives: actively accept what is provided, or (c) prefer some alternative format. Klyne, Iwazaki, Crocker Internet draft [Page 14] Content Negotiation for Internet Fax 14 July 2000 3.2.1 Alternatives not recognized This corresponds to the case that the receiver is a simple mode Internet fax recipient [12], or a traditional e-mail user agent. The receiver does not recognize the alternatives offered, or chooses not to recognize them, and simply accepts the data as sent. A standard MDN response [4] or an extended MDN response [2] MAY be generated at the receiver's option. 3.2.2 Alternative not desired The receiver does recognize the alternatives offered, but specifically chooses to accept the data originally offered. An MDN response SHOULD be sent indicating acceptance of the data and also containing the receiver's capabilities. This is similar to the defined behaviour of an Extended Internet Fax receiver [1,2]. 3.2.3 Alternative preferred This case extends the behaviour of Extended Internet Fax [1,2] to allow an alternative form of data for the current message to be transferred. This option may be followed ONLY if the original message contains an 'Alternative-available' MDN option (alternative data resends may not use this option). The receiver recognizes that alternative data is available, and based on the information provided determines that an alternative format would be preferable. An MDN response MUST be sent containing: o an 'Alternative-preferred' disposition modifier [9] indicating that some data format other than that originally sent is preferred, and o receiver capabilities, per RFC 2530 [2]. On sending such an MDN response, the receiver MAY discard the message data provided, in the expectation that some alternative will be sent. Having requested alternative data and not displayed the original data, the receiver MUST remember this fact and be prepared to take corrective action is alternative data is not received within a reasonable time (e.g. if the MDN response or transmission of alternative data is lost in transit). Klyne, Iwazaki, Crocker Internet draft [Page 15] Content Negotiation for Internet Fax 14 July 2000 Corrective action may be any of the following: (a) resend the MDN response, and continue waiting for an alternative, (b) generate an error response indicating loss of data, or (c) present the data originally supplied (if it is still available). This would be the preferred action, may not be possible for receivers with limited memory. See section 3.4.1 for further discussion of receiver behaviour options. NOTE: the receiver does not actually get to select any specific data format offered by the sender. The final choice of data format is always made by the sender, based on the receiver's eclared capabilities. This approach: (a) more closely matches the style of T.30 content negotiation, (b) provides for clean integration with the current extended mode Internet fax specification, (c) builds upon existing e-mail mechanisms in a consistent fashion, and (d) allows for cases (e.g. dynamically generated content) where it is not feasible for the sender to enumerate the alternatives available. 3.3 Send alternative message data Having offered to provide alternative data by including an 'Alternative-available' option with the original MDN request, and on receipt of an MDN response indicating 'Alternative-preferred', the sender SHOULD transmit alternative message data that best matches the receiver's declared capabilities. If the alternative message data is the same as that originally sent, it SHOULD still be retransmitted because the receiver may have discarded the original data. Any data sent as a result of receiving an 'Alternative-preferred' response should include an MDN request but not an 'Alternative-available' option. If the sender is no longer able to send message data for any reason, it MUST send a message to the receiver indicating a failed transfer. It SHOULD also generate a report for the sender indicating the failure. Klyne, Iwazaki, Crocker Internet draft [Page 16] Content Negotiation for Internet Fax 14 July 2000 [[[Discuss this last paragraph.]]] [[[When sending alternative data, should this fact be indicated? How is the resend tied to the original send.]]] [[[The mechanisms are described above in terms of the entire message. With MDN extensions that are being considered for finer- grained disposition notification at the level of individual message body parts (e.g. the separate parts of a MIME multipart/mixed), this mechanism can be extended to provide independent negotiation for each body part, because the 'Content-features:' and 'Content- alternative:' can be applied to inner body parts.]]] [[[Does it make sense to do a partial retransmission? I think this would be a receiver option, based on which message parts it indicates have been discarded. If it can buffer then partial retransmission is sensible.]]] 3.4 Implementation issues This section is not a normative part of this specification. Rather, it discusses some of the issues that were considered during its design in a way that we hope will be useful to implementers. 3.4.1 Receiver state Probably the biggest implication for implementers of this proposal compared with standard SMTP is the need to maintain some kind of state information at the receiver while content is being negotiated. By "receiver state", we mean that a receiver needs to remember that it has received an initial message AND that it has requested an alternative form of data. Without this, when a receiver responds with a request for an alternative data format there is a possibility (if the response does not reach the sender) that the message will be silently lost, despite its having been delivered to the receiving MTA. The matter of maintaining receiver state is particularly germane because of the requirement to allow low-memory systems to participate in the content negotiation. Unlike traditional T.30 facsimile, where the negotiation takes place within the duration of a single connection, an extended time may be taken to complete a negotiation in e-mail. State information must be maintained for all negotiations outstanding at any time, and there is no theoretical upper bound on how many there may be. Klyne, Iwazaki, Crocker Internet draft [Page 17] Content Negotiation for Internet Fax 14 July 2000 Keeping receiver state is probably not a problem for systems with high capacity storage devices to hold message data and state information. The remainder of this section discusses strategies that small-system designers might employ to place an upper bound on memory that must be reserved for this information. When a receiver is really memory constrained then message loss remains a possibility, but the mechanisms described here should ensure that it never happens silently. So what is this "receiver state"? It must contain, as a minimum: o the fact that message data was received, and alternative data has been requested, o a unique message identifier, and o the time at which an alternative format request was sent. This allows the receiver to re-issue a request, or to report an error, if requested alternative data does not arrive in a reasonable time. Receiver state may also include: o a copy of the data originally received. This allows the receiver to display the original data if an alternative is not received. o details of the data format supplied, and alternatives offered. This permits improved diagnostics if alternative data is not received. If a receiver of a message with alternative content available does not have enough memory to hold new negotiation state information, it may fall back to non-negotiation behaviour, accept the data received and send an MDN indicating disposition of that data (see sections 3.2.1, 3.2.2). If a receiving system runs low on memory after entering into a negotiation, a number of options may be possible: o display or print buffered data, if available, and complete the transaction. If alternative data arrives subsequently, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender. o discard any buffered data, and continue waiting for alternative data. If alternative data does not subsequently arrive, a message transfer failure should be declared. Klyne, Iwazaki, Crocker Internet draft [Page 18] Content Negotiation for Internet Fax 14 July 2000 o abort the transfer and declare a message transfer failure: a diagnostic message must be displayed to the local user, and a failure notification sent to the sender. 3.4.2 Receiver buffering of message data If a receiver is capable of buffering received message data while waiting for an alternative, this is to be prefered because it retains the option to display that data if an alternative is not received (see above). Partial message data should not be buffered for this purpose: displaying part of the original message is not an allowable substitute for displaying all of the received data. (There may be some value in keeping some of the original message data for diagnostic purposes.) If a receiver starts to buffer message data pending negotiation, then finds that the entire message is too large to buffer, it may choose to fall back to "extended mode" and display the incoming data as it is received. 3.4.x Other issues... -- Sender state [[[Maintenance of information about outsanding offers of alternative data formats.]]] -- Timeout of offer of alternatives [[[Expand on note at end of section 3.1. Sender alternatives and choices? Consider facility to indicate expiry of alternatives.]]] -- Timeout of receiver capabilities [[[Consider facility to indicate expiry of receiver capabilities. Also, cache-control options, for temporary capabilities.]]] -- Relationship to timely delivery [[[What optimizations are possible (if any) when delivery and response is known to take no more than a few seconds?]]] -- Ephemeral capabilities [[[Consider the case of selection of a particular variant which may depend on an ephemeral setting. Imagine someone sending a basic fax to a color fax machine and indicating that a color alternative is available. The color fax discards the content and sends an MDN Klyne, Iwazaki, Crocker Internet draft [Page 19] Content Negotiation for Internet Fax 14 July 2000 which says "deleted/alternative-preferred" to the originator. It then runs out of colored ink. The originating fax then sends a new message which the colored fax cannot print. (This may sound stretched, but consider it from the email client in a phone with sound on/off as a related problem).]]] -- Partial vs whole-message resend -- Recipient is fax machine vs e-mail UA -- Reinforce situations where MDNs must not be auto-generated -- Fax offramp issues 4. The Content-alternative header [[[May be moved to a separate document.]]] The 'Content-alternative:' header is a MIME header that can be attached to a MIME body part to indicate availability of some alternative form of the data it contains. This header does not, of itself, indicate how the alternative form of data may be accessed. Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content- alternative' header is defined as: Content-alternative-header = "Content-alternative" ":" Alternative-feature-expression Alternative-feature-expression = More than one 'Content-alternative:' header may be applied to a MIME body part, in which case each one is taken to describe a separate alternative data format that is available. [[[Define 'ext-param' for feature cache control/expiry?]]] [[[Need to consider how to express composite document capabilities, specifically to assert a number of feature expressions that must be simultaneously satisfied for a document to be processed, as in the case of an MRC containing hi-res B/W and low-res colour. The approach currently under consideration is a metalogic level encapsulating media feature expressions]]] [[[Discuss use with 'message/partial'?]]] Klyne, Iwazaki, Crocker Internet draft [Page 20] Content Negotiation for Internet Fax 14 July 2000 5. MDN extension for alternative data [[[May be moved to a separate document]]] Here, we define two extensions to the Message Disposition Notification (MDN) protocol [4] to allow a sender to indicate readiness to send alternative message data formats, and to allow a receiver to indicate a preference for some alternative format. Indication of what alternatives may be available or preferred are not covered here. This functionality is provided by the 'Content- alternative' MIME header [8] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2]. 5.1 Indicating readiness to send alternative data A sender wishing to indicate its readiness to send alternative message data formats must request an MDN response using the MDN 'Disposition-Notification-To:' header [4]. The MDN request is accompanied by a 'Disposition-Notification- Options:' header containing the parameter 'Alternative-available' with an importance value of 'optional'. (The significance of 'optional' is that receiving agents unaware of this option do not generate inappropriate failure responses.) This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]: attribute =/ "Alternative-available" Thus, a sender includes the following headers to indicate that alternative message data is available: Disposition-Notification-To: Disposition-Notification-Options: Alternative-available=optional,(TRUE) [[[Is the parameter value really mandatory? RFC2298 syntax says so. If so, what value should be used (what variations might be required). Think carefully, this is a solution looking for a problem. For now, I would prefer the option value to be optional. If the value is required, its syntax should not preclude useful extensions later. Use parameter to indicate return mailbox? Note that RFC2298 allows auto-response to a single mailbox only.]]] [[[Use the parameter value to indicate an expiry time?]]] Klyne, Iwazaki, Crocker Internet draft [Page 21] Content Negotiation for Internet Fax 14 July 2000 A message sent with a request for an MDN with an 'Alternative- available' option MUST also contain a 'Message-ID:' header field [20]. 5.2 Indicating a preference for alternative data The MDN specification [4] defines a number of message disposition options that may be reported by the receiver of a message: disposition-type = "displayed" / "dispatched" / "processed" / "deleted" / "denied" / "failed" disposition-modifier = ( "error" / "warning" ) / ( "superseded" / "expired" / "mailbox-terminated" ) / disposition-modifier-extension This specification defines an additional value for 'disposition- modifier-extension': disposition-modifier-extension =/ "Alternative-preferred" When a receiver discards message data because it prefers that an alternative format be sent, it sends a message disposition notification message containing the following disposition field: Disposition: / deleted/alternative-preferred For example, an automatically generated response might contain: Disposition: automatic-action/MDN-sent-automatically, deleted/alternative-preferred An MDN response containing an 'alternative-preferred' disposition modifier MUST also contain an 'Original-message-ID:' field [4] with the 'Message-ID:' value from the original message. [[[Discuss constraints on sending this response automatically.]]] [[[Add E164 address type for fax offramp to fax machine as final recipient?]]] Klyne, Iwazaki, Crocker Internet draft [Page 22] Content Negotiation for Internet Fax 14 July 2000 6. Internet Fax Considerations Both sender and receiver parts of this specification involve the use of media feature expressions. In the context of Internet fax, any such expressions SHOULD employ feature tags defined by "Content feature schema for Internet fax" [16]. In a wider e-mail context, any valid media features MAY be used. 7. Examples 7.1 Sending enhanced Internet Fax image An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image to send to a receiver. The baseline for Internet fax is 200x200dpi and MH image compression. Sender's initial message: Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400 From: Jane Sender Message-Id: <199509200019.12345@huge.com> Subject: Internet FAX Full Mode Content Negotiation To: Tom Recipient Disposition-Notification-To: Jane_Sender@huge.com Disposition-Notification-Options: Alternative-available=optional,[[[xxx]]] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RAA14128.773615765/ huge.com" --RAA14128.773615765/ huge.com Content-type: image/tiff; application=faxbw Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) ) Klyne, Iwazaki, Crocker Internet draft [Page 23] Content Negotiation for Internet Fax 14 July 2000 Content-alternative: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) ) [TIFF-FX Profile-S message goes here] --RAA14128.773615765/ huge.com-- Receiver sends MDN response to initial message: Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 From: Tom Recipient Message-Id: <199509200020.12345@mega.edu> Subject: Re: Internet FAX Full Mode Content Negotiation To: Jane Sender MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615766/mega.edu" --RAA14128.773615766/mega.edu The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested. --RAA14128.773615766/mega.edu Content-Type: message/disposition-notification Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode Original-Recipient: rfc822;Tom-Recipient@mega.edu Final-Recipient: rfc822;Tom-Recipient@mega.edu Original-Message-ID: <199509200019.12345@huge.com> Disposition: automatic-action/MDN-sent-automatically; deleted/alternative-preferred Klyne, Iwazaki, Crocker Internet draft [Page 24] Content Negotiation for Internet Fax 14 July 2000 Media-Accept-Features: (& (color=Binary) (image-file-structure=TIFF) (| (& (dpi=200) (dpi-xyratio=200/100) ) (& (dpi=200) (dpi-xyratio=1) ) (& (dpi=400) (dpi-xyratio=1) ) ) (| (image-coding=[MH,MR,MMR]) (& (image-coding=JBIG) (image-coding-constraint=JBIG-T85) (JBIG-stripe-size=128) ) ) (MRC-mode=0) (paper-size=[A4,B4]) (ua-media=stationery) ) --RAA14128.773615766/mega.edu-- Sender's message with enhanced content: Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400 From: Jane Sender Message-Id: <199509200021.12345@huge.com> Subject: Internet FAX Full Mode Image Transmission To: Tom Recipient Disposition-Notification-To: Jane_Sender@huge.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RAA14128.773615768/ huge.com" --RAA14128.773615768/ huge.com Content-type: image/tiff; application=faxbw Content-Transfer-Encoding: base64 [TIFF-FX profile-F message goes here] --RAA14128.773615768/ huge.com-- Receiver sends MDN confirmation of enhanced message content: Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 From: Tom Recipient Message-Id: <199509200022.12345@mega.edu> Subject: Re: Internet FAX Full Mode Image Transmission To: Jane Sender MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615769/mega.edu" --RAA14128.773615769/mega.edu Klyne, Iwazaki, Crocker Internet draft [Page 25] Content Negotiation for Internet Fax 14 July 2000 The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode. --RAA14128.773615769/mega.edu Content-Type: message/disposition-notification Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode Original-Recipient: rfc822;Tom-Recipient@mega.edu Final-Recipient: rfc822;Tom-Recipient@mega.edu Original-Message-ID: <199509200021.12345@huge.com> Disposition: automatic-action/MDN-sent-automatically; processed Media-Accept-Features: (& (color=Binary) (image-file-structure=TIFF) (| (& (dpi=200) (dpi-xyratio=200/100) ) (& (dpi=200) (dpi-xyratio=1) ) (& (dpi=400) (dpi-xyratio=1) ) ) (| (image-coding=[MH,MR,MMR]) (& (image-coding=JBIG) (image-coding-constraint=JBIG-T85) (JBIG-stripe-size=128) ) ) (MRC-mode=0) (paper-size=[A4,B4]) (ua-media=stationery) ) --RAA14128.773615769/mega.edu-- 7.2 Internet fax with initial data usable This example shows how the second and subsequent transfers between the systems in the previous example might be conducted. Using knowledge gained from the previous exchange, the sender includes profile-F data with its first contact. Sender's initial message: Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400 From: Jane Sender Message-Id: <199509200019.12345@huge.com> Subject: Internet FAX Full Mode Content Negotiation To: Tom Recipient Disposition-Notification-To: Jane_Sender@huge.com Disposition-Notification-Options: Alternative-available=optional,[[[xxx]]] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RAA14128.773615765/ huge.com" Klyne, Iwazaki, Crocker Internet draft [Page 26] Content Negotiation for Internet Fax 14 July 2000 --RAA14128.773615765/ huge.com Content-type: image/tiff; application=faxbw Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) ) [TIFF-FX Profile-F message goes here] --RAA14128.773615765/ huge.com-- Receiver sends MDN confirmation of received message content: Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400 From: Tom Recipient Message-Id: <199509200022.12345@mega.edu> Subject: Re: Internet FAX Full Mode Image Transmission To: Jane Sender MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615769/mega.edu" --RAA14128.773615769/mega.edu The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom Recipient with subject "Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode. --RAA14128.773615769/mega.edu Content-Type: message/disposition-notification Klyne, Iwazaki, Crocker Internet draft [Page 27] Content Negotiation for Internet Fax 14 July 2000 Reporting-UA: Toms-pc.cs.mega.edu; IFAX-FullMode Original-Recipient: rfc822;Tom-Recipient@mega.edu Final-Recipient: rfc822;Tom-Recipient@mega.edu Original-Message-ID: <199509200021.12345@huge.com> Disposition: automatic-action/MDN-sent-automatically; processed Media-Accept-Features: (& (color=Binary) (image-file-structure=TIFF) (| (& (dpi=200) (dpi-xyratio=200/100) ) (& (dpi=200) (dpi-xyratio=1) ) (& (dpi=400) (dpi-xyratio=1) ) ) (| (image-coding=[MH,MR,MMR]) (& (image-coding=JBIG) (image-coding-constraint=JBIG-T85) (JBIG-stripe-size=128) ) ) (MRC-mode=0) (paper-size=[A4,B4]) (ua-media=stationery) ) --RAA14128.773615769/mega.edu-- 7.3 Other example??? [[[Showing negotiate-down]]] 8. IANA Considerations [[[TBD: MIME header and MDN extension registrations]]] [[[See RFC 2298, section 10]]] 9. Internationalization considerations [[[TBD?]]] 10. Security considerations [[[TBD]]] 11. Acknowledgements The basic structure of the negotiation described here was first documented in a draft by Mr. Toru Maeda of Canon. Helpful comments on earlier drafts were provided by Mr Hiroshi Tamura and Ted Hardie. Klyne, Iwazaki, Crocker Internet draft [Page 28] Content Negotiation for Internet Fax 14 July 2000 12. References [1] RFC 2532, "Extended Facsimile using Internet Mail" L. Masinter, Xerox Corporation D. Wing, Cisco Systems March 1999. [2] RFC 2530, "Indicating Supported Media Features Using Extensions to DSN and MDN" D. Wing, Cisco Systems March 1999. [3] RFC 2542, "Terminology and Goals for Internet Fax" L. Masinter, Xerox Corporation March 1999. [4] RFC 2298, "An Extensible Message Format for Message Disposition Notifications" R. Fajman, National Institutes of Health March 1998. [5] RFC 2506, "Media Feature Tag Registration Procedure" Koen Holtman, TUE Andrew Mutz, Hewlett-Packard Ted Hardie, NASA March 1999. [6] RFC 2533, "A syntax for describing media feature sets" Graham Klyne, 5GM/Content Technologies March 1999. [7] "Indicating media features for MIME content" Graham Klyne, Content Technologies Internet draft: Work in progress, April 1999. [8] 'Content-alternative' header (this memo, section 4) [9] MDN extension for alternative data (this memo, section 5) [10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" D. Crocker (editor), Internet Mail Consortium P. Overell, Demon Internet Ltd. November 1997. Klyne, Iwazaki, Crocker Internet draft [Page 29] Content Negotiation for Internet Fax 14 July 2000 [11] RFC 2301, "File format for Internet fax" L. McIntyre, R. Buckley, D. Venable, Xerox Corporation S. Zilles, Adobe Systems, Inc. G. Parsons, Northern Telecom J. Rafferty, Human Communications March 1998. [12] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail" K. Toyoda H. Ohno J. Murai, WIDE Project D. Wing, Cisco Systems March 1998. [13] RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1" R. Fielding, UC Irvine J. Gettys, Compaq/W3C J. Mogul, Compaq H. Frystyk, W3C/MIT L. Masinter, Xerox P. Leach, Microsoft T. Berners-Lee, W3C/MIT June 1999. (Accept headers are described in section 14.1; section 12 discusses content negotiation possibilities in HTTP.) [14] RFC 2295, "Transparent Content Negotiation in HTTP" Koen Holtman, TUE Andrew Mutz, Hewlett Packard March 1998. [15] RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media types" N. Freed, Innosoft N. Borenstein, First Virtual November 1996. [16] RFC 2531, "Content feature schema for Internet fax" Graham Klyne, 5GM/Content Technologies Lloyd McIntyre, Xerox Corporation March 1998. [17] RFC 2703, "Protocol-independent Content Negotiation Framework" Graham Klyne, 5GM/Content Technologies September 1999. (This memo indicates terminology, framework and goals for content negotiation independent of any particular transfer protocol with which it may be deployed.) Klyne, Iwazaki, Crocker Internet draft [Page 30] Content Negotiation for Internet Fax 14 July 2000 [18] RFC 1891, "SMTP Service Extension for Delivery Status Notifications" K. Moore, University of Tennessee January 1996. [19] RFC 821, "Simple Mail Transfer Protocol" Jonathan B. Postel, ISI/USC August 1982. [20] RFC 822, "Standard for the Format of ARPA Internet Text Messages" David H. Crocker, University of Delaware August 1982. [21] "Timely Delivery for Facsimile Using Internet Mail" Graham Klyne, Content Technologies Internet draft: Work in progress, October 1999. 13. Authors' addresses Graham Klyne (editor) Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom. Telephone: +44 118 930 1300 Facsimile: +44 118 930 1301 E-mail: GK@ACM.ORG Ryuji Iwazaki TOSHIBA TEC CORPORATION 2-4-1, Shibakoen, Minato-ku, Tokyo, 105-8524 Japan Tel: +81 3 3438 6866 Fax: +81 3 3438 6861 E-mail: iwa@rdl.toshibatec.co.jp D. Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@brandenburg.com Klyne, Iwazaki, Crocker Internet draft [Page 31] Content Negotiation for Internet Fax 14 July 2000 Appendix A: Amendment history 00a 30-Sep-1999 Memo initially created. 00b 15-Oct-1999 Incorporated co-author material. Added examples. Added background section about open- and closed- loop operations. Cleaned up some text. Develop section describing the MDN extensions. Complete reference details. 00c 19-Oct-1999 Acknowledgement and editorial changes. Re-written abstract and revised introductory text. 01a 12-Nov-1999 Make consistent date and time values in the examples. Fix mailing list description. 01b 09-Mar-2000 Add text clarifying the role of sender and receiver in selecting alternative formats, the use of multiple 'Content-alternative' headers. Also add some notes about sender behaviour when sending an alternative data format. Updated author contact information. Added reference to multipart/alternative in the introduction. Added text in section 3.1 about retention of data by the sender. Added some comments to the implementation notes section. Added emphemeral capability scenario suggested by Ted Hardie for consideration under implementation notes. 02a 11-Jul-2000 Change title of memo. Re-work abstract and introduction. Add some text to the terminology section; also cite RFC 2703 here. Minor editorial changes. Remove suggestion of allowing comma separated list for 'Content-alternative' header (following style of Content-features' defined separately). 02b 14-Jul-2000 Added revisions arising from comments by Tamura- san: text about receiver state issues; note about distinguishing initial message from resend of alternative data; added requirement for message-ID header; add discussion of receiver options in case of insufficient memory. TODO: o Review use of RFC 2119 language o Complete terminology (1.2.1) Klyne, Iwazaki, Crocker Internet draft [Page 32] Content Negotiation for Internet Fax 14 July 2000 o Require use of 'Original-recipient' header, and limit negotiation to receivers named there? (3) o Allow negotiation with forwarded messages? (3) o Require use of content-id to be noted by requests for alternative formats? (3) o TTL for alternative-feature sets? (3.1) o Use q-values to distinguish 'definitive' from 'informative' format options? (3.1.3) o Cache-control for alternative feature sets? (e.g. colour offered for selected recipients only). (3.1.3) o Confirm action when sender cannot honour request for alternative (e.g. offer timed out). (3.3) o How to differentiate alternative data (e.g. don't show alternative available)? (3.3) o How to relate resend to original send? (3.3) o Consideration of partial resends (i.e. selected body parts only)? (3.3) o Write up "implementation issues" -- when outstanding issues are decided. (3.4) o Cache-control, timeout for receiver capabilities? (3.4) o Define Content-alternative in a separate document? (Possibly, because it mighgt be used separately from the content negotiation framework; e.g. in a fashion similar to the HTTP vary: header.) (4) o Consideration of composite document structures (e.g. MRC) in Content-alternative header? (This is really a media feature expression issue that is not fully resolved. The current syntax is a particular trade-off between reasonable simplicity and comprehensive functionality.) (4) o Describe interaction between Content-alternative and message/partial. (4) o Define MDN extensions in separate document? (Probably not, since they are not really useful separately from this negotiation framework.) (5) Klyne, Iwazaki, Crocker Internet draft [Page 33] Content Negotiation for Internet Fax 14 July 2000 o Consider use of MDN option parameter: request MDN expert input. (5.1) o Time-limit on offer of alternative data? (This raises clock- synchronization and message transit time issues.) (5.1) o Add text about automated transmission of MDN responses for content negotiation. (5.2) o Add E164 address type for reporting fax offramp disposal? (5.2) o Negotiate-down example? (7.3) o IANA considerations. (8) o Internationalization considerations (if any). (9) o Security considerations. (10) Full copyright statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Klyne, Iwazaki, Crocker Internet draft [Page 34]