From owner-ietf-fax@mail.imc.org Thu Jun 1 07:55:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20831 for ; Thu, 1 Jun 2000 07:55:55 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA17705 for ietf-fax-bks; Thu, 1 Jun 2000 03:00:38 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17699 for ; Thu, 1 Jun 2000 03:00:33 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA26632; Thu, 1 Jun 2000 19:04:44 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA03256; Thu, 1 Jun 2000 19:04:38 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA07306; Thu, 1 Jun 2000 19:04:19 +0900 (JST) To: paf@swip.net, ned.freed@innosoft.com, ietf-secretariat@ietf.org Cc: Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: [IETF-FAX] Request for IESG Consideration for TIFF draft X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Jun_01_19:10:05_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000601191041J.tamura@toda.ricoh.co.jp> Date: Thu, 01 Jun 2000 19:10:41 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 1065 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Thu_Jun_01_19:10:05_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Patrik, Dear Ned, Dear IETF secretary, I am Hiroshi Tamura, a co-chair of Fax WG. The Internet Fax Working Group requests IESG approval for publication of the following two documents, with the specified status. ..... DOCUMENT 1: File Format for Internet Fax draft-ietf-fax-tiff-fx-06.txt Status: Draft Standard Technical Summary: This document is a revised version of Proposed Standard RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since the Proposed Standard was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. The earlier versions of this draft have completed an Internet Fax working group Last Call. There are clarifications for implementers and change on reference information of TIFF-REG and auther information. There are no technical change. Enough interworking is already done. There are no specific normative reference dependencies that need to be resloved. TIFF-REG(RFC 2302) will be replaced by a reference to the following document(DOCUMENT 2) which is being proposed as a BCP. Attached is the interworking report by a editor. DOCUMENT 2: Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration draft-ietf-fax-tiff-regbis-01.txt Status: BCP Technical Summary: This document is a revised version of Proposed Standard RFC 2302. There are no techical change. There are only changes on auther information. This document describes only the registration of the MIME sub-type image/tiff. Therefore, the working group agrees the status should be changed to BCP. ..... Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp ----Next_Part(Thu_Jun_01_19:10:05_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="tiff-fx-impl-report.txt" Content-Transfer-Encoding: 7bit TIFF-FX IMPLEMENTATION REPORT This report describes the implementation and interoperability testing of TIFF-FX, specified in RFC 2301, the Proposed Standard File Format for Internet Fax . The following independently implemented and jointly tested the TIFF-FX profiles listed, and furnished the data for this report: Japan Color Document Committee - All profiles Matsushita Graphic Communication Systems Toshiba TEC Sharp NTT Printec Mitsubishi Fuji Xerox Waseda University Genoa Technology - All profiles Xerox - All profiles Intel - All profiles, except L Image Power - All profiles, except L and M This report is organized in 2 sections. Section 1 describes the results of TIFF-FX interoperability testing. Section 2 describes the independent TIFF-FX implementations, by implementor. Each description includes a series of tables. The first is a general table that lists the TIFF-FX fields, field values and features used by multiple profiles. Following it are tables, one for each implemented profile, that list the TIFF-FX fields and features that either can have multiple values or are optional in that profile. This report was compiled by Rob Buckley . ----------------------------------------------------------------------- SECTION 1: TIFF-FX INTEROPERABILITY TESTING ----------------------------------------------------------------------- To facilitate interoperability testing, a standard set of test cases was specified that exercised all "features and options" of TIFF-FX, per RFC 2026. The test methodology was: generate TIFF-FX files corresponding to these test cases by converting uncompressed TIFF 6.0 source images to TIFF-FX file, exchange the resulting files by e-mail, then read the TIFF- FX files and convert them to uncompressed TIFF 6.0 images for visual checking and comparison with the original source images. For Profile M, both merged and layer source images were available. A subset of the TIFF-FX test files used for interoperability testing will be available soon at . In addition, Genoa Technology made available a pre-release version of its TIFF Test System for interoperability testing. The TIFF Test System includes a listing utility, image viewer and file validator. Intel, Genoa Technology and Xerox demonstrated interoperability for TIFF-FX Profiles J, C and M at the IMC Fax Connect 1 Workshop, December 1-2, 1998 in San Jose, CA. They and other workshop participants also demonstrated interoperability for Profiles S and F. For the final report on the workshop, see . The interoperability results are based on testing between at least 2 independent implementations. Fields and features listed as implemented by the Reader were verified with TIFF-FX files created by an independent writer. Fields and features implemented in the Writer were verified by an independent reader, using visual checks (view and print) and, in the case of lossless compression, by pixel comparisons of the original and decompressed source images. General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II, MM | II, MM | | DateTime* | Y | Y | | FillOrder | 1, 2 | 1, 2 | | ImageDescription* | Y | Y | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2, 16, 18 | 2, 16, 18 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | Y | Y | | XResolution | 80, 160 | 80, 160 | | YResolution | 77, 154 | 77, 154 | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation* | Y | Y | | Software* | Y | Y | | DocumentName* | Y | Y | | PageNumber | Y | Y | | GlobalParametersIFD* | Y | Y | | CodingMethod* | Y | Y | | FaxProfile* | Y | Y | | ProfileType* | Y | Y | | VersionYear* | Y | Y | +--------------------------+--------------------+--------------------+ Y=Yes, N=No, *=optional field; All profiles use ImageLength, RowsPerStrip, StripByteCounts, StripOffsets Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ For all Profile S: ResolutionUnit=2, BitsPerSample=1, Compression=3 SamplesPerPixel=1, FillOrder=2, Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single, multiple | single, multiple | | BadFaxLines | Y | Y | | CleanFaxLines | Y | Y | | ConsecutiveFaxLines | Y | Y | +--------------------------+--------------------+--------------------+ For all Profile F: BitsPerSample=1, SamplesPerPixel=1 Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | +--------------------------+--------------------+--------------------+ For all Profile J: BitsPerSample=1, SamplesPerPixel=1, Compression=9 Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | Y | Y | +--------------------------+--------------------+--------------------+ For all Profile C: ResolutionUnit=2, PhotometricInterpretation=10, Compression=7, ChromaPositioning=1 Profile L +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | 1-bit RGB | Y | Y | | 1-bit CMY | Y | Y | | 1-bit CMYK | Y | Y | | ITULAB | Y | Y | | BitsPerSample | 4, 8 | 4, 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | Decode | Y | Y | | Indexed (Palette) | Y | Y | | BitsPerSample | 8 | 8 | +--------------------------+--------------------+--------------------+ For all Profile L: ResolutionUnit=2, Compression=10 1-bit RGB: BitsPerSample=1, SamplesPerPixel=3, PhotometricInt=2 1-bit CMY: BitsPerSample=1, SamplesPerPixel=3, PhotometricInt=5 1-bit CMYK: BitsPerSample=1, SamplesPerPixel=4, PhotometricInt=5 ITULAB: PhotometricInterpretation=10 Indexed: Indexed=1, SamplesPerPixel=1, PhotometricInt=10 Profile M +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Number of layers | 1, 2, 3 | 1, 2, 3 | | Mixed Resolutions | Y | Y | | ImageLayer | Y | Y | | ModeNumber* | Y | Y | | Foreground/Background | Y | Y | | Compression | 7, 10 | 7, 10 | | Mixed color spaces | Y | Y | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | Decode | Y | Y | | XPosition, YPosition | Y | Y | | DefaultImageColor | Y | Y | | As Primary IFD | Y | Y | | Mask | Y | Y | | Compression | 3, 4, 9 | 3, 4, 9 | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | T4Options | Y | Y | | T6Options | Y | Y | | StripRowCounts | Y | Y | +--------------------------+--------------------+--------------------+ For all Profile M: ResolutionUnit=2, Mask:PhotometricInterpretation=0 Mask uses SubIFDs field to point to Foreground/Background Mixed Resolutions means Mask & Foreground/Background have different resolutons, Mixed Color Spaces means Foreground and Background have different PhotometricInterpretation values. ----------------------------------------------------------------------- SECTION 2: TIFF-FX IMPLEMENTATIONS ----------------------------------------------------------------------- Japan Color Document Committee Japan Color Document Committee Implementor No. 1 Name of implementation: MGCS TIFF-FX reader/writer Organization: Matsushita Graphic Communication Systems Inc. Platform: Windows 95/98/NT Origin of code: All original source code Location of code: proprietary to MGCS Inc. Contact: Yoshinori Aoki Sub-implementor: Sharp (operation only) Platform: Windows 95 Contact: Hideaki Yamada Sub-implementor: Toshiba TEC Corp. (operation only) Platform: Windows 95 Contact: Ryuji Iwazaki Profiles implemented: S, F, J Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II | II, MM | | DateTime | N | - | | FillOrder | 1, 2 | 1, 2 | | ImageDescription | N | - | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2 | 2 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | N | - | | XResolution | - | - | | YResolution | - | - | | Resolution: color | - | - | | Orientation | N | - | | Software | N | - | | DocumentName | N | - | | PageNumber | Y | Y | | GlobalParametersIFD | N | - | | CodingMethod | N | - | | FaxProfile | N | - | | ProfileType | N | - | | VersionYear | N | - | +--------------------------+--------------------+--------------------+ Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0 | 0 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single | single, multiple | | BadFaxLines | N | - | | CleanFaxLines | N | - | | ConsecutiveFaxLines | N | - | +--------------------------+--------------------+--------------------+ Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 0 | 0 | | ResolutionUnit | 2 | 2 | +--------------------------+--------------------+--------------------+ Japan Color Document Committee, Implementor No. 2 Name of implementation: Toshiba TEC TIFF-FX reader/writer Organization: Toshiba TEC Corp. Platform: Windows 95 Origin of code: Internal interface architecture with Independent JPEG Group public source code and image processing algorithms implemented from scratch Location of code: proprietary to Toshiba TEC Contact: Ryuji Iwazaki Profiles implemented: C Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II | II | | DateTime | N | - | | FillOrder | 1, 2 | 1, 2 | | ImageDescription | N | - | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2 | 2 | | Multi-page file | Y | Y | | Resolution: b&w | - | - | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation | Y | Y | | Software | N | - | | DocumentName | N | - | | PageNumber | Y | Y | | GlobalParametersIFD | Y | Y | | CodingMethod | Y | Y | | FaxProfile | Y | Y | | ProfileType | Y | Y | | VersionYear | Y | Y | +--------------------------+--------------------+--------------------+ Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | Y | Y | +--------------------------+--------------------+--------------------+ Japan Color Document Committee, Implementor No. 3 Name of implementation: NTT Printec TIFF-FX Profile L reader/writer Organization: NTT Printec Corp. Platform: Unix - Sun Solaris 2.4 Origin of code: JBIG codec (s1r4) for color facsimile test from AT&T Location of code: proprietary to NTT Printec Corp. Contact: Makoto Matsuki Sub-implementor: Mitsubishi (operation only) Platform: Unix - Sun OS 4.1.4 Contact: Fumitaka Ono Profiles implemented: L Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II | II, MM | | DateTime | Y | Y | | FillOrder | 1 | 1 | | ImageDescription | Y | Y | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2 | 2 | | Multi-page file | Y | Y | | Resolution: b&w | - | - | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation | N | N | | Software | Y | Y | | DocumentName | Y | Y | | PageNumber | Y | Y | | GlobalParametersIFD | Y | Y | | CodingMethod | Y | Y | | FaxProfile | Y | Y | | ProfileType | Y | Y | | VersionYear | Y | Y | +--------------------------+--------------------+--------------------+ Profile L +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | 1-bit RGB | Y | Y | | 1-bit CMY | Y | Y | | 1-bit CMYK | Y | Y | | ITULAB | Y | Y | | BitsPerSample | 2-8 | 2-8 | | SamplesPerPixel | 1, 3 | 1, 3 | | Decode | Y | Y | | Indexed (Palette) | Y | Y | | BitsPerSample | 2-12 | 2-12 | +--------------------------+--------------------+--------------------+ Japan Color Document Committee, Implementor No. 4 Name of implementation: Fuji_Xerox TIFF-FX reader/writer Organization: Fuji Xerox Co. Ltd. Platform: Unix - Sun Solaris 2.5.1 Origin of code: Internal interface architecture with Independent JPEG Group public source code, libtiff src code for general I/O formatting, Markus Kuhn free JBIG library, and image processing algorithms implemented from publication Location of code: proprietary to Fuji Xerox Contact: Hiroaki Ikegami Sub-implementor: Waseda University (M operation only) Platform: Unix - Sun Solaris 2.6 Contact: Hiroyuki Kasai Profiles implemented: All - S, F, J, C, L, M Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II, MM | II, MM | | DateTime | Y | Y | | FillOrder | 1, 2 | 1, 2 | | ImageDescription | Y | Y | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2, 16, 18 | 2, 16, 18 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | Y | Y | | XResolution | 80, 160 | 80, 160 | | YResolution | 77, 154 | 77, 154 | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation | Y | Y | | Software | Y | Y | | DocumentName | Y | Y | | PageNumber | Y | Y | | GlobalParametersIFD | Y | Y | | CodingMethod | Y | Y | | FaxProfile | Y | Y | | ProfileType | Y | Y | | VersionYear | Y | Y | +--------------------------+--------------------+--------------------+ Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single, multiple | single, multiple | | BadFaxLines | Y | Y | | CleanFaxLines | Y | Y | | ConsecutiveFaxLines | Y | Y | +--------------------------+--------------------+--------------------+ Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | +--------------------------+--------------------+--------------------+ Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | Y | Y | +--------------------------+--------------------+--------------------+ Profile L +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | 1-bit RGB | Y | Y | | 1-bit CMY | Y | Y | | 1-bit CMYK | Y | Y | | ITULAB | Y | Y | | BitsPerSample | 2-8, 12 | 2-8, 12 | | SamplesPerPixel | 1, 3 | 1, 3 | | Decode | Y | Y | | Indexed (Palette) | Y | Y | | BitsPerSample | 2-8, 12 | 2-8, 12 | +--------------------------+--------------------+--------------------+ Profile M +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Number of layers | 1, 2, 3 | 1, 2, 3 | | Mixed Resolutions | Y | Y | | ImageLayer | Y | Y | | ModeNumber | Y | Y | | Foreground/Background | Y | Y | | Compression | 7, 10 | 7, 10 | | PhotometricInterpret. | 2, 10 | 2, 10 | | Mixed color spaces | Y | Y | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | Decode | Y | Y | | XPosition, YPosition | Y | Y | | DefaultImageColor | Y | Y | | As Primary IFD | Y | Y | | Mask | Y | Y | | Compression | 3, 4, 9 | 3, 4, 9 | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | T4Options | Y | Y | | T6Options | Y | Y | | StripRowCounts | Y | Y | +--------------------------+--------------------+--------------------+ ------------------------------------------------------------------------ Genoa Technology Name of implementation: TIFF Test System Organization: Genoa Technology Platform: Windows 95/98/NT4.0 Origin of code: Internal interface architecture with Independent JPEG Group public source code, personalized src code for general I/O formatting, Markus Kuhn free JBIG library, and image processing algorithms implemented with LeadTools 6.0 Location of code: proprietary to Genoa Technology Contact: Teodor Ceausu Profiles implemented: All - S, F, J, C, L, M Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II, MM | II, MM | | DateTime | Y | Y | | FillOrder | 1, 2 | 1, 2 | | ImageDescription | Y | Y | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2, 16, 18 | 2, 16, 18 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | Y | Y | | XResolution | 80, 160 | 80, 160 | | YResolution | 77, 154 | 77, 154 | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation | Y | Y | | Software | Y | Y | | DocumentName | Y | Y | | PageNumber | Y | Y | | GlobalParametersIFD | Y | Y | | CodingMethod | Y | Y | | FaxProfile | Y | Y | | ProfileType | Y | Y | | VersionYear | Y | Y | +--------------------------+--------------------+--------------------+ Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single, multiple | single, multiple | | BadFaxLines | Y | Y | | CleanFaxLines | Y | Y | | ConsecutiveFaxLines | Y | Y | +--------------------------+--------------------+--------------------+ Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | +--------------------------+--------------------+--------------------+ Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | Y | Y | +--------------------------+--------------------+--------------------+ Profile L +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | 1-bit RGB | Y | Y | | 1-bit CMY | Y | Y | | 1-bit CMYK | Y | Y | | ITULAB | Y | Y | | BitsPerSample | 4, 8, 12 | 4, 8, 12 | | SamplesPerPixel | 1, 3 | 1, 3 | | Decode | Y | Y | | Indexed (Palette) | Y | Y | | BitsPerSample | 8 | 8 | +--------------------------+--------------------+--------------------+ Profile M +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Number of layers | 1, 2, 3 | 1, 2, 3 | | Mixed Resolutions | Y | Y | | ImageLayer | Y | Y | | ModeNumber | Y | Y | | Foreground/Background | Y | Y | | Compression | 7, 10 | 7, 10 | | PhotometricInterpret. | 2, 5, 10 | 2, 5, 10 | | Mixed color spaces | Y | Y | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | Decode | Y | Y | | XPosition, YPosition | Y | Y | | DefaultImageColor | Y | Y | | As Primary IFD | Y | Y | | Mask | Y | Y | | Compression | 3, 4, 9 | 3, 4, 9 | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | T4Options | Y | Y | | T6Options | Y | Y | | StripRowCounts | Y | Y | +--------------------------+--------------------+--------------------+ ------------------------------------------------------------------------ Xerox Name of implementation: Valen TIFF-X reader/writer Organization: Xerox Corp. Platform: Unix - Sun Solaris 2.6 Origin of code: Internal interface architecture with Independent JPEG Group public source code, libtiff src code for general I/O formatting, Markus Kuhn free JBIG library, and image processing algorithms implemented from publication Location of code: proprietary to Xerox Contact: Rob Buckley Profiles implemented: All - S, F, J, C, L, M Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II, MM | II, MM | | DateTime | N | N | | FillOrder | 1, 2 | 1, 2 | | ImageDescription | Y | Y | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2, 16, 18 | 2, 16, 18 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | Y | Y | | XResolution | 80, 160 | 80, 160 | | YResolution | 77, 154 | 77, 154 | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation | Y | Y | | Software | Y | Y | | DocumentName | Y | Y | | PageNumber | Y | Y | | GlobalParametersIFD | Y | Y | | CodingMethod | Y | Y | | FaxProfile | Y | Y | | ProfileType | Y | Y | | VersionYear | Y | Y | +--------------------------+--------------------+--------------------+ Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single, multiple | single, multiple | | BadFaxLines | Y | Y | | CleanFaxLines | Y | Y | | ConsecutiveFaxLines | Y | Y | +--------------------------+--------------------+--------------------+ Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 0 | 0, 1 | | ResolutionUnit | 2, 3 | 2, 3 | +--------------------------+--------------------+--------------------+ Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | Y | Y | +--------------------------+--------------------+--------------------+ Profile L +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | 1-bit RGB | Y | Y | | 1-bit CMY | Y | Y | | 1-bit CMYK | Y | Y | | ITULAB | Y | Y | | BitsPerSample | 4, 8 | 4, 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | Decode | Y | Y | | Indexed (Palette) | Y | Y | | BitsPerSample | 8 | 8 | +--------------------------+--------------------+--------------------+ Profile M +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Number of layers | 1, 2, 3 | 1, 2, 3 | | Mixed Resolutions | Y | Y | | ImageLayer | Y | Y | | ModeNumber | Y | Y | | Foreground/Background | Y | Y | | Compression | 7, 10 | 7, 10 | | PhotometricInterpret. | 2, 10 | 2, 10 | | Mixed color spaces | Y | Y | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | Decode | Y | Y | | XPosition, YPosition | Y | Y | | DefaultImageColor | Y | Y | | As Primary IFD | Y | Y | | Mask | Y | Y | | Compression | 3, 4, 9 | 3, 4, 9 | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | T4Options | Y | Y | | T6Options | Y | Y | | StripRowCounts | Y | Y | +--------------------------+--------------------+--------------------+ ------------------------------------------------------------------------ Intel Name of implementation: Intel Corporation Tiff-Fx reader-writer Organization: Intel Corporation Platform: Windows 95/98/NT Origin of code: Internal interface architecture with Independent JPEG Group public source code, code for general I/O formatting, Markus Kuhn free JBIG library, and image processing algorithms implemented from publication Location of code: proprietary to Intel Contact: Bradley Benham Profiles implemented: S, F, J, C, M Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II, MM | II, MM | | DateTime | N | N | | FillOrder | 1, 2 | 1, 2 | | ImageDescription | N | N | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2, 16, 18 | 2, 16, 18 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | Y | Y | | XResolution | 80, 160 | 80, 160 | | YResolution | 77, 154 | 77, 154 | | Resolution: color | 100, 200, 300, 400 | 100, 200, 300, 400 | | Orientation | N | N | | Software | N | N | | DocumentName | N | N | | PageNumber | Y | Y | | GlobalParametersIFD | Y | Y | | CodingMethod | Y - fixed value | Y - fixed value | | FaxProfile | Y - fixed value | Y - fixed value | | ProfileType | Y - fixed value | Y - fixed value | | VersionYear | Y - fixed value | Y - fixed value | +--------------------------+--------------------+--------------------+ Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2 | 2 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single, multiple | single, multiple | | BadFaxLines | N | N | | CleanFaxLines | N | N | | ConsecutiveFaxLines | N | N | +--------------------------+--------------------+--------------------+ Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2 | 2 | +--------------------------+--------------------+--------------------+ Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | N | N | +--------------------------+--------------------+--------------------+ Profile M +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Number of layers | 1, 2, 3 | 1, 2, 3 | | Mixed Resolutions | Y | Y | | ImageLayer | Y | Y | | ModeNumber | Y | Y | | Foreground/Background | Y | Y | | Compression | 7 | 7 | | PhotometricInterpret. | 10 | 10 | | Mixed color spaces | N | N | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | Decode | N | N | | XPosition, YPosition | Y | Y | | DefaultImageColor | Y | Y | | As Primary IFD | Y | Y | | Mask | Y | Y | | Compression | 3, 4 | 3, 4 | | XResolution,YResolution| 100, 200, 300, 400 | 100, 200, 300, 400 | | T4Options | Y | Y | | T6Options | Y | Y | | StripRowCounts | Y | Y | +--------------------------+--------------------+--------------------+ ------------------------------------------------------------------------ Image Power Name of implementation: Image Power TIFF-FX reader-writer Organization: Image Power, Inc. Platform: Windows 95/NT Origin of code: Extension to Image Power's Power SDK 1.1 to support TIFF-FX features, using libtiff for basic TIFF support and jbigkit for JBIG support Location of code: proprietary for Power SDK, other components available on the Internet Contact: Stephen Swift Profiles implemented: S, F, J, C Fields/Features tested: General - apply to multiple profiles +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ByteOrder | II | II | | DateTime | N | N | | FillOrder | 2 | 2 | | ImageDescription | N | N | | ImageWidth | A4/Letter, A3, B4 | A4/Letter, A3, B4 | | NewSubFileType | 2 | 2 | | Multi-page file | Y | Y | | Resolution: b&w | | | | ResolutionUnit=2 | Y | Y | | XResolution | 200/204,300,400/408| 200/204,300,400/408| | YResolution | 196/200,300,391/400| 196/200,300,391/400| | ResolutionUnit=3 | N | N | | XResolution | - | - | | YResolution | - | - | | Resolution: color | 100, 200 | 100, 200 | | Orientation | N | N | | Software | N | N | | DocumentName | N | N | | PageNumber | Y | Y | | GlobalParametersIFD | N | N | | CodingMethod | N | N | | FaxProfile | Y | Y | | ProfileType | Y | Y | | VersionYear | N | N | +--------------------------+--------------------+--------------------+ Profile S +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | ResolutionUnit=2 | Y | Y | | XResolution | 200/204 | 200/204 | | YResolution | 98/100, 196/200 | 98/100, 196/200 | | T4Options | 0, 4 | 0, 4 | +--------------------------+--------------------+--------------------+ Profile F +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | Compression | 3, 4 | 3, 4 | | PhotometricInterpretation| 0, 1 | 0, 1 | | ResolutionUnit | 2 | 2 | | T4Options | 0, 1, 4, 5 | 0, 1, 4, 5 | | T6Options | Y | Y | | StripOffsets | single | single, multiple | | BadFaxLines | N | N | | CleanFaxLines | N | N | | ConsecutiveFaxLines | N | N | +--------------------------+--------------------+--------------------+ Profile J +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | PhotometricInterpretation| 1 | 1 | | ResolutionUnit | 2 | 2 | +--------------------------+--------------------+--------------------+ Profile C +--------------------------+--------------------+--------------------+ | Field/Feature | Writer | Reader | +--------------------------+--------------------+--------------------+ | BitsPerSample | 8 | 8 | | SamplesPerPixel | 1, 3 | 1, 3 | | ChromaSubsamping | (1, 1), (2, 2) | (1, 1), (2, 2) | | Decode | N | N | +--------------------------+--------------------+--------------------+ ----Next_Part(Thu_Jun_01_19:10:05_2000_955)---- From owner-ietf-fax@mail.imc.org Thu Jun 1 10:38:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24491 for ; Thu, 1 Jun 2000 10:38:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26592 for ietf-fax-bks; Thu, 1 Jun 2000 06:53:40 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA26588 for ; Thu, 1 Jun 2000 06:53:38 -0700 (PDT) Date: Thu, 1 Jun 2000 15:58:39 +0100 To: agenda@ietf.org cc: Hiroshi Tamura , Patrik Faltstrom , Ned Freed , ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: ietf-fax WG meeting slot request at Pittsburgh Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, This is to request a 2 and 1/2 hour slot for the Pittsburgh meeting for the Internet Fax WG. Anticipated attendance: 60 Other WGs/BOF to avoid: IPPext, VPIM, DRUMS, Rescap, Enum, Megaco, Qualdocs, IMPP A time on Monday-Wednesday (with a strong preference for Monday-Tuesday) in preferred, due to some problems in attending the meeting on Thursday and Friday by some members of the WG. Thank you indeed and regards Claudio Allocchio, ietf-fax WG co-chair From owner-ietf-fax@mail.imc.org Thu Jun 1 22:45:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11095 for ; Thu, 1 Jun 2000 22:45:54 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA23261 for ietf-fax-bks; Thu, 1 Jun 2000 18:49:58 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23252 for ; Thu, 1 Jun 2000 18:49:56 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA27755 for ; Fri, 2 Jun 2000 10:57:48 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA03296 for ; Fri, 2 Jun 2000 10:57:47 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id KAA07360 for ; Fri, 2 Jun 2000 10:57:27 +0900 (JST) To: ietf-fax@imc.org Subject: Re: draft communication letter to ITU-T Q4/SG8 meeting in June In-Reply-To: <20000529194516U.tamura@toda.ricoh.co.jp> References: <20000529194516U.tamura@toda.ricoh.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Jun_02_11:03:49_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000602110352T.tamura@toda.ricoh.co.jp> Date: Fri, 02 Jun 2000 11:03:52 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 245 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Fri_Jun_02_11:03:49_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Colleagues, The final version of a letter to ITU is below. Only the 3rd pargraph in "3 FFPIM" is modified. > In fact, the draft-ietf-fax-ffpim-00.txt refers to > draft-ietf-fax-timely-delivery-00.txt about timeliness and > refers to draft-ietf-fax-content-negotiation-01.txt > about capability negotiation. is replaced with < In fact, the draft-ietf-fax-ffpim-00.txt mentions < timeliness(draft-ietf-fax-timely-delivery-00.txt), < capability negotiation(draft-ietf-fax-content-negotiation-01.txt) < and security consideration. Attached is the modified charter. ---------------------- Begin --------------------------------------------- TITLE: Communication from IETF Fax Working Group on Current Activities Abstract This letter is to notify current activities of IETF Fax Working Group. At Adelaide meeting held in March, Fax WG newly started and re-chartered. 1 Charter New charter was discussed at Adelaide meeting. There are mainly following items that the group agrees to and aims at. a) Full equivalance of T.30 service over Internet mail b) Offramp and Onramp Gateway c) TIFF-FX extensions d) Implementer's Guide for simple mode and extended mode Except for item b), the group has internet-drafts. The group also agrees to continue the cooperation with ITU-T, in order to enhance the service. Please refer to the attached charter. 2 For Draft Standard The group considers the following RFCs, which T.37 refers to, as being Draft Standard. Existing RFCs Internet drafts a)RFC 2301(TIFF-FX) draft-ietf-fax-tiff-fx-06.txt b)RFC 2303(PSTN address format) draft-ietf-fax-minaddr-v2-00.txt c)RFC 2304(Fax address format) draft-ietf-fax-faxaddr-v2-00.txt d)RFC 2305(Simple mode) draft-ietf-fax-service-v2-01.txt After Adelaide meeting, the group is going forward. Concerning a), there is no technical changes from RFC 2301. There are only clarification issues. The group already discussed it. The group thinks the draft can be submitted to IESG for Draft Standard. The co-chair requested IESG for the consideration. IESG is now considering it. Concerning b), c) and d), there are dependancy problems(some references are at proposed standard level) and interworking is not enough. The group is now making effort to solve the matters. There are also no technical changes from existing RFCs. At the same time, the group agrees that draft-ietf-fax-tiff-regbis-01.txt, which will be replaced with RFC 2302(TIFF registration), should be BCP(Best current practice). The co-chair also requested ISEG for the consideration. After approved, these RFCs are replaced with new ones. The group will notify Q4/SG8 of it. 3 FFPIM FFPIM is the acronym of "Full-mode Facsimile Profile of Internet Mail". FFPIM aims at equivalence of T.30 service over Internet mail. There are the following three internet-drafts. a) draft-ietf-fax-ffpim-00.txt b) draft-ietf-fax-timely-delivery-00.txt c) draft-ietf-fax-content-negotiation-01.txt In fact, the draft-ietf-fax-ffpim-00.txt mentions timeliness(draft-ietf-fax-timely-delivery-00.txt), capability negotiation(draft-ietf-fax-content-negotiation-01.txt) and security consideration. With regard to b), the specification defines a set of capabilities which permits an originator to request that the email transport system give a particular timeliness in delivery and then assures if the system will report the success or failure of that request. With regard to c), the specification uses a post-hoc technique that permits an originator to send the best version known by the originator to be supported by the recipient and then sending a better version the recipient requests it. Especially, last year, the group had some requests from Q4 about capability request before sending TIFF-FX file. The draft-ietf-fax-content-negotiation-01.txt realizes it partly, it may meet the requests. They are at rough level and pre-mature. After they are improved very much, the group may think they are sent to ITU-T. 4 Implementer's Guide The draft-ietf-fax-implementers-guide-01.txt is an informational document and clarifies publised RFCs for facsimile communication over Internet mail. This draft is a contribution in this Q4/SG8 meeting as the other document, so the details are not in this letter. Please refer to it. ... Finally, it is noted that the group appreciates your activity and welcomes any comments from you. The group believes the good relationship between them should continue, even after Q4/SG8 is re-organized. ---------------------- End --------------------------------------------- Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp ----Next_Part(Fri_Jun_02_11:03:49_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="charter.txt" Content-Transfer-Encoding: 7bit Internet Fax Extensions (faxext) -------------------------------- Chair(s): Hiroshi Tamura Claudio Allocchio Applications Area Director(s): Patrik Faltstrom Ned Freed Area Advisor Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ DESCRIPTION OF WORKING GROUP: Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will take care of differential routing between classic Internet mail and timely deliveries, and consider with particular regard universal messaging issues and its relation with Internet mail. The WG will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, [image] feature selection/negotiation, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM). For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The working group will also consider the requirements for gatewaying Internet Mail (as profiled for facsimile Simple, Extended modes and FFPIM) with T.30 Facsimile. The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide. T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document integrity, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet. T.30 facsimile provides for receiver capability identification to the sender, allowing a sender to provide the "best" fax image the receiver can handle. The Faxext working group will consider mechanisms to provide similar functionality for fax images transferred by e-mail. Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method. The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, in particular the ITU, VPIM and other WGs, and with using work from related IETF efforts. GOALS AND MILESTONES: Mar 2000 Working Group chartered Mar 2000 Initial drafts for timely delivery , content negotiaton and FFPIM Mar 2000 Initial draft of Implementors Guide for Simple and Extended mode Jun 2000 Revised drafts for timely delivery, content negotiaton and FFPIM Jun 2000 Initial drafts of TIFF-fx extensions Jul 2000 Initial Routing considerations draft Jul 2000 Initial draft of gateway requirements Jul 2000 Final draft of Implementors Guide for Simple and Extended mode Sep 2000 Initial drafts of schema for TIFF-fx extensions Nov 2000 Final draft for timely delivery and content negotiaton. Nov 2000 Final draft of Routing Considerations Nov 2000 Final draft of FFPIM Mar 2001 Final draft of gateway requirements Apr 2001 Final drafts of schema and TIFF-fx extensions for JBIG-2 ----Next_Part(Fri_Jun_02_11:03:49_2000_955)---- From owner-ietf-fax@mail.imc.org Fri Jun 2 05:26:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26748 for ; Fri, 2 Jun 2000 05:26:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA28390 for ietf-fax-bks; Fri, 2 Jun 2000 01:40:05 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA28377 for ; Fri, 2 Jun 2000 01:39:58 -0700 (PDT) Date: Fri, 2 Jun 2000 10:46:35 +0100 To: James Rafferty cc: Hiroshi Tamura , ietf-fax@imc.org, agenda@ietf.org, Patrik Faltstrom , Ned Freed In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F029DD46E@nhmail1.admin.brooktrout.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: RE: ietf-fax WG meeting slot request at Pittsburgh Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > There is a conflict early in that week with Fax Directions 2000, a > conference > which is in San Diego and gets lots of attendance from fax industry people. > > A time on Monday-Wednesday (with a strong preference for > > Monday-Tuesday) > > in preferred, due to some problems in attending the meeting > > on Thursday > > and Friday by some members of the WG. The reason why Tamura-san and myself suggested an "early" meeting is due to the fact that both Tamura-san and myself have problems on Thursday and Friday. at this point we can strongly ask for a Wednesday meeting, or Tuesday afternoon one as an alternate. Are there other WG members which have problems for Wednesday or Tuesday afternoon? Regards, Claudio From owner-ietf-fax@mail.imc.org Tue Jun 6 15:15:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17507 for ; Tue, 6 Jun 2000 15:15:49 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA11485 for ietf-fax-bks; Tue, 6 Jun 2000 11:10:28 -0700 (PDT) Received: from mis2.centigram.com (pix70.centigram.com [198.137.183.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11481 for ; Tue, 6 Jun 2000 11:10:26 -0700 (PDT) From: Eric.Burger@centigram.com Received: from notes.centigram.com (notes.centigram.com [129.1.11.64]) by mis2.centigram.com (8.9.1/8.9.1) with SMTP id LAA10511; Tue, 6 Jun 2000 11:17:46 -0700 (PDT) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882568F6.0064F519 ; Tue, 6 Jun 2000 11:22:43 -0700 X-Lotus-FromDomain: CENTIGRAM To: internet-drafts@ietf.org cc: vpim@lists.neystadt.org, ietf-fax@imc.org Message-ID: <882568F6.0064F2DF.00@notes.centigram.com> Date: Tue, 6 Jun 2000 08:37:39 -0400 Subject: draft-burger-vpim-cc-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Network Working Group E. Burger Internet Draft Centigram Communications Document: draft-burger-vpim-cc-00.txt E. Candell Category: Standards Track Comverse Network Systems Expires in six Months June 6, 2000 Critical Content of Internet Mail Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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." One can access the list of current Internet-Drafts at http://www.ietf.org/ietf/1id-abstracts.txt One can access the list of Internet-Draft Shadow Directories at http://www.ietf.org/shadow.html. 1. Abstract This document describes a mechanism for identifying the critical content body parts of a multi-part Internet mail message. Expires 12/6/00 [Page 1] Critical Content of Internet Mail June 2000 Table of Contents 1.ABSTRACT ...........................................................1 2.CONVENTIONS USED IN THIS DOCUMENT ..................................2 3.INTRODUCTION .......................................................2 4.CONTENT-NOTIFICATION ENTITY ........................................5 4.1. NOTIFY ..........................................................5 4.2. PARTIAL .........................................................5 4.3. IGNORE ..........................................................6 4.4. Other Values ....................................................6 4.5. Notification Precedence .........................................6 5.BACKWARD COMPATIBILITY CONSIDERATIONS ..............................6 6.SECURITY CONSIDERATIONS ............................................7 7.COLLECTED SYNTAX ...................................................7 8.REFERENCES .........................................................7 9.ACKNOWLEDGMENTS ....................................................8 10. AUTHOR'S ADDRESSES ...............................................8 2. Conventions used in this document This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. 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 RFC-2119 [2]. FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. 3. Introduction This document describes the Critical Content identification for multi-part Internet mail. The need for a critical content identification mechanism comes about because of the internetworking of Internet mail systems with legacy messaging systems that do not fulfil all of the semantics of Internet mail. Such legacy systems have a limited ability to render Burger and Candell Expires 12/6/00 [Page 2] Critical Content of Internet Mail June 2000 all parts of a given message. This document will use the case of an Internet mail system exchanging electronic messages with a legacy voice messaging system for illustrative purposes. Electronic mail has historically been text-centric. Extensions such as MIME [3] enable the desktop to send and receive multi-part, multimedia messages. Popular multimedia data types include binary word processing documents, binary business presentation graphics, voice, and video. Voice mail has historically been audio-centric. Many voice messaging systems only render voice. Extensions such as fax enable the voice mail system to send and receive fax images as well as create multi-part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax technology. Although theoretically possible, none can today render video. An important aspect of the interchange between voice messaging services and desktop e-mail client applications is that the rendering capability of the voice messaging platform is often much less than the rendering capability of a desktop e-mail client. In the e-mail case, the sender has the expectation that the recipient receives all components of a multimedia message. This is so even if the recipient cannot render all body parts. In most cases, the recipient can either find the appropriate rendering tool or tell the sender that she cannot read the particular attachment. This is an important issue. By definition, a MIME-enabled user agent, conforming to [4] will present or make available all of the body parts to the recipient. However, a voice mail system may not be capable of storing non-voice objects. Moreover, the voice mail system may not be capable of notifying the recipient that there were undeliverable message parts. The inability of the receiving system to render a body part is usually a permanent failure. Retransmission of the message will not improve the likelihood of a future successful delivery. Contrast this to the case with normal data delivery. Traditional message failures, such as a garbled message or disabled link will benefit from retransmission. This situation is fundamentally different from normal Internet mail. In the Internet mail case, either the system delivered the message, or it didn't. There is no concept of a system partially delivering a message. In addition, the sender would not mind if the system did not deliver non-critical parts of a message. In fact, the sender's user agent may be silently adding body parts to a message unbeknownst to the sender. For example, take Microsoft Outlook as a user agent. Outlook often will attach a TNEF section or other body parts. If the Burger and Candell Expires 12/6/00 [Page 3] Critical Content of Internet Mail June 2000 receiving system rejected the message because it could not render TNEF, the sender would be understandably confused and upset. Thus, there is a need for a method of indicating to a Mail Transfer Agent (MTA) or User Agent (UA) that the sender considers parts of a message to be critical. From the sender's perspective, he would not consider the message delivered if the system did not deliver the critical parts. One method of indicating critical content of a message is to define a profile. The profile defines discard rules based on knowledge of the user population for silently deleting body parts. Citing the example above, a voice profile can easily declare that MTAs or UAs can silently delete TNEF data and yet consider the message successfully delivered. This is, in fact, the approach originally proposed for VPIMv3 [5]. Since one aspect of the issue is deciding when to notify the sender that the system cannot deliver part of a message, one could use a partial non-delivery notification mechanism [6] to indicate a problem with delivering a given body part. However, this requires the user request a MDN. Moreover, the sender will receive PNDN failures for objects the sender may not be aware he is sending. An example would be the TNEF part. Summarizing the needs, we need a mechanism that will let the sender or sender's UA mark body parts he considers critical to the message that the system must deliver. The mechanism MUST NOT burden the sender with failure notifications for non-critical body parts. The mechanism MUST conform to the general notification status request mechanism for positive or negative notification. When requested, the mechanism MUST indicate to the sender when a receiving system cannot deliver a critical body part. In short, we need a method of indicating what sort of delivery notification the sender requires on a per-body part basis. This document describes a Critical Content marking mechanism that satisfies these needs. Following the format for Internet message bodies [3], this document introduces the Content-Notification body part header. Values for this header are NOTIFY, PARTIAL, or IGNORE. The receiving MTA or UA will generate a DSN or PNDN if it receives a request for notification and the (non-)delivery status of the parts marked NOTIFY meet the criteria for notification. Likewise, the receiving UA will generate a MDN or MNDN if it receives a request for notification and the (non-)delivery status of the parts marked NOTIFY meet the criteria for notification. <<>> Burger and Candell Expires 12/6/00 [Page 4] Critical Content of Internet Mail June 2000 4. Content-Notification Entity The Content-Notification field is a MIME body part header inserted by the sending UA to indicate to the receiving MTA or UA whether to consider this body part when generating a (non-)delivery message. If the value of the field is IGNORE, the receiving MTA or UA MUST NOT generate a notification. If the value of the field is NOTIFY, the receiving MTA or UA MUST generate a notification, based on the normal notification request mechanisms. Normal notification request mechanisms include the SMTP RCPT NOTIFY command [7] and the Disposition-Notification-To header [8]. The terms "entity" and "body part" have the meanings defined in [3]. The next sections examine the actions taken by an MTA or UA given the different values of Content-Notification. NOTE: This implies that the MTA must examine the entire message on receipt to determine whether it needs to generate a notification. However, the MTA need not examine the message if it knows it can store and forward all media types. Said differently, an Internet e- mail MTA can, by default, handle any arbitrary MIME-encapsulated type. Some voice mail systems, on the other hand, cannot even store binary attachments, such as application/ms-word. The voice mail MTA, in this example, would be scanning for non-renderable body parts anyway. 4.1. NOTIFY "Content-Notification: NOTIFY" signifies that this body part is critical to the sender. The sender wishes to receive notification reports for this body part. If the receiving system cannot render or store a body part marked NOTIFY, then the entire message has failed. In this case, the receiving system MUST take the appropriate failure action. NOTE: We say "appropriate action", because the sender may have suppressed all notifications. In this case, the appropriate action is to simply discard the message. 4.2. PARTIAL "Content-Notification: PARTIAL" signifies that the sender wishes to receive notification reports for this body part. If the receiving system cannot render or store a body part marked PARTIAL, the receiving system MUST take the appropriate failure action. It is important to note that if the system is successful in delivering other critical body parts, then the message delivery is Burger and Candell Expires 12/6/00 [Page 5] Critical Content of Internet Mail June 2000 successful. In this situation, the receiving system MUST return a partial non-delivery notification [6]. 4.3. IGNORE "Content-Notification: IGNORE" signifies that the sender does not care about notification reports for this body part. If the receiving system cannot render or store a body part marked IGNORE, the receiving system may silently delete the body part. The receiving system MUST NOT return a delivery failure, unless parts marked PARTIAL or NOTIFY have also failed. 4.4. Other Values The receiving system MUST treat unrecognized values as PARTIAL. This is to provide backward compatibility with future uses of the Content-Notification entity. <<>> 4.5. Notification Precedence <<>> 5. Backward Compatibility Considerations If there are no Content-Notification entities in the message, the default value for Content-Notification is NOTIFY. The standard notification mechanisms work for sending user agents (UA) that do Burger and Candell Expires 12/6/00 [Page 6] Critical Content of Internet Mail June 2000 not know about the content notification entity. All body parts are critical, because they have the default marking of NOTIFY. If there is at least one Content-Notification entity in the message, the default value for unspecified body parts is IGNORE. The philosophy is that UAs, especially manually constructed messages, will explicitly mark the critical body parts. NOTE: We could choose the default value for Content-Notification to be IGNORE. This would make VPIMv2 automatically compliant with this document, as VPIMv2 has provision to silently delete undeliverable parts. However, VPIMv2 systems should not be receiving arbitrary e- mail from the Internet. If they do, they should be compliant with this series of documents. By defaulting to NOTIFY, this draft is compliant with the rest of the Internet infrastructure. 6. Security Considerations We anticipate no new security issues beyond those already addressed by the notification RFCs. 7. Collected Syntax The format of the collected syntax is in accordance with the ABNF of [9]. Note that per RFC 2045, none of the strings are case sensitive. "Content-Notification" ":" notification-type CRLF notification-type = "NOTIFY" / "PARTIAL" / "IGNORE" 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft and First Virtual, November 1996. Burger and Candell Expires 12/6/00 [Page 7] Critical Content of Internet Mail June 2000 4 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and First Virtual, November 1996. 5 Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail - version 3", , Work in Progress, expired. 6 Burger, E., "Partial Non-Delivery Notification", Work in Progress, draft-ema-burger-pndn-01.txt, March 2000. 7 Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1981, University of Tennessee, January 1996. 8 Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, National Institutes of Health, March 1998. 9 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 9. Acknowledgments Coming soon! 10. Author's Addresses Eric Burger Centigram Communications Corporation Maryland Technology Center 1375 Piccard Dr., MS 150I Rockville, MD 20850-4311 USA Phone: +1 301/212-3320 Email: e.burger@ieee.org Emily Candell Comverse Network Systems 200 Quannapowitt Pkwy. Wakefield, MA 01880 USA Phone: +1 781/213-2324 Email: emily@comversens.com Burger and Candell Expires 12/6/00 [Page 8] Critical Content of Internet Mail June 2000 Full Copyright Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright (C) 2000 The Internet Society. 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. Burger and Candell Expires 12/6/00 [Page 9] From owner-ietf-fax@mail.imc.org Tue Jun 6 15:16:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17546 for ; Tue, 6 Jun 2000 15:16:56 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA11490 for ietf-fax-bks; Tue, 6 Jun 2000 11:10:37 -0700 (PDT) Received: from mis2.centigram.com (pix70.centigram.com [198.137.183.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11486 for ; Tue, 6 Jun 2000 11:10:36 -0700 (PDT) From: Eric.Burger@centigram.com Received: from notes.centigram.com (notes.centigram.com [129.1.11.64]) by mis2.centigram.com (8.9.1/8.9.1) with SMTP id LAA10508; Tue, 6 Jun 2000 11:17:44 -0700 (PDT) Received: by notes.centigram.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882568F6.0064F5C2 ; Tue, 6 Jun 2000 11:22:45 -0700 X-Lotus-FromDomain: CENTIGRAM To: internet-drafts@ietf.org cc: vpim@lists.neystadt.org, ietf-fax@imc.org Message-ID: <882568F6.0064F440.00@notes.centigram.com> Date: Tue, 6 Jun 2000 08:39:00 -0400 Subject: draft-burger-vpim-pc-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Network Working Group E. Burger Internet Draft Centigram Communications Document: draft-burger-vpim-pc-00.txt E. Candell Category: Standards Track Comverse Network Systems Expires in six Months June 6, 2000 Primary Content of Internet Mail Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document describes a mechanism for identifying the primary content type of a multi-part Internet mail message. Expires 12/6/00 [Page 1] Primary Content of Internet Mail May 2000 Table of Contents 1. ABSTRACT .........................................................1 2. CONVENTIONS USED IN THIS DOCUMENT ................................2 3. INTRODUCTION .....................................................2 4. PRIMARY-CONTENT REFERENCE FIELD ..................................3 4.1. Primary-Content Syntax .........................................4 4.2. content-type Syntax ............................................4 5. SECURITY CONSIDERATIONS ..........................................4 6. IANA CONSIDERATIONS ..............................................4 6.1. Primary-Content Registration ...................................4 6.2. Primary Content Type Registrations .............................5 6.2.1. voice-message ................................................5 6.2.2. fax-message ..................................................6 6.2.3. video-message ................................................7 6.2.4. text-message .................................................7 7. REFERENCES .......................................................8 8. ACKNOWLEDGMENTS ..................................................9 9. AUTHOR'S ADDRESSES ...............................................9 2. Conventions used in this document This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient. 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 RFC-2119 [2]. FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices. 3. Introduction This document describes the Primary Content identification for multi-part Internet mail. Burger and Candell Expires 12/6/00 [Page 2] Primary Content of Internet Mail May 2000 There is a need for a method of indicating to a User Agent (UA) that the sender or sending system designates that a particular message is primarily of some type. For example, some clients put a little fax or telephone icon next to a message header in the client application to indicate of the message is fax mail or voice mail, respectively. In addition, some clients will launch helper applications that are appropriate to a particular type of primary message type. This is a different approach than the usual method of launching a helper application based on one of the (many) media types in the message. One method of indicating the primary media content of a message is to examine the media types in the message. However, this requires the UA to scan the entire message before making this determination. This is particularly burdensome for the multi-media mail situation, as voice and especially video mail objects are quite large. Another method of indicating the primary media content of a message is to register a multipart/* MIME subtype. For example, the VPIM Work Group has registered multipart/voice-message to indicate that a message is primarily voice mail [3]. However, multipart/voice- message is identical in syntax to multipart/mixed. The only difference is that VPIM mail transfer agents and user agents recognize that they can perform special handling of the message based on it being a voice mail message. We wish to avoid scanning the entire message. In addition, we wish to avoid having to create multiple aliases for multipart/mixed every time someone identifies a new primary content type. Since the Primary Content indicator is an attribute of the entire message, it is logical to define a new top-level (RFC 822 [4]) message attribute, Primary-Content. Primary-Content only serves to identify the primary content type of the message. It does not provide any indication of content that the UA must be capable of delivering. It does not imply any message disposition or delivery notification. See the companion document, Critical Content of Internet Mail [5], for a mechanism to perform these tasks. Since Primary-Content is only an indicator, goofy situations, such as a message marked "voice-message" but without a voice body part, MUST NOT generate any error report. 4. Primary-Content Reference Field The Primary-Content reference field is a top-level header inserted by the sending UA to indicate the primary content type of the message. Burger and Candell Expires 12/6/00 [Page 3] Primary Content of Internet Mail May 2000 4.1. Primary-Content Syntax The syntax of the Primary-Content field, formatted according to the ABNF [6] is as follows. Note that "Primary-Content" is not case sensitive, per RFC 822. "Primary-Content" ":" content-type CRLF 4.2. content-type Syntax The content-type indicates the primary media content type of the message. This is an IANA registered value. Current values for Primary-Content are as follows. content-type = 1 *( [ "voice-message"] [ "fax-message" ] [ "video-message" ] [ "text-message" ] ) 5. Security Considerations The intention for this header is to indicate media content type only. One can imagine one creating an "Application" primary content type, and have a poorly designed user agent blindly execute a mailed program. Don't do that! 6. IANA Considerations NOTE: We won't send in any registrations until it looks like this will become a RFC! Following the policies outlined in [7], IANA assigns values for Primary-Content as Specification Required. 6.1. Primary-Content Registration To: ietf-types@iana.org Subject: Registration of New Top-Level Header Field Primary-Content Header name: Primary-Content Required parameters: Single 7bit text value Parameter value: Burger and Candell Expires 12/6/00 [Page 4] Primary Content of Internet Mail May 2000 The parameter value specifies the primary media content type for the message. Security considerations: The intention for this header is to indicate media content type only. One can imagine one creating an "Application" primary content type, and have a poorly designed user agent blindly execute a mailed program. Published specification: draft-burger-vpim-pc-00.txt Applications which use this media type: Mail VPIM FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 6.2. Primary Content Type Registrations 6.2.1. voice-message To: ietf-types@iana.org Subject: Registration of New Primary-Content type voice-message Primary-Content type name: voice-message Required parameters: none Optional parameters: none Encoding considerations: none Security considerations: none Interoperability considerations: User agents declaring the primary content to be voice-message SHOULD conform to VPIMv2. Burger and Candell Expires 12/6/00 [Page 5] Primary Content of Internet Mail May 2000 Published specification: draft-burger-vpim-pc-00.txt RFC 2421, Voice Profile for Internet Mail - version 2 Applications which use this media type: VPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 6.2.2. fax-message To: ietf-types@iana.org Subject: Registration of New Primary-Content type fax-message Primary-Content type name: fax-message Required parameters: none Optional parameters: none Encoding considerations: none Security considerations: none Interoperability considerations: none Published specification: draft-burger-vpim-pc-00.txt Applications which use this media type: FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Burger and Candell Expires 12/6/00 [Page 6] Primary Content of Internet Mail May 2000 Intended usage: COMMON 6.2.3. video-message To: ietf-types@iana.org Subject: Registration of New Primary-Content type video-message Primary-Content type name: voice-message Required parameters: none Optional parameters: none Encoding considerations: none Security considerations: none Interoperability considerations: none Published specification: draft-burger-vpim-pc-00.txt Applications which use this media type: VPIM, FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 6.2.4. text-message To: ietf-types@iana.org Subject: Registration of New Primary-Content type text-message Primary-Content type name: text-message Required parameters: Burger and Candell Expires 12/6/00 [Page 7] Primary Content of Internet Mail May 2000 none Optional parameters: none Encoding considerations: none Security considerations: none Interoperability considerations: none Published specification: draft-burger-vpim-pc-00.txt Applications which use this media type: VPIM, FPIM Additional information: none Person & email address to contact for further information: Eric Burger e.burger@ieee.org Intended usage: COMMON 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type Registration", RFC 2423, Lucent Technologies and Northern Telecom, September 1998. 4 Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. 5 Burger, E. and Candell, E., "Critical Content of Internet Mail", draft-burger-vpim-cc-00.txt, Work in Progress. Burger and Candell Expires 12/6/00 [Page 8] Primary Content of Internet Mail May 2000 6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 7 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 8. Acknowledgments Coming soon! 9. Author's Addresses Eric Burger Centigram Communications Corporation Maryland Technology Center 1375 Piccard Dr., MS 150I Rockville, MD 20850-4311 USA Phone: +1 301/212-3320 Email: e.burger@ieee.org Emily Candell Comverse Network Systems 200 Quannapowitt Pkwy. Wakefield, MA 01880 USA Phone: +1 781/213-2324 Email: emily@comversens.com Full Copyright Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such Burger and Candell Expires 12/6/00 [Page 9] Primary Content of Internet Mail May 2000 proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright (C) 2000 The Internet Society. 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. Burger and Candell Expires 12/6/00 [Page 10] From owner-ietf-fax@mail.imc.org Tue Jun 6 19:50:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20757 for ; Tue, 6 Jun 2000 19:50:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA15395 for ietf-fax-bks; Tue, 6 Jun 2000 16:14:14 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15391 for ; Tue, 6 Jun 2000 16:14:12 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA03992; Tue, 6 Jun 2000 19:22:14 -0400 (EDT) Message-Id: <200006062322.TAA03992@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Eric.Burger@centigram.com cc: internet-drafts@ietf.org, vpim@lists.neystadt.org, ietf-fax@imc.org Subject: Re: [VPIM] draft-burger-vpim-pc-00.txt In-reply-to: Your message of "Tue, 06 Jun 2000 08:39:00 EDT." <882568F6.0064F440.00@notes.centigram.com> Date: Tue, 06 Jun 2000 19:22:13 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: some immediate reactions: 1. given that the recipient's UA isn't supposed to indicate an error if the message is mislabeled (which I presume means that the message is supposed to be presented properly even if the primary-content field is incorrect or missing), is the entire purpose of this header field to make it easy to put an icon that shows the recipient the message type? what is this really supposed to convey to the recipient? - the kind of device that originated the message? - (more abstractly) the context in which this message is sent, or in which the sender expects it to be interpreted? - hints about possible modes of reply? - importance/urgency? (to some people, a fax inherently has a different importance/urgency than say, voice mail) - capabilities you need to be able to display/present this? 2. "primary content" doesn't really seem to capture what this is about. then again, I'm not sure what this is about... 3. the available types seem poorly defined, or at least, incomplete. either that or they seem to be oriented toward labelling the type of device that originated the message. content-type = 1 *( [ "voice-message"] [ "fax-message" ] [ "video-message" ] [ "text-message" ] ) what is a "voice message" anyway? is it any message that contains audio or for which the primary content is audio? is it limited to VPIM-compatible audio types. why not "audio message"? is music excluded? what is the difference between a "fax message" and an ordinary message for which the primary content is one or more images? are "fax messages" limited to internet fax content-types? are they expected to fit on letter or A4 size pages? etc. aren't there a large number of messages which don't fit into any of these categories? From owner-ietf-fax@mail.imc.org Tue Jun 6 20:01:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20908 for ; Tue, 6 Jun 2000 20:01:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16844 for ietf-fax-bks; Tue, 6 Jun 2000 16:30:50 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16838 for ; Tue, 6 Jun 2000 16:30:49 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA04130; Tue, 6 Jun 2000 19:38:59 -0400 (EDT) Message-Id: <200006062338.TAA04130@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Eric.Burger@centigram.com cc: internet-drafts@ietf.org, vpim@lists.neystadt.org, ietf-fax@imc.org Subject: Re: [VPIM] draft-burger-vpim-cc-00.txt In-reply-to: Your message of "Tue, 06 Jun 2000 08:37:39 EDT." <882568F6.0064F2DF.00@notes.centigram.com> Date: Tue, 06 Jun 2000 19:38:59 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: immediate comments on the criticality flag: 1. I'd far rather see this as a content-disposition parameter, but this might be just a matter of taste. 2. for DSNs, the interactions between notify/partial/ignore and the NOTIFY= SMTP parameter might need to be spelled out, preferably in a table. the current prose about this seems muddy. 3. "notify" and "partial" seem likely to invite confusion between SMTP NOTIFY and the "partial" message delivery status. something like "critical", "semi-critical", "not-critical" might work better...but these are not quite right either. (what did X.400 use? I don't have it handy right now...) 4. when to issue a DSN vs. when to deliver an MDN needs to be clarified - you send a DSN if the problem is detected at delivery time, you send an MDN if the problem is detected when the message is read. 5. there need to be DSN and MDN extensions to indicate which parts could not be converted/presented. this would presumably include new DSN status codes and new per-recipient, per-body-part, DSN fields to indicate the failure type and error message. (*please* don't invent new report types for these!) Keith p.s. both of these proposals really need to be reviewed by MIME folks - the mailing list is ietf-822@imc.org. From owner-ietf-fax@mail.imc.org Tue Jun 6 20:15:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21057 for ; Tue, 6 Jun 2000 20:15:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18250 for ietf-fax-bks; Tue, 6 Jun 2000 16:49:42 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18234 for ; Tue, 6 Jun 2000 16:49:39 -0700 (PDT) Received: from roselinsky ([207.175.94.186]) by mta1biz.bizmailsrvcs.net with SMTP id <20000606235711.CBFH4241532.mta1biz.bizmailsrvcs.net@roselinsky>; Tue, 6 Jun 2000 18:57:11 -0500 From: "Milt Roselinsky" To: Cc: , Subject: RE: [VPIM] draft-burger-vpim-pc-00.txt Date: Tue, 6 Jun 2000 16:57:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <882568F6.0064F440.00@notes.centigram.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have one comment about this draft. Have you thought about using the IMAP annotate draft? draft-daboo-imapext-annotate-00.txt Then the VPIM spec could just define the entries and attributes that identify a "voicemail" or "fax"message. Milt From owner-ietf-fax@mail.imc.org Wed Jun 7 01:37:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29409 for ; Wed, 7 Jun 2000 01:37:52 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA25456 for ietf-fax-bks; Tue, 6 Jun 2000 21:56:43 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25449 for ; Tue, 6 Jun 2000 21:56:42 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQAOUFIQGG0008M1@mauve.mrochek.com> for ietf-fax@imc.org; Tue, 06 Jun 2000 22:04:44 -0700 (PDT) Date: Tue, 06 Jun 2000 21:21:42 -0700 (PDT) Subject: Re: [VPIM] draft-burger-vpim-cc-00.txt In-reply-to: "Your message dated Tue, 06 Jun 2000 19:38:59 -0400" <200006062338.TAA04130@astro.cs.utk.edu> To: Keith Moore Cc: Eric.Burger@centigram.com, vpim@lists.neystadt.org, ietf-fax@imc.org Message-id: <01JQAQWPFWHM0008M1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: <882568F6.0064F2DF.00@notes.centigram.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > immediate comments on the criticality flag: > 1. I'd far rather see this as a content-disposition parameter, but > this might be just a matter of taste. I agree, and it isn't simply a matter of taste. There is already machinery deployed to handle content-disposition; using it is a real savings for implementors. > 2. for DSNs, the interactions between notify/partial/ignore and the > NOTIFY= SMTP parameter might need to be spelled out, preferably > in a table. the current prose about this seems muddy. Agreed as well. > 3. "notify" and "partial" seem likely to invite confusion between > SMTP NOTIFY and the "partial" message delivery status. Yes, these aren't good choices. But IMO this goes even deeper -- this document puts criticality solely on the axis of delivery notification generation. From the Introduction: In short, we need a method of indicating what sort of delivery notification the sender requires on a per-body part basis. I think this misses the point rather badly -- notifications aren't the immediate issue, the issue is whether or not the message should even be delivered, with notifications only being a consequence of that choice. I could also see a criticality flag of this sort affecting where a message is or isn't auto-forwarded by a smart delivery system. I would therefore suggest putting this along the axis of criticality, not along the axis of notifications. One you do this all sorts of choices suggest themselves (e.g., essential/useful/nonessential). > something like "critical", "semi-critical", "not-critical" > might work better...but these are not quite right either. > (what did X.400 use? I don't have it handy right now...) FWIW, I think you're confusing X.400's tri-state attributes (priority nonurgent, normal, urgent and sensitivity personal, private, company-confidential) with X.400's criticality flag. The former are attributes of a message; the latter is a boolean attribute of envelope extensions. That is, in X.400 you can mark an envelope extension as to whether or not understanding it is critical for message processing, and it is a yes/no choice. There's no way in X.400 to mark anything in the header or body in a similar fashion, and no associated useful terms in any case. > 4. when to issue a DSN vs. when to deliver an MDN needs to be > clarified - you send a DSN if the problem is detected at > delivery time, you send an MDN if the problem is detected > when the message is read. Right. > 5. there need to be DSN and MDN extensions to indicate which parts > could not be converted/presented. this would presumably include > new DSN status codes and new per-recipient, per-body-part, DSN > fields to indicate the failure type and error message. > (*please* don't invent new report types for these!) I believe this is already being done in draft-ema-vpim-pndn-01.txt, although I think this document needs work. It doesn't define a new report type (although there is an apparenent remnant of when it did so in the table of contents referring to message/partial-delivery-status). FYI, issues I see in draft-ema-vpim-pndn-01.txt include: (1) Use of separate sections in the delivery status area for different parts as opposed to different recipients isn't backwards-compatible and is likely to cause trouble with existing handlers of these things. (The MIXER mapping to X.400 certainly breaks in this case, for example.) I'd rather see everything pertaining to a single recipient in a single section. (2) The combination of a 5.x.y status with an action of "delivered" isn't good either, although I'm not sure how to resolve it. (3) Content-ids have the same syntax as message-ids, more or less. This document presents them as simple strings. (4) The dependency on content-ids is worrisome. Yes, any positional reference may be thrown off by conversions and who knows what else, but some indication may be better than nothing. Ned From owner-ietf-fax@mail.imc.org Thu Jun 8 12:50:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11806 for ; Thu, 8 Jun 2000 12:50:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28621 for ietf-fax-bks; Thu, 8 Jun 2000 09:08:27 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28607 for ; Thu, 8 Jun 2000 09:08:26 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D37FA42U@mta5.rcsntx.swbell.net> for ietf-fax@imc.org; Thu, 8 Jun 2000 11:05:15 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:15 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-fax@imc.org Message-id: <0FVU00DFOFCP2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-ietf-fax@mail.imc.org Thu Jun 8 15:12:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14575 for ; Thu, 8 Jun 2000 15:12:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03790 for ietf-fax-bks; Thu, 8 Jun 2000 11:02:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03786 for ; Thu, 8 Jun 2000 11:02:10 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA19514; Thu, 8 Jun 2000 11:10:30 -0700 (PDT) Message-Id: <200006081810.LAA19514@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2846 on GSTN Address Extensions in E-mail Services Cc: rfc-ed@ISI.EDU, ietf-fax@imc.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 08 Jun 2000 11:10:30 -0700 From: RFC Editor Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2846 Title: GSTN Address Element Extensions in E-mail Services Author(s): C. Allocchio Status: Standards Track Date: June 2000 Mailbox: Claudio.Allocchio@elettra.trieste.it Pages: 35 Characters: 54316 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fax-fulladdr-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc2846.txt There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in [1]. This document is a product of the Internet Fax Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608110831.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2846 --OtherAccess Content-Type: Message/External-body; name="rfc2846.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608110831.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Fri Jun 9 05:38:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08000 for ; Fri, 9 Jun 2000 05:38:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA28505 for ietf-fax-bks; Fri, 9 Jun 2000 01:51:34 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28500 for ; Fri, 9 Jun 2000 01:51:32 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQBUZBCTDC0009XA@mauve.mrochek.com> for ietf-fax@imc.org; Fri, 09 Jun 2000 01:59:58 -0700 (PDT) Date: Fri, 09 Jun 2000 01:56:16 -0700 (PDT) Subject: RE: [VPIM] draft-burger-vpim-pc-00.txt In-reply-to: "Your message dated Tue, 06 Jun 2000 16:57:07 -0700" To: Milt Roselinsky Cc: Eric.Burger@centigram.com, vpim@lists.neystadt.org, ietf-fax@imc.org Message-id: <01JQDRP221HA0009XA@mauve.mrochek.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <882568F6.0064F440.00@notes.centigram.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I have one comment about this draft. > Have you thought about using the IMAP annotate draft? > draft-daboo-imapext-annotate-00.txt > Then the VPIM spec could just define the entries and > attributes that identify a "voicemail" or "fax"message. IMAP annotations only apply to messages in message stores, not to messages being transported. The intent of this mechanism is to allow a message sender to indicate the type of a message to a recipient, which means a mechanism that works across message transports has to be used. Ned From owner-ietf-fax@mail.imc.org Fri Jun 9 10:41:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12379 for ; Fri, 9 Jun 2000 10:41:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16428 for ietf-fax-bks; Fri, 9 Jun 2000 06:47:47 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16423 for ; Fri, 9 Jun 2000 06:47:45 -0700 (PDT) Date: Fri, 9 Jun 2000 15:55:33 +0100 To: agenda@ietf.org cc: ietf-fax@imc.org, Hiroshi Tamura , Patrik Faltstrom , Ned Freed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: ietf-fax meeting slot for Pittsburgh (update). Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, as we received no further objections from WG members, I confirm the following request: A 2 and 1/2 hour slot for the Pittsburgh meeting for the Internet Fax WG. Anticipated attendance: 60 Other WGs/BOF to avoid: IPPext, VPIM, DRUMS, Rescap, Enum, Megaco, Qualdocs, IMPP A time on Wednesday or Tuesday afternoon (with a strong preference for Wednesday) is preferred, as Monday, Thursday and Friday clashes with other events where the "fax community" people is attending. Thank you indeed and regards Claudio Allocchio, ietf-fax WG co-chair From owner-ietf-fax@mail.imc.org Sat Jun 10 23:52:31 2000 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14557 for ; Sat, 10 Jun 2000 23:52:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA08484 for ietf-fax-bks; Sat, 10 Jun 2000 20:15:20 -0700 (PDT) Received: from 209.58.67.69 (Teleglobe.net [209.58.67.69] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08475 for ; Sat, 10 Jun 2000 20:15:17 -0700 (PDT) Received: apparently from Palito - 209.58.67.69 by 209.58.67.69 with Microsoft SMTPSVC(5.5.1775.675.6); Sat, 10 Jun 2000 22:15:10 -0500 X-Sender: peruvians2000@hotmail.com From: Jorge Mattiesti To: ietf-fax@imc.org Date: Sat, 10 Jun 2000 22:15:10 -0500 Subject: page about Peru Reply-To: jorge@209.58.67.69 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__3330949_80110,94" Message-ID: <008101015030b60MARQUITO@209.58.67.69> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. ------=_NextPart_000_001__3330949_80110,94 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_001__3330949_80110,94 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Please

Please visit page of Peru: http://209.58.67.69/peruvians  Our country is a beautiful place for know.

Jorge

------=_NextPart_000_001__3330949_80110,94-- From owner-ietf-fax@mail.imc.org Tue Jun 13 23:19:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29102 for ; Tue, 13 Jun 2000 23:19:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA25004 for ietf-fax-bks; Tue, 13 Jun 2000 19:46:41 -0700 (PDT) Received: from pp-mx0.tokyo.spin.ad.jp (PP-mx0.Tokyo.Spin.AD.JP [165.76.52.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24988 for ; Tue, 13 Jun 2000 19:46:36 -0700 (PDT) Received: from localhost (1Cust89.tnt2.tco2.da.uu.net [63.20.245.89]) by pp-mx0.tokyo.spin.ad.jp (8.8.8+Spin/3.6W-JENS-stand2(10/10/99)) id LAA20045; Wed, 14 Jun 2000 11:45:48 +0900 (JST) To: paf@swip.net, ned.freed@innosoft.com, ietf-fax@imc.org Cc: tsg8ifax@ITU.CH, Claudio.Allocchio@elettra.trieste.it Subject: [IETF-FAX] Modified charter of Fax WG From: Hiroshi Tamura X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000614064031G.adm@ifax.attnet.ne.jp> Date: Wed, 14 Jun 2000 06:40:31 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 125 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Patrik, Dear Ned, Dear Colleagues of IETF Fax WG, I am Hiroshi Tamura, a co-chair of Fax WG. The modified charter is below. The discussion at Adelaide is reflected in it. With regard to milestone(target date), in fact, it may be necessary to modify. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. tamura@toda.ricoh.co.jp -------------------------------------------------------------------- Internet Fax Extensions (faxext) -------------------------------- Chair(s): Hiroshi Tamura Claudio Allocchio Applications Area Director(s): Patrik Faltstrom Ned Freed Area Advisor Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ DESCRIPTION OF WORKING GROUP: Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will take care of differential routing between classic Internet mail and timely deliveries, and consider with particular regard universal messaging issues and its relation with Internet mail. The WG will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, [image] feature selection/negotiation, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM). For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The working group will also consider the requirements for gatewaying Internet Mail (as profiled for facsimile Simple, Extended modes and FFPIM) with T.30 Facsimile. The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide. T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document integrity, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet. T.30 facsimile provides for receiver capability identification to the sender, allowing a sender to provide the "best" fax image the receiver can handle. The Faxext working group will consider mechanisms to provide similar functionality for fax images transferred by e-mail. Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method. The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, in particular the ITU, VPIM and other WGs, and with using work from related IETF efforts. GOALS AND MILESTONES: Mar 2000 Working Group chartered Mar 2000 Initial drafts for timely delivery , content negotiaton and FFPIM Mar 2000 Initial draft of Implementors Guide for Simple and Extended mode Jun 2000 Revised drafts for timely delivery, content negotiaton and FFPIM Jun 2000 Initial drafts of TIFF-fx extensions Jul 2000 Initial Routing considerations draft Jul 2000 Initial draft of gateway requirements Jul 2000 Final draft of Implementors Guide for Simple and Extended mode Sep 2000 Initial drafts of schema for TIFF-fx extensions Nov 2000 Final draft for timely delivery and content negotiaton. Nov 2000 Final draft of Routing Considerations Nov 2000 Final draft of FFPIM Mar 2001 Final draft of gateway requirements Apr 2001 Final drafts of schema and TIFF-fx extensions for JBIG-2 From owner-ietf-fax@mail.imc.org Wed Jun 14 10:34:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22673 for ; Wed, 14 Jun 2000 10:34:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04476 for ietf-fax-bks; Wed, 14 Jun 2000 07:04:36 -0700 (PDT) Received: from jsc-ems-gws02.jsc.nasa.gov (JSC-EMS-GWS02.jsc.nasa.gov [139.169.16.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04472 for ; Wed, 14 Jun 2000 07:04:35 -0700 (PDT) Received: by JSC-EMS-GWS02.jsc.nasa.gov with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jun 2000 09:02:53 -0500 Message-ID: <81F639B56628D011A32D0020AFFC019003B88749@jsc-ems-mbs07.jsc.nasa.gov> From: "COLES, RICHARD J. (JSC-EV)" To: "'Hiroshi Tamura'" Cc: "'ietf-fax@imc.org'" Subject: RE: [IETF-FAX] Modified charter of Fax WG Date: Wed, 14 Jun 2000 09:03:04 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-san, The revised charter looks good to me, but I have a question. Am I automatically subscribed, having been a member of this list for about 3 years (mostly listening), or must we all re-subscribe to the new address, as inserted below? >Mailing lists: > General Discussion:ietf-fax@imc.org > To Subscribe: ietf-fax-request@imc.org > In Body: In Body: subscribe > Archive: http://www.imc.org/ietf-fax/ Thanks, Richard Coles Lockheed Martin, in support of NASA/Johnson Space Center/Houston -----Original Message----- From: Hiroshi Tamura [mailto:tamura@toda.ricoh.co.jp] Sent: Tuesday, June 13, 2000 4:41 PM To: paf@swip.net; ned.freed@innosoft.com; ietf-fax@imc.org Cc: tsg8ifax@ITU.CH; Claudio.Allocchio@elettra.trieste.it Subject: [IETF-FAX] Modified charter of Fax WG Dear Patrik, Dear Ned, Dear Colleagues of IETF Fax WG, I am Hiroshi Tamura, a co-chair of Fax WG. The modified charter is below. The discussion at Adelaide is reflected in it. With regard to milestone (target date), in fact, it may be necessary to modify. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. tamura@toda.ricoh.co.jp -------------------------------------------------------------------- Internet Fax Extensions (faxext) -------------------------------- Chair(s): Hiroshi Tamura Claudio Allocchio Applications Area Director(s): Patrik Faltstrom Ned Freed Area Advisor Mailing lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ DESCRIPTION OF WORKING GROUP: < text deleted for economy > From owner-ietf-fax@mail.imc.org Wed Jun 14 12:03:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26305 for ; Wed, 14 Jun 2000 12:03:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07122 for ietf-fax-bks; Wed, 14 Jun 2000 08:39:23 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07118 for ; Wed, 14 Jun 2000 08:39:21 -0700 (PDT) Date: Wed, 14 Jun 2000 17:35:09 +0100 To: "COLES, RICHARD J. (JSC-EV)" cc: "'Hiroshi Tamura'" , "'ietf-fax@imc.org'" In-Reply-To: <81F639B56628D011A32D0020AFFC019003B88749@jsc-ems-mbs07.jsc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: RE: [IETF-FAX] Modified charter of Fax WG Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Am I automatically subscribed, having been a member of this list for about 3 > years (mostly listening), or must we all re-subscribe to the new address, as > inserted below? Actually, we did not change the mailing list, thus no re-subscription should be needed, at all. Regards, Claudio Allocchio PS: as Tamura-san pointed out, could the members of the WG (expecially the editors of the various document) please check the new Milestone dates? Thank you! From owner-ietf-fax@mail.imc.org Thu Jun 15 03:46:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24740 for ; Thu, 15 Jun 2000 03:46:39 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA01558 for ietf-fax-bks; Wed, 14 Jun 2000 23:49:55 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01551 for ; Wed, 14 Jun 2000 23:49:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA17584 for ; Wed, 14 Jun 2000 23:49:01 -0700 (PDT) Date: Wed, 14 Jun 2000 23:49:01 -0700 (PDT) From: Dan Wing To: IETF Internet Fax WG Subject: Fwd: RFC 2852 on Deliver By SMTP Service Extension Message-ID: <0006142348450.15338-110000@omega.cisco.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-961051741=:15338" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-758783491-961051741=:15338 Content-Type: TEXT/PLAIN; charset=US-ASCII This RFC should be of interest to folks dealing with fax. -Dan Wing ---559023410-758783491-961051741=:15338 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: <0006142348451.15338@omega.cisco.com> Content-Description: Fwd: RFC 2852 on Deliver By SMTP Service Extension Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA10417; Tue, 13 Jun 2000 16:33:42 -0700 (PDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA28909; Tue, 13 Jun 2000 16:33:12 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e5DNX2a14283; Tue, 13 Jun 2000 16:33:02 -0700 (PDT) Received: from (loki.ietf.org [132.151.1.177]) by proxy3.cisco.com with SMTP (MailShield v1.5); Tue, 13 Jun 2000 16:33:01 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id TAA29295 for ietf-123-outbound.02@ietf.org; Tue, 13 Jun 2000 19:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id SAA29226 for ; Tue, 13 Jun 2000 18:52:12 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24294 for ; Tue, 13 Jun 2000 18:52:10 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA15669; Tue, 13 Jun 2000 15:52:10 -0700 (PDT) Message-Id: <200006132252.PAA15669@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2852 on Deliver By SMTP Service Extension Cc: rfc-ed@ISI.EDU Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 13 Jun 2000 15:52:10 -0700 From: RFC Editor X-SPAM: Yes X-SPAM-REASON: Suspicious TO Address X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: loki.ietf.org X-SMTP-MAIL-FROM: ietf-123-owner@loki.ietf.org X-SMAP-Received-From: outside X-SMTP-PEER-INFO: loki.ietf.org [132.151.1.177] X-Envelope-From: list-owner-incoming-ietf@sj-msg-core-1.cisco.com Tue Jun 13 16:33:42 2000 omega --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2852 Title: Deliver By SMTP Service Extension Author(s): D. Newman Status: Standards Track Date: June 2000 Mailbox: dan.newman@innosoft.com Pages: 13 Characters: 29285 Updates: 1849 I-D Tag: draft-newman-deliver-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2852.txt This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued. This extension should not be viewed as a vehicle for requesting "priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a Deliver By request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period. A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond 17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a "delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000613155008.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2852 --OtherAccess Content-Type: Message/External-body; name="rfc2852.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000613155008.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- ---559023410-758783491-961051741=:15338-- From owner-ietf-fax@mail.imc.org Tue Jun 20 14:34:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01257 for ; Tue, 20 Jun 2000 14:34:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20863 for ietf-fax-bks; Tue, 20 Jun 2000 11:04:49 -0700 (PDT) Received: from pasiphae.eastgw.xerox.com (root@pasiphae.xerox.com [208.140.33.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20858 for ; Tue, 20 Jun 2000 11:04:47 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA19159; Tue, 20 Jun 2000 14:04:41 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id LAA18214; Tue, 20 Jun 2000 11:03:44 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 11:03:44 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A2A10@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Claudio Allocchio'" , "COLES, RICHARD J. (JSC-EV)" Cc: "'Hiroshi Tamura'" , "'ietf-fax@imc.org'" Subject: RE: [IETF-FAX] Modified charter of Fax WG Date: Tue, 20 Jun 2000 11:03:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Claudio and Tamura-san, Graham and I would like to suggest a modification to the charter milestone date for the initial schema draft (i.e. Sep 2000 changed to Nov 2000). We anticipate that the TIFF-FX extension associated with annotations may not realize convergence soon enough to deliver a Schema extension draft in September. Regards, Lloyd ---snip--- GOALS AND MILESTONES: Sep 2000 Initial drafts of schema for TIFF-FX extensions change to: Nov 2000 Initial drafts of schema for TIFF-FX extensions > -----Original Message----- > From: Claudio Allocchio [mailto:Claudio.Allocchio@elettra.trieste.it] > Sent: Wednesday, June 14, 2000 9:35 AM > To: COLES, RICHARD J. (JSC-EV) > Cc: 'Hiroshi Tamura'; 'ietf-fax@imc.org' > Subject: RE: [IETF-FAX] Modified charter of Fax WG > > > > > Am I automatically subscribed, having been a member of this > list for about 3 > > years (mostly listening), or must we all re-subscribe to > the new address, as > > inserted below? > > Actually, we did not change the mailing list, thus no re-subscription > should be needed, at all. > > Regards, > Claudio Allocchio > > PS: as Tamura-san pointed out, could the members of the WG > (expecially the > editors of the various document) please check the new Milestone dates? > Thank you! > From owner-ietf-fax@mail.imc.org Wed Jun 21 16:59:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12758 for ; Wed, 21 Jun 2000 16:59:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29669 for ietf-fax-bks; Wed, 21 Jun 2000 13:14:32 -0700 (PDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29665 for ; Wed, 21 Jun 2000 13:14:31 -0700 (PDT) Received: by dnspri.npac.com; id PAA23127; Wed, 21 Jun 2000 15:14:05 -0500 (CDT) Received: from nodnsquery(192.168.20.171) by dnspri.npac.com via smap (V5.0) id xma023036; Wed, 21 Jun 00 15:13:40 -0500 Message-Id: <4.3.1.2.20000621150539.00c217d0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 21 Jun 2000 15:14:33 -0500 To: "McDonald, Ira" , "'ipp@pwg.org'" , "'ifx@pwg.org'" From: Richard Shockey Subject: Re: IFX> Some current Internet FAX refs - RFCs and I-Ds Cc: ietf-fax@imc.org In-Reply-To: <1115A7CFAC25D311BC4000508B2CA5375ECDAA@MAILSRVNT02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:44 PM 6/21/2000 -0700, McDonald, Ira wrote: >Copies: ipp@pwg.org, ifx@pwg.org > >Hi folks, Wednesday (21 June 2000) > >Per my action from today's IPP WG Telecon, below is a list of the RFCs >that are pertinent for Internet Fax and therefore for QualDocs (IFax >over IPP). > >Cheers, >- Ira McDonald > High North Inc This is excellent Ira. . I just want make it publicly clear, as I stated in the IPP Telecon today that I am totally in favor of the PWG taking on the QUALDOCS work independently of the IETF. There is no reason to wait any longer. I don't think this should be interpreted as a reproach of the IETF, far from it, it only a simple recognition of the difficulties APP's Area Directors have in taking on new work. Only one new WG, VPIM has received a charter since IETF in Australia. QUALDOCS has had 3 successful BOF's and a team assembled ready to start work ....but no charter. I would continue to extend a open invitation to the members of the IETF-FAX work group to participate in a PWG QUALDOCS project through this list and through invitations to the regularly scheduled IPP meetings. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please Note New Contact Information: Richard Shockey Shockey Consulting LLC 5237 Sutherland St. Louis, MO 63109 Voice 314.503.0640 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<