From owner-ietf-fax@mail.imc.org Mon Jul 2 14:37: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 OAA06666 for ; Mon, 2 Jul 2001 14:37:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62HUH728720 for ietf-fax-bks; Mon, 2 Jul 2001 10:30:17 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62HUFm28716 for ; Mon, 2 Jul 2001 10:30:15 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id TAA10286 for ; Mon, 2 Jul 2001 19:26:30 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma010279; Mon, 2 Jul 01 19:26:23 +0200 Received: from crf.canon.fr ([194.2.81.21]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GFUVWA00.MQE; Mon, 2 Jul 2001 19:14:35 +0200 Message-ID: <3B40AF51.2AAF4DDA@crf.canon.fr> Date: Mon, 02 Jul 2001 19:28:49 +0200 From: "MAEDA Toru" Organization: Canon Research Centre France X-Mailer: Mozilla 4.75 [ja] (Win98; U) X-Accept-Language: ja MIME-Version: 1.0 To: Dan Wing CC: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Wing-san We need further discussion about the valid "codes". Do you have any idea about it? Regards. Toru Maeda Dan Wing wrote: > > Hi. > > This I-D shows the following: > > 2. MDN extension > To send fax prosessing status from the receiver, MDN extension field > is used for results, received page number and error page number. > > MDN extension field: > Fax-Report: Fax-Results = code > ; Fax-Pages = received page number > ; Fax-Errorpage = error page number > > What are the valid "codes"? > > -d > > > -----Original Message----- > > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Wednesday, June 27, 2001 4:03 AM > > To: IETF-Announce: > > Cc: ietf-fax@imc.org > > Subject: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > 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 : Fax Processing Status > > Author(s) : T. Maeda > > Filename : draft-ietf-fax-faxprocessing-status-00.txt > > Pages : 4 > > Date : 26-Jun-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-ietf-fax-faxprocessing-sta > > tus-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-ietf-fax-faxprocessing-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-ietf-fax-faxprocessing-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 Canon Research Centre France S.A. *********************************** From owner-ietf-fax@mail.imc.org Mon Jul 2 14:58:28 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 OAA22147 for ; Mon, 2 Jul 2001 14:58:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62HWHo28761 for ietf-fax-bks; Mon, 2 Jul 2001 10:32:17 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62HWFm28757 for ; Mon, 2 Jul 2001 10:32:15 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id TAA10301 for ; Mon, 2 Jul 2001 19:28:30 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma010295; Mon, 2 Jul 01 19:28:17 +0200 Received: from crf.canon.fr ([194.2.81.21]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GFUVZH00.BQM; Mon, 2 Jul 2001 19:16:29 +0200 Message-ID: <3B40AFC4.81790A7D@crf.canon.fr> Date: Mon, 02 Jul 2001 19:30:44 +0200 From: "MAEDA Toru" Organization: Canon Research Centre France X-Mailer: Mozilla 4.75 [ja] (Win98; U) X-Accept-Language: ja MIME-Version: 1.0 To: Dan Wing CC: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Wing-san Could you explain about the current situation that the existing infrastructure doesn't permit connecting directly from Internet hosts to internal SMTP servers Regards. Toru Maeda Dan Wing wrote: > > I'm unclear on why the ability to fallback requires the original attempt be in > SMTP. > > The goals document also says that "Use of Existing Infrastructure" is a goal. > You do know that the existing infrastructure doesn't permit connecting > directly from Internet hosts to internal SMTP servers? > > -d > > > -----Original Message----- > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > Sent: Thursday, June 28, 2001 10:12 AM > > To: Dan Wing > > Cc: ietf-fax@imc.org > > Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > Hi, Wing-san > > > > Thank you for your comments. > > > > Since Terminal Mode should fall back to Full Mode or Simple Mode, > > ESMTP is more preferable than IPP. > > > > Regards. > > > > Toru Maeda > > > > > > Dan Wing wrote: > > > > > > IPP is more suitable for these goals than SMTP. > > > > > > -d > > > > > > > -----Original Message----- > > > > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On > > > > Behalf Of Internet-Drafts@ietf.org > > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > > To: IETF-Announce: > > > > Cc: ietf-fax@imc.org > > > > Subject: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > > > > 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 : Goals for Terminal Mode > > > > Author(s) : T. Maeda > > > > Filename : draft-ietf-fax-terminal-mode-goals-00.txt > > > > Pages : 5 > > > > Date : 26-Jun-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. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-fax-terminal-mode-goa > > > > ls-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-ietf-fax-terminal-mode-goals-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-ietf-fax-terminal-mode-goals-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 > > Canon Research Centre France S.A. > > *********************************** -- *********************************** MAEDA TORU Canon Research Centre France S.A. *********************************** From owner-ietf-fax@mail.imc.org Mon Jul 2 14:58:57 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 OAA22558 for ; Mon, 2 Jul 2001 14:58:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62I2wE00950 for ietf-fax-bks; Mon, 2 Jul 2001 11:02:58 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62I2vm00944 for ; Mon, 2 Jul 2001 11:02:57 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f62I32x00810; Mon, 2 Jul 2001 11:03:02 -0700 (PDT) Received: from DWINGW2K (dwings-dsl3.cisco.com [10.19.89.164]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AHP01063; Mon, 2 Jul 2001 11:02:52 -0700 (PDT) From: "Dan Wing" To: "MAEDA Toru" Cc: Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt Date: Mon, 2 Jul 2001 11:02:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B40AF51.2AAF4DDA@crf.canon.fr> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Enumerate the T.30 error codes, I guess, as this is very T.30 specific. Text needs to be added that transmission should be ceased when an error page is encountered (again, very T.30 specific). There should be codes added for 'unable to process TIFF file' or 'invalid TIFF file' -- for example, if the email is marked clearly as 'image/tiff', but the attachment is really a PDF file or a Microsoft Word document, or a JPG, etc., it isn't a valid TIFF and this can't be assigned a T.30 error code. So, I would say some ABNF like this: code = attachment_code | t30_code t30_code = "T30" ... all of the T30 codes .... attachment_code = "Attachment" att_code att_code = "unable to process attachment as TIFF" | "invalid pointer in TIFF" Where "... all of the T30 codes ...." enumerates all of the error codes from T.30 into a textual or numeric ASCII format -- not binary. Comments from anyone on this? -d > -----Original Message----- > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > Sent: Monday, July 02, 2001 10:29 AM > To: Dan Wing > Cc: ietf-fax@imc.org > Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > Hi, Wing-san > > We need further discussion about the valid "codes". > Do you have any idea about it? > > Regards. > > Toru Maeda > > > Dan Wing wrote: > > > > Hi. > > > > This I-D shows the following: > > > > 2. MDN extension > > To send fax prosessing status from the receiver, MDN extension field > > is used for results, received page number and error page number. > > > > MDN extension field: > > Fax-Report: Fax-Results = code > > ; Fax-Pages = received page number > > ; Fax-Errorpage = error page number > > > > What are the valid "codes"? > > > > -d > > > > > -----Original Message----- > > > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > To: IETF-Announce: > > > Cc: ietf-fax@imc.org > > > Subject: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > > > > 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 : Fax Processing Status > > > Author(s) : T. Maeda > > > Filename : draft-ietf-fax-faxprocessing-status-00.txt > > > Pages : 4 > > > Date : 26-Jun-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-ietf-fax-faxprocessing-sta > > > tus-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-ietf-fax-faxprocessing-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-ietf-fax-faxprocessing-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 > Canon Research Centre France S.A. > *********************************** From owner-ietf-fax@mail.imc.org Mon Jul 2 15:12:02 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 PAA00918 for ; Mon, 2 Jul 2001 15:12:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62IDH101829 for ietf-fax-bks; Mon, 2 Jul 2001 11:13:17 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62IDGm01824 for ; Mon, 2 Jul 2001 11:13:16 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f62IDLr02503; Mon, 2 Jul 2001 11:13:21 -0700 (PDT) Received: from DWINGW2K (dwings-dsl3.cisco.com [10.19.89.164]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AHP01361; Mon, 2 Jul 2001 11:13:07 -0700 (PDT) From: "Dan Wing" To: "MAEDA Toru" Cc: Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Mon, 2 Jul 2001 11:13:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B40AFC4.81790A7D@crf.canon.fr> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit My mailer I use for POP (and IMAP) here at Cisco is mira-sjcm-3.cisco.com, IP address 171.69.24.15. Our firewall doesn't allow you to connect to the SMTP port of 171.69.24.15 from outside of Cisco: # telnet 171.69.24.15 25 Trying 171.69.24.15... telnet: connect to address 171.69.24.15: Operation timed out telnet: Unable to connect to remote host # I bet you nearly all companies have similar firewall configurations, as the current practice for any security-aware company is to have all incoming mail, ftp, and http traffic go to a device that is on the insecure side of the corporate firewall. This connection is completely terminated on this device and this device is then the only device permitted to connect to interior devices. You work for Canon, and I expect its configuration is similar -- direct connections from the Internet to port 25 of arbitrary devices inside of your company are not permitted. -d > -----Original Message----- > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > Sent: Monday, July 02, 2001 10:31 AM > To: Dan Wing > Cc: ietf-fax@imc.org > Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > Hi, Wing-san > > Could you explain about the current situation that the existing > infrastructure doesn't permit connecting directly from Internet hosts to > internal SMTP servers > > Regards. > > Toru Maeda > > > Dan Wing wrote: > > > > I'm unclear on why the ability to fallback requires the original > attempt be in > > SMTP. > > > > The goals document also says that "Use of Existing > Infrastructure" is a goal. > > You do know that the existing infrastructure doesn't permit connecting > > directly from Internet hosts to internal SMTP servers? > > > > -d > > > > > -----Original Message----- > > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > > Sent: Thursday, June 28, 2001 10:12 AM > > > To: Dan Wing > > > Cc: ietf-fax@imc.org > > > Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > Hi, Wing-san > > > > > > Thank you for your comments. > > > > > > Since Terminal Mode should fall back to Full Mode or Simple Mode, > > > ESMTP is more preferable than IPP. > > > > > > Regards. > > > > > > Toru Maeda > > > > > > > > > Dan Wing wrote: > > > > > > > > IPP is more suitable for these goals than SMTP. > > > > > > > > -d > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-fax@mail.imc.org > [mailto:owner-ietf-fax@mail.imc.org]On > > > > > Behalf Of Internet-Drafts@ietf.org > > > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > > > To: IETF-Announce: > > > > > Cc: ietf-fax@imc.org > > > > > Subject: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > > > > > > > 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 : Goals for Terminal Mode > > > > > Author(s) : T. Maeda > > > > > Filename : draft-ietf-fax-terminal-mode-goals-00.txt > > > > > Pages : 5 > > > > > Date : 26-Jun-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. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-fax-terminal-mode-goa > > > > > ls-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-ietf-fax-terminal-mode-goals-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-ietf-fax-terminal-mode-goals-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 > > > Canon Research Centre France S.A. > > > *********************************** > > -- > *********************************** > MAEDA TORU > Canon Research Centre France S.A. > *********************************** From owner-ietf-fax@mail.imc.org Mon Jul 2 17:12: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 RAA16296 for ; Mon, 2 Jul 2001 17:12:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62KL4513382 for ietf-fax-bks; Mon, 2 Jul 2001 13:21:04 -0700 (PDT) Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62KL2m13377 for ; Mon, 2 Jul 2001 13:21:03 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id NAA04453; Mon, 2 Jul 2001 13:25:35 -0700 (PDT) Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 13:16:06 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA537C52DA0@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Dan Wing'" , MAEDA Toru Cc: ietf-fax@imc.org Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt Date: Mon, 2 Jul 2001 13:16:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dan, I like your approach to the T.30 error codes below. But I would revise your two 'Attachment' error codes as follows: "unable to process attachment as TIFF" ---> "invalid attachment encoding" (because someday Internet Fax might allow other high-quality document formats like PDF as PWG IPP Fax has chosen to do) "invalid pointer in TIFF" ---> "invalid pointer in attachment" (which is understood and documented to include bad URL references in XML and PDF documents, as well) Comments? Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Monday, July 02, 2001 2:03 PM To: MAEDA Toru Cc: ietf-fax@imc.org Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt Enumerate the T.30 error codes, I guess, as this is very T.30 specific. Text needs to be added that transmission should be ceased when an error page is encountered (again, very T.30 specific). There should be codes added for 'unable to process TIFF file' or 'invalid TIFF file' -- for example, if the email is marked clearly as 'image/tiff', but the attachment is really a PDF file or a Microsoft Word document, or a JPG, etc., it isn't a valid TIFF and this can't be assigned a T.30 error code. So, I would say some ABNF like this: code = attachment_code | t30_code t30_code = "T30" ... all of the T30 codes .... attachment_code = "Attachment" att_code att_code = "unable to process attachment as TIFF" | "invalid pointer in TIFF" Where "... all of the T30 codes ...." enumerates all of the error codes from T.30 into a textual or numeric ASCII format -- not binary. Comments from anyone on this? -d > -----Original Message----- > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > Sent: Monday, July 02, 2001 10:29 AM > To: Dan Wing > Cc: ietf-fax@imc.org > Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > Hi, Wing-san > > We need further discussion about the valid "codes". > Do you have any idea about it? > > Regards. > > Toru Maeda > > > Dan Wing wrote: > > > > Hi. > > > > This I-D shows the following: > > > > 2. MDN extension > > To send fax prosessing status from the receiver, MDN extension field > > is used for results, received page number and error page number. > > > > MDN extension field: > > Fax-Report: Fax-Results = code > > ; Fax-Pages = received page number > > ; Fax-Errorpage = error page number > > > > What are the valid "codes"? > > > > -d > > > > > -----Original Message----- > > > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org] On > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > To: IETF-Announce: > > > Cc: ietf-fax@imc.org > > > Subject: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > > > > 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 : Fax Processing Status > > > Author(s) : T. Maeda > > > Filename : draft-ietf-fax-faxprocessing-status-00.txt > > > Pages : 4 > > > Date : 26-Jun-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-ietf-fax-faxprocessing-sta > > > tus-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-ietf-fax-faxprocessing-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-ietf-fax-faxprocessing-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 > Canon Research Centre France S.A. > *********************************** From owner-ietf-fax@mail.imc.org Mon Jul 2 17:26: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 RAA24623 for ; Mon, 2 Jul 2001 17:26:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62KhJL15228 for ietf-fax-bks; Mon, 2 Jul 2001 13:43:19 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62KhIm15222 for ; Mon, 2 Jul 2001 13:43:18 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f62KhFh29702; Mon, 2 Jul 2001 13:43:15 -0700 (PDT) Received: from DWINGW2K (dhcp-128-107-139-131.cisco.com [128.107.139.131]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AHQ01226; Mon, 2 Jul 2001 13:43:13 -0700 (PDT) From: "Dan Wing" To: "McDonald, Ira" , "MAEDA Toru" Cc: Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt Date: Mon, 2 Jul 2001 13:43:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <1115A7CFAC25D311BC4000508B2CA537C52DA0@mailsrvnt02.enet.sharplabs.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There are lots of things that could be wrong with an attachment; I believe Vivian's Implementation Guide document lists many of these. Perhaps we would like to number them, too, I don't know -- in any event it needs to be enumerated. -d > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: Monday, July 02, 2001 1:16 PM > To: 'Dan Wing'; MAEDA Toru > Cc: ietf-fax@imc.org > Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > Hi Dan, > > I like your approach to the T.30 error codes below. > > But I would revise your two 'Attachment' error codes as follows: > > "unable to process attachment as TIFF" > ---> "invalid attachment encoding" > (because someday Internet Fax might allow other high-quality > document formats like PDF as PWG IPP Fax has chosen to do) > > "invalid pointer in TIFF" > ---> "invalid pointer in attachment" > (which is understood and documented to include bad URL references > in XML and PDF documents, as well) > > Comments? > > Cheers, > - Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, July 02, 2001 2:03 PM > To: MAEDA Toru > Cc: ietf-fax@imc.org > Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > Enumerate the T.30 error codes, I guess, as this is very T.30 specific. > Text > needs to be added that transmission should be ceased when an error page is > encountered (again, very T.30 specific). There should be codes added for > 'unable to process TIFF file' or 'invalid TIFF file' -- for example, if the > email is marked clearly as 'image/tiff', but the attachment is really a PDF > file or a Microsoft Word document, or a JPG, etc., it isn't a valid TIFF and > this can't be assigned a T.30 error code. > > So, I would say some ABNF like this: > > code = attachment_code | t30_code > t30_code = "T30" ... all of the T30 codes .... > attachment_code = "Attachment" att_code > att_code = "unable to process attachment as TIFF" | > "invalid pointer in TIFF" > > Where "... all of the T30 codes ...." enumerates all of the error codes from > T.30 into a textual or numeric ASCII format -- not binary. > > > Comments from anyone on this? > > -d > > > -----Original Message----- > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > Sent: Monday, July 02, 2001 10:29 AM > > To: Dan Wing > > Cc: ietf-fax@imc.org > > Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > Hi, Wing-san > > > > We need further discussion about the valid "codes". > > Do you have any idea about it? > > > > Regards. > > > > Toru Maeda > > > > > > Dan Wing wrote: > > > > > > Hi. > > > > > > This I-D shows the following: > > > > > > 2. MDN extension > > > To send fax prosessing status from the receiver, MDN extension field > > > is used for results, received page number and error page number. > > > > > > MDN extension field: > > > Fax-Report: Fax-Results = code > > > ; Fax-Pages = received page number > > > ; Fax-Errorpage = error page number > > > > > > What are the valid "codes"? > > > > > > -d > > > > > > > -----Original Message----- > > > > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org] > On > > > > Behalf Of Internet-Drafts@ietf.org > > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > > To: IETF-Announce: > > > > Cc: ietf-fax@imc.org > > > > Subject: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > > > > > > > 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 : Fax Processing Status > > > > Author(s) : T. Maeda > > > > Filename : draft-ietf-fax-faxprocessing-status-00.txt > > > > Pages : 4 > > > > Date : 26-Jun-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-ietf-fax-faxprocessing-sta > > > > tus-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-ietf-fax-faxprocessing-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-ietf-fax-faxprocessing-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 > > Canon Research Centre France S.A. > > *********************************** From owner-ietf-fax@mail.imc.org Tue Jul 3 04:49:14 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 EAA04563 for ; Tue, 3 Jul 2001 04:49:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f637tNH02211 for ietf-fax-bks; Tue, 3 Jul 2001 00:55:23 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f637tKm02206 for ; Tue, 3 Jul 2001 00:55:21 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id JAA13456 for ; Tue, 3 Jul 2001 09:51:35 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma013443; Tue, 3 Jul 01 09:51:04 +0200 Received: from crf.canon.fr ([194.2.81.21]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GFVZXF00.FPH; Tue, 3 Jul 2001 09:39:15 +0200 Message-ID: <3B4179F7.BD866808@crf.canon.fr> Date: Tue, 03 Jul 2001 09:53:27 +0200 From: "MAEDA Toru" Organization: Canon Research Centre France X-Mailer: Mozilla 4.75 [ja] (Win98; U) X-Accept-Language: ja MIME-Version: 1.0 To: Dan Wing CC: Dave Crocker , ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt References: Content-Type: text/plain; charset=iso-2022-jp 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 > If you want something easier than T.38, IPP exists. IPP can be enhanced as > needed to support the features necessary to replicate fax. > Do you mean that "IPP" is IPP FAX? Regards. Toru Maeda Dan Wing wrote: > > Yes, shared code is good. > > "Fax terminal mode" is an end-to-end service which has much more in common > with PSTN fax and T.38 fax than the SMTP model of multiple hops, storing mail, > mailing lists, etc. > > IPP has more in common with transmitting documents than SMTP, and I still say > that IPP can provide something more closer approaching the goals of "fax > terminal mode" than SMTP. > > For universal messaging, T.37/RFC2305 is the way to go. For duplication of > exact fax functionality on an IP network, T.38 is the way to go. While T.38 > is more difficult than an IETF text-based protocol, forcing SMTP to > essentially do 'SAML' (everyone by Dave, see RFC821 for a description of SAML) > across multiple hops is hard. > > If you want something easier than T.38, IPP exists. IPP can be enhanced as > needed to support the features necessary to replicate fax. > > -d > > > -----Original Message----- > > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > > Sent: Saturday, June 30, 2001 7:55 AM > > To: Dan Wing > > Cc: MAEDA Toru; ietf-fax@imc.org > > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > At 01:39 PM 6/28/2001, Dan Wing wrote: > > >I'm unclear on why the ability to fallback requires the original > > attempt be in > > >SMTP. > > > > > > The more the modes have in common, the more code they share. That means > > that the different modes have less to implement. > > > > There also might be operational impact, such as retaining an SMTP > > connection. > > > > Retaining interworking with email continues to be a nice ability, too. > > > > It also makes it easier to evaluate the efficacy of each, different > > mode. The fewer modes the better/simpler. > > > > d/ > > > > ---------- > > Dave Crocker > > Brandenburg InternetWorking > > tel +1.408.246.8253; fax +1.408.273.6464 > > -- *********************************** MAEDA TORU Canon Research Centre France S.A. *********************************** From owner-ietf-fax@mail.imc.org Tue Jul 3 06:22: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 GAA02377 for ; Tue, 3 Jul 2001 06:21:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f639LSg06773 for ietf-fax-bks; Tue, 3 Jul 2001 02:21:28 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f639LJm06769 for ; Tue, 3 Jul 2001 02:21:19 -0700 (PDT) Date: Tue, 3 Jul 2001 11:20:22 +0100 To: Dan Wing cc: MAEDA Toru , ietf-fax@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > My mailer I use for POP (and IMAP) here at Cisco is mira-sjcm-3.cisco.com, IP > address 171.69.24.15. > > Our firewall doesn't allow you to connect to the SMTP port of 171.69.24.15 > from outside of Cisco: > > # telnet 171.69.24.15 25 > Trying 171.69.24.15... > telnet: connect to address 171.69.24.15: Operation timed out > telnet: Unable to connect to remote host > # > > I bet you nearly all companies have similar firewall configurations, as the > current practice for any security-aware company is to have all incoming mail, > ftp, and http traffic go to a device that is on the insecure side of the > corporate firewall. This connection is completely terminated on this device > and this device is then the only device permitted to connect to interior > devices. This is also completely true in general, as this is the correct secure configuration of servers on any LAN/Intranet. For example at GARR (and at nearly all the other R&D and academic netqorks, too) there is ONLY a few devices (well configured and controlled) which are SMTP accessible from outside. A tipical configuration on the router (cisco in this case) is: access-list 101 permit tcp any host 140.105.4.200 eq smtp access-list 101 deny tcp any any access-list 101 permit ip any any This will introduce a "relay" host (140.105.4.200 in the above example) between any sender and any internal SMTP server in ANY case, and thus there will be no direct negotiation nor delivery. Thus SMTP is defintly a "relay" protocol. Regards, Claudio From owner-ietf-fax@mail.imc.org Tue Jul 3 09:30: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 JAA28940 for ; Tue, 3 Jul 2001 09:30:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Cfbr12428 for ietf-fax-bks; Tue, 3 Jul 2001 05:41:37 -0700 (PDT) Received: from hotmail.com (f40.law7.hotmail.com [216.33.237.40]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Cfam12424 for ; Tue, 3 Jul 2001 05:41:36 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Jul 2001 05:29:46 -0700 Received: from 64.241.181.128 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 03 Jul 2001 12:29:44 GMT X-Originating-IP: [64.241.181.128] From: "Terry Brookes" To: dwing@cisco.com Cc: ietf-fax@imc.org, maeda@crf.canon.fr, dcrocker@brandenburg.com Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Tue, 03 Jul 2001 08:29:44 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2001 12:29:46.0098 (UTC) FILETIME=[D803CD20:01C103BB] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi I'd re-phrase the following- >IPP exists. < This would be more accurate- >IPP barely exists< Also 'IPP FAX' certainly does NOT exist...yet. IPP also requires infrastrucure in the form of IPP servers, so it may not meet the stated requirements of 'using existing infrastructure'. If SMTP really doesn't work for fax terminal mode then strategicaly the new Windows Instant Messenger could be a much better bet. It's likely to become a de facto standard for the non-AOL IM's, and with IM you get an instant response that should allow replication of T30 with great simplicity. You also get SIP with Windows IM, which could allow discovery of the capabilities of the receiving fax terminal, probably even give you the color of the operator's hair. Terry Brookes www.polyteq.com >From: "Dan Wing" >To: "Dave Crocker" >CC: "MAEDA Toru" , >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt >Date: Sat, 30 Jun 2001 17:42:39 -0700 > > >Yes, shared code is good. > >"Fax terminal mode" is an end-to-end service which has much more in common >with PSTN fax and T.38 fax than the SMTP model of multiple hops, storing >mail, >mailing lists, etc. > >IPP has more in common with transmitting documents than SMTP, and I still >say >that IPP can provide something more closer approaching the goals of "fax >terminal mode" than SMTP. > >For universal messaging, T.37/RFC2305 is the way to go. For duplication of >exact fax functionality on an IP network, T.38 is the way to go. While >T.38 >is more difficult than an IETF text-based protocol, forcing SMTP to >essentially do 'SAML' (everyone by Dave, see RFC821 for a description of >SAML) >across multiple hops is hard. > >If you want something easier than T.38, IPP exists. IPP can be enhanced as >needed to support the features necessary to replicate fax. > >-d > > > -----Original Message----- > > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > > Sent: Saturday, June 30, 2001 7:55 AM > > To: Dan Wing > > Cc: MAEDA Toru; ietf-fax@imc.org > > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > At 01:39 PM 6/28/2001, Dan Wing wrote: > > >I'm unclear on why the ability to fallback requires the original > > attempt be in > > >SMTP. > > > > > > The more the modes have in common, the more code they share. That means > > that the different modes have less to implement. > > > > There also might be operational impact, such as retaining an SMTP > > connection. > > > > Retaining interworking with email continues to be a nice ability, too. > > > > It also makes it easier to evaluate the efficacy of each, different > > mode. The fewer modes the better/simpler. > > > > d/ > > > > ---------- > > Dave Crocker > > Brandenburg InternetWorking > > tel +1.408.246.8253; fax +1.408.273.6464 > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ietf-fax@mail.imc.org Tue Jul 3 12:30:01 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 MAA11508 for ; Tue, 3 Jul 2001 12:29:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Fkfs19973 for ietf-fax-bks; Tue, 3 Jul 2001 08:46:41 -0700 (PDT) Received: from rhenium (rhenium.btinternet.com [194.73.73.93]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Fkdm19969 for ; Tue, 3 Jul 2001 08:46:40 -0700 (PDT) Received: from [213.122.162.96] (helo=GK-VAIO.ninebynine.org) by rhenium with esmtp (Exim 3.22 #9) id 15HSNo-0006rF-00; Tue, 03 Jul 2001 16:46:36 +0100 Message-Id: <5.0.2.1.2.20010703154842.03747270@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Jul 2001 15:50:14 +0100 To: Hiroshi Tamura From: Graham Klyne Subject: Re: I-D ACTION:draft-ietf-fax-timely-delivery-03.txt Cc: ietf-fax@imc.org In-Reply-To: <20010630140535G.tamura@toda.ricoh.co.jp> References: <5.0.2.1.2.20010623214748.0388b840@joy.songbird.com> <5.0.2.1.2.20010623092928.035f6cb0@joy.songbird.com> <20010623185828W.tamura@toda.ricoh.co.jp> <5.0.2.1.2.20010623214748.0388b840@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 02:05 PM 6/30/01 +0900, Hiroshi Tamura wrote: > > Title : Extensions to Mail System Status Codes > > Author(s) : G. Vaudreuil > > Filename : draft-vaudreuil-1983ext-00.txt > > Pages : 5 > > Date : 21-Jun-01 > > > > This document defines an additional set of extended status codes based > > on new messaging applications and associated error states since the > > creation of the original RFC 1893 document. These include extended > > media conversion codes for fax and voice messaging and results for > > message tracking. > >Is it being discussed in VPIM WG or just come out? >It addresses the fax related codes. I'm not aware that this is being discussed by VPIM. I'm not sure if it is being discussed specifically by any WG. #g ------------------------------------------------------------ Graham Klyne Baltimore Technologies Strategic Research Content Security Group ------------------------------------------------------------ From owner-ietf-fax@mail.imc.org Tue Jul 3 13:18: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 NAA12923 for ; Tue, 3 Jul 2001 13:18:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Gfle22270 for ietf-fax-bks; Tue, 3 Jul 2001 09:41:47 -0700 (PDT) Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Gfkm22265 for ; Tue, 3 Jul 2001 09:41:46 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id JAA19031; Tue, 3 Jul 2001 09:46:20 -0700 (PDT) Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 09:36:51 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA537C52DA4@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Dave Crocker'" , "McDonald, Ira" Cc: "'ietf-fax@imc.org'" , "'hastings@cp10.es.xerox.com'" , "'cmanros@cp10.es.xerox.com'" Subject: RE: FW: IFX> IPP FAX telecon, Fri, June 29, 12-2 PDT (3-5 EDT); R evie w IFX spe c Date: Tue, 3 Jul 2001 09:36:50 -0700 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: Hi Dave, My apologies for the very short notice - we had a regularly scheduled (and announced on the IPP FAX list) telecon on Wednesday and reviewed the UIF spec. Due to time constraints (trying to get new drafts out before next PWG plenary meeting) we decided to continue on Friday. I will ask Tom Hastings (current editor of IPP Fax protocol spec) to cross-post notices of future IPP Fax telecons to this IFax list, OK? Certainly some more dialogue would be a good thing. The IETF Apps ADs firmly rejected IPP Fax work under IETF auspices, so there is no present intent to publish the IEEE ISTO PWG specs for IPP Fax as RFCs (which I personally think is unfortunate, but I have a very lonely minority opinion here). Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Dave Crocker [mailto:dcrocker@brandenburg.com] Sent: Saturday, June 30, 2001 10:50 AM To: McDonald, Ira Cc: 'ietf-fax@imc.org'; 'hastings@cp10.es.xerox.com'; 'cmanros@cp10.es.xerox.com' Subject: Re: FW: IFX> IPP FAX telecon, Fri, June 29, 12-2 PDT (3-5 EDT); Revie w IFX spe c At 12:17 PM 6/29/2001, McDonald, Ira wrote: >We'd be very please to have any of the Internet Fax folks join us >this afternoon on the IFX spec review telecon. Thanks for the invitation. Some dialogue could be helpful. A little more notice, next time, would be quite helpful. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-fax@mail.imc.org Tue Jul 3 14:11: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 OAA14455 for ; Tue, 3 Jul 2001 14:10:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63HWj923704 for ietf-fax-bks; Tue, 3 Jul 2001 10:32:45 -0700 (PDT) Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63HWim23700 for ; Tue, 3 Jul 2001 10:32:44 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id KAA19883; Tue, 3 Jul 2001 10:37:17 -0700 (PDT) Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 10:27:47 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA537C52DAA@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Terry Brookes'" , dwing@cisco.com Cc: ietf-fax@imc.org, maeda@crf.canon.fr, dcrocker@brandenburg.com Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Tue, 3 Jul 2001 10:27:47 -0700 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: Hi Terry, Do you just dislike IPP? For IPP Fax to work, IPP does NOT need to be ubiquitous. It just needs to be ubiquitous in deployed PRINTERS. Very few printers shipped in calendar 2001 that did not have IPP protocol support. Probably NONE will ship in calendar 2002 without IPP protocol support. I agree that SMTP is ubiquitous, but it doesn't (and can't ever) do realtime capabilities negotiation, by its very nature. Certainly such protocols as IMPP (your suggestion) are utterly inappropriate for sending large documents by VALUE (like IPP) and not by REFERENCE. Could you explain your implacable opposition to IPP Fax, please? Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Terry Brookes [mailto:brookes_terry@hotmail.com] Sent: Tuesday, July 03, 2001 8:30 AM To: dwing@cisco.com Cc: ietf-fax@imc.org; maeda@crf.canon.fr; dcrocker@brandenburg.com Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Hi I'd re-phrase the following- >IPP exists. < This would be more accurate- >IPP barely exists< Also 'IPP FAX' certainly does NOT exist...yet. IPP also requires infrastrucure in the form of IPP servers, so it may not meet the stated requirements of 'using existing infrastructure'. If SMTP really doesn't work for fax terminal mode then strategicaly the new Windows Instant Messenger could be a much better bet. It's likely to become a de facto standard for the non-AOL IM's, and with IM you get an instant response that should allow replication of T30 with great simplicity. You also get SIP with Windows IM, which could allow discovery of the capabilities of the receiving fax terminal, probably even give you the color of the operator's hair. Terry Brookes www.polyteq.com >From: "Dan Wing" >To: "Dave Crocker" >CC: "MAEDA Toru" , >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt >Date: Sat, 30 Jun 2001 17:42:39 -0700 > > >Yes, shared code is good. > >"Fax terminal mode" is an end-to-end service which has much more in common >with PSTN fax and T.38 fax than the SMTP model of multiple hops, storing >mail, >mailing lists, etc. > >IPP has more in common with transmitting documents than SMTP, and I still >say >that IPP can provide something more closer approaching the goals of "fax >terminal mode" than SMTP. > >For universal messaging, T.37/RFC2305 is the way to go. For duplication of >exact fax functionality on an IP network, T.38 is the way to go. While >T.38 >is more difficult than an IETF text-based protocol, forcing SMTP to >essentially do 'SAML' (everyone by Dave, see RFC821 for a description of >SAML) >across multiple hops is hard. > >If you want something easier than T.38, IPP exists. IPP can be enhanced as >needed to support the features necessary to replicate fax. > >-d > > > -----Original Message----- > > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > > Sent: Saturday, June 30, 2001 7:55 AM > > To: Dan Wing > > Cc: MAEDA Toru; ietf-fax@imc.org > > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > At 01:39 PM 6/28/2001, Dan Wing wrote: > > >I'm unclear on why the ability to fallback requires the original > > attempt be in > > >SMTP. > > > > > > The more the modes have in common, the more code they share. That means > > that the different modes have less to implement. > > > > There also might be operational impact, such as retaining an SMTP > > connection. > > > > Retaining interworking with email continues to be a nice ability, too. > > > > It also makes it easier to evaluate the efficacy of each, different > > mode. The fewer modes the better/simpler. > > > > d/ > > > > ---------- > > Dave Crocker > > Brandenburg InternetWorking > > tel +1.408.246.8253; fax +1.408.273.6464 > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ietf-fax@mail.imc.org Thu Jul 5 07:15:50 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 HAA07335 for ; Thu, 5 Jul 2001 07:15:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65AY7w25979 for ietf-fax-bks; Thu, 5 Jul 2001 03:34:07 -0700 (PDT) Received: from hotmail.com (f76.law7.hotmail.com [216.33.237.76]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65AY6m25975 for ; Thu, 5 Jul 2001 03:34:06 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Jul 2001 03:34:02 -0700 Received: from 64.241.181.128 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 05 Jul 2001 10:34:01 GMT X-Originating-IP: [64.241.181.128] From: "Terry Brookes" To: imcdonald@sharplabs.com, dwing@cisco.com Cc: ietf-fax@imc.org, maeda@crf.canon.fr, dcrocker@brandenburg.com Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Thu, 05 Jul 2001 06:34:01 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jul 2001 10:34:02.0295 (UTC) FILETIME=[02030C70:01C1053E] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Ira, >Do you just dislike IPP? Nope, think it's great and would like to see a URI on every business card, but from a business standpoint it doesn't look like a very good way of meeting Mr Maeda's requirements. As far as I can tell he's looking for a way to use the popularity of e-mail as the basis for a simple low cost T30-like internet fax machine to replace the 100 million or so traditional fax machines in use. There are estimated to be half a billion fax users, this, presumably, is the target market. I believe its a reasonable assumption that a very large proportion of these users now have e-mail addresses; a rapidly growing number use Instant Messaging ( a number which will accelerate dramaticaly when Windows XP appears); but only a very small and exclusive group (the IPP developers ? printer manufacturers ?) appears to have any knowledge whatsoever of IPP. From a technical standpoint Dan's proposal of IPP may be OK, from a marketing standpoint it doesn't look like a very good idea because the user won't have anyone to send to, because, despite the valiant efforts of IPP people, hardly anyone actualy uses it. IM could (not would!) be a better bet on the basis that it could work very much like T30 AND have a large number of people already using it. Not IMPP, which the Blue Window Software Corporation (Redmond WA) is in the process of killing, but Windows IM which will probably be the de facto IM standard by the time Mr Maeda's machine is ready for production. My own belief is that FOIP will only be successfull if it's as easy to use as a regular fax machine. POP/SMTP has proved to be much too complex to set up, IPP doesn't have a user base even if it *is* imbedded in every printer, so maybe IM will be the answer...who knows? Terry >From: "McDonald, Ira" >To: "'Terry Brookes'" , dwing@cisco.com >CC: ietf-fax@imc.org, maeda@crf.canon.fr, dcrocker@brandenburg.com >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt >Date: Tue, 3 Jul 2001 10:27:47 -0700 > > >Hi Terry, > >Do you just dislike IPP? > >For IPP Fax to work, IPP does NOT need to be ubiquitous. It just >needs to be ubiquitous in deployed PRINTERS. Very few printers >shipped in calendar 2001 that did not have IPP protocol support. >Probably NONE will ship in calendar 2002 without IPP protocol >support. > >I agree that SMTP is ubiquitous, but it doesn't (and can't ever) >do realtime capabilities negotiation, by its very nature. > >Certainly such protocols as IMPP (your suggestion) are utterly >inappropriate for sending large documents by VALUE (like IPP) >and not by REFERENCE. > >Could you explain your implacable opposition to IPP Fax, please? > >Cheers, >- Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > >-----Original Message----- >From: Terry Brookes [mailto:brookes_terry@hotmail.com] >Sent: Tuesday, July 03, 2001 8:30 AM >To: dwing@cisco.com >Cc: ietf-fax@imc.org; maeda@crf.canon.fr; dcrocker@brandenburg.com >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > >Hi >I'd re-phrase the following- > >IPP exists. < > >This would be more accurate- > >IPP barely exists< > >Also 'IPP FAX' certainly does NOT exist...yet. > >IPP also requires infrastrucure in the form of IPP servers, so it may not >meet the stated requirements of 'using existing infrastructure'. > >If SMTP really doesn't work for fax terminal mode then strategicaly the new >Windows Instant Messenger could be a much better bet. It's likely to become >a de facto standard for the non-AOL IM's, and with IM you get an instant >response that should allow replication of T30 with great simplicity. You >also get SIP with Windows IM, which could allow discovery of the >capabilities of the receiving fax terminal, probably even give you the >color > >of the operator's hair. > >Terry Brookes >www.polyteq.com > > > > >From: "Dan Wing" > >To: "Dave Crocker" > >CC: "MAEDA Toru" , > >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > >Date: Sat, 30 Jun 2001 17:42:39 -0700 > > > > > >Yes, shared code is good. > > > >"Fax terminal mode" is an end-to-end service which has much more in >common > >with PSTN fax and T.38 fax than the SMTP model of multiple hops, storing > >mail, > >mailing lists, etc. > > > >IPP has more in common with transmitting documents than SMTP, and I still > >say > >that IPP can provide something more closer approaching the goals of "fax > >terminal mode" than SMTP. > > > >For universal messaging, T.37/RFC2305 is the way to go. For duplication >of > >exact fax functionality on an IP network, T.38 is the way to go. While > >T.38 > >is more difficult than an IETF text-based protocol, forcing SMTP to > >essentially do 'SAML' (everyone by Dave, see RFC821 for a description of > >SAML) > >across multiple hops is hard. > > > >If you want something easier than T.38, IPP exists. IPP can be enhanced >as > >needed to support the features necessary to replicate fax. > > > >-d > > > > > -----Original Message----- > > > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > > > Sent: Saturday, June 30, 2001 7:55 AM > > > To: Dan Wing > > > Cc: MAEDA Toru; ietf-fax@imc.org > > > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > At 01:39 PM 6/28/2001, Dan Wing wrote: > > > >I'm unclear on why the ability to fallback requires the original > > > attempt be in > > > >SMTP. > > > > > > > > > The more the modes have in common, the more code they share. That >means > > > that the different modes have less to implement. > > > > > > There also might be operational impact, such as retaining an SMTP > > > connection. > > > > > > Retaining interworking with email continues to be a nice ability, too. > > > > > > It also makes it easier to evaluate the efficacy of each, different > > > mode. The fewer modes the better/simpler. > > > > > > d/ > > > > > > ---------- > > > Dave Crocker > > > Brandenburg InternetWorking > > > tel +1.408.246.8253; fax +1.408.273.6464 > > > > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ietf-fax@mail.imc.org Fri Jul 6 13:19:28 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 NAA13237 for ; Fri, 6 Jul 2001 13:19:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66GI2o09880 for ietf-fax-bks; Fri, 6 Jul 2001 09:18:02 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66GI0m09875 for ; Fri, 6 Jul 2001 09:18:00 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id SAA08902 for ; Fri, 6 Jul 2001 18:14:15 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma008898; Fri, 6 Jul 01 18:14:03 +0200 Received: from crf.canon.fr ([194.2.81.15]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GG277O00.0W9; Fri, 6 Jul 2001 18:02:12 +0200 Message-ID: <3B45E458.2F8A0D54@crf.canon.fr> Date: Sat, 07 Jul 2001 01:16:24 +0900 From: "MAEDA Toru" X-Mailer: Mozilla 4.75 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Dan Wing CC: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Wing-san Thank you very much for the idea of error code. I prefere to use numeric ASCII format for the error code, since users can not understand a English text message for the error code in Japan. The device should transrate into local language message from the numeric ASCII for the error code. Regards. Toru Maeda Dan Wing wrote: > > Enumerate the T.30 error codes, I guess, as this is very T.30 specific. Text > needs to be added that transmission should be ceased when an error page is > encountered (again, very T.30 specific). There should be codes added for > 'unable to process TIFF file' or 'invalid TIFF file' -- for example, if the > email is marked clearly as 'image/tiff', but the attachment is really a PDF > file or a Microsoft Word document, or a JPG, etc., it isn't a valid TIFF and > this can't be assigned a T.30 error code. > > So, I would say some ABNF like this: > > code = attachment_code | t30_code > t30_code = "T30" ... all of the T30 codes .... > attachment_code = "Attachment" att_code > att_code = "unable to process attachment as TIFF" | > "invalid pointer in TIFF" > > Where "... all of the T30 codes ...." enumerates all of the error codes from > T.30 into a textual or numeric ASCII format -- not binary. > > Comments from anyone on this? > > -d > > > -----Original Message----- > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > Sent: Monday, July 02, 2001 10:29 AM > > To: Dan Wing > > Cc: ietf-fax@imc.org > > Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > Hi, Wing-san > > > > We need further discussion about the valid "codes". > > Do you have any idea about it? > > > > Regards. > > > > Toru Maeda > > > > > > Dan Wing wrote: > > > > > > Hi. > > > > > > This I-D shows the following: > > > > > > 2. MDN extension > > > To send fax prosessing status from the receiver, MDN extension field > > > is used for results, received page number and error page number. > > > > > > MDN extension field: > > > Fax-Report: Fax-Results = code > > > ; Fax-Pages = received page number > > > ; Fax-Errorpage = error page number > > > > > > What are the valid "codes"? > > > > > > -d > > > > > > > -----Original Message----- > > > > From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On > > > > Behalf Of Internet-Drafts@ietf.org > > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > > To: IETF-Announce: > > > > Cc: ietf-fax@imc.org > > > > Subject: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > > > > > > > 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 : Fax Processing Status > > > > Author(s) : T. Maeda > > > > Filename : draft-ietf-fax-faxprocessing-status-00.txt > > > > Pages : 4 > > > > Date : 26-Jun-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-ietf-fax-faxprocessing-sta > > > > tus-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-ietf-fax-faxprocessing-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-ietf-fax-faxprocessing-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 > > Canon Research Centre France S.A. > > *********************************** -- ********************************* MAEDA Toru CANON Research Centre France S.A. ********************************* From owner-ietf-fax@mail.imc.org Sat Jul 7 00:44: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 AAA29740 for ; Sat, 7 Jul 2001 00:44:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f673daP28497 for ietf-fax-bks; Fri, 6 Jul 2001 20:39:36 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f673dYm28493 for ; Fri, 6 Jul 2001 20:39:34 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id MAA14625 for ; Sat, 7 Jul 2001 12:39:37 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by azteca.isd.ricoh.co.jp (Mirapoint) with SMTP id AAT04051; Sat, 7 Jul 2001 12:39:37 +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 MAA16754 for ; Sat, 7 Jul 2001 12:39:33 +0900 To: ietf-fax@imc.org Subject: Our meeting slot(not fixed) in London X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) References: <200107052144.RAA28197@ietf.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010707124201T.tamura@toda.ricoh.co.jp> Date: Sat, 07 Jul 2001 12:42:01 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, > FYI, this is the draft agenda of the 51st IETF meeting in London. > There could be any changes until the time when the scheduling officially > is closed July 16 at 500 PM ET. We are planning to post the draft agenda > on the IETF web page tomorrow, Friday, July 06. > Draft Agenda of the Fifty-first IETF > August 5-10, 2001 > MONDAY, August 6, 2001 > 1930-2200 Evening Sessions > APP fax Internet Fax WG This is ***preliminary***. As the above says, it could change. Please take care until the final one is fixed. Regarding our agenda, if there is a new one you would like to request, please say in our ML soon. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Sat Jul 7 01:15: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 BAA00638 for ; Sat, 7 Jul 2001 01:15:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f674KVi28911 for ietf-fax-bks; Fri, 6 Jul 2001 21:20:31 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f674KUm28907 for ; Fri, 6 Jul 2001 21:20:30 -0700 (PDT) Received: from bbthead.brandenburg.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id VAA18654; Fri, 6 Jul 2001 21:19:31 -0700 Message-Id: <5.1.0.14.2.20010706211949.03267310@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 21:20:54 -0400 To: Hiroshi Tamura From: Dave Crocker Subject: Re: Our meeting slot(not fixed) in London Cc: ietf-fax@imc.org In-Reply-To: <20010707124201T.tamura@toda.ricoh.co.jp> References: <200107052144.RAA28197@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: At 11:42 PM 7/6/2001, Hiroshi Tamura wrote: >Regarding our agenda, if there is a new one you would like to request, >please say in our ML soon. If I have failed to notice this appearing recently, please forgive me. Could we, perhaps, have a review of the details that remain for completing FFPIM? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-fax@mail.imc.org Sun Jul 8 19:38: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 TAA16743 for ; Sun, 8 Jul 2001 19:38:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f68Mqe808675 for ietf-fax-bks; Sun, 8 Jul 2001 15:52:40 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f68Mqcm08671 for ; Sun, 8 Jul 2001 15:52:39 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id HAA27094; Mon, 9 Jul 2001 07:51:18 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by delsol.isd.ricoh.co.jp (Mirapoint) with SMTP id AAW60524; Mon, 9 Jul 2001 07:51:17 +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 HAA00413; Mon, 9 Jul 2001 07:51:14 +0900 To: dcrocker@brandenburg.com Cc: ietf-fax@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Our meeting slot(not fixed) in London In-Reply-To: <5.1.0.14.2.20010706211949.03267310@brandenburg.com> References: <200107052144.RAA28197@ietf.org> <20010707124201T.tamura@toda.ricoh.co.jp> <5.1.0.14.2.20010706211949.03267310@brandenburg.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: <20010709075348O.tamura@toda.ricoh.co.jp> Date: Mon, 09 Jul 2001 07:53:48 +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 Dave, > me. Could we, perhaps, have a review of the details that remain for > completing FFPIM? For the time being, I do not think so. But, ***personally***, I wonder if it is not ready for LC because of the comment you added in -01, especially, the one for ESMTP CONNEG. Fortunately, thanks to you and Toyoda-san, there is a ESMTP CONNEG I-D. If it is your intension, I think it is better to do LC for these two I-Ds at the same time. Any comments are welcome. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Jul 9 03:23:33 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 DAA07078 for ; Mon, 9 Jul 2001 03:23:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f696dNI23769 for ietf-fax-bks; Sun, 8 Jul 2001 23:39:23 -0700 (PDT) Received: from kings.mei.co.jp (kings.mei.co.jp [202.224.189.27]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f696dLm23761 for ; Sun, 8 Jul 2001 23:39:21 -0700 (PDT) Received: by kings.mei.co.jp (8.11.3/3.7W) with ESMTP id f696cQ504524; Mon, 9 Jul 2001 15:38:26 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id PAA01469; Mon, 9 Jul 2001 15:38:23 +0900 (JST) Received: from [133.185.137.6] by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 9 Jul 2001 06:38:25 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id PAA21318; Mon, 9 Jul 2001 15:38:23 +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 PAA05074; Mon, 9 Jul 2001 15:38:23 +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 PAA14150; Mon, 9 Jul 2001 15:38:22 +0900 (JST) Message-Id: <200107090644.AA01824@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Mon, 09 Jul 2001 15:44:38 +0900 To: Hiroshi Tamura Cc: dcrocker@brandenburg.com, ietf-fax@imc.org Subject: Re: Our meeting slot(not fixed) in London In-Reply-To: <20010709075348O.tamura@toda.ricoh.co.jp> References: <20010709075348O.tamura@toda.ricoh.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: Tamura-san, Hiroshi Tamura wrote > >But, ***personally***, I wonder if it is not ready for LC because of >the comment you added in -01, especially, the one for ESMTP CONNEG. > >Fortunately, thanks to you and Toyoda-san, there is a ESMTP CONNEG I-D. >If it is your intension, I think it is better to do LC for these >two I-Ds at the same time. > Since I have not seen comments about ESMTP CONNEG I-D, I would like you to do LC for it with FFPIM I-D. Thank you. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Mon Jul 9 05:48:44 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 FAA08303 for ; Mon, 9 Jul 2001 05:48:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6994PD09684 for ietf-fax-bks; Mon, 9 Jul 2001 02:04:25 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6994Nm09680 for ; Mon, 9 Jul 2001 02:04:23 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id SAA23273; Mon, 9 Jul 2001 18:04:21 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by delsol.isd.ricoh.co.jp (Mirapoint) with SMTP id AAW78729; Mon, 9 Jul 2001 18:04:19 +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 SAA06618; Mon, 9 Jul 2001 18:04:13 +0900 To: ktoyoda@rdmg.mgcs.mei.co.jp Cc: dcrocker@brandenburg.com, ietf-fax@imc.org Subject: Re: Our meeting slot(not fixed) in London In-Reply-To: <200107090644.AA01824@d23n59.rdmg.mgcs.mei.co.jp> References: <20010709075348O.tamura@toda.ricoh.co.jp> <200107090644.AA01824@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: <20010709180653G.tamura@toda.ricoh.co.jp> Date: Mon, 09 Jul 2001 18:06:53 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Since I have not seen comments about ESMTP CONNEG I-D, I would like > you to do LC for it with FFPIM I-D. This is a new I-D. We have to take it carefully. The LC time depends on the discussion from now on! But, Claudio and I will ask your target date at London. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Jul 9 05:51: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 FAA08336 for ; Mon, 9 Jul 2001 05:51:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6999tE09750 for ietf-fax-bks; Mon, 9 Jul 2001 02:09:55 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6999rm09746 for ; Mon, 9 Jul 2001 02:09:53 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id LAA15571 for ; Mon, 9 Jul 2001 11:06:07 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma015562; Mon, 9 Jul 01 11:05:38 +0200 Received: from crf.canon.fr ([194.2.81.15]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GG77DI00.AYG; Mon, 9 Jul 2001 10:53:43 +0200 Message-ID: <3B497478.A5EB69BA@crf.canon.fr> Date: Mon, 09 Jul 2001 18:08:08 +0900 From: "MAEDA Toru" X-Mailer: Mozilla 4.75 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Dan Wing CC: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Wing-san Sorry for slow responce. Can IPP and IPP-fax protocol go through under the current firewall configurations? Regards. Toru Maeda Dan Wing wrote: > > My mailer I use for POP (and IMAP) here at Cisco is mira-sjcm-3.cisco.com, IP > address 171.69.24.15. > > Our firewall doesn't allow you to connect to the SMTP port of 171.69.24.15 > from outside of Cisco: > > # telnet 171.69.24.15 25 > Trying 171.69.24.15... > telnet: connect to address 171.69.24.15: Operation timed out > telnet: Unable to connect to remote host > # > > I bet you nearly all companies have similar firewall configurations, as the > current practice for any security-aware company is to have all incoming mail, > ftp, and http traffic go to a device that is on the insecure side of the > corporate firewall. This connection is completely terminated on this device > and this device is then the only device permitted to connect to interior > devices. > > You work for Canon, and I expect its configuration is similar -- direct > connections from the Internet to port 25 of arbitrary devices inside of your > company are not permitted. > > -d > > > -----Original Message----- > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > Sent: Monday, July 02, 2001 10:31 AM > > To: Dan Wing > > Cc: ietf-fax@imc.org > > Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > Hi, Wing-san > > > > Could you explain about the current situation that the existing > > infrastructure doesn't permit connecting directly from Internet hosts to > > internal SMTP servers > > > > Regards. > > > > Toru Maeda > > > > > > Dan Wing wrote: > > > > > > I'm unclear on why the ability to fallback requires the original > > attempt be in > > > SMTP. > > > > > > The goals document also says that "Use of Existing > > Infrastructure" is a goal. > > > You do know that the existing infrastructure doesn't permit connecting > > > directly from Internet hosts to internal SMTP servers? > > > > > > -d > > > > > > > -----Original Message----- > > > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > > > Sent: Thursday, June 28, 2001 10:12 AM > > > > To: Dan Wing > > > > Cc: ietf-fax@imc.org > > > > Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > > > > Hi, Wing-san > > > > > > > > Thank you for your comments. > > > > > > > > Since Terminal Mode should fall back to Full Mode or Simple Mode, > > > > ESMTP is more preferable than IPP. > > > > > > > > Regards. > > > > > > > > Toru Maeda > > > > > > > > > > > > Dan Wing wrote: > > > > > > > > > > IPP is more suitable for these goals than SMTP. > > > > > > > > > > -d > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ietf-fax@mail.imc.org > > [mailto:owner-ietf-fax@mail.imc.org]On > > > > > > Behalf Of Internet-Drafts@ietf.org > > > > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > > > > To: IETF-Announce: > > > > > > Cc: ietf-fax@imc.org > > > > > > Subject: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > > > > > > > > > > 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 : Goals for Terminal Mode > > > > > > Author(s) : T. Maeda > > > > > > Filename : draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > Pages : 5 > > > > > > Date : 26-Jun-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. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-fax-terminal-mode-goa > > > > > > ls-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-ietf-fax-terminal-mode-goals-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-ietf-fax-terminal-mode-goals-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 > > > > Canon Research Centre France S.A. > > > > *********************************** > > > > -- > > *********************************** > > MAEDA TORU > > Canon Research Centre France S.A. > > *********************************** -- ********************************* MAEDA Toru CANON Research Centre France S.A. ********************************* From owner-ietf-fax@mail.imc.org Mon Jul 9 07:34: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 HAA09644 for ; Mon, 9 Jul 2001 07:34:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69Anrh12044 for ietf-fax-bks; Mon, 9 Jul 2001 03:49:53 -0700 (PDT) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Anmm12039 for ; Mon, 9 Jul 2001 03:49:48 -0700 (PDT) Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id f69Anwl06090 for ; Mon, 9 Jul 2001 03:49:58 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f69Anhl05303 for ; Mon, 9 Jul 2001 03:49:43 -0700 (PDT) Received: from [130.248.17.166] ([130.248.17.166]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GG7CQO00.A3S; Mon, 9 Jul 2001 03:49:36 -0700 Mime-Version: 1.0 X-Sender: sfoshee@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: <20010707124201T.tamura@toda.ricoh.co.jp> References: <200107052144.RAA28197@ietf.org> <20010707124201T.tamura@toda.ricoh.co.jp> Date: Mon, 9 Jul 2001 03:49:54 -0700 To: Hiroshi Tamura , ietf-fax@imc.org From: "Scott Foshee" Subject: London meeting Agenda Cc: klensin@research.att.com 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, et al., I looked, but did not see the agenda for the London meeting, so apologies if this is already on it..... I recommend that the committee receive a report on IAB activity regarding Adobe's IP concerns regarding TIFF FX. Thank you. Scott At 12:42 PM +0900 7/7/01, Hiroshi Tamura wrote: >Folks, > >> FYI, this is the draft agenda of the 51st IETF meeting in London. >> There could be any changes until the time when the scheduling officially >> is closed July 16 at 500 PM ET. We are planning to post the draft agenda >> on the IETF web page tomorrow, Friday, July 06. > >> Draft Agenda of the Fifty-first IETF >> August 5-10, 2001 > >> MONDAY, August 6, 2001 > >> 1930-2200 Evening Sessions >> APP fax Internet Fax WG > >This is ***preliminary***. As the above says, it could change. >Please take care until the final one is fixed. > >Regarding our agenda, if there is a new one you would like to request, >please say in our ML soon. > >Regards, >-- >Hiroshi Tamura, Co-chair of IETF-FAX WG >E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Jul 9 13:37:15 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 NAA23301 for ; Mon, 9 Jul 2001 13:37:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69GqgL23176 for ietf-fax-bks; Mon, 9 Jul 2001 09:52:42 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Gqdm23172 for ; Mon, 9 Jul 2001 09:52:40 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f69Gqdh05004; Mon, 9 Jul 2001 09:52:39 -0700 (PDT) Received: from DWINGW2K (dwings-dsl3.cisco.com [10.19.89.164]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AIY02338; Mon, 9 Jul 2001 09:52:34 -0700 (PDT) From: "Dan Wing" To: "MAEDA Toru" Cc: Subject: RE: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt Date: Mon, 9 Jul 2001 09:52:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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) In-Reply-To: <3B45E458.2F8A0D54@crf.canon.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree -- numeric is better. But all of the acceptable values need to be enumerated. -d > -----Original Message----- > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > Sent: Friday, July 06, 2001 9:16 AM > To: Dan Wing > Cc: ietf-fax@imc.org > Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > Hi, Wing-san > > Thank you very much for the idea of error code. > > I prefere to use numeric ASCII format for the error code, > since users can not understand a English text message for the error code > in Japan. > The device should transrate into local language message from the numeric > ASCII for the error code. > > Regards. > > Toru Maeda > > > Dan Wing wrote: > > > > Enumerate the T.30 error codes, I guess, as this is very T.30 > specific. Text > > needs to be added that transmission should be ceased when an error page is > > encountered (again, very T.30 specific). There should be codes added for > > 'unable to process TIFF file' or 'invalid TIFF file' -- for > example, if the > > email is marked clearly as 'image/tiff', but the attachment is > really a PDF > > file or a Microsoft Word document, or a JPG, etc., it isn't a > valid TIFF and > > this can't be assigned a T.30 error code. > > > > So, I would say some ABNF like this: > > > > code = attachment_code | t30_code > > t30_code = "T30" ... all of the T30 codes .... > > attachment_code = "Attachment" att_code > > att_code = "unable to process attachment as TIFF" | > > "invalid pointer in TIFF" > > > > Where "... all of the T30 codes ...." enumerates all of the error > codes from > > T.30 into a textual or numeric ASCII format -- not binary. > > > > Comments from anyone on this? > > > > -d > > > > > -----Original Message----- > > > From: MAEDA Toru [mailto:maeda@crf.canon.fr] > > > Sent: Monday, July 02, 2001 10:29 AM > > > To: Dan Wing > > > Cc: ietf-fax@imc.org > > > Subject: Re: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > > > > Hi, Wing-san > > > > > > We need further discussion about the valid "codes". > > > Do you have any idea about it? > > > > > > Regards. > > > > > > Toru Maeda > > > > > > > > > Dan Wing wrote: > > > > > > > > Hi. > > > > > > > > This I-D shows the following: > > > > > > > > 2. MDN extension > > > > To send fax prosessing status from the receiver, MDN extension field > > > > is used for results, received page number and error page number. > > > > > > > > MDN extension field: > > > > Fax-Report: Fax-Results = code > > > > ; Fax-Pages = received page number > > > > ; Fax-Errorpage = error page number > > > > > > > > What are the valid "codes"? > > > > > > > > -d > > > > > > > > > -----Original Message----- > > > > > From: owner-ietf-fax@mail.imc.org > [mailto:owner-ietf-fax@mail.imc.org]On > > > > > Behalf Of Internet-Drafts@ietf.org > > > > > Sent: Wednesday, June 27, 2001 4:03 AM > > > > > To: IETF-Announce: > > > > > Cc: ietf-fax@imc.org > > > > > Subject: I-D ACTION:draft-ietf-fax-faxprocessing-status-00.txt > > > > > > > > > > > > > > > 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 : Fax Processing Status > > > > > Author(s) : T. Maeda > > > > > Filename : draft-ietf-fax-faxprocessing-status-00.txt > > > > > Pages : 4 > > > > > Date : 26-Jun-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-ietf-fax-faxprocessing-sta > > > > > tus-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-ietf-fax-faxprocessing-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-ietf-fax-faxprocessing-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 > > > Canon Research Centre France S.A. > > > *********************************** > > -- > ********************************* > MAEDA Toru > CANON Research Centre France S.A. > ********************************* From owner-ietf-fax@mail.imc.org Mon Jul 9 14:09:15 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 OAA24355 for ; Mon, 9 Jul 2001 14:09:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69HNwY23887 for ietf-fax-bks; Mon, 9 Jul 2001 10:23:58 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69HNum23883 for ; Mon, 9 Jul 2001 10:23:56 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f69HO1x24511; Mon, 9 Jul 2001 10:24:01 -0700 (PDT) Received: from DWINGW2K (dwings-dsl3.cisco.com [10.19.89.164]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AIZ00845; Mon, 9 Jul 2001 10:23:46 -0700 (PDT) From: "Dan Wing" To: "Claudio Allocchio" Cc: "MAEDA Toru" , Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Mon, 9 Jul 2001 10:23:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > I bet you nearly all companies have similar firewall > > configurations, as the > > current practice for any security-aware company is to have all > > incoming mail, > > ftp, and http traffic go to a device that is on the insecure side of the > > corporate firewall. This connection is completely terminated on > > this device > > and this device is then the only device permitted to connect to interior > > devices. > > This is also completely true in general, as this is the correct secure > configuration of servers on any LAN/Intranet. For example at GARR (and at > nearly all the other R&D and academic netqorks, too) there is ONLY a few > devices (well configured and controlled) which are SMTP accessible from > outside. A tipical configuration on the router (cisco in this case) is: > > access-list 101 permit tcp any host 140.105.4.200 eq smtp > access-list 101 deny tcp any any > access-list 101 permit ip any any > > This will introduce a "relay" host (140.105.4.200 in the above example) > between any sender and any internal SMTP server in ANY case, and thus > there will be no direct negotiation nor delivery. > > Thus SMTP is defintly a "relay" protocol. Yep. And I don't see this changing to support 'terminal mode' fax on the Internet. So for 'terminal mode', I really think we need something other than SMTP as the underlying protocol. -d From owner-ietf-fax@mail.imc.org Mon Jul 9 16:20: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 QAA27801 for ; Mon, 9 Jul 2001 16:20:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69JX5c26681 for ietf-fax-bks; Mon, 9 Jul 2001 12:33:05 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69JX4m26676 for ; Mon, 9 Jul 2001 12:33:04 -0700 (PDT) Received: from crthub1.crt.xerox.com (crthub1.crt.xerox.com [13.138.80.3]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA25498 for ; Mon, 9 Jul 2001 15:33:06 -0400 (EDT) Received: by crthub1.crt.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jul 2001 15:33:06 -0400 Message-ID: From: "Zehler, Peter" To: "'ietf-fax@imc.org'" Subject: RESEND: IFX> FW: [Another take on IPP Fax from Terry Brookes] Date: Mon, 9 Jul 2001 15:33:03 -0400 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: Terry, A couple of comments on your comments: >IPP also requires infrastructure in the form of IPP servers, so it may not >meet the stated requirements of 'using existing infrastructure'. IPP does not require "IPP servers" IPP only has "Printers" "Clients" and "Jobs". The only thing that matches an "IPP server" would be an IPP Printer. I would not consider an IPP Printer a part of the infrastructure. IPP uses components such as HTTP, Security, firewalls and registered MIME types for content description. These I would consider infrastructure. All of these existing technologies are used without any IPP specific modifications. Any FAX exchange requires similar components at both ends regardless of the transport scheme. >Nope, think it's great and would like to see a URI on every business card, >but from a business standpoint it doesn't look like a very good way of >meeting Mr Maeda's requirements. As far as I can tell he's looking for a way >to use the popularity of e-mail as the basis for a simple low cost T30-like >internet fax machine to replace the 100 million or so traditional fax >machines in use. There are estimated to be half a billion fax users, this, >presumably, is the target market. I believe its a reasonable assumption that >a very large proportion of these users now have e-mail addresses; a rapidly >growing number use Instant Messaging ( a number which will accelerate >dramaticaly when Windows XP appears); but only a very small and exclusive >group (the IPP developers ? printer manufacturers ?) appears to have any >knowledge whatsoever of IPP. From a technical standpoint Dan's proposal of >IPP may be OK, from a marketing standpoint it doesn't look like a very good >idea because the user won't have anyone to send to, because, despite the >valiant efforts of IPP people, hardly anyone actualy uses it. IM could (not >would!) be a better bet on the basis that it could work very much like T30 >AND have a large number of people already using it. Not IMPP, which the Blue >Window Software Corporation (Redmond WA) is in the process of killing, but >Windows IM which will probably be the de facto IM standard by the time Mr >Maeda's machine is ready for production. >My own belief is that FOIP will only be successfull if it's as easy to use >as a regular fax machine. POP/SMTP has proved to be much too complex to set >up, IPP doesn't have a user base even if it *is* imbedded in every printer, >so maybe IM will be the answer...who knows? I contend that only a small number of FAX users know anything about ITU specifications and many don't know the meaning of TIFF. I doubt your average email user is very familiar with SMTP or POP-3. Anyone sending a traditional FAX or email does know the phone number or email address of the recipient. I believe there is a business case for ifax and IPP FAX. Ask marketing/end users if they would be interested in 1) Sending a FAX around the world through their Internet service provider avoiding long distance phone charges. 2) Sending a FAX without encountering a "busy signal". 3) Sending a FAX securely with mutual authentication and encryption. 4) Having the capability of negotiating to a higher fidelity of output. 5) Faxing directly from an application with the best resolution available at the printer. 6) Receiving confirmation similar to or beyond traditional FAX (i.e. reception and printed). 7) Having a single device that is connected to both the Internet and the phone line capable of sending and receiving FAXs via traditional FAX, ifax or IPP FAX based on availability. With ifax and IPP FAX we are met with the classic chicken and egg problem. At least one side has to be built first. Hopefully the other side will soon follow. IPP has a track record of interoperability across vendor implementations for clients and printers. I expect the FAX profile for IPP to meet similar success. By the way, user of Windows XP have IPP Client capability out of the box just as Windows 2000 users do. Why would IPP have much of a user base even though it is available in printers and in Windows given that most printing is done locally and traditional methods are the easiest to set up in Windows. ("where do we want you to go today?") Windows also have the capability of acting as IPP Printers. Pete Peter Zehler XEROX Xerox Architecture Center Email: PZehler@crt.xerox.com Voice: (716) 265-8755 FAX: (716) 265-8792 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-69E Webster NY, 14580-9701 -----Original Message----- From: Terry Brookes [mailto:brookes_terry@hotmail.com] Sent: Thursday, July 05, 2001 6:34 AM To: imcdonald@sharplabs.com; dwing@cisco.com Cc: ietf-fax@imc.org; maeda@crf.canon.fr; dcrocker@brandenburg.com Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Hi Ira, >Do you just dislike IPP? Nope, think it's great and would like to see a URI on every business card, but from a business standpoint it doesn't look like a very good way of meeting Mr Maeda's requirements. As far as I can tell he's looking for a way to use the popularity of e-mail as the basis for a simple low cost T30-like internet fax machine to replace the 100 million or so traditional fax machines in use. There are estimated to be half a billion fax users, this, presumably, is the target market. I believe its a reasonable assumption that a very large proportion of these users now have e-mail addresses; a rapidly growing number use Instant Messaging ( a number which will accelerate dramaticaly when Windows XP appears); but only a very small and exclusive group (the IPP developers ? printer manufacturers ?) appears to have any knowledge whatsoever of IPP. From a technical standpoint Dan's proposal of IPP may be OK, from a marketing standpoint it doesn't look like a very good idea because the user won't have anyone to send to, because, despite the valiant efforts of IPP people, hardly anyone actualy uses it. IM could (not would!) be a better bet on the basis that it could work very much like T30 AND have a large number of people already using it. Not IMPP, which the Blue Window Software Corporation (Redmond WA) is in the process of killing, but Windows IM which will probably be the de facto IM standard by the time Mr Maeda's machine is ready for production. My own belief is that FOIP will only be successfull if it's as easy to use as a regular fax machine. POP/SMTP has proved to be much too complex to set up, IPP doesn't have a user base even if it *is* imbedded in every printer, so maybe IM will be the answer...who knows? Terry >From: "McDonald, Ira" >To: "'Terry Brookes'" , dwing@cisco.com >CC: ietf-fax@imc.org, maeda@crf.canon.fr, dcrocker@brandenburg.com >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt >Date: Tue, 3 Jul 2001 10:27:47 -0700 > > >Hi Terry, > >Do you just dislike IPP? > >For IPP Fax to work, IPP does NOT need to be ubiquitous. It just >needs to be ubiquitous in deployed PRINTERS. Very few printers >shipped in calendar 2001 that did not have IPP protocol support. >Probably NONE will ship in calendar 2002 without IPP protocol >support. > >I agree that SMTP is ubiquitous, but it doesn't (and can't ever) >do realtime capabilities negotiation, by its very nature. > >Certainly such protocols as IMPP (your suggestion) are utterly >inappropriate for sending large documents by VALUE (like IPP) >and not by REFERENCE. > >Could you explain your implacable opposition to IPP Fax, please? > >Cheers, >- Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > > >-----Original Message----- >From: Terry Brookes [mailto:brookes_terry@hotmail.com] >Sent: Tuesday, July 03, 2001 8:30 AM >To: dwing@cisco.com >Cc: ietf-fax@imc.org; maeda@crf.canon.fr; dcrocker@brandenburg.com >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > >Hi >I'd re-phrase the following- > >IPP exists. < > >This would be more accurate- > >IPP barely exists< > >Also 'IPP FAX' certainly does NOT exist...yet. > >IPP also requires infrastrucure in the form of IPP servers, so it may not >meet the stated requirements of 'using existing infrastructure'. > >If SMTP really doesn't work for fax terminal mode then strategicaly the new >Windows Instant Messenger could be a much better bet. It's likely to become >a de facto standard for the non-AOL IM's, and with IM you get an instant >response that should allow replication of T30 with great simplicity. You >also get SIP with Windows IM, which could allow discovery of the >capabilities of the receiving fax terminal, probably even give you the >color > >of the operator's hair. > >Terry Brookes >www.polyteq.com > > > > >From: "Dan Wing" > >To: "Dave Crocker" > >CC: "MAEDA Toru" , > >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > >Date: Sat, 30 Jun 2001 17:42:39 -0700 > > > > > >Yes, shared code is good. > > > >"Fax terminal mode" is an end-to-end service which has much more in >common > >with PSTN fax and T.38 fax than the SMTP model of multiple hops, storing > >mail, > >mailing lists, etc. > > > >IPP has more in common with transmitting documents than SMTP, and I still > >say > >that IPP can provide something more closer approaching the goals of "fax > >terminal mode" than SMTP. > > > >For universal messaging, T.37/RFC2305 is the way to go. For duplication >of > >exact fax functionality on an IP network, T.38 is the way to go. While > >T.38 > >is more difficult than an IETF text-based protocol, forcing SMTP to > >essentially do 'SAML' (everyone by Dave, see RFC821 for a description of > >SAML) > >across multiple hops is hard. > > > >If you want something easier than T.38, IPP exists. IPP can be enhanced >as > >needed to support the features necessary to replicate fax. > > > >-d > > > > > -----Original Message----- > > > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > > > Sent: Saturday, June 30, 2001 7:55 AM > > > To: Dan Wing > > > Cc: MAEDA Toru; ietf-fax@imc.org > > > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > At 01:39 PM 6/28/2001, Dan Wing wrote: > > > >I'm unclear on why the ability to fallback requires the original > > > attempt be in > > > >SMTP. > > > > > > > > > The more the modes have in common, the more code they share. That >means > > > that the different modes have less to implement. > > > > > > There also might be operational impact, such as retaining an SMTP > > > connection. > > > > > > Retaining interworking with email continues to be a nice ability, too. > > > > > > It also makes it easier to evaluate the efficacy of each, different > > > mode. The fewer modes the better/simpler. > > > > > > d/ > > > > > > ---------- > > > Dave Crocker > > > Brandenburg InternetWorking > > > tel +1.408.246.8253; fax +1.408.273.6464 > > > > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ietf-fax@mail.imc.org Tue Jul 10 11:25: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 LAA03596 for ; Tue, 10 Jul 2001 11:25:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AEWtH13234 for ietf-fax-bks; Tue, 10 Jul 2001 07:32:55 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AEWqm13226 for ; Tue, 10 Jul 2001 07:32:52 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id QAA26676 for ; Tue, 10 Jul 2001 16:29:09 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma026670; Tue, 10 Jul 01 16:28:55 +0200 Received: from crf.canon.fr ([194.2.81.15]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GG9H0B00.JYV; Tue, 10 Jul 2001 16:16:59 +0200 Message-ID: <3B4B11B3.FBFA9900@crf.canon.fr> Date: Tue, 10 Jul 2001 23:31:16 +0900 From: "MAEDA Toru" X-Mailer: Mozilla 4.75 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Claudio Allocchio CC: Dan Wing , ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Allocchio-san Thank you very much for comments. > Thus SMTP is defintly a "relay" protocol. > I think that the router is confifurated SMTP server as a "relay" device. Regards. Toru Maeda Claudio Allocchio wrote: > > > My mailer I use for POP (and IMAP) here at Cisco is mira-sjcm-3.cisco.com, IP > > address 171.69.24.15. > > > > Our firewall doesn't allow you to connect to the SMTP port of 171.69.24.15 > > from outside of Cisco: > > > > # telnet 171.69.24.15 25 > > Trying 171.69.24.15... > > telnet: connect to address 171.69.24.15: Operation timed out > > telnet: Unable to connect to remote host > > # > > > > I bet you nearly all companies have similar firewall configurations, as the > > current practice for any security-aware company is to have all incoming mail, > > ftp, and http traffic go to a device that is on the insecure side of the > > corporate firewall. This connection is completely terminated on this device > > and this device is then the only device permitted to connect to interior > > devices. > > This is also completely true in general, as this is the correct secure > configuration of servers on any LAN/Intranet. For example at GARR (and at > nearly all the other R&D and academic netqorks, too) there is ONLY a few > devices (well configured and controlled) which are SMTP accessible from > outside. A tipical configuration on the router (cisco in this case) is: > > access-list 101 permit tcp any host 140.105.4.200 eq smtp > access-list 101 deny tcp any any > access-list 101 permit ip any any > > This will introduce a "relay" host (140.105.4.200 in the above example) > between any sender and any internal SMTP server in ANY case, and thus > there will be no direct negotiation nor delivery. > > Thus SMTP is defintly a "relay" protocol. > > Regards, > Claudio -- ********************************* MAEDA Toru CANON Research Centre France S.A. ********************************* From owner-ietf-fax@mail.imc.org Tue Jul 10 11:59: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 LAA05476 for ; Tue, 10 Jul 2001 11:59:15 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6AFABK16895 for ietf-fax-bks; Tue, 10 Jul 2001 08:10:11 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AFA8m16888 for ; Tue, 10 Jul 2001 08:10:08 -0700 (PDT) Date: Tue, 10 Jul 2001 17:09:10 +0100 To: MAEDA Toru cc: Claudio Allocchio , Dan Wing , ietf-fax@imc.org In-Reply-To: <3B4B11B3.FBFA9900@crf.canon.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Thus SMTP is defintly a "relay" protocol. > > > I think that the router is confifurated SMTP server as a "relay" device. ... the "router" ? the router does not support any application protocol like SMTP. it is level 3 downwards... If it is a "firewall", then it can act as an intermiediate SMTP relay. Regards Claudio From owner-ietf-fax@mail.imc.org Wed Jul 11 20:23:17 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 UAA25820 for ; Wed, 11 Jul 2001 20:23:16 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6BNPSr11018 for ietf-fax-bks; Wed, 11 Jul 2001 16:25:28 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BNPQm11014 for ; Wed, 11 Jul 2001 16:25:26 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id IAA00830 for ; Thu, 12 Jul 2001 08:25:18 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by delsol.isd.ricoh.co.jp (Mirapoint) with SMTP id AAX32059; Thu, 12 Jul 2001 08:25:17 +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 IAA06603 for ; Thu, 12 Jul 2001 08:25:14 +0900 To: ietf-fax@imc.org Subject: Result of WG Last Call for draft-ietf-fax-content-negotiation-05.txt In-Reply-To: <20010623135325C.tamura@toda.ricoh.co.jp> References: <20010623135325C.tamura@toda.ricoh.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010712082750F.tamura@toda.ricoh.co.jp> Date: Thu, 12 Jul 2001 08:27:50 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, This is the result of Working Group Last Call for draft-ietf-fax-content-negotiation-05.txt. It was submitted for IETF-FAX WG Last CALL on June 23. During WG period (2 weeks), there were no comments. All the points made by Minneapolis meeting were covered in the -05 I-D. Therefore, we can go to the next steps, i.e. IETF Last Call. Within a few days, I request IESG for the Proposed Standard consideration. I thank the editors and all the people who contributed them. > ----------------------------------------------------------------- > Content Negotiation for Internet Messaging Services > > > > > Abstract > > This memo describes a content negotiation mechanism for facsimile, > voice and other messaging services that use Internet email. > > Services such as facsimile and voice messaging need to cope with > new message content formats, yet need to ensure that the content of > any given message is renderable by the receiving agent. The > mechanism described here aims to meet these needs in a fashion that > is fully compatible with the current behaviour and expectations of > Internet email. > ----------------------------------------------------------------- Regards, -- Hiroshi Tamura IETF FAX WG co-chair From owner-ietf-fax@mail.imc.org Sat Jul 14 07:09: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 HAA01258 for ; Sat, 14 Jul 2001 07:09:43 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6EAHnI22283 for ietf-fax-bks; Sat, 14 Jul 2001 03:17:49 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6EAHcq22276 for ; Sat, 14 Jul 2001 03:17:39 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id TAA16773 for ; Sat, 14 Jul 2001 19:17:37 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by azteca.isd.ricoh.co.jp (Mirapoint) with SMTP id AAU32298; Sat, 14 Jul 2001 19:17:33 +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 TAA00674 for ; Sat, 14 Jul 2001 19:17:26 +0900 To: ietf-fax@imc.org Subject: I-D Cutoff date for London meeting 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: <20010714192016C.tamura@toda.ricoh.co.jp> Date: Sat, 14 Jul 2001 19:20:16 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Please take care of I-D cutoff date. July 20 - Internet Draft final submission cutoff date at 1700 ET BTW, Within a few days, our draft agenda will be circulated. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Sat Jul 14 12:53: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 MAA08814 for ; Sat, 14 Jul 2001 12:53:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6EG3HD06766 for ietf-fax-bks; Sat, 14 Jul 2001 09:03:17 -0700 (PDT) Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6EG3Fq06762 for ; Sat, 14 Jul 2001 09:03:15 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id JAA17134; Sat, 14 Jul 2001 09:07:36 -0700 (PDT) Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Jul 2001 08:57:56 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA537C52DBF@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'MAEDA Toru'" , Dan Wing Cc: ietf-fax@imc.org Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Sat, 14 Jul 2001 08:57:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The following reply was lost due to the size of the attachment, but the URL for the attachment is in the message. Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc ----------------------------- This message was too long. Please send it again without attaching the large PDF file. > >From owner-ietf-fax Wed Jul 11 09:00:56 2001 >Received: from sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) > by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BG0tm27020 > for ; Wed, 11 Jul 2001 09:00:55 -0700 (PDT) >Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) > by sharplabs.com (8.9.3+Sun/8.9.2) with ESMTP id JAA10977; > Wed, 11 Jul 2001 09:00:12 -0700 (PDT) >Received: by webmail.sharplabs.com with Internet Mail Service (5.5.2653.19) > id ; Wed, 11 Jul 2001 08:50:35 -0700 >Message-ID: ><1115A7CFAC25D311BC4000508B2CA537C52DB9@mailsrvnt02.enet.sharplabs.com> >From: "McDonald, Ira" >To: "'MAEDA Toru'" , Dan Wing >Cc: ietf-fax@imc.org >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt >Date: Wed, 11 Jul 2001 08:50:33 -0700 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2653.19) >Content-Type: multipart/mixed; > boundary="----_=_NextPart_000_01C10A21.38254650" > >This message is in MIME format. Since your mail reader does not understand >this format, some or all of this message may not be legible. > >------_=_NextPart_000_01C10A21.38254650 >Content-Type: text/plain; > charset="iso-2022-jp" > >Hi, > >At the last IPP interoperability test, firewalls and proxies >that supported IPP were all successfully tested. See the >attached summary, which is available at the PWG FTP server: > >ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Bake-Off-3-Summary.pdf > >It should be noted that in-bound IPP connections (from the public >Internet across a firewall into an enterprise) have most of the >same security problems associated with in-bound SMTP connections. > >Some vendors of production print services plan to let customers >submit jobs via IPP, but the terminus of the IPP connection will >be in a special-purpose server OUTSIDE the print vendor's firewall >(for security reasons). > >IPP strong security uses TLS, which means that there MUST be an >application layer gateway at the firewall, or no enterprise data >network protection is possible (because the IPP traffic may be >encrypted in the TLS layer). > >I agree with Dan Wing that IPP Fax is probably more suitable than >SMTP as a transport for ITU-like realtime fax service. The >PWG IPP Fax WG has very carefully chosen to be consistent in >data formats (the Internet Fax TIFF-FX profiles) and capabilities >discovery (CONNEG) with existing Internet Fax modes, in order to >facilitate gateways. > >Cheers, >- Ira McDonald, consulting architect at Sharp and Xerox > High North Inc > >-----Original Message----- >From: MAEDA Toru [mailto:maeda@crf.canon.fr] >Sent: Monday, July 09, 2001 5:08 AM >To: Dan Wing >Cc: ietf-fax@imc.org >Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > >Hi, Wing-san > >Sorry for slow responce. > >Can IPP and IPP-fax protocol go through under the current firewall >configurations? > > >Regards. > >Toru Maeda > > > From owner-ietf-fax@mail.imc.org Sun Jul 15 21:03:50 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 VAA25778 for ; Sun, 15 Jul 2001 21:03:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6G0ODO03910 for ietf-fax-bks; Sun, 15 Jul 2001 17:24:13 -0700 (PDT) Received: from hotmail.com (f52.law7.hotmail.com [216.33.237.52]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6G0NQq03889 for ; Sun, 15 Jul 2001 17:23:26 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 15 Jul 2001 17:12:10 -0700 Received: from 64.241.181.128 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 16 Jul 2001 00:12:10 GMT X-Originating-IP: [64.241.181.128] From: "Terry Brookes" To: PZehler@crt.xerox.com Cc: ifx@pwg.org, ietf-fax@imc.org, imcdonald@sharplabs.com, hastings@cp10.es.xerox.com, dwing@cisco.com Subject: RE: IFX> FW: [Another take on IPP Fax from Terry Brookes] Date: Sun, 15 Jul 2001 20:12:10 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jul 2001 00:12:10.0285 (UTC) FILETIME=[F4DD65D0:01C10D8B] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Pete As mentioned, I think that IPP is great, the problem today is that nobody uses it, and I've yet to see a URI on anybody's business card or under anyone's email signature. OTOH ICQ numbers are beginning to appear, and even if you divide the *claimed* number of IM users in general by 3, that's still approaching the number of fax machines world-wide, so I really do wonder if you'll ever get all the fax machine manufacturers behind a T30+IPP device. Looks to me like it will probably suffer the same fate as the current email based Internet Fax machines which are just toooo difficult to set up, and which, at least in theory, have many of the advantages you claim for IPP Fax. Talking to several large corporate suspects about sending faxes to IPP printers was met with total indifference, but when I tell em I can send faxes from any old fax machine to the IM client of their choice they get very very interested and even willing to spend a dollar or two. The reason they are interested is because many of them already have a bundle of people using IM. E.g. around 250,000 in-house IM users in one major computer manufacturer, without even trying to promote it. (I think they may also build IPP printers) Terry > >but from a business standpoint it doesn't look like a very good way of > >meeting Mr Maeda's requirements. As far as I can tell he's looking >From: >"Zehler, Peter" >To: "'brookes_terry@hotmail.com'" >CC: "'ifx@pwg.org'" , "'imcdonald@sharplabs.com'" >, "'dwing@cisco.com'" , > "'ietf-fax@imc.org'" , "Hastings, Tom N" > >Subject: RE: IFX> FW: [Another take on IPP Fax from Terry Brookes] >Date: Mon, 9 Jul 2001 11:33:15 -0400 > >Terry, > >A couple of comments on your comments: > > >IPP also requires infrastructure in the form of IPP servers, so it may >not > >meet the stated requirements of 'using existing infrastructure'. > >IPP does not require "IPP servers" IPP only has "Printers" "Clients" and >"Jobs". The only thing that matches an "IPP server" would be an IPP >Printer. I would not consider an IPP Printer a part of the infrastructure. >IPP uses components such as HTTP, Security, firewalls and registered MIME >types for content description. These I would consider infrastructure. All >of these existing technologies are used without any IPP specific >modifications. Any FAX exchange requires similar components at both ends >regardless of the transport scheme. > > >Nope, think it's great and would like to see a URI on every business >cardfor a >way > >to use the popularity of e-mail as the basis for a simple low cost >T30-like > > >internet fax machine to replace the 100 million or so traditional fax > >machines in use. There are estimated to be half a billion fax users, >this, > >presumably, is the target market. I believe its a reasonable assumption >that > >a very large proportion of these users now have e-mail addresses; a >rapidly > > >growing number use Instant Messaging ( a number which will accelerate > >dramaticaly when Windows XP appears); but only a very small and exclusive > >group (the IPP developers ? printer manufacturers ?) appears to have any > >knowledge whatsoever of IPP. From a technical standpoint Dan's proposal >of > >IPP may be OK, from a marketing standpoint it doesn't look like a very >good > > >idea because the user won't have anyone to send to, because, despite the > >valiant efforts of IPP people, hardly anyone actualy uses it. IM could >(not > > >would!) be a better bet on the basis that it could work very much like >T30 > >AND have a large number of people already using it. Not IMPP, which the >Blue > >Window Software Corporation (Redmond WA) is in the process of killing, >but > >Windows IM which will probably be the de facto IM standard by the time Mr > >Maeda's machine is ready for production. > >My own belief is that FOIP will only be successfull if it's as easy to >use > >as a regular fax machine. POP/SMTP has proved to be much too complex to >set > > >up, IPP doesn't have a user base even if it *is* imbedded in every >printer, > > >so maybe IM will be the answer...who knows? > >I contend that only a small number of FAX users know anything about ITU >specifications and many don't know the meaning of TIFF. I doubt your >average email user is very familiar with SMTP or POP-3. Anyone sending a >traditional FAX or email does know the phone number or email address of the >recipient. >I believe there is a business case for ifax and IPP FAX. Ask marketing/end >users if they would be interested in >1) Sending a FAX around the world through their Internet service provider >avoiding long distance phone charges. >2) Sending a FAX without encountering a "busy signal". >3) Sending a FAX securely with mutual authentication and encryption. >4) Having the capability of negotiating to a higher fidelity of output. >5) Faxing directly from an application with the best resolution available >at >the printer. >6) Receiving confirmation similar to or beyond traditional FAX (i.e. >reception and printed). >7) Having a single device that is connected to both the Internet and the >phone line capable of sending and receiving FAXs via traditional FAX, ifax >or IPP FAX based on availability. > >With ifax and IPP FAX we are met with the classic chicken and egg problem. >At least one side has to be built first. Hopefully the other side will >soon >follow. > >IPP has a track record of interoperability across vendor implementations >for >clients and printers. I expect the FAX profile for IPP to meet similar >success. > >By the way, user of Windows XP have IPP Client capability out of the box >just as Windows 2000 users do. Why would IPP have much of a user base even >though it is available in printers and in Windows given that most printing >is done locally and traditional methods are the easiest to set up in >Windows. ("where do we want you to go today?") Windows also have the >capability of acting as IPP Printers. > >Pete > > Peter Zehler > XEROX > Xerox Architecture Center > Email: PZehler@crt.xerox.com > Voice: (716) 265-8755 > FAX: (716) 265-8792 > US Mail: Peter Zehler > Xerox Corp. > 800 Phillips Rd. > M/S 128-69E > Webster NY, 14580-9701 > > >-----Original Message----- >From: Terry Brookes [mailto:brookes_terry@hotmail.com] >Sent: Thursday, July 05, 2001 6:34 AM >To: imcdonald@sharplabs.com; dwing@cisco.com >Cc: ietf-fax@imc.org; maeda@crf.canon.fr; dcrocker@brandenburg.com >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > >Hi Ira, > > >Do you just dislike IPP? >Nope, think it's great and would like to see a URI on every business card, >but from a business standpoint it doesn't look like a very good way of >meeting Mr Maeda's requirements. As far as I can tell he's looking for a >way > >to use the popularity of e-mail as the basis for a simple low cost T30-like >internet fax machine to replace the 100 million or so traditional fax >machines in use. There are estimated to be half a billion fax users, this, >presumably, is the target market. I believe its a reasonable assumption >that > >a very large proportion of these users now have e-mail addresses; a rapidly >growing number use Instant Messaging ( a number which will accelerate >dramaticaly when Windows XP appears); but only a very small and exclusive >group (the IPP developers ? printer manufacturers ?) appears to have any >knowledge whatsoever of IPP. From a technical standpoint Dan's proposal of >IPP may be OK, from a marketing standpoint it doesn't look like a very good >idea because the user won't have anyone to send to, because, despite the >valiant efforts of IPP people, hardly anyone actualy uses it. IM could (not >would!) be a better bet on the basis that it could work very much like T30 >AND have a large number of people already using it. Not IMPP, which the >Blue > >Window Software Corporation (Redmond WA) is in the process of killing, but >Windows IM which will probably be the de facto IM standard by the time Mr >Maeda's machine is ready for production. >My own belief is that FOIP will only be successfull if it's as easy to use >as a regular fax machine. POP/SMTP has proved to be much too complex to set >up, IPP doesn't have a user base even if it *is* imbedded in every printer, >so maybe IM will be the answer...who knows? > >Terry > > >From: "McDonald, Ira" > >To: "'Terry Brookes'" , dwing@cisco.com > >CC: ietf-fax@imc.org, maeda@crf.canon.fr, dcrocker@brandenburg.com > >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > >Date: Tue, 3 Jul 2001 10:27:47 -0700 > > > > > >Hi Terry, > > > >Do you just dislike IPP? > > > >For IPP Fax to work, IPP does NOT need to be ubiquitous. It just > >needs to be ubiquitous in deployed PRINTERS. Very few printers > >shipped in calendar 2001 that did not have IPP protocol support. > >Probably NONE will ship in calendar 2002 without IPP protocol > >support. > > > >I agree that SMTP is ubiquitous, but it doesn't (and can't ever) > >do realtime capabilities negotiation, by its very nature. > > > >Certainly such protocols as IMPP (your suggestion) are utterly > >inappropriate for sending large documents by VALUE (like IPP) > >and not by REFERENCE. > > > >Could you explain your implacable opposition to IPP Fax, please? > > > >Cheers, > >- Ira McDonald, consulting architect at Sharp and Xerox > > High North Inc > > > > > >-----Original Message----- > >From: Terry Brookes [mailto:brookes_terry@hotmail.com] > >Sent: Tuesday, July 03, 2001 8:30 AM > >To: dwing@cisco.com > >Cc: ietf-fax@imc.org; maeda@crf.canon.fr; dcrocker@brandenburg.com > >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > >Hi > >I'd re-phrase the following- > > >IPP exists. < > > > >This would be more accurate- > > >IPP barely exists< > > > >Also 'IPP FAX' certainly does NOT exist...yet. > > > >IPP also requires infrastrucure in the form of IPP servers, so it may not > >meet the stated requirements of 'using existing infrastructure'. > > > >If SMTP really doesn't work for fax terminal mode then strategicaly the >new > >Windows Instant Messenger could be a much better bet. It's likely to >become > >a de facto standard for the non-AOL IM's, and with IM you get an instant > >response that should allow replication of T30 with great simplicity. You > >also get SIP with Windows IM, which could allow discovery of the > >capabilities of the receiving fax terminal, probably even give you the > >color > > > >of the operator's hair. > > > >Terry Brookes > >www.polyteq.com > > > > > > > > >From: "Dan Wing" > > >To: "Dave Crocker" > > >CC: "MAEDA Toru" , > > >Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > >Date: Sat, 30 Jun 2001 17:42:39 -0700 > > > > > > > > >Yes, shared code is good. > > > > > >"Fax terminal mode" is an end-to-end service which has much more in > >common > > >with PSTN fax and T.38 fax than the SMTP model of multiple hops, >storing > > >mail, > > >mailing lists, etc. > > > > > >IPP has more in common with transmitting documents than SMTP, and I >still > > >say > > >that IPP can provide something more closer approaching the goals of >"fax > > >terminal mode" than SMTP. > > > > > >For universal messaging, T.37/RFC2305 is the way to go. For >duplication > >of > > >exact fax functionality on an IP network, T.38 is the way to go. While > > >T.38 > > >is more difficult than an IETF text-based protocol, forcing SMTP to > > >essentially do 'SAML' (everyone by Dave, see RFC821 for a description >of > > >SAML) > > >across multiple hops is hard. > > > > > >If you want something easier than T.38, IPP exists. IPP can be >enhanced > >as > > >needed to support the features necessary to replicate fax. > > > > > >-d > > > > > > > -----Original Message----- > > > > From: Dave Crocker [mailto:dcrocker@brandenburg.com] > > > > Sent: Saturday, June 30, 2001 7:55 AM > > > > To: Dan Wing > > > > Cc: MAEDA Toru; ietf-fax@imc.org > > > > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > > > > > > > > > > At 01:39 PM 6/28/2001, Dan Wing wrote: > > > > >I'm unclear on why the ability to fallback requires the original > > > > attempt be in > > > > >SMTP. > > > > > > > > > > > > The more the modes have in common, the more code they share. That > >means > > > > that the different modes have less to implement. > > > > > > > > There also might be operational impact, such as retaining an SMTP > > > > connection. > > > > > > > > Retaining interworking with email continues to be a nice ability, >too. > > > > > > > > It also makes it easier to evaluate the efficacy of each, different > > > > mode. The fewer modes the better/simpler. > > > > > > > > d/ > > > > > > > > ---------- > > > > Dave Crocker > > > > Brandenburg InternetWorking > > > > tel +1.408.246.8253; fax +1.408.273.6464 > > > > > > > > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at http://explorer.msn.com > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ietf-fax@mail.imc.org Mon Jul 16 07:32: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 HAA15092 for ; Mon, 16 Jul 2001 07:32:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GAasE09045 for ietf-fax-bks; Mon, 16 Jul 2001 03:36:54 -0700 (PDT) Received: from elettra.trieste.it (SYNW06.elettra.trieste.it [140.105.2.8]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6GAaqq09039 for ; Mon, 16 Jul 2001 03:36:53 -0700 (PDT) Date: Mon, 16 Jul 2001 12:33:26 +0100 To: Terry Brookes cc: PZehler@crt.xerox.com, ifx@pwg.org, ietf-fax@imc.org, imcdonald@sharplabs.com, hastings@cp10.es.xerox.com, dwing@cisco.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: RE: IFX> FW: [Another take on IPP Fax from Terry Brookes] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Looks to me like it will probably suffer the same fate as the current email > based Internet Fax machines which are just toooo difficult to set up, As I already mentioned on the mailing list, they're "just a mail MTA+MUA in a box"... It is a bit more complex than a printer machine, but... It goes anywhere, while the rest simply CANNOT. And a messaging service which cannot go anywhere, is not a service which will make the users happy, and thus will probably to attract customers. > printers was met with total indifference, but when I tell em I can send > faxes from any old fax machine to the IM client of their choice they get > very very interested and even willing to spend a dollar or two. This is just a onramp/offramp gateway, and i-fax have it, too. Just my personal opinion, without the ietf fax wg chair hat on. Regards Claudio Allocchio PS: netiquette states "do no quote full messages when replying, just quote needed parts - RFC 1855" From owner-ietf-fax@mail.imc.org Tue Jul 17 07:47: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 HAA17076 for ; Tue, 17 Jul 2001 07:47:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HB0gM05578 for ietf-fax-bks; Tue, 17 Jul 2001 04:00:42 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HB0eq05574 for ; Tue, 17 Jul 2001 04:00:41 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.9.2/8.9.2) id MAA13642 for ; Tue, 17 Jul 2001 12:56:54 +0200 (MET DST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from mercure.crf.canon.fr(intranet.crf.canon.fr 194.2.81.249) by lancelot via smap (V2.0beta) id xma013634; Tue, 17 Jul 01 12:56:36 +0200 Received: from crf.canon.fr ([194.2.81.15]) by mercure.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GGM5UC00.B9K; Tue, 17 Jul 2001 12:44:36 +0200 Message-ID: <3B541A82.3A4F17E4@crf.canon.fr> Date: Tue, 17 Jul 2001 19:59:14 +0900 From: "MAEDA Toru" X-Mailer: Mozilla 4.75 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Claudio Allocchio CC: Dan Wing , ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Claudio. My point is that "firewall" is SMTP relay, but SMTP is not a "relay" protocol. Regards. Toru Maeda Claudio Allocchio wrote: > > > > Thus SMTP is defintly a "relay" protocol. > > > > > I think that the router is confifurated SMTP server as a "relay" device. > > ... the "router" ? the router does not support any application protocol > like SMTP. it is level 3 downwards... > > If it is a "firewall", then it can act as an intermiediate SMTP relay. > > Regards > Claudio -- ********************************* MAEDA Toru CANON Research Centre France S.A. ********************************* From owner-ietf-fax@mail.imc.org Tue Jul 17 12:58: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 MAA19692 for ; Tue, 17 Jul 2001 12:58:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HGK2B07265 for ietf-fax-bks; Tue, 17 Jul 2001 09:20:02 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HGK1q07261 for ; Tue, 17 Jul 2001 09:20:01 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6HGJlv07554; Tue, 17 Jul 2001 09:19:58 -0700 (PDT) Received: from DWINGW2K (dhcp-milan-italtel-144-254-87-85.cisco.com [144.254.87.85]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ABB00390; Tue, 17 Jul 2001 09:19:39 -0700 (PDT) From: "Dan Wing" To: "MAEDA Toru" , "Claudio Allocchio" Cc: Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Tue, 17 Jul 2001 18:19:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B541A82.3A4F17E4@crf.canon.fr> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Hi, Claudio. > > My point is that "firewall" is SMTP relay, > but SMTP is not a "relay" protocol. I disagree. SMTP is a relay protocol. RFC2821, says this in Section 1, "Introduction": An important feature of SMTP is its capability to transport mail across networks, usually referred to as "SMTP mail relaying" (see section 3.8). A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks. The trouble is the "multually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet" -- the remote ifax device will (nearly) always be on a firewall-isolated TCP/IP Intranet. If this significant problem can be somehow overcome, then SMTP could work. But I am not convinced that network administrators would allow unauthenticated connections from the Internet to their internal ifax devices. Is the intent of the 'full mode' ifax to work only within an enterprise's internal network, or between enterprises that trust each other, or between enterprises that have a VPN set up between themselves? If that's the model, that's fine, too. In fact, I could believe such a model would be more successful and more viable. -d From owner-ietf-fax@mail.imc.org Wed Jul 18 09:00: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 JAA16468 for ; Wed, 18 Jul 2001 09:00:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ICIFd00387 for ietf-fax-bks; Wed, 18 Jul 2001 05:18:15 -0700 (PDT) Received: from hotmail.com (f100.law7.hotmail.com [216.33.237.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ICIDq00380 for ; Wed, 18 Jul 2001 05:18:13 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Jul 2001 05:18:10 -0700 Received: from 64.241.181.128 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 18 Jul 2001 12:18:08 GMT X-Originating-IP: [64.241.181.128] From: "Terry Brookes" To: dwing@cisco.com, maeda@crf.canon.fr, Claudio.Allocchio@garr.it Cc: ietf-fax@imc.org Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Wed, 18 Jul 2001 08:18:08 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2001 12:18:10.0042 (UTC) FILETIME=[B55455A0:01C10F83] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dan, pardon the probably dumb newbies question, but why can't the fax-terminal inside the firewall simply use POP to get the ifax from wherever its mailbox is, inside the firewall or outside ? also >Is the intent of the 'full mode' ifax to work only within an enterprise's >internal network, or between enterprises that trust each other, or between >enterprises that have a VPN set up between themselves? If that's the >model, >that's fine, too. In fact, I could believe such a model would be more >successful and more viable. > You just killed the market for it, thanks ;-) ! Terry _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ietf-fax@mail.imc.org Wed Jul 18 13:23: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 NAA16602 for ; Wed, 18 Jul 2001 13:23:41 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6IGjcu07469 for ietf-fax-bks; Wed, 18 Jul 2001 09:45:38 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IGjbq07465 for ; Wed, 18 Jul 2001 09:45:37 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6IGhSc16302; Wed, 18 Jul 2001 09:43:51 -0700 (PDT) Received: from DWINGW2K (dhcp-milan-italtel-144-254-87-91.cisco.com [144.254.87.91]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ABM06285; Wed, 18 Jul 2001 09:45:05 -0700 (PDT) From: "Dan Wing" To: "Terry Brookes" , , Cc: Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt Date: Wed, 18 Jul 2001 18:45:03 +0200 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Full-mode" requires an end-to-end connection to support all existing T.30 functions. POP can't do that. It would have to be SMTP end-to-end (from transmitter to receiver). This means POP wouldn't work. -d > -----Original Message----- > From: Terry Brookes [mailto:brookes_terry@hotmail.com] > Sent: Wednesday, July 18, 2001 2:18 PM > To: dwing@cisco.com; maeda@crf.canon.fr; Claudio.Allocchio@garr.it > Cc: ietf-fax@imc.org > Subject: RE: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt > > > Hi Dan, > > pardon the probably dumb newbies question, but why can't the fax-terminal > inside the firewall simply use POP to get the ifax from wherever > its mailbox > is, inside the firewall or outside ? > > also > > > >Is the intent of the 'full mode' ifax to work only within an enterprise's > >internal network, or between enterprises that trust each other, or between > >enterprises that have a VPN set up between themselves? If that's the > >model, > >that's fine, too. In fact, I could believe such a model would be more > >successful and more viable. > > > > You just killed the market for it, thanks ;-) ! > > Terry > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > From owner-ietf-fax@mail.imc.org Thu Jul 19 17:56: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 RAA24327 for ; Thu, 19 Jul 2001 17:56:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JL6lM06576 for ietf-fax-bks; Thu, 19 Jul 2001 14:06:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JL6gq06572 for ; Thu, 19 Jul 2001 14:06:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13551; Thu, 19 Jul 2001 17:05:25 -0400 (EDT) Message-Id: <200107192105.RAA13551@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-fax@imc.org From: The IESG Subject: Protocol Action: Minimal FAX address format in Internet Mail to Draft Standard Date: Thu, 19 Jul 2001 17:05:25 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Minimal FAX address format in Internet Mail' as a Draft Standard, replacing RFC2304, a Proposed Standard. This document is the product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary This memo describes a simple method of encoding GSTN addresses of facsimile devices in the local-part of Internet email addresses. As with all Internet mail addresses, the left-hand-side (local- part) of an address generated according to this specification, is not to be interpreted except by the MTA that is named on the right-hand-side (domain). This document is an updated version of RFC 2304. Working Group Summary This document is a product of the FAX Working Group of the IETF. Protocol Summary Ned Freed reviewed this document for the IESG. Note to RFC Editor: As these documents are now at draft standard and RFCs 2821 and 2822 are proposed standards, the references to RFCs 2821 and 2822 need to be changed to refer to full standard RFCs 821 and 822. From owner-ietf-fax@mail.imc.org Thu Jul 19 17:56:14 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 RAA24338 for ; Thu, 19 Jul 2001 17:56:12 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6JLC3h06859 for ietf-fax-bks; Thu, 19 Jul 2001 14:12:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JLBxq06850 for ; Thu, 19 Jul 2001 14:11:59 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13751; Thu, 19 Jul 2001 17:06:58 -0400 (EDT) Message-Id: <200107192106.RAA13751@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-fax@imc.org From: The IESG Subject: Protocol Action: Minimal GSTN address format in Internet Mail to Draft Standard Date: Thu, 19 Jul 2001 17:06:58 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Minimal GSTN address format in Internet Mail' as a Draft Standard, replacing RFC2303, a Proposed Standard. This document is the product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary This memo describes a simple method of encoding GSTN addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. Only the minimal set of generic features that all agents must support is specified in this document. As with all Internet mail addresses, the left-hand-side (local-part) of an address generated according to this specification, is not to be interpreted except by an MTA that handles messages for the domain given in the right-hand-side. This document is an updated version of RFC 2303. Working Group Summary This document is a product of the FAX Working Group of the IETF. Protocol Summary Ned Freed reviewed this document for the IESG. Note to RFC Editor: As these documents are now at draft standard and RFCs 2821 and 2822 are proposed standards, the references to RFCs 2821 and 2822 need to be changed to refer to full standard RFCs 821 and 822. From owner-ietf-fax@mail.imc.org Sat Jul 21 05:24: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 FAA08047 for ; Sat, 21 Jul 2001 05:24:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6L8lnJ23825 for ietf-fax-bks; Sat, 21 Jul 2001 01:47:49 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6L8lkq23821 for ; Sat, 21 Jul 2001 01:47:46 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id RAA19249; Sat, 21 Jul 2001 17:47:28 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by azteca.isd.ricoh.co.jp (Mirapoint) with SMTP id AAV08055; Sat, 21 Jul 2001 17:47:25 +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 RAA07798; Sat, 21 Jul 2001 17:47:19 +0900 To: ned.freed@mrochek.com, paf@cisco.com, ietf-secretariat@ietf.org Cc: Claudio.Allocchio@garr.it, ietf-fax@imc.org Subject: [IETF-FAX] Request for IESG Consideration for content-negoation I-D 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: <20010721175018N.tamura@toda.ricoh.co.jp> Date: Sat, 21 Jul 2001 17:50:18 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Ned, Dear Patrik, Dear IETF secretary, I am Hiroshi Tamura, a co-chair of IETF FAX WG. The Internet Fax Working Group requests IESG approval for publication of the following document, with the specified status. .................................................................... Content Negotiation for Internet Messaging Services draft-ietf-fax-content-negotiation-05.txt Status: Proposed Standard Summary: This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email. Working Group Last Call Result: All the points made by Minneapolis meeting are covered in the I-D. The I-D was submitted for IETF-FAX WG Last Call on June 23. During WG LC period, there were no comments. It sucessfully finished. .................................................................... Best Regards, -- Hiroshi Tamura IETF FAX WG co-chair From owner-ietf-fax@mail.imc.org Mon Jul 23 19:27: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 TAA00808 for ; Mon, 23 Jul 2001 19:27:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NMY3W08105 for ietf-fax-bks; Mon, 23 Jul 2001 15:34:03 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NMY0q08099; Mon, 23 Jul 2001 15:34:00 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id SAA16664; Mon, 23 Jul 2001 18:33:59 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id OAA08057; Mon, 23 Jul 2001 14:15:50 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 14:15:49 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A3482@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'IETF - fax WG dl'" Cc: "'IETF - Claudio Allocchio (IFaxWG chair)'" , "'IETF - Hiroshi Tamura (IFaxWG chair)'" , "'IETF - Ned Freed (App Area Director/Area Advisor, Innosoft Int)'" , "'IETF-web site - Paul Hoffman'" , "'William Rucklidge 1'" , "Abercrombie, Dave" , "Krockenberger, Martin " Subject: Drafts TIFF-FX Extension 1 and Schema Extension 1 Date: Mon, 23 Jul 2001 14:15:45 -0700 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: All, The following URL: http://www.parc.xerox.com/ietf_fax/ contains two drafts (draft-mcintyre-tiff-fx-extension1-02.txt and draft-mcintyre-feature-schema-extension1-00.txt) for your review and discussion during the IFax WG session of the Aug. London IETF meetings. 1. draft-mcintyre-tiff-fx-extension1-02.txt This is intended to represent the -02 draft version of draft-ietf-fax-tiff-fx-extension1-01.txt, which was sent to the drafts list for publication on Friday July 20th but arrived after the 17:00 USA Eastern Daylight Time cut-off. The main changes in draft-mcintyre-tiff-fx-extension1-02.txt relative to draft-ietf-fax-tiff-fx-extension1-01.txt are: a) a restructuring of the draft to change its context from being a narrative on performing a text edit of TIFF-FX (RFC 2301 or a replacement RFC XXXX) to a more self-contained structure, which must be read together with RFC XXXX. This is consistent with the fact that RFC XXXX will not be modified by this or any future extension. b) accommodation of the two new JBIG2 profiles under ITU-T Last Call approval (July 28th LC closure). c) accommodation of JPEGTables field to improve interoperability with applications such as Photoshop 6.0 which always uses the JPEGTables field when generating JPEG encoded files. 2. draft-mcintyre-feature-schema-extension1-00.txt This draft defines extensions to RFC 2879 Content Feature Schema for Internet Fax (V2) and requests registration of the new feature tags and new values for existing tags. These extensions reflect the range of new TIFF-FX Extension Set 1 capabilities (e.g. new resolutions 300x600 to 1200x1200 and JBIG2 encoding) that were adopted by Group 3 facsimile during the period of 1999 through 2001. Lloyd *********************************************** Lloyd McIntyre lmcintyre@pahv.xerox.com Xerox Corp., Xerox Architecture Center 3400 Hillview Ave. Bldg. 1 Palo Alto, CA 94304 Tel: +1 650 813 6762 fax: +1 650 813 6860 *********************************************** From owner-ietf-fax@mail.imc.org Mon Jul 23 19:52:57 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 TAA02258 for ; Mon, 23 Jul 2001 19:52:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NN9wf08970 for ietf-fax-bks; Mon, 23 Jul 2001 16:09:58 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NN9vq08965 for ; Mon, 23 Jul 2001 16:09:57 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id TAA28028 for ; Mon, 23 Jul 2001 19:09:59 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id QAA10545 for ; Mon, 23 Jul 2001 16:09:57 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 16:09:57 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE0BD77CA4@mercury.ADOC.xerox.com> From: "Abercrombie, Dave" To: "'ietf-fax@imc.org'" Subject: Draft TIFF-FX Extension 1 for JBIG2 comments Date: Mon, 23 Jul 2001 16:09:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C113CC.92C8E4E0" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C113CC.92C8E4E0 Content-Type: text/plain; charset="iso-8859-1" A few minor edits to Draft TIFF-FX Extension 1 for JBIG2: E1.5.4, first paragraph: Change: "from the beginning of the file of the first" to "from the beginning of the file to the first". Change: "that physically exist in the table" to "that physically exist in that table". E1.5.4, last paragraph: Change: "have 3, 1 and 2 shared data entry respectively" to "have 3, 1 and 2 shared data entries respectively". Add to last sentence: "change in the reference to the new ID (see SharedDataList, E1.5.4.1). Regards, Dave Abercrombie aber@pahv.xerox.com , (650) 813-6811 XEROX THE DOCUMENT COMPANY Xerox Architecture Center Document Solutions Architecture Color & Imaging Solutions Group ------_=_NextPart_001_01C113CC.92C8E4E0 Content-Type: text/html; charset="iso-8859-1"
A few minor edits to Draft TIFF-FX Extension 1 for JBIG2:
 
E1.5.4, first paragraph:
Change: "from the beginning of the file of the first" to "from the beginning of the file to the first".
Change: "that physically exist in the table" to "that physically exist in that table".
 
E1.5.4, last paragraph:
Change: "have 3, 1 and 2 shared data entry respectively" to "have 3, 1 and 2 shared data entries respectively".
Add to last sentence: "change in the reference to the new ID (see SharedDataList, E1.5.4.1).
 
Regards,
 
Dave Abercrombie
aber@pahv.xerox.com, (650) 813-6811
XEROX THE DOCUMENT COMPANY
Xerox Architecture Center
Document Solutions Architecture
Color & Imaging Solutions Group
 
------_=_NextPart_001_01C113CC.92C8E4E0-- From owner-ietf-fax@mail.imc.org Tue Jul 24 06:07: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 GAA05359 for ; Tue, 24 Jul 2001 06:07:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6O9Scg12701 for ietf-fax-bks; Tue, 24 Jul 2001 02:28:38 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6O9SaG12692 for ; Tue, 24 Jul 2001 02:28:37 -0700 (PDT) Date: Tue, 24 Jul 2001 11:28:28 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: ietf fax WG meeting - draft agenda Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, here is (finally) our draft agenda for the ietf fax wg meeting in London. Please comment ASAP on it, expecially: - editors confirm/update their time requirements (it might also mean "I need less time than scheduled") - all, please check that all topics are planned for discussion We added a bigger slot for Milestones update, as it is time to have an accurate list now. Sorry for the delay. On Friday 27th July I'd like to tantatively submit the final WG agenda. Regards, ------------------------------------------------------------------------------ Internet FAX Working Group meeting Draft Agenda IETF 51st, London, UK Monday August 6th 2001, 19.30 - 22.00 1. Agenda bashing 2 min 2 2. Status of Draft Standard consideration 2.1 Addressing 1 min 3 - draft-ietf-fax-minaddr-v2-04.txt - draft-ietf-fax-faxaddr-v2-04.txt [done - IESG approved on July 19th 2001, RFC editor queue now] 2.2 TIFF-FX 20 min 23 - draft-ietf-fax-tiff-fx-09.txt - draft-ietf-fax-tiff-regbis-02.txt [Status report on these docuements by IAB - J. Klensin; Introduction of the ITU letter regarding TIFF-FX] 3 Targeted for Draft Standard 1 min 24 3.1 Service - draft-ietf-fax-service-v2-03.txt [Sent publication request to IESG on June 23rd with Interworking report (published on June 18th); request to wait for publication until all dependancies are resolved - on IESG requests queue] 4 Targeted for Informational 4.1 Implementers Guide 1 min 25 - draft-ietf-fax-implementers-guide-07.txt [Sent publication request to IESG on Apr 10th and we had the letter from ITU confirming that T.37 would refer the Implementer's guide. - Still not in IESG pages, we asked again IESG . Ned, any information for it?] 5 On-going Internet-Drafts 5.1 Gateway issue 15 min 40 - draft-ietf-fax-gateway-protocol-05.txt - draft-ietf-fax-gateway-options-03.txt [New I-Ds are published and the discussion is going on] 5.2 FFPIM - draft-ietf-fax-ffpim-01.txt 10 min 50 [we need to review the details of the ID and ask for target date. In the Minneapolis meeting the possibility to include terminal mode in the I-D was metioned] - draft-ietf-fax-content-negotiation-05.txt 1 min 51 [status WG last call OK, request for IETF last call to IESG on July 21st. 2001] - draft-ietf-fax-esmtp-conneg-00.txt 15 min 66 [this is brand new and we need to present and discuss it] - draft-ietf-fax-timely-delivery-03.txt 2 min 68 [actions done by Graham, issues discussed with Ned and still in dicussion. We also agreed in Minneapolis that we could go to the WG Last call after the new I-D is published and we confirm it in some ways] 5.3 Terminal mode issue 30 min 98 - draft-maeda-faxwg-terminal-mode-goals-00.txt - draft-maeda-faxwg-terminal-mode-protocol-00.txt - draft-maeda-faxwg-fax-processing-status-00.txt [quite some discussion on the list about the viability of the whole "terminal mode" schema - we should clarify this issue] 5.4 PWG IPP Fax status report 15 min 113 [Tom Hastings should report on their activity] 5.4 TIFF-FX extension issue 30 min 143 - draft-ietf-fax-tiff-fx-Extension-1-02.txt (draft-mcintyre-tiff-fx-extension1-02.txt) - darft-mcintyre-feature-schema-extension1-00.txt [the documents are just distributed on out ML, not in time for ID submission] 7 Miscellaneous 2 min 145 - status of fax charter update [We will report on the "update" process] 8 Confirmation of milestone 5 min 150 [please come prepared with feasible dates in mind!] ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 From owner-ietf-fax@mail.imc.org Tue Jul 24 16:19: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 QAA17996 for ; Tue, 24 Jul 2001 16:19:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OIotL03543 for ietf-fax-bks; Tue, 24 Jul 2001 11:50:55 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OIonG03538 for ; Tue, 24 Jul 2001 11:50:49 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA05796; Tue, 24 Jul 2001 14:50:45 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id LAA29229; Tue, 24 Jul 2001 11:50:34 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 11:50:34 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A3492@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Claudio Allocchio'" , ietf-fax@imc.org Subject: RE: IETF fax WG meeting - draft agenda Date: Tue, 24 Jul 2001 11:50:33 -0700 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: Claudio, For 5.4 PWG IPP Fax status report, please list me as the presenter. Thanks, Lloyd > -----Original Message----- > From: Claudio Allocchio [mailto:Claudio.Allocchio@garr.it] > Sent: Tuesday, July 24, 2001 3:28 AM > To: ietf-fax@imc.org > Subject: ietf fax WG meeting - draft agenda > > > > > Hallo, > > here is (finally) our draft agenda for the ietf fax wg > meeting in London. > > Please comment ASAP on it, expecially: > > - editors confirm/update their time requirements (it might > also mean "I > need less time than scheduled") > > - all, please check that all topics are planned for discussion > > We added a bigger slot for Milestones update, as it is time > to have an > accurate list now. > > Sorry for the delay. On Friday 27th July I'd like to > tantatively submit > the final WG agenda. > > Regards, > > -------------------------------------------------------------- > ---------------- > > Internet FAX Working Group meeting > Draft Agenda > IETF 51st, London, UK > Monday August 6th 2001, 19.30 - 22.00 > > > 1. Agenda bashing 2 min > 2 > > 2. Status of Draft Standard consideration > 2.1 Addressing 1 min > 3 > - draft-ietf-fax-minaddr-v2-04.txt > - draft-ietf-fax-faxaddr-v2-04.txt > > [done - IESG approved on July 19th 2001, RFC editor > queue now] > > 2.2 TIFF-FX 20 min > 23 > - draft-ietf-fax-tiff-fx-09.txt > - draft-ietf-fax-tiff-regbis-02.txt > > [Status report on these docuements by IAB - J. Klensin; > Introduction of the ITU letter regarding TIFF-FX] > > 3 Targeted for Draft Standard 1 min > 24 > 3.1 Service > - draft-ietf-fax-service-v2-03.txt > > [Sent publication request to IESG on June 23rd with Interworking > report (published on June 18th); request to wait for publication > until all dependancies are resolved - on IESG requests queue] > > 4 Targeted for Informational > 4.1 Implementers Guide 1 min > 25 > - draft-ietf-fax-implementers-guide-07.txt > > [Sent publication request to IESG on Apr 10th and we had the > letter from ITU confirming that T.37 would refer the Implementer's > guide. - Still not in IESG pages, we asked again IESG . Ned, any > information for it?] > > 5 On-going Internet-Drafts > 5.1 Gateway issue 15 min > 40 > - draft-ietf-fax-gateway-protocol-05.txt > - draft-ietf-fax-gateway-options-03.txt > > [New I-Ds are published and the discussion is going on] > > 5.2 FFPIM > - draft-ietf-fax-ffpim-01.txt 10 min > 50 > > [we need to review the details of the ID and ask for target date. > In the Minneapolis meeting the possibility to include terminal mode > in the I-D was metioned] > > - draft-ietf-fax-content-negotiation-05.txt 1 min > 51 > > [status WG last call OK, request for IETF last call to IESG > on July 21st. 2001] > > - draft-ietf-fax-esmtp-conneg-00.txt 15 min > 66 > > [this is brand new and we need to present and discuss it] > > - draft-ietf-fax-timely-delivery-03.txt 2 min > 68 > > [actions done by Graham, issues discussed with Ned and > still in dicussion. We also agreed in Minneapolis that we > could go to the WG Last call after the new I-D is published > and we confirm it in some ways] > > 5.3 Terminal mode issue 30 min > 98 > - draft-maeda-faxwg-terminal-mode-goals-00.txt > - draft-maeda-faxwg-terminal-mode-protocol-00.txt > - draft-maeda-faxwg-fax-processing-status-00.txt > > [quite some discussion on the list about the viability of the > whole "terminal mode" schema - we should clarify this issue] > > 5.4 PWG IPP Fax status report 15 min > 113 > > [Tom Hastings should report on their activity] > > 5.4 TIFF-FX extension issue 30 min > 143 > - draft-ietf-fax-tiff-fx-Extension-1-02.txt > (draft-mcintyre-tiff-fx-extension1-02.txt) > - darft-mcintyre-feature-schema-extension1-00.txt > > [the documents are just distributed on out ML, not in > time for ID submission] > > 7 Miscellaneous 2 min > 145 > - status of fax charter update > > [We will report on the "update" process] > > 8 Confirmation of milestone 5 min > 150 > > [please come prepared with feasible dates in mind!] > > > -------------------------------------------------------------- > ---------------- > Claudio Allocchio G A R R > Claudio.Allocchio@garr.it > Project Technical Officer > tel: +39 040 3758523 Italian Academic and > G=Claudio; S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; > A=garr; C=it; > > PGP Key: > http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 > From owner-ietf-fax@mail.imc.org Wed Jul 25 11:16: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 LAA00091 for ; Wed, 25 Jul 2001 11:16:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6PE3Xh14914 for ietf-fax-bks; Wed, 25 Jul 2001 07:03:33 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6PE3Vs14910 for ; Wed, 25 Jul 2001 07:03:31 -0700 (PDT) Date: Wed, 25 Jul 2001 16:03:00 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Milestones Review Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, I just finished a cross check of the whole set of our milestones (past - present and future). Please check that the result is correct, and eventually sent me the relevant corrections. We will anyhow confirm the current and future ones at the meeting, but it would be useful also a prior verification. Thanks indeed ! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 GOALS AND MILESTONES: ------------ from old charter ---------------------------------------------- Jan 1997 Submit Internet-Draft of terminology document Done (see RFC 2542) Jan 1997 Submit Internet-Draft of data specifications Done (see RFC 2301) Feb 1997 Submit Internet-Draft of operational constraints document First Gateway draft (equiv to operational constraints) Done (see draft-ietf-fax-gateway-protocol-XX.txt and draft-ietf-fax-gateway-options-XX.txt) Feb 1997 Submit Internet-Draft of messaging-related specification Done (See RFC 2305) Apr 1997 Submit data specifications to IESG for consideration as a standards track document Done (see RFC 2301) Apr 1997 Submit terminology document to IESG for publication Done (see RFC 2542) Jun 1997 Submit messaging-related specification to IESG for consideration as a standards track document Done (See RFC 2305) Jun 1997 Submit operational constraints document to IESG for publication as an Informational document Done (see draft-ietf-fax-implementers-guide-07.txt sent to IESG on June 2001 for publication) -------------- new charter milestones ----------------------------------- Jun 1998 Submit Initial drafts for Full Mode documents Done (see RFC 2532) Jun 1998 Submit Initial drafts for Receipts documents Done (see RFC 2530) Sep 1998 Submit Extended/Full mode documents to IESG for publication as Proposed Standard Done (see RFC 2532, RFC 2846) Dec 1998 Submit updated Addressing documents to IESG for publication as Draft Standards Done (see draft-ietf-fax-minaddr-v2-04.txt and draft-ietf-fax-faxaddr-v2-04.txt approved on July 19th 2001) Mar 1999 Submit updated Simple Mode document to IESG for publication as Draft Standard Done (see draft-ietf-fax-service-v2-03.txt sent to IESG on June 2001) Mar 1999 Submit updated File Mode (tiff-fx) documents to IESG for publication as Draft Standard Pending for IAB comments - Submitted to IESG in Dec 2000 Mar 2000 Re-charter the Working Group Done (document sent to IESG in June 2000) Mar 2000 Submit Initial internet-draft for timely delivery Done (see draft-ietf-fax-timely-delivery-XX.txt) Mar 2000 Submit Initial internet-draft for content negotiaton for fax Done (see draft-ietf-fax-content-negotiation-XX.txt) Mar 2000 Submit initial Internet-drafts for FFPIM Done (see draft-ietf-fax-ffpim-XX.txt) Mar 2000 Submit initial Internet-draft of Implementors Guide for Simple and Extended mode Done (see draft-ietf-fax-implementers-guide-XX.txt) Jul 2000 Submit initial Internet-draft of Routing considerations Decision: drop the document Jul 2000 Submit initial Internet-draft of gateway requirements Done (see draft-ietf-fax-gateway-protocol-XX.txt and draft-ietf-fax-gateway-options-XX.txt) Nov 2000 Submit initial Internet-drafts of schema and TIFF-fx extensions for JBIG-2 Done (see draft-ietf-fax-tiff-fx-Extension-1-XX.txt and darft-mcintyre-feature-schema-extension1-XX.txt) Nov 2000 Submit final draft of Routing Considerations Decision: drop the document Apr 2001 Submit final draft of Implementors Guide for Simple and Extended mode to IESG for publication as Infomrational. Done (see draft-ietf-fax-implementers-guide-07.txt sent to IESG on June 2001) Apr 2001 Submit final draft for timely delivery to IESG for publication as Proposed Standard Done (see draft-ietf-fax-timely-delivery-03.txt being sent to ISEG) Apr 2001 Submit final draft for content negotiaton to IESG for publication as Proposed Standard Done (see draft-ietf-fax-content-negotiation-05.txt sent to IESG on July 21st 2001) Apr 2001 Submit final draft for FFPIM to IESG for publication Jul 2001 Submit final draft of gateway requirements Jul 2001 Submit final draft of TIFF-fx extensions Jul 2001 Submit final draft of schema for TIFF-fx extensions Jul 2001 Submit second draft of Fax status information Jul 2001 Submit second draft of Goal for Terminal Mode Jul 2001 Submit second draft of Protocol for Terminal Mode Dec 2001 Submit final draft of Fax status information Dec 2001 Submit final draft of Goal for Terminal Mode Dec 2001 Submit Final draft of Protocol for Terminal Mode From owner-ietf-fax@mail.imc.org Wed Jul 25 14:47: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 OAA22168 for ; Wed, 25 Jul 2001 14:47:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6PI44R26177 for ietf-fax-bks; Wed, 25 Jul 2001 11:04:04 -0700 (PDT) Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PI42s26173 for ; Wed, 25 Jul 2001 11:04:02 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA25779; Wed, 25 Jul 2001 14:04:02 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id LAA22859; Wed, 25 Jul 2001 11:03:23 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 11:03:22 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A3495@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Claudio Allocchio'" , ietf-fax@imc.org Subject: RE: Milestones Review Date: Wed, 25 Jul 2001 11:03:22 -0700 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: Claudio, Please adjust the TIFF-FX and Schema extensions milestones as reflected below. Thanks, Lloyd Aug 2001 Submit final draft of TIFF-fx extensions Nov 2001 Submit final draft of schema for TIFF-fx extensions From owner-ietf-fax@mail.imc.org Thu Jul 26 13:51: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 NAA26289 for ; Thu, 26 Jul 2001 13:51:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6Q8FS329940 for ietf-fax-bks; Thu, 26 Jul 2001 01:15:28 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6Q8FQs29936 for ; Thu, 26 Jul 2001 01:15:26 -0700 (PDT) Date: Thu, 26 Jul 2001 10:15:10 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: updated agenda - last comments please! Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, here is the updated agenda which includes the comments received up to now. Please send any further comment by tomorrow, July 27th at 12.00 GMT than I'll submit it... but we can always make on sit modifications! Regards Claudio Allocchio ----------------------------- Internet FAX Working Group meeting Draft Agenda IETF 51st, London, UK Monday August 6th 2001, 19.30 - 22.00 1. Agenda bashing 2 min 2 2. Status of Draft Standard consideration 2.1 Addressing 1 min 3 - draft-ietf-fax-minaddr-v2-04.txt - draft-ietf-fax-faxaddr-v2-04.txt [done - IESG approved on July 19th 2001, RFC editor queue now] 2.2 TIFF-FX 20 min 23 - draft-ietf-fax-tiff-fx-09.txt - draft-ietf-fax-tiff-regbis-02.txt [Status report on these docuements by IAB - J. Klensin; Introduction of the ITU letter regarding TIFF-FX] 3 Targeted for Draft Standard 1 min 24 3.1 Service - draft-ietf-fax-service-v2-03.txt [Sent publication request to IESG on June 23rd with Interworking report (published on June 18th); request to wait for publication until all dependancies are resolved - on IESG requests queue] 4 Targeted for Informational 4.1 Implementers Guide 1 min 25 - draft-ietf-fax-implementers-guide-07.txt [Sent publication request to IESG on Apr 10th and we had the letter from ITU confirming that T.37 would refer the Implementer's guide. - Still not in IESG pages, we asked again IESG . Ned, any information for it?] 5 On-going Internet-Drafts 5.1 Gateway issue 15 min 40 - draft-ietf-fax-gateway-protocol-05.txt - draft-ietf-fax-gateway-options-03.txt [New I-Ds are published and the discussion is going on] 5.2 FFPIM - draft-ietf-fax-ffpim-01.txt 10 min 50 [we need to review the details of the ID and ask for target date. In the Minneapolis meeting the possibility to include terminal mode in the I-D was metioned] - draft-ietf-fax-content-negotiation-05.txt 1 min 51 [status WG last call OK, request for IETF last call to IESG on July 21st. 2001] - draft-ietf-fax-esmtp-conneg-00.txt 15 min 66 [this is brand new and we need to present and discuss it] - draft-ietf-fax-timely-delivery-03.txt 2 min 68 [actions done by Graham, issues discussed with Ned and still in dicussion. We also agreed in Minneapolis that we could go to the WG Last call after the new I-D is published and we confirm it in some ways] 5.3 Terminal mode issue 30 min 98 - draft-maeda-faxwg-terminal-mode-goals-00.txt - draft-maeda-faxwg-terminal-mode-protocol-00.txt - draft-maeda-faxwg-fax-processing-status-00.txt [quite some discussion on the list about the viability of the whole "terminal mode" schema - we should clarify this issue] 5.4 PWG IPP Fax status report 15 min 113 [Lloyd McIntyre should report on their activity] 5.5 TIFF-FX extension issue 30 min 143 - draft-ietf-fax-tiff-fx-Extension-1-02.txt (draft-mcintyre-tiff-fx-extension1-02.txt) - darft-mcintyre-feature-schema-extension1-00.txt [the documents are just distributed on out ML, not in time for ID submission] 6 Miscellaneous 2 min 145 - status of fax charter update [We will report on the "update" process] 7 Confirmation of milestone 5 min 150 [please come prepared with feasible dates in mind!] From owner-ietf-fax@mail.imc.org Thu Jul 26 14:16:35 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 OAA00131 for ; Thu, 26 Jul 2001 14:16:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QGLHT23930 for ietf-fax-bks; Thu, 26 Jul 2001 09:21:17 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QGLGs23926 for ; Thu, 26 Jul 2001 09:21:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01K6DMFPV3VK000UU5@mauve.mrochek.com> for ietf-fax@imc.org; Thu, 26 Jul 2001 09:21:16 -0700 (PDT) Date: Thu, 26 Jul 2001 09:06:35 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: [IETF-FAX] Request for IESG Consideration on Service I-D In-reply-to: "Your message dated Sat, 23 Jun 2001 14:25:41 +0900 (JST)" <20010623142541D.tamura@toda.ricoh.co.jp> To: Hiroshi Tamura Cc: ned.freed@mrochek.com, paf@cisco.com, ietf-secretariat@ietf.org, Claudio.Allocchio@garr.it, ietf-fax@imc.org Message-id: <01K6DR6H9G30000UU5@mauve.mrochek.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 > A Simple Mode of Facsimile Using Internet Mail > draft-ietf-fax-service-v2-03.txt > Status: Draft Standard A few things need to be fixed before this one will be ready for IETF last call. (1) This document apparently obsoletes RFC 2305 but never mentions RFC 2305. At a minimum you need to have "Obsoletes: RFC 2305" in the document header, you need to include RFC 2305 in the references, and you need to have a section explaining the differences between this document and RFC 2305. (2) I don't insist on it, but since this document talks about "network printers" some discussion of its relationship with IPP might be appropriate. (3) References [10] and [11] needs to be updated to refer to the recently approved updates to RFC 2303 and RFC 2304. (It is OK to reference a draft that is in the RFC publication queue, as these are.) (4) This document has lots of references, some of which are normative and some of which are not. (And yes, I'm well aware of the issue surrounding the updates to the DSN specifications.) It would be really helpful if you could separate the normative and non-normative references, making it clear what needs to in place before this can actually be published. (5) Appendix A uses the capitalized phrase "NOT REQUIRED". We try and reserve use of capitalization of this sort to the terms defined in RFC 2119. (And yes, I do realize that this wasn't caught in the previous version.) I suggest that you either lower case these words or reword to use the regular capitalized terms (MAY is the one that comes to mind). Let me know when a new draft has been submitted and I'll review it again. Ned From owner-ietf-fax@mail.imc.org Thu Jul 26 16:02: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 QAA08299 for ; Thu, 26 Jul 2001 16:02:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QJLHE27959 for ietf-fax-bks; Thu, 26 Jul 2001 12:21:17 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QJLFs27955 for ; Thu, 26 Jul 2001 12:21:16 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QJKf900435 for ; Thu, 26 Jul 2001 15:20:41 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 26 Jul 2001 15:20:57 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:21:00 -0400 Message-ID: From: "Glenn Parsons" To: "'ietf-fax@imc.org'" Subject: FW: [VPIM] I-D ACTION:draft-ema-vpim-cb-02.txt Date: Thu, 26 Jul 2001 15:20:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11608.1918CE10" X-Orig: Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11608.1918CE10 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11608.1918CE10" ------_=_NextPart_001_01C11608.1918CE10 Content-Type: text/plain FYI, there will be a last call on this draft shortly in the VPIM WG. Cheers, Glenn. > ---------- > From: Internet-Drafts@ietf.org > Sent: Wednesday, July 25, 2001 6:41 am > To: IETF-Announce > Cc: vpim@lists.neystadt.org > Subject: [VPIM] I-D ACTION:draft-ema-vpim-cb-02.txt > > <<...>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Voice Messaging Client Behaviour > Author(s) : G. Parsons, J. Maruszak > Filename : draft-ema-vpim-cb-02.txt > Pages : 9 > Date : 24-Jul-01 > > This document defines the expected behaviour of a client to > various aspects of a VPIM message or any voice or fax message. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ema-vpim-cb-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-ema-vpim-cb-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-ema-vpim-cb-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_001_01C11608.1918CE10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: [VPIM] I-D ACTION:draft-ema-vpim-cb-02.txt

FYI, there will be a last = call on this draft shortly in the VPIM WG.

Cheers,
Glenn.

----------
From:   Internet-Drafts@ietf.org
Sent:   Wednesday, July 25, 2001 6:41 am
To:     = IETF-Announce
Cc:     = vpim@lists.neystadt.org
Subject: =        [VPIM] I-D ACTION:draft-ema-vpim-cb-02.txt

<<...>> =
A New Internet-Draft is available = from the on-line Internet-Drafts directories.


        Title   =         : Voice Messaging Client = Behaviour
        Author(s)       : G. = Parsons, J. Maruszak
        Filename        : = draft-ema-vpim-cb-02.txt
        Pages   =         : 9
        Date    =         : 24-Jul-01
       =20
This document defines the expected = behaviour of a client to  
various aspects of a VPIM message or = any voice or fax message.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ema-vpim-cb-= 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-ema-vpim-cb-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-ema-vpim-cb-02.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable = a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_001_01C11608.1918CE10-- ------_=_NextPart_000_01C11608.1918CE10 Content-Type: message/rfc822 To: Subject: Date: Wed, 25 Jul 2001 17:09:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C11608.1918CE10" ------_=_NextPart_002_01C11608.1918CE10 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C11608.1918CE10" ------_=_NextPart_003_01C11608.1918CE10 Content-Type: text/plain ------_=_NextPart_003_01C11608.1918CE10 Content-Type: text/html

  ------_=_NextPart_003_01C11608.1918CE10-- ------_=_NextPart_002_01C11608.1918CE10 Content-Type: application/octet-stream; name="ATT41528" Content-Disposition: attachment; filename="ATT41528" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724143614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ema-vpim-cb-02.txt ------_=_NextPart_002_01C11608.1918CE10 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ema-vpim-cb-02"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C11608.1918CE10-- ------_=_NextPart_000_01C11608.1918CE10-- From owner-ietf-fax@mail.imc.org Thu Jul 26 19:33: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 TAA22316 for ; Thu, 26 Jul 2001 19:33:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6QMoKg02136 for ietf-fax-bks; Thu, 26 Jul 2001 15:50:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QMoHs02131 for ; Thu, 26 Jul 2001 15:50:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19279; Thu, 26 Jul 2001 18:49:18 -0400 (EDT) Message-Id: <200107262249.SAA19279@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: Implementers Guide for Facsimile Using Internet Mail to Informational Reply-to: iesg@ietf.org Date: Thu, 26 Jul 2001 18:49:18 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider Implementers Guide for Facsimile Using Internet Mail 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 August 26, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-implementers-guide-07.txt From owner-ietf-fax@mail.imc.org Fri Jul 27 08:37: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 IAA12623 for ; Fri, 27 Jul 2001 08:37:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RBrE813600 for ietf-fax-bks; Fri, 27 Jul 2001 04:53:14 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6RBrDs13596 for ; Fri, 27 Jul 2001 04:53:13 -0700 (PDT) Date: Fri, 27 Jul 2001 13:52:57 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: fax WG updated charter and milestones - new version published Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ... it took "some time"... but at last... ---------- Forwarded message ---------- Date: Thu, 26 Jul 2001 18:50:12 -0400 (Eastern Daylight Time) From: Steve Coya To: Claudio Allocchio Cc: iesg@ietf.org, Ned Freed , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Hiroshi Tamura Subject: Re: fax WG updated charter and milestones - can we finally fix it? Claudio, It is with great pleasure that I report the update of the FAX WG Charter. The web page will be regenerated tonight. Steve From owner-ietf-fax@mail.imc.org Fri Jul 27 09:46:23 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 JAA17928 for ; Fri, 27 Jul 2001 09:46:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6RD0ps14740 for ietf-fax-bks; Fri, 27 Jul 2001 06:00:51 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6RD0ns14736 for ; Fri, 27 Jul 2001 06:00:50 -0700 (PDT) Date: Fri, 27 Jul 2001 15:00:30 +0100 To: agenda@ietf.org cc: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: FAX WG agenda for the 51st IETF Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here is the final agenda for the FAX WG meeting at IETF 51st, With my best regards, Claudio Allocchio ietf fax WG co-chair ------------------------------------------------------------------------------ Internet FAX Working Group meeting Draft Agenda IETF 51st, London, UK Monday August 6th 2001, 19.30 - 22.00 1. Agenda bashing 2 min 2 2. Status of Draft Standard consideration 2.1 Addressing 1 min 3 - draft-ietf-fax-minaddr-v2-04.txt - draft-ietf-fax-faxaddr-v2-04.txt [done - IESG approved on July 19th 2001, RFC editor queue now] 2.2 TIFF-FX 20 min 23 - draft-ietf-fax-tiff-fx-09.txt - draft-ietf-fax-tiff-regbis-02.txt [Status report on these docuements by IAB - J. Klensin; Introduction of the ITU letter regarding TIFF-FX] 3 Targeted for Draft Standard 1 min 24 3.1 Service - draft-ietf-fax-service-v2-03.txt [Sent to IESG on June 23rd with Interworking report (published on June 18th); request to wait for publication until all dependancies are resolved - received AD comments (July 26th) for an update before IETF Last Call] 4 Targeted for Informational 4.1 Implementers Guide 1 min 25 - draft-ietf-fax-implementers-guide-07.txt [Sent request to IESG on Apr 10th and we had the letter from ITU confirming that T.37 would refer the Implementer's guide. - IETF Last Call on July 26th until August 26th] 5 On-going Internet-Drafts 5.1 Gateway issue 15 min 40 - draft-ietf-fax-gateway-protocol-05.txt - draft-ietf-fax-gateway-options-03.txt [New I-Ds are published and the discussion is going on] 5.2 FFPIM - draft-ietf-fax-ffpim-01.txt 10 min 50 [we need to review the details of the ID and ask for target date. In the Minneapolis meeting the possibility to include terminal mode in the I-D was metioned] - draft-ietf-fax-content-negotiation-05.txt 1 min 51 [status WG last call OK, request for IETF last call to IESG on July 21st. 2001] - draft-ietf-fax-esmtp-conneg-00.txt 15 min 66 [this is brand new and we need to present and discuss it] - draft-ietf-fax-timely-delivery-03.txt 2 min 68 [actions done by Graham, issues discussed with Ned and still in dicussion. We also agreed in Minneapolis that we could go to the WG Last call after the new I-D is published and we confirm it in some ways] 5.3 Terminal mode issue 30 min 98 - draft-maeda-faxwg-terminal-mode-goals-00.txt - draft-maeda-faxwg-terminal-mode-protocol-00.txt - draft-maeda-faxwg-fax-processing-status-00.txt [quite some discussion on the list about the viability of the whole "terminal mode" schema - we should clarify this issue] 5.4 PWG IPP Fax status report 15 min 113 [Lloyd McIntyre should report on their activity] 5.5 TIFF-FX extension issue 30 min 143 - draft-ietf-fax-tiff-fx-Extension-1-02.txt (draft-mcintyre-tiff-fx-extension1-02.txt) - darft-mcintyre-feature-schema-extension1-00.txt [the documents are just distributed on out ML, not in time for ID submission] 6 Miscellaneous 2 min 145 - status of fax charter update [Done July 26th] 7 Confirmation of milestone 5 min 150 [please come prepared with feasible dates in mind!] From owner-ietf-fax@mail.imc.org Sat Jul 28 20:41:55 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 UAA12081 for ; Sat, 28 Jul 2001 20:41:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6SHPZp22964 for ietf-fax-bks; Sat, 28 Jul 2001 10:25:35 -0700 (PDT) Received: from ws2-7.us4.outblaze.com (205-158-62-82.outblaze.com [205.158.62.82]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6SHPXs22960 for ; Sat, 28 Jul 2001 10:25:34 -0700 (PDT) Received: (qmail 5915 invoked by uid 1001); 28 Jul 2001 17:25:30 -0000 Message-ID: <20010728172530.5914.qmail@earthlink.net> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from ws2-7.us4.outblaze.com for [209.179.246.64] via web-mailer on Sun, 29 Jul 2001 01:25:29 +0800 From: "Dale Knutsen" To: ietf-fax@imc.org Date: Sun, 29 Jul 2001 01:25:29 +0800 Subject: ImageBaseColor's photometry: Redefine to be simple, convenient, practical Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am working on software implementing a TIFF-FX reader, and I have found the current definition of ImageBaseColor in TIFF-FX to be rather impractical, and I recommend changing it as described below. The Problem The color sample data contained in the ImageBaseColor field is specified to be in photometry ITU L*a*b*. Notice that this photometry may be DIFFERENT than that of the image that is being represented. For example, consider TIFF generator software which has an input image with photometry CMYK; the software is rendering this image into a TIFF-FX data stream. If the generator notices a strip whose color is constant, the generator could achieve excellent compression by representing the constant color in ImageBaseColor and setting the strip byte count to zero. HOWEVER, the generator is faced with the daunting task of representing the CMYK (in this example) constant color in ITU L*a*b* color space. This requires: (a) the generator must have the mapping from device-dependent CMYK photometry to the colorimetric ITU L*a*b* photometry; typically this is done by having the appropriate ICC profile and applying it to the CMYK. However, the generator may not have the profile data available for a variety of reasons. (b) the generator must incorporate the complicated algorithms (color space conversion, ICC profile processing) -- which are not required otherwise of the generator. Similar problems occur to software reading a TIFF data stream. Analysis and Proposal It seems to me that the motivation behind of ImageBaseColor is to provide an efficient way to represent strips of constant color. Of course we want it to be simple and practical too -- which I think the present definition is not. I propose that that the photometry and interpretation of the ImageBaseColor field data be changed to be IDENTICAL TO that of the containing IFD (including all applicable fields which modify the representation and photometric interpretation of color sample data). This means that the representation of ImageBaseColor sample data would be identical to the representation of the ordinary color sample data that it represents (stands in place of). This would be extremely simple and convenient, both for the creator of a TIFF data stream and for the reader of a TIFF data stream! There would be NO difference in the treatment of ordinary color sample data and the color sample data in the ImageBaseColor field. Dale Knutsen -- Dale Knutsen _______________________________________________ Get your free email from http://webmail.earthlink.net From owner-ietf-fax@mail.imc.org Sat Jul 28 20:54: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 UAA15260 for ; Sat, 28 Jul 2001 20:54:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6S7xj800171 for ietf-fax-bks; Sat, 28 Jul 2001 00:59:45 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6S7xgs00158 for ; Sat, 28 Jul 2001 00:59:43 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id QAA03241 for ; Sat, 28 Jul 2001 16:59:41 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by delsol.isd.ricoh.co.jp (Mirapoint) with SMTP id ABA04450; Sat, 28 Jul 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 QAA04505 for ; Sat, 28 Jul 2001 16:59:35 +0900 To: ietf-fax@imc.org Subject: Re: FAX WG agenda for the 51st IETF 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: <20010728170245G.tamura@toda.ricoh.co.jp> Date: Sat, 28 Jul 2001 17:02:45 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 147 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, London meeting is coming soon. Thanks to Claudio, we have the status summary for each I-Ds. Please read on-going I-Ds and provide your comments before our meeting. I add comments for our agenda. > - draft-ietf-fax-minaddr-v2-04.txt > - draft-ietf-fax-faxaddr-v2-04.txt > > [done - IESG approved on July 19th 2001, RFC editor > queue now] Yes! I thank Claudio and all of the contributors, especially the people who did implementation tests. No action remains for us. > - draft-ietf-fax-tiff-fx-09.txt > - draft-ietf-fax-tiff-regbis-02.txt > > [Status report on these docuements by IAB - J. Klensin; > Introduction of the ITU letter regarding TIFF-FX] ITU letter is already circulated by ITU-T SG16 TSB. They also request quick action. > - draft-ietf-fax-service-v2-03.txt > > [Sent to IESG on June 23rd with Interworking report > (published on June 18th); request to wait for publication > until all dependancies are resolved - received AD comments > (July 26th) for an update before IETF Last Call] Now, the editors are revising it. Toyoda-san, please comment a little about it at our meeting. > - draft-ietf-fax-implementers-guide-07.txt > > [Sent request to IESG on Apr 10th and we had the > letter from ITU confirming that T.37 would refer the Implementer's > guide. - IETF Last Call on July 26th until August 26th] No action, for the time being. We wait. > - draft-ietf-fax-gateway-protocol-05.txt > - draft-ietf-fax-gateway-options-03.txt > > [New I-Ds are published and the discussion is going on] I hear the editors want to fix it at London and agree to WG LC after the meeting. Please provide comments, if you are interested in them. Mimura-san, please explain the differences from the previous version. > - draft-ietf-fax-ffpim-01.txt 10 min 50 > > [we need to review the details of the ID and ask for target date. > In the Minneapolis meeting the possibility to include terminal mode > in the I-D was metioned] Yes. Along with terminal mode, we have to consider it. But, it is the big and only issue. After deciding whether the I-D includes it or not, it is easy to proceed, I think. > - draft-ietf-fax-content-negotiation-05.txt 1 min 51 > > [status WG last call OK, request for IETF last call to IESG > on July 21st. 2001] I did. No action, for the time being. We wait. > - draft-ietf-fax-esmtp-conneg-00.txt 15 min 66 > > [this is brand new and we need to present and discuss it] Yes. But, the concept is simple. It is for direct SMTP transfer, which relates to terminal mode. > - draft-ietf-fax-timely-delivery-03.txt 2 min 68 > > [actions done by Graham, issues discussed with Ned and > still in dicussion. We also agreed in Minneapolis that we > could go to the WG Last call after the new I-D is published > and we confirm it in some ways] After he gets the information from Ned and reflect it in the new I-D, we can do WG LC. Graham, please get it. > 5.3 Terminal mode issue 30 min 98 > - draft-maeda-faxwg-terminal-mode-goals-00.txt > - draft-maeda-faxwg-terminal-mode-protocol-00.txt > - draft-maeda-faxwg-fax-processing-status-00.txt > > [quite some discussion on the list about the viability of the > whole "terminal mode" schema - we should clarify this issue] Just clarification. The contents of processing-status I-D can be used in other situations. It is not only for terminal mode. Of course, the "terminal mode" schema is the main issue here. Some people do not like this mode in SMTP. Maeda-san, Please provide in detail for advancing it. > 5.4 PWG IPP Fax status report 15 min 113 Just for information. No action is necessary for us. > - draft-ietf-fax-tiff-fx-Extension-1-02.txt > (draft-mcintyre-tiff-fx-extension1-02.txt) > - darft-mcintyre-feature-schema-extension1-00.txt They are large documents. Please read them beforehand. > 6 Miscellaneous 2 min 145 > - status of fax charter update > > [Done July 26th] Yes! We finally reached to it. It took more than one year. > 7 Confirmation of milestone 5 min 150 > > [please come prepared with feasible dates in mind!] Yes. We need to update our milestone. See you at London. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Sat Jul 28 20:59: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 UAA16106 for ; Sat, 28 Jul 2001 20:59:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6S3ABn06716 for ietf-fax-bks; Fri, 27 Jul 2001 20:10:11 -0700 (PDT) Received: from AvantiServer.avantiholdings.com (durham-23-122.biz.dsl.gtei.net [4.3.23.122]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6S3A8s06710 for ; Fri, 27 Jul 2001 20:10:08 -0700 (PDT) Received: from JP2000 ([12.98.203.162]) by AvantiServer.avantiholdings.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 27 Jul 2001 20:02:31 -0700 Reply-To: From: "John Pulera" To: "IETF - Internet FAX Group" Cc: "Lloyd McIntyre" Subject: comments on tiff-fx & schema extension drafts Date: Fri, 27 Jul 2001 20:10:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C116D8.3BEDC5F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 28 Jul 2001 03:02:31.0437 (UTC) FILETIME=[BE1A6BD0:01C11711] 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_0013_01C116D8.3BEDC5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I have reviewed the documents 'draft-ietf-fax-tiff-fx-Extension1-02.txt' and 'draft-McIntyre-Feature-Schema-Extension1-00.txt'. Here are some comments for both: 'draft-ietf-fax-tiff-fx-Extension1-02.txt' Section E1.5.4: The document does not contain any recommended or required restrictions on placement within the TIFF file of (i) the first Shared Data Table and (ii) the Shared Data data blocks. Are the Shared Data data blocks allowed to span the entire TIFF file? Or should all shared data tables and data blocks appear within the TIFF file BEFORE any references to them are encountered in a TIFF strip? Section E1.6.1 Paragraph 2, Line (editorial) Change "Rational" to "Rationale" Section E1.6.7 Rule #10 This rule not clear. Section 1.4.8 of which document is referenced? 'draft-McIntyre-Feature-Schema-Extension1-00.txt' Section 2.1.2 line 1 (editorial) Change "Nine new T88Options coding parameter feature" to "Nine new T88Options coding parameter features" Section 2.1.2 seventh bullet and throughout Appendixes A and B (editorial) Should 'T88Options-TextStipesMixed' be changed to 'T88Options-TextStripesMixed' John Pulera ----------------------------------------- John Pulera Minolta Systems Laboratory jpulera@minolta-mil.com (949)737-4520 x348 ------=_NextPart_000_0013_01C116D8.3BEDC5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have = reviewed the=20 documents 'draft-ietf-fax-tiff-fx-Extension1-02.txt' and=20 'draft-McIntyre-Feature-Schema-Extension1-00.txt'. Here are some = comments for=20 both:
 
'draft-ietf-fax-tiff-fx-Extension1-02.= txt'=20
 
Section=20 E1.5.4:
   =20 The document does not contain any recommended or required restrictions = on=20 placement within the TIFF file of (i) the first Shared Data Table = and (ii)=20 the Shared Data data blocks. Are the Shared Data data = blocks allowed=20 to span the entire TIFF file? Or should all shared data tables and data = blocks=20 appear within the TIFF file BEFORE any references to them are = encountered=20 in a TIFF strip?
 
Section E1.6.1=20 Paragraph 2, Line (editorial)
     Change "Rational" to = "Rationale"
 
Section E1.6.7 Rule=20 #10
      This rule not = clear.=20 Section 1.4.8 of which document is referenced?
 
 
'draft-McIntyre-Feature-Schema-Extensi= on1-00.txt'
 
Section 2.1.2 line 1=20 (editorial)
   =20 Change "Nine new T88Options coding parameter feature" to "Nine new = T88Options=20 coding parameter features"
 
Section 2.1.2=20 seventh bullet and throughout Appendixes A and B (editorial)=20
    Should=20 'T88Options-TextStipesMixed' be changed to=20 'T88Options-TextStripesMixed'
 
 
John=20 Pulera
 
-----------------------------------------
John Pulera
Minolta Systems Laboratory
jpulera@minolta-mil.com
(949)737-4520 x348
 
 

 

------=_NextPart_000_0013_01C116D8.3BEDC5F0-- From owner-ietf-fax@mail.imc.org Sat Jul 28 20:59: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 UAA16125 for ; Sat, 28 Jul 2001 20:59:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6S22HY05924 for ietf-fax-bks; Fri, 27 Jul 2001 19:02:17 -0700 (PDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6S21us05914 for ; Fri, 27 Jul 2001 19:02:16 -0700 (PDT) Received: from norman.cp10.es.xerox.com (norman.cp10.es.xerox.com [13.240.124.12]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id WAA28090 for ; Fri, 27 Jul 2001 22:01:59 -0400 (EDT) Received: from x-crt-es-ms1.es.cp10.es.xerox.com (x-crt-es-ms1 [13.240.124.41]) by norman.cp10.es.xerox.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21375 for ; Fri, 27 Jul 2001 19:02:15 -0700 (PDT) Received: by x-crt-es-ms1.cp10.es.xerox.com with Internet Mail Service (5.5.2653.19) id <3HYP5DVQ>; Fri, 27 Jul 2001 19:01:57 -0700 Message-ID: <918C79AB552BD211A2BD00805F15CE85056F345C@x-crt-es-ms1.cp10.es.xerox.com> From: "Hastings, Tom N" To: ietf-fax@imc.org Subject: FW: IFX> Revised agenda for the IPPFAX WG meeting in Toronto, Aug 1 Date: Fri, 27 Jul 2001 19:01:15 -0700 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: Internet FAX WG, The attached note indicates the three documents that we are working on for IPPFAX: 1. UIF spec version D0.6: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06.pdf 2. IFX (IPP FAX Protocol) spec version D0.6: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf 3. IPPGET Delivery Method (): ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf If you have comments, we'd like to hear them. Our mailing list is: IPP FAX Mailing List: ifx@pwg.org IPP FAX Web Page: http://www.pwg.org/qualdocs/index.html To subscribe to the ifx mailing list, send the following email: 1) send it to majordomo@pwg.org 2) leave the subject line blank 3) put the following two lines in the message body: subscribe ifx end In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list. Thank you, Tom Hastings -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, July 27, 2001 17:21 To: IPP FAX DL (E-mail) Subject: IFX> Revised agenda for the IPPFAX WG meeting in Toronto, Aug 1 This mail note supersedes the previous ones on suggested IPPFAX WG agenda for the Toronto meeting. This mail note lists each document to be reviewed. I've included the issues that are included in each document and the ones that have come up on the mailing list this past week. I have not been able to update the IPPGET spec with the discussion that we have had this week after last Friday's IETF deadline (7/20). So the IPPGET spec that was sent to the IETF last Friday and announced on Monday (7/23) should be used. As I said before, there are three IPP FAX documents that could be covered at the IPP FAX WG meeting. In the past, we have only been able to cover one such document in a full day and for this meeting the PWG plenary takes up some of the time. The IPPFAX WG will need to decide whether to focus on one document and which one, or try to go through the issues that are raised explicitly in each document. I suggest the latter approach. The UIF spec has 5 issues and is in good shape. The IFX spec has 41 issues and needs real review. The IPPGET spec is in pretty good shape with 7 issues. The documents are: 1. UIF spec version D0.6, John Pulera posted Wednesday, 7/25 at: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06.pdf ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06-edit.pdf 2. IFX (IPP FAX Protocol) spec version D0.6, I posted today, 7/27: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf 3. IPPGET Delivery Method (), I posted Monday, 7/23, at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf 4. Drafts TIFF-FX Extension 1 and Schema Extension 1 Lloyd McIntyre called our attention to last Monday, 7/23. As soon as it is approved we can add a Profile T (JBIG2) to our UIF document. Here it is important to send any comments to the Internet FAX DL () as well as the IPP FAX DL (=0) (CIELAB-L-max<=100) (CIELAB-a-min>=-85) (CIELAB-a-max<=85) (CIELAB-b-min>=-75) (CIELAB-b-max<=125) (dpi=[200,300]) (dpi-xyratio=1) ) Define "profile=uif-l" to mean (& (image-file-structure=TIFF-limited-uif) (MRC-mode=0) (color=grey) (image-coding=JBIG) (image-coding-constraint=JBIG-T43) (JBIG-stripe-size=128) (image-interleave=stripe) (color-space=CIELAB) (color-levels<=256) (color-illuminant=D50) (CIELAB-L-min>=0) (CIELAB-L-max<=100) (dpi=[200,300]) (dpi-xyratio=1) ) Then, for example, we can rewrite the minimum capabilities string for UIF Profile M shown in Section 4.1.2.6 as (| (profile=[uif-s,uif-c]) (& (image-file-structure=TIFF-MRC-limited) (MRC-mode=1) (MRC-max-stripe-size<=256) (profile=[uif-s,uif-c]) (dpi=[200,300]) ) ) As another example, if we would like to advertise a Receiver that can support UIF Profiles S, F, J with optional resolution of 1200 dpi for the black & white profiles and optional resolution of 600dpi for the color profile, we can say (| (& (profile=[uif-s,uif-f]) (dpi=[200,300,600,1200]) ) (& (profile=uif-c) (dpi=[200,300,600]) ) ) UIF Issue 4. (not in the document; see section 5.1.1) Should we change the MIME media registration to be simply a single value for the application parameter and add a new 'profile' parameter which is multi-valued to indicate the profiles that are in the document? So for a document that contains C and F on separate pages, instead of: image/tiff; application=uif-cf we'd have: image/tiff; application=uif; profile=uif-c,uif-f and for a document that contains MRC with C, L, and S, instead of: image/tiff; application=uif-mcls we'd have (in any order): image/tiff; application=uif; profile=uif-c,uif-l,uif-m,uif-s UIF ISSUE 5. (not in the document; see table 15) Profile M only lists 200** and 300** for background and foreground layers and doesn't mention the binary mask layer at all. We need to add the binary mask layer back in. OK to add 400** as a REQUIRED value for all three uses? MRC requires that the mask layer be an integral multiple (1, 2,3, ...) of the resolutions for the background and foreground layers. If we don't add 400** as a REQUIRED resolution, the mask layer would have to be the same as the background and foreground layers (200 or 300) unless an OPTIONAL resolution were used. 2. IFX spec version D0.6, I posted today, 7/27: ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf All of these issues are in the document: ISSUE 01: We did a lot of name changing at the telecon. Are these attribute names ok now? Check the TOC to see all the names together. ISSUE 02: I'm not completely happy with the organization of the document. Each attribute has its own section, so it appears in the TOC. Also I've tried to put the corresponding "xxx-supported" right next to the "xxx" attribute description, but in a separate section. However, several operation attributes appear more than once: "ippfax-semantics", "ippfax-profiles", and "document-format". Any suggestions or is this OK? ISSUE 03: OK that we are using the 'ipp:' scheme for both IPP and IPPFAX protocols? ISSUE 04: Can 'http' scheme be used in the "printer-uri" target attribute? Will 'http' be more likely to be configured to get through firewalls? What can a standards track RFC say about this since IPP/1.1 REQUIRES the use of the 'ipp' scheme? ISSUE 05: OK that we are forced to use the same default port for IPPFAX as for IPP? So if a Receiver is configured to only receive IPPFAX Jobs from outside its firewall, but receive IPP Jobs from inside its firewall, one or the other will be forced to supply an explicit (different) port? ISSUE 06: If an IPPFAX Receiver is configured for IPP only, should it still accept an IPPFAX job, rather than rejecting it, but perform it with IPP semantics? That is what an IPP/1.1 Printer would do that doesn't know about the IPPFAX spec and the IPP Sender won't make this mistake, since it MUST query to determine if the Receiver is currently accepting IPPFAX requests. ISSUE 07: OK to add the new 'client-error-missing-required-attribute' status code? The existing 'client-error-bad-request' status code isn't sufficient, since we want to return the missing attribute rather than indicate something wrong with what was submitted. Also the existing 'client-error-forbidden' is too mysterious, since it suggests an authorization and/or authentication problem. In the past, missing REQUIRED attributes are developer errors, so that the 'client-error-bad-request' was sufficient. But this error can happen to a customer who has turned off IPP (or the implementation only supports IPPFAX semantics). This new status code can be used for other cases where 'client-error-bad-request' is used. ISSUE 08: How does coloring work when more than one UIF Profile is specified? ISSUE 09: Should we REQUIRE the Receiver to color attributes with the "ippfax-uif-profiles" supplied by the Sender in a Get-Printer-Attributes operation? If yes, should we REQUIRE the Sender to supply the "ippfax-uif-profiles" attribute in the Get-Printer-Attributes? ISSUE 10: Should we REQUIRE the Receiver to color attributes with the "document-format" supplied by the Sender in a Get-Printer-Attributes operation? If yes, should we REQUIRE the Sender to supply the "document-format" attribute in the Get-Printer-Attributes? ISSUE 11: OK to REQUIRE the Sender to query the "ippfax-versions-supported" Printer Description attribute, or is using Validate-Job sufficient if we change it from SHOULD to MUST? An IPP/1.1 Printer would return success, with the "ippfax-semantics" operation attribute in the Unsupported Group which the Sender could check for. What about an IPPFAX Receiver that is configured only for 'ipp'? ISSUE 12: OK to REQUIRE the Sender to query the "ippfax-semantics-supported" Printer Description attribute, or is using Validate-Job sufficient if we change it from SHOULD to MUST? An IPP/1.1 Printer would return success, with the "ippfax-semantics" operation attribute in the Unsupported Group which the Sender could check for. What about an IPPFAX Receiver that is configured only for 'ipp'? ISSUE 13: Need to add some more UIF Profiles for color versus gray scale for C and L Profiles (same issue for UIF spec). ISSUE 14: OK that we got rid of the new 'octetString32k' attribute syntax and use existing IPP/1.1 attribute syntaxes, so that existing IPP systems can be used as gateways? ISSUE 15: are these additional capabilities restricted to the OPTIONAL capabilities in the UIF Profile according to the UIF spec ([14]), or MAY they include other capabilities as well? ISSUE 16: Should the UIF specification [14] add registered UIF Profile tags so that the entire minimum string becomes a single named token. Lloyd McIntyre thought this would be a good idea in order to shorten the strings and make the processing easier by the Sender. ISSUE 17: Should we add the new "ippfax-uif-profile" operation attribute to the Get-Printer-Attributes operation and then REQUIRE the Receiver to perform attribute coloring for the "ippfax-uif-profile" operation attribute? Then the Sender could determine the resolutions supported for a particular UIF Profile without having to do the CONNEG stuff? ISSUE 18: What restrictions on the vCard content do we need to make? vCard can have image, logos, sound! ISSUE 19: Denial of service problem: a Sender could bog down a Receiver Job with a huge amount of data which the Receiver is supposed to copy to the Job object ISSUE 20: What restrictions on the vCard content do we need to make? vCard can have image, logos, sound! ISSUE 21: Denial of service problem: a Sender could bog down a Receiver Job with a huge amount of data which the Receiver is supposed to copy to the Job object ISSUE 22: Did we agree to delete the ippfax-sender-uri (uri) operation/Job Description attribute in favor of depending on TLS authentication? ISSUE 23: SHOULD be using a client URL by preference and NOT a MAC address (generally totally unknown to an IPP client application). In any case the IEEE and IETF don't approve the use of MAC address for identifiers anymore except in EUI-64 format (an IEEE standard), which is the basis for canonical IPv6 self-configured global addresses. Ira will look up the RFC references later, if you want EUI-64 ISSUE 24: Or should the spec be changed to REQUIRE the Sender to use Validate-Job? Currently the spec only RECOMMENDS using Validate-Job and REQUIRES that the Sender query a number of Printer Description attributes in order to submit a job the Receiver will accept. ISSUE 25 (for UIF document; see UIF ISSUE #4): Need to add the multi-valued profile parameter with 'uif-x' values to the image/tiff MIME Media Type registration and only have a single 'uif' value for the 'application' parameter (instead of 'uif-s', 'uif-c', 'uif-l', etc.). ISSUE 26: OK to REQUIRE the Sender to supply the "ippfax-uif-profiles" of the document being sent? What if the Sender didn't create the document? ISSUE 27: Need to fill in the TBD entries to indicate the IPPFAX semantics for the Job Template attributes. ISSUE 28: Are the entries in the Operations Conformance Table 6 correct? ISSUE 29: What does the 'tel' scheme do for IPPFAX? ISSUE 30: OK that we got rid of the new 'octetString32k' attribute syntax and use existing IPP/1.1 attribute syntaxes, so that existing IPP systems can be used as gateways? ISSUE 31: Is the description of this new 'client-error-missing-required-attribute' (0x0419) status code sufficient? ISSUE 32: Do the conformance requirements look ok? Need to register the new attributes and the new status code. Text TBD. ISSUE 33: Need version 3.0 of vCard, since it is an RFC, while version 2.1 is not. ISSUE 34: Is this example accurate? The phone number format seem wrong. ISSUE 35 (repeat): What vCard restrictions? No pictures, no logos, no sound? ISSUE 36: What other Receiver attributes should go in the Generic Directory Schema for an IPPFAX Receiver? ISSUE 37: OK that it is of abstract type printer? ISSUE 38: Should the concrete type be 'IPP' (since the 'ipp' scheme is being used), or 'IPPFAX' to differentiate it from an IPP Printer? ISSUE 39: Is the conformance right? ISSUE 40: Should we add authors to PWG standards like we do IETF RFCs? ISSUE 41: Should we add participants to PWG standards like we do IETF RFCs? 3. IPPGET Delivery Method (), I posted Monday, 7/23, at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf ISSUE 01 (see section 12): Should we use application/multiplexed (draft-herriot-application-multiplexed-03.txt) which can chunk mime types using content lengths, instead of multi-part/related, which uses boundary strings? ISSUE 02: For Event Wait Mode, OK to make each successive response after the first a complete IPP response, instead of just the Event Notification Attributes Groups? Then each response looks like a complete response with its own status code. Also complete responses might be necessary on some other transport. Also we can move the "notify-interval" attribute back to the Operation Attributes Group where it belongs, since it applies to all events being returned in that response. ISSUE 03: OK to clarify that the Per-Job Subscription Object and the associated Job object MUST persist after the job completes (job completed, canceled, or aborted) in the Job Retention or Job History phases (see [RFC2911] section 4.3.7.2)? Otherwise, a Notification Recipient that is polling would not get the Event Notification, if it polled after the job completed, but before the Event Lease Time expired. ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the underlying transport connect for any operation, including the Event No Wait Get-Notifications operation and the Event Wait Get-Notifications operation when the Printer isn't willing to honor the initial request or reneges in a later response? So a client could keep the connection open for multiple Event No Wait Get-Notifications. Before a Printer disconnects it needs to wait enough time to make sure that any IPP response has had time to get back to the client before disconnecting, otherwise the client might not see the response. ISSUE 05: OK to add 'successful-ok-events-complete' status code for a Get-Notifications response whether Event No Wait or Event Wait mode? Here is more detail: The Printer MUST return the 'successful-ok-events-complete' status code to indicate when this return is the last return for all Subscription objects that match the request, whether or not there are Event Notifications being returned. This condition occurs for Event Wait Mode Notification Recipients waiting for responses when the Subscription Object is: (1) canceled with a Cancel-Subscription operation, (2) deleted when the Per-Printer Subscription lease time expires, or (3) when the 'job-completed' event occurs for a Per-Job Subscription. This condition also occurs for a Get-Notifications request that a Notification Recipient makes after the job completes, but before the Event Lease Time expires. Here is a complete table of combinations of "notify-wait", "status-code", "notify-interval", and Event Notification Attributes Groups for Get-Notification initial (Wait and No Wait) Responses and subsequent Event Wait Mode Responses (which may be staying in Wait Mode or may be requesting the Notification Recipient to leave Wait Mode): Event client sends: Printer returns: Notification "notify-wait" "status-code" "notify-get-interval" Attribute Groups ------------- ------------- --------------------- ---------------- 1.'false'/omitted 'successful-ok' MUST return N maybe 2.'false'/omitted 'not-found' MUST NOT MUST NOT 3.'false'/omitted 'busy' MUST return N MUST NOT 4.'false'/omitted 'events-complete' MUST NOT 'job-completed' 5. 'true' 'not-found' MUST NOT MUST NOT 6. 'true' 'busy' MUST return N MUST NOT 7. 'true' 'successful-ok' MUST NOT MUST 8. 'true' 'successful-ok' MUST return N maybe 9. 'true' 'events-complete' MUST NOT 'job-completed' or maybe other Explanation: 1-4: client requests Event No Wait 5-9: client request Event No Wait 2,5: Subscription object not found, or was canceled earlier; client should NOT try again. 3,6: server busy, tells client to try later; client should try again in N seconds. 4: client polled after job completed, but before Event Lease Time expired, and got the 'job-completed' event, so the client shouldn't bother trying again; client should NOT try again later. 7: Printer returns one or more Event Notifications and is ok to stay in Event Wait Mode; the client waits for more. 8: Printer wants to leave Event Wait mode. Can happen on the first response (with events) or happen on a subsequent response with or without Event Notifications; the client should try again in N seconds. 9. Printer either (1) returns 'job-completed' event or (2) the Subscription Object was canceled by either a Cancel-Job or a Per-Printer Subscription expired without being renewed. For case (1), at least one event MUST be returned, while for case (2), it is unlikely that any Events are returned; the client should NOT try again. ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but this has no significance to the IPP semantics." Is this sufficient, or is HTTP/1.1 chunking REQUIRED in order to support the multi-part/related MIME type? ISSUE 07: For Event No Wait mode, should we add a way for the Notification Recipient to have the Printer filter out returning Event Notifications that the Notification Recipient has already received in order to reduce the duplicates (that will usually happen, else events will be lost)? Or should we just depend on most usage using Event Wait Mode, so that there aren't duplicates? It has been suggested on the mailing list that the Notification Recipient could supply pairs of the "notify-sequence-number" and "subscription-id" and the Printer would only return events with a higher sequence number. 4. Drafts TIFF-FX Extension 1 and Schema Extension 1 Lloyd McIntyre called our attention to last Monday, 7/23. As soon as it is approved we can add a Profile T (JBIG2) to our UIF document. Here it is important to send any comments to the Internet FAX DL () as well as the IPP FAX DL (; Mon, 30 Jul 2001 04:19:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6U7QCF09169 for ietf-fax-bks; Mon, 30 Jul 2001 00:26:12 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6U7QAs09165 for ; Mon, 30 Jul 2001 00:26:10 -0700 (PDT) Received: by bulls.mei.co.jp (8.11.4/3.7W) with ESMTP id f6U7PJB00735; Mon, 30 Jul 2001 16:25:19 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id QAA26089; Mon, 30 Jul 2001 16:25:18 +0900 (JST) Received: from [133.185.137.6] by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 30 Jul 2001 07:25:19 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id QAA05431; Mon, 30 Jul 2001 16:25:18 +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 QAA03643; Mon, 30 Jul 2001 16:25:18 +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 QAA08046; Mon, 30 Jul 2001 16:25:17 +0900 (JST) Message-Id: <200107300727.AA00035@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Mon, 30 Jul 2001 16:27:18 +0900 To: Hiroshi Tamura Cc: ietf-fax@imc.org Subject: Re: FAX WG agenda for the 51st IETF In-Reply-To: <20010728170245G.tamura@toda.ricoh.co.jp> References: <20010728170245G.tamura@toda.ricoh.co.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-san, Hiroshi Tamura wrote: > >> - draft-ietf-fax-service-v2-03.txt >> >> [Sent to IESG on June 23rd with Interworking report >> (published on June 18th); request to wait for publication >> until all dependancies are resolved - received AD comments >> (July 26th) for an update before IETF Last Call] > >Now, the editors are revising it. > >Toyoda-san, >please comment a little about it at our meeting. Yes, I will do. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Mon Jul 30 22:38:23 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 WAA12318 for ; Mon, 30 Jul 2001 22:38:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6V1kJ517253 for ietf-fax-bks; Mon, 30 Jul 2001 18:46:19 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V1kHs17249 for ; Mon, 30 Jul 2001 18:46:17 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id VAA18353; Mon, 30 Jul 2001 21:44:30 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id SAA02474; Mon, 30 Jul 2001 18:44:10 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 18:44:09 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A34C7@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'jpulera@minolta-mil.com'" , IETF - Internet FAX Group Cc: "McIntyre, Lloyd" , "'IBM - Ron Arps'" , "'ImagePower Steve Swift@imagepower'" , "'Ono Fumitaka - Tokyo Institute of Polytechincs'" , "'William Rucklidge 1'" , "'PWG - IPPFax DL'" Subject: RE: comments on tiff-fx & schema extension drafts Date: Mon, 30 Jul 2001 18:44:07 -0700 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: John, Thank you for your review and comments. Please see our response below. Lloyd -----Original Message----- From: John Pulera [mailto:jpulera@minolta-mil.com] Sent: Friday, July 27, 2001 8:11 PM To: IETF - Internet FAX Group Cc: Lloyd McIntyre Subject: comments on tiff-fx & schema extension drafts I have reviewed the documents 'draft-ietf-fax-tiff-fx-Extension1-02.txt' and 'draft-McIntyre-Feature-Schema-Extension1-00.txt'. Here are some comments for both: 'draft-ietf-fax-tiff-fx-Extension1-02.txt' Section E1.5.4: The document does not contain any recommended or required restrictions on placement within the TIFF file of (i) the first Shared Data Table and (ii) the Shared Data data blocks. Are the Shared Data data blocks allowed to span the entire TIFF file? Or should all shared data tables and data blocks appear within the TIFF file BEFORE any references to them are encountered in a TIFF strip? [LM] Thanks for pointing out this oversight. Our proposal is to inset the following paragraph between paragraph 3 and the NOTE of Section E1.5.4: Shared Data Tables SHOULD be ordered in the file in the same order as their ordinal number. The file location of each Shared Data Table SHOULD precede all shared data blocks referenced by the Shared Data Entries that appear within that table. Additionally, the file location of each shared data block SHOULD precede that of the data stream that requires its inclusion (i.e. the reference data stream). Section E1.6.1 Paragraph 2, Line (editorial) Change "Rational" to "Rationale" [LM] Done. Section E1.6.7 Rule #10 This rule not clear. Section 1.4.8 of which document is referenced? [LM] The 3rd paragraph of the draft overview, Section E1.1.2, states: "This document is an extension to RFC XXXX, as such it should be read in conjunction with RFC XXXX. Throughout this document, section number references without an "E1" prefix should be interpreted as [RFC XXXX] section references." Is this adequate or is there a desire that some form of this statement should be replicated throughout the document? 'draft-McIntyre-Feature-Schema-Extension1-00.txt' Section 2.1.2 line 1 (editorial) Change "Nine new T88Options coding parameter feature" to "Nine new T88Options coding parameter features" [LM] Done. Section 2.1.2 seventh bullet and throughout Appendixes A and B (editorial) Should 'T88Options-TextStipesMixed' be changed to 'T88Options-TextStripesMixed' [LM] Done. John Pulera ----------------------------------------- John Pulera Minolta Systems Laboratory jpulera@minolta-mil.com (949)737-4520 x348 From owner-ietf-fax@mail.imc.org Mon Jul 30 23:13: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 XAA13387 for ; Mon, 30 Jul 2001 23:13:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6V2Sm517850 for ietf-fax-bks; Mon, 30 Jul 2001 19:28:48 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V2Sls17846 for ; Mon, 30 Jul 2001 19:28:47 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id WAA27562; Mon, 30 Jul 2001 22:28:48 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id TAA03049; Mon, 30 Jul 2001 19:28:45 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 19:28:45 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A34C8@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Ryuji Iwazaki'" , "McIntyre, Lloyd" , "'Yoshio YOSHIURA'" Cc: "'IETF - fax WG dl'" , "'PWG - IPPFax DL'" Subject: RE: TIFF-FX Extension 1 Date: Mon, 30 Jul 2001 19:28:42 -0700 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: Iwazaki-san, Thank you for your review and comments. Please see our responses below. Regards, Lloyd > -----Original Message----- > From: Ryuji Iwazaki [mailto:iwa@rdl.toshibatec.co.jp] > Sent: Monday, July 30, 2001 6:19 PM > To: McIntyre, Lloyd; 'Yoshio YOSHIURA' > Subject: Re: TIFF-FX Extension 1 > > > McIntyre-san, > I have reviewed section E1.3. > In page18, > > d) The Section 7.2.1. "Baseline Fields" XResolution and Yresolution > > fields now read: > > > > XResolution(282) = 100, 200, 300, 400, 600, 1200. > RATIONAL > > YResolution(283) = 100, 200, 300, 400, 600, 1200. > RATIONAL > > The resolution of the image is expressed in pixels per > resolution > > unit. In pixels per inch, allowed XResolution values > are: 100, 200, > > 300, 400, 600 and 1200. The lossless color fax profile > requires the > > pixels to be square, hence YResolution SHALL equal > XResolution. Base > > resolution is 200 pixels per inch. > > There are no NOTEs such as page 17. > I think it is better to add the following sentense. > > See Section 2.2.2 for inch-metric equivalency. > > Is it needed to add the note which describes limitation of > combinations? Your are correct. Our proposal is to add the following note: NOTE: For inch-metric equivalency and legal combinations of YResolution and XResolution, see the two notes of Profile C YResolution and XResolution (i.e. the notes of item C above). > There is no such note in section 7.2.1 of RFC2301. A similar note may be considered. NOTE: For inch-metric equivalency and legal combinations of YResolution and XResolution, see the two notes of Profile C Section 6.2.1 YResolution and XResolution. > > > In page18, > > > +---------------------------+--------------------------------+ > > | YResolution | 98**, 100, 196**, 200, > 300, | > > | | 400, 600, 800, 1200 > | > > | | (written in > pixels/inch) | > > > +---------------------------+--------------------------------+ > > There is no value 391. > Please add this value. Done. > > Regards, > > Ryuji Iwazaki > TOSHIBA TEC Corporation > > From owner-ietf-fax@mail.imc.org Mon Jul 30 23:26: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 XAA13809 for ; Mon, 30 Jul 2001 23:26:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6V2hQn18088 for ietf-fax-bks; Mon, 30 Jul 2001 19:43:26 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V2hOs18084 for ; Mon, 30 Jul 2001 19:43:24 -0700 (PDT) Received: from earthlink.net (pool0438.cvx35-bradley.dialup.earthlink.net [216.244.13.183]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id TAA04626 for ; Mon, 30 Jul 2001 19:43:25 -0700 (PDT) Message-ID: <41200172312441340@earthlink.net> X-EM-Version: 5, 0, 0, 0 X-EM-Registration: #3003520714B31D032830 Reply-To: terryandlori@earthlink.net X-Mailer: EarthLink MailBox 5.03.42 (Windows) From: "Terry Stewart" To: ietf-fax@imc.org Subject: Suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt Date: Mon, 30 Jul 2001 19:44:1 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset=US-ASCII Hi All, Below are suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt. Terry Stewart ================================================================================ E1.2.1.3. New Fields, GlobalParametersIFD Field: The current wording regarding the GlobalParametersIFD contains the sentence: "Required baseline fields should not be located in the GlobalParametersIFD, but should be in each image IFD." The "should" in this sentence appears to be a suggestion only and a TIFF writer could place required baseline fields in the GlobalParametersIFD and still be considered a valid TIFF-FX file. This means that TIFF-FX readers would need to handle the cases where TIFF-FX writers decided to ignore the suggestion and place required fields into the GlobalParametersIFD. It is my understanding that the GlobalParametersIFD should never contain fields that would directly affect the rendered image (e.g. Photometric Interpretation, ImageWidth). Therefore, it would be better to enforce this by declaring that the GlobalParametersIFD must not contain required baseline fields. "Required baseline fields MUST NOT be located in the GlobalParametersIFD, but should be in each image IFD." This would remove ambiguity about the intended use of the GlobalParametersIFD and reduce the complexity of TIFF readers. Otherwise a tolerant TIFF reader would have to treat the GlobalParametersIFD as a type defaulting mechanism for required baseline TIFF fields since the GlobalParametersIFD would need to be checked when IFDs are missing required baseline fields. ================================================================================ The definition for NewSubFileType in Section 8.2.1 is: NewSubFileType(254) = 16, 18. LONG For Profile M, the NewSubFileType field has two bits that are required. Bit 1 indicates a single page of a multi-page document and must be set for the Primary IFD; Bit 4 indicates the MRC imaging model as described in ITU-T Recommendation T.44 [T.44], and must be set for Primary IFDs and all MRC-specific child IFDs. This definition allows Bit 1 to be on for MRC-specific child IFDs. I believe the description in Section 8.4 "Rules and Requirements for Images" clarifies that the child IFDs must not set bit 1 on, but it would be clearer if the definition of NewSubFileType mentioned this as well: NewSubFileType(254) = 16, 18. LONG For Profile M, the NewSubFileType field has two bits that are required. Bit 1 indicates a single page of a multi-page document and must be set for the Primary IFD and MUST NOT be set for MRC-specific child IFDs; Bit 4 indicates the MRC imaging model as described in ITU-T Recommendation T.44 [T.44], and must be set for Primary IFDs and all MRC-specific child IFDs. ================================================================================ E1.4.5. Rules and Requirements for Images The current description of multi-stripped IFDs for non-Primary IFDs is currently described as follows: 8. In MRC Internet Fax, each layer is transmitted as a sequence of : single Primary IFD as a series of corresponding strips. Without constraint on coding parameter changes, all stripes of the foreground/Background/secondary mask layers SHALL be stored in separate single-stripped IFDs. These IFDs are referenced by the : 10. When there are no image and coding parameter changes between stripes, a single multi-stripped IFD (i.e. each strip corresponding to a stripe) MAY be used to represent a multi- striped layer that! is not a Primary Mask layer. The phrase "Without constraint on coding parameters changes" in item 8 wasn't very clear to me. Recommend clarifying this area of 8 with the following: 8. In MRC Internet Fax, each layer is transmitted as a sequence of : single Primary IFD as a series of corresponding strips. When the image or coding parameters change between stripes in the foreground/Background/secondary mask layers these stripes SHALL be stored in separate single-stripped IFDs. These IFDs are referenced by the ... ================================================================================ Typos: E1.4.1 Introduction, last paragraph: "in-dept" should be "in-depth" ================================================================================ ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset=US-ASCII
Hi All,
 
  Below are suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt.
 
Terry Stewart
 
================================================================================
 
E1.2.1.3. New Fields, GlobalParametersIFD Field:
 
The current wording regarding the GlobalParametersIFD contains the sentence:
 
   "Required baseline fields should not be located in the
    GlobalParametersIFD, but should be in each image IFD."
 
The "should" in this sentence appears to be a suggestion only and a TIFF
writer could place required baseline fields in the GlobalParametersIFD
and still be considered a valid TIFF-FX file.  This means that TIFF-FX
readers would need to handle the cases where TIFF-FX writers decided to
ignore the suggestion and place required fields into the GlobalParametersIFD.
 
It is ! my! understanding that the GlobalParametersIFD should never contain
fields that would directly affect the rendered image (e.g. Photometric
Interpretation, ImageWidth).  Therefore, it would be better to enforce
this by declaring that the GlobalParametersIFD must not contain required
baseline fields.
 
   "Required baseline fields MUST NOT be located in the
    GlobalParametersIFD, but should be in each image IFD."
 
This would remove ambiguity about the intended use of the GlobalParametersIFD
and reduce the complexity of TIFF readers.  Otherwise a tolerant TIFF reader
would have to treat the GlobalParametersIFD as a type defaulting mechanism for
required baseline TIFF fields since the GlobalParametersIFD would need to
be checked when IFDs are missing required baseline fields.
 
================================================================================
 
The definit! io! n for NewSubFileType in Section 8.2.1 is:
 
   NewSubFileType(254) = 16, 18.                                       LONG
      For Profile M, the NewSubFileType field has two bits that are
      required.  Bit 1 indicates a single page of a multi-page document
      and must be set for the Primary IFD; Bit 4 indicates the MRC imaging
      model as described in ITU-T Recommendation T.44 [T.44], and must be
      set for Primary IFDs and all MRC-specific child IFDs.
 
This definition allows Bit 1 to be on for MRC-specific child IFDs. I believe
the description in Section 8.4 "Rules and Requirements for Images" cla! ri! fies
that the child IFDs must not set bit 1 on, but it would be clearer if
the definition of NewSubFileType mentioned this as well:
 
 NewSubFileType(254) = 16, 18.                                       LONG
      For Profile M, the NewSubFileType field has two bits that are
      required.  Bit 1 indicates a single page of a multi-page document
      and must be set for the Primary IFD and MUST NOT be set for
      MRC-specific child IFDs; Bit 4 indicates the MRC imaging
      model as described in ITU-T Recommendation T.44 [T.44], and must be
      set for Primary IFDs and all MRC-specific chil! d ! IFDs.
 
================================================================================
E1.4.5. Rules and Requirements for Images
 
The current description of multi-stripped IFDs for non-Primary IFDs is
currently described as follows:
 
   8. In MRC Internet Fax, each layer is transmitted as a sequence of
             :
      single Primary IFD as a series of corresponding strips. Without
      constraint on coding parameter changes, all stripes of the
      foreground/Background/secondary mask layers SHALL be stored in
      separate single-stripped IFDs. These IFDs are referenced by the
 
              :
  10. When there are no image and coding parameter changes be! tw! een
      stripes, a single multi-stripped IFD (i.e. each strip
      corresponding to a stripe) MAY be used to represent a multi-
      striped layer that! is not a Primary Mask layer.
 
The phrase "Without constraint on coding parameters changes" in item 8
wasn't very clear to me.  Recommend clarifying this area of 8 with the
following:
 
  8. In MRC Internet Fax, each layer is transmitted as a sequence of
          :
      single Primary IFD as a series of corresponding strips. When
      the image or coding parameters change between stripes in the
      foreground/Background/secondary mask layers these stripes SHALL
      be stored in separate single-stripped IFDs. These IFDs are
 ! &n! bsp;    referenced by the ...
 
================================================================================
Typos:
 
E1.4.1 Introduction, last paragraph: 
 
   "in-dept" should be "in-depth"
================================================================================
------=_NextPart_84815C5ABAF209EF376268C8-- From owner-ietf-fax@mail.imc.org Tue Jul 31 01:38: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 BAA22625 for ; Tue, 31 Jul 2001 01:38:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6V51Zr20381 for ietf-fax-bks; Mon, 30 Jul 2001 22:01:35 -0700 (PDT) Received: from icope.com (PPP-200-7-93.bng.vsnl.net.in [203.200.7.93]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6V51Js20376 for ; Mon, 30 Jul 2001 22:01:24 -0700 (PDT) Received: from avenger by icope.com with SMTP (MDaemon.v2.7.SP5.R) for ; Tue, 31 Jul 2001 10:00:25 +0530 Reply-To: From: "Ganesh Krishnan" To: Subject: T.30 implementation Date: Tue, 31 Jul 2001 10:03:16 +0530 Message-ID: <000b01c11979$eba39cb0$5e01000a@avenger> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE067A3495@mercury.ADOC.xerox.com> X-MDaemon-Deliver-To: ietf-fax@imc.org X-Return-Path: gkrishnan@icope.com Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, I just wanted to know if could get a T.30 protocol implementation from anywhere on the net. Regards, Ganesh Ganesh Krishnan iCOPE Technologies Pvt. Ltd. 111/112, 3rd Cross,1st Main, 7th Block Koramangala, Bangalore - 560 095 Phone : 5716909, 5716939, 5715213 Fax : 5716908 Visit us at www.icope.com From owner-ietf-fax@mail.imc.org Tue Jul 31 18:13: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 SAA26906 for ; Tue, 31 Jul 2001 18:13:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6VLJ3O12822 for ietf-fax-bks; Tue, 31 Jul 2001 14:19:03 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VLJ1s12818 for ; Tue, 31 Jul 2001 14:19:01 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id RAA19820; Tue, 31 Jul 2001 17:18:54 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id OAA20574; Tue, 31 Jul 2001 14:18:37 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 14:18:36 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A34D0@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Terry Stewart@earthlink.net'" Cc: ietf-fax@imc.org, "'William Rucklidge 1'" , "'PWG - IPPFax DL'" Subject: FW: Suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt Date: Tue, 31 Jul 2001 14:18:23 -0700 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: Terry, Thanks for your review and comments. 1. E1.2.1.3. New Fields, GlobalParametersIFD We do not believe there is much ambiguity as to which fields a reader needs to look for within the GlobalParametersIFD. First, the GlobalParametersIFD definition further restricts the fields by stating that the legal set is listed within TIFF-FX or a TIFF-FX extension. "Fields in the GlobalParametersIFD MAY be TIFF fields that are legal in any IFD. Only a limited number of fields are designated as belonging inside the GPIFD, and they are specifically mentioned by RFC XXXX or an extension when they do." Second, the "SHOULD" recommendation is considered very strong with potential interoperability consequences if ignored. It does, however, leave the door open for other actions should a compelling situation arise. The SharedData field is one example of a field that is required for proper interpretation of a data stream, yet it is located within the GlobalParametersIFD. If the TIFF-FX GlobalParametersIFD constraint were MUST rather than SHOULD, the TIFF-FX extension would not have been able to include SharedData. 2. TIFF-FX Section 8.2.1 NewSubFileType fields The NewSubFileType field definition appears to be clear enough, as each SubIFD is NOT a page, so Bit 1 doesn't make sense on a SubIFD. A reader could ignore that bit if it appeared on a SubIFD, without changing the meaning of anything. As you have pointed out, the Section 8.4 rules do clarify this further. 3. E1.4.5 Rules and Requirements for Images We agree with your clarification recommendations. The 5th sentence of Rule 8 has being change to read: "When the image or coding parameters change between stripes in the foreground/Background/secondary mask layers these stripes SHALL be stored in separate single-stripped IFDs." 4. E1.4.1 typos Done. Regards, Lloyd -----Original Message----- From: Terry Stewart [mailto:terryandlori@earthlink.net] Sent: Monday, July 30, 2001 1:00 AM To: ietf-fax@imc.org Subject: Suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt Hi All, Below are suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt. Terry Stewart ============================================================================ ==== E1.2.1.3. New Fields, GlobalParametersIFD Field: The current wording regarding the GlobalParametersIFD contains the sentence: "Required baseline fields should not be located in the GlobalParametersIFD, but should be in each image IFD." The "should" in this sentence appears to be a suggestion only and a TIFF writer could place required baseline fields in the GlobalParametersIFD and still be considered a valid TIFF-FX file. This means that TIFF-FX readers would need to handle the cases where TIFF-FX writers decided to ignore the suggestion and place required fields into the GlobalParametersIFD. It is ! my! understanding that the GlobalParametersIFD should never contain fields that would directly affect the rendered image (e.g. Photometric Interpretation, ImageWidth). Therefore, it would be better to enforce this by declaring that the GlobalParametersIFD must not contain required baseline fields. "Required baseline fields MUST NOT be located in the GlobalParametersIFD, but should be in each image IFD." This would remove ambiguity about the intended use of the GlobalParametersIFD and reduce the complexity of TIFF readers. Otherwise a tolerant TIFF reader would have to treat the GlobalParametersIFD as a type defaulting mechanism for required baseline TIFF fields since the GlobalParametersIFD would need to be checked when IFDs are missing required baseline fields. ============================================================================ ==== The definit! io! n for NewSubFileType in Section 8.2.1 is: NewSubFileType(254) = 16, 18. LONG For Profile M, the NewSubFileType field has two bits that are required. Bit 1 indicates a single page of a multi-page document and must be set for the Primary IFD; Bit 4 indicates the MRC imaging model as described in ITU-T Recommendation T.44 [T.44], and must be set for Primary IFDs and all MRC-specific child IFDs. This definition allows Bit 1 to be on for MRC-specific child IFDs. I believe the description in Section 8.4 "Rules and Requirements for Images" cla! ri! fies that the child IFDs must not set bit 1 on, but it would be clearer if the definition of NewSubFileType mentioned this as well: NewSubFileType(254) = 16, 18. LONG For Profile M, the NewSubFileType field has two bits that are required. Bit 1 indicates a single page of a multi-page document and must be set for the Primary IFD and MUST NOT be set for MRC-specific child IFDs; Bit 4 indicates the MRC imaging model as described in ITU-T Recommendation T.44 [T.44], and must be set for Primary IFDs and all MRC-specific chil! d ! IFDs. ============================================================================ ==== E1.4.5. Rules and Requirements for Images The current description of multi-stripped IFDs for non-Primary IFDs is currently described as follows: 8. In MRC Internet Fax, each layer is transmitted as a sequence of : single Primary IFD as a series of corresponding strips. Without constraint on coding parameter changes, all stripes of the foreground/Background/secondary mask layers SHALL be stored in separate single-stripped IFDs. These IFDs are referenced by the : 10. When there are no image and coding parameter changes be! tw! een stripes, a single multi-stripped IFD (i.e. each strip corresponding to a stripe) MAY be used to represent a multi- striped layer that! is not a Primary Mask layer. The phrase "Without constraint on coding parameters changes" in item 8 wasn't very clear to me. Recommend clarifying this area of 8 with the following: 8. In MRC Internet Fax, each layer is transmitted as a sequence of : single Primary IFD as a series of corresponding strips. When the image or coding parameters change between stripes in the foreground/Background/secondary mask layers these stripes SHALL be stored in separate single-stripped IFDs. These IFDs are ! &n! bsp; referenced by the ... ============================================================================ ==== Typos: E1.4.1 Introduction, last paragraph: "in-dept" should be "in-depth" ============================================================================ ==== From owner-ietf-fax@mail.imc.org Tue Jul 31 19:54: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 TAA05966 for ; Tue, 31 Jul 2001 19:54:22 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6VN6pU14386 for ietf-fax-bks; Tue, 31 Jul 2001 16:06:51 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VN6ns14382 for ; Tue, 31 Jul 2001 16:06:49 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.9.3+3.2W/3.7W) id IAA11186; Wed, 1 Aug 2001 08:06:21 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by azteca.isd.ricoh.co.jp (Mirapoint) with SMTP id AAW37607; Wed, 1 Aug 2001 08:06:20 +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 IAA10485; Wed, 1 Aug 2001 08:06:18 +0900 To: ned.freed@mrochek.com Cc: paf@cisco.com, ietf-secretariat@ietf.org, Claudio.Allocchio@garr.it, ietf-fax@imc.org Subject: Re: [IETF-FAX] Request for IESG Consideration on Service I-D In-Reply-To: <01K6DR6H9G30000UU5@mauve.mrochek.com> References: <20010623142541D.tamura@toda.ricoh.co.jp> <01K6DR6H9G30000UU5@mauve.mrochek.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: <20010801080931D.tamura@toda.ricoh.co.jp> Date: Wed, 01 Aug 2001 08:09:31 +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 Ned, Thank you for your comment for > > A Simple Mode of Facsimile Using Internet Mail > > draft-ietf-fax-service-v2-03.txt > > > Status: Draft Standard I have a small question, instead of the editors. > (4) This document has lots of references, some of which are normative and > some of which are not. (And yes, I'm well aware of the issue surrounding > the updates to the DSN specifications.) It would be really helpful if > you could separate the normative and non-normative references, making > it clear what needs to in place before this can actually be published. The I-D refers RFC2302(Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration), which is Proposed Standard, now. We have a I-D draft-ietf-fax-tiff-regbis-02.txt, which will replace RFC2302. It is being proposed as BCP, along with Draft Standard consideration for draft-ietf-fax-tiff-fx-09.txt. RFC2302 describes only the registration of the MIME sub-type image/tiff. Therefore, the working group agrees the status should be changed to BCP. My question is, Is this document normative or non-normative for draft-ietf-fax-service-v2-03.txt? Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Tue Jul 31 21:16: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 VAA12348 for ; Tue, 31 Jul 2001 21:16:53 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f710boa16030 for ietf-fax-bks; Tue, 31 Jul 2001 17:37:50 -0700 (PDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f710bns16026 for ; Tue, 31 Jul 2001 17:37:49 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id UAA12542 for ; Tue, 31 Jul 2001 20:37:51 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id RAA24320 for ; Tue, 31 Jul 2001 17:37:49 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 17:37:49 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE0BD77CB1@mercury.ADOC.xerox.com> From: "Abercrombie, Dave" To: ietf-fax@imc.org Subject: Suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt Date: Tue, 31 Jul 2001 17:37:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11A22.2D8EAD60" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11A22.2D8EAD60 Content-Type: text/plain; charset="iso-8859-1" I don't see an addition to the CodingMethods field for JBIG2. Looks like it should be bit 7. Dave Abercrombie aber@pahv.xerox.com , (650) 813-6811 XEROX THE DOCUMENT COMPANY Xerox Architecture Center Document Solutions Architecture Color & Imaging Solutions Group ------_=_NextPart_001_01C11A22.2D8EAD60 Content-Type: text/html; charset="iso-8859-1"

I don't see an addition to the CodingMethods field for JBIG2.  Looks like it should be bit 7.

Dave Abercrombie
aber@pahv.xerox.com, (650) 813-6811
XEROX THE DOCUMENT COMPANY
Xerox Architecture Center
Document Solutions Architecture
Color & Imaging Solutions Group


 

 ------_=_NextPart_001_01C11A22.2D8EAD60-- From owner-ietf-fax@mail.imc.org Tue Jul 31 22:42: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 WAA18448 for ; Tue, 31 Jul 2001 22:42:42 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f71266J17278 for ietf-fax-bks; Tue, 31 Jul 2001 19:06:06 -0700 (PDT) Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71264s17274 for ; Tue, 31 Jul 2001 19:06:04 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id WAA10584 for ; Tue, 31 Jul 2001 22:06:03 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id TAA25584 for ; Tue, 31 Jul 2001 19:06:04 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 19:06:04 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A34D6@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "Abercrombie, Dave" , ietf-fax@imc.org Subject: RE: Suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt Date: Tue, 31 Jul 2001 19:05:57 -0700 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: Dave, Thanks for the catch. I have added CodingMethods field to E1.2.2.2 with "Bit 7: ITU-T Rec. T.88 (JBIG2)," appended to the list of coding methods. Lloyd -----Original Message----- From: Abercrombie, Dave [mailto:aber@pahv.xerox.com] Sent: Tuesday, July 31, 2001 5:38 PM To: ietf-fax@imc.org Subject: Suggestions for draft-ietf-fax-tiff-fx-Extension-1-02.txt I don't see an addition to the CodingMethods field for JBIG2. Looks like it should be bit 7. Dave Abercrombie aber@pahv.xerox.com, (650) 813-6811 XEROX THE DOCUMENT COMPANY Xerox Architecture Center Document Solutions Architecture Color & Imaging Solutions Group