idnits 2.17.1 draft-ietf-fax-t30-capabilities-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 331 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MEDIA-FEATURES,FEATURE-ALGEBRA,, FEATURE-REG], [FEATURE-ALGEBRA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 305 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1999) is 9226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TIFF' is mentioned on line 163, but not defined == Missing Reference: 'FEATURE-ALG' is mentioned on line 245, but not defined == Missing Reference: 'AUTH' is mentioned on line 220, but not defined == Missing Reference: 'SMIME' is mentioned on line 223, but not defined == Missing Reference: 'PGP-MIME' is mentioned on line 224, but not defined == Missing Reference: 'SMTP-TLS' is mentioned on line 224, but not defined == Missing Reference: 'HTTP-SSL' is mentioned on line 224, but not defined == Unused Reference: 'EIFAX' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'FAX-REQ' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC2305' is defined on line 283, but no explicit reference was found in the text -- No information found for draft-ietf-fax-eifax-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EIFAX' -- No information found for draft-ietf-fax-requirements-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FAX-REQ' -- No information found for draft-ietf-conneg-feature-algebra-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FEATURE-ALGEBRA' -- No information found for draft-ietf-conneg-feature-reg-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FEATURE-REG' -- No information found for draft-ietf-conneg-media-features-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEDIA-FEATURES' ** Downref: Normative reference to an Informational RFC: RFC 1303 (ref. 'RFC2303') ** Obsolete normative reference: RFC 2304 (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 2305 (Obsoleted by RFC 3965) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Fax Working Group Dan Wing 2 Internet Draft Cisco Systems 3 August 7, 1998 4 Expires January 1999 5 draft-ietf-fax-t30-capabilities-00.txt 7 Expressing Fax Capabilities in Internet Protocols 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Copyright Notice 30 Copyright (C) The Internet Society (1998). All Rights Reserved. 32 1. Abstract 34 This document describes how the DIS Standard Capabilities and 35 Non-Standard Capabilities (NSF) of [T.30] can be expressed using the 36 format described by the IETF Content Negotiation Working Group 37 [MEDIA-FEATURES, FEATURE-ALGEBRA, FEATURE-REG]. 39 The format described in this document, and the format described 40 in [FEATURE-ALGEBRA] is intended to be usable in many Internet 41 protocols and by a variety of methods. The specific methods 42 are not described by this document. 44 2. Introduction 46 To exchange documents between a sender and recipient it is important 47 to know the display or print capabilities of the recipient. 49 The fax protocol [T.30] has a long-established method of 50 exchanging capabilities. The fax protocol requires a realtime 51 connection between the sender and receiver, and is not designed 52 to be cached by the sender or to be shared with multiple senders. 53 Additionally, the [T.30] capabilities exchange describes many 54 data link layer specific information which is not applicable 55 to an Internet application layer program. 57 On the Internet, it is not expected that document exchange 58 devices and software such as MUAs, printers, word processors, 59 or PostScript will have knowledge of the fax protocol [T.30], 60 except in the case of Internet Fax (IFax) devices themselves 61 or MultiFunction Periphials (MFPs). 63 Non-fax devices and software which creates, manipulates, or prints 64 images are more likely to use capability expressions which are more 65 portable across multiple devices than the capability expressions of 66 [T.30]. 68 The portion of the T.30 protocol used to indicate the 69 capabilities of the recipient is the DIS Standard Capabilities 70 (section 5.3.6.2.1 of [T.30]) and the Non-Standard Capabilities 71 (NSF, section 5.3.6.2.7 of [T.30]) which is used for vendor- 72 specific extensions. 74 This draft is being discussed on the "ietf-fax" mailing list. To 75 subscribe, send a message to: 76 ietf-fax-request@imc.org 77 with the line: 78 subscribe 79 in the body of the message. Archives are available from 80 . 82 3. Mapping DIS 84 The following DIS bits and their function are described in [T.30] and 85 mapped using the descriptions in the following sections. The 86 following sections use ABNF [RFC2234] to describe the syntax. 88 DIS bit number T.30 use Section 89 -------------- -------- ------- 90 1 Reserved 91 2 Reserved 92 3 Reserved 93 4 Reserved 94 5 Reserved 95 6 V.8 capabilities 3.1 96 7 256/64 octets preferred 3.1 97 8 Reserved 98 9 Polling 3.2 99 10 Receiver fax operation 3.1 100 11-14 Data signalling rate 3.1 101 15 Paper size 3.3 102 16 2D coding capability 3.1 103 17-18 Scan line width 3.3 104 19-20 Page height 3.3 105 21-23 Scan line receive rate 3.1 106 24 Extend field 3.1 107 25 Reserved 108 26 Uncompressed mode 3.11 109 27 Error correction mode 3.1 110 28 Must be 0 3.1 111 29 Reserved 112 30 Reserved 113 31 T.6 coding 3.4 114 32 Extend field 3.1 115 33-39 Reserved 116 40 Extend field 3.1 117 41 Paper size 3.3 118 42 ? ? 119 43 Paper size (inch/metric) 3.3 120 44 Inch resolution preferred 3.5 121 45 Metric resolution preferred 3.5 122 46 Scan line receive rate 3.1 123 47 Selective polling 3.2 124 48 Extend field 3.1 125 49 Subaddress 3.6 126 50 Password 3.10 127 51 Ready to xmit (polling) 3.2 128 52 Reserved 129 53-55 Binary File Transfer 3.7 130 56 Extend field 3.1 131 57 Binary File Transfer 3.7 132 58 Reserved 133 59 Ready for polling 3.2 134 60 Character mode ? 135 61 Reserved 136 62 Mixed mode (color) 3.8 137 63 Reserved 138 64 Extend field 3.1 139 65 T.505 ? 140 66 Digital network capable 3.1 141 67 Duplex/half-duplex 3.1 142 68 JPEG encoding 3.9 143 69 Full color mode 3.8 144 70 Must be 0 3.1 145 71 8 or 12 bits/pel/component 3.8 146 72 Extend field 3.1 147 73 Color subsampling 3.8 148 74 Custom illuminant 3.8 149 75 Custom gamut range 3.8 150 76-77 N. American letter/legal 3.3 151 78 T.85 capability ? 152 79 T.85 L0 capability ? 153 80 Extend field 155 3.1. Not Applicable to Content Negotiation 157 This item is not applicable to content negotiation. For 158 example, this item may refer to data rate of the modem, 159 if error correction mode is enabled, or the fastest receive 160 rate supported. 162 As only a file describing the data is transmitted between 163 the sender and receiver [TIFF], the only information necessary 164 is what data will be understood by the recipient, not other 165 information which is performed by the actual fax offramp. 167 3.2. Polling 169 With SMTP polling is acheived with the TURN, ETRN, and 170 ATRN commands [ref]. 172 With HTTP polling is acheived with GET [ref]. 174 With FTP polling is acheived with RETR. 176 Thus, information about a remote machine's ability to have messages 177 polled is not useful to use over the Internet. 179 3.3. Paper Size 181 Paper size is expressed as: 183 papersize = "Papersize" "=" token 185 token = "na-letter" / "iso-a4" / "iso-b4" / "iso-a3" / "na-legal" 187 3.4. Group 4 Facsimile 189 ? What do we want to say about group 4 191 3.5. Inch versus Metric resolution 193 The algebra of [FEATURE-ALG] handles both metric- and inch- 194 based measurements. 196 3.6. Subaddressing 198 Subaddressing is handled by the addressing format described 199 in [RFC2303, RFC2304], and is ignored by the fax offramp 200 if the legacy fax doesn't advertise support for subaddresses. 202 3.7. Binary File Transfer 204 Binary File Transfer is acheived on the Internet using FTP, 205 HTTP, and MIME messages in SMTP. 207 3.8. Color Transmission 209 ? What do we want to say about color 211 3.9. JPEG Encoding 213 For Internet Fax we are only supporting TIFF->FAX and FAX->TIFF. 215 3.10. Password 217 The password, used to authenticate the recipient, is 218 equivalent to the password necessary to retreive POP (or 219 IMAP) messages from a POP (or IMAP) server. Similar 220 authentication is available with SMTP with [AUTH], and 221 with the password with FTP. 223 With SMTP, stronger authentication is available with [SMIME] or 224 [PGP-MIME] and [SMTP-TLS], and with HTTP with [HTTP-SSL]. 226 The fax offramp may wish to use the legacy machine's supplied 227 password to authenticate the recipient. This could be done 228 by comparing a special field in the recipient's email address 229 (if using SMTP), such as "/T30PASSWORD=8924". 231 3.11. Compression 233 XXX - we need to determine if the offramp will be responsible 234 for changing compressions, or if this will be something that 235 is expressed as one of the CONNEG features. 237 4. Mapping Non-Standard Features (NSF) 239 Many fax manufacturers support features that are not part 240 of the [T.30] specification. These features allow better 241 compression, higher resolution, or provide other similar value- 242 add features. 244 Each fax manufacturer which wishes to provide such a feature 245 should map the feature to the algebra described in [FEATURE-ALG]. 246 This allows the feature to be expressed to senders using 247 the same mechanism as described in section 3 of this document. 249 5. Security Considerations 251 ? 253 5. Acknowledgments 255 XXX 257 7. References 259 [EIFAX] L. Masinter, D. Wing, "Extended Facsimile Using Internet 260 Mail", Internet Draft, Work in Progress, draft-ietf-fax-eifax-XX.txt 262 [FAX-REQ] L. Masinter, "Requirements for Internet FAX", Internet 263 Draft, Work in Progress, draft-ietf-fax-requirements-XX.txt. 265 [FEATURE-ALGEBRA] G. Klyne, "An algebra for describing media feature 266 sets", Internet Draft, Work in Progress, 267 draft-ietf-conneg-feature-algebra-XX.txt. 269 [FEATURE-REG] K. Holtman, A. Mutz, T. Hardie, "Content Feature Tag 270 Registration Procedure", Internet Draft, Work in Progress, 271 draft-ietf-conneg-feature-reg-XX.txt. 273 [MEDIA-FEATURES] L. Masinter, K. Holtman, D. Wing, "Media Features 274 for Display, Print, and Fax", Internet Draft, Work in Progress, 275 draft-ietf-conneg-media-features-XX.txt. 277 [RFC2303] C. Allocchio, "Minimal PSTN address format in Internet 278 Mail", RFC 1303, March 1998. 280 [RFC2304] C. Allocchio, "Minimal FAX address format in Internet 281 Mail", RFC 2304, March 1998. 283 [RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 284 Facsimile Using Internet Mail", RFC 2305, March 1998. 286 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 287 Specifications: ABNF", RFC 2234, November 1997. 289 [T.30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission 290 in the General Switched Telephone Network", ITU-T (CCITT), 291 Recommendation T.30, July, 1996. 293 9. Copyright 295 Copyright (C) The Internet Society 1998. All Rights Reserved. 297 This document and translations of it may be copied and furnished to 298 others, and derivative works that comment on or otherwise explain it 299 or assist in its implmentation may be prepared, copied, published and 300 distributed, in whole or in part, without restriction of any kind, 301 provided that the above copyright notice and this paragraph are 302 included on all such copies and derivative works. However, this 303 document itself may not be modified in any way, such as by removing 304 the copyright notice or references to the Internet Society or other 305 Internet organizations, except as needed for the purpose of 306 developing Internet standards in which case the procedures for 307 copyrights defined in the Internet Standards process must be 308 followed, or as required to translate it into languages other than 309 English. 311 The limited permissions granted above are perpetual and will not be 312 revoked by the Internet Society or its successors or assigns. 314 This document and the information contained herein is provided on an 315 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 316 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 317 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 318 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 319 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 10. Author's Address 323 Dan Wing 324 Cisco Systems, Inc. 325 101 Cooper Street 326 Santa Cruz, CA 95060 USA 328 Phone: +1 408 457 5200 329 Fax: +1 408 457 5208 330 EMail: dwing@cisco.com