< draft-ietf-fax-implementers-guide-07.txt		draft-ietf-fax-implementers-guide-08.txt >
			A new Request for Comments is now available in online RFC libraries.
	IETF Fax Working Group Vivian Cancio		RFC 3249
	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
	4 April 2001
	Expires: October 2001
	Implementers Guide for Facsimile Using Internet Mail
	<draft-ietf-fax-implementers-guide-07.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.
	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 Color Gamut Considerations
	5.2.3 File format Considerations
	5.2.3.1 Considerations for greater reader flexibility
	5.2.3.2 Error considerations
	6. Implementation Issues for Internet Fax Addressing
	7. Security considerations
	8. Acknowledgements
	9. References
	10. Authors' addresses
	Full copyright statement
	Revision history
	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.
	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
	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.
	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.
	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:
	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
	--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
	--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
	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
	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
	--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
	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 Color Gamut Considerations
	The ITULAB encoding (PhotometricInterpretation = 10) allows choosing
	a gamut range for L*a*b* (see the TIFF field Decode), which in turn
	provides a way to place finer granularity on the integer values
	represented in this colorspace. But consequently, an inadequate
	gamut choice may cause a loss in the preservation of colors that
	don't fall within the space of colors bounded by the gamut. As such,
	it is worth commenting on this.
	The ITULAB default gamut, L [0,100] a [-85,85] b [-75,125], was
	chosen to accommodate most scan devices, which typically acquire from
	a hardcopy source. It wasn't chosen to deal with the range of color
	from camera input or sRGB monitor data. In fact, when dealing with
	images from the web and other display oriented sources, the color
	range for scanned hardcopy may likely be inadequate. It is important
	to use a gamut that matches the source of the image data.
	The following guidelines are recommended:
	1. When acquiring input from a printed hardcopy source, without
	modification, the ITU-T Recommendation T.42 default ITULAB gamut
	should be appropriate.
	2. For an sRGB source the ITU-T Recommendation T.42 default ITULAB
	gamut is not appropriate. A more appropriate gamut to consider is:
	L [0,100], a [-88,99] and b [-108.8,95.2]. These may be
	realized by using the following Decode values for 8-bit data:
	(0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255).
	3. If the range of L*a*b* value can be precomputed efficiently before
	converting to ITULAB, then you may get the best result by picking
	a gamut that is custom to this range.
	5.2.3 File format Considerations
	TIFF-FX implementers should make sure of the contents in the
	following two sections.
	5.2.3.1 Considerations for greater reader flexibility
	a) Readers are able to handle cases where IFD offsets point beyond
	the end of the TIFF-FX file, while writers ensure the IFD offset
	does not point beyond the end of the file.
	b) Readers are able to handle the first IFD offset being on a
	non-word boundary, while writers ensure that the first IFD offset
	is on a word boundary.
	c) Readers are flexible and able to accommodate: IFDs that are not
	presented in ascending page order; IFDs that are not placed at a
	location that precedes the image which the IFD describes; next IFD
	offsets that precede the current IFD, the current IFDs' field
	data, or the current IFDs' image data. Writers on the other hand
	should generate files with IFDs presented in ascending page order;
	IFDs placed at a location that precedes the image which the IFD
	describes; the next IFD should always follow the current IFD and
	all of its data.
	d) Writers generate tags with the appropriate type of data (for
	example RATIONAL instead of SRATIONAL). Readers are flexible
	with those types of misrepresentations that may be readily
	accommodated (for example SHORT instead of LONG) and lead to
	enhanced robustness.
	e) The appropriate count is associated with the tags (it is not 0
	and matches the tag requirement) while readers are flexible with
	these types of misrepresentations, which may be readily
	accommodated and lead to enhanced robustness.
	f) Tags appear in the correct order in the IFD and readers are
	flexible with these types of misrepresentations.
	5.2.3.2 Error considerations
	a) Readers only accept files with bytes 2-3 of the Image File Header
	equal to 42 (2Ah), the "magic number", as being valid TIFF-FX
	files, while writers only generate files with the appropriate
	magic number.
	b) Files are not generated with missing field entries, and readers
	reject any such files.
	c) The PageNumber value is based on the order within the Primary IFD
	chain. The ImageLayer values are based on the layer order and
	the image order within the layer respectively. Readers may reject
	the pages where the PageNumber or ImageLayer values are not
	consistent with the number of Primary IFDs, number of layers or
	number of images within the layers.
	d) Tags are unique within an IFD and readers may reject pages where
	this is not the case.
	e) Strip data does not overlap other file data and the reader may
	error appropriately.
	f) The strip offset does not point outside the file, under these
	conditions readers may reject the page where this is the case.
	g) The strip offset + StripByteCounts does not point outside the
	file, under these conditions the reader may error appropriately.
	h) Only one endian order is used within the file otherwise the
	rendered file will be corrupted.
	i) Tag values are consistent with the data contained within the
	image strip. For example, a bi-level black mark on white
	background image strip with PhotometricInterpretation tag value
	of "1" (bit value of "0" means black) will result in rendering of
	the image as white marks on a black background (reverse video).
	j) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters
	used for transformations are correct and compliant with the
	specification.
	k) The XPosition and YPosition values are consistent with the
	horizontal and vertical offsets of the top-left of the IFD from
	the top-left of the Primary IFD, in units of the resolution. To do
	otherwise results in misplacement of the rendered image.
	l) All combinations of tag values are correct, with special attention
	being given to the sets: XResolution, YResolution and
	ImageWidth; PhotometricInterpretation, SamplesPerPixel, and
	BitsPerSample. Any appropriate combinations will likely result in
	image distortion or an inability to render the image.
	m) The appropriate Compression types are used for the image layers
	within a Profile M file, such as a bi-level coder for the mask
	layers (i.e. odd numbered layers) and multi-level (color) coders
	for the background and foreground layers. Readers should reject
	files where this is not true.
	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].
	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.
	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
	[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
	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.
	Revision history
	[[[RFC editor: Please remove this section on publication]]]		Title: Implementers Guide for Facsimile Using Internet
			Mail
			Author(s): V. Cancio, M. Moldovan, H. Tamura, D. Wing
			Status: Informational
			Date: September 2002
			Mailbox: vcancio@pacbell.net, mmoldovan@g3nova.com,
			tamura@toda.ricoh.co.jp, dwing@cisco.com
			Pages: 21
			Characters: 40413
			Updates/Obsoletes/SeeAlso: None
	Version 2		I-D Tag: draft-ietf-fax-implementers-guide-08.txt
	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		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3249.txt
	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		This document is intended for the implementers of software that use
			email to send to facsimiles using RFC 2305 and 2532. This is an
			informational document and its guidelines do not supersede the
			referenced documents.
	Examples were improved and some of the text was improved or re-arranged.		This document is a product of the Internet Fax Working Group of the
	Section 6 was revised and simplified.		IETF.
	Version 5		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	1) Table of contents was changed according to real title		This announcement is sent to the IETF list and the RFC-DIST list.
	and re-labelling.		Requests to be added to or deleted from the IETF distribution list
	2) "e) Open implementation issues" text in section 1.1 was deleted.		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	The outline of this document are added in section 1.1.		added to or deleted from the RFC-DIST distribution list should
	3) Section 3.2.1 was modified for clarification.		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	4) Sub-Section 4.4 was re-labeled.
	5) Duplication description ("Disposition-Notification-To:") is deleted
	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		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	1) Addition that a "word" in TIFF is a 2-byte in Section 5.1.		To: rfc-info@RFC-EDITOR.ORG
	2) Section 5.2 was re-assembled and divided into new secion		Subject: getting rfcs
	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.
	Version 7		help: ways_to_get_rfcs
	1) Section 5.2.2 was modified for more clarification and re-arragened		Requests for special distribution should be addressed to either the
	as section 5.2.3.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	2) Add new section 5.2.2 about Color Gamut Considerations.		specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	992 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/