One document matched: draft-ietf-fax-implementers-guide-06.txt
Differences from draft-ietf-fax-implementers-guide-05.txt
IETF Fax Working Group Vivian Cancio
Internet Draft RedCreek Communications,Inc.
Category: Work-in-progress Mike Moldovan
Intended Category: Informational G3Nova Technology, Inc.
Hiroshi Tamura
Ricoh Company, LTD.
Dan Wing
Cisco Systems
13 February 2001
Expires: September 2001
Implementers Guide for Facsimile Using Internet Mail
<draft-ietf-fax-implementers-guide-06.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.
[[INTENDED STATUS: This memo provides information for the Internet
community. It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.]]
Copyright Notice
Copyright (C) The Internet Society 2001. All Rights Reserved.
Cancio, Moldovan, Tamura, Wing [Page 1]
Implementers Guide Internet draft 9 February 2001
Abstract
This document is intended for the implementers of software which uses
email to send to facsimiles using RFC 2305 and 2532. This is an
informational document and its guidelines do not supersede the
referenced documents.
Table of contents
1. Introduction
1.1 Organization of this document
1.2 Discussion of this document
2. Terminology
3. Implementation Issues Specific to Simple Mode
3.1 Simple Mode Fax Senders
3.1.1 Multipart-alternative
3.2 Simple Mode Fax Receivers
3.2.1 Multipart-alternative and Storage Capacity
4. Implementation Issues Specific to Extended Mode
4.1 Multipart-alternative
4.2 Correlation of MDN with Original Message
4.3 Correlation of DSN with Original Message
4.4 Extended Mode Receivers
4.4.1 Confirmation of receipt and processing from User Agents
4.4.1.1 Discrepancies in MDN [9] Interpretation
4.4.1.2 Disposition-Type and body of message in MDN
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers)
4.4.3.1 Success Case Example
4.4.3.2 Failure Case Example 1
4.4.3.3 Failure Case Example 2
4.4.4 Extended Mode Receivers that are POP3/IMAP4
4.4.4.1 Success Case Example
4.4.4.2 Failure Case Example
4.4.5 Receiving Multiple TIFF-FX Attachments
5. Implementation Issues Specific to the File Format
5.1 IFD Placement in TIFF file & Profile-S Constraints
5.2 Precautions for implementers of RFC 2301 [4]
5.2.1 Errors encountered during interoperability testing
5.2.2 Items that require particular attention
6. Implementation Issues for Internet Fax Addressing
7. Security considerations
8. Acknowledgements
9. References
10. Authors' addresses
Full copyright statement
Revision history
Cancio, Moldovan, Tamura, Wing [Page 2]
Implementers Guide Internet draft 9 February 2001
1. Introduction
This document clarifies published RFCs which standardize facsimile
communications using Internet Email. The intent is to prevent
implementations that deviate in such a way as to cause
interoperability problems.
1.1 Organization of this document
This document contains four sections that clarify, in order, the
handling of simple mode fax messages, extended mode fax messages, the
file format, and the internet addressing of fax recipients.
See Section 2 for terminology.
1.2 Discussion of this document
Discussion of this document should take place on the Internet fax
mailing list hosted by the Internet Mail Consortium (IMC). Please
send comments regarding this document to:
ietf-fax@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-fax-request@imc.org".
To see what has gone on before you subscribed, please see the mailing
list archive at:
http://www.imc.org/ietf-fax/
2. Terminology
The following terms are used throughout this document:
DSN - RFC 1894, "An Extensible Message Format for
Delivery Status Notifications" [7]
Extended Mode - RFC 2532, "Extended Facsimile Using
Internet Mail" [3]
MDN - RFC 2298, "An Extensible Message Format for
Message Disposition Notifications" [9]
Simple Mode - RFC 2305, "A Simple Mode of Facsimile
Using Internet Mail" [2]
TIFF-FX - RFC 2301, "File Format for Internet Fax" [4]
In examples, "C:" is used to indicate lines sent by the client, and
"S:" to indicate those sent by the server.
Cancio, Moldovan, Tamura, Wing [Page 3]
Implementers Guide Internet draft 9 February 2001
3. Implementation Issues Specific to Simple Mode
Issues specific to Simple Mode [2] are described below:
3.1 Simple Mode Fax Senders
3.1.1 Multipart/alternative
Although a requirement of MIME compliance (16, Section 5.1.4), some
email client implementations are not capable of correctly processing
messages with a MIME Content-Type of "multipart/alternative". If a
sender is unsure if the recipient is able to correctly process a
message with a Content-Type of "multipart/alternative", the sender
should assume the worst and not use this MIME Content-Type.
3.2 Simple Mode Fax Receivers
3.2.1 Multipart/alternative and Storage Capacity
Devices with little storage capacity are unable to cache previous
parts of a multipart/alternative message. In order for such devices
to correctly process only one part of a multipart/alternative
message, such devices may simply use the first part of a
multipart/alternative message it is capable of processing.
This behavior means that even if subsequent, higher-fidelity parts
could have been processed they will not be used.
This behavior can cause user dissatisfaction because when two high-
fidelity but low-memory devices are used with each other, the
lowest-fidelity part of the multipart/alternative will be processed.
The solution to this problem is for the sender to determine the
capability of the recipient and send only high fidelity. However a
mechanism to determine the recipient capabilities prior to an initial
message sent to the recipient doesn't yet exist on the Internet.
After an initial message is sent, the Extended Mode mechanism
described in RFC 2532 [3], Section 3.3 enables a recipient to include
its capabilities in a delivery and/or a disposition notification: in
a DSN if the recipient device is an RFC 2532/ESMTP [3] compliant
server or in an MDN if the recipient is a User Agent.
4. Implementation Issues Specific to Extended Mode
Issues specific to Extended Mode [3] fax are described below. Note
that any Extended Mode device also needs to consider issues specific
Cancio, Moldovan, Tamura, Wing [Page 4]
Implementers Guide Internet draft 9 February 2001
to Simple Mode (Section 3 of this document).
4.1 Multipart/Alternative
Sections 3.1.1 and 3.2.1 are also applicable to this mode.
4.2. Correlation of MDN with Original Message
To re-iterate a paragraph from section 2.1, RFC 2298 [9]:
A message that contains a Disposition-Notification-To header
SHOULD also contain a Message-ID header as specified in RFC 822
[10]. This will permit automatic correlation of MDNs with original
messages by user agents.
4.3 Correlation of DSN with Original Message
Similar to the requirement to correlate an MDN, above, DSNs also need
to be correlated. This is best done using the ENVID parameter in the
"MAIL" command. See Sections 3 and 5.4 of RFC 1891 [5] for details.
4.4 Extended Mode Receivers
Confirmation that the facsimile image (TIFF-FX attachment) was
delivered and successfully processed is an important aspect of the
extended mode of facsimile using Internet mail. This section
describes implementation issues with several types of confirmations.
4.4.1 Confirmation of receipt and processing from User Agents
When a message is received with the "Disposition-Notification-To"
header and the receiver has determined if the message can be
processed, it may generate a:
a) Negative MDN in case of error, or
b) Positive MDN in case of success
The purpose of receiving a requested MDN acknowledgement from an
Extended Mode recipient is the indication of success or failure to
process the TIFF-FX file attachment that was sent. The attachment,
not the body, constitutes the facsimile message. Therefore an
Extended Mode sender would expect, and it is recommended that the
Extended Mode receiver send (with an MDN), an acknowledgement of the
success or failure to decode and process the TIFF file attachment.
Implementers of the Extended Mode [3] should be consistent in the
feedback provided to senders in the form of error codes and/or
failure/successful messages.
Cancio, Moldovan, Tamura, Wing [Page 5]
Implementers Guide Internet draft 9 February 2001
4.4.1.1 Discrepancies in MDN [9] Interpretation
An Extended Mode sender must be aware that RFC 2298 [9] does not
distinguish between the success or failure to decode the body-content
part of the message and the success or failure to decode a file
attachment. Consequently MDNs may be received which do not reflect
the success or failure to decode the attached TIFF-FX file, but
rather to decode the body-content part of the message.
4.4.1.2 Disposition-Type and body of message in MDN
If the receiver of an MDN request is an RFC 2532 compliant device
that automatically prints the received Internet mail messages and
attachments, or forwards the attachment via GSTN fax, it should, in
the case of success:
a) Use a "disposition-type" of "dispatched" (with no "disposition-
modifier") in the MDN, and
b) Use text similar to the following in the body of the message:
"This is a Return Receipt for the mail that you sent to [above, or
below, or this address, etc]. The message and attached files[s] may
have been printed, faxed or saved. This is no guarantee that the
message has been read or understood".
and in the case of failure:
a) Use a "disposition-type" of "processed" and disposition-modifier
of "error", and
b) Use text similar to the following in the body of the message:
"This is a Return Receipt for the mail that you sent to [above, or
below, or this address, etc]. An error occurred while attempting to
decode the attached file[s]".
This recommendation adheres to the definition in RFC 2298 [9] and
helps to distinguish the returned MDNs for proper handling.
Implementers may wish to consider sending messages in the language of
the sender (by utilizing a header field from the original message) or
including multiple languages by using multipart/alternative for the
text portion of the MDN.
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases
Because legacy e-mail applications do not parse the machine-readable
headers, e- mail users depend on the human-readable parts of the MDN
to recognize the type of acknowledgement that is received.
Cancio, Moldovan, Tamura, Wing [Page 6]
Implementers Guide Internet draft 9 February 2001
Examples:
MDN:
Subject: Your message was processed successfully. (MDN)
Subject: Your message has been rejected. (MDN)
DSN:
Subject: Your message was delivered successfully. (DSN)
Subject: Your message could not be delivered. (DSN)
Subject: Your message is delayed. (DSN)
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers)
SMTP server-based implementations are strongly encouraged to
implement the "SMTP Service Extension for Returning Enhanced Error
Codes" [8]. This standard is easy to implement and it allows detailed
standardized success and error indications to be returned to the
sender by the submitting MTA.
The following examples are provided as illustration only. They should
not be interpreted as limiting the protocol or the DSN form. If the
examples conflict with the definitions in the standards (RFC
1891[5]/1893[6]/1894[7]/2034[8]), the standards take precedence.
4.4.3.1 Success Case Example
In the following example the sender <jean@water.line.com> sends a
message to the receiver <ifax@copper.point.com> which is an ESMTP
server and the receiver successfully decodes the message.
water.line.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
foo.com copper.point.com
SMTP Sequence:
Cancio, Moldovan, Tamura, Wing [Page 7]
Implementers Guide Internet draft 9 February 2001
S: 220 copper.point.com SMTP service ready
C: EHLO foo.com
S: 250-copper.point.com
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@water.line.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@water.line.com> ok
C: RCPT TO:<ifax@copper.point.com> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@copper.point.com
S: 250 2.1.5 Recipient <ifax@copper.point.com> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
C:
C: [Message goes here.]
C:
C: .
S: 250 2.0.0 Message accepted
C: QUIT
S: 221 2.0.0 Goodbye
DSN (to jean@water.line.com):
Date: Mon, 12 Dec 1999 19:01:57 +0900
From: postmaster@copper.point.com
Message-ID: <19991212190157.01234@copper.point.com>
To: jean@water.line.com
Subject: Your message was delivered successfully. (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121854870001
--JUK199912121854870001
Content-type: text/plain
Your message (id MM123456) was successfully delivered
to ifax@copper.point.com.
--JUK199912121854870001
Content-type: message/delivery-status
Reporting-MTA: dns; copper.point.com
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@copper.point.com
Action: delivered
Status: 2.1.5 (Destination address valid)
Diagnostic-Code: smtp; 250 2.1.5
Recipient <ifax@copper.point.com> ok
Cancio, Moldovan, Tamura, Wing [Page 8]
Implementers Guide Internet draft 9 February 2001
--JUK199912121854870001
Content-type: message/rfc822
[headers of returned message go here.]
--JUK199912121854870001--
4.4.3.2 Failure Case Example 1
In this example the receiver determines it is unable to decode the
TIFF file AFTER it has received the SMTP message. The receiver then
sends a 'failure' DSN.
water.line.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
foo.com copper.point.com
SMTP Sequence:
This is the same as the case a). After the sequence, a decode
error occurs at the receiver, so instead of a 'success' DSN, a
'failure' DSN is sent.
DSN (to jean@water.line.com):
Date: Mon, 12 Dec 1999 19:31:20 +0900
From: postmaster@copper.point.com
Message-ID: <19991212193120.87652@copper.point.com>
To: jean@water.line.com
Subject: Your message could not be delivered. (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121934240002
Cancio, Moldovan, Tamura, Wing [Page 9]
Implementers Guide Internet draft 9 February 2001
--JUK199912121934240002
Content-type: text/plain
Your message (id MM123456) to ifax@copper.point.com resulted
in an error while attempting to decode the attached file.
--JUK199912121934240002
Content-type: message/delivery-status
Reporting-MTA: dns; copper.point.com
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@copper.point.com
Action: Failed
Status: 5.6.1 (Media not supported)
Diagnostic-Code: smtp; 554 5.6.1 Decode error
--JUK199912121934240002
Content-type: message/rfc822
[headers of returned message go here.]
--JUK199912121934240002--
4.4.3.3 Failure Case Example 2
In this example the receiver determines it is unable to decode the
attached TIFF file BEFORE it accepts the SMTP transmission.
SMTP sequence:
S: 220 copper.point.com SMTP service ready
C: EHLO foo.com
S: 250-copper.point.com
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@water.line.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@water.line.com> ok
C: RCPT TO:<ifax@copper.point.com> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@copper.point.com
S: 250 2.1.5 Recipient <ifax@copper.point.com> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
C:
C: [Message goes here.]
C:
C: .
S: 554 5.6.1 Media not supported
C: QUIT
Cancio, Moldovan, Tamura, Wing [Page 10]
Implementers Guide Internet draft 9 February 2001
S: 221 2.0.0 Goodbye
DSN:
Note: In this case, the previous MTA generates the DSN that is
forwarded to the original sender. The receiving MTA has not
accepted delivery and therefore can not generate a DSN.
4.4.4 Extended Mode Receivers that are POP3/IMAP4
NOTE: This document does not define new disposition-types or
disposition-modifiers. Those used below are defined in RFC
2298[9]. This section provides examples on how POP3/IMAP4 devices
may use the already defined values.
These examples are provided as illustration only. They should not be
interpreted as limiting the protocol or the MDN form. If the examples
conflict with the MDN [9] standard, the standard takes precedence.
4.4.4.1 Success Case Example
If the original sender receives an MDN which has "displayed",
"dispatched" or "processed" disposition-type without disposition-
modifier, the receiver may have received or decoded the attached
TIFF-FX file that it sent. The MDN does not guarantee that the
receiver displays, prints or saves the attached TIFF-FX file. See
Section 4.4.1.1, Discrepancies in MDN Interpretation.
NOTE: This example does not include the third component of the
MDN.
Date: 14 Dec 1999 17:48:44 +0900
From: ken_recipient@bronze.dot.com
Message-ID: <19991214174844.98765@silver.dot.com>
Subject: Your message was processed successfully. (MDN)
To: mary@silver.dot.com
Mime-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification; boundary="61FD1001_IFAX"
--61FD1001_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to
"ken_recipient@bronze.dot.com". The message and attached files may
have been printed, faxed or saved. This is no guarantee that the
Cancio, Moldovan, Tamura, Wing [Page 11]
Implementers Guide Internet draft 9 February 2001
message has been read or understood.
--61FD1001_IFAX
Content-Type: message/disposition-notification
Reporting-UA: ken-ifax.bronze.dot.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@bronze.dot.com
Final-Recipient: rfc822;ken_recipient@bronze.dot.com
Original-Message-ID: <19991214174010O.mary@silver.dot.com>
Disposition: automatic-action/MDN-send-automatically; dispatched
--61FD1001_IFAX--
4.4.4.2 Failure Case Example
If the original sender receives an MDN with an "error" or "warning"
disposition-modifier, it is possible that the receiver could not
receive or decode the attached TIFF-FX file. Currently there is no
mechanism to associate the disposition-type with the handling of the
main content body of the message or the attached TIFF-FX file.
Date: 14 Dec 1999 19:48:44 +0900
From: ken_recipient@bronze.dot.com
Message-ID: <19991214194844.67325@silver.dot.com>
Subject: Your message has been rejected. (MDN)
To: mary@silver.dot.com
Mime-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification; boundary="84FD1011_IFAX"
--84FD1011_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to
"ken_recipient@bronze.dot.com". An error occurred
while attempting to decode the attached file[s]".
--84FD1011_IFAX
Content-Type: message/disposition-notification
Reporting-UA: ken-ifax.bronze.dot.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@bronze.dot.com
Final-Recipient: rfc822;ken_recipient@bronze.dot.com
Original-Message-ID: <199912141823123.mary@silver.dot.com>
Disposition: automatic-action/MDN-send-automatically;
processed/error
Cancio, Moldovan, Tamura, Wing [Page 12]
Implementers Guide Internet draft 9 February 2001
--84FD1011_IFAX
Content-Type: message/rfc822
[original message goes here]
--84FD1011_IFAX--
4.4.5 Receiving Multiple TIFF-FX Attachments
A received email message could contain multiple TIFF-FX attachments
and each distinct TIFF-FX file may use different encoding and/or
resolution. A received email message could include TIFF-FX attachment
and non-TIFF-FX attachments.
There is currently no mechanism to identify, in a returned MDN, the
attachments that were successfully decoded from those that could not
be decoded.
If the Extended Mode recipient is unable to decode any of the
attached files, it is recommended that the Extended Mode recipient
return a decoding error for the entire message.
5. Implementation Issues Specific to the File Format
5.1 IFD Placement in TIFF file & Profile-S Constraints
a) An IFD is required, by TIFF 6.0, to begin on a word boundary,
however, there is ambiguity with regard to the defined size of
a word. A word should be interpreted as a 2-byte quantity. This
recommendation is based on examination of Figure 1 and the
definition of IFD Entry, Bytes 8-11, found in Section 2 of
TIFF 6.0.
b) Low memory devices, which support resolutions greater than the
required Profile-S, may be memory-constrained such that those
devices cannot properly handle arbitrary placement of TIFF IFDs
within a TIFF file.
To interoperate with a receiver that is constrained, it is
strongly recommended that senders always place the IFD at the
beginning of the TIFF-FX file when using any of the Profiles
defined in RFC 2301.
5.2 Precautions for implementers of RFC 2301 [4]
5.2.1 Errors encountered during interoperability testing
Cancio, Moldovan, Tamura, Wing [Page 13]
Implementers Guide Internet draft 9 February 2001
The TIFF/RFC 2301 [4] errors listed below were encountered during
interoperability testing and are provided so that implementers of
TIFF readers and writers can take precautionary measures.
a) Although Profile S of TIFF-FX [4] specifies that files should
be in little-endian order, during testing it was found that
some common TIFF writers create big-endian files. If possible,
the TIFF reader should be coded to handle big-endian files.
TIFF writers should always create little-endian files to be
compliant with the standard and to allow interoperation with
memory-constrained devices.
b) Bytes 0-1 of the Image File Header are supposed to be set to "II"
(4949h) or "MM" (4d4dh) to indicate the byte order. During
testing, other values were encountered. Readers should handle
cases where the byte order field contain values other than "II"
or "MM", and writers should ensure the correct value is used.
5.2.2 Items that require particular attention
Implementers should make sure when generating a TIFF file that:
a) Bytes 2-3 of the Image File Header are the "magic number" and must
be equal to 42 (2Ah).
b) Readers should handle cases where IFD offsets point beyond the
end of the TIFF-FX file, and writers should ensure the IFD offset
does not point beyond the end of the file.
c) Readers should be coded to handle the first IFD offset being on a
non-word boundary, and writers should create the first IFD offset
on a word boundary.
d) Readers and writers should be careful to correctly handle IFDs
with other TIFF profile data such as strip image data and
header data.
e) Some readers have difficulties with IFDs in certain locations.
If possible, such reader implementations should be corrected
and TIFF writers should take extra precautions to not place
IFDs in these positions: IFD at the end of the profile, IFD
intercalated with another IFD data like XResolution, DateTime,
or strip image data.
f) All entries exist. Missing entries make it impossible to read
the image data.
g) Tags do not have the wrong type of data (for example RATIONAL
Cancio, Moldovan, Tamura, Wing [Page 14]
Implementers Guide Internet draft 9 February 2001
instead of SRATIONAL).
h) The count of type is correct for a specified tag (it is not null
and matches the tag ID).
i) Tags appear in the right order in the IFD.
j) Tags such as PageNumber or ImageLayer have values that match the
number of IFDs or the image data.
k) Tags are unique within an IFD.
l) Strip data does not overlap another file data.
m) The strip offset does not point outside the file.
n) The strip offset + StripByteCounts does not point outside the
file.
o) There is only one bit order (not more) specified for data storing.
p) To match the type of image tags and the strip data. For example,
if in case of a black and white image the
PhotometricInterpretation tag value is 0 (bit 0 means white) the
image will appear inverted.
q) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters
used for transformations are correct and compliant with the
specification.
r) The tag values for XPosition and YPosition are correct.
s) All combinations of tag values are correct. Special attention
should be given to the sets: XResolution, YResolution and
ImageWidth and PhotometricInterpretation, SamplesPerPixel,
and BitsPerSample.
t) When generating a TIFF Profile M, the compression used for the
layers is correct. Possible errors may include the Mask layer
not being compressed with a binary encoder and the Background
and Foreground layers not being compressed with a multi-level
(e.g. color) encoder.
6. Implementation Issues for Internet Fax Addressing
The "+" and "=" characters are valid within message headers, but must
be encoded within some ESMTP commands, most notably ORCPT [5].
Cancio, Moldovan, Tamura, Wing [Page 15]
Implementers Guide Internet draft 9 February 2001
Implementations must take special care that ORCPT (and other ESMTP
values) are properly encoded.
For example, the following header is valid as-is:
To: Home Fax <FAX=+390408565@faxmail.com>
but when used with ORCPT, the "=" and "+" must be encoded like this:
RCPT TO:<FAX=+390408565@faxmail.com> \
ORCPT=FAX+3D+2B390408565@faxmail.com
Note the "=" and "+" are valid inside the forward-path, but must be
encoded when used within the esmtp value.
See [5] for details on this encoding.
7. Security considerations
With regards to this document, Sections 5 in RFC 2305 [2] and Section
4 in RFC 2532 [3] apply.
8. Acknowledgements
The authors gratefully acknowledge the following persons who
contributed or made comments on earlier versions of this memo:
Claudio Allocchio, Richard Coles, Ryuji Iwazaki, Graham Klyne, James
Rafferty, Kensuke Yamada, Jutta Degener and Lloyd McIntyre.
9. References
[1] RFC 2542, "Terminology and Goals for Internet Fax",
Masinter, L.,
March 1999.
[2] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail",
Toyoda, K., Ohno, H., Murai, J. and Wing, D.,
March 1998.
[3] RFC 2532, "Extended Facsimile Using Internet Mail",
Masinter, L. and Wing, D.
March 1999.
[4] RFC 2301 "File Format for Internet Fax",
McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G.
Cancio, Moldovan, Tamura, Wing [Page 16]
Implementers Guide Internet draft 9 February 2001
and J. Rafferty,
March 1998.
[5] RFC 1891 "SMTP Service Extension for Delivery Status
Notification",
Moore, K.,
January 1996.
[6] RFC 1893 "Enhanced Mail System Status Codes",
Vaudreuil, G.,
January 1996.
[7] RFC 1894 "An Extensible Message Format for Delivery Status
Notifications",
Moore, K., Vaudreuil, G.,
January 1996.
[8] RFC 2034 "SMTP Service Extension for Returning Enhanced Error
Codes",
Freed, N.,
October 1996.
[9] RFC 2298 "An Extensible Message Format for Message Disposition
Notifications",
Fajman, R.
March 1998.
[10] RFC 822 "Standard for the Format of ARPA Internet Text
Messages",
Crocker. D.,
August 1982.
[11] RFC 821 "A Simple Mail Transfer Protocol",
Postel, D.,
August 1982.
[12] RFC 2303 "Minimal PSTN address format in Internet Mail",
Allocchio, C.
March 1998
[13] RFC 2304 "Minimal FAX address format in Internet Mail",
Allocchio, C.
March 1998
[14] RFC 2846 "GSTN Address Element Extensions in E-mail Services",
Allocchio, C.
June 2000
Cancio, Moldovan, Tamura, Wing [Page 17]
Implementers Guide Internet draft 9 February 2001
[15] RFC 1869 "SMTP Service Extensions",
Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.
November 1995
[16] RFC 2046 "Multipurpose Internet Mail Extensions (MIME) Part Two:
Media Types",
Freed, N., Borenstein, N.
November 1996
10. Authors' addresses
Vivian Cancio
RedCreek Communications, Inc.
3900 Newpark Mall Road
Newark, CA 94560
Telephone: +1-510-745-3905
Facsimile: +1-510-745-3999
Email: vcancio@redcreek.com
Mike Moldovan
G3 Nova Technology, Inc.
2794 Queens Way
Thousand Oaks, CA 91362 USA
Telephone: +1-805-245-4625
Facsimile: +1-805-245-4214
Email: mmoldovan@g3nova.com
Hiroshi Tamura
Ricoh Company, LTD.
2446 Toda, Atsugi City,
Kanagawa-Pref., 243-0023 Japan
Telephone: +81-46-228-1743
Facsimile: +81-46-228-7500
Email: tamura@toda.ricoh.co.jp
Dan Wing
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134-1706 USA
Telephone: +1-408-525-5314
Facsimile: +1-408-527-8083
Email: dwing@cisco.com
Cancio, Moldovan, Tamura, Wing [Page 18]
Implementers Guide Internet draft 9 February 2001
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.
Cancio, Moldovan, Tamura, Wing [Page 19]
Implementers Guide Internet draft 9 February 2001
Revision history
[[[RFC editor: Please remove this section on publication]]]
Version 2
1) Changed first sentence of 4.4.1.1
2) Added Sections: 4.4.1.2, 4.4.1.3, 4.4.1.4, 4.4.2.1, 4.4.2.2, 4.4.2.3,
4.4.3.1, 4.4.3.2 and 4.4.4
3) Deleted Sections: 6 and 7
4) Changed heading of Section 4.4.1
5) In examples: replaced ifax@water.line.com
with ifax@copper.point.com as well as other editorial changes
in the examples through the document.
6) In examples: changed text in subject field of DSN
7) In examples: changed text in subject field of MDN
8) In examples: changed text in text field of MDN
9) Reworded text through out the document
10) Replaced heading in 5.2.1
[to "TIFF Readers: Be Cautious with Headers"]
11) " " 5.2.2
[to "TIFF Writers: Be Cautious in use of IFD"]
Version 3
1) Section 5.2.1 and 5.2.2 were merged into 5.2; some of the
Paragraphs in Section 5 were reworded for clarity.
2) The RFC 821 was added to the Reference section.
3) The Reference section format was modified for consistency.
4) A new Section 6 was added.
5) References [9], [10], [11], [12], [13], [14] & [15] were added
in Section 6.
6) Description of [12], [13], [14] & [15] was added to
the Reference section
Version 4
Examples were improved and some of the text was improved or re-arranged.
Section 6 was revised and simplified.
Version 5
1) Table of contents was changed according to real title
and re-labelling.
2) "e) Open implementation issues" text in section 1.1 was deleted.
The outline of this document are added in section 1.1.
3) Section 3.2.1 was modified for clarification.
4) Sub-Section 4.4 was re-labeled.
5) Duplication description ("Disposition-Notification-To:") is deleted
Cancio, Moldovan, Tamura, Wing [Page 20]
Implementers Guide Internet draft 9 February 2001
in section 4.4.1
6) The title of section 4.4.1.2 was changed according to the content.
7) Recommended "Subject" texts were modified in section 4.4.2.
The title of this section was changed.
(*** It is the first main change in this version. ***)
According to this modification, the examples in section 4.4.3.1,
4.4.3.2, 4.4.4.1 and 4.4.4.2 were modified.
8) The mail contents of message in the sequence examples of section
4.4.3.1 and 4.4.3.3 was deleted.
9) TIFF "magic number" description was made simple in section 5.2 c).
(*** It is the second main change in this version. ***)
10) Typos and minor modification for clarification (i.e. editorial) were
corrected in section 4, 4.2, 4.4.1, 4.4.1.2, 4.4.3, 4.4.3.1,
4.4.3.2, 4.4.4, 4.4.4.1, 5.1, 5.2, 5.2.1, 5.2.2, 5.2.3, 5.2.4 and 6.
11) The contact information of one of authors was changed.
Version 6
1) Addition that a "word" in TIFF is a 2-byte in Section 5.1.
2) Section 5.2 was re-assembled and divided into new secion
5.2.1 and 5.2.2.
3) Some unfounded items(Child IFDs and GlobalParametersIFD)
in section 5.2 were deleted, according to a suggestion.
Cancio, Moldovan, Tamura, Wing [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 14:59:19 |