分享
 
 
 

RFC3249 - Implementers Guide for Facsimile Using Internet Mail

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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

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 - RFC1894, "An Extensible Message Format for

Delivery Status Notifications" [7]

Extended Mode - RFC2532, "Extended Facsimile Using

Internet Mail" [3]

MDN - RFC2298, "An Extensible Message Format for

Message Disposition Notifications" [9]

Simple Mode - RFC2305, "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.

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 RFC2532 [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 RFC2532/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, RFC2298 [9]:

A message that contains a Disposition-Notification-To header

SHOULD also contain a Message-ID header, as specified in RFC822

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

4.4.1.2 Disposition-Type and body of message in MDN

If the receiver of an MDN request is an RFC2532 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 RFC2298 [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@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

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

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

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.

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

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.

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

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

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 RFC2301 [4]

5.2.1 Errors encountered during interoperability testing

The TIFF/RFC2301 [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:

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.

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.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 RFC2305 [2] and Section

4 in RFC2532 [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", RFC3205, March 1998.

[3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet

Mail", RFC2532, March 1999.

[4] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G.

and J. Rafferty, "File Format for Internet Fax", RFC2301,

March 1998.

[5] Moore, K., "SMTP Service Extension for Delivery Status

Notification", RFC1891, January 1996.

[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC1893,

January 1996.

[7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for

Delivery Status Notifications", RFC1894, January 1996.

[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error

Codes", RFC2034, October 1996.

[9] Fajman, R., "An Extensible Message Format for Message

Disposition Notifications", RFC2298, March 1998.

[10] Crocker, D., "Standard for the Format of ARPA Internet Text

Messages", STD 11, RFC822, August 1982.

[11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC821,

August 1982.

[12] Allocchio, C., "Minimal GSTN address format in Internet Mail",

RFC3191, October 2001.

[13] Allocchio, C., "Minimal FAX address format in Internet Mail",

RFC3192, October 2001.

[14] Allocchio, C., "GSTN Address Element Extensions in E-mail

Services", RFC2846, June 2000

[15] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,

D., "SMTP Service Extensions", RFC2846, November 1995

[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part Two: Media Types", RFC2046, 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", RFC3250, September 2002.

[18] Klensin, J., "Simple Mail Transfer Protocol", RFC2821, April

2001.

[19] Resnick, P., "Internet Message Format", RFC2822, April 2001.

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

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 RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有