One document matched: draft-ietf-fax-t30-capabilities-00.txt
Fax Working Group Dan Wing
Internet Draft Cisco Systems
August 7, 1998
Expires January 1999
draft-ietf-fax-t30-capabilities-00.txt
Expressing Fax Capabilities in Internet Protocols
Status of this memo
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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Abstract
This document describes how the DIS Standard Capabilities and
Non-Standard Capabilities (NSF) of [T.30] can be expressed using the
format described by the IETF Content Negotiation Working Group
[MEDIA-FEATURES, FEATURE-ALGEBRA, FEATURE-REG].
The format described in this document, and the format described
in [FEATURE-ALGEBRA] is intended to be usable in many Internet
protocols and by a variety of methods. The specific methods
are not described by this document.
2. Introduction
To exchange documents between a sender and recipient it is important
to know the display or print capabilities of the recipient.
The fax protocol [T.30] has a long-established method of
exchanging capabilities. The fax protocol requires a realtime
connection between the sender and receiver, and is not designed
to be cached by the sender or to be shared with multiple senders.
Additionally, the [T.30] capabilities exchange describes many
data link layer specific information which is not applicable
to an Internet application layer program.
On the Internet, it is not expected that document exchange
devices and software such as MUAs, printers, word processors,
or PostScript will have knowledge of the fax protocol [T.30],
except in the case of Internet Fax (IFax) devices themselves
or MultiFunction Periphials (MFPs).
Non-fax devices and software which creates, manipulates, or prints
images are more likely to use capability expressions which are more
portable across multiple devices than the capability expressions of
[T.30].
The portion of the T.30 protocol used to indicate the
capabilities of the recipient is the DIS Standard Capabilities
(section 5.3.6.2.1 of [T.30]) and the Non-Standard Capabilities
(NSF, section 5.3.6.2.7 of [T.30]) which is used for vendor-
specific extensions.
This draft is being discussed on the "ietf-fax" mailing list. To
subscribe, send a message to:
ietf-fax-request@imc.org
with the line:
subscribe
in the body of the message. Archives are available from
<http://www.imc.org/ietf-fax>.
3. Mapping DIS
The following DIS bits and their function are described in [T.30] and
mapped using the descriptions in the following sections. The
following sections use ABNF [RFC2234] to describe the syntax.
DIS bit number T.30 use Section
-------------- -------- -------
1 Reserved
2 Reserved
3 Reserved
4 Reserved
5 Reserved
6 V.8 capabilities 3.1
7 256/64 octets preferred 3.1
8 Reserved
9 Polling 3.2
10 Receiver fax operation 3.1
11-14 Data signalling rate 3.1
15 Paper size 3.3
16 2D coding capability 3.1
17-18 Scan line width 3.3
19-20 Page height 3.3
21-23 Scan line receive rate 3.1
24 Extend field 3.1
25 Reserved
26 Uncompressed mode 3.11
27 Error correction mode 3.1
28 Must be 0 3.1
29 Reserved
30 Reserved
31 T.6 coding 3.4
32 Extend field 3.1
33-39 Reserved
40 Extend field 3.1
41 Paper size 3.3
42 ? ?
43 Paper size (inch/metric) 3.3
44 Inch resolution preferred 3.5
45 Metric resolution preferred 3.5
46 Scan line receive rate 3.1
47 Selective polling 3.2
48 Extend field 3.1
49 Subaddress 3.6
50 Password 3.10
51 Ready to xmit (polling) 3.2
52 Reserved
53-55 Binary File Transfer 3.7
56 Extend field 3.1
57 Binary File Transfer 3.7
58 Reserved
59 Ready for polling 3.2
60 Character mode ?
61 Reserved
62 Mixed mode (color) 3.8
63 Reserved
64 Extend field 3.1
65 T.505 ?
66 Digital network capable 3.1
67 Duplex/half-duplex 3.1
68 JPEG encoding 3.9
69 Full color mode 3.8
70 Must be 0 3.1
71 8 or 12 bits/pel/component 3.8
72 Extend field 3.1
73 Color subsampling 3.8
74 Custom illuminant 3.8
75 Custom gamut range 3.8
76-77 N. American letter/legal 3.3
78 T.85 capability ?
79 T.85 L0 capability ?
80 Extend field
3.1. Not Applicable to Content Negotiation
This item is not applicable to content negotiation. For
example, this item may refer to data rate of the modem,
if error correction mode is enabled, or the fastest receive
rate supported.
As only a file describing the data is transmitted between
the sender and receiver [TIFF], the only information necessary
is what data will be understood by the recipient, not other
information which is performed by the actual fax offramp.
3.2. Polling
With SMTP polling is acheived with the TURN, ETRN, and
ATRN commands [ref].
With HTTP polling is acheived with GET [ref].
With FTP polling is acheived with RETR.
Thus, information about a remote machine's ability to have messages
polled is not useful to use over the Internet.
3.3. Paper Size
Paper size is expressed as:
papersize = "Papersize" "=" token
token = "na-letter" / "iso-a4" / "iso-b4" / "iso-a3" / "na-legal"
3.4. Group 4 Facsimile
? What do we want to say about group 4
3.5. Inch versus Metric resolution
The algebra of [FEATURE-ALG] handles both metric- and inch-
based measurements.
3.6. Subaddressing
Subaddressing is handled by the addressing format described
in [RFC2303, RFC2304], and is ignored by the fax offramp
if the legacy fax doesn't advertise support for subaddresses.
3.7. Binary File Transfer
Binary File Transfer is acheived on the Internet using FTP,
HTTP, and MIME messages in SMTP.
3.8. Color Transmission
? What do we want to say about color
3.9. JPEG Encoding
For Internet Fax we are only supporting TIFF->FAX and FAX->TIFF.
3.10. Password
The password, used to authenticate the recipient, is
equivalent to the password necessary to retreive POP (or
IMAP) messages from a POP (or IMAP) server. Similar
authentication is available with SMTP with [AUTH], and
with the password with FTP.
With SMTP, stronger authentication is available with [SMIME] or
[PGP-MIME] and [SMTP-TLS], and with HTTP with [HTTP-SSL].
The fax offramp may wish to use the legacy machine's supplied
password to authenticate the recipient. This could be done
by comparing a special field in the recipient's email address
(if using SMTP), such as "/T30PASSWORD=8924".
3.11. Compression
XXX - we need to determine if the offramp will be responsible
for changing compressions, or if this will be something that
is expressed as one of the CONNEG features.
4. Mapping Non-Standard Features (NSF)
Many fax manufacturers support features that are not part
of the [T.30] specification. These features allow better
compression, higher resolution, or provide other similar value-
add features.
Each fax manufacturer which wishes to provide such a feature
should map the feature to the algebra described in [FEATURE-ALG].
This allows the feature to be expressed to senders using
the same mechanism as described in section 3 of this document.
5. Security Considerations
?
5. Acknowledgments
XXX
7. References
[EIFAX] L. Masinter, D. Wing, "Extended Facsimile Using Internet
Mail", Internet Draft, Work in Progress, draft-ietf-fax-eifax-XX.txt
[FAX-REQ] L. Masinter, "Requirements for Internet FAX", Internet
Draft, Work in Progress, draft-ietf-fax-requirements-XX.txt.
[FEATURE-ALGEBRA] G. Klyne, "An algebra for describing media feature
sets", Internet Draft, Work in Progress,
draft-ietf-conneg-feature-algebra-XX.txt.
[FEATURE-REG] K. Holtman, A. Mutz, T. Hardie, "Content Feature Tag
Registration Procedure", Internet Draft, Work in Progress,
draft-ietf-conneg-feature-reg-XX.txt.
[MEDIA-FEATURES] L. Masinter, K. Holtman, D. Wing, "Media Features
for Display, Print, and Fax", Internet Draft, Work in Progress,
draft-ietf-conneg-media-features-XX.txt.
[RFC2303] C. Allocchio, "Minimal PSTN address format in Internet
Mail", RFC 1303, March 1998.
[RFC2304] C. Allocchio, "Minimal FAX address format in Internet
Mail", RFC 2304, March 1998.
[RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC 2305, March 1998.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[T.30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission
in the General Switched Telephone Network", ITU-T (CCITT),
Recommendation T.30, July, 1996.
9. Copyright
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 implmentation 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.
10. Author's Address
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Phone: +1 408 457 5200
Fax: +1 408 457 5208
EMail: dwing@cisco.com
| PAFTECH AB 2003-2026 | 2026-04-23 06:09:57 |