From owner-ietf-fax@mail.imc.org Sun Sep 3 23:55: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 XAA16745 for ; Sun, 3 Sep 2000 23:55:41 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA14938 for ietf-fax-bks; Sun, 3 Sep 2000 20:03:16 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14934 for ; Sun, 3 Sep 2000 20:03:12 -0700 (PDT) Received: by bulls.mei.co.jp (8.11.0/3.7W) with ESMTP id e8433Lb19040; Mon, 4 Sep 2000 12:03:21 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id MAA25191; Mon, 4 Sep 2000 12:03:19 +0900 (JST) Received: from [133.185.137.6] by m-bb.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 4 Sep 2000 03:03:20 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id MAA09601; Mon, 4 Sep 2000 12:03:18 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id MAA26744; Mon, 4 Sep 2000 12:02:34 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id MAA28837; Mon, 4 Sep 2000 12:03:17 +0900 (JST) Message-Id: <200009040307.AA00657@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Mon, 04 Sep 2000 12:07:39 +0900 To: Claudio.Allocchio@elettra.trieste.it, tamura@toda.ricoh.co.jp Cc: ietf-fax@imc.org Subject: Implementation Report of RFC2304 Interworking test 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: Allocchio-san and Tamura-san Hiroshi Tamura wrote in the draft minutes of FAX WG at Pittsburgh >It was confirmed that "formal" report is necessary for request of >Draft Standard consideration. I made the draft of report about RFC2304 interworing test according to the format of "Implementation Reports" published on the IETF WEB site. Please find attaced text below. ---------------------------------------------------------------------- RFC2304 IMPLEMENTATION REPORT This report describes the implementation and interoperability testing of RFC2304 "Minimal FAX address format in Internet Mail". The test was held on the 28th June 2000 in Japan. The following independently implemented and jointly tested RFC2304. Matsushita Graphic Communication Systems Inc. TOYOCOM Inc. This report is organized in 2 sections. Section 1 describes the method and results of RFC2304 interoperability testing. Section 2 describes the independent RFC2304 implementations, by implementor. RFC2304 is the application of RFC2303 generic specification to FAX addresses. ----------------------------------------------------------------------- SECTION 1: RFC2304 INTEROPERABILITY TESTING ----------------------------------------------------------------------- 1. Testing Method 1-1. TOYOCOM sends the data to Internet Fax (IFAX) of M.G.C.S. (figure 1) . --------- ------------ ---------- ------ | Gateway | | IFAX | |Onramp GW | | | | TOYOCOM | ------->| M.G.C.S. |------>| DX-2000 |----->| PC | |_________| Internet|____________| PSTN |__________| LAN |______| figure 1 1)OnRamp Gateway of TOYOCOM sends the data with the following address formula. FAX=+81312345677@ifax.mgcs.mei.co.jp FAX=+81312345677/T33S=1234@ifax.mgcs.mei.co.jp FAX=+81312345677/T33S=5678@ifax.mgcs.mei.co.jp FAX+81-3-12345677@ifax.mgcs.mei.co.jp FAX=+81312345677/T33S=1234@ifax.mgcs.mei.co.jp and FAX=+81312345677/T33S=5678@ifax.mgcs.mei.co.jp /FAX=+81-3-12345677/T33S=1234/@ifax.mgcs.mei.co.jp and /FAX=+81.3.12345677/T33S=5678/@ifax.mgcs.mei.co.jp 2)IFax of M.G.C.S. sends the fax to DX-2000 with the addresss 03-12345677 including sub-address 1234 and/or 5678. 3)DX-2000(IFAX made by Panafax) sends e-mail to PC which has the corresponding e-mail address of the sub address. DX-2000 is used for verification method of sub address field in FIF. 1-2. M.G.C.S. sends the data to the OffRamp Gateway of TOYOCOM (figure 2) . --------- ------------ ---------- ------ | IFAX | | Gateway | |Onramp GW | | | | M.G.C.S | ------->| TOYOCOM |------>| DX-2000 |----->| PC | |_________| Internet|____________| PSTN |__________| LAN |______| figure 2 1)M.G.C.S. sends the data to the OffRamp Gateway of TOYOCOM (figure 2). FAX=+81312345677@ifax.toyocom.co.jp FAX=+81312345677/T33S=1234@ifax.toyocom.co.jp etc. 2),3) repeat same procedure as article 2-1. 3. Results We satisfied the items of "RFC2304 Interworking Configuration Matrix" which has deliverd to Fax Connect II. (http://www.imc.org/imc-faxconnect/) The items are below. 1) Minimum Specification (MUST) All implementations supporting this FAX over e-mail address format MUST supports as a minimum the specification described in this document(RFC 2304) 2) qualif-type1 element (REQUIRED) The minimal addressing for the fax service also requires support for a "qualif-type1" elment. This element is an OPTIONAL element of the fax address, but its support, when present, is REQUIRED. 3) Fax address minimum specification (REQUIRED) The minimal specification of a fax in e-mail address is: fax-address = fax-mbox["T33S="sub-addr] fax-mbox = "FAX="global-phone 4) Multiple T.33 Subaddresses (MUST) In case a particular service requires multiple T.33 subaddresses, and these subaddresses need to be given on the same "fax-mbox", multiple "fax-email" elements will be used. ----------------------------------------------------------------------- SECTION 2: RFC2304 IMPLEMENTATIONS ----------------------------------------------------------------------- Name of implementation: MGCS Internet Fax Organization: Matsushita Graphic Communication Systems Inc. Platforms: original appliance Location of code: proprietary to MGCS Inc. Contact: Kiyoshi Toyoda Implemented Features: Full features of RFC2304 Name of implementation: TOYOCOM OnRamp and OffRamp Gateway Organization: TOYOCOM Inc. Platforms: Windows NT Server ver.4.0 Location of code: proprietary to TOYOCOM Inc. Contact: Katsuhiko Mimura Implemented Features: Full features of RFC2304 Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Mon Sep 4 02:58:05 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 CAA00107 for ; Mon, 4 Sep 2000 02:58:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA22209 for ietf-fax-bks; Sun, 3 Sep 2000 23:20:45 -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 XAA22205 for ; Sun, 3 Sep 2000 23:20:43 -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 PAA00918; Mon, 4 Sep 2000 15:22:06 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id PAA02516; Mon, 4 Sep 2000 15:22:05 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id PAA20559; Mon, 4 Sep 2000 15:22:00 +0900 To: ietf-fax@imc.org, e.burger@ieee.org Cc: vpim@lists.neystadt.org Subject: PNDN (draft-ietf-vpim-pndn-00.txt) X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) References: <20000821151221R.tamura@toda.ricoh.co.jp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000904152401V.tamura@toda.ricoh.co.jp> Date: Mon, 04 Sep 2000 15:24:01 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 32 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, W.R.T. PNDN issue, from the minutes at Pittsburgh, FAX: > Some members commented that PNDN issue should also be discussed in FAX > WG. Whether to take it and add in WG charter will be discussed in ML. > AD agrees to it. VPIM: > Clarification: The chair emphasised that we had proposed the deletion of > IMPORTANT in Critical Content, and so we no longer need PNDNs for this > purpose, but that no consideration had yet been given to whether we still > progress Partial Delivery Notifications (and develop Partial Message > Disposition Notifications) anyway. To FAX WG people: Please discuss it, if you're interested in it. To Eric: Some FAX WG people do not follow it well. Could you please explain PNDN briefly? To VPIM WG people: Please say somthing in ietf-fax@imc.org, if you have comments about it. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Sep 4 02:59:08 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 CAA00118 for ; Mon, 4 Sep 2000 02:59:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA22749 for ietf-fax-bks; Sun, 3 Sep 2000 23:28:47 -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 XAA22742 for ; Sun, 3 Sep 2000 23:28:45 -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 PAA03193; Mon, 4 Sep 2000 15:30:08 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id PAA04808; Mon, 4 Sep 2000 15:30:08 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id PAA20672; Mon, 4 Sep 2000 15:30:03 +0900 To: mimu@toyocom.co.jp Cc: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-gateway-protocol-01.txt In-Reply-To: <200008171057.GAA23241@ietf.org> References: <200008171057.GAA23241@ietf.org> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000904153203X.tamura@toda.ricoh.co.jp> Date: Mon, 04 Sep 2000 15:32:03 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mimura-san, Questions. Does the version-01 reflect the results of Pittsburgh meeting. There were lots of suggestions and etc there. Please refer our meeting minutes. If not reflected, I recommend you to submit the version-02, which includes the suggestions at Pittsburgh. I'm sorry I have not read through version-01 yet. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Sep 4 03:01:16 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 DAA00208 for ; Mon, 4 Sep 2000 03:01:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA22239 for ietf-fax-bks; Sun, 3 Sep 2000 23:22:26 -0700 (PDT) Received: from neo.it.comsat.com (neo.it.comsat.com [134.133.200.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA22235 for ; Sun, 3 Sep 2000 23:22:25 -0700 (PDT) Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e846Hro22347; Mon, 4 Sep 2000 02:17:53 -0400 (EDT) Received: from stalker.iguide.co.il (stalker.iGuide.co.il [194.90.246.9]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e846Hoo22343 for ; Mon, 4 Sep 2000 02:17:50 -0400 (EDT) Received: from localhost (majordom@localhost) by stalker.iguide.co.il (8.9.3/8.9.3) with SMTP id IAA05359; Mon, 4 Sep 2000 08:22:36 +0200 Received: by stalker.iGuide.co.il (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 04 Sep 2000 08:22:23 +0000 (EET) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by stalker.iguide.co.il (8.9.3/8.9.3) with ESMTP id IAA05336 for ; Mon, 4 Sep 2000 08:22:16 +0200 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 PAA00918; Mon, 4 Sep 2000 15:22:06 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id PAA02516; Mon, 4 Sep 2000 15:22:05 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id PAA20559; Mon, 4 Sep 2000 15:22:00 +0900 To: ietf-fax@imc.org, e.burger@ieee.org Cc: vpim@lists.neystadt.org Subject: [VPIM] PNDN (draft-ietf-vpim-pndn-00.txt) X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) References: <20000821151221R.tamura@toda.ricoh.co.jp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000904152401V.tamura@toda.ricoh.co.jp> Date: Mon, 04 Sep 2000 15:24:01 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 32 X-Mail-Filter: omnivore ver 1.0.0 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, W.R.T. PNDN issue, from the minutes at Pittsburgh, FAX: > Some members commented that PNDN issue should also be discussed in FAX > WG. Whether to take it and add in WG charter will be discussed in ML. > AD agrees to it. VPIM: > Clarification: The chair emphasised that we had proposed the deletion of > IMPORTANT in Critical Content, and so we no longer need PNDNs for this > purpose, but that no consideration had yet been given to whether we still > progress Partial Delivery Notifications (and develop Partial Message > Disposition Notifications) anyway. To FAX WG people: Please discuss it, if you're interested in it. To Eric: Some FAX WG people do not follow it well. Could you please explain PNDN briefly? To VPIM WG people: Please say somthing in ietf-fax@imc.org, if you have comments about it. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Sep 4 22:52: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 WAA11265 for ; Mon, 4 Sep 2000 22:52:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA25880 for ietf-fax-bks; Mon, 4 Sep 2000 19:17:32 -0700 (PDT) Received: from iscan.toyocom.co.jp (mail.toyocom.co.jp [210.232.21.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25871 for ; Mon, 4 Sep 2000 19:17:30 -0700 (PDT) Received: from smtp.toyocom.co.jp (localhost [127.0.0.1]) by iscan.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA28686; Tue, 5 Sep 2000 11:18:44 +0900 Received: from toyocom.co.jp ([172.16.72.36]) by smtp.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA13427; Tue, 5 Sep 2000 11:18:19 +0900 Message-ID: <39B45840.94DBD9E0@toyocom.co.jp> Date: Tue, 05 Sep 2000 11:19:44 +0900 From: Katsuhiko Mimura Organization: TOYO Communication Equipment CO., LTD. X-Mailer: Mozilla 4.73 [ja] (WinNT; U) X-Accept-Language: ja MIME-Version: 1.0 To: Hiroshi Tamura CC: ietf-fax@imc.org Subject: Re: I-D ACTION:draft-ietf-fax-gateway-protocol-01.txt References: <200008171057.GAA23241@ietf.org> <20000904153203X.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 Tamura-san, Hiroshi Tamura wrote: > Does the version-01 reflect the results of Pittsburgh meeting. > There were lots of suggestions and etc there. > Please refer our meeting minutes. The version-01 reflect the results of Pittsuburgh meeting. but , I might miss some suggestions or others . I miss the Automatic retransmission and the scope of Onramp gateway. I will update on the version-02. ----------------------------------------------- Ktasuhiko Mimura E-mail mimu@toyocom.co.jp TOYOCOM(TOYO COMMUNICATION EQUIPMENT CO., LTD) Multimedia Engineering Department Communication Systems Division Tel +81-467-74-3584 Fax +81-467-74-3934 From owner-ietf-fax@mail.imc.org Thu Sep 7 11:37:21 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 LAA19063 for ; Thu, 7 Sep 2000 11:37:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA14889 for ietf-fax-bks; Thu, 7 Sep 2000 06:43:47 -0700 (PDT) Received: from elettra.trieste.it (SYNW10.elettra.trieste.it [140.105.2.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14884 for ; Thu, 7 Sep 2000 06:43:41 -0700 (PDT) Date: Thu, 7 Sep 2000 15:44:44 +0100 To: internet-drafts@ietf.org cc: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3213-1103527590-968341484=:538977353" From: Claudio Allocchio Subject: Updated DRAFT-IETF-FAX-MINADDR-V2-02.TXT, DRAFT-IETF-FAX-FAXADDR-V2-02.TXT Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --3213-1103527590-968341484=:538977353 Content-Type: TEXT/PLAIN; charset=US-ASCII Hallo, here are the updated versions of the 2 I-D which are going in last call soon. The only changes from version "01" are a typo correction in DRAFT-IETF-FAX-FAXADDR-V2-02.TXT (thank you Yokoyama-san for detecting it!) and the updated reference list in order to include RFC 2846 which was published last June. When the new I-Ds will be in the I-Ds repository, we will issue the WG last call. Regards, ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 --3213-1103527590-968341484=:538977353 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="DRAFT-IETF-FAX-MINADDR-V2-02.TXT" Content-ID: Content-Description: Content-Transfer-Encoding: BASE64 TmV0d29yayBXb3JraW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDLiBBbGxvY2NoaW8NCkdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBH QVJSLUl0YWx5DQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMA0KT2Jzb2xl dGVzOiBSRkMyMzAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEV4cGlyZXM6IE1hcmNoIDIwMDENClVwZGF0ZXM6IFJGQzI4NDYgICAgICAg ICAgICAgICAgIEZpbGU6IGRyYWZ0LWlldGYtZmF4LW1pbmFkZHItdjItMDIu dHh0DQoNCg0KDQogICAgICAgICAgICAgIE1pbmltYWwgR1NUTiBhZGRyZXNz IGZvcm1hdCBpbiBJbnRlcm5ldCBNYWlsDQoNCg0KU3RhdHVzIG9mIHRoaXMg TWVtbw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0IERyYWZ0 IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92 aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJu ZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJl YXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90 aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l bnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBz aXgNCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzDQogICBhdCBhbnkgdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyANCiAgIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBs aXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl ZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFi c3RyYWN0cy50eHQNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQg U2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDE5OTkpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KDQpBYnN0 cmFjdA0KDQogICBUaGlzIG1lbW8gZGVzY3JpYmVzIGEgc2ltcGxlIG1ldGhv ZCBvZiBlbmNvZGluZyBHU1ROIGFkZHJlc3NlcyANCiAgIChjb21tb25seSBj YWxsZWQgInRlbGVwaG9uZSBudW1iZXJzIikgaW4gdGhlIGxvY2FsLXBhcnQg b2YgSW50ZXJuZXQgDQogICBlbWFpbCBhZGRyZXNzZXMsIGFsb25nIHdpdGgg YW4gZXh0ZW5zaW9uIG1lY2hhbmlzbSB0byBhbGxvdyBlbmNvZGluZyANCiAg IG9mIGFkZGl0aW9uYWwgc3RhbmRhcmQgYXR0cmlidXRlcyBuZWVkZWQgZm9y IGVtYWlsIGdhdGV3YXlzIHRvIA0KICAgR1NUTi1iYXNlZCBzZXJ2aWNlcy4N Cg0KICAgQXMgd2l0aCBhbGwgSW50ZXJuZXQgbWFpbCBhZGRyZXNzZXMsIHRo ZSBsZWZ0LWhhbmQtc2lkZSAobG9jYWwtcGFydCkNCiAgIG9mIGFuIGFkZHJl c3MgZ2VuZXJhdGVkIGFjY29yZGluZyB0byB0aGlzIHNwZWNpZmljYXRpb24s IGlzIG5vdCB0byBiZQ0KICAgaW50ZXJwcmV0ZWQgZXhjZXB0IGJ5IGFuIE1U QSB0aGF0IGhhbmRsZXMgbWVzc2FnZXMgZm9yIHRoZSBkb21haW4gZ2l2ZW4N CiAgIGluIHRoZSByaWdodC1oYW5kLXNpZGUuDQoNCjEuIEludHJvZHVjdGlv bg0KDQogICBTaW5jZSB0aGUgdmVyeSBmaXJzdCBlLW1haWwgdG8gR1NUTiBz ZXJ2aWNlcyBnYXRld2F5IGFwcGVhcmVkLCBhDQogICBudW1iZXIgb2YgZGlm ZmVyZW50IG1ldGhvZHMgdG8gc3BlY2lmeSBhIEdTVE4gYWRkcmVzcyBhcyBh biBlLW1haWwNCiAgIGFkZHJlc3MgaGF2ZSBiZWVuIHVzZWQgYnkgaW1wbGVt ZW50b3JzLiBTZXZlcmFsIG9iamVjdGl2ZXMgZm9yIHRoaXMNCiAgIG1ldGhv ZHMgaGF2ZSBiZWVuIGlkZW50aWZpZWQsIGxpa2UgdG8gZW5hYmxlIGFuIGUt bWFpbCB1c2VyIHRvIGFjY2Vzcw0KICAgR1NUTiBzZXJ2aWNlcyBmcm9tIGhp cy9oZXIgZS1tYWlsIGludGVyZmFjZSwgdG8gYWxsb3cgc29tZSBraW5kIG9m IA0KICAgIkdTVE4gb3ZlciBlLW1haWwgc2VydmljZSIgdHJhbnNwb3J0IChw b3NzaWJseSByZWR1Y2luZyB0aGUgY29zdHMgb2YNCiAgIEdTVE4gbG9uZyBk aXN0YW5jZSB0cmFuc21pc3Npb25zKSB3aGlsZSB1c2luZyB0aGUgZXhpc3Rp bmcgZS1tYWlsIA0KICAgaW5mcmFzdHJ1Y3R1cmUuDQoNCiAgIFRoaXMgbWVt byBkZXNjcmliZXMgdGhlIE1JTklNQUwgYWRkcmVzc2luZyBtZXRob2QgdG8g ZW5jb2RlIEdTVE4NCiAgIGFkZHJlc3NlcyBpbnRvIGUtbWFpbCBhZGRyZXNz ZXMgYW5kIHRoZSBzdGFuZGFyZCBleHRlbnNpb24gbWVjaGFuaXNtDQogICB0 byBhbGxvdyBkZWZpbml0aW9uIG9mIGZ1cnRoZXIgc3RhbmRhcmQgZWxlbWVu dHMuIFRoZSBvcHBvc2l0ZQ0KICAgcHJvYmxlbSwgaS5lLiB0byBhbGxvdyBh IHRyYWRpdGlvbmFsIG51bWVyaWMtb25seSBHU1ROIGRldmljZSB1c2VyIHRv DQogICBhY2Nlc3MgdGhlIGUtbWFpbCB0cmFuc3BvcnQgc2VydmljZSwgaXMg bm90IGRpc2N1c3NlZCBoZXJlLg0KDQogICBUaGlzIElBTkEgcmVnaXN0cmF0 aW9uIHRlbXBsYXRlcyB3aGljaCBNVVNUIGJlIHVzZWQgdG8gcmVnaXN0ZXIg YW55DQogICBzdGFuZGFyZCBlbGVtZW50IGRlZmluZWQgYWNjb3JkaW5nIHRv IHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUgZ2l2ZW4gaW4NCiAgIHRoZSAiSUFO QSBDb25zaWRlcmF0aW9ucyIgY2hhcHRlciAoc2VjdGlvbiA3IG9mIHRoaXMg ZG9jdW1lbnQpLg0KDQogICBBbGwgaW1wbGVtZW50YXRpb25zIHN1cHBvcnRp bmcgdGhpcyBHU1ROIG92ZXIgZS1tYWlsIHNlcnZpY2UgTVVTVA0KICAgc3Vw cG9ydCBhcyBhIG1pbmltdW0gdGhlIHNwZWNpZmljYXRpb24gZGVzY3JpYmVk IGluIHRoaXMgZG9jdW1lbnQuDQogICBUaGUgZ2VuZXJpYyBjb21wbGV4IGNh c2Ugb2YgY29udmVydGluZyB0aGUgd2hvbGUgR1NUTiBhZGRyZXNzaW5nIGlu dG8NCiAgIGUtbWFpbCBpcyBvdXQgb2Ygc2NvcGUgaW4gdGhpcyBtaW5pbWFs IHNwZWNpZmljYXRpb246IHRoZXJlIGlzIHNvbWUNCiAgIHdvcmsgaW4gcHJv Z3Jlc3MgaW4gdGhlIGZpZWxkLCB3aGVyZSBhbHNvIGEgbnVtYmVyIG9mIG9w dGlvbmFsIA0KICAgc3RhbmRhcmQgZXh0ZW5zaW9ucyBhcmUgYmVpbmcgZGVm aW5lZC4NCg0KMS4xIFRlcm1pbm9sb2d5IGFuZCBTeW50YXggY29udmVudGlv bnMNCg0KICAgSW4gdGhpcyBkb2N1bWVudCB0aGUgZm9ybWFsIGRlZmluaXRp b25zIGFyZSBkZXNjcmliZWQgdXNpbmcgQUJORg0KICAgc3ludGF4LCBhcyBk ZWZpbmVkIGludG8gWzddLiBUaGlzIG1lbW8gYWxzbyB1c2VzIHNvbWUgb2Yg dGhlICJDT1JFDQogICBERUZJTklUSU9OUyIgZGVmaW5lZCBpbiAiQVBQRU5E SVggQSAtIENPUkUiIG9mIHRoYXQgZG9jdW1lbnQuIFRoZQ0KICAgZXhhY3Qg bWVhbmluZyBvZiB0aGUgY2FwaXRhbGlzZWQgd29yZHMNCg0KICAgICAgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIiwgIlNIT1VMRCIsDQogICAgICAiU0hPVUxEIE5PVCIsICJSRUNPTU1F TkRFRCIsICAiTUFZIiwgIk9QVElPTkFMIg0KDQogICBpcyBkZWZpbmVkIGlu IHJlZmVyZW5jZSBbNl0uDQoNCiAgIEluIHRoaXMgZG9jdW1lbnQgdGhlIGZv bGxvd2luZyBuZXcgdGVybXMgYXJlIGFsc28gZGVmaW5lZDoNCg0KICAgICBJ LXBzdG4gZGV2aWNlOg0KICAgICAgICBhIGRldmljZSB3aGljaCBoYXMgYW4g SW50ZXJuZXQgZG9tYWluIG5hbWUgYW5kIGl0IGlzIGFibGUgdG8NCiAgICAg ICAgY29tbXVuaWNhdGUgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkg d2l0aCB0aGUgR1NUTiBuZXR3b3JrOw0KDQogICAgIG10YS1JLXBzdG46DQog ICAgICAgIHRoZSBJbnRlcm5ldCBkb21haW4gbmFtZSB3aGljaCBpZGVudGlm aWVzIHVuaXF1ZWx5IGFuIEktcHN0bg0KICAgICAgICBkZXZpY2Ugb3ZlciB0 aGUgSW50ZXJuZXQ7DQoNCiAgICAgcHN0bi1lbWFpbDoNCiAgICAgICAgdGhl IGNvbXBsZXRlIEludGVybmV0IGUtbWFpbCBhZGRyZXNzIHN0cnVjdHVyZSB3 aGljaCBpcyB1c2VkIHRvIA0KICAgICAgICB0cmFuc3BvcnQgYSBHU1ROIGFk ZHJlc3Mgb3ZlciB0aGUgSW50ZXJuZXQgZS1tYWlsIHNlcnZpY2UuDQoNCg0K Mi4gTWluaW1hbCBHU1ROIGFkZHJlc3MNCg0KICAgVGhlIG1pbmltYWwgc3Bl Y2lmaWNhdGlvbiBvZiBhIEdTVE4gYWRkcmVzcyB3aXRoaW4gYW4gZS1tYWls IGFkZHJlc3MgaXMNCiAgIGFzIGZvbGxvd3M6DQoNCiAgICAgIHBzdG4tYWRk cmVzcyA9IHBzdG4tbWJveCAgWyBxdWFsaWYtdHlwZTEgXQ0KDQogICAgICBw c3RuLW1ib3ggPSBzZXJ2aWNlLXNlbGVjdG9yICI9IiBnbG9iYWwtcGhvbmUN Cg0KICAgICAgc2VydmljZS1zZWxlY3RvciA9IDEqKCBESUdJVCAvIEFMUEhB IC8gIi0iICkNCiAgICAgICAgICAgICAgICAgICAgICAgICA7IG5vdGUgdGhh dCBTUCAoc3BhY2UpIGlzIG5vdCBhbGxvd2VkIGluDQogICAgICAgICAgICAg ICAgICAgICAgICAgOyBzZXJ2aWNlLXNlbGVjdG9yLg0KICAgICAgICAgICAg ICAgICAgICAgICAgIDsgc2VydmljZS1zZWxlY3RvciBNVVNUIGJlIGhhbmRs ZWQgYXMgYSBjYXNlDQogICAgICAgICAgICAgICAgICAgICAgICAgOyBJTlNF TlNJVElWRSBzdHJpbmcgYnkgaW1wbGVtZW50YXRpb25zLg0KDQogICBPdGhl ciBzcGVjaWZpY2F0aW9ucyBhZG9wdGluZyB0aGUgInBzdG4tYWRkcmVzcyIg ZGVmaW5pdGlvbiBNVVNUIGRlZmluZQ0KICAgYW5kIHJlZ2lzdGVyIHdpdGgg SUFOQSBhIHVuaXF1ZSBjYXNlIGluc2Vuc2l0aXZlICJzZXJ2aWNlLXNlbGVj dG9yIiANCiAgIGVsZW1lbnQgdG8gaWRlbnRpZnkgdGhlIHNwZWNpZmljIG1l c3NhZ2luZyBzZXJ2aWNlIGludm9sdmVkLg0KDQogICBUaGVzZSBzcGVjaWZp Y2F0aW9ucyBhbmQgcmVnaXN0cmF0aW9ucyBNVVNUIGFsc28gZGVmaW5lIHdo aWNoIG1pbmltYWwgDQogICAicXVhbGlmLXR5cGUxIiBleHRlbnNpb25zLCBp ZiBhbnksIE1VU1QgYmUgc3VwcG9ydGVkIGZvciB0aGUgc3BlY2lmaWVkIA0K ICAgbWVzc2FuZ2luZyBzZXJ2aWNlLg0KDQogICBJbXBsZW1lbnRhdGlvbnMg Y29uZmlybWluZyB0byB0aGlzIG1pbmltYWwgcmVxdWlyZW1lbnRzIHNwZWNp ZmljYXRpb24NCiAgIGFyZSBhbGxvd2VkIHRvIGlnbm9yZSBhbnkgb3RoZXIg bm9uLW1pbmltYWwgZXh0ZW5zaW9ucyBhZGRyZXNzIGVsZW1lbnQNCiAgIHdo aWNoIGlzIHByZXNlbnQgaW4gdGhlICJwc3RuLWFkZHJlc3MiLiBIb3dldmVy LCBjb25mb3JtaW5nIA0KICAgaW1wbGVtZW50YXRpb25zIE1VU1QgcHJlc2Vy dmUgYWxsICJxdWFsaWYtdHlwZTEiIGFkZHJlc3MgZWxlbWVudHMNCiAgIHRo ZXkgcmVjZWl2ZS4NCg0KICAgVGhlIGdlbmVyaWMgInF1YWxpZi10eXBlMSIg ZWxlbWVudCBpcyBkZWZpbmVkIGFzOg0KDQogICAgICBxdWFsaWYtdHlwZTEg PSAiLyIga2V5d29yZCAiPSIgc3RyaW5nDQoNCiAgICAgIGtleXdvcmQgPSAx KiggRElHSVQgLyBBTFBIQSAvICItIiApDQogICAgICAgICAgICAgICAgOyBu b3RlIHRoYXQgU1AgKHNwYWNlKSBpcyBub3QgYWxsb3dlZCBpbiBrZXl3b3Jk DQoNCiAgICAgIHN0cmluZyA9IFBDSEFSDQogICAgICAgICAgICAgICA7IG5v dGUgdGhhdCBwcmludGFibGUgY2hhcmFjdGVycyBhcmUgJXgyMC03RQ0KDQog ICBBcyBzdWNoLCBhbGwgInBzdG4tYWRkcmVzcyIgZXh0ZW5zaW9uIGVsZW1l bnRzIE1VU1QgYmUgZGVmaW5lZCBpbg0KICAgdGhlICJxdWFsaWYtdHlwZTEi IGZvcm0gYXQgdGhlIHRpbWUgb2YgcmVnaXN0cmF0aW9uIHdpdGggSUFOQS4N Cg0KMi4xIE1pbmltYWwgImdsb2JhbC1waG9uZSIgZGVmaW5pdGlvbg0KDQog ICBUaGUgcHVycG91c2Ugb2YgZ2xvYmFsLXBob25lIGVsZW1lbnQgaXMgdG8g cmVwcmVzZW50IHN0YW5kYXJkIEUuMTY0DQogICBudW1lcmljIGFkZHJlc3Nl cyBbMTBdIHdpdGhpbiBhIHN5bnRheCBmb3IgZWxlY3Ryb25pYyBtYWlsIGFk ZHJlc3NpbmcNCiAgIHRoYXQgaXMgY29tcGxpYW50IHdpdGggc3RhbmRhcmQg ZS1tYWlsIHNwZWNpZmljYXRpb25zIGdpdmVuIGluIFsxXSANCiAgIGFuZCBb Ml0uDQoNCiAgIFRoZSBtaW5pbWFsIHN1cHBvcnRlZCBzeW50YXggZm9yIGds b2JhbC1waG9uZSBlbGVtZW50IGlzIGFzIGZvbGxvd3M6DQoNCiAgICAgIGds b2JhbC1waG9uZSA9ICIrIiAxKiggRElHSVQgLyB3cml0dGVuLXNlcCApDQoN CiAgICAgIHdyaXR0ZW4tc2VwID0gKCAiLSIgLyAiLiIgKQ0KDQogICBUaGUg dXNlIG9mIG90aGVyIGRpYWxsaW5nIHNjaGVtZXMgZm9yIEdTVE4gbnVtYmVy cyAobGlrZSBwcml2YXRlDQogICBudW1iZXJpbmcgcGxhbnMgb3IgbG9jYWwg ZGlhbGxpbmcgY29udmVudGlvbnMpIGlzIGFsc28gYWxsb3dlZC4NCiAgIEhv d2V2ZXIsIHRoaXMgZG9lcyBub3QgcHJlY2x1ZGUgbm9yIHJlbW92ZSB0aGUg bWFuZGF0b3J5IHJlcXVpcmVtZW50DQogICBmb3Igc3VwcG9ydCB0byB0aGUg Imdsb2JhbC1waG9uZSIgc3ludGF4IHdpdGhpbiBtaW5pbWFsIEdTVE4gYWRk cmVzcw0KICAgZm9ybWF0Lg0KDQogICBBbnkgb3RoZXIgZGlhbGxpbmcgc2No ZW1lcyBNVVNUIE5PVCB1c2UgdGhlIGxlYWRpbmcgIisiIGRlZmluZWQgaGVy ZQ0KICAgYmV0d2VlbiB0aGUgIj0iIHNpZ24gYW5kIHRoZSBkaWFsbGluZyBz dHJpbmcuIFRoZSAiKyIgc2lnbiBpcw0KICAgc3RyaWN0bHkgcmVzZXJ2ZWQg Zm9yIHRoZSBzdGFuZGFyZCAiZ2xvYmFsLXBob25lIiBzeW50YXguDQoNCiAg IE5vdGU6DQogICAgIFRoZSBzcGVjaWZpY2F0aW9uIG9mIGFsdGVybmF0ZSBk aWFsbGluZyBzY2hlbWFzIGlzIG91dCBvZiBzY29wZQ0KICAgICBmb3IgdGhp cyBtaW5pbWFsIHNwZWNpZmljYXRpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQg YWxzbyBwZXJtaXQgdGhlIHVzZSBvZiB3cml0dGVuLXNlcCBlbGVtZW50cyBp biBvcmRlciB0bw0KICAgaW1wcm92ZSBodW1hbiByZWFkaWJpbGl0eSBvZiBH U1ROIGUtbWFpbCBhZGRyZXNlcy4gVGhlIHdyaXR0ZW4tc2VwIGFyZQ0KICAg ZWxlbWVudHMgd2hpY2ggY2FuIGJlIHBsYWNlZCBiZXR3ZWVuIGRpYWwgZWxl bWVudHMgc3VjaCBhcyBkaWdpdHMNCiAgIGV0Yy4NCg0KICAgSW1wbGVtZW50 b3JzJyBub3RlOg0KICAgICBVc2Ugb2YgdGhlIHdyaXR0ZW4tc2VwIGVsZW1l bnRzIGlzIGFsbG93ZWQsIGJ1dCBub3QgcmVjb21tZW5kZWQNCiAgICAgZm9y IHRyYW5zbWlzc2lvbi4gQW55IG9jY3VyZW5jZXMgb2Ygd3JpdHRlbi1zZXAg ZWxlbWVudHMgaW4gYSANCiAgICAgcHN0bi1tYm94IE1VU1QgYmUgaWdub3Jl ZCBieSBhbGwgY29uZm9ybWFudCBpbXBsZW1lbnRhdGlvbnMuIFVzZXINCiAg ICAgQWdlbnRzIFNIT1VMRCByZW1vdmUgd3JpdHRlbi1zZXAgZWxlbWVudHMg YmVmb3JlIHN1Ym1pdHRpbmcgbWVzc2FnZXMNCiAgICAgdG8gdGhlIE1lc3Nh Z2UgVHJhbnNwb3J0IFN5c3RlbS4NCg0KDQoyLjIgVGhlIG1pbmltYWwgInBz dG4tYWRkcmVzcyIgZXhhbXBsZXMNCg0KICAgU29tZSBleGFtcGxlcyBvZiBt aW5pbWFsIHBzdG4tYWRkcmVzcyBmb2xsb3dzOg0KDQogICAgICBWT0lDRT0r Mzk0MDIyNjMzOA0KDQogICAgICBGQVg9KzEyMDI3NjUzMDAwL1QzM1M9NjM3 Nw0KDQogICAgICBTTVM9KzMzLTEtODgzMzUyMTUNCg0KICAgTm90ZTogDQog ICAgICBvbmx5IHRoZSB1c2Ugb2YgcmVnaXN0ZXJlZCBzZXJ2aWNlLXNlbGVj dG9yIGFuZCBxdWFsaWYtdHlwZTENCiAgICAgIGVsZW1lbnRzIGlzIGFsbG93 ZWQuIFRoZSBleGFtcGxlcyBzaG93biBhcmUganVzdCBmb3IgaWxsdXN0cmF0 aW9uDQogICAgICBwdXJwb3Nlcy4NCg0KDQozLiBUaGUgZS1tYWlsIGFkZHJl c3Mgb2YgdGhlIEktcHN0biBkZXZpY2U6IG10YS1JLXBzdG4NCg0KICAgQW4g IkktcHN0biBkZXZpY2UiIGhhcywgYW1vbmcgaXRzIGNoYXJhY3RlcmlzdGlj cywgYSB1bmlxdWUgDQogICBJbnRlcm5ldCBkb21haW4gbmFtZSB3aGljaCBp ZGVudGlmaWVzIGl0IG9uIHRoZSBJbnRlcm5ldC4gV2l0aGluDQogICBJbnRl cm5ldCBtYWlsLCB0aGlzIGlzIHRoZSBSaWdodCBIYW5kIFNpZGUgKFJIUykg cGFydCBvZiB0aGUNCiAgIGFkZHJlc3MsIGkuZS4gdGhlIHBhcnQgb24gdGhl IHJpZ2h0IG9mIHRoZSAiQCIgc2lnbi4gRm9yIHB1cnBvdXNlcw0KICAgb2Yg dGhpcyBkb2N1bWVudCB3ZSB3aWxsIGNhbGwgdGhpcyAibXRhLUktcHN0biIN Cg0KICAgICAgbXRhLUktcHN0biA9IGRvbWFpbg0KDQogICBGb3IgImRvbWFp biIgc3RyaW5ncyB1c2VkIGluIFNNVFAgdHJhbnNtaXNzaW9ucywgdGhlIHN0 cmluZyBNVVNUDQogICBjb25mb3JtIHRvIHRoZSByZXF1aXJlbWVudHMgb2Yg dGhhdCBzdGFuZGFyZCdzIDxkb21haW4+DQogICBzcGVjaWZpY2F0aW9ucyBb MV0sIFszXS4gIEZvciAiZG9tYWluIiBzdHJpbmdzIHVzZWQgaW4gbWVzc2Fn ZQ0KICAgY29udGVudCBoZWFkZXJzLCB0aGUgc3RyaW5nIE1VU1QgY29uZm9y bSB0byB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZQ0KICAgcmVsZXZhbnQgc3Rh bmRhcmRzIFsyXSwgWzNdLg0KDQogICBOb3RlOiBib3RoIGluIHRoZSBTTVRQ IGVudmVsb3BlIGFuZCBpbiB0aGUgbWVzc2FnZSBoZWFkZXJzLCB0aGUNCiAg ICAgICAgIHN0YW5kYXJkcyBwZXJtaXQgdGhlIHVzZSBvZiAiZG9tYWluIG5h bWVzIiBvciAiZG9tYWluIGxpdGVyYWxzIg0KICAgICAgICAgaW4gYWRkcmVz c2VzLg0KDQoNCjQuIFRoZSBwc3RuLWVtYWlsDQoNCiAgIFRoZSBjb21wbGV0 ZSBzdHJ1Y3R1cmUgdXNlZCB0byB0cmFuc2ZlciBhIG1pbmltYWwgR1NUTiBh ZGRyZXNzIG92ZXINCiAgIHRoZSBJbnRlcm5ldCBlLW1haWwgdHJhbnNwb3J0 IHN5c3RlbSBpcyBjYWxsZWQgInBzdG4tZW1haWwiLiBUaGlzDQogICBvYmpl Y3QgaXMgYSBhbiBlLW1haWwgYWRkcmVzcyB3aGljaCBjb25mb3JtcyB0byBb Ml0gYW5kIFszXSANCiAgICJhZGRyLXNwZWMiIHN5bnRheCwgd2l0aCBzdHJ1 Y3R1cmUgcmVmaW5lbWVudHMgd2hpY2ggYWxsb3dzIHRoZQ0KICAgR1NUTiBu dW1iZXIgdG8gYmUgaWRlbnRpZmllZC4NCg0KICAgICAgcHN0bi1lbWFpbCA9 ICBbIi8iXSBwc3RuLWFkZHJlc3MgWyIvIl0gIkAiIG10YS1JLXBzdG4NCg0K ICAgSW1wbGVtZW50b3JzJyBub3RlOg0KICAgICBUaGUgb3B0aW9uYWwgIi8i IGNoYXJhY3RlcnMgY2FuIHJlc3VsdCBmcm9tIHRyYW5zbGF0aW9ucyBmcm9t IA0KICAgICBvdGhlciB0cmFuc3BvcnQgZ2F0ZXdheXMgKHN1Y2ggYXMgc29t ZSBYLjQwMCBnYXRld2F5cykgd2hpY2ggDQogICAgIGhhdmUgaW5jbHVkZWQg dGhlICIvIiBhcyBhbiBvcHRpb25hbCBlbGVtZW50LiBJbXBsZW1lbnRhdGlv bnMNCiAgICAgTVVTVCBhY2NlcHQgdGhlIG9wdGlvbmFsIHNsYXNoZXMgYnV0 IFNIT1VMRCBOT1QgZ2VuZXJhdGUgdGhlbS4NCiAgICAgR2F0ZXdheXMgYXJl IGFsbG93ZWQgdG8gc3RyaXAgdGhlbSBvZmYgd2hlbiBjb252ZXJ0aW5nIHRv IA0KICAgICBJbnRlcm5ldCBtYWlsIGFkZHJlc3NpbmcuIEltcGxlbWVudG9y cyBhcmUgcmVtaW5kZWQgdGhhdCBpdCBpcw0KICAgICBlc3NlbnRpYWwgdGhh dCAicHN0bi1hZGRyZXNzIiBlbGVtZW50IE1VU1Qgc3RyaWN0bHkgZm9sbG93 IHRoZQ0KICAgICAicXVvdGluZyBydWxlcyIgc3BjaWZpZWQgaW4gdGhlIHJl bGV2YW50IHN0YW5kYXJkcyBbMl0sIFszXS4NCg0KNC4xIE11bHRpcGxlIHN1 YmFkZHJlc3Nlcw0KDQogICBUaGVyZSBhcmUgc29tZSBpbnN0YW5jZXMgaW4g R1NUTiBhcHBsaWNhdGlvbnMgd2hlcmUgbXVsdGlwbGUNCiAgIHN1YmFkZHJl c3NlcyBhcmUgdXNlZC4gT24gdGhlIG90aGVyIGhhbmQgaW4gZS1tYWlsIHBy YWN0aWNlIA0KICAgYSBzZXBhcmF0ZSBhbmQgdW5pcXVlIGUtbWFpbCBhZGRy ZXNzIGlzIGFsd2F5cyB1c2VkIGZvciBlYWNoIA0KICAgcmVjaXBpZW50Lg0K IA0KICAgSW4gdGhlIGV2ZW50IGEgcGFydGljdWxhciBHU1ROIHNlcnZpY2Ug cmVxdWlyZXMgbXVsdGlwbGUNCiAgIHN1YmFkZHJlc3NlcyAoaW4gYW55IGZv cm0gZGVmaW5lZCBieSB0aGUgc3RhbmRhcmQgc3BlY2lmaWNhdGlvbiBmb3IN CiAgIHRoYXQgR1NUTiBzZXJ2aWNlKSB0aGF0IGFyZSBhc3NvY2lhdGVkIHdp dGggdGhlIHNhbWUgInBzdG4tbWJveCIsDQogICB0aGVuIHRoZSB1c2Ugb2Yg bXVsdGlwbGUgInBzdG4tZW1haWwiIGVsZW1lbnRzIGlzIFJFUVVJUkVELg0K DQogICBJbXBsZW1lbnRvcnMnIG5vdGU6DQogICAgIFRoZSBVQSBtYXkgYWNj ZXB0IG11bHRpcGxlIHN1YmFkZHJlc3MgZWxlbWVudHMgZm9yIHRoZSBzYW1l DQogICAgIGdsb2JhbC1waG9uZSwgYnV0IGl0IE1VU1QgZ2VuZXJhdGUgbXVs dGlwbGUgInBzdG4tbWJveCIgZWxlbWVudHMNCiAgICAgd2hlbiBzdWJtaXR0 aW5nIHRoZSBtZXNzYWdlIHRvIHRoZSBNVEEuDQoNCg0KNC4yIFNvbWUgZXhh bXBsZXMgb2YgbWluaW1hbCAicHN0bi1lbWFpbCIgYWRkcmVzc2VzDQoNClNv bWUgZXhhbXBsZXMgb2YgbWluaW1hbCBwc3RuLWVtYWlsIGFkZHJlc3NlcyBm b2xsb3dzOg0KDQogICAgICBWT0lDRT0rMzk0MDIyNjMzOEB3b3JsZHZvaWNl LmNvbQ0KDQogICAgICBGQVg9KzEuMjAyLjc2NTMwMDAvVDMzUz02Mzc3QGZh eHNlcnYub3JnDQoNCiAgICAgIC9TTVM9KzMzLTEtODgzMzUyMTUvQHRlbGVj b20uY29tDQoNCk5vdGU6IA0KICAgICAgb25seSB0aGUgdXNlIG9mIHJlZ2lz dGVyZWQgc2VydmljZS1zZWxlY3RvciBhbmQgcXVhbGlmLXR5cGUxDQogICAg ICBlbGVtZW50cyBpcyBhbGxvd2VkLiBUaGUgZXhhbXBsZXMgc2hvd24gYXJl IGp1c3QgZm9yIGlsbHVzdHJhdGlvbg0KICAgICAgcHVycG91c2VzLg0KDQo1 LiBDb25jbHVzaW9ucw0KDQogICBUaGlzIHByb3Bvc2FsIGNyZWF0ZXMgYSBt aW5pbWFsIHN0YW5kYXJkIGVuY29kaW5nIGZvciBHU1ROIGFkZHJlc3Nlcw0K ICAgd2l0aGluIHRoZSBnbG9iYWwgZS1tYWlsIHRyYW5zcG9ydCBzeXN0ZW0u IEl0IGFsc28gZGVmaW5lcyB0aGUNCiAgIHN0YW5kYXJkIGV4dGVuc2lvbiBt ZWNoYW5pc20gdG8gYmUgdXNlZCB0byBpbnRyb2R1Y2UgbmV3IGVsZW1lbnRz IGZvcg0KICAgR1NUTiBhZGRyZXNzZXMuDQoNCiAgIFRoZSBwcm9wb3NhbCBp cyBjb25zaXN0ZW50IHdpdGggZXhpc3RpbmcgZS1tYWlsIHN0YW5kYXJkcy4g RWFjaA0KICAgc3BlY2lmaWMgR1NUTiBzZXJ2aWNlIHVzaW5nIHRoaXMgcHJv cG9zYWwgTVVTVCBkZWZpbmUgYW5kIHJlZ2lzdGVyDQogICB3aXRoIElBTkEg aXRzIG93biAic2VydmljZS1zZWxlY3RvciIgc3BlY2lmaWNhdGlvbiBhbmQg TVVTVCBkZWZpbmUNCiAgIGFuZCByZWdpc3RlciB0aGUgZXZlbnR1YWwgb3Ro ZXIgInF1YWxpZi10eXBlMSIgZWxlbWVudHMgbmVlZGVkIGZvcg0KICAgaXRz IHNwZWNpZmljYWwgYXBwbGljYXRpb24uIEFuIGV4YW1wbGUgb2Ygc3VjaCBh biBhcHBsaWNhdGlvbiBpcyANCiAgIGNvbnRhaW5lZCBpbiByZWZlcmVuY2Ug WzEzXS4NCg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtZWFucyBieSB3aGljaCBHU1ROIGFk ZHJlc3NlcyBjYW4gYmUNCiAgIGVuY29kZWQgaW50byBlLW1haWwgYWRkcmVz c2VzLiBTaW5jZSBlLW1haWwgcm91dGluZyBpcyBkZXRlcm1pbmVkIGJ5DQog ICBEb21haW4gTmFtZSBTeXN0ZW0gKEROUykgZGF0YSwgYSBzdWNjZXNzZnVs IGF0dGFjayB0byBETlMgY291bGQgDQogICBkaXNzZW1pbmF0ZSB0YW1wZXJl ZCBpbmZvcm1hdGlvbiwgd2hpY2ggY2F1c2VzIGUtbWFpbCBtZXNzYWdlcyB0 byBiZQ0KICAgZGl2ZXJ0ZWQgdmlhIHNvbWUgTVRBIG9yIEdhdGV3YXkgd2hl cmUgdGhlIHNlY3VyaXR5IG9mIHRoZSBzb2Z0d2FyZQ0KICAgaGFzIGJlZW4g Y29tcHJpbWlzZWQuDQoNCiAgIFRoZXJlIGFyZSBzZXZlcmFsIG1lYW5zIGJ5 IHdoaWNoIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gZGVsaXZlcg0K ICAgaW5jb3JyZWN0IG1haWwgcm91dGluZyBpbmZvcm1hdGlvbiB0byBhIGNs aWVudC4gVGhlc2UgaW5jbHVkZTogKGEpDQogICBjb21wcm9taXNlIG9mIGEg RE5TIHNlcnZlciwgKGIpIGdlbmVyYXRpbmcgYSBjb3VudGVyZmVpdCByZXNw b25zZSB0bw0KICAgYSBjbGllbnQncyBETlMgcXVlcnksIChjKSByZXR1cm5p bmcgaW5jb3JyZWN0ICJhZGRpdGlvbmFsDQogICBpbmZvcm1hdGlvbiIgaW4g cmVzcG9uc2UgdG8gYW4gdW5yZWxhdGVkIHF1ZXJ5LiBDbGllbnRzIFNIT1VM RCBlbnN1cmUNCiAgIHRoYXQgbWFpbCByb3V0aW5nIGlzIGJhc2VkIG9ubHkg b24gYXV0aG9yaXRhdGl2ZSBhbnN3ZXJzLiBPbmNlIEROUw0KICAgU2VjdXJp dHkgbWVjaGFuaXNtcyBbNV0gYmVjb21lIG1vcmUgd2lkZWx5IGRlcGxveWVk LCBjbGllbnRzIFNIT1VMRA0KICAgZW1wbG95IHRob3NlIG1lY2hhbmlzbXMg dG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgYW5kIGludGVncml0eSBvZg0K ICAgbWFpbCByb3V0aW5nIHJlY29yZHMuDQoNCjcuIElBTkEgQ29uc2lkZXJh dGlvbnMNCg0KICAgQXMgdGhlIHNlcnZpY2Utc2VsZWN0b3IgYW5kIHF1YWxp Zi10eXBlMSBlbGVtZW50cyB2YWx1ZXMgYXJlDQogICBleHRlbnNpYmxlIG9u ZXMsIHRoZXkgTVVTVCBiZSByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAg VG8gcmVnaXN0ZXIgYSBzZXJ2aWNlLXNlbGVjdG9yIG9yIGEgcXVhbGlmLXR5 cGUxIGVsZW1lbnQsIHRoZSANCiAgIHJlZ2lzdHJhdGlvbiBmb3JtIHRlbXBs YXRlcyBnaXZlbiBpbiA3LjEgYW5kIDcuMiBNVVNUIGJlIHVzZWQuIA0KICAg QW55IG5ldyByZWdpc3RyYXRpb24gTVVTVCBmdWxmaWwgdGhlICJTcGVjaWZp Y2F0aW9uIFJlcXVpcmVkIg0KICAgY3JpdGVyaXVtLCBhcyBkZWZpbmVkIGlu IFJGQyAyNDM0LCBzZWN0aW9uIDIgWzE2XToNCg0KICAgICJTcGVjaWZpY2F0 aW9uIFJlcXVpcmVkIC0gVmFsdWVzIGFuZCB0aGVpciBtZWFuaW5nIE1VU1Qg YmUNCiAgICAgZG9jdW1lbnRlZCBpbiBhbiBSRkMgb3Igb3RoZXIgcGVybWFu ZW50IGFuZCByZWFkaWx5IGF2YWlsYWJsZQ0KICAgICByZWZlcmVuY2UsIGlu IHN1ZmZpY2llbnQgZGV0YWlsIHNvIHRoYXQgaW50ZXJvcGVyYWJpbGl0eQ0K ICAgICBiZXR3ZWVuIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucyBpcyBw b3NzaWJsZS4iDQoNCiAgIElBTkEgTVVTVCBOT1QgYWNjZXB0IHJlZ2lzdHJh dGlvbnMgd2hpY2ggYXJlIG5vdCBzdXBwbGVtZW50ZWQgYnkNCiAgIGEgU3Bl Y2lmaWNhdGlvbiBhcyBkZWZpbmVkIGFib3ZlIGFuZCB3aGljaCBhcmUgbm90 IGZ1bGx5IHNwZWNpZmllZA0KICAgYWNjb2RpbmcgdG8gdGhlIHRlbXBsYXRl IGZvcm1zIGdpdmVuIGluIDcuMSBhbmQgNy4yLiBJbiBjYXNlIG9mIG5lZWQN CiAgIGZvciBmdXJ0aGVyIGNvbnN1bHRhdGlvbiBhYm91dCBhY2NlcHRpbmcg YSBuZXcgcmVnaXN0cmF0aW9uLCBJQU5BDQogICBTSE9VTEQgcmVmZXIgdG8g dGhlIEFwcGxpY2F0aW9uIEFyZWEgRGlyZWN0b3IgdG8gYmUgZGlyZWN0ZWQg dG8gdGhlDQogICBhcHByb3ByaWF0ZSAiZXhwZXJ0IiBpbmRpdmlkYWwgb3Ig SUVURiBXb3JraW5nIEdyb3VwLiANCiANCiAgIEFmdGVyIHN1Y2Nlc2Z1bCBy ZWdpc3RyYXRpb24sIElBTkEgc2hvdWxkIHB1Ymxpc2ggdGhlIHJlZ2lzdGVy ZWQgbmV3DQogICBlbGVtZW50IGluIHRoZSBhcHByb3ByaWF0ZSBvbi1saW5l IElBTkEgV0VCIHNpdGUsIGFuZCBpbmNsdWRlIGl0DQogICBpbnRvIHRoZSB1 cGRhdGVzIG9mIHRoZSAiQXNzaWduZWQgTnVtYmVycyIgUkZDIHNlcmllcy4N Cg0KICAgVGhpcyBzZWN0aW9uIChpbmNsdWRpbmcgNy4xIGFuZCA3LjIpIHVw ZGF0ZXMgdGhlIG9uZXMgY29udGFpbmVkIGluDQogICBbMTVdLg0KICAgDQoN CiAgIDcuMTogSUFOQSBSZWdpc3RyYXRpb24gZm9ybSB0ZW1wbGF0ZSBmb3Ig bmV3IHZhbHVlcyBvZiBHU1ROIA0KICAgYWRkcmVzcyBzZXJ2aWNlLXNlbGVj dG9yDQoNCiAgIFRvOiBJQU5BQGlzaS5lZHUgDQogICBTdWJqZWN0OiBSZWdp c3RyYXRpb24gb2YgbmV3IHZhbHVlcyBmb3IgdGhlIEdTVE4gYWRkcmVzcyAN CiAgICAgICAgICAgIHNlcnZpY2Utc2VsZWN0b3Igc3BlY2lmaWVyICJmb28i DQoNCiAgIHNlcnZpY2Utc2VsZWN0b3IgbmFtZToNCg0KICAgICAgZm9vDQoN CiAgIERlc2NyaXB0aW9uIG9mIFVzZToNCg0KICAgICAgZm9vIC0gKCJmb28i IGlzIGEgZmljdGlvbmFsIG5ldyBzZXJ2aWNlLXNlbGVjdG9yIHVzZWQgaW4g dGhpcyANCiAgICAgIHRlbXBsYXRlIGFzIGFuIGV4YW1wbGUsIGl0IGlzIHRv IGJlIHJlcGxhY2VkIHdpdGggdGhlIG5ldyB2YWx1ZQ0KICAgICAgYmVpbmcg cmVnaXN0ZXJlZC4gSW5jbHVkZSBhIHNob3J0IGRlc2NyaXB0aW9uIG9mIHRo ZSB1c2Ugb2YgdGhlDQogICAgICBuZXcgdmFsdWUgaGVyZS4gVGhpcyBNVVNU IGluY2x1ZGUgcmVmZXJlbmNlIHRvIFN0YW5kYXJkIFRyYWNrIFJGQ3MNCiAg ICAgIGFuZCBldmVudGF1bGx5IHRvIG90aGVyIFN0YW5kYXJkIEJvZGllcyBk b2N1bWVudHMgZm9yIHRoZSBjb21wbGV0ZQ0KICAgICAgZGVzY3JpcHRpb247 ICB0aGUgdXNlIG9mIHRoZSB2YWx1ZSBtdXN0IGJlIGRlZmluZWQgY29tcGxl dGVseQ0KICAgICAgZW5vdWdoIGZvciBpbmRlcGVuZGVudCBpbXBsZW1lbnRh dGlvbikuDQoNCiAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOg0KDQogICAg ICAoQW55IGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGhh dCBtYXkgYmUgaW50cm9kdWNlZCBieQ0KICAgICAgdXNlIG9mIHRoZSBuZXcg c2VydmljZS1zZWxlY3RvciBwYXJhbWV0ZXIgc2hvdWxkIGJlIGRlZmluZWQg aGVyZSBvcg0KICAgICAgaW4gdGhlIHJlZmVyZW5jZSBTdGFuZGFyZHMgVHJh Y2sgUkZDcykNCg0KICAgUGVyc29uICYgZW1haWwgYWRkcmVzcyB0byBjb250 YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOg0KDQogICAgICAoZmlsbCBp biBjb250YWN0IGluZm9ybWF0aW9uKQ0KDQogICBJTkZPUk1BVElPTiBUTyBU SEUgU1VCTUlUVEVSOg0KDQogICBUaGUgYWNjZXB0ZWQgcmVnaXN0cmF0aW9u cyB3aWxsIGJlIGxpc3RlZCBpbiB0aGUgIkFzc2lnbmVkIE51bWJlcnMiDQog ICBzZXJpZXMgb2YgUkZDcy4gIFRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVn aXN0cmF0aW9uIGZvcm0gaXMgZnJlZWx5DQogICBkaXN0cmlidXRhYmxlLg0K DQoNCiAgIDcuMjogSUFOQSBSZWdpc3RyYXRpb24gZm9ybSB0ZW1wbGF0ZSBm b3IgbmV3IHZhbHVlcyBvZiBHU1RODQogICBhZGRyZXNzIHF1YWxpZi10eXBl MSBrZXl3b3JkIGFuZCB2YWx1ZQ0KDQogICBUbzogSUFOQUBpc2kuZWR1IA0K ICAgU3ViamVjdDogUmVnaXN0cmF0aW9uIG9mIG5ldyB2YWx1ZXMgZm9yIHRo ZSBHU1ROIGFkZHJlc3MgDQogICAgICAgICAgICBxdWFsaWYtdHlwZTEgZWxl bWVudCAiYmFyIg0KDQogICBxdWFsaWYtdHlwZTEgImtleXdvcmQiIG5hbWU6 DQoNCiAgICAgIGJhcg0KDQogICBxdWFsaWYtdHlwZTEgInZhbHVlIiBBQk5G IGRlZmluaXRpb246DQoNCiAgICAgIGFibmYgLSAoImFibmYiIE1VU1QgZGVm aW5lIHRoZSBBQk5GIGZvcm0gb2YgdGhlIHF1YWxpZi10eXBlMSB2YWx1ZS4N CiAgICAgIFRoZSBBQk5GIHNwZWNpZmljYXRpb24gTVVTVCBiZSBzZWxmLWNv bnRhaW5lZCwgdXNpbmcgYXMgYmFzaWMgDQogICAgICBlbGVtZW50cyB0aGUg dG9rZW5zIGdpdmVuIGluIHNwZWNpZmljYXRpb24gWzRdLiBUbyBhdm9pZCBh bnkNCiAgICAgIGR1cGxpY2F0aW9uICh3aGVuIGFwcHJvcHJpYXRlKSwgaXQg TVVTVCBhbHNvIHVzZSBhbnkgYWxyZWFkeSANCiAgICAgIHJlZ2lzdGVyZWQg bm9uLWJhc2ljIHRva2VuIGZyb20gb3RoZXIgcXVhbGlmLXR5cGUxIGVsZW1l bnRzLCANCiAgICAgIGkuZS4gaXQgTVVTVCB1c2UgdGhlIHNhbWUgbm9uLWJh c2ljIHRva2VuIG5hbWUgYW5kIHRoZW4gcmVwZWF0IGl0cyANCiAgICAgIGlk ZW50aWNhbCBBQk5GIGRlZmluaXRpb24gZnJvbSBiYXNpYyB0b2tlbnMuDQoN CiAgIERlc2NyaXB0aW9uIG9mIFVzZToNCg0KICAgICAgYmFyIC0gKCJiYXIi IGlzIGEgZmljdGlvbmFsIGRlc2NyaXB0aW9uIGZvciBhIG5ldyBxdWFsaWYt dHlwZTEgDQogICAgICBlbGVtZW50IHVzZWQgaW4gdGhpcyB0ZW1wbGF0ZSBh cyBhbiBleGFtcGxlLiBJdCBpcyB0byBiZSByZXBsYWNlZA0KICAgICAgYnkg dGhlIHJlYWwgZGVzY3JpcHRpb24gb2YgcXVhbGlmLXR5cGUxIGVsZW1lbnQg YmVpbmcgcmVnaXN0ZXJlZC4NCiAgICAgIEluY2x1ZGUgYSBzaG9ydCBkZXNj cmlwdGlvbiBvZiB0aGUgdXNlIG9mIHRoZSBuZXcgcXVhbGlmLXR5cGUxIGhl cmUuDQogICAgICBUaGlzIE1VU1QgaW5jbHVkZSByZWZlcmVuY2UgdG8gU3Rh bmRhcmRzIFRyYWNrIFJGQ3MgYW5kIGV2ZW50dWFsbHkNCiAgICAgIHRvIG90 aGVyIFN0YW5kYXJkIEJvZGllcyBkb2N1bWVudHMgZm9yIHRoZSBjb21wbGV0 ZSBkZXNjcmlwdGlvbjsgdGhlDQogICAgICB1c2Ugb2YgdGhlIHZhbHVlIE1V U1QgYmUgZGVmaW5lZCBjb21wbGV0ZWx5IGVub3VnaCBmb3IgaW5kZXBlbmRl bnQgDQogICAgICBpbXBsZW1lbnRhdGlvbi4pDQoNCiAgIFVzZSBSZXN0cmlj dGlvbjoNCg0KICAgICAgKElmIHRoZSBuZXcgcXVhbGlmLXR5cGUxIGVsZW1l bnRzIGlzIG1lYW5pbmdmdWwgb25seSBmb3IgYSBzcGVjaWZpYw0KICAgICAg c2V0IG9mIHNlcnZpY2UtZWxlbWVudCwgeW91IE1VU1Qgc3BlY2lmeSBoZXJl IHRoZSBsaXN0IG9mIGFsbG93ZWQgDQogICAgICBzZXJ2aWNlLWVsZW1lbnQg dHlwZXMuIElmIHRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uLCB0aGVuIHNwZWNp ZnkgdGhlDQogICAgICBrZXl3b3JkICJub25lIikNCiAgIA0KICAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnM6DQoNCiAgICAgIChBbnkgYWRkaXRpb25hbCBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGF0IG1heSBiZSBpbnRyb2R1Y2Vk IGJ5DQogICAgICB1c2Ugb2YgdGhlIG5ldyBzZXJ2aWNlLXNlbGVjdG9yIHBh cmFtZXRlciBzaG91bGQgYmUgZGVmaW5lZCBoZXJlIG9yDQogICAgICBpbiB0 aGUgcmVmZXJlbmNlIFN0YW5kYXJkcyBUcmFjayBSRkNzKQ0KDQogICBQZXJz b24gJiBlbWFpbCBhZGRyZXNzIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5m b3JtYXRpb246DQoNCiAgICAgIChmaWxsIGluIGNvbnRhY3QgaW5mb3JtYXRp b24pDQoNCiAgIElORk9STUFUSU9OIFRPIFRIRSBTVUJNSVRURVI6DQoNCiAg IFRoZSBhY2NlcHRlZCByZWdpc3RyYXRpb25zIHdpbGwgYmUgbGlzdGVkIGlu IHRoZSAiQXNzaWduZWQgTnVtYmVycyINCiAgIHNlcmllcyBvZiBSRkNzLiAg VGhlIGluZm9ybWF0aW9uIGluIHRoZSByZWdpc3RyYXRpb24gZm9ybSBpcyBm cmVlbHkNCiAgIGRpc3RyaWJ1dGFibGUuDQoNCg0KOC4gQXV0aG9yJ3MgQWRk cmVzcw0KDQogICBDbGF1ZGlvIEFsbG9jY2hpbw0KICAgSU5GTi1HQVJSDQog ICBjL28gU2luY3JvdHJvbmUgVHJpZXN0ZQ0KICAgU1MgMTQgS20gMTYzLjUg QmFzb3ZpenphDQogICBJIDM0MDEyIFRyaWVzdGUNCiAgIEl0YWx5DQoNCiAg IFJGQzgyMjogQ2xhdWRpby5BbGxvY2NoaW9AZWxldHRyYS50cmllc3RlLml0 DQogICBYLjQwMDogIEM9aXQ7QT1nYXJyO1A9VHJpZXN0ZTtPPUVsZXR0cmE7 DQogICAgICAgICAgIFM9QWxsb2NjaGlvO0c9Q2xhdWRpbzsNCiAgIFBob25l OiAgKzM5IDA0MCAzNzU4NTIzDQogICBGYXg6ICAgICszOSAwNDAgMzc1ODU2 NQ0KDQoNCjkuIFJlZmVyZW5jZXMNCg0KICAgWzFdICBQb3N0ZWwsIEouLCAi U2ltcGxlIE1haWwgVHJhbnNmZXIgUHJvdG9jb2wiLCBTVEQgMTAsIFJGQyA4 MjEsDQogICAgICAgIEF1Z3VzdCAxOTgyLiAtLT4gRFJVTVM/DQoNCiAgIFsy XSAgQ3JvY2tlciwgRC4sICIgU3RhbmRhcmQgZm9yIHRoZSBmb3JtYXQgb2Yg QVJQQSBJbnRlcm5ldCB0ZXh0DQogICAgICAgIG1lc3NhZ2VzIiwgU1REIDEx LCBSRkMgODIyLCBBdWd1c3QgMTk4Mi4gLS0+IERSVU1TPw0KDQogICBbM10g IEJyYWRlbiwgUi4sICJSZXF1aXJlbWVudHMgZm9yIEludGVybmV0IGhvc3Rz IC0gYXBwbGljYXRpb24gYW5kDQogICAgICAgIHN1cHBvcnQiLCBSRkMgMTEy MywgT2N0b2JlciAxOTg5Lg0KDQogICBbNF0gIE1hbGFtdWQsIEMuIGFuZCBN LiBSb3NlLCAiUHJpbmNpcGxlcyBvZiBPcGVyYXRpb24gZm9yIHRoZQ0KICAg ICAgICBUUEMuSU5UIFN1YmRvbWFpbjogUmVtb3RlIFByaW50aW5nIC0tIFRl Y2huaWNhbCBQcm9jZWR1cmVzIiwgUkZDDQogICAgICAgIDE1MjgsIE9jdG9i ZXIgMTk5My4NCg0KICAgWzVdICBFYXN0bGFrZSwgRC4gYW5kIEMuIEthdWZt YW4sICJEb21haW4gTmFtZSBTeXN0ZW0gU2VjdXJpdHkNCiAgICAgICAgRXh0 ZW5zaW9ucyIsIFJGQyAyMDY1LCBKYW51YXJ5IDE5OTcuDQoNCiAgIFs2XSAg QnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIFJlcXVpcmVtZW50DQogICAgICAgIExldmVscyIsIFJGQyAyMTE5 LCBNYXJjaCAxOTk3Lg0KDQogICBbN10gIENyb2NrZXIsIEQuIGFuZCBQLiBP dmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4DQogICAgICAgIFNw ZWNpZmljYXRpb25zIiwgUkZDIDIyMzQsIE5vdmVtYmVyIDE5OTcuDQoNCiAg IFs4XSAgSVRVIEYuNDAxIC0gTWVzc2FnZSBIYW5kbGluZyBTZXJ2aWNlczog TmFtaW5nIGFuZCBBZGRyZXNzaW5nIGZvcg0KICAgICAgICBQdWJsaWMgTWVz c2FnZSBIYW5kbGluZyBTZXJ2aWNlOyByZWNvbW1lbmRhdGlvbiBGLjQwMSAo QXVndXN0DQogICAgICAgIDE5OTIpDQoNCiAgIFs5XSAgSVRVIEYuNDIzIC0g TWVzc2FnZSBIYW5kbGluZyBTZXJ2aWNlczogSW50ZXJjb21tdW5pY2F0aW9u DQogICAgICAgIEJldHdlZW4gdGhlIEludGVycGVyc29uYWwgTWVzc2FnaW5n IFNlcnZpY2UgYW5kIHRoZSBUZWxlZmF4DQogICAgICAgIFNlcnZpY2U7IHJl Y29tbWVuZGF0aW9uIEYuNDIzIChBdWd1c3QgMTk5MikNCg0KICAgWzEwXSBJ VFUgRS4xNjQgLSBUaGUgSW50ZXJuYXRpb25hbCBQdWJsaWMgVGVsZWNvbW11 bmljYXRpb24gTnVtYmVyaW5nDQogICAgICAgIFBsYW4gRS4xNjQvSS4zMzEg KE1heSAxOTk3KQ0KDQogICBbMTFdIElUVSBULjMzIC0gRmFjc2ltaWxlIHJv dXRpbmcgdXRpbGl6aW5nIHRoZSBzdWJhZGRyZXNzOw0KICAgICAgICByZWNv bW1lbmRhdGlvbiBULjMzIChKdWx5LCAxOTk2KQ0KDQogICBbMTJdIEVUU0kg SS1FVFMgMzAwLDM4MCAtIFVuaXZlcnNhbCBQZXJzb25hbCBUZWxlY29tbXVu aWNhdGlvbg0KICAgICAgICAoVVBUKTogQWNjZXNzIERldmljZXMgRHVhbCBU b25lIE11bHRpIEZyZXF1ZW5jeSAoRFRNRikgc2VuZGVyDQogICAgICAgIGZv ciBhY291c3RpY2FsIGNvdXBsaW5nIHRvIHRoZSBtaWNyb3Bob25lIG9mIGEg aGFuZHNldCB0ZWxlcGhvbmUNCiAgICAgICAgKE1hcmNoIDE5OTUpDQoNCiAg IFsxM10gQWxsb2NjaGlvLCBDLiwgIk1pbmltYWwgRkFYIGFkZHJlc3MgZm9y bWF0IGluIEludGVybmV0IE1haWwiLA0KICAgICAgICBSRkMgMjMwNCBiaXMs IHh4eHh4IDE5OTkuDQoNCiAgIFsxNF0gS2lsbGUsIFMuLCAiTUlYRVIgKE1p bWUgSW50ZXJuZXQgWC40MDAgRW5oYW5jZWQgUmVsYXkpOiBNYXBwaW5nDQog ICAgICAgIGJldHdlZW4gWC40MDAgYW5kIFJGQyA4MjIvTUlNRSIsIFJGQyAy MTU2LCBKYW51YXJ5IDE5OTguDQoNCiAgIFsxNV0gQWxsb2NjaGlvLCBDLiAi R1NUTiBhZGRyZXNzIGVsZW1lbnQgZXh0ZW5zaW9ucyBpbiBlLW1haWwgDQog ICAgICAgIHNlcnZpY2VzIiwgUkZDIDI4NDYsIEp1bmUgMjAwMC4NCg0KICAg WzE2XSBOYXJ0ZW4sIFQuLCBBbHZlc3RyYW5kLCBILiwgIkd1aWRlbGluZXMg Zm9yIFdyaXRpbmcgYW4gSUFOQQ0KICAgICAgICBDb25zaWRlcmF0aW9ucyBT ZWN0aW9uIGluIFJGQ3MiLCBSRkMgMjQzNCwgT2N0b2JlciAxOTk4Lg0KDQoN CjEwLiAgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdo dCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDE5OTkpLiAgQWxsIFJpZ2h0 cyBSZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRp b25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bw0KICAg b3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24g b3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCiAgIG9yIGFzc2lzdCBpbiBpdHMg aW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxp c2hlZA0KICAgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0 LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQ0KICAga2luZCwgcHJvdmlk ZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBw YXJhZ3JhcGggYXJlDQogICBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMg YW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzDQogICBkb2N1 bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBz dWNoIGFzIGJ5IHJlbW92aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBv ciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVy DQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVk IGZvciB0aGUgcHVycG9zZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBz dGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAg IGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRz IHByb2Nlc3MgbXVzdCBiZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVk IHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQog ICBFbmdsaXNoLg0KDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFu dGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICBy ZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNz b3JzIG9yIGFzc2lnbnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFu DQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBB TkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJ U0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJ TkNMVURJTkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkg VEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0KICAgSEVSRUlOIFdJ TEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FS UkFOVElFUyBPRg0KICAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCg== --3213-1103527590-968341484=:538977353 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="DRAFT-IETF-FAX-FAXADDR-V2-02.TXT" Content-ID: Content-Description: Content-Transfer-Encoding: BASE64 TmV0d29yayBXb3JraW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDLiBBbGxvY2NoaW8NCkdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBH QVJSLUl0YWx5DQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMA0KT2Jzb2xl dGVzOiBSRkMyMzA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEV4cGlyZXM6IE1hcmNoIDIwMDENClVwZGF0ZXM6IFJGQzI4NDYgICAgICAg ICAgICAgICAgIEZpbGU6IGRyYWZ0LWlldGYtZmF4LWZheGFkZHItdjItMDIu dHh0DQoNCg0KDQogICAgICAgICAgICAgIE1pbmltYWwgRkFYIGFkZHJlc3Mg Zm9ybWF0IGluIEludGVybmV0IE1haWwNCg0KDQoNClN0YXR1cyBvZiB0aGlz IE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldCBEcmFm dCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICBhbGwgcHJv dmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4DQogICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cw0KICAgYXQgYW55IHRp bWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgDQogICByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQNCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1h YnN0cmFjdHMudHh0DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KDQpDb3B5 cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDE5OTkpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KQWJz dHJhY3QNCg0KICAgVGhpcyBtZW1vIGRlc2NyaWJlcyBhIHNpbXBsZSBtZXRo b2Qgb2YgZW5jb2RpbmcgR1NUTiBhZGRyZXNzZXMgb2YNCiAgIGZhY3NpbWls ZSBkZXZpY2VzIGluIHRoZSBsb2NhbC1wYXJ0IG9mIEludGVybmV0IGVtYWls IGFkZHJlc3Nlcy4NCg0KICAgQXMgd2l0aCBhbGwgSW50ZXJuZXQgbWFpbCBh ZGRyZXNzZXMsIHRoZSBsZWZ0LWhhbmQtc2lkZSAobG9jYWwtIHBhcnQpDQog ICBvZiBhbiBhZGRyZXNzIGdlbmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhpcyBz cGVjaWZpY2F0aW9uLCBpcyBub3QgdG8gYmUNCiAgIGludGVycHJldGVkIGV4 Y2VwdCBieSB0aGUgTVRBIHRoYXQgaXMgbmFtZWQgb24gdGhlIHJpZ2h0LWhh bmQtc2lkZQ0KICAgKGRvbWFpbikuDQoNCg0KMS4gSW50cm9kdWN0aW9uDQoN CiAgIFNpbmNlIHRoZSB2ZXJ5IGZpcnN0IGUtbWFpbCB0byBmYXggZ2F0ZXdh eSBvYmplY3RzIGFwcGVhcmVkLCBhDQogICBudW1iZXIgb2YgZGlmZmVyZW50 IG1ldGhvZHMgdG8gc3BlY2lmeSBhIGZheCBhZGRyZXNzIGFzIGFuIGUtbWFp bA0KICAgYWRkcmVzcyBoYXZlIGJlZW4gdXNlZCBieSBpbXBsZW1lbnRvcnMu IFNldmVyYWwgb2JqZWN0aXZlcyBmb3IgdGhpcw0KICAgbWV0aG9kcyBoYXZl IGJlZW4gaWRlbnRpZmllZCwgbGlrZSB0byBlbmFibGUgYW4gZS1tYWlsIHVz ZXIgdG8gc2VuZA0KICAgYW5kIHJlY2VpdmUgZmF4ZXMgZnJvbSBoaXMvaGVy IGUtbWFpbCBpbnRlcmZhY2UsIHRvIGFsbG93IHNvbWUga2luZCBvZiANCiAg ICJmYXggb3ZlciBlLW1haWwgc2VydmljZSIgdHJhbnNwb3J0IChwb3NzaWJs eSByZWR1Y2luZyB0aGUgY29zdHMgb2YNCiAgIEdTVE4gbG9uZyBkaXN0YW5j ZSB0cmFuc21pc3Npb25zKSB3aGlsZSB1c2luZyB0aGUgZXhpc3RpbmcgZS1t YWlsIA0KICAgaW5mcmFzdHJ1Y3R1cmUuDQoNCiAgIFRoaXMgbWVtbyBkZXNj cmliZXMgdGhlIE1JTklNQUwgYWRkcmVzc2luZyBtZXRob2QgYW5kIHN0YW5k YXJkDQogICBleHRlbnNpb25zIHRvIGVuY29kZSBGQVggYWRkcmVzc2VzIGlu dG8gZS1tYWlsIGFkZHJlc3NlcywgYXMgcmVxdWlyZWQNCiAgIGluIHJlZmVy ZW5jZSBbMTNdLiBUaGUgb3Bwb3NpdGUgcHJvYmxlbSwgaS5lLiB0byBhbGxv dyBhIHRyYWRpdGlvbmFsDQogICBudW1lcmljLW9ubHkgZmF4IGRldmljZSB1 c2VyIHRvIGFjY2VzcyB0aGUgZS1tYWlsIHRyYW5zcG9ydCBzZXJ2aWNlLA0K ICAgaXMgbm90IGRpc2N1c3NlZCBoZXJlLg0KDQogICBUaGlzIElBTkEgZm9y bXMgdXNlZCB0byByZWdpc3RlciB0aGUgc3RhbmRhcmQgZWxlbWVudHMgZGVm aW5lZCBoZXJlDQogICBhcmUgZ2l2ZW4gaW4gdGhlICJJQU5BIENvbnNpZGVy YXRpb25zIiBjaGFwdGVyIChzZWN0aW9uIDcgb2YgdGhpcw0KICAgZG9jdW1l bnQpLg0KDQogICBBbGwgaW1wbGVtZW50YXRpb25zIHN1cHBvcnRpbmcgRkFY IG92ZXIgZS1tYWlsIGFkZHJlc3MgZm9ybWF0IE1VU1QNCiAgIHN1cHBvcnQg dGhpcyBtaW5pbWFsIHNwZWNpZmljYXRpb24uDQoNCg0KMS4xIFRlcm1pbm9s b2d5IGFuZCBTeW50YXggY29udmVudGlvbnMNCg0KICAgSW4gdGhpcyBkb2N1 bWVudCB0aGUgZm9ybWFsIGRlZmluaXRpb25zIGFyZSBkZXNjcmliZWQgdXNp bmcgQUJORg0KICAgc3ludGF4LCBhcyBkZWZpbmVkIGludG8gWzddLiBXZSB3 aWxsIGFsc28gdXNlIHNvbWUgb2YgdGhlICJDT1JFDQogICBERUZJTklUSU9O UyIgZGVmaW5lZCBpbiAiQVBQRU5ESVggQSAtIENPUkUiIG9mIHRoYXQgZG9j dW1lbnQuIFRoZQ0KICAgZXhhY3QgbWVhbmluZyBvZiB0aGUgY2FwaXRhbGlz ZWQgd29yZHMNCg0KICAgICAgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsDQogICAgICAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgIk9QVElPTkFM Ig0KDQogICBpcyBkZWZpbmVkIGluIHJlZmVyZW5jZSBbNl0uDQoNCiAgIElu IHRoaXMgZG9jdW1lbnQgdGhlIGZvbGxvd2luZyBuZXcgdGVybXMgYXJlIGFs c28gZGVmaW5lZDoNCg0KICAgICBJLWZheCBkZXZpY2U6DQogICAgICAgIGFu IEktcHN0biBkZXZpY2UgdHlwZSBbMTNdIHdoaWNoIGlzIGFibGUgdG8gY29t bXVuaWNhdGUgZWl0aGVyDQogICAgICAgIGRpcmVjdGx5IG9yIGluZGlyZWN0 bHkgd2l0aCB0aGUgdHJhZGl0aW9uYWwgRkFYIG92ZXIgR1NUTg0KICAgICAg ICBzZXJ2aWNlOw0KDQogICAgIG10YS1JLWZheDoNCiAgICAgICAgdGhlIElu dGVybmV0IGRvbWFpbiBuYW1lIHdoaWNoIGlkZW50aWZpZXMgdW5pcXVlbHkg YW4gSS1mYXgNCiAgICAgICAgZGV2aWNlIG92ZXIgdGhlIEludGVybmV0IChz ZWUgYWxzbyBtdGEtSS1wc3RuIGluIFsxM10pOw0KDQogICAgIGZheC1lbWFp bDoNCiAgICAgICAgdGhlIGNvbXBsZXRlIEludGVybmV0IGUtbWFpbCBhZGRy ZXNzIHN0cnVjdHVyZSB3aGljaCBpcyB1c2VkIHRvIA0KICAgICAgICB0cmFu c3BvcnQgYSBGQVggYWRkcmVzcyBvdmVyIHRoZSBJbnRlcm5ldCBlLW1haWwg c2VydmljZSAoc2VlDQogICAgICAgIGFsc28gcHN0bi1lbWFpbCBpbiBbMTNd KS4NCg0KMi4gTWluaW1hbCBGYXggYWRkcmVzcw0KDQogICBUaGUgbWluaW1h bCBmYXggYWRkcmVzcyB3aXRoaW4gZS1tYWlsIGhhcyBiZWVuIGRlZmluZWQg Zm9yIGNvbnNpc3RlbmN5DQogICB3aXRoIHJlZmVyZW5jZSBbMTNdIGFuZCBp dCBjb250YWlucyB0d28gZWxlbWVudHM6IHRoZSBmYXgtbWJveCBhbmQNCiAg IGFuIG9wdGlvbmFsIHF1YWxpZi10eXBlMSBlbGVtZW50Lg0KDQogICBNb3Jl IHByZWNpc2VseSB0aGUgR1NUTiBtaW5pbWFsIGFkZHJlc3Mgc3BlY2lmaWNh dGlvbiByZXF1aXJlcyB0aGUNCiAgIHVzZSBvZiBhIHVuaXF1ZSBzZXJ2aWNl LXNlbGVjdG9yIGZvciBlYWNoIHNwZWNpZmljIGFwcGxpY2F0aW9uIA0KICAg KHNlY3Rpb24gMiBpbiBbMTNdKS4NCg0KICAgVGhlICJzZXJ2aWNlLXNlbGVj dG9yIiBkZWZpbmVkIGZvciB0aGUgZmF4IHNlcnZpY2UgaXMgYXMgZm9sbG93 czoNCg0KICAgICAgc2VydmljZS1zZWxlY3RvciA9ICJGQVgiDQoNCiAgIElu IHRoZSBzeW50YXggZm9yIHRoZSBmYXggYWRkcmVzcyBhIHF1YWxpZi10eXBl MSBlbGVtZW50IGhhcyBiZWVuDQogICBkZWZpbmVkIGZvciBzdXBwb3J0IG9m IFQuMzAvVC4zMyBzdWJhZGRyZXNzZXMgKHNlZSBzZWN0aW9uIDIgb2YgWzEz XSkuDQogICBUaGUgdXNlIG9mIHRoaXMgZWxlbWVudCBpcyBPUFRJT05BTCwg YnV0IGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMNCiAgIE1VU1QgYmUgYWJs ZSB0byBzdXBwb3J0IGFuZCBjb3JyZWN0bHkgaW50ZXJwcmV0IGl0IHdoZW4g cHJlc2VudC4NCiAgIEl0cyBkZWZpbml0aW9uIGlzIGFzIGZvbGxvd3M6DQoN CiAgICAgIHF1YWxpZi10eXBlMSA9ICIvIiB0MzMtc2VwICI9IiBzdWItYWRk cg0KDQogICB3aGVyZQ0KDQogICAgICB0MzMtc2VwID0gIlQzM1MiDQoNCiAg ICAgIHN1Yi1hZGRyID0gMSooIERJR0lUICkNCg0KICAgVGh1cywgdGhlIG1p bmltYWwgc3BlY2lmaWNhdGlvbiBvZiBhIGZheCBpbiBlLW1haWwgYWRkcmVz cyBpczoNCg0KICAgICAgZmF4LWFkZHJlc3MgPSBmYXgtbWJveCBbICIvVDMz Uz0iIHN1Yi1hZGRyIF0NCg0KICAgICAgZmF4LW1ib3ggPSAiRkFYPSIgZ2xv YmFsLXBob25lDQoNCiAgTm90ZXM6DQogICAgRm9yIHRoZSBjYXNlIG9mIGEg c2luZ2xlIHN1YmFkZHJlc3MsIG9ubHkgbnVtYmVycyBhcmUgYWxsb3dlZCBp bg0KICAgIDxzdWItYWRkcj4gd2hpY2ggaXMgY29uc2lzdGVudCB3aXRoIFQu MzAsIFQuMzMsIGFuZCB0aGlzIGRvY3VtZW50Lg0KICAgIFdoaWxlIFQuMzAg YW5kIFQuMzMgdXNlIFNQQUNFIHRvIHBhZCBpdHMgZmllbGQsIHBhZGRpbmcg aXNuJ3QgbmVjZXNzYXJ5DQogICAgaW4gdGhlIDxzdWItYWRkcj4gZmllbGQg ZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50Lg0KDQogICAgRm9yIHRoZSBjYXNl IG9mIG11bHRpcGxlIHN1YmFkZHJlc3NlcywgVC4zMyBzcGVjaWZpZXMgdGhl ICIjIg0KICAgIGNoYXJhY3RlciBzaG91bGQgYmUgdXNlZCB0byBzcGVjaWZ5 IG11bHRpcGxlIHN1YmFkZHJlc2VzLiAgSG93ZXZlciwNCiAgICBvbmx5IGRp Z2l0cyBhcmUgcGVybWl0dGVkIGluIHRoZSA8c3ViLWFkZHI+IGZpZWxkIGRl ZmluZWQgYnkgdGhpcw0KICAgIGRvY3VtZW50LiAgUmVmZXIgdG8gc2VjdGlv biA0LjEgaW4gY2FzZSBtdWx0aXBsZSA8c3ViLWFkZHI+IHBlcg0KICAgIHBl ciA8ZmF4LW1ib3g+IG5lZWQgdG8gYmUgc3BlY2lmaWVkLg0KDQogICBUaGUg TWluaW1hbCBzdXBwb3J0ZWQgc3ludGF4IGZvciBnbG9iYWwtcGhvbmUgKGFz IGRlc2NyaWJlZCBpbg0KICAgc2VjdGlvbiAyLjEgb2YgcmVmZXJlbmNlIFsx M10pIGlzOg0KDQogICBnbG9iYWwtcGhvbmUgPSAiKyIgMSooIERJR0lUIC8g d3JpdHRlbi1zZXAgKQ0KDQogICB3cml0dGVuLXNlcCA9ICggIi0iIC8gIi4i ICkNCg0KICAgUmVmZXIgdG8gc2VjdGlvbiAyLjEgaW4gWzEzXSBmb3Igb3Ro ZXIgaW1wb3J0YW50IGNvbnNpZGVyYXRpb25zIGFib3V0DQogICB0aGUgZ2xv YmFsLXBob25lIGVsZW1lbnQuDQoNCg0KMi4yIFNvbWUgZXhhbXBsZXMgb2Yg YSBtaW5pbWFsICJmYXgtYWRkcmVzcyINCg0KICAgU29tZSBleGFtcGxlcyBv ZiBtaW5pbWFsIGZheC1hZGRyZXNzIGZvbGxvd3M6DQoNCiAgICAgIEZBWD0r Mzk0MDIyNjMzOA0KDQogICAgICBGQVg9KzEyMDI3NjUzMDAwL1QzM1M9MTM4 Nw0KDQogICAgICBGQVg9KzMzLTEtODgzMzUyMTUNCg0KICAgTm90ZTogDQog ICAgICB0aGUgZXhhbXBsZXMgc2hvd24gYXJlIGp1c3QgZm9yIGlsbHVzdHJh dGlvbiBwdXJwb3VzZXMuDQoNCg0KMy4gVGhlIGUtbWFpbCBhZGRyZXNzIG9m IHRoZSBJLWZheCBkZXZpY2U6IG10YS1JLWZheA0KDQogICBBbiAiSS1mYXgg ZGV2aWNlIiBoYXMgZ290LCBhbW9uZyBpdHMgY2hhcmFjdGVyaXN0aWNzLCBh IHVuaXF1ZSANCiAgIEludGVybmV0IGRvbWFpbiBuYW1lIHdoaWNoIGlkZW50 aWZpZXMgaXQgb24gdGhlIEludGVybmV0LiBXaXRoaW4NCiAgIEludGVybmV0 IG1haWwsIHRoaXMgaXMgdGhlIFJpZ2h0IEhhbmQgU2lkZSAoUkhTKSBwYXJ0 IG9mIHRoZQ0KICAgYWRkcmVzcywgaS5lLiB0aGUgcGFydCBvbiB0aGUgcmln aHQgb2YgdGhlICJAIiBzaWduLiBGb3IgcHVycG91c2VzDQogICBvZiB0aGlz IGRvY3VtZW50IHdlIHdpbGwgY2FsbCB0aGlzICJtdGEtSS1mYXgiDQoNCiAg ICAgIG10YS1JLWZheCA9IGRvbWFpbg0KDQogICBGb3IgImRvbWFpbiIgc3Ry aW5ncyB1c2VkIGluIFNNVFAgdHJhbnNtaXNzaW9ucywgdGhlIHN0cmluZyBN VVNUDQogICBjb25mb3JtIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgdGhhdCBz dGFuZGFyZCdzIDxkb21haW4+DQogICBzcGVjaWZpY2F0aW9ucyBbMV0sIFsz XS4gIEZvciAiZG9tYWluIiBzdHJpbmdzIHVzZWQgaW4gbWVzc2FnZQ0KICAg Y29udGVudCBoZWFkZXJzLCB0aGUgc3RyaW5nIE1VU1QgY29uZm9ybSB0byB0 aGUgcmVxdWlyZW1lbnRzIG9mIHRoZQ0KICAgcmVsZXZhbnQgc3RhbmRhcmRz IFsyXSwgWzNdLg0KDQogICBOb3RlOiBib3RoIGluIHRoZSBTTVRQIGVudmVs b3BlIGFuZCBpbiB0aGUgbWVzc2FnZSBoZWFkZXJzLCB0aGUNCiAgICAgICAg IHN0YW5kYXJkcyBwZXJtaXQgdGhlIHVzZSBvZiAiZG9tYWluIG5hbWVzIiBv ciAiZG9tYWluIGxpdGVyYWxzIg0KICAgICAgICAgaW4gYWRkcmVzc2VzLg0K DQo0LiBUaGUgZmF4LWVtYWlsDQoNCiAgIFRoZSBjb21wbGV0ZSBzdHJ1Y3R1 cmUgdXNlZCB0byB0cmFuc2ZlciBhIG1pbmltYWwgRkFYIGFkZHJlc3Mgb3Zl cg0KICAgdGhlIEludGVybmV0IGUtbWFpbCB0cmFuc3BvcnQgc3lzdGVtIGlz IGNhbGxlZCAiZmF4LWVtYWlsIi4gVGhpcw0KICAgb2JqZWN0IGlzIGEgYW4g ZS1tYWlsIGFkZHJlc3Mgd2hpY2ggY29uZm9ybXMgdG8gWzJdIGFuZCBbM10N CiAgICJhZGRyLXNwZWMiIHN5bnRheCwgd2l0aCBzdHJ1Y3R1cmUgcmVmaW5l bWVudHMgd2hpY2ggYWxsb3dzIHRoZQ0KICAgRkFYIG51bWJlciB0byBiZSBp ZGVudGlmaWVkLg0KDQogICAgICAgICBmYXgtZW1haWwgPSAgWyIvIl0gZmF4 LWFkZHJlc3MgWyIvIl0gIkAiIG10YS1JLWZheA0KDQogICBJbXBsZW1lbnRv cnMnIG5vdGU6DQogICAgIFRoZSBvcHRpb25hbCAiLyIgY2hhcmFjdGVycyBj YW4gcmVzdWx0IGZyb20gdHJhbnNsYXRpb25zIGZyb20gDQogICAgIG90aGVy IHRyYW5zcG9ydCBnYXRld2F5cyAoc3VjaCBhcyBzb21lIFguNDAwIGdhdGV3 YXlzKSB3aGljaCANCiAgICAgaGF2ZSBpbmNsdWRlZCB0aGUgIi8iIGFzIGFu IG9wdGlvbmFsIGVsZW1lbnQuIEltcGxlbWVudGF0aW9ucw0KICAgICBNVVNU IGFjY2VwdCB0aGUgb3B0aW9uYWwgc2xhc2hlcyBidXQgU0hPVUxEIE5PVCBn ZW5lcmF0ZSB0aGVtLg0KICAgICBHYXRld2F5cyBhcmUgYWxsb3dlZCB0byBz dHJpcCB0aGVtIG9mZiB3aGVuIGNvbnZlcnRpbmcgdG8gDQogICAgIEludGVy bmV0IG1haWwgYWRkcmVzc2luZy4gSW1wbGVtZW50b3JzIGFyZSByZW1pbmRl ZCB0aGF0IGl0IGlzDQogICAgIGVzc2VudGlhbCB0aGF0ICJmYXgtYWRkcmVz cyIgZWxlbWVudCBNVVNUIHN0cmljdGx5IGZvbGxvdyB0aGUNCiAgICAgInF1 b3RpbmcgcnVsZXMiIHNwY2lmaWVkIGluIHRoZSByZWxldmFudCBzdGFuZGFy ZHMgWzJdLCBbM10uDQoNCg0KNC4xIE11bHRpcGxlIHN1YmFkZHJlc3Nlcw0K DQogICBUaGVyZSBhcmUgc29tZSBpbnN0YW5jZXMgaW4gR1NUTiBhcHBsaWNh dGlvbnMgd2hlcmUgbXVsdGlwbGUNCiAgIHN1YmFkZHJlc3NlcyBhcmUgdXNl ZDogVC4zMyBzdWJhZGRyZXNzZXMgaW4gZmF4IHNlcnZpY2UgYXJlIG9uZSBv Zg0KICAgdGhlc2UgY2FzZXMuIEluIGUtbWFpbCBwcmFjdGljZSBhIHNlcGFy YXRlIGFuZCB1bmlxdWUgZS1tYWlsDQogICBhZGRyZXNzIGlzIGFsd2F5cyB1 c2VkIGZvciBlYWNoIHJlY2lwaWVudDsgYXMgc3VjaCwgaWYgbXVsdGlwbGUg VC4zMyANCiAgIHN1YmFkZHJlc3NlcyBhcmUgcHJlc2VudCwgdGhlIHVzZSBv ZiBtdWx0aXBsZSAiZmF4LWVtYWlsIiBlbGVtZW50cyANCiAgIGlzIFJFUVVJ UkVELg0KDQogICBJbXBsZW1lbnRvcnMnIG5vdGU6DQogICAgIFRoZSBVQSBN QVkgYWNjZXB0IG11bHRpcGxlIHN1YmFkZHJlc3MgZWxlbWVudHMgZm9yIHRo ZSBzYW1lDQogICAgIGdsb2JhbC1waG9uZSwgYnV0IGl0IE1VU1QgZ2VuZXJh dGUgbXVsdGlwbGUgImZheC1tYm94IiBlbGVtZW50cw0KICAgICB3aGVuIHN1 Ym1pdHRpbmcgdGhlIG1lc3NhZ2UgdG8gdGhlIE1UQS4NCg0KDQo0LjIgU29t ZSBleGFtcGxlcyBvZiBtaW5pbWFsICJmYXgtZW1haWwiDQoNCiAgIFNvbWUg ZXhhbXBsZXMgb2YgbWluaW1hbCBmYXgtZW1haWwgYWRkcmVzc2VzIGZvbGxv d3M6DQoNCiAgICAgIEZBWD0rMzk0MDIyNjMzOEBmYXh3b3JsZC5vcmcNCg0K ICAgICAgRkFYPSsxMjAyNzY1MzAwMC9UMzNTPTEzODdAZmF4d29ybGQub3Jn DQoNCiAgICAgIC9GQVg9KzMzLTEtODgzMzUyMTUvQGZheHdvcmxkLm9yZw0K DQogICBOb3RlOiANCiAgICAgIHRoZSBleGFtcGxlcyBzaG93biBhcmUganVz dCBmb3IgaWxsdXN0cmF0aW9uIHB1cnBvdXNlcy4NCg0KDQo1LiBDb25jbHVz aW9uDQoNCiAgIFRoaXMgcHJvcG9zYWwgY3JlYXRlcyBhIG1pbmltYWwgc3Rh bmRhcmQgZW5jb2RpbmcgZm9yIEZBWCBhZGRyZXNzZXMNCiAgIHdpdGhpbiB0 aGUgZ2xvYmFsIGUtbWFpbCB0cmFuc3BvcnQgc3lzdGVtLiBUaGUgcHJvcG9z YWwgaXMgY29uc2lzdGVudA0KICAgd2l0aCBleGlzdGluZyBlLW1haWwgc3Rh bmRhcmRzLg0KDQoNCjYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbWVhbnMgYnkgd2hpY2ggRkFY IGFkZHJlc3NlcyBjYW4gYmUNCiAgIGVuY29kZWQgaW50byBlLW1haWwgYWRk cmVzc2VzLiBTaW5jZSBlLW1haWwgcm91dGluZyBpcyBkZXRlcm1pbmVkIGJ5 DQogICBEb21haW4gTmFtZSBTeXN0ZW0gKEROUykgZGF0YSwgYSBzdWNjZXNz ZnVsIGF0dGFjayB0byBETlMgY291bGQgDQogICBkaXNzZW1pbmF0ZSB0YW1w ZXJlZCBpbmZvcm1hdGlvbiwgd2hpY2ggY2F1c2VzIGUtbWFpbCBtZXNzYWdl cyB0byBiZQ0KICAgZGl2ZXJ0ZWQgdmlhIHNvbWUgTVRBIG9yIEdhdGV3YXkg d2hlcmUgdGhlIHNlY3VyaXR5IG9mIHRoZSBzb2Z0d2FyZQ0KICAgaGFzIGJl ZW4gY29tcHJpbWlzZWQuDQoNCiAgIFRoZXJlIGFyZSBzZXZlcmFsIG1lYW5z IGJ5IHdoaWNoIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gZGVsaXZl cg0KICAgaW5jb3JyZWN0IG1haWwgcm91dGluZyBpbmZvcm1hdGlvbiB0byBh IGNsaWVudC4gVGhlc2UgaW5jbHVkZTogKGEpDQogICBjb21wcm9taXNlIG9m IGEgRE5TIHNlcnZlciwgKGIpIGdlbmVyYXRpbmcgYSBjb3VudGVyZmVpdCBy ZXNwb25zZSB0bw0KICAgYSBjbGllbnQncyBETlMgcXVlcnksIChjKSByZXR1 cm5pbmcgaW5jb3JyZWN0ICJhZGRpdGlvbmFsDQogICBpbmZvcm1hdGlvbiIg aW4gcmVzcG9uc2UgdG8gYW4gdW5yZWxhdGVkIHF1ZXJ5LiBDbGllbnRzIFNI T1VMRCBlbnN1cmUNCiAgIHRoYXQgbWFpbCByb3V0aW5nIGlzIGJhc2VkIG9u bHkgb24gYXV0aG9yaXRhdGl2ZSBhbnN3ZXJzLiBPbmNlIEROUw0KICAgU2Vj dXJpdHkgbWVjaGFuaXNtcyBbNV0gYmVjb21lIG1vcmUgd2lkZWx5IGRlcGxv eWVkLCBjbGllbnRzIFNIT1VMRA0KICAgZW1wbG95IHRob3NlIG1lY2hhbmlz bXMgdG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgYW5kIGludGVncml0eSBv Zg0KICAgbWFpbCByb3V0aW5nIHJlY29yZHMuDQoNCg0KICAgNy4gSUFOQSBD b25zaWRlcmF0aW9ucw0KDQogICBUaGUgSUFOQSByZWdpc3RyYXRpb24gZm9y bXMgZm9yICJGQVgiIHNlcnZpY2Utc2VsZWN0b3IgYW5kICJUMzNTIg0KICAg cXVhbGlmLXR5cGUxIGVsZW1lbnRzIGFyZSBkZWZpbmVkIGhlcmUuIFRoZXNl IGZvcm1zIHVwZGF0ZSB0aGUNCiAgIHByZXZpb3VzIHJlZ2lzdHJhdGlvbiBm b3JtcyBkZWZpbmVkIGluIFsxNV0uDQoNCiAgIDcuMSBJQU5BIFJlZ2lzdHJh dGlvbiBmb3JtIGZvciB1cGRhdGVkIHZhbHVlIG9mIEdTVE4gDQogICAgICAg YWRkcmVzcyBzZXJ2aWNlLXNlbGVjdG9yICJGQVgiDQoNCiAgIFRvOiBJQU5B QGlzaS5lZHUgDQogICBTdWJqZWN0OiBSZWdpc3RyYXRpb24gb2YgdXBkYXRl ZCB2YWx1ZXMgZm9yIHRoZSBHU1ROIGFkZHJlc3MgDQogICAgICAgICAgICBz ZXJ2aWNlLXNlbGVjdG9yIHNwZWNpZmllciAiRkFYIg0KICAgICAgIA0KICAg c2VydmljZS1zZWxlY3RvciBuYW1lOg0KDQogICAgICBGQVgNCg0KICAgRGVz Y3JpcHRpb24gb2YgVXNlOg0KDQogICAgICBGQVggLSBzcGVjaWZ5IHRoYXQg dGhlIEdTVE4gYWRkcmVzcyByZWZlcnMgZWl0aGVyIHRvIGFuIA0KICAgICAg SW50ZXJuZXQgRmF4IGRldmljZSwgb3IgYW4gb25yYW1wL29mZnJhbXAgRmF4 IGdhdGV3YXkuDQoNCiAgICAgIEZvciBhIGNvbXBsZXRlIGRlc2NyaXB0aW9u IHJlZmVyIHRvIFJGQzIzMDRiaXMgYW5kIFJGQzIzMDNiaXMNCg0KICAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnM6DQoNCiAgICAgIFNlZSB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uIG9mIFJGQzIzMDRiaXMuDQoNCiAg IFBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29udGFjdCBmb3IgZnVydGhl ciBpbmZvcm1hdGlvbjoNCg0KICAgICAgQ2xhdWRpbyBBbGxvY2NoaW8NCiAg ICAgIElORk4tR0FSUg0KICAgICAgYy9vIFNpbmNyb3Ryb25lIFRyaWVzdGUN CiAgICAgIFNTIDE0IEttIDE2My41IEJhc292aXp6YQ0KICAgICAgSSAzNDAx MiBUcmllc3RlDQogICAgICBJdGFseQ0KDQogICAgICBSRkM4MjI6IENsYXVk aW8uQWxsb2NjaGlvQGVsZXR0cmEudHJpZXN0ZS5pdA0KICAgICAgWC40MDA6 ICBDPWl0O0E9Z2FycjtQPVRyaWVzdGU7Tz1FbGV0dHJhOw0KICAgICAgICAg ICAgICBTPUFsbG9jY2hpbztHPUNsYXVkaW87DQogICAgICBQaG9uZTogICsz OSAwNDAgMzc1ODUyMw0KICAgICAgRmF4OiAgICArMzkgMDQwIDM3NTg1NjUN Cg0KDQo3LjIgSUFOQSBSZWdpc3RyYXRpb24gZm9ybSBmb3IgdXBkYXRlZCB2 YWx1ZSBvZiBHU1ROIA0KICAgICAgIGFkZHJlc3MgcXVhbGl0LXR5cGUxIGtl eXdvcmQgIlQzM1MiIGFuZCB2YWx1ZQ0KDQpUbzogSUFOQUBpc2kuZWR1IA0K ICAgU3ViamVjdDogUmVnaXN0cmF0aW9uIG9mIHVwZGF0ZWQgdmFsdWVzIGZv ciB0aGUgR1NUTiBhZGRyZXNzIA0KICAgICAgICAgICAgcXVhbGlmLXR5cGUx IGVsZW1lbnQgIlQzM1MiDQogICAgICAgDQogICBxdWFsaWYtdHlwZTEgImtl eXdvcmQiIG5hbWU6DQoNCiAgICAgIFQzM1MNCg0KICAgcXVhbGlmLXR5cGUx ICJ2YWx1ZSIgQUJORiBkZWZpbml0aW9uOg0KDQogICAgICBzdWItYWRkciA9 IDEqKCBESUdJVCApDQoNCiAgIERlc2NyaXB0aW9uIG9mIFVzZToNCg0KICAg ICAgVDMzUyBpcyB1c2VkIHRvIHNwZWNpZnkgdGhlIG51bWVyaWMgb25seSBv cHRpb25hbCBmYXggc3ViLWFkZHJlc3MNCiAgICAgIGVsZW1lbnQgZGVzY3Jp YmVkIGluICJJVFUgVC4zMyAtIEZhY3NpbWlsZSByb3V0aW5nIHV0aWxpemlu ZyB0aGUgDQogICAgICBzdWJhZGRyZXNzOyByZWNvbW1lbmRhdGlvbiBULjMz IChKdWx5LCAxOTk2KSIuIEZ1cnRoZXIgZGV0YWlsZWQNCiAgICAgIGRlc2Ny aXB0aW9uIGlzIGF2YWlsYWJsZSBpbiBSRkMyMzA0Lg0KDQogICBVc2UgUmVz dHJpY3Rpb246DQoNCiAgICAgIFRoZSB1c2Ugb2YgIlQzM1MiIGlzIHJlc3Ry aWN0ZWQgdG8gIkZBWCIgc2VydmljZS1zZWxlY3RvciwgaXMgaXQgaGFzDQog ICAgICBubyBtZWFuaW5nIG91dHNpZGUgdGhlIGZheCBzZXJ2aWNlLg0KDQog ICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczoNCg0KICAgICAgU2VlIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9uIHNlY3Rpb24gb2YgUkZDMjMwNGJpcy4N Cg0KICAgUGVyc29uICYgZW1haWwgYWRkcmVzcyB0byBjb250YWN0IGZvciBm dXJ0aGVyIGluZm9ybWF0aW9uOg0KDQogICAgICBDbGF1ZGlvIEFsbG9jY2hp bw0KICAgICAgSU5GTi1HQVJSDQogICAgICBjL28gU2luY3JvdHJvbmUgVHJp ZXN0ZQ0KICAgICAgU1MgMTQgS20gMTYzLjUgQmFzb3ZpenphDQogICAgICBJ IDM0MDEyIFRyaWVzdGUNCiAgICAgIEl0YWx5DQoNCiAgICAgIFJGQzgyMjog Q2xhdWRpby5BbGxvY2NoaW9AZWxldHRyYS50cmllc3RlLml0DQogICAgICBY LjQwMDogIEM9aXQ7QT1nYXJyO1A9VHJpZXN0ZTtPPUVsZXR0cmE7DQogICAg ICAgICAgICAgIFM9QWxsb2NjaGlvO0c9Q2xhdWRpbzsNCiAgICAgIFBob25l OiAgKzM5IDA0MCAzNzU4NTIzDQogICAgICBGYXg6ICAgICszOSAwNDAgMzc1 ODU2NSAgIA0KDQoNCiAgIDguIEF1dGhvcidzIEFkZHJlc3MNCg0KICAgQ2xh dWRpbyBBbGxvY2NoaW8NCiAgIElORk4tR0FSUg0KICAgYy9vIFNpbmNyb3Ry b25lIFRyaWVzdGUNCiAgIFNTIDE0IEttIDE2My41IEJhc292aXp6YQ0KICAg SSAzNDAxMiBUcmllc3RlDQogICBJdGFseQ0KDQogICBSRkM4MjI6IENsYXVk aW8uQWxsb2NjaGlvQGVsZXR0cmEudHJpZXN0ZS5pdA0KICAgWC40MDA6ICBD PWl0O0E9Z2FycjtQPVRyaWVzdGU7Tz1FbGV0dHJhOw0KICAgICAgICAgICBT PUFsbG9jY2hpbztHPUNsYXVkaW87DQogICBQaG9uZTogICszOSAwNDAgMzc1 ODUyMw0KICAgRmF4OiAgICArMzkgMDQwIDM3NTg1NjUNCg0KOS4gUmVmZXJl bmNlcw0KDQogICBbMV0gIFBvc3RlbCwgSi4sICJTaW1wbGUgTWFpbCBUcmFu c2ZlciBQcm90b2NvbCIsIFNURCAxMCwgUkZDIDgyMSwNCiAgICAgICAgQXVn dXN0IDE5ODIuIC0tPiBEUlVNUz8NCg0KICAgWzJdICBDcm9ja2VyLCBELiwg IiBTdGFuZGFyZCBmb3IgdGhlIGZvcm1hdCBvZiBBUlBBIEludGVybmV0IHRl eHQNCiAgICAgICAgbWVzc2FnZXMiLCBTVEQgMTEsIFJGQyA4MjIsIEF1Z3Vz dCAxOTgyLiAtLT4gRFJVTVM/DQoNCiAgIFszXSAgQnJhZGVuLCBSLiwgIlJl cXVpcmVtZW50cyBmb3IgSW50ZXJuZXQgaG9zdHMgLSBhcHBsaWNhdGlvbiBh bmQNCiAgICAgICAgc3VwcG9ydCIsIFJGQyAxMTIzLCBPY3RvYmVyIDE5ODku DQoNCiAgIFs0XSAgTWFsYW11ZCwgQy4gYW5kIE0uIFJvc2UsICJQcmluY2lw bGVzIG9mIE9wZXJhdGlvbiBmb3IgdGhlDQogICAgICAgIFRQQy5JTlQgU3Vi ZG9tYWluOiBSZW1vdGUgUHJpbnRpbmcgLS0gVGVjaG5pY2FsIFByb2NlZHVy ZXMiLCBSRkMNCiAgICAgICAgMTUyOCwgT2N0b2JlciAxOTkzLg0KDQogICBb NV0gIEVhc3RsYWtlLCBELiBhbmQgQy4gS2F1Zm1hbiwgIkRvbWFpbiBOYW1l IFN5c3RlbSBTZWN1cml0eQ0KICAgICAgICBFeHRlbnNpb25zIiwgUkZDIDIw NjUsIEphbnVhcnkgMTk5Ny4NCg0KICAgWzZdICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1l bnQNCiAgICAgICAgTGV2ZWxzIiwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoN CiAgIFs3XSAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50 ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAgU3BlY2lmaWNhdGlvbnMiLCBS RkMgMjIzNCwgTm92ZW1iZXIgMTk5Ny4NCg0KICAgWzhdICBJVFUgRi40MDEg LSBNZXNzYWdlIEhhbmRsaW5nIFNlcnZpY2VzOiBOYW1pbmcgYW5kIEFkZHJl c3NpbmcgZm9yDQogICAgICAgIFB1YmxpYyBNZXNzYWdlIEhhbmRsaW5nIFNl cnZpY2U7IHJlY29tbWVuZGF0aW9uIEYuNDAxIChBdWd1c3QNCiAgICAgICAg MTk5MikNCg0KICAgWzldICBJVFUgRi40MjMgLSBNZXNzYWdlIEhhbmRsaW5n IFNlcnZpY2VzOiBJbnRlcmNvbW11bmljYXRpb24NCiAgICAgICAgQmV0d2Vl biB0aGUgSW50ZXJwZXJzb25hbCBNZXNzYWdpbmcgU2VydmljZSBhbmQgdGhl IFRlbGVmYXgNCiAgICAgICAgU2VydmljZTsgcmVjb21tZW5kYXRpb24gRi40 MjMgKEF1Z3VzdCAxOTkyKQ0KDQogICBbMTBdIElUVSBFLjE2NCAtIFRoZSBJ bnRlcm5hdGlvbmFsIFB1YmxpYyBUZWxlY29tbXVuaWNhdGlvbiBOdW1iZXJp bmcNCiAgICAgICAgUGxhbiBFLjE2NC9JLjMzMSAoTWF5IDE5OTcpDQoNCiAg IFsxMV0gSVRVIFQuMzMgLSBGYWNzaW1pbGUgcm91dGluZyB1dGlsaXppbmcg dGhlIHN1YmFkZHJlc3M7DQogICAgICAgIHJlY29tbWVuZGF0aW9uIFQuMzMg KEp1bHksIDE5OTYpDQoNCiAgIFsxMl0gRVRTSSBJLUVUUyAzMDAsMzgwIC0g VW5pdmVyc2FsIFBlcnNvbmFsIFRlbGVjb21tdW5pY2F0aW9uDQogICAgICAg IChVUFQpOiBBY2Nlc3MgRGV2aWNlcyBEdWFsIFRvbmUgTXVsdGkgRnJlcXVl bmN5IChEVE1GKSBzZW5kZXINCiAgICAgICAgZm9yIGFjb3VzdGljYWwgY291 cGxpbmcgdG8gdGhlIG1pY3JvcGhvbmUgb2YgYSBoYW5kc2V0IHRlbGVwaG9u ZQ0KICAgICAgICAoTWFyY2ggMTk5NSkNCg0KICAgWzEzXSBBbGxvY2NoaW8s IEMuLCAiTWluaW1hbCBHU1ROIGFkZHJlc3MgZm9ybWF0IGluIEludGVybmV0 IE1haWwiLA0KICAgICAgICBSRkMgMjMwM2JpcywgeHh4eCAxOTk5Lg0KDQog ICBbMTRdIEtpbGxlLCBTLiwgIk1JWEVSIChNaW1lIEludGVybmV0IFguNDAw IEVuaGFuY2VkIFJlbGF5KTogTWFwcGluZw0KICAgICAgICBiZXR3ZWVuIFgu NDAwIGFuZCBSRkMgODIyL01JTUUiLCBSRkMgMjE1NiwgSmFudWFyeSAxOTk4 Lg0KDQogICBbMTVdIEFsbG9jY2hpbywgQy4gIkdTVE4gYWRkcmVzcyBlbGVt ZW50IGV4dGVuc2lvbnMgaW4gZS1tYWlsIA0KICAgICAgICBzZXJ2aWNlcyIs IFJGQyAyODQ2LCBKdW5lIDIwMDAuDQoNCg0KMTAuICBGdWxsIENvcHlyaWdo dCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMTk5OSkuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQogICBU aGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhbmQgZnVybmlzaGVkIHRvDQogICBvdGhlcnMsIGFuZCBkZXJpdmF0 aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFp biBpdA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkg YmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkDQogICBhbmQgZGlzdHJp YnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rp b24gb2YgYW55DQogICBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZSBj b3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUNCiAgIGlu Y2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jr cy4gIEhvd2V2ZXIsIHRoaXMNCiAgIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90 IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2ggYXMgYnkgcmVtb3ZpbmcN CiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhl IEludGVybmV0IFNvY2lldHkgb3Igb3RoZXINCiAgIEludGVybmV0IG9yZ2Fu aXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9m DQogICBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBj YXNlIHRoZSBwcm9jZWR1cmVzIGZvcg0KICAgY29weXJpZ2h0cyBkZWZpbmVk IGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlDQog ICBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGlu dG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4NCiAgIEVuZ2xpc2guDQoNCiAgIFRo ZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBl dHVhbCBhbmQgd2lsbCBub3QgYmUNCiAgIHJldm9rZWQgYnkgdGhlIEludGVy bmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4NCg0K ICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5H SU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5U SUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORw0KICAgQlVUIE5P VCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhF IElORk9STUFUSU9ODQogICBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5Z IFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GDQogICBNRVJD SEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UuDQoNCg0K --3213-1103527590-968341484=:538977353-- From owner-ietf-fax@mail.imc.org Fri Sep 8 19:56:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02402 for ; Fri, 8 Sep 2000 19:56:08 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA02292 for ietf-fax-bks; Fri, 8 Sep 2000 15:42:33 -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 PAA02288 for ; Fri, 8 Sep 2000 15:42:30 -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 SAA18523 for ; Fri, 8 Sep 2000 18:44:15 -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 PAA04209 for ; Fri, 8 Sep 2000 15:44:14 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Fri, 8 Sep 2000 15:44:14 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE092C8FD2@mercury.ADOC.xerox.com> From: "Cancio, Vivian" To: ietf-fax@imc.org Subject: Implementers Guide Version 03d Date: Fri, 8 Sep 2000 15:44:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C019E6.4FA85970" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C019E6.4FA85970 Content-Type: text/plain; charset="iso-8859-1" Please, review new version. October is our dateline. Section 5 was partly rewritten by D. Wing and also Section 6 was added to clarify the encoding of '=' in ORCPT. Vivian ------_=_NextPart_000_01C019E6.4FA85970 Content-Type: text/plain; name="draft-ietf-fax-implementers-guide-03d.txt" Content-Disposition: attachment; filename="draft-ietf-fax-implementers-guide-03d.txt" Content-Transfer-Encoding: quoted-printable IETF Fax Working Group = Vivian Cancio Internet Draft Xerox = Corporation Category: Work-in-progress Mike = Moldovan Intended Category: Informational G3Nova = Technology, Inc. = Hiroshi Tamura Ricoh = Company, LTD. = Dan Wing = Cisco Systems =20 6 = September 2000 Expires: = January 2001 Implementers Guide for Facsimile Using Internet Mail Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. =20 [[INTENDED STATUS: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.]] Copyright Notice Copyright (C) The Internet Society 1999. All Rights Reserved. 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 =20 referenced documents.=20 =20 Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 1] Internet draft Implementers Guide 6 = September 2000 Table of contents 1. Introduction =20 1.1 Organization of this document 1.2 Convention of this document =20 1.3 Discussion of this document =20 2. Terminology=20 3. Implementation Issues Specific to Simple Mode=20 3.1 Simple Mode Fax Senders 3.1.1 Multipart-alternative =20 3.2 Simple Mode Fax Receivers 3.2.1 Multipart-alternative and Storage Capacity 4. Implementation Issues Specific to Extended Mode 4.1 Multipart-alternative=20 4.2 Correlation of MDN with Original Message=20 4.3 Correlation of DSN with Original Message=20 4.4 Extended Mode Receivers 4.4.1 Confirmation of receipt and processing from UA Clients 4.4.1.1 Discrepancies in MDN [9] Interpretation 4.4.1.2 Disposition-Type: "dispatched" 4.4.1.3 "Subject" of MDN in Success and Failure Cases=20 4.4.1.4 "Body" of MDN in Success and Failure Cases=20 4.4.2 Extended Mode Receivers that are MTAs (or ESMTP servers) 4.4.2.1 Success Case Example 4.4.2.2 Failure Case Example 1 4.4.2.3 Failure Case Example 2 4.4.3 Extended Mode Receivers that are POP3/IMAP4=20 4.4.3.1 Success Case Example 4.4.3.2 Failure Case Example 4.4.4 Receiving Multiple TIFF-FX Attachments=20 5. Implementation Issues the File Format 5.1 IFD Placement in TIFF file & Profile-S Constraints 5.2 Precautions for implementers of RFC 2301 [4]=20 5.2.1 TIFF Readers: Be Cautious with Headers 5.2.2 TIFF Writers: Be Cautious in use of IFD=20 5.2.3 IFD Entry Errors 5.2.4 Strip Errors 5.2.5 Image Errors 5.2.6 Profile Specific Errors 6. Implementation Issues for Internet Fax Addressing 7. Security considerations=20 8. Acknowledgements =20 9. References=20 10. Authors' addresses=20 Full copyright statement=20 Revision history=20 Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 2] Internet draft Implementers Guide 6 = September 2000 1. Introduction This document clarifies published RFCs which standardize facsimile=20 communications using Internet Email. The intent is to prevent = implementations=20 that deviate in such a way as to cause interoperability problems.=20 1.1 Organization of this document See Section 2 for terminology. a) Simple mode clarifications b) Extended mode clarifications c) File format clarifications d) Fax Addressing Clarifications e) Open implementation issues 1.2. Convention of this document [[[Editorial comments from authors are embedded in triple brackets and will be removed before publication]]] 1.3 Discussion of this document Discussion of this document should take place on the Internet fax mailing list hosted by the Internet Mail Consortium (IMC). Please send comments regarding this document to: ietf-fax@imc.org To subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org". To see what has gone on before you subscribed, please see the mailing list archive at: http://www.imc.org/ietf-fax/ =20 2. Terminology Simple Mode - RFC 2305, "A Simple Mode of Facsimile Using Internet = Mail" [2] Extended Mode - RFC 2532, "Extended Facsimile Using Internet Mail" [3] TIFF-FX - RFC 2301, "File Format for Internet Fax" [4] UA - User Agent DSN - Delivery Status Notification [7] MDN - Message Disposition Notification [9] In examples: - "C:" is used to indicates lines sent by the client, and "S:" to indicate those sent by the server. MTA - Message Transfer Agent Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 3] Internet draft Implementers Guide 6 = September 2000 3. Implementation Issues Specific to Simple Mode 3.1 Simple Mode Fax Senders 3.1.1 Multipart/alternative Although a requirement of MIME compliance (see RFC 2046, Section = 5.1.4), some=20 email client implementations are not capable of correctly processing = messages=20 with a MIME Content-Type of "multipart/alternative". If a sender is = unsure if=20 the recipient is able to correctly process a message with a = Content-Type of=20 "multipart/alternative", the sender should assume the worst and not use = this=20 MIME Content-Type. 3.2 Simple Mode Fax Receivers 3.2.1 Multipart/alternative and Storage Capacity Devices with little storage capacity are unable to cache previous parts = of a=20 multipart/alternative message. In order for such devices to correctly = process=20 only one part of a multipart/alternative message, such devices may = simply use=20 the first process-able part of a multipart/alternative message. This is = viable=20 because the parts within a multipart/alternative are always sent in = least- fidelity to most-fidelity order.=20 This behavior means that even if subsequent, higher-fidelity parts may = have been=20 process-able they will not be used. =20 This behavior can cause user dissatisfaction because when two = high-fidelity=20 but low-memory devices are used with each other, the lowest-fidelity = part of=20 the multipart/alternative will be processed. The solution to this problem is for the sender to determine the = capability of=20 the recipient and send only high fidelity. However a mechanism to = determine the=20 recipient capabilities priorto an initial message sent to the recipient = doesn't=20 yet exist on the Internet. After an initial message is sent, the Extended Mode mechanism described = in RFC=20 2532 [3], Section 3.3 enables a recipient to include its capabilities = in a=20 delivery and/or a disposition notification: in a DSN if the recipient = device is=20 an RFC 2532/ESMTP [3] compliant server or in an MDN if the recipient is = only an=20 UA.=20 Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 4] Internet draft Implementers Guide 6 = September 2000 4. Implementation Issues Specific to Extended Mode 4.1 Multipart/Alternative Sections 3.1.1 and 3.2.1 are also applicable to this mode. 4.2. Correlation of MDN with Original Message To re-iterate a paragraph from section 2.1, RFC 2298 [9], it is included here: A message that contains a Disposition-Notification-To header SHOULD also contain a Message-ID header as specified in RFC 822 [10]. = This=20 will permit automatic correlation of MDNs with original messages = by user agents. 4.3 Correlation of DSN with Original Message Similar to the requirement to correlate an MDN, above, DSNs also need = to be=20 correlated. This is best done using the ENVID parameter in the "MAIL"=20 command. See Sections 3 and 5.4 of RFC 1891 [5] for details. 4.4 Extended Mode Receivers Confirmation that the facsimile image (TIFF-FX attachment) was = delivered and=20 successfully processed is an important aspect of the extended mode of = facsimile=20 using Internet mail. 4.4.1 Confirmation of receipt and processing from UA Clients When a message is received with the "Disposition-Notification-To" = header and the=20 receiver has determined if the message is process-able, it may generate = a: a) Negative MDN in case of error, or b) Positive MDN if requested by the sender. =20 The advantage of receiving a requested MDN acknowledgement from an = Extended Mode=20 recipient is the indication of success or failure to process the = TIFF-FX file=20 attachment that was sent. The attachment constitutes the facsimile = message and=20 not the body-content of the message. Therefore an Extended Mode sender = would=20 expect, and it is recommended that the Extended Mode receiver will = acknowledge=20 (with an MDN) the success or failure to decode and process the TIFF = file=20 attachment. Implementers of the Extended Mode [3] should provide consistency in the = feedback=20 provided to senders in the form of error codes and/or = failure/successful=20 messages. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 5] Internet draft Implementers Guide 6 = September 2000=20 4.4.1.1 Discrepancies in MDN [9] Interpretation An Extended Mode sender must be aware that RFC 2298 [9] does not make a = distinction between the success or failure to decode the body-content = part of=20 the message, from the success or failure to decode a file attachment.=20 Consequently MDNs may be received which do not reflect the success or = failure to=20 decode the attached TIFF-FX file, but rather to decode the body-content = part of=20 the message. 4.4.1.2 Disposition-Type: "dispatched". The receiver of an MDN request, if it is also an a RFC 2532 compliant = device=20 that automatically prints the received Internet mail messages and = attachments,=20 or forwards the attachment via GSTN fax, should respond with a = "disposition- type: dispatched" when the received message is successfully processed. = This=20 recommendation adheres to the definition in RFC 2298 [9] and helps to=20 distinguish the returned MDNs for proper handling. 4.4.1.3 "Subject" of MDN in Success and Failure Cases Because legacy e-mail applications do not parse the machine-readable = headers, e- mail users depend on the human-readable parts of the MDN to recognize = the type=20 of acknowledgement that is received. For the sake of consistency and to = help=20 users visually distinguish a DSN from an MDN returned notification, it = is=20 suggested that the text 'disposition' be used for MDNs in the 'Subject' = field. Example: Subject: Disposition Notification (MDN) - Successful or Subject: Disposition Notification (MDN) =96 Failure 4.4.1.4 "Body" of MDN in Success and Failure Cases If the receiver of an MDN request is also an RFC 2532 [3] compliant = device that=20 automatically prints the received Internet mail messages and = attachments, or=20 forwards the attachment via GSTN fax, for consistency the following = text is=20 suggested for the body of the message. In case of success: "This is a Return Receipt for the mail that you sent to [above, or = below, or=20 here address, etc]. The message and attached file[s] may have been = printed,=20 faxed or saved. This is no guarantee that the message has been read or=20 understood". In case if failure: "This is a Return Receipt for the mail that you sent to [above, or = below, or=20 here address, etc]. An error occurred while attempting to decode the = attached=20 file[s]. [[[Include details on error; and maybe recognize language (of sender) = in headers=20 to send above text in appropriate language. From D.W.]]] Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 6] Internet draft Implementers Guide 6 September = 2000=20 4.4.2 Extended Mode Receivers that are MTAs (or ESMTP servers) It is strongly encouraged that SMTP server-based implementations should = implement "SMTP Service Extension for Returning Enhanced Error Codes" = [6]. This=20 standard is easy to implement and it allows detailed standardized = success and=20 error indications to be returned to the sender by the submitting MTA. =20 The following examples are provided as illustration only. They should = not be=20 interpreted as limiting the protocol or the DSN form. If the examples = conflict=20 with the definitions in the standards (RFC 1891/1893/1894/2034), the = standards=20 take precedence and the examples in this documents should not be used.=20 4.4.2.1 Success Case Example In the following example the sender sends a = message to=20 receiver which is an ESMTP server and the = receiver=20 successfully decodes the message. SMTP Sequence: S: 220 copper.point.com SMTP service ready C: EHLO water.line.com S: 250-copper.point.com S: 250-DSN S: 250 ENHANCEDSTATUSCODES C: MAIL FROM: RET=3DHDRS ENVID=3DMM123456 S: 250 2.1.0 Originator ok C: RCPT TO: NOTIFY=3DSUCCESS,FAILURE = ORCPT=3Drfc822; ifax@copper.point.com S: 250 2.1.5 Recipient ok C: DATA S: 354 Send message, ending in . ... ...[[[Replace 'dots' with actual data. From D.W.]]] ... ... S: 250 2.0.0 Message accepted C: QUIT S: 221 2.0.0 Goodbye Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 7] Internet draft Implementers Guide 6 = September 2000=20 DSN (to jean@water.line.com): Date: Mon, 12 Dec 1999 19:01:57 +0900 From: postmaster@copper.point.com Message-ID: <19991212190157.01234@copper.point.com> To: jean@water.line.com Subject: Delivery Notification (DSN) MIME-Version: 1.0 Content-Type: multipart/report; report-type=3Ddelivery-status; boundary=3DJUK199912121854870001 --JUK199912121854870001 Content-type: text/plain; Your message (id MM123456) was successfully delivered to ifax@copper.point.com. --JUK199912121854870001 Content-type: message/delivery-status Reporting-MTA: dns; copper.point.com Original-Envelope-ID: MM123456 Final-Recipient: rfc822;ifax@copper.point.com Action: delivered Status: 2.1.5 (Destination address valid) Diagnostic-Code: smtp; 250 2.1.5 Recipient = ok --JUK199912121854870001 Content-type: message/rfc822 (headers of returned message go here) [[[Replace with actual header data. From D.W.]]] --JUK199912121854870001-- Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 8] Internet draft Implementers Guide 6 = September 2000=20 4.4.2.2 Failure Case Example 1 In this example the receiver determines it is unable to decode the = attached TIFF=20 file AFTER it has received the SMTP message. The receiver then sends a = 'failure'=20 DSN. SMTP Sequence: This is the same as the case a). After the sequence, a decode error = occurs at the receiver, so instead of a 'success' DSN, a 'failure' DSN is sent. = DSN(to jean@water.line.com): Date: Mon, 12 Dec 1999 19:31:20 +0900 From: postmaster@copper.point.com Message-ID: <19991212193120.87652@copper.point.com> To: jean@water.line.com Subject: Delivery Notification (DSN) - Failure MIME-Version: 1.0 Content-Type: multipart/report; report-type=3Ddelivery-status; boundary=3DJUK199912121934240002 --JUK199912121934240002 Content-type: text/plain; Your message (id MM123456) to ifax@copper.point.com resulted in an = error in attempt to decode the attached file. --JUK199912121934240002 Content-type: message/delivery-status Reporting-MTA: dns; copper.point.com Original-Envelope-ID: MM123456 Final-Recipient: rfc822;ifax@copper.point.com Action: Failed Status: 5.6.1 (Media not supported) Diagnostic-Code: smtp; 554 5.6.1 Decode error --JUK199912121934240002 Content-type: message/rfc822 (headers of returned message go here) [[[Replace with actual header data. From D.W.]]] =20 --JUK199912121934240002-- Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 9] Internet draft Implementers Guide 6 = September 2000=20 4.4.2.3 Failure Case Example 2 In this example the receiver determines it is unable to decode the = attached TIFF=20 file BEFORE it accepts the SMTP transmission. [[[It should be noted = that the=20 results could be the same if instead the receiver could not decode the = 'body=20 content' of the message. D.W. & V.C.]]] SMTP sequence: S: 220 copper.point.com SMTP service ready C: EHLO water.line.com S: 250-copper.point.com S: 250-DSN S: 250 ENHANCEDSTATUSCODES C: MAIL FROM: RET=3DHDRS ENVID=3DMM123456 S: 250 2.1.0 Originator ok C: RCPT TO: NOTIFY=3DSUCCESS,FAILURE = ORCPT=3Drfc822; ifax@copper.point.com=20 S: 250 2.1.5 Recipient ok C: DATA S: 354 Send message, ending in . ... ... (the attached file cannot be decoded by receiver) ... [[[Replace 'dots' with actual data. From D.W.]]] ... C: . S: 554 5.6.1 Media not supported C: QUIT S: 221 2.0.0 Goodbye DSN: Note: In this case, the previous MTA generates the DSN that is = forwarded to=20 the original sender. The receiving MTA has not accepted delivery and = therefore=20 can not generate a DSN. 4.4.3 Extended Mode Receivers that are POP3/IMAP4 NOTE: There are no new definitions here in this document. The = definitions of disposition-types and disposition-modifiers are defined in RFC 2298[9]. This section provides examples on how POP3/IMAP4 = devices may use the already defined values. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 10] Internet draft Implementers Guide 6 September = 2000=20 These examples are provided as illustration only. They should not be = interpreted=20 as limiting the protocol or the MDN form. If the examples conflict with = the=20 definitions in the MDN [9] standard, the standard takes precedence and = the=20 examples in this documents should not be used.=20 4.4.3.1 Success Case Example=20 If the original sender receives an MDNs which has "displayed", = "dispatched" or=20 "processed" disposition-type without disposition-modifier, the receiver = may have=20 possibly received or decoded the attached TIFF-FX file that it sent. It = does not=20 guarantee that the receiver displays, prints or saves the attached = TIFF-FX file=20 See Section 4.4.1.1, Discrepancies in MDN Interpretation. NOTE: This example does not include the third component of the MDN. Date: 14 Dec 1999 17:48:44 +0900 From: ken_recipient@bronze.dot.com Message-ID: <19991214174844.98765@silver.dot.com> Subject: Disposition Notification (MDN) To: mary@silver.dot.com Mime-Version: 1.0 Content-Type: multipart/report; = report-type=3Ddisposition-notification; boundary=3D"61FD1001_IFAX" --61FD1001_IFAX Content-Type: text/plain This is a Return Receipt for the mail that you sent to "ken_recipient@bronze.dot.com". The message and attached files may=20 have been printed, faxed or saved. This is no guarantee that the message has been read or understood. --61FD1001_IFAX Content-Type: message/disposition-notification Reporting-UA: ken-ifax.bronze.dot.com; barmail 1999.10 Original-Recipient: rfc822;ken_recipient@bronze.dot.com Final-Recipient: rfc822;ken_recipient@bronze.dot.com Original-Message-ID: <19991214174010O.mary@silver.dot.com> Disposition: automatic-action/MDN-send-automatically; dispatched --61FD1001_IFAX-- Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 11] Internet draft Implementers Guide 6 = September 2000=20 4.4.3.2 Failure Case Example=20 If the original sender receives an MDN with an "error" or "warning"=20 disposition-modifier, it is possible that the receiver could not = receive or=20 decode the attached TIFF-FX file. Currently there is no mechanism to = associate=20 the disposition-type with the handling of the main content body of the = message=20 or the attached TIFF-FX file. Date: 14 Dec 1999 19:48:44 +0900 From: ken_recipient@bronze.dot.com Message-ID: <19991214194844.67325@silver.dot.com> Subject: Disposition Notification (MDN) To: mary@silver.dot.com Mime-Version: 1.0 Content-Type: multipart/report; = report-type=3Ddisposition-notification; boundary=3D"84FD1011_IFAX" --84FD1011_IFAX Content-Type: text/plain This is a Return Receipt for the mail that you sent to "ken_recipient@bronze.dot.com". A decoding error occurred in the attached file. --84FD1011_IFAX Content-Type: message/disposition-notification Reporting-UA: ken-ifax.bronze.dot.com; barmail 1999.10 Original-Recipient: rfc822;ken_recipient@bronze.dot.com Final-Recipient: rfc822;ken_recipient@bronze.dot.com Original-Message-ID: <199912141823123.mary@silver.dot.com> Disposition: automatic-action/MDN-send-automatically; = processed/error --84FD1011_IFAX Content-Type: message/rfc822 [original message goes here] --84FD1011_IFAX-- Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 12] Internet draft Implementers Guide 6 = September 2000=20 4.4.4 Receiving Multiple TIFF-FX Attachments A received email message could contain multiple TIFF-FX attachments and = each=20 distinct TIFF-FX file may use different encoding and/or resolution. A = received=20 email message could include TIFF-FX attachment and non-TIFF-FX = attachments. There is currently no mechanism to identify, in a returned = notification, the=20 attachments that were successfully decoded from those that could not be = decoded. If the Extended Mode recipient is unable to decode any of the attached = files, it=20 is recommended that the Extended Mode recipient return a decoding = error. 5. Implementation Issues Specific to the File Format 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. 5.2 Precautions for implementers of RFC 2301 [4] =09 Interoperability testing of the File Format for Internet Fax [4] yielded useful information that may help developers avoid the same mistakes. The following compiled list of TIFF/RFC 2301 [4] errors were encountered during interoperability testing and is provided so that implementers of TIFF readers and writers can take precautionary measures. a) Although Profile S of TIFF-FX [4] specifies that files should be in little-endian order, during testing it was found that some common TIFF writers create big-endian files. If possible, the TIFF reader should be coded to handle big-endian files. TIFF writers should always create little-endian files to be compliant with the standard and to allow interoperation with memory-constrained devices; b) Bytes 0-1 of the Image File Header are supposed to be set to "II" = (4949h) or "MM" (4d4dh) to indicate the byte order. During testing, other values were encountered. Readers should be coded to exit gracefully if the byte order field contain values other than "II" or "MM", and writers should ensure the correct value is used; =20 Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 13] Internet draft Implementers Guide 6 = September 2000=20 c) Bytes 2-3 of the Image File Header are the "magic number" and are supposed to be equal to 42 (2Ah). Readers should be coded to = exit gracefully if the magic number is a different value, and writers should ensure the correct value is used; d) Readers should be coded to correctly handle the first and subsequent IFD offsets do not point beyond the end of the TIFF-FX file, and writers should not point the IFD offset beyond the end of the file; e) Readers should be coded to handle the first IFD offset being on a non-word boundary, and writers should create the first IFD offset on a word boundary; f) Readers and writers should be careful to correctly handle IFDs with other TIFF profile data such as strip image data and header data. g) Some readers have difficulties with IFDs in certain locations. If possible, such reader implementations should be corrected and TIFF writers should take extra precautions to not place IFDs in these positions: IFD at the end of the profile, IFD intercalated with another IFD data like XResolution, DateTime, or strip image data. h) Some readers do not support child IFDs. Child IFDs should not be created by TIFF writers. i) Some readers do not recognize the GlobalParametersIFD. The GlobalParametersIFD should not be created by TIFF writers. 5.2.3 IFD Entry Errors Implementers should make sure when generating a TIFF profile that: a) All entries exist. Missing entries make it impossible to read the image data. b) Tags will not have two types of data (for example SHORT or LONG). c) Tags do not have the wrong type of data (for example RATIONAL instead of SRATIONAL). d) The count of type is correct for a specified tag (it is not null and the matches the tag ID) e) Tags appear in the right order in the IFD. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 14] Internet draft Implementers Guide 6 = September 2000=20 f) Tags as PageNumber or ImageLayer have values that match the number of IFDs or the image data. g) Tags are unique within an IFD. =20 5.2.4 Strip Errors Implementers should make sure when generating a TIFF profile that: a) Strip data is not overlapped with another file data b) The strip offset does not point outside file c) The strip length is not null or the strip offset + strip length does not point outside file d) There is only one bit order (not more) specified for data = storing. 5.2.5 Image Errors a) Implementers should be cautious when generating a TIFF profile that the type of image tags and the data from the strip data match. For example, if in case of a black and white image the PhotometricInterpretation tag value is 0 (bit 0 means white) the image will appear inverted. b) Implementers should be cautious when generating a TIFF profile that for the special color spaces (ITULAB, YCBCR, CMYK) the parameters used for transformations are correct and compliant to the specification. c) Implementers should make sure when generating a TIFF profile that the tag values for XPosition and YPosition are correct. 5.2.6 Profile Specific Errors =20 a) Implementers should make sure when generating a TIFF profile that all combinations of tag values are correct. Special attention should be given to the sets: XResolution, YResolution and ImageWidth and PhotometricInterpretation, SamplesPerPixel, and BitsPerSample. b) Implementers should make sure when generating a TIFF Profile M that the compression used for the layers is correct. Typical errors are for the Mask layer not be compressed with a black and white compression and the Background and Foreground layer not to be compressed with a color compression. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 15] Internet draft Implementers Guide 6 = September 2000=20 6. Implementation Issues for Internet Fax Addressing The GSTN addresses in e-mail addresses specifications (currently = RFC2303,=20 RFC2304 and RFC2846) require the use of the "=3D" and "+" characters = inside the local-part (see RFC822) and forward-path and reverse-path (see = RFC821) of the address. In these fields the "=3D" and "+" characters are = allowed and thus they MUST NOT be encoded in any way. Also other message headers = fields extensions (like Original-Recipient, see RFC2298) allows these = characters which thus MUST NOT be encoded. However GSTN addresses can also appear in other fields, and in = particular=20 inside ESMTP parameters as esmtp-value (see RFC1869); the ORCPT = parameter (see RFC1891) is one of such cases. When the "=3D" and "+" characters = in=20 GSTN addresses appear as esmtp-value, they MUST be encoded as hexchar=20 (see RFC1891). In particular, the same GSTN address could require different behavior=20 inside the same ESMTP command line: RCPT TO: = ORCPT=3DFAX+3D+2B290408565@fxmail.com 7. Security considerations With regards to this document, Sections 5 in RFC 2305 [2] and Section 4 = in RFC 2532 [3] apply. 8. Acknowledgements he authors gratefully acknowledge the following persons who contributed = or=20 made comments on earlier versions of this memo: Claudio Allocchio, Richard Coles, Ryuji Iwazaki, Graham Klyne, James = Rafferty,=20 and Kensuke Yamada. 9. References [1] RFC 2542, "Terminology and Goals for Internet Fax", Masinter, L., March 1999. [2] RFC 2305, "A Simple Mode of Facsimile Using Internet Mail", Toyoda, K., Ohno, H., Murai, J. and Wing, D., March 1998. [3] RFC 2532, "Extended Facsimile Using Internet Mail", Masinter, L. and Wing, D. March 1999. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 16] Internet draft Implementers Guide September = 6, 2000 [4] RFC 2301 "File Format for Internet Fax", McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, March 1998. [5] RFC 1891 "SMTP Service Extension for Delivery Status Notification", Moore, K.,=20 January 1996. [6] RFC 1893 "Enhanced Mail System Status Codes", Vaudreuil, G., January 1996. [7] RFC 1894 "An Extensible Message Format for Delivery Status = Notifications", Moore, K., Vaudreuil, G., January 1996. [8] RFC 2034 "SMTP Service Extension for Returning Enhanced Error = Codes", Freed, N., October 1996. [9] RFC 2298 "An Extensible Message Format for Message Disposition=20 Notifications", Fajman, R. March 1998. [10] RFC 822 "Standard for the Format of ARPA Internet Text Messages", Crocker. D., August 1982. [11] RFC 821 "A Simple Mail Transfer Protocol", Postel, D., August 1982. 10. Authors' addresses Vivian Cancio Xerox Corporation Mailstop PAHV-211 3400 Hillview Ave. Palo Alto, CA 94304 USA Telephone: +1-650-813-7591 Facsimile: +1-650-845-2341 Email: vivian.cancio@pahv.xerox.com Mike Moldovan G3 Nova Technology, Inc. 2794 Queens Way Thousand Oaks, CA 91362 USA Telephone: +1-805-245-4625 Facsimile: +1-805-245-4214 Email: mmoldovan@g3nova.com Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 17] Internet draft Implementers Guide 6 = September 2000=20 Hiroshi Tamura Ricoh Company, LTD. 2446 Toda, Atsugi City, Kanagawa-Pref., 243-0023 Japan Telephone: +81-46-228-1743 Facsimile: +81-46-228-7500 Email: tamura@toda.ricoh.co.jp Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA Telephone: +1 831 457 5200 Facsimile: +1 831 457 5208 EMail: dwing@cisco.com Full copyright statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 18] Internet draft Implementers Guide 6 = September 2000=20 Revision history [[[RFC editor: Please remove this section on publication]]] Version 2 1) Changed first sentence of 4.4.1.1=20 2) Added Sections: 4.4.1.2, 4.4.1.3, 4.4.1.4, 4.4.2.1, 4.4.2.2, = 4.4.2.3, 4.4.3.1, 4.4.3.2 and 4.4.4 3) Deleted Sections: 6 and 7 4) Changed heading of Section 4.4.1=20 5) In examples: replaced ifax@water.line.com with ifax@copper.point.com as well as other editorial changes in the examples through the document. 6) In examples: changed text in subject field of DSN 7) In examples: changed text in subject field of MDN 8) In examples: changed text in text field of MDN 9) Reworded text through out the document 10) Replaced heading in 5.2.1 [to "TIFF Readers: Be Cautious with = Headers"] 11) " " 5.2.2 [to "TIFF Writers: Be Cautious in use of = IFD"] Version 3 1) Section 5.2.1 and 5.2.2 were merged into 5.2; some of the = paragraphs in Section 5 were reworded for clarity. 2) The RFC 821 was added to the Reference section 3) The Reference section format was modified for consistency. 4) A new Section 6 was added. Cancio, Moldovan, Tamura, Wing Work-in-progress = [Page 19] ------_=_NextPart_000_01C019E6.4FA85970-- From owner-ietf-fax@mail.imc.org Sat Sep 9 04:40:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20473 for ; Sat, 9 Sep 2000 04:40:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA11062 for ietf-fax-bks; Sat, 9 Sep 2000 01:13:15 -0700 (PDT) Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11058 for ; Sat, 9 Sep 2000 01:13:14 -0700 (PDT) Received: from imc.org (HSE-Toronto-ppp100850.sympatico.ca [216.209.79.163]) by smtp11.bellglobal.com (8.8.5/8.8.5) with SMTP id EAA29820 for ietf-fax@imc.org; Sat, 9 Sep 2000 04:22:35 -0400 (EDT) Message-Id: <200009090822.EAA29820@smtp11.bellglobal.com> From: Me@smtp11.bellglobal.com, Your.Friend.@smtp11.bellglobal.com REPLY-TO: colocatz@yahoo.com X-Mailer: EzyMassMailer V2.xx Date: 09 Sep 2000 To: Newsletter.Subscriber@smtp11.bellglobal.com Subject: Important Text - Something I need to tell you. Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We're not weird......we're sexy!!!!!!! http://205.232.74.175 From owner-ietf-fax@mail.imc.org Sun Sep 10 20:49:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11033 for ; Sun, 10 Sep 2000 20:49:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22235 for ietf-fax-bks; Sun, 10 Sep 2000 17:13:05 -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 RAA22231 for ; Sun, 10 Sep 2000 17:13:03 -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 JAA11457; Mon, 11 Sep 2000 09:08:13 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id JAA13575; Mon, 11 Sep 2000 09:08:13 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id JAA04513; Mon, 11 Sep 2000 09:08:10 +0900 To: Vivian.Cancio@pahv.xerox.com Cc: ietf-fax@imc.org Subject: Re: Implementers Guide Version 03d In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE092C8FD2@mercury.ADOC.xerox.com> References: <51B8ABCE456FD111899900805F6FD6EE092C8FD2@mercury.ADOC.xerox.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000911091020K.tamura@toda.ricoh.co.jp> Date: Mon, 11 Sep 2000 09:10:20 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 54 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vivian, A comment as a chiar. After collecting comments, please submit to internet-drafts@ietf.org as version 03. Version 2 is formerly the latest I-D. > Section 5 was partly rewritten by D. Wing and also Section 6 was added to > clarify the encoding of '=' in ORCPT. Editorial additions or modifications for Section 6 and References(section 9). > 6. Implementation Issues for Internet Fax Addressing > > The GSTN addresses in e-mail addresses specifications (currently RFC2303, > RFC2304 and RFC2846) require the use of the "=" and "+" characters inside > the local-part (see RFC822) and forward-path and reverse-path (see RFC821) > of the address. In these fields the "=" and "+" characters are allowed and > thus they MUST NOT be encoded in any way. Also other message headers fields > extensions (like Original-Recipient, see RFC2298) allows these characters > which thus MUST NOT be encoded. RFC2303 -> RFC 2303 [A] or [A] RFC2304 -> RFC 2304 [B] or [B] RFC2846 -> RFC 2846 [C] or [C] RFC822 -> RFC 822 [10] or [10] RFC821 -> RFC 821 [11] or [11] RFC2298 -> RFC 2298 [9] or [9] > However GSTN addresses can also appear in other fields, and in particular > inside ESMTP parameters as esmtp-value (see RFC1869); the ORCPT parameter > (see RFC1891) is one of such cases. When the "=" and "+" characters in > GSTN addresses appear as esmtp-value, they MUST be encoded as hexchar > (see RFC1891). RFC1869 -> RFC 1869 [D] or [D] RFC1891 -> RFC 1891 [5] or [5] Please add RFC references on [A],[B],[C],[D],[E] in section 7. A:12 B:13 C:14 D:15 E:16 I do not read section 1 through 4 yet. But, if they are the same as the version 02, no problems for me. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Tue Sep 12 07:22:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29675 for ; Tue, 12 Sep 2000 07:22:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12772 for ietf-fax-bks; Tue, 12 Sep 2000 03:48:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12767 for ; Tue, 12 Sep 2000 03:48:27 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28684; Tue, 12 Sep 2000 06:50:32 -0400 (EDT) Message-Id: <200009121050.GAA28684@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-minaddr-v2-02.txt Date: Tue, 12 Sep 2000 06:50:31 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Minimal GSTN address format in Internet Mail Author(s) : C. Allocchio Filename : draft-ietf-fax-minaddr-v2-02.txt Pages : 10 Date : 11-Sep-00 This memo describes a simple method of encoding GSTN addresses (commonly called 'telephone numbers') in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. As with all Internet mail addresses, the left-hand-side (local-part) of an address generated according to this specification, is not to be interpreted except by an MTA that handles messages for the domain given in the right-hand-side. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-minaddr-v2-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-minaddr-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-minaddr-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000911143426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-minaddr-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-minaddr-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143426.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Tue Sep 12 16:42:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14024 for ; Tue, 12 Sep 2000 16:42:37 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA29963 for ietf-fax-bks; Tue, 12 Sep 2000 12:52:02 -0700 (PDT) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA29954 for ; Tue, 12 Sep 2000 12:52:00 -0700 (PDT) Received: (qmail 5271 invoked from network); 12 Sep 2000 19:54:06 -0000 Received: from userbf77.uk.uudial.com (HELO GK-VAIO.Dial.pipex.com) (62.188.142.98) by smtp.dial.pipex.com with SMTP; 12 Sep 2000 19:54:06 -0000 Message-Id: <4.3.2.7.2.20000912200532.00b0aab0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Sep 2000 20:07:57 +0100 To: Hiroshi Tamura From: Graham Klyne Subject: Re: Progressing content negotiation, timely delivery Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-san, I am going through some _old_ e-mails, catching up on review comments for FFPIM. I think that your comments (copied below, with my responses) have been addressed in the -02 version of the content negotiation draft. If you notice I have missed anything, please let me know. #g -- 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. --end-- ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Sep 13 07:05:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04357 for ; Wed, 13 Sep 2000 07:05:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28377 for ietf-fax-bks; Wed, 13 Sep 2000 03:26:18 -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 DAA28372 for ; Wed, 13 Sep 2000 03:26:16 -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 TAA17324; Wed, 13 Sep 2000 19:28:22 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id TAA15877; Wed, 13 Sep 2000 19:28:21 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id TAA02193; Wed, 13 Sep 2000 19:28:15 +0900 To: GK@dial.pipex.com Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org, gparsons@nortelnetworks.com Subject: Re: Progressing content negotiation, timely delivery In-Reply-To: <4.3.2.7.2.20000912200532.00b0aab0@pop.dial.pipex.com> References: <4.3.2.7.2.20000912200532.00b0aab0@pop.dial.pipex.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000913193033J.tamura@toda.ricoh.co.jp> Date: Wed, 13 Sep 2000 19:30:33 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 61 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham, Thank you for your mail. > I am going through some _old_ e-mails, catching up on review comments for > FFPIM. > > I think that your comments (copied below, with my responses) have been > addressed in the -02 version of the content negotiation draft. Most of my comments has already been addressed there, though some may be necessary to modify or add. I think it is better to separate the minimum things for content-negotiation and the implementation issues such as "state". The implementatios issues are not normative but informative. But I think they should be better to describe in the document. BTW, from the minutes of VPIM WG at Pittsburgh, > Fax, CONNEG & RESCAP WGs update (Graham Klyne) > The first area covered is content negotiation (which could also be > applicable to VPIM), which allows a recipient to request an alternative > form of a message it received. > Action: Fax WG chair to take this discussion to the VPIM and FAX lists. > Work Group Focus - Glenn Parsons > -------------------------------- > > To close, Glenn reiterated the Work Groups focus areas: > > 1. Progress VPIMv2 to draft > 2. IVM > 3. The VPIM addenda items including: addressing, directory, IMAP, content > negotiation I could not attend the 2nd VPIM meeting. I do not know exactly. But, the one think I can say is that the idea of content-negotiation mechanism can also be used for VPIM. So, for the time being, I recommend you to post in VPIM WG ML as well as FAX WG ML, for this issue. Glenn, is it OK? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Wed Sep 13 09: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 SMTP id JAA07576 for ; Wed, 13 Sep 2000 09:25:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA02764 for ietf-fax-bks; Wed, 13 Sep 2000 05:51:05 -0700 (PDT) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA02760 for ; Wed, 13 Sep 2000 05:51:04 -0700 (PDT) Received: (qmail 4231 invoked from network); 13 Sep 2000 12:53:13 -0000 Received: from usereb40.uk.uudial.com (HELO GK-VAIO.Dial.pipex.com) (62.188.10.21) by smtp.dial.pipex.com with SMTP; 13 Sep 2000 12:53:13 -0000 Message-Id: <4.3.2.7.2.20000913134527.00bcfd00@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Sep 2000 13:50:17 +0100 To: Hiroshi Tamura From: Graham Klyne Subject: Re: Progressing content negotiation, timely delivery Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org, gparsons@nortelnetworks.com In-Reply-To: <20000913193033J.tamura@toda.ricoh.co.jp> References: <4.3.2.7.2.20000912200532.00b0aab0@pop.dial.pipex.com> <4.3.2.7.2.20000912200532.00b0aab0@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, At 07:30 PM 9/13/00 +0900, Hiroshi Tamura wrote: >I think it is better to separate the minimum things for content-negotiation >and the implementation issues such as "state". The implementatios issues >are not normative but informative. >But I think they should be better to describe in the document. OK, I'll try and ensure some separation in the next revision. We have many comments to work through! FYI, I'm hoping to get an updated timely delivery draft out very soon. >BTW, from the minutes of VPIM WG at Pittsburgh, [...] >I could not attend the 2nd VPIM meeting. I do not know exactly. >But, the one think I can say is that the idea of content-negotiation >mechanism can also be used for VPIM. > >So, for the time being, I recommend you to post in VPIM WG ML >as well as FAX WG ML, for this issue. Yes, I think it would be good to cross-post announcements But I also think it would be better to have any ongoing technical discussion in a single place -- and I think the fax WG list is it. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Sep 13 11:06:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09996 for ; Wed, 13 Sep 2000 11:06:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA05132 for ietf-fax-bks; Wed, 13 Sep 2000 07:35:44 -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 HAA05122 for ; Wed, 13 Sep 2000 07:35:41 -0700 (PDT) Received: from GK-VAIO.Dial.pipex.com (useraw70.uk.uudial.com [62.188.138.216]) by hose.pipex.net (Postfix) with ESMTP id 2F51245E6 for ; Wed, 13 Sep 2000 15:37:48 +0100 (BST) Message-Id: <4.3.2.7.2.20000913141900.00b95100@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Sep 2000 14:25:19 +0100 To: IETF fax WG From: Graham Klyne Subject: Question about requirements for timely delivery 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 would like to understand what sort of time interval is felt to be a reasonable when requesting timely delivery: (a) less than one second (b) 1-10 seconds (c) 10-60 seconds (d) over a minute If (a), and maybe (b), then I am concerned that the timing resolution offered by RFC 2852 may not be fine enough. RFC 2852 allows the deliver-by interval to be expressed as a whole number of seconds. Given that the value must be recalculated by each relay I fear that accumulated errors may make intervals less than (say) 10 seconds difficult to achieve reliably, and certainly not intervals less than a second. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Wed Sep 13 11:54:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10776 for ; Wed, 13 Sep 2000 11:54:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07478 for ietf-fax-bks; Wed, 13 Sep 2000 08:20:08 -0700 (PDT) Received: from inetmail1.turbopower.com (inetmail1.turbopower.com [209.151.79.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07473 for ; Wed, 13 Sep 2000 08:20:07 -0700 (PDT) Received: by inetmail1.turbopower.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 09:22:21 -0600 Message-ID: <714AD8888E79D211978700A0C90DFDB72F712D@inetmail1.turbopower.com> From: "Gary Frerking (TurboPower)" To: IETF fax WG Subject: RE: Question about requirements for timely delivery Date: Wed, 13 Sep 2000 09:22:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> I would like to understand what sort of time interval is felt to be a reasonable when requesting timely delivery: (c) seems reasonable to me, using normal POTS/PBX faxing as a point of comparison. It's very possible to break over the 10 sec mark when a call is working through the switches and so on -- particularly with international calls. The high end of the (c) range seems a bit high to me -- if there was a "(c1) 10 - 30 seconds" choice, I would pick that. -- Gary Frerking -- TurboPower Software Co. -- garyf@turbopower.com From owner-ietf-fax@mail.imc.org Wed Sep 13 20:58:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19804 for ; Wed, 13 Sep 2000 20:58:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA25691 for ietf-fax-bks; Wed, 13 Sep 2000 17:23:10 -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 RAA25687 for ; Wed, 13 Sep 2000 17:23:08 -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 JAA29899; Thu, 14 Sep 2000 09:25:17 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id JAA24296; Thu, 14 Sep 2000 09:25:16 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id JAA06670; Thu, 14 Sep 2000 09:25:12 +0900 To: GK@dial.pipex.com Cc: iwa@rdl.toshibatec.co.jp, ietf-fax@imc.org, gparsons@nortelnetworks.com Subject: Re: Progressing content negotiation, timely delivery In-Reply-To: <4.3.2.7.2.20000913134527.00bcfd00@pop.dial.pipex.com> References: <20000913193033J.tamura@toda.ricoh.co.jp> <4.3.2.7.2.20000913134527.00bcfd00@pop.dial.pipex.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000914092728N.tamura@toda.ricoh.co.jp> Date: Thu, 14 Sep 2000 09:27:28 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham, > FYI, I'm hoping to get an updated timely delivery draft out very soon. Thanks! > >So, for the time being, I recommend you to post in VPIM WG ML > >as well as FAX WG ML, for this issue. > > Yes, I think it would be good to cross-post announcements > > But I also think it would be better to have any ongoing technical > discussion in a single place -- and I think the fax WG list is it. OK, I see. I think there is a large change in the next content-negotiation I-D, including the chapter structure. I would like the editors to judge when the discussion should be cc'ed to VPIM ML. Any other suggestions? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Thu Sep 14 06:37:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08088 for ; Thu, 14 Sep 2000 06:37:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA08759 for ietf-fax-bks; Thu, 14 Sep 2000 03:04:14 -0700 (PDT) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA08755 for ; Thu, 14 Sep 2000 03:04:12 -0700 (PDT) Received: (qmail 29728 invoked from network); 14 Sep 2000 10:05:57 -0000 Received: from userat48.uk.uudial.com (HELO GK-VAIO.Dial.pipex.com) (62.188.137.151) by smtp.dial.pipex.com with SMTP; 14 Sep 2000 10:05:57 -0000 Message-Id: <4.3.2.7.2.20000914105142.00b23f00@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Sep 2000 10:55:19 +0100 To: IETF fax WG , IETF VPIM List From: Graham Klyne Subject: FYI: Content feature RFCs 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: FYI, Two new RFCs are recently published, dealing with matters that may affect content negotiation. (VPIM folks should also be aware that Internet fax group is discussing a content negotiation proposal that could be applicable to VPIM/IVM.) --- URL: ftp://ftp.isi.edu/in-notes/rfc2912.txt In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo defines a Multipurpose Internet Mail Extensions (MIME) 'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. This document is a product of the Content Negotiation Working Group of the IETF. This is now a Proposed Standard Protocol. --- URL: ftp://ftp.isi.edu/in-notes/rfc2913.txt In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data. This document is a product of the Content Negotiation Working Group of the IETF. This is now a Proposed Standard Protocol. --- #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Thu Sep 14 09:41:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11760 for ; Thu, 14 Sep 2000 09:41:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16189 for ietf-fax-bks; Thu, 14 Sep 2000 06:10:44 -0700 (PDT) Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16185 for ; Thu, 14 Sep 2000 06:10:41 -0700 (PDT) From: dfvbdopf@svr01.city-naruto.co.jp Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id NAA12202 for ; Thu, 14 Sep 2000 13:12:27 GMT env-from (dfvbdopf@svr01.city-naruto.co.jp) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eefpdl.in; 14 Sep 2000 14:51:00 +0200 To: Date: Thu, 14 Sep 2000 05:16:46 Message-Id: <600.549466.505698@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International From owner-ietf-fax@mail.imc.org Fri Sep 15 07:39:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17711 for ; Fri, 15 Sep 2000 07:39:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA07167 for ietf-fax-bks; Fri, 15 Sep 2000 03:57:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA07161 for ; Fri, 15 Sep 2000 03:57:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17338; Fri, 15 Sep 2000 07:00:19 -0400 (EDT) Message-Id: <200009151100.HAA17338@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-faxaddr-v2-02.txt Date: Fri, 15 Sep 2000 07:00:18 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Minimal FAX address format in Internet Mail Author(s) : C. Allocchio Filename : draft-ietf-fax-faxaddr-v2-02.txt Pages : 8 Date : 14-Sep-00 This memo describes a simple method of encoding GSTN addresses of facsimile devices in the local-part of Internet email addresses. As with all Internet mail addresses, the left-hand-side (local- part) of an address generated according to this specification, is not to be interpreted except by the MTA that is named on the right-hand-side (domain). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-faxaddr-v2-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-faxaddr-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-faxaddr-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000914115853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-faxaddr-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-faxaddr-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000914115853.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Mon Sep 18 05:20:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00285 for ; Mon, 18 Sep 2000 05:20:41 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA00672 for ietf-fax-bks; Mon, 18 Sep 2000 01:31:26 -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 BAA00667 for ; Mon, 18 Sep 2000 01:31:24 -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 RAA04273; Mon, 18 Sep 2000 17:33:59 +0900 (JST) Received: from newton.toda.ricoh.co.jp (newton.toda.ricoh.co.jp [133.139.60.10]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with SMTP id RAA02474; Mon, 18 Sep 2000 17:33:58 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by newton.toda.ricoh.co.jp (8.6.11+2.4W/3.3W9-1.0S8sun) with ESMTP id RAA06295; Mon, 18 Sep 2000 17:33:45 +0900 To: ietf-fax@imc.org Cc: ned.freed@innosoft.com, paf@cisco.com Subject: IETF-FAX WG Last Call on Addressing I-Ds X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Sep_18_17:36:14_2000_955)--" Content-Transfer-Encoding: 7bit Message-Id: <20000918173616I.tamura@toda.ricoh.co.jp> Date: Mon, 18 Sep 2000 17:36:16 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 194 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----Next_Part(Mon_Sep_18_17:36:14_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, This is a Working Group Last Call notice for the following two documents. 1 draft-ietf-fax-minaddr-v2-02.txt (update of RFC 2303) - Minimal GSTN address format in Internet Mail - For your information, the following is the technical summary when requesting to IESG. This memo describes a simple method of encoding GSTN addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. The method used is of general use for various application services where GSTN addresses and e-mail addresses are involved, like FAX and Voice Mail. The standard encoding method allows an easy interoperability of onramp/offramp gateways connecting e-mail service to other messaging systems using GSTN addresses. Currently the generic encoding method is being deployed inside Internet FAX compliant applications, which proved to interoperate correctly, but also global messaging application services are adopting it. The document also provides the needed documentation, procedures and templates for a correct registration c/o IANA of the extensions which can be defined. 2 draft-ietf-fax-faxaddr-v2-02.txt (update of RFC 2304) - Minimal FAX address format in Internet Mail - For your information, the following is the technical summary when requesting to IESG. This memo describes a simple method of encoding GSTN addresses of facsimile devices in the local-part of Internet email addresses. It is an application of draft-ietf-fax-minaddr-v2-02.txt for the specific internet fax service. It also defines one qualifier needed to support correclty ITU T.33 subaddresses inside internet fax e-mail addresses. The specification has been implemented indipendently inside internet fax products and the tests proved correct interoperability. It also includes the IANA registration of the T33S qualifier. ....... At Pittsburgh meeting, we reviewed them. We agreed there are no problems for Draft Standard consideration. Also, the formal interworking report is already circulated. For your information, it is attached to this mail. Therefore, we can do a Working Group Last Call for the above documents. After WG Last Call, they will be submitted to IESG with the interworking report for Draft Standard consideration. The WG Last Call period is 2 weeks. It will close on Oct 2. If you have any comments, please circulate them to our ML by Oct 2. Regards, -- Hiroshi Tamura IETF FAX WG co-chair ----Next_Part(Mon_Sep_18_17:36:14_2000_955)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="IWR_addressing.txt" Content-Transfer-Encoding: 7bit ---------------------------------------------------------------------- RFC2304 IMPLEMENTATION REPORT This report describes the implementation and interoperability testing of RFC2304 "Minimal FAX address format in Internet Mail". The test was held on the 28th June 2000 in Japan. The following independently implemented and jointly tested RFC2304. Matsushita Graphic Communication Systems Inc. TOYOCOM Inc. This report is organized in 2 sections. Section 1 describes the method and results of RFC2304 interoperability testing. Section 2 describes the independent RFC2304 implementations, by implementor. RFC2304 is the application of RFC2303 generic specification to FAX addresses. ----------------------------------------------------------------------- SECTION 1: RFC2304 INTEROPERABILITY TESTING ----------------------------------------------------------------------- 1. Testing Method 1-1. TOYOCOM sends the data to Internet Fax (IFAX) of M.G.C.S. (figure 1) . --------- ------------ ---------- ------ | Gateway | | IFAX | |Onramp GW | | | | TOYOCOM | ------->| M.G.C.S. |------>| DX-2000 |----->| PC | |_________| Internet|____________| PSTN |__________| LAN |______| figure 1 1)OnRamp Gateway of TOYOCOM sends the data with the following address formula. FAX=+81312345677@ifax.mgcs.mei.co.jp FAX=+81312345677/T33S=1234@ifax.mgcs.mei.co.jp FAX=+81312345677/T33S=5678@ifax.mgcs.mei.co.jp FAX+81-3-12345677@ifax.mgcs.mei.co.jp FAX=+81312345677/T33S=1234@ifax.mgcs.mei.co.jp and FAX=+81312345677/T33S=5678@ifax.mgcs.mei.co.jp /FAX=+81-3-12345677/T33S=1234/@ifax.mgcs.mei.co.jp and /FAX=+81.3.12345677/T33S=5678/@ifax.mgcs.mei.co.jp 2)IFax of M.G.C.S. sends the fax to DX-2000 with the addresss 03-12345677 including sub-address 1234 and/or 5678. 3)DX-2000(IFAX made by Panafax) sends e-mail to PC which has the corresponding e-mail address of the sub address. DX-2000 is used for verification method of sub address field in FIF. 1-2. M.G.C.S. sends the data to the OffRamp Gateway of TOYOCOM (figure 2) . --------- ------------ ---------- ------ | IFAX | | Gateway | |Onramp GW | | | | M.G.C.S | ------->| TOYOCOM |------>| DX-2000 |----->| PC | |_________| Internet|____________| PSTN |__________| LAN |______| figure 2 1)M.G.C.S. sends the data to the OffRamp Gateway of TOYOCOM (figure 2). FAX=+81312345677@ifax.toyocom.co.jp FAX=+81312345677/T33S=1234@ifax.toyocom.co.jp etc. 2),3) repeat same procedure as article 2-1. 3. Results We satisfied the items of "RFC2304 Interworking Configuration Matrix" which has deliverd to Fax Connect II. (http://www.imc.org/imc-faxconnect/) The items are below. 1) Minimum Specification (MUST) All implementations supporting this FAX over e-mail address format MUST supports as a minimum the specification described in this document(RFC 2304) 2) qualif-type1 element (REQUIRED) The minimal addressing for the fax service also requires support for a "qualif-type1" elment. This element is an OPTIONAL element of the fax address, but its support, when present, is REQUIRED. 3) Fax address minimum specification (REQUIRED) The minimal specification of a fax in e-mail address is: fax-address = fax-mbox["T33S="sub-addr] fax-mbox = "FAX="global-phone 4) Multiple T.33 Subaddresses (MUST) In case a particular service requires multiple T.33 subaddresses, and these subaddresses need to be given on the same "fax-mbox", multiple "fax-email" elements will be used. ----------------------------------------------------------------------- SECTION 2: RFC2304 IMPLEMENTATIONS ----------------------------------------------------------------------- Name of implementation: MGCS Internet Fax Organization: Matsushita Graphic Communication Systems Inc. Platforms: original appliance Location of code: proprietary to MGCS Inc. Contact: Kiyoshi Toyoda Implemented Features: Full features of RFC2304 Name of implementation: TOYOCOM OnRamp and OffRamp Gateway Organization: TOYOCOM Inc. Platforms: Windows NT Server ver.4.0 Location of code: proprietary to TOYOCOM Inc. Contact: Katsuhiko Mimura Implemented Features: Full features of RFC2304 ----Next_Part(Mon_Sep_18_17:36:14_2000_955)---- From owner-ietf-fax@mail.imc.org Wed Sep 27 07:10:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08199 for ; Wed, 27 Sep 2000 07:10:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA19352 for ietf-fax-bks; Wed, 27 Sep 2000 03:28:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA19348 for ; Wed, 27 Sep 2000 03:28:08 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07511; Wed, 27 Sep 2000 06:31:29 -0400 (EDT) Message-Id: <200009271031.GAA07511@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-implementers-guide-03.txt Date: Wed, 27 Sep 2000 06:31:29 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Implementers Guide for Facsimile Using Internet Mail Author(s) : V. Cancio, M. Moldovan, H. Tamura, D. Wing Filename : draft-ietf-fax-implementers-guide-03.txt Pages : 19 Date : 25-Sep-00 This document is intended for the implementers of software which uses email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-implementers-guide-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-implementers-guide-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-implementers-guide-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000925114422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-implementers-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-implementers-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000925114422.I-D@ietf.org> --OtherAccess-- --NextPart--