File: rfc2306.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 (1403 lines) | stat: -rw-r--r-- 59,358 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
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403






Network Working Group                                        G. Parsons
Request for Comments: 2306                             Northern Telecom
Category: Informational                                     J. Rafferty
                                                   Human Communications
                                                             March 1998


         Tag Image File Format (TIFF) - F Profile for Facsimile


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

Overview

   This document describes in detail the definition of TIFF-F that is
   used to store facsimile images.  The TIFF-F encoding has been
   folklore with no standard reference definition before this document.

Internet Fax Working Group

   This document is a product of the IETF Internet Fax Working Group.
   All comments on this document should be forwarded to the email
   distribution list at <ietf-fax@imc.org>.

1.  Abstract

   This document references the Tag Image File Format (TIFF) to define
   the F profile of TIFF for facsimile (TIFF-F) as a file format that
   may be used for the storage and interchange of facsimile images.

2.  TIFF Definition

   TIFF (Tag Image File Format) Revision 6.0 is defined in detail within
   [TIFF].

   A brief review of concepts used in TIFF is included in this document
   as background information, but the reader is directed to the original
   TIFF specification [TIFF] to obtain specific technical details.





Parsons & Rafferty           Informational                      [Page 1]

RFC 2306                     TIFF-F Profile                   March 1998


2.1  Baseline TIFF and Applications

   TIFF provides a method to describe and store raster image data.  A
   primary goal of TIFF is to provide a rich environment within which
   implementations can exchange image data.  [TIFF] characterizes
   Baseline TIFF as being the core of TIFF, the essentials that all
   mainstream TIFF developers should support in their products.
   Applications of TIFF are defined by using Baseline TIFF as a starting
   point and then defining "extensions" to TIFF that are used for the
   specific "application", as well as specifying any other differences
   from Baseline TIFF.

3.  TIFF-F Definition

3.1 Introduction

   Though it has been in common usage for many years, TIFF-F has
   previously never been documented in the form of a standard.  An
   informal TIFF-F document was originally created by a small group of
   fax experts led by Joe Campbell.  The existence of TIFF-F is noted in
   [TIFF] but it is not defined.  This document defines the F
   application of [TIFF]. For ease of reference, the term TIFF-F will be
   used throughout this document as a shorthand for "F Profile of TIFF
   for Facsimile".  TIFF-F files are intended for use with the
   image/tiff MIME media content-type which includes support for the
   "application" parameter (e.g., application=faxbw).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [REQ].

 3.1.1 TIFF-F Historical Background

   Up until TIFF 6.0, TIFF supported various "Classes" which defined the
   use of TIFF for various applications. Classes were used to support
   specific applications and in this spirit, TIFF-F has been known
   historically as "TIFF Class F".  Previous informal TIFF-F documents
   used the "Class F" terminology.

   As of TIFF 6.0 [TIFF], the TIFF Class concept has been eliminated in
   favor of the concept of Baseline TIFF.  Therefore, this document
   updates the definition of TIFF-F as the F profile of TIFF for
   facsimile, by using Baseline TIFF as defined in [TIFF] as the
   starting point and then defining the differences from Baseline TIFF
   which apply for TIFF-F.   In almost all cases, the resulting
   definition of TIFF-F fields and values remains consistent with those
   used historically in earlier definitions of TIFF Class F.  Where some




Parsons & Rafferty           Informational                      [Page 2]

RFC 2306                     TIFF-F Profile                   March 1998


   of the values for fields have been updated to provide more precise
   conformance with the ITU-T [T.4] and [T.30] fax recommendations,
   these differences are noted.

3.1.2     Overview

   The intent of this specification is to document:

   1)  The fields and values which are applicable for this F profile
       of TIFF for facsimile.
   2)  A minimum set of TIFF-F fields and values which should be able
       to interwork with virtually all historic TIFF-F readers.
   3)  A broader range of values for the traditional TIFF-F fields
       that will provide support for the most widely used facsimile
       compressions, page sizes and resolutions, consistent with the
       ITU-T [T.4] and [T.30] recommendations.

   The structure of the TIFF-F definition will be as follows.  A brief
   review of the structure of TIFF files and practical guidelines for
   the writing and reading of multi-page TIFF-F files is provided in
   sections 3.1.3 and 3.1.4.

   A review of TIFF-F fields follows.  Section 3.2 reviews the fields
   from Baseline TIFF that are applicable for black and white (bi-
   level) images and are also used by TIFF-F.

   Section 3.3 reviews the other required TIFF-F fields. Several fields
   that are specific extensions for  TIFF-F  are reviewed in section
   3.4.  There are also fields that may be helpful, but are not
   required.  These recommended fields are listed in the section 3.5.
   Section 3.6 defines the requirements for the minimum subset of TIFF-F
   fields and values to maximize interoperability.  Several technical
   topics, including implementation issues and warnings are discussed in
   subsequent sections.  Finally, section 3.9 introduces the TIFF-F
   Reader and Writer.  A table of the required and recommended fields
   for a TIFF-F Reader is provided, along with details on the permitted
   set of values.

3.1.3 Structure of TIFF Files

   The structure of TIFF files is specified within [TIFF].  In this
   section, a short summary of the TIFF structure is included for the
   informational purposes.   In addition, some practical guidelines for
   the use of this structure in reading and writing TIFF-F files are
   addressed in the following section 3.1.4.  The structure for writing
   "minimum subset" TIFF-F files is defined in section 3.6.2.





Parsons & Rafferty           Informational                      [Page 3]

