One document matched: draft-ietf-fax-content-negotiation-05.txt-104124.txt
Differences from 05.txt-04.txt
IETF fax WG G. Klyne (editor), Baltimore Technologies
Internet draft R. Iwazaki, Toshiba TEC
D. Crocker, Brandenburg Consulting
30 May 2001
Expires: September 2001
Content Negotiation for Internet Messaging Services
<draft-ietf-fax-content-negotiation-05.txt>
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/1id-abstracts.html
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 2001. All Rights Reserved.
Abstract
This memo describes a content negotiation mechanism for facsimile,
voice and other messaging services that use Internet email.
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 email.
Klyne, Iwazaki, Crocker Internet draft [Page 1]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Discussion of this document
Please send comments to: <ietf-fax@imc.org>.
To subscribe: send a message with the body 'subscribe' to
<ietf-fax-request@imc.org>. The mailing list archive is at
<http://www.imc.org/ietf-fax/>.
Table of contents
1. Introduction.............................................3
1.1 Structure of this document ...........................4
1.2 Document terminology and conventions .................5
1.2.1 Terminology......................................5
1.2.2 Design goals.....................................5
1.2.3 Other document conventions.......................6
2. Background and goals.....................................6
2.1 Background ...........................................6
2.1.1 Fax and email....................................6
2.1.2 Current facilities in Internet Fax...............7
2.2 Closing the loop .....................................7
2.3 Goals for content negotiation ........................9
3. Framework for content negotiation........................10
3.1 Send data with an indication of alternatives .........12
3.1.1 Choice of default data format....................13
3.1.2 MDN request indicating alternate data formats....13
3.1.3 Information about alternative data formats.......13
3.2 Receiver options .....................................15
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 ........................17
3.4 Confirm receipt of resent message data ...............18
4. The Content-alternative header...........................19
5. The Original-Message-ID message header...................19
6. MDN extension for alternative data.......................20
6.1 Indicating readiness to send alternative data ........20
6.2 Indicating a preference for alternative data .........21
6.3 Indicating alternative data is no longer available ...22
6.4 Indicating loss of original data .....................23
6.5 Automatic sending of MDN responses ...................23
7. Internet Fax Considerations..............................24
8. Examples.................................................24
8.1 Sending enhanced Internet Fax image ..................24
8.2 Internet fax with initial data usable ................28
8.3 Negotiate to lower receiver capability ...............30
8.4 Sending an alternative content type ..................33
9. IANA Considerations......................................37
9.1 New message headers ..................................37
Klyne, Iwazaki, Crocker Internet draft [Page 2]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
9.2 MDN extensions .......................................37
9.2.1 Notification option 'Alternative-available'......38
9.2.2 Notification option 'Alternative-not-available'..38
9.2.3 Disposition modifier 'Alternative-preferred'.....38
9.2.4 Disposition modifier 'Original-lost'.............38
10. Internationalization considerations.....................39
11. Security considerations.................................39
12. Acknowledgements........................................39
13. References..............................................39
14. Authors' addresses......................................42
Appendix A: Implementation issues...........................43
A.1 Receiver state .......................................43
A.2 Receiver buffering of message data ...................44
A.3 Sender state .........................................45
A.4 Timeout of offer of alternatives .....................45
A.5 Timeout of receiver capabilities .....................45
A.6 Relationship to timely delivery ......................46
A.7 Ephemeral capabilities ...............................46
A.8 Situations where MDNs must not be auto-generated .....46
Appendix B: Candidates for further enhancements.............47
Appendix C: Amendment history...............................48
Full copyright statement....................................50
1. Introduction
This memo describes a mechanism for email 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 email 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.
Klyne, Iwazaki, Crocker Internet draft [Page 3]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
An alternative facility available in email (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 based the initial transmission on
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 replace 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.
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 a new mail message header, 'Original-Message-
ID', which is used to correlate alternative data sent during
negotiation with the original message data, and to distinguish the
continuation of an old message transaction from the start of a new
transaction.
Klyne, Iwazaki, Crocker Internet draft [Page 4]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Section 6 describes extensions to the Message Disposition
Notification (MDN) framework [4] that support negotiation between
the communicating parties.
1.2 Document terminology and conventions
1.2.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [22].
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.
Message transaction
A sequence of exchanges between a message sender and receiver
that accomplish the transfer of message data.
RFC 2703 [17] introduces several other terms related to content
negotiation.
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.
Klyne, Iwazaki, Crocker Internet draft [Page 5]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
{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.
2. Background and goals
2.1 Background
2.1.1 Fax and email
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 email 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
negotiation is to permit better-than baseline capabilities to be
employed where available.
Klyne, Iwazaki, Crocker Internet draft [Page 6]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
One of challenges addressed by this specification is how to adapt
the email 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 email message. There are some
important uses of email 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
email 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
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 email 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.
Klyne, Iwazaki, Crocker Internet draft [Page 7]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 email is to establish that consenting
parties can recognize a closed loop situation, and hence their
responsibilities to close the loop.
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
Klyne, Iwazaki, Crocker Internet draft [Page 8]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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.
Further goals are:
(a) Must {1} interwork with existing simple mode Internet fax
systems.
(b) Must {1} interwork with existing email clients.
The term "interwork" used above means that the mechanism 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 email
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 transmission 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.
Klyne, Iwazaki, Crocker Internet draft [Page 9]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 consistent with and
applicable to other Internet email based applications; e.g.
regular email, voice messaging, unified messaging, etc.
(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 email 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 some other guess of what the recipient can handle.
Klyne, Iwazaki, Crocker Internet draft [Page 10]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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).
Note that only recipients named in 'to:', 'cc:' or 'bcc:'
headers in the original message may request alternative data
formats in this way. Recipients not named in the original
message headers MUST NOT attempt to initiate content
negotiation.
NOTE: the prohibition on initiation of negotiation by
recipients other than those explicitly addressed is to
avoid the sender having to deal with negotiation requests
from unexpected parties.
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.
4. On receipt of final data from the sender, the receiver sends an
MDN response indicating acceptance (or otherwise) of the data
received.
Klyne, Iwazaki, Crocker Internet draft [Page 11]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 email, 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 email using
"multipart/alternative" and "message/external-body" MIME
types [15].
3.1 Send data with an indication of alternatives
A sender that is prepared to provide alternative message data
formats MUST send the following message elements:
(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],
(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 is expected to hold the necessary information for some time,
to allow the receiver an opportunity to request such data. But,
unless it so indicates (see [9]), 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 available. If message transfer is being
completed within a predetermined time interval (e.g. using [21]),
Klyne, Iwazaki, Crocker Internet draft [Page 12]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
then the sender should normally maintain the data for at least that
period.
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].
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.
Klyne, Iwazaki, Crocker Internet draft [Page 13]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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.
Alternative formats will often be variations of the content-type
originally sent. When different content-types can be provided,
they should be indicated in a corresponding content-alternative
header using the 'type' media feature tag [24]. (See example 8.4.)
NOTE: the sender is not necessarily expected to describe
every single alternative format that is available --
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
available.
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.
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 could
be used with a different protocol having nothing to do
with email or MDN. Thus, the 'Content-alternative'
header provides information about alternative data
formats without actually indicating if or 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 show how the 'Content-features:'
and 'Content-alternative:' MIME headers may be used to describe the
content provided and available alternatives.
Klyne, Iwazaki, Crocker Internet draft [Page 14]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 email 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.
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 email 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 the same as 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 re-sends may not use this option). Further, this option may
be followed ONLY if the recipient is explicitly addressed in the
message headers ('to:', 'cc:' or 'bcc:').
Klyne, Iwazaki, Crocker Internet draft [Page 15]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 [4] is sent, which
MUST contain the following:
o an 'Alternative-preferred' disposition modifier [9] indicating
that some data format other than that originally sent is
preferred,
o an 'Original-Message-ID:' field [4] with the message identifier
from the received message, 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. But if the sender has indicated a limited lifetime
for the alternative data, and the original data received is within
the receiver's capability to display, the receiver SHOULD NOT
discard it. Lacking sufficient memory to hold the original data
for a period of time within which alternative data would reasonably
be received, the receiver SHOULD accept and display the original
data. In the case that the original data is not within the
receiver's capability to display then it SHOULD discard the
original data and request an alternative format.
NOTE: the above rules are meant to ensure that the
content negotiation framework does not result in the loss
of data that would otherwise be received and displayed.
Having requested alternative data and not displayed the original
data, the receiver MUST remember this fact and be prepared to take
corrective action if alternative data is not received within a
reasonable time (e.g. if the MDN response or transmission of
alternative data is lost in transit).
Corrective action might be any of the following:
(a) re-send the MDN response, and continue waiting for an
alternative,
(b) present the data originally supplied (if it is still
available), or
(c) generate an error response indicating loss of data.
On concluding that alternative data is not forthcoming, the
preferred option is (b), but this may not be possible for receivers
with limited memory.
Klyne, Iwazaki, Crocker Internet draft [Page 16]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
See Appendix A for further discussion of receiver behaviour
options.
NOTE: A cache control indicator on recipient
capabilities has been considered, but is not included in
this specification. (Sometimes, a recipient may want to
offer certain capabilities only under certain
circumstances, and does not wish them to be remembered
for future use; e.g. not wanting to receive colour
images for routine communications.)
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 declared 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 email 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. (In the exceptional
case that the response requesting an alternative data format does
not contain receiver capabilities, a baseline format should be
selected.)
If any part of the best available message data matching the
receiver capabilities is the same as that originally sent, it MUST
still be re-transmitted 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
SHOULD NOT include an 'Alternative-available' disposition
notification modifier.
Klyne, Iwazaki, Crocker Internet draft [Page 17]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 receiver
indicating the failure, containing an MDN request and including an
'Alternative-not-available' disposition notification modifier.
Any message sent to a receiver in response to a request for
alternative data MUST include an 'Original-Message-ID:' header [23]
containing the Original-message-ID value from the received
disposition notification message (which is the 'Message-ID:' from
the original message). This header serves to correlate the re-send
(or failure message) with the original message, and also to
distinguish a re-send from an original message.
3.4 Confirm receipt of resent message data
When resent data is received (indicated by presence of an
'original-message-ID:' header field), the receiver processes that
data and generates an MDN response indicating the final disposition
of the data received, and also indicating capabilities that may be
used for future messages, per RFC 2530 [2] and RFC 2532 [1].
If the re-send indicates that alternative data is no longer
available (by including an 'Alternative-not-available' disposition
notification modifier), and the receiver still holds the original
data sent, it should display or process the original data and send
an MDN response indicating the final disposition of that data.
Thus, the response to an 'Alternative-not-available' indication may
be a successful disposition notification.
If the re-send indicates that alternative data is no longer
available (by including an 'Alternative-not-available' disposition
notification modifier), and the receiver has discarded the original
data sent, it SHOULD:
(a) display or process the failure message received, OR
(b) construct and display a message indicating that message data
has been lost, preferably indicating the sender, time,
subject, message identifier and other information that may
help the recipient user to identify the missing message.
and send a message disposition response indicating a final message
disposition of "deleted".
Klyne, Iwazaki, Crocker Internet draft [Page 18]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
4. The Content-alternative header
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 =
<As defined for 'Filter' by RFC 2533 [6]>
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.
A content-alternative header is used with some MIME-encapsulated
data, and is interpreted in that context. The intent is to
indicate possible variations of that data, and it is not
necessarily expected to be a complete free-standing description of
a specific available data. Enough information should be provided
for a receiver to be able to decide whether or not the alternative
thus described (a) is likely to be an improvement over the actual
data provided, and (b) is likely to be processable by the receiver.
Thus, when interpreting an Content-alternative header value, a
receiver may assume that features not explicitly mentioned are not
different in the indicated alternative from the supplied data. For
example, if a Content-alternative header does not mention an
alternative MIME content-type, the receiver may assume that the
available alternative uses the same content-type as the supplied
data.
See also the example in section 8.4.
5. The Original-Message-ID message header
The 'Original-Message-ID' header is used to correlate any message
response or re-send with the original message to which it relates
(see also sections 3.2.3, 3.3). A re-send is distinct from the
original message, so it MUST have its own unique Message-ID value
(per RFC 2822, section 3.6.4).
Klyne, Iwazaki, Crocker Internet draft [Page 19]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
The syntax for this header is:
"Original-Message-ID" ":" msg-id
where 'msg-id' is defined by RFC2822 as:
msg-id = "<" id-left "@" id-right ">"
The 'msg-id' value given must be identical to that supplied in the
Message-ID: header of the original message for which the current
message is a response or re-send.
6. MDN extension for alternative data
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].
6.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"
Klyne, Iwazaki, Crocker Internet draft [Page 20]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Thus, a sender includes the following headers to indicate that
alternative message data is available:
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-available=optional,<lifetime>
where <lifetime> is "transient" or "permanent", indicating whether
the alternative data will be made available for just a short while,
or for an indefinite period. A value of "permanent" indicates that
the data is held on long term storage and can be expected to be
available for at least several days, and probably weeks or months.
A value of "transient" indicates that the alternative data may be
discarded at any time, though it would normally be held for the
expected duration of a message transaction.
NOTE: the <lifetime> parameter is provided to help low-
memory receivers (which are unable to store received
data) avoid loss of information through requesting an
alternative data format that may become unavailable.
A message sent with a request for an MDN with an 'Alternative-
available' option MUST also contain a 'Message-ID:' header field
[20].
6.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"
Klyne, Iwazaki, Crocker Internet draft [Page 21]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
When a receiver requests that an alternative format be sent, it
sends a message disposition notification message containing the
following disposition field:
Disposition:
<action-mode>/<sending-mode>
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.
An MDN response containing an 'alternative-preferred' disposition
modifier SHOULD also contain a 'Media-accept-features:' field [2]
indicating the capabilities that the sender should use in selecting
an alternative form of message data. If this field is not
supplied, the sender should assume some baseline feature
capabilities. Receiver capabilities supplied with an alternative-
preferred disposition notification MUST NOT be cached: they may
apply to the current transaction only.
6.3 Indicating alternative data is no longer available
A sender that receives a request for alternative data that is no
longer available, or is unable to provide alternative data matching
the receiver's capabilities, MUST respond with an indication of
this fact, sending a message containing data describing the
failure.
Such a message MUST specify the MDN 'Disposition-Notification-To:'
header [4], accompanied by a 'Disposition-Notification-Options:'
header containing the parameter 'Alternative-not-available' with an
importance value of 'required'.
This specification defines a value for 'attribute' to be used in an
MDN 'Disposition-Notification-Options:' header [4]:
attribute =/ "Alternative-not-available"
Klyne, Iwazaki, Crocker Internet draft [Page 22]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Thus, a sender includes the following headers to indicate that
alternative message data previously offered is no longer available:
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-not-available=required,(TRUE)
A message sent with a request for an MDN with an 'Alternative-not-
available' option MUST also contain an 'Original-message-ID:'
header [23] containg the value from the 'Message-ID:' header of the
original message.
6.4 Indicating loss of original data
This specification defines an additional value for 'disposition-
modifier-extension':
disposition-modifier-extension =/
"original-lost"
When a receiver loses message data because it lack memory to store
the original while waiting for an alternative to be sent, it sends
a message disposition notification containing the following field:
Disposition:
<action-mode>/<sending-mode>
deleted/original-lost
For example, an automatically generated response might contain:
Disposition:
automatic-action/MDN-sent-automatically,
deleted/original-lost
An MDN response containing an 'original-lost' disposition modifier
MUST also contain an 'Original-message-ID:' field [4] with the
'Message-ID:' value from the resent message, or from the original
message (if no re-send has been received).
6.5 Automatic sending of MDN responses
In sending an MDN response that requests alternative data, the
security concerns stated in RFC 2298 [4] (sections 2.1 and 6.2)
regarding automatic MDN responses must be respected. In
particular, 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.
Klyne, Iwazaki, Crocker Internet draft [Page 23]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
7. 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 email context,
any valid media features MAY be used.
For Internet fax, "image/tiff" is the assumed content-type for
message data. In particular, all Internet fax devices are presumed
to be capable of sending and receiving the baseline TIFF
capabilities [11,12]. When communication is between Internet fax
devices, this capability may be assumed. But when dealing with
devices that go beyond these capabilities defined for Internet fax
(e.g. generic email agents with fax capabilities) it would be
better not to assume fax capabilities, and for the negotiating
parties to be explicit with respect to all their capabilities.
It would be better if even Internet fax devices do not assume that
they are communicating with other such devices: when using
Internet email there is no reliable way to establish this fact.
Therefore, for any Internet fax device that may reasonably be
expected to exchange messages with any other email agent, it is
RECOMMENDED that Internet fax capabilities (such as image/tiff
baseline format handling) are not assumed but stated explcitly.
In particular, the 'Media-Accept-Features:' header in receiver MDN
responses SHOULD explicitly indicate (type="image/tiff") and
baseline TIFF capabilities, rather than just assuming that they are
understood.
8. Examples
8.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.
Klyne, Iwazaki, Crocker Internet draft [Page 24]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Sender's initial message:
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@mega.edu>
Disposition-Notification-To: Jane_Sender@huge.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
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) )
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--
Klyne, Iwazaki, Crocker Internet draft [Page 25]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Receiver sends MDN response to initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@mega.edu>
Message-Id: <199509200020.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@huge.com>
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 <Tom_Recipient@mega.edu> 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
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/mega.edu--
Klyne, Iwazaki, Crocker Internet draft [Page 26]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Sender's message with enhanced content:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200021.12345@huge.com>
Original-Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@mega.edu>
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 <Tom_Recipient@mega.edu>
Message-Id: <199509200022.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@huge.com>
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:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@mega.edu> 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 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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:
(& (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/mega.edu--
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@huge.com>
Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@mega.edu>
Disposition-Notification-To: Jane_Sender@huge.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ huge.com"
Klyne, Iwazaki, Crocker Internet draft [Page 28]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
--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 <Tom_Recipient@mega.edu>
Message-Id: <199509200022.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@huge.com>
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 <Tom_Recipient@mega.edu> 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 29]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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:
(& (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/mega.edu--
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 the 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.
Klyne, Iwazaki, Crocker Internet draft [Page 30]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Sender's initial message:
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@mega.edu>
Disposition-Notification-To: Jane_Sender@huge.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
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-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/ huge.com--
Receiver sends MDN response to initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@mega.edu>
Message-Id: <199509200020.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Negotiate Down
To: Jane Sender <Jane_Sender@huge.com>
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 <Tom_Recipient@mega.edu> with subject "Internet FAX
Full Mode Content Negotiation" has been received. An alternative
form of the message data is requested.
Klyne, Iwazaki, Crocker Internet draft [Page 31]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
--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
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/mega.edu--
Sender's message with baseline content:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200021.12345@huge.com>
Original-Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@mega.edu>
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-S message goes here]
--RAA14128.773615768/ huge.com--
Klyne, Iwazaki, Crocker Internet draft [Page 32]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Receiver sends MDN confirmation of impoverished message content:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@mega.edu>
Message-Id: <199509200022.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@huge.com>
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:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@mega.edu> 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-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615769/mega.edu--
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.
Klyne, Iwazaki, Crocker Internet draft [Page 33]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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@huge.com>
Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@mega.edu>
Disposition-Notification-To: Jane_Sender@huge.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
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) )
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/ huge.com--
Klyne, Iwazaki, Crocker Internet draft [Page 34]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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@mega.edu>
Message-Id: <199509200020.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@huge.com>
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 <Tom_Recipient@mega.edu> 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
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/mega.edu--
Klyne, Iwazaki, Crocker Internet draft [Page 35]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Resend with alternative content-type:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200021.12345@huge.com>
Original-Message-Id: <199509200019.12345@huge.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@mega.edu>
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: application/pdf
Content-Transfer-Encoding: base64
[PDF data goes here]
--RAA14128.773615768/ huge.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@mega.edu>
Message-Id: <199509200022.12345@mega.edu>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@huge.com>
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:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@mega.edu> 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 36]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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:
(| (& (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/mega.edu--
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 RFC
2298 [4], section 10.
Klyne, Iwazaki, Crocker Internet draft [Page 37]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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)
Klyne, Iwazaki, Crocker Internet draft [Page 38]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 RFC 2298 [4].
o Risks of negotiation: see the security considerations section
of RFC 2532 [1]; also of RFC 2703 [17], RFC 2506 [6] and RFC
2533 [5].
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 and Ted Hardie.
13. 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.
Klyne, Iwazaki, Crocker Internet draft [Page 39]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
[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] RFC 2938, "Indicating media features for MIME content"
Graham Klyne, Content Technologies
September 2000.
[8] 'Content-alternative' header (this memo, section 4)
[9] MDN extension for alternative data (this memo, section 6)
[10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF"
D. Crocker (editor), Internet Mail Consortium
P. Overell, Demon Internet Ltd.
November 1997.
[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.
Klyne, Iwazaki, Crocker Internet draft [Page 40]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
[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.)
[18] RFC 1891, "SMTP Service Extension for Delivery Status
Notifications"
K. Moore, University of Tennessee
January 1996.
[19] RFC 2821, "Simple Mail Transfer Protocol"
J. Klensin, AT&T Laboratories
April 2001.
[20] RFC 2822, "Internet Message Format"
Pete Resnick, Qualcomm Inc.
April 2001.
Klyne, Iwazaki, Crocker Internet draft [Page 41]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
[21] "Timely Delivery for Facsimile Using Internet Mail"
Graham Klyne, Baltimore Technologies
David Crocker, Brandenburg Consulting
Internet draft: <draft-ietf-fax-timely-delivery-02.txt>
Work in progress, February 2001.
[22] RFC 2119, "Key words for use in RFCs to Indicate Requirement
Levels"
S. Bradner, Harvard University
March 1997.
[23] 'Original-Message-ID' header for mail messages (this memo,
section 5)
[24] RFC 2913, "MIME Content Types in Media Feature Expressions"
Graham Klyne, Content Technologies
September 2000.
14. Authors' addresses
Graham Klyne (editor)
Baltimore Technologies - Content Security Group,
1310 Waterside,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 903 8000
Facsimile: +44 118 903 9000
Email: 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
Email: 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 42]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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.
Klyne, Iwazaki, Crocker Internet draft [Page 43]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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 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.)
Klyne, Iwazaki, Crocker Internet draft [Page 44]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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
receipient seing 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.
Klyne, Iwazaki, Crocker Internet draft [Page 45]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
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
Ephemaral 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
capabilties 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.
Klyne, Iwazaki, Crocker Internet draft [Page 46]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
While it may be OK for an unattended fax machine to perform
automated nagotiation, 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.
Klyne, Iwazaki, Crocker Internet draft [Page 47]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
Appendix C: 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 re-send
of alternative data; added requirement for
message-ID header; add discussion of receiver
options in case of insufficient memory.
03a 12-Sep-2000 Incorporate review comments. Move implementation
issues to appendix.
Klyne, Iwazaki, Crocker Internet draft [Page 48]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
03b 03-Oct-2000 Limit negotiation response to original addressees
(for now). Add use of Original-message-ID: header
to link re-send of alternative data to original
message. Add new disposition modifier option to
indicate alternatives previously offered are no
longer available. Add description of final
confirmation following re-send. Resolve many
small outstanding design decisions.
03c 05-Oct-2000 Include 'Original-Message-ID:' header in re-send
of first example.
04a 17-Oct-2000 Fix error in description of recipient processing
when data is no longer available.
04b 23-Jan-2001 Define Original-Message-ID header. Add negotiate-
down example. Flesh out text of IANA
considerations, internationalization
considerations and security considerations
sections. Write up outstanding implementation
issues (NOTE: transient receiver capabilities seem
to be addressed rather neatly by A.5).
04c 29-Jan-2001 Add note to discuss range of alternatives to be
disclosed using the Content-alternatives header.
05a 15-Feb-2001 Editorial changes. Added text to section 6.2
about cacheability of receiver capabilities
offered. Added text in 3.3 to cover exceptional
situation of request for alternative without
declared capabilities.
05b 20-Mar-2001 Editorial changes. Add text and example dealing
with possibility of sending alternative content
types. Updated references.
05c 30-May-2001 Expand the description of Content-alternative to
cover asusmptions that may be made concerning
features not explicitly mentioned. Sections 7,
8.3: some clarification of position with respect
to declaring baseline capabilities. Included
(type="image/tiff") in all receiver capability
examples, per section 7 recommendation. Updated
references to RFC 2821 and 2822.
REVIEW CHECKLIST:
(Points to be checked more widely on or before final review)
o Check the correct final disposition for lost message data (3.4)
Klyne, Iwazaki, Crocker Internet draft [Page 49]
Content Negotiation for Internet Fax 30 May 2001
<draft-ietf-fax-content-negotiation-05.txt>
o Editorial: IANA action for new message headers (section 9.1)?
Handling of internal document references.
Full copyright statement
Copyright (C) The Internet Society 2001. 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 50]
| PAFTECH AB 2003-2026 | 2026-04-23 11:48:28 |