File: rfc3249.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1179 lines) | stat: -rw-r--r-- 40,413 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179






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

      --JUK199912121854870001
      Content-type: text/plain

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

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

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










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

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













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"

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




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


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





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]