From owner-ietf-fax@mail.imc.org Thu Feb 1 07:34:10 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24742 for ; Thu, 1 Feb 2001 07:34:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28213 for ietf-fax-bks; Thu, 1 Feb 2001 03:54:38 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28208 for ; Thu, 1 Feb 2001 03:54:36 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id VAA14741; Thu, 1 Feb 2001 21:01:18 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma014649; Thu, 1 Feb 01 21:00:57 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id VAA09309; Thu, 1 Feb 2001 21:00:56 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id VAA18437; Thu, 1 Feb 2001 21:00:56 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id VAA03539; Thu, 1 Feb 2001 21:00:05 +0900 (JST) Message-Id: <4.2.0.58.J.20010201210000.00a82480@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 01 Feb 2001 21:08:44 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: goals for Terminal Mode Cc: Hiroshi Tamura , Claudio Allocchio 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: Hi, forks I explained about Terminal Mode in the fax wg at San Diego on December, that ITU-T requested to consider adding a new charter about Terminal Mode. I tried to define the goals for Terminal Mode as follows. This is just beginning of discussion. I want have creative discussion about Terminal Mode over mailing list before the Minneapolis IETF meeting on March. Regards, Toru MAEDA CANON Inc. Goal for Terminal Mode 1. Introduction The specification defines Terminal mode carriage of facsimile data over the Internet, and its functionality necessary for achieving reliability, timeliness and capability negotiation for Internet mail that is on a par with classic T.30 facsimile. Terminal Mode is intend to implement features of all classic T.30 facsimile over Internet, providing a level of service that approximates the level currently enjoyed by fax users, and providing all fax-specific features that will be implemented in an embedded fax device software working on G3 fax based system with limited memory size and CPU performance. These fax specific features to be supported are Polling, Subaddress, Password, senders ID, Internet Selective Polling address, Internet Routing address and Double Side Printing, which will be easy to develop gateway function between G3 fax and Terminal Mode Internet fax. Also new features are designed such as (1) legal support by fax header or cover page with sender's ID and Time&date, (2) end to end SMTP session and (3) One SMTP session for capability exchange/image transmission/confirmation. 2. Goals for Terminal Mode Those are goals for Terminal Mode Easy to Implement Interworking with G3 fax, IFAX Simple Mode and EIFAX Features shared with G3 fax Proof of delivery/receipt Capability Exchange Timely Delivery Data Format Support Cover Page and Fax Header Date and Time Information Legal Issue Legal Identity Exchange Quality of output Addressing Support Use of Existing Infrastructure Reliably in the global Internet Security -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Thu Feb 1 10:58:59 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29770 for ; Thu, 1 Feb 2001 10:58:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09240 for ietf-fax-bks; Thu, 1 Feb 2001 07:16:05 -0800 (PST) Received: from mail15b.boca15-verio.com ([208.55.91.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09229 for ; Thu, 1 Feb 2001 07:16:02 -0800 (PST) Received: from 128.241.144.247 (128.241.144.247) by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id 120810943; Thu, 1 Feb 2001 10:22:35 -0500 (EST) From: "Eric Burger" To: , , Subject: FW: I-D ACTION:draft-ietf-vpim-hint-02.txt Date: Thu, 1 Feb 2001 10:22:54 -0500 Message-ID: <003201c08c62$d94909a0$d19bfea9@office.snowshore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C08C38.F07C2960" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Loop-Detect: 1 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C08C38.F07C2960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Voice Profile for Internet Mail Working Group of the IETF. Title : Message Context for Internet Mail Author(s) : E. Burger, E. Candell, C. Eliot, G. Klyne Filename : draft-ietf-vpim-hint-02.txt Pages : 19 Date : 26-Jan-01 This memo describes a new RFC822 message header, 'Message-Context'. This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vpim-hint-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vpim-hint-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0033_01C08C38.F07C2960 Content-Type: Message/External-body; name="ATT00024.dat" Content-Disposition: attachment; filename="ATT00024.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010126131950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vpim-hint-02.txt ------=_NextPart_000_0033_01C08C38.F07C2960 Content-Type: Message/External-body; name="draft-ietf-vpim-hint-02.txt" Content-Disposition: attachment; filename="draft-ietf-vpim-hint-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010126131950.I-D@ietf.org> ------=_NextPart_000_0033_01C08C38.F07C2960-- From owner-ietf-fax@mail.imc.org Thu Feb 1 20:44:44 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16842 for ; Thu, 1 Feb 2001 20:44:44 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA16495 for ietf-fax-bks; Thu, 1 Feb 2001 17:02:28 -0800 (PST) Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA16488 for ; Thu, 1 Feb 2001 17:02:26 -0800 (PST) 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 UAA03275; Thu, 1 Feb 2001 20:09:14 -0500 (EST) 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 RAA26648; Thu, 1 Feb 2001 17:08:57 -0800 (PST) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 1 Feb 2001 17:08:56 -0800 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A2FE6@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'IETF - Hiroshi Tamura (IFaxWG chair)'" , "'IETF fax WG'" Cc: "'Cancio vcancio@pacbell.net'" , "'Cancio,Vivian (Redcreek Comm)'" , "'Cisco - Dan Wing'" , "'Mike Moldovan - GenTec'" Subject: Implementers Guide comments Date: Thu, 1 Feb 2001 17:08:50 -0800 Importance: high X-Priority: 1 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: Tamura-san, I would like to comment on two items, 1) ambiguity with regard to the definition of "word" size and 2) comments on Section 5 of the Implementers Guide. Please see below. Thank you, Lloyd 1) Word Size The requirement to begin an IFD on a "word" boundary is specified in TIFF 6.0. TIFF-FX is simply reiterating this requirement. Since TIFF 6.0 is the based reference for TIFF-FX, any clarification of ambiguity associated with the definition of "word" size should be done in TIFF 6.0, not TIFF-FX. It may, however, be appropriate to add an item to Section 5.1 of the Implementers Guide giving guidance on interpretation of this ambiguity. I propose revising Section 5.1 of the Implementers Guide V4.0 to read as follows: 5.1 IFD Placement in TIFF file & Profile S Constraints a) An IFD is required, by TIFF 6.0, to begin on a word boundary, however, there is ambiguity with regard to the defined size of a word. A word should be interpreted as a 2-byte quantity. This recommendation is based on examination of Figure 1 and the definition of IFD Entry, Bytes 8-11, found in Section 2 of TIFF 6.0. b) Low memory devices, which support resolutions greater than the required Profile-S, may be memory-constrained such that those devices cannot properly handle arbitrary placement of TIFF IFDs within a TIFF file. To interoperate with a receiver that is constrained, it is strongly recommended that senders always place the IFD at the beginning of the TIFF-FX file when using any of the Profiles defined in RFC 2301. 2) Section 5 of the Implementers Guide Most of errors document in Section 5.2 were NOT experienced during interoperability testing, as stated. Recommendation a) Delete current items 5.2 h, 5.2 i and 5.2.1 b as they are unfounded and the recommendations will create incompatibilities. b) Divide Section 5.2 into two distinct sub-sections, clarifying those that are observed interoperability errors. Example: New 5.2.1 Errors encountered during interoperability testing This could include items such as current 5.2 a and b. New 5.2.2 Items that require particular attention This could include items that were not observed during interoperability testing. At the start of this sub-section it may be appropriate to highlight the general TIFF guidelines of ignoring field values that are not recognized or are not supported. Items that may be included: current 5.2 c, d, e, f, g current 5.2.1 a, c, d, e, f, g current 5.2.2 a, b, c, d Revise 5.2.2 C to read as follows: "The strip offset + StripByteCounts does not point outside the file" current 5.2.3 a, b, c current 5.2.4 a, b Revise 5.2.4 b to read as follows: "Implementers should make sure when generating a TIFF Profile M that the compression used for the layers is correct. Possible errors may include the Mask layer not being compressed with a binary encoder and the Background and Foreground layers not being compressed with a multi-level (e.g. color) encoder." From owner-ietf-fax@mail.imc.org Sun Feb 4 20:09:54 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13526 for ; Sun, 4 Feb 2001 20:09:54 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA12477 for ietf-fax-bks; Sun, 4 Feb 2001 16:24:51 -0800 (PST) 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 QAA12473 for ; Sun, 4 Feb 2001 16:24:48 -0800 (PST) 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 JAA16592; Mon, 5 Feb 2001 09:22:37 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id JAA18999; Mon, 5 Feb 2001 09:22:36 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id JAA07495; Mon, 5 Feb 2001 09:22:33 +0900 To: Lloyd.McIntyre@pahv.xerox.com, mmoldovan@gentech.com Cc: ietf-fax@imc.org Subject: Re: Implementers Guide comments In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE067A2FE6@mercury.ADOC.xerox.com> References: <51B8ABCE456FD111899900805F6FD6EE067A2FE6@mercury.ADOC.xerox.com> 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: <20010205092855K.tamura@toda.ricoh.co.jp> Date: Mon, 05 Feb 2001 09:28:55 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 74 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1) Word Size > > The requirement to begin an IFD on a "word" boundary is specified in TIFF > 6.0. TIFF-FX is simply reiterating this requirement. Since TIFF 6.0 is the > based reference for TIFF-FX, any clarification of ambiguity associated with > the definition of "word" size should be done in TIFF 6.0, not TIFF-FX. It > may, however, be appropriate to add an item to Section 5.1 of the > Implementers Guide giving guidance on interpretation of this ambiguity. I > propose revising Section 5.1 of the Implementers Guide V4.0 to read as > follows: OK. > 5.1 IFD Placement in TIFF file & Profile S Constraints > > a) An IFD is required, by TIFF 6.0, to begin on a word boundary, > however, there is ambiguity with regard to the defined size of > a word. A word should be interpreted as a 2-byte quantity. This > recommendation is based on examination of Figure 1 and the > definition of IFD Entry, Bytes 8-11, found in Section 2 of > TIFF 6.0. Ok. I think everybody can agree to the above. > 2) Section 5 of the Implementers Guide > > Most of errors document in Section 5.2 were NOT experienced during > interoperability testing, as stated. > > Recommendation > a) Delete current items 5.2 h, 5.2 i and 5.2.1 b as they are unfounded and > the recommendations will create incompatibilities. > > b) Divide Section 5.2 into two distinct sub-sections, clarifying those that > are observed interoperability errors. > > Example: > New 5.2.1 Errors encountered during interoperability testing > This could include items such as current 5.2 a and b. > > New 5.2.2 Items that require particular attention > This could include items that were not observed during interoperability > testing. > > At the start of this sub-section it may be appropriate to highlight the > general TIFF guidelines of ignoring field values that are not recognized or > are not supported. > > Items that may be included: > current 5.2 c, d, e, f, g > current 5.2.1 a, c, d, e, f, g > current 5.2.2 a, b, c, d > Revise 5.2.2 C to read as follows: > "The strip offset + StripByteCounts does not point > outside the file" > current 5.2.3 a, b, c > current 5.2.4 a, b > Revise 5.2.4 b to read as follows: > "Implementers should make sure when generating a TIFF Profile M > that the compression used for the layers is correct. Possible > errors may include the Mask layer not being compressed with a > binary encoder and the Background and Foreground layers not > being compressed with a multi-level (e.g. color) encoder." With regard to it, I need Mike's comment. Mike, can you agree to the above? If so, I will update according to it. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Tue Feb 6 02:32:56 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09797 for ; Tue, 6 Feb 2001 02:32:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA18019 for ietf-fax-bks; Mon, 5 Feb 2001 22:53:42 -0800 (PST) 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 WAA17999 for ; Mon, 5 Feb 2001 22:53:38 -0800 (PST) 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 QAA13032; Tue, 6 Feb 2001 16:00:42 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id QAA22617; Tue, 6 Feb 2001 16:00:41 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id QAA19638; Tue, 6 Feb 2001 16:00:35 +0900 To: GK@ninebynine.org Cc: ietf-fax@imc.org Subject: Re: Progress update: negotiation In-Reply-To: <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> References: <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> 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: <20010206160703W.tamura@toda.ricoh.co.jp> Date: Tue, 06 Feb 2001 16:07:03 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 69 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit At first glance of draft-ietf-fax-content-negotiaion-04.txt, lots of points are clarified, I think. > The draft is all there now, but there are some specific points I would like > to discuss. One in particular that the authors jointly feel would benefit > from group discussion has arisen from the late addition of a negotiate-down > example: if the sender has an alternative that assumed _lower_ > capabilities than the version actually sent, should those lower > capabilities be described explicitly by a Content-alternatives > header? When the draft is available, I'll post more details of this > issue. Other points regarding which WG revciew is explicitly requested are: Negotiation-down example itself is good. Thanks for taking it. In my feeling, it is better to describe lower or baseline capabilities in Content-alternatives explicitly, but not mandatory. All terminals or software must support baseline one at least. > o Cache-control for recipient features? (e.g. colour offered for > selected senders only). (3.2.3) I understand under some conditions the receiver do not want to announce his capabilities. If you take care, you can write something in Appendix A(implementation issues). > o Check the correct final disposition for lost message data (3.4) An suitable type do not exist in the current definitions, but "deleted" is ok for me. > o Define Content-alternative in a separate document? (Possibly, > because it might be used separately from the content negotiation > framework; e.g. in a fashion similar to the HTTP vary: header.) > (4) If possible, another document is better so that other applications can use it clearly. But, I leave it to the editors. > o Describe interaction between Content-alternative and > message/partial. Is the discussion in RFC 2298 section 2.5 > sufficient? (4) Huum. Difficult to comment. I do not know soon. I hope it is sufficient. How about describing something in Appendix A? > o Special considerations for defining composite document > characteristics (e.g. MRC) in Content-alternative headers? (4) I do not know the issue well. Is it diffcult to express? > o Add E164 address type for reporting fax offramp disposal? (6.2) It seems to be difficult to take. Because, it has something to do with G3 or G4 fax protocol itself. It is better NOT to address, I think. > o Discuss the options that should be exposed using Content- > alternative; e.g. is it necessary to declare 'baseline' > capabilities. As I said in the above, it is better, but not mandatory. BTW, Section 9(IANA...) is sufficient for registering headers or anything? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Wed Feb 7 00:55:01 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12101 for ; Wed, 7 Feb 2001 00:55:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA21328 for ietf-fax-bks; Tue, 6 Feb 2001 21:06:33 -0800 (PST) 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 VAA21324 for ; Tue, 6 Feb 2001 21:06:30 -0800 (PST) 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 OAA15687; Wed, 7 Feb 2001 14:13:51 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id OAA27425; Wed, 7 Feb 2001 14:13:48 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id OAA27741; Wed, 7 Feb 2001 14:13:28 +0900 To: ietf-fax@imc.org cc: maeda.toru@canon.co.jp Subject: Re: goals for Terminal Mode In-Reply-To: <4.2.0.58.J.20010201210000.00a82480@ffmmail.ffm.canon.co.jp> References: <4.2.0.58.J.20010201210000.00a82480@ffmmail.ffm.canon.co.jp> 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: <20010207141956T.tamura@toda.ricoh.co.jp> Date: Wed, 07 Feb 2001 14:19:56 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 101 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Our group was requested to reply to ITU-T SG16. Next SG16 meeting will be held at the end of May. We have time to consider. But, at Minneapolis meeting, I would like to have some directions. I think Maeda-san is preparing two I-Ds. One is about the terminal mode, which he writes below. The other is about ifax status information. About the terminal mode, we already have a letter from ITU-T and He writes his goals below. If there are comments, please kindly say in ML. Any comment are welcome by him. W.R.T. the ifax status information, there are no information. We wait for his I-D or something. Regards, -- Hiroshi Tamura, Co-chair of IETF FAX WG E-mail: tamura@toda.ricoh.co.jp From: MAEDA toru Subject: goals for Terminal Mode Date: Thu, 01 Feb 2001 21:08:44 +0900 > > Hi, forks > > I explained about Terminal Mode in the fax wg at San Diego on December, > that ITU-T requested to consider adding a new charter about Terminal Mode. > > I tried to define the goals for Terminal Mode as follows. > This is just beginning of discussion. > I want have creative discussion about Terminal Mode > over mailing list before the Minneapolis IETF meeting on March. > > > Regards, > > Toru MAEDA > CANON Inc. > > > Goal for Terminal Mode > > 1. Introduction > The specification defines Terminal mode carriage of > facsimile data over the Internet, and its functionality necessary > for achieving reliability, timeliness and capability negotiation for > Internet mail that is on a par with classic T.30 facsimile. > > Terminal Mode is intend to implement features of all classic T.30 facsimile > over > Internet, providing a level of service that approximates the level > currently enjoyed by fax users, and providing all fax-specific features > that will be implemented in an embedded fax device software working on > G3 fax based system with limited memory size and CPU performance. > These fax specific features to be supported are Polling, Subaddress, > Password, senders ID, Internet Selective Polling address, Internet Routing > address and > Double Side Printing, which will be easy to develop gateway function > between G3 fax and Terminal Mode Internet fax. > > > Also new features are designed such as (1) legal support by fax header or > cover page with sender's ID and Time&date, (2) end to end SMTP session > and (3) One SMTP session for capability exchange/image > transmission/confirmation. > > > 2. Goals for Terminal Mode > Those are goals for Terminal Mode > > Easy to Implement > Interworking with G3 fax, IFAX Simple Mode and EIFAX > Features shared with G3 fax > > Proof of delivery/receipt > Capability Exchange > Timely Delivery > > Data Format Support > Cover Page and Fax Header > Date and Time Information > Legal Issue > Legal Identity Exchange > Quality of output > > Addressing Support > > Use of Existing Infrastructure > Reliably in the global Internet > > Security > > -------------------- > MAEDA TORU > MIE Development Div. 2 > CANON Inc. > -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 7 05:46:40 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27510 for ; Wed, 7 Feb 2001 05:46:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA23714 for ietf-fax-bks; Wed, 7 Feb 2001 01:55:17 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23704 for ; Wed, 7 Feb 2001 01:55:15 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id TAA19003 for ; Wed, 7 Feb 2001 19:02:37 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma018904; Wed, 7 Feb 01 19:01:53 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id TAA28780 for ; Wed, 7 Feb 2001 19:01:52 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA23848 for ; Wed, 7 Feb 2001 19:01:52 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id TAA26821 for ; Wed, 7 Feb 2001 19:00:54 +0900 (JST) Message-Id: <4.2.0.58.J.20010207184332.00ac9748@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 07 Feb 2001 19:09:52 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: E2E communication over SMTP 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: Hi, forks, I have mailed the goals for Terminal Mode into the mailing list last week. I proposed that the end to end communication over SMTP in the goal. We have been discussed about the store and forward IFAX for long time and developed Simple Mode and EIFAX. My question is why do we need the store and forward system for Internet fax. In case of communication to Email client such as PCs, the existing S&F mailing environment must be used. Since the Terminal Mode IFAX devices will run and will be connected to iternet all time, end to end communication is more practical and more beneficial. I think it will be easy to connect to the receiver by SMTP as end-to-end, when the destination address is the global address instead of the Email address. Any comments? Regards, Toru MAEDA -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 7 06:38:50 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27868 for ; Wed, 7 Feb 2001 06:38:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26824 for ietf-fax-bks; Wed, 7 Feb 2001 02:50:35 -0800 (PST) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26819 for ; Wed, 7 Feb 2001 02:50:32 -0800 (PST) Received: by bulls.mei.co.jp (8.11.1/3.7W) with ESMTP id f17Av8115538; Wed, 7 Feb 2001 19:57:08 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id TAA10722; Wed, 7 Feb 2001 19:57:03 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 7 Feb 2001 10:57:05 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id TAA28506; Wed, 7 Feb 2001 19:57:02 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id TAA19981; Wed, 7 Feb 2001 19:57:02 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id TAA21480; Wed, 7 Feb 2001 19:57:01 +0900 (JST) Message-Id: <200102071058.AA01228@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Wed, 07 Feb 2001 19:58:00 +0900 To: MAEDA toru Cc: ietf-fax@imc.org Subject: Re: E2E communication over SMTP In-Reply-To: <4.2.0.58.J.20010207184332.00ac9748@ffmmail.ffm.canon.co.jp> References: <4.2.0.58.J.20010207184332.00ac9748@ffmmail.ffm.canon.co.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maeda-san, MAEDA toru wrote: >Hi, forks, > >I have mailed the goals for Terminal Mode into the mailing list last week. >I proposed that the end to end communication over SMTP in the goal. >We have been discussed about the store and forward IFAX for long time >and developed Simple Mode and EIFAX. >My question is why do we need the store and forward system for Internet fax. >In case of communication to Email client such as PCs, >the existing S&F mailing environment must be used. >Since the Terminal Mode IFAX devices will run and will be connected to >iternet all time, >end to end communication is more practical and more beneficial. In the most enterprise, fire wall rejects SMTP to the terminal other than mail server. If we want end to end communication in the Internet, we need security policy of fire wall to allow to open the port of SMTP to the IFAX. On the other hand, end to end communication is practical in the Intranet and we can get benefits deifferenet from S&F communicaton. I think that IPP has the same problem and the IFAX which communicate directry between terminals on T.38. If we can solve the problem of fire wall, I prefer terminal mode than T.38 because SMTP protocol is simple and easy to implement. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Wed Feb 7 11:51:53 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03478 for ; Wed, 7 Feb 2001 11:51:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19203 for ietf-fax-bks; Wed, 7 Feb 2001 07:49:15 -0800 (PST) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19192 for ; Wed, 7 Feb 2001 07:49:12 -0800 (PST) Received: from mrelay.jrc.it (localhost [127.0.0.1]) by mrelay.jrc.it (LMC5614B) with ESMTP id f17FuY701741 for ; Wed, 7 Feb 2001 16:56:34 +0100 (MET) Received: from adinms1.jrc.org (adinms1.jrc.org [139.191.10.20]) by mrelay.jrc.it (LMC5614A) with ESMTP id f17FuWs01723 for ; Wed, 7 Feb 2001 16:56:33 +0100 (MET) X-Internal-ID: 3A76EE5D00001C91 Received: from jrc.it (139.191.163.36) by adinms1.jrc.org (NPlex 2.0.108) for ietf-fax@imc.org; 7 Feb 2001 16:56:33 +0100 Message-ID: <3A817013.9A1F101F@jrc.it> Date: Wed, 07 Feb 2001 16:56:03 +0100 From: Monica Merlotti Reply-To: monica.merlotti@jrc.it X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-fax@imc.org Subject: Fax-Sendmail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallo, I need some help. I would like to send a fax to the address: /dd.fax=number@mydomain, but the sendmail (Berkely 8.11), answers to me with the following error msg "550 5.7.1 /dd.fax=number@mydomain.. Cannot mail directly to files". Which configuration option or something like this I have to add to my sendmail to accept msg to /dd.fax=...... Many thanks. Monica Merlotti From owner-ietf-fax@mail.imc.org Wed Feb 7 15:03:16 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07852 for ; Wed, 7 Feb 2001 15:03:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00157 for ietf-fax-bks; Wed, 7 Feb 2001 11:10:17 -0800 (PST) Received: from zeus.faximum.com (IDENT:root@probono.faximum.com [216.232.11.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00153 for ; Wed, 7 Feb 2001 11:10:16 -0800 (PST) Received: from pavilion (atg113jly19mh.bc.hsia.telus.net [216.232.160.209]) by zeus.faximum.com (8.9.3/8.9.3) with SMTP id LAA03515; Wed, 7 Feb 2001 11:17:35 -0800 Message-ID: <00db01c0913a$6d93b020$d1a0e8d8@faximum.com> From: "George Pajari" To: , References: <3A817013.9A1F101F@jrc.it> Subject: Re: Fax-Sendmail Date: Wed, 7 Feb 2001 11:16:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I would like to send a fax to the address: /dd.fax=number@mydomain, but > the sendmail (Berkely 8.11), > answers to me with the following error msg "550 5.7.1 > /dd.fax=number@mydomain.. Cannot mail directly to files". > > Which configuration option or something like this I have to add to my > sendmail to accept msg to /dd.fax=...... Unless sendmail has been configured (in sendmail.cf) to recognise the '/dd.fax' pattern in the local-part of the address it will think you are trying to email to a filename. Of course, not only do you have to configure sendmail.cf to recognise a fax address, you need to provide a delivery agent that will accept the message from sendmail and attempt to deliver it by fax. Sendmail does not come with such a delivery agent but there are commercial (such as ours) and open-source solutions to accomplish this. If you wish to "roll your own" then an excellent place to start is with O'Reilly's definitive book on sendmail (http://www.ora.com/catalog/sendmail2/) which will explain how to configure sendmail to recognise special email addresses and how to interface delivery agents. George Pajari Faximum Software From owner-ietf-fax@mail.imc.org Wed Feb 7 23:13:36 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17295 for ; Wed, 7 Feb 2001 23:13:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21049 for ietf-fax-bks; Wed, 7 Feb 2001 19:13:25 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21045 for ; Wed, 7 Feb 2001 19:13:23 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id MAA21249; Thu, 8 Feb 2001 12:20:20 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma021060; Thu, 8 Feb 01 12:19:57 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id MAA17597; Thu, 8 Feb 2001 12:19:57 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id MAA16291; Thu, 8 Feb 2001 12:19:57 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id MAA08427; Thu, 8 Feb 2001 12:18:58 +0900 (JST) Message-Id: <4.2.0.58.J.20010208121825.00ab60f8@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 08 Feb 2001 12:28:00 +0900 To: "Toyoda, Kiyoshi" From: MAEDA toru Subject: Re: E2E communication over SMTP Cc: ietf-fax@imc.org In-Reply-To: <200102071058.AA01228@d23n59.rdmg.mgcs.mei.co.jp> References: <4.2.0.58.J.20010207184332.00ac9748@ffmmail.ffm.canon.co.jp> <4.2.0.58.J.20010207184332.00ac9748@ffmmail.ffm.canon.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Toyoda-san IPPFAX and T.38 have same problem over firewall. Terminal Mode will also have the same firewall problem too. I am not sure that the firewall problem should be discussed within standardization or deployment. ITU-T did not discuss about it during T.38 standardization. The problem should be asked to the group who has responsible of firewall operation after the standardization. Regards, Toru Maeda At 19:58 01/02/07 +0900, Toyoda, Kiyoshi wrote: >Maeda-san, > >MAEDA toru wrote: > >Hi, forks, > > > >I have mailed the goals for Terminal Mode into the mailing list last week. > >I proposed that the end to end communication over SMTP in the goal. > >We have been discussed about the store and forward IFAX for long time > >and developed Simple Mode and EIFAX. > >My question is why do we need the store and forward system for Internet fax. > >In case of communication to Email client such as PCs, > >the existing S&F mailing environment must be used. > >Since the Terminal Mode IFAX devices will run and will be connected to > >iternet all time, > >end to end communication is more practical and more beneficial. > >In the most enterprise, fire wall rejects SMTP to the terminal other than >mail server. If we want end to end communication in the Internet, we need >security policy of fire wall to allow to open the port of SMTP to the IFAX. >On the other hand, end to end communication is practical in the Intranet >and we can get benefits deifferenet from S&F communicaton. > >I think that IPP has the same problem and the IFAX which communicate directry >between terminals on T.38. If we can solve the problem of fire wall, I >prefer terminal mode than T.38 because SMTP protocol is simple and easy >to implement. > > > >Kiyoshi Toyoda ----------------------------------- $B%-%d%N%s3t<02q; Thu, 8 Feb 2001 03:33:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06116 for ietf-fax-bks; Wed, 7 Feb 2001 23:37:18 -0800 (PST) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06101 for ; Wed, 7 Feb 2001 23:37:15 -0800 (PST) Received: by bulls.mei.co.jp (8.11.1/3.7W) with ESMTP id f187iA104380; Thu, 8 Feb 2001 16:44:10 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id QAA22022; Thu, 8 Feb 2001 16:44:05 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 8 Feb 2001 07:44:07 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id QAA23298; Thu, 8 Feb 2001 16:44:04 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id QAA00374; Thu, 8 Feb 2001 16:44:04 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id QAA20144; Thu, 8 Feb 2001 16:44:03 +0900 (JST) Message-Id: <200102080745.AA01235@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Thu, 08 Feb 2001 16:45:05 +0900 To: MAEDA toru Cc: ietf-fax@imc.org Subject: Re: E2E communication over SMTP In-Reply-To: <4.2.0.58.J.20010208121825.00ab60f8@ffmmail.ffm.canon.co.jp> References: <4.2.0.58.J.20010208121825.00ab60f8@ffmmail.ffm.canon.co.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maeda-san, I comment below. MAEDA toru wrote: >Toyoda-san > >IPPFAX and T.38 have same problem over firewall. >Terminal Mode will also have the same firewall problem too. > >I am not sure that the firewall problem should be discussed within >standardization or deployment. >ITU-T did not discuss about it during T.38 standardization. > >The problem should be asked to the group who has responsible of >firewall operation after the standardization. > I agree. I would like to add terminal mode to new charter if terminal mode has a feature and goals below you said in your e-mail. Maeda-san wrote: > >Also new features are designed such as (1) legal support by fax header or >cover page with sender's ID and Time&date, (2) end to end SMTP session >and (3) One SMTP session for capability exchange/image >transmission/confirmation. > >2. Goals for Terminal Mode >Those are goals for Terminal Mode > >Easy to Implement >Interworking with G3 fax, IFAX Simple Mode and EIFAX >Features shared with G3 fax > >Proof of delivery/receipt >Capability Exchange >Timely Delivery > What idea do you have to interwork with IFAX Simple mode or EIFAX? How about falling back method below? At first, IFAX try to resolve the IP address of the target by DNS. If IFAX can get the IP address, then IFAX communicates with the target directry by terminal mode. If IFAX can not get the IP address, IFAX communicate with the target by Simple mode or EIFAX mode. Regards, Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Thu Feb 8 04:56:51 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03622 for ; Thu, 8 Feb 2001 04:56:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA17504 for ietf-fax-bks; Thu, 8 Feb 2001 01:01:03 -0800 (PST) Received: from elettra.trieste.it (SYNW10.elettra.trieste.it [140.105.2.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA17493 for ; Thu, 8 Feb 2001 01:01:00 -0800 (PST) Date: Thu, 8 Feb 2001 10:07:50 +0100 To: George Pajari cc: monica.merlotti@jrc.it, ietf-fax@imc.org In-Reply-To: <00db01c0913a$6d93b020$d1a0e8d8@faximum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: Fax-Sendmail Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > I would like to send a fax to the address: /dd.fax=number@mydomain, but > > the sendmail (Berkely 8.11), > > answers to me with the following error msg "550 5.7.1 > > /dd.fax=number@mydomain.. Cannot mail directly to files". > > > > Which configuration option or something like this I have to add to my > > sendmail to accept msg to /dd.fax=...... > > Unless sendmail has been configured (in sendmail.cf) to recognise the > '/dd.fax' pattern in the local-part of the address it will think you are > trying to email to a filename. There is also something else, which is fundamentally wrong in the approach: /dd.fax= is NOT the correct syntax for a "GSTN address in e-mail" (this is its official name, including fax numbers, of course). It resembles one of the early stages proposals (also one of my very old s/w prototypes was using it). The correct standard syntax for it is fax=faxnumber@faxgateway-domain where for example: fax=+390403758565@faxgw.something.org is an example, provided that "faxgw.something.org" is an "internet fax machine" following the ietf-fax standards. > Of course, not only do you have to configure sendmail.cf to recognise a fax > address, you need to provide a delivery agent that will accept the message > from sendmail and attempt to deliver it by fax. ... If I remember correctly sendmail.cf rules, the "standard address" fax=fanumeber@faxgateway-domain does not even require any special rule to be recognised. > Sendmail does not come with such a delivery agent but there are commercial > (such as ours) and open-source solutions to accomplish this. Correct! > If you wish to "roll your own" then an excellent place to start is with > O'Reilly's definitive book on sendmail > (http://www.ora.com/catalog/sendmail2/) which will explain how to configure > sendmail to recognise special email addresses and how to interface delivery > agents. exactly. I only add the suggestion to choose an ietf-fax standard compliant agent, if you really wish to deliver a global interworking service to your customers. Regards, Claudio Allocchio From owner-ietf-fax@mail.imc.org Thu Feb 8 05:13:57 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03726 for ; Thu, 8 Feb 2001 05:13:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA20941 for ietf-fax-bks; Thu, 8 Feb 2001 01:22:25 -0800 (PST) Received: from elettra.trieste.it (SYNW10.elettra.trieste.it [140.105.2.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA20928 for ; Thu, 8 Feb 2001 01:22:21 -0800 (PST) Date: Thu, 8 Feb 2001 10:29:30 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Reminder for Upcoming IETF fax WG meeting. Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, our next IETF fax WG meeting is approaching and we woud like to remind you some important issues, as also our ADs are suggesting: - The deadline for draft submission prior to the Minneapolis meeting is 23 February at 5pm EST. - The final IETF Agenda is NOT fixed, yet. As IETF runs from Sunday afternoon until Friday at 12am, we cannot know in advance in which day our WG will meet, it could be in any slot, including early Monday morning or late Friday morning. Please consider this fact when arranging your travel plans. - The meetings are not for technology presentations but rather for face time to resolve outstanding issues. Please submit the new drafts in time to have them discussed on the e-mail list in advance. - The IETF secretariat is asking us to check for milestone dates. It would be useful that, in caso of any change, you advice us in time! See you in Minneapolis! Claudio Allocchio From owner-ietf-fax@mail.imc.org Thu Feb 8 05:52:50 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03943 for ; Thu, 8 Feb 2001 05:52:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA25941 for ietf-fax-bks; Thu, 8 Feb 2001 02:06:28 -0800 (PST) Received: from zeus.faximum.com (IDENT:root@probono.faximum.com [216.232.11.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25936 for ; Thu, 8 Feb 2001 02:06:26 -0800 (PST) Received: from pavilion (atg113jly19mh.bc.hsia.telus.net [216.232.160.209]) by zeus.faximum.com (8.9.3/8.9.3) with SMTP id CAA06021; Thu, 8 Feb 2001 02:13:25 -0800 Message-ID: <006601c091b7$91754bc0$d1a0e8d8@faximum.com> From: "George Pajari" To: "Claudio Allocchio" Cc: , References: Subject: Re: Fax-Sendmail Date: Thu, 8 Feb 2001 02:11:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Claudio: Thank you so much for the clarification. > > Of course, not only do you have to configure sendmail.cf to recognise a fax > > address, you need to provide a delivery agent that will accept the message > > from sendmail and attempt to deliver it by fax. > > ... If I remember correctly sendmail.cf rules, the "standard address" > fax=fanumeber@faxgateway-domain does not even require any special rule to > be recognised. Sorry if I did not make it clear. If faxgateway-domain is NOT running sendmail and presumably knows how to handle addresses of the above form then you are correct. Sendmail servers intermediate between the user and the faxgateway-domain do not need any special rules. If, on the other hand, faxgateway-domain is running sendmail then that sendmail needs to be configured so that it knows the message is to be delivered by a fax delivery agent (which will interprete the fax=faxnumber part) and not to try to deliver it to a local user called "fax=faxnumber". > > Sendmail does not come with such a delivery agent but there are commercial > > (such as ours) and open-source solutions to accomplish this. .... > .... I only add the suggestion to choose an ietf-fax standard > compliant agent, if you really wish to deliver a global interworking > service to your customers. We try, Claudio, we try. From owner-ietf-fax@mail.imc.org Thu Feb 8 06:03:13 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04033 for ; Thu, 8 Feb 2001 06:03:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27425 for ietf-fax-bks; Thu, 8 Feb 2001 02:16:50 -0800 (PST) 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 CAA27420 for ; Thu, 8 Feb 2001 02:16:48 -0800 (PST) Date: Thu, 8 Feb 2001 11:22:47 +0100 To: George Pajari cc: monica.merlotti@jrc.it, ietf-fax@imc.org In-Reply-To: <006601c091b7$91754bc0$d1a0e8d8@faximum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: Fax-Sendmail Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Sorry if I did not make it clear. If faxgateway-domain is NOT running > sendmail and presumably knows how to handle addresses of the above form then > you are correct. Sendmail servers intermediate between the user and the > faxgateway-domain do not need any special rules. > > If, on the other hand, faxgateway-domain is running sendmail then that > sendmail needs to be configured so that it knows the message is to be > delivered by a fax delivery agent (which will interprete the fax=faxnumber > part) and not to try to deliver it to a local user called "fax=faxnumber". Exactly, George! it is a configuration needed only on the offramp gateway, "faxgateway-domain", if it runs sendmail plus the special handling delivery agent for i-fax (or an equivalent stuff for any other MTA type, handling i-fax). :-) Claudio From owner-ietf-fax@mail.imc.org Thu Feb 8 07:36:29 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05282 for ; Thu, 8 Feb 2001 07:36:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06630 for ietf-fax-bks; Thu, 8 Feb 2001 03:48:30 -0800 (PST) Received: from gaia.ohnolab.org ([202.249.37.98]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA06626 for ; Thu, 8 Feb 2001 03:48:28 -0800 (PST) Received: (qmail 16012 invoked from network); 8 Feb 2001 11:55:06 -0000 Received: from localhost.ecs.ohnolab.org (HELO localhost) (127.0.0.1) by localhost.ecs.ohnolab.org with SMTP; 8 Feb 2001 11:55:06 -0000 To: ietf-fax@imc.org Subject: Re: Fax-Sendmail From: Masahiko Kimoto In-Reply-To: <00db01c0913a$6d93b020$d1a0e8d8@faximum.com> References: <3A817013.9A1F101F@jrc.it> <00db01c0913a$6d93b020$d1a0e8d8@faximum.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-fingerprint: DA 63 E3 AD 3F 30 98 05 EB CF 3C 06 2D FF 07 7F X-URL: http://www.ohnolab.org/~kimoto/index.html Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010208205506V.kimoto@ohnolab.org> Date: Thu, 08 Feb 2001 20:55:06 +0900 X-Dispatcher: imput version 20000414(IM141) Lines: 30 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Of course, not only do you have to configure sendmail.cf to recognise a fax > address, you need to provide a delivery agent that will accept the message > from sendmail and attempt to deliver it by fax. > > Sendmail does not come with such a delivery agent but there are commercial > (such as ours) and open-source solutions to accomplish this. # Sorry, but I don't have so much experiences on sendmail. But, as far as I know, "qmail" can accept such addresses easily. Write the following lines in /var/qmail/users/assign +fax=:ifax:60:60:/home/ifax:-:offramp: . and run qmail-newu, /var/qmail/users/cdb will be updated. Then, qmail passes all mails which is sent TO fax=*****@this_server to ~ifax/.qmail-offramp. You can write script name in .qmail-offramp. In the script, just pick up To: header and destination phone number, and process it. This is another solution I think. Regards, --------------------------------------------------------------------------- Masahiko KIMOTO -- http://www.ohnolab.org/~kimoto WIDE Project. Tokyo Institute of Technology. From owner-ietf-fax@mail.imc.org Thu Feb 8 20:01:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22381 for ; Thu, 8 Feb 2001 20:01:44 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA11611 for ietf-fax-bks; Thu, 8 Feb 2001 16:21:58 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA11607 for ; Thu, 8 Feb 2001 16:21:56 -0800 (PST) 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 JAA22819 for ; Fri, 9 Feb 2001 09:21:46 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id JAA09866 for ; Fri, 9 Feb 2001 09:21:45 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id JAA09766 for ; Fri, 9 Feb 2001 09:21:41 +0900 To: ietf-fax@imc.org Subject: Re: Reminder for Upcoming IETF fax WG meeting. In-Reply-To: References: 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: <20010209092810A.tamura@toda.ricoh.co.jp> Date: Fri, 09 Feb 2001 09:28:10 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Addition. > - The deadline for draft submission prior to the Minneapolis > meeting is 23 February at 5pm EST. To be exactly, for -00 draft. March 2, for others. For details, please see http://www.ietf.org/meetings/cutoff_dates_50.html. But, the sooner, the better. > - The final IETF Agenda is NOT fixed, yet. As IETF runs from Sunday afternoon > until Friday at 12am, we cannot know in advance in which day our WG will > meet, it could be in any slot, including early Monday morning or late > Friday morning. Please consider this fact when arranging your travel plans. Claudio, Thank you for taking it. We have to take care of it. > - The meetings are not for technology presentations but rather for face > time to resolve outstanding issues. Please submit the new drafts in time > to have them discussed on the e-mail list in advance. Exactly right. Please discuss in ML. Regards, -- Hiroshi Tamura, Co chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Fri Feb 9 00:22:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27625 for ; Fri, 9 Feb 2001 00:22:41 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id UAA18318 for ietf-fax-bks; Thu, 8 Feb 2001 20:44:44 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA18314 for ; Thu, 8 Feb 2001 20:44:41 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id NAA21309; Fri, 9 Feb 2001 13:44:21 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma020894; Fri, 9 Feb 01 13:43:17 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id NAA13178; Fri, 9 Feb 2001 13:43:17 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id NAA21307; Fri, 9 Feb 2001 13:43:16 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id NAA19969; Fri, 9 Feb 2001 13:42:16 +0900 (JST) Message-Id: <4.2.0.58.J.20010209134522.00a91348@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 09 Feb 2001 13:51:22 +0900 To: "Toyoda, Kiyoshi" From: MAEDA toru Subject: Re: E2E communication over SMTP Cc: ietf-fax@imc.org In-Reply-To: <200102080745.AA01235@d23n59.rdmg.mgcs.mei.co.jp> References: <4.2.0.58.J.20010208121825.00ab60f8@ffmmail.ffm.canon.co.jp> <4.2.0.58.J.20010208121825.00ab60f8@ffmmail.ffm.canon.co.jp> 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: Toyoda-san At 16:45 01/02/08 +0900, Toyoda, Kiyoshi wrote: >What idea do you have to interwork with IFAX Simple mode or EIFAX? >How about falling back method below? Terminal Mode will use TIFF-FX file format, so it will be no problem to send image file to IFAX Simple mode without confirmation nor capabilities exchange. >At first, IFAX try to resolve the IP address of the target by DNS. > > If IFAX can get the IP address, then IFAX communicates with the target > directry by terminal mode. > > If IFAX can not get the IP address, IFAX communicate with the target > by Simple mode or EIFAX mode. Yes, this will be the first step of the protocol in Terminal Mode We should ask SMTP and DNS people that it is possible. Regards, Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Fri Feb 9 00:46:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27983 for ; Fri, 9 Feb 2001 00:46:25 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA18873 for ietf-fax-bks; Thu, 8 Feb 2001 21:11:08 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA18869 for ; Thu, 8 Feb 2001 21:11:06 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id OAA27079 for ; Fri, 9 Feb 2001 14:11:06 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma026891; Fri, 9 Feb 01 14:10:12 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id OAA16500 for ; Fri, 9 Feb 2001 14:10:11 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id OAA26430 for ; Fri, 9 Feb 2001 14:10:11 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id OAA21634 for ; Fri, 9 Feb 2001 14:09:11 +0900 (JST) Message-Id: <4.2.0.58.J.20010209135129.00a900c8@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 09 Feb 2001 14:18:16 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: Extension of SMTP in Terminal Mode 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: Hi, I described the extension of SMTP in the goals for Terminal Mode. (3) One SMTP session for capability exchange/image transmission/confirmation. If the extension is possible, capabilities exchange, image transmission and confirmation will be done in one SMTP session as the classic fax session. Followings are my idea of the extension of SMTP. (1) turn over One of idea is to add turn over mechanism in SMTP. In a SMTP session, the client sends the command and the server responds to the command. Extend SMTP to support the turn over during the SMTP session so that the server sends the command and client responds to the command. (2) polling command The other idea is add optional polling command. The client sends the polling command to get receiver's capabilities and confirmation. The server responds with it's capabilities or confirmation. Are there any idea? Regards, Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Fri Feb 9 01:20:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00070 for ; Fri, 9 Feb 2001 01:20:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA19303 for ietf-fax-bks; Thu, 8 Feb 2001 21:43:52 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA19299 for ; Thu, 8 Feb 2001 21:43:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA13679; Thu, 8 Feb 2001 21:43:04 -0800 (PST) Date: Thu, 8 Feb 2001 21:43:04 -0800 (PST) From: Dan Wing To: MAEDA toru cc: "Toyoda, Kiyoshi" , ietf-fax@imc.org Subject: Re: E2E communication over SMTP In-Reply-To: <4.2.0.58.J.20010209134522.00a91348@ffmmail.ffm.canon.co.jp> Message-ID: <0102082140170.13080-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 9 Feb 2001 13:51 +0900, MAEDA toru wrote: Hi. > >At first, IFAX try to resolve the IP address of the target by DNS. > > > > If IFAX can get the IP address, then IFAX communicates with the target > > directry by terminal mode. > > > > If IFAX can not get the IP address, IFAX communicate with the target > > by Simple mode or EIFAX mode. > > Yes, this will be the first step of the protocol in Terminal Mode > We should ask SMTP and DNS people that it is possible. DNS has supported this functionality for a long time with MX records. Using SRV records, it is possible to provide further refinement beyond MX to help find the correct host. But all this assumes fixed locations for a recipient. This is outdated. Using something like SIP would allow a user to move around and register where they would most like to receive their communications -- video, fax, voicemail, live voice, and email. -Dan Wing From owner-ietf-fax@mail.imc.org Fri Feb 9 01:29:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01176 for ; Fri, 9 Feb 2001 01:29:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA19710 for ietf-fax-bks; Thu, 8 Feb 2001 21:53:22 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA19706 for ; Thu, 8 Feb 2001 21:53:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA14096; Thu, 8 Feb 2001 21:52:46 -0800 (PST) Date: Thu, 8 Feb 2001 21:52:46 -0800 (PST) From: Dan Wing To: MAEDA toru cc: ietf-fax@imc.org Subject: Re: Extension of SMTP in Terminal Mode In-Reply-To: <4.2.0.58.J.20010209135129.00a900c8@ffmmail.ffm.canon.co.jp> Message-ID: <0102082143340.13080-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 9 Feb 2001 14:18 +0900, MAEDA toru wrote: > Hi, > > I described the extension of SMTP in the goals for Terminal Mode. > > (3) One SMTP session for capability exchange/image transmission/confirmation. > > If the extension is possible, capabilities exchange, image transmission and > confirmation > will be done in one SMTP session as the classic fax session. > Followings are my idea of the extension of SMTP. > > (1) turn over > One of idea is to add turn over mechanism in SMTP. > In a SMTP session, the client sends the command and the server responds to > the command. > Extend SMTP to support the turn over during the SMTP session > so that the server sends the command and client responds to the command. Supported today with ETRN, RFC1985. Sendmail, PMDF, and a bunch of other mailers support ETRN: % telnet proxy1.cisco.com 25 220 proxy1.cisco.com ESMTP Sendmail 8.11.2/8.11.2; Thu, 8 Feb 2001 21:46:41 -0800 (PST) ehlo j 250-proxy1.cisco.com Hello omega.cisco.com [171.69.26.42], pleased to meet you 250-ENHANCEDSTATUSCODES 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 250-XUSR 250 HELP > (2) polling command > The other idea is add optional polling command. > The client sends the polling command to get receiver's capabilities and > confirmation. > The server responds with it's capabilities or confirmation. What sort of capabilities are you looking to see? Remember that SMTP is not an end-to-end protocol -- it works hop-by-hop. Examine the "Received:" headers of this email that you're reading. Every "Received:" header is one more SMTP server that has processed the message. Outside of my company, there is no way to determine which IP address actually receives the mail addressed to "dwing@cisco.com". And there is no way to connect directly to my mailer from outside the company. This is by design and is typical of any company's firewalled connectivity to the Internet. SMTP can't be used for _immediate_ delivery of information. For _immediate_ delivery something else must be used. In my experience the delay of email is much less than the delay of fax. It takes about 15-20 seconds to receive one page of fax, including dialed digits, fax modem training speed, transmission time, etc. Email is faster -- this message will be distributed to several hundred recipients mailboxes in far less than 20 seconds. And that includes the time to be processed by several SMTP servers on the way to each recipient's mailbox. -Dan Wing > Are there any idea? > > > Regards, > > Toru Maeda > > > -------------------- > MAEDA TORU > MIE Development Div. 2 > CANON Inc. > -------------------- > From owner-ietf-fax@mail.imc.org Fri Feb 9 02:36:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12233 for ; Fri, 9 Feb 2001 02:36:11 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id WAA21982 for ietf-fax-bks; Thu, 8 Feb 2001 22:58:02 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA21977 for ; Thu, 8 Feb 2001 22:58:00 -0800 (PST) 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 PAA04184; Fri, 9 Feb 2001 15:57:58 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id PAA22532; Fri, 9 Feb 2001 15:57:57 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id PAA12931; Fri, 9 Feb 2001 15:56:41 +0900 To: dwing@cisco.com Cc: maeda.toru@canon.co.jp, ietf-fax@imc.org Subject: Re: Extension of SMTP in Terminal Mode In-Reply-To: <0102082143340.13080-100000@omega.cisco.com> References: <4.2.0.58.J.20010209135129.00a900c8@ffmmail.ffm.canon.co.jp> <0102082143340.13080-100000@omega.cisco.com> 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: <20010209160311I.tamura@toda.ricoh.co.jp> Date: Fri, 09 Feb 2001 16:03:11 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 48 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan, At first, I would like to say, I neither support his ideas nor oppose it. > > (2) polling command > > The other idea is add optional polling command. > > The client sends the polling command to get receiver's capabilities and > > confirmation. > > The server responds with it's capabilities or confirmation. > > What sort of capabilities are you looking to see? Remember that SMTP > is not an end-to-end protocol -- it works hop-by-hop. Examine the > "Received:" headers of this email that you're reading. Every > "Received:" header is one more SMTP server that has processed the > message. I think Maeda-san wants to use SMTP as end-to-end communication, not as hop by hop. A sender(he) DIRECTLY connects to a receiver(her). I.e, he specfies her IP address and her port number 25 and connects to her(connect() in socket). She accepts it(bind(), listen(), accept()). > SMTP can't be used for _immediate_ delivery of information. For > _immediate_ delivery something else must be used. Personally, I think so, now. Like T.38. But T.38 syntax is a little diffcult, so, some people do not like it. This is one of the background in his idea, I think. Am I right? Maeda-san. Anyway, as a co-chair, I keep watching this thread. > In my experience the delay of email is much less than the delay of fax. > It takes about 15-20 seconds to receive one page of fax, including dialed > digits, fax modem training speed, transmission time, etc. Email is faster > -- this message will be distributed to several hundred recipients > mailboxes in far less than 20 seconds. And that includes the time to > be processed by several SMTP servers on the way to each recipient's > mailbox. Oh, Timely delivery may be useful! If so, Delivered by how many minutes is effective? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Fri Feb 9 12:17:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24285 for ; Fri, 9 Feb 2001 12:17:23 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA17933 for ietf-fax-bks; Fri, 9 Feb 2001 08:29:49 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17928 for ; Fri, 9 Feb 2001 08:29:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA12159; Fri, 9 Feb 2001 08:28:48 -0800 (PST) Date: Fri, 9 Feb 2001 08:28:48 -0800 (PST) From: Dan Wing To: Hiroshi Tamura cc: maeda.toru@canon.co.jp, ietf-fax@imc.org Subject: Re: Extension of SMTP in Terminal Mode In-Reply-To: <20010209160311I.tamura@toda.ricoh.co.jp> Message-ID: <0102090826490.10654-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 9 Feb 2001 16:03 +0900, Hiroshi Tamura wrote: > Dan, > > At first, I would like to say, > I neither support his ideas nor oppose it. > > > > (2) polling command > > > The other idea is add optional polling command. > > > The client sends the polling command to get receiver's capabilities and > > > confirmation. > > > The server responds with it's capabilities or confirmation. > > > > What sort of capabilities are you looking to see? Remember that SMTP > > is not an end-to-end protocol -- it works hop-by-hop. Examine the > > "Received:" headers of this email that you're reading. Every > > "Received:" header is one more SMTP server that has processed the > > message. > > I think Maeda-san wants to use SMTP as end-to-end communication, > not as hop by hop. A sender(he) DIRECTLY connects to a receiver(her). I.e, > he specfies her IP address and her port number 25 and connects > to her(connect() in socket). She accepts it(bind(), listen(), accept()). Yes, I agree that is Maeda-san's proposal. > > SMTP can't be used for _immediate_ delivery of information. For > > _immediate_ delivery something else must be used. > > Personally, I think so, now. Like T.38. But T.38 syntax is a little > diffcult, so, some people do not like it. This is one of the background > in his idea, I think. Am I right? Maeda-san. > > Anyway, as a co-chair, > I keep watching this thread. > > > In my experience the delay of email is much less than the delay of fax. > > It takes about 15-20 seconds to receive one page of fax, including dialed > > digits, fax modem training speed, transmission time, etc. Email is faster > > -- this message will be distributed to several hundred recipients > > mailboxes in far less than 20 seconds. And that includes the time to > > be processed by several SMTP servers on the way to each recipient's > > mailbox. > > Oh, Timely delivery may be useful! > If so, Delivered by how many minutes is effective? The sender should decide how many minutes of delay is acceptable. The existing DELIVER BY extension is quite useful for this - RFC2852. -d From owner-ietf-fax@mail.imc.org Fri Feb 9 13:41:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28164 for ; Fri, 9 Feb 2001 13:41:30 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA23142 for ietf-fax-bks; Fri, 9 Feb 2001 10:05:56 -0800 (PST) Received: from apollo.mctr.umbc.edu (apollo.mctr.umbc.edu [130.85.101.89]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23137 for ; Fri, 9 Feb 2001 10:05:55 -0800 (PST) Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA10875; Fri, 9 Feb 2001 13:05:52 -0500 (EST) Received: from localhost (umang@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id NAA10357; Fri, 9 Feb 2001 13:12:08 -0500 (EST) X-Authentication-Warning: mercury.mctr.umbc.edu: umang owned process doing -bs Date: Fri, 9 Feb 2001 13:12:07 -0500 (EST) From: Umang Choudhary X-Sender: umang@mercury.mctr.umbc.edu To: ietf-fax@imc.org cc: jfmule@clarent.com Subject: Question on SIP/T.38 call flow mapping Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I have a question on SIP/T.38 call flow mapping. The draft SIP T.38 call flow examples and Best Current Practices uses SIP to do call signalling for a T.38 fax call. It addresses the SIP exchanges needed for initial call setup, when a CED/Preamble or end of fax tone is detected. Does this mean that all the other T.38 messages like DIS, DCS, CFR/FTT, MPS, etc. should be transmitted without using SIP, although they are not actual fax images? Is there any draft/paper that might address these issues. Thanks, Umang Choudhary University of Maryland, Baltimore County From owner-ietf-fax@mail.imc.org Sat Feb 10 10:43:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26237 for ; Sat, 10 Feb 2001 10:43:28 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA05725 for ietf-fax-bks; Sat, 10 Feb 2001 07:08:18 -0800 (PST) Received: from sniffout.com ([62.209.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA05720 for ; Sat, 10 Feb 2001 07:08:17 -0800 (PST) Received: from GK-VAIO.ninebynine.org ([62.209.135.73]) by sniffout.com with Microsoft SMTPSVC(5.5.1877.977.9); Sat, 10 Feb 2001 15:08:18 +0000 Message-Id: <5.0.2.1.2.20010210142557.00a7a0a0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 10 Feb 2001 14:28:55 +0000 To: Dan Wing From: Graham Klyne Subject: Re: Extension of SMTP in Terminal Mode Cc: Hiroshi Tamura , maeda.toru@canon.co.jp, ietf-fax@imc.org In-Reply-To: <0102090826490.10654-100000@omega.cisco.com> References: <20010209160311I.tamura@toda.ricoh.co.jp> 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 08:28 AM 2/9/01 -0800, Dan Wing wrote: >The sender should decide how many minutes of delay is acceptable. The >existing DELIVER BY extension is quite useful for this - RFC2852. The timely delivery for fax proposal draft has just been updated. In this latest version, it extends the DELIVERBY mechanism of RFC2852, and DSN, to provide a deterministic framework for timely message delivery, including confirmation. The new I-D has been submitted, and should be announced very soon. #g ------------------------------------------------------------ Graham Klyne Baltimore Technologies Strategic Research Content Security Group ------------------------------------------------------------ From owner-ietf-fax@mail.imc.org Mon Feb 12 07:59:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04804 for ; Mon, 12 Feb 2001 07:59:31 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA21514 for ietf-fax-bks; Mon, 12 Feb 2001 04:22:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA21506 for ; Mon, 12 Feb 2001 04:22:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04214; Mon, 12 Feb 2001 07:22:09 -0500 (EST) Message-Id: <200102121222.HAA04214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-timely-delivery-02.txt Date: Mon, 12 Feb 2001 07:22:08 -0500 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Timely Delivery for Internet Messaging Services Author(s) : G. Klyne, D. Crocker Filename : draft-ietf-fax-timely-delivery-02.txt Pages : 38 Date : 09-Feb-01 This proposal describes a way to request timely completion for Internet email, for services such as facsimile and voice messaging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-timely-delivery-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-timely-delivery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-timely-delivery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010209142958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-timely-delivery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-timely-delivery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209142958.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Mon Feb 12 10:31:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10729 for ; Mon, 12 Feb 2001 10:31:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA29645 for ietf-fax-bks; Mon, 12 Feb 2001 06:48:23 -0800 (PST) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA29639 for ; Mon, 12 Feb 2001 06:48:21 -0800 (PST) Date: Mon, 12 Feb 2001 15:47:54 +0100 To: ietf-fax@imc.org cc: Hiroshi Tamura Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="=====================_2057109==_.ALT" Content-ID: From: Claudio Allocchio Subject: 50th IETF -FAX meeting (fwd) 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. --=====================_2057109==_.ALT Content-Type: TEXT/PLAIN; CHARSET=us-ascii; FORMAT=flowed Content-ID: >From: Dinara Suleymanova >To: Claudio.Allocchio@garr.it, tamura@toda.ricoh.co.jp >Subject: 50th IETF -FAX meeting > >Hello, > >FAX meeting has been tentatively scheduled for ONE session. > >Please check and see the Draft Agenda (which can be changed by February 26) >of the 50th IETF Meeting at : http://www.ietf.org/meetings/agenda_50.txt Currently our slot is MONDAY, 19th March 2001 - 19.30 - 22.00 Evening Session. As announced, please note that this is NOT the final agenda, thus it could still be changed until Feb 26th. In the given URL you can also see the schedule of other WGs With this slot we do not conflict with any of the WGs, BOFs you suggested. We will let you know if there is any change! Regards, Claudio Allocchio --=====================_2057109==_.ALT-- From owner-ietf-fax@mail.imc.org Tue Feb 13 07:01:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15701 for ; Tue, 13 Feb 2001 07:01:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id DAA22216 for ietf-fax-bks; Tue, 13 Feb 2001 03:22:09 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA22212 for ; Tue, 13 Feb 2001 03:22:07 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id UAA15003; Tue, 13 Feb 2001 20:22:01 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma014924; Tue, 13 Feb 01 20:21:11 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id UAA28452; Tue, 13 Feb 2001 20:21:11 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id UAA21896; Tue, 13 Feb 2001 20:21:11 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id UAA04353; Tue, 13 Feb 2001 20:20:06 +0900 (JST) Message-Id: <4.2.0.58.J.20010213200903.00a7cea8@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 13 Feb 2001 20:29:25 +0900 To: Hiroshi Tamura , dwing@cisco.com From: MAEDA toru Subject: Re: Extension of SMTP in Terminal Mode Cc: ietf-fax@imc.org In-Reply-To: <20010209160311I.tamura@toda.ricoh.co.jp> References: <0102082143340.13080-100000@omega.cisco.com> <4.2.0.58.J.20010209135129.00a900c8@ffmmail.ffm.canon.co.jp> <0102082143340.13080-100000@omega.cisco.com> 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: Tamura-san Thank you very much for clarification about my idea. The extension of SMTP in Terminal Moden is based on the end-to-end SMTP communication which I proposed in the previous mail. At 16:03 01/02/09 +0900, Hiroshi Tamura wrote: >Dan, > >At first, I would like to say, >I neither support his ideas nor oppose it. > > > > (2) polling command > > > The other idea is add optional polling command. > > > The client sends the polling command to get receiver's capabilities and > > > confirmation. > > > The server responds with it's capabilities or confirmation. > > > > What sort of capabilities are you looking to see? Remember that SMTP > > is not an end-to-end protocol -- it works hop-by-hop. Examine the > > "Received:" headers of this email that you're reading. Every > > "Received:" header is one more SMTP server that has processed the > > message. > >I think Maeda-san wants to use SMTP as end-to-end communication, >not as hop by hop. A sender(he) DIRECTLY connects to a receiver(her). I.e, >he specfies her IP address and her port number 25 and connects >to her(connect() in socket). She accepts it(bind(), listen(), accept()). Thank you, I wanted mean this. > > SMTP can't be used for _immediate_ delivery of information. For > > _immediate_ delivery something else must be used. > >Personally, I think so, now. Like T.38. But T.38 syntax is a little >diffcult, so, some people do not like it. This is one of the background >in his idea, I think. Am I right? Maeda-san. T.38 has another difficulty on the delay of Internet. Response timers in SMTP is longer than T.30 timer (T4 3.0+-15%). >Anyway, as a co-chair, >I keep watching this thread. > > > In my experience the delay of email is much less than the delay of fax. > > It takes about 15-20 seconds to receive one page of fax, including dialed > > digits, fax modem training speed, transmission time, etc. Email is faster > > -- this message will be distributed to several hundred recipients > > mailboxes in far less than 20 seconds. And that includes the time to > > be processed by several SMTP servers on the way to each recipient's > > mailbox. > >Oh, Timely delivery may be useful! >If so, Delivered by how many minutes is effective? Objectives of E2E SMTP communication and the extension of SMTP are to support one fax session over SMTP without S&F. When end-to-end SMTP communication is supported, Timely delivery may not be required. Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Tue Feb 13 12:04:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24340 for ; Tue, 13 Feb 2001 12:04:59 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA15634 for ietf-fax-bks; Tue, 13 Feb 2001 08:17:54 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA15629 for ; Tue, 13 Feb 2001 08:17:52 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA11022; Tue, 13 Feb 2001 08:15:19 -0800 (PST) Date: Tue, 13 Feb 2001 08:15:19 -0800 (PST) From: Dan Wing To: MAEDA toru cc: Hiroshi Tamura , ietf-fax@imc.org Subject: Re: Extension of SMTP in Terminal Mode In-Reply-To: <4.2.0.58.J.20010213200903.00a7cea8@ffmmail.ffm.canon.co.jp> Message-ID: <0102130813380.18478-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 13 Feb 2001 20:29 +0900, MAEDA toru wrote: > >Personally, I think so, now. Like T.38. But T.38 syntax is a little > >diffcult, so, some people do not like it. This is one of the background > >in his idea, I think. Am I right? Maeda-san. > > T.38 has another difficulty on the delay of Internet. > Response timers in SMTP is longer than T.30 timer (T4 3.0+-15%). > > > >Anyway, as a co-chair, > >I keep watching this thread. > > > > > In my experience the delay of email is much less than the delay of fax. > > > It takes about 15-20 seconds to receive one page of fax, including dialed > > > digits, fax modem training speed, transmission time, etc. Email is faster > > > -- this message will be distributed to several hundred recipients > > > mailboxes in far less than 20 seconds. And that includes the time to > > > be processed by several SMTP servers on the way to each recipient's > > > mailbox. > > > >Oh, Timely delivery may be useful! > >If so, Delivered by how many minutes is effective? > > Objectives of E2E SMTP communication and the extension of SMTP are > to support one fax session over SMTP without S&F. > When end-to-end SMTP communication is supported, Timely delivery may not be > required. SMTP won't solve the delay and jitter sensitivity of T.30 timers, though. In fact, it would be more sensitive to delay and jitter than T.38 because TCP is slower to recover from network-induced jitter. -Dan Wing From owner-ietf-fax@mail.imc.org Tue Feb 13 12:39:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25389 for ; Tue, 13 Feb 2001 12:39:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA18246 for ietf-fax-bks; Tue, 13 Feb 2001 09:04:20 -0800 (PST) Received: from sniffout.com ([62.209.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA18242 for ; Tue, 13 Feb 2001 09:04:19 -0800 (PST) Received: from GK-VAIO.NineByNine.org ([62.209.136.24]) by sniffout.com with Microsoft SMTPSVC(5.5.1877.977.9); Tue, 13 Feb 2001 17:04:18 +0000 Message-Id: <5.0.2.1.2.20010213155656.041d8850@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 13 Feb 2001 16:04:11 +0000 To: Hiroshi Tamura From: Graham Klyne Subject: Re: draft-ietf-fax-timely-delivery-01.txt Cc: ietf-fax@imc.org In-Reply-To: <20001204143251Z.tamura@toda.ricoh.co.jp> 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: Tamura-san, This is mainly to acknowledge your comments, which were made a long time ago now, but not forgotten or ignored. I did use your comments when editing the -02 draft. There was a lot of change to make the latest (-02) version, and I think that most of your comments are indirectly incorporated. At 02:32 PM 12/4/00 +0900, Hiroshi Tamura wrote: >Personal comments. > >There are mainly two pending issues, I think. >Section 4 "Compliance-required ESMTP extension" and >Section 5 "DSN extension". > >The Key issue is Compliance-required(section 4). >If my undestanding is correct, this must be dealt with UA >like POP/IMAP4 device. If so, how about considering the time >interval by POP/IMAP4 device? > >If the thing that comforms to timely delivery is a POP/IMAP4 device >and I-fax device, is it possible to recommend the short interval time? >Specific value is difficult to define, but, I think the value >for guidance can be described like Section 3.4(Timely confirmation). >If it is the I-fax device(not PC mailer software), it runs 24-hours. >It may be feasible. > >This is just at idea level. The various extensions have been folded into an enhancement of the "Deliver by" proposal, and some small extensions to the DSN report format. I think the receiver timing issue is covered by saying that report must be sent before the deliver-by time expires. >The next is DSN extension(section 5). >Yes, it would be better to have the extension. But, we can use >the existing definitions. There are "delayed" action-value >with status code 4.4.7 and "failed" with 5.4.7, which are >written in section 4.1.3 of RFC2852. There are other dscriptions. Well, I've proposed some specific extensions -- I guess we'll see how they go down. >Also, how about separating requirement parts and guidance parts? >For example, Section 3.4(Timely confirmation) is for guidance. I've rearranged this material, but I did think it was important to say something about timing in the normative sections. >Minimum requirements should be decided, but, it is no problems >that the rests are guidances or implementation issues, I think. >Because, there are some items that are difficult to solve completely. Yes. I think that's what the latest version tries to do. >I hope it helps you. Thank you, yes, it did. #g From owner-ietf-fax@mail.imc.org Tue Feb 13 13:43:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27134 for ; Tue, 13 Feb 2001 13:43:37 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA21457 for ietf-fax-bks; Tue, 13 Feb 2001 09:59:58 -0800 (PST) Received: from galadrial.creativeonline.com (mail.creativeonline.com [204.141.213.133]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA21450 for ; Tue, 13 Feb 2001 09:59:56 -0800 (PST) Received: from [192.168.1.2] ([24.188.201.177]) by galadrial.creativeonline.com (Post.Office MTA v3.1 release PO205e ID# LEGENDS-1997LS) with ESMTP id AAA112; Tue, 13 Feb 2001 13:14:53 -0500 Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <200102071058.AA01228@d23n59.rdmg.mgcs.mei.co.jp> References: <4.2.0.58.J.20010207184332.00ac9748@ffmmail.ffm.canon.co.jp> <200102071058.AA01228@d23n59.rdmg.mgcs.mei.co.jp> X-Mailer: Eudora Pro 5.0.1 PPC (Macintosh) Date: Tue, 13 Feb 2001 12:36:33 -0500 To: "Toyoda, Kiyoshi" From: "Robert A. Rosenberg" Subject: Re: E2E communication over SMTP Cc: MAEDA toru , ietf-fax@imc.org 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 19:58 +0900 on 02/07/2001, Toyoda, Kiyoshi wrote about Re: E2E communication over SMTP: >In the most enterprise, fire wall rejects SMTP to the terminal other than >mail server. If we want end to end communication in the Internet, we need >security policy of fire wall to allow to open the port of SMTP to the IFAX. One solution to this problem might be to define a Well Known Port Number for incoming E2E IFAX devices (Just like there already is a SMTP port [547?] for Mail Submission Agents [MUA-to-SMTP] that can be used in lieu of Port 25 to inject new mail as opposed to forward mail from MTA to MTA). This port number can be opened in the Firewall by listing the device as a IFAX Server just like the SMTP Servers are currently listed as Port 25 authorized. From owner-ietf-fax@mail.imc.org Tue Feb 13 21:44:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05637 for ; Tue, 13 Feb 2001 21:44:43 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA19300 for ietf-fax-bks; Tue, 13 Feb 2001 18:14:26 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19296 for ; Tue, 13 Feb 2001 18:14:23 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA29718; Tue, 13 Feb 2001 18:13:32 -0800 (PST) Date: Tue, 13 Feb 2001 18:13:32 -0800 (PST) From: Dan Wing To: "Robert A. Rosenberg" cc: "Toyoda, Kiyoshi" , MAEDA toru , ietf-fax@imc.org Subject: E2E requirements In-Reply-To: Message-ID: <0102131807270.18360-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 13 Feb 2001 12:36 -0500, Robert A. Rosenberg wrote: > At 19:58 +0900 on 02/07/2001, Toyoda, Kiyoshi wrote about Re: E2E > communication over SMTP: > > >In the most enterprise, fire wall rejects SMTP to the terminal other than > >mail server. If we want end to end communication in the Internet, we need > >security policy of fire wall to allow to open the port of SMTP to the IFAX. > > One solution to this problem might be to define a Well Known Port > Number for incoming E2E IFAX devices (Just like there already is a > SMTP port [547?] for Mail Submission Agents [MUA-to-SMTP] that can be > used in lieu of Port 25 to inject new mail as opposed to forward mail > from MTA to MTA). This port number can be opened in the Firewall by > listing the device as a IFAX Server just like the SMTP Servers are > currently listed as Port 25 authorized. Let's examine the requirements that I believe we're trying to meet. If we could get agreement on these we can look at technologies to solve all the requirements. I believe the requirements which aren't currently solved with RFC2305 and RFC2532 are: * absolutely guaranteed delivery receipts with functionality identical to PSTN-based fax delivery receipts * immediate delivery Comments? We can define "immediate" in a few days. As we all know, nothing is immediate and physics says that there isn't such a thing as an "explosion", either -- just a fast burn. -d From owner-ietf-fax@mail.imc.org Tue Feb 13 21:47:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05648 for ; Tue, 13 Feb 2001 21:47:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA19154 for ietf-fax-bks; Tue, 13 Feb 2001 18:07:40 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19148 for ; Tue, 13 Feb 2001 18:07:39 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA25902; Tue, 13 Feb 2001 18:06:28 -0800 (PST) Date: Tue, 13 Feb 2001 18:06:28 -0800 (PST) From: Dan Wing To: MAEDA toru cc: Hiroshi Tamura , ietf-fax@imc.org Subject: Re: Extension of SMTP in Terminal Mode In-Reply-To: <4.2.0.58.J.20010213200903.00a7cea8@ffmmail.ffm.canon.co.jp> Message-ID: <0102131757490.18360-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I had an offline discussion with George Pajari and he helped me understand your proposal better. I believe there are several scenarios that are possible with this end-to-end proposal [view with fixed-width font]: 1) scanner -> ifax ------------> ifax -> printer ^ ^ SMTP 2) scanner -> fax -> PSTN -> ifax -----------> ifax -> printer ^ ^ SMTP 3) scanner -> ifax ------------> ifax -> PSTN -> fax -> printer ^ ^ SMTP 4) scanner -> fax -> PSTN -> ifax --------> ifax -> PSTN -> fax -> printer ^ ^ SMTP I believe that only (1) is useful. Any of (2), (3), or (4) would have the same jitter and delay sensitivity as T.38 itself. SMTP may well be easier to implement than T.38, but using SMTP doesn't avoid the jitter and delay sensitivity problems in scenario (2), (3), or (4), above. So, if we constrain the problem to (1), I think this WG can address it. In fact, I believe it can be done using existing SMTP technologies and without inventing anything new, AND provide all the necessary guarantees for a real delivery receipt. -d On Tue, 13 Feb 2001 20:29 +0900, MAEDA toru wrote: > Tamura-san > > Thank you very much for clarification about my idea. > The extension of SMTP in Terminal Moden is based on the end-to-end SMTP > communication > which I proposed in the previous mail. > > > At 16:03 01/02/09 +0900, Hiroshi Tamura wrote: > >Dan, > > > >At first, I would like to say, > >I neither support his ideas nor oppose it. > > > > > > (2) polling command > > > > The other idea is add optional polling command. > > > > The client sends the polling command to get receiver's capabilities and > > > > confirmation. > > > > The server responds with it's capabilities or confirmation. > > > > > > What sort of capabilities are you looking to see? Remember that SMTP > > > is not an end-to-end protocol -- it works hop-by-hop. Examine the > > > "Received:" headers of this email that you're reading. Every > > > "Received:" header is one more SMTP server that has processed the > > > message. > > > >I think Maeda-san wants to use SMTP as end-to-end communication, > >not as hop by hop. A sender(he) DIRECTLY connects to a receiver(her). I.e, > >he specfies her IP address and her port number 25 and connects > >to her(connect() in socket). She accepts it(bind(), listen(), accept()). > > Thank you, I wanted mean this. > > > > > SMTP can't be used for _immediate_ delivery of information. For > > > _immediate_ delivery something else must be used. > > > >Personally, I think so, now. Like T.38. But T.38 syntax is a little > >diffcult, so, some people do not like it. This is one of the background > >in his idea, I think. Am I right? Maeda-san. > > T.38 has another difficulty on the delay of Internet. > Response timers in SMTP is longer than T.30 timer (T4 3.0+-15%). > > > >Anyway, as a co-chair, > >I keep watching this thread. > > > > > In my experience the delay of email is much less than the delay of fax. > > > It takes about 15-20 seconds to receive one page of fax, including dialed > > > digits, fax modem training speed, transmission time, etc. Email is faster > > > -- this message will be distributed to several hundred recipients > > > mailboxes in far less than 20 seconds. And that includes the time to > > > be processed by several SMTP servers on the way to each recipient's > > > mailbox. > > > >Oh, Timely delivery may be useful! > >If so, Delivered by how many minutes is effective? > > Objectives of E2E SMTP communication and the extension of SMTP are > to support one fax session over SMTP without S&F. > When end-to-end SMTP communication is supported, Timely delivery may not be > required. > > Toru Maeda > > > -------------------- > MAEDA TORU > MIE Development Div. 2 > CANON Inc. > -------------------- > From owner-ietf-fax@mail.imc.org Tue Feb 13 22:13:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05839 for ; Tue, 13 Feb 2001 22:13:39 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA19856 for ietf-fax-bks; Tue, 13 Feb 2001 18:37:28 -0800 (PST) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA19852 for ; Tue, 13 Feb 2001 18:37:24 -0800 (PST) Received: by bulls.mei.co.jp (8.11.1/3.7W) with ESMTP id f1E2adv17349; Wed, 14 Feb 2001 11:36:39 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id LAA19599; Wed, 14 Feb 2001 11:36:30 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 14 Feb 2001 02:36:31 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id LAA03403; Wed, 14 Feb 2001 11:36:28 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id LAA13121; Wed, 14 Feb 2001 11:36:28 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id LAA08698; Wed, 14 Feb 2001 11:36:25 +0900 (JST) Message-Id: <200102140237.AA01241@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Wed, 14 Feb 2001 11:37:38 +0900 To: "Robert A. Rosenberg" Cc: MAEDA toru , ietf-fax@imc.org Subject: Re: E2E communication over SMTP In-Reply-To: References: MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert A. Rosenberg wrote: >At 19:58 +0900 on 02/07/2001, Toyoda, Kiyoshi wrote about Re: E2E >communication over SMTP: > >>In the most enterprise, fire wall rejects SMTP to the terminal other than >>mail server. If we want end to end communication in the Internet, we need >>security policy of fire wall to allow to open the port of SMTP to the IFAX. > >One solution to this problem might be to define a Well Known Port >Number for incoming E2E IFAX devices (Just like there already is a >SMTP port [547?] for Mail Submission Agents [MUA-to-SMTP] that can be >used in lieu of Port 25 to inject new mail as opposed to forward mail >from MTA to MTA). This port number can be opened in the Firewall by >listing the device as a IFAX Server just like the SMTP Servers are >currently listed as Port 25 authorized. > If the port number can be opened in the Firewall at both sending side and receiving side, IFAX can communicate. Registering IFAX to MX record on DNS server also realize direct communication of IFAX. But I'm afraid how many Manager of Information System devision allow it. If we certify that IFAX has no security hole, they may allow it. Maybe we can certify it because IFAX only has limited function for IFAX communication. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Tue Feb 13 23:10:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07346 for ; Tue, 13 Feb 2001 23:10:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA21914 for ietf-fax-bks; Tue, 13 Feb 2001 19:25:37 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA21909 for ; Tue, 13 Feb 2001 19:25:35 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id MAA14026; Wed, 14 Feb 2001 12:25:29 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma013928; Wed, 14 Feb 01 12:24:27 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id MAA14297; Wed, 14 Feb 2001 12:24:26 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id MAA04995; Wed, 14 Feb 2001 12:24:26 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id MAA14069; Wed, 14 Feb 2001 12:23:20 +0900 (JST) Message-Id: <4.2.0.58.J.20010214122518.00a7e2a8@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 14 Feb 2001 12:32:43 +0900 To: Dan Wing From: MAEDA toru Subject: Re: Extension of SMTP in Terminal Mode Cc: Hiroshi Tamura , ietf-fax@imc.org In-Reply-To: <0102131757490.18360-100000@omega.cisco.com> References: <4.2.0.58.J.20010213200903.00a7cea8@ffmmail.ffm.canon.co.jp> 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: Wing-san Thank you very much for clarification of my idea. 2), 3) and 4) are the gate way function of T.38. 1) is the target of Terminal Mode which communicates end-to-end as fax terminals. At 18:06 01/02/13 -0800, Dan Wing wrote: >I had an offline discussion with George Pajari and he helped me understand >your proposal better. > >I believe there are several scenarios that are possible with this >end-to-end proposal [view with fixed-width font]: > > >1) > > scanner -> ifax ------------> ifax -> printer > ^ > ^ > SMTP > > >2) > > scanner -> fax -> PSTN -> ifax -----------> ifax -> printer > ^ > ^ > SMTP > > >3) > > scanner -> ifax ------------> ifax -> PSTN -> fax -> printer > ^ > ^ > SMTP > > >4) > > scanner -> fax -> PSTN -> ifax --------> ifax -> PSTN -> fax -> printer > ^ > ^ > SMTP > > > >I believe that only (1) is useful. Any of (2), (3), or (4) would have the >same jitter and delay sensitivity as T.38 itself. SMTP may well be easier >to implement than T.38, but using SMTP doesn't avoid the jitter and delay >sensitivity problems in scenario (2), (3), or (4), above. > > >So, if we constrain the problem to (1), I think this WG can address it. >In fact, I believe it can be done using existing SMTP technologies and >without inventing anything new, AND provide all the necessary guarantees >for a real delivery receipt. > >-d > > >On Tue, 13 Feb 2001 20:29 +0900, MAEDA toru wrote: > > > Tamura-san > > > > Thank you very much for clarification about my idea. > > The extension of SMTP in Terminal Moden is based on the end-to-end SMTP > > communication > > which I proposed in the previous mail. > > > > > > At 16:03 01/02/09 +0900, Hiroshi Tamura wrote: > > >Dan, > > > > > >At first, I would like to say, > > >I neither support his ideas nor oppose it. > > > > > > > > (2) polling command > > > > > The other idea is add optional polling command. > > > > > The client sends the polling command to get receiver's > capabilities and > > > > > confirmation. > > > > > The server responds with it's capabilities or confirmation. > > > > > > > > What sort of capabilities are you looking to see? Remember that SMTP > > > > is not an end-to-end protocol -- it works hop-by-hop. Examine the > > > > "Received:" headers of this email that you're reading. Every > > > > "Received:" header is one more SMTP server that has processed the > > > > message. > > > > > >I think Maeda-san wants to use SMTP as end-to-end communication, > > >not as hop by hop. A sender(he) DIRECTLY connects to a receiver(her). I.e, > > >he specfies her IP address and her port number 25 and connects > > >to her(connect() in socket). She accepts it(bind(), listen(), accept()). > > > > Thank you, I wanted mean this. > > > > > > > > SMTP can't be used for _immediate_ delivery of information. For > > > > _immediate_ delivery something else must be used. > > > > > >Personally, I think so, now. Like T.38. But T.38 syntax is a little > > >diffcult, so, some people do not like it. This is one of the background > > >in his idea, I think. Am I right? Maeda-san. > > > > T.38 has another difficulty on the delay of Internet. > > Response timers in SMTP is longer than T.30 timer (T4 3.0+-15%). > > > > > > >Anyway, as a co-chair, > > >I keep watching this thread. > > > > > > > In my experience the delay of email is much less than the delay of fax. > > > > It takes about 15-20 seconds to receive one page of fax, including > dialed > > > > digits, fax modem training speed, transmission time, etc. Email is > faster > > > > -- this message will be distributed to several hundred recipients > > > > mailboxes in far less than 20 seconds. And that includes the time to > > > > be processed by several SMTP servers on the way to each recipient's > > > > mailbox. > > > > > >Oh, Timely delivery may be useful! > > >If so, Delivered by how many minutes is effective? > > > > Objectives of E2E SMTP communication and the extension of SMTP are > > to support one fax session over SMTP without S&F. > > When end-to-end SMTP communication is supported, Timely delivery may > not be > > required. > > > > Toru Maeda > > > > > > -------------------- > > MAEDA TORU > > MIE Development Div. 2 > > CANON Inc. > > -------------------- > > -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 14 03:16:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24779 for ; Wed, 14 Feb 2001 03:16:39 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id XAA06593 for ietf-fax-bks; Tue, 13 Feb 2001 23:35:08 -0800 (PST) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA06578 for ; Tue, 13 Feb 2001 23:35:04 -0800 (PST) Received: by bulls.mei.co.jp (8.11.1/3.7W) with ESMTP id f1E7Y1v16145; Wed, 14 Feb 2001 16:34:02 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id QAA12947; Wed, 14 Feb 2001 16:33:51 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 14 Feb 2001 07:33:53 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id QAA22752; Wed, 14 Feb 2001 16:33:47 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id QAA03106; Wed, 14 Feb 2001 16:33:46 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id QAA06989; Wed, 14 Feb 2001 16:33:46 +0900 (JST) Message-Id: <200102140735.AA01242@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Wed, 14 Feb 2001 16:35:00 +0900 To: Dan Wing Cc: "Robert A. Rosenberg" , MAEDA toru , ietf-fax@imc.org Subject: Re: E2E requirements In-Reply-To: <0102131807270.18360-100000@omega.cisco.com> References: <0102131807270.18360-100000@omega.cisco.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Wing wrote: >Let's examine the requirements that I believe we're trying to meet. > >If we could get agreement on these we can look at technologies to >solve all the requirements. > >I believe the requirements which aren't currently solved with RFC2305 >and RFC2532 are: > > * absolutely guaranteed delivery receipts with functionality identical > to PSTN-based fax delivery receipts > * immediate delivery > I want to add the below which Maeda-san said in previous e-mail as "Goals for Ternmnal Mode". - interworking with IFAX Simple Mode and EIFAX - capability exchange (maybe the requirements above include it) Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Wed Feb 14 03:53:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25025 for ; Wed, 14 Feb 2001 03:53:08 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA13729 for ietf-fax-bks; Wed, 14 Feb 2001 00:14:03 -0800 (PST) Received: from ionet.net (root@mail.ionet.net [206.41.128.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA13722 for ; Wed, 14 Feb 2001 00:14:02 -0800 (PST) Received: from localhost (ip28.bedford3.ma.pub-ip.psi.net [38.32.11.28]) by ionet.net (8.9.1a/8.9.1) with ESMTP id CAA05435 for ; Wed, 14 Feb 2001 02:14:12 -0600 (CST) Message-Id: <200102140814.CAA05435@ionet.net> X-Sender: chris@collegewafer.com From: Chris Baker To: ietf-fax@imc.org Date: Wed, 14 Feb 2001 03:13:41 -0500 Subject: Hi, Need 6"-8" Wafer Special! Si, SOI, ZnO, MEMS & More! MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Priority: 1 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id AAA13729 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25025 Hi, Let CollegeWafer.com take care of your wafer needs! Save time and $$$ It's a FREE service to you! Visit http://www.collegewafer.com or call 800-713-9375, Fax 888-832-0340 or email chris@collegewafer.com We have AIN, Fused Silica, Pyrex, GaN, SiC, ZnO of course Si, SOI, Ultra-Thin Si, Ge, InP, ZnSe, ZnO, ZnS, GaP, Infrared and so much more, including: Custom orders for Prime wafers, Test wafers, or Coin Roll wafers. 5" N<100> 5-10 ohm-cm. 24-25.9mils 5" N <100> 10-20 ohm-cm. 24-26mils 5" P<100> 5-10 ohm-cm. 24-25.9mils 5" P<100> 10-20 ohm-cm. 24-25.9mils 6" N<100> 1-5 ohm-cm. 25-27.9mils 6" N<100> 10-20 ohm-cm. 585-725µm 6" N<100> 10-20 ohm-cm. >650µm 6" N<100> 20-30 ohm-cm. 625-725µm 6" N<100> 20-30 ohm-cm. 25-27.5mils 6" P<100> 1-10 ohm-cm. 625-725µm 6" P<100> 10-20 ohm-cm. 625-725µm 6" P<100> 2-15 ohm-cm. 625-725µm 6" P<100> >30 ohm-cm. 25-27.5mils 8" P<100> 1-10 ohm-cm. 675-775µm 8" P<100> 10-20 ohm-cm. 675-775µm 8" P<100> 10-20 ohm-cm. 700-750µm 8" P<100> 10-20 ohm-cm. 700-750µm 12" P <100> 1-100 ohm-cm.750-800µm Polishing and Reclaim: We can polish test and prime wafers at better than SEMI standard specifications. Need Wafer inspection services? Test your wafers for type, resistivity, thickness, TIR, STIR, TTV, FPD and cleanliness analysis. How about: Cleaning, Lapping, Etching, Edge round, graphic printouts (2D & 3D), Certificate of Conformance, Certificate of Analysis, Polishing, Reclaim Services, Laser-cutting and Oxide Services Ask about In-House Oxide Services: Thermally grown oxide for 2"-8" wafers ranging in thickness from 500-100,000 Angstroms. http://www.collegewafer.com/contact_us/Remove/remove.html 11ada22 From owner-ietf-fax@mail.imc.org Wed Feb 14 04:36:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25372 for ; Wed, 14 Feb 2001 04:36:12 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA19366 for ietf-fax-bks; Wed, 14 Feb 2001 00:58:45 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA19348 for ; Wed, 14 Feb 2001 00:58:42 -0800 (PST) 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 RAA17248; Wed, 14 Feb 2001 17:58:29 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id RAA12595; Wed, 14 Feb 2001 17:58:29 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id RAA13678; Wed, 14 Feb 2001 17:58:23 +0900 To: GK@ninebynine.org Cc: ietf-fax@imc.org Subject: draft-ietf-fax-timely-delivery-02.txt 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: <20010214180505E.tamura@toda.ricoh.co.jp> Date: Wed, 14 Feb 2001 18:05:05 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 67 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham, There are lots of changes from the previous version. But, I think it becomes well-refined, although I do not yet understand the latest version well. At first, I have two questions, which may be very basic. 1. TIMELY option Why is 'interval' value of TIMELY option in MAIL FROM unchanged in all SMTP sessions? How do the relay MTA and the final MTA use this value? 2. The conditions that the final MTA returns 'success'(delivered) DSN The second paragraph in Section 3.3 says, ----------------------------------- Before generating a success DSN message, the final MTA must ensure that all of the conditions for delivery of the message have been achieved. Specifically, when the TIMELY option is used, it should ensure that final delivery to the MUA will be completed within the delivery interval indicated. ----------------------------------- I want to know the meaning of "delivery interval indicated". I would like to use the specific example in Section 7.1. ----------------------------------- S: 220 Harper.org ESMTP server C: EHLO Benden.net S: 250-Harper.org S: 250-DELIVERBY 10,TIMELY S: 250 DSN C: MAIL FROM: BY=16;R TIMELY=20 \ ENVID=EE271828 RET=HDRS AAA S: 250 OK C: RCPT TO: NOTIFY=SUCCESS,FALURE \ ORCPT=rfc822;Robinton@Harper.org S: 250 OK C: DATA S: 354 Send data C: (message data goes here) : . BBB S: 250 Message received At this point, the delivery MTA Harper.org has accepted responsibility to achieve message disposition or to report a failure. This will depend on some kind of cooperation with the receiving user agent. When disposition is completed within the specified interval, a DSN report is sent in the following fashion: ----------------------------------- My question is, If the MUA retrieves his mail within '16' seconds after it stores in his mail box of the final MTA, can the final MTA issue issue a "delivered" DSN? Or the specified interval is '16' minus the interval between 'AAA' and 'BBB'(I put 'AAA' and 'BBB' the above SMTP sequence)? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Wed Feb 14 04:57:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25486 for ; Wed, 14 Feb 2001 04:57:18 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id BAA22672 for ietf-fax-bks; Wed, 14 Feb 2001 01:21:51 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA22667 for ; Wed, 14 Feb 2001 01:21:49 -0800 (PST) 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 SAA22218; Wed, 14 Feb 2001 18:21:44 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id SAA17651; Wed, 14 Feb 2001 18:21:44 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id SAA13866; Wed, 14 Feb 2001 18:21:37 +0900 To: umang@apollo.mctr.umbc.edu Cc: ietf-fax@imc.org, jfmule@clarent.com Subject: Re: Question on SIP/T.38 call flow mapping In-Reply-To: References: 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: <20010214182820L.tamura@toda.ricoh.co.jp> Date: Wed, 14 Feb 2001 18:28:20 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Umang, I am not familiar with SIP in T.38. But SIP is only used for call-setup in T.38, I believe. > I have a question on SIP/T.38 call flow mapping. The draft SIP T.38 call flow examples > and Best Current Practices uses SIP > to do call signalling for a T.38 fax call. > It addresses the SIP exchanges needed for initial call setup, when a > CED/Preamble or end of fax tone is detected. Does this mean that all > the other T.38 messages like DIS, DCS, CFR/FTT, MPS, etc. should be > transmitted without using SIP, although they are not actual fax images? So, My answer is Yes. There are two call-setups in T.38. One is H.323 call-setup, and the other is SIP/MGCP call-setup. Even if H.323 call-setup is used, T.30 signals as well as image data are transmitted without H.323 definitions. Only T.38 definitions(T.38 Annex A etc.) can be used. Also, T.30 signals such as DIS and DCS are defined in Annex A. I think the use of SIP must be the same. > Is there any draft/paper that might address these issues. Please see the latest version T.38, including Annex and Appendix. If I am wrong, please correct me, folks. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Wed Feb 14 06:39:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26277 for ; Wed, 14 Feb 2001 06:39:33 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA28716 for ietf-fax-bks; Wed, 14 Feb 2001 02:19:32 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA28711 for ; Wed, 14 Feb 2001 02:19:27 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id TAA07405; Wed, 14 Feb 2001 19:19:21 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma007321; Wed, 14 Feb 01 19:18:35 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id TAA01177; Wed, 14 Feb 2001 19:18:35 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA22478; Wed, 14 Feb 2001 19:18:34 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id TAA08280; Wed, 14 Feb 2001 19:17:29 +0900 (JST) Message-Id: <4.2.0.58.J.20010214192227.009f4570@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 14 Feb 2001 19:26:50 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: Fax processing confirmation Cc: Claudio Allocchio , Hiroshi Tamura 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: Hi, Folks I want discuss about the Fax processing confirmation for which I asked to issue the Internet Draft in ITU-T SG16 meeting last November. The notification of success/failure of document processing and page by page status are very important feature for not only the classic fax but also the internet fax. My idea is to add Fax-Report field in the MDN extension field as follows. MDN extension field: Fax-Report: Fax-Results = code ; Fax-Pages = received page number ; Fax-Errorpage = error page number After we agreed to add the filed, the field will be registered to IANA under the registration procedure written in RFC2434. There will be another method to add the Fax processing confirmation in MDN. Your comments are well come, Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 14 08:02:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27146 for ; Wed, 14 Feb 2001 08:02:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA07713 for ietf-fax-bks; Wed, 14 Feb 2001 04:10:29 -0800 (PST) Received: from sniffout.com ([62.209.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA07706 for ; Wed, 14 Feb 2001 04:10:26 -0800 (PST) Received: from GK-VAIO.NineByNine.org ([62.209.128.19]) by sniffout.com with Microsoft SMTPSVC(5.5.1877.977.9); Wed, 14 Feb 2001 12:10:24 +0000 Message-Id: <5.0.2.1.2.20010214110424.0389ddb0@joy.songbird.com> X-Sender: gk@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 14 Feb 2001 11:34:21 +0000 To: Hiroshi Tamura From: Graham Klyne Subject: Re: draft-ietf-fax-timely-delivery-02.txt Cc: IETF fax WG In-Reply-To: <20010214180505E.tamura@toda.ricoh.co.jp> 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: Tamura-san, Thank you for your comments. I think you raise some details that need to be made more clear. At 06:05 PM 2/14/01 +0900, you wrote: >Graham, > >There are lots of changes from the previous version. But, >I think it becomes well-refined, although I do not yet understand >the latest version well. > >At first, I have two questions, which may be very basic. > >1. TIMELY option > >Why is 'interval' value of TIMELY option in MAIL FROM unchanged >in all SMTP sessions? How do the relay MTA and the final MTA >use this value? Oh yes, the reason for that got rather buried. I propose adding a paragraph in section 3.2: >>> The TIMELY parameter, in the MAIL FROM command of a message in transit, is copied unchanged when the message is retransmitted. Thus, any originally specified time interval is conveyed to the final MTA, to be used as a basis for selecting a delivery interval for returning a timely notification. <<< >2. The conditions that the final MTA returns 'success'(delivered) DSN > >The second paragraph in Section 3.3 says, >----------------------------------- > Before generating a success DSN message, the final MTA must ensure > that all of the conditions for delivery of the message have been > achieved. Specifically, when the TIMELY option is used, it should > ensure that final delivery to the MUA will be completed within the > delivery interval indicated. >----------------------------------- Hmmm... I think that should read "final delivery to and disposition by..." >I want to know the meaning of "delivery interval indicated". It means the remaining interval for delivery, as specified by the received BY= parameter. I'll try and clarify the text. Suggested revision reads: >>> Before generating a success DSN message, the final MTA must ensure that all of the conditions for delivery of the message have been achieved. Specifically, when the TIMELY option is used, it should ensure that final delivery to and processing by the MUA will be completed within the delivery interval indicated as the value of the BY parameter of the received MAIL FROM command. <<< >I would like to use the specific example in Section 7.1. > >----------------------------------- > S: 220 Harper.org ESMTP server > C: EHLO Benden.net > S: 250-Harper.org > S: 250-DELIVERBY 10,TIMELY > S: 250 DSN > C: MAIL FROM: BY=16;R TIMELY=20 \ > ENVID=EE271828 RET=HDRS >AAA S: 250 OK > C: RCPT TO: NOTIFY=SUCCESS,FALURE \ > ORCPT=rfc822;Robinton@Harper.org > S: 250 OK > C: DATA > S: 354 Send data > C: (message data goes here) > : > . >BBB S: 250 Message received > > At this point, the delivery MTA Harper.org has accepted > responsibility to achieve message disposition or to report a > failure. This will depend on some kind of cooperation with the > receiving user agent. When disposition is completed within the > specified interval, a DSN report is sent in the following fashion: >----------------------------------- > >My question is, >If the MUA retrieves his mail within '16' seconds after it stores >in his mail box of the final MTA, can the final MTA issue issue >a "delivered" DSN? Or the specified interval is '16' minus >the interval between 'AAA' and 'BBB'(I put 'AAA' and 'BBB' >the above SMTP sequence)? I rephrase thus: >>> At this point, the delivery MTA Harper.org has accepted responsibility to achieve message disposition or to report a failure within 16 seconds of receiving the MAIL FROM command. This will depend on some kind of cooperation with the receiving user agent. When disposition is completed within the specified interval, a DSN report is sent in the following fashion: <<< I also think the following should be added to section 3.2 and 3.3: >>> The time interval for completion of final delivery and processing should be taken to start with receipt of the MAIL FROM command. <<< Does this help clarify the issue? Also, section 6.3 has some discussion of timing issues. #g From owner-ietf-fax@mail.imc.org Wed Feb 14 09:06:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29058 for ; Wed, 14 Feb 2001 09:06:06 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id FAA11638 for ietf-fax-bks; Wed, 14 Feb 2001 05:03:22 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA11629 for ; Wed, 14 Feb 2001 05:03:20 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27413; Wed, 14 Feb 2001 08:03:22 -0500 (EST) Message-Id: <200102141303.IAA27413@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-implementers-guide-06.txt Date: Wed, 14 Feb 2001 08:03:22 -0500 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Implementers Guide for Facsimile Using Internet Mail Author(s) : V. Cancio, M. Moldovan, H. Tamura, D. Wing Filename : draft-ietf-fax-implementers-guide-06.txt Pages : 21 Date : 13-Feb-01 This document is intended for the implementers of software which uses email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-implementers-guide-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-implementers-guide-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-implementers-guide-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010213122620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-implementers-guide-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-implementers-guide-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010213122620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Wed Feb 14 13:04:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09610 for ; Wed, 14 Feb 2001 13:04:30 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA03267 for ietf-fax-bks; Wed, 14 Feb 2001 09:25:08 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03263 for ; Wed, 14 Feb 2001 09:25:07 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA00500; Wed, 14 Feb 2001 09:23:37 -0800 (PST) Date: Wed, 14 Feb 2001 09:23:37 -0800 (PST) From: Dan Wing To: Graham Klyne cc: Hiroshi Tamura , IETF fax WG Subject: Re: draft-ietf-fax-timely-delivery-02.txt In-Reply-To: <5.0.2.1.2.20010214110424.0389ddb0@joy.songbird.com> Message-ID: <0102140921470.7858-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Feb 2001 11:34 -0000, Graham Klyne wrote: > >I want to know the meaning of "delivery interval indicated". > > It means the remaining interval for delivery, as specified by the received > BY= parameter. I'll try and clarify the text. Suggested revision reads: > > >>> > Before generating a success DSN message, the final MTA must ensure that all > of the conditions for delivery of the message have been > achieved. Specifically, when the TIMELY option is used, it should ensure > that final delivery to and processing by the MUA will be completed within > the delivery interval indicated as the value of the BY parameter of the > received MAIL FROM command. > <<< How would the final MTA (actually, MSA -- Mail Storage Agent) know when the MUA has "processed" the message? If the MSA has a POP3 or IMAP4 server, the simple act of retreiving and deleting the message doesn't indicate successful "processing" of the message. -d From owner-ietf-fax@mail.imc.org Wed Feb 14 13:09:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09860 for ; Wed, 14 Feb 2001 13:09:51 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA03148 for ietf-fax-bks; Wed, 14 Feb 2001 09:21:49 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03144 for ; Wed, 14 Feb 2001 09:21:48 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA28455; Wed, 14 Feb 2001 09:21:18 -0800 (PST) Date: Wed, 14 Feb 2001 09:21:17 -0800 (PST) From: Dan Wing To: MAEDA toru cc: ietf-fax@imc.org, Claudio Allocchio , Hiroshi Tamura Subject: Re: Fax processing confirmation In-Reply-To: <4.2.0.58.J.20010214192227.009f4570@ffmmail.ffm.canon.co.jp> Message-ID: <0102140917410.7858-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Feb 2001 19:26 +0900, MAEDA toru wrote: > Hi, Folks > > I want discuss about the Fax processing confirmation for > which I asked to issue the Internet Draft in ITU-T SG16 > meeting last November. > > The notification of success/failure of document > processing and page by page status are very important > feature for not only the classic fax but also the internet fax. If "internet fax" is: 1) scanner -> ifax ------------> ifax -> printer ^ ^ SMTP how would page-by-page confirmation be useful? The only way a page could fail is if the printer jammed or ran out of paper or the receiving ifax crashed or lost power. All of these are exceptional conditions and are solved with buffering in the ifax, UPS (uninterruptable power supply) -- that is, they're solved today with traditional fax machines. I don't see a need for page-by-page confirmation unless there is a transmission over analog lines -- such as over PSTN. If you see a need for page-by-page confirmation, please provide a scenario where a specific intermediate page could fail when the protcols involved are TCP and SMTP. -Dan Wing > My idea is to add Fax-Report field in the MDN extension > field as follows. > > MDN extension field: > Fax-Report: Fax-Results = code > ; Fax-Pages = received page number > ; Fax-Errorpage = error page number > > After we agreed to add the filed, the field will be registered to > IANA under the registration procedure written in RFC2434. > > There will be another method to add the Fax processing > confirmation in MDN. > > Your comments are well come, > > Toru Maeda > > > -------------------- > MAEDA TORU > MIE Development Div. 2 > CANON Inc. > -------------------- > From owner-ietf-fax@mail.imc.org Wed Feb 14 17:21:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17979 for ; Wed, 14 Feb 2001 17:21:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA17620 for ietf-fax-bks; Wed, 14 Feb 2001 13:37:26 -0800 (PST) Received: from sniffout.com ([62.209.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17616 for ; Wed, 14 Feb 2001 13:37:24 -0800 (PST) Received: from GK-VAIO.NineByNine.org ([62.209.142.17]) by sniffout.com with Microsoft SMTPSVC(5.5.1877.977.9); Wed, 14 Feb 2001 21:37:20 +0000 Message-Id: <5.0.2.1.2.20010214212622.03b24a00@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 14 Feb 2001 21:34:51 +0000 To: Dan Wing From: Graham Klyne Subject: Re: draft-ietf-fax-timely-delivery-02.txt Cc: IETF fax WG In-Reply-To: <0102140921470.7858-100000@omega.cisco.com> References: <5.0.2.1.2.20010214110424.0389ddb0@joy.songbird.com> 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 09:23 AM 2/14/01 -0800, Dan Wing wrote: >How would the final MTA (actually, MSA -- Mail Storage Agent) know when >the MUA has "processed" the message? If the MSA has a POP3 or IMAP4 >server, the simple act of retreiving and deleting the message doesn't >indicate successful "processing" of the message. The exact mechanism is explicitly out-of-scope. But the memo does say that it is presumed there is some cooperation between the delivery MTA and the receiving MUA. In the same way, I suppose, that it is presumed that delivery MTA hands of to the MUA, without SMTP actually specifying how this is done. In this case, there may be no MSA as such; e.g. for fax, the "UA" may be a printer, and the delivery MTA may queue a received message to the printer. As to what constitutes processing/disposition, that too is not absolutely laid down. It is suggested that for a receiving message store, retrieval from the store may be considered to be followed by immediate processing. The whole thrust of this aspect of the proposal is that there exists a relationship between the delivery MTA and receiving MUA that allows such assertions to make sense. In the absence of such relationship, the message should not be accepted for timely processing. Make sense? #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Feb 14 17:26:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18067 for ; Wed, 14 Feb 2001 17:26:08 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA17843 for ietf-fax-bks; Wed, 14 Feb 2001 13:45:42 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17839 for ; Wed, 14 Feb 2001 13:45:41 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA12114; Wed, 14 Feb 2001 13:44:44 -0800 (PST) Date: Wed, 14 Feb 2001 13:44:44 -0800 (PST) From: Dan Wing To: Graham Klyne cc: IETF fax WG Subject: Re: draft-ietf-fax-timely-delivery-02.txt In-Reply-To: <5.0.2.1.2.20010214212622.03b24a00@joy.songbird.com> Message-ID: <0102141341360.7858-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Feb 2001 21:34 -0000, Graham Klyne wrote: > At 09:23 AM 2/14/01 -0800, Dan Wing wrote: > >How would the final MTA (actually, MSA -- Mail Storage Agent) know when > >the MUA has "processed" the message? If the MSA has a POP3 or IMAP4 > >server, the simple act of retreiving and deleting the message doesn't > >indicate successful "processing" of the message. > > The exact mechanism is explicitly out-of-scope. > > But the memo does say that it is presumed there is some cooperation between > the delivery MTA and the receiving MUA. In the same way, I suppose, that > it is presumed that delivery MTA hands of to the MUA, without SMTP actually > specifying how this is done. > > In this case, there may be no MSA as such; e.g. for fax, the "UA" may be a > printer, and the delivery MTA may queue a received message to the printer. > > As to what constitutes processing/disposition, that too is not absolutely > laid down. It is suggested that for a receiving message store, retrieval > from the store may be considered to be followed by immediate > processing. The whole thrust of this aspect of the proposal is that there > exists a relationship between the delivery MTA and receiving MUA that > allows such assertions to make sense. In the absence of such relationship, > the message should not be accepted for timely processing. > > Make sense? I didn't realize you were overloading the term 'delivery'. Delivery has always ment the final MTA (the MSA) has successfully deposited the mail in the user's "mbox" file (or similar for the platform). Delivery doesn't include the MUA pulling the message, the MUA processing the message, or the MUA deleting the message. Perhaps a similar term could be used, but something other than 'delivery', as it's being used with a different meaning than 'deilvery' in the traditional sense used with SMTP such as with Deilvery Status Notifiactions (DSNs) which don't involve the MUA at all, but rather just the final MTA (the MSA). -d From owner-ietf-fax@mail.imc.org Wed Feb 14 20:39:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20455 for ; Wed, 14 Feb 2001 20:39:12 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA00858 for ietf-fax-bks; Wed, 14 Feb 2001 16:57:24 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA00849 for ; Wed, 14 Feb 2001 16:57:21 -0800 (PST) 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 JAA25631 for ; Thu, 15 Feb 2001 09:57:24 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id JAA22164 for ; Thu, 15 Feb 2001 09:57:23 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id JAA01205 for ; Thu, 15 Feb 2001 09:57:14 +0900 To: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-implementers-guide-06.txt In-Reply-To: <200102141303.IAA27413@ietf.org> References: <200102141303.IAA27413@ietf.org> 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: <20010215100400M.tamura@toda.ricoh.co.jp> Date: Thu, 15 Feb 2001 10:04:00 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, As the revision history says, there are only small additions from the previous version. -------------------------------------------------------------- Version 6 1) Addition that a "word" in TIFF is a 2-byte in Section 5.1. 2) Section 5.2 was re-assembled and divided into new secion 5.2.1 and 5.2.2. 3) Some unfounded items(Child IFDs and GlobalParametersIFD) in section 5.2 were deleted, according to a suggestion. -------------------------------------------------------------- Also, "diff" between -06 and -05 makes lots of things. But, this is just the format issue. I formatted it as less than 72 characters per line and 55(maybe) lines per page except for the 1st page. It is a very minor issue. Our WG already agreed to the contents. Also, as the San Diego minutes says, after minor issues are solved, we can issue WG Last Call. I wait for comments in a few days and ask Claudio to issue it sooner or later. In a co-chair's point of view, from other threads, there seems lots of things we have to cover in Minneapolis. So, I would like to proceed what we can do right now, such as this impl-guide, as soon as possible. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Wed Feb 14 20:55:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20677 for ; Wed, 14 Feb 2001 20:54:59 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA01806 for ietf-fax-bks; Wed, 14 Feb 2001 17:05:52 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA01797 for ; Wed, 14 Feb 2001 17:05:50 -0800 (PST) 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 KAA27210; Thu, 15 Feb 2001 10:05:50 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id KAA23764; Thu, 15 Feb 2001 10:05:49 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id KAA01261; Thu, 15 Feb 2001 10:05:41 +0900 To: GK@ninebynine.org Cc: ietf-fax@imc.org Subject: Re: draft-ietf-fax-timely-delivery-02.txt In-Reply-To: <5.0.2.1.2.20010214110424.0389ddb0@joy.songbird.com> References: <20010214180505E.tamura@toda.ricoh.co.jp> <5.0.2.1.2.20010214110424.0389ddb0@joy.songbird.com> 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: <20010215101156O.tamura@toda.ricoh.co.jp> Date: Thu, 15 Feb 2001 10:11:56 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 72 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham, > >1. TIMELY option > >>> > The TIMELY parameter, in the MAIL FROM command of a message in transit, is > copied unchanged when the message is retransmitted. Thus, any originally > specified time interval is conveyed to the final MTA, to be used as a basis > for selecting a delivery interval for returning a timely notification. > <<< OK. I see what you intend. > >2. The conditions that the final MTA returns 'success'(delivered) DSN > >>> > Before generating a success DSN message, the final MTA must ensure that all > of the conditions for delivery of the message have been > achieved. Specifically, when the TIMELY option is used, it should ensure > that final delivery to and processing by the MUA will be completed within > the delivery interval indicated as the value of the BY parameter of the > received MAIL FROM command. > <<< Yes, that's what I asked for. > > S: 220 Harper.org ESMTP server > > C: EHLO Benden.net > > S: 250-Harper.org > > S: 250-DELIVERBY 10,TIMELY > > S: 250 DSN > > C: MAIL FROM: BY=16;R TIMELY=20 \ > > ENVID=EE271828 RET=HDRS > >AAA S: 250 OK > > C: RCPT TO: NOTIFY=SUCCESS,FALURE \ > > ORCPT=rfc822;Robinton@Harper.org > > S: 250 OK > > C: DATA > > S: 354 Send data > > C: (message data goes here) > > : > > . > >BBB S: 250 Message received > >>> > At this point, the delivery MTA Harper.org has accepted responsibility to > achieve message disposition or to report a failure within 16 seconds of > receiving the MAIL FROM command. This will depend on some kind of > cooperation with the receiving user agent. When disposition is completed > within the specified interval, a DSN report is sent in the following fashion: > <<< OK. > >>> > The time interval for completion of final delivery and processing should be > taken to start with receipt of the MAIL FROM command. > <<< Good addition. > Does this help clarify the issue? Yes, of course. When i have much time, I read again. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Wed Feb 14 21:01:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20769 for ; Wed, 14 Feb 2001 21:01:22 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA02645 for ietf-fax-bks; Wed, 14 Feb 2001 17:14:05 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA02640 for ; Wed, 14 Feb 2001 17:14:03 -0800 (PST) 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 KAA28843; Thu, 15 Feb 2001 10:14:04 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id KAA25458; Thu, 15 Feb 2001 10:14:03 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id KAA01335; Thu, 15 Feb 2001 10:13:54 +0900 To: maeda.toru@canon.co.jp, ietf-fax@imc.org Subject: Re: Fax processing confirmation In-Reply-To: <0102140917410.7858-100000@omega.cisco.com> References: <4.2.0.58.J.20010214192227.009f4570@ffmmail.ffm.canon.co.jp> <0102140917410.7858-100000@omega.cisco.com> 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: <20010215102040P.tamura@toda.ricoh.co.jp> Date: Thu, 15 Feb 2001 10:20:40 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Maeda-san, I have some comments for your two proposals. Before I do, I ask one basic question. Do "Terminal mode" proposal and "Fax processing confirmation" one have to go together in your idea? Or, separate(independent) ones? Can "Fax processing confirmation" also be used in Eifax or Fullmode in your idea? Please explain. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Thu Feb 15 01:14:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28012 for ; Thu, 15 Feb 2001 01:14:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA10357 for ietf-fax-bks; Wed, 14 Feb 2001 21:35:50 -0800 (PST) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA10351 for ; Wed, 14 Feb 2001 21:35:44 -0800 (PST) Received: by bulls.mei.co.jp (8.11.2/3.7W) with ESMTP id f1F5ZGD20751 for ; Thu, 15 Feb 2001 14:35:16 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id OAA28852 for ; Thu, 15 Feb 2001 14:35:13 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 15 Feb 2001 05:35:14 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id OAA15178 for ; Thu, 15 Feb 2001 14:35:11 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id OAA17535 for ; Thu, 15 Feb 2001 14:35:10 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id OAA11021 for ; Thu, 15 Feb 2001 14:35:10 +0900 (JST) Message-Id: <200102150536.AA01250@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Thu, 15 Feb 2001 14:36:26 +0900 To: ietf-fax@imc.org Subject: new I-D service-v2-03 MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Folks, I have submitted the new I-D service-v2-03 because service-v2-02 is expired at January 2001. So, its contents is same as service-v2-02 except expired date. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Thu Feb 15 09:39:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18960 for ; Thu, 15 Feb 2001 09:39:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA01098 for ietf-fax-bks; Thu, 15 Feb 2001 06:03:17 -0800 (PST) Received: from sniffout.com ([62.209.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA01085 for ; Thu, 15 Feb 2001 06:03:15 -0800 (PST) Received: from GK-VAIO.NineByNine.org ([62.209.143.225]) by sniffout.com with Microsoft SMTPSVC(5.5.1877.977.9); Thu, 15 Feb 2001 14:03:14 +0000 Message-Id: <5.0.2.1.2.20010215131357.00a08580@joy.songbird.com> X-Sender: gk@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Feb 2001 13:42:59 +0000 To: Hiroshi Tamura From: Graham Klyne Subject: Re: Progress update: negotiation Cc: ietf-fax@imc.org In-Reply-To: <20010206160703W.tamura@toda.ricoh.co.jp> References: <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> 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: Tamura-san, I've responded to the negotiate-down matter in a separate message. Here, I'll make any response to the other comments you have raised. First, a general point: the document contains a list of points for consideration in a "review checklist" in appendix C. This is to draw attention to some points that we felt deserved wider consideration. But if we don't receive any views on any of these issues, the general plan is to not change the specification. We've made our decisions: now is the group's opportunity to voice any disagreements. At 04:07 PM 2/6/01 +0900, Hiroshi Tamura wrote: > > o Cache-control for recipient features? (e.g. colour offered for > > selected senders only). (3.2.3) > >I understand under some conditions the receiver do not want to >announce his capabilities. If you take care, you can write something >in Appendix A(implementation issues). I've added a paragraph to section 6.2, which I think probably covers this issue adequately. >>> An MDN response containing an 'alternative-preferred' disposition modifier SHOULD also contain a 'Media-accept-features:' field [2] indicating the capabilities that the sender should use in selecting an alternative form of message data. If this field is not supplied, the sender should assume some baseline feature capabilities. Receiver capabilities supplied with an alternative-preferred disposition notification MUST NOT be cached: they may apply to the current transaction only. <<< This is also covered in section A.5. > > o Check the correct final disposition for lost message data (3.4) > >An suitable type do not exist in the current definitions, >but "deleted" is ok for me. > > > o Define Content-alternative in a separate document? (Possibly, > > because it might be used separately from the content negotiation > > framework; e.g. in a fashion similar to the HTTP vary: header.) > > (4) > >If possible, another document is better so that other applications >can use it clearly. But, I leave it to the editors. In consideration of the editorial effort that will be needed to separate this, unless someone says this is likely to be used in another specification I propose to leave it where it is. > > o Describe interaction between Content-alternative and > > message/partial. Is the discussion in RFC 2298 section 2.5 > > sufficient? (4) > >Huum. Difficult to comment. I do not know soon. I hope it is sufficient. >How about describing something in Appendix A? Unless someone comes up with specific concerns, I don't propose to add anything. > > o Special considerations for defining composite document > > characteristics (e.g. MRC) in Content-alternative headers? (4) > >I do not know the issue well. Is it diffcult to express? It could be difficult. I think it is a theoretical issue that takes us into a level of considerable extra complexity with zero-to-marginal utility. > > o Add E164 address type for reporting fax offramp disposal? (6.2) > >It seems to be difficult to take. Because, it has something to do with >G3 or G4 fax protocol itself. It is better NOT to address, I think. I tend to agree. This might be an issue to be covered in an offramp gateway specification? > > o Discuss the options that should be exposed using Content- > > alternative; e.g. is it necessary to declare 'baseline' > > capabilities. > >As I said in the above, it is better, but not mandatory. See separate message. >BTW, >Section 9(IANA...) is sufficient for registering headers or anything? I'll take AD advice on that. In the absence of an IANA registry, I think that definition in an RFC is all that is needed. For now, that material is a place-holder. (Also, I am aware of separate ideas in formation for which I think it's helpful to highlight any new headers defined.) The others I think are all in the prescribed form. At some stage we'll probably need to extract the templates and send them to the right mailing address for IANA to action. #g From owner-ietf-fax@mail.imc.org Thu Feb 15 09:48:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19240 for ; Thu, 15 Feb 2001 09:48:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA01109 for ietf-fax-bks; Thu, 15 Feb 2001 06:03:21 -0800 (PST) Received: from sniffout.com ([62.209.144.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA01087 for ; Thu, 15 Feb 2001 06:03:15 -0800 (PST) Received: from GK-VAIO.NineByNine.org ([62.209.143.225]) by sniffout.com with Microsoft SMTPSVC(5.5.1877.977.9); Thu, 15 Feb 2001 14:03:12 +0000 Message-Id: <5.0.2.1.2.20010215122007.009ff830@joy.songbird.com> X-Sender: gk@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Feb 2001 13:13:49 +0000 To: Hiroshi Tamura From: Graham Klyne Subject: Negotiation: declaring baseline capabilities Cc: ietf-fax@imc.org In-Reply-To: <20010206160703W.tamura@toda.ricoh.co.jp> References: <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> 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: Tamura-san, Again, thank you for your thoughts and comments. Here, I'll try to pick up the main outstanding item... At 04:07 PM 2/6/01 +0900, Hiroshi Tamura wrote: > > The draft is all there now, but there are some specific points I would > like > > to discuss. One in particular that the authors jointly feel would benefit > > from group discussion has arisen from the late addition of a > negotiate-down > > example: if the sender has an alternative that assumed _lower_ > > capabilities than the version actually sent, should those lower > > capabilities be described explicitly by a Content-alternatives > > header? When the draft is available, I'll post more details of this > > issue. Other points regarding which WG revciew is explicitly requested > are: > >Negotiation-down example itself is good. Thanks for taking it. > >In my feeling, it is better to describe lower or baseline capabilities >in Content-alternatives explicitly, but not mandatory. >All terminals or software must support baseline one at least. I've been thinking about this a little more. In writing a protocol specification, I think the important matter to cover is that conforming implementations behave correctly over a reasonably wide range of circumstances. Or: to minimize surprises. I think that simply declaring a feature as desirable but not mandatory doesn't really further this goal. Applying this approach to the matter of sender capability declarations and content negotiation, here are the possible scenarios (I think these cover all the possibilities): (a) Receiver capabilities exactly match the data sent. (b) Receiver has higher feature capabilities that match some alternative offered by the sender. (c) Receiver has higher feature capabilities than the data sent, but these don't match any higher features are offered by the sender. (d) Receiver has lower feature capabilities that match an alternative offered by the sender. (e) Receiver has lower feature capabilities that do not match any alternative offered by the sender. What are the reasonably desired outcomes? (i) Receiver displays data and reports success. (ii) Receiver does not display data and requests alternative, supplying its own capabilities so that the sender can select an alternative. (iii) Receiver does not display data and reports failure. These would be applied as: (a) -> (i) (b) -> (ii) (c) -> (i) (d) -> (ii) (e) -> (ii) or (iii)? I suggest: if there is a reasonable chance that usable alternative data is available then simply reporting failure is not a helpful outcome. Therefore the more useful outcome for case (e) would be action (ii). The possible disadvantage in this case would be that if the sender does not have a suitable alternative, an additional round-trip message may be incurred (sections 3.3, 6.3). So, if we accept that (ii) is the right way to respond in case (e), there is nothing to be gained in advertising features lower than those actually sent. Otherwise if (iii) is the preferred response, then the lower capabilities MUST be sent. Because there is a general presumption of a universally supported baseline format (Section 2.1.1, para 3) I tend to prefer option (ii). I think the receiver's behaviour is the point of debate, then the issue of whether the sender declares lesser feature support follows from that. Either way, I think some clarification in the document will be required. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Thu Feb 15 15:58:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29775 for ; Thu, 15 Feb 2001 15:58:30 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA21778 for ietf-fax-bks; Thu, 15 Feb 2001 12:21:21 -0800 (PST) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21773 for ; Thu, 15 Feb 2001 12:21:19 -0800 (PST) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA29021; Thu, 15 Feb 2001 15:21:21 -0500 (EST) 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 MAA05697; Thu, 15 Feb 2001 12:02:23 -0800 (PST) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 15 Feb 2001 12:02:22 -0800 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A3045@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Graham Klyne'" Cc: ietf-fax@imc.org Subject: RE: Progress update: negotiation Date: Thu, 15 Feb 2001 12:02:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Graham Klyne [mailto:GK@ninebynine.org] > Sent: Thursday, February 15, 2001 5:43 AM > To: Hiroshi Tamura > Cc: ietf-fax@imc.org > Subject: Re: Progress update: negotiation > > > Tamura-san, > ---snip--- > > > > > o Special considerations for defining composite document > > > characteristics (e.g. MRC) in Content-alternative > headers? (4) > > > >I do not know the issue well. Is it diffcult to express? > > It could be difficult. I think it is a theoretical issue > that takes us > into a level of considerable extra complexity with > zero-to-marginal utility. > I am not sure what Graham had in mind for composite document characteristics. I, however, assume that any provision would be defined in Schema (RFC 2879). There could be value in a more explicit representation of composite attributes. ---snip--- Lloyd From owner-ietf-fax@mail.imc.org Thu Feb 15 17:43:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01814 for ; Thu, 15 Feb 2001 17:43:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA26145 for ietf-fax-bks; Thu, 15 Feb 2001 13:56:52 -0800 (PST) Received: from bnfep03.boone.winstar.net (bnfep03w.boone.winstar.net [63.140.240.55]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26141 for ; Thu, 15 Feb 2001 13:56:50 -0800 (PST) Received: from commercilv4rrq ([63.140.12.10]) by bnfep03.boone.winstar.net with SMTP id <20010215215647.JHQK464.bnfep03@commercilv4rrq>; Thu, 15 Feb 2001 16:56:47 -0500 From: "Commercial Lease Solutions" To: "McIntyre, Lloyd" , "'Graham Klyne'" Cc: Subject: RE: Progress update: negotiation Date: Thu, 15 Feb 2001 16:53:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE067A3045@mercury.ADOC.xerox.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Not sure how I got on this email list, but I can't seem to get off it. ****However, since I am, I was wondering if I could get some help. I would like to turn one of our office computers into a fax server with the ability to fax over IP. Our fax bill is running as high as $500, and we would like to trim that. Any suggestions would be appreciated. Thank you -----Original Message----- From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On Behalf Of McIntyre, Lloyd Sent: Thursday, February 15, 2001 3:02 PM To: 'Graham Klyne' Cc: ietf-fax@imc.org Subject: RE: Progress update: negotiation > -----Original Message----- > From: Graham Klyne [mailto:GK@ninebynine.org] > Sent: Thursday, February 15, 2001 5:43 AM > To: Hiroshi Tamura > Cc: ietf-fax@imc.org > Subject: Re: Progress update: negotiation > > > Tamura-san, > ---snip--- > > > > > o Special considerations for defining composite document > > > characteristics (e.g. MRC) in Content-alternative > headers? (4) > > > >I do not know the issue well. Is it diffcult to express? > > It could be difficult. I think it is a theoretical issue > that takes us > into a level of considerable extra complexity with > zero-to-marginal utility. > I am not sure what Graham had in mind for composite document characteristics. I, however, assume that any provision would be defined in Schema (RFC 2879). There could be value in a more explicit representation of composite attributes. ---snip--- Lloyd From owner-ietf-fax@mail.imc.org Thu Feb 15 19:40:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02980 for ; Thu, 15 Feb 2001 19:40:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA03587 for ietf-fax-bks; Thu, 15 Feb 2001 15:56:56 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03581 for ; Thu, 15 Feb 2001 15:56:54 -0800 (PST) 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 IAA08356; Fri, 16 Feb 2001 08:56:41 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id IAA07422; Fri, 16 Feb 2001 08:56:41 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id IAA06176; Fri, 16 Feb 2001 08:56:38 +0900 To: GK@ninebynine.org Cc: ietf-fax@imc.org Subject: Re: Progress update: negotiation In-Reply-To: <5.0.2.1.2.20010215131357.00a08580@joy.songbird.com> References: <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> <20010206160703W.tamura@toda.ricoh.co.jp> <5.0.2.1.2.20010215131357.00a08580@joy.songbird.com> 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: <20010216090319I.tamura@toda.ricoh.co.jp> Date: Fri, 16 Feb 2001 09:03:19 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 68 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > First, a general point: the document contains a list of points for > consideration in a "review checklist" in appendix C. This is to draw > attention to some points that we felt deserved wider consideration. But if > we don't receive any views on any of these issues, the general plan is to > not change the specification. We've made our decisions: now is the > group's opportunity to voice any disagreements. OK. I see. I think so, too, as a chair. > > > o Cache-control for recipient features? (e.g. colour offered for > > > selected senders only). (3.2.3) > I've added a paragraph to section 6.2, which I think probably covers this > issue adequately. > > >>> > An MDN response containing an 'alternative-preferred' disposition modifier > SHOULD also contain a 'Media-accept-features:' field [2] indicating the > capabilities that the sender should use in selecting an alternative form of > message data. If this field is not supplied, the sender should assume some > baseline feature capabilities. Receiver capabilities supplied with an > alternative-preferred disposition notification MUST NOT be cached: they > may apply to the current transaction only. > <<< Good. > > > o Define Content-alternative in a separate document? (Possibly, > > > because it might be used separately from the content negotiation > > > framework; e.g. in a fashion similar to the HTTP vary: header.) > > > (4) > > > >If possible, another document is better so that other applications > >can use it clearly. But, I leave it to the editors. I see. > > > o Add E164 address type for reporting fax offramp disposal? (6.2) > > > >It seems to be difficult to take. Because, it has something to do with > >G3 or G4 fax protocol itself. It is better NOT to address, I think. > > I tend to agree. This might be an issue to be covered in an offramp > gateway specification? If possible, it is better to address this issue in it. But, even in it, it may be very difficult. > >Section 9(IANA...) is sufficient for registering headers or anything? My question is, for example, some more detailed descriptions are necessary, such as RFC2302 or draft-ietf-fax-tiff-regbis-02.txt,,? > I'll take AD advice on that. In the absence of an IANA registry, I think > that definition in an RFC is all that is needed. For now, that material is > a place-holder. (Also, I am aware of separate ideas in formation for which > I think it's helpful to highlight any new headers defined.) Yes, we may need AD advice. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Thu Feb 15 21:52:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05924 for ; Thu, 15 Feb 2001 21:52:04 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA09487 for ietf-fax-bks; Thu, 15 Feb 2001 18:12:29 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA09483 for ; Thu, 15 Feb 2001 18:12:26 -0800 (PST) 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 LAA29078; Fri, 16 Feb 2001 11:12:25 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id LAA28582; Fri, 16 Feb 2001 11:12:24 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id LAA07355; Fri, 16 Feb 2001 11:12:21 +0900 To: GK@ninebynine.org Cc: ietf-fax@imc.org Subject: Re: Negotiation: declaring baseline capabilities In-Reply-To: <5.0.2.1.2.20010215122007.009ff830@joy.songbird.com> References: <5.0.2.1.2.20010130104623.03a86b30@pop.dial.pipex.com> <20010206160703W.tamura@toda.ricoh.co.jp> <5.0.2.1.2.20010215122007.009ff830@joy.songbird.com> 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: <20010216111903A.tamura@toda.ricoh.co.jp> Date: Fri, 16 Feb 2001 11:19:03 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Short comments. > (e) Receiver has lower feature capabilities that do not match any > alternative offered by the sender. > (ii) Receiver does not display data and requests alternative, supplying its > own capabilities so that the sender can select an alternative. > (iii) Receiver does not display data and reports failure. > (e) -> (ii) or (iii)? > The possible disadvantage in this case would be that if the sender does not > have a suitable alternative, an additional round-trip message may be > incurred (sections 3.3, 6.3). Oh, that's right. > Because there is a general presumption of a universally supported baseline > format (Section 2.1.1, para 3) I tend to prefer option (ii). I also prefer (ii) in this case, although it may cause additional message as the above. > I think the receiver's behaviour is the point of debate, then the issue of > whether the sender declares lesser feature support follows from > that. Either way, I think some clarification in the document will be required. I think so, too. Thank you for your thoughful comments. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Thu Feb 15 23:28:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08969 for ; Thu, 15 Feb 2001 23:28:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA12737 for ietf-fax-bks; Thu, 15 Feb 2001 19:46:16 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA12730 for ; Thu, 15 Feb 2001 19:46:14 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id MAA10316; Fri, 16 Feb 2001 12:46:13 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma010046; Fri, 16 Feb 01 12:45:07 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id MAA19115; Fri, 16 Feb 2001 12:45:06 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id MAA20527; Fri, 16 Feb 2001 12:45:06 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id MAA27555; Fri, 16 Feb 2001 12:43:58 +0900 (JST) Message-Id: <4.2.0.58.J.20010216123710.00a64c08@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 16 Feb 2001 12:53:27 +0900 To: Hiroshi Tamura , ietf-fax@imc.org From: MAEDA toru Subject: Re: Fax processing confirmation In-Reply-To: <20010215102040P.tamura@toda.ricoh.co.jp> References: <0102140917410.7858-100000@omega.cisco.com> <4.2.0.58.J.20010214192227.009f4570@ffmmail.ffm.canon.co.jp> <0102140917410.7858-100000@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tamura-san My opinion is that the fax status confirmation must be mandatory for Full Mode and Terminal Mode. Full Mode (FFPIM) should be updated to use "Fax processing confirmation", after WG agreed to use it in Full Mode. EIFAX will be updated to use it as optional. Terminal Mode will refer "Fax processing confirmation", if WG agreed to use it. Regards, Toru MAEDA At 10:20 01/02/15 +0900, Hiroshi Tamura wrote: >Maeda-san, > >I have some comments for your two proposals. >Before I do, I ask one basic question. > >Do "Terminal mode" proposal and "Fax processing confirmation" one >have to go together in your idea? Or, separate(independent) ones? >Can "Fax processing confirmation" also be used in Eifax or Fullmode >in your idea? Please explain. > >Regards, >-- >Hiroshi Tamura, Ricoh Company, LTD. >E-mail: tamura@toda.ricoh.co.jp ----------------------------------- $B%-%d%N%s3t<02q; Fri, 16 Feb 2001 05:41:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA12508 for ietf-fax-bks; Fri, 16 Feb 2001 01:49:21 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA12503 for ; Fri, 16 Feb 2001 01:49:19 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id SAA29867; Fri, 16 Feb 2001 18:49:15 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma029757; Fri, 16 Feb 01 18:48:55 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id SAA04028; Fri, 16 Feb 2001 18:48:54 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id SAA03917; Fri, 16 Feb 2001 18:48:54 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id SAA19428; Fri, 16 Feb 2001 18:47:46 +0900 (JST) Message-Id: <4.2.0.58.J.20010216181726.00ab0d28@ffmmail.ffm.canon.co.jp> X-Sender: maeda/ffmpop1.ffm.canon.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 16 Feb 2001 18:57:14 +0900 To: Dan Wing From: MAEDA toru Subject: Re: Fax processing confirmation Cc: ietf-fax@imc.org, Claudio Allocchio , Hiroshi Tamura In-Reply-To: <0102140917410.7858-100000@omega.cisco.com> References: <4.2.0.58.J.20010214192227.009f4570@ffmmail.ffm.canon.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wing-san How much confidence of ifax transmission in Simple Mode ? Does no response mean a good confirmation ? I want to add Fax processing confirmation in Full Mode. In Full Mode, the image file is send as TIFF file over SMTP. There will be some possibilities to fail to print or process the TIFF file by some reasons. These reasons may be incorrect TIFF parameter for the receiver or out of capabilities TIFF parameter for the receiver. When you put the 10 pages of document on the scanner and send by ifax Full Mode and you get the confirmation sheet with 9 pages received successfully, you will find something wrong with the scanner or the transmission. You will check the scanner or the system and may ask to the user of the receiver. Comparing to the E-mail system, you can not get information about how many pages the receiver successfully printed but just received. You may find that the attached file is not be able to be processed nor printed by the Email receiver with your inspiration. The user of Full Mode ifax will have confidence of the ifax transmission when the transmitter prints confirmation sheet with the number of pages printed on the receiver and also the number of page in error. Any comments? Regards, Toru Maeda At 09:21 01/02/14 -0800, Dan Wing wrote: >On Wed, 14 Feb 2001 19:26 +0900, MAEDA toru wrote: > > > Hi, Folks > > > > I want discuss about the Fax processing confirmation for > > which I asked to issue the Internet Draft in ITU-T SG16 > > meeting last November. > > > > The notification of success/failure of document > > processing and page by page status are very important > > feature for not only the classic fax but also the internet fax. > >If "internet fax" is: > > 1) > > scanner -> ifax ------------> ifax -> printer > ^ > ^ > SMTP > >how would page-by-page confirmation be useful? The only way a page could >fail is if the printer jammed or ran out of paper or the receiving ifax >crashed or lost power. All of these are exceptional conditions and are >solved with buffering in the ifax, UPS (uninterruptable power supply) -- >that is, they're solved today with traditional fax machines. > >I don't see a need for page-by-page confirmation unless there is a >transmission over analog lines -- such as over PSTN. > >If you see a need for page-by-page confirmation, please provide a scenario >where a specific intermediate page could fail when the protcols involved >are TCP and SMTP. > >-Dan Wing > > > My idea is to add Fax-Report field in the MDN extension > > field as follows. > > > > MDN extension field: > > Fax-Report: Fax-Results = code > > ; Fax-Pages = received page number > > ; Fax-Errorpage = error page number > > > > After we agreed to add the filed, the field will be registered to > > IANA under the registration procedure written in RFC2434. > > > > There will be another method to add the Fax processing > > confirmation in MDN. > > > > Your comments are well come, > > > > Toru Maeda > > > > > > -------------------- > > MAEDA TORU > > MIE Development Div. 2 > > CANON Inc. > > -------------------- > > ----------------------------------- $B%-%d%N%s3t<02q; Fri, 16 Feb 2001 07:33:00 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA22608 for ietf-fax-bks; Fri, 16 Feb 2001 03:53:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA22603 for ; Fri, 16 Feb 2001 03:53:46 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26604; Fri, 16 Feb 2001 06:53:46 -0500 (EST) Message-Id: <200102161153.GAA26604@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-service-v2-02.txt Date: Fri, 16 Feb 2001 06:53:45 -0500 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : A Simple Mode of Facsimile Using Internet Mail Author(s) : K. Toyoda, H. Ohno, J. Murai, D. Wing Filename : draft-ietf-fax-service-v2-02.txt Pages : 13 Date : 15-Feb-01 This specification provides for 'simple mode' carriage of facsimile data over the Internet. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], and TIFF for Facsimile [5,6,19]. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-service-v2-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-service-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-service-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010215122222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-service-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-service-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010215122222.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Fri Feb 16 14:07:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07258 for ; Fri, 16 Feb 2001 14:07:20 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA16530 for ietf-fax-bks; Fri, 16 Feb 2001 10:26:57 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16524 for ; Fri, 16 Feb 2001 10:26:55 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA27537; Fri, 16 Feb 2001 10:26:02 -0800 (PST) Date: Fri, 16 Feb 2001 10:26:02 -0800 (PST) From: Dan Wing To: MAEDA toru cc: ietf-fax@imc.org, Claudio Allocchio , Hiroshi Tamura Subject: Re: Fax processing confirmation In-Reply-To: <4.2.0.58.J.20010216181726.00ab0d28@ffmmail.ffm.canon.co.jp> Message-ID: <0102161025420.12313-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote: > Wing-san > > How much confidence of ifax transmission in Simple Mode ? > Does no response mean a good confirmation ? > > I want to add Fax processing confirmation in Full Mode. > In Full Mode, the image file is send as TIFF file over SMTP. > There will be some possibilities to fail to print or process > the TIFF file by some reasons. These reasons may be > incorrect TIFF parameter for the receiver > or out of capabilities TIFF parameter for the receiver. > > When you put the 10 pages of document on the scanner > and send by ifax Full Mode and you get the confirmation sheet > with 9 pages received successfully, you will find something > wrong with the scanner or the transmission. You will check > the scanner or the system and may ask to the user of the receiver. > > Comparing to the E-mail system, you can not get information about > how many pages the receiver successfully printed but just received. > You may find that the attached file is not be able to be processed > nor printed by the Email receiver with your inspiration. > > The user of Full Mode ifax will have confidence of the ifax > transmission when the transmitter prints confirmation sheet > with the number of pages printed on the receiver and also > the number of page in error. > > Any comments? IPP provides this sort of confirmation today. Why not use IPP? -d From owner-ietf-fax@mail.imc.org Sat Feb 17 16:39:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07650 for ; Sat, 17 Feb 2001 16:39:52 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA23681 for ietf-fax-bks; Sat, 17 Feb 2001 13:00:35 -0800 (PST) Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA23677 for ; Sat, 17 Feb 2001 13:00:33 -0800 (PST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id MAA00365; Sat, 17 Feb 2001 12:59:06 -0800 (PST) Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2448.0) id <108RNJVW>; Sat, 17 Feb 2001 12:59:24 -0800 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ED072@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Dan Wing'" , MAEDA toru Cc: ietf-fax@imc.org, Claudio Allocchio , Hiroshi Tamura Subject: RE: Fax processing confirmation Date: Sat, 17 Feb 2001 12:59:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dan and IFax folks, Please note that IPP notifications (in-band via IPP channel or out-of-band via SMTP or 'reverse' HTTP) are still work-in-progress in the IETF IPP WG. IPP native protocol itself does NOT provide confirmation that any pages have actually been printed without polling (by the IPP Client) of the IPP Printer. The IEEE/ISTO PWG (Printer Working Group) has chartered IPPFax project, but it isn't very far along yet. The IETF declined to charter IPPFax as an IETF WG, so this is probably quite far away from an IETF 'standards track' RFC. Cheers, - Ira McDonald, consulting architect at Sharp and Xerox (active member of IETF IPP WG, author of 'ipp:' URL scheme) High North Inc -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Friday, February 16, 2001 10:26 AM To: MAEDA toru Cc: ietf-fax@imc.org; Claudio Allocchio; Hiroshi Tamura Subject: Re: Fax processing confirmation On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote: > Wing-san > > How much confidence of ifax transmission in Simple Mode ? > Does no response mean a good confirmation ? > > I want to add Fax processing confirmation in Full Mode. > In Full Mode, the image file is send as TIFF file over SMTP. > There will be some possibilities to fail to print or process > the TIFF file by some reasons. These reasons may be > incorrect TIFF parameter for the receiver > or out of capabilities TIFF parameter for the receiver. > > When you put the 10 pages of document on the scanner > and send by ifax Full Mode and you get the confirmation sheet > with 9 pages received successfully, you will find something > wrong with the scanner or the transmission. You will check > the scanner or the system and may ask to the user of the receiver. > > Comparing to the E-mail system, you can not get information about > how many pages the receiver successfully printed but just received. > You may find that the attached file is not be able to be processed > nor printed by the Email receiver with your inspiration. > > The user of Full Mode ifax will have confidence of the ifax > transmission when the transmitter prints confirmation sheet > with the number of pages printed on the receiver and also > the number of page in error. > > Any comments? IPP provides this sort of confirmation today. Why not use IPP? -d From owner-ietf-fax@mail.imc.org Mon Feb 19 03:42:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00423 for ; Mon, 19 Feb 2001 03:42:41 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA17808 for ietf-fax-bks; Mon, 19 Feb 2001 00:00:04 -0800 (PST) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA17783 for ; Sun, 18 Feb 2001 23:59:59 -0800 (PST) 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 QAA20416; Mon, 19 Feb 2001 16:59:41 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id QAA27501; Mon, 19 Feb 2001 16:59:40 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id QAA04612; Mon, 19 Feb 2001 16:59:09 +0900 To: ktoyoda@rdmg.mgcs.mei.co.jp, dwing@cisco.com, hal9001@panix.com, maeda.toru@canon.co.jp, ietf-fax@imc.org Subject: Re: E2E requirements In-Reply-To: <200102140735.AA01242@d23n59.rdmg.mgcs.mei.co.jp> References: <0102131807270.18360-100000@omega.cisco.com> <200102140735.AA01242@d23n59.rdmg.mgcs.mei.co.jp> 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: <20010219170625G.tamura@toda.ricoh.co.jp> Date: Mon, 19 Feb 2001 17:06:25 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chair's comments. There are some comments about Maeda-san's ideas. Some of his ideas are not accepted. But, one agreement is E2E communication, I think. Our group may agree to somthing about it. Folks, Please continue to discuss E2E communication, together with the items necessary for E2E communication. Maeda-san, Please summarize your ideas and the pros/cons after your draft is circulated. Regards, -- Hiroshi Tamura, Co-Chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Feb 19 13:37:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11295 for ; Mon, 19 Feb 2001 13:37:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA13592 for ietf-fax-bks; Mon, 19 Feb 2001 10:03:24 -0800 (PST) Received: from correo.007mundo.com ([63.171.232.45]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13568 for ; Mon, 19 Feb 2001 10:03:19 -0800 (PST) Received: from mail01bg ([192.168.168.21]) by correo.007mundo.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 19 Feb 2001 13:01:55 -0500 Received: from correo.007mundo.com ([192.168.170.2]) by mail01bg (NAVIEG 2.1 bld 63) with SMTP id M2001021913015211124 for ; Mon, 19 Feb 2001 13:01:53 -0500 From: To: Date: Mon, 19 Feb 2001 09:20:29 Message-Id: <786.897518.616652@correo.007mundo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit < get your own 100 meg web site for only $11.95 per month today! STOP PAYING $19.95 or more PER MONTH for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL OUR OFFICE. YOU CAN CHANGE YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 or fax 240 337 8325 WEB HOSTING INTERNATIONAL From owner-ietf-fax@mail.imc.org Tue Feb 20 05:12:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09586 for ; Tue, 20 Feb 2001 05:12:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA06190 for ietf-fax-bks; Tue, 20 Feb 2001 01:35:34 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA06186 for ; Tue, 20 Feb 2001 01:35:31 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id SAA28785; Tue, 20 Feb 2001 18:35:21 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma028658; Tue, 20 Feb 01 18:34:30 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id SAA00333; Tue, 20 Feb 2001 18:34:30 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id SAA15002; Tue, 20 Feb 2001 18:34:29 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id SAA14098; Tue, 20 Feb 2001 18:33:17 +0900 (JST) Message-Id: <4.2.0.58.J.20010220183656.00adaa90@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 20 Feb 2001 18:42:52 +0900 To: "McDonald, Ira" , "'Dan Wing'" From: MAEDA toru Subject: RE: Fax processing confirmation Cc: ietf-fax@imc.org, Claudio Allocchio, Hiroshi Tamura In-Reply-To: <1115A7CFAC25D311BC4000508B2CA5375ED072@mailsrvnt02.enet.sh arplabs.com> 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: Ira-san Thank you very much for detailed information about the IPP notification that it does not support page by page confirmation from the receiver. Fax wg should discuss about fax processing status. PWG IPP FAX WG may discuss about the fax processing status also. Regards. Toru Maeda At 12:59 01/02/17 -0800, McDonald, Ira wrote: >Hi Dan and IFax folks, > >Please note that IPP notifications (in-band via IPP channel >or out-of-band via SMTP or 'reverse' HTTP) are still >work-in-progress in the IETF IPP WG. > >IPP native protocol itself does NOT provide confirmation that >any pages have actually been printed without polling (by the >IPP Client) of the IPP Printer. > >The IEEE/ISTO PWG (Printer Working Group) has chartered IPPFax >project, but it isn't very far along yet. The IETF declined >to charter IPPFax as an IETF WG, so this is probably quite >far away from an IETF 'standards track' RFC. > >Cheers, >- Ira McDonald, consulting architect at Sharp and Xerox > (active member of IETF IPP WG, author of 'ipp:' URL scheme) > High North Inc > >-----Original Message----- >From: Dan Wing [mailto:dwing@cisco.com] >Sent: Friday, February 16, 2001 10:26 AM >To: MAEDA toru >Cc: ietf-fax@imc.org; Claudio Allocchio; Hiroshi Tamura >Subject: Re: Fax processing confirmation > > >On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote: > > > Wing-san > > > > How much confidence of ifax transmission in Simple Mode ? > > Does no response mean a good confirmation ? > > > > I want to add Fax processing confirmation in Full Mode. > > In Full Mode, the image file is send as TIFF file over SMTP. > > There will be some possibilities to fail to print or process > > the TIFF file by some reasons. These reasons may be > > incorrect TIFF parameter for the receiver > > or out of capabilities TIFF parameter for the receiver. > > > > When you put the 10 pages of document on the scanner > > and send by ifax Full Mode and you get the confirmation sheet > > with 9 pages received successfully, you will find something > > wrong with the scanner or the transmission. You will check > > the scanner or the system and may ask to the user of the receiver. > > > > Comparing to the E-mail system, you can not get information about > > how many pages the receiver successfully printed but just received. > > You may find that the attached file is not be able to be processed > > nor printed by the Email receiver with your inspiration. > > > > The user of Full Mode ifax will have confidence of the ifax > > transmission when the transmitter prints confirmation sheet > > with the number of pages printed on the receiver and also > > the number of page in error. > > > > Any comments? > >IPP provides this sort of confirmation today. Why not use IPP? > >-d -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 21 03:56:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21008 for ; Wed, 21 Feb 2001 03:56:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA28543 for ietf-fax-bks; Wed, 21 Feb 2001 00:03:51 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA28539 for ; Wed, 21 Feb 2001 00:03:48 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id RAA24122; Wed, 21 Feb 2001 17:03:34 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma023864; Wed, 21 Feb 01 17:02:12 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id RAA08040; Wed, 21 Feb 2001 17:02:12 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id RAA26031; Wed, 21 Feb 2001 17:02:11 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id RAA15304; Wed, 21 Feb 2001 17:00:57 +0900 (JST) Message-Id: <4.2.0.58.J.20010221164323.00a73538@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 21 Feb 2001 17:10:38 +0900 To: "Wagner,William" , "McDonald, Ira", ifx@pwg.org, ietf-fax@imc.org From: MAEDA toru Subject: RE: IFX> RE: Fax processing confirmation In-Reply-To: <3FEE3089984DD211ABCC00A0C9D346D001117B73@postoffice.netsil icon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit William-san Thank you very much for comments. I do not care that the IPP notification may still be "work in progress" or not. I think that the IPP notification describes print job results but not fax processing results. We have to think about difference between print job results and fax processing results. My questions are; (1) Does the current draft of the IPP notification include fax processing status which I proposed? (2) Which section in the IPP notification does describe it? (3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it, if the current draft of IPP notification does not describe it? (4) Will PWG IPP FAX wg define fax processing status in the IPP notification if required? (5) Can EIFAX and T.37 Full Mode use the IPP notification for fax processing results? Regards. Toru Maeda At 12:22 01/02/20 -0500, Wagner,William wrote: >Maeda-san, > >I think Ira McDonald's message may have been misunderstood. The IPP >notification may still be "work in progress". But, as indicated by the IESG >message below, the basic mechanisms are up for last call. These documents, >although they deal with many possible notification events and mechanisms, do >include "page by page confirmation from the receiver" (or more exactly, >sheet by sheet confirmation.) > >Further, although various notification mechanisms are identified, it is >assumed that sheet-by-sheet job progress notification is applicable >primarily to real-time notification connections which include the "indp" >method as well as the "get" method > alluded to by Ira. > >I suggest that the IP FAX community may be interested in commenting on these >notification approaches. > >I would also suggest that the various IFAX approaches each have advantages >in certain environments. T.37 uses virtually universal EMAIL capabilities. >T.38 (non-gateway) uses voice over IP, which suggests a voice/fax >capability. IPP has great flexibility, it can utilize developments in its >host HTTP protocol, and provides for authentication and encryption. It is >unclear that internet fax must settle on a single protocol. > >The IESG announcement, dated Mon 2/19/2001. follows. > >"The IESG has received a request from the Internet Printing Protocol >Working Group to consider Internet Printing Protocol (IPP):IPP Event >Notification Specification as a >Proposed Standard. > >The IESG will also consider publication of Internet Printing Protocol: >Requirements for IPP Notifications as an >Informational RFC. > > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by March 5, 2001. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-05.txt " > >Regards, > >William A. Wagner (Bill Wagner) >Director of Technology >Imaging Division >NETsilicon, Inc. >781-398-4588 > > >-----Original Message----- >From: MAEDA toru [mailto:maeda.toru@canon.co.jp] >Sent: Tuesday, February 20, 2001 4:45 AM >To: McDonald, Ira; ifx@pwg.org >Subject: IFX> RE: Fax processing confirmation > > >Ira-san > >Thank you very much for detailed information about the IPP notification >that it does not support page by page confirmation from the receiver. >Fax wg should discuss about fax processing status. >PWG IPP FAX WG may discuss about the fax processing status also. > >Regards. > >Toru Maeda > >At 12:59 01/02/17 -0800, McDonald, Ira wrote: > >Hi Dan and IFax folks, > > > >Please note that IPP notifications (in-band via IPP channel > >or out-of-band via SMTP or 'reverse' HTTP) are still > >work-in-progress in the IETF IPP WG. > > > >IPP native protocol itself does NOT provide confirmation that > >any pages have actually been printed without polling (by the > >IPP Client) of the IPP Printer. > > > >The IEEE/ISTO PWG (Printer Working Group) has chartered IPPFax > >project, but it isn't very far along yet. The IETF declined > >to charter IPPFax as an IETF WG, so this is probably quite > >far away from an IETF 'standards track' RFC. > > > >Cheers, > >- Ira McDonald, consulting architect at Sharp and Xerox > > (active member of IETF IPP WG, author of 'ipp:' URL scheme) > > High North Inc > > > >-----Original Message----- > >From: Dan Wing [mailto:dwing@cisco.com] > >Sent: Friday, February 16, 2001 10:26 AM > >To: MAEDA toru > >Cc: ietf-fax@imc.org; Claudio Allocchio; Hiroshi Tamura > >Subject: Re: Fax processing confirmation > > > > > >On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote: > > > > > Wing-san > > > > > > How much confidence of ifax transmission in Simple Mode ? > > > Does no response mean a good confirmation ? > > > > > > I want to add Fax processing confirmation in Full Mode. > > > In Full Mode, the image file is send as TIFF file over SMTP. > > > There will be some possibilities to fail to print or process > > > the TIFF file by some reasons. These reasons may be > > > incorrect TIFF parameter for the receiver > > > or out of capabilities TIFF parameter for the receiver. > > > > > > When you put the 10 pages of document on the scanner > > > and send by ifax Full Mode and you get the confirmation sheet > > > with 9 pages received successfully, you will find something > > > wrong with the scanner or the transmission. You will check > > > the scanner or the system and may ask to the user of the receiver. > > > > > > Comparing to the E-mail system, you can not get information about > > > how many pages the receiver successfully printed but just received. > > > You may find that the attached file is not be able to be processed > > > nor printed by the Email receiver with your inspiration. > > > > > > The user of Full Mode ifax will have confidence of the ifax > > > transmission when the transmitter prints confirmation sheet > > > with the number of pages printed on the receiver and also > > > the number of page in error. > > > > > > Any comments? > > > >IPP provides this sort of confirmation today. Why not use IPP? > > > >-d > >-------------------- >MAEDA TORU >MIE Development Div. 2 >CANON Inc. >-------------------- ----------------------------------- $B%-%d%N%s3t<02q; Wed, 21 Feb 2001 06:47:02 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA19690 for ietf-fax-bks; Wed, 21 Feb 2001 03:09:48 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA19686 for ; Wed, 21 Feb 2001 03:09:46 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id UAA22866; Wed, 21 Feb 2001 20:09:40 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma022685; Wed, 21 Feb 01 20:08:39 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id UAA24090; Wed, 21 Feb 2001 20:08:39 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id UAA22592; Wed, 21 Feb 2001 20:08:38 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id UAA25644; Wed, 21 Feb 2001 20:07:25 +0900 (JST) Message-Id: <4.2.0.58.J.20010221200854.00abb918@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 21 Feb 2001 20:17:05 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: draft-maeda-faxwg-terminal-mode-protocol-00.txt Cc: Hiroshi Tamura , Claudio Allocchio 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: Hi, I have submitted the internet draft and it is available from the on-line Internet-Drafts directories. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol for Terminal Mode Author(s) : T. Maeda Filename : draft-maeda-faxwg-terminal-mode-protocol-00.txt Pages : 8 Date : 16-Feb-01 This proposal describes a protocol which was proposed in ITU-T SG16 meeting on November 2000 at Geneva, for Terminal Mode. The Terminal Mode supports the transfer of image data, capabilities exchange and confirmation for Store and Forward internet fax terminals having limited memory and small CPU power. Terminal Mode also supports all features of Group 3 facsimile on the Internet using T.30 signals in capability exchange. -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 21 06:47:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22647 for ; Wed, 21 Feb 2001 06:47:15 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA20851 for ietf-fax-bks; Wed, 21 Feb 2001 03:11:30 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA20844 for ; Wed, 21 Feb 2001 03:11:23 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id UAA23115; Wed, 21 Feb 2001 20:11:23 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma023035; Wed, 21 Feb 01 20:10:51 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id UAA24249; Wed, 21 Feb 2001 20:10:50 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id UAA22736; Wed, 21 Feb 2001 20:10:49 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id UAA25755; Wed, 21 Feb 2001 20:09:36 +0900 (JST) Message-Id: <4.2.0.58.J.20010221201718.00aaf960@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 21 Feb 2001 20:19:16 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: draft-maeda-faxwg-terminal-mode-goal-00.txt Cc: Hiroshi Tamura , Claudio Allocchio 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: Hi, I have submitted the internet draft and it is available from the on-line Internet-Drafts directories. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol for Terminal Mode Author(s) : T. Maeda Filename : draft-maeda-faxwg-terminal-mode-goal-00.txt Pages : 5 Date : 16-Feb-01 This draft describes goals of Terminal Mode which was proposed in ITU-T SG16 meeting on November 2000 at Geneva. The Terminal Mode supports the transfer of image data, capabilities exchange and confirmation for Store and Forward internet fax terminals having limited memory and small CPU power. Terminal Mode also supports all features of Group 3 facsimile on the Internet using T.30 signals in capability exchange. -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 21 09:40:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27984 for ; Wed, 21 Feb 2001 09:40:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA04742 for ietf-fax-bks; Wed, 21 Feb 2001 05:58:01 -0800 (PST) Received: from pb-exch1.pb.scansoft.com (mail1.scansoft.com [198.71.66.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA04705 for ; Wed, 21 Feb 2001 05:57:51 -0800 (PST) Received: by pb-exch1.pb.scansoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Feb 2001 08:59:07 -0500 Message-ID: From: "Platt, Tim" To: "'ietf-fax@imc.org'" Subject: comments on draft-ietf-fax-tiff-fx-Extension1-00.txt Date: Wed, 21 Feb 2001 08:59:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To whom it may concern, Hello Not having commented on this list before, allow me to introduce myself. I am a developer with ScanSoft Inc., the leading provider of digital imaging software. ScanSoft develops OCR, Web publishing, electronic forms, document management, and media asset management software. I have reviewed the draft and in general it is fine. My comments appear below in descending order of importance. At the end of the document are editing comments that you may or may not want to pay attention to. Section E1.7, JBIG2 Color Extension of M Profile issues Consider a page that contains mostly small text, which has evenly colored characters. There is however, large text in a title or headline that has a color gradient running from top to bottom. The top of the title characters is a light color and the bottom is a dark version of the same color. For generality, assume that the large title or headline text cannot be isolated to a strip or stripe of its own. I would like to take advantage of the extensions proposed to make the smallest file possible. I want, however to be able to run OCR on all text, including the title or headline text for indexing purposes. To encode the large text with the color gradient faithfully, and yet use color tags to increase compressions I need to separate the title or headline text into a separate IFD. I have to put the text I wish to encode using the color tags in a separate IFD. Since the title or headline text may overlap other text in the Y direction I will need to use the n-layer extension of the M profile to put the title or headline text into a separate layer. This means I will have to OCR separate layers to retrieve all text for indexing. Depending on the OCR engine used it may be more or less difficult. I would need to combine the results of the separate passes into a single OCR result page to allow for indexing for searching, but also to allow hit highlighting on any page displayed for the search hit list. Why can't the color tags be associated with the mask layer? They are already there anyway. Then we could have a foreground layer associated with that mask layer that had actual color image data. In the mask layer, a JBIG2 symbol that had color tag data would be rendered with that color. JBIG2 symbols without color tag data would be rendered with the color from the foreground. If a sufficient amount of the foreground color is missing or some don't care color (like black) it would compress very well. This would handle the situation I have given above and yet leave all the text in the mask layer so only one OCR pass would be required. Another member of my group, who is leading the segmentation development effort, has recently asked me to ask you gentlemen if there would be such a provision to mix color tags and foreground color data for a single mask layer. He did this before I reviewed the your proposal, so it can be considered an independent corroboration of my request. Now, my fall back position is to have some way to mark in the file what mask layers are to be considered for OCR purposes. Perhaps a bit can be assigned form the NewSubFileType field that would indicate this. Note that this is a fall back position and not what I would really like to see. Section E1.6, T profile - Lossy and Lossless JBIG2 Black-and-White Fax profile issues Much of the same arguments about OCR and simpler mask layer planes above apply to black and white images where there is reversed video text. In this case, one could encode in a full M profile. The foreground and background layers would be used but with only black and white content. Presumably, even though this black and white foreground/background data were encoded with > one bits per pixel, they would still compress well. Better yet, if JBIG2 is used, then such a page could be encoded with a binary background, and a mask/foreground combination with color tags. This would require allowing a binary background. I do not have an opinion as to whether this should be a relaxation to the M profile or and extension to the T profile. If you did not want to use JBIG2 for the Primary IFD for some reason, then you cannot enable color tags. Why should you not be able to have a binary background AND foreground to indicate areas of reversed video while allowing OCR on all characters in the mask layer? Other issues In section E1.5.4.1 "may include a list of IDs in a SharedDataList". It might be good to note that SharedData IDs may be used in the future in some other way. You do not want to require a single SharedData ID to have a two-byte count of one in front of it. For instance, a stamp annotation may wish to point to a single SharedData ID so to keep stamp annotation small we do not want the extra two byte count overhead of a SharedDataList. Editing comments E1.4.1 (around line 11) does not read very well (to me) E1.4.4 (just before E1.4.5 line 48/49) this does not appear different from 8/10/00 version of RFC 2301 Thank you very much for your attention Timothy J. Platt tp@scansoft.com (978) 977-2068 From owner-ietf-fax@mail.imc.org Wed Feb 21 12:29:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03750 for ; Wed, 21 Feb 2001 12:29:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA19603 for ietf-fax-bks; Wed, 21 Feb 2001 08:50:08 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19598 for ; Wed, 21 Feb 2001 08:50:07 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA08980; Wed, 21 Feb 2001 08:48:22 -0800 (PST) Date: Wed, 21 Feb 2001 08:48:19 -0800 (PST) From: Dan Wing To: maeda.toru@canon.co.jp cc: IETF Internet Fax WG Subject: Re: I-D ACTION:draft-maeda-faxwg-fax-processing-status-00.txt In-Reply-To: <200102211144.GAA22226@ietf.org> Message-ID: <0102210845000.4753-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maeda-san, This needs to support both MDNs and DSNs. I noticed your email address in the Internet Draft is incorrect (.jo instead of .jp). -Dan Wing On Wed, 21 Feb 2001 06:44 -0500, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Fax Processing Status > Author(s) : T. Maeda > Filename : draft-maeda-faxwg-fax-processing-status-00.txt > Pages : 4 > Date : 20-Feb-01 > > This proposal describes a fax processing status which was requested > in ITU-T SG16 meeting on November 2000 at Geneva, for Full Mode. > The notification of success/failure of document processing and page > by page status from the receiver is very important feature for the > internet fax. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-maeda-faxwg-fax-processing-status-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-maeda-faxwg-fax-processing-status-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-maeda-faxwg-fax-processing-status-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ietf-fax@mail.imc.org Wed Feb 21 12:40:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04020 for ; Wed, 21 Feb 2001 12:40:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA19771 for ietf-fax-bks; Wed, 21 Feb 2001 08:58:17 -0800 (PST) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA19765 for ; Wed, 21 Feb 2001 08:58:15 -0800 (PST) Date: Wed, 21 Feb 2001 17:57:48 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: WG Last Call for draft-ietf-fax-implementers-guide-06.txt Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear ietf fax WG, as there were no further comments to the document draft-ietf-fax-implementers-guide-06.txt I believe it is time to issue the WG last call. Please send your "last comments" before March 9th 2001. After that date we will as the IESG to consider the document for publication as an Informational RFC. Here is the "summary". Regards Claudio Allocchio ---------------------------------------------------------------- - Implementers Guide for Facsimile Using Internet Mail - draft-ietf-fax-implementers-guide-06.txt Status: Informational Summary: This document clarifies published RFCs such as RFC 2301, RFC 2305 and RFC 2532, which standardize facsimile communications using Internet Email. The intent is to prevent implementations that deviate in such a way as to cause interoperability problems. ---------------------------------------------------------------- From owner-ietf-fax@mail.imc.org Wed Feb 21 12:51:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04222 for ; Wed, 21 Feb 2001 12:51:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA20249 for ietf-fax-bks; Wed, 21 Feb 2001 09:11:41 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20245 for ; Wed, 21 Feb 2001 09:11:40 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.26.42]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA01471; Wed, 21 Feb 2001 09:11:12 -0800 (PST) Date: Wed, 21 Feb 2001 09:11:11 -0800 (PST) From: Dan Wing To: IETF Internet Fax WG cc: MAEDA toru Subject: identifying parts Message-ID: <0102210848380.4753-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This question is related to draft-maeda-faxwg-fax-processing-status-00.txt. A long time ago, I recall that some ifax sending devices would (or could) send a multiple pages as multiple one-page TIFF attachments. Here is a description of several different valid messages which describe the problem I see with the current proposal in draft-maeda-faxwg-fax-processing-status-00.txt. The problem is that it cannot identify the "page" successfully -- the definition of a page is different from the sender and the receiver's view. Email allows much richer operation than scanning, transmitting, and printing. This richer operation means a straight-forward "page NNN failed" is not sufficient for email. A proposal to resolve this problem is below. The proposal allows operation as described in draft-maeda-faxwg-fax-processing-status-00.txt while also allowing the richer operation of email. Method 1: From: someone@default.com To: someone-else@default.com Subject: 3 page fax Message-ID: <123@default.com> Date: 1 Jan 2001 01:00:00 -0800 Content-Type: multipart/mixed; boundary=ABC --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC-- Method 2: From: someone@default.com To: someone-else@default.com Subject: 3 page fax Message-ID: <123@default.com> Date: 1 Jan 2001 01:00:00 -0800 Content-Type: multipart/mixed; boundary=ABC --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC-- Method 3: From: someone@default.com To: someone-else@default.com Subject: 3 page fax Message-ID: <123@default.com> Date: 1 Jan 2001 01:00:00 -0800 Content-Type: multipart/mixed; boundary=ABC --ABC Content-type: text/plain FAX COVERSHEET From: Jim To: Susan Date: 1 Jan 2001 01:00:00, Pacific Time Contact: jim@default.com, 408-555-1212 Susan, Here is the fax you requested. There should be 4 pages total (this coversheet, plus 3 pages of the fax content itself). --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC-- To support non-ASCII languages on the coversheet, the first part in Method 3 could be image/tiff which contains a graphical representation of the coversheet. Method 4: From: someone@default.com To: someone-else@default.com Subject: 3 page fax Message-ID: <123@default.com> Date: 1 Jan 2001 01:00:00 -0800 Content-Type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ Method 5: From: someone@default.com To: someone-else@default.com Subject: your two faxes: Sumerset, Egghead Content-Type: multipart/mixed; boundary=ABC Date: 1 Jan 2001 01:00:00 -0800 Message-ID: <123@default.com> --ABC Content-type: text/plain FAX COVERSHEET From: Jim To: Susan Date: 1 Jan 2001 01:00:00, Pacific Time Contact: jim@default.com, 408-555-1212 Susan, Here are your two faxes. The first one is a 3 page fax from Sumerset, Inc. The second one is a 9 page fax from Egghead. Thanks. Jim --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC content-type: image/tiff content-transfer-encoding: base64 EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ --ABC-- I _believe_ that most dedicated ifax devices use Method 4, above. I believe most of the typical mailers (Netscape, Eudora, Outlook) would use Method 2 or Method 3, above. I feel it is critical that any MDN or DSN response indicating a portion of a message was successfully or unsuccessfully processed must also indicate which MIME part is being described in the MDN or DSN reponse -- it is NOT as simple as the "page" having the problem, especially if Method 1 is used -- they are all page "1" from the view of the sender. Method 1 is a valid message format and is allowed, so we must handle it correctly. I propose we require the use of Content-ID to identify MIME parts. This identification allows the MDN to indicate which part(s) were successfully or unsuccessfully processed. Content-ID is described in RFC2045, section 7. Its use is discussed in RFC2046. -Dan Wing From owner-ietf-fax@mail.imc.org Wed Feb 21 18:16:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13642 for ; Wed, 21 Feb 2001 18:16:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA29230 for ietf-fax-bks; Wed, 21 Feb 2001 14:31:56 -0800 (PST) Received: from postoffice.netsilicon.com (postoffice.netsilicon.com [199.93.124.180]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29223 for ; Wed, 21 Feb 2001 14:31:54 -0800 (PST) Received: by postoffice.netsilicon.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Feb 2001 17:30:25 -0500 Message-ID: <3FEE3089984DD211ABCC00A0C9D346D001117B87@postoffice.netsilicon.com> From: "Wagner,William" To: "'MAEDA toru'" , "McDonald, Ira" , ifx@pwg.org, ietf-fax@imc.org Subject: RE: IFX> RE: Fax processing confirmation Date: Wed, 21 Feb 2001 17:30:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maeda-san, Thank you for your response. I will address your questions as best as I can. I understand that IPP appears printer-oriented rather than Facsimile oriented. Correcting that and adding the necessary facsimile features is one reason for the IPP FAX effort. We must consider what notification parameters are significant to the end user in his desire to communicate a document. It is not clear to me that these parameters are so different between remote printing and facsimile. Your questions were: 1) Does the current draft of the IPP notification include fax processing status which I proposed? I understand you have proposed "success/failure of document processing and page by page status from the receiver" In a TCP connection, the lower layers ensure the integrity of the transmitted data (or report the inability to sustain a connection); therefore, notification of transmission problems are already covered in any TCP based transmission.. It is possible for any transmission (including telephone) to be handled by an intermediate server thereby losing the ability to report on document processing immediately as the document is transmitted. If there is no intermediate server, IPP provides mechanisms for delivering processing information during and immediately after transmission. If there is an intermediate server, defined notification delivery mechanisms such as MAIL_TO (EMAIL message) can still be used to provide notification of final disposition; it is assumed that sheet-by-sheet notification by email would not be practical. Further, the attributes already defined include the sheet-by-sheet completion as well as satisfactory completion with job statistics (e.g., number of sheets printed). The use of sheets rather than pages reflects the desire to communicate the end result in terms of hardcopy emerging from the receiver. The use of sheets avoids the question of two sided or multiple page up printing. (2) Which section in the IPP notification does describe it? The notification mechanism is very general, and only a subset would apply to fax. But see 5.3.2.1.3 Subscribed Job Events in , especially Job-State-Changed and Job_Progress *(printing a sheet). The sender can "subscribe" to the desired notification events when the job is sent. These events (such as printing a sheet) trigger a notification to the sender or other designated destination with appropriate attribute values. The subscription also defines the method of notification delivery, of which three methods have been documented in current internet drafts. (, and ) It is likely that, in a fax application, there will be a preferred eventing and delivery, so that the whole gamut of IPP capabilities need not be addressed. (3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it, if the current draft of IPP notification does not describe it? I suggest that the IPP FAX working group would be more than happy to discuss additional attribute and feature requirements from the facsimile community. (4) Will PWG IPP FAX wg define fax processing status in the IPP notification if required? The IPP FAX wg intends to add to the basic IPP capability what is needed to provide FAX functionality to the end users. (5) Can EIFAX and T.37 Full Mode use the IPP notification for fax processing results? Although IPP Notification was not designed to be an all purpose notification capability, it includes may features and other facsimile modes could use a subset of the IPP notification capability. It is not immediately clear to me whether this would be a good idea, although, if devices included a multi-mode Ifax capability, a common notification scheme may have advantages. Best regards, Bill Wagner -----Original Message----- From: MAEDA toru [mailto:maeda.toru@canon.co.jp] Sent: Wednesday, February 21, 2001 3:11 AM To: Wagner,William; McDonald, Ira; ifx@pwg.org; ietf-fax@imc.org Subject: RE: IFX> RE: Fax processing confirmation William-san Thank you very much for comments. I do not care that the IPP notification may still be "work in progress" or not. I think that the IPP notification describes print job results but not fax processing results. We have to think about difference between print job results and fax processing results. My questions are; (1) Does the current draft of the IPP notification include fax processing status which I proposed? (2) Which section in the IPP notification does describe it? (3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it, if the current draft of IPP notification does not describe it? (4) Will PWG IPP FAX wg define fax processing status in the IPP notification if required? (5) Can EIFAX and T.37 Full Mode use the IPP notification for fax processing results? Regards. Toru Maeda At 12:22 01/02/20 -0500, Wagner,William wrote: >Maeda-san, > >I think Ira McDonald's message may have been misunderstood. The IPP >notification may still be "work in progress". But, as indicated by the IESG >message below, the basic mechanisms are up for last call. These documents, >although they deal with many possible notification events and mechanisms, do >include "page by page confirmation from the receiver" (or more exactly, >sheet by sheet confirmation.) > >Further, although various notification mechanisms are identified, it is >assumed that sheet-by-sheet job progress notification is applicable >primarily to real-time notification connections which include the "indp" >method as well as the "get" method > alluded to by Ira. > >I suggest that the IP FAX community may be interested in commenting on these >notification approaches. > >I would also suggest that the various IFAX approaches each have advantages >in certain environments. T.37 uses virtually universal EMAIL capabilities. >T.38 (non-gateway) uses voice over IP, which suggests a voice/fax >capability. IPP has great flexibility, it can utilize developments in its >host HTTP protocol, and provides for authentication and encryption. It is >unclear that internet fax must settle on a single protocol. > >The IESG announcement, dated Mon 2/19/2001. follows. > >"The IESG has received a request from the Internet Printing Protocol >Working Group to consider Internet Printing Protocol (IPP):IPP Event >Notification Specification as a >Proposed Standard. > >The IESG will also consider publication of Internet Printing Protocol: >Requirements for IPP Notifications as an >Informational RFC. > > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by March 5, 2001. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-05.txt " > >Regards, > >William A. Wagner (Bill Wagner) >Director of Technology >Imaging Division >NETsilicon, Inc. >781-398-4588 > > >-----Original Message----- >From: MAEDA toru [mailto:maeda.toru@canon.co.jp] >Sent: Tuesday, February 20, 2001 4:45 AM >To: McDonald, Ira; ifx@pwg.org >Subject: IFX> RE: Fax processing confirmation > > >Ira-san > >Thank you very much for detailed information about the IPP notification >that it does not support page by page confirmation from the receiver. >Fax wg should discuss about fax processing status. >PWG IPP FAX WG may discuss about the fax processing status also. > >Regards. > >Toru Maeda > >At 12:59 01/02/17 -0800, McDonald, Ira wrote: > >Hi Dan and IFax folks, > > > >Please note that IPP notifications (in-band via IPP channel > >or out-of-band via SMTP or 'reverse' HTTP) are still > >work-in-progress in the IETF IPP WG. > > > >IPP native protocol itself does NOT provide confirmation that > >any pages have actually been printed without polling (by the > >IPP Client) of the IPP Printer. > > > >The IEEE/ISTO PWG (Printer Working Group) has chartered IPPFax > >project, but it isn't very far along yet. The IETF declined > >to charter IPPFax as an IETF WG, so this is probably quite > >far away from an IETF 'standards track' RFC. > > > >Cheers, > >- Ira McDonald, consulting architect at Sharp and Xerox > > (active member of IETF IPP WG, author of 'ipp:' URL scheme) > > High North Inc > > > >-----Original Message----- > >From: Dan Wing [mailto:dwing@cisco.com] > >Sent: Friday, February 16, 2001 10:26 AM > >To: MAEDA toru > >Cc: ietf-fax@imc.org; Claudio Allocchio; Hiroshi Tamura > >Subject: Re: Fax processing confirmation > > > > > >On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote: > > > > > Wing-san > > > > > > How much confidence of ifax transmission in Simple Mode ? > > > Does no response mean a good confirmation ? > > > > > > I want to add Fax processing confirmation in Full Mode. > > > In Full Mode, the image file is send as TIFF file over SMTP. > > > There will be some possibilities to fail to print or process > > > the TIFF file by some reasons. These reasons may be > > > incorrect TIFF parameter for the receiver > > > or out of capabilities TIFF parameter for the receiver. > > > > > > When you put the 10 pages of document on the scanner > > > and send by ifax Full Mode and you get the confirmation sheet > > > with 9 pages received successfully, you will find something > > > wrong with the scanner or the transmission. You will check > > > the scanner or the system and may ask to the user of the receiver. > > > > > > Comparing to the E-mail system, you can not get information about > > > how many pages the receiver successfully printed but just received. > > > You may find that the attached file is not be able to be processed > > > nor printed by the Email receiver with your inspiration. > > > > > > The user of Full Mode ifax will have confidence of the ifax > > > transmission when the transmitter prints confirmation sheet > > > with the number of pages printed on the receiver and also > > > the number of page in error. > > > > > > Any comments? > > > >IPP provides this sort of confirmation today. Why not use IPP? > > > >-d > >-------------------- >MAEDA TORU >MIE Development Div. 2 >CANON Inc. >-------------------- ----------------------------------- $B%-%d%N%s3t<02q; Wed, 21 Feb 2001 19:57:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA06450 for ietf-fax-bks; Wed, 21 Feb 2001 16:14:00 -0800 (PST) Received: from himalia.eastgw.xerox.com (himalia.xerox.com [208.140.33.21]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA06440 for ; Wed, 21 Feb 2001 16:13:57 -0800 (PST) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by himalia.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id TAA06657; Wed, 21 Feb 2001 19:13:53 -0500 (EST) 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 QAA24064; Wed, 21 Feb 2001 16:13:51 -0800 (PST) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Feb 2001 16:13:50 -0800 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A3066@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Tim Platt'" , "'IETF fax WG'" Subject: RE: comments on draft-ietf-fax-tiff-fx-Extension1-00.txt Date: Wed, 21 Feb 2001 16:13:49 -0800 Importance: high X-Priority: 1 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: Tim, Thanks you for your very constructive comment. Please see my response below, Lloyd > -----Original Message----- > From: Platt, Tim [mailto:tp@scansoft.com] > Sent: Wednesday, February 21, 2001 5:59 AM > To: 'ietf-fax@imc.org' > Subject: comments on draft-ietf-fax-tiff-fx-Extension1-00.txt > > > To whom it may concern, > > Hello > > Not having commented on this list before, allow me to > introduce myself. > I am a developer with ScanSoft Inc., the leading provider of > digital imaging > software. ScanSoft develops OCR, Web publishing, electronic > forms, document > management, and media asset management software. > > I have reviewed the draft and in general it is fine. My > comments appear > below in descending order of importance. At the end of the > document are > editing comments that you may or may not want to pay attention to. > > Section E1.7, JBIG2 Color Extension of M Profile issues > > Consider a page that contains mostly small text, which has > evenly colored > characters. There is however, large text in a title or > headline that has a > color gradient running from top to bottom. The top of the > title characters > is a light color and the bottom is a dark version of the same > color. For > generality, assume that the large title or headline text > cannot be isolated > to a strip or stripe of its own. > > I would like to take advantage of the extensions proposed to make the > smallest file possible. I want, however to be able to run > OCR on all text, > including the title or headline text for indexing purposes. > > To encode the large text with the color gradient faithfully, > and yet use > color tags to increase compressions I need to separate the > title or headline > text into a separate IFD. This is close but not quite accurate. The title or headline text needs to be placed in a separate TIFF strip from the one containing the regular text, however both strips would be contained within a single mask layer IFD. The gradient color of the title or headline text would be represented in a foreground IFD that corresponds to the title or headline text strip within the mask layer IFD. The colors of the regular text (i.e. flat non-gradient colors) would be in a separate foreground IFD. Page Image _________________________ | Gradient Color Title | | | | Regular text, | | composed of flat non- | | gradient colors. | | dkjtieh;jgjgjgejhjjjig | | thogh ghotgjrepggh hf. | |_________________________| JPEG coded Foreground layer JBIG2 coded Mask layer IFD IFD 1 with 2 strips ------------------------- ------------------------- ] Gradient Color [ ] Gradient Color Title [ ------------------------- ]+++++++++++++++++++++++++[ ] Regular text, [ Color Tag coded Foreground layer ] composed of flat non- [ IFD 2 ] gradient colors. [ ------------------------- ] dkjtieh;jgjgjgejhjjjig [ ] Regular flat colors [ ] thogh ghotgjrepggh hf. [ ] colors colors [ ------------------------- ] colors colors [ ] colors colors [ ] colors colors [ ------------------------- For more complex pages where it is not possible to split the color gradient text and the flat color text into two or more strips, it may be best to forego use of color tags and simply JPEG encode the entire foreground layer. The file will not be as small, however, you will retain a simple structure that is conducive to OCR. > I have to put the text I wish to > encode using the > color tags in a separate IFD. Since the title or headline > text may overlap > other text in the Y direction I will need to use the n-layer > extension of > the M profile to put the title or headline text into a > separate layer. This > means I will have to OCR separate layers to retrieve all text > for indexing. Given the representation above, which contains a single mask IFD with two stripes (i.e. stripe 1 containing title or headline text plus any regular text that may be overlapped in the Y direction and stripe 2 containing regular text) and two foreground IFDs, there is no need to use n-layers. OCR can be run on the single mask layer to retrieve all text for indexing. > Depending on the OCR engine used it may be more or less > difficult. I would > need to combine the results of the separate passes into a > single OCR result > page to allow for indexing for searching, but also to allow > hit highlighting > on any page displayed for the search hit list. > > Why can't the color tags be associated with the mask layer? They ARE associated with the mask layer. Please see Section E1.7.7.2 on color tag terms of use, the color tags are augmented to the binary JBIG2 portion, but referenced together with the binary image as the foreground image. > They are > already there anyway. Then we could have a foreground layer > associated with > that mask layer that had actual color image data. In the > mask layer, a > JBIG2 symbol that had color tag data would be rendered with > that color. > JBIG2 symbols without color tag data would be rendered with > the color from > the foreground. There is no way to handle two separate color encodings within a single foreground IFD, additionally mask layers are strictly binary - mask layer IFDs cannot have color content. The TIFF rules require different encodings to be placed in separate IFDs. In the representation above, the binary mask layer IFD is JBIG2 encoded (i.e. each symbol instance is represented by a triplet consisting of its XPosition, YPosition plus symbol ID). Foreground IFD1 is associated with the first strip of the mask IFD and it contains the gradient colors of the title or headline text. Foreground IFD1 is coded with a convention color coder such as JPEG. Foreground IFD2 is associated with the second strip of the mask IFD and it contains the flat colors of the regular text, which is color tag encoded. This means that the foreground image is also JBIG2 encoded and each JBIG2 symbol instance is augmented with a color tag or color name. This results in quad, consisting of XPosition, YPosition, symbol ID plus color tag. Obviously the JBIG2 coded XPosition, YPosition and symbol ID portion of the foreground quad is identical to that of the mask triplet. The draft recognizes this redundancy and accommodates it by requiring only a single representation of the JBIG2 bi-level data. The mask IFD would contain the ColourTagsFollow flag, alerting the decoder that the foreground will point to the same block of data that is used by the mask IFD. The byte count is, however, increased to include the color tags. > If a sufficient amount of the foreground > color is missing > or some don't care color (like black) it would compress very > well. This > would handle the situation I have given above and yet leave > all the text in > the mask layer so only one OCR pass would be required. > > Another member of my group, who is leading the segmentation > development > effort, has recently asked me to ask you gentlemen if there > would be such a > provision to mix color tags and foreground color data for a > single mask > layer. He did this before I reviewed the your proposal, so it can be > considered an independent corroboration of my request. As stated above, using a single mask IFD that contains two or more strips plus two or more corresponding foreground IFDs, make it possible to mix both color tags and normal bit-map color representation while using a single JBIG2 mask. > > Now, my fall back position is to have some way to mark in the > file what mask > layers are to be considered for OCR purposes. Perhaps a bit > can be assigned > form the NewSubFileType field that would indicate this. Note > that this is a > fall back position and not what I would really like to see. I hope that you are now comfortable that this is not necessary. > > Section E1.6, T profile - Lossy and Lossless JBIG2 Black-and-White Fax > profile issues > > Much of the same arguments about OCR and simpler mask layer > planes above > apply to black and white images where there is reversed video > text. In this > case, one could encode in a full M profile. The foreground > and background > layers would be used but with only black and white content. Profile T does allow 3 layers, with the explicit reasoning of allowing the reverse video scenario. In this case only black and white are allowed as background and foreground colors, and are set using the ImageBaseColor field, and the 0-byte strips option. This is addressed specifically in Section E1.6.2.1, StripByteCounts. > Presumably, even > though this black and white foreground/background data were > encoded with > > one bits per pixel, they would still compress well. Better > yet, if JBIG2 is > used, then such a page could be encoded with a binary > background, and a > mask/foreground combination with color tags. This would > require allowing a > binary background. I do not have an opinion as to whether > this should be a > relaxation to the M profile or and extension to the T > profile. If you did > not want to use JBIG2 for the Primary IFD for some reason, > then you cannot > enable color tags. Why should you not be able to have a > binary background > AND foreground to indicate areas of reversed video while > allowing OCR on all > characters in the mask layer? Given that the draft does handle reverse video within the context of the rules, there is no need to bend or break the MRC model or TIFF-FX rules. > > Other issues > > In section E1.5.4.1 "may include a list of IDs in a > SharedDataList". It > might be good to note that SharedData IDs may be used in the > future in some > other way. You do not want to require a single SharedData ID > to have a > two-byte count of one in front of it. For instance, a stamp > annotation may > wish to point to a single SharedData ID so to keep stamp > annotation small we > do not want the extra two byte count overhead of a SharedDataList. If the intention is to reduce the file size, then the alternative that I think you're implying is to use a 1-byte count instead. This might be limiting, in that a single data block could only reference up to 255 shared data items. This may or may not be reasonable, but it would be foolish to limit it like this. I believe that the savings in using a shared resource for something larger than two bytes will make up for something that would otherwise be more than two bytes, repeated in every page. If you suspect that many data items will have a count of zero, and that they will all incur the 2-byte overhead, then define the data stream such that no SharedDataList is ever used. It's only for data that might use a shared resource, and in this case, must at least have the 2-byte count of zero. I believe it is appropriate to strengthen the requirement by changing the word "may" in the first sentence of E1.5.4.1 to "SHALL". > > Editing comments > > E1.4.1 (around line 11) does not read very well (to me) I will revise. > E1.4.4 (just before E1.4.5 line 48/49) this does not appear > different from > 8/10/00 version of RFC 2301 I will delete. > > Thank you very much for your attention > > Timothy J. Platt > tp@scansoft.com > (978) 977-2068 > From owner-ietf-fax@mail.imc.org Wed Feb 21 20:54:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16172 for ; Wed, 21 Feb 2001 20:54:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA08856 for ietf-fax-bks; Wed, 21 Feb 2001 17:15:33 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA08850 for ; Wed, 21 Feb 2001 17:15:31 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id KAA25297; Thu, 22 Feb 2001 10:15:30 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma025048; Thu, 22 Feb 01 10:14:00 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id KAA27754; Thu, 22 Feb 2001 10:14:00 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id KAA16816; Thu, 22 Feb 2001 10:13:59 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id KAA26665; Thu, 22 Feb 2001 10:12:45 +0900 (JST) Message-Id: <4.2.0.58.J.20010222101727.00a86b48@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 22 Feb 2001 10:22:24 +0900 To: Dan Wing From: MAEDA toru Subject: Re: I-D ACTION:draft-maeda-faxwg-fax-processing-status-00.txt Cc: IETF Internet Fax WG In-Reply-To: <0102210845000.4753-100000@omega.cisco.com> References: <200102211144.GAA22226@ietf.org> 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: Wing-san Thank you very much for pointing out typo which is very important part of the draft. I found same type in my 3 IDs (terminal mode protocol and terminal mode goals). I will reissue the drafts soon. Regards. Toru Maeda At 08:48 01/02/21 -0800, Dan Wing wrote: >Maeda-san, > >This needs to support both MDNs and DSNs. > >I noticed your email address in the Internet Draft is incorrect (.jo >instead of .jp). > >-Dan Wing > > >On Wed, 21 Feb 2001 06:44 -0500, Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Fax Processing Status > > Author(s) : T. Maeda > > Filename : draft-maeda-faxwg-fax-processing-status-00.txt > > Pages : 4 > > Date : 20-Feb-01 > > > > This proposal describes a fax processing status which was requested > > in ITU-T SG16 meeting on November 2000 at Geneva, for Full Mode. > > The notification of success/failure of document processing and page > > by page status from the receiver is very important feature for the > > internet fax. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-maeda-faxwg-fax-processing-statu > s-00.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-maeda-faxwg-fax-processing-status-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-maeda-faxwg-fax-processing-status-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 21 21:01:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16269 for ; Wed, 21 Feb 2001 21:01:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA09349 for ietf-fax-bks; Wed, 21 Feb 2001 17:22:39 -0800 (PST) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09342 for ; Wed, 21 Feb 2001 17:22:37 -0800 (PST) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id UAA00699; Wed, 21 Feb 2001 20:22:40 -0500 (EST) 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 RAA25253; Wed, 21 Feb 2001 17:22:37 -0800 (PST) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Feb 2001 17:22:37 -0800 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A306C@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Wagner,William'" , "'MAEDA toru'" , "McDonald, Ira" , ifx@pwg.org, ietf-fax@imc.org Subject: RE: IFX> RE: Fax processing confirmation Date: Wed, 21 Feb 2001 17:22:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For those wondering what value there is in providing notification information that distinguishes the processing status of each page, let me clarify by stating that it is possible to send a file that contains more than one encodings. Envision a document with both black-and-white and color pages. It is more efficient, both in file size and image quality, to code the black-and-white pages with a bi-level coder such as MMR (G4) and the color pages with a multi-level coder such as JPEG. TIFF-FX does not restrict both encoding being interleaved throughout the file. Given this condition, it is conceivable that a decoder may able to render the bi-level but not the color pages. The draft-ietf-fax-tiff-fx-Extension1-01.txt draft makes provision for signaling such mixed content documents/files so that a decoder will not be caught off guard. Lloyd > -----Original Message----- > From: Wagner,William [mailto:wwagner@netsilicon.com] > Sent: Wednesday, February 21, 2001 2:30 PM > To: 'MAEDA toru'; McDonald, Ira; ifx@pwg.org; ietf-fax@imc.org > Subject: RE: IFX> RE: Fax processing confirmation > > > Maeda-san, > > Thank you for your response. I will address your questions as > best as I can. > I understand that IPP appears printer-oriented rather than Facsimile > oriented. Correcting that and adding the necessary facsimile > features is one > reason for the IPP FAX effort. We must consider what > notification parameters > are significant to the end user in his desire to communicate > a document. It > is not clear to me that these parameters are so different > between remote > printing and facsimile. > > Your questions were: > > 1) Does the current draft of the IPP notification include fax > processing > status which I proposed? > > I understand you have proposed "success/failure of document > processing and > page by page status from the receiver" > > In a TCP connection, the lower layers ensure the integrity of the > transmitted data (or report the inability to sustain a connection); > therefore, notification of transmission problems are already > covered in any > TCP based transmission.. > > It is possible for any transmission (including telephone) to > be handled by > an intermediate server thereby losing the ability to report > on document > processing immediately as the document is transmitted. If there is no > intermediate server, IPP provides mechanisms for delivering processing > information during and immediately after transmission. If there is an > intermediate server, defined notification delivery mechanisms such as > MAIL_TO (EMAIL message) can still be used to provide > notification of final > disposition; it is assumed that sheet-by-sheet notification > by email would > not be practical. > > Further, the attributes already defined include the sheet-by-sheet > completion as well as satisfactory completion with job > statistics (e.g., > number of sheets printed). The use of sheets rather than > pages reflects the > desire to communicate the end result in terms of hardcopy > emerging from the > receiver. The use of sheets avoids the question of two sided > or multiple > page up printing. > > (2) Which section in the IPP notification does describe it? > > The notification mechanism is very general, and only a subset > would apply to > fax. But see 5.3.2.1.3 Subscribed Job Events in > , especially Job-State-Changed and > Job_Progress *(printing a sheet). The sender can "subscribe" > to the desired > notification events when the job is sent. These events (such > as printing a > sheet) trigger a notification to the sender or other > designated destination > with appropriate attribute values. > > The subscription also defines the method of notification > delivery, of which > three methods have been documented in current internet drafts. > (, > and > ) > > It is likely that, in a fax application, there will be a > preferred eventing > and delivery, so that the whole gamut of IPP capabilities need not be > addressed. > > > > (3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it, if > the current > draft of IPP notification does not describe it? > > I suggest that the IPP FAX working group would be more than > happy to discuss > additional attribute and feature requirements from the facsimile > community. > > > (4) Will PWG IPP FAX wg define fax processing status in the > IPP notification > if required? > > The IPP FAX wg intends to add to the basic IPP capability > what is needed to > provide FAX functionality to the end users. > > > (5) Can EIFAX and T.37 Full Mode use the IPP notification for > fax processing > results? > > Although IPP Notification was not designed to be an all > purpose notification > capability, it includes may features and other facsimile > modes could use a > subset of the IPP notification capability. It is not > immediately clear to > me whether this would be a good idea, although, if devices included a > multi-mode Ifax capability, a common notification scheme may have > advantages. > > Best regards, > > Bill Wagner > > > -----Original Message----- > From: MAEDA toru [mailto:maeda.toru@canon.co.jp] > Sent: Wednesday, February 21, 2001 3:11 AM > To: Wagner,William; McDonald, Ira; ifx@pwg.org; ietf-fax@imc.org > Subject: RE: IFX> RE: Fax processing confirmation > > > William-san > > Thank you very much for comments. > I do not care that the IPP notification may still be "work in > progress" or > not. > I think that the IPP notification describes print job results > but not fax > processing results. > We have to think about difference between print job results and fax > processing results. > > My questions are; > (1) Does the current draft of the IPP notification include > fax processing > status which I proposed? > (2) Which section in the IPP notification does describe it? > (3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it, > if the current draft of IPP notification does not describe it? > (4) Will PWG IPP FAX wg define fax processing status in the IPP > notification if required? > (5) Can EIFAX and T.37 Full Mode use the IPP notification for fax > processing results? > > > Regards. > > Toru Maeda > > > At 12:22 01/02/20 -0500, Wagner,William wrote: > >Maeda-san, > > > >I think Ira McDonald's message may have been misunderstood. The IPP > >notification may still be "work in progress". But, as > indicated by the IESG > >message below, the basic mechanisms are up for last call. > These documents, > >although they deal with many possible notification events > and mechanisms, > do > >include "page by page confirmation from the receiver" (or > more exactly, > >sheet by sheet confirmation.) > > > >Further, although various notification mechanisms are > identified, it is > >assumed that sheet-by-sheet job progress notification is applicable > >primarily to real-time notification connections which > include the "indp" > >method as well as the > "get" method > > alluded to by Ira. > > > >I suggest that the IP FAX community may be interested in > commenting on > these > >notification approaches. > > > >I would also suggest that the various IFAX approaches each > have advantages > >in certain environments. T.37 uses virtually universal EMAIL > capabilities. > >T.38 (non-gateway) uses voice over IP, which suggests a voice/fax > >capability. IPP has great flexibility, it can utilize > developments in its > >host HTTP protocol, and provides for authentication and > encryption. It is > >unclear that internet fax must settle on a single protocol. > > > >The IESG announcement, dated Mon 2/19/2001. follows. > > > >"The IESG has received a request from the Internet Printing Protocol > >Working Group to consider Internet Printing Protocol (IPP):IPP Event > >Notification Specification as a > >Proposed Standard. > > > >The IESG will also consider publication of Internet Printing > Protocol: > >Requirements for IPP Notifications as an > >Informational RFC. > > > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send any comments to the > >iesg@ietf.org or ietf@ietf.org mailing lists by March 5, 2001. > > > >Files can be obtained via > >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt > >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-05.txt " > > > >Regards, > > > >William A. Wagner (Bill Wagner) > >Director of Technology > >Imaging Division > >NETsilicon, Inc. > >781-398-4588 > > > > > >-----Original Message----- > >From: MAEDA toru [mailto:maeda.toru@canon.co.jp] > >Sent: Tuesday, February 20, 2001 4:45 AM > >To: McDonald, Ira; ifx@pwg.org > >Subject: IFX> RE: Fax processing confirmation > > > > > >Ira-san > > > >Thank you very much for detailed information about the IPP > notification > >that it does not support page by page confirmation from the receiver. > >Fax wg should discuss about fax processing status. > >PWG IPP FAX WG may discuss about the fax processing status also. > > > >Regards. > > > >Toru Maeda > > > >At 12:59 01/02/17 -0800, McDonald, Ira wrote: > > >Hi Dan and IFax folks, > > > > > >Please note that IPP notifications (in-band via IPP channel > > >or out-of-band via SMTP or 'reverse' HTTP) are still > > >work-in-progress in the IETF IPP WG. > > > > > >IPP native protocol itself does NOT provide confirmation that > > >any pages have actually been printed without polling (by the > > >IPP Client) of the IPP Printer. > > > > > >The IEEE/ISTO PWG (Printer Working Group) has chartered IPPFax > > >project, but it isn't very far along yet. The IETF declined > > >to charter IPPFax as an IETF WG, so this is probably quite > > >far away from an IETF 'standards track' RFC. > > > > > >Cheers, > > >- Ira McDonald, consulting architect at Sharp and Xerox > > > (active member of IETF IPP WG, author of 'ipp:' URL scheme) > > > High North Inc > > > > > >-----Original Message----- > > >From: Dan Wing [mailto:dwing@cisco.com] > > >Sent: Friday, February 16, 2001 10:26 AM > > >To: MAEDA toru > > >Cc: ietf-fax@imc.org; Claudio Allocchio; Hiroshi Tamura > > >Subject: Re: Fax processing confirmation > > > > > > > > >On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote: > > > > > > > Wing-san > > > > > > > > How much confidence of ifax transmission in Simple Mode ? > > > > Does no response mean a good confirmation ? > > > > > > > > I want to add Fax processing confirmation in Full Mode. > > > > In Full Mode, the image file is send as TIFF file over SMTP. > > > > There will be some possibilities to fail to print or process > > > > the TIFF file by some reasons. These reasons may be > > > > incorrect TIFF parameter for the receiver > > > > or out of capabilities TIFF parameter for the receiver. > > > > > > > > When you put the 10 pages of document on the scanner > > > > and send by ifax Full Mode and you get the confirmation sheet > > > > with 9 pages received successfully, you will find something > > > > wrong with the scanner or the transmission. You will check > > > > the scanner or the system and may ask to the user of > the receiver. > > > > > > > > Comparing to the E-mail system, you can not get > information about > > > > how many pages the receiver successfully printed but > just received. > > > > You may find that the attached file is not be able to > be processed > > > > nor printed by the Email receiver with your inspiration. > > > > > > > > The user of Full Mode ifax will have confidence of the ifax > > > > transmission when the transmitter prints confirmation sheet > > > > with the number of pages printed on the receiver and also > > > > the number of page in error. > > > > > > > > Any comments? > > > > > >IPP provides this sort of confirmation today. Why not use IPP? > > > > > >-d > > > >-------------------- > >MAEDA TORU > >MIE Development Div. 2 > >CANON Inc. > >-------------------- > > ----------------------------------- > $B%-%d%N%s3t<02q $B1GA|;vL35!(JMIE$B?d?J%;%s%?!<(J > $B1GA|;vL35!(JMIE$BBh#23+H/It(J > $BA0ED!!E0(J > 146-8501$B!!El5~ETBgED6h2<4];R#3!]#3#0!]#2(J > $BEEOC!!(J03-3757-9738$B!"(JFAX$B!!(J03-3757-8205 > ----------------------------------- > From owner-ietf-fax@mail.imc.org Wed Feb 21 21:10:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16441 for ; Wed, 21 Feb 2001 21:10:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA09962 for ietf-fax-bks; Wed, 21 Feb 2001 17:34:36 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09958 for ; Wed, 21 Feb 2001 17:34:34 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id KAA00186; Thu, 22 Feb 2001 10:34:32 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma029917; Thu, 22 Feb 01 10:33:01 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id KAA00564; Thu, 22 Feb 2001 10:33:01 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id KAA21409; Thu, 22 Feb 2001 10:33:00 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id KAA27785; Thu, 22 Feb 2001 10:31:46 +0900 (JST) Message-Id: <4.2.0.58.J.20010222102347.00a673e0@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 22 Feb 2001 10:41:25 +0900 To: Dan Wing From: MAEDA toru Subject: Re: I-D ACTION:draft-maeda-faxwg-fax-processing-status-00.txt Cc: IETF Internet Fax WG In-Reply-To: <0102210845000.4753-100000@omega.cisco.com> References: <200102211144.GAA22226@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wing-san We have a lot of discussion about DSN and MDN. I may be still confused in DSN and MDN. Please check my idea as follows. Basically DSN returns delivery status, and MDN returns processing status. Since my idea is to return the processing status from the receiver, the draft describes to use MDN. When the Full Mode receiver get ifax mail from the server via POP, MDN will be returned. When the Full Mode receiver get ifax mail from the server via SMTP, DSN and MDN will be returned. DSN will be returned when the mail is received, and MDN will be returned when the mail is printed or processed. Regards. Toru Maeda At 08:48 01/02/21 -0800, Dan Wing wrote: >Maeda-san, > >This needs to support both MDNs and DSNs. > >I noticed your email address in the Internet Draft is incorrect (.jo >instead of .jp). > >-Dan Wing > > >On Wed, 21 Feb 2001 06:44 -0500, Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Fax Processing Status > > Author(s) : T. Maeda > > Filename : draft-maeda-faxwg-fax-processing-status-00.txt > > Pages : 4 > > Date : 20-Feb-01 > > > > This proposal describes a fax processing status which was requested > > in ITU-T SG16 meeting on November 2000 at Geneva, for Full Mode. > > The notification of success/failure of document processing and page > > by page status from the receiver is very important feature for the > > internet fax. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-maeda-faxwg-fax-processing-statu > s-00.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-maeda-faxwg-fax-processing-status-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-maeda-faxwg-fax-processing-status-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > ----------------------------------- $B%-%d%N%s3t<02q; Wed, 21 Feb 2001 23:07:36 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA15182 for ietf-fax-bks; Wed, 21 Feb 2001 19:33:22 -0800 (PST) Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA15178 for ; Wed, 21 Feb 2001 19:33:21 -0800 (PST) Received: from tot-tm.proxy.aol.com (tot-tm.proxy.aol.com [152.163.197.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id WAA21880 for ; Wed, 21 Feb 2001 22:32:39 -0500 (EST) Received: from eburger (AC95DBAA.ipt.aol.com [172.149.219.170]) by tot-tm.proxy.aol.com (8.10.0/8.10.0) with SMTP id f1M3WbC22127 for ; Wed, 21 Feb 2001 22:32:37 -0500 (EST) From: "Eric Burger" To: "IETF Internet Fax WG" Subject: RE: identifying parts Date: Thu, 22 Feb 2001 04:33:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <0102210848380.4753-100000@omega.cisco.com> X-Apparently-From: Eburger3@aol.com Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue was fully addressed by partial non-delivery notification (PNDN). Would that be an appropriate approach? The draft has expired. If we want to discuss it, I can resubmit it as a fax WG item. However, I believe that would reset it to -00, which means I would have to submit it today. -- - Eric > -----Original Message----- > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On > Behalf Of Dan Wing > Sent: Wednesday, February 21, 2001 12:11 PM > To: IETF Internet Fax WG > Cc: MAEDA toru > Subject: identifying parts [snip] > I feel it is critical that any MDN or DSN response indicating a portion of > a message was successfully or unsuccessfully processed must also indicate > which MIME part is being described in the MDN or DSN reponse -- it is NOT > as simple as the "page" having the problem, especially if Method 1 is used > -- they are all page "1" from the view of the sender. Method 1 is a valid > message format and is allowed, so we must handle it correctly. > > > I propose we require the use of Content-ID to identify MIME parts. This > identification allows the MDN to indicate which part(s) were successfully > or unsuccessfully processed. > > Content-ID is described in RFC2045, section 7. Its use is discussed in > RFC2046. > > -Dan Wing From owner-ietf-fax@mail.imc.org Thu Feb 22 02:06:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05485 for ; Thu, 22 Feb 2001 02:06:09 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id WAA18825 for ietf-fax-bks; Wed, 21 Feb 2001 22:27:30 -0800 (PST) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA18819 for ; Wed, 21 Feb 2001 22:27:28 -0800 (PST) Received: by bulls.mei.co.jp (8.11.2/3.7W) with ESMTP id f1M6Qrf23598; Thu, 22 Feb 2001 15:26:54 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id PAA27689; Thu, 22 Feb 2001 15:26:48 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 22 Feb 2001 06:26:49 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id PAA02043; Thu, 22 Feb 2001 15:26:47 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id PAA24279; Thu, 22 Feb 2001 15:26:47 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id PAA25446; Thu, 22 Feb 2001 15:26:46 +0900 (JST) Message-Id: <200102220628.AA01275@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Thu, 22 Feb 2001 15:28:17 +0900 To: MAEDA toru Cc: ietf-fax@imc.org Subject: Re:draft-maeda-faxwg-terminal-mode-protocol-00.txt MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Meda-san, I comment "draf-maeda-faxwg-terminal-mode-protocol-00.txt" and "goals.txt". It dosn't mention E2E communication which is discussed in this mailing list. I think terminal mode solve current problems of IFAX by using E2E communication. So, I propose the items below regarding E2E communication to add or change the terminal mode draft. I expect terminal mode as next step of FFPIM to solve current IFAX problems rather than realizing all features of Group 3 facsimile. ------------------------------------------------------------------------ 1 Requirement To solve the following problems which current IFAX can not realize. 1)Real time confirmation of delivery 2)Capability exchange before data communication 2 Proposal Add Direct ESMTP communication between terminals as extension to FFPIM or EIFAX. 2.1 Transport $B!!!!(BESMTP 2.2 Confirmation $B!!(B2.2.1 Delivery confirmation $B!!!!!!(BReal Time confirmation is realized by communicating with directly $B!!!!!!(BESMTP between IFAX terminals. $B!!(B2.2.2 Processing Confirmation $B!!!!!!(BMDN response is submitted by separate session after communication. 2.3 Capability Exchange $B!!(B2.3.1 Protocol $B!!!!!!(BThere are several methods to be selected and discussed. $B!!!!!!(B- Define new command of EIFAX such as REQCAP $B!!!!!!(B- Define local command of EIFAX such as XREQCAP $B!!!!!!(B- Use ETRN command The detail is to be studied. 2.3.2 Format RFC2531 2.4 Interworking with EIFAX or Simple Mode IFAX machine Terminal mode IFAX communicate with EIFAX or Simple Mode IFAX machine in direct SMTP connection except capability exchange because EIFAX or Simple Mode IFAX can speak SMTP. If network environment doesn't allow to direct ESMTP communication, terminal mode machine fall down its capability to FFPIM as store and forward mode. 3 Goal -Easy to Implement -Interworking with IFAX simple mode and EIFAX -Timely delivery -Real time delivery confirmation -Capability exchange -Use of existing infrastructure Best regards, Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Thu Feb 22 07:03:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07407 for ; Thu, 22 Feb 2001 07:03:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA27609 for ietf-fax-bks; Thu, 22 Feb 2001 03:24:39 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA27604 for ; Thu, 22 Feb 2001 03:24:36 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id UAA01301; Thu, 22 Feb 2001 20:23:27 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma001186; Thu, 22 Feb 01 20:22:13 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id UAA08965; Thu, 22 Feb 2001 20:22:13 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id UAA11358; Thu, 22 Feb 2001 20:22:12 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id UAA01009; Thu, 22 Feb 2001 20:20:56 +0900 (JST) Message-Id: <4.2.0.58.J.20010222200324.00a934d8@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 22 Feb 2001 20:30:35 +0900 To: "Carl Kugler" From: MAEDA toru Subject: RE: IFX> RE: Fax processing confirmation Cc: ifx@pwg.org, ietf-fax@imc.org In-Reply-To: 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: Kugler-san Thank you very much for the information about the page-by-page job notifications in the IPP draft. I read the section. 'job-progress' will be send for each sheet. I am not sure that user can find the error page number and the total number of pages printed from 'job-progress'. It's idea is similar idea as the fax processing status. The fax processing status will be sent in one MDN message with summarized information after printing a TIFF-FX file, such as total number of printed page and error page with error code. "page" in the fax processing status should be "page" in the TIFF-FX file but not sheet. 'job-progress' should be extended as 'job-summary' to report summarized information after printing for the fax processing status. Regards. Toru Maeda At 08:56 01/02/21 -0700, Carl Kugler wrote: >See section 5.3.2.1.3 "Subscribed Job Events", in the document you cited: > >'job-progress': OPTIONAL - when the Printer has completed Printing a > sheet. See the separate [ipp-prog] specification for additional > attributes that a Printer MAY send in an Event Notification caused > by this Event. The "notify-time-interval" attribute affects this > Event by causing the Printer NOT to send an Event Notification > every time a 'job-progress' Events occurs. See section 5.3.8 for > full details. > > > -Carl > > >MAEDA toru @pwg.org on 02/21/2001 02:24:36 AM > >Sent by: owner-ifx@pwg.org > > >To: "McDonald, Ira" , "'Wagner,William'" > , "McDonald, Ira" , > ifx@pwg.org >cc: >Subject: RE: IFX> RE: Fax processing confirmation > > > >Ira-san > > >And the page-by-page job notifications are OPTIONAL in the > >IPP notifications model spec. > >Please let me know which section describes the page-by-page job >notifications, > since I could not find it in >http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt. > >Shall I check other drafts? > > >Reagrds. > > >Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Thu Feb 22 07:04:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07770 for ; Thu, 22 Feb 2001 07:04:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id DAA28626 for ietf-fax-bks; Thu, 22 Feb 2001 03:28:12 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA28621 for ; Thu, 22 Feb 2001 03:28:10 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id UAA01903; Thu, 22 Feb 2001 20:28:08 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma001820; Thu, 22 Feb 01 20:27:33 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id UAA09324; Thu, 22 Feb 2001 20:27:33 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id UAA11890; Thu, 22 Feb 2001 20:27:32 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id UAA01267; Thu, 22 Feb 2001 20:26:17 +0900 (JST) Message-Id: <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 22 Feb 2001 20:35:55 +0900 To: Dan Wing , IETF Internet Fax WG , Hiroshi Tamura From: MAEDA toru Subject: Re: identifying parts In-Reply-To: <0102210848380.4753-100000@omega.cisco.com> 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: Tamura-san Are there any description about these Methods described by Wing-san in the implementation guide? Regards. Toru Maeda At 09:11 01/02/21 -0800, Dan Wing wrote: >This question is related to >draft-maeda-faxwg-fax-processing-status-00.txt. > > >A long time ago, I recall that some ifax sending devices would (or >could) send a multiple pages as multiple one-page TIFF >attachments. > >Here is a description of several different valid messages which describe >the problem I see with the current proposal in >draft-maeda-faxwg-fax-processing-status-00.txt. The problem is that it >cannot identify the "page" successfully -- the definition of a page is >different from the sender and the receiver's view. Email allows >much richer operation than scanning, transmitting, and printing. This >richer operation means a straight-forward "page NNN failed" is not >sufficient for email. > >A proposal to resolve this problem is below. The proposal allows >operation as described in draft-maeda-faxwg-fax-processing-status-00.txt >while also allowing the richer operation of email. > > > > >Method 1: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: multipart/mixed; boundary=ABC > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > > >Method 2: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: multipart/mixed; boundary=ABC > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > > >Method 3: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: multipart/mixed; boundary=ABC > > --ABC > Content-type: text/plain > > FAX COVERSHEET > > From: Jim > To: Susan > Date: 1 Jan 2001 01:00:00, Pacific Time > Contact: jim@default.com, 408-555-1212 > > Susan, > > Here is the fax you requested. There should be 4 pages total > (this coversheet, plus 3 pages of the fax content itself). > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > >To support non-ASCII languages on the coversheet, the first part in Method >3 could be image/tiff which contains a graphical representation of the >coversheet. > > >Method 4: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > >Method 5: > > From: someone@default.com > To: someone-else@default.com > Subject: your two faxes: Sumerset, Egghead > Content-Type: multipart/mixed; boundary=ABC > Date: 1 Jan 2001 01:00:00 -0800 > Message-ID: <123@default.com> > > --ABC > Content-type: text/plain > > FAX COVERSHEET > > From: Jim > To: Susan > Date: 1 Jan 2001 01:00:00, Pacific Time > Contact: jim@default.com, 408-555-1212 > > Susan, > > Here are your two faxes. The first one is a 3 page fax from > Sumerset, Inc. The second one is a 9 page fax from Egghead. > > Thanks. > Jim > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > > >I _believe_ that most dedicated ifax devices use Method 4, above. I >believe most of the typical mailers (Netscape, Eudora, Outlook) would use >Method 2 or Method 3, above. > > >I feel it is critical that any MDN or DSN response indicating a portion of >a message was successfully or unsuccessfully processed must also indicate >which MIME part is being described in the MDN or DSN reponse -- it is NOT >as simple as the "page" having the problem, especially if Method 1 is used >-- they are all page "1" from the view of the sender. Method 1 is a valid >message format and is allowed, so we must handle it correctly. > > >I propose we require the use of Content-ID to identify MIME parts. This >identification allows the MDN to indicate which part(s) were successfully >or unsuccessfully processed. > >Content-ID is described in RFC2045, section 7. Its use is discussed in >RFC2046. > >-Dan Wing -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Thu Feb 22 07:35:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08696 for ; Thu, 22 Feb 2001 07:35:02 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA00975 for ietf-fax-bks; Thu, 22 Feb 2001 04:04:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA00965 for ; Thu, 22 Feb 2001 04:04:27 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07685; Thu, 22 Feb 2001 07:04:27 -0500 (EST) Message-Id: <200102221204.HAA07685@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-gateway-protocol-03.txt Date: Thu, 22 Feb 2001 07:04:27 -0500 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Internet FAX Gateway Protocol Author(s) : K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide Filename : draft-ietf-fax-gateway-protocol-03.txt Pages : 12 Date : 21-Feb-01 An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) the Internet. This document provides information on recommended behaviors for Internet FAX Gateways Functions. In this context, an Offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to Internet from the GSTN. This document covers the delivery-process of the data among equipment which may include Internet Fax terminals, PCs on the Internet and FAX terminal on GSTN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-gateway-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-gateway-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221145235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-gateway-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-gateway-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145235.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Feb 22 07:36:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08830 for ; Thu, 22 Feb 2001 07:36:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA00982 for ietf-fax-bks; Thu, 22 Feb 2001 04:04:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA00947 for ; Thu, 22 Feb 2001 04:04:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07658; Thu, 22 Feb 2001 07:04:21 -0500 (EST) Message-Id: <200102221204.HAA07658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-gateway-options-01.txt Date: Thu, 22 Feb 2001 07:04:21 -0500 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Guideline of optional services for Internet FAX Gateway Author(s) : K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide Filename : draft-ietf-fax-gateway-options-01.txt Pages : 11 Date : 21-Feb-01 An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) the Internet. This document provides information on guideline of optional services and some examples for an Internet FAX Gateway classified as an onramp gateway and an offramp gateway. So this document does not intend to specify the actions that ifax offramp and onramp Gateways conform to. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-gateway-options-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-gateway-options-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010221145226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-gateway-options-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-gateway-options-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010221145226.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu Feb 22 07:59:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09518 for ; Thu, 22 Feb 2001 07:58:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA02525 for ietf-fax-bks; Thu, 22 Feb 2001 04:22:19 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA02521 for ; Thu, 22 Feb 2001 04:22:17 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id VAA07792; Thu, 22 Feb 2001 21:22:14 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma007761; Thu, 22 Feb 01 21:21:30 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id VAA12464; Thu, 22 Feb 2001 21:21:30 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id VAA16735; Thu, 22 Feb 2001 21:21:29 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id VAA03920; Thu, 22 Feb 2001 21:20:14 +0900 (JST) Message-Id: <4.2.0.58.J.20010222204217.00a7b418@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 22 Feb 2001 21:29:51 +0900 To: Dan Wing , IETF Internet Fax WG From: MAEDA toru Subject: Re: identifying parts In-Reply-To: <0102210848380.4753-100000@omega.cisco.com> 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: Wing-san I got data for ifax devices about these Methods during the Ifax communication test in 1999. There were three types of MIME type usage in the ifax devices. Type-1= Method 4 No Multi-part one tiff file Type-2= Method 2 Content-Type:Multipart/mixed Multi-part with one tiff file part Type-3= Method 3 (Not completely same in text part) Content-Type:Multipart/mixed Multi-part with one Text part and one tiff file part Some manufacturers want to suppress printing Multi-part Text part in the ifax receiver, since the text is just information to PC client such as; "There is a TIFF file in this mail, which sent from an Internet Facsimile." "An image data has been attached to this E-mail message and image data is the Tiff file format." "An image data in TIFF-F format has been attached to this email. You can download the TIFF-F Image Viewer from the following URL addresses." etc. Any way, ifax should send one tiff file, so there will be no confusion of page-by-page confirmation processing one tiff file. Regards. Toru Maeda At 09:11 01/02/21 -0800, Dan Wing wrote: >This question is related to >draft-maeda-faxwg-fax-processing-status-00.txt. > > >A long time ago, I recall that some ifax sending devices would (or >could) send a multiple pages as multiple one-page TIFF >attachments. > >Here is a description of several different valid messages which describe >the problem I see with the current proposal in >draft-maeda-faxwg-fax-processing-status-00.txt. The problem is that it >cannot identify the "page" successfully -- the definition of a page is >different from the sender and the receiver's view. Email allows >much richer operation than scanning, transmitting, and printing. This >richer operation means a straight-forward "page NNN failed" is not >sufficient for email. > >A proposal to resolve this problem is below. The proposal allows >operation as described in draft-maeda-faxwg-fax-processing-status-00.txt >while also allowing the richer operation of email. > > > > >Method 1: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: multipart/mixed; boundary=ABC > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > > >Method 2: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: multipart/mixed; boundary=ABC > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > > >Method 3: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: multipart/mixed; boundary=ABC > > --ABC > Content-type: text/plain > > FAX COVERSHEET > > From: Jim > To: Susan > Date: 1 Jan 2001 01:00:00, Pacific Time > Contact: jim@default.com, 408-555-1212 > > Susan, > > Here is the fax you requested. There should be 4 pages total > (this coversheet, plus 3 pages of the fax content itself). > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > >To support non-ASCII languages on the coversheet, the first part in Method >3 could be image/tiff which contains a graphical representation of the >coversheet. > > >Method 4: > > From: someone@default.com > To: someone-else@default.com > Subject: 3 page fax > Message-ID: <123@default.com> > Date: 1 Jan 2001 01:00:00 -0800 > Content-Type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > >Method 5: > > From: someone@default.com > To: someone-else@default.com > Subject: your two faxes: Sumerset, Egghead > Content-Type: multipart/mixed; boundary=ABC > Date: 1 Jan 2001 01:00:00 -0800 > Message-ID: <123@default.com> > > --ABC > Content-type: text/plain > > FAX COVERSHEET > > From: Jim > To: Susan > Date: 1 Jan 2001 01:00:00, Pacific Time > Contact: jim@default.com, 408-555-1212 > > Susan, > > Here are your two faxes. The first one is a 3 page fax from > Sumerset, Inc. The second one is a 9 page fax from Egghead. > > Thanks. > Jim > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC > content-type: image/tiff > content-transfer-encoding: base64 > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > --ABC-- > > >I _believe_ that most dedicated ifax devices use Method 4, above. I >believe most of the typical mailers (Netscape, Eudora, Outlook) would use >Method 2 or Method 3, above. > > >I feel it is critical that any MDN or DSN response indicating a portion of >a message was successfully or unsuccessfully processed must also indicate >which MIME part is being described in the MDN or DSN reponse -- it is NOT >as simple as the "page" having the problem, especially if Method 1 is used >-- they are all page "1" from the view of the sender. Method 1 is a valid >message format and is allowed, so we must handle it correctly. > > >I propose we require the use of Content-ID to identify MIME parts. This >identification allows the MDN to indicate which part(s) were successfully >or unsuccessfully processed. > >Content-ID is described in RFC2045, section 7. Its use is discussed in >RFC2046. > >-Dan Wing -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Thu Feb 22 14:49:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24618 for ; Thu, 22 Feb 2001 14:49:49 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA28154 for ietf-fax-bks; Thu, 22 Feb 2001 11:10:57 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28146 for ; Thu, 22 Feb 2001 11:10:55 -0800 (PST) Received: from DWING-W2K.cisco.com (dwings-dsl3.cisco.com [10.19.89.164]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA06815 for ; Thu, 22 Feb 2001 11:10:27 -0800 (PST) Message-Id: <4.3.2.7.2.20010222110859.038581e8@omega.cisco.com> X-Sender: dwing@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 11:11:31 -0800 To: ietf-fax@imc.org From: Dan Wing Subject: Re: I-D ACTION:draft-ietf-fax-gateway-options-01.txt In-Reply-To: <200102221204.HAA07658@ietf.org> 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: The non-deterministic recommendation in section 4 of this document is worrisome. Some of the recommendations in this document seem like they should be folded into Implementor's Guide, which just went to Last Call. -d At 07:04 AM 22-02-2001 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Internet Fax Working Group of the IETF. > > Title : Guideline of optional services for Internet FAX > Gateway > Author(s) : K. Mimura, K. Yokoyama, T. Satoh, > K. Watanabe, C. Kanaide > Filename : draft-ietf-fax-gateway-options-01.txt > Pages : 11 > Date : 21-Feb-01 > >An Internet FAX Gateway provides functions which translate facsimile >between the general switched telephone network (GSTN) the Internet. >This document provides information on guideline of optional services >and some examples for an Internet FAX Gateway classified as an onramp >gateway and an offramp gateway. >So this document does not intend to specify the actions that ifax offramp >and onramp Gateways conform to. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-fax-gateway-options-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-fax-gateway-options-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010221145226.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-fax-gateway-options-01.txt > > From owner-ietf-fax@mail.imc.org Thu Feb 22 14:59:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24974 for ; Thu, 22 Feb 2001 14:59:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA28714 for ietf-fax-bks; Thu, 22 Feb 2001 11:21:20 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28709 for ; Thu, 22 Feb 2001 11:21:19 -0800 (PST) Received: from DWING-W2K.cisco.com (dwings-dsl3.cisco.com [10.19.89.164]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA08136 for ; Thu, 22 Feb 2001 11:20:50 -0800 (PST) Message-Id: <4.3.2.7.2.20010222111534.00af8e98@omega.cisco.com> X-Sender: dwing@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 11:21:57 -0800 To: ietf-fax@imc.org From: Dan Wing Subject: Re: I-D ACTION:draft-ietf-fax-gateway-protocol-03.txt In-Reply-To: <200102221204.HAA07685@ietf.org> 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: Section 4.6, return notice. This section mentions an onramp having offramp functions. An onramp is an onramp, and an offramp is an offramp. Keeping them separate is best. I suggest changing the text to say something like: An onramp should ensure that bounces or delivery receipts, which are destined to the originating GSTN-based fax machine, are addressed appropriately to an offramp. In many situations an onramp device also performs offramp functions, so the bounces and delivery receipts will be addressed to the same device. However, in some situations and some deployments this is not the case and the onramp device SHOULD include a mechanism to direct bounces and delivery receipts to a device other than itself. Where the requirements in gateway-protocol-03.txt differ from RFC2305 or RFC2532, which document is authoritative? This should be clearly described in gateway-protocol.txt. How does this document's requirements relate to draft-ietf-fax-service-v2-03.txt ? Not all of them match - there are differences. -d At 07:04 AM 22-02-2001 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Internet Fax Working Group of the IETF. > > Title : Internet FAX Gateway Protocol > Author(s) : K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide > Filename : draft-ietf-fax-gateway-protocol-03.txt > Pages : 12 > Date : 21-Feb-01 > >An Internet FAX Gateway provides functions which translate facsimile >between the general switched telephone network (GSTN) the Internet. >This document provides information on recommended behaviors for >Internet FAX Gateways Functions. In this context, an Offramp means >facsimile data transmission to the GSTN from the Internet, and onramp >means facsimile data transmission to Internet from the GSTN. >This document covers the delivery-process of the data among equipment >which may include Internet Fax terminals, PCs on the Internet and FAX >terminal on GSTN. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-03.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-fax-gateway-protocol-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-fax-gateway-protocol-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010221145235.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-fax-gateway-protocol-03.txt > > From owner-ietf-fax@mail.imc.org Thu Feb 22 19:18:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01287 for ; Thu, 22 Feb 2001 19:18:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA12552 for ietf-fax-bks; Thu, 22 Feb 2001 15:28:28 -0800 (PST) Received: from mail.notes.ricoh.co.jp (mail2.notes.ricoh.co.jp [202.211.49.12]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA12545 for ; Thu, 22 Feb 2001 15:28:24 -0800 (PST) Received: from artemis.isd.ricoh.co.jp (artemis [133.139.250.72]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id IAA11061; Fri, 23 Feb 2001 08:27:08 +0900 (JST) Received: from newton.toda.ricoh.co.jp by artemis.isd.ricoh.co.jp (8.9.3+3.2W/3.7W) id IAA12348; Fri, 23 Feb 2001 08:27:08 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id IAA19751; Fri, 23 Feb 2001 08:27:05 +0900 To: maeda.toru@canon.co.jp Cc: dwing@cisco.com, ietf-fax@imc.org Subject: Re: identifying parts In-Reply-To: <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> References: <0102210848380.4753-100000@omega.cisco.com> <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> 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: <20010223083358J.tamura@toda.ricoh.co.jp> Date: Fri, 23 Feb 2001 08:33:58 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 224 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit MAEDA-san, > Are there any description about these Methods described by Wing-san in > the implementation guide? No. We do not have any descriptions about page-by-page confirmation in our guide. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp > At 09:11 01/02/21 -0800, Dan Wing wrote: > >This question is related to > >draft-maeda-faxwg-fax-processing-status-00.txt. > > > > > >A long time ago, I recall that some ifax sending devices would (or > >could) send a multiple pages as multiple one-page TIFF > >attachments. > > > >Here is a description of several different valid messages which describe > >the problem I see with the current proposal in > >draft-maeda-faxwg-fax-processing-status-00.txt. The problem is that it > >cannot identify the "page" successfully -- the definition of a page is > >different from the sender and the receiver's view. Email allows > >much richer operation than scanning, transmitting, and printing. This > >richer operation means a straight-forward "page NNN failed" is not > >sufficient for email. > > > >A proposal to resolve this problem is below. The proposal allows > >operation as described in draft-maeda-faxwg-fax-processing-status-00.txt > >while also allowing the richer operation of email. > > > > > > > > > >Method 1: > > > > From: someone@default.com > > To: someone-else@default.com > > Subject: 3 page fax > > Message-ID: <123@default.com> > > Date: 1 Jan 2001 01:00:00 -0800 > > Content-Type: multipart/mixed; boundary=ABC > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC-- > > > > > >Method 2: > > > > From: someone@default.com > > To: someone-else@default.com > > Subject: 3 page fax > > Message-ID: <123@default.com> > > Date: 1 Jan 2001 01:00:00 -0800 > > Content-Type: multipart/mixed; boundary=ABC > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC-- > > > > > >Method 3: > > > > From: someone@default.com > > To: someone-else@default.com > > Subject: 3 page fax > > Message-ID: <123@default.com> > > Date: 1 Jan 2001 01:00:00 -0800 > > Content-Type: multipart/mixed; boundary=ABC > > > > --ABC > > Content-type: text/plain > > > > FAX COVERSHEET > > > > From: Jim > > To: Susan > > Date: 1 Jan 2001 01:00:00, Pacific Time > > Contact: jim@default.com, 408-555-1212 > > > > Susan, > > > > Here is the fax you requested. There should be 4 pages total > > (this coversheet, plus 3 pages of the fax content itself). > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC-- > > > >To support non-ASCII languages on the coversheet, the first part in Method > >3 could be image/tiff which contains a graphical representation of the > >coversheet. > > > > > >Method 4: > > > > From: someone@default.com > > To: someone-else@default.com > > Subject: 3 page fax > > Message-ID: <123@default.com> > > Date: 1 Jan 2001 01:00:00 -0800 > > Content-Type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > >Method 5: > > > > From: someone@default.com > > To: someone-else@default.com > > Subject: your two faxes: Sumerset, Egghead > > Content-Type: multipart/mixed; boundary=ABC > > Date: 1 Jan 2001 01:00:00 -0800 > > Message-ID: <123@default.com> > > > > --ABC > > Content-type: text/plain > > > > FAX COVERSHEET > > > > From: Jim > > To: Susan > > Date: 1 Jan 2001 01:00:00, Pacific Time > > Contact: jim@default.com, 408-555-1212 > > > > Susan, > > > > Here are your two faxes. The first one is a 3 page fax from > > Sumerset, Inc. The second one is a 9 page fax from Egghead. > > > > Thanks. > > Jim > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC > > content-type: image/tiff > > content-transfer-encoding: base64 > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > --ABC-- > > > > > >I _believe_ that most dedicated ifax devices use Method 4, above. I > >believe most of the typical mailers (Netscape, Eudora, Outlook) would use > >Method 2 or Method 3, above. > > > > > >I feel it is critical that any MDN or DSN response indicating a portion of > >a message was successfully or unsuccessfully processed must also indicate > >which MIME part is being described in the MDN or DSN reponse -- it is NOT > >as simple as the "page" having the problem, especially if Method 1 is used > >-- they are all page "1" from the view of the sender. Method 1 is a valid > >message format and is allowed, so we must handle it correctly. > > > > > >I propose we require the use of Content-ID to identify MIME parts. This > >identification allows the MDN to indicate which part(s) were successfully > >or unsuccessfully processed. > > > >Content-ID is described in RFC2045, section 7. Its use is discussed in > >RFC2046. > > > >-Dan Wing > > -------------------- > MAEDA TORU > MIE Development Div. 2 > CANON Inc. > -------------------- From owner-ietf-fax@mail.imc.org Thu Feb 22 19:33:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01585 for ; Thu, 22 Feb 2001 19:33:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA13789 for ietf-fax-bks; Thu, 22 Feb 2001 15:52:28 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA13785 for ; Thu, 22 Feb 2001 15:52:27 -0800 (PST) Received: from DWING-W2K.cisco.com (dwings-dsl3.cisco.com [10.19.89.164]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07868; Thu, 22 Feb 2001 15:51:49 -0800 (PST) Message-Id: <4.3.2.7.2.20010222154948.0413cee0@omega.cisco.com> X-Sender: dwing@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 15:52:55 -0800 To: MAEDA toru , IETF Internet Fax WG From: Dan Wing Subject: Re: identifying parts In-Reply-To: <4.2.0.58.J.20010222204217.00a7b418@ffmmail.ffm.canon.co.jp > References: <0102210848380.4753-100000@omega.cisco.com> 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 09:29 PM 2/22/01 +0900, MAEDA toru wrote: >Wing-san > >I got data for ifax devices about these Methods during the Ifax >communication test in 1999. >There were three types of MIME type usage in the ifax devices. > >Type-1= Method 4 >No Multi-part >one tiff file > > >Type-2= Method 2 >Content-Type:Multipart/mixed >Multi-part with one tiff file part > > >Type-3= Method 3 (Not completely same in text part) >Content-Type:Multipart/mixed >Multi-part with one Text part and one tiff file part > >Some manufacturers want to suppress printing >Multi-part Text part in the ifax receiver, >since the text is just information to PC client such as; >"There is a TIFF file in this mail, which sent from an Internet >Facsimile." >"An image data has been attached to this E-mail message and image data is >the Tiff file format." >"An image data in TIFF-F format has been attached to this email. >You can download the TIFF-F Image Viewer from the following URL >addresses." >etc. Throwing away parts of an email is a scary assumption. With almost all mailers supporting MIME today, such boilerplate instructing a user on how to view an attachment seems unnecessary. Certainly users requiring non-ASCII character sets are going to use MIME-aware mailers -- it's the only standard way to view text without a reader! >Any way, ifax should send one tiff file, so there will be no confusion >of page-by-page confirmation processing one tiff file. How would an ifax receiver be restricted to only receive this one method? It seems we need correct behavior for all the valid types of email messages that an ifax may utilize. If we don't, why use SMTP? -d >Regards. > >Toru Maeda > > > >At 09:11 01/02/21 -0800, Dan Wing wrote: >>This question is related to >>draft-maeda-faxwg-fax-processing-status-00.txt. >> >> >>A long time ago, I recall that some ifax sending devices would (or >>could) send a multiple pages as multiple one-page TIFF >>attachments. >> >>Here is a description of several different valid messages which describe >>the problem I see with the current proposal in >>draft-maeda-faxwg-fax-processing-status-00.txt. The problem is that it >>cannot identify the "page" successfully -- the definition of a page is >>different from the sender and the receiver's view. Email allows >>much richer operation than scanning, transmitting, and printing. This >>richer operation means a straight-forward "page NNN failed" is not >>sufficient for email. >> >>A proposal to resolve this problem is below. The proposal allows >>operation as described in draft-maeda-faxwg-fax-processing-status-00.txt >>while also allowing the richer operation of email. >> >> >> >> >>Method 1: >> >> From: someone@default.com >> To: someone-else@default.com >> Subject: 3 page fax >> Message-ID: <123@default.com> >> Date: 1 Jan 2001 01:00:00 -0800 >> Content-Type: multipart/mixed; boundary=ABC >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC-- >> >> >>Method 2: >> >> From: someone@default.com >> To: someone-else@default.com >> Subject: 3 page fax >> Message-ID: <123@default.com> >> Date: 1 Jan 2001 01:00:00 -0800 >> Content-Type: multipart/mixed; boundary=ABC >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC-- >> >> >>Method 3: >> >> From: someone@default.com >> To: someone-else@default.com >> Subject: 3 page fax >> Message-ID: <123@default.com> >> Date: 1 Jan 2001 01:00:00 -0800 >> Content-Type: multipart/mixed; boundary=ABC >> >> --ABC >> Content-type: text/plain >> >> FAX COVERSHEET >> >> From: Jim >> To: Susan >> Date: 1 Jan 2001 01:00:00, Pacific Time >> Contact: jim@default.com, 408-555-1212 >> >> Susan, >> >> Here is the fax you requested. There should be 4 pages total >> (this coversheet, plus 3 pages of the fax content itself). >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC-- >> >>To support non-ASCII languages on the coversheet, the first part in >>Method >>3 could be image/tiff which contains a graphical representation of the >>coversheet. >> >> >>Method 4: >> >> From: someone@default.com >> To: someone-else@default.com >> Subject: 3 page fax >> Message-ID: <123@default.com> >> Date: 1 Jan 2001 01:00:00 -0800 >> Content-Type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> >>Method 5: >> >> From: someone@default.com >> To: someone-else@default.com >> Subject: your two faxes: Sumerset, Egghead >> Content-Type: multipart/mixed; boundary=ABC >> Date: 1 Jan 2001 01:00:00 -0800 >> Message-ID: <123@default.com> >> >> --ABC >> Content-type: text/plain >> >> FAX COVERSHEET >> >> From: Jim >> To: Susan >> Date: 1 Jan 2001 01:00:00, Pacific Time >> Contact: jim@default.com, 408-555-1212 >> >> Susan, >> >> Here are your two faxes. The first one is a 3 page fax from >> Sumerset, Inc. The second one is a 9 page fax from Egghead. >> >> Thanks. >> Jim >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC >> content-type: image/tiff >> content-transfer-encoding: base64 >> >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ >> >> --ABC-- >> >> >>I _believe_ that most dedicated ifax devices use Method 4, above. I >>believe most of the typical mailers (Netscape, Eudora, Outlook) would use >>Method 2 or Method 3, above. >> >> >>I feel it is critical that any MDN or DSN response indicating a portion >>of >>a message was successfully or unsuccessfully processed must also indicate >>which MIME part is being described in the MDN or DSN reponse -- it is NOT >>as simple as the "page" having the problem, especially if Method 1 is >>used >>-- they are all page "1" from the view of the sender. Method 1 is a >>valid >>message format and is allowed, so we must handle it correctly. >> >> >>I propose we require the use of Content-ID to identify MIME parts. This >>identification allows the MDN to indicate which part(s) were successfully >>or unsuccessfully processed. >> >>Content-ID is described in RFC2045, section 7. Its use is discussed in >>RFC2046. >> >>-Dan Wing > >-------------------- >MAEDA TORU >MIE Development Div. 2 >CANON Inc. >-------------------- From owner-ietf-fax@mail.imc.org Thu Feb 22 20:06:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02101 for ; Thu, 22 Feb 2001 20:06:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA16096 for ietf-fax-bks; Thu, 22 Feb 2001 16:37:23 -0800 (PST) Received: from iscan.toyocom.co.jp (mail.toyocom.co.jp [210.232.21.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA16089 for ; Thu, 22 Feb 2001 16:37:20 -0800 (PST) Received: from iscan.toyocom.co.jp (localhost [127.0.0.1]) by iscan.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA21723 for ; Fri, 23 Feb 2001 09:36:21 +0900 Received: from smtp.toyocom.co.jp (smtp.toyocom.co.jp [10.1.11.24]) by iscan.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA21205 for ; Fri, 23 Feb 2001 09:35:51 +0900 Received: from toyocom.co.jp ([172.16.72.36]) by smtp.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA16657; Fri, 23 Feb 2001 09:39:26 +0900 Message-ID: <3A95B136.8000107@toyocom.co.jp> Date: Fri, 23 Feb 2001 09:39:18 +0900 From: Katsuhiko Mimura Organization: TOYOCOM User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; ja-JP; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: ja, en-us MIME-Version: 1.0 To: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-gateway-options-01.txt References: <4.3.2.7.2.20010222110859.038581e8@omega.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Wing-san, Dan Wing wrote: > The non-deterministic recommendation in section 4 of this document is > worrisome. Sorry, I have not change section 4. I would llike to change Section 4 to say something like: Offramp and Onramp gateway MAY have a user authorization function to confirm that they are the data that suitable user transmitted. Encipherment of facsimile data is performed by the existing SMTP, such as S/MIME, using the possible security technique. Thank you for your comments. ------- Katsuhiko Mimura From owner-ietf-fax@mail.imc.org Thu Feb 22 21:22:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03275 for ; Thu, 22 Feb 2001 21:22:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA19707 for ietf-fax-bks; Thu, 22 Feb 2001 17:52:12 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA19702 for ; Thu, 22 Feb 2001 17:52:11 -0800 (PST) Received: from DWING-W2K.cisco.com (dwings-dsl3.cisco.com [10.19.89.164]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA18919; Thu, 22 Feb 2001 17:51:41 -0800 (PST) Message-Id: <4.3.2.7.2.20010222175137.00b48790@omega.cisco.com> X-Sender: dwing@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 17:52:47 -0800 To: Katsuhiko Mimura , ietf-fax@imc.org From: Dan Wing Subject: Re: I-D ACTION:draft-ietf-fax-gateway-options-01.txt In-Reply-To: <3A95B136.8000107@toyocom.co.jp> References: <4.3.2.7.2.20010222110859.038581e8@omega.cisco.com> 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: Thanks. I was most concerned with the paragraphs recommending that only 1/100 of positive messages be sent. Both S/MIME and PGP are standards for encrypting messages; both need to be allowed. -d At 09:39 AM 02/23/01 +0900, Katsuhiko Mimura wrote: >Wing-san, > >Dan Wing wrote: > >>The non-deterministic recommendation in section 4 of this document is >>worrisome. > >Sorry, I have not change section 4. >I would llike to change Section 4 to say something like: > >Offramp and Onramp gateway MAY have a user authorization >function to confirm that they are the data that suitable user transmitted. > >Encipherment of facsimile data is performed by the existing SMTP, such as >S/MIME, using the possible >security technique. > >Thank you for your comments. > >------- >Katsuhiko Mimura > From owner-ietf-fax@mail.imc.org Thu Feb 22 21:22:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03296 for ; Thu, 22 Feb 2001 21:22:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA19755 for ietf-fax-bks; Thu, 22 Feb 2001 17:54:16 -0800 (PST) Received: from cisco.com (omega.cisco.com [171.69.26.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA19751 for ; Thu, 22 Feb 2001 17:54:15 -0800 (PST) Received: from DWING-W2K.cisco.com (dwings-dsl3.cisco.com [10.19.89.164]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA19143; Thu, 22 Feb 2001 17:53:46 -0800 (PST) Message-Id: <4.3.2.7.2.20010222175411.00b75ef8@omega.cisco.com> X-Sender: dwing@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Feb 2001 17:54:52 -0800 To: Katsuhiko Mimura , ietf-fax@imc.org From: Dan Wing Subject: Re: I-D ACTION:draft-ietf-fax-gateway-options-01.txt 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: (correction below) Thanks. I was most concerned with the paragraphs recommending that only 1/100 of positive messages be sent. Section 2.4 (sorry I had omitted this previously). Both S/MIME and PGP are standards for encrypting messages; both need to be allowed. -d At 09:39 AM 02/23/01 +0900, Katsuhiko Mimura wrote: >Wing-san, > >Dan Wing wrote: > >>The non-deterministic recommendation in section 4 of this document is >>worrisome. > >Sorry, I have not change section 4. >I would llike to change Section 4 to say something like: > >Offramp and Onramp gateway MAY have a user authorization >function to confirm that they are the data that suitable user transmitted. > >Encipherment of facsimile data is performed by the existing SMTP, such as >S/MIME, using the possible >security technique. > >Thank you for your comments. > >------- >Katsuhiko Mimura From owner-ietf-fax@mail.imc.org Fri Feb 23 12:26:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10125 for ; Fri, 23 Feb 2001 12:26:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA28066 for ietf-fax-bks; Fri, 23 Feb 2001 08:37:39 -0800 (PST) Received: from mail.interstarinc.com (mail.faxserver.com [207.35.87.240]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA28062 for ; Fri, 23 Feb 2001 08:37:37 -0800 (PST) Received: by mail.interstarinc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Feb 2001 11:30:55 -0500 Message-ID: <7EDA5140F315D311B3E8006094B90AEA4AA608@mail.interstarinc.com> From: MailingList To: "'ietf-fax@imc.org'" Subject: Doing T.30 / T.38 all by software?? Date: Fri, 23 Feb 2001 11:30:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA28063 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA28066 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10125 Hi, I have one little question for which I cannot find any answer on the web, maybe someone here could help me: I want to know if it is possible / thinkable to create a complete software solution to perform T.30 and T.38 (realtime fax over ip) in software that will NOT run on a DSP, but on a normal computer with WinNT or Linux. For example, the fax does not come from a PSTN, we have a TIFF file on computer and want to send it to a T.38 compliant gateway. The problem is that we need to generate the equivalent T.30 signals and interact with the remote FAX adequately. I have heard that there might be timing problems, especially if we want to have many simultaneous fax channels. If someone has the answer or part of the answer for this question, please help me, I have been searching for a while now and I can't find anything interesting. Thanks a lot, Sebastien Lalonde Interstar Technologies inc. 5835 Ave. Verdun, Suite 302 Verdun, Québec, Canada H4H 1M1 email : slalonde@interstarinc.com http://www.faxserver.com Tel. (514) 766-1668 ext.4453 Fax (514) 766-1439 From owner-ietf-fax@mail.imc.org Fri Feb 23 14:29:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16872 for ; Fri, 23 Feb 2001 14:29:47 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA04875 for ietf-fax-bks; Fri, 23 Feb 2001 10:49:13 -0800 (PST) Received: from mail.commetrex.com ([216.181.108.27]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA04871 for ; Fri, 23 Feb 2001 10:49:12 -0800 (PST) Received: by mail.commetrex.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 852569FC.006774A0 ; Fri, 23 Feb 2001 13:50:00 -0500 X-Lotus-FromDomain: COMMETREX From: "Mike Coffee" To: MailingList cc: "'ietf-fax@imc.org'" Message-ID: <852569FC.00677392.00@mail.commetrex.com> Date: Fri, 23 Feb 2001 13:49:57 -0500 Subject: Re: Doing T.30 / T.38 all by software?? 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: Commetrex has the entire solution...we do it all the time. Mike Coffee 770-449-7775x310 From owner-ietf-fax@mail.imc.org Sun Feb 25 13:08:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11625 for ; Sun, 25 Feb 2001 13:08:02 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA22634 for ietf-fax-bks; Sun, 25 Feb 2001 09:29:48 -0800 (PST) Received: from mg2.jjcn.ne.jp (qmailr@mg2.jjcn.ne.jp [210.81.64.156]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA22630 for ; Sun, 25 Feb 2001 09:29:46 -0800 (PST) From: bigjoe@japan.com Received: (qmail 10578 invoked by uid 0); 8 Feb 2001 18:54:24 -0000 Received: from 1cust219.tnt3.irving2.tx.da.uu.net (HELO 1Cust219.tnt3.irving2.tx.da.uu.net??63.24.178.219?) (63.24.178.219) by mg2.jjcn.ne.jp with SMTP; 8 Feb 2001 18:54:24 -0000 Received: from minniemouse.cemax.com by 1Cust219.tnt3.irving2.tx.da.uu.net with ESMTP; Thu, 08 Feb 2001 12:53:27 -0600 Message-ID: <0000074a0421$000043bf$00005878@minniemouse.cemax.com> To: Subject: Brand New E-Mail pager for FR-EE! 22648 Date: Thu, 08 Feb 2001 12:53:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bigjoe@japan.com Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! No long term contract From owner-ietf-fax@mail.imc.org Mon Feb 26 04:07:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03008 for ; Mon, 26 Feb 2001 04:07:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA24053 for ietf-fax-bks; Mon, 26 Feb 2001 00:29:32 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA24048 for ; Mon, 26 Feb 2001 00:29:29 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id RAA23326; Mon, 26 Feb 2001 17:29:24 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma023128; Mon, 26 Feb 01 17:28:42 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id RAA06304; Mon, 26 Feb 2001 17:28:42 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id RAA13040; Mon, 26 Feb 2001 17:28:41 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id RAA07701; Mon, 26 Feb 2001 17:27:21 +0900 (JST) Message-Id: <4.2.0.58.J.20010226173104.00a98800@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 26 Feb 2001 17:37:18 +0900 To: Hiroshi Tamura From: MAEDA toru Subject: Re: identifying parts Cc: dwing@cisco.com, ietf-fax@imc.org In-Reply-To: <20010223083358J.tamura@toda.ricoh.co.jp> References: <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> <0102210848380.4753-100000@omega.cisco.com> <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tamura-san I think we need some description about DSN and MDN when multiple TIFF files are received, in the implementers guide. I do not mean that the partial deliver notification is required in the implementers guide. Regards. Toru Maeda At 08:33 01/02/23 +0900, Hiroshi Tamura wrote: >MAEDA-san, > > > Are there any description about these Methods described by Wing-san in > > the implementation guide? > >No. We do not have any descriptions about page-by-page confirmation >in our guide. > >Regards, >-- >Hiroshi Tamura, Ricoh Company, LTD. >E-mail: tamura@toda.ricoh.co.jp > > > > At 09:11 01/02/21 -0800, Dan Wing wrote: > > >This question is related to > > >draft-maeda-faxwg-fax-processing-status-00.txt. > > > > > > > > >A long time ago, I recall that some ifax sending devices would (or > > >could) send a multiple pages as multiple one-page TIFF > > >attachments. > > > > > >Here is a description of several different valid messages which describe > > >the problem I see with the current proposal in > > >draft-maeda-faxwg-fax-processing-status-00.txt. The problem is that it > > >cannot identify the "page" successfully -- the definition of a page is > > >different from the sender and the receiver's view. Email allows > > >much richer operation than scanning, transmitting, and printing. This > > >richer operation means a straight-forward "page NNN failed" is not > > >sufficient for email. > > > > > >A proposal to resolve this problem is below. The proposal allows > > >operation as described in draft-maeda-faxwg-fax-processing-status-00.txt > > >while also allowing the richer operation of email. > > > > > > > > > > > > > > >Method 1: > > > > > > From: someone@default.com > > > To: someone-else@default.com > > > Subject: 3 page fax > > > Message-ID: <123@default.com> > > > Date: 1 Jan 2001 01:00:00 -0800 > > > Content-Type: multipart/mixed; boundary=ABC > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC-- > > > > > > > > >Method 2: > > > > > > From: someone@default.com > > > To: someone-else@default.com > > > Subject: 3 page fax > > > Message-ID: <123@default.com> > > > Date: 1 Jan 2001 01:00:00 -0800 > > > Content-Type: multipart/mixed; boundary=ABC > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC-- > > > > > > > > >Method 3: > > > > > > From: someone@default.com > > > To: someone-else@default.com > > > Subject: 3 page fax > > > Message-ID: <123@default.com> > > > Date: 1 Jan 2001 01:00:00 -0800 > > > Content-Type: multipart/mixed; boundary=ABC > > > > > > --ABC > > > Content-type: text/plain > > > > > > FAX COVERSHEET > > > > > > From: Jim > > > To: Susan > > > Date: 1 Jan 2001 01:00:00, Pacific Time > > > Contact: jim@default.com, 408-555-1212 > > > > > > Susan, > > > > > > Here is the fax you requested. There should be 4 pages total > > > (this coversheet, plus 3 pages of the fax content itself). > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC-- > > > > > >To support non-ASCII languages on the coversheet, the first part in Method > > >3 could be image/tiff which contains a graphical representation of the > > >coversheet. > > > > > > > > >Method 4: > > > > > > From: someone@default.com > > > To: someone-else@default.com > > > Subject: 3 page fax > > > Message-ID: <123@default.com> > > > Date: 1 Jan 2001 01:00:00 -0800 > > > Content-Type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > > > >Method 5: > > > > > > From: someone@default.com > > > To: someone-else@default.com > > > Subject: your two faxes: Sumerset, Egghead > > > Content-Type: multipart/mixed; boundary=ABC > > > Date: 1 Jan 2001 01:00:00 -0800 > > > Message-ID: <123@default.com> > > > > > > --ABC > > > Content-type: text/plain > > > > > > FAX COVERSHEET > > > > > > From: Jim > > > To: Susan > > > Date: 1 Jan 2001 01:00:00, Pacific Time > > > Contact: jim@default.com, 408-555-1212 > > > > > > Susan, > > > > > > Here are your two faxes. The first one is a 3 page fax from > > > Sumerset, Inc. The second one is a 9 page fax from Egghead. > > > > > > Thanks. > > > Jim > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC > > > content-type: image/tiff > > > content-transfer-encoding: base64 > > > > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > EJKFJFKEJKEFJFKJEFJKEJFEJFKEJ > > > > > > --ABC-- > > > > > > > > >I _believe_ that most dedicated ifax devices use Method 4, above. I > > >believe most of the typical mailers (Netscape, Eudora, Outlook) would use > > >Method 2 or Method 3, above. > > > > > > > > >I feel it is critical that any MDN or DSN response indicating a portion of > > >a message was successfully or unsuccessfully processed must also indicate > > >which MIME part is being described in the MDN or DSN reponse -- it is NOT > > >as simple as the "page" having the problem, especially if Method 1 is used > > >-- they are all page "1" from the view of the sender. Method 1 is a valid > > >message format and is allowed, so we must handle it correctly. > > > > > > > > >I propose we require the use of Content-ID to identify MIME parts. This > > >identification allows the MDN to indicate which part(s) were successfully > > >or unsuccessfully processed. > > > > > >Content-ID is described in RFC2045, section 7. Its use is discussed in > > >RFC2046. > > > > > >-Dan Wing > > > > -------------------- > > MAEDA TORU > > MIE Development Div. 2 > > CANON Inc. > > -------------------- ----------------------------------- $B%-%d%N%s3t<02q; Mon, 26 Feb 2001 04:23:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA24996 for ietf-fax-bks; Mon, 26 Feb 2001 00:55:42 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA24992 for ; Mon, 26 Feb 2001 00:55:40 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id RAA28905; Mon, 26 Feb 2001 17:55:39 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma028702; Mon, 26 Feb 01 17:54:50 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id RAA09474; Mon, 26 Feb 2001 17:54:50 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id RAA18203; Mon, 26 Feb 2001 17:54:49 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id RAA09349; Mon, 26 Feb 2001 17:53:30 +0900 (JST) Message-Id: <4.2.0.58.J.20010226174011.00a98910@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 26 Feb 2001 18:03:26 +0900 To: ietf-fax@imc.org From: MAEDA toru Subject: draft-maeda-faxwg-fax-processing-status-00.txt Cc: Hiroshi Tamura , Claudio Allocchio 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: Hi, I have submitted the internet draft and it is available from the on-line Internet-Drafts directories. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol for Terminal Mode Author(s) : T. Maeda Filename : draft-maeda-faxwg-fax-processing-status-00.txt Pages : 4 Date : 20-Feb-01 http URL:draft-maeda-faxwg-fax-processing-status-00.txt [abstract] This proposal describes a fax processing status which was requested in ITU-T SG16 meeting on November 2000 at Geneva, for Full Mode. The notification of success/failure of document processing and page by page status from the receiver is very important feature for the internet fax. URLs of Other IDs I submitted are as follows, http URL:draft-maeda-faxwg-terminal-mode-goals-00.txt http URL:draft-maeda-faxwg-terminal-mode-protocol-00.txt Regards Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Mon Feb 26 04:25:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03081 for ; Mon, 26 Feb 2001 04:25:03 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA25002 for ietf-fax-bks; Mon, 26 Feb 2001 00:55:51 -0800 (PST) Received: from mail.notes.ricoh.co.jp (mail2.notes.ricoh.co.jp [202.211.49.12]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA24998 for ; Mon, 26 Feb 2001 00:55:49 -0800 (PST) Received: from artemis.isd.ricoh.co.jp (artemis [133.139.250.72]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id RAA17098; Mon, 26 Feb 2001 17:55:37 +0900 (JST) Received: from newton.toda.ricoh.co.jp by artemis.isd.ricoh.co.jp (8.9.3+3.2W/3.7W) id RAA17114; Mon, 26 Feb 2001 17:55:36 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id RAA05421; Mon, 26 Feb 2001 17:55:16 +0900 To: maeda.toru@canon.co.jp Cc: dwing@cisco.com, ietf-fax@imc.org Subject: Re: identifying parts In-Reply-To: <4.2.0.58.J.20010226173104.00a98800@ffmmail.ffm.canon.co.jp> References: <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> <20010223083358J.tamura@toda.ricoh.co.jp> <4.2.0.58.J.20010226173104.00a98800@ffmmail.ffm.canon.co.jp> 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: <20010226180232Y.tamura@toda.ricoh.co.jp> Date: Mon, 26 Feb 2001 18:02:32 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit MAEDA-san, > I think we need some description about DSN and MDN > when multiple TIFF files are received, > in the implementers guide. Fortunately, we alread have. See Section 4.4.5. --------------------------------------------------------------------------- 4.4.5 Receiving Multiple TIFF-FX Attachments A received email message could contain multiple TIFF-FX attachments and each distinct TIFF-FX file may use different encoding and/or resolution. A received email message could include TIFF-FX attachment and non-TIFF-FX attachments. There is currently no mechanism to identify, in a returned MDN, the attachments that were successfully decoded from those that could not be decoded. If the Extended Mode recipient is unable to decode any of the attached files, it is recommended that the Extended Mode recipient return a decoding error for the entire message. --------------------------------------------------------------------------- This is NOT to intend page-by-page confirmation. As you already know, We cannot have the page-by-page confirmation in RFC2532. Therefore, this description is reasonable, I think. Please do not complicate it. If you stick to it, you should propose in your I-Ds. > I do not mean that the partial deliver notification is required in the > implementers guide. With regard to this issue, please respond in the corresponding thread. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Feb 26 05:52:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03646 for ; Mon, 26 Feb 2001 05:52:09 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA27383 for ietf-fax-bks; Mon, 26 Feb 2001 02:16:38 -0800 (PST) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA27378 for ; Mon, 26 Feb 2001 02:16:35 -0800 (PST) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id TAA12610; Mon, 26 Feb 2001 19:16:31 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma012492; Mon, 26 Feb 01 19:15:23 +0900 Received: (from root@localhost) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) id TAA17176; Mon, 26 Feb 2001 19:15:23 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA05367; Mon, 26 Feb 2001 19:15:23 +0900 (JST) Received: from MAEADA18209N ([172.22.36.20]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id TAA14319; Mon, 26 Feb 2001 19:15:21 +0900 (JST) Message-Id: <4.2.0.58.J.20010226191526.00aa9a10@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 26 Feb 2001 19:24:00 +0900 To: Hiroshi Tamura From: MAEDA toru Subject: Re: identifying parts Cc: dwing@cisco.com, ietf-fax@imc.org In-Reply-To: <20010226180232Y.tamura@toda.ricoh.co.jp> References: <4.2.0.58.J.20010226173104.00a98800@ffmmail.ffm.canon.co.jp> <4.2.0.58.J.20010222203259.00a9b390@ffmmail.ffm.canon.co.jp> <20010223083358J.tamura@toda.ricoh.co.jp> <4.2.0.58.J.20010226173104.00a98800@ffmmail.ffm.canon.co.jp> 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: Tamura-san Thank you for clarification about m,y question. At 18:02 01/02/26 +0900, Hiroshi Tamura wrote: >MAEDA-san, > ... >This is NOT to intend page-by-page confirmation. As you already know, >We cannot have the page-by-page confirmation in RFC2532. Therefore, >this description is reasonable, I think. Yes, it is reasonable for us. But you can have the page-by-page confirmation if you want. >Please do not complicate it. I did not mean it. I wanted to confirm that your ID describes about multiple files. >If you stick to it, you should propose in your I-Ds. Yes, I have submitted the ID "fax processing status". > > I do not mean that the partial deliver notification is required in the > > implementers guide. > >With regard to this issue, please respond in the corresponding thread. I did not mean more than I wrote. Regards. Toru Maeda -------------------- MAEDA TORU MIE Development Div. 2 CANON Inc. -------------------- From owner-ietf-fax@mail.imc.org Wed Feb 28 07:55:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04474 for ; Wed, 28 Feb 2001 07:55:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA20587 for ietf-fax-bks; Wed, 28 Feb 2001 04:08:36 -0800 (PST) Received: from fallback-mx1.registeredsite.com (fallback-mx1.registeredsite.com [64.224.9.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA20578 for ; Wed, 28 Feb 2001 04:08:34 -0800 (PST) Received: from mail1.registeredsite.com (IDENT:root@mail1.registeredsite.com [64.224.9.10]) by fallback-mx1.registeredsite.com (8.11.1/8.11.1) with ESMTP id f1SC8YE14541 for ; Wed, 28 Feb 2001 07:08:34 -0500 Received: from mail.sharppage.com (mail.sharppage.com [216.247.135.231]) by mail1.registeredsite.com (8.11.1/8.11.1) with ESMTP id f1SC84d17767 for ; Wed, 28 Feb 2001 07:08:04 -0500 Received: from localhost [216.69.200.132] by mail.sharppage.com with ESMTP (SMTPD32-6.05) id AA1D7EC00082; Wed, 28 Feb 2001 07:07:57 -0500 X-Sender: sales@sharppage.com From: SharpPage Web Design To: ietf-fax@imc.org Date: Wed, 28 Feb 2001 07:16:26 -0800 Subject: Get Your Business Noticed! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__67179113_26186.27" Message-Id: <200102280707734.SM00479@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. ------=_NextPart_000_001__67179113_26186.27 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_001__67179113_26186.27 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCg0KPGh0bWw+DQo8aGVhZD4NCgkNCjx0aXRsZT5TaGFycFBhZ2UgLSBXZWIg RGVzaWduIFNlcnZpY2VzPC90aXRsZT4NCgkNCjxtZXRhIG5hbWU9ImRlc2NyaXB0aW9uIiBj b250ZW50PSJTaGFycFBhZ2Ugd2ViIGRlc2lnbiBpcyBhIGZ1bGwgc2VydmljZSB3ZWIgZGVz aWduIGNvbXBhbnkuIFRoZSBlbmQgcmVzdWx0IG9mIG91ciB3b3JrIHdpbGwgYmUgYSBzaXRl IHRoYXQgaXMgaW52aXRpbmcgYW5kIGluZm9ybWF0aXZlIGFuZCB3aWxsIGNhcHR1cmUgeW91 ciBhdWRpZW5jZSdzIGV5ZS4iPg0KPG1ldGEgbmFtZT0ia2V5d29yZHMiIGNvbnRlbnQ9Indl YiBkZXNpZ24sIGNvcnBvcmF0ZSBob3VzaW5nLCBzZWFyY2ggZW5naW5lIHRpcHMsIHNpdGUg ZGV2ZWxvcG1lbnQsIGludGVybmV0LCBjb3Jwb3JhdGUgaG91c2luZyB3ZWIgZGVzaWduLCBl bXBsb3ltZW50LCBjdXN0b20gd2ViIGRlc2lnbiwgd2VibWFzdGVyaW5nLCB3ZWJzZWl0ZSwg d2VibWFzdGVyLCBkZXNpZ24sIHdlYmRlc2lnbiwgbWFya2V0aW5nLCBncmFwaGljcywgd2Vi IHByb21vdGlvbnMsIHN1Ym1pc3Npb25zLCB3b3JsZHdpZGUsIGluZm9ybWF0aW9uLCB0ZW1w b3JhcnkgaG91c2luZywgY29ycG9yYXRlIGhvdXNpbmcgTG9zIEFuZ2VsZXMsIHdvcmxkIHdp ZGUgd2ViLCBkZXNpZ24sIG5ld3MsIHdlYiBkZXNpZ24iPg0KPC9oZWFkPg0KDQo8Ym9keSBi Z2NvbG9yPSIjMDAwMDAwIiBhbGluaz0icmVkIiBsaW5rPSJyZWQiIHZsaW5rPSJSZWQiPg0K DQo8dGFibGUgd2lkdGg9IjUzNiIgYm9yZGVyPSIwIiBiZ2NvbG9yPSJibGFjayIgYWxpZ249 ImNlbnRlciI+DQo8dHI+IA0KPHRkIGhlaWdodD0iNzYiPiANCjxjZW50ZXI+DQo8cD4gPGEg aHJlZj0iaHR0cDovL3d3dy5zaGFycHBhZ2UuY29tIj48aW1nIHNyYz0iaHR0cDovL3d3dy5z aGFycHBhZ2UuY29tL2ltYWdlcy9lbWFpbGhlYWRlcl9yMV9jMDEuZ2lmIiB3aWR0aD0iMTI1 IiBoZWlnaHQ9IjQ2IiBib3JkZXI9IjAiPjwvYT48YSBocmVmPSJodHRwOi8vd3d3LnNoYXJw cGFnZS5jb20iPjxpbWcgc3JjPSJodHRwOi8vd3d3LnNoYXJwcGFnZS5jb20vaW1hZ2VzL2Vt YWlsaGVhZGVyX3IxX2MwNS5naWYiIHdpZHRoPSI5MyIgaGVpZ2h0PSI0NiIgYm9yZGVyPSIw Ij48L2E+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9Ii0xIiBmYWNlPSJWZXJkYW5hLCBB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9 IiNGRkZGRkYiIHNpemU9Ii0xIiBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmIj5FLW1haWw6IA0KPGEgaHJlZj0ibWFpbHRvOnNhbGVzQHNoYXJwcGFnZS5j b20iPnNhbGVzQHNoYXJwcGFnZS5jb208L2E+PC9mb250Pjxmb250IGNvbG9yPSIjRkZGRkZG IiBzaXplPSItMSIgZmFjZT0iYXJpYWwiPjxicj4NClRvbGwgRnJlZTogPGI+MS04NzctNzg1 LTI1NzI8L2I+PC9mb250PiA8L3A+DQo8L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KPHRyPiAN Cjx0ZCBoZWlnaHQ9IjU0OCI+IA0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRoPSI0NTYi IGJvcmRlcj0iMCI+DQo8dHI+IA0KPHRkIGhlaWdodD0iMjYiIGFsaWduPSJjZW50ZXIiPjxz dHJvbmc+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZiIgc2l6ZT0iMyIgY29sb3I9IndoaXRlIj5XaHkgDQpTaG91bGQgWW91ciBCdXNpbmVzcyBC ZSBPbiBUaGUgV2ViPzwvZm9udD48L3N0cm9uZz48L3RkPg0KPC90cj4NCjx0cj4gDQo8dGQg aGVpZ2h0PSI4OCI+IA0KPHA+PGZvbnQgZmFjZT0iYXJpYWwiIHNpemU9IjMiIGNvbG9yPSIj RkZGRkZGIj48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIiBzaXplPSItMSI+SW4gDQp0b2RheSdzIGZhc3QgcGFjZWQgc29jaWV0eSwgaGF2aW5n IGEgd2ViIHNpdGUgaGFzIGJlY29tZSBhbiBpbmNyZWFzaW5nbHkgZXNzZW50aWFsIA0KcGFy dCBvZiBkb2luZyBxdWFsaXR5IGJ1c2luZXNzLiBXaGV0aGVyIHRoZXkgYXJlIHNob3BwaW5n LCBsZWFybmluZywgb3IgbWVyZWx5IA0Kc3VyZmluZyB0aGUgd2ViLCBjdXN0b21lcnMgYXBw cmVjaWF0ZSB0aGUgZWFzZSBvZiBzZXJ2aWNlIHRoYXQgY29tZXMgd2l0aCBhIHdlbGwgDQpk ZXNpZ25lZCB3ZWIgc2l0ZS48L2ZvbnQ+PC9mb250PjwvcD4NCjxwPiA8Zm9udCBmYWNlPSJW ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSItMSIgY29sb3I9 IndoaXRlIj5TaGFycFBhZ2UgDQpvZmZlcnMgdG90YWwgd2ViIHNpdGUgZGV2ZWxvcG1lbnQg cGFja2FnZXMgc3RhcnRpbmcgYXQgb25seSAkMTIwMC4gVGhlc2UgcGFja2FnZXMgDQppbmNs dWRlOiA8L2ZvbnQ+DQogICAgICAgICAgICA8Zm9udCBmYWNlPSJhcmlhbCIgc2l6ZT0iMyIg Y29sb3I9IndoaXRlIj4gDQogICAgICAgICAgICA8dWw+DQogICAgICAgICAgICAgIDxsaT48 Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXpl PSItMSI+RG9tYWluIA0KICAgICAgICAgICAgICAgIE5hbWUgUmVnaXN0cmF0aW9uIDwvZm9u dD4gDQogICAgICAgICAgICAgIDxsaT48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSItMSI+V2ViIA0KICAgICAgICAgICAgICAgIFNp dGUgSG9zdGluZyA8L2ZvbnQ+IA0KICAgICAgICAgICAgICA8bGk+PGZvbnQgZmFjZT0iVmVy ZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iLTEiPiANCiAgICAg ICAgICAgICAgICBDdXN0b20gV2ViIFNpdGUgRGVzaWduIDwvZm9udD4gDQogICAgICAgICAg ICAgIDxsaT48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIiBzaXplPSItMSI+IA0KICAgICAgICAgICAgICAgIFVubGltaXRlZCBFLW1haWwgQWNj b3VudHMgPC9mb250PiANCiAgICAgICAgICAgICAgPGxpPjxmb250IGZhY2U9IlZlcmRhbmEs IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9Ii0xIj4gDQogICAgICAgICAg ICAgICAgU2Nhbm5pbmcgYW5kIFBob3RvIFdvcmsgPC9mb250PiANCiAgICAgICAgICAgICAg PGxpPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi IHNpemU9Ii0xIj5IaWdoIA0KICAgICAgICAgICAgICAgIEltcGFjdCBMb2dvIERlc2lnbjwv Zm9udD4gDQogICAgICAgICAgICAgIDxsaT48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSItMSI+IA0KICAgICAgICAgICAgICAgIEN1 c3RvbSBDb250YWN0IEZvcm1zIDwvZm9udD4gDQogICAgICAgICAgICAgIDxsaT48Zm9udCBm YWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSItMSI+ IA0KICAgICAgICAgICAgICAgIFByb21vdGlvbiBvZiBZb3VyIEJ1c2luZXNzIDwvZm9udD4g DQogICAgICAgICAgICA8L3VsPg0KICAgICAgICAgICAgPC9mb250PiANCiAgICAgICAgICAg IDxwPjxmb250IGNvbG9yPSJ3aGl0ZSIgc2l6ZT0iLTEiIGZhY2U9IlZlcmRhbmEsIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2hhcnBwYWdl LmNvbS8iPjxmb250IGNvbG9yPSIjRkYwMDAwIj5TaGFycFBhZ2UgDQpXZWIgRGVzaWduPC9m b250PjwvYT4gY2FuIGNyZWF0ZSBhIHdlYiBzaXRlIHRoYXQgcmVmbGVjdHMgeW91ciBjb21w YW55J3MgaW1hZ2UgDQphbmQgYXR0cmFjdHMgeW91ciB0YXJnZXQgYXVkaWVuY2UuJm5ic3A7 V2UgaGF2ZSBjcmVhdGVkIG1hbnkgPGEgaHJlZj0iaHR0cDovL3d3dy5zaGFycHBhZ2UuY29t L3Byb2plY3RzbmV3Lmh0bWwiPjxmb250IGNvbG9yPSIjRkYwMDAwIj5zdWNjZXNzZnVsIA0K d2ViIHNpdGVzPC9mb250PjwvYT4gZm9yIGEgdmFyaWV0eSBvZiBidXNpbmVzc2VzLiA8L2Zv bnQ+PC9wPg0KICAgICAgICAgICAgPHA+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhl bHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iLTEiIGNvbG9yPSJ3aGl0ZSI+IA0KICAgICAg ICAgICAgICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBzaXRlIGRldmVsb3BtZW50IG9yIHJl ZGVzaWduLCA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9Ii0xIiBmYWNlPSJW ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48Yj5wbGVhc2UgDQogICAg ICAgICAgICAgIGNhbGwgdXMgdG9sbCBmcmVlIGF0IDxmb250IGNvbG9yPSIjMDAzM0ZGIj4x LTg3Ny03ODUtMjU3MjwvZm9udD48L2I+IA0KICAgICAgICAgICAgICBvciBzZW5kIHVzIGFu IEUtbWFpbCBhdCA8YSBocmVmPSJtYWlsdG86c2FsZXNAc2hhcnBwYWdlLmNvbSI+c2FsZXNA c2hhcnBwYWdlLmNvbTwvYT4gDQogICAgICAgICAgICAgIGZvciBjb25zdWx0YXRpb24uICZu YnNwO1dlIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGggeW91ISA8L2ZvbnQ+PC9wPg0K PC90ZD4NCjwvdHI+DQo8dHIgdmFsaWduPSJtaWRkbGUiPiANCjx0ZCBhbGlnbj0iY2VudGVy Ij4gDQo8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8dHI+IA0K PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGNvbG9yPSIjMDBGRkZGIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiIgc2l6ZT0iMiI+PGEgaHJlZj0ibWFpbHRvOnNhbGVz QHNoYXJwcGFnZS5jb20/U3ViamVjdD1SZW1vdmUgICZib2R5PQ0KKioqKioqKioqIFRoYW5r IHlvdSBmb3IgY29uc2lkZXJpbmcgU2hhcnBQYWdlIHdlYiBkZXNpZ24gc2VydmljZXMgKioq KioqKioqKiI+VG8gDQp1bnN1YnNjcmliZSBwbGVhc2UgY2xpY2sgb24gdGhpcyBsaW5rIGFu ZCBzZW5kLjwvYT4uPC9mb250PjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCjwvdGQ+DQo8L3Ry Pg0KPC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__67179113_26186.27--