GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3249

Network Working Group V. Cancio Request for Comments: 3249 Xerox Corporation Category: Informational M. Moldovan

                                              G3 Nova Technology, Inc.
                                                             H. Tamura
                                                   Ricoh Company, LTD.
                                                               D. Wing
                                                         Cisco Systems
                                                        September 2002
        Implementers Guide for Facsimile Using Internet Mail

Status of this Memo

 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 (2002).  All Rights Reserved.

Abstract

 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.

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

Cancio, et. al. Informational [Page 1] RFC 3249 Implementers Guide for Facsimile September 2002

 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 ..................................... 21

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

Cancio, et. al. Informational [Page 2] RFC 3249 Implementers Guide for Facsimile September 2002

 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          - 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

 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.

Cancio, et. al. Informational [Page 3] RFC 3249 Implementers Guide for Facsimile September 2002

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 parts.
 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.

Cancio, et. al. Informational [Page 4] RFC 3249 Implementers Guide for Facsimile September 2002

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 an important aspect of the extended mode of
 the 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 purpose of receiving a requested MDN acknowledgement from an
 Extended Mode recipient is the indication of success or failure to
 process the 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 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/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 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 file, but rather to
 decode the body-content part of the message.

Cancio, et. al. Informational [Page 5] RFC 3249 Implementers Guide for Facsimile September 2002

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)

Cancio, et. al. Informational [Page 6] RFC 3249 Implementers Guide for Facsimile September 2002

    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@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.net

Cancio, et. al. Informational [Page 7] RFC 3249 Implementers Guide for Facsimile September 2002

 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: 250 2.0.0 Message accepted
    C: QUIT
    S: 221 2.0.0 Goodbye
 DSN (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
  1. -JUK199912121854870001

Content-type: text/plain

    Your message (id MM123456) was successfully delivered
    to ifax@example.net.
  1. -JUK199912121854870001

Content-type: message/delivery-status

Cancio, et. al. Informational [Page 8] RFC 3249 Implementers Guide for Facsimile September 2002

    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
  1. -JUK199912121854870001

Content-type: message/rfc822

    [headers of returned message go here.]
  1. -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.
    example.com
     +-------+
     | Mail  |
     | User  |
     | Agent |
     +-------+
         |
         V
    +----------+      +--------+     +---------+
    |   Mail   +      |  Mail  |     |  Mail   |
    |Submission|----->|Transfer|---->|Transfer |
    |   Agent  |      | Agent  |     |  Agent  |
    +----------+      +--------+     +---------+
                      example.org    example.net
 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.

Cancio, et. al. Informational [Page 9] RFC 3249 Implementers Guide for Facsimile September 2002

 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
  1. -JUK199912121934240002

Content-type: text/plain

    Your message (id MM123456) to ifax@example.net resulted in an
    error while attempting to decode the attached file.
  1. -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
  1. -JUK199912121934240002

Content-type: message/rfc822

    [headers of returned message go here.]
  1. -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.

Cancio, et. al. Informational [Page 10] RFC 3249 Implementers Guide for Facsimile September 2002

 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 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 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.

Cancio, et. al. Informational [Page 11] RFC 3249 Implementers Guide for Facsimile September 2002

    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"
  1. -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.
  1. -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
  1. -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.
    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"

Cancio, et. al. Informational [Page 12] RFC 3249 Implementers Guide for Facsimile September 2002

  1. -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]".
  1. -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
  1. -84FD1011_IFAX

Content-Type: message/rfc822

    [original message goes here]
  1. -84FD1011_IFAX–

4.4.5 Receiving Multiple Attachments

 A received email message could contain multiple attachments and each
 distinct attachment could use TIFF or TIFF-FX with different
 encodings or resolutions, and these could be mixed with other file
 types.
 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 & 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

Cancio, et. al. Informational [Page 13] RFC 3249 Implementers Guide for Facsimile September 2002

    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.

Cancio, et. al. Informational [Page 14] RFC 3249 Implementers Guide for Facsimile September 2002

 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:
 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

 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.

Cancio, et. al. Informational [Page 15] RFC 3249 Implementers Guide for Facsimile September 2002

 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.

Cancio, et. al. Informational [Page 16] RFC 3249 Implementers Guide for Facsimile September 2002

 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.

Cancio, et. al. Informational [Page 17] RFC 3249 Implementers Guide for Facsimile September 2002

 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.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]  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.

Cancio, et. al. Informational [Page 18] RFC 3249 Implementers Guide for Facsimile September 2002

 [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.

Cancio, et. al. Informational [Page 19] RFC 3249 Implementers Guide for Facsimile September 2002

10. Authors' Addresses

 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.com

Cancio, et. al. Informational [Page 20] RFC 3249 Implementers Guide for Facsimile September 2002

11. Full Copyright Statement

 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

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Cancio, et. al. Informational [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3249.txt · Last modified: 2002/09/19 00:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki