IETF fax WG G. Klyne (editor), Content Technologies
Internet draft R. Iwazaki, Toshiba TEC
D. Crocker, Brandenburg Consulting
19 October 1999
Expires: April 2000
Content Negotiation for Facsimile Using Internet Mail
<draft-ietf-fax-content-negotiation-00.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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract
This memo describes a mechanism for e-mail content negotiation that
allows Internet fax to transfer enhanced image data in a fashion
comparable with traditional facsimile.
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.
Klyne, Iwazaki, Crocker Internet draft [Page 1]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
Table of contents
1. Introduction.............................................3
1.1 Structure of this document ...........................3
1.2 Document terminology and conventions .................4
1.2.1 Terminology......................................4
1.2.2 Design goals.....................................4
1.2.3 Other document conventions.......................4
1.3 Discussion of this document ..........................5
2. Background and goals.....................................5
2.1 Background ...........................................5
2.1.1 Fax and e-mail...................................5
2.1.2 Current facilities in Internet Fax...............6
2.2 Closing the loop .....................................6
2.3 Goals for content negotiation ........................8
3. Framework for content negotiation........................9
3.1 Send data with an indication of alternatives .........11
3.1.1 Choice of default data format....................11
3.1.2 MDN request indicating alternate data formats....11
3.1.3 Information about alternative data formats.......12
3.2 Receiver options .....................................13
3.2.1 Alternatives not recognized......................13
3.2.2 Alternative not desired..........................13
3.2.3 Alternative preferred............................14
3.3 Send alternative message data ........................14
3.4 Implementation issues ................................15
4. The Content-alternative header...........................15
5. MDN extension for alternative data.......................16
5.1 Indicating readiness to send alternative data ........17
5.2 Indicating a preference for alternative data .........18
6. Internet Fax Considerations..............................19
7. Examples.................................................19
7.1 Sending enhanced Internet Fax image ..................19
7.2 Internet fax with initial data usable ................22
7.3 Other example??? .....................................24
8. IANA Considerations......................................24
9. Internationalization considerations......................24
10. Security considerations.................................24
11. Acknowledgements........................................24
12. References..............................................25
13. Authors' addresses......................................27
Appendix A: Amendment history...............................28
Full copyright statement....................................28
Klyne, Iwazaki, et al. Internet draft [Page 2]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
1. Introduction
This memo describes a mechanism for e-mail content negotiation to
provide an Internet fax facility comparable to that of traditional
facsimile.
"Extended Facsimile using Internet Mail" [1] specifies the transfer
of image data using Internet e-mail protocols. "Indicating
Supported Media Features Using Extensions to DSN and MDN" [2]
describes a mechanism for providing the sender with details of a
receiver's capabilities. The capability information thus provided,
if stored by the sender, can be used in subsequent transfers
between the same sender and receiver.
Many communications are one-off or infrequent transfers between a
given sender and receiver, and cannot benefit from this "do better
next time" approach.
This memo describes a mechanism that allows better-than-baseline
data formats to be sent in the first communication between a sender
and receiver. The same mechanism can also achieve a usable message
transfer when the sender has stored incorrect information about the
receiver's capabilities. It allows the sender of a message to
indicate availability of alternative formats, and the receiver to
indicate that an alternative format should be provided to replacing
the message data originally transmitted.
When the sender does not have correct information about a
receiver's capabilities, the mechanism described here may incur an
additional message round trip. An important goal of this mechanism
is to allow enough information to be provided to determine whether
or not the extra round trip is required.
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.
Klyne, Iwazaki, et al. Internet draft [Page 3]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
Section 5 describes extensions to the Message Disposition
Notification (MDN) framework [4] that are used to allow negotiation
between the communicating parties.
1.2 Document terminology and conventions
1.2.1 Terminology
Content negotiation
Capability exchange
Capability identification
[[[FROM RFC 2703]]]
[[[Others?]]]
1.2.2 Design goals
In discussing the goals for content negotiation, {1}, {2}, {3}
notation is used, per RFC 2542, "Terminology and Goals for Internet
Fax" [3]. The meanings associated with these notations are:
{1} there is general agreement that this is a critical
characteristic of any definition of content negotiation for
Internet Fax.
{2} most believe that this is an important characteristic of
content negotiation for Internet Fax.
{3} there is general belief that this is a useful feature of
content negotiation for Internet Fax, but that other factors
might override; a definition that does not provide this
element is acceptable.
1.2.3 Other document conventions
NOTE: Comments like this provide additional nonessential
information about the rationale behind this document.
Such information is not needed for building a conformant
implementation, but may help those who wish to understand
the design in greater depth.
[[[Editorial comments and questions about outstanding issues are
provided in triple brackets like this. These working comments
should be resolved and removed prior to final publication.]]]
Klyne, Iwazaki, et al. Internet draft [Page 4]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
1.3 Discussion of this document
Discussion of this document should take place on the content
negotiation and media feature registration mailing list hosted by
the Internet Mail Consortium (IMC):
Please send comments regarding this document to:
ietf-fax@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-fax-request@imc.org".
To see what has gone on before you subscribed, please see the
mailing list archive at:
http://www.imc.org/ietf-fax/
2. Background and goals
2.1 Background
2.1.1 Fax and e-mail
One of the goals of the work to define a facsimile service using
Internet mail has been to deliver benefits of the traditional Group
3 Fax service in an e-mail environment. Traditional Group 3 Fax
leans heavily on the idea that an online exchange of information
discloses a receiver's capabilities to the sender before any
message data is transmitted.
By contrast, Internet mail has been developed to operate in a less
constrained fashion, without any expectation that the sender and
receiver will exchange information prior to message transfer. One
consequence of this is that all mail messages must contain some
kind of meaningful message data: messages that are sent simply to
elicit information from a receiving message handling agent are not
generally acceptable in the Internet mail environment.
To guarantee some level of interoperability, Group 3 Fax and
Internet mail rely on all receivers being able to deal with some
baseline format (i.e. a basic image format or plain ASCII text,
respectively). The role of capability exchange or content
negotation is to permit better-than baseline capabilities to be
employed where available.
Klyne, Iwazaki, et al. Internet draft [Page 5]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
One of challenges addressed by this specification is how to adapt
the e-mail environment to provide a fax-like service. A sender
must not make any a priori assumption that the receiver can
recognize anything other than a simple e-mail message. There are
some important uses of e-mail that are fundamentally incompatible
with the fax model of message passing and content negotiation
(notably mailing lists). So we need to have a way of recognizing
when content negotiation is possible, without breaking the existing
e-mail model.
2.1.2 Current facilities in Internet Fax
"Extended Facsimile using Internet Mail" [1] provides for limited
provision of receiver capability information to the sender of a
message, using an extension to Message Disposition Notifications
[2,4], employing media feature tags [5] and media feature
expressions [6].
This mechanism provides for receiver capabilities to be disclosed
after a message has been received and processed. This information
can be used for subsequent transmissions to the same receiver. But
many communications are one-off messages from a given sender to a
given receiver, and cannot benefit from this mechanism.
2.2 Closing the loop
Classic Internet mail is an "open loop" process: no information is
returned back to the point from which the message is sent. This
has been unkindly --but accurately-- characterized as "send and
pray", since it lacks confirmation.
Sending a message and obtaining confirmation that the message has
been received is a "closed loop" process: the confirmation sent
back to the sender creates a loop around which information is
passed.
Many Internet e-mail agents are not designed to participate in a
closed loop process, and thus have no responsibility to respond to
receipt of a message. Later additions to Internet standards,
notably Delivery Service Notification [18] and Message Disposition
Notification [4], specify means for certain confirmation responses
to be sent back to the sender, thereby closing the loop. However
conformance to these enhancements is optional and full deployment
is in the future.
DSN must be fully implemented by the entire infrastructure;
further when support is lacking, the message is still sent on in
open-loop fashion. Sometimes, transmission and delivery should,
instead, be aborted and the fact be reported to the sender.
Klyne, Iwazaki, et al. Internet draft [Page 6]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
Due to privacy considerations for end-users, MDN usage is entirely
voluntary.
Content negotiation is a closed loop function, and requires that
the recipient of a message makes some response to the sender.
Since content negotiation must retro-fit a closed-loop environment
over Internet mail's voluntary and high-latency environment, a
challenge for content negotiation in e-mail is to establish that
consenting parties can recognize a closed loop situation, and hence
their responsibilities to close the loop.
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 negotable 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, et al. Internet draft [Page 7]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.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 e-mail clients.
The term "interwork" used above means that the mechansism must
be introduced in a way that may be ignored by existing
systems, and systems enhanced to use the negotiation
mechanisms will behave in a fashion that is expected by
existing systems. (I.e. existing clients are not expected in
any way to participate in or be aware of content negotiation.)
(c) Must {1} avoid transmission of "administrative non messages".
(I.e. only messages that contain content for the end user may
be sent unless it is known that the receiving system will
interpret them, and not attempt to display them.) This
requirement has been stated very strongly by the e-mail
community.
This means that a sender must not assume that a receiver can
understand the capability exchange protocol elements, so must
always start by sending some meaningful message data.
(d) Avoid {1} multiple renderings of a message. In situations
where multiple versions of a message are transferred, the
receiver must be able to reliably decide a single version to
be displayed.
(e) Minimize {2} round trips needed to complete a transmission.
Ideally {3} every enhanced trasmission will result in simply
sending data that the recipient can process, and receiving a
confirmation response.
(f) The solution adopted should not {3} transmit multiple versions
of the same data. In particular, it must not {1} rely on
routinely sending multiple instances of the same data in a
single message.
Klyne, Iwazaki, et al. Internet draft [Page 8]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.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 applicable to other
Internet e-mail based applications; e.g. regular e-mail,
VPIM, 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 e-mail mechanisms should {3} be
used rather than inventing new ones. (It is clear that some
new mechanisms will be needed, but they should be defined
cautiously.)
(k) The mechanism should {2} be implementable in low memory
devices. That is, it should not depend on any party being
able to buffer arbitrary amounts of message data.
(It may not be possible to completely satisfy this goal in a
sending system. But if the sender does not have enough memory
to buffer some given message, it can choose to not offer
content negotiation.)
3. Framework for content negotiation
This section starts with an outline of the negotiation process, and
provides greater detail about each stage in following sub-sections.
1. Sender sends initial message data with an indication of
alternative formats available (section 3.1). Initial data may be
a baseline or other best guess of what the recipient can handle.
Klyne, Iwazaki, et al. Internet draft [Page 9]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.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).
[[[Discuss concept of "receiver request" (response
retransmission) -- is it a "request" or a "declaration"?]]]
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.
NOTE: the receiver does not choose the particular data
format to be received; that choice rests with the
sender. We find that this approach is simpler than
having the receiver choose an alternative, because it
builds upon existing mechanisms in e-mail, and follows
the same pattern as traditional Group 3 fax. Further, it
deals with situations where the range of alternatives may
be difficult to describe.
This approach is similar to server driven negotiation in
HTTP using "Accept" headers [13]. This is distinct to
the agent-driven style of negotiation provided for HTTP
as part of Transparent Content Negotiation [14], or which
might be constructed in e-mail using
"multipart/alternative" and "message/external-body" MIME
types [15].
[[[?Require use of Original-recipient header. Only receivers that
match this may request alternative data formats. This reinforces
the 1:1 nature of a negotiation transaction? (This is spec.ed for
gateways and may be inappropriate here.)]]]
[[[?Consider whether to handle case of forwarded message?]]]
Klyne, Iwazaki, et al. Internet draft [Page 10]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
[[[?To ensure consistency of results, require content-id with body
part to which alternative capabilities are attached, to be noted in
MDN response?]]]
3.1 Send data with an indication of alternatives
A sender that is prepared to provide alternative message data
formats sends:
(a) a default message data format,
(b) appropriate 'Content-features' header(s) [7] describing the
default message data sent,
(c) a request for Message Disposition Notification [4],
(d) an indication that it is prepared to send different message
data, using an 'Alternative-available' MDN option field [9],
and
(e) an indication of the alternative data formats available, in
the form of 'Content-alternative' header(s) [8].
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 proposed RESCAP protocol).
3.1.2 MDN request indicating alternate data formats
When a sender is indicating preparedness to send alternative
message data, it must request a Message Disposition Notification
(MDN) [4].
Klyne, Iwazaki, et al. Internet draft [Page 11]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
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].
3.1.3 Information about alternative data formats
A sender can provide information about the alternative message data
available by applying one or more 'Content-alternative' headers to
message body parts for which alternative data is available, each
indicating media features [5,6] of an available alternative.
The purpose of this information to allow a receiver to decide
whether any of the available alternatives are preferable, or likely
to be preferable, to the default message data provided.
Not every available alternative is required to be described in this
way, but the sender should include enough information to allow a
receiver to determine whether or not it can expect more useful
message data if it chooses to indicate a preference for some
alternative that matches its capabilities.
NOTE: this header is intended to be usable independently
of the MDN extension that indicates the sender is
prepared to send alternative formats. It might be used
with some completely different content negototiation
protocol that is nothing to do with e-mail or MDN.
Thus, the 'Content-alternative' header provides
information about alternative data formats without
actually indicating if and how they might be obtained.
Further, the 'Content-alternative' header applies to a
MIME body part, where the MDN 'Alternative-available'
option applies to the message as a whole.
The example sections of this memo shows how the 'Content-features:'
and 'Content-alternative:' MIME headers may be used to describe the
content provided and available alternatives.
[[[Q-factor values, per RFC 2533, in the 'Content-alternative:'
expressions might be used to distinguish between "definitive" and
"approximate" alternatives.]]]
Klyne, Iwazaki, et al. Internet draft [Page 12]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
[[[Expiration time on alternatives list. Else recipient is in non-
deterministic position. Also, cache control on recipient
capabilities?]]]
3.2 Receiver options
A negotiation-aware system receiving message data without an
indication of alternative data formats MUST process that message in
the same way as a standard Internet fax system or e-mail user
agent.
Given an indication of alternative data format options, the
receiver has three primary options:
(a) do not recognize the alternatives: passively accept what is
provided,
(b) do not prefer the alternatives: actively accept what is
provided, or
(c) prefer some alternative format.
3.2.1 Alternatives not recognized
This corresponds to the case that the receiver is a simple mode
Internet fax recipient [12], or a traditional e-mail user agent.
The receiver does not recognize the alternatives offered, or
chooses not to recognize them, and simply accepts the data as sent.
A standard MDN response [4] or an extended MDN response [2] MAY be
generated at the receiver's option.
3.2.2 Alternative not desired
The receiver does recognize the alternatives offered, but
specifically chooses to accept the data originally offered. An MDN
response SHOULD be sent indicating acceptance of the data and also
containing the receiver's capabilities.
This is similar to the defined behaviour of an Extended Internet
Fax receiver [1,2].
Klyne, Iwazaki, et al. Internet draft [Page 13]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
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.
The receiver recognizes that alternative data is available, and
based on the information provided determines that an alternative
format would be preferable. An MDN response MUST be sent
containing:
o an 'Alternative-preferred' disposition modifier [9] indicating
that some data format other than that originally sent is
preferred, and
o receiver capabilities, per RFC 2530 [2].
On sending such an MDN response, the receiver MAY discard the
message data provided, in the expectation that some alternative
will be sent.
[[[Need to address issues of receiver maintaining state;
specifically, what happens if the MDN response is lost in transit?
If the receiver does not maintain state then the original message
data is effectively lost, but the sender cannot infer this from the
lack of response. If the receiver does maintain state, it can (a)
resend the MDN response, (b) generate an error response indicating
loss of data, (c) present the data originally supplied (if it is
still available). Option (c) is incompatible with a low-memory
receiver.]]]
3.3 Send alternative message data
Having offered to provide alternative data by including an
'Alternative-available' option with the original MDN request, and
on receipt of an MDN response indicating 'Alternative-preferred',
the sender SHOULD transmit alternative message data that best
matches the receiver's declared capabilities.
If the alternative message data is the same as that originally
sent, it SHOULD still be retransmitted because the receiver may
have discarded the original data. Any data sent as a result of
receiving an 'Alternative-preferred' response should include an MDN
request but not an 'Alternative-available' option.
If the sender is no longer able to send message data for any
reason, it MUST send a message to the receiver indicating a failed
transfer. It SHOULD also generate a report for the sender
indicating the failure.
Klyne, Iwazaki, et al. Internet draft [Page 14]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
[[[Discuss this last paragraph.]]]
[[[The mechanisms are described above in terms of the entire
message. With MDN extensions that are being considered for finer-
grained disposition notification at the level of individual message
body parts (e.g. the separate parts of a MIME multipart/mixed),
this mechanism can be extended to provide independent negotiation
for each body part, because the 'Content-features:' and 'Content-
alternative:' can be applied to inner body parts.]]]
[[[Does it make sense to do a partial retransmission? I think this
would be a receiver option, based on which message parts it
indicates have been discarded. If it can buffer then partial
retransmission is sensible.]]]
3.4 Implementation issues
[[[TBD]]]
-- Sender state
-- Receiver state
-- Timeout of offer of alternatives
-- Partial vs whole-message resend
-- Recipient is fax machine vs e-mail UA
-- Reinforce situations where MDNs must not be auto-generated
-- Fax offramp issues
4. The Content-alternative header
[[[May be moved to a separate document.]]]
The 'Content-alternative:' header is a MIME header that can be
attached to a MIME body part to indicate availability of some
alternative form of the data it contains. This header does not, of
itself, indicate how the alternative form of data may be accessed.
Klyne, Iwazaki, et al. Internet draft [Page 15]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
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.
[[[Define 'ext-param' for feature cache control?]]]
[[[Should this be defined as comma-separated list, to allow
multiple values on a single header?]]]
[[[Need to consider how to express composite document capabilities,
specifically to assert a number of feature expressions that must be
simultaneously satisfied for a document to be processed, as in the
case of an MRC containing hi-res B/W and low-res colour. The
approach currently under consideration is a metalogic level
encapsulating media feature expressions]]]
[[[Discuss use with 'message/partial'?]]]
5. MDN extension for alternative data
[[[May be moved to a separate document]]]
Here, we define two extensions to the Message Disposition
Notification (MDN) protocol [4] to allow a sender to indicate
readiness to send alternative message data formats, and to allow a
receiver to indicate a preference for some alternative format.
Indication of what alternatives may be available or preferred are
not covered here. This functionality is provided by the 'Content-
alternative' MIME header [8] and "Indicating Supported Media
Features Using Extensions to DSN and MDN" [2].
Klyne, Iwazaki, et al. Internet draft [Page 16]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
5.1 Indicating readiness to send alternative data
A sender wishing to indicate its readiness to send alternative
message data formats must request an MDN response using the MDN
'Disposition-Notification-To:' header [4].
The MDN request is accompanied by a 'Disposition-Notification-
Options:' header containing the parameter 'Alternative-available'
with an importance value of 'optional'. (The significance of
'optional' is that receiving agents unaware of this option do not
generate inappropriate failure responses.)
This specification defines a value for 'attribute' to be used in an
MDN 'Message-Disposition-Options:' header [4]:
attribute =/ "Alternative-available"
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,(TRUE)
[[[Is the parameter value really mandatory? RFC2298 syntax says
so. If so, what value should be used (what variations might be
required). Think carefully, this is a solution looking for a
problem. For now, I would prefer the option value to be optional.
If the value is required, its syntax should not preclude useful
extensions later. Use parameter to indicate return mailbox? Note
that RFC2298 allows auto-response to a single mailbox only.]]]
A message sent with a request for an MDN with an 'Alternative-
available' option MUST also contain a 'Message-ID:' header field
[20].
Klyne, Iwazaki, et al. Internet draft [Page 17]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
5.2 Indicating a preference for alternative data
The MDN specification [4] defines a number of message disposition
options that may be reported by the receiver of a message:
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extension
This specification defines an additional value for 'disposition-
modifier-extension':
disposition-modifier-extension =/
"Alternative-preferred"
When a receiver discards message data because it prefers that an
alternative format be sent, it sends a message disposition
notification message containing the following disposition field:
Disposition:
<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.
[[[Discuss constraints on sending this response automatically.]]]
[[[Add E164 address type for fax offramp to fax machine as final
recipient?]]]
Klyne, Iwazaki, et al. Internet draft [Page 18]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
6. Internet Fax Considerations
Both sender and receiver parts of this specification involve the
use of media feature expressions. In the context of Internet fax,
any such expressions SHOULD employ feature tags defined by "Content
feature schema for Internet fax" [16]. In a wider e-mail context,
any valid media features MAY be used.
7. Examples
7.1 Sending enhanced Internet Fax image
An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image
to send to a receiver. The baseline for Internet fax is 200x200dpi
and MH image compression.
Sender's initial message:
Date: Wed,20 Sep 1995 00: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,[[[xxx]]]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ huge.com"
--RAA14128.773615765/ huge.com
Content-type: image/tiff; application=faxbw
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
Klyne, Iwazaki, et al. Internet draft [Page 19]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
Content-alternative:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
[TIFF-FX Profile-S message goes here]
--RAA14128.773615765/ huge.com--
Receiver sends MDN response to initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <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 19 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
Klyne, Iwazaki, et al. Internet draft [Page 20]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
Media-Accept-Features:
(& (color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615766/mega.edu--
Sender's message with enhanced content:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@huge.com>
Message-Id: <199509200021.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
Klyne, Iwazaki, et al. Internet draft [Page 21]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
The message sent on 1995 Sep 19 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)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/mega.edu--
7.2 Internet fax with initial data usable
This example shows how the second and subsequent transfers between
the systems in the previous example might be conducted. Using
knowledge gained from the previous exchange, the sender includes
profile-F data with its first contact.
Sender's initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Jane Sender <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,[[[xxx]]]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ huge.com"
Klyne, Iwazaki, et al. Internet draft [Page 22]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.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 19 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, et al. Internet draft [Page 23]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.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:
(& (color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/mega.edu--
7.3 Other example???
[[[Showing negotiate-down]]]
8. IANA Considerations
[[[TBD: MIME header and MDN extension registrations]]]
[[[See RFC 2298, section 10]]]
9. Internationalization considerations
[[[TBD?]]]
10. Security considerations
[[[TBD]]]
11. Acknowledgements
The basic structure of the negotiation described here was first
documented in an Internet Draft by Mr. Toru Maeda of Canon.
Klyne, Iwazaki, et al. Internet draft [Page 24]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
12. References
[1] RFC 2532, "Extended Facsimile using Internet Mail"
L. Masinter, Xerox Corporation
D. Wing, Cisco Systems
March 1999.
[2] RFC 2530, "Indicating Supported Media Features Using Extensions
to DSN and MDN"
D. Wing, Cisco Systems
March 1999.
[3] RFC 2542, "Terminology and Goals for Internet Fax"
L. Masinter, Xerox Corporation
March 1999.
[4] RFC 2298, "An Extensible Message Format for Message Disposition
Notifications"
R. Fajman, National Institutes of Health
March 1998.
[5] RFC 2506, "Media Feature Tag Registration Procedure"
Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard
Ted Hardie, NASA
March 1999.
[6] RFC 2533, "A syntax for describing media feature sets"
Graham Klyne, 5GM/Content Technologies
March 1999.
[7] "Indicating media features for MIME content"
Graham Klyne, 5GM/Content Technologies
Internet draft: <draft-ietf-conneg-content-features-01.txt>
Work in progress, April 1999.
[8] 'Content-alternative' header (this memo, section 4)
[9] MDN extension for alternative data (this memo, section 5)
[10] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF"
D. Crocker (editor), Internet Mail Consortium
P. Overell, Demon Internet Ltd.
November 1997.
Klyne, Iwazaki, et al. Internet draft [Page 25]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
[11] RFC 2301, "File format for Internet fax"
L. McIntyre,
R. Buckley,
D. Venable, Xerox Corporation
S. Zilles, Adobe Systems, Inc.
G. Parsons, Northern Telecom
J. Rafferty, Human Communications
March 1998.
[12] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail"
K. Toyoda
H. Ohno
J. Murai, WIDE Project
D. Wing, Cisco Systems
March 1998.
[13] RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1"
R. Fielding, UC Irvine
J. Gettys, Compaq/W3C
J. Mogul, Compaq
H. Frystyk, W3C/MIT
L. Masinter, Xerox
P. Leach, Microsoft
T. Berners-Lee, W3C/MIT
June 1999.
(Accept headers are described in section 14.1; section 12
discusses content negotiation possibilities in HTTP.)
[14] RFC 2295, "Transparent Content Negotiation in HTTP"
Koen Holtman, TUE
Andrew Mutz, Hewlett Packard
March 1998.
[15] RFC 2046, "Multipurpose Internet Mail Extensions (MIME)
Part 2: Media types"
N. Freed, Innosoft
N. Borenstein, First Virtual
November 1996.
[16] RFC 2531, "Content feature schema for Internet fax"
Graham Klyne, 5GM/Content Technologies
Lloyd McIntyre, Xerox Corporation
March 1998.
[17] RFC 2703, "Protocol-independent Content Negotiation Framework"
Graham Klyne, 5GM/Content Technologies
September 1999.
(This memo indicates terminology, framework and goals for content
negotiation independent of any particular transfer protocol with
which it may be deployed.)
Klyne, Iwazaki, et al. Internet draft [Page 26]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
[18] RFC 1891, "SMTP Service Extension for Delivery Status
Notifications"
K. Moore, University of Tennessee
January 1996.
[19] RFC 821, "Simple Mail Transfer Protocol"
Jonathan B. Postel, ISI/USC
August 1982.
[20] RFC 822, "Standard for the Format of ARPA Internet Text Messages"
David H. Crocker, University of Delaware
August 1982.
13. Authors' addresses
Graham Klyne (editor)
Content Technologies Ltd.
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG
Ryuji Iwazaki
TOSHIBA TEC CORPORATION
6-78, Minami-cho, Mishima-shi,
Shizuoka, 411-8520 Japan
Tel: +81 559 76 7507
Fax: +81 559 76 7725
E-mail: iwa@rdl.toshibatec.co.jp
D. Crocker
Brandenburg Consulting
675 Spruce Dr.
Sunnyvale, CA 94086 USA
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@brandenburg.com
Klyne, Iwazaki, et al. Internet draft [Page 27]
Content Negotiation for Internet Fax 19 October 1999
<draft-ietf-fax-content-negotiation-00c.txt>
Appendix A: Amendment history
00a 30-Sep-1999 Memo initially created.
00b 15-Oct-1999 Incorporated co-author material. Added examples.
Added background section about open- and closed-
loop operations. Cleaned up some text. Develop
section describing the MDN extensions. Complete
reference details.
00c 19-Oct-1999 Acknowledgement and editorial changes. Re-written
abstract and revised introductory text.
TODO:
o Review use of RFC 2119 language
Full copyright statement
Copyright (C) The Internet Society 1999. 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, et al. Internet draft [Page 28]
