Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
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) )
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/ example.com--
Receiver sends MDN response to initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@example.org> with subject "Internet
FAX Full Mode Content Negotiation" has been received. An
alternative form of the message data is requested.
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(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/example.org--
Sender's message with enhanced content:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
[TIFF-FX profile-F message goes here]
--RAA14128.773615768/ example.com--
Receiver sends MDN confirmation of enhanced message content:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject " Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(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/example.org--
8.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 <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
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/ example.com--
Receiver sends MDN confirmation of received message content:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject "Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(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/example.org--
8.3 Negotiate to lower receiver capability
In this example, the sender has incorrectly assumed that the receiver
has a higher capability, and must re-send lower capability data in
response to the receiver's response showing lesser capability.
An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image. When
the receiver cannot handle this, it falls back to baseline profile-S.
As this is a baseline format, it is not necessary to declare that
capability with the original message. When a receiver is faced with
data it cannot process from a negotiating sender, it can do no better
than to respond with a description of its actual capabilities and let
the sender determine the outcome.
Sender's initial message:
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
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) )
[TIFF-FX Profile-F message goes here]
--RAA14128.773615765/ example.com--
Receiver sends MDN response to initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Negotiate Down
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@example.org> with subject "Internet
FAX Full Mode Content Negotiation" has been received. An
alternative form of the message data is requested.
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615766/example.org--
Sender's message with baseline content:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
[TIFF-FX profile-S message goes here]
--RAA14128.773615768/ example.com--
Receiver sends MDN confirmation of impoverished message content:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject " Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-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) )
--RAA14128.773615769/example.org--
8.4 Sending an alternative content type
As noted in section 4, the sender can offer the data using a
different MIME content-type. This example shows a profile-F (A4,
400x400dpi, MMR) image and a limited-colour PDF document offered as
alternatives to a baseline image/TIFF.
Sender's initial message:
(Note that the MIME content type is not specified for the
image/tiff alternative, being the same as that provided, but
is mentioned for the application/pdf alternative.)
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
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) )
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) )
Content-alternative:
(& (type="application/pdf")
(color=Limited)
(dpi=400)
(paper-size=A4)
(ua-media=stationery) )
[TIFF-FX Profile-S message goes here]
--RAA14128.773615765/ example.com--
Receiver sends MDN response to initial message:
(Note that this response indicates an ability to handle the
PDF MIME content-types, but with only binary colour.)
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@example.org> with subject "Internet
FAX Full Mode Content Negotiation" has been received. An
alternative form of the message data is requested.
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615766/example.org--
Resend with alternative content-type:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: application/pdf
Content-Transfer-Encoding: base64
[PDF data goes here]
--RAA14128.773615768/ example.com--
Receiver sends MDN confirmation of enhanced message content:
(Also indicating the PDF capability for future messages.)
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject " Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615769/example.org--
9. IANA Considerations
9.1 New message headers
This specification defines new email/MIME message headers:
Content-alternative
Original-Message-ID
As such, there being no registry of email headers, it is an update to
the specifications of RFC2822 and RFC2045.
9.2 MDN extensions
This specification defines extensions to the Message Disposition
Notification (MDN) protocol. The sections below are the registration
templates for these extensions, as required by RFC2298 [4], section
10.
9.2.1 Notification option 'Alternative-available'
(a) Disposition-notification-option name:
Alternative-available
(b) Syntax:
(see this document, section 6.1)
(c) Character-encoding:
US-ASCII characters only are used
(d) Semantics:
(see this document, section 6.1)
9.2.2 Notification option 'Alternative-not-available'
(a) Disposition-notification-option name:
Alternative-not-available
(b) Syntax:
(see this document, section 6.1)
(c) Character-encoding:
US-ASCII characters only are used
(d) Semantics
(see this document, section 6.3)
9.2.3 Disposition modifier 'Alternative-preferred'
(a) Disposition-modifier name:
Alternative-preferred
(b) Semantics:
(see this document, section 6.2)
9.2.4 Disposition modifier 'Original-lost'
(a) Disposition-modifier name:
Original-lost
(b) Semantics:
(see this document, section 6.4)
10. Internationalization considerations
This specification deals with protocol exchanges between mail user
agents, and as such does not deal primarily with human readable text.
But not all user agents may automatically handle the protocol
elements defined here, and may attempt to display text from the
protocol elements to the user.
The main candidate for this treatment is the text accompanying a
disposition notification response that requests alternative
information. In normal use, the protocol design ensures that the
recipient can process this response automatically; exceptionally, a
receiving agent may display it to a user.
11. Security Considerations
Security considerations of this specification can be divided into two
main areas:
o Privacy concerns with automated MDN response generation: see
section 6.5 of this document, and the security considerations
section of RFC2298 [4].
o Risks of negotiation: see the security considerations section
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.
12. 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, Ted Hardie and Larry Masinter.
13. References
[1] Masinter, L. and D. Wing, "Extended Facsimile using Internet
Mail", RFC2532, March 1999.
[2] Wing, D., "Indicating Supported Media Features Using Extensions
to DSN and MDN", RFC2530, March 1999.
[3] Masinter, L., "Terminology and Goals for Internet Fax", RFC
2542, March 1999.
[4] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC2298, March 1998.
[5] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
Registration Procedure", RFC2506, March 1999.
[6] Klyne, G., "A syntax for describing media feature sets", BCP
31, RFC2533, March 1999.
[7] Klyne, G., "Indicating media features for MIME content", RFC
2938, September 2000.
[8] 'Content-alternative' header (this memo, section 4)
[9] MDN extension for alternative data (this memo, section 6)
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[11] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons,
G. and J. Rafferty, "File format for Internet fax", RFC2301,
March 1998.
[12] Toyoda K., Ohno H., Murai, J. and D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC2305, March 1998.
[13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC2616, June 1999.
[14] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP", RFC2295, March 1998.
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part 2: Media types", RFC2046, November
1996.
[16] Klyne, G. and L. McIntyre, "Content feature schema for Internet
fax V2", RFC2879, August 2000.
[17] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC2703, September 1999.
[18] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC1891, January 1996.
[19] Klensin, J., "Simple Mail Transfer Protocol", RFC2821, April
2001.
[20] Resnick, P., "Internet Message Format", RFC2822, April 2001.
[21] Klyne, G. and D. Crocker, "Timely Delivery for Facsimile Using
Internet Mail", Work in Progress.
[22] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[23] 'Original-Message-ID' header for mail messages (this memo,
section 5)
[24] Klyne, G., "MIME Content Types in Media Feature Expressions",
RFC2913, September 2000.
Appendix A: 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.
A.1 Receiver state
Probably the biggest implication for implementers of this proposal
compared with standard mail user agents 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 email. 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.
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.
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.
A.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 preferred 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.
When a sender indicates availability of alternative data, it also
indicates whether it is permanently or transiently available. The
intent of this is that if alternative data is transient, a receiver
should not discard original data received. If necessary, it should
simply display the original data without requesting an alternative.
A.3 Sender state
When a sender indicates that it can offer an alternative format of
message content, it accepts some responsibility for trying to ensure
that alternative is available if requested. Thus, the message
content (both original and any alternative) should be stored for a
reasonable period, together with any corresponding Message-ID
value(s).
A request for retransmission must be accompanied by an Original-
Message-ID value that the sender can use to correlate with the
message data originally sent.
A.4 Timeout of offer of alternatives
If the sender is operating with a high capacity message storage
device (e.g., a disk drive), and normally holds the data for extended
periods (several days or weeks) then it should indicate that the
alternative data is permanently available (see 6.1): a recipient
seeing this may discard the original data, assuming that the sender
will most likely be able to re-transmit.
If the sender has limited memory capacity, and is likely to be able
to hold the data for no more than a few minutes or hours, it should
indicate that the alternative data is transiently available (see
6.1). If there is doubt about a sender's ability to keep the message
content, it should indicate that availability of any alternative is
transient.
A.5 Timeout of receiver capabilities
It should not be assumed that receiver capabilities declared during
negotiation are available indefinitely.
In particular, any receiver capabilities declared on a final message
confirmation should be regarded as definitive, even if they differ
from the capabilities associated with the message just accepted.
These may be stored for future use.
Any receiver capabilities declared when requesting an alternative
format should not be stored for future use, as the receiver might be
selective about the purposes for which those capabilities may be
used.
A.6 Relationship to timely delivery
Some of the issues of sender state maintenance may be simplified if
content negotiation is used in conjunction with a facility for timely
delivery (e.g., [21]). If there is a known time window within which
a response should be received, the sender may be less conservative
about keeping information about outstanding offers of alternative
data for extended periods. A sender that exploits timely delivery in
this way should indicate that the alternative is transiently
available.
A.7 Ephemeral capabilities
Ephemeral capabilities may present some special problems. Consider
the case of selection of a particular content variant that may depend
on an ephemeral setting.
Imagine someone sending a basic fax to a color fax machine,
indicating that a color alternative is available. The color fax
discards the content and sends an MDN 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.
Or consider an the email client in a phone with sound on/off as a
related problem. When sound is ON, the phone may be able to accept
voice messages by email.
This negotiation framework has not been designed with ephemeral
capabilities in mind, but, with care, may be adaptable to deal with
them.
A.8 Situations where MDNs must not be auto-generated
Bearing in mind privacy concerns, implementers should be careful that
systems do not automatically enter into a negotiation exchange in a
way that may disclose the recipient's whereabouts without first
having obtained explicit permission. For example, if receiving a
message depends in any way on the user's physical presence, automatic
negotiation should not be performed.
While it may be OK for an unattended fax machine to perform automated
negotiation, it is not OK for a PC software package to do so without
the users explicit permission as the PC may be switched on only when
the user is present. This suggests that default settings in this
regard should take account of the type of system.
Appendix B: Candidates for further enhancements
This appendix lists some possible features of content negotiation
that were considered, but not included in the current specification.
In most cases the reasons for exclusion were (a) that they could
introduce unanticipated additional complexities, and (b) no
compelling requirement was recognized.
o Cache control indicator for recipient capabilities. This would
instruct the sender, or other message system component, that
capability information in the current message is for the current
transaction only, and should NOT be remembered for future
transactions. E.g., a recipient may not wish colour capability to
be used for routine communications. (See also section A.5 above.)
o Use of q-values [6] in media feature expressions for indicating
preference among alternatives available and/or receiver
preferences.
o Partial re-sends. There are proposals being developed for
"partial MDN" responses that can indicate disposition status on a
per-message-part basis. This opens the possibility of partial
re-sends when alternative formats are requested for only some of
the message body parts. The current specification assumes that
either none or all of message is re-sent when content negotiation
is used.
o Allow negotiation with parties other than originally addressed
recipients of a message.
o Negotiation response might indicate different receiver endpoint
with different capabilities.
Authors' Addresses
Graham Klyne (editor)
Clearswift Corporation,
1310 Waterside,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Ryuji Iwazaki
TOSHIBA TEC CORPORATION
2-4-1, Shibakoen, Minato-ku,
Tokyo, 105-8524 Japan
Phone: +81 3 3438 6866
Fax: +81 3 5402 6355
EMail: iwa@rdl.toshibatec.co.jp
Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086 USA
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@brandenburg.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.