RFC 3249
Implementers Guide for Facsimile Using Internet Mail
RFC 3249: Implementers Guide for Facsimile Using Internet Mail 📠✨
okay bestie, this is RFC 3249, the Implementers Guide for Facsimile Using Internet Mail 💖. It's from the Network Working Group, and it's an Informational doc (not a standard) dated September 2002 🌸. The authors are V. Cancio (Xerox Corporation), M. Moldovan (G3 Nova Technology, Inc.), H. Tamura (Ricoh Company, LTD.), and D. Wing (Cisco Systems) 👑. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈.
Status of this Memo 📜
This memo gives info to 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 (2002). All Rights Reserved.
Abstract 💜
This doc is for the implementers of software that uses email to send to fax machines, using RFC 2305 and 2532 📠. It's informational, so its guidelines don't supersede the referenced documents, just so we're clear 💅.
Table of Contents 🗺️
1. Introduction .................................................. 2
1.1 Organization of this document ................................ 2
1.2 Discussion of this document .................................. 2
2. Terminology ................................................... 3
3. Implementation Issues Specific to Simple Mode ................. 3
3.1 Simple Mode Fax Senders ...................................... 3
3.1.1 Multipart-alternative ...................................... 3
3.2 Simple Mode Fax Receivers .................................... 4
3.2.1 Multipart-alternative and Storage Capacity ................. 4
4. Implementation Issues Specific to Extended Mode ............... 4
4.1 Multipart-alternative ........................................ 4
4.2 Correlation of MDN with Original Message ..................... 4
4.3 Correlation of DSN with Original Message ..................... 5
4.4 Extended Mode Receivers ...................................... 5
4.4.1 Confirmation of receipt and processing from User Agents .... 5
4.4.1.1 Discrepancies in MDN [9] Interpretation .................. 5
4.4.1.2 Disposition-Type and body of message in MDN .............. 6
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases ...... 6
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers) ... 7
4.4.3.1 Success Case Example ..................................... 7
4.4.3.2 Failure Case Example 1 ................................... 9
4.4.3.3 Failure Case Example 2 ................................... 10
4.4.4 Extended Mode Receivers that are POP3/IMAP4 ................ 11
4.4.4.1 Success Case Example ..................................... 11
4.4.4.2 Failure Case Example ..................................... 12
4.4.5 Receiving Multiple Attachments ............................. 13
5. Implementation Issues Specific to the File Format ............. 13
5.1 IFD Placement & Profile-S Constraints ........................ 13
5.2 Precautions for implementers of RFC 2301 [4] ................. 14
5.2.1 Errors encountered during interoperability testing ......... 14
5.2.2 Color Gamut Considerations ................................. 14
5.2.3 File format Considerations ................................. 15
5.2.3.1 Considerations for greater reader flexibility ............ 15
5.2.3.2 Error considerations ..................................... 16
5.3 Content-Type for the file format ............................. 17
6. Implementation Issues for Internet Fax Addressing ............. 17
7. Security Considerations ....................................... 18
8. Acknowledgements .............................................. 18
9. References .................................................... 18
10. Authors' Addresses ........................................... 20
11. Full Copyright Statement ..................................... 211. Introduction ✨
This doc clarifies the published RFCs that standardize facsimile communications using Internet Email 📬. The goal is to stop implementations from going off-script in ways that cause interoperability problems 🙅♀️.
1.1 Organization of this document 🗂️
This document has 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 🎀. For terminology, see Section 2 💅.
1.2 Discussion of this document 💬
Discussion of this doc should happen on the Internet fax mailing list hosted by the Internet Mail Consortium (IMC) 🌈. Send comments about this document to ietf-fax@imc.org 💌.
To subscribe, send a message with the body 'subscribe' to "ietf-fax-request@imc.org" 🦋. Want the tea from before you joined? Check 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 - profile S or F of "File Format for Internet Fax" [4]
delivered as "image/tiff"
TIFF-FX - other profiles sent as "image/tiff-fx"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
Even though MIME compliance requires it (16, Section 5.1.4), some email client implementations can't correctly process messages with a MIME Content-Type of "multipart/alternative" 😭. If a sender isn't sure the recipient can 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 can't cache previous parts of a multipart/alternative message 💾. So for these devices to correctly process only one part of a multipart/alternative message, they may simply use the first part of a multipart/alternative message that they're capable of processing 🥺.
This behavior means that even if subsequent, higher-fidelity parts could have been processed, they won't be used 💀.
This behavior can cause user dissatisfaction, because when two high-fidelity but low-memory devices talk to each other, the lowest-fidelity part of the multipart/alternative gets processed 😤.
The solution is for the sender to figure out the recipient's capability and send only high-fidelity parts ✨. But a mechanism to determine recipient capabilities before an initial message is 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, lets a recipient include its capabilities in a delivery and/or a disposition notification 🔥. That's a DSN if the recipient device is an RFC 2532/ESMTP [3] compliant server, or 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 (attachment) was delivered and successfully processed is a big deal in 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 whether 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 whole point of getting a requested MDN acknowledgement from an Extended Mode recipient is to find out whether the file attachment that was sent was processed successfully or not 🫶. The attachment, not the body, is the facsimile message 📄. So an Extended Mode sender would expect, and it is recommended that the Extended Mode receiver send (with an MDN), an acknowledgement of whether the file attachment was successfully decoded and processed 💅.
Implementers of the Extended Mode [3] should be consistent in the feedback they give senders, whether that's in the form of error codes and/or failure/success 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 success or failure to decode the body-content part of the message and success or failure to decode a file attachment 😤. As a result, MDNs may come back that don't reflect whether the attached file was decoded, but rather whether the body-content part of the message was decoded 💀.
4.4.1.2 Disposition-Type and body of message in MDN ✨
okay bestie, so picture this 🎀 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 do the following, and I'm obsessed with how clear this is 💅
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".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 🧚 it's giving organisation, no cap.
Implementers MAY 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 🌈 so many options, iconic.
4.4.2. "Subject" of MDN and DSN in Success and Failure Cases 💌
okay so legacy e-mail apps don't parse the machine-readable headers, which means e-mail users depend on the human-readable parts of the MDN to figure out what kind of acknowledgement they got 🫶 super relatable tbh.
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 💖 literally the MVP.
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 👑 rules are rules, bestie.
4.4.3.1. Success Case Example ✨
In the following example the sender <jean@example.com> sends a message to the receiver <ifax@example.net>, which is an ESMTP server, and the receiver successfully decodes the message 🎀
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.netSMTP Sequence:
S: 220 example.net SMTP service ready
C: EHLO example.org
S: 250-example.net
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@example.com> ok
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@example.net
S: 250 2.1.5 Recipient <ifax@example.net> 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 GoodbyeDSN (to jean@example.com):
Date: Mon, 12 Dec 1999 19:01:57 +0900
From: postmaster@example.net
Message-ID: <19991212190157.01234@example.net>
To: jean@example.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@example.net.
--JUK199912121854870001
Content-type: message/delivery-status
Reporting-MTA: dns; example.net
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@example.net
Action: delivered
Status: 2.1.5 (Destination address valid)
Diagnostic-Code: smtp; 250 2.1.5
Recipient <ifax@example.net> 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 attached file AFTER it has received the SMTP message. The receiver then sends a 'failure' DSN 💀 oof.
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.netSMTP 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@example.com):
Date: Mon, 12 Dec 1999 19:31:20 +0900
From: postmaster@example.net
Message-ID: <19991212193120.87652@example.net>
To: jean@example.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@example.net resulted in an
error while attempting to decode the attached file.
--JUK199912121934240002
Content-type: message/delivery-status
Reporting-MTA: dns; example.net
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@example.net
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 file BEFORE it accepts the SMTP transmission.
SMTP sequence:
S: 220 example.net SMTP service ready
C: EHLO example.org
S: 250-example.net
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@example.com> ok
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@example.net
S: 250 2.1.5 Recipient <ifax@example.net> 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 GoodbyeDSN:
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 file that it sent. The MDN does NOT guarantee that the receiver displays, prints or saves the attached 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@example.com
Message-ID: <19991214174844.98765@example.com>
Subject: Your message was processed successfully. (MDN)
To: mary@example.net
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@example.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.example.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@example.com
Final-Recipient: rfc822;ken_recipient@example.com
Original-Message-ID: <19991214174010O.mary@example.net>
Disposition: automatic-action/MDN-sent-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 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 file 🙈 it's a lil bit of a plot hole, ngl.
Date: 14 Dec 1999 19:48:44 +0900
From: ken_recipient@example.com
Message-ID: <19991214194844.67325@example.com>
Subject: Your message has been rejected. (MDN)
To: mary@example.net
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@example.com". An error occurred while attempting
to decode the attached file[s]".
--84FD1011_IFAX
Content-Type: message/disposition-notification
Reporting-UA: ken-ifax.example.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@example.com
Final-Recipient: rfc822;ken_recipient@example.com
Original-Message-ID: <199912141823123.mary@example.net>
Disposition: automatic-action/MDN-sent-automatically;
processed/error
--84FD1011_IFAX
Content-Type: message/rfc822
[original message goes here]
--84FD1011_IFAX--4.4.5 Receiving Multiple Attachments 📎✨
okay so one email can carry multiple attachments 📎, and each one could be TIFF or TIFF-FX with totally different encodings or resolutions 🌈. they can also be mixed in with other file types. the whole thing is giving chaos, bestie 💀
there's currently no mechanism to identify, in a returned MDN, which attachments got decoded and which ones didn't 🙈. so the MDN can't tell you that part, ngl.
so 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 & 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 image file when using any of the Profiles defined in [4]. 🫶
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 [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 contains 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 are typically acquired 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 a 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:
- When acquiring input from a printed hardcopy source, without modification, the ITU-T Recommendation T.42 default
ITULABgamut should be appropriate. 🖨️✨ - For an sRGB source, the ITU-T Recommendation T.42 default
ITULABgamut 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 followingDecodevalues for 8-bit data:(0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255). 🖥️💖 - If the range of
L*a*b*value can be precomputed efficiently before converting toITULAB, then you may get the best result by picking a gamut that is custom to this range. 🧠👑
5.2.3 File format Considerations 📁
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 file, while writers ensure that 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 or 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 a white background image strip with a PhotometricInterpretation tag value of "1" (bit value of "0" means black) will result in the 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. 🛑
5.3 Content-Type for the file format 🏷️
The content-type "image/tiff" should only be used for Profiles S and F. Some existing implementations based on [4] may use "image/tiff" for other Profiles. However, this usage is now deprecated. Instead, the content-type "image/tiff-fx", whose registration is being defined in [17] should be used. 📮
To maximize interworking with devices that are only capable of rendering Profile S or F, "image/tiff" SHOULD be used when transporting Profile S or F. 🧃
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@example.com>but when used with ORCPT, the "=" and "+" must be encoded like this:
RCPT TO:<FAX=+390408565@example.com> \
ORCPT=FAX+3D+2B390408565@example.comNote 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 ✨
okay bestie, here's the whole citation squad, every single one, exactly as it was written 📚💅
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[2] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3205, March 1998.
[3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[4] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[5] Moore, K., "SMTP Service Extension for Delivery Status Notification", RFC 1891, January 1996.
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[9] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[10] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[12] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[13] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[14] Allocchio, C., "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000
[15] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, D., "SMTP Service Extensions", RFC 2846, November 1995
[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996
[17] McIntyre, L., Parsons, G. and J. Rafferty, "Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration", RFC 3250, September 2002.
[18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[19] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
10. Authors' Addresses 💌
the crew who made this happen, with all their contact deets 🦋
Vivian Cancio
103 Cuesta Drive
Los Altos, CA 94022
Phone: +1-650-948-3135
EMail: vcancio@pacbell.net
Mike Moldovan
G3 Nova Technology Inc.
5743 Corsa Avenue, Suite 122
Westlake Village, CA 91362
Phone: (818) 865-6600 Ext.113
EMail: mmoldovan@g3nova.com
Hiroshi Tamura
Ricoh Company, LTD.
1-3-6 Nakamagome, Ohta-ku
Tokyo 143-8555 Japan
Phone: +81-3-3777-8124
Fax: +81-3-5742-8859
EMail: tamura@toda.ricoh.co.jp
Dan Wing
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1-408-525-5314
Fax: +1-408-527-8083
EMail: dwing@cisco.com11. Full Copyright Statement 🔒
the legal bit, kept word for word because it's serious business 💅
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🫶
last but not least, the thank-yous 🌸
Funding for the RFC Editor function is currently provided by the
Internet Society.that's the whole RFC, bestie! 🌈✨
📦 where this page comes from
- ietf: rfc3249 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms