Content Negotiation for Messaging Services based on Email
Extracted elements (27)
Content-alternative is designed as a standalone MIME header, independent of the MDN Alternative-available option, so that it can be used with other protocols having nothing to do with email or MDN. It indicates that alternatives exist without specifying how to obtain them.
The Alternative-available option uses importance 'optional' so that receiving agents unaware of this MDN option do not generate inappropriate failure responses, preserving backward compatibility with existing email infrastructure.
The final choice of data format is always made by the sender based on the receiver's declared capabilities, not by the receiver choosing from enumerated alternatives. This more closely matches T.30 negotiation, integrates cleanly with extended Internet fax, and handles cases where dynamically generated content cannot be enumerated in advance.
The mechanism avoids 'administrative non-messages' by requiring the sender to always include meaningful data in the initial message. A sender must not assume a receiver understands the capability exchange protocol, so must start with processable content regardless.
A negotiation-aware receiver that receives a message without any indication of alternative data formats MUST process that message identically to a standard Internet fax system or email user agent, ensuring full backward compatibility.
For Internet fax, the assumed content-type is image/tiff and all devices must support TIFF profile S. However, it is RECOMMENDED that Internet fax devices explicitly state their capabilities (including type='image/tiff' and baseline TIFF) in MDN responses rather than assuming the peer is also an Internet fax device.
A sender that is prepared to provide alternative message data formats MUST send: a default message data format, a Message-ID header, appropriate Content-features headers, an MDN request, an Alternative-available MDN option, and Content-alternative headers indicating available alternatives.
A system capable of performing content negotiation MUST have an option for its user to disable negotiation responses, either generally, on a per-message basis, or both, respecting privacy concerns about automatic MDN generation.
An MDN response containing an alternative-preferred disposition modifier MUST also contain an Original-message-ID field, and receiver capabilities supplied with such a notification MUST NOT be cached as they may apply to the current transaction only.
Any message sent in response to a request for alternative data MUST include an Original-Message-ID header containing the Original-message-ID value from the received disposition notification (which is the Message-ID from the original message).
Having requested alternative data and not displayed the original, the receiver MUST remember this fact and be prepared to take corrective action (re-send MDN, present original, or generate error) if alternative data is not received within a reasonable time.
If the re-send indicates alternative data is no longer available (Alternative-not-available) and the receiver has discarded the original data, the receiver SHOULD display the failure message or construct a loss notification, then send an MDN with disposition 'deleted'.
If the sender is no longer able to send message data, it MUST send a message to the receiver indicating a failed transfer, and SHOULD generate a report with an MDN request including an Alternative-not-available modifier.
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.
Recipients not named in the original message's 'to:', 'cc:' or 'bcc:' headers MUST NOT attempt to initiate content negotiation by requesting alternative data formats.
When a sender is indicating preparedness to send alternative message data, it MUST request a Message Disposition Notification (MDN) and MUST include a Message-ID header when using the Alternative-available option.
MDN usage is entirely voluntary due to privacy considerations for end-users. Content negotiation, which depends on MDN, must therefore build on a voluntary, high-latency closed-loop model and cannot mandate MDN responses from all receivers.
The Alternative-available MDN notification option, included in Disposition-Notification-Options, signals the sender's readiness to supply alternative message data. It carries a lifetime value of 'transient' or 'permanent' and must have importance 'optional' so unaware agents do not generate failures.
The Alternative-not-available MDN notification option, with importance 'required', is sent by a sender that can no longer provide the previously offered alternative data. The accompanying message MUST include an Original-Message-ID header.
The Alternative-preferred MDN disposition modifier is a new disposition-modifier-extension value. When present in a disposition notification, it signals that the receiver prefers an alternative format and requests the sender to re-transmit accordingly.
The Content-alternative MIME header is attached to a MIME body part to indicate availability of an alternative form of that data. Its value is an Alternative-feature-expression (same syntax as the RFC 2533 Filter), and multiple such headers may appear on a single body part.
The Original-lost MDN disposition modifier (disposition-modifier-extension) is sent by a receiver that has lost message data due to insufficient memory while waiting for an alternative, using disposition 'deleted/original-lost'.
The Original-Message-ID message header correlates a response or re-send with the original message. Its value is a msg-id identical to the Message-ID of the original message; the re-send MUST carry its own unique Message-ID in addition.
This specification defines two new email/MIME message headers, Content-alternative and Original-Message-ID, updating the specifications of RFC 2822 and RFC 2045. There is no formal registry of email headers at the time of publication.
This specification registers four MDN extensions: notification options Alternative-available and Alternative-not-available (as new 'attribute' values in Disposition-Notification-Options), and disposition modifiers Alternative-preferred and Original-lost (as new disposition-modifier-extension values), per RFC 2298 section 10.
Automated MDN response generation raises privacy concerns: systems MUST provide a user option to disable negotiation responses to avoid disclosing capabilities or confirming receipt without user consent, per RFC 2298 sections 2.1 and 6.2.
The negotiation involves three optional loops: (1) sender receives acknowledgement that negotiable content was received; (2) receiver receives confirmation its alternative request was received; (3) sender receives confirmation that received data was processed. If the initial data is acceptable, only loop (3) fires. The receiver's state must track that an alternative was requested and not yet resolved.