RFC 2306                     TIFF-F Profile                   March 1998


   A TIFF file begins with an 8-byte image file header that defines the
   byte order used within a file (see section 3.9.1), includes a magic
   number sequence that identifies the content as a TIFF file, and then
   uses an offset to point to the first Image File Directory (IFD).  An
   IFD is a sequence of tagged fields, sorted in ascending order (by tag
   value), that contains attributes of an image and pointers to the
   image data.   TIFF fields (also called entries) contain a tag, its
   type (e.g. short, long, rational, etc.), a count (which indicates the
   number of values/offsets) and a value/offset.  However, the actual
   value for the field will only be present if it fits into 4 bytes;
   otherwise, an offset will be used to point to the location of the
   data associated with the field.  In turn, this offset may itself be
   used to point to an array of offsets.

   For the case of facsimile data, many documents consist of a series of
   multiple pages.   Within TIFF, these may be represented using more
   than one IFD within the TIFF file.   Each IFD defines a subfile whose
   type is given in the NewSubfileType field.  For the case of facsimile
   data that is placed in a TIFF-F file, each facsimile page in a
   multi-page document has its own IFD.   For bi- level facsimile files,
   multiple IFDs are organized as a linked list, with the last entry in
   each IFD pointing to the next IFD (the pointer in the last IFD is 0).
   (There is also another technique for organizing multiple IFDs as a
   tree, that uses the SubIFDs field, but this technique is not
   applicable for TIFF-F images.)  Within each IFD, the location of the
   related image data is defined by using fields that are associated
   with strips.  These fields identify the size of strips (in rows), the
   number of bytes per strip after compression and a strip offset, which
   is used to point to the actual location of the image strip.

   TIFF has a very flexible file structure, but the use of some
   practical guidelines for implementors when writing  multi-page TIFF-
   F files can produce TIFF structures which are easier for readers to
   process.   This is especially for implementations in environments
   such as facsimile terminals where a complex file structure is
   difficult to support.

3.1.4 Practical Guidelines for Writing/Reading Multi-Page TIFF-F Files

   Traditionally, historical TIFF-F has required readers and writers to
   be able to handle multi-page TIFF-F files.  Based on the experience
   of various TIFF-F implementors, it has been seen that the
   implementation of TIFF-F can be greatly simplified if certain
   practical guidelines are followed when writing multi-page TIFF-F
   files.  However, for interchange robustness, TIFF-F readers SHOULD be
   prepared to read TIFF files whose structure is consistent with
   [TIFF], which supports a more flexible file structure than is
   recommended here.



Parsons & Rafferty           Informational                      [Page 4]

