One document matched: draft-ietf-fax-itudc-00.txt
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please
check the ``1id-abstracts.txt'' listing contained in the
Internet- Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).
INTRODUCTION
NOTE: The distribution of this document to the IETF
Fax WG was authorized by Study Group 8. The
information herein is made available for use by the
Fax WG. The material is copyright ITU-T and is not
for further publication.
This document is based on a draft which received an
affirmative "determination" at the October, 1997 meeting of
ITU Study Group 8. This version tunes and corrects some
portions of that document, as well as creating an alternate
organization and separating some control and value-added
functions from the core process of sending a facsimile
document. One of the goals of the reorganization is to
facilitate use for simple facsimile over the Internet,
possibly even compatible with the work being done by the IETF
Fax working group, while still permitting use for the more
advanced features desired by some constituencies of the ITU
Study Group.
ITU - Telecommunication Standadization Sector Temporary
Document
Study Group 8
Geneva, 7-
16 October
1997
Question: 4/8
SOURCE*: Internet Society
TITLE: PROPOSED REVISION OF NEW DRAFT PROCEDURES FOR THE
TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL
________
Based on discussons with the author of TD 2128, the enclosed
document attempts a reorganization and revision of TD 2128 to
improve interworking with Internet mail end users and to
simplify the specification and distinction between Simple and
Basic Internet Fax services.
The enclosed revised copy of TD2128 includes the following
changes:
1. Revised list of References to include additional RFC
specifications
2. Revision of document structure to distinguish Basic and
Simple Internet fax within the main body of the document
3. Revision of Basic Internet Fax to form a functional core
service.
4. Revision of specification for Simple Internet Fax to
build upon the specification of Simple Internet Fax
5. Addition of sections for Internet mail addressing,
tailored for use with Internet Fax.
6. Addition of sections for Internet mail message headers,
to specify the headers required for use with Internet Fax.
7. Addition of section specifying delivery confirmation
through use of existing Internet mail standards.
8. Revision of specification for exchange of capabilities,
to use separate MIME type during a message exchange without
other facsimile data.
9. Inclusion of annotations for opportunities to incorporate
IETF RFCs by reference.
INTERNATIONAL TELECOMMUNICATIONS Draft
UNION Recommendatio
n
TELECOMMUNICATION T.Ifax1
STANDARDISATIZATION SECTOR
STUDY PERIOD 1997 - 2000 October 1997
Original:
English only
PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA STORE AND
FORWARD ON THE INTERNET
CONTENTS:
1. SUMMARY AND SCOPE 7
2. INTRODUCTION AND BACKGROUND 7
3. REFERENCES 7
4. DEFINITIONS AND ABBREVIATIONS 8
5. SIMPLE INTERNET FAX 8
5.1 REASON FOR SIMPLE STORE AND FORWARD FACSIMILE 8
5.2 ADDRESSING 9
5.3 MESSAGE STRUCTURE 9
5.4 MESSAGE HEADERS 10
5.4.1 DATE: 10
5.4.2 FROM: 10
5.4.3 TO: AND CC: 10
5.4.4 MESSAGE-ID: 10
6. BASIC INTERNET FAX 10
6.1 ADDRESSING 10
6.2 MESSAGE STRUCTURE 10
6.3 MESSAGE HEADERS 11
7. CONFIRMATION OF RECEIPT 11
8. EXCHANGE OF CAPABILITIES 12
8.1.1 G3: SENDER'S CAPABILITIES 13
8.1.2 X"0A" G3: SENDER'S FACSIMILE TELEPHONE NUMBER1
3
8.1.3 X"0B" G3: NSF SIGNAL 13
8.1.4 X"0C" G3: NSS SIGNAL 13
8.1.5 X"0D" G3: NSC SIGNAL 13
8.1.6 G4 CAPABILITIES 13
9. FACSIMILE POLLING 13
9.1 MIME LABEL FOR DOCUMENT-RETRIEVAL BODY-PART 14
9.2 FORMAT OF THE DOCUMENT-RETRIEVAL BODY-PART 14
9.2.1 X"0F" G3: SELECTIVE POLL 14
9.2.2 G3: PASSWORD 14
9.2.3 G3: DTC 14
ANNEX A: TIFF-F FORMAT 16
A.1 REFERENCES, DEFINITIONS AND ABBREVIATIONS 16
A.2 TIFF 16
A.2.1 REFERENCES, DEFINITIONS AND ABBREVIATIONS 16
A.3 MIME LABELLING 16
A.4 TIFF-F 16
A.4.1 IFD AND IMAGE DATA 16
A.4.2 FACSIMILE CAPABILITIES 20
(XRESOLUTION,YRESOLUTION) = (200,200) IS CONSIDERED AS
EQUIVALENT TO (204,196) 20
ANNEX B: TIFF-FX FORMAT 21
B.1 MIME LABELLING 21
B.2 TIFF-FX 21
B.3 COPY OF THE CONTENTS OF GENEVA OCTOBER 7-16 TEMPORARY
DOCUMENT TD 2100 TO GO HERE. 21
APPENDIX A: SAMPLE TRANSACTIONS 22
APPENDIX B - A MULTIPART EXAMPLE 30
_1. Summary and scope
This Recommendation:
a) defines procedures that enable facsimile data to be
transferred via Internet Email.
b) supports the requirements of F.IFax.
c) defines a method for identifying the capabilities of the
remote equipment.
d) defines a method for providing positive or negative
acknowledgement of receipt.
e) does not require changes to current ITU facsimile
Recommendations.
f) does not require changes to current IETF internet
standards.
g) does not require terminals to have multi-page memory.
h) permits extensive interworking between facsimile and
Internet mail users and facilities, sharing common services
where possible and isolated facsimile-specific functions
2. Introduction and Background
F.IFax, defines the service requirement for both real-time and
store and forward facsimile over the Internet. For store and
forward facsimile this Recommendation defines addressing, MIME
encapsulation of document components and data formats for
those components..
Store and forward facsimile uses Internet mail standard
protocols for posting, relaying and delivery of store and
forward facsimile document. It requires no changes to Internet
standards or to ITU Facsimile Recommendations. Such an
approach leads to a system that can be used universally
without changes to Internet servers or other intermediate
systems between the sender and the recipient and which permits
interworking between facsimile store and forward users and
users of general Internet mail.
3. References
The following ITU-T Recommendations, and other references
contain provisions which, through reference in this text,
constitute provisions of this Recommendation. At the time of
publication, the editions indicated were valid. All
Recommendations and other references are subject to revision;
all users of this Recommendation are therefore encouraged to
investigate the possibility of applying the most recent
edition of the Recommendations and other references listed
below. A list of the currently valid ITU-T Recommendations is
regularly published.
Internet RFC (Request For Comments) documents are available
via http://ds.internic.net/ds/dspg/intdoc.html.
1. ITU-T T.30: Procedures for document facsimile
transmission in the general switched telephone network
2. ITU-T T.4: Standardization of Group 3 facsimile apparatus
for document transmission
3. ITU-T T.6: Facsimile coding schemes and coding control
functions for Group 4 facsimile apparatus
4. ITU-T T.50: International Reference Alphabet (IRA)
5. ITU-T E.164: Numbering plan for the ISDN era
6. ITU-T F.IFax: Internet facsimile: operations and
definition of service
7. ISO 8601:1988: Data elements and interchange formats
–representation of dates and times
8. ISO 2111: Data Communications - basic mode control
procedures - code independent information transfer
9. RFC 822: Standard for the format of ARPA Internet text
messages
10. RFC 821: Simple Mail Transfer Protocol
11. RFC-2045: Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies
12. RFC-2046: Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types
13. RFC-2047: MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text
14. RFC-2048: Multipurpose Internet Mail Extensions (MIME)
Part Four: Registration Procedures
15. RFC-2049: Multipurpose Internet Mail Extensions (MIME)
Part Five: Conformance Criteria and Examples
16. RFC-1725: Post Office Protocol – Version 3
17. ITU-T T.563: Terminal characteristics for Group 4
facsimile apparatus
18. RFC 1123: Requirements for Internet Hosts -- Application
and Support
19. RFC-1891 SMTP Service Extension for Delivery Status
Notifications
20. RFC-1894 An Extensible Message Format for Delivery Status
Notifications
4. Definitions and abbreviations
All abbreviations are as per documents ITU-T T.30 and ITU-
F.IFax unless specifically stated otherwise.
G3 Group 3 facsimile
G4 Group 4 facsimile
Relay
terminal A receiving system capable of relaying the received
facsimile to one or more Group 3 or Group 4
facsimile terminals
Email Electronic Mail
IETF Internet Engineering Task Force
IMAP Internet Mail Access Protocol version 4
MIME Multipurpose Internet Mail Extensions
POP3 Post Office Protocol version 3
RFC Request For Comment (Draft IETF standard)
SMTP Simple Mail Transfer Protocol
TIFF Tagged Image File Format
UTC Coordinated Universal Time: Time scale, based on the
second (SI)
IP Internet Protocol
TCP Transmission Control Protocol
In the descriptions below the following formats are used to
represent octet values:
X"nn" hexadecimal
B"nnnnnnnn" binary: X"A3" = B"10100011"
nnnn nnnn ITU format as bits are received: X"A3" =
B"10100011" = 1100 0101
5. Simple Internet Fax
5.1 Reason for simple store and forward facsimile
This mode is designed so that a facsimile terminal sends and
receives the facsimile document as an image attached to an
Email.
5.2 Addressing
(This sub-section may be replaced by RFC citation, if the
current IETF specification for facsimile addressing is
published in a sufficiently timely fashion.)
Specification of store and forward facsimile senders and
recipients is accomplished by the use existing Internet mail
addressing mechanisms and standards. Those mechanisms are
tailored for store and forward facsimile through a compatible
profile, which encodes the information required to refer to a
facsimile terminal and the store and forward relay which
connects that terminal to the Internet mail service.
simple-fax-mbox = "FAX=" ( global-phone / local-
phone )
global-phone = "+" digit-string
local-phone = digit-string
digit-string = 1*(DIGIT / "-" / ".")
5.3 Message structure
The structure of an Internet mail message containing a
facsimile is:
Table 1/T.IFax - Simple store and forward facsimile Format
DESCRIPTI NOTE
ON
Email 1
envelope
Email 2
header
Image 3
Data
Notes:
1. Envelope information specifies the list of destinations
to which the message is currently being sent, as well as the
address of the agent which posted the message, and any other
transfer-specific information which applies to the current
transfer of the message. Normally this information is carried
via SMTP (Reference 10, 18) commands.
2. This contains all normal end-to-end Internet mail message
header fields such as "To:", "From:", "CC:", "BCC:", "Reply
to:" etc., as documented in (References 9, 18) and extensions.
3. The body of the email is a MIME part which contains one
or more pages of image data in the format defined in Annex A.
4. Some terminals may transmit character coded information
with or without image data using Multipart/mixed. It is
recommended that a terminal supporting the format defined here
be designed to process such mixed content email; however it is
outside the specification of this annex.
5.4 Message headers
The following standard Internet mail headers are required for
facsimile store and forward:
5.4.1 Date:
This contains the date and time of message posting
5.4.2 From:
This specifies the originator (author) of the message
5.4.3 To: and CC:
These list the primary and secondary recipients, respectively,
for the message. The lists can be a mixture of general
Internet mail addresses and Internet mail addresses tailored
for use by facsimile store and forward, as defined in Section
5.1.
5.4.4 Message-ID:
This is a unique string which identifyies the message
6. Basic Internet Fax
6.1 Addressing
(This sub-section may be replaced by RFC citation, if the
current IETF specification for facsimile addressing is
published in a sufficiently timely fashion.)
basic-fax-mbox = simple-fax-mbox
[ sub-sep sub-addr ]
[ post-sep post-dial]
sub-sep =
sub-addr =
; This contains the contents of the T.30
SUB FIF.
post-sep =
post-dial =
6.2 Message structure
The structure of an Email message containing a Basic facsimile
store and forward message is the same as for Simple Internet
Fax, with the addition of support for binary file data using
standard MIME structuring and labelling:
Table 2/T.IFax - Basic Store and forward facsimile Format
DESCRIPTI NOTE
ON
Email 1
envelope
Email 2
header
Image 3
Data
Binary 4
File Data
Notes:
1. This is the same as for Simple Internet Fax.
2. This is the same as for Simple Internet Fax.
3. The body of the email is a MIME part which contains one
or more pages of image data in the format defined in Annex B.
4. This MIME part contains other binary file data using any
of the formats acceptable for facsimile.
5. Where possible the content types for binary files should
be the same as those already existing. Where no suitable
content type exists it will be necessary to apply for a new
content type after consultation with the IETF. This paragraph
needs detailed specification of the alignment between BFT and
MIME types.)
6. Binary file parts and image data parts may be interleaved
in any order.
6.3 Message headers
Message headers are the same as for Basic Internet fax.
7. Confirmation of receipt
Senders of facsimile store and forward may request delivery
confirmation. Existing Internet mail Delivery Service
Notification (DSN) (Reference 19, 20) mechanisms shall be
used.
Facsimile store and forward recipients which receive a DSN
request must return a delivery service notice, upon successful
delivery of the facsimile.
For the purposes of facsimile store and forward relay devices,
the DSN shall be issued upon receipt of the confirmation
message from the target facsimile station. For the purposes
of Internet mail recipients, the DSN shall be issued according
the standard rules specified for DSNs.
8. Exchange of capabilities
Facsimile store and forward participants may wish to
communicate their capabilities prior to sending a facsimile.
A special MIME Content-Type is defined for this purpose, in
place of the Image Data MIME body-part present in a facsimile
message. In all other respects the capabilities message shall
conform to requirements for Simple or Basic Internet
Facsimile.
The sending system must make use of the "Capabilities Request"
message type to obtain the capabilities of the recipient.
This can be done as part of a first facsimile transmission or
as a special transmission using the ITU header alone with no
image or binary data. The sending system should store the
recipient's capabilities for use during future transmissions.
The sender of any message using the procedures defined in this
Recommendation shall be free to use any valid facsimile
capabilities during its first call to other equipment. If the
receiving equipment can process the data transmitted it will
send back an acknowledgement of successful reception otherwise
it will send back an acknowledgement indicating "Capabilities
mismatch".
8.1 MIME label for exchange of capabilities body part
The MIME label is:
Content-Type: application/fax-poll
(NB: this section may also be expressed in ASN.1 notation
following an editorial update from those desiring such
notation):
The MIME label is:
Content-Type:application/fax-capabilities
8.2 Format of exchange of capabilities body-part
The Application/Fax-Capabilities MIME part contains the
following data (NB: this section may also be expressed in
ASN.1 notation following an editorial update from those
desiring such notation):
3/T.IFax: Exchange of Capabilities Body-Part
Description Mandato Repeata Field
ry ble Type
DIS: G3 sender's Yes1 No X"09"
capabilities
TSI: G3 sender's No No X"0A"
facsimile number
NSF: G3 NSF signal No No X"0B"
NSS: G3 NSS signal No No X"0C"
NSC: G3 NSS signal No No X"0D"
G4 capabilities Yes2 No X"12"
Notes:
1 For Group 3 only
2 For Group 4 only
All fields within the ITU header part have the following
format:
Field type Data length Data
Field type (1 octet)
Data length (2 octets: low octet/high octet order)
Data (Of defined length)
The desirability of an extension method for this format is to
be studied and, if it is felt necessary, a method is to be
added to this draft Recommendation.
The following field types are allocated:
8.2.1 G3: Sender's capabilities
This contains the contents of the T.30 DIS FIF. It is present
in all messages and identifies the capabilities of the sender.
8.2.2 X"0A" G3: Sender's facsimile telephone number
This contains the contents of the T.30 TSI FIF.
8.2.3 X"0B" G3: NSF signal
This contains the contents of the T.30 NSF FIF.
8.2.4 X"0C" G3: NSS signal
This contains the contents of the T.30 NSS FIF.
8.2.5 X"0D" G3: NSC signal
This contains the contents of the T.30 NSC FIF.
8.2.6 G4 capabilities
This contains Group 4 applications capability data as defined
in T.563 Appendix II.
The sender of any message using the procedures defined in this
Recommendation shall be free to use any valid facsimile
capabilities during its first call to other equipment. If the
receiving equipment can process the data transmitted it will
send back an acknowledgement of successful reception otherwise
it will send back an acknowledgement indicating "Capabilities
mismatch".
9. Facsimile polling
Facsimile store and forward participants may wish to poll a
destination facsimile station, to request return transmission
of one or more fax documents. A special MIME Content-Type is
defined for this purpose, in place of the Image Data MIME body-
part present in a facsimile message. In all other respects
the capabilities message shall conform to requirements for
Simple or Basic Internet Facsimile.
The sender of any message using the procedures defined in this
Recommendation shall be free to request any facsimile
document. If the receiving equipment can process the data
transmitted it will send back the requested document(s);
otherwise it will send back an acknowledgement indicating
"Document(s) unavailable".
9.1 MIME label for Document-Retrieval body-part
The MIME label is:
Content-Type: application/fax-poll
(NB: this section may also be expressed in ASN.1 notation
following an editorial update from those desiring such
notation):
9.2 Format of the Document-Retrieval body-part
The ITU header MIME part contains the following data (NB: this
section may also be expressed in ASN.1 notation following an
editorial update from those desiring such notation):
Table 2/T.IFax: ITU Header Format
Description Mandato Repeata Field
ry ble Type
SEP: G3 selective No Yes X"0F"
poll
PWD: G3 password No Yes X"10"
DTC: G3 polling No No X"11"
request
Notes:
1 Where known
2 For Group 3 only
3 For Group 4 only
All fields within the ITU header part have the following
format:
Field type Data length Data
Field type (1 octet)
Data length (2 octets: low octet/high octet order)
Data (Of defined length)
The desirability of an extension method for this format is to
be studied and, if it is felt necessary, a method is to be
added to this draft Recommendation.
The following field types are allocated:
9.2.1 X"0F" G3: Selective poll
This contains the contents of the T.30 SEP FIF.
9.2.2 G3: Password
This contains the contents of the T.30 PWD FIF.
9.2.3 G3: DTC
This contains the contents of the T.30 DTC FIF. This is used
for a non-selective poll or turnaround poll.
Annex A: TIFF-F format
(This annex forms an integral part of this Recommendation)
Editorial consideration will be given to reconciling Annex A
and Annex B.
A.1 References, definitions and abbreviations
IFD : Image File directory
(See main body of this Recommendation for other references,
definitions and abbreviations)
A.2 TIFF
(This annex forms an integral part of this Recommendation)
Editorial consideration will be given to reconciling Annex A
and Annex B.
A.2.1 References, definitions and abbreviations
TIFF: "The TIFF 6.0 specification dated June 3, 1992
specification © 1986-1988, 1992 Adobe Systems Incorporated.
All Rights Reserved"
This Annex is not a complete definition of TIFF but is,
instead, a use of a particular TIFF specification referenced.
This annex includes a definition of an extension to TIFF to
meet the requirements of facsimile. Under the terms of the
letter dated September 19th 1997 from Adobe Systems
Incorporated to the Director if the ITU-T Adobe grants a
license to use the TIFF specification as the basis for an ITU
Recommendation. Detailed terms are contained within the
letter which is available from the ITU.
(See main body of this Recommendation for other references,
definitions and abbreviations)
A.3 MIME labelling
The email body part which contains the TIFF-F file shall be
preceded by the following indicator.
Content-type: Image/TIFF
(specific type/subtype & parameter details need to be
reconciled with IETF documents currently in Working Group
Last Call.)
TIFF creates binary data which shall may need MIME Content-
Transfer-Encoding, such as Base64, for carriage through
Internet mail relay systems. Hence is may be necessary to
convert the binary data to MIME base64 format and to follow
the Content-Type MIME header with:
Content-Transfer-Encoding: base64
A.4 TIFF-F
(This sub-section may be replaced by RFC citation, if the
current IETF specification for TIFF-F is published in a
sufficiently timely fashion.)
In this section a minimum set of TIFF features is described.
A.4.1 IFD and image data
Flexibility of positioning IFD and image data in a TIFF data
stream is constrained in the format defined in this annex.
The three elements of a TIFF file: Header, IFD and Image data;
shall appear as shown in Fig, Annex A.1/T.IFax. Header
information shall be at the beginning of the file and IFD and
Image data shall follow in pairs according to page order. A
pair of IFD and Image data shall correspond to one page of the
facsimile document.
Fig. Annex A.1/T.IFax - Sequence of Header, IFD and image
data
The fixed values used in the Header field are described in
Table Annex A-1/T.IFax.
Table Annex A.1/T.IFax - Header
Off Value
set Descripti
on
0 Byte 0x4949
Order
2 42 0x2A
4 Offset
of 1st 0x00000
IFD 008
The structure of an IFD is described in Table Annex A.2/T.IFax
along with coding samples.
| PAFTECH AB 2003-2026 | 2026-04-23 17:16:55 |