From owner-ietf-fax@mail.imc.org Sun Apr 2 23:02:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00621 for ; Sun, 2 Apr 2000 23:02:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA25886 for ietf-fax-bks; Sun, 2 Apr 2000 19:29:17 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25876 for ; Sun, 2 Apr 2000 19:29:15 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA12229 for ; Mon, 3 Apr 2000 11:32:05 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA11954 for ; Mon, 3 Apr 2000 11:32:04 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id LAA02270 for ; Mon, 3 Apr 2000 11:27:05 +0900 (JST) To: ietf-fax@imc.org Subject: [IETF-FAX] Addition to Adelaide meeting (ITU-T issue) X-Mailer: Mew version 1.94.1 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: <20000403113630Q.tamura@toda.ricoh.co.jp> Date: Mon, 03 Apr 2000 11:36:30 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 73 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, At Adelaide, unfortunately, we had no time to introduce ITU-T matters, which were scheduled. As I said at Adelaide, I introduce them briefly, here. Specifically, for our plan for ITU-T, any suggesions are welcome. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------- Begin ------------------ 1 Report of SG8 February Meeting 1.1 T.37 There were no proposals at the meeting. IETF-FAX WG draft charter was introduced. Q4/SG8 confirmed the cooperation between IETF-FAX WG and Q4/SG8, and agreed to continue it. Q4/SG8 proposed the plan for T.37 extension. The plan was as follows. - Support for Full Mode enhancements - Support for new image compression capabilities - Support for new image transmission capabilities - Support for Group 4 - T.37 Gateway functionality - T.37 over mobile packets networks - T.37 quality of service But Q4/SG8 did not discuss them in detail. 1.2 Re-organizing SGs in ITU-T February SG8 meeting was the final SG8 one in this study period (1996-2000). ITU re-organizes itself every 4 years. There is a WTSA(Plenary conference) in October. According to the results, SG8 will be merged with other SGs. Anyway, Q4/SG8 will continue as one of questions in a re-organized SG. 2 Our plan for ITU-T 2.1 Notice of our WG Status and other related matters IETF-FAX WG has started again. So, I believe it is necessary to notify our WG status. The items are as follows. - Our fixed charter itself - Discussion matters(e.g. Internet drafts) - Other WGs information 2.2 Input of Internet drafts We have the four Internet drafts that we should consider to input to ITU-T. But the three drafts related to FFPIM are not TECHNICALLY mature. With regard to Implementers-draft, it is an informative one. In fact, there are some issues that we should modify. But this draft is meant for Simple mode and Eifax, which we have already made. I believe it is better to input to ITU-T, because the contents are very useful for T.37 implementers as well as Simple/Eifax ones. 2.3 Can we agree to send a letter and one draft to Q4/SG8 ? Q4/SG8 interim meeting will be held in June. Can we agree to send them there ? If agreed, I will write a draft letter and circulate it here. -------------- End ------------------ Again, any comments are welcome. -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Tue Apr 4 21:32:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21294 for ; Tue, 4 Apr 2000 21:32:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA08799 for ietf-fax-bks; Tue, 4 Apr 2000 17:55:40 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08795 for ; Tue, 4 Apr 2000 17:55:38 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA17635; Wed, 5 Apr 2000 09:57:56 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA18436; Wed, 5 Apr 2000 09:57:56 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id JAA02407; Wed, 5 Apr 2000 09:52:53 +0900 (JST) To: paf@swip.net, moore@cs.utk.edu, ned.freed@innosoft.com Cc: Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: [IETF-FAX] Summary at Adelaide meeting X-Mailer: Mew version 1.94.1 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: <20000405100225A.tamura@toda.ricoh.co.jp> Date: Wed, 05 Apr 2000 10:02:25 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 46 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IETF FAX-Ext Group meeting was held on Thursday. New co-chairs introduced themselves. This is the first meeting since new-charter was created. New charter was discussed. The group confirmed to continue the study of the specification that is equivalent to T.30 service. Onramp/Offramp gateway issue were not discussed so far, so, there are things to do for this issue. Other matters related to the charter was discussed. The status of internet drafts wating for Draft Standard was introduced. Concerning draft-ietf-fax-tiff-fx-04.txt, there are no problems and ADs will review it. Concerning draft-ietf-fax-service-v2-01.txt, draft-ietf-fax-faxaddr-v2-00.txt and draft-ietf-fax-minaddr-v2-00.txt, there are dependancy problems and enough interworking report are not ready. We had reviews for the following 4 drafts. draft-ietf-fax-ffpim-00.txt draft-ietf-fax-timely-delivery-00.txt draft-ietf-fax-content-negotiation-01.txt draft-ietf-fax-implementers-guide-01.txt The three of them are related to full-mode, which the group are considering to be close to T.30 service as much as possible. There are some issues to be solved for the mechanism. Concerning the guide draft, this is mainly meant for RFC2305 and RFC2352 implementers. There are open issues for MDN disposition-type and Tiff attachement/body content. Tiff-fx extensions were introduced. The extensions are MRC N-layer, JBIG2, annotation, and so on. Concerning Fax Gateway issue, new proposal with the use of HTTP and CGI was introduced. The group confirmed the discussion should take place in both Fax group and Enum group. There was no time to introduce ITU related matter. One co-chair promised to circulate this issue in ML. The meeting finised. -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Wed Apr 5 03:52:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06925 for ; Wed, 5 Apr 2000 03:52:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA15180 for ietf-fax-bks; Wed, 5 Apr 2000 00:21:23 -0700 (PDT) Received: from mx.toshibatec.co.jp (mx.toshibatec.co.jp [202.215.2.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15176 for ; Wed, 5 Apr 2000 00:21:21 -0700 (PDT) Received: from cn.toshibatec.co.jp by mx.toshibatec.co.jp (8.8.8+Sun/3.6W TEC mailserver) id QAA29094; Wed, 5 Apr 2000 16:23:58 +0900 (JST) Received: from president.rdl.toshibatec.co.jp by cn.toshibatec.co.jp (SMI-8.6/3.5W TEC master mailserver [99/10/07 13:34]) id QAA27436; Wed, 5 Apr 2000 16:20:45 +0900 Received: from rdl.toshibatec.co.jp ([157.69.214.251]) by president.rdl.toshibatec.co.jp (8.9.3/3.7W-99041822) with ESMTP id QAA04085; Wed, 5 Apr 2000 16:26:38 +0900 (JST) Message-ID: <38EAEB3F.F758B39E@rdl.toshibatec.co.jp> Date: Wed, 05 Apr 2000 16:29:03 +0900 From: Ryuji Iwazaki Reply-To: iwa@rdl.toshibatec.co.jp Organization: TOSHIBA TEC Corp. X-Mailer: Mozilla 4.7 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: Hiroshi Tamura CC: ietf-fax@imc.org Subject: Re: [IETF-FAX] Addition to Adelaide meeting (ITU-T issue) References: <20000403113630Q.tamura@toda.ricoh.co.jp> 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 > 2.2 Input of Internet drafts > > We have the four Internet drafts that we should consider > to input to ITU-T. But the three drafts related to FFPIM > are not TECHNICALLY mature. With regard to Implementers-draft, > it is an informative one. In fact, there are some issues that > we should modify. But this draft is meant for Simple mode and Eifax, > which we have already made. I believe it is better to input > to ITU-T, because the contents are very useful for T.37 implementers > as well as Simple/Eifax ones. > > 2.3 Can we agree to send a letter and one draft to Q4/SG8 ? > I agree to send them to ITU-T. I would like to solve the open issues in the draft through discussion on this mailing list. And also I would like to discuss about three drafts regarding FFPIM. Ryuji Iwazaki TOSHIBA TEC Corporation From owner-ietf-fax@mail.imc.org Wed Apr 5 07:10:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08224 for ; Wed, 5 Apr 2000 07:10:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA21733 for ietf-fax-bks; Wed, 5 Apr 2000 02:43:06 -0700 (PDT) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21729 for ; Wed, 5 Apr 2000 02:43:02 -0700 (PDT) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 5 Apr 2000 10:46:26 +0100 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2C7NQXAT; Wed, 5 Apr 2000 10:46:01 +0100 Message-Id: <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 09:50:31 +0100 To: iwa@rdl.toshibatec.co.jp From: Graham Klyne Subject: Progressing content negotiation, timely delivery Cc: ietf-fax@imc.org In-Reply-To: <38EAEB3F.F758B39E@rdl.toshibatec.co.jp> References: <20000403113630Q.tamura@toda.ricoh.co.jp> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_4772692==_" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_4772692==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:29 PM 4/5/00 +0900, Ryuji Iwazaki wrote: > > ... But the three drafts related to FFPIM > > are not TECHNICALLY mature. >I would like to solve the open issues in the draft through discussion >on this mailing list. >And also I would like to discuss about three drafts regarding FFPIM. I agree. Further, for key issues relating to the content negotiation and the timely delivery drafts, I note that there were some additional slides that I did not show in Adelaide at the end of the presentation sets used. I assume these will show up in the proceedings for the IETF meeting, but I also attach them (in PDF form) for present company. For content negotiation, see the slide headed "The big issue: receiver state management". For timely delivery, see the final three slides headed "The unresolved challenge" and "Strawman proposal...". I would welcome discussion of the matters raised there. #g --=====================_4772692==_ Content-Type: application/pdf; name="f-conneg.pdf" Content-Disposition: attachment; filename="f-conneg.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KOCAwIG9iag0KPDwNCi9MZW5ndGggOSAwIFINCi9GaWx0ZXIg L0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAMRBAoEcjOIAaNhgLhyNhAMhuLhnDhuMoWMhoIBqNI vGTkZRAZgaQioDRiOBmLhxGRoNxqLhsOBAICoRAaMBBOJxBoQLyNOInMypIoWMBiMBrQjHORcMBs MaTNDuIBQQzebjoZawICcZTObzoaTDYavITechARjCeBTNDUDRaMhiLhiMhBcZeObtNCIIJ9BBzD L3Q5vTRpMppS5xUqoPDIcjCZjoLTSZToZhaZrWLTHV6zWBabq9YLFZDcLRhCzoeDoPraVLeLRiNh cNYcLaeLsHfZ9OIxQqJTRqMsQVKXqBdh8PQqmKCmbzbIK+YTYcx1r7fOBaMxptYdfJzSvDjBQXBk Mhr2Ab5+945rTNTQcT8Bp9eZVCdZzb1BAYjKNAwjsNI3jqtA7jSOg0BAs4yDSNwwjkPIQDKFr9jS Nj1LiGT2u27oZt29zFPu8rzvStz1w22z3L6oq6vE5CLIy8j8hA8wZBmMIyDbBw0jmOjILCOyQDcq 8KjKOY5jCM8jxsGkMvZFUOva8DFuM9zmxtEzYRQ9sqxYpoZhvGUrRgGQczG5orrONYQQPBIQDHAq Pq2OY0jaOA2QoEAwjcMkJtYrQyDKMgWvU7T0MEoS+uQ1IbBy8Sio3R7yDaN9BJCtYQDmPMfDKNo5 yfFLbu5Kb3yrETySy9UoIdLy7xa78rKKG00KoKQys7IUIpCOToU0OjqJAMYwjGNFBzgMI4DCMULw QPNDLvRCY0VEMrqpBwzP0scBjdUMOVJFUqPFEj0VXUUVvgqDBuOi4YIrEYoDfJA0jFPIQDYN47yN Std0FAQxpBO08U8rVgNM9QipKgINCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2JqDQo2MjINCmVu ZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2Vz IDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YxIDcgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBS DQo+Pg0KL0NvbnRlbnRzIDggMCBSDQo+Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwNCi9MZW5ndGgg MTQgMCBSDQovRmlsdGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqADEQQKBHIziAGjYYC4cjY QDIbi4Zw4bjKFjIaCAajSLxk5GUQGYGkIqA2IDkXDiMjQbDSUjgQCAqEQGjAQTabQaEC8jTaJzEq SKFjAZjmMzIxiAWxcYDejlQ7iAUEM2G85mk3Qc6GiQVU3nAUzI1A0WjccC6MUocWcaw6ZEQQTwZQ 8YxK3UGyUMb06gUmbTKoigpmU3GQynKwlSxxOXW2b0C4UsXDCiXOkVIpGUxmU0nbD4mxkWS3UbTC og2BEqEQI1QicY8pEeEDKJi4Yw4ZjMZbaHG3Z7XbwPbi6WiA2Qgp78bbyBjDljCYb6TDS6jSMjHh 8XjyYZwu18Ll9rlcwY87JzDt8nucvgjkai4a3PpRjq9fzdDjb/vTDy8/0PG9r3vi/IGvUhYaNM1z 4BguaFhrBibwWuadJMGr3twGL3hi+TZhqGa0BAGYYojAbthqHC6wG7qOwIGobuWisQhglz8RMHLS IeHKzxqhEXIcGSjRbFC0JhICIw3AgZPihkMN3GLtyVC8Qwy2y5u2MQVNQgctwoGYaQ0ubcw/JDpS 8lyMxElzvxMyiXxk5aGxaGEcN097rQJL0wRC3MqwIM0spImqGR0G6lKHB6HUO50IhzQkQy+4kppQ 0qgDamrHpyg4Gp4GaBuWmCZKEyYYpYvtDSqGgcqAwLBsKECsDSOg0jC442jKOY5jCM4ytABrRUFB 8GwlCNghBCkTpQuYZJatCMukGsb0jZbdx4kwbQ+GUipYF0ESS0r4R+GkPp/KElzijCIzvKFvvxJU P3U2drsmjKMUnFtop/ZdPv+BtkRBZaXLTK8soJLlNN0lEBohGjooQ3MWSjSMTBjD6VIfZk44m3bv 2zbE8SA+FlKc88/UAkqF0aHFC0UhzJBhRFGUdh4XRjZaFuKmVLNfTMFMoGSBMuyTsNpVbMDKOI61 uOgQVoOjDjcMNZM8EAyaiMNe1/gqC00GIcPfbKHhpdNnNXr2aR/B9wQJrrl27d1uIy7euojSklP9 tYcJRJElLPbu5WjsGbOJuLVhzD4c2UG1qX4GKGolxMPxLwtk4vgPCJNBnH8rbl+Itr/N4E2boZJZ fIys2by5pxPFyTik+8E8STSpwMT851s4bRu8oa65m33h2Sz45tLHd3vVlbFuHW+DbU1eV3rqIZ0/ Zdwh6i3n1uvyK2vY5/MdlS91XWoXms+RnJPR3bEWJdFz7aP387dt16ub8vxvKfdN2/uX+TaRxv7h 3voffM38urgXwJPbK8Z6p4X6sqOI9olEA2yttW0XVxDeD3ovbC81uTZnAvId+lgkZoyjO9es+Yt6 lzXoULkQ8thdyRMuKKU8vzRQUAxawydYaDkIQ8QmppiKP3XG9Q6x5n8FEhIpLm40s7GUeovfCRZj a90cONU+i2DTjUnPSRPAU/h7iUuXSUbtc52EQLlSk919YDYRNaWMwcG0FnvvvTKQpJhdDduxQQww h55nLx7JSQ8jD+WHRxei/OQgDU/wjUEylQrLmYMsZiypELiluF0boqAKjOlMRvJ2EZTpw5NKiTmh BoJC0Nsvhsq0MjTA2NODk1BqSvCxK+h0sWHyxEILHbyiA28ZIiL9WiQ426DiHLrWwfxSD0llwvIG 9Biy5ZgTPPZMdeKOz+A1jkt6AR10EOaRsXUn5t0pIml7EuS0To2MES21thzozvojRwmUGBKGLIZX HNZfr4C0m3TOi1PiA2usbX4d15ZAwbv+IRItQLKFHSSkgouh0lERELfkhlvqlYVGPQoX8KhSWhHl BrDYIYbw3BmDSHI3wdVchiDYSBqjVljGaM4Z4MkOUtMFQo4pOx13HMNISkqB5A1G1DO24ptsfTdv EIQ4pukfaeoEcUslIpTYw1SfUncixKINVHT4xZn59asRIZ/QSrBKF8xDqkDQ3bbnXTRqapCtKH59 EtLOWmssiQbNpY5GZ39e5kx9q5XVCy/6rVwISi517L3k1Hdq/xzNTLEwRp8pNfle6qVEivY6ylRI AVSsfEtaMErEpHiWWuS9jnPtstBYFrrFXL17ffQO1Nca7nXBwyiutcpiW5WbWutp/Lc1nLsQO3zo SEm1W6123VWLYXGrbVisVr6r1HZA2C1l1qntdozdapLjS62kp5UNxtn7rVRitIFgcjFrkuovagp5 NGdyeU2EZZUzlQl5MnDNU1HjAgypxG5CjXXszUOYdLAjZ5n2dg7EhDM24OyZIGRu9UCU+oZepARI mE4FP/kPMXCpqHHUXcU2uos6JppQcziRj2KrVzpn0RabCnpmOpRjiBzrrkkIZw66jAuGI7u7eohm DjqCznBwfId3dB1SYMdRApUk1XnTxXFhvJZ5COW1enHdihEau4+w2xQ965HUPeIGnzGr44lvqck5 jGbFKLTMsZEtkGMcV50rRPp+0vs64mf3mvOOJrPsUiViaL2Z8W4Wx2DPMeeoHKUy7grBrtlSIHgx gpUlgYO4/W2cG9agXGkuyQDNEhliZ0bZ4A0FAM8A1DNOQqjJuTdnBOlrCS52IGIEPVrY+zd9axDP 4dm2JRML7Cqk6PXrJD01N2QCCMCA9f10P4fey+xMd7U2PRnZ70j1EBANCmVuZHN0cmVhbQ0KZW5k b2JqDQoxNCAwIG9iag0KMTkzOA0KZW5kb2JqDQoxMCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQov UGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YyIDEx IDAgUiANCi9GMyAxMiAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgMTMg MCBSDQo+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwNCi9MZW5ndGggMTcgMCBSDQovRmlsdGVyIC9M WldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqADEQQKBHIziAGjYYC4cjYQDIbi4Zw4bjKFjIaCAajSLxk 5GUQGYGkIqA0ZDgcC6KiAaDYaC6UCAQFQiA0YCCbzeDQgXkabxOZFSRC2FjAYjIc0ExziJRikzM7 iAUE84HQ0m00noymQQGMwnMyimZmoGi0cRGjiCzSkaw6ZkQQT0ZQ8YxK3UKy0UbjeMzOlzeoVIpm U3GQynKxFSyROX22cUG4UQXDAYDO536pFIymMymk7YfE2QiyW6jYcCCog2BEqEQI1Qic48pEeEDK Ji4Yw4Z5bcQ427Xb7mB7kXS4QGyEFPgDbewMYcwYaffyYaXUaRkY8TjciTDOFzHs8zt8vmjHn5PT 9zld3mcIcjUXDW59OMdbsefo8fgd/T+boPS8j3Pg+T9Aa9aFho07UoWGoYLnBkHKZBq5p2kwavg3 QYvgtL6BqGYXLmGYYojAjuBqHC6wI7yOwKGobuYlbvJe/MTBy0qHhylMaIRFyHKQjMTRREDTqQtC 5u4GT5IZDIZJVI7awu4oQRFDcngaMQVNUgctwqGYaSrKbdtw+aES8l6MxEl6YxMyiYNO7zmIbFqj Skyz4OvAsvTA3cPrS7gzSykibIZHIbrUosGodRDnqYHNCynL86hiHLitOmY2psx6dIOBqehmgbmU svCihilqlUPMYaKeKiohQwbChANI3DSqwwuQNoyjmOYwjOsKxga0dBwnCUIwhClORPSi5hkl0QIy 6YaxtKVmSbHaTBtD6ToeloXQTAtmLZHwaQ+oEkSVOSMIjPEkNM9CHw9bsgNrbDJoyp0pRquqgWZU MAAbZMQIfZqMQLLEtIIEEuujNyHhvPsyAa71KBxeyNuLeV/y9Z2BPgHMrQ9D8CJOl7hO47yUpiiG HwLQCRpKhdHLOpgYUTVGaUZmFHxEhbLXfSjTKDTDY022FTsk7OaKDVohjeNwzDSOTfjrXYxDYkAQ DIMI6DDhLNs6z4yNDYDSS2gtOBiHD4W1dN4hA6e0PhF93wYhzubQ5lvSTD91tas9K3e/8C7RSi0y SlNvbtaW1oVi/BBzD+PYFat/Um5me2ZkMrUnZWBJfgkkQcpvO27fyLbV0fPtrhb88w+MrBk80ncl d0kBjldmIW8aTQ1Id38P0riXQtvaNrtDm71tva5RIkGvjuvi8JZYaXVjHYeXbc1W/4zhPqhnX+DH wZ0oGHq95tbb912Hb40lfaoWlbbQ/8lv9XIkRXx1XTts/n6Sby53nGuJc4/thjiXLLLfu881Tj3v EPTE/NxJdXzkvfa316MDjxMYbQRFoBtnxwaBw3hIh1YGt2bSSpcT2YTNqhG9RgqgTSA5ZI+GD5kF MmxQqXIh64SglDKK+IvoVC/tKKkDNsSwTSoKIQQpw6YUmnCOnExbpw4MoFPXFI+7gYou2b+eGAMS zKpjipF8hLC4svEQNGCJp73XNuiXFxoB/o0EKZXHJa0WAQRsRKckhBAQDQplbmRzdHJlYW0NCmVu ZG9iag0KMTcgMCBvYmoNCjExMDINCmVuZG9iag0KMTUgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0K L1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMiAx MSAwIFIgDQovRjMgMTIgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDE2 IDAgUg0KPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8DQovTGVuZ3RoIDIwIDAgUg0KL0ZpbHRlciAv TFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgAxEECgRyM4gBo2GAuHI2EAyG4uGcOG4yhYyGggGo0i8 ZORlEBmBpCKgNGY0GwuHAgGg3GouG0rEBUIgNGAgm83g0IF5Gm8TEEzkULGAwGIyoJUMc4pJ3EAo IhlOhhNJsOYurApmZqBotGI4GguGErFoyl45pEzIggnsEHMMtJUodiGkypVPHhkORhMx0FppqRmF pmMJ4FpjN5uOhlxQtNxlM5vOhpMOTxItoouOh4Og+rRUrlelI1hwtGwxF1xtc9m8YpNDpNLFBcGV mz9c2ou0lMtQgzFiGIwGexp5TxhkMpyHW3BoxGYuGkZssRh291kDu1zGEV4mz2o25lf3k0nHAGY1 4lE2vomdOFBNIhOEEfOJ1MpzOggN5wyxuEA0jcMg0jGyr7hAMI7KoNgwjEqo0joPL9DNA42MWOQ3 MqNI7Pu5ivLIsy4KStaiO4malpu9qntoGTwK25qVxQ8j1BquKlt+2q0Kap4hsSxbGjDCrkwwycNh 0EA0DKMLkDkOb/wDAcCwpC0hw0kAzSSOg6o+OcOo23wZhklS7NWnyHoyoSbPTHTvNtFzct3GMRrE GTnO6KQyjGMsquU8Lnui3yIJhES2TK8U0RJGsVO+8MYUGoiJzOu8bo5SL3R4xTGPzAQ5jgN45weN LEv0/lQv9AEBQIxcmjgj8ro+N08pCN45OYm6vLemNBt+ooZuHEzxvdIEpwzDcOvEsqztU8rt0TNk WtBF7xzk4QcUTSbazXO88z2EECDhBkHMnA1WDeOw0uQMgQDvB40BA+D5S3To3DmMsuulMExUG67X UPNUUzYGrmTeh04t8ojg18u4UONALkuXFznOg6VAuq8jr0MuSbLFEuFRXZ6uPFgtHhoHLiRuGYcZ Lf7jDZPA6SbYUhWJK1ZjayoQDEMN6XTUSP23DY5RWGUm29cA2VBDkXCKkqAgDQplbmRzdHJlYW0N CmVuZG9iag0KMjAgMCBvYmoNCjcwNQ0KZW5kb2JqDQoxOCAwIG9iag0KPDwNCi9UeXBlIC9QYWdl DQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0Yx IDcgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDE5IDAgUg0KPj4NCmVu ZG9iag0KMjMgMCBvYmoNCjw8DQovTGVuZ3RoIDI0IDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0K Pj4NCnN0cmVhbQ0KgAxEECgRyM4gBo2GAuHI2EAyG4uGcOG4yhYyGggGo0i8ZORlEBmBpCKgNGQ5 iI4jI0lUSGQgEBUIgNGAgms1g0IF5GmsTmBUkULGAwGc/Mc2FwwGw5n53EAoKhokBCNMHJJzOZ1M o6FMxNQNFoxGI0hkOFozHAuHA4n5EEAtoQ3HNsmNHhY4G4xuhUpwoKRlMZlNJ2MpyEBzOhhOkgNp hNxhM5lNplNx0rpUr9nGwuitvGoypN7t07jN6n9Bo02ptPLgyGQ1y9f1wuGsOmsxtwoK5pOhoEBh EB0ORhMm8NJvx5skJhPAgxpjNBpN0g5BsPIg5GMMtYyBl2M0t4xHIuGkZ3FPMeOEBikEfwODMpk3 5035u650NOTF0/NB1OYWOCqTfjaN46sq76arC8YbNEp43jMw7EsWEDpDMN45Ma/DkOcMLpMS6T4v W+8BPcwTCDlBDwvG8q2qeNI5vXAo3DI+IXO+FrZtqt7XoYl7zhQ1rXu/HLbRaFAkwg4Dnui6cKRg MI2I+4jrxKwbpIPJTtjm7oWRTBTyPMmSnscN7esLDjoRAw78jg6wQMiOknhAEQxP8PIRTWM7ky88 QXQZIwuBQ9j0v87TuMjCLFJBF8YwM+Q6DeEAxuQ6Yxw0N0+RXMLcjGNI5DGOreUSxYuBTGyvLBIk dhrHtANc2FUVU28xBQKApCeKAnimIImB0mDgSrE8nBAj441Cj9H0ixsPQ7TFUQTPsWR+xFFODSNJ jbNoywnMwQOmM8yjSxTjjcEA4DkN7AqxU7MVS0EdRwzYYodH8g1hdtZSMIQqipXw0whMyP2GN1lM lC770jKA2DepzpqcydDu9Z8VTBI1qW5SL2QjC8QwswzgYdCg3WxK7vioFSn2/cNxuRAFu2DM703K M2FBaMQwjGNdrUzP0GhQMo8MXGcQwJGgQDu3g0QK+g0DCO0r2sEGlDY+THOvAiP55aVaYuMr9hAJ Nyt7Rg7jCPMARoOaqumOUYZkEA2PzUUzZNlAUUgxLlDDAkDPpB9Ru1rDr3ON+n7VDdAjCrA6jbkt UZO9DkWoyrsMMMUZRo+Wu3NM+IS2yNS3Yr4ipKgIDQplbmRzdHJlYW0NCmVuZG9iag0KMjQgMCBv YmoNCjgxNg0KZW5kb2JqDQoyMSAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBS DQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0Y0IDIyIDAgUiANCj4+DQov UHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAyMyAwIFINCj4+DQplbmRvYmoNCjI2IDAgb2Jq DQo8PA0KL0xlbmd0aCAyNyAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAM RBAoEcjOIAaNhgLhyNhAMhuLhnDhuMoWMhoIBqNIvGTkZRAZgaQioDRmNBsLhwIBoOBpEhkIBAVC IDRgIJvN4NCBeRpvE5kVJELYWMBmModMzHOKCdxAKCKeDCbTgbDKKZmagaLRiMJiLRmOJVK5mRBB RBcMBjMaVOLTLqbTySbjSdDSYTYIDaZTmczCZ5AczKbjJWCpWq4MJeNoyLY2LorQbNPYyMRnDLZQ ptaZbQaXN5nThQIB1hq1N64NYlSZpTyIaTmcDec7qaTebhaTjfdjMaTGYbttxaVDeOhASjCbjKXy ngzIZTkQDQdcALjGbzbpptZxjqrXktdsNltODuN1vN9wNtuCecPKc9LWQaVBVT5kQTYdOgbvUdjK FowjsMI0jYMIxKsHo3vc9a8BYLcHjxCIuwm7TUBmjrwNG0kKu47zMrMFAhtu/Q3DoFozDK4A6o++ DtPo+yZBALgUBNGQUOuNg3jkHohDS/g5DyLisRmNI2r+/7eqsFo5joOQ6jGOkVjKHoqCSIwjBaNs fSKvEhRc+sNRimUZjIOA0h6iwYSFG0yjSFo8DyOT1DeHoYzXIkjMAFrrjJHwzh6JokTuFAmikIcs je54ezUFMvxhMUbDgMI4OhJY0j1KYghpQY6jDLIyz6MIeyZOblSBO9GvlF8QxGwcTLw/Q5P4uz/P iw75zBMUZxrGccR1HkfDDU8hhRLk9SS/8mSdKEpSpK0sDZIq61BL1VVzSE2TMHqOUZbM3ThOTgzr atb1XbEbWM/8+T9QFC0HQtDjbRMp0ZR0w10FFJUoOVLUwHtNU5Ty91DUY6VK6EgyHVNy1zWytCKk qAgNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNyAwIG9iag0KNjMxDQplbmRvYmoNCjI1IDAgb2JqDQo8 PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQov RjAgNiAwIFIgDQovRjQgMjIgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRz IDI2IDAgUg0KPj4NCmVuZG9iag0KMzAgMCBvYmoNCjw8DQovTGVuZ3RoIDMxIDAgUg0KL0ZpbHRl ciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgAxEECgRyM4gBo2GAuHI2EAyG4uGcOG4yhYyGggG o0i8ZORlEBmBpCKgNGY0GwuHAgGg4GkSGQgEBUIgNGAgm83g0IF5Gm8TmRUkQthYwGYyh0zMc4oJ 3EAoIp4MJtOBsMopmZqBotGNGhkxFozHEqlczIggoguGFGGdBpdFG41tszpwoJJuNJ0NJhNggJpE Jwgj5zOBvNxzq9ZrcNF0VtEbxsxswgnsZGIzr9BkVFltupl0p4gHVYKlam9cGsSpM0p5ENOEN5zv Jpww6EBhOp0N5tMN6MYtMJjvWGF9/JwtxBuOnA3O73ppMd8Nh5Hek01oGOpGOS1gomXf8HgMhlqx 0MpkF988xyN3POxlFpwj5mMpyj5k6wNKgqp5N869haIIxjGMo4OWIwyt6OrBtGxT9tC74uBQEwQQ kMY3jYN45B6IQ0vaOQ8i4FL8we7zwwqFA0t4M74DMNKrOQOg5Dq4UFjKHoqCSIwjRFEj+RM8MJD5 FEKQkMg4DSHqLBhEUUSONIWjwPI5OeN8lLWF6uyYrEewdH8TvBCUihRJ8ry3J0kSjKcqh6GMmy60 r9S/MCZTFNEko5M8jTTKUqOHNs3y5EcvQhIIUSHCUVDDFgWwuMkPDOHotiaJAWCaKVLUuLs4K1Es 6TrCcUUVRlHUgHolCEJIj05OVC0/UUVvhUo3DPRrDDnGQww8OlT1SI4WioHAa1ZT1X1BVFVRiOQ0 jg+DZD1G7thxQMK0HONi0NS4hhaNo3vGHstx9V0IhQOAw2aOTkDTaFJCCGgWCEGlN2tTs50MOow2 4/4wh7XEqjc+sQ0FcTvQbOIipKgIDQplbmRzdHJlYW0NCmVuZG9iag0KMzEgMCBvYmoNCjYyMQ0K ZW5kb2JqDQoyOCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDI5IDAgUg0KL1Jlc291 cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GNCAyMiAwIFIgDQo+Pg0KL1Byb2NTZXQg MiAwIFINCj4+DQovQ29udGVudHMgMzAgMCBSDQo+Pg0KZW5kb2JqDQozMyAwIG9iag0KPDwNCi9M ZW5ndGggMzQgMCBSDQovRmlsdGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqADEQQKBHIziAG jYYC4cjYQDIbi4Zw4bjKFjIaCAajSLxk5GUQGYGkIqA0ZjQbC4cCAaDgaRIZCAQFQiA0YCCbzeDQ gXkabxOZFSRC2FjAZjKHTMxzigncQCgingwm04GwyimZmoGi0YjcZi4YRkWjMcSqVzMiCCiWCJjW g0uFyccW6Z04UFMym4yCAw3oQGM3m4zGk5G2+Gw6GU5G4wnQ0nar1mtxAXQ4WjWUjizzQQT2bxig yKb0qmXWnlwZDIa1gqVrUi7MaXOUWw5ul2sYw3N3a8X4w4jFYzHZDWVoW6/Y1yIjek5yexkY18cz GZ6KwS237K7CAdcWbWoYjUXDHqZwUEQ0nM4G85mnHYEWk4347BmPGmn4FQ3joQEq+jKL7ejIxQgD QOozjKFzADa7wqBUp7uO8m4WhoiKwqCtLPIejLqu+0gUNQ1TvOQhzRs4tYYBgGwbuyoqNxY0wUCG wLBsKw7EsW+7iMk44ZNgyyuhc5kMM6IzoOk8rrNrFqmwg7rJQm8LxvKtLzvS9b2veNz+DCOo6DeN r7jGFowjHLQXiaIgnBaOa8jpMkvTBMTfjYPIdhAOA5DeMYyjnNoyQbB4UCaMoyDSMIWiCMc+DhN4 jDKxo6o+OcntaBsHQgmQQC4FATU2FDADYN45B6IQ0sYOQ8i4FNA0zTSZU4NMwwQFrBqtNg6DkOsz UkMoeioJIjCNVdWhRV9NU4PlP09TgyDgNIeosGFV0/Zw0haPA8jk+432jFIXhjFNqWIyVMWNY9X0 5ZgUWtb1pqxZtn2xbVuB6GNx1ZctBXRdNO2rZ4eo5d9/2vbNtvfe18U3fNLXNflk0/WQw1owFDDc M4ei2JokBYJopY7jwu3Jht935WF/VjWYyhbitT4wJQhCSI+Rq1h2TX7iWKDfiwz5YwI51yMNTjoH uYZkFoqLnmlL5Lm+T6MI9cDkNI4ZW9o9V88gcYVpebWPTmPCGFo253X132Lh4UDgMOqjlNg06xjI ghoFghBpkWGZrpt+jrRA20LQ4e6Bbg3MVVV4bzpknO8IqSoCDQplbmRzdHJlYW0NCmVuZG9iag0K MzQgMCBvYmoNCjc4Nw0KZW5kb2JqDQozMiAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50 IDI5IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GNCAyMiAwIFIg DQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgMzMgMCBSDQo+Pg0KZW5kb2JqDQo2 IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YwDQov QmFzZUZvbnQgL0FyaWFsLEJvbGQNCi9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQo+Pg0KZW5k b2JqDQo3IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUg L0YxDQovQmFzZUZvbnQgL0NvdXJpZXJOZXcsQm9sZA0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcNCj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVl VHlwZQ0KL05hbWUgL0YyDQovQmFzZUZvbnQgL0FyaWFsDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNv ZGluZw0KPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1Ry dWVUeXBlDQovTmFtZSAvRjMNCi9CYXNlRm9udCAvQXJpYWwsSXRhbGljDQovRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZw0KPj4NCmVuZG9iag0KMjIgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1 YnR5cGUgL1RydWVUeXBlDQovTmFtZSAvRjQNCi9CYXNlRm9udCAvQ291cmllck5ldw0KL0VuY29k aW5nIC9XaW5BbnNpRW5jb2RpbmcNCj4+DQplbmRvYmoNCjIgMCBvYmoNClsgL1BERiAvVGV4dCAg XQ0KZW5kb2JqDQo1IDAgb2JqDQo8PA0KL0tpZHMgWzQgMCBSIDEwIDAgUiAxNSAwIFIgMTggMCBS IDIxIDAgUiAyNSAwIFIgXQ0KL0NvdW50IDYNCi9UeXBlIC9QYWdlcw0KL1BhcmVudCAzNSAwIFIN Cj4+DQplbmRvYmoNCjI5IDAgb2JqDQo8PA0KL0tpZHMgWzI4IDAgUiAzMiAwIFIgXQ0KL0NvdW50 IDINCi9UeXBlIC9QYWdlcw0KL1BhcmVudCAzNSAwIFINCj4+DQplbmRvYmoNCjM1IDAgb2JqDQo8 PA0KL0tpZHMgWzUgMCBSIDI5IDAgUiBdDQovQ291bnQgOA0KL1R5cGUgL1BhZ2VzDQovTWVkaWFC b3ggWyAwIDAgODQyIDU5NSBdDQo+Pg0KZW5kb2JqDQoxIDAgb2JqDQo8PA0KL0NyZWF0b3IgKFBv d2VyUG9pbnQgKQ0KL0NyZWF0aW9uRGF0ZSAoU3VuZGF5LCBNYXJjaCAyNiwgMjAwMCA5OjM5OjM0 IFBNKQ0KL1RpdGxlIChGLUNPTk5FRy5QREYpDQovQXV0aG9yIChVbmtub3duKQ0KL1Byb2R1Y2Vy IChBY3JvYmF0IFBERldyaXRlciAzLjAyIGZvciBXaW5kb3dzKQ0KL0tleXdvcmRzICgpDQovU3Vi amVjdCAoKQ0KPj4NCmVuZG9iag0KMyAwIG9iag0KPDwNCi9QYWdlcyAzNSAwIFINCi9UeXBlIC9D YXRhbG9nDQovRGVmYXVsdEdyYXkgMzYgMCBSDQovRGVmYXVsdFJHQiAgMzcgMCBSDQo+Pg0KZW5k b2JqDQozNiAwIG9iag0KWy9DYWxHcmF5DQo8PA0KL1doaXRlUG9pbnQgWzAuOTUwNSAxIDEuMDg5 MSBdDQovR2FtbWEgMC4yNDY4IA0KPj4NCl0NCmVuZG9iag0KMzcgMCBvYmoNClsvQ2FsUkdCDQo8 PA0KL1doaXRlUG9pbnQgWzAuOTUwNSAxIDEuMDg5MSBdDQovR2FtbWEgWzAuMjQ2OCAwLjI0Njgg MC4yNDY4IF0NCi9NYXRyaXggWzAuNDM2MSAwLjIyMjUgMC4wMTM5IDAuMzg1MSAwLjcxNjkgMC4w OTcxIDAuMTQzMSAwLjA2MDYgMC43MTQxIF0NCj4+DQpdDQplbmRvYmoNCnhyZWYNCjAgMzgNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxMDIzNSAwMDAwMCBuDQowMDAwMDA5ODk1IDAwMDAwIG4N CjAwMDAwMTA0NTIgMDAwMDAgbg0KMDAwMDAwMDc0NyAwMDAwMCBuDQowMDAwMDA5OTI5IDAwMDAw IG4NCjAwMDAwMDkyOTAgMDAwMDAgbg0KMDAwMDAwOTQxMCAwMDAwMCBuDQowMDAwMDAwMDIxIDAw MDAwIG4NCjAwMDAwMDA3MjUgMDAwMDAgbg0KMDAwMDAwMjkzNiAwMDAwMCBuDQowMDAwMDA5NTM1 IDAwMDAwIG4NCjAwMDAwMDk2NTEgMDAwMDAgbg0KMDAwMDAwMDg5MCAwMDAwMCBuDQowMDAwMDAy OTEyIDAwMDAwIG4NCjAwMDAwMDQzMDUgMDAwMDAgbg0KMDAwMDAwMzA5NSAwMDAwMCBuDQowMDAw MDA0MjgxIDAwMDAwIG4NCjAwMDAwMDUyNzYgMDAwMDAgbg0KMDAwMDAwNDQ2NCAwMDAwMCBuDQow MDAwMDA1MjUzIDAwMDAwIG4NCjAwMDAwMDYzNDQgMDAwMDAgbg0KMDAwMDAwOTc3NCAwMDAwMCBu DQowMDAwMDA1NDIxIDAwMDAwIG4NCjAwMDAwMDYzMjEgMDAwMDAgbg0KMDAwMDAwNzIyOCAwMDAw MCBuDQowMDAwMDA2NDkwIDAwMDAwIG4NCjAwMDAwMDcyMDUgMDAwMDAgbg0KMDAwMDAwODEwMiAw MDAwMCBuDQowMDAwMDEwMDQ1IDAwMDAwIG4NCjAwMDAwMDczNzQgMDAwMDAgbg0KMDAwMDAwODA3 OSAwMDAwMCBuDQowMDAwMDA5MTQzIDAwMDAwIG4NCjAwMDAwMDgyNDkgMDAwMDAgbg0KMDAwMDAw OTEyMCAwMDAwMCBuDQowMDAwMDEwMTM1IDAwMDAwIG4NCjAwMDAwMTA1NTAgMDAwMDAgbg0KMDAw MDAxMDYzOCAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUgMzgNCi9Sb290IDMgMCBSDQovSW5m byAxIDAgUg0KL0lEIFs8ZmIyZTFlMTFlODdhYTcwNWU1ZTBiNmYyMDMxZGQyMGU+PGZiMmUxZTEx ZTg3YWE3MDVlNWUwYjZmMjAzMWRkMjBlPl0NCj4+DQpzdGFydHhyZWYNCjEwODE2DQolJUVPRg0K --=====================_4772692==_ Content-Type: application/pdf; name="f-timely.pdf" Content-Disposition: attachment; filename="f-timely.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KOCAwIG9iag0KPDwNCi9MZW5ndGggOSAwIFINCi9GaWx0ZXIg L0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAMRBAoEcjOIAaNhgLhyNhAMhuLhnDhuMoWMhoIBqNI vGTkZRAZgaQioDRkMhmLhsOBANBuNZVLBAVCIDRgIJvN4NCBeRpvExBM5ELYWMBwN6CVDHOJUMxz STuIBQVDSbTKbDyICJVzSdjKcqyZjechARjCeBTMzUDRbE4ZDhaMpgORlSSIIJ7BBzDLrQpsLhgN JlSpxUKkPDIcjCZjoLTSZToZhaZrOLTpVaueRaZK5XrBRIWdDwdB9aSpaxbHBcNbgNhiLr7NLxPo fGb9N5nSxQXJONdNa5Pq4duNlRMAMhxtsJRRuNuVURQQaqcxAdDeIDgcjedjTnBBvJQdzQaTZIDy bzqIDuYTSdPBGc4bK7X6ybzMIDDv5sILjc9iu6ihkGwaqSpbjBkGIcQImboKsOY5jCM4yhY9T2jQ EDtq+MI2DYEAyjcMjLDeFsPjI/Sbv6mK7KYGCMIc3MWJQ56pDoxQ3DmNo0weNI3jc6rMOo+wQDmq ryDCsixs4sjrOqNA3jmMsTv4uS+RXAIbqfGEAhggUGKksSyMoPAdqCNIXDKF0hjKMcejI6jFDoNC vyaMMfRyNw6joMsgjk/QqBVFgYxe5bDBRJw6jkOYXP0uIZOE/gZhpR6ZwBAqpPA3y1JNRzWMLSkW BnFtLQOk7YugrciDONwyjI6rrjeOENT1Cs4jTH04pAIopiaKgoSlFK6SswAaoxUaOhpGYUDK0cPy JHqQsUqw7rGNcKQ2Ng3jvWyDyakEoRBObrV/KiV2FLgYy65bAInLIqOgzgxu6kDKQ4MQwjGNdXOq xQyPbHg3Q3DwWja9kOjS+7LqsrFxv9FbjS4GbYqWorXVMqT4vmsE1Dk7gxpBHQQDrgA7YKMIxPLR dNCKkqAgDQplbmRzdHJlYW0NCmVuZG9iag0KOSAwIG9iag0KNjY1DQplbmRvYmoNCjQgMCBvYmoN Cjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwN Ci9GMCA2IDAgUiANCi9GMSA3IDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50 cyA4IDAgUg0KPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8DQovTGVuZ3RoIDEzIDAgUg0KL0ZpbHRl ciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgAxEECgRyM4gBo2GAuHI2EAyG4uGcOG4yhYyGggG o0i8ZORlEBmBpCKgNGI3HAuHAgGg2GkqlYgKhEBowEE2m0GhAvI02iYgmUiFsLGAwHI1oBUMc3Fw wHAxpEyO4gFBUNJtMpsNJuMpzOYgMJuMggMhlOhlORtrZpOZtFMyNQNFozGQulwgFo1lN0pJEEE8 m0YpMim0ypeFKlTFBcGQyGtvKlxxouGsOxF+og1GEZw14juCqVUq1YrVcrwgyFxGIzGNNjOXv5GG UPzhUwlNytJw9JxRjsOpBo01o12ewwG0wc1psnG+6zwuiw55uhFAgMUgMJjNBpMp2MtjOpzrcHMp 4th08fAFsnuu5FuOhmzmWY12s51DFw0G41gXUOA5DeOg3jGN42DmFgQDuNI6DQsA4P+N7/jSMKzh AOY3jMOg7jCj6yK6NIzjc4CbPeGq7JimamBg0ClOeGQYoc6iwrHCK0QoNI3jcMI2BANqwjCM4yqw Nw6PUyb3Bml7cvm2LZxYoSOucxDFMYxzgSOyy+uezcUKWFAhDrIq4AaGYcpU18tOPJ7lBgqAZykp q6OmxKqQQOYyrEtCwLEECPjGMo0u8OSyDeoA3QCEECSJAEeR2Nj1TLM68PgHL5RS/Ci0rOAYBqir eKpBiQI+Ngwjyr7wu/Iz2ocuclRjFLEN26kqsfMcsJvLSiBpJL7ouGaN0+qo0VEMsdhAtg5jqkC2 BBUgxjWEEMQ8s60rWtrgNW/KMveiNXr844YxQ24YU8zspqpKobWwlbYKJF7+xaogYhoHNgjDHquj nICQLUM40Do6yQLKrVBO+EA4jqNNnjYPMEDfQcFx7EF/hAOgwjWMsRrwGMzBo2r6KK/VNtZN7qDQ N46jkr+HhA7s8LJUsD2jiGAX7ilD4A68PYItGDQosA2DYHagVC4AqBVFTiKjFr8McG2lsVO880GN Awq+rQ6DoNiQDXQ4762Mkgz2sdD0THI6UY9VgLmuocRRb6euQoKaylYNaSvVdcSZTFftqw6JBlXj qCDCwy0UMkODzY6vWVxYQDgN45joFuB0CtHFaqsTSjPbAZ21SduzTuNwuSoly3juzG3VMfSXa5Yc 3hv82hterqQVoOK2HPvDUAOzxhAKvCQhP7T1DfCvX3Y43Yqq6sjzjT1zMG23xVedLVlOgUDNqztx yH7gCKkqAg0KZW5kc3RyZWFtDQplbmRvYmoNCjEzIDAgb2JqDQo4OTINCmVuZG9iag0KMTAgMCBv YmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQg PDwNCi9GMCA2IDAgUiANCi9GMiAxMSAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29u dGVudHMgMTIgMCBSDQo+Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwNCi9MZW5ndGggMTYgMCBSDQov RmlsdGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqADEQQKBHIziAGjYYC4cjYQDIbi4Zw4bjK FjIaCAajSLxk5GUQGYGkIqA0ZRMXDgcCAaDYaSmViAqEQGjAQTabQaEC8jTaJiCZSIWzaZGObi4Y RUb0AqHcQCgqGiQFMmlQoCAuDKTkM3m46HIwmM6VmMCmZGoGi0cwuKiAWjcbRIZUwiCCeTaMUyRU QqUa+U4UWQa2YqWitC4aw6+XWFjAYDaHUWjjAaDGMzLAE83CCwmMynA6Gk3QcwiA2mU5nMwmcyiz OZuqVYQVUg4S0TYWjIawy5zLGUik0y/UjK0zAZ3PnQ5iCPnM4V05mkxGk2Gk6HkQHQ3jrbA0YjMX DSM7mI5GZ3aewOYlS90gYjaBZLGjEcjnjU8uCgwlyzHU5pAMTUDoEAyjMMw3jk5TsjfAg3DmOqPh AMgyuqOwyjk7A3jM7KpNM1DVNY10EO63DdN4ujJhgHLer6yYZBs9bAPyMT+BAOA5DeOw0wmEA3De 0IzDSMYwtCrsOSJCUKDTC0MBAMY3jqNgyR7H4QQCzgxjQNIywsMjuhan8wBkmEULuh7LvYmrhJu+ 7Aq0wazpNMbEzY3y3MaG4YPW4YZhqlU2iGNAwtG0SDjpDsnq8sCxBcoAguyNLTjYPIWwnCsLuw2k SLdE0VxQxrgvk4j4qap7kNA5bmufBzpOo6zsO07k4u+8LxogFzzLrMwYvW9oYBk+k1vm4rMPw/Ua v8kCPjCOaujCMQ2JBAsDwS5btQbB8I0tJdMBAO7rS0zYwu7Xi3PpWtPvdP1hKQi0WMA5wyjGNMgj LKbQtO11B3vBkbxzHaQXxCjsUTII5DbIg0yNDVNhbc7xRQoakBuGdSOGHAZBzUjAW3Jg8xEOUv3K 3K4vfiNQBrdjKY3Y0aLNf0dR5gVJypIEhYTI1DyRjtujvZma3IleHBzdE7KHYU2rDLUuXtkWhU7F jfqTFijTdF+gzq8+JBgGIahnlQau/NqopA/43QmOUnUHJN5x40qPyfjwQDmr8iDKM48u6IqSoCAN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAwIG9iag0KNzY1DQplbmRvYmoNCjE0IDAgb2JqDQo8PA0K L1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAg NiAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgMTUgMCBSDQo+Pg0KZW5k b2JqDQoxOSAwIG9iag0KPDwNCi9MZW5ndGggMjAgMCBSDQovRmlsdGVyIC9MWldEZWNvZGUgDQo+ Pg0Kc3RyZWFtDQqADEQQKBHIziAGjYYC4cjYQDIbi4Zw4bjKFjIaCAajSLxk5GUQGYGkIqA0ZxgX RUQDQbDQXDgcCAQFQiA0YCCbzeDQgXkabxOZFSRQsYDKgmOcUE7iAUEY5GE2mU7m85GsUzM1A0iy WFjSY0sGwIlQiBGqETmklIj2SB22d2EbDgXV6HjgYi4ZTEcS66DWFzAQR8QGKRyUYjcai64iAZjE ZXOYzOa2idQcGz0ZwO5Q2g0MXDAZjmMzOkCgpmU3GQ0m4z1cqVkYy7AC0ZY/IzQQC2iDYYjWj0wm lQg66s1uw22C5YZ6CXxm83e8iC9ymjX6XzHBYSSSYZXe94wYQvOZKbUnK2fP6CHaSmFIymwwnniV rDcjA5YaDWHc+8XqXJU6zAOywoGhoG6XIw8DxPWmjyrQt4UPc+D5Kw+jjoI+6EBqHK7v2uz+uk/7 qr+7CQO0ksNseGCYsax66PIykMpsz7Ghu38IjKMYyjSOzVtbCrusU3LapeoIiNy3bexu4Lhwq40M OSsi4sggYZByiSHOmvqFpawMTQIw7EsWGKFBc/UjQcpK3qI0LRio0rTtTHz5yC77aBmz83SPNgZM y9gUCrJrXwtBYQLBKEZQ3DsqyuoDpwBLiPS+7cUs+mMyIXM8YPNGU2MPG73R1Hk5yAuUzzvPMjJx Gk+xvQL5yfDkQBiHCbjaslZOiiDEhqow2IQKdcOgmL+OjW6whyxLHIeG88IdX9kJdMlmJdFYQWgG IczwHKjIhaqY2xbS5udA6JV9XEXWJcqT2vdFqTNZ9cUy/dyzPcKiXUl12WwHEr2Xb1zXasKYMVcl v4FWi5WngFrX4iNuWZPDv4dceIyFcNhrrjNoDMFQGhlXqGIcxsrhojNjysuVrZJitoWCkzmO/lmT BBlFkoYozGsSoFoSsGy5sY3rm4Fn2gMbn99oRosu6PIueobgugoi6On5+wEapTeOP6hq9aLwjOno jZbGrklWwhdsaLbRrWi6vtWwaVrkWSDZeq6ik9F7tpk67hrefoyk7H6Tv2jSJcG4sTiCTzxqiEOX iXAWzlqEY6k2CTPmeToQjkxaDku+5ejkr8VyWaWOGgY8ZFnS9BzbDyFzOa83IOc9ZgXQ5BM3a8/2 UChox/Mdtl3NpY6/PYr07rLp2PhwL4PedOr2A51LGBZNK4Ycjq3rBp7HI6nw/fSu6OsBvrXrxBvG 0XP8VU/V8/u/dvnuLldnFxBaD85H4XKY8jZCyVOxWODUHDnXmLAQ0rJ/b0ENA4Wc6tnbWoCLSf2Y licDYKNBaQ+yCbRkyNOgxB58DAoOtMde+aEh04TFyQStCDrXWywcOm24ha04XQqcA2+FJLm9l3br CGHLeYgGMfnDeDLgWAxGbXEQ20KYHxEdVCSBTx2aMcY8DYjbImNIgWPFglxnFaNaZfF6LStFbEIi xD4oytCImLWhGlIUbHJkJZCtaOUVY0A1Tw9kzTPzORviygmMMWpARfIdINs0eTExrBwz+RMdExKX kbISPLYpGR+a1FhlUkiIx4joqaQ4OJOt9k0kWOUbo8yGM0TeKwDS/NWWI6lobp1+tDO65B27m4Cu 6IfLI78tC7sQlu0N5qBiInfmHL9za5UEzJdagUGzo1uy+c08420sZcTFekmeZzvWTSqm7NpEkvZc OnBnCOcMCECkni1N107QphTUlygUGKi53ObWtOkBroTmGLnugU8LAZ9MvNCfueSx5zmboNNmdU54 eHOoO44G5d4+UDccDaR005y0XTwUCixJkNqpn+DMGkT6PgznOYqbEs3HH5eqd2Nr4aSLKmm1NgVM 31y9ozTdkzxjut/plT1LtP6eUPl6S5e1LS+VHUtUVoEw2tUkqNMOH5JqhUQQ7UGmkvYAPspwv8GJ XatUvrDTelM/p5StpRTGclLGPuoZxW2C7HzQtZra2ys8vZrtEBnJGXpd5PJ9ohKxpVKKRIrqaz2d k+QYOJfYn07xzjmK9r5ZGPs87INDjM702snKVNELylSO7fbOxllFHM2rvI5WPStZ+Qcf7Cxqj7JS uii5EWPsXJKndingShkxXwjNr68F8s9bhERmpR18MSzS0dyq4ynfDZk79m5Wm8MeSpYpMYumOOoQ 9PtcY33cLobUu8KLw3loMleTNYV4S9rZG+xBgKiXwt+d02TAiFX3vtYmNBRWoz6Brdy+VaZ1Svp9 RGVxsUi0ws/C7BS7MGQcwfNO3aGsFT5g+XTBzBzuyLfDgGXGHVU4OxDgqpOCVnVMYbhbFNUISTyq phLEpj0u4bqad0x8NsLYcnqXjF6+pp1dx/QK9mGsd4LrLC4GEsK5N9cqdsk5ckWUhOieQntEHqkz JEboz4NqSG/hqyBPwVClgoCeHUOgYg3h1NSzUMocw5hhDOGU+ZNwWq0MTCgySSDPp9NuUhfANUbE zzKe4OgdQ5BuBAGMN4bgzBpDkG0MIdA06NVgVxKhYHf45P2ctqLp0gzC09jWdTv6xEP1HNXUzX9U KRnm6jKWrdPuulBrLUk+3XSW1tqqD98tU6vaEzRPurp3yL13sBPEKNh6znpFHZet3Q49mRr+d89t fzFvYwvak+JpbHmLYi8e26AQsOdp4wG33t7LMA6fJd7d1Phn5Vvd83ns0+3NvCfCeNhb33oY8zm8 9vl3spvPdjGeAUNBylfac46EcJSFwfXBJgcsK07wxxwOWHrd3482gqVOCcXZ/M3jfCL9b84bUjir xuOLiX/ybi+NNyzj5WdDWW6+LqF4hQSWvAzG05oRLVXXPaq86mPuW2XP426otlxySe2ujuOl3qLp dDUtLE6EUbn6COjU56ZE2zJQOfuC40XdnnVJx9fIdz/V3aJ5znfH0p6tCAb0K7h2XiM5yI887J2m iU6Oe92oIYiW3f++Em8Fp3vfbVy9OSF3JbfY2L0NIrx7nvhZz+QjFRJefcPLA3IXhDyvbUp6+stQ hKdQ+e1zoIDam10pqkTvr6mZ5E1eeQmUSaLCIPXeixD7J3pE8W++44DbTncPbkTqzqhFW+PcanT7 8v35CvlX87vATd07F2UI+t6DsXbT9b2+79pn/qPu8cBrsb57AftTg+w+ygkepefpTP9rZ07MT/vs t/Ly2AaX/28ypAhq06iaoQfin8nY+YpI3I+mu0pa6sia44eKm4sMj5AIg21Qj29mp619Aw9+qvAu xGoapKx8T7A5AI3807A5Ag4E40ijAIoo3Kii44rq2nBaccrqo8sMca7upS1ETwsooQrO6tB8/dBs 5DBgrtCBBQrtBk5RA+hRCAyBCc/+pQr2sE9+nY9Q9m56409e08uwy+44ta549etaoqpI1ZDC6SsE 1YoQIg/6uI7ady1FDhDar9DWyM7uJQ5EuPDa3KuPDCt61RD4ccSI9BD+oabU18lVDaK61Q2M44ck 402MoQa9C/Eeoade6CuW9edfDNE27aaE07E/EogjEcjmoIlk1Esc9+llANFXEgMe5FFXEpEkvBEw 82T6Z+WnEoXw1RF1Cmvi6sb+9+3BF8aA443a3+Im2YOWp3FyajGQw9GMS6oQsapFGW3Ooan7GM5s Zgo606yZGQmC4011Gq+ST6Ii8AccoC5FHS8sPC1Q6SeaZS+u6SZsk3HimInUaW3LHwZtGGz8+oZe Ss/Yfq6wbiuPICcHIGXE6C1qZtA5IC/ubi2se8s4VlBxItHmlq1EfHAYY+lrANI8swYI5ESvB+aU tO2UrqspI3AsIwjPJAZ+nyI5JIqmI4SoZQS0IfJxDxIGBxBPJ4yFJ0uuW7JwkfJ+4MrhIPJBBfJ4 5pHmBuvVKes+ZRKkperglQ4iIg4zJ4+LKsrYIw+LKiqBK82YIgP2d+5VH2XKWJBE7AaUXrLSxTKi TwX+p6WtKtCqp7IXLjHOpdApL8YqIxGlKi+ceKQTKsI7J5LLMNJ4rZMVMfFtK288u6IwX9KYIg5w fjHUY+8mYWOs+zLiRcIfNDCJM8xa/5MDNQls/5B1IG8EV0/5CfLi9rNLNPLRMsZCLpLBBGZDKRLi LkqG/hMy7mp9OJJI8+W6/gMXJ1FxOY+YLzOWgzKI1YZAgzI2pMizGpJS8fNKqNI3FLOueNJ0c7PH GzK2tOoq/O7jJS7zOXFLI27oZAc7J07fPo8jK2By7W+/Lybi7PP7OiW4oE+/NEa3ECZBAtHmNFNK Z+/nIROs+/QFDs0EVSZtFWZAIij5QXHdNKhGZs6LQ8fxH24dNlPfIvJPOXRPGQ5xQrNoZg5pQzCX G05hNLI+OXCqgI7a3qwg+tMTHXCaZBAVGQP2+tN5HXCNRsSpGRLC+sJVGq4pSVOAZhKnSEi1Gq4U Oc+stg7ux7Nk7fEpBXNK7fFgnaypFYcZTHFOccwVOGgYJMwUvkpCk9FRJepDObTZQdSK27EgWIpC YhEoLkvHT/NOZYmETLF3EJACIfURCmSCP3Ua9+fmBlUjDC2cTLDJCHUZEbDCnATLO4O4/RU+9nUo v/VHUkyZUo1dDDINU3PJEI1jVVLXB3MXVlG6pQ+cTLPQoI57UO6eJMnYYWN464oasNUg8TCAxDWH M6pRGlUpWRBtNtWeerBkvrWG8spSW7Wu7aBnOEOdW3CBMxUYiE7vJwwhXApaL/XHH1XLFjW+9Kpa XTXW9UpbO9Uo+hAIgzXvIEpbPM+IqbAIgtW++hAgnRX/QMpJRPX3L6qtPnYPKYpId5YXUKOsqHX/ QepAtlX3ImpBQRYu/269Y++861UZAGcciyvHX/ARPZUPZMpBF/ZKhA+rDVZU9/QqmRZq/NJHUpBL ZOSu2Uy9BA7uTK3/aDNW+RMHaM9nZUWJaU+jLtW1BSoaJa3daCWMouv1atAQoxOta0+jLLZ5RHaH K7bDJQ9xSjbLUKmi4faDbMnPF7bS8U4NbbYgomrtbi44WbBHbo9/b02Fb5byNlaa2S863laCvM8l T1UZcJb63TcPCnOMmbcfb7UFcHRm7vKvUPcY7Uqfcm6Yntcm7Cxvc86pU1bDRfW7cZUo9ml3W09e l3b/dZVTVBW611dW7acvUhdfVi2g5va69fP3Mtaoha4RHHUZZI4bNJdXDQ4RWVeQ4uw5eG9mZu4H ek9+ZvaBZI5W9bes4auTeXeI7u4mp9e64vXFfAmeI5FxfKoBKdfQ1ev9cleeoBKLePeY4iI5X1fZ fzc7e01LGtZxfmI5Jnabf9fwBhYVf3gRbves2/PvapSOoBYlgg+YdQ7Pgom8x6X/gw2xY9DoddIj g41KwVZTg+npIThFfwg/WFhMdRIBhS2jRDeXgi1hdHDg2xRTfthoclezSW1Kdph1I+d+sBW/hvhH DtWGWW1A+LhmfCdRiRHlh/iZgxiXVNiNfwJQnziodnCjia1edzh7hpUpiDi/e/i2QLDcn9hgdnfP jOd+Ubd1h9fw3NjInNbniudCnZhLJyc2nZaLjxj6qXi8nMqnjWnXgJjrj7Jfga1KpTh7R+nXgLfv jzgngErrjVgMdCrhg3gErgo9kZfxLVklkgZNUvkyeJhRk7U9lOd9hfk6/HiLkmeJHxfeejVbfem1 Z/jjlIL9ftfCdC/5djDYc2/5kxlkedahl81VOZmU1fPYorVAPzWdd6edGdmi+/j/mdUFeOm8+tYt fSTLi01UTLXPnAvRcXCQc2+JnRcRfxaDb/c3nVXtdJndPFdDnVX9cYmK9YpFnumhYNn01KSmuxn8 JZYdoDfxMrW/U0dPMrYtU0mK8ni1oYmW+7bw1Lb1aBooQKmZoWl5ojiRo2QNQxcBoxQ7bjobZpoh oxItbDavo5Z3a8mKVreFZ6QLppaLalfxKBc7psK9RrbDQ21KOnonQsl1SDadpnUhp8knclp0dCtP jVZcK9bJZzqHjhZjiFJDqy1eVlmhqmVzabAe1LQHoJECdPQHaLECmKNFc6/Cc3ravlYfq7kXreQK agm5rnrZrE/VrhAVX2xXfw4dqlYBrg27sA+YL88TsQd7sVbZYIwKOZmhXglcOYV1WHXpsrhQUWgH GtW1XIZewNYts4Q03brltBtLlvWW8KL81rWnM6wCJvtftYvZck8SeawDHPiTKZtyrjWm6GxYpft3 sbFbVdV2wsMTmg4swTWlV1sSg/aLuWwDe45kwKa9Ys2IwsylabVWwKbVXPuylcbVrzu64iV7W1Ea gGSJclU5u8pNUjvVnnUXtwdyo9UJsadymRvvvonRvvvVYVv3u9PnTvI+V7PvwInmj1P5TfwVOOd5 tw/bTVt4/9wlwSy/SsM4gHDOmbS2/+j1Qo7pw1ZhStSmj1DVSNwKpTv1crwtZ3xRsbJZOXSGwLJw 3/R8mqI3RjxvwTLVOHwLlFT8IjnbtDL5RVnSlcp6m5QrJbxpSLROgGeLUGhHtwQNt9QrNWI3bRyu meI3SrQlsafjv0e3txNdT9cUgG/44HQLNO/PKDQTr6ldORzfsDtDO3S1YFsaizTlzxzJTtPqQ1y/ Pxw9x3PxLhzjxZPxuBzjsPz1wLUjPPsTW3PHVAP0/zZRwTa8zErigHb500Yhtxapxs31xw9zOX1H 0xlhNvSuQ1a5Tlfr1BlpN30dtcZDl/1Zl1NLnOgG891zo+wLbs2FNVxxbsn8QDwS8nTlF713mSZB F7twXLJpu3sb2hLdW92PSDyqdMQ1LlMlzZb0mQJZ2mxapdyH23eVA12n3Ovv2fM2YP12yEIwoZvN bW4HLftZbWV1BF0UP1hlx71J37Rqhdn5LT4CwLa4OdLVUSlc9ymErh0/4NISrh214XDgIxiJ0xIj KXsbZr4sx91BsXKPt5uHJgu7zIvVLdMXzRPvJx1tzjyE071xzRYUrr3LzjkQT7hzzRzx5xbFzrkE rrywiy21I0wLN+401jzRXlIDsT2E1RIf0BXVIlw9M407Vbyh2lIVzZ2zH7sLyQ9bW7X5yQzy07Hs Q0pc55ijvNLw6tQ7yg97Q7ypeUpTiV7NiZ7mg54T7JWJ7V3hGxx++d79xbGv1Tw1tdGXmpxMpzGf 0p8DGfy4r7MHGX4Vw/BH8lw8sNJXZhw1dN8tws+gT7FmQ0999BMntC083Kr9w1UX9JK1tCtDEseQ Q0tDFlTXvE3T8h4mV7cV9JzYdy5bEn9lcFFN971PDXwz9lTT+Mgku/C4tp9dnPDXSf9lTF+j97bh DP+kwTSzEFjltCa9D9j4wTbJDPJ8wtbBw3xwg/D3mOwC5L/TSDDBut2Yy+gGwE6ty4x633niwTRj 8xw8BgIAORcNxsIBkMxnA4KbRADRqMIENRlBoRChAbIaU4bDxwLhgOIpCYIIIZDhgNxdBYPCYlF4 zGxgNhcMZVFZbJYeNRcOYnKxdLYwDY1JhoLhpIJ8MpBOBhRRkNJCLqVLqFMBkLqRFanTKuNZrCan QaHDxjM57FabJJgMKxWYTabFDRoOYENKhPrTJbnArPb6hcQbc5RI7xUL0OZRU8LVKHc50OLuM6vS 7kOZ1NcnjMrRZpFK7C8rCZ5np/BcBc6vR9JXrVgZ5Usjn81rrZWdlh7ZrIPstOOIEMbPV8lraPHR xthdw97KLtpOHehxMhzmOTE97Opbu49lMCOJ1isl29nR4TkNJH+IOIT1PRvavnYPZfN0LLo/jWL/ L+7bNV9/muQcLYp6KPk/KqsCG7jQI/DiQS0sFvM04bpQ4EIMMuSCJSyMCvGG7vwtBqiunEEJJYs6 ytBBCwKzFEOw4+8UhoG8WxhDq2PgGcWr0GyBPtHKUvGGyOv7H4ZxjITYQXI0gplFjkyOmThvvJbT hsorjyVI6iytLMgrBLsdqvEcptM/QaBssrsyLI6yvAssqTMGqBPM+8Kr1OUgTq604o7HCyzsuQap RH0/z3A4aK8o0nUAwLdR/CrThqotHUK4lJOrBdITiyastq7lEKvLiD088YazailSTutkxhnUjTrm n6z1SuVYPBV0zRlBlRra4lcprW9DzOmdf14vVEJTTteVepzI1mwLm13LFXtlaNPho4VZWVXFSWrX q2VFVttUOGa+VRYq5BmjtWWAxoZpRNVnBpdypWTaUzBmx9mw04l8Sfc0uNOisfW/C7AorIV/wNdq rwHXcuL1KVw4Be7c2Jh90LZiOCPGpVeYdgtro7cGNtOGTE4S4gZOli2FLkGTsWzi7A5ej19YnQ6D zziWQZzJeP444ys549+WKpkOPZNejZiEKgGyMlGEKfU4QCoIgGheIwaoNN6C6oMwGrYj80BBqgxh AFsbq8ieqDuEAUCaMo5jmMIzjKi43jeOAU6oNQGiLpqAgA0KZW5kc3RyZWFtDQplbmRvYmoNCjIw IDAgb2JqDQo2MTc5DQplbmRvYmoNCjE3IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQg NSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQovRjMgMTggMCBSIA0K L0Y0IDIxIDAgUiANCi9GNSAyMiAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVu dHMgMTkgMCBSDQo+Pg0KZW5kb2JqDQoyNSAwIG9iag0KPDwNCi9MZW5ndGggMjYgMCBSDQovRmls dGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqADEQQKBHIziAGjYYC4cjYQDIbi4Zw4bjKFjIa CAajSLxk5GUQGYGkIqA2LDgXDgQDQbDSUyoQFQiA0YCCazWDQgXkaaxMQTGRC2FjAYDkaz8qGObC 4YDgY0eYncQCgilMmlQoCAing6GU3HM0m+viAqnMymQUzE1A0WjYZC6WiAWjcbRIZUgiCCdzWMUi RTWY0rAFSpCguDIZDW0lS14gXDWHYO80KmU2kUoUEQpk7F2sYjMXDSMi2IXC8XqeQOYFS/0yK5ep 4cZDbOg0YyrJUsYRwZ7DKRgab2o1MiGWunI2mk3Gk5nQ00o3G/nGbnmHnWIQG0ymM0GHlnM2iA62 YyCA6G8QGEyHbmGXazUWjEc6GMzHJ0Pb3fA7qN/rCKmsw3DIMo5BAN4zOyMo5jmMIzpBAY2DKNI7 QIPMDQK6I3BbCEJwq2oWo2uQZreHDVryvaHvq1iaNgwbCtkxS1JMt7IJs07KKI1bMCIIomCSKwii kIQstqz76Lk0qHPs1CatuvyaNc/zMNk2kZSc3McBgGqBP2oYaBjLj/hQJI2jgN6zDm9IQI+OczK+ NIxDSNg0jpCzsKuIM0vOEAxjfMsIq6EEOQoOQ8veuT5LhEzdBsnz9soGoYLopDCjvOg0OVNU2u2N LqLO8w0u1D8QhbEaXtPFC+qBFku0o2LERixkZseyMby8HLYBiFwZByG9XBQIYnicIwnikJogicIY ihaKQiiiKok2avIuBQH4uBTIrQNFJCIyUmUmNVJ6htfVrhsMxEq1lK9bMqGbhKS3QZhzd7CzJM00 TVNk3LBOM5zrAw3BBPE9PRPs/uNB4yznQkLOVQ74vnbcly83yOxUws+jcMw3uQ7wxpBSw6DQEDmu tT6PjiOo0o+7Q3DoOYWQu8z0OiOlBYVDo5NqKgVP4G8dLkhYby+1bC5EkDtQXBoyhdD8nNIGqGP8 vNxylG1zSpIrcNOoYZXdFqmBiiFftkGYhQVmwyjNjY5Do2SMuZNYyjgNgw4+8oxQtsqPjCOaxDCM UIhBtW2DpmIxDrmyujYNkE4fRIbUXHAY0lsDdhtX1zDu7qu0IEA8jeOtBDft7aiKkqAgDQplbmRz dHJlYW0NCmVuZG9iag0KMjYgMCBvYmoNCjgyMA0KZW5kb2JqDQoyNCAwIG9iag0KPDwNCi9UeXBl IC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBS IA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDI1IDAgUg0KPj4NCmVuZG9iag0K MjggMCBvYmoNCjw8DQovTGVuZ3RoIDI5IDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0KPj4NCnN0 cmVhbQ0KgAxEECgRyM4gBo2GAuHI2EAyG4uGcOG4yhYyGggGo0i8ZORlEBmBpCKgNGI5HIuGw4EA 0Gw0Fw4lggKhEBowEE4nEGhAvI04iYgmkiFsLGAzGMOmhjnMSGlBmh3EAoKhokB1N0fOZvNh2Mpk EBjNBhNhsMpuM5lFM0NQNFo1GYuGoyEAtG42iV0mhEEE+nEYoRUkU4pc5wNSFBcGQyGtrKltxdyh 2EmtNGGMjOFoouGQxG+ZKmIIhFJhJKxFKRCLIgMJkMlaOZlOYgOhpNplNhpN2y2ZmN5y2lWx1tnA txkMvWVo2XHOBplGGg1gVRqe+OR3MJysBwMJ0NAgN5uNh5HdC70gIhTJwgj50OpyNwgNOzNxvOnD m9148rwN8zYYBi5LnsOqYwjMMwyjGOivvw4wZMkuoZpgGqlOU5ypsUxj8MjCjDL2urlhmG8LqM6U RuoFAjDqso8hAMgywWOQ2t0+baqYMQyrGOw0je972DKOI6jSrTgu6/DiuOHLkr45YbhnEgXBgjkT tCqbzvZHo3DIFo6DkNI4No2yQDoN8XNwNKvOA245jmMK0tZLT8CoFTLBoGIawuzYZBmGc8RQj4xj LNCQK0ODwti+TZjGN42jgs0FrAO40u83TWTlOijBkHEBRAziLOSxA1vqO74tq275DdGI7LJBsOIc FsJLy/sPCpAcUQyxq2AbV1aSZKIYBtCrnyjOzQMQKAyjlBEFTNGMZjc+Y20SEA4DkN4xDCMTxhAr AwrENIy1XbS1V1JAauRWajKRJ7CqMpMqMQLgUDKFwzhcEDYpAKQjCGgcpBuLgU3uEApDKOAyu7Mz czTcDZuzcjHgbObLItYWKM/AgULNNgQLHGQzRXIr4jYN45joEE1zatI5hYEAxDrk9wrPS+KBs6da 06zocZuxDz0QOY0R6NiwRxlEaRmPSvhc/AipKgINCmVuZHN0cmVhbQ0KZW5kb2JqDQoyOSAwIG9i ag0KNzA3DQplbmRvYmoNCjI3IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFIN Ci9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFIN Cj4+DQovQ29udGVudHMgMjggMCBSDQo+Pg0KZW5kb2JqDQozMiAwIG9iag0KPDwNCi9MZW5ndGgg MzMgMCBSDQovRmlsdGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqADEQQKBHIziAGjYYC4cjY QDIbi4Zw4bjKFjIaCAajSLxk5GUQGYGkIqA0YjYbC4cCAaDgaRIZCAQFQiA0YCCbzeDQgXkabxOZ FSRC2FjAaDWgmOcUE7iAUFM6HIwimZmqbC4YDIcjekiCiC4Y1uuTOmig7m0wm4QHA5G84G85mE2S E3nIQG4ymE5Gw81QqVYWjGVi0ZjiVSuZkScVgYDGYzOlUUbjDEFSymQynQynI2mk3Gk5nQ00q2nU 3GQW1E0nAQaI2yAuCgYlwU37ADIXDaMi0aykcZXFT2bxigyKb5Cl2SnFwZDIa7YG80Xb3kzSvUWI QLkZIa9rLU4gmw7mE8nOQmE03MzXXxnIyCDMGw0nbNnkQGkzXc3m4W9Cbha5yGMe6yvqyGausk7y yiIIomCSKwiikIQshAJoqCC+7zDKNwxje0zNI+MjoQA3DqMIl4ZwGxTjioyKmOW5rnqq6MSodFjF QKGYaO8yKsBwGUFKdBkHQhCUKLc0T9taN4QI+OI6jK0LWjS16+PgMr5PoOS+xm/8AhzFTFsaG8eT EGYYBzF4UPWuwiCmJ0msyOo5DcFgQDqObPIOuLXyWOi5SnPrYjwGQftoEAwjm6AqBVMSWq6r9HuV Nb2L0944DCOg0OgGIZhcGjdog3KguCnyBsq4ysIrBE1OYGQbU4lcbuuxkgQQrDCyCFAqjmkA0DSM 40LWOQ0rqNI6PtJFirVNjWjQkE3Tgj46TmtTY2bCwgvNTVMv8ryw0+jLEzEG6kO3NS0P8xjKVuGA ZhrAayvtP41pANw3s0EA3vyOY6jHYVNT0ObaRGwSvVesCHXGyUBxdSdXVhGeDVnAoYJRdoaVfNQi SYJwnio870v00QzNHTNlyvLL6vu/N7v5IcHwjCcKwvbzAhzcNSUcwtIIWiobsqsrQBBDcOw+zYyx FGbAsHL8w4ZVmHubiK/pNWWdRZHt3BrA9JipZ842pOgQWjDORvuOlejY/L4vm+oW3vkg06TEaNq9 FLD504SH3EoSbai74UVdGWquk6lZuwGO+61V+FcCKcNswuy0PtRN+z7bg6BA145riM6QaGNi4c0M IzRBm2nawrAYhgscWzMG+u8COY3z6No6jY0Q4DY2AUDwGlDKpfd9WIM7PUBmEiwnRdGuxnoXSBeK nM9EA7UANFErXy2khAO9jjRD3Nbi/GTDo/YXOgIqSoCADQplbmRzdHJlYW0NCmVuZG9iag0KMzMg MCBvYmoNCjkwNA0KZW5kb2JqDQozMCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMx IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCj4+DQovUHJvY1NldCAy IDAgUg0KPj4NCi9Db250ZW50cyAzMiAwIFINCj4+DQplbmRvYmoNCjM1IDAgb2JqDQo8PA0KL0xl bmd0aCAzNiAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAMRBAoEcjOIAaN hgLhyNhAMhuLhnDhuMoWMhoIBqNIvGTkZRAZgaQioDRiNhsLhwIBoOBpEhkIBAVCIDRgIJvN4NCB eRpvE5kVJELYWMBoNaCY5xQTuIBQUzocjCKZmapsLhgMhyN6SIKILhjW65M6aKDubTCbhAcDkbzg bzmYTZITechAbjKYTkbDzVCpVhaMZWLRmOJVK5mRJxWBgMZjM6VRRuMMQVLKZDKdDKcjaaTcaTmd DTSradTcZBbUTScBBojbIC4KBkXBTfsAMhcNoyLRrKRxlcVPZvGKDIpvkKXZKcXBkMhrtgbzRdve TNMWMKzYypkaxRxnTKcUzLp82INAII+cTqaY+ZNab7XbTsacwIPGdjKbLdICSROgm4WuchjHusoq XK6r4coa8CzDSOg0BA145riM4yhc6EAtw6jCJeGcCMU47tuqsrmOc6DpOpEMQKwwqBOQr4ZBmxsG CSMwQDm8bMLsj7UjkNIyjmHToBiGYXBo3aINyoLgp8gbKuMrCKq7EMSOaG0hpXFTro4h0Xo6Gkus spw6xxG4wte+w3Pw/Q4P4/yqgawLBhklKTyW68pORKjlytLDqxWGAZupLwXRjBblBQNsyDoEAxJA O8HDQz0bjfNFFDY0Q4DYkA3xsIgiiYJIrCKKQhCy8w3M0OQ7Lk/6vLDIyMsSryihgGqkT07oY1xM QUNiPAbB+2kbs8MaQQekA2DC0L0MyOQ8pk2K0WhYqP2WkDPVVVg2B2mTMDoMI0jYOboCoFTr0E79 CUNdVejo+FHNaNCpDmNAyvcN46jo2kLzg3jdw8w87uEh9ZKEm0pwZErnzhFCHS1ELuKMyqyikMtj DS/C7PO0K2jcM6+TSMd8qlCr3XeEA1jKMrWDcN7NVdAIawHO+Iy3iinU7ZuMPw9z7vy/YQP6ui7D nSqQUvTNNhBTty3Or7sSPKasBq4lEWQEFP1DUdS1PbLN22EFfhxYSqDMut5JAOA6jkt8caddAbzC pUYK1MKy50O+VjIzyD3zRgyDrTTRjCzQ536v4GiKkqAgDQplbmRzdHJlYW0NCmVuZG9iag0KMzYg MCBvYmoNCjc4NQ0KZW5kb2JqDQozNCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMx IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCj4+DQovUHJvY1NldCAy IDAgUg0KPj4NCi9Db250ZW50cyAzNSAwIFINCj4+DQplbmRvYmoNCjYgMCBvYmoNCjw8DQovVHlw ZSAvRm9udA0KL1N1YnR5cGUgL1RydWVUeXBlDQovTmFtZSAvRjANCi9CYXNlRm9udCAvQXJpYWws Qm9sZA0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8 DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1RydWVUeXBlDQovTmFtZSAvRjENCi9CYXNlRm9udCAv Q291cmllck5ldyxCb2xkDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KPj4NCmVuZG9iag0K MTEgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1RydWVUeXBlDQovTmFtZSAvRjIN Ci9CYXNlRm9udCAvQXJpYWwsQm9sZEl0YWxpYw0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcN Cj4+DQplbmRvYmoNCjE4IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlw ZQ0KL05hbWUgL0YzDQovQmFzZUZvbnQgL0FyaWFsDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGlu Zw0KPj4NCmVuZG9iag0KMjEgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1RydWVU eXBlDQovTmFtZSAvRjQNCi9CYXNlRm9udCAvQXJpYWwsSXRhbGljDQovRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZw0KPj4NCmVuZG9iag0KMjIgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5 cGUgL1RydWVUeXBlDQovTmFtZSAvRjUNCi9CYXNlRm9udCAvQXJpYWxOYXJyb3csSXRhbGljDQov Rmlyc3RDaGFyIDMxDQovTGFzdENoYXIgMjU1DQovV2lkdGhzIFsgMjI4IDIyOCAyMjggMjkxIDQ1 NiA0NTYgNzI5IDU0NyAxNTcgMjczIDI3MyAzMTkgNDc5IDIyOCAyNzMgMjI4IA0KMjI4IDQ1NiA0 NTYgNDU2IDQ1NiA0NTYgNDU2IDQ1NiA0NTYgNDU2IDQ1NiAyMjggMjI4IDQ3OSA0NzkgNDc5IA0K NDU2IDgzMiA1NDcgNTQ3IDU5MiA1OTIgNTQ3IDUwMSA2MzggNTkyIDIyOCA0MTAgNTQ3IDQ1NiA2 ODMgNTkyIA0KNjM4IDU0NyA2MzggNTkyIDU0NyA1MDEgNTkyIDU0NyA3NzQgNTQ3IDU0NyA1MDEg MjI4IDIyOCAyMjggMzg1IA0KNDU2IDI3MyA0NTYgNDU2IDQxMCA0NTYgNDU2IDIyOCA0NTYgNDU2 IDE4MiAxODIgNDEwIDE4MiA2ODMgNDU2IA0KNDU2IDQ1NiA0NTYgMjczIDQxMCAyMjggNDU2IDQx MCA1OTIgNDEwIDQxMCA0MTAgMjc0IDIxMyAyNzQgNDc5IA0KMjI4IDIyOCAyMjggMTgyIDQ1NiAy NzMgODIwIDQ1NiA0NTYgMjczIDgyMCA1NDcgMjczIDgyMCAyMjggMjI4IA0KMjI4IDIyOCAxODIg MTgyIDI3MyAyNzMgMjg3IDQ1NiA4MjAgMjczIDgyMCA0MTAgMjczIDc3NCAyMjggMjI4IA0KNTQ3 IDIyOCAyNzMgNDU2IDQ1NiA0NTYgNDU2IDIxMyA0NTYgMjczIDYwNCAzMDMgNDU2IDQ3OSAyNzMg NjA0IA0KNTAwIDQwMCA1NDkgMjczIDI3MyAyNzMgNTc2IDQ0MCAyMjggMjczIDI3MyAyOTkgNDU2 IDY4NCA2ODQgNjg0IA0KNTAxIDU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDgyMCA1OTIgNTQ3IDU0 NyA1NDcgNTQ3IDIyOCAyMjggMjI4IA0KMjI4IDU5MiA1OTIgNjM4IDYzOCA2MzggNjM4IDYzOCA0 NzkgNjM4IDU5MiA1OTIgNTkyIDU5MiA1NDcgNTQ3IA0KNTAxIDQ1NiA0NTYgNDU2IDQ1NiA0NTYg NDU2IDcyOSA0MTAgNDU2IDQ1NiA0NTYgNDU2IDIyOCAyMjggMjI4IA0KMjI4IDQ1NiA0NTYgNDU2 IDQ1NiA0NTYgNDU2IDQ1NiA1NDkgNTAxIDQ1NiA0NTYgNDU2IDQ1NiA0MTAgNDU2IA0KNDEwIF0N Ci9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDQovRm9udERlc2NyaXB0b3IgMjMgMCBSDQo+Pg0K ZW5kb2JqDQoyMyAwIG9iag0KPDwNCi9UeXBlIC9Gb250RGVzY3JpcHRvcg0KL0ZvbnROYW1lIC9B cmlhbE5hcnJvdyxJdGFsaWMNCi9GbGFncyA5Ng0KL0ZvbnRCQm94IFsgLTI1MCAtMjI1IDk5NyA5 MzMgXQ0KL01pc3NpbmdXaWR0aCAyMjUNCi9TdGVtViA2NQ0KL1N0ZW1IIDY1DQovSXRhbGljQW5n bGUgLTExDQovQ2FwSGVpZ2h0IDkzMw0KL1hIZWlnaHQgNjUzDQovQXNjZW50IDkzMw0KL0Rlc2Nl bnQgMjI1DQovTGVhZGluZyAxNzkNCi9NYXhXaWR0aCA4MzENCi9BdmdXaWR0aCAzNjANCj4+DQpl bmRvYmoNCjIgMCBvYmoNClsgL1BERiAvVGV4dCAgXQ0KZW5kb2JqDQo1IDAgb2JqDQo8PA0KL0tp ZHMgWzQgMCBSIDEwIDAgUiAxNCAwIFIgMTcgMCBSIDI0IDAgUiAyNyAwIFIgXQ0KL0NvdW50IDYN Ci9UeXBlIC9QYWdlcw0KL1BhcmVudCAzNyAwIFINCj4+DQplbmRvYmoNCjMxIDAgb2JqDQo8PA0K L0tpZHMgWzMwIDAgUiAzNCAwIFIgXQ0KL0NvdW50IDINCi9UeXBlIC9QYWdlcw0KL1BhcmVudCAz NyAwIFINCj4+DQplbmRvYmoNCjM3IDAgb2JqDQo8PA0KL0tpZHMgWzUgMCBSIDMxIDAgUiBdDQov Q291bnQgOA0KL1R5cGUgL1BhZ2VzDQovTWVkaWFCb3ggWyAwIDAgODQyIDU5NSBdDQo+Pg0KZW5k b2JqDQoxIDAgb2JqDQo8PA0KL0NyZWF0b3IgKFBvd2VyUG9pbnQgKQ0KL0NyZWF0aW9uRGF0ZSAo U3VuZGF5LCBNYXJjaCAyNiwgMjAwMCAxMDowOToxMyBQTSkNCi9UaXRsZSAoRi1USU1FTFkuUERG KQ0KL0F1dGhvciAoVW5rbm93bikNCi9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgMy4wMiBm b3IgV2luZG93cykNCi9LZXl3b3JkcyAoKQ0KL1N1YmplY3QgKCkNCj4+DQplbmRvYmoNCjMgMCBv YmoNCjw8DQovUGFnZXMgMzcgMCBSDQovVHlwZSAvQ2F0YWxvZw0KL0RlZmF1bHRHcmF5IDM4IDAg Ug0KL0RlZmF1bHRSR0IgIDM5IDAgUg0KPj4NCmVuZG9iag0KMzggMCBvYmoNClsvQ2FsR3JheQ0K PDwNCi9XaGl0ZVBvaW50IFswLjk1MDUgMSAxLjA4OTEgXQ0KL0dhbW1hIDAuMjQ2OCANCj4+DQpd DQplbmRvYmoNCjM5IDAgb2JqDQpbL0NhbFJHQg0KPDwNCi9XaGl0ZVBvaW50IFswLjk1MDUgMSAx LjA4OTEgXQ0KL0dhbW1hIFswLjI0NjggMC4yNDY4IDAuMjQ2OCBdDQovTWF0cml4IFswLjQzNjEg MC4yMjI1IDAuMDEzOSAwLjM4NTEgMC43MTY5IDAuMDk3MSAwLjE0MzEgMC4wNjA2IDAuNzE0MSBd DQo+Pg0KXQ0KZW5kb2JqDQp4cmVmDQowIDQwDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMTYw NzkgMDAwMDAgbg0KMDAwMDAxNTczOSAwMDAwMCBuDQowMDAwMDE2Mjk3IDAwMDAwIG4NCjAwMDAw MDA3OTAgMDAwMDAgbg0KMDAwMDAxNTc3MyAwMDAwMCBuDQowMDAwMDEzNzIwIDAwMDAwIG4NCjAw MDAwMTM4NDAgMDAwMDAgbg0KMDAwMDAwMDAyMSAwMDAwMCBuDQowMDAwMDAwNzY4IDAwMDAwIG4N CjAwMDAwMDE5MzIgMDAwMDAgbg0KMDAwMDAxMzk2NSAwMDAwMCBuDQowMDAwMDAwOTMzIDAwMDAw IG4NCjAwMDAwMDE5MDkgMDAwMDAgbg0KMDAwMDAwMjk1MCAwMDAwMCBuDQowMDAwMDAyMDc4IDAw MDAwIG4NCjAwMDAwMDI5MjcgMDAwMDAgbg0KMDAwMDAwOTM3MCAwMDAwMCBuDQowMDAwMDE0MDky IDAwMDAwIG4NCjAwMDAwMDMwODMgMDAwMDAgbg0KMDAwMDAwOTM0NiAwMDAwMCBuDQowMDAwMDE0 MjA4IDAwMDAwIG4NCjAwMDAwMTQzMzEgMDAwMDAgbg0KMDAwMDAxNTQ1NSAwMDAwMCBuDQowMDAw MDEwNDY5IDAwMDAwIG4NCjAwMDAwMDk1NDIgMDAwMDAgbg0KMDAwMDAxMDQ0NiAwMDAwMCBuDQow MDAwMDExNDE2IDAwMDAwIG4NCjAwMDAwMTA2MDIgMDAwMDAgbg0KMDAwMDAxMTM5MyAwMDAwMCBu DQowMDAwMDEyNTYwIDAwMDAwIG4NCjAwMDAwMTU4ODkgMDAwMDAgbg0KMDAwMDAxMTU0OSAwMDAw MCBuDQowMDAwMDEyNTM3IDAwMDAwIG4NCjAwMDAwMTM1ODYgMDAwMDAgbg0KMDAwMDAxMjY5NCAw MDAwMCBuDQowMDAwMDEzNTYzIDAwMDAwIG4NCjAwMDAwMTU5NzkgMDAwMDAgbg0KMDAwMDAxNjM5 NSAwMDAwMCBuDQowMDAwMDE2NDgzIDAwMDAwIG4NCnRyYWlsZXINCjw8DQovU2l6ZSA0MA0KL1Jv b3QgMyAwIFINCi9JbmZvIDEgMCBSDQovSUQgWzxiZTBjMTJmZWUwNGRiNzc5NTgwNThiODUyOTRm MTZkZD48YmUwYzEyZmVlMDRkYjc3OTU4MDU4Yjg1Mjk0ZjE2ZGQ+XQ0KPj4NCnN0YXJ0eHJlZg0K MTY2NjENCiUlRU9GDQo= --=====================_4772692==_ Content-Type: text/plain; charset="us-ascii"; format=flowed ------------ Graham Klyne (GK@ACM.ORG) --=====================_4772692==_-- From owner-ietf-fax@mail.imc.org Mon Apr 10 07:30:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05248 for ; Mon, 10 Apr 2000 07:30:02 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA11605 for ietf-fax-bks; Mon, 10 Apr 2000 03:44:07 -0700 (PDT) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11601 for ; Mon, 10 Apr 2000 03:44:05 -0700 (PDT) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id TAA01331; Mon, 10 Apr 2000 19:47:31 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xmab01316; Mon, 10 Apr 00 19:47:19 +0900 Received: from canongw.cecn.canon.co.jp (canongw.cecn.canon.co.jp [150.61.8.7]) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA04782; Mon, 10 Apr 2000 19:47:19 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA24458; Mon, 10 Apr 2000 19:47:18 +0900 (JST) Received: from pcg-z505maeda ([172.22.33.253]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id TAA07547; Mon, 10 Apr 2000 19:44:09 +0900 (JST) Message-Id: <4.2.0.58.J.20000410193221.00a445a0@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 10 Apr 2000 19:55:13 +0900 To: Hiroshi Tamura , ietf-fax@imc.org From: MAEDA toru Subject: Re: [IETF-FAX] Addition to Adelaide meeting (ITU-T issue) In-Reply-To: <20000403113630Q.tamura@toda.ricoh.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Tamura-san, I request to send a follow-on communication which will reply to the ITU-T communication "Communication form SG8 on the use of Extended Internet Fax for ITU-T T.37 Full Mode" dated 04-Apr-1999 from Mr. Silbiger. Issues in the ITU-T communication are open. Regards, Toru MAEDA At 11:36 00/04/03 +0900, Hiroshi Tamura wrote: >Dear Colleagues, > >At Adelaide, unfortunately, we had no time to introduce ITU-T matters, >which were scheduled. As I said at Adelaide, I introduce them briefly, here. > >Specifically, for our plan for ITU-T, any suggesions are welcome. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >-------------- Begin ------------------ > >1 Report of SG8 February Meeting > >1.1 T.37 > >There were no proposals at the meeting. IETF-FAX WG draft charter >was introduced. Q4/SG8 confirmed the cooperation between IETF-FAX WG >and Q4/SG8, and agreed to continue it. Q4/SG8 proposed the plan >for T.37 extension. The plan was as follows. > >- Support for Full Mode enhancements >- Support for new image compression capabilities >- Support for new image transmission capabilities >- Support for Group 4 >- T.37 Gateway functionality >- T.37 over mobile packets networks >- T.37 quality of service > >But Q4/SG8 did not discuss them in detail. > >1.2 Re-organizing SGs in ITU-T > >February SG8 meeting was the final SG8 one in this study period >(1996-2000). ITU re-organizes itself every 4 years. >There is a WTSA(Plenary conference) in October. According to the results, >SG8 will be merged with other SGs. Anyway, Q4/SG8 will continue >as one of questions in a re-organized SG. > >2 Our plan for ITU-T > >2.1 Notice of our WG Status and other related matters > >IETF-FAX WG has started again. So, I believe it is necessary >to notify our WG status. The items are as follows. >- Our fixed charter itself >- Discussion matters(e.g. Internet drafts) >- Other WGs information > >2.2 Input of Internet drafts > >We have the four Internet drafts that we should consider >to input to ITU-T. But the three drafts related to FFPIM >are not TECHNICALLY mature. With regard to Implementers-draft, >it is an informative one. In fact, there are some issues that >we should modify. But this draft is meant for Simple mode and Eifax, >which we have already made. I believe it is better to input >to ITU-T, because the contents are very useful for T.37 implementers >as well as Simple/Eifax ones. > >2.3 Can we agree to send a letter and one draft to Q4/SG8 ? > >Q4/SG8 interim meeting will be held in June. >Can we agree to send them there ? > >If agreed, I will write a draft letter and circulate it here. > >-------------- End ------------------ > >Again, any comments are welcome. > >-- >Hiroshi Tamura, Ricoh Company, LTD. >Mail: tamura@toda.ricoh.co.jp >Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) ************************ 前田　徹 キヤノン(株)　映事第3技推部 ************************ From owner-ietf-fax@mail.imc.org Mon Apr 10 20:05:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07268 for ; Mon, 10 Apr 2000 20:05:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25195 for ietf-fax-bks; Mon, 10 Apr 2000 16:37:03 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25191 for ; Mon, 10 Apr 2000 16:37:01 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA25509; Tue, 11 Apr 2000 08:40:30 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA17059; Tue, 11 Apr 2000 08:40:29 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id IAA02839; Tue, 11 Apr 2000 08:35:13 +0900 (JST) To: ietf-fax@imc.org Cc: Claudio.Allocchio@elettra.trieste.it Subject: Re: [IETF-FAX] Addition to Adelaide meeting (ITU-T issue) X-Mailer: Mew version 1.94.1 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: <20000411084508X.tamura@toda.ricoh.co.jp> Date: Tue, 11 Apr 2000 08:45:08 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 18 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, I think we have a consensus to agree to send a letter and Implementers-draft. Next month I will circulate a draft letter to ITU-T. Please check it. For your information, ITU-T Q4/SG8 meeting will be held on June 12 - 15 at Gaithersburg, MD, USA. T.37 matter is one the agendas. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Wed Apr 12 05:02:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13955 for ; Wed, 12 Apr 2000 05:01:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA21474 for ietf-fax-bks; Wed, 12 Apr 2000 01:23:14 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA21464 for ; Wed, 12 Apr 2000 01:23:12 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id RAA10069; Wed, 12 Apr 2000 17:26:38 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id RAA27999; Wed, 12 Apr 2000 17:26:37 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id RAA02962; Wed, 12 Apr 2000 17:21:19 +0900 (JST) To: GK@dial.pipex.com Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org Subject: Re: Progressing content negotiation, timely delivery In-Reply-To: <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> References: <20000403113630Q.tamura@toda.ricoh.co.jp> <38EAEB3F.F758B39E@rdl.toshibatec.co.jp> <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> X-Mailer: Mew version 1.94.1 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: <20000412173119C.tamura@toda.ricoh.co.jp> Date: Wed, 12 Apr 2000 17:31:19 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 43 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Klyne-san, Just comments. > For content negotiation, see the slide headed "The big issue: receiver > state management". If there is a state in receiver, receiver wants to know whether incoming message is the first received message or the second one. I think identifier or something in sending message is necessary for this purpose. State: Idle, In-Negotiation, ..... for each id or something. In some implementations, receiver may keep the first received Profile S data during state:In-Negotiation, and if a timer expires receiver may print it. There may be no memory case in Negotiation, as your slides say. In this case, some methods in which receiver notify sender of receiver state may solve this situation. But difficult ? In fact, "State" in receiver is necessary for real implementation, irrespective of whether "State" is described in draft or not. Some should be described. Others remain implementation matter. But, I do not have specific ideas now. > For timely delivery, see the final three slides headed "The unresolved > challenge" and "Strawman proposal...". I do not understand well why "Compliance(Conformance ?)-required" is necessary. "DeliveryBy" and "DSN" ESMTP extensions are not enough to realize it ? And, What about the status of the referenced "draft-newman-deliver-..." ? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Wed Apr 12 08:50:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17677 for ; Wed, 12 Apr 2000 08:50:28 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA04275 for ietf-fax-bks; Wed, 12 Apr 2000 05:04:49 -0700 (PDT) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04271 for ; Wed, 12 Apr 2000 05:04:47 -0700 (PDT) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 12 Apr 2000 13:07:57 +0100 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2C7NR2FD; Wed, 12 Apr 2000 13:07:51 +0100 Message-Id: <4.2.2.20000412100803.00bbb730@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Apr 2000 12:01:51 +0100 To: Hiroshi Tamura From: Graham Klyne Subject: Re: Progressing content negotiation, timely delivery Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org In-Reply-To: <20000412173119C.tamura@toda.ricoh.co.jp> References: <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> <20000403113630Q.tamura@toda.ricoh.co.jp> <38EAEB3F.F758B39E@rdl.toshibatec.co.jp> <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-an, Thank you for your comments. I think that I maybe need to clarify some aspects of what I meant to say. The issue of receiver state information is raised because it has implications for the design and capacity of a receiving system. By receiver state, I mean that a receiver needs to remember that it has received an initial message AND that it has requested an alternative form of data. Without this, there is a possibility that message data may be silently lost, which is very much to be avoided. Receiver state MUST contain, as a minimum: - the fact that message data was received, and alternative data has been requested. - a unique message identifier - the time at which alternative This allows the receiver to re-issue a request for an alternative data format, or to report an error, if the requested data does not arrive in a reasonable time. It MAY also include: - a copy of the data originally received. This would allow the receiver to display the original data if alternative data is not received. - details of the data format supplied, and alternatives offered. This may allow improved diagnostics in the event that the alternative data requested is not received. At 05:31 PM 4/12/00 +0900, Hiroshi Tamura wrote: > > For content negotiation, see the slide headed "The big issue: receiver > > state management". > >If there is a state in receiver, receiver wants to know >whether incoming message is the first received message or the second one. This information should be implicit in the form of message, so this should not need to be explicitly part of the state maintained by a receiver. Only the _first_ message should contain the message disposition request indicating the sender's willingness to send alternative forms. In practice, a receiver would have implicit information about first- and subseqent- messages, because it would establish state information only in response to the first message. >I think identifier or something in sending message is necessary >for this purpose. Yes, I agree. This should be added in section 3.1 of the proposal. >State: Idle, In-Negotiation, ..... for each id or something. I think the only meaningful state here is "in negotiation" >In some implementations, receiver may keep the first received >Profile S data during state:In-Negotiation, and if a timer expires >receiver may print it. I agree this is the ideal situation. But I think we must recognize that some receivers may be unable to store message content for extended periods, so we have tried to avoid making this an absolute requirement. >There may be no memory case in Negotiation, as your slides say. >In this case, some methods in which receiver notify sender of >receiver state may solve this situation. But difficult ? I'm not sure what you mean by "no memory case". Do you mean that the receiver has insufficient memory to store state? In which case, I'd suggest that the receiver simply displays the received data and respond per "extended mode". Or do you mean that the receiver runs out of memory after entered negotiaton. I think the exact recovery path here would depend upon a number of factors: preferably, the receiver should display any data received; at least, it must display a diagnostic, and try to notify the sender of failure. I don't think there's any reason for the receiver to notify the sender of its internal state; I think that all the sender needs to know is: (a) that the receiver has asked for something different, (b) that the transfer has completed successfully, (c) that the transfer has failed, or (d) that it is waiting for one of the above responses from the receiver. >In fact, "State" in receiver is necessary for real implementation, >irrespective of whether "State" is described in draft or not. In a sense, I agree. But prior to e-mail based negotiation, the state information is very transient (e.g. for T.30, it is maintained only for the duration of a connection, when receiving an extended-mode fax, it exists only between receipt and disposition (e.g. printing) of the data. These are all characterized by having clear upper bounds on the "amount" of receiver state maintained at any instant in time. With e-mail based content negotiation, the number of outstanding messages a any time is not theoretically bounded. For a typical computer system, this is not really a problem as disk capacity is generally sufficient to deal with "arbitrary" amounts of state information (the capacity limits are so much greater than normal expected requirement that they don't normally represent a practical constraint). But for a "fax machine" style of receiver, memory is a scarce resource, so there is some conflict with the requirements of e-mail based content negotiation. >Some should be described. Others remain implementation matter. I agree. In talking about receiver state, what I am really raising is the issue of how to maintain bounds on the amount of receiver state that must be kept. I believe we have some reasonable ideas in this regard, but I want to be clear about the issue so that implementers can judge for themselves. > > For timely delivery, see the final three slides headed "The unresolved > > challenge" and "Strawman proposal...". > >I do not understand well why "Compliance(Conformance ?)-required" is >necessary. >"DeliveryBy" and "DSN" ESMTP extensions are not enough to realize it ? Your observation is very pertinent. For the purposes of SMTP transfer, the "compliance required" feature is not required and think there is a strong case for pursuing this proposal without that part. But consider the following scenario: +--------+ +-------+ +-----------+ +-----------+ | Sender |-->--| Relay |-->--| Receiving |-->--| Disposing | | MTA | | MTA | | MTA | | agent | +--------+ +-------+ +-----------+ +-----------+ <------SMTP-------> <-?-> The (possibly enhanced) DELIVERBY proposal concerns itself ONLY with the SMTP transfers. But for the purposes of timely delivery, the goal is not satisfied from a user perspective unless the disposition also completes in "timely" fashion. The thinking behind the "conformance required" idea is that the receiving MTA communicates with the disposing agent (in some unspecified way), and confirms final delivery of the message only if the disposing agent confirms that it will dispose of the message in timely fashion. Simply putting the message into a POP mailbox would not meet this criterion. This is all consistent with the fundamental strategy of given the sender total control over the whole process: if the disposing agent cannot communicate the required guarantee, delivery is not completed and the sender is duly notified. >And, What about the status of the referenced "draft-newman-deliver-..." ? I'm not certain, but I understand it is close to approval. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Apr 12 11:18:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24097 for ; Wed, 12 Apr 2000 11:18:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08146 for ietf-fax-bks; Wed, 12 Apr 2000 07:42:09 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08139 for ; Wed, 12 Apr 2000 07:42:05 -0700 (PDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 12 Apr 2000 09:01:57 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2VP8MY8P>; Wed, 12 Apr 2000 08:56:40 -0500 Message-ID: From: "Ra'ed Awdeh" To: ietf-fax@imc.org Subject: FoIP QoS requirements Date: Wed, 12 Apr 2000 08:56:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA486.ED2CDBFA" 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_01BFA486.ED2CDBFA Content-Type: text/plain Hi, Are you aware of any published work on FoIP QoS requirements? In other words, how much packet loss and delay it can tolerate? Thanks. Regards; Ra'ed ------_=_NextPart_001_01BFA486.ED2CDBFA Content-Type: text/html Content-Transfer-Encoding: quoted-printable FoIP QoS requirements

Hi,

Are you aware of any published work on = FoIP QoS requirements? In other words, how much packet loss and delay = it can tolerate? Thanks.

Regards;
Ra'ed


------_=_NextPart_001_01BFA486.ED2CDBFA-- From owner-ietf-fax@mail.imc.org Wed Apr 12 12:47:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27146 for ; Wed, 12 Apr 2000 12:47:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA12195 for ietf-fax-bks; Wed, 12 Apr 2000 09:27:06 -0700 (PDT) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12184 for ; Wed, 12 Apr 2000 09:27:03 -0700 (PDT) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 12 Apr 2000 17:30:17 +0100 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2C7NRJ1T; Wed, 12 Apr 2000 17:30:11 +0100 Message-Id: <4.2.2.20000412161341.00ae4ae0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Apr 2000 16:25:59 +0100 To: IETF fax WG From: Graham Klyne Subject: draft-ietf-fax-implementers-guide-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, I've just been going through some old notes regarding the -00 draft. I think they've mostly been caught, but I did notice a couple of comments/questions that might apply to the -01 draft. #g -- > Implementers Guide for Facsimile Using Internet Mail > > > >Abstract > > This document is intended for the implementers of > software which uses email to send to facsimiles using RFC 2305 and 2532. > This is an informational document and its guidelines do not supersede the ..........................................^^^^^^^^^^^^^^^^^^^^ "does not" > referenced documents. >5.1 IFD Placement in TIFF file & Profile S Constraints > >Low memory devices, which support resolutions greater than the required >Profile-S may be memory-constrained such that those devices cannot >properly handle arbitrary placement of TIFF IFDs within a TIFF file. > >To interoperate with a receiver that is constrained, it is strongly >recommended that senders always place the IFD at the beginning of the >TIFF-FX file when using any of the Profiles defined in RFC 2301. Do we want to say anything about low-memory senders? #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Apr 12 12:51:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27282 for ; Wed, 12 Apr 2000 12:51:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA12200 for ietf-fax-bks; Wed, 12 Apr 2000 09:27:07 -0700 (PDT) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12194 for ; Wed, 12 Apr 2000 09:27:06 -0700 (PDT) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 12 Apr 2000 17:30:17 +0100 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2C7NRJ1R; Wed, 12 Apr 2000 17:30:10 +0100 Message-Id: <4.2.2.20000412155803.00a3b9a0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Apr 2000 16:12:29 +0100 To: IETF fax WG From: Graham Klyne Subject: draft-ietf-fax-minaddr-v2-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Some minor comments... >draft-ietf-fax-minaddr-v2-00.txt >Minimal GSTN address format in Internet Mail >Abstract > > This memo describes a simple method of encoding GSTN addresses in the ..................................................................^ "(telephone numbers)" (For the benefit of the uninitiated.) > 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. > > 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 ..........................^^^^^^^^^^^^^^^ Strictly, I think "the MTA that is" should read "an MTA that handles messages for the domain" In the presence of MX records, etc., the right-hand-side does not necessarily name a single MTA. >2.1 Minimal "global-phone" definition > > The purpouse of global-phone element is to represent standard E.164 > numeric addresses [10] within a syntax for electronic mail addressing > that is compliant with standard e-mail specifications given in [1] > and [2]. > > The minimal supported syntax for global-phone element is as follows: > > global-phone = "+" 1*( DIGIT , written-sep ) I think this should be: # global-phone = "+" 1*( DIGIT / written-sep ) >2.2 The minimal "pstn-address" examples > > Some examples of minimal pstn-address follows: > > VOICE=+3940226338 > > FAX=+12027653000/T33S=6377 > > SMS=+33-1-88335215 > > Note: > only the use of registered service-selector and qualif-type1 > elements is allowed. The examples shown are just for illustration > purpouses. .......[-------] "purposes". >3. The e-mail address of the I-pstn device: mta-I-pstn > > An "I-pstn device" has got, among its characteristics, a unique ...........................^^^ Delete "got". >4.1 Multiple subaddresses [...] > Implementors' note: > The UA MAY accept multiple subaddress elements for the same > global-phone, but it MUST generate multiple "pstn-mbox" elements > when submitting the message to the MTA. I believe the "MAY" above should be "may". This refers to behaviour beyond the scope of this specification (i.e. user interface), and as such is not normative, even as an option. > 7.2: IANA Registration form template for new values of GSTN > address qualif-type1 keyword and value [...] > qualif-type1 "value" ABNF definition: > > abnf - ("abnf" MUST define the ABNF form of the qualif-type1 value. > The ABNF specification MUST be self-contained, using as basic > elements the tokens given in specification [4]. To avoid any > duplication (when appropriate), it MUST also use as building > non-basic tokens any already registered non-basic token from other This doesn't make sense ("use as building non-basic tokens"?) #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Apr 12 12:54:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27373 for ; Wed, 12 Apr 2000 12:54:31 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA12204 for ietf-fax-bks; Wed, 12 Apr 2000 09:27:08 -0700 (PDT) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12199 for ; Wed, 12 Apr 2000 09:27:06 -0700 (PDT) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 12 Apr 2000 17:30:16 +0100 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2C7NRJ1P; Wed, 12 Apr 2000 17:30:10 +0100 Message-Id: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Apr 2000 15:55:47 +0100 To: IETF fax WG From: Graham Klyne Subject: draft-ietf-fax-service-v2-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, I have some small comments. >draft-ietf-fax-service-v2-01.txt >A Simple Mode of Facsimile Using Internet Mail >SUMMARY > > This specification provides for "simple mode" carriage of facsimile > data over the Internet. Extensions to this document will follow. "over the Internet" seems rather vague. I suggest "using Internet e-mail" >1 SCOPE > > This specification defines a message-based facsimile communication ...............................^ Delete "a". >2.2.2 MIME > > IFax devices MUST be compliant with MIME [4], except as noted in > Appendix A. Do we want to say anything about support for multipart/alternative? MIME technically requires this, but I understand it is not widely implemented. >3.3 Address Formats Used by Offramps > > When a G3Fax device is identified by a telephone number, the entire > address used for the G3fax device, including the number and offramp > host reference MUST be contained within standard Internet mail > transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address > MAY be contained within message content fields, such as > and [2, 3], as appropriate. > > As for all Internet mail addresses, the left-hand-side (local- part) > of an address is not to be interpreted except by the MTA that is > named on the right-hand-side (domain). > > The telephone number format SHOULD conform to [11, 12]. Other > formats MUST be syntactically distinct from [11, 12]. I find this is not clear. What "other" is meant by "other formats"? Does this refer to e-mail addresses that do not refer to GSTN-connected fax machines? I also noted, looking at RFC 2304, that the address form: FAX=123456789@gateway.domain is not permitted. (i.e. no local-phone with FAX=) I understand that the standard was not intended to say anything about non-standard forms. But it's not clear to me whether the above example is just not-specified, or actually prohibited. A possible replacement for the final paragraph quoted above: # For fax machines that are accessed via a gateway to the GSTN, the address # format SHOULD conform to [11,12], including a fully qualified international # telephone number, per 'global-phone' [11]. For fax machines that are accessed # by other means, including local dialing plans, address formats used MUST be # syntactically distinct from the format defined by 'fax-mbox' [12]. >5.2.2 Resources consumed by dialout > [...] > Offramp gateways SHOULD provide the ability to authorize senders in > some manner to prevent unauthorized use of the offramp. There are no > standard techniques for authorization using Internet protocols. What is the status of the SMTP AUTH specification? Should it be cited here? >5.2.5 Message disclosure > > Users of G3Fax devices have an expectation of a level of message > privacy which is higher than the level provided by Internet mail > without security enhancements. > > This expectation of privacy by G3Fax users SHOULD be preserved as > much as possible. > > Sufficient physical and software control may be acceptable in > constrained environments. The usual mechanism for ensuring data > confidentially entail encryption, as discussed below. .........................^ "entails" #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Apr 12 17:48:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04123 for ; Wed, 12 Apr 2000 17:48:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA20038 for ietf-fax-bks; Wed, 12 Apr 2000 14:25:36 -0700 (PDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20031 for ; Wed, 12 Apr 2000 14:25:34 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA28142; Wed, 12 Apr 2000 14:28:41 -0700 (PDT) Date: Wed, 12 Apr 2000 14:28:41 -0700 (PDT) From: Dan Wing To: "Ra'ed Awdeh" cc: ietf-fax@imc.org Subject: Re: FoIP QoS requirements In-Reply-To: Message-ID: <0004121427530.18245-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What is "FoIP"? I'm guessing by your question that you're asking about T.38. This IETF WG doesn't work with T.38 but there are many on this list who may be able to answer your question, however. -Dan Wing On Wed, 12 Apr 2000 08:56 -0500, Ra'ed Awdeh wrote: > Hi, > > Are you aware of any published work on FoIP QoS requirements? In other > words, how much packet loss and delay it can tolerate? Thanks. > > Regards; > Ra'ed > > > From owner-ietf-fax@mail.imc.org Wed Apr 12 19:25:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05204 for ; Wed, 12 Apr 2000 19:25:09 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA22374 for ietf-fax-bks; Wed, 12 Apr 2000 15:56:59 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22369 for ; Wed, 12 Apr 2000 15:56:58 -0700 (PDT) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 12 Apr 2000 17:29:49 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <25CJS1CZ>; Wed, 12 Apr 2000 17:23:33 -0500 Message-ID: From: "Ra'ed Awdeh" To: "'Dan Wing'" , ietf-fax@imc.org Subject: RE: FoIP QoS requirements Date: Wed, 12 Apr 2000 17:05:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA4CD.BB00EB16" 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_01BFA4CD.BB00EB16 Content-Type: text/plain Yes I meant T.38 fax over IP. I am sorry if this is the wrong list. -Regards; Ra'ed > -----Original Message----- > From: Dan Wing [SMTP:dwing@cisco.com] > Sent: Wednesday, April 12, 2000 5:29 PM > To: Awdeh, Ra'ed [RICH3:2F21-M:EXCH] > Cc: ietf-fax@imc.org > Subject: Re: FoIP QoS requirements > > What is "FoIP"? I'm guessing by your question that you're asking about > T.38. This IETF WG doesn't work with T.38 but there are many on this > list who may be able to answer your question, however. > > -Dan Wing > > > On Wed, 12 Apr 2000 08:56 -0500, Ra'ed Awdeh wrote: > > > Hi, > > > > Are you aware of any published work on FoIP QoS requirements? In other > > words, how much packet loss and delay it can tolerate? Thanks. > > > > Regards; > > Ra'ed > > > > > > > ------_=_NextPart_001_01BFA4CD.BB00EB16 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FoIP QoS requirements

Yes I meant T.38 fax over IP. = I am sorry if this is the wrong list.

-Regards;
Ra'ed


    -----Original Message-----
    From:   Dan Wing [SMTP:dwing@cisco.com]
    Sent:   Wednesday, April 12, 2000 5:29 PM
    To:     Awdeh, Ra'ed [RICH3:2F21-M:EXCH]
    Cc:     ietf-fax@imc.org
    Subject:       = Re: FoIP QoS requirements

    What is "FoIP"?  I'm = guessing by your question that you're asking about
    T.38.  This IETF WG doesn't work = with T.38 but there are many on this
    list who may be able to answer your = question, however.

    -Dan Wing


    On Wed, 12 Apr 2000 08:56 -0500, Ra'ed = Awdeh wrote:

    > Hi,
    >
    > Are you aware of any published = work on FoIP QoS requirements? In other
    > words, how much packet loss and = delay it can tolerate? Thanks.
    >
    > Regards;
    > Ra'ed
    >
    >
    >

------_=_NextPart_001_01BFA4CD.BB00EB16-- From owner-ietf-fax@mail.imc.org Thu Apr 13 06:12:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25529 for ; Thu, 13 Apr 2000 06:12:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA08515 for ietf-fax-bks; Thu, 13 Apr 2000 02:42:57 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08510 for ; Thu, 13 Apr 2000 02:42:51 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA25512; Thu, 13 Apr 2000 18:46:25 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA10052; Thu, 13 Apr 2000 18:46:23 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id SAA03030; Thu, 13 Apr 2000 18:41:02 +0900 (JST) To: GK@dial.pipex.com Cc: ietf-fax@imc.org Subject: Re: draft-ietf-fax-service-v2-01.txt In-Reply-To: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> References: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> X-Mailer: Mew version 1.94.1 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: <20000413185107H.tamura@toda.ricoh.co.jp> Date: Thu, 13 Apr 2000 18:51:07 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 38 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A question. > I also noted, looking at RFC 2304, that the address form: > > FAX=123456789@gateway.domain > > is not permitted. (i.e. no local-phone with FAX=) FAX=+123456789@gateway.domain is permitted ? RFC2304 says, -------------------------------------------------------------------------- global-phone = "+" 1*( DIGIT , written-sep ) written-sep = ( "-" / "." ) The use of other dialling schemas for PSTN numbers (like private numbering plans or local dialling conventions) is also allowed. However, this does not preclude nor remove the minimal compulsory requirement to support the "global-phone" syntax as defined above. Any non "global-phone" dialling schema MUST NOT use the leading "+" between the "=" sign and the dialling string. The "+" sign is strictly reserved for the standard "global-phone" syntax. Note: The specification of these different dialling schemas is out of scope for this minimal specification. -------------------------------------------------------------------------- I am a little confused. -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Thu Apr 13 06:25:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25681 for ; Thu, 13 Apr 2000 06:25:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA08990 for ietf-fax-bks; Thu, 13 Apr 2000 02:59:39 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08986 for ; Thu, 13 Apr 2000 02:59:37 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA29194; Thu, 13 Apr 2000 19:03:12 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA13795; Thu, 13 Apr 2000 19:03:10 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id SAA03034; Thu, 13 Apr 2000 18:57:48 +0900 (JST) To: raed@nortelnetworks.com Cc: dwing@cisco.com, ietf-fax@imc.org Subject: RE: FoIP QoS requirements In-Reply-To: References: X-Mailer: Mew version 1.94.1 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: <20000413190753K.tamura@toda.ricoh.co.jp> Date: Thu, 13 Apr 2000 19:07:53 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 26 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ra'ed Awdeh san, > Yes I meant T.38 fax over IP. I am sorry if this is the wrong list. Unfortunately, T.38 issue is not main target here. > > > Are you aware of any published work on FoIP QoS requirements? In other > > > words, how much packet loss and delay it can tolerate? Thanks. To be able to transmit fax document between two G3fax at ends even through IP network, as normal GSTN fax transmission does. This is the minimum requirement. There are some timers in T.30. If a timer expires, transmission fails. Gateways manage to do something for it, considering network delays. There are not recommended methods/recommendations/..., now. Please go to Geneva(ITU-T). Am I right ? :-) -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Thu Apr 13 06:43:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26034 for ; Thu, 13 Apr 2000 06:43:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA10472 for ietf-fax-bks; Thu, 13 Apr 2000 03:13:33 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10463 for ; Thu, 13 Apr 2000 03:13:20 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA02040; Thu, 13 Apr 2000 19:16:58 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA16615; Thu, 13 Apr 2000 19:16:57 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA03038; Thu, 13 Apr 2000 19:11:36 +0900 (JST) To: GK@dial.pipex.com Cc: ietf-fax@imc.org Subject: Re: draft-ietf-fax-implementers-guide-01.txt In-Reply-To: <4.2.2.20000412161341.00ae4ae0@pop.dial.pipex.com> References: <4.2.2.20000412161341.00ae4ae0@pop.dial.pipex.com> X-Mailer: Mew version 1.94.1 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: <20000413192140M.tamura@toda.ricoh.co.jp> Date: Thu, 13 Apr 2000 19:21:40 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 25 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Klyne san, > >5.1 IFD Placement in TIFF file & Profile S Constraints > > > >Low memory devices, which support resolutions greater than the required > >Profile-S may be memory-constrained such that those devices cannot > >properly handle arbitrary placement of TIFF IFDs within a TIFF file. > > > >To interoperate with a receiver that is constrained, it is strongly > >recommended that senders always place the IFD at the beginning of the > >TIFF-FX file when using any of the Profiles defined in RFC 2301. > > Do we want to say anything about low-memory senders? The intension here is for low-memory receivers. Even Eifax machine may be a low-memory device. So, it is better for senders to place IFD at the beginning. I think we already agreed to this issue last year,,,,, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Thu Apr 13 07:21:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26728 for ; Thu, 13 Apr 2000 07:21:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA13679 for ietf-fax-bks; Thu, 13 Apr 2000 03:58:22 -0700 (PDT) Received: from toolbox.total.net (toolbox.total.net [154.11.89.179]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA13674 for ; Thu, 13 Apr 2000 03:58:21 -0700 (PDT) Received: (qmail 25132 invoked from network); 13 Apr 2000 11:02:02 -0000 Received: from unknown (HELO LOCALNAME) (154.5.103.11) by smtp.total.net with SMTP; 13 Apr 2000 11:02:02 -0000 Message-Id: <3.0.6.16.20000413070154.2247f396@total.net> X-Sender: mactag@total.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (16) Date: Thu, 13 Apr 2000 07:01:54 To: Hiroshi Tamura , raed@nortelnetworks.com From: Don Mactaggart Subject: RE: FoIP QoS requirements Cc: dwing@cisco.com, ietf-fax@imc.org, In-Reply-To: <20000413190753K.tamura@toda.ricoh.co.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: T.38 lacks info necessary to maintain T.30 session in presence of lost & delayed packets; we have solved this our way and it is time to get an interop group together. Are you in touch with Glenn Parsons ? --- Don At 07:07 PM 00/4/13 +0900, Hiroshi Tamura wrote: >Ra'ed Awdeh san, > >> Yes I meant T.38 fax over IP. I am sorry if this is the wrong list. > >Unfortunately, T.38 issue is not main target here. > >> > > Are you aware of any published work on FoIP QoS requirements? In other >> > > words, how much packet loss and delay it can tolerate? Thanks. > >To be able to transmit fax document between two G3fax at ends >even through IP network, >as normal GSTN fax transmission does. > >This is the minimum requirement. > >There are some timers in T.30. If a timer expires, transmission fails. >Gateways manage to do something for it, considering network delays. > >There are not recommended methods/recommendations/..., now. > >Please go to Geneva(ITU-T). Am I right ? :-) > >-- >Hiroshi Tamura, Ricoh Company, LTD. >Mail: tamura@toda.ricoh.co.jp >Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) > > From owner-ietf-fax@mail.imc.org Thu Apr 13 07:23:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26763 for ; Thu, 13 Apr 2000 07:23:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA13454 for ietf-fax-bks; Thu, 13 Apr 2000 03:50:59 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13450 for ; Thu, 13 Apr 2000 03:50:57 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA08993; Thu, 13 Apr 2000 19:54:36 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA23682; Thu, 13 Apr 2000 19:54:34 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA03046; Thu, 13 Apr 2000 19:49:13 +0900 (JST) To: GK@dial.pipex.com Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org Subject: Re: Progressing content negotiation, timely delivery In-Reply-To: <4.2.2.20000412100803.00bbb730@pop.dial.pipex.com> References: <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> <20000412173119C.tamura@toda.ricoh.co.jp> <4.2.2.20000412100803.00bbb730@pop.dial.pipex.com> X-Mailer: Mew version 1.94.1 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: <20000413195917Q.tamura@toda.ricoh.co.jp> Date: Thu, 13 Apr 2000 19:59:17 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 139 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Klyne san, Thank you for your clarification. > Receiver state MUST contain, as a minimum: > - the fact that message data was received, and alternative data has been > requested. > - a unique message identifier > - the time at which alternative > This allows the receiver to re-issue a request for an alternative data > format, or to report an error, if the requested data does not arrive in a > reasonable time. I agree. But, can the receiver re-issue the request again in the current draft ? > It MAY also include: > - a copy of the data originally received. This would allow the receiver to > display the original data if alternative data is not received. > - details of the data format supplied, and alternatives offered. This may > allow improved diagnostics in the event that the alternative data requested > is not received. I see. > >If there is a state in receiver, receiver wants to know > >whether incoming message is the first received message or the second one. > > This information should be implicit in the form of message, so this should > not need to be explicitly part of the state maintained by a receiver. Only > the _first_ message should contain the message disposition request > indicating the sender's willingness to send alternative forms. Does it mean, whether the mesaage from the sender includes "Disposition-Notification-Options:Alternative-available ..." or not ? > >State: Idle, In-Negotiation, ..... for each id or something. > > I think the only meaningful state here is "in negotiation" Yes. > >In some implementations, receiver may keep the first received > >Profile S data during state:In-Negotiation, and if a timer expires > >receiver may print it. > > I agree this is the ideal situation. But I think we must recognize that > some receivers may be unable to store message content for extended periods, > so we have tried to avoid making this an absolute requirement. Right. I agree to the avoiding. > >There may be no memory case in Negotiation, as your slides say. > >In this case, some methods in which receiver notify sender of > >receiver state may solve this situation. But difficult ? > I'm not sure what you mean by "no memory case". My intension is, The receiver has enough memory when the first message comes. It requests an alternative to sender with "alternative-preferred". But, when the subsequent message comes, it may have little memory due to some reasons. > I don't think there's any reason for the receiver to notify the sender of > its internal state; I think that all the sender needs to know is: > (a) that the receiver has asked for something different, > (b) that the transfer has completed successfully, > (c) that the transfer has failed, or > (d) that it is waiting for one of the above responses from the receiver. OK, I see. So, the sender possibly may do 3rd try(transmission) after 2nd MDN from the receiver is not good.... Am I right ? > represent a practical constraint). But for a "fax machine" style of > receiver, memory is a scarce resource, so there is some conflict with the > requirements of e-mail based content negotiation. Right. > >Some should be described. Others remain implementation matter. > > I agree. > > In talking about receiver state, what I am really raising is the issue of > how to maintain bounds on the amount of receiver state that must be > kept. I believe we have some reasonable ideas in this regard, but I want > to be clear about the issue so that implementers can judge for themselves. I hope it in the next version. > >I do not understand well why "Compliance(Conformance ?)-required" is > >necessary. > >"DeliveryBy" and "DSN" ESMTP extensions are not enough to realize it ? > But consider the following scenario: > > +--------+ +-------+ +-----------+ +-----------+ > | Sender |-->--| Relay |-->--| Receiving |-->--| Disposing | > | MTA | | MTA | | MTA | | agent | > +--------+ +-------+ +-----------+ +-----------+ > > <------SMTP-------> <-?-> > > The (possibly enhanced) DELIVERBY proposal concerns itself ONLY with the > SMTP transfers. But for the purposes of timely delivery, the goal is not > satisfied from a user perspective unless the disposition also completes in > "timely" fashion. > > The thinking behind the "conformance required" idea is that the receiving > MTA communicates with the disposing agent (in some unspecified way), and > confirms final delivery of the message only if the disposing agent confirms > that it will dispose of the message in timely fashion. Simply putting the > message into a POP mailbox would not meet this criterion. This is all > consistent with the fundamental strategy of given the sender total control > over the whole process: if the disposing agent cannot communicate the > required guarantee, delivery is not completed and the sender is duly notified. I see the background. A question. In reality, what should MTA do in order to meet "Compliance-required" ? -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Thu Apr 13 08:23:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28285 for ; Thu, 13 Apr 2000 08:23:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA15765 for ietf-fax-bks; Thu, 13 Apr 2000 04:58:21 -0700 (PDT) Received: from hose.pipex.net (hose.mail.pipex.net [158.43.128.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA15758 for ; Thu, 13 Apr 2000 04:58:19 -0700 (PDT) Received: from GK-VAIO (usern003.uk.uudial.com [193.149.81.36]) by hose.pipex.net (Postfix) with ESMTP id C988E4528; Thu, 13 Apr 2000 13:02:00 +0100 (BST) Message-Id: <4.2.2.20000413112010.00bb1cb0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 13 Apr 2000 11:22:59 +0100 To: Hiroshi Tamura From: Graham Klyne Subject: Re: draft-ietf-fax-service-v2-01.txt Cc: ietf-fax@imc.org In-Reply-To: <20000413185107H.tamura@toda.ricoh.co.jp> References: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-san, Thank you for pointing out my error... At 06:51 PM 4/13/00 +0900, you wrote: >A question. > > > I also noted, looking at RFC 2304, that the address form: > > > > FAX=123456789@gateway.domain > > > > is not permitted. (i.e. no local-phone with FAX=) > >FAX=+123456789@gateway.domain > >is permitted ? Yes, that's clearly OK. >RFC2304 says, >-------------------------------------------------------------------------- > global-phone = "+" 1*( DIGIT , written-sep ) > > written-sep = ( "-" / "." ) > > The use of other dialling schemas for PSTN numbers (like private > numbering plans or local dialling conventions) is also allowed. > However, this does not preclude nor remove the minimal compulsory > requirement to support the "global-phone" syntax as defined above. I missed that -- thanks. > Any non "global-phone" dialling schema MUST NOT use the leading "+" > between the "=" sign and the dialling string. The "+" sign is > strictly reserved for the standard "global-phone" syntax. And that! >I am a little confused. No -- it's my fault. I looked at the ABNF, and not at the text. Sorry to confuse you. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Thu Apr 13 08:26:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28331 for ; Thu, 13 Apr 2000 08:26:43 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA15775 for ietf-fax-bks; Thu, 13 Apr 2000 04:58:23 -0700 (PDT) Received: from hose.pipex.net (hose.mail.pipex.net [158.43.128.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA15769 for ; Thu, 13 Apr 2000 04:58:22 -0700 (PDT) Received: from GK-VAIO (usern003.uk.uudial.com [193.149.81.36]) by hose.pipex.net (Postfix) with ESMTP id 5E0C94586; Thu, 13 Apr 2000 13:02:02 +0100 (BST) Message-Id: <4.2.2.20000413112432.00a5af00@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 13 Apr 2000 11:39:41 +0100 To: Hiroshi Tamura From: Graham Klyne Subject: Re: Progressing content negotiation, timely delivery Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org In-Reply-To: <20000413195917Q.tamura@toda.ricoh.co.jp> References: <4.2.2.20000412100803.00bbb730@pop.dial.pipex.com> <4.2.2.20000405093306.00b13f00@pop.dial.pipex.com> <20000412173119C.tamura@toda.ricoh.co.jp> <4.2.2.20000412100803.00bbb730@pop.dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:59 PM 4/13/00 +0900, Hiroshi Tamura wrote: >I agree. >But, can the receiver re-issue the request again in the current draft ? Yes, I believe that is allowed (but not required). I must check the draft wording. > > >If there is a state in receiver, receiver wants to know > > >whether incoming message is the first received message or the second one. > > > > This information should be implicit in the form of message, so this should > > not need to be explicitly part of the state maintained by a > receiver. Only > > the _first_ message should contain the message disposition request > > indicating the sender's willingness to send alternative forms. > >Does it mean, >whether the mesaage from the sender includes >"Disposition-Notification-Options:Alternative-available ..." or not ? Yes, this would indicate a sender's initial "offer to negotiate" I shall look at the wording to make this clearer. > > >There may be no memory case in Negotiation, as your slides say. > > >In this case, some methods in which receiver notify sender of > > >receiver state may solve this situation. But difficult ? > > > I'm not sure what you mean by "no memory case". > > > >My intension is, >The receiver has enough memory when the first message comes. >It requests an alternative to sender with "alternative-preferred". >But, when the subsequent message comes, it may have little memory >due to some reasons. Ah, I see. I think that the receiver must (almost) _always_ reserve enough memory to process an arbitrary incoming message -- including a response to "alternative-preferred". (This is not the same as being able to *store* an arbitrary incoming message.) I imagine a system will be able to (a) save-to-disk, or (b) print data as it arrives. (I am assuming that disk overflow is not a concern.) > > I don't think there's any reason for the receiver to notify the sender of > > its internal state; I think that all the sender needs to know is: > > (a) that the receiver has asked for something different, > > (b) that the transfer has completed successfully, > > (c) that the transfer has failed, or > > (d) that it is waiting for one of the above responses from the receiver. > >OK, I see. >So, the sender possibly may do 3rd try(transmission) after 2nd MDN >from the receiver is not good.... Am I right ? I would say that this is possible, but not expected behaviour. > > But consider the following scenario: > > > > +--------+ +-------+ +-----------+ +-----------+ > > | Sender |-->--| Relay |-->--| Receiving |-->--| Disposing | > > | MTA | | MTA | | MTA | | agent | > > +--------+ +-------+ +-----------+ +-----------+ > > > > <------SMTP-------> <-?-> > > > > The (possibly enhanced) DELIVERBY proposal concerns itself ONLY with the > > SMTP transfers. But for the purposes of timely delivery, the goal is not > > satisfied from a user perspective unless the disposition also completes in > > "timely" fashion. > > > > The thinking behind the "conformance required" idea is that the receiving > > MTA communicates with the disposing agent (in some unspecified way), and > > confirms final delivery of the message only if the disposing agent > confirms > > that it will dispose of the message in timely fashion. Simply putting the > > message into a POP mailbox would not meet this criterion. This is all > > consistent with the fundamental strategy of given the sender total control > > over the whole process: if the disposing agent cannot communicate the > > required guarantee, delivery is not completed and the sender is duly > notified. > >I see the background. >A question. In reality, what should MTA do in order to >meet "Compliance-required" ? (1) It must be able to communicate with the "disposing agent" at the time a message is delivered. (In a fax machine style of device, I assume this functionality would be integrated in a single unit, so noi problem.) (2) The "disposing agent" must recognize the requested "conformance required" (whatever that may be), and indicate that it can satisfy the stated requirement (e.g. to print or display the message within a given time interval, or indicate failure to do so). The actual mechanism of communication between the MTA and disposing agent is not defined (and I believe cannot be defined at this level). #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Fri Apr 14 04:14:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04190 for ; Fri, 14 Apr 2000 04:14:13 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA14034 for ietf-fax-bks; Fri, 14 Apr 2000 00:32:37 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14025 for ; Fri, 14 Apr 2000 00:32:34 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id QAA28957; Fri, 14 Apr 2000 16:35:32 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id QAA02473; Fri, 14 Apr 2000 16:35:27 +0900 (JST) Received: from [133.185.137.6] by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 14 Apr 2000 07:35:29 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id QAA02024; Fri, 14 Apr 2000 16:34:42 +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 QAA17312; Fri, 14 Apr 2000 16:34:03 +0900 (JST) Received: from ifptoyo.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id QAA29156; Fri, 14 Apr 2000 16:34:01 +0900 (JST) Message-Id: <200004140738.AA00241@ifptoyo.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Fri, 14 Apr 2000 16:38:46 +0900 To: Graham Klyne Cc: IETF fax WG Subject: Re: draft-ietf-fax-service-v2-01.txt In-Reply-To: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> References: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Klyne-san, Thank you for your comments. I comment below. Graham Klyne wrote: > >>SUMMARY >> >> This specification provides for "simple mode" carriage of facsimile >> data over the Internet. Extensions to this document will follow. > >"over the Internet" seems rather vague. I suggest "using Internet e-mail" Yes, I agree. > > >>1 SCOPE >> >> This specification defines a message-based facsimile communication >...............................^ >Delete "a". Thank you. > > >>2.2.2 MIME >> >> IFax devices MUST be compliant with MIME [4], except as noted in >> Appendix A. > >Do we want to say anything about support for multipart/alternative? MIME >technically requires this, but I understand it is not widely implemented. No, I think we don't need to say anything about support for multipart/alternative in this draft. It's enough that Implementer's Guide say about multipart/alternative. > > >>3.3 Address Formats Used by Offramps >> >> When a G3Fax device is identified by a telephone number, the entire >> address used for the G3fax device, including the number and offramp >> host reference MUST be contained within standard Internet mail >> transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address >> MAY be contained within message content fields, such as >> and [2, 3], as appropriate. >> >> As for all Internet mail addresses, the left-hand-side (local- part) >> of an address is not to be interpreted except by the MTA that is >> named on the right-hand-side (domain). >> >> The telephone number format SHOULD conform to [11, 12]. Other >> formats MUST be syntactically distinct from [11, 12]. > >I find this is not clear. What "other" is meant by "other formats"? Does >this refer to e-mail addresses that do not refer to GSTN-connected fax >machines? Other formats means private formats which don't conform to [11,12]. I want to keep this paragraph as it is. > > >>5.2.2 Resources consumed by dialout >> > >[...] > >> Offramp gateways SHOULD provide the ability to authorize senders in >> some manner to prevent unauthorized use of the offramp. There are no >> standard techniques for authorization using Internet protocols. > >What is the status of the SMTP AUTH specification? Should it be cited here? I don't know the specification of SMTP AUTH. I think that S/MIME or PGP/MIME is needed for authentication and authorization rather than SMTP. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Fri Apr 14 05:29:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04726 for ; Fri, 14 Apr 2000 05:29:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA18105 for ietf-fax-bks; Fri, 14 Apr 2000 01:56:02 -0700 (PDT) Received: from helicon.office-logic.com ([212.250.89.13]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA18098 for ; Fri, 14 Apr 2000 01:55:58 -0700 (PDT) Received: from office-logic.com (helicon.office-logic.com [212.250.89.13]) by helicon.office-logic.com id 2paqfspp0 with ESMTP (SUBMIT) (Courier Evaluation); Fri, 14 Apr 2000 09:58:04 +0100 Message-ID: <38F6DD82.7DF62F16@office-logic.com> Date: Fri, 14 Apr 2000 08:57:38 +0000 From: Brian Stafford Organization: OfficeLogic International Ltd X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: IETF fax WG CC: "Toyoda, Kiyoshi" , Graham Klyne Subject: Re: draft-ietf-fax-service-v2-01.txt References: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> <200004140738.AA00241@ifptoyo.rdmg.mgcs.mei.co.jp> 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 "Toyoda, Kiyoshi" wrote: > >[...] > > > >> Offramp gateways SHOULD provide the ability to authorize senders in > >> some manner to prevent unauthorized use of the offramp. There are no > >> standard techniques for authorization using Internet protocols. > > > >What is the status of the SMTP AUTH specification? Should it be cited here? > > I don't know the specification of SMTP AUTH. I think that S/MIME or > PGP/MIME is needed for authentication and authorization rather than > SMTP. The provider of an offramp service needs to be assured of the identity of the sender of the fax (presumably that's who gets the bill), not the previous hop MTA. This implies that the message itself must contain the identity of the sender. In a very simple case, the offramp operator might have a database which maps sender email addresses to authorisation credentials. A digital signature in the message will provide non-repudiation of the sender's identity, within the limitations of the S/MIME or PGP concepts of trust. Although the former case is wide open to abuse and forgery, it seems to satisfy the statement that "Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp" and avoids the need for normative references to S/MIME or PGP MIME. Indeed any ad-hoc sender authentication would satisfy this requirement. The second sentence "There are no standard techniques for authorization using Internet protocols" diverts the reader's attention from authentication of the fax message and its sender to the protocol which delivered the message to the offramp. Perhaps the second sentence should be deleted to avoid misleading the reader. All that said, a standardised method to authenticate the sender of a fax would be a good thing to have. -- Brian Stafford, OfficeLogic International Ltd. PGP fingerprint: 23DE 0A02 95B2 EC3C D521 0CD1 97D8 6BF2 B673 DC11 From owner-ietf-fax@mail.imc.org Fri Apr 14 07:52:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06141 for ; Fri, 14 Apr 2000 07:52:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA25767 for ietf-fax-bks; Fri, 14 Apr 2000 04:22:44 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25763 for ; Fri, 14 Apr 2000 04:22:42 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id UAA20445; Fri, 14 Apr 2000 20:26:14 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id UAA29198; Fri, 14 Apr 2000 20:26:08 +0900 (JST) Received: from [133.185.137.6] by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 14 Apr 2000 11:26:10 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id UAA10219; Fri, 14 Apr 2000 20:25:22 +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 UAA26092; Fri, 14 Apr 2000 20:24:43 +0900 (JST) Received: from ifptoyo.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id UAA11778; Fri, 14 Apr 2000 20:24:43 +0900 (JST) Message-Id: <200004141129.AA00242@ifptoyo.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Fri, 14 Apr 2000 20:29:28 +0900 To: Brian Stafford Cc: IETF fax WG , Graham Klyne Subject: Re: draft-ietf-fax-service-v2-01.txt In-Reply-To: <38F6DD82.7DF62F16@office-logic.com> References: <38F6DD82.7DF62F16@office-logic.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Brian Stafford wrote: >Although the former case is wide open to abuse and forgery, it seems to >satisfy the statement that "Offramp gateways SHOULD provide the ability to >authorize senders in some manner to prevent unauthorized use of the offramp" >and avoids the need for normative references to S/MIME or PGP MIME. >Indeed any ad-hoc sender authentication would satisfy this requirement. I agree that there are some manner to prevent unauthorized use of the offramp and avoids the need for normative references to S/MIME or PGP/MIME. S/MIME or PGP/MIME is one of the way. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Fri Apr 14 08:40:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06648 for ; Fri, 14 Apr 2000 08:40:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA26690 for ietf-fax-bks; Fri, 14 Apr 2000 05:06:35 -0700 (PDT) Received: from ricky.ssg.gunter.af.mil (RICKY.SSG.gunter.af.mil [143.158.254.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26685 for ; Fri, 14 Apr 2000 05:06:32 -0700 (PDT) From: Robert.Tucker@Gunter.AF.mil Received: from ricky.ssg.gunter.af.mil (root@localhost) by ricky.ssg.gunter.af.mil with ESMTP id HAA10400 for ; Fri, 14 Apr 2000 07:09:51 -0500 (CDT) Received: from fsjubj01.ssg.gunter.af.mil (fsjubj01.gunter.af.mil [143.158.17.101]) by ricky.ssg.gunter.af.mil with ESMTP id HAA10392 for ; Fri, 14 Apr 2000 07:09:51 -0500 (CDT) Received: by fsjubj01.gunter.af.mil with Internet Mail Service (5.5.2650.21) id <2XF2AR46>; Fri, 14 Apr 2000 07:09:49 -0500 Message-ID: To: ietf-fax@imc.org Subject: FW: FW: Notification: Inbound Mail Failure Date: Fri, 14 Apr 2000 07:09:48 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Please remove the individual listed below from your database. They are no >longer at this location and the mail is causing rejects at this location > >Robert E Tucker >Email Administrator > >-----Original Message----- >From: Gunter Exchange Administrator >Sent: Thursday, April 13, 2000 7:34 AM >To: Gunter Exchange Administrator >Subject: Notification: Inbound Mail Failure > > >The following recipients did not receive the attached mail. A NDR was not >sent to the originator for the following recipients for one of the following >reasons: > > > * The Delivery Status Notification options did not request failure >notification, or requested no notification. > > * The message was of precedence bulk. > > > >NDR reasons are listed with each recipient, along with the notification >requested for that recipient, >or the precedence. > > Gregory.Cothran@Gunter.AF.mil > MSEXCH:IMS:ORGANIZATION:GUNTER-ANNEX:FSJUBJ02 0 (000C05A6) Unknown >Recipient > Precedence: bulk > >The message that caused this notification was: > > > <> > >----- >Message-ID: <4.2.2.20000413112432.00a5af00@pop.dial.pipex.com> >From: GK@dial.pipex.com >To: tamura@toda.ricoh.co.jp >Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org >Subject: Re: Progressing content negotiation, timely delivery >Date: Thu, 13 Apr 2000 05:39:41 -0500 >X-Mailer: Internet Mail Service (5.5.2650.21) >List-Unsubscribe: > >At 07:59 PM 4/13/00 +0900, Hiroshi Tamura wrote: > >I agree. > >But, can the receiver re-issue the request again in the current draft ? > >Yes, I believe that is allowed (but not required). I must check the draft >wording. > > > > >If there is a state in receiver, receiver wants to know > > > >whether incoming message is the first received message or the second >one. > > > > > > This information should be implicit in the form of message, so this >should > > > not need to be explicitly part of the state maintained by a > > receiver. Only > > > the _first_ message should contain the message disposition request > > > indicating the sender's willingness to send alternative forms. > > > >Does it mean, > >whether the mesaage from the sender includes > >"Disposition-Notification-Options:Alternative-available ..." or not ? > >Yes, this would indicate a sender's initial "offer to negotiate" > >I shall look at the wording to make this clearer. > > > > > >There may be no memory case in Negotiation, as your slides say. > > > >In this case, some methods in which receiver notify sender of > > > >receiver state may solve this situation. But difficult ? > > > > > I'm not sure what you mean by "no memory case". > > > > > > > >My intension is, > >The receiver has enough memory when the first message comes. > >It requests an alternative to sender with "alternative-preferred". > >But, when the subsequent message comes, it may have little memory > >due to some reasons. > >Ah, I see. > >I think that the receiver must (almost) _always_ reserve enough memory to >process an arbitrary incoming message -- including a response to >"alternative-preferred". (This is not the same as being able to *store* an >arbitrary incoming message.) I imagine a system will be able to (a) >save-to-disk, or (b) print data as it arrives. (I am assuming that disk >overflow is not a concern.) > > > > I don't think there's any reason for the receiver to notify the sender >of > > > its internal state; I think that all the sender needs to know is: > > > (a) that the receiver has asked for something different, > > > (b) that the transfer has completed successfully, > > > (c) that the transfer has failed, or > > > (d) that it is waiting for one of the above responses from the receiver. > > > >OK, I see. > >So, the sender possibly may do 3rd try(transmission) after 2nd MDN > >from the receiver is not good.... Am I right ? > >I would say that this is possible, but not expected behaviour. > > > > > But consider the following scenario: > > > > > > +--------+ +-------+ +-----------+ +-----------+ > > > | Sender |-->--| Relay |-->--| Receiving |-->--| Disposing | > > > | MTA | | MTA | | MTA | | agent | > > > +--------+ +-------+ +-----------+ +-----------+ > > > > > > <------SMTP-------> <-?-> > > > > > > The (possibly enhanced) DELIVERBY proposal concerns itself ONLY with the > > > SMTP transfers. But for the purposes of timely delivery, the goal is >not > > > satisfied from a user perspective unless the disposition also completes >in > > > "timely" fashion. > > > > > > The thinking behind the "conformance required" idea is that the >receiving > > > MTA communicates with the disposing agent (in some unspecified way), and > > > confirms final delivery of the message only if the disposing agent > > confirms > > > that it will dispose of the message in timely fashion. Simply putting >the > > > message into a POP mailbox would not meet this criterion. This is all > > > consistent with the fundamental strategy of given the sender total >control > > > over the whole process: if the disposing agent cannot communicate the > > > required guarantee, delivery is not completed and the sender is duly > > notified. > > > >I see the background. > >A question. In reality, what should MTA do in order to > >meet "Compliance-required" ? > >(1) It must be able to communicate with the "disposing agent" at the time a >message is delivered. (In a fax machine style of device, I assume this >functionality would be integrated in a single unit, so noi problem.) > >(2) The "disposing agent" must recognize the requested "conformance >required" (whatever that may be), and indicate that it can satisfy the >stated requirement (e.g. to print or display the message within a given >time interval, or indicate failure to do so). > >The actual mechanism of communication between the MTA and disposing agent >is not defined (and I believe cannot be defined at this level). > >#g > >------------ >Graham Klyne >(GK@ACM.ORG) ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Fri Apr 14 10:18:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08079 for ; Fri, 14 Apr 2000 10:18:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA27939 for ietf-fax-bks; Fri, 14 Apr 2000 06:28:52 -0700 (PDT) Received: from msw.mimesweeper.com (msw.mimesweeper.com [194.168.90.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27935 for ; Fri, 14 Apr 2000 06:28:50 -0700 (PDT) Received: from bell.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 14 Apr 2000 14:32:22 +0100 Received: from GK-VAIO (gk-vaio.mimesweeper.com [194.168.90.137]) by bell.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2C7NR3TG; Fri, 14 Apr 2000 14:32:04 +0100 Message-Id: <4.2.2.20000414132118.00c2b350@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 14 Apr 2000 13:23:52 +0100 To: "Toyoda, Kiyoshi" From: Graham Klyne Subject: Re: draft-ietf-fax-service-v2-01.txt Cc: IETF fax WG In-Reply-To: <200004141129.AA00242@ifptoyo.rdmg.mgcs.mei.co.jp> References: <38F6DD82.7DF62F16@office-logic.com> <38F6DD82.7DF62F16@office-logic.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 08:29 PM 4/14/00 +0900, Toyoda, Kiyoshi wrote: >I agree that there are some manner to prevent unauthorized use of the >offramp and avoids the need for normative references to S/MIME or >PGP/MIME. S/MIME or PGP/MIME is one of the way. A quick survey of RFCs reveals the following with relevance to SMTP and authentication. (There may be others, including S/MIME and OpenPGP.) 2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD) 2554 SMTP Service Extension for Authentication. J. Myers. March 1999. (Format: TXT=20534 bytes) (Status: PROPOSED STANDARD) 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R. Gellens. August 1999. (Format: TXT=16302 bytes) (Status: PROPOSED STANDARD) #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Fri Apr 14 12:56:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10709 for ; Fri, 14 Apr 2000 12:56:12 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA00779 for ietf-fax-bks; Fri, 14 Apr 2000 09:19:08 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00775 for ; Fri, 14 Apr 2000 09:19:07 -0700 (PDT) Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id JAA26622 for ; Fri, 14 Apr 2000 09:22:54 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.0.20000414090330.00d48ef0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 14 Apr 2000 09:22:17 -0700 To: IETF fax WG From: Dave Crocker Subject: Re: draft-ietf-fax-service-v2-01.txt In-Reply-To: <38F6DD82.7DF62F16@office-logic.com> References: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> <200004140738.AA00241@ifptoyo.rdmg.mgcs.mei.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:57 AM 4/14/00 +0000, Brian Stafford wrote: >"Toyoda, Kiyoshi" wrote: > > >What is the status of the SMTP AUTH specification? Should it be cited > here? > > I don't know the specification of SMTP AUTH. I think that S/MIME or > > PGP/MIME is needed for authentication and authorization rather than > > SMTP. SMTP AUTH is gradually being deployed. It does not yet seem to be widely available. However, I agree that it is not the correct choice, for most fax-over-email. SMTP is a "direct" mechanism, between the SMTP sender and the SMTP receiver, and SMTP AUTH therefore only works for one SMTP "hop". However the originator of a fax-over-email and the gateway typically are separated by multiple SMTP relays (or "hops"). Therefore, security mechanisms based on wrapping something around the object, rather than around the relay channel, are appropriate. So yes, PGP or S/MIME are the best choices. >A digital signature in the message will provide non-repudiation of the >sender's >identity, within the limitations of the S/MIME or PGP concepts of trust. In talking with my friends who are security experts, I find the use of the term 'non-repudiation" holds a special place. Standard PGP and S/MIME mechanisms are adequate for "authentication" which validates that a signature is associated with a purported originator. "Non-repudiation of originator" requires being able to prove to an independent third party that the signature is both valid and took place at a particular moment in time. (That is, non-repudiation is designed to resolve a claim that the key used for the signature was compromised and that, therefore, someone else used it.) There are no standard mechanisms for non-repudiation of originator for Internet mail, yet. The existing mechanisms DO permit validating the identity of the purported originator. >The second sentence "There are no standard techniques for authorization >using Internet protocols" diverts the reader's attention from authentication The problem is that authorization is a different mechanism from authentication. A gateway does not only need to know who sent the fax but whether that sender is authorized to use the gateway. There are no widely deployed authorization mechanisms for the Internet, although IMAP probably was the most widely used. Hence a gateway and a fax originator must have some prior arrangement, using non-standard mechanisms. It might be appropriate to change the text, to separate discussion of authentication from authorization, to avoid confusion. >All that said, a standardised method to authenticate the sender of a fax would >be a good thing to have. Yes. It would be wonderful. Perhaps the new working group can explore this, although it is likely to be both difficult and beyond the basic scope of the new effort. On the other hand, a store-and-forward email-based authorization standard would have much broader utility than just for use of outbound fax-over-email gateways. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-ietf-fax@mail.imc.org Fri Apr 14 15:16:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13253 for ; Fri, 14 Apr 2000 15:16:24 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03697 for ietf-fax-bks; Fri, 14 Apr 2000 11:38:17 -0700 (PDT) Received: from mauve.innosoft.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03692 for ; Fri, 14 Apr 2000 11:38:16 -0700 (PDT) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.1-1 #35243) id <01JO827YOX2800020J@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Fri, 14 Apr 2000 11:41:52 -0800 (PST) Date: Fri, 14 Apr 2000 11:16:47 -0800 (PST) Subject: Re: draft-ietf-fax-service-v2-01.txt In-reply-to: "Your message dated Fri, 14 Apr 2000 09:22:17 -0700" <4.3.0.20000414090330.00d48ef0@mail.bayarea.net> To: Dave Crocker Cc: IETF fax WG Message-id: <01JO83P6GNG600020J@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <4.2.2.20000412152926.00b2f640@pop.dial.pipex.com> <200004140738.AA00241@ifptoyo.rdmg.mgcs.mei.co.jp> <38F6DD82.7DF62F16@office-logic.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 08:57 AM 4/14/00 +0000, Brian Stafford wrote: > >"Toyoda, Kiyoshi" wrote: > > > >What is the status of the SMTP AUTH specification? Should it be cited > > here? > > > I don't know the specification of SMTP AUTH. I think that S/MIME or > > > PGP/MIME is needed for authentication and authorization rather than > > > SMTP. > SMTP AUTH is gradually being deployed. Actually, deployment has been quite rapid, on both the client and server side. And there is every indication that this trend will continue and likely accelerate. This isn't because of FAX or any other "new" service. It is because of an old problem: Spam. Most sites now implement anti-relaying policies. This in turn means that in order to get access from outside the site to the site's relays you have to use some kind of authentication. There are two ways this is being done: SMTP-after-POP and SMTP AUTH. The former doesn't work in quite a few cases (separate POP and SMTP servers, for example) and scales quite poorly. The latter works quite well and, depending on the authentication scheme used, scales well too. So, once again we see that unless you have a true "killer app" your best bet on getting a service deployed is to piggyback it on fixing some pressing problem. It isn't pretty, but it works. > It does not yet seem to be widely > available. I don't agree. There is one case where deployment is problematic, and that's where there's a huge installed base of relative old clients with no good way to upgrade them. But pressure to upgrade clients to the latest and greatest (which in almost every case these days gets you AUTH support) is unrelenting because of other factors. So this problem is likely to be transient even in such cases. > However, I agree that it is not the correct choice, for most > fax-over-email. SMTP is a "direct" mechanism, between the SMTP sender and > the SMTP receiver, and SMTP AUTH therefore only works for one SMTP > "hop". Not true. Properly configured, the AUTH extension can carry authentication credentials across multiple hops. This is what the AUTH MAIL FROM parameter is all about. > However the originator of a fax-over-email and the gateway > typically are separated by multiple SMTP relays (or "hops"). This is only a real issue when they are in separate administrative domains. And there are other problems when this is the case -- problems you get into below. > Therefore, security mechanisms based on wrapping something around the > object, rather than around the relay channel, are appropriate. So yes, PGP > or S/MIME are the best choices. Both PGP and S/MIME have been around a lot longer than SMTP AUTH, yet in my experience I see effectively zero deployment. > > The second sentence "There are no standard techniques for authorization > > using Internet protocols" diverts the reader's attention from authentication > The problem is that authorization is a different mechanism from > authentication. A gateway does not only need to know who sent the fax but > whether that sender is authorized to use the gateway. There are no widely > deployed authorization mechanisms for the Internet, although IMAP probably > was the most widely used. > Hence a gateway and a fax originator must have some prior arrangement, > using non-standard mechanisms. This equates to having overlapping administrative domains. This in turn means SMTP AUTH can be used. Mind you, I'm not claiming that multi-hop SMTP AUTH is the best possible mechanism to use for this sort of thing. But present-day reality is that hop-by-hop security mechanisms are deploying quite rapidly. (The TLS SMTP extension is deploying too, albeit not as rapidly since it doesn't have the push of a problem behind it.) And end-to-end mechanisms, which have been around a lot longer and have been advocated a lot longer, aren't. I don't like this situation, but I'm a realist. I'd rather use something that's there than wait for something that isn't there and I have no confidence ever will be. Especially when I've already played the waiting game for over 10 years, with at least 5 different standards, and gotten nowhere. Ned From owner-ietf-fax@mail.imc.org Sat Apr 15 16:55:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07023 for ; Sat, 15 Apr 2000 16:55:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA00482 for ietf-fax-bks; Sat, 15 Apr 2000 13:20:36 -0700 (PDT) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00478 for ; Sat, 15 Apr 2000 13:20:34 -0700 (PDT) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id QAA03512; Sat, 15 Apr 2000 16:09:37 -0400 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id ; Sat, 15 Apr 2000 16:21:35 -0400 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F0257D9DD@nhmail1.admin.brooktrout.com> From: David Duehren To: Don Mactaggart , Hiroshi Tamura , raed@nortelnetworks.com Cc: dwing@cisco.com, ietf-fax@imc.org, glenn.parsons@nortel.ca Subject: RE: FoIP QoS requirements Date: Sat, 15 Apr 2000 16:21:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: T.38 intentionally did not want to include these type of algorithms in the standard because it is up to individual implementors. We can add signals to T.38 if necessary to support standard procedures. However, in my experience, most "spoofing" is handled locally in the gateway and does not require gateway to gateway communication. David Duehren T.38 Editor v: 781-433-9402 f: 781-433-9202 dwd@brooktrout.com > -----Original Message----- > From: Don Mactaggart [mailto:mactag@total.net] > Sent: Thursday, April 13, 2000 3:02 AM > To: Hiroshi Tamura; raed@nortelnetworks.com > Cc: dwing@cisco.com; ietf-fax@imc.org; glenn.parsons@nortel.ca > Subject: RE: FoIP QoS requirements > > > > T.38 lacks info necessary to maintain T.30 session in presence of > lost & delayed packets; we have solved this our way and it is time > to get an interop group together. Are you in touch with Glenn > Parsons ? > > --- Don > > At 07:07 PM 00/4/13 +0900, Hiroshi Tamura wrote: > >Ra'ed Awdeh san, > > > >> Yes I meant T.38 fax over IP. I am sorry if this is the wrong list. > > > >Unfortunately, T.38 issue is not main target here. > > > >> > > Are you aware of any published work on FoIP QoS > requirements? In other > >> > > words, how much packet loss and delay it can tolerate? Thanks. > > > >To be able to transmit fax document between two G3fax at ends > >even through IP network, > >as normal GSTN fax transmission does. > > > >This is the minimum requirement. > > > >There are some timers in T.30. If a timer expires, > transmission fails. > >Gateways manage to do something for it, considering network delays. > > > >There are not recommended methods/recommendations/..., now. > > > >Please go to Geneva(ITU-T). Am I right ? :-) > > > >-- > >Hiroshi Tamura, Ricoh Company, LTD. > >Mail: tamura@toda.ricoh.co.jp > >Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) > > > > > From owner-ietf-fax@mail.imc.org Mon Apr 17 05:56:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28060 for ; Mon, 17 Apr 2000 05:56:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA25998 for ietf-fax-bks; Mon, 17 Apr 2000 02:21:43 -0700 (PDT) Received: from mail.usadatanet.net ([209.177.0.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25990 for ; Mon, 17 Apr 2000 02:21:42 -0700 (PDT) Received: from usadatanet.net (unverified [208.51.157.6]) by mail.usadatanet.net (Vircom SMTPRS 4.0.179) with SMTP id for ; Mon, 17 Apr 2000 05:07:19 -0400 Date: Mon, 17 Apr 2000 05:07:19 -0400 Message-ID: To: Engineering Professional From: Ryan Dunham Subject: $150 3D INJECTION MOLD FLOW ANALYSIS IN 48-HOURS Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: THIS IS A ONE TIME MAILING, DON'T MISS THIS OPPORTUNITY! EARN DISCOUNTS BY RECOMMENDING OUR SERVICES TO YOUR CUSTOMERS! EARN 15% COMMISSION AS A SALES REP! Recent advances in mold flow analysis software allow us to offer 3D mold flow analysis services starting at $150 with a 48-Hour turn around. We work directly from your CAD files. Results include the following: PART and/or RUNNER ANALYSIS, PRESSURE DROP, WELD LINES, AIR TRAPS, COOLING TIME, FILL TIME, SINK MARK ANALYSIS, FLOW ORIENTATION, FLOW FRONT TEMPERATURE, RESIN SELECTION, AND GATE LOCATIONS. Taking advantage of injection mold flow analysis during design will: 1) Help you to add value to your services and stand out as a high tech company. 2) Help you reduce the amount of plastic in your parts and runners, saving money. 3) Help you to uncover problems before the tool is made, saving time and money. 4) Provide you with the information necessary to improve quality. PLEASE CALL US @ (518)210-4933 From owner-ietf-fax@mail.imc.org Thu Apr 20 01:19:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22898 for ; Thu, 20 Apr 2000 01:19:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA08825 for ietf-fax-bks; Wed, 19 Apr 2000 21:30:44 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08821 for ; Wed, 19 Apr 2000 21:30:42 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA01064 for ; Thu, 20 Apr 2000 13:34:53 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA06869 for ; Thu, 20 Apr 2000 13:34:52 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id NAA03492 for ; Thu, 20 Apr 2000 13:29:16 +0900 (JST) To: ietf-fax@imc.org Subject: [IETF-FAX] Simple Mode Test Report in CIAJ X-Mailer: Mew version 1.94.1 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: <20000420133946V.tamura@toda.ricoh.co.jp> Date: Thu, 20 Apr 2000 13:39:46 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, For your information, Japanese manufactures had a test about Simple mode. There is a report about it in English. Please refer to the following. http://www.ciaj.or.jp/ciaj/ciaj-e/quart/vol-19/1903.html -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Wed Apr 26 20:35:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07262 for ; Wed, 26 Apr 2000 20:35:00 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA20295 for ietf-fax-bks; Wed, 26 Apr 2000 16:30:50 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20291 for ; Wed, 26 Apr 2000 16:30:48 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA07166; Thu, 27 Apr 2000 08:35:34 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA18580; Thu, 27 Apr 2000 08:35:33 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id IAA04057; Thu, 27 Apr 2000 08:29:43 +0900 (JST) To: ietf-fax@imc.org Cc: paf@swip.net, ned.freed@innosoft.com Subject: [IETF-FAX] draft meeting minutes at Adelaide X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <20000427084039Y.tamura@toda.ricoh.co.jp> Date: Thu, 27 Apr 2000 08:40:39 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 324 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear colleagues, Sorry for being late. Our draft meeting minutes are below. Would you please check, correct and modify it, as soon as possible ? ^^^^^^^^^^^^^^^^^^^ ############ Begin ############# ------------------------------------------------------------------------- ------------------------------------------------------------------------- IETF FAX-Ext Group meeting was held at 15:30-17:50 on March 30. ------------------------------------------------------------------------ 1 Opening ------------------------------------------------------------------------ New co-chairs(Mr. Allocchio and Mr. Tamura) introduced themselves. They thanked the out-going chair, Mr. Rafferty and the achievements of our working group. The meeting agenda itself was introduced and accepted. ------------------------------------------------------------------------ 2 Charter ------------------------------------------------------------------------ This is the first meeting since new charter was created. New charter was discussed. Concerning the phrase "full equivalence of T.30 service", a question about the relation with T.38 was raised. T.38 describes the procedure for Real-Time G3 fax over IP networks. It is NOT a service over Internet mail, which Fax working group has been studying for years. The group confirmed to continue the study of the specification that is equivalent to T.30 service over Internet mail. There was an opinion that the phrase "universal messaging issues" should move and be included in the first sentence in the first paragraph. The group agreed it. [[[Allocchio-san will modify this part to the suitable ones.]]] Concerning interconnecting the GSTN fax services, there are onramp and offramp gateway related issues. But they have not been deeply discussed so far in the group. The group confirmed there are things to do for these issues. The group confirmed the Implementers' Guide is useful for quality of service. The group confirmed FFPIM is a base for equivalence of T.30 service. It includes capability negotiation, in which a sender can transmit the "best" fax image the receiver indicates. There was an opinion about the use of RESCAP protocol for negotiation. A question about document authentication issue was raised. There are PGP, S/MIME, digital signature, and so on. The group confirmed to study the authentication under FFPIM. Related to FFPIM, the group confirmed TIFF-FX extensions like JBIG2 should be included. The target date of initial drafts of the extensions was modified as Jun 2000. Concerning the schema, it remains Sep 2000. The group confirmed to continue the cooperation with ITU-T and other IETF WGs such as VPIM. The group agreed to the charter. Modified charter will be circulated. ------------------------------------------------------------------------ 3 Status of internet drafts ------------------------------------------------------------------------ 1) Internet drafts waiting for RFC - draft-ietf-fax-feature-schema-v2-01.txt - draft-ietf-fax-feature-T30-mapping-03.txt The chair introduced these are in the queue by IESG review and will be approved soon. 2) Internet drafts waiting for Draft Standard. - draft-ietf-fax-tiff-fx-04.txt The chair introduced the interworking report was circulated and there are no problems. ADs will review it. Related to this document, the status of draft-ietf-fax-tiff-regbis-00.txt (Updated RFC2302)was introduced. [After the meeting: The out-going chair(Mr. Rafferty) told this draft is dependent on RFC2302. He suggests draft-ietf-fax-tiff-regbis-00.txt should be BCP, because it only contains the IANA registration information.] - draft-ietf-fax-service-v2-01.txt There are dependency problems(DSN, IMAP4 and Addressing). Concerning DSN, there is one idea in order not to be dependent on DSN. It was circulated in ML. For others, the group confirmed to wait for being Draft standards. The right format of the results of Interworking (FaxConnect2) is necessary. Mr. Ohno, who was responsible for FaxConnect2 at Japan, will report it with other key people. - draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt Interworking is not enough, especially for /T33S issue. T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress). It is kind of an application profile. There are fax machines that support T.30 SUB signal. But there are very few implementations about T.33. A question was raised about how to validate if two independent implementations interwork for addressing. About this question, there was an opinion it is that gateways can handle the specified address correctly. ------------------------------------------------------------------------ 4 On-going Internet drafts ------------------------------------------------------------------------ 1) draft-ietf-fax-ffpim-00.txt Mr. Crocker introduced it. FFPIM abbreviates Full-mode Fax Profile for Internet Mail. This specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability, timeliness and capability negotiation for Internet mail that is on a par with classic T.30 facsimile. About timeliness, it refers to draft-ietf-fax-timely-delivery-00.txt. About capability negotiation, it refers to draft-ietf-fax-content-negotiation-01.txt 2) draft-ietf-fax-timely-delivery-00.txt Mr. Klyne mainly introduced it. This specification defines a set of capabilities which permits an originator to request that the email transport system give a particular timeliness in delivery and then assures if the system will report the success or failure of that request. Specifically, it provides "while you wait" delivery of a message, with overall end-to-end transmission times of similar order to those for fax(seconds rather than minutes). It is also designed to operate within the ESMTP extension framework, allowing the sender to decide fallback to traditional e-mail if timely delivery service is unavailable. This can be achieved by the three ESMTP extensions(DSN, DELIVERBY, CONFORMANCE-REQUIRED). DELIVERBY imposes a responsibility on MTAs to complete delivery within a specified time. CONFORMANCE-REQUIRED imposes responsibility on MTAs to complete delivery in conformance with stated requirements, or not to deliver the message. There was the following comments about timelines. Page-by-page confirmation like T.30 cannot be done. Those kinds of confirmation are not necessary over Internet-mail. There was an comment that all MTAs should be changed to configure it. Mr. Klyne also commented the reverse(DSN return) path is not considered now and it should be done for complete timeliness. 3) draft-ietf-fax-content-negotiation-01.txt Mr. Klyne mainly introduced it. This specification uses a post-hoc technique that permits an originator to send the best version known by the originator to be supported by the recipient and then sending a better version the recipient requests it. There are the following goals. - Normal behavior with ordinary e-mail - No "administrative non-messages" - Work with current simple- and extended-mode fax systems - Recovery from stale cached capability information - Possible low-memory device implementation Sender specifies MDN option "Alternative-available" and alternative features in "Content-alternative". Receiver indicates "alternative- preferred" disposition-modifier-extension and its capabilities in MDN. Sender selects alternative format based on receiver's capabilities. Negotiation case example and optimized one were introduced. A question was raised about negotiation mechanism. Mr. Klyne emphasized it is sender who judges the capabilities indicated by receiver and selects the format. He also notified the Receiver's state issue. 4) draft-ietf-fax-implementers-guide-01.txt Ms. Cancio introduced it. This guide addresses implementations of the followings. - RFCs 2305, 2532, 2301 - RFC 2298 in connection with RFC 2532 - Others related as needed Users want to know if returned MDN indicates Main body text or TIFF attachments. There are no suitable disposition-types. This draft describes guides on how to express, using the existing definitions. It also describes TIFF interoperability issue, including the issue of low-end limited memory embedded recipients. There are controversies that how many TIFF problems should be included and if examples should reflect desired best practice to accomplish model or not. There were suggestions on Subject field and first part text of MDN as follows. - Subject "Return Receipt:", followed by original subject field text "Disposition Notification:" followed by original subject field text - First part text "This is a Return Receipt for the mail that you sent to … etc. The message and attached file may have been printed or saved. This is no guarantee that the message has been read or understood." There was an indication as open issues that MDN new disposition-types (e.g. "telephone line busy" etc.) and MDN message part identification (main body vs. attachment etc.) should be addressed as standard track (other internet drafts). There were the following comments. In other mail applications, there are similar issues. MDN extension is considered in other WGs. The group confirmed to refine this draft. ------------------------------------------------------------------------ 5 TIFF-FX extensions ------------------------------------------------------------------------ Mr. McIntyre introduced Tiff-fx extensions. There are the following two extensions. 1) New field values and/or relaxed constraints - higher resolutions 300x600, 600x600, 400x800, 600x1200 and 1200x1200 are introduced. - MRC (more than 3 MRC layers) Arranged in mask and foreground pairs. It is beneficial to synthetic images. - MRC (multi-strip background and foreground layers) It is to reduce overhead of IFDs when there is no change in coding parameters between strips (i.e. cases where multiple IFDs are not needed and a single IFD will do) by removing constraint requiring separate IFD for each TIFF strip 2) New fields and/or profiles - More than one profile within document . allow use of more than one profiles within a document . add new MultiFaxProfile field to the GlobalParameters IFD . use of the MultiFaxProfile field is signaled by a FaxProfile field value of X'FF' - JBIG2 (T.88) (Black and White, Color) JBIG2 boosts compression of text-like documents by 3x or more by retaining similar shapes across multiple images. There are 3 ways in which JBIG2 may be used in TIFF-FX. One is in B&W case and two are in Color case. Two new profiles, 3 new fields and a new value for an existing field may be required to accommodate the three usage - Annotation It brings life to raster images by accommodating a limited level of editability. The result is increased desktop citizenship and a significant step towards realization of integrated messaging. There are 3 forms(information annotation, quality annotation and tag annotation) of annotation to be considered. New fields and new values for existing fields may be required to accommodate the three forms. He will submit the internet-drafts. ------------------------------------------------------------------------ 6 Fax Gateway issue ------------------------------------------------------------------------ Mr. Kitagawa explained new proposal with the use of HTTP and CGI, concerning Fax Offramp issues. In his ideas, users put only a telephone number into a device which is connected to Internet. The device accesses to a directory server and resolves the addressing information for the number by getting it from the directory server. He emphasized the gateway local policy. This issue may possibly be solved in ENUM WG. The group confirmed the discussion should take place in both Fax WG and Enum WG. No internet draft exists. Therefore, he will submit the internet-draft about it. ------------------------------------------------------------------------ 7 ITU-T issue ------------------------------------------------------------------------ There was no time to introduce ITU related matter, as scheduled. Therefore, the chair promised to circulate this issue in ML soon. [After the meeting: The chair circulated the report of February SG8 meeting and the information of re-organizing ITU-T in ML. Q4/SG8 confirmed to continue cooperation between IETF Fax WG and them. They will be merged into new SGs and continue to study. Plan for T.37 extension such as support for Full-mode enhancements, new image compression method, and T.37 gateway functionaliy was introduced. The group agreed to send a letter and Implementer's Guide draft to Q4/SG8.] ------------------------------------------------------------------------ 8 Closing ------------------------------------------------------------------------ The meeting finished. ############ End ############# -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Thu Apr 27 13:55:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04502 for ; Thu, 27 Apr 2000 13:55:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18047 for ietf-fax-bks; Thu, 27 Apr 2000 10:22:35 -0700 (PDT) Received: from ananke.eastgw.xerox.com (root@ananke.xerox.com [208.140.33.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18043 for ; Thu, 27 Apr 2000 10:22:32 -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 NAA25269; Thu, 27 Apr 2000 13:27:14 -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 KAA21745; Thu, 27 Apr 2000 10:27:11 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Apr 2000 10:27:11 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A2888@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'Hiroshi Tamura'" , ietf-fax@imc.org Cc: paf@swip.net, ned.freed@innosoft.com Subject: RE: [IETF-FAX] draft meeting minutes at Adelaide Date: Thu, 27 Apr 2000 10:27:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Please allow me to first congratulate the co-chairs on the fine job they have done in conducting the meeting and generating the draft minutes. I have one comment on the draft meeting minutes extract below: ---snip--- > 2) Internet drafts waiting for Draft Standard. > > - draft-ietf-fax-tiff-fx-04.txt > > The chair introduced the interworking report was circulated > and there are no problems. ADs will review it. Related to > this document, the status of draft-ietf-fax-tiff-regbis-00.txt > (Updated RFC2302)was introduced. > The AD indicated, during the meeting, that he was not aware that draft-ietf-fax-tiff-fx-04.txt was submitted and is in queue for IESG Draft Standard consideration. He had agreed to confirm and provide status with respect to this draft. Would it be appropriate that the minutes include a reference to the AD's confirmation of Draft Standard status? ---snip--- From owner-ietf-fax@mail.imc.org Thu Apr 27 14:32:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05062 for ; Thu, 27 Apr 2000 14:32:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA18587 for ietf-fax-bks; Thu, 27 Apr 2000 11:04:09 -0700 (PDT) Received: from nic.cafax.se (IDENT:root@nic.cafax.se [192.71.228.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18583 for ; Thu, 27 Apr 2000 11:04:07 -0700 (PDT) Received: from [147.28.0.69] (dhcp-69.psg.com [147.28.0.69]) by nic.cafax.se (8.9.1a/8.9.1) with ESMTP id UAA00640; Thu, 27 Apr 2000 20:08:32 +0200 (MEST) Mime-Version: 1.0 X-Sender: paf@127.0.0.1 Message-Id: In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE067A2888@mercury.ADOC.xerox.com> References: <51B8ABCE456FD111899900805F6FD6EE067A2888@mercury.ADOC.xerox.com> Date: Thu, 27 Apr 2000 11:07:07 -0700 To: "McIntyre, Lloyd" , "'Hiroshi Tamura'" , ietf-fax@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [IETF-FAX] draft meeting minutes at Adelaide Cc: ned.freed@innosoft.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: At 10.27 -0700 00-04-27, McIntyre, Lloyd wrote: >The AD indicated, during the meeting, that he was not aware that >draft-ietf-fax-tiff-fx-04.txt was submitted and is in queue for IESG Draft >Standard consideration. I was not the AD being at the meeting, but I can let you know that it is NOT part of the work items for the IESG. If the wg want it to be, you have to request an IETF wide last call from the ADs Ned and myself. What I saw in the minutes was that the AD which was present at the meeting (not me) agreed on reading the document, which is a different thing than being a work item for the IESG. Sorry for being picky, but I want to make it clear that the document is still in the hands of the WG. Patrik Area Director, Applications Area, IETF From owner-ietf-fax@mail.imc.org Fri Apr 28 04:31:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25947 for ; Fri, 28 Apr 2000 04:31:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA29790 for ietf-fax-bks; Fri, 28 Apr 2000 00:53:16 -0700 (PDT) Received: from mauve.innosoft.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA29784 for ; Fri, 28 Apr 2000 00:53:14 -0700 (PDT) From: ned.freed@innosoft.com Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.1-1 #35243) id <01JOQ8NIEFTS00004R@MAUVE.INNOSOFT.COM> for ietf-fax@imc.org; Fri, 28 Apr 2000 00:58:01 -0800 (PST) Date: Fri, 28 Apr 2000 00:55:48 -0800 (PST) Subject: RE: [IETF-FAX] draft meeting minutes at Adelaide In-reply-to: "Your message dated Thu, 27 Apr 2000 11:07:07 -0700" To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: "McIntyre, Lloyd" , "'Hiroshi Tamura'" , ietf-fax@imc.org, ned.freed@innosoft.com Message-id: <01JOR1AQ93AA00004R@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <51B8ABCE456FD111899900805F6FD6EE067A2888@mercury.ADOC.xerox.com> <51B8ABCE456FD111899900805F6FD6EE067A2888@mercury.ADOC.xerox.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 10.27 -0700 00-04-27, McIntyre, Lloyd wrote: > >The AD indicated, during the meeting, that he was not aware that > >draft-ietf-fax-tiff-fx-04.txt was submitted and is in queue for IESG Draft > >Standard consideration. > I was not the AD being at the meeting, but I can let you know that it > is NOT part of the work items for the IESG. > If the wg want it to be, you have to request an IETF wide last call > from the ADs Ned and myself. > What I saw in the minutes was that the AD which was present at the > meeting (not me) agreed on reading the document, which is a different > thing than being a work item for the IESG. That's exactly what happened: I agreed to review the document and provide feedback. The authors/WG have several options after that, as Patrik says. (I hope to have it done over the weekend, along with a bunch of others.) Ned