RFC 2306                     TIFF-F Profile                   March 1998


   The structure for a multi-page TIFF-F file will include one IFD per
   page of the document.   Therefore, each IFD will define the
   attributes for a single page.   For simplicity, the writer of TIFF- F
   files SHOULD present IFDs in the same order as the actual sequence of
   pages.  (The pages are numbered within TIFF-F beginning with page 0
   as the first page and then ascending (i.e. 0, 1, 2,...).  However, as
   noted in section 3.1.3, any field values over 4 bytes will be stored
   separately from the IFD. TIFF-F readers SHOULD expect IFDs to be
   presented in page order, but be able to handle exceptions.

   Per [TIFF], the exact placement of image data is not specified.
   However, the strip offsets for each strip of image are defined from
   within each IFD.   Where possible, a second simplifying assumption
   for the writing of TIFF-F files is to specify that the image data for
   each page of a multi-page document SHOULD be contained within a
   single strip (i.e. one image strip per fax page).   The use of a
   single image strip per page is very useful for implementations such
   as store and forward messaging, where the file is usually prepared in
   advance of the transmission, but other assumptions may apply for the
   size of the image strip for implementations which require the use of
   "streaming" techniques (see section 3.7.6).  In the event a different
   image strip size assumption has been used (e.g. constant size for
   image strips which may be less than the page size), this will
   immediately be evident from the values/offsets of the fields that are
   related to strips.   From the TIFF-F reader standpoint, one image
   strip per page permits the image data to be found through reference
   via a single offset, resulting in a much simplified image structure
   and faster processing.

   A third simplifying assumption is that each IFD SHOULD be placed in
   the TIFF-F file structure at a point which precedes the image which
   the IFD describes.  If any long field values are present (see section
   3.1.3) then these SHOULD be placed after their referencing IFD and
   before the image data they describe.

   A fourth simplifying assumption for TIFF-F writers and readers is to
   place the actual image data in a physical order within the TIFF file
   structure which is consistent with the logical page order.  In
   practice, TIFF-F readers will need to use the strip offsets to find
   the exact physical location of the image data, whether or not it is
   presented in logical page order.

   TIFF-F writers MAY make a fifth simplifying assumption, in which the
   IFD, the value data and the image data for which the IFD has offsets
   precede the next image IFD. These elements MUST precede the next
   image IFD in the minimum set TIFF-F files (see section 3.6.2).
   However, this principle has been relaxed in the case of TIFF-F to
   reflect past practices.



Parsons & Rafferty           Informational                      [Page 5]

RFC 2306                     TIFF-F Profile                   March 1998


   So, a TIFF-F file which is structured using the guidelines of this
   section will essentially be composed of a linked list of IFDs,
   presented in ascending page order, which in turn each point to a
   single page of image data (one strip per page), where the pages of
   image data are also placed in a logical page order within the TIFF-F
   file structure.  (The pages of image data may themselves be stored in
   a contiguous manner, at the option of the implementor).

3.2  Baseline TIFF  Required Fields for BiLevel Images

   Baseline TIFF per [TIFF] requires that the following fields be
   present for all BiLevel Images:  ImageWidth, ImageLength,
   Compression, PhotometricInterpretation, StripOffsets, RowsPerStrip,
   StripByteCounts, XResolution, YResolution and ResolutionUnit.  TIFF-F
   uses all of these fields, but in some cases specifies a different
   range of acceptable values than Baseline TIFF.   Per [TIFF], if
   fields are omitted, the Baseline TIFF default value(if specified)
   will apply.

   In the field definitions which follow in this section and subsequent
   sections, the fields will be presented in the following form:

   Fieldname (tag-number) = values (if applicable). TYPE

   A brief summary of the Baseline TIFF fields and their use in TIFF-F
   follows:

   ImageWidth(256) = 1728, 2048, 2432, 2592, 3072, 3648, 3456, 4096,
                     4864.
       SHORT or LONG.  These are the fixed page widths in pixels.  The
       permissible values are dependent upon X and Y resolutions as
       shown in sections 2 and 3 of [T.4] and reproduced here for
       convenience:

       XResolution x Yresolution                  | ImageWidth
      --------------------------------------------|------------------
       204x98, 204x196, 204x391, 200x100, 200x200 | 1728, 2048, 2432
       300x300                                    | 2592, 3072, 3648
       408x391, 400x400                           | 3456, 4096, 4864
      --------------------------------------------|------------------

       Historical TIFF-F did not include support for the following
       widths related to higher resolutions:  2592, 3072, 3648, 3456,
       4096 and 4864.   Historical TIFF-F documents also included the
       following values related to A5 and A6 widths:  816 and 1216.  Per
       the most recent version of [T.4], A5 and A6 documents are no





Parsons & Rafferty           Informational                      [Page 6]

RFC 2306                     TIFF-F Profile                   March 1998


       longer supported in Group 3 facsimile, so the related width
       values are now obsolete.  See section 3.8.2 for more information
       on inch/metric equivalencies and other implementation details.

   ImageLength (257).  SHORT or LONG. LONG recommended.
       The total number of scan lines in the image.

   Compression (259) = 3,4.  SHORT.
       This is a required TIFF-F field.  The permitted values for TIFF-
       F purposes are 3 and 4 as shown.   The default value per Baseline
       TIFF is 1 (Uncompressed), but this value is invalid for facsimile
       images.    Baseline TIFF also permits use of value 2 (Modified
       Huffman encoding), but the data is presented in a form which does
       not contain EOLs. Instead, TIFF-F specifies the value 3 for
       encoding one-dimensional T.4 Modified Huffman or 2-dimensional
       Modified READ data.   The detailed settings which apply for T.4
       encoded data are specified using the T4Options field.  TIFF-F
       also permits use of the value 4 for the compression field, which
       indicates that the data is coded using a [T.6] compression method
       (i.e the Modified Modified READ two-dimensional method). The
       detailed settings which apply for T.6 encoded data are specified
       using the T6Options field.

       Please refer to the definitions of the T4Options and T6Options
       fields in section 3.3, and section 3.8 for more information on
       the encoding of images and conventions used within TIFF-F.

   PhotometricInterpretation (260) = 0,1.  SHORT.
       This field allows notation of an inverted ("negative") image:
               0 = normal
               1 = inverted

   StripOffsets (273).  SHORT or LONG.
       For each strip, the offset of that strip.  The offset is measured
       from the beginning of the file. If a page is expressed as one
       large strip, there is one such entry per page.

   RowsPerStrip (278).  SHORT or LONG.  LONG recommended.
       The number of scan lines per strip.  When a page is expressed as
       one large strip, this is the same as the ImageLength field.

   StripByteCounts (279).  LONG or SHORT.  LONG recommended.
       For each strip, the number of bytes in that strip. If a page is
       expressed as one large strip, this is the total number of bytes
       in the page after compression.  Note that the choice of LONG or
       SHORT depends upon the size of the strip.





Parsons & Rafferty           Informational                      [Page 7]

RFC 2306                     TIFF-F Profile                   March 1998


   ResolutionUnit (296) = 2,3.  SHORT.
       The units of measure for resolution:
               2 = Inch
               3 = Centimeter

       TIFF-F has traditionally used inch based measures.

   XResolution (282) = 204, 200, 300, 400, 408 (inches). RATIONAL.
       The horizontal resolution of the TIFF-F image expressed in pixels
       per resolution unit. The values of 200 and 408 have been added to
       the historical TIFF-F values, for consistency with [T.30].  Some
       existing TIFF-F implementations may also support values of 77
       (cm).  See section 3.8.2 for more information on inch/metric
       equivalencies and other implementation details.

   YResolution (283) = 98, 196, 100, 200, 300, 391, 400  (inches).
                       RATIONAL.
       The vertical resolution of the TIFF-F image expressed in pixels
       per resolution unit. The values of 100, 200, and 391 have been
       added to the historical TIFF-F values, for consistency with
       [T.30].  Some existing TIFF-F implementations may also support
       values of 77, 38.5 (cm). See section 3.8.2 for more information
       on inch/metric equivalencies and other implementation details.

3.3  TIFF-F Required Fields

   In addition to the Baseline TIFF fields, there are additional
   required fields for TIFF-F. A review of the additional required
   fields for TIFF-F follows:

   BitsPerSample (258) = 1.  SHORT.
       Since TIFF-F  is only used for black-and-white facsimile images,
       the value is  1 (the default) for all files.

   FillOrder (266) = 1, 2.  SHORT.
       TIFF  F readers must be able to read data in both bit orders, but
       the vast majority of facsimile products store data LSB first,
       exactly as it appears on the telephone line.
               1 = Most Significant Bit first.
               2 = Least Significant Bit first.

   NewSubFileType (254)= (Bit 1 = 1).  LONG.
       This field is made up of 32 flag bits.  Unused bits are
       expected to be 0 and bit 0 is the low order bit.   Bit 0 is set
       to 0 for TIFF-F.   Bit 1 is always set to 1 for TIFF-F,
       indicating a single page of a multi-page image. The same bit





Parsons & Rafferty           Informational                      [Page 8]

RFC 2306                     TIFF-F Profile                   March 1998


       settings are used when TIFF-F is used for a one page fax image.
       See sections 3.1.1 and 3.1.2 for more details on the structure
       of multi-page TIFF-F image files.

   PageNumber (297).  SHORT/SHORT.
       This field specifies the page numbers in the fax document.  The
       field comprises two SHORT values: the first value is the page
       number, the second is the total number of pages. Single-page
       documents therefore use 0000/0001 hex.  If the second value is
       0, the total number of pages in the document is not available.

   SamplesPerPixel (277) = 1.  SHORT.
       The value of 1 denotes a bi-level, grayscale, or palette color
       image.

   There is also a requirement to include either the T4Options or the
   T6Options field in a TIFF-F IFD, depending upon the setting of the
   Compression field.  These fields are defined in the next section on
   TIFF extensions.

3.4  TIFF-F Extensions

   These are fields which are extensions beyond the required TIFF-F
   fields.  The following fields have been defined as extensions in
   [TIFF].

   T4Options (292) (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1).  LONG.
       This field is required if the value for the compression field
       has been set to 3.   The values are set as shown below for TIFF-
       F.   For TIFF-F, uncompressed data is not allowed and EOLs MAY
       be byte aligned (see section 3.8.3).
               bit 0 = 0 for 1-Dimensional, 1 for 2-Dimensional (MR)
               bit 1 = must be 0 (uncompressed data not allowed)
               bit 2 = 0 for non-byte-aligned EOLs or 1 for byte-
                       aligned EOLs

       This field is made up of a set of 32 flag bits. Unused bits
       must be set to 0.  Bit 0 is the low order bit.  Please note
       that T4Options was known as G3Options in earlier versions of
       TIFF and TIFF-F.  The data in a TIFF-F image encoded using
       one of the T.4 methods is not terminated with an RTC (see
       section 3.8.5).

   T6Options (293) = (Bit 0 = 0, Bit 1 = 0)  LONG.
       This field is required for TIFF-F if value of the compression
       field has been set to 4. The value for this field is made up of
       a set of 32 flag bits.   Setting bit 0 to 0 indicates that the
       data is compressed using the Modified Modified READ (MMR) two-



Parsons & Rafferty           Informational                      [Page 9]

RFC 2306                     TIFF-F Profile                   March 1998


       dimensional compression method.  MMR compressed Data is two-
       dimensional and does not use EOLs. Each MMR encoded image MUST
       include an "end-of-facsimile-block" (EOFB) code at the end of
       each coded strip (see section 3.8.6). Uncompressed data is not
       applicable for bi-level facsimile images, so that bit 1 must be
       set to 0.  Unused bits must be set to 0. Bit 0 is the low-order
       bit. The default value is 0 (all bits 0).
               bit 0 = 0 for 2-Dimensional
               bit 1 = must be 0 (uncompressed data not allowed)

       In earlier versions of TIFF, this field was named Group4Options.
       The significance has not changed and the present definition is
       compatible.

       In addition, three new fields, defined as TIFF-F extensions,
       describe page quality.  The information contained in these fields
       is usually obtained from receiving facsimile hardware (if
       applicable).   These fields are optional.  They SHOULD NOT be
       used in writing TIFF-F files for facsimile image data that is
       error corrected or otherwise guaranteed not to have coding
       errors.

       Some implementations need to understand exactly the error content
       of the data.  For example, a CAD program might wish to verify
       that a file has a low error level before importing it into a
       high- accuracy document.  Because Group 3 facsimile devices do
       not necessarily perform error correction on the image data, the
       quality of a received page must be inferred from the pixel count
       of decoded scan lines. A "good" scan line is defined as a line
       that, when decoded, contains the correct number of pixels.
       Conversely, a "bad" scan line is defined as a line that, when
       decoded, comprises an incorrect number of pixels.

       BadFaxLines (326). SHORT or LONG
       This field reports the number of scan lines with an incorrect
       number of pixels encountered by the facsimile during reception
       (but not necessarily in the file).

       Note: PercentBad = (BadFaxLines/ImageLength) * 100

   CleanFaxData (327). SHORT
       N =
           0 = Data contains no lines with incorrect pixel counts or
              regenerated lines  (i.e., computer generated)
           1 = Lines with an incorrect pixel count were regenerated by
              receiving device





Parsons & Rafferty           Informational                     [Page 10]

RFC 2306                     TIFF-F Profile                   March 1998


           2 = Lines with an incorrect pixel count are in the data  and
              were not regenerated by receiving device (i.e. data
              contains bad scan lines)

       Many facsimile devices do not actually output bad lines.
       Instead, the previous good line is repeated in place of a bad
       line. Although this substitution, known as line regeneration,
       results in a visual improvement to the image, the data is
       nevertheless corrupted.  The CleanFaxData field describes the
       error content of the data.  That is, when the BadFaxLines and
       ImageLength fields indicate that the facsimile device
       encountered lines with an incorrect number of pixels during
       reception, the CleanFaxData field indicates whether these bad
       lines are actually still in the data or if the receiving
       facsimile device replaced them with regenerated lines.

   ConsecutiveBadFaxLines (328). LONG or SHORT.
       This field reports the maximum number of consecutive lines
       containing an incorrect number of pixels encountered by the
       facsimile device during reception (but not necessarily in the
       file).

       The BadFaxLines and ImageLength data indicate only the quantity
       of such lines.  The ConsecutiveBadFaxLines field is an
       indicator of their distribution and may therefore be a better
       general indicator of perceived image quality.

3.5  Recommended Fields

   hese are fields that MAY be used in encoding TIFF-F files, but are
   ptional in nature and may be ignored by many TIFF readers.  These
   ields are called recommended consistent with historical TIFF-F
   ractice.

   BadFaxLines (326) [defined in section 3.4]

   CleanFaxData (327) [defined in section 3.4]

   ConsecutiveBadFaxLines (328) [defined in section 3.4]

   DateTime (306).  ASCII.
       Date and time in the format YYYY:MM:DD HH:MM:SS, in 24-hour
       format. String length including NUL byte is 20 bytes. Space
       between DD and HH.

   DocumentName (269).  ASCII.
       This is the name of the document from which the document was
       scanned.



Parsons & Rafferty           Informational                     [Page 11]

RFC 2306                     TIFF-F Profile                   March 1998



   ImageDescription (270).  ASCII.
       This is an ASCII string describing the contents of the image.

   Orientation (274).  SHORT.
       This field is designated as "Recommended" for consistency with
       historical TIFF-F, but is also a Baseline TIFF field with a
       default value of 1 per [TIFF]. The default value of 1 applies
       if the field is omitted, but for clarity, TIFF-F writers SHOULD
       include this field.  This field might be useful for displayers
       that always want to show the same orientation, regardless of
       the image.  The default value of 1 is "0th row is visual top of
       image, and 0th column is the visual left."  An 180-degree
       rotation is 3.  See [TIFF] for an explanation of other values.

   Software (305).  ASCII.
       The optional name and release number of the software package
       that created the image.

3.6   Requirements for TIFF-F Minimum Subset

   This section defines the requirements for a minimum subset of TIFF-F
   fields and values that all TIFF-F readers SHOULD support to maximize
   interoperability with current and historical TIFF-F implementations.
   The TIFF-F structure for writing minimum subset files is also
   defined.

3.6.1   Summary of Minimum Subset Fields and Values

   A summary of the minimum subset TIFF-F fields and values is provided
   in the following table.  The required fields for the minimum subset
   are shown under the column labeled "Field".  The values for these
   fields in the minimum subset are shown under the column labeled
   "Minimum".

  Field             | Minimum      | Comment
  ------------------|--------------|-------------------------------
  BitsPerSample     | 1            |one bit per sample
  Compression       | 3            |3 for T.4 (MH)
  FillOrder         | 2            |LSB first
  ImageWidth        | 1728         |
  ImageLength       |              |required
  NewSubFileType    | Bit 1 = 1    |single page of multipage file
  PageNumber        | X/X          |pg/tot, 0 base, tot in 1st IFD
  PhotometricInterp | 0            |0 is white
  ResolutionUnit    | 2            |inches (default)
  RowsPerStrip      |=ImageLength  |
  SamplesPerPixel   | 1            |one sample per pixel



Parsons & Rafferty           Informational                     [Page 12]

RFC 2306                     TIFF-F Profile                   March 1998


  StripByteCounts   |              |required
  StripOffsets      |              |required
  T4Options         | Bit 0 = 0    |MH
                    | Bit 1 = 0    |
                    | Bit 2 = 0,1  |Non-Byte-aligned,
                    |              | Byte-Aligned EOLs
  XResolution       | 204          |Units is per inch
  YResolution       | 196,98       |Units is per inch
  ------------------|--------------|------------------------------

3.6.2     TIFF-F Minimum Subset File Structure

   For implementations which need to write minimum subset TIFF-F files,
   the file structure shown in Figure 3.1 MUST be used:

                   +-----------------------+
                   |         Header        |------------+
                   +-----------------------+            | First IFD
                   |      IFD (page 0)     | <----------+ Offset
               +---|                       |------------+
               |   |                       |--+         |
         Value |   +-----------------------+  |         |
        Offset +-->|      Long Values      |  |         |
                   +-----------------------|  | Strip   |
                   |  Image Data (page 0)  |<-+ Offset  |
                   +-----------------------+            | Next IFD
                   |      IFD (page 1)     | <----------+ Offset
               +---|                       |------------+
               |   |                       |--+         |
         Value |   +-----------------------+  |         |
        Offset +-->|      Long Values      |  |         |
                   +-----------------------|  | Strip   |
                   |  Image Data (page 1)  |<-+ Offset  |
                   +-----------------------+            | Next IFD
                   |      IFD (page 2)     | <----------+ Offset
                   +-----------------------+
                   |          :            |
                   |          :            |

       Figure 3.1     TIFF-F Minimum Subset File Structure

   As depicted in Figure 3.1, the IFD of each page precedes the related
   Image Data for that page.  If present, any long field values appear
   between the IFD and the image data for that page.  For multiple page
   documents, each IFD/image pair is immediately followed by the next
   IFD/image pair in logical page order within the file structure, until
   all pages have been defined.




Parsons & Rafferty           Informational                     [Page 13]

RFC 2306                     TIFF-F Profile                   March 1998


   The format for the TIFF Header is as defined in [TIFF].  When writing
   TIFF-F minimum subset files, the value for the byte order in the
   Header SHOULD be II (0x4949, denoting that the bytes in the TIFF file
   are in LSB first (little-endian) order.

   This results in a TIFF header whose content is as shown in Figure
   3.2.

   | Offset |   Description     | Type   |     Value          |
   +--------+-------------------+--------+--------------------+
   |   0    |   Byte Order      | Short  |  0x4949 (II)       |
   +--------+-------------------+--------+--------------------+
   |   2    |   Version         | Short  |  42                |
   +--------+-------------------+--------+--------------------+
   |   4    | Offset of 0th IFD | Long   |  0x 0000 0008      |
   +--------+-------------------+--------+--------------------+

   Figure 3.2: Image File Header for Minimum Subset TIFF-F Files

 3.7  Technical Implementation Issues

3.7.1   Strips

   Those new to TIFF may not be familiar with the concept of "strips"
   embodied in the three fields RowsPerStrip, StripByteCount,
   StripOffsets.

   In general, third-party implementations that read and write TIFF
   files expect the image to be divided into "strips," also known as
   "bands."  Each strip contains a few lines of the image. By using
   strips, a TIFF reader need not load the entire image into memory,
   thus enabling it to fetch and decompress small random portions of the
   image as necessary.

   The dimensions of a strip are described by the RowsPerStrip and
   StripByteCount fields.  The location in the TIFF file of each strip
   is contained in the StripOffsets field.

   The size of TIFF-F strips is application dependent.  The recommended
   approach for multi-page TIFF-F images is to represent each page as a
   single strip.










Parsons & Rafferty           Informational                     [Page 14]

RFC 2306                     TIFF-F Profile                   March 1998


3.7.2  Bit Order

   The default bit order in Baseline TIFF per [TIFF] is indicated by
   FillOrder=1, where bits are not reversed before being stored.
   However, TIFF-F typically utilizes the setting of FillOrder=2, where
   the bit order within bytes is reversed before storage (i.e., bits are
   stored with the Least Significant Bit first).

   Facsimile data appears on the phone line in bit-reversed order
   relative to its description in CCITT Recommendation T.4.  Therefore,
   a wide majority of facsimile implementations choose this natural
   order for storage. Nevertheless, TIFF-F readers must be able to read
   data in both bit orders.

3.7.3  Multi-Page

   Many existing implementations already read TIFF-F like files, but do
   not support the multi- page field.  Since a multi-page format greatly
   simplifies file management in fax application software, TIFF-F
   specifies multi-page documents (NewSubfileType = 2) as the standard
   case.

3.7.4 Compression

   In Group 3 facsimile, there are three compression methods which had
   been standardized as of 1994 and are in common use.  The ITU-T T.4
   recommendation defines a one-dimensional compression method known as
   Modified Huffman (MH) and a two-dimensional method known as Modified
   READ (MR) (READ is short for Relative Element Address Designate).  In
   1984, a somewhat more efficient compression method known as Modified
   Modified READ (MMR) was defined in the T.6 recommendation.  It was
   originally defined for use with Group 4 facsimile, so that this
   compression method has been commonly called Group 4 compression.  In
   1991, the MMR method was approved for use in Group 3 facsimile and
   has since been widely utilized.

   TIFF-F permits three different compression methods.  In the most
   common practice, the one-dimensional compression method (Modified
   Huffman) is used.  This is specified by setting the value of the
   Compression field to 3 and then setting bit 0 of the T4Options field
   to 0.  Alternatively, the two dimensional Modified READ method (which
   is much less frequently used in historical TIFF-F implementations)
   may be selected by setting bit 0 to a value of 1.

   Optionally, depending upon the implementation requirements, the more
   efficient two-dimensional compression method from T.6 (i.e.  MMR or
   "Group 4 compression") may be selected.  This method is selected by




Parsons & Rafferty           Informational                     [Page 15]

RFC 2306                     TIFF-F Profile                   March 1998


   setting the value of the Compression field to 4 and then setting the
   value of the first two bits (and all unused bits) of T6options to 0.
   More information to aid the implementer in making a compression
   selection is contained in section 3.8 on Implementation Warnings.

3.7.5  Example Use of Page-quality Fields

   Here are examples for writing the CleanFaxData,  BadFaxLines, and
   ConsecutiveBadFaxLines fields:

       1.  Facsimile hardware does not provide page quality
           information: MUST NOT write page-quality fields.
       2.  Facsimile hardware provides page quality information, but
           reports no bad lines.  Write only BadFaxLines = 0.
       3.  Facsimile hardware provides page quality information, and
           reports bad lines.  Write both BadFaxLines and
           ConsecutiveBadFaxLines.  Also write CleanFaxData = 1 or 2 if
           the hardware's regeneration capability is known.
       4.  Source image data stream is error-corrected or otherwise
           guaranteed to be error-free such as for a computer generated
           file:  SHOULD NOT write page-quality fields.

3.7.6   Use of TIFF-F for Streaming Applications

   TIFF-F has historically been used for handling fax image files in
   implementations such as store and forward messaging where the entire
   size of the file is known in advance.  While TIFF-F may also possibly
   be used as a file format for cases such as streaming applications,
   different assumptions may be required than those provided in this
   document (e.g., the entire size and number of pages within the image
   are not known in advance).  As a result, a definition for the
   streaming application of TIFF-F is beyond the scope of this document.

3.7.7  TIFF-F Export and Import

   Fax implementations that do not wish to support TIFF-F as a native
   format may elect to support it as import/export medium.

   Export

   It is recommended that implementations export multiple page TIFF-F
   files without manipulating fields and values.   Historically, some
   TIFF-F writers have attempted to produce individual single-page
   TIFF-F files with modified NewSubFileType and PageNumber (page one-
   of-one) values for export purposes.  However, there is no easy way to
   link such multiple single page files together into a logical multiple
   page document, so that this practice is not recommended.




Parsons & Rafferty           Informational                     [Page 16]

RFC 2306                     TIFF-F Profile                   March 1998


   Import

   A TIFF-F reader MUST be able to handle a TIFF-F file containing
   multiple pages.

3.8  Implementation Warnings

   3.8.1  Uncompressed data

   TIFF-F requires the ability to read and write at least one-
   dimensional T.4 Huffman ("compressed") data.  Uncompressed data is
   not allowed.  This means that the "Uncompressed" bit in T4Options or
   T6Options must be set to 0.

3.8.2  Encoding and Resolution

   Since two-dimensional encoding is not required for Group 3
   compatibility, some historic TIFF-F readers have not been able to
   read such files.  The minimum subset of TIFF-F REQUIRES support for
   one dimensional (Modified Huffman) files, so this choice maximizes
   portability.  However, implementers seeking greater efficiency SHOULD
   use T.6 MMR compression when writing TIFF-F files.  Some TIFF-F
   readers will also support two-dimensional Modified READ files.
   Implementers that wish to have the maximum flexibility in reading
   TIFF-F files SHOULD support all three of these compression methods
   (MH, MR and MMR).

   For the case of resolution, almost all facsimile products support
   both standard (98 dpi) vertical resolution  and "fine" (196 dpi)
   resolution.  Therefore, fine-resolution files are quite portable in
   the real world.

   In 1993, the ITU-T added support for higher resolutions in the T.30
   recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per
   inch based units.  At the same time, support was added for metric
   dimensions which are equivalent to the following inch based
   resolutions: 391v x 204h and 391v x 408h.  Therefore, the full set of
   inch-based equivalents of the new resolutions are supported in the
   TIFF-F writer, since they may appear in some image data streams
   received from Group 3 facsimile devices.  However, many facsimile
   terminals and older versions of  TIFF-F readers are likely to not
   support the use of these higher resolutions.

   Per [T.4], it is permissible for implementations to treat the
   following XResolution values as being equivalent: <204,200> and
   <400,408>.  In a similar respect, the following YResolution values





Parsons & Rafferty           Informational                     [Page 17]

RFC 2306                     TIFF-F Profile                   March 1998


   may also be treated as being equivalent: <98, 100>, <196, 200>, and
   <391, 400>.   These equivalencies were allowed by [T.4] to permit
   conversions between inch and metric based facsimile terminals.

   In a similar respect, the optional support of metric based
   resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for
   completeness, since they are used in some legacy TIFF-F
   implementations, but this use is not recommended for the creation of
   TIFF-F files by a writer.

3.8.3  EOL byte-aligned

   The historical convention for TIFF-F has been that all EOLs in
   Modified Huffman or Modified READ data must be byte-aligned.
   However, Baseline TIFF has permitted use of non-byte-aligned EOLs by
   default, so that a large percentage of TIFF-F reader implementations
   support both conventions.   Therefore, the minimum subset of TIFF-F
   as defined in this document includes support for both byte-aligned
   and non-byte-aligned EOLs.

   An EOL is said to be byte-aligned when Fill bits have been added as
   necessary before EOL codes such that EOL always ends on a byte
   boundary, thus ensuring an  EOL-sequence of a one byte preceded by a
   zero nibble: xxxx0000 00000001.

   Modified Huffman encoding encodes bits, not bytes. This means that
   the end-of-line token may end in the middle of a byte. In byte
   alignment, extra zero bits (Fill) are added so that the first bit of
   data following an EOL begins on a byte boundary. In effect, byte
   alignment relieves application software of the burden of bit-
   shifting every byte while parsing scan lines for line-oriented image
   manipulation (such as writing a TIFF file).

   For Modified READ encoding, each line is terminated by an EOL and a
   one bit tag bit.  Per [T.4], the value of the tag bit is 0 if the
   next line contains two dimensional data and 1 if the next line is a
   reference line.   To maintain byte alignment, fill bits are added
   before the EOL/tag bit sequence, so that the first bit of data
   following an MR tag bit begins on a byte boundary.

3.8.4  EOL

   As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded
   with Modified Huffman begin with an EOL (which in TIFF-F may be
   byte-aligned). The last line of the image is not terminated by an
   EOL.  In a similar respect, images encoded with Modified READ two
   dimensional encoding begin with an EOL, followed by a tag bit.




Parsons & Rafferty           Informational                     [Page 18]

RFC 2306                     TIFF-F Profile                   March 1998


3.8.5  RTC Exclusion

   Aside from EOLs, TIFF-F files have historically only contained image
   data. This means that implementations which wish to maintain strict
   conformance with the rules in [TIFF] and compatibility with
   historical TIFF-F, SHOULD NOT include the Return To Control sequence
   (RTC) (consisting of 6 consecutive EOLs) when writing TIFF- F files.
   However, implementations which need to support "transparency" of
   [T.4] image data MAY include RTCs when writing TIFF-F files if the
   flag settings of the T4Options field are set for non-byte aligned MH
   or MR image data.  Implementors of TIFF readers should also be aware
   that there are some existing TIFF-F implementations which include the
   RTC sequence in MH/MR image data.  Therefore, TIFF-F readers MUST be
   able to process files which do not include RTCs and SHOULD be able to
   process files which do include RTCs.

3.8.6  Use of EOFB for T.6 Compressed Images

   TIFF-F pages which are encoded with the T.6 Modified Modified READ
   compression method MUST include an "end-of-facsimile-block" (EOFB)
   code at the end of each coded strip. Per [TIFF], the EOFB code is
   followed by pad bits as needed to align on a byte boundary.   TIFF
   readers SHOULD ignore any bits other than pad bits beyond the EOFB.

3.9  TIFF-F Fields Summary

   Implementations may choose to implement a TIFF-F Reader, TIFF-F
   Writer or both, depending upon application requirements.  The TIFF- F
   Reader is typically used to read an existing TIFF-F file which
   resides on a computer or peripheral device.  The TIFF-F Writer is
   typically used to convert a bi-level image bit stream into a TIFF-F
   compliant file. For many Internet applications, only the Reader needs
   to be implemented. The specific field support required for TIFF-F
   Readers and Writers is summarized below.

3.9.1  TIFF Reader

   The fields in the following table are specified for a TIFF-F Reader.
   The range of values for required and recommended fields are as shown.
   The minimum subset of values are also shown. If required fields are
   omitted in a TIFF-F file, the Baseline TIFF default value will apply.
   Image data must not have any coding errors. In the table, certain
   fields have a value that is a sequence of flag bits (e.g. T4Options).
   An implementation should test the setting of the relevant flag bits
   individually to allow extensions to the sequence of flag bits to be
   appropriately ignored.





Parsons & Rafferty           Informational                     [Page 19]

RFC 2306                     TIFF-F Profile                   March 1998


   As noted within [TIFF], a TIFF file begins with an 8-byte image file
   header, of which the first two bytes (0-1) contain the byte order
   within the file.  The permissible values are:

       II- Byte order from least significant byte to the most
           significant byte (little-endian)
       MM - byte order is always from most significant to least
           significant (big-endian)

   For a TIFF-F Reader, the legal values are:

       ByteOrder: MM,II (Either byte order is allowed)

3.9.1.1  Fields for TIFF-F Reader

   Recommended Fields in the table are shown with an asterisk (*).

   Other fields may be present, but they should be of an informational
   nature, so that a reader can elect to ignore them.

   Informational fields which are often present in TIFF-F images are:
      Software, Datetime, BadFaxLines, CleanFaxData and
      ConsecutiveBadFaxLines.

  Field             | Values      | Minimum     | Comment
  ------------------|-------------|-------------|----------------------
  BitsPerSample     | 1           | 1           |one bit per sample
  Compression       | 3,4         | 3           |3 for T.4 (MH, MR)
                    |             |             |4 for T.6 - MMR
  FillOrder         | 2,1         | 2           |LSB first or MSB first
  ImageWidth        | 1728, 2048, | 1728        |depends on XResolution
                    | 2432, 2592, |             |
                    | 3072, 3648, |             |
                    | 3456, 4096, |             |
                    | 4864        |             |
  ImageLength       | >0          |             |required
  NewSubFileType    | Bit 1 = 1   | Bit 1 = 1   |single page of
                    |             |             |multipage file
  Orientation *     | 1           |             |1st row=top left,
                    |             |             | 1st col=top
  PageNumber        | X/X         | 0/1         |pg/tot, 0 base,
                    |             |             | tot in 1st IFD
  PhotometricInterp | 0,1         | 0           |0 is white
  ResolutionUnit    | 2,3         | 2           |inches (default)
  RowsPerStrip      |=ImageLength |=ImageLength |
                    | or other    |             |
  SamplesPerPixel   | 1           | 1           |one sample per pixel
  StripByteCounts   | >0          |             |required



Parsons & Rafferty           Informational                     [Page 20]

RFC 2306                     TIFF-F Profile                   March 1998


  StripOffsets      | >0          |             |required
  T4Options         | Bit 0 = 0,1 | Bit 0 = 0   |MH,MR(incl if not MMR)
                    | Bit 1 = 0   | Bit 1 = 0   |
                    | Bit 2 = 0,1 | Bit 2 = 0,1 | Non-Byte-aligned and
                    |             |             | Byte-Aligned EOLs
  T6Options         | 0           |             |MMR (incl only if MMR)
  XResolution       | 204,200,300,| 204         | If unit is per inch
                    | 400,408,    |             |
                    | 77          |             | If unit is per cm
  YResolution       | 196,98,100, | 196,98      | If unit is per inch
                    | 200,300,391,|             |
                    | 400,        |             |
                    | 77,38.5     |             | If unit is per cm
  ------------------|-------------|-------------|----------------------

3.9.2  TIFF-F Writer

   For the case of writing (creating) a TIFF-F file format from an image
   data stream or other raster data, implementations SHOULD write files
   which can be read by a TIFF-F Reader as defined in 3.9.1.  It is
   recommended that all fields from the table in 3.9.1.1 SHOULD be
   included when writing TIFF-F files in order to  minimize dependencies
   on default values. Image data must not have any coding errors.

   Other fields may be present, but they should be of an informational
   nature, so that a Reader may elect to ignore them.

   For the case of writing "minimum subset" TIFF-F files, the rules
   defined in section 3.6 apply.

   Informational fields that may be useful for TIFF-F files are:
       Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines

   TIFF Writers SHOULD only generate the fields that describe facsimile
   image quality when the image has been generated from a fax image data
   stream where error correction (e.g. Group 3 Error Correction Mode)
   was not used.  These fields are:  CleanFaxData, BadFaxLines and
   ConsecutiveBadFaxLines.

4.  MIME sub-type image/tiff

   [TIFFREG] describes the registration of the MIME content-type image/
   tiff to refer to TIFF 6.0 encoded image data.   When transported by
   MIME, the TIFF content defined by this document must be encoded
   within an image/tiff content type. In addition, an optional
   "application" parameter is defined for image/tiff to identify a
   particular application's subset of TIFF and TIFF extensions for the




Parsons & Rafferty           Informational                     [Page 21]

RFC 2306                     TIFF-F Profile                   March 1998


   encoded image data, if it is known. Typically, this would be used to
   assist the recipient in dispatching a suitable rendering package to
   handle the display or processing of the image file.

4.1 Refinement of MIME sub-type image/tiff for Application F

   Since this document defines a facsimile specific profile of TIFF, it
   is useful to note an appropriate application parameter for the
   image/tiff MIME content-type.

   The "faxbw" application parameter is defined for black and white
   facsimile.  It is suitable for use by applications that can process
   one or more TIFF for facsimile profiles or subsets used for the
   encoding of black and white facsimile data.

   Since this document defines a profile of TIFF for facsimile which is
   suitable for use with black and white facsimile image data,
   applications which use this profile or its minimum subset should set
   the value of the application parameter to "faxbw".

   An example of the use of the image/tiff MIME Content-type with the
   application parameter set with the value "faxbw" follows:

   Example:

          Content-type: image/tiff; application=faxbw

   In this example, use of this parameter value will enable applications
   to identify the content as being within a profile or subset of TIFF
   for Facsimile that is suitable for encoding black and white image
   data, before attempting to process the image data.

5.  Implementation Usage

   5.1 Internet Fax Usage

   The usage of TIFF-F is envisioned as a component of Internet Fax.  It
   is anticipated that Internet Fax may use both a TIFF-F Reader and
   TIFF-F Writer. The details of the Internet Fax services and their use
   of TIFF-F will be specified in other documents.

5.2 VPIM Usage

   The Application F of TIFF (i.e. TIFF-F content) is a secondary
   component of the VPIM Message as defined in [VPIM2].  Voice messaging
   systems can often handle fax store-and-forward capabilities in
   addition to traditional voice message store-and- forward functions.




Parsons & Rafferty           Informational                     [Page 22]

RFC 2306                     TIFF-F Profile                   March 1998


   As a result, TIFF-F fax messages can optionally be sent between
   compliant VPIM systems, and may be rejected if the recipient system
   cannot deal with fax.

   Refer to the VPIM Specification for proper usage of this content.

6.  Security Considerations

   This document describes the encoding for TIFF-F, which is a profile
   of the TIFF encoding for facsimile.  As such, it does not create any
   security issues not already identified in [TIFFREG], in its use of
   fields as defined in [TIFF]. There are also new TIFF fields defined
   within this specification, but they are of a purely descriptive
   nature, so that no new security risks are incurred.

   Further, the encoding specified in this document does not in any way
   preclude the use of any Internet security protocol to encrypt,
   authenticate, or non-repudiate TIFF-F encoded facsimile messages.

7.  Authors' Addresses

   Glenn W. Parsons
   Northern Telecom
   P.O. Box 3511, Station C
   Ottawa, ON  K1Y 4H7
   Canada
   Phone: +1-613-763-7582
   Fax:   +1-613-763-2697
   Email: Glenn.Parsons@Nortel.ca

   James Rafferty
   Human Communications
   12 Kevin Drive
   Danbury, CT 06811-2901
   USA
   Phone: +1-203-746-4367
   Fax:   +1-203-746-4367
   Email: Jrafferty@worldnet.att.net

8. References

   [MIME1] Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.
   [MIME4] Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
        Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
        November 1996.




Parsons & Rafferty           Informational                     [Page 23]

RFC 2306                     TIFF-F Profile                   March 1998


   [REQ] Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", RFC 2119, March 1997.
   [T.30] ITU-T Recommendation T.30 - "Procedures for Document
        Facsimile Transmission in the General Switched Telephone
        Network", June, 1996
   [T.4] ITU-T Recommendation T.4 - "Standardization of Group 3
        Facsimile Apparatus for Document Transmission", June, 1996
   [T.6] ITU-T Recommendation T.6 - "Facsimile Coding Schemes and
        Coding Control Functions for Group 4 Facsimile Apparatus",
        March, 1993
   [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 -
        Final, June 3, 1992.
   [TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File
        Format (TIFF) - image/tiff:  MIME Sub-type Registration ", RFC
        2302, March 1998.
   [VPIM2] G. Vaudreuil and G. Parsons, "Voice Profile for Internet
        Mail - version 2", Work In Progress, <draft-ema-vpim-06.txt>,
        November 1997.

































Parsons & Rafferty           Informational                     [Page 24]

RFC 2306                     TIFF-F Profile                   March 1998


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Parsons & Rafferty           Informational                     [Page 25]