idnits 2.17.1 draft-ietf-fax-feature-schema-01.txt: 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. 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 ([5], [1,2,3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 128: '... "SHOULD", SHOULD NOT", "RECOMMENDED"...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Work-in-progress', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (October 1998) is 9325 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 130 -- Looks like a reference, but probably isn't: '1-7' on line 313 == Missing Reference: '13' is mentioned on line 540, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2301 (ref. '7') (Obsoleted by RFC 3949) ** Obsolete normative reference: RFC 2305 (ref. '8') (Obsoleted by RFC 3965) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Fax working group Graham Klyne 3 Request for comments: nnnn 5GM/Content Technologies 4 Category: Work-in-progress Lloyd McIntyre 5 Xerox Corporation 6 October 1998 7 Expires: April 1999 9 Content feature schema for Internet fax 10 12 Status of this memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as ``work in 23 progress''. 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 30 West Coast). 32 [[INTENDED STATUS: This document specifies an Internet standards 33 track protocol for the Internet community, and requests discussion 34 and suggestions for improvements. Please refer to the current 35 edition of the "Internet Official Protocol Standards" (STD 1) for 36 the standardization state and status of this protocol. 37 Distribution of this memo is unlimited.]] 39 Copyright Notice 41 Copyright (C) The Internet Society 1998. All Rights Reserved. 43 Abstract 45 This document defines a content feature schema that is a profile of 46 the media feature registration mechanisms [1,2,3] for use in 47 performing capability identification between extended Internet fax 48 systems [5]. 50 RFC nnnn Content feature schema for Internet fax October 1998 52 This document does not describe any specific mechanisms for 53 communicating capability information, but does presume that any 54 such mechanisms will transfer textual values. It specifies a 55 textual format to be used for describing Internet fax capability 56 information. 58 Table of contents 60 1. Introduction ............................................2 61 1.1 Organization of this document 3 62 1.2 Terminology and document conventions 3 63 1.3 Revision history 3 64 1.4 Unfinished business 4 65 2. Fax feature schema syntax ...............................4 66 3. Internet fax feature tags ...............................4 67 3.1 Image Size 5 68 3.2 Resolution 5 69 3.3 Media type 6 70 3.4 Paper Size 6 71 3.5 Colour and greyscale 6 72 3.6 Coding 7 73 3.7 Colour model 8 74 3.8 Preferred units 8 75 4. Examples ................................................8 76 4.1 Simple mode Internet fax system 8 77 4.2 High-end black-and-white Internet fax system 9 78 4.3 Grey-scale Internet fax system 9 79 4.4 Full-colour Internet fax system (JPEG) 9 80 4.5 Full-colour Internet fax system (MRC) 9 81 4.6 Sender and receiver feature matching 9 82 5. Security considerations .................................12 83 5.1 Threats 12 84 6. Full copyright statement ................................12 85 7. Acknowledgements ........................................13 86 8. References ..............................................13 87 9. Authors' addresses ......................................15 88 Appendix A: Feature registrations ..........................15 90 1. Introduction 92 This document defines a content feature schema that is a profile of 93 the media feature registration mechanisms [1,2,3] for use in 94 performing capability identification between extended Internet fax 95 systems [5]. 97 This document does not describe any specific mechanisms for 98 communicating capability information, but does presume that any 99 such mechanisms will transfer textual values. It specifies a 100 textual format to be used for describing Internet fax capability 101 information. 103 RFC nnnn Content feature schema for Internet fax October 1998 105 The range of capabilities that can be indicated are based on those 106 covered by the TIFF file format for Internet fax [7] and Group 3 107 facsimile [6]. A companion document [4] describes the relationship 108 and mapping between this schema and Group 3 fax capabilities. 110 1.1 Organization of this document 112 Section 2 specifies the overall syntax for fax feature descriptions 113 by reference to the media feature registration and syntax documents 114 [1,2]. 116 Section 3 enumerates the feature tags that are to be recognized and 117 processed by extended Internet fax systems, according to their 118 capabilities. 120 Appendix A contains additional feature tag registrations for media 121 features that are specific to fax and for which no applicable 122 registration already exists. These are presented in the form 123 prescribed by the media feature registration procedure [1]. 125 1.2 Terminology and document conventions 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 The term "eifax system" is used to describe any software, device or 132 combination of these that conforms to the specification "Extended 133 Facsimile Using Internet Mail" [5]. 135 NOTE: Comments like this provide additional nonessential 136 information about the rationale behind this document. 137 Such information is not needed for building a conformant 138 implementation, but may help those who wish to understand 139 the design in greater depth. 141 1.3 Revision history 143 00a 28-Sep-1998 Initial draft. 145 01a 12-Oct-1998 Incorporated review comments. Described feature 146 tag for differential x/y resolution ratio. 148 RFC nnnn Content feature schema for Internet fax October 1998 150 1.4 Unfinished business 152 - Review terminology (especially eifax). 154 - Finalize feature set 156 - Supply examples 158 - Supply new feature registrations 160 2. Fax feature schema syntax 162 The syntax for the fax feature schema is described by "A syntax for 163 describing media feature sets" [2]. This in turn calls upon media 164 feature tags that may be registered according to the procedure 165 described in "Media Feature Tag Registration Procedure" [1]. 167 NOTE: Media feature registration provides a base 168 vocabulary of features that correspond to media handling 169 capabilities. The feature set syntax provides a 170 mechanism and format for combining these to describe 171 combinations of features that may be handled by eifax 172 systems. 174 3. Internet fax feature tags 176 This section enumerates and briefly describes a number of feature 177 tags that are defined for use with Extended Internet Fax (eifax) 178 systems and applications. These tags may be used also by other 179 systems and applications that support corresponding capabilities. 181 The feature tags presented below are those that an eifax system is 182 expected to recognize its ability or non-ability to handle. 184 Definitive descriptions of feature tags are indicated by reference 185 to their registration per the 'conneg' registration procedure [1] 186 (some of which are appended to this document) 188 NOTE: The presence of a feature tag in this list does 189 not mean that an eifax system must have that capability; 190 rather, it must recognize the feature tag and deal with 191 it according to the capabilities that it does have. 193 Further, an eifax system is not prevented from 194 recognizing and offering additional feature tags. The 195 list below is intended to provide a minimum vocabulary 196 that all eifax systems can use in a consistent fashion. 198 If an unrecognized or unused feature tag is received, the 199 feature set matching rule (described in [2]) operates so 200 that tag is effectively ignored. 202 RFC nnnn Content feature schema for Internet fax October 1998 204 3.1 Image Size 206 Feature tag name Legal values 207 ---------------- ------------ 208 pix-x (>0) 209 pix-y (>0) 211 Reference: "Media Features for Display, Print, and Fax" [3]. 213 [[[GK: The use of pixels as a measure of fax image size is 214 currently under discussion: should we use pixels or some physical 215 unit of measure? In my opinion, we should use physical dimensions 216 rather than pixels, because when a device (like a fax) offers a 217 range of resolutions, these are not generally reflected in the 218 physical image size, though they would affect the pixel size. 219 Thus, using physical dimensions, it is not necessary to specify a 220 different image size with each resolution option.]]] 222 3.2 Resolution 224 Feature tag name Legal values 225 ---------------- ------------ 226 dpi (>0) 227 dpi-xyratio (>0) 229 Reference: "Media Features for Display, Print, and Fax" [3], and 230 this document appendix A. 232 If 'dpi-xyratio' is present and not equal to 1 then the horizontal 233 resolution (x-axis) is indicated by the 'dpi' feature value, and 234 the vertical resolution (y-axis) is the value of 'dpi' divided by 235 'dpi-xyratio'. 237 For example, the basic Group 3 fax resolution of 200*100dpi might 238 be indicated as: 240 (& (dpi=200) (dpi-xyratio=200/100) ) 242 [[[Handling of differential x- and y- resolutions is currently 243 under discussion.]]] 245 RFC nnnn Content feature schema for Internet fax October 1998 247 3.3 Media type 249 Feature tag name Legal values 250 ---------------- ------------ 251 ua-media screen 252 screen-paged 253 stationery 254 transparency 255 envelope 256 envelope-plain 257 continuous 259 Reference: "Media Features for Display, Print, and Fax" [3]. 261 NOTE: Where the recipient indicates specific support for 262 hard copy or soft copy media type, a sender of colour 263 image data may wish to adjust the colour components (e.g. 264 per the related rules of ITU recommendation T.42 [9]) to 265 improve rendered image quality on that medium. 267 3.4 Paper Size 269 Feature tag name Legal values 270 ---------------- ------------ 271 paper-size A4 272 A3 273 B4 274 letter 275 legal 277 Reference: "Media Features for Display, Print, and Fax" [3]. 279 3.5 Colour and greyscale 281 Feature tag name Legal values 282 ---------------- ------------ 283 grey 284 (Typically 2,16,256,65536,16777216) 285 color 286 (Typically 16,256,65536,16777216) 288 Reference: "Media Features for Display, Print, and Fax" [3]. 290 NOTE: a bi-level (i.e. black-and-white only) fax image or 291 capability is indicated by the feature value 'grey=2'. 292 This is indicates the rendering capabilities of a 293 recipient or requirements of a document, and does not of 294 itself indicate a coding scheme. 296 RFC nnnn Content feature schema for Internet fax October 1998 298 3.6 Coding 300 Feature tag name Legal values 301 ---------------- ------------ 302 image-coding MH 303 MR 304 MMR 305 JBIG-2-Level (bi-level) 306 JBIG-M-Level (multi-level) 307 JPEG 308 MRC 309 strip-size 310 image-interleave Strip 311 Plane 312 color-subsampling 313 MRC-level [1-7] 315 The 'strip-size' feature may be used with JBIG and MRC coding, and 316 indicates the maximum number of scan lines in an image strip. For 317 JBIG receivers the legal constraints are: 319 (strip-size=128) 320 (strip-size>=0) 322 The later being equivalent to no restriction. For MRC coded image 323 receivers, the legal constraints are: 325 (strip-size=[0..256]) 326 (strip-size>=0) 328 For a receiver that can handle both JBIG and MRC images, the strip- 329 size constraints may need to be related to the image coding, as in 330 this example: 332 (| (& (image-coding=JBIG-2-LEVEL) (strip-size=128) ) 333 (& (image-coding=JBIG-M-LEVEL) (strip-size=128) ) 334 (& (image-coding=MRC) (strip-size=[0..256]) ) 336 Where it may vary, the actual maximum strip size for a given file 337 is indicated in the image data. 339 The 'MRC-level' feature is used only if the 'image-coding' feature 340 includes MRC. 342 Reference: this document, appendix A. 344 [[[GK: color subsampling is proposed to be changed to a token, thus 345 allowing subsampling capabilities other than 4:1:1.]]] 347 RFC nnnn Content feature schema for Internet fax October 1998 349 3.7 Colour model 351 Feature tag name Legal values 352 ---------------- ------------ 353 color-space CIELAB (per T.42 [9]) 354 Palette (per T.43 [10]) 355 custom-illuminant 356 custom-gamut 358 Reference: this document, appendix A. 360 3.8 Preferred units 362 Feature tag name Legal values 363 ---------------- ------------ 364 preferred-unit metric 365 inch 367 NOTE: this feature is really provided for interactions 368 that involve legacy fax machines. TIFF images used for 369 Internet fax (per RFC 2301 [7]) always contain inch-based 370 measurements. 372 The value of this feature does not affect in any way the 373 units used for expressing other feature values; e.g. 374 resolution is always measured in dots per inch. 376 Reference: this document, appendix A. 378 4. Examples 380 Some of the examples contain comments introduced by '--...'. These 381 are not part of the allowed capability description syntax. They 382 are included here to explain some of the constructs used. 384 <<> 386 4.1 Simple mode Internet fax system 388 This example describes the capabilities of a typical simple mode 389 Internet fax system. Note that TIFF application S is required to 390 be supported by such a system. 392 (& ( dpi=200 ) 393 ( dpi-xyratio=[200/100,200/200] ) 394 ( grey=2 ) 395 ( paper-size=A4 ) 396 ( image-coding=MH ) 397 ( ua-media=stationery ) ) 399 RFC nnnn Content feature schema for Internet fax October 1998 401 4.2 High-end black-and-white Internet fax system 403 This would include support for B/W JBIG and be equivalent to what 404 is sometimes called "Super G3", except that Internet fax 405 functionality would be added. 407 (& (| (& (dpi=200) (dpi-xyratio=200/100) ) -- 200*100 408 (& (dpi=200) (dpi-xyratio=1) ) -- 200*200 409 (& (dpi=300) (dpi-xyratio=1) ) -- 300*300 410 (& (dpi=400) (dpi-xyratio=1) ) ) -- 400*400 411 ( grey=2 ) 412 ( paper-size=[A4,B4] ) 413 ( image-coding=[MH,MR,MMR,JBIG-2-LEVEL] ) ) 415 4.3 Grey-scale Internet fax system 417 This is the previous example extended to handle grey scale multi- 418 level images. In keeping with Group 3 fax, this capability 419 requires equal x- and y- resolutions for a multi-level image. 421 (& (| (& (dpi=200) (dpi-xyratio=200/100) (grey=2) ) 422 (& (dpi=200) (dpi-xyratio=1) ) 423 (& (dpi=300) (dpi-xyratio=1) ) 424 (& (dpi=400) (dpi-xyratio=1) ) ) 425 ( grey<=256 ) 426 ( paper-size=[A4,B4] ) 427 ( image-coding=[MH,MR,MMR,JBIG-2-LEVEL,JPEG,JBIG-M-LEVEL] ) ) 429 4.4 Full-colour Internet fax system (JPEG) 431 <<>> 433 4.5 Full-colour Internet fax system (MRC) 435 <<>> 437 4.6 Sender and receiver feature matching 439 This example considers sending a document to a high-end black-and- 440 white fax system with the following capabilities: 442 (& (| (& (dpi=200) (dpi-xyratio=200/100) ) -- 200*100 443 (& (dpi=200) (dpi-xyratio=1) ) -- 200*200 444 (& (dpi=300) (dpi-xyratio=1) ) -- 300*300 445 (& (dpi=400) (dpi-xyratio=1) ) ) -- 400*400 446 ( grey=2 ) (color=0) 447 (| (& (paper-size=A4) (ua-media=[stationery,transparency]) ) 448 (& (paper-size=B4) (ua-media=continuous) ) ) 449 ( image-coding=[MH,MR,JBIG-2-LEVEL] ) ) 451 RFC nnnn Content feature schema for Internet fax October 1998 453 Turning to the document itself, assume it is available to the 454 sender in three possible formats, A4 high resolution, B4 low 455 resolution and A4 high resolution colour, described by: 457 (& ( dpi=300 ) ( dpi-xyratio=1 ) 458 ( grey=2 ) 459 ( paper-size=A4 ) 460 ( image-coding=[MMR,JBIG-2-LEVEL] ) ) 462 (& ( dpi=200 ) (dpi-xyratio=200/100) 463 ( grey=2 ) 464 ( paper-size=B4 ) 465 ( image-coding=[MH,MR] ) ) 467 (& ( dpi=300 ) ( dpi-xyratio=1 ) 468 ( color<=256 ) 469 ( paper-size=A4 ) 470 ( image-coding=JPEG ) ) 472 These three image formats can be combined into a composite 473 capability statement by a logical-OR operation (to describe format- 474 1 OR format-2 OR format-3): 476 (| (& ( dpi=300 ) ( dpi-xyratio=1 ) 477 ( grey=2 ) 478 ( paper-size=A4 ) 479 ( image-coding=[MMR,JBIG-2-LEVEL] ) ) 480 (& ( dpi=200 ) (dpi-xyratio=200/100) 481 ( grey=2 ) 482 ( paper-size=B4 ) 483 ( image-coding=[MH,MR] ) ) 484 (& ( dpi=300 ) ( dpi-xyratio=1 ) 485 ( color=42 ) 486 ( paper-size=A4 ) 487 ( image-coding=JPEG ) ) ) 489 This could be simplified, but there is little gain in doing so at 490 this point. 492 RFC nnnn Content feature schema for Internet fax October 1998 494 The composite document description can be matched with the receiver 495 capability description, according to the rules in [2], to yield the 496 result: 498 (| (& ( dpi=300 ) ( dpi-xyratio=1 ) 499 ( grey=2 ) 500 ( paper-size=A4 ) 501 ( ua-media=[stationery,transparency] ) 502 ( image-coding=JBIG-2-LEVEL ) ) 503 (& ( dpi=200 ) (dpi-xyratio=200/100) 504 ( grey=2 ) 505 ( paper-size=B4 ) 506 ( ua-media=continuous ) 507 ( image-coding=[MH,MR] ) ) ) 509 Points to note about the feature matching process: 511 o The colour document option is eliminated because the receiver 512 cannot handle either colour (indicated by '(color=0)') or JPEG 513 coding. 515 o The high resolution version of the document with '(dpi=300)' must 516 be send using '(image-coding=JBIG-2-LEVEL)' because this is the 517 only available coding of the image data that the receiver can use 518 for high resolution documents. 520 o The low-resolution version of the document can be sent with 521 either MH or MR coding as the receiver can deal with either of 522 these for low resolution documents. 524 o The high resolution variant of the document is available only for 525 A4, so that is the paper-size used in that case. Similarly the 526 low resolution version is sent for B4 paper. 528 o Even though the sender may not understand the 'ua-media' feature 529 tag, and does not mention it, the matching rules preserve the 530 constraint that the B4 document is rendered with 531 '(ua-media=continuous)', and the A4 document may be rendered with 532 '(ua-media=[stationery,transparency])'. 534 RFC nnnn Content feature schema for Internet fax October 1998 536 5. Security considerations 538 The points raised below are in addition to the general security 539 considerations for extended Internet fax [5], and others discussed 540 in [2,8,11,12,13] 542 5.1 Threats 544 Negotiation mechanisms reveal information about one party to other 545 parties. This may raise privacy concerns, and may allow a 546 malicious party to make better guesses about the presence of 547 specific security holes. 549 Most of these considerations pertain to capabilities information 550 getting into the hands of someone who wanted to abuse it. This 551 document specifies a list of capabilities which will help a sender 552 determine what image files characteristics can be processed by the 553 recipient, not mechanisms for their publication. Implementors and 554 users should try to ensure that these capabilities are provided to 555 appropriate persons, systems and agents. 557 1. Unsolicited bulk mail: if it is known that a recipient can 558 process certain types of images, they may be targeted by bulk 559 mailers that want to send such images. 561 <<>> 563 6. Full copyright statement 565 Copyright (C) The Internet Society 1998. All Rights Reserved. 567 This document and translations of it may be copied and furnished to 568 others, and derivative works that comment on or otherwise explain 569 it or assist in its implementation may be prepared, copied, 570 published and distributed, in whole or in part, without restriction 571 of any kind, provided that the above copyright notice and this 572 paragraph are included on all such copies and derivative works. 573 However, this document itself may not be modified in any way, such 574 as by removing the copyright notice or references to the Internet 575 Society or other Internet organizations, except as needed for the 576 purpose of developing Internet standards in which case the 577 procedures for copyrights defined in the Internet Standards process 578 must be followed, or as required to translate it into languages 579 other than English. 581 The limited permissions granted above are perpetual and will not be 582 revoked by the Internet Society or its successors or assigns. 584 RFC nnnn Content feature schema for Internet fax October 1998 586 This document and the information contained herein is provided on 587 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 589 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 590 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 7. Acknowledgements 595 The authors gratefully acknowledge the following persons who made 596 comments on earlier versions of this memo: James Rafferty, Dan 597 Wing, [[...]]. 599 8. References 601 [1] "Media Feature Tag Registration Procedure" 602 Koen Holtman, TUE 603 Andrew Mutz, Hewlett-Packard 604 Ted Hardie, NASA 605 Internet draft: 606 Work in progress, July 1998. 608 [2] "A syntax for describing media feature sets" 609 Graham Klyne, 5GM/Content Technologies 610 Internet draft: " 611 Work in progress, September 1998. 613 [3] "Media Features for Display, Print, and Fax" 614 Larry Masinter, Xerox PARC 615 Koen Holtman, TUE 616 Andrew Mutz, Hewlett-Packard 617 Dan Wing, Cisco Systems 618 Internet draft: 619 Work in progress, September 1998. 621 [4] "Internet fax feature mapping from Group 3 fax" 622 Lloyd McIntyre, Xerox Corporation 623 Graham Klyne, 5GM/Content Technologies 624 Internet draft: 625 Work in progress, August 1998. 627 [5] "Extended Facsimile Using Internet Mail 628 Larry Masinter, Xerox Corporation 629 Dan Wing, Cisco Systems 630 Internet draft: 631 Work in progress, September 1998. 633 RFC nnnn Content feature schema for Internet fax October 1998 635 [6] "Procedures for document facsimile transmission in the general 636 switched telephone network" 637 ITU-T Recommendation T.30 638 International Telecommunications Union 639 July 1996 641 [7] RFC 2301, "File format for Internet fax" 642 L. McIntyre, 643 R. Buckley, 644 D. Venable, Xerox Corporation 645 S. Zilles, Adobe Systems, Inc. 646 G. Parsons, Northern Telecom 647 J. Rafferty, Human Communications 648 March 1998. 650 [8] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail" 651 K. Toyoda 652 H. Ohno 653 J. Murai, WIDE Project 654 D. Wing, Cisco Systems 655 March 1998. 657 [9] T.42 (custom illuminant, gamut) 659 [10] T.43 (JBIG for colour/grey) 661 [11] "Scenarios for the Delivery of Negotiated Content" 662 T. Hardie, NASA Network Information Center 663 Internet draft: 664 Work in progress, November 1997. 666 [12] "Requirements for protocol-independent content negotiation" 667 G. Klyne, Integralis Ltd. 668 Internet draft: 669 Work in progress, March 1998. 671 RFC nnnn Content feature schema for Internet fax October 1998 673 9. Authors' addresses 675 Graham Klyne 676 5th Generation Messaging Ltd. Content Technologies Ltd. 677 5 Watlington Street Forum 1, Station Road 678 Nettlebed Theale 679 Henley-on-Thames, RG9 5AB Reading, RG7 4RA 680 United Kingdom United Kingdom. 681 Telephone: +44 1491 641 641 +44 118 930 1300 682 Facsimile: +44 1491 641 611 +44 118 930 1301 683 E-mail: GK@ACM.ORG 685 Lloyd McIntyre 686 Xerox Corporation 687 Mailstop PAHV-305 688 3400 Hillview Ave. 689 Palo Alto, CA 94304 USA 690 Telephone: +1-650-813-6762 691 Facsimile: +1-650-845-2340 692 E-mail: Lloyd.McIntyre@pahv.xerox.com 694 Appendix A: Feature registrations 696 [[[This appendix contains registrations of media features, that are 697 specific to fax and for which no applicable registration already 698 exists.]]]