From owner-ietf-fax@mail.imc.org Tue May 2 00:34:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13207 for ; Tue, 2 May 2000 00:34:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA08348 for ietf-fax-bks; Mon, 1 May 2000 20:47:55 -0700 (PDT) Received: from mail.qatar.net.qa (qatar.net.qa [194.133.33.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08339 for ; Mon, 1 May 2000 20:47:51 -0700 (PDT) Received: from [206.82.133.54] ([206.82.133.54]) by mail.qatar.net.qa (Netscape Messaging Server 4.04) with ESMTP id FTWYQD00.VC0; Tue, 2 May 2000 06:51:49 +0300 Mime-Version: 1.0 X-Sender: paf@127.0.0.1 (Unverified) Message-Id: Date: Mon, 1 May 2000 23:20:36 -0700 To: IESG-Secretary , Hiroshi Tamura From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Last call on fax documents? Cc: Ned Freed , ietf-fax@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't see that I can last call these because of the following (taken from the minutes of the FAX meeting in Adelaide): At 08.40 +0900 00-04-27, Hiroshi Tamura wrote: >- draft-ietf-fax-service-v2-01.txt > >There are dependency problems(DSN, IMAP4 and Addressing). >Concerning DSN, there is one idea in order not to be dependent on DSN. >It was circulated in ML. For others, the group confirmed to wait for >being Draft standards. The right format of the results of Interworking >(FaxConnect2) is necessary. Mr. Ohno, who was responsible for >FaxConnect2 at Japan, will report it with other key people. > >- draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt > >Interworking is not enough, especially for /T33S issue. >T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress). >It is kind of an application profile. There are fax machines >that support T.30 SUB signal. But there are very few implementations >about T.33. A question was raised about how to validate >if two independent implementations interwork for addressing. >About this question, there was an opinion it is that gateways can >handle the specified address correctly. Steve, please _remove_ the following documents from the IESG table until further notice. draft-ietf-fax-service-v2-01.txt draft-ietf-fax-faxaddr-v2-00.txt draft-ietf-fax-minaddr-v2-00.txt Hiroshi-san: please resolve these issues, and if needed come back with new versions of the documents. An interoperability report have to be sent in together with the request for last call -- especially when the community seems to question the interoperability. Patrik Faltstrom Area Director, Applications Area, IETF From owner-ietf-fax@mail.imc.org Tue May 2 02:16:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25116 for ; Tue, 2 May 2000 02:16:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA15773 for ietf-fax-bks; Mon, 1 May 2000 22:44:39 -0700 (PDT) Received: from ricohigw.ricoh.co.jp (ricohigw.ricoh.co.jp [202.32.12.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA15769 for ; Mon, 1 May 2000 22:44:37 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id OAA02821; Tue, 2 May 2000 14:49:37 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id OAA17590; Tue, 2 May 2000 14:49:36 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id OAA04493; Tue, 2 May 2000 14:43:32 +0900 (JST) To: paf@swip.net, Claudio.Allocchio@elettra.trieste.it, ktoyoda@rdmg.mgcs.mei.co.jp Cc: iesg-secretary@ietf.org, Ned.Freed@innosoft.com, ietf-fax@imc.org Subject: Re: Last call on fax documents? In-Reply-To: References: X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20000502145451V.tamura@toda.ricoh.co.jp> Date: Tue, 02 May 2000 14:54:51 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 35 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA15770 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Fältström-san, > I don't see that I can last call these because of the following > (taken from the minutes of the FAX meeting in Adelaide): You are right. > draft-ietf-fax-service-v2-01.txt > draft-ietf-fax-faxaddr-v2-00.txt > draft-ietf-fax-minaddr-v2-00.txt > Hiroshi-san: please resolve these issues, and if needed come back > with new versions of the documents. An interoperability report have > to be sent in together with the request for last call -- especially > when the community seems to question the interoperability. OK. Allocchio-san, Toyoda-san: If necessary, please submit the new-version again. About interoperability report, please discuss in ML or directly contact Allocchio-san and me. -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Tue May 2 03:18:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25584 for ; Tue, 2 May 2000 03:18:10 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA16752 for ietf-fax-bks; Mon, 1 May 2000 23:35:07 -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 XAA16748 for ; Mon, 1 May 2000 23:35:01 -0700 (PDT) Received: from thunder.ricoh.co.jp (thunder [133.139.211.198]) by ricohigw.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA14432; Tue, 2 May 2000 15:40:14 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA29579; Tue, 2 May 2000 15:40:12 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id PAA04502; Tue, 2 May 2000 15:34:08 +0900 (JST) To: minutes@ietf.org, ietf-fax@imc.org Cc: paf@swip.net, ned.freed@innosoft.com Subject: Final Minutes for Interet Fax-Ext WG Adelaide Meeting X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000502154527O.tamura@toda.ricoh.co.jp> Date: Tue, 02 May 2000 15:45:27 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 990905(IM130) Lines: 324 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagus, The final minutes at Adelaide meeting are below. Only draft-ietf-fax-tiff-fx-04.txt issue was modified. If you have any comments, please discuss it at new threads. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) ######################################################################### ------------------------------------------------------------------------- ------------------------------------------------------------------------- IETF FAX-Ext Group meeting was held at 15:30-17:50 on March 30. ------------------------------------------------------------------------ 1 Opening ------------------------------------------------------------------------ New co-chairs(Claudio Allocchio and Hiroshi Tamura) introduced themselves. They thanked the out-going chair, James Rafferty and the achievements of our working group. The meeting agenda itself was introduced and accepted. ------------------------------------------------------------------------ 2 Charter ------------------------------------------------------------------------ This is the first meeting since new charter was created. New charter was discussed. Concerning the phrase "full equivalence of T.30 service", a question about the relation with T.38 was raised. T.38 describes the procedure for Real-Time G3 fax over IP networks. It is NOT a service over Internet mail, which Fax working group has been studying for years. The group confirmed to continue the study of the specification that is equivalent to T.30 service over Internet mail. There was an opinion that the phrase "universal messaging issues" should move and be included in the first sentence in the first paragraph. The group agreed it. Concerning interconnecting the GSTN fax services, there are onramp and offramp gateway related issues. But they have not been deeply discussed so far in the group. The group confirmed there are things to do for these issues. The group confirmed the Implementers' Guide is useful for quality of service. The group confirmed FFPIM is a base for equivalence of T.30 service. It includes capability negotiation, in which a sender can transmit the "best" fax image the receiver indicates. There was an opinion about the use of RESCAP protocol for negotiation. A question about document authentication issue was raised. There are PGP, S/MIME, digital signature, and so on. The group confirmed to study the authentication under FFPIM. Related to FFPIM, the group confirmed TIFF-FX extensions like JBIG2 should be included. The target date of initial drafts of the extensions was modified as Jun 2000. Concerning the schema, it remains Sep 2000. The group confirmed to continue the cooperation with ITU-T and other IETF WGs such as VPIM. The group agreed to the charter. Modified charter will be circulated. ------------------------------------------------------------------------ 3 Status of internet drafts ------------------------------------------------------------------------ 1) Internet drafts waiting for RFC - draft-ietf-fax-feature-schema-v2-01.txt - draft-ietf-fax-feature-T30-mapping-03.txt The chair introduced these are in the queue by IESG review and will be approved soon. 2) Internet drafts waiting for Draft Standard. - draft-ietf-fax-tiff-fx-04.txt The chair introduced the interworking report was circulated and there are no problems. ADs will review it. Related to this document, the status of draft-ietf-fax-tiff-regbis-00.txt (Updated RFC2302)was introduced. [After the meeting: The out-going chair(James Rafferty) told this draft is dependent on RFC2302. He suggests draft-ietf-fax-tiff-regbis-00.txt should be BCP in order that tiff-fx is not dependent on tiff-regbis. It is possible because tiff-regbis only contains the IANA registration information. We agreed that tiff-fx, along with the supporting interworking report, should be submitted to the IESG for Draft Standard consideration while the tiff-regbis draft should be submitted for consideration as a BCP.] - draft-ietf-fax-service-v2-01.txt There are dependency problems(DSN, IMAP4 and Addressing). Concerning DSN, there is one idea in order not to be dependent on DSN. It was circulated in ML. For others, the group confirmed to wait for being Draft standards. The right format of the results of Interworking (FaxConnect2) is necessary. Hiroyuki Ohno, who was responsible for FaxConnect2 at Japan, will report it with other key people. - draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt Interworking is not enough, especially for /T33S issue. T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress). It is kind of an application profile. There are fax machines that support T.30 SUB signal. But there are very few implementations about T.33. A question was raised about how to validate if two independent implementations interwork for addressing. About this question, there was an opinion it is that gateways can handle the specified address correctly. ------------------------------------------------------------------------ 4 On-going Internet drafts ------------------------------------------------------------------------ 1) draft-ietf-fax-ffpim-00.txt Dave Crocker introduced it. FFPIM abbreviates Full-mode Fax Profile for Internet Mail. This specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability, timeliness and capability negotiation for Internet mail that is on a par with classic T.30 facsimile. About timeliness, it refers to draft-ietf-fax-timely-delivery-00.txt. About capability negotiation, it refers to draft-ietf-fax-content-negotiation-01.txt 2) draft-ietf-fax-timely-delivery-00.txt Graham Klyne mainly introduced it. This specification defines a set of capabilities which permits an originator to request that the email transport system give a particular timeliness in delivery and then assures if the system will report the success or failure of that request. Specifically, it provides "while you wait" delivery of a message, with overall end-to-end transmission times of similar order to those for fax(seconds rather than minutes). It is also designed to operate within the ESMTP extension framework, allowing the sender to decide fallback to traditional e-mail if timely delivery service is unavailable. This can be achieved by the three ESMTP extensions(DSN, DELIVERBY, CONFORMANCE-REQUIRED). DELIVERBY imposes a responsibility on MTAs to complete delivery within a specified time. CONFORMANCE-REQUIRED imposes responsibility on MTAs to complete delivery in conformance with stated requirements, or not to deliver the message. There was the following comments about timelines. Page-by-page confirmation like T.30 cannot be done. Those kinds of confirmation are not necessary over Internet-mail. There was an comment that all MTAs should be changed to configure it. Graham Klyne also commented the reverse(DSN return) path is not considered now and it should be done for complete timeliness. 3) draft-ietf-fax-content-negotiation-01.txt Graham Klyne mainly introduced it. This specification uses a post-hoc technique that permits an originator to send the best version known by the originator to be supported by the recipient and then sending a better version the recipient requests it. There are the following goals. - Normal behavior with ordinary e-mail - No "administrative non-messages" - Work with current simple- and extended-mode fax systems - Recovery from stale cached capability information - Possible low-memory device implementation Sender specifies MDN option "Alternative-available" and alternative features in "Content-alternative". Receiver indicates "alternative- preferred" disposition-modifier-extension and its capabilities in MDN. Sender selects alternative format based on receiver's capabilities. Negotiation case example and optimized one were introduced. A question was raised about negotiation mechanism. Graham Klyne emphasized it is sender who judges the capabilities indicated by receiver and selects the format. He also notified the Receiver's state issue. 4) draft-ietf-fax-implementers-guide-01.txt Vivian Cancio introduced it. This guide addresses implementations of the followings. - RFCs 2305, 2532, 2301 - RFC 2298 in connection with RFC 2532 - Others related as needed Users want to know if returned MDN indicates Main body text or TIFF attachments. There are no suitable disposition-types. This draft describes guides on how to express, using the existing definitions. It also describes TIFF interoperability issue, including the issue of low-end limited memory embedded recipients. There are controversies that how many TIFF problems should be included and if examples should reflect desired best practice to accomplish model or not. There were suggestions on Subject field and first part text of MDN as follows. - Subject "Return Receipt:", followed by original subject field text "Disposition Notification:" followed by original subject field text - First part text "This is a Return Receipt for the mail that you sent to __ etc. The message and attached file may have been printed or saved. This is no guarantee that the message has been read or understood." There was an indication as open issues that MDN new disposition-types (e.g. "telephone line busy" etc.) and MDN message part identification (main body vs. attachment etc.) should be addressed as standard track (other internet drafts). There were the following comments. In other mail applications, there are similar issues. MDN extension is considered in other WGs. The group confirmed to refine this draft. ------------------------------------------------------------------------ 5 TIFF-FX extensions ------------------------------------------------------------------------ Lloyd McIntyre introduced Tiff-fx extensions. There are the following two extensions. 1) New field values and/or relaxed constraints - higher resolutions 300x600, 600x600, 400x800, 600x1200 and 1200x1200 are introduced. - MRC (more than 3 MRC layers) Arranged in mask and foreground pairs. It is beneficial to synthetic images. - MRC (multi-strip background and foreground layers) It is to reduce overhead of IFDs when there is no change in coding parameters between strips (i.e. cases where multiple IFDs are not needed and a single IFD will do) by removing constraint requiring separate IFD for each TIFF strip 2) New fields and/or profiles - More than one profile within document . allow use of more than one profiles within a document . add new MultiFaxProfile field to the GlobalParameters IFD . use of the MultiFaxProfile field is signaled by a FaxProfile field value of X'FF' - JBIG2 (T.88) (Black and White, Color) JBIG2 boosts compression of text-like documents by 3x or more by retaining similar shapes across multiple images. There are 3 ways in which JBIG2 may be used in TIFF-FX. One is in B&W case and two are in Color case. Two new profiles, 3 new fields and a new value for an existing field may be required to accommodate the three usage - Annotation It brings life to raster images by accommodating a limited level of editability. The result is increased desktop citizenship and a significant step towards realization of integrated messaging. There are 3 forms(information annotation, quality annotation and tag annotation) of annotation to be considered. New fields and new values for existing fields may be required to accommodate the three forms. He will submit the internet-drafts. ------------------------------------------------------------------------ 6 Fax Gateway issue ------------------------------------------------------------------------ Takurou Kitagawa explained new proposal with the use of HTTP and CGI, concerning Fax Offramp issues. In his ideas, users put only a telephone number into a device which is connected to Internet. The device accesses to a directory server and resolves the addressing information for the number by getting it from the directory server. He emphasized the gateway local policy. This issue may possibly be solved in ENUM WG. The group confirmed the discussion should take place in both Fax WG and Enum WG. No internet draft exists. Therefore, he will submit the internet-draft about it. ------------------------------------------------------------------------ 7 ITU-T issue ------------------------------------------------------------------------ There was no time to introduce ITU related matter, as scheduled. Therefore, the chair promised to circulate this issue in ML soon. [After the meeting: The chair(Hiroshi Tamura) circulated the report of February SG8 meeting and the information of re-organizing ITU-T in ML. Q4/SG8 confirmed to continue cooperation between IETF Fax WG and them. They will be merged into new SGs and continue to study. Plan for T.37 extension such as support for Full-mode enhancements, new image compression method, and T.37 gateway functionality was introduced. The group agreed to send a letter and Implementer's Guide draft to Q4/SG8.] ------------------------------------------------------------------------ 8 Closing ------------------------------------------------------------------------ The meeting finished. From owner-ietf-fax@mail.imc.org Tue May 2 13:37:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06008 for ; Tue, 2 May 2000 13:37:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08659 for ietf-fax-bks; Tue, 2 May 2000 09:58:22 -0700 (PDT) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08655 for ; Tue, 2 May 2000 09:58:21 -0700 (PDT) Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id KAA18589; Tue, 2 May 2000 10:03:41 -0700 (PDT) Message-Id: <200005021703.KAA18589@kiwi.equinix.com> Subject: Request for review of conneg hash draft To: ietf-fax@imc.org Date: Tue, 2 May 2000 10:03:41 -0700 (PDT) Cc: hardie@equinix.com (ted hardie) From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] 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 draft-ietf-conneg-feature-hash-04.txt is currently moving into working group last call and the CONNEG working group would appreciate an early review of it from those members of the FAX working group who are active in this area. Please send comments to ietf-medfree@imc.org. Thanks and regards, Ted Hardie Chair, CONNEG Forwarded message: > From owner-ietf-medfree@mail.imc.org Tue May 2 09:57:09 2000 > Message-Id: <200005021652.JAA18292@kiwi.equinix.com> > Subject: LAST CALL for hash draft > To: ietf-medfree@imc.org > Date: Tue, 2 May 2000 09:52:54 -0700 (PDT) > Cc: hardie@equinix.com (ted hardie) > From: hardie@equinix.com > Reply-to: hardie@equinix.com > X-Mailer: ELM [version 2.5 PL1] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: owner-ietf-medfree@mail.imc.org > Precedence: bulk > List-Archive: > List-ID: > List-Unsubscribe: > X-Sorted: List > > I would like to ask for any working group comments on > > draft-ietf-conneg-feature-hash-04.txt > > > to be submitted by May 17, 2000. > > > To remind folks of the history here, this version focuses on the > hash form to the exclusion of the URI forms included in previous > versions, as per the discussions in Adelaide. Please review it > carefully. > thanks, > Ted Hardie > Chair, CONEG > From owner-ietf-fax@mail.imc.org Tue May 2 15:15:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07467 for ; Tue, 2 May 2000 15:15:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA09823 for ietf-fax-bks; Tue, 2 May 2000 11:43:58 -0700 (PDT) Received: from lysithea.eastgw.xerox.com (root@lysithea.xerox.com [208.140.33.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09819 for ; Tue, 2 May 2000 11:43:57 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA04573 for ; Tue, 2 May 2000 14:49:10 -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 LAA01586 for ; Tue, 2 May 2000 11:49:08 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 11:49:08 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A28AA@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'IETF fax WG'" Subject: Internet Imaging II at EI 2001 Date: Tue, 2 May 2000 11:49:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, would like to take this opportunity to invite members of the WG to consider showcasing the IFax work we have done or are doing by presenting papers at the upcoming Jan. 2001 Internet Imaging conference of the 13th annual Electronic Imaging 2001 symposium. As a session chair of the upcoming conference and the last two conferences, I believe this could be a win for WG activities. Please see the URL for more information, http://www.spie.org/web/meetings/calls/pw01/confs/EI24.html Lloyd ************************************************ Lloyd McIntyre lmcintyre@pahv.xerox.com Rapporteur ITU-T SG8 Q5 Xerox Corp., Xerox Architecture Center 3400 Hillview Ave. Bldg. 1 Palo Alto, CA 94304 Tel: +1 650 813 6762 fax: +1 650 845 2340 ************************************************ From owner-ietf-fax@mail.imc.org Tue May 9 03:32:18 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 DAA12388 for ; Tue, 9 May 2000 03:32:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA00682 for ietf-fax-bks; Mon, 8 May 2000 23:54:28 -0700 (PDT) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00676 for ; Mon, 8 May 2000 23:54:26 -0700 (PDT) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id QAA29788; Tue, 9 May 2000 16:00:17 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma029711; Tue, 9 May 00 15:59:39 +0900 Received: from canongw.cecn.canon.co.jp (localhost [127.0.0.1]) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id PAA14171; Tue, 9 May 2000 15:59:39 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id PAA27386; Tue, 9 May 2000 15:59:38 +0900 (JST) Received: from maeda18209.ffm.canon.co.jp ([172.22.33.171]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with SMTP id PAA21745; Tue, 9 May 2000 15:56:01 +0900 (JST) Message-Id: <4.0.2-J.20000509152902.00f6c930@ffmpop1.ffm.canon.co.jp> X-Sender: maeda@ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2-J Date: Tue, 09 May 2000 16:02:11 +0900 To: ietf-fax@imc.org, Lloyd.McIntyre@pahv.xerox.com From: MAEDA toru Subject: New resolutions for TIFF-FX Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear McIntyre-san, ITU-T added new resolutions for T.30. tiff-fx-04 should also include those resolutions as follows. Black and White 600x600 dpi 1200x1200 300x600 400x800 600x1200 Colour and Gray Scale 600x600 dpi 1200x1200 Regards. Toru MAEDA ---------------------------- CANON INC. TORU MAEDA Technology Advancement Div. 3 3-30-2,Shimomaruko Ohtaku,Tokyo,Japan E-mail maeda@ffm.canon.co.jp TEL +81-3-3757-9738 FAX +81-3-3757-8205 ---------------------------- From owner-ietf-fax@mail.imc.org Tue May 9 07:05:18 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 HAA14433 for ; Tue, 9 May 2000 07:05:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14063 for ietf-fax-bks; Tue, 9 May 2000 03:30:22 -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 DAA14059 for ; Tue, 9 May 2000 03:30:21 -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 GAA13893; Tue, 9 May 2000 06:36:13 -0400 (EDT) Message-Id: <200005091036.GAA13893@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-tiff-regbis-01.txt Date: Tue, 09 May 2000 06:36:13 -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 : Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration Author(s) : G. Parsons, J. Rafferty, S. Zilles Filename : draft-ietf-fax-tiff-regbis-01.txt Pages : 9 Date : 08-May-00 This document describes the registration of the MIME sub-type image/tiff. The baseline encoding is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-regbis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-tiff-regbis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-tiff-regbis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000508103938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-regbis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-regbis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000508103938.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Tue May 9 14:08:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26747 for ; Tue, 9 May 2000 14:08:00 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23186 for ietf-fax-bks; Tue, 9 May 2000 10:30:55 -0700 (PDT) Received: from pasiphae.eastgw.xerox.com (root@pasiphae.xerox.com [208.140.33.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23178 for ; Tue, 9 May 2000 10:30:49 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id NAA06147; Tue, 9 May 2000 13:36:07 -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 KAA14220; Tue, 9 May 2000 10:36:04 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Tue, 9 May 2000 10:36:04 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A28C8@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'MAEDA toru'" , ietf-fax@imc.org, "McIntyre, Lloyd" Subject: RE: New resolutions for TIFF-FX Date: Tue, 9 May 2000 10:36:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maeda-san, You are correct, in that T.30 has introduced a set of new resolutions. These new resolutions, along with other enhancements (e.g. JBIG2, Annotations, more than 3 MRC layers, etc.) are being addressed in the planned TIFF-FX extension draft. The first TIFF-FX extension draft is scheduled for distribution prior to the next IETF meeting. This new TIFF-FX extension will undergo the normal draft review process and will then be submitted for Proposed Standard consideration. It is not appropriate to add the new resolutions to tiff-fx-04 since tiff-fx-04 reflects RFC2301 revisions that are necessary to progress this version of TIFF-FX to Draft Standard status. I hope this clarifies the situation. Regards Lloyd > -----Original Message----- > From: MAEDA toru [mailto:maeda@ffm.canon.co.jp] > Sent: Tuesday, May 09, 2000 12:02 AM > To: ietf-fax@imc.org; Lloyd.McIntyre@pahv.xerox.com > Subject: New resolutions for TIFF-FX > > > Dear McIntyre-san, > > ITU-T added new resolutions for T.30. > tiff-fx-04 should also include those resolutions as follows. > > Black and White > 600x600 dpi > 1200x1200 > 300x600 > 400x800 > 600x1200 > > Colour and Gray Scale > 600x600 dpi > 1200x1200 > > Regards. > > Toru MAEDA > > ---------------------------- > CANON INC. > TORU MAEDA > Technology Advancement Div. 3 > 3-30-2,Shimomaruko Ohtaku,Tokyo,Japan > E-mail maeda@ffm.canon.co.jp > TEL +81-3-3757-9738 FAX +81-3-3757-8205 > ---------------------------- > From owner-ietf-fax@mail.imc.org Tue May 9 14:25:29 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 OAA27158 for ; Tue, 9 May 2000 14:25:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23734 for ietf-fax-bks; Tue, 9 May 2000 10:45:18 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies From owner-ietf-fax@mail.imc.org Thu May 11 03:26:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22156 for ; Thu, 11 May 2000 03:26:23 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA23216 for ietf-fax-bks; Wed, 10 May 2000 22:55:48 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23209 for ; Wed, 10 May 2000 22:55:44 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id PAA16000; Thu, 11 May 2000 15:00:29 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id PAA17221; Thu, 11 May 2000 15:00:26 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 11 May 2000 06:00:27 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id OAA06938; Thu, 11 May 2000 14:59:12 +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 OAA13298; Thu, 11 May 2000 14:57:57 +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 OAA06730; Thu, 11 May 2000 14:57:54 +0900 (JST) Message-Id: <200005110601.AA00313@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Thu, 11 May 2000 15:01:14 +0900 To: tamura@toda.ricoh.co.jp Cc: ietf-fax@imc.org Subject: draft-ietf-fax-service-v2-02 MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: multipart/mixed; boundary="--------------------4130014523499218" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is multipart message. ----------------------4130014523499218 Content-Type: text/plain; charset=iso-2022-jp Tamura-san, We revised the service draft as draft-ietf-fax-service-v2-02 attached. By revising the draft, we can resolve the depandency problem about IMAP4, but must wait for being Draft standards of DSN and addressing. Patrik F$BgM(Btstr wrote >> >>There are dependency problems(DSN, IMAP4 and Addressing). >>Concerning DSN, there is one idea in order not to be dependent on DSN. >>It was circulated in ML. For others, the group confirmed to wait for >>being Draft standards. The right format of the results of Interworking >>(FaxConnect2) is necessary. Mr. Ohno, who was responsible for >>FaxConnect2 at Japan, will report it with other key people. >> Hiroshi-san: please resolve these issues, and if needed come back >> with new versions of the documents. An interoperability report have >> to be sent in together with the request for last call -- especially >> when the community seems to question the interoperability. Hiroshi Tamura wrote. >OK. > >Allocchio-san, Toyoda-san: >If necessary, please submit the new-version again. The revised points are as below. 1. update copyright. 2. change from "over the Internet" to "using Internet mail" in the paragraph below. > >SUMMARY > > This specification provides for "simple mode" carriage of facsimile > data over the Internet. Extensions to this document will follow. 3. remove the references to RFC1891(DSN) and RFC2060(IMAP) because we think they are not normative references. 4. change the paragraphs regarding to references [17], [19], [13] and [20] to make them very non-normative references. Kiyoshi Toyoda ----------------------4130014523499218 Content-Type: application/octet-stream; name="draft-ietf-fax-service-v2-02.txt" Content-Disposition: attachment; filename="draft-ietf-fax-service-v2-02.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBLLiBUb3lvZGENCkludGVybmV0IERyYWZ0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBILiBPaG5vDQpGZWJy dWFyeSAyNiwgMTk5OSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBKLiBNdXJhaQ0KRXhwaXJlcyBBdWd1c3QgMTk5OSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBXSURFIFByb2plY3QNCmRyYWZ0LWlldGYtZmF4LXNlcnZp Y2UtdjItMDIudHh0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBXaW5nDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDaXNjbw0KDQoNCiAgICAgICAgICAgICBBIFNpbXBsZSBNb2RlIG9mIEZh Y3NpbWlsZSBVc2luZyBJbnRlcm5ldCBNYWlsDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0K ICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBj b25mb3JtYW5jZQ0KICAgd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJG QzIwMjYuIEludGVybmV0LURyYWZ0cyBhcmUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgDQogICBpdHMgYXJl YXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvDQogICBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURy YWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluIHByb2dyZXNzLiINCg0KICAgVG8gdmlldyB0aGUgZW50aXJlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1EcmFmdHMsIHBsZWFzZSBjaGVjaw0KICAgdGhlICIxaWQtYWJzdHJhY3Rz LnR4dCIgbGlzdGluZyBjb250YWluZWQgaW4gdGhlIEludGVybmV0LURyYWZ0cw0KICAgU2hh ZG93IERpcmVjdG9yaWVzIG9uIGZ0cC5pcy5jby56YSAoQWZyaWNhKSwgZnRwLm5vcmR1Lm5l dA0KICAgKE5vcnRoZXJuIEV1cm9wZSksIGZ0cC5uaXMuZ2Fyci5pdCAoU291dGhlcm4gRXVy b3BlKSwgbXVubmFyaS5vei5hdQ0KICAgKFBhY2lmaWMgUmltKSwgZnRwLmlldGYub3JnIChV UyBFYXN0IENvYXN0KSwgb3IgZnRwLmlzaS5lZHUNCiAgIChVUyBXZXN0IENvYXN0KS4NCg0K ICAgVGhpcyBkcmFmdCBpcyBhIHByb2R1Y3Qgb2YgdGhlIElFVEYgSW50ZXJuZXQgRmF4IHdv cmtpbmcgZ3JvdXAuICBUbw0KICAgc3Vic2NyaWJlIHRvIHRoZSBtYWlsaW5nIGxpc3QsIHNl bmQgYSBtZXNzYWdlIHRvDQogICBpZXRmLWZheC1yZXF1ZXN0QGltYy5vcmcgd2l0aCB0aGUg bGluZSAic3Vic2NyaWJlIiBpbiB0aGUgYm9keSBvZiB0aGUNCiAgIG1lc3NhZ2UuICBBcmNo aXZlcyBhcmUgYXZhaWxhYmxlIGZyb20gPGh0dHA6Ly93d3cuaW1jLm9yZy9pZXRmLWZheD4u DQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMTk5OSyBQDIwMDApLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KU1VNTUFS WQ0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgZm9yICJzaW1wbGUgbW9kZSIg Y2FycmlhZ2Ugb2YgZmFjc2ltaWxlDQogICBkYXRhIHVzaW5nIEludGVybmV0IG1haWwuICBF eHRlbnNpb25zIHRvIHRoaXMgZG9jdW1lbnQgd2lsbCBmb2xsb3cuDQogICBUaGUgY3VycmVu dCBzcGVjaWZpY2F0aW9uIGVtcGxveXMgc3RhbmRhcmQgcHJvdG9jb2xzIGFuZCBmaWxlIGZv cm1hdHMNCiAgIHN1Y2ggYXMgVENQL0lQLCBJbnRlcm5ldCBtYWlsIHByb3RvY29scyBbMSwg MiwgM10sIE1JTUUgWzQsIDE0LCAxNV0sDQogICBhbmQgVElGRiBmb3IgRmFjc2ltaWxlIFs1 LDYsMTddLiAgSXQgY2FuIHNlbmQgaW1hZ2VzIG5vdCBvbmx5IHRvDQoNCg0KVG95b2RhLCBl dC4gYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAg IFtQYWdlIDFdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBG YWNzaW1pbGUgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQogICBvdGhlciBJbnRlcm5l dC1hd2FyZSBmYWNzaW1pbGUgZGV2aWNlcyBidXQgYWxzbyB0byBJbnRlcm5ldC1uYXRpdmUN CiAgIHN5c3RlbXMsIHN1Y2ggYXMgUENzIHdpdGggY29tbW9uIGVtYWlsIHJlYWRlcnMgd2hp Y2ggY2FuIGhhbmRsZSBNSU1FDQogICBtYWlsIGFuZCBUSUZGIGZvciBGYWNzaW1pbGUgZGF0 YS4gIFRoZSBzcGVjaWZpY2F0aW9uIGZhY2lsaXRhdGVzDQogICBjb21tdW5pY2F0aW9uIGFt b25nIGV4aXN0aW5nIGZhY3NpbWlsZSBkZXZpY2VzLCBJbnRlcm5ldCBtYWlsIGFnZW50cywN CiAgIGFuZCB0aGUgZ2F0ZXdheXMgd2hpY2ggY29ubmVjdCB0aGVtLg0KDQogICBUaGUgSUVU RiBoYXMgYmVlbiBub3RpZmllZCBvZiBpbnRlbGxlY3R1YWwgcHJvcGVydHkgcmlnaHRzIGNs YWltZWQgaW4NCiAgIHJlZ2FyZCB0byBzb21lIG9yIGFsbCBvZiB0aGUgc3BlY2lmaWNhdGlv biBjb250YWluZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQuICBGb3IgbW9yZSBpbmZvcm1hdGlv biBjb25zdWx0IHRoZSBvbmxpbmUgbGlzdCBvZiBjbGFpbWVkDQogICByaWdodHMgaW4gPGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaXByLmh0bWw+Lg0KDQogICBUaGUga2V5IHdvcmRzICJNVVNU IiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BU SU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBk ZXNjcmliZWQgaW4gWzddLg0KDQoxICBTQ09QRQ0KDQogICBUaGlzIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBtZXNzYWdlLWJhc2VkIGZhY3NpbWlsZSBjb21tdW5pY2F0aW9uDQogICBvdmVy IHRoZSBJbnRlcm5ldC4gIEl0IGRlc2NyaWJlcyBhIG1pbmltdW0gc2V0IG9mIGNhcGFiaWxp dGllcywNCiAgIHRha2luZyBpbnRvIGFjY291bnQgdGhvc2Ugb2YgdHlwaWNhbCBmYWNzaW1p bGUgZGV2aWNlcyBhbmQgUENzIHRoYXQNCiAgIGNhbiBnZW5lcmF0ZSBmYWNzaW1pbGUgZGF0 YS4NCg0KICAgQSBHM0ZheCBkZXZpY2UgaGFzIHN1YnN0YW50aWFsIHJlc3RyaWN0aW9ucyBk dWUgdG8gc3BlY2lmaWNhdGlvbnMgaW4NCiAgIHRoZSBzdGFuZGFyZHMsIHN1Y2ggYXMgZm9y IHRpbWVycy4gVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYQ0KICAgcHJvZmlsZSBmb3Ig SW50ZXJuZXQgbWFpbCwgcmF0aGVyIHRoYW4gY3JlYXRpbmcgYSBkaXN0aW5jdCAiZmFjc2lt aWxlDQogICBvdmVyIHRoZSBJbnRlcm5ldCIgc2VydmljZS4gIFRoZSBzZW1hbnRpY3MgcmVz dWx0aW5nIGZyb20gdGhlIHByb2ZpbGUNCiAgIGFyZSBkZXNpZ25lZCB0byBiZSBjb21wYXRp YmxlIHdpdGggZmFjc2ltaWxlIG9wZXJhdGlvbiBvdmVyIHRoZQ0KICAgZ2VuZXJhbCBzd2l0 Y2hlZCB0ZWxlcGhvbmUgbmV0d29yaywgc28gdGhhdCBnYXRld2F5cyBiZXR3ZWVuDQogICBm YWNzaW1pbGUgYW5kIEludGVybmV0IG1haWwgY2FuIG9wZXJhdGUgd2l0aCB2ZXJ5IGhpZ2gg ZmlkZWxpdHkuDQoNCiAgIFRoZSByZWFzb24gZm9yIGRldmVsb3BpbmcgdGhpcyBjYXBhYmls aXR5IGFzIGFuIGVtYWlsIHByb2ZpbGUgaXMgdG8NCiAgIHBlcm1pdCBpbnRlcndvcmtpbmcg YW1vbmdzdCBmYWNzaW1pbGUgYW5kIGVtYWlsIHVzZXJzLiAgRm9yIGV4YW1wbGUNCiAgIGl0 IGlzIGludGVuZGVkIHRoYXQgZXhpc3RpbmcgZW1haWwgdXNlcnMgYmUgYWJsZSB0byBzZW5k IG5vcm1hbA0KICAgbWVzc2FnZXMgdG8gbGlzdHMgb2YgdXNlcnMsIGluY2x1ZGluZyBmYWNz aW1pbGUtYmFzZWQgcmVjaXBpZW50cywgYW5kDQogICB0aGF0IG90aGVyIGVtYWlsIHJlY2lw aWVudHMgc2hhbGwgYmUgYWJsZSB0byByZXBseSB0byB0aGUgb3JpZ2luYWwNCiAgIGFuZCBj b250aW51ZSB0byBpbmNsdWRlIGZhY3NpbWlsZSByZWNpcGllbnRzLiAgU2ltaWxhcmx5IGl0 IGlzDQogICBpbnRlbmRlZCB0aGF0IGV4aXN0aW5nIGVtYWlsIHNvZnR3YXJlIHdvcmsgd2l0 aG91dCBtb2RpZmljYXRpb24gYW5kDQogICBub3QgYmUgcmVxdWlyZWQgdG8gcHJvY2VzcyBu ZXcsIG9yIGRpZmZlcmVudCBkYXRhIHN0cnVjdHVyZXMsIGJleW9uZA0KICAgd2hhdCBpcyBu b3JtYWwgZm9yIEludGVybmV0IG1haWwgdXNlcnMuICBFeGlzdGluZyBlbWFpbCBzZXJ2aWNl DQogICBzdGFuZGFyZHMgYXJlIHVzZWQsIHJhdGhlciB0aGFuIHJlcGxpY2F0aW5nIG1lY2hh bmlzbXMgd2hpY2ggYXJlIG1vcmUNCiAgIHRhaWxvcmVkIHRvIGV4aXN0aW5nIGZhY3NpbWls ZSBzdGFuZGFyZHMsIHRvIGVuc3VyZSB0aGlzDQogICBjb21wYXRpYmlsaXR5IHdpdGggZXhp c3RpbmcgZW1haWwgc2VydmljZS4NCg0KMS4xIFNlcnZpY2VzDQoNCiAgIEEgZmFjc2ltaWxl LWNhcGFibGUgZGV2aWNlIHRoYXQgdXNlcyBULjQgWzhdIGFuZCB0aGUgZ2VuZXJhbCBzd2l0 Y2hlZA0KICAgdGVsZXBob25lIG5ldHdvcmsgKEdTVE4pIGlzIGNhbGxlZCBhICJHM0ZheCBk ZXZpY2UiIGluIHRoaXMNCiAgIHNwZWNpZmljYXRpb24uICBBbiAiSUZheCBkZXZpY2UiIGlz IGFuIEludGVybmV0LSBhY2Nlc3NpYmxlIGRldmljZQ0KDQoNCg0KVG95b2RhLCBldC4gYWwu ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdl IDJdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBGYWNzaW1p bGUgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQogICBjYXBhYmxlIG9mIHNlbmRpbmcs IHJlY2VpdmluZyBvciBmb3J3YXJkaW5nIEludGVybmV0IGZheGVzLiAgQQ0KICAgbWVzc2Fn ZSBjYW4gYmUgc2VudCB0byBhbiBJRmF4IGRldmljZSB1c2luZyAgYW4gSW50ZXJuZXQgbWFp bA0KICAgYWRkcmVzcy4gQSBtZXNzYWdlIGNhbiBiZSBzZW50IHRvIGEgRzNGYXggZGV2aWNl ICB1c2luZyBhbiBJbnRlcm5ldA0KICAgbWFpbCBhZGRyZXNzOyB0aGUgbWVzc2FnZSBNQVkg YmUgZm9yd2FyZGVkIHZpYSBhbiBJRmF4IG9mZnJhbXANCiAgIGdhdGV3YXkuDQoNCjEuMiBD YXNlcw0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgZm9yIGNvbW11bmljYXRp b24gYmV0d2VlbiBlYWNoIG9mIHRoZQ0KICAgZm9sbG93aW5nIGNvbWJpbmF0aW9uczoNCiAg IEludGVybmV0IG1haWwgICAgICAgICAgICAgPT4gIE5ldHdvcmsgcHJpbnRlcg0KICAgSW50 ZXJuZXQgbWFpbCAgICAgICAgICAgICA9PiAgT2ZmcmFtcCBnYXRld2F5IChmb3J3YXJkIHRv DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHM0ZheCkNCiAgIE5ldHdvcmsg c2Nhbm5lciAgICAgICAgICAgPT4gIE5ldHdvcmsgcHJpbnRlcg0KICAgTmV0d29yayBzY2Fu bmVyICAgICAgICAgICA9PiAgT2ZmcmFtcCBnYXRld2F5IChmb3J3YXJkIHRvDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHM0ZheCkNCiAgIE5ldHdvcmsgc2Nhbm5lciAg ICAgICAgICAgPT4gIEludGVybmV0IG1haWwNCg0KDQoyICBDT01NVU5JQ0FUSU9OIFBST1RP Q09MUw0KDQogICBUaGUgc2V0IG9mIGNvbnZlbnRpb25zIG5lY2Vzc2FyeSB0byBhY2hpZXZl IGZhY3NpbWlsZS0gY29tcGF0aWJsZQ0KICAgc2VydmljZSBjb3ZlcnMgYmFzaWMgZGF0YSB0 cmFuc3BvcnQsIGRvY3VtZW50IGRhdGEgZm9ybWF0cywgbWVzc2FnZQ0KICAgKGRvY3VtZW50 KSBhZGRyZXNzaW5nLCBkZWxpdmVyeSBjb25maXJtYXRpb24sIGFuZCBtZXNzYWdlIHNlY3Vy aXR5Lg0KICAgSW4gdGhpcyBzZWN0aW9uLCB0aGUgZmlyc3QgNCBhcmUgY292ZXJlZC4gIFRo ZSByZW1haW5kZXIgYXJlIGNvdmVyZWQNCiAgIGluIGZvbGxvd2luZyBzZWN0aW9ucywgYWxv bmcgd2l0aCBhZGRpdGlvbmFsIGRldGFpbHMgZm9yIGFkZHJlc3NpbmcNCiAgIGFuZCBmb3Jt YXRzLg0KDQoyLjEgVHJhbnNwb3J0DQoNCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgbWVj aGFuaXNtcyBpbnZvbHZlZCBpbiB0aGUgdHJhbnNwb3J0IGJldHdlZW4NCiAgIElGQVggZGV2 aWNlcy4NCg0KMi4xLjEgICAgIFJlbGF5DQoNCiAgIERhdGEgdHJhbnNmZXIgTUFZIGJlIGFj aGlldmVkIHVzaW5nIHN0YW5kYXJkIEludGVybmV0IG1haWwgdHJhbnNmZXINCiAgIG1lY2hh bmlzbXNbMSwgM10uICBUaGUgZm9ybWF0IG9mIGFkZHJlc3NlcyBNVVNUIGNvbmZvcm0gdG8g dGhlIFJGQw0KICAgODIxIDxhZGRyLXNwZWM+IGFuZCBSRkMgODIyIDxtYWlsYm94PiBJbnRl cm5ldCBtYWlsIHN0YW5kYXJkcyBbMSwgMiwNCiAgIDNdLg0KDQoyLjEuMiAgICAgR2F0ZXdh eQ0KDQogICBBIGdhdGV3YXkgdHJhbnNsYXRlcyBiZXR3ZWVuIGRpc3NpbWlsYXIgZW52aXJv bm1lbnRzLiAgRm9yIElGYXgsIGENCiAgIGdhdGV3YXkgY29ubmVjdHMgYmV0d2VlbiBJbnRl cm5ldCBtYWlsIGFuZCB0aGUgVC40L0dTVE4gZmFjc2ltaWxlLg0KICAgR2F0ZXdheXMgY2Fu IHNlcnZpY2UgbXVsdGlwbGUgVC40L0dTVE4gZmFjc2ltaWxlIHVzZXJzIG9yIGNhbiBzZXJ2 aWNlDQogICBvbmx5IG9uZS4gIEluIHRoZSBmb3JtZXIgY2FzZSwgdGhleSBzZXJ2ZSBhcyBh IGNsYXNzaWMgIm1haWwgdHJhbnNmZXINCiAgIGFnZW50IiAoTVRBKSBhbmQgaW4gdGhlIGxh dHRlciBhcyBhIGNsYXNzaWMgIm1haWwgdXNlciBhZ2VudCIgKFVBKS4NCg0KDQoNCg0KVG95 b2RhLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAg ICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9k ZSBvZiBGYWNzaW1pbGUgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQogICBBbiBvbnJh bXAgaXMgYSBnYXRld2F5IHdoaWNoIGNvbm5lY3RzIGZyb20gVC40L0dTVE4gZmFjc2ltaWxl IHRvDQogICBJbnRlcm5ldCBtYWlsLiAgQW4gb2ZmcmFtcCBpcyBhIGdhdGV3YXkgd2hpY2gg Y29ubmVjdHMgZnJvbSBJbnRlcm5ldA0KICAgbWFpbCB0byBULjQvR1NUTiBmYWNzaW1pbGUu IEJlaGF2aW9yIG9mIG9ucmFtcHMgaXMgb3V0IG9mIHNjb3BlIGZvcg0KICAgdGhpcyBzcGVj aWZpY2F0aW9uLg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIHRoZSBJbnRl cm5ldCBtYWlsIHNlcnZpY2UgcG9ydGlvbiBvZg0KICAgb2ZmcmFtcCBhZGRyZXNzaW5nLCBj b25maXJtYXRpb24gYW5kIGZhaWx1cmUgbm90aWZpY2F0aW9uLiAgRGV0YWlscw0KICAgYXJl IHByb3ZpZGVkIGluIGxhdGVyIHNlY3Rpb25zLg0KDQoyLjEuMyAgICAgTWFpbGJveCBwcm90 b2NvbHMNCg0KICAgQW4gb2ZmcmFtcCBnYXRld2F5IHRoYXQgb3BlcmF0ZSBhcyBhbiBNVEEg c2VydmluZyBtdWx0aXBsZSB1c2Vycw0KICAgU0hPVUxEIHVzZSBTTVRQOyBhIGdhdGV3YXkg dGhhdCBvcGVyYXRlcyBhcyBhIFVBIHNlcnZpbmcgYSBzaW5nbGUNCiAgIG1haWwgcmVjaXBp ZW50IE1BWSB1c2UgYSBtYWlsYm94IGFjY2VzcyBwcm90b2NvbCBzdWNoIGFzIFBPUFs5XSBv ciANCiAgIHNpbWlsYXIgbWFpbGJveCBhY2Nlc3MgcHJvdG9jb2xzLg0KDQogICBOT1RFOiBB biBvZmZyYW1wIGdhdGV3YXkgdGhhdCByZWxheXMgbWFpbCBiYXNlZCBvbiBhZGRyZXNzaW5n DQogICBpbmZvcm1hdGlvbiBuZWVkcyB0byBlbnN1cmUgdGhhdCBpdCB1c2VzIGFkZHJlc3Nl cyBzdXBwbGllZCBpbiB0aGUNCiAgIE1UQSBlbnZlbG9wZSwgcmF0aGVyIHRoYW4gZnJvbSBl bHNld2hlcmUsIHN1Y2ggYXMgYWRkcmVzc2VzIGxpc3RlZCBpbg0KICAgdGhlIG1lc3NhZ2Ug Y29udGVudCBoZWFkZXJzLg0KDQoyLjIgRm9ybWF0cw0KDQoyLjIuMSAgICAgSGVhZGVycw0K DQogICBJRmF4IGRldmljZXMgTVVTVCBiZSBjb21wbGlhbnQgd2l0aCBSRkMgODIyIGFuZCBS RkMxMTIzLCB3aGljaCBkZWZpbmUNCiAgIHRoZSBmb3JtYXQgb2YgbWFpbCBoZWFkZXJzLiAg VGhlIGhlYWRlciBvZiBhbiBJRmF4IG1lc3NhZ2UgU0hPVUxEDQogICBpbmNsdWRlIE1lc3Nh Z2UtSUQgYW5kIE1VU1QgaW5jbHVkZSBhbGwgZmllbGRzIHJlcXVpcmVkIGJ5IFsyLCAzXSwN CiAgIHN1Y2ggYXMgREFURSBhbmQgRlJPTS4NCg0KMi4yLjIgICAgIE1JTUUNCg0KICAgSUZh eCBkZXZpY2VzIE1VU1QgYmUgY29tcGxpYW50IHdpdGggTUlNRSBbNF0sIGV4Y2VwdCBhcyBu b3RlZCBpbg0KICAgQXBwZW5kaXggQS4NCg0KMi4yLjMgICAgIENvbnRlbnQNCg0KICAgVGhl IGRhdGEgZm9ybWF0IG9mIHRoZSBmYWNzaW1pbGUgaW1hZ2UgaXMgYmFzZWQgb24gdGhlIG1p bmltdW0gc2V0IG9mDQogICBUSUZGIGZvciBGYWNzaW1pbGVbNl0sIGFsc28ga25vd24gYXMg dGhlIFMgcHJvZmlsZS4gICBTdWNoIGZhY3NpbWlsZQ0KICAgZGF0YSBhcmUgaW5jbHVkZWQg aW4gYSBNSU1FIG9iamVjdCBieSB1c2Ugb2YgdGhlIGltYWdlL1RJRkYgc3ViLXR5cGUNCiAg IFsxN10uICBBZGRpdGlvbmFsIHJ1bGVzIGZvciB0aGUgdXNlIG9mIFRJRkYgZm9yIEZhY3Np bWlsZSwgZm9yIHRoZQ0KICAgbWVzc2FnZS1iYXNlZCBJbnRlcm5ldCBmYWNzaW1pbGUgYXBw bGljYXRpb24sIGFyZSBkZWZpbmVkIGxhdGVyLg0KDQoyLjIuNCAgICAgTXVsdGlwYXJ0DQoN CiAgIEEgc2luZ2xlIG11bHRpLXBhZ2UgZG9jdW1lbnQgU0hPVUxEIGJlIHNlbnQgYXMgYSBz aW5nbGUgbXVsdGktIHBhZ2UNCiAgIFRJRkYgZmlsZSwgZXZlbiB0aG91Z2ggcmVjaXBpZW50 cyBNVVNUIHByb2Nlc3MgbXVsdGlwYXJ0L21peGVkDQogICBjb250YWluaW5nIG11bHRpcGxl IFRJRkYgZmlsZXMuIElmIG11bHRpcGFydCBjb250ZW50IGlzIHByZXNlbnQgYW5kDQogICBw cm9jZXNzaW5nIG9mIGFueSBwYXJ0IGZhaWxzLCB0aGVuIHByb2Nlc3NpbmcgZm9yIHRoZSBl bnRpcmUgbWVzc2FnZQ0KICAgaXMgdHJlYXRlZCBhcyBmYWlsaW5nLCBwZXIgW1Byb2Nlc3Np bmcgZmFpbHVyZV0gYmVsb3cuDQoNCg0KVG95b2RhLCBldC4gYWwuICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5l dCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgICAgICAgICAgIEZl YnJ1YXJ5IDE5OTkNCg0KDQoyLjMgRXJyb3IgSGFuZGxpbmcNCg0KMi4zLjEgICAgIERlbGl2 ZXJ5IGZhaWx1cmUNCg0KICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBleGlzdGluZyByZXF1 aXJlbWVudHMgZm9yIEludGVybmV0IG1haWwsDQogICByYXRoZXIgdGhhbiBpbmRpY2F0aW5n IHNwZWNpYWwgcmVxdWlyZW1lbnRzIGZvciBJRmF4IGRldmljZXMuDQoNCiAgIEluIHRoZSBl dmVudCBvZiByZWxheSBmYWlsdXJlLCB0aGUgc2VuZGluZyByZWxheSBNVVNUIGdlbmVyYXRl IGENCiAgIGZhaWx1cmUgbWVzc2FnZSwgd2hpY2ggU0hPVUxEIGJlIGluIHRoZSBmb3JtYXQg b2YgYSBEU04uIFsxM10NCg0KICAgICAgICBOT1RFOiAgSW50ZXJuZXQgbWFpbCB0cmFuc3Bv cnRlZCB2aWEgU01UUCBNVVNUIGNvbnRhaW4gYSBNQUlMDQogICAgICAgIEZST00gYWRkcmVz cyBhcHByb3ByaWF0ZSBmb3IgZGVsaXZlcnkgb2YgcmV0dXJuIG5vdGljZXMgW0Fsc28NCiAg ICAgICAgc2VlIHNlY3Rpb24gNS4yLjZdDQoNCjIuMy4yICAgICBQcm9jZXNzaW5nIGZhaWx1 cmUNCg0KICAgSUZheCBkZXZpY2VzIHdpdGggbGltaXRlZCBjYXBhYmlsaXRpZXMgbWlnaHQg YmUgdW5hYmxlIHRvIHByb2Nlc3MgdGhlDQogICBjb250ZW50IG9mIGEgbWVzc2FnZS4gIElm IHRoaXMgb2NjdXJzIGl0IGlzIGltcG9ydGFudCB0byBlbnN1cmUgdGhhdA0KICAgdGhlIG1l c3NhZ2UgaXMgbm90IGxvc3Qgd2l0aG91dCBhbnkgbm90aWNlLiBOb3RpY2UgTUFZIGJlIHBy b3ZpZGVkIGluDQogICBhbnkgYXBwcm9wcmlhdGUgZmFzaGlvbiwgYW5kIHRoZSBleGFjdCBo YW5kbGluZyBpcyBhIGxvY2FsIG1hdHRlci4NCiAgIChBbHNvIHNlZSBBcHBlbmRpeCBBLCBz ZWNvbmQgYnVsbGV0LikNCg0KMyAgQUREUkVTU0lORw0KDQozLjEgQ2xhc3NpYyBFbWFpbCBE ZXN0aW5hdGlvbnMNCg0KICAgTWVzc2FnZXMgYmVpbmcgc2VudCB0byBub3JtYWwgSW50ZXJu ZXQgbWFpbCByZWNpcGllbnRzIHdpbGwgdXNlDQogICBzdGFuZGFyZCBJbnRlcm5ldCBtYWls IGFkZHJlc3Nlcywgd2l0aG91dCBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzLg0KDQozLjIgRzNG YXggRGV2aWNlcw0KDQogICBHM0ZheCBkZXZpY2VzIGFyZSBhY2Nlc3NlZCB2aWEgYW4gSUZB WCBvZmZyYW1wIGdhdGV3YXksIHdoaWNoDQogICBwZXJmb3JtcyBhbnkgYXV0aG9yaXplZCB0 ZWxlcGhvbmUgZGlhbC11cC4NCg0KMy4zIEFkZHJlc3MgRm9ybWF0cyBVc2VkIGJ5IE9mZnJh bXBzDQoNCiAgIFdoZW4gYSBHM0ZheCBkZXZpY2UgaXMgaWRlbnRpZmllZCBieSBhIHRlbGVw aG9uZSBudW1iZXIsIHRoZSBlbnRpcmUNCiAgIGFkZHJlc3MgdXNlZCBmb3IgdGhlIEczZmF4 IGRldmljZSwgaW5jbHVkaW5nIHRoZSBudW1iZXIgYW5kIG9mZnJhbXANCiAgIGhvc3QgcmVm ZXJlbmNlIE1VU1QgYmUgY29udGFpbmVkIHdpdGhpbiBzdGFuZGFyZCBJbnRlcm5ldCBtYWls DQogICB0cmFuc3BvcnQgZmllbGRzLCBzdWNoIGFzIFJDUFQgVE8gYW5kIE1BSUwgRlJPTSBb MSwgM10uICBUaGUgYWRkcmVzcw0KICAgTUFZIGJlIGNvbnRhaW5lZCB3aXRoaW4gbWVzc2Fn ZSBjb250ZW50IGZpZWxkcywgc3VjaCBhcyA8YXV0aGVudGljPg0KICAgYW5kIDxkZXN0aW5h dGlvbj4gWzIsIDNdLCBhcyBhcHByb3ByaWF0ZS4NCg0KICAgQXMgZm9yIGFsbCBJbnRlcm5l dCBtYWlsIGFkZHJlc3NlcywgdGhlIGxlZnQtaGFuZC1zaWRlIChsb2NhbC0gcGFydCkNCiAg IG9mIGFuIGFkZHJlc3MgaXMgbm90IHRvIGJlIGludGVycHJldGVkIGV4Y2VwdCBieSB0aGUg TVRBIHRoYXQgaXMNCiAgIG5hbWVkIG9uIHRoZSByaWdodC1oYW5kLXNpZGUgKGRvbWFpbiku DQoNCiAgIFRoZSB0ZWxlcGhvbmUgbnVtYmVyIGZvcm1hdCBTSE9VTEQgY29uZm9ybSB0byBb MTAsIDExXS4gIE90aGVyDQogICBmb3JtYXRzIE1VU1QgYmUgc3ludGFjdGljYWxseSBkaXN0 aW5jdCBmcm9tIFsxMCwgMTFdLg0KDQoNClRveW9kYSwgZXQuIGFsLiAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMTk5OSAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJu ZXQgRHJhZnQgICAgICAgICAgU2ltcGxlIE1vZGUgb2YgRmFjc2ltaWxlICAgICAgICAgICBG ZWJydWFyeSAxOTk5DQoNCg0KNCAgSU1BR0UgRklMRSBGT1JNQVQNCg0KICAgU2VuZGluZyBJ RmF4IGRldmljZXMgTVVTVCBiZSBhYmxlIHRvIHdyaXRlIG1pbmltdW0gc2V0IFRJRkYgZmls ZXMsDQogICBwZXIgdGhlIHJ1bGVzIGZvciBjcmVhdGluZyBtaW5pbXVtIHNldCBUSUZGIGZp bGVzIGRlZmluZWQgaW4gVElGRiBmb3INCiAgIEZhY3NpbWlsZSAodGhlIFMgcHJvZmlsZSkg WzZdLCB3aGljaCBpcyBhbHNvIGNvbXBhdGlibGUgd2l0aCB0aGUNCiAgIHNwZWNpZmljYXRp b24gZm9yIHRoZSBtaW5pbXVtIHN1YnNldCBvZiBUSUZGLUYgaW4gWzVdLiAgUmVjZWl2aW5n DQogICBJRmF4IGRldmljZXMgTVVTVCBiZSBhYmxlIHRvIHJlYWQgbWluaW11bSBzZXQgVElG RiBmaWxlcy4NCg0KICAgQSBzZW5kZXIgU0hPVUxEIE5PVCB1c2UgVElGRiBmaWVsZHMgYW5k IHZhbHVlcyBiZXlvbmQgdGhlIG1pbmltdW0NCiAgIHN1YnNldCBvZiBUSUZGIGZvciBGYWNz aW1pbGUgdW5sZXNzIHRoZSBzZW5kZXIgaGFzIHByaW9yIGtub3dsZWRnZSBvZg0KICAgb3Ro ZXIgVElGRiBmaWVsZHMgb3IgdmFsdWVzIHN1cHBvcnRlZCBieSB0aGUgcmVjaXBpZW50LiAg VGhlDQogICBtZWNoYW5pc20gZm9yIGRldGVybWluaW5nIGNhcGFiaWxpdGllcyBvZiByZWNp cGllbnRzIGlzIGJleW9uZCB0aGUNCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCjUg IFNFQ1VSSVRZIENPTlNJREVSQVRJT05TDQoNCjUuMSBHZW5lcmFsIERpcmVjdGl2ZQ0KDQog ICBUaGlzIHNwZWNpZmljYXRpb24gaXMgYmFzZWQgb24gdXNlIG9mIGV4aXN0aW5nIEludGVy bmV0IG1haWwuICBUbw0KICAgbWFpbnRhaW4gaW50ZXJvcGVyYWJpbGl0eSB3aXRoIEludGVy bmV0IG1haWwsIGFueSBzZWN1cml0eSB0byBiZQ0KICAgcHJvdmlkZWQgc2hvdWxkIGJlIHBh cnQgb2YgdGhlIG9mIHRoZSBJbnRlcm5ldCBzZWN1cml0eQ0KICAgaW5mcmFzdHJ1Y3R1cmUs IHJhdGhlciB0aGFuIGEgbmV3IG1lY2hhbmlzbSBvciBzb21lIG90aGVyIG1lY2hhbmlzbQ0K ICAgb3V0c2lkZSBvZiB0aGUgSW50ZXJuZXQgaW5mcmFzdHJ1Y3R1cmUuDQoNCjUuMiBUaHJl YXRzIGFuZCBQcm9ibGVtcw0KDQogICBCb3RoIEludGVybmV0IG1haWwgYW5kIEczRmF4IHN0 YW5kYXJkcyBhbmQgb3BlcmF0aW9uYWwgc2VydmljZXMgaGF2ZQ0KICAgdGhlaXIgb3duIHNl dCBvZiB0aHJlYXRzIGFuZCBjb3VudGVybWVhc3VyZXMuICBUaGlzIHNlY3Rpb24gYXR0ZW5k cw0KICAgb25seSB0byB0aGUgc2V0IG9mIGFkZGl0aW9uYWwgdGhyZWF0cyB3aGljaCBlbnN1 ZSBmcm9tIGludGVncmF0aW5nDQogICB0aGUgdHdvIHNlcnZpY2VzLiBUaGlzIHNlY3Rpb24g cmV2aWV3cyByZWxldmFudCBjb25jZXJucyBhYm91dA0KICAgSW50ZXJuZXQgbWFpbCBmb3Ig SUZheCBlbnZpcm9ubWVudHMsIGFzIHdlbGwgYXMgY29uc2lkZXJpbmcgdGhlDQogICBwb3Rl bnRpYWwgcHJvYmxlbXMgd2hpY2ggY2FuIHJlc3VsdCBvZiBpbnRlZ3JhdGluZyB0aGUgZXhp c3RpbmcgRzNGYXgNCiAgIHNlcnZpY2Ugd2l0aCBJbnRlcm5ldCBtYWlsLg0KDQo1LjIuMSAg ICAgU3Bvb2ZlZCBzZW5kZXINCg0KICAgVGhlIGFjdHVhbCBzZW5kZXIgb2YgdGhlIG1lc3Nh Z2UgbWlnaHQgbm90IGJlIHRoZSBzYW1lIGFzIHRoYXQNCiAgIHNwZWNpZmllZCBpbiB0aGUg U2VuZGVyIG9yIEZyb20gZmllbGRzIG9mIHRoZSBtZXNzYWdlIGNvbnRlbnQgaGVhZGVycw0K ICAgb3IgdGhlIE1BSUwgRlJPTSBhZGRyZXNzIGZyb20gdGhlIFNNVFAgZW52ZWxvcGUuDQoN CiAgIEluIGEgdGlnaHRseSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCwgc3VmZmljaWVudCBw aHlzaWNhbCBhbmQNCiAgIHNvZnR3YXJlIGNvbnRyb2xzIG1heSBiZSBhYmxlIHRvIGVuc3Vy ZSBwcmV2ZW50aW9uIG9mIHRoaXMgcHJvYmxlbS4NCiAgIFRoZSB1c3VhbCBzb2x1dGlvbiBp cyB0aHJvdWdoIGVuY3J5cHRpb24tYmFzZWQgYXV0aGVudGljYXRpb24sIGVpdGhlcg0KICAg Zm9yIHRoZSBjaGFubmVsIG9yIGFzc29jaWF0ZWQgd2l0aCB0aGUgb2JqZWN0LCBhcyBkaXNj dXNzZWQgYmVsb3cuDQoNCiAgIEl0IHNob3VsZCBiZSByZWNvZ25pemVkIHRoYXQgU01UUCBp bXBsZW1lbnRhdGlvbnMgZG8gbm90IHByb3ZpZGUNCiAgIGluaGVyZW50IGF1dGhlbnRpY2F0 aW9uIG9mIHRoZSBzZW5kZXJzIG9mIG1lc3NhZ2VzLCBub3IgYXJlIHNpdGVzDQogICB1bmRl ciBvYmxpZ2F0aW9uIHRvIHByb3ZpZGUgc3VjaCBhdXRoZW50aWNhdGlvbi4gRW5kLXRvLWVu ZA0KICAgYXBwcm9hY2hlcyBzdWNoIGFzIFMvTUlNRSBhbmQgUEdQL01JTUUgYXJlIGN1cnJl bnRseSBiZWluZyBkZXZlbG9wZWQNCiAgIHdpdGhpbiB0aGUgSUVURi4gVGhlc2UgdGVjaG5v bG9naWVzIGNhbiBwcm92aWRlIHN1Y2ggYXV0aGVudGljYXRpb24uDQoNCg0KVG95b2RhLCBl dC4gYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAg IFtQYWdlIDZdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBG YWNzaW1pbGUgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQo1LjIuMiAgICAgUmVzb3Vy Y2VzIGNvbnN1bWVkIGJ5IGRpYWxvdXQNCg0KICAgSW4gYWRkaXRpb24gdG8gdGhlIHJlc291 cmNlcyBub3JtYWxseSBjb25zdW1lZCBmb3IgZW1haWwgKENQVSBjeWNsZXMNCiAgIGFuZCBk aXNrKSwgb2ZmcmFtcCBmYWNzaW1pbGUgY2F1c2VzIGFuIG91dGRpYWwgd2hpY2ggb2Z0ZW4g aW1wb3Nlcw0KICAgc2lnbmlmaWNhbnQgcmVzb3VyY2UgY29uc3VtcHRpb24sIHN1Y2ggYXMg ZmluYW5jaWFsIGNvc3QuIFRlY2huaXF1ZXMNCg0KICAgZm9yIGVzdGFibGlzaGluZyBhdXRo b3JpemF0aW9uIG9mIHRoZSBzZW5kZXIgYXJlIGVzc2VudGlhbCB0byB0aG9zZQ0KICAgb2Zm cmFtcCBmYWNzaW1pbGUgc2VydmljZXMgdGhhdCBuZWVkIHRvIG1hbmFnZSBzdWNoIGNvbnN1 bXB0aW9uLg0KDQogICBEdWUgdG8gdGhlIGNvbnN1bXB0aW9uIG9mIHRoZXNlIHJlc291cmNl cyBieSBkaWFsb3V0LCB1bnNvbGljaXRlZA0KICAgYnVsayBlbWFpbCB3aGljaCBjYXVzZXMg YW4gb3V0ZGlhbCBpcyB1bmRlc2lyYWJsZS4NCg0KICAgT2ZmcmFtcCBnYXRld2F5cyBTSE9V TEQgcHJvdmlkZSB0aGUgYWJpbGl0eSB0byBhdXRob3JpemUgc2VuZGVycyBpbg0KICAgc29t ZSBtYW5uZXIgdG8gcHJldmVudCB1bmF1dGhvcml6ZWQgdXNlIG9mIHRoZSBvZmZyYW1wLiBU aGVyZSBhcmUgbm8NCiAgIHN0YW5kYXJkIHRlY2huaXF1ZXMgZm9yIGF1dGhvcml6YXRpb24g dXNpbmcgSW50ZXJuZXQgcHJvdG9jb2xzLg0KDQogICBUeXBpY2FsIHNvbHV0aW9ucyB1c2Ug c2ltcGxlIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBvcmlnaW5hdG9yIHRvDQogICBlc3RhYmxp c2ggYW5kIHZlcmlmeSB0aGVpciBpZGVudGl0eSBhbmQgdGhlbiBjaGVjayB0aGUgaWRlbnRp dHkNCiAgIGFnYWluc3QgYSBwcml2YXRlIGF1dGhvcml6YXRpb24gdGFibGUuDQoNCiAgIE9y aWdpbmF0b3IgYXV0aGVudGljYXRpb24gZW50YWlscyB0aGUgdXNlIG9mIHdlYWsgb3Igc3Ry b25nDQogICBtZWNoYW5pc21zLCBzdWNoIGFzIGNsZWFydGV4dCBrZXl3b3JkcyBvciBlbmNy eXB0aW9uLWJhc2VkIGRhdGEtDQogICBzaWduaW5nLCByZXNwZWN0aXZlbHksIHRvIGRldGVy bWluZSBhbmQgdmFsaWRhdGUgdGhlIGlkZW50aWZ5IG9mIHRoZQ0KICAgc2VuZGVyIGFuZCBh c3Nlc3MgcGVybWlzc2lvbnMgYWNjb3JkaW5nbHkuDQoNCiAgIE90aGVyIGNvbnRyb2wgbWVj aGFuaXNtcyB3aGljaCBhcmUgY29tbW9uIGluY2x1ZGUgc291cmNlIGZpbHRlcmluZw0KICAg YW5kIG9yaWdpbmF0b3IgYXV0aGVudGljYXRpb24uICBTb3VyY2UgZmlsdGVyaW5nIGVudGFp bHMgb2ZmcmFtcA0KICAgZ2F0ZXdheSB2ZXJpZmljYXRpb24gb2YgdGhlIGhvc3Qgb3IgbmV0 d29yayBvcmlnaW5hdGluZyB0aGUgbWVzc2FnZQ0KICAgYW5kIHBlcm1pdHRpbmcgb3IgcHJv aGliaXRpbmcgcmVsYXlpbmcgYWNjb3JkaW5nbHkuDQoNCjUuMi4zICAgICBHU1ROIGF1dGhv cml6YXRpb24gaW5mb3JtYXRpb24NCg0KICAgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBzZW5kZXIgbmVjZXNzYXJ5IHRvIGRpYWwgYSBHM0ZheA0KICAgcmVjaXBpZW50 LCBzdWNoIGFzIHNlbmRlcidzIGNhbGxpbmcgY2FyZCBhdXRob3JpemF0aW9uIG51bWJlciwg bWlnaHQNCiAgIGJlIGRpc2Nsb3NlZCB0byB0aGUgRzNGYXggcmVjaXBpZW50IChvbiB0aGUg Y292ZXIgcGFnZSksIHN1Y2ggYXMNCiAgIHRocm91Z2ggcGFyYW1ldGVycyBlbmNvZGVkIGlu IHRoZSBHM0ZheCByZWNpcGllbnRzIGFkZHJlc3MgaW4gdGhlIFRvOg0KICAgb3IgQ0M6IGZp ZWxkcy4NCg0KICAgU2VuZGVycyBTSE9VTEQgYmUgcHJvdmlkZWQgd2l0aCBhIG1ldGhvZCBv ZiBwcmV2ZW50aW5nIHN1Y2gNCiAgIGRpc2Nsb3N1cmUuICBBcyB3aXRoIG1lY2hhbmlzbXMg Zm9yIGhhbmRsaW5nIHVuc29saWNpdGVkIGZheGVzLCB0aGVyZQ0KICAgYXJlIG5vdCB5ZXQg c3RhbmRhcmQgbWVjaGFuaXNtcyBmb3IgcHJvdGVjdGluZyBzdWNoIGluZm9ybWF0aW9uLg0K ICAgT3V0LW9mLWJhbmQgY29tbXVuaWNhdGlvbiBvZiBhdXRob3JpemF0aW9uIGluZm9ybWF0 aW9uIG9yIHVzZSBvZg0KICAgZW5jcnlwdGVkIGRhdGEgaW4gc3BlY2lhbCBmaWVsZHMgYXJl IHRoZSBhdmFpbGFibGUgbm9uLXN0YW5kYXJkDQogICB0ZWNobmlxdWVzLg0KDQogICBUeXBp Y2FsbHkgYXV0aG9yaXphdGlvbiBuZWVkcyB0byBiZSBhc3NvY2lhdGVkIHRvIHNwZWNpZmlj IHNlbmRlcnMNCiAgIGFuZCBzcGVjaWZpYyBtZXNzYWdlcywgaW4gb3JkZXIgdG8gcHJldmVu dCBhICJyZXBsYXkiIGF0dGFjayB3aGljaA0KICAgY2F1c2VzIGFuZCBlYXJsaWVyIGF1dGhv cml6YXRpb24gdG8gZW5hYmxlIGEgbGF0ZXIgZGlhbC1vdXQgYnkgYQ0KICAgZGlmZmVyZW50 IChhbmQgdW5hdXRob3JpemVkKSBzZW5kZXIuICBBIG5vbi1tYWxpY2lvdXMgZXhhbXBsZSBv ZiBzdWNoDQoNCg0KVG95b2RhLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAx OTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAg ICAgICBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkN Cg0KDQogICBhIHJlcGxheSB3b3VsZCBiZSB0byBoYXZlIGFuIGVtYWlsIHJlY2lwaWVudCBy ZXBseSB0byBhbGwgb3JpZ2luYWwNCiAgIHJlY2lwaWVudHMgLS0gaW5jbHVkaW5nIGFuIG9m ZnJhbXAgSUZheCByZWNpcGllbnQgLS0gYW5kIGhhdmUgdGhlDQogICBvcmlnaW5hbCBzZW5k ZXIncyBhdXRob3JpemF0aW9uIGNhdXNlIHRoZSByZXBseSB0byBiZSBzZW50Lg0KDQo1LjIu NCAgICAgU2VuZGVyIGFjY291bnRhYmlsaXR5DQoNCiAgIEluIG1hbnkgY291bnRyaWVzLCB0 aGVyZSBpcyBhIGxlZ2FsIHJlcXVpcmVtZW50IHRoYXQgdGhlICJzZW5kZXIiIGJlDQogICBk aXNjbG9zZWQgb24gYSBmYWNzaW1pbGUgbWVzc2FnZS4gIEVtYWlsIEZyb20gYWRkcmVzc2Vz IGFyZSB0cml2aWFsDQogICB0byBmYWtlLCBzbyB0aGF0IHVzaW5nIG9ubHkgdGhlIE1BSUwg RlJPTSBbMSwgM10gIG9yIEZyb20gWzIsIDNdDQogICBoZWFkZXIgaXMgbm90IHN1ZmZpY2ll bnQuDQoNCiAgIE9mZnJhbXBzIFNIT1VMRCBlbnN1cmUgdGhhdCB0aGUgcmVjaXBpZW50IGlz IHByb3ZpZGVkIGNvbnRhY3QNCiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBvZmZyYW1wLCBp biB0aGUgZXZlbnQgb2YgcHJvYmxlbXMuDQoNCiAgIFRoZSBHM0ZheCByZWNpcGllbnQgU0hP VUxEIGJlIHByb3ZpZGVkIHdpdGggc3VmZmljaWVudCBpbmZvcm1hdGlvbg0KICAgd2hpY2gg cGVybWl0cyB0cmFjaW5nIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBJRmF4IG1lc3NhZ2UuICBT dWNoDQogICBpbmZvcm1hdGlvbiBtaWdodCBpbmNsdWRlIHRoZSBjb250ZW50cyBvZiB0aGUg TUFJTCBGUk9NLCBGcm9tLCBTZW5kZXINCiAgIGFuZCBSZXBseS1UbyBoZWFkZXJzLCBhcyB3 ZWxsIGFzIE1lc3NhZ2UtSWQgYW5kIFJlY2VpdmVkIGhlYWRlcnMuDQoNCjUuMi41ICAgICBN ZXNzYWdlIGRpc2Nsb3N1cmUNCg0KICAgVXNlcnMgb2YgRzNGYXggZGV2aWNlcyBoYXZlIGFu IGV4cGVjdGF0aW9uIG9mIGEgbGV2ZWwgb2YgbWVzc2FnZQ0KICAgcHJpdmFjeSB3aGljaCBp cyBoaWdoZXIgdGhhbiB0aGUgbGV2ZWwgcHJvdmlkZWQgYnkgSW50ZXJuZXQgbWFpbA0KICAg d2l0aG91dCBzZWN1cml0eSBlbmhhbmNlbWVudHMuDQoNCiAgIFRoaXMgZXhwZWN0YXRpb24g b2YgcHJpdmFjeSBieSBHM0ZheCB1c2VycyBTSE9VTEQgYmUgcHJlc2VydmVkIGFzDQogICBt dWNoIGFzIHBvc3NpYmxlLg0KDQogICBTdWZmaWNpZW50IHBoeXNpY2FsIGFuZCBzb2Z0d2Fy ZSBjb250cm9sIG1heSBiZSBhY2NlcHRhYmxlIGluDQogICBjb25zdHJhaW5lZCBlbnZpcm9u bWVudHMuICBUaGUgdXN1YWwgbWVjaGFuaXNtIGZvciBlbnN1cmluZyBkYXRhDQogICBjb25m aWRlbnRpYWxseSBlbnRhaWwgZW5jcnlwdGlvbiwgYXMgZGlzY3Vzc2VkIGJlbG93Lg0KDQo1 LjIuNiAgICAgTm9uIHByaXZhdGUgbWFpbGJveGVzDQoNCiAgIFdpdGggZW1haWwsIGJvdW5j ZXMgKGRlbGl2ZXJ5IGZhaWx1cmVzKSBhcmUgdHlwaWNhbGx5IHJldHVybmVkIHRvIHRoZQ0K ICAgc2VuZGVyIGFuZCBub3QgdG8gYSBwdWJsaWNseS1hY2Nlc3NpYmxlIGVtYWlsIGFjY291 bnQgb3IgcHJpbnRlci4NCiAgIFdpdGggZmFjc2ltaWxlLCBib3VuY2VzIGRvIG5vdCB0eXBp Y2FsbHkgb2NjdXIuICBIb3dldmVyLCB3aXRoIElGYXgsDQogICBhIGJvdW5jZSBjb3VsZCBi ZSBzZW50IGVsc2V3aGVyZSAoc2VlIHNlY3Rpb24gW0RlbGl2ZXJ5IEZhaWx1cmVdKSwNCiAg IHN1Y2ggYXMgYSBsb2NhbCBzeXN0ZW0gYWRtaW5pc3RyYXRvcidzIGFjY291bnQsIHB1Ymxp Y2x5LWFjY2Vzc2libGUNCiAgIGFjY291bnQsIG9yIGFuIElGYXggcHJpbnRlciAoc2VlIGFs c28gW1RyYWZmaWMgQW5hbHlzaXNdKS4NCg0KNS4yLjcgICAgIFRyYWZmaWMgYW5hbHlzaXMN Cg0KICAgRWF2ZXNkcm9wcGluZyBvZiBzZW5kZXJzIGFuZCByZWNpcGllbnRzIGlzIGVhc2ll ciBvbiB0aGUgSW50ZXJuZXQNCiAgIHRoYW4gR1NUTi4gIE5vdGUgdGhhdCBtZXNzYWdlIG9i amVjdCBlbmNyeXB0aW9uIGRvZXMgbm90IHByZXZlbnQNCiAgIHRyYWZmaWMgYW5hbHlzaXMs IGJ1dCBjaGFubmVsIHNlY3VyaXR5IGNhbiBoZWxwIHRvIGZydXN0cmF0ZSBhdHRlbXB0cw0K ICAgYXQgdHJhZmZpYyBhbmFseXNpcy4NCg0KDQoNCg0KVG95b2RhLCBldC4gYWwuICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoM DQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgICAg ICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQo1LjMgU2VjdXJpdHkgVGVjaG5pcXVlcw0KDQog ICBUaGVyZSBhcmUgdHdvIGJhc2ljIGFwcHJvYWNoZXMgdG8gZW5jcnlwdGlvbi1iYXNlZCBz ZWN1cml0eSB3aGljaA0KICAgc3VwcG9ydCBhdXRoZW50aWNhdGlvbiBhbmQgcHJpdmFjeToN Cg0KNS4zLjEgICAgIENoYW5uZWwgc2VjdXJpdHkNCg0KICAgQXMgd2l0aCBhbGwgZW1haWws IGFuIElGYXggbWVzc2FnZSBjYW4gYmUgdmlld2VkIGFzIGl0IHRyYXZlcnNlcw0KICAgaW50 ZXJuYWwgbmV0d29ya3Mgb3IgdGhlIEludGVybmV0IGl0c2VsZi4NCg0KICBWaXJ0dWFsIFBy aXZhdGUgTmV0d29ya3MgKFZQTiksIGVuY3J5cHRlZCB0dW5uZWxzLCBvciB0cmFuc3BvcnQN CiAgbGF5ZXIgc2VjdXJpdHkgY2FuIGJlIHVzZWQgdG8gcHJldmVudCBlYXZlc2Ryb3BwaW5n IG9mIGEgbWVzc2FnZQ0KICBhcyBpdCB0cmF2ZXJzZXMgc3VjaCBuZXR3b3Jrcy4gIEl0IGFs c28gcHJvdmlkZXMgc29tZSBwcm90ZWN0aW9uDQogIGFnYWluc3QgdHJhZmZpYyBhbmFseXNp cywgYXMgZGVzY3JpYmVkIGFib3ZlLg0KDQogIEF0IHRoZSBjdXJyZW50IHRpbWUgdmFyaW91 cyBwcm90b2NvbHMgZXhpc3QgZm9yIHBlcmZvcm1pbmcgdGhlIGFib3ZlDQogIGZ1bmN0aW9u cywgYW5kIGFyZSBvbmx5IG1lbnRpb25lZCBoZXJlIGZvciBpbmZvcm1hdGlvbi4gIFN1Y2gg cHJvdG9jb2xzDQogIGFyZSBJUFNlYyBbMTZdIGFuZCBUTFMgWzE4XS4NCg0KNS4zLjIgICAg IE9iamVjdCBzZWN1cml0eQ0KDQogICBBcyB3aXRoIGFsbCBlbWFpbCwgYW4gSUZheCBtZXNz YWdlIGNhbiBiZSB2aWV3ZWQgd2hpbGUgaXQgcmVzaWRlcyBvbiwNCiAgIG9yIHdoaWxlIGl0 IGlzIHJlbGF5ZWQgdGhyb3VnaCwgYW4gaW50ZXJtZWRpYXRlIE1haWwgVHJhbnNmZXIgQWdl bnQuDQogIA0KICBNZXNzYWdlIGVuY3J5cHRpb24gY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBl bmQtdG8tZW5kIGVuY3J5cHRpb24uDQogIA0KICBBdCB0aGUgY3VycmVudCB0aW1lIHR3byBw cm90b2NvbHMgYXJlIGNvbW1vbmx5IHVzZWQgZm9yIG1lc3NhZ2UNCiAgZW5jcnlwdGlvbiBh bmQgYXJlIG9ubHkgbWVudGlvbmVkIGhlcmUgZm9yIGluZm9ybWF0aW9uLiAgVGhlIHR3bw0K ICBwcm90b2NvbHMgYXJlIFBHUC1NSU1FIFsxMl0gYW5kIFMvTUlNRSBbMTldLg0KDQo2ICBS RUZFUkVOQ0VTDQoNCiAgIFsxXSAgUG9zdGVsLCBKLiwgIlNpbXBsZSBNYWlsIFRyYW5zZmVy IFByb3RvY29sIiwgU1REIDEwLCBSRkMNCiAgICAgICAgODIxLCBBdWd1c3QgMTk4Mi4NCg0K ICAgWzJdICBDcm9ja2VyLCBELiwgIlN0YW5kYXJkIGZvciB0aGUgRm9ybWF0IG9mIEFSUEEg SW50ZXJuZXQNCiAgICAgICAgVGV4dCBNZXNzYWdlcyIsIFNURCAxMSwgUkZDIDgyMiwgQXVn dXN0IGw5ODIuDQoNCiAgIFszXSAgQnJhZGVuLCBSLiwgMTEyMyAiUmVxdWlyZW1lbnRzIGZv ciBJbnRlcm5ldCBob3N0cyAtDQogICAgICAgIGFwcGxpY2F0aW9uIGFuZCBzdXBwb3J0Iiwg UkZDIDExMjMsIE9jdG9iZXIgMTk4OS4NCg0KICAgWzRdICBCb3JlbnN0ZWluLCBOLiwgYW5k IE4uIEZyZWVkLCAiIE11bHRpcHVycG9zZSBJbnRlcm5ldA0KICAgICAgICBNYWlsIEV4dGVu c2lvbnMgKE1JTUUpIFBhcnQgRml2ZTogIENvbmZvcm1hbmNlIENyaXRlcmlhIGFuZA0KICAg ICAgICBFeGFtcGxlcyAiLCBSRkMgMjA0OSwgTm92ZW1iZXIgMTk5Ni4NCg0KICAgWzVdICBQ YXJzb25zLCBHLiwgYW5kIEouIFJhZmZlcnR5LCAiVGFnIEltYWdlIEZpbGUgRm9ybWF0DQog ICAgICAgIChUSUZGKSAtLSBGIFByb2ZpbGUgZm9yIEZhY3NpbWlsZSIsIFJGQyAyMzA2LCBN YXJjaCAxOTk4Lg0KDQoNCg0KVG95b2RhLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldCBEcmFm dCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgICAgICAgICAgIEZlYnJ1YXJ5 IDE5OTkNCg0KDQogICBbNl0gIE1jSW50eXJlLCBMLiwgWmlsbGVzLCBTLiwgQnVja2xleSwg Ui4sIFZlbmFibGUsIEQuLA0KICAgICAgICBQYXJzb25zLCBHLiwgYW5kIEouIFJhZmZlcnR5 LCAiRmlsZSBGb3JtYXQgZm9yIEludGVybmV0IEZheCIsDQogICAgICAgIFJGQyAyMzAxLCBN YXJjaCAxOTk4Lg0KDQogICBbN10gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMg MjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgWzhdICBJVFUtVCAoQ0NJVFQpLCAiU3RhbmRhcmRp emF0aW9uIG9mIEdyb3VwIDMgZmFjc2ltaWxlDQogICAgICAgIGFwcGFyYXR1cyBmb3IgZG9j dW1lbnQgdHJhbnNtaXNzaW9uIiwgSVRVLVQgKENDSVRUKSwNCiAgICAgICAgUmVjb21tZW5k YXRpb24gVC40Lg0KDQogICBbOV0gIE15ZXJzLCBKLiwgYW5kIE0uIFJvc2UsICJQb3N0IE9m ZmljZSBQcm90b2NvbCAtIFZlcnNpb24NCiAgICAgICAgMyIsIFNURCA1MywgUkZDIDE5Mzks IE1heSAxOTk2Lg0KDQogICBbMTBdIEFsbG9jY2hpbywgQy4sICJNaW5pbWFsIFBTVE4gYWRk cmVzcyBmb3JtYXQgZm9yIEludGVybmV0DQogICAgICAgIG1haWwiLCBSRkMgMjMwMywgTWFy Y2ggMTk5OC4NCg0KICAgWzExXSBBbGxvY2NoaW8sIEMuLCAiTWluaW1hbCBmYXggYWRkcmVz cyBmb3JtYXQgZm9yIEludGVybmV0DQogICAgICAgIG1haWwiLCBSRkMgMjMwNCwgTWFyY2gg MTk5OC4NCg0KICAgWzEyXSBDYWxsYXMsIEouLCBEb25uZXJoYWNrZSwgTC4sIEZpbm5leSwg SC4sIGFuZCBUaGF5ZXIsIFIuLA0KICAgICAgICAiT3BlblBHUCBNZXNzYWdlIEZvcm1hdCIs IFJGQyAyNDQwLCBOb3ZlbWJlciAxOTk4DQoNCiAgIFsxM10gTW9vcmUsIEsuLCBhbmQgRy4g VmF1ZHJldWlsLCAiQW4gRXh0ZW5zaWJsZSBNZXNzYWdlDQogICAgICAgIEZvcm1hdCBmb3Ig RGVsaXZlcnkgU3RhdHVzIE5vdGlmaWNhdGlvbnMiLCBSRkMgMTg5NCwgSmFudWFyeQ0KICAg ICAgICAxOTk2Lg0KDQogICBbMTRdIEZyZWVkLCBOLiwgYW5kIE4uIEJvcmVuc3RlaW4sICJN dWx0aXB1cnBvc2UgSW50ZXJuZXQNCiAgICAgICAgTWFpbCBFeHRlbnNpb25zIChNSU1FKSBQ YXJ0IFR3bzogTWVkaWEgVHlwZXMiLCBSRkMgMjA0NiwNCiAgICAgICAgTm92ZW1iZXIgMTk5 Ni4NCg0KICAgWzE1XSBNb29yZSwgSy4sICJNSU1FIChNdWx0aXB1cnBvc2UgSW50ZXJuZXQg TWFpbCBFeHRlbnNpb25zKSBQYXJ0DQogICAgICAgIFRocmVlOiBNZXNzYWdlIEhlYWRlciBF eHRlbnNpb25zIGZvciBOb24tQVNDSUkgVGV4dCIsIFJGQyAyMDQ3LA0KICAgICAgICBOb3Zl bWJlciAxOTk2Lg0KDQogICBbMTZdIEtlbnQsIFMuIGFuZCBBdGtpbnNvbiwgUi4sICJTZWN1 cml0eSBBcmNoaXRlY3R1cmUgZm9yIHRoZQ0KICAgICAgICBJbnRlcm5ldCBQcm90b2NvbCIs IFJGQyAyNDAxLCBOb3ZlbWJlciAxOTk4Lg0KDQogICBbMTddIFBhcnNvbnMsIEcuIGFuZCBS YWZmZXJ0eSwgSi4sICJUYWcgSW1hZ2UgRmlsZSBGb3JtYXQNCiAgICAgICAgKFRJRkYpIC0t IGltYWdlL1RJRkY6IE1JTUUgU3ViLXR5cGUgUmVnaXN0cmF0aW9uIiwgUkZDIDIzMDIsDQog ICAgICAgIE1hcmNoIDE5OTguDQoNCiAgIFsxOF0gSG9mZm1hbiwgUC4sICJTTVRQIFNlcnZp Y2UgRXh0ZW5zaW9uIGZvciBTZWN1cmUgU01UUCBvdmVyIFRMUyIsDQogICAgICAgIFJGQyAy NDg3LCBKYW51YXJ5IDE5OTkuDQoNCiAgIFsxOV0gRHVzc2UsIFMuLCBIb2ZmbWFuLCBQLiwg UmFtc2RlbGwsIEIuLCBMdW5kYmxhZGUsIEwuLCBhbmQNCiAgICAgICAgTC4gUmVwa2EsICJT L01JTUUgVmVyc2lvbiAyIE1lc3NhZ2UgU3BlY2lmaWNhdGlvbiIsIFJGQyAyMzExLA0KICAg ICAgICBNYXJjaCAxOTk4Lg0KDQoNCg0KVG95b2RhLCBldC4gYWwuICAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5l dCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9kZSBvZiBGYWNzaW1pbGUgICAgICAgICAgIEZl YnJ1YXJ5IDE5OTkNCg0KDQo3ICBBQ0tOT1dMRURHRU1FTlRTDQoNCiAgIFRoaXMgc3BlY2lm aWNhdGlvbiB3YXMgcHJvZHVjZWQgYnkgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sN CiAgIEZvcmNlIEZheCBXb3JraW5nIEdyb3VwLCBvdmVyIHRoZSBjb3Vyc2Ugb2YgbW9yZSB0 aGFuIG9uZSB5ZWFyJ3MNCiAgIG9ubGluZSBhbmQgZmFjZS10by1mYWNlIGRpc2N1c3Npb25z LiAgQXMgd2l0aCBhbGwgSUVURiBlZmZvcnRzLCBtYW55DQogICBwZW9wbGUgY29udHJpYnV0 ZWQgdG8gdGhlIGZpbmFsIHByb2R1Y3QuDQoNCiAgIEFjdGl2ZSBmb3IgdGhpcyBkb2N1bWVu dCB3ZXJlOiBTdGV2ZSBIdXN0b24sIEplZmZyZXkgUGVycnksIEdyZWcNCiAgIFZhdWRyZXVp bCwgUmljaGFyZCBTaG9ja2V5LCBDaGFybGVzIFd1LCBHcmFoYW0gS2x5bmUsIFJvYmVydCBB Lg0KICAgUm9zZW5iZXJnLCBMYXJyeSBNYXNpbnRlciwgRGF2ZSBDcm9ja2VyLCBIZXJtYW4g U2lsYmlnZXIsIEphbWVzDQogICBSYWZmZXJ0eS4NCg0KOCAgQVVUSE9SUycgQUREUkVTU0VT DQoNCiAgIEtpeW9zaGkgVG95b2RhDQogICBNYXRzdXNoaXRhIEdyYXBoaWMgQ29tbXVuaWNh dGlvbiBTeXN0ZW1zLCBJbmMuDQogICAyLTMtOCBTaGltb21lZ3VybywgTWVndXJvLWt1DQog ICBUb2t5byAxNTMgSmFwYW4NCiAgIEZheDogKzgxIDMgNTQzNCA3MTY2DQogICBFbWFpbDog a3RveW9kYUByZG1nLm1nY3MubWVpLmNvLmpwDQoNCiAgIEhpcm95dWtpIE9obm8NCiAgIFRv a3lvIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5DQogICAyLTEyLTEgTy1va2F5YW1hLCBNZWd1 cm8ta3UNCiAgIFRva3lvIDE1MiBKYXBhbg0KICAgRkFYOiArODEgMyA1NzM0IDI3NTQNCiAg IEVtYWlsOiBob2hub0Bpcy50aXRlY2guYWMuanANCg0KICAgSnVuIE11cmFpDQogICBLZWlv IFVuaXZlcnNpdHkNCiAgIDUzMjIgRW5kbywgRnVqaXNhd2ENCiAgIEthbmFnYXdhIDI1MiBK YXBhbg0KICAgRmF4OiArODEgNDY2IDQ5IDExMDENCiAgIEVtYWlsOiBqdW5Ad2lkZS5hZC5q cA0KDQogICBEYW4gV2luZw0KICAgMTcwIFcuIFRhc21hbiBEcml2ZQ0KICAgU2FuIEpvc2Us IENBIDk1MTM0DQogICBQaG9uZTogKzEgNDA4IDUyNSA1MzE0DQogICBFbWFpbDogZHdpbmdA Y2lzY28uY29tDQoNCg0KDQoNCg0KDQoNCg0KDQpUb3lvZGEsIGV0LiBhbC4gICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDE5OTkgICAgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCklu dGVybmV0IERyYWZ0ICAgICAgICAgIFNpbXBsZSBNb2RlIG9mIEZhY3NpbWlsZSAgICAgICAg ICAgRmVicnVhcnkgMTk5OQ0KDQoNCjkgQVBQRU5ESVggQTogIEV4Y2VwdGlvbnMgdG8gTUlN RQ0KDQogICAqICAgIElGYXggc2VuZGVycyBhcmUgTk9UIFJFUVVJUkVEIHRvIGJlIGFibGUg dG8gc2VuZA0KICAgICAgICB0ZXh0L3BsYWluIG1lc3NhZ2VzIChSRkMgMjA0OSByZXF1aXJl bWVudCA0KSwgYWx0aG91Z2ggSUZheA0KICAgICAgICByZWNpcGllbnRzIGFyZSByZXF1aXJl ZCB0byBhY2NlcHQgc3VjaCBtZXNzYWdlcywgYW5kIHRvIHByb2Nlc3MNCiAgICAgICAgdGhl bS4NCg0KICAgKiAgICBJRmF4IHJlY2lwaWVudHMgYXJlIE5PVCBSRVFVSVJFRCB0byBvZmZl ciB0byBwdXQgcmVzdWx0cw0KICAgICAgICBpbiAgYSBmaWxlLiAoQWxzbyBzZWUgMi4zLjIu KQ0KDQogICAqICAgIElGYXggcmVjaXBpZW50cyBNQVkgZGlyZWN0bHkgcHJpbnQvZmF4ICB0 aGUgcmVjZWl2ZWQNCiAgICAgICAgbWVzc2FnZSByYXRoZXIgIHRoYW4gImRpc3BsYXkiIGl0 LCBhcyBpbmRpY2F0ZWQgaW4gUkZDIDIwNDkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVG95 b2RhLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAg ICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICBTaW1wbGUgTW9k ZSBvZiBGYWNzaW1pbGUgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQoxMCAgRnVsbCBD b3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDE5OTkpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVu dCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0 bw0KICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Ig b3RoZXJ3aXNlIGV4cGxhaW4gaXQNCiAgIG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRp b24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZA0KICAgYW5kIGRpc3RyaWJ1 dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQ0K ICAga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQg dGhpcyBwYXJhZ3JhcGggYXJlDQogICBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5k IGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYg bWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nDQog ICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBT b2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMg bmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFu ZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMg ZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBiZQ0KICAg Zm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdl cyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9u cyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZv a2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2ln bnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5U RVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZP UkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNM VURJTkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTg0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBS SUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRg0KICAgTUVSQ0hBTlRBQklMSVRZ IE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVG95b2RhLCBldC4gYWwuICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoM DQoNCg== ----------------------4130014523499218-- From owner-ietf-fax@mail.imc.org Mon May 15 19:44:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11600 for ; Mon, 15 May 2000 19:44:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA06870 for ietf-fax-bks; Mon, 15 May 2000 16:13:11 -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 QAA06866 for ; Mon, 15 May 2000 16:13: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 IAA08447; Tue, 16 May 2000 08:19:30 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA02269; Tue, 16 May 2000 08:19:29 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id IAA05495; Tue, 16 May 2000 08:12:51 +0900 (JST) To: ktoyoda@rdmg.mgcs.mei.co.jp, ietf-fax@imc.org Subject: Re: draft-ietf-fax-service-v2-02 In-Reply-To: <200005110601.AA00313@d23n59.rdmg.mgcs.mei.co.jp> References: <200005110601.AA00313@d23n59.rdmg.mgcs.mei.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516082507G.tamura@toda.ricoh.co.jp> Date: Tue, 16 May 2000 08:25:07 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Toyoda-san, I missed your message for a few days. Sorry. > We revised the service draft as draft-ietf-fax-service-v2-02 > attached. By revising the draft, we can resolve the depandency > problem about IMAP4, but must wait for being Draft standards of > DSN and addressing. OK. Concerning addressing, We might solve it because this document is under our WG. Concerning DSN(RFC 1894), does anybody know the situation about being Draft standard ? Anyway, I suggest you submit it as new I-D. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. Mail: tamura@toda.ricoh.co.jp Tel: +81-46-228-1743 Fax: +81-46-228-7500 (SUB/F-code 5727) From owner-ietf-fax@mail.imc.org Tue May 16 07:04:47 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 HAA01287 for ; Tue, 16 May 2000 07:04:47 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA01517 for ietf-fax-bks; Tue, 16 May 2000 03:24:56 -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 DAA01509 for ; Tue, 16 May 2000 03:24:55 -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 GAA00696; Tue, 16 May 2000 06:31:23 -0400 (EDT) Message-Id: <200005161031.GAA00696@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-tiff-fx-05.txt Date: Tue, 16 May 2000 06:31:22 -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 : File Format for Internet Fax Author(s) : R. Buckley, D. Venable, S. Zilles, L. McIntyre, G. Parsons, J. Rafferty Filename : draft-ietf-fax-tiff-fx-05.txt Pages : 85 Date : 15-May-00 This document is a revised version of Proposed Standard RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since the Proposed Standard was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-05.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-tiff-fx-05.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-tiff-fx-05.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: <20000515095103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-fx-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-fx-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000515095103.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Wed May 17 07:31:04 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 HAA02782 for ; Wed, 17 May 2000 07:31:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA22437 for ietf-fax-bks; Wed, 17 May 2000 03:50:53 -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 DAA22432 for ; Wed, 17 May 2000 03:50:51 -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 GAA02204; Wed, 17 May 2000 06:57:24 -0400 (EDT) Message-Id: <200005171057.GAA02204@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-tiff-fx-06.txt Date: Wed, 17 May 2000 06:57:23 -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 : File Format for Internet Fax Author(s) : R. Buckley, D. Venable, S. Zilles, L. McIntyre, G. Parsons, J. Rafferty Filename : draft-ietf-fax-tiff-fx-06.txt Pages : 85 Date : 16-May-00 This document is a revised version of Proposed Standard RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since the Proposed Standard was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-tiff-fx-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-tiff-fx-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000516095122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-fx-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-fx-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000516095122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Thu May 18 02:33:04 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 CAA28677 for ; Thu, 18 May 2000 02:33:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA18972 for ietf-fax-bks; Wed, 17 May 2000 22:52:16 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA18967 for ; Wed, 17 May 2000 22:52:14 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id OAA02102; Thu, 18 May 2000 14:57:28 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id OAA09828; Thu, 18 May 2000 14:57:24 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 18 May 2000 05:57:25 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id OAA06796; Thu, 18 May 2000 14:57:24 +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 OAA08464; Thu, 18 May 2000 14:57:23 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.9.3/3.7W-RDMG) with SMTP id OAA19597; Thu, 18 May 2000 14:54:36 +0900 (JST) Message-Id: <200005180558.AA00328@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Thu, 18 May 2000 14:58:26 +0900 To: Hiroshi Tamura Cc: ietf-fax@imc.org Subject: Re: draft-ietf-fax-service-v2-02 In-Reply-To: <20000516082507G.tamura@toda.ricoh.co.jp> References: <20000516082507G.tamura@toda.ricoh.co.jp> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tamura-san, I will sumit draft-ietf-fax-services-v2-02 as new ID after we find a way to solve the issues of addressing and DSN(RFC 1894) is expected to become Draft Standard. Hiroshi Tamura wrote: >Toyoda-san, > >OK. >Concerning addressing, We might solve it because this document >is under our WG. > >Concerning DSN(RFC 1894), does anybody know the situation >about being Draft standard ? > >Anyway, I suggest you submit it as new I-D. > Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Thu May 18 07:28:22 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 HAA02652 for ; Thu, 18 May 2000 07:28:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA08799 for ietf-fax-bks; Thu, 18 May 2000 03:30:11 -0700 (PDT) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08795 for ; Thu, 18 May 2000 03:30:09 -0700 (PDT) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id TAA15388; Thu, 18 May 2000 19:36:44 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma015334; Thu, 18 May 00 19:36:31 +0900 Received: from canongw.cecn.canon.co.jp (localhost [127.0.0.1]) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA04954; Thu, 18 May 2000 19:36:30 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id TAA02532; Thu, 18 May 2000 19:36:30 +0900 (JST) Received: from 18209 ([172.22.33.253]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id TAA17523; Thu, 18 May 2000 19:32:44 +0900 (JST) Message-Id: <4.2.0.58.J.20000518191926.00a46370@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 18 May 2000 19:40:50 +0900 To: "McIntyre, Lloyd" , ietf-fax@imc.org From: MAEDA toru Subject: RE: New resolutions for TIFF-FX In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE067A28C8@mercury.ADOC.xero x.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: Dear McIntyre-san, Thank you very much for clear explanation about my question. I wish to have an up-to-date TIFF-FX standards than a fossil Draft standard. I will wait a new version of TIFF-FX RFC for 600 dpi by 21th century. Why don't you write tiff-fx-v2-01 now? Do we have to wait TIFF-FX to Draft Standard status before writing TIFF-FX extension draft? Regards Toru MAEDA At 10:36 00/05/09 -0700, McIntyre, Lloyd wrote: >Maeda-san, >You are correct, in that T.30 has introduced a set of new resolutions. >These new resolutions, along with other enhancements (e.g. JBIG2, >Annotations, more than 3 MRC layers, etc.) are being addressed in the >planned TIFF-FX extension draft. The first TIFF-FX extension draft is >scheduled for distribution prior to the next IETF meeting. This new TIFF-FX >extension will undergo the normal draft review process and will then be >submitted for Proposed Standard consideration. > >It is not appropriate to add the new resolutions to tiff-fx-04 since >tiff-fx-04 reflects RFC2301 revisions that are necessary to progress this >version of TIFF-FX to Draft Standard status. > >I hope this clarifies the situation. > >Regards > >Lloyd > > > -----Original Message----- > > From: MAEDA toru [mailto:maeda@ffm.canon.co.jp] > > Sent: Tuesday, May 09, 2000 12:02 AM > > To: ietf-fax@imc.org; Lloyd.McIntyre@pahv.xerox.com > > Subject: New resolutions for TIFF-FX > > > > > > Dear McIntyre-san, > > > > ITU-T added new resolutions for T.30. > > tiff-fx-04 should also include those resolutions as follows. > > > > Black and White > > 600x600 dpi > > 1200x1200 > > 300x600 > > 400x800 > > 600x1200 > > > > Colour and Gray Scale > > 600x600 dpi > > 1200x1200 > > > > Regards. > > > > Toru MAEDA > > > > ---------------------------- > > CANON INC. > > TORU MAEDA > > Technology Advancement Div. 3 > > 3-30-2,Shimomaruko Ohtaku,Tokyo,Japan > > E-mail maeda@ffm.canon.co.jp > > TEL +81-3-3757-9738 FAX +81-3-3757-8205 > > ---------------------------- > > ***************************** Toru MAEDA CANON Inc. OIP Technology Adv. 3 ***************************** From owner-ietf-fax@mail.imc.org Thu May 18 12:23:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09921 for ; Thu, 18 May 2000 12:23:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21111 for ietf-fax-bks; Thu, 18 May 2000 08:43:26 -0700 (PDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21107 for ; Thu, 18 May 2000 08:43:24 -0700 (PDT) Received: from [10.0.1.4] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id RAA12103; Thu, 18 May 2000 17:49:03 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: Date: Thu, 18 May 2000 17:50:16 +0200 To: GK@acm.org, Lloyd.McIntyre@pahv.xerox.com From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: draft-ietf-fax-feature-schema-v2-01.txt, draft-ietf-fax-feature-T30-mapping-03.txt Cc: Claudio Allocchio , James Rafferty , Hiroshi Tamura , ietf-fax@imc.org, Ned Freed Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In the discussions in the IESG about the documents mentioned in the Subject, the following is a proposed note to the RFC-Editor to make the changes stated. Please respond and let me know if this is ok or not. I.e. what is needed is an explicit note stating that this document is obsoleting RFC 2531. Patrik Faltstrom Area Director, Applications Area ------------- Dear RFC Editor Please replace in draft-ietf-fax-feature-schema-v2-01.txt: 1. Introduction This document revises the content feature schema described in RFC 2531, with clarifications to some of the feature tag descriptions and addition of one new feature tag. with 1. Introduction This document revises the content feature schema described in RFC 2531, with clarifications to some of the feature tag descriptions and addition of one new feature tag. This document thus obsoletes RFC 2531. From owner-ietf-fax@mail.imc.org Thu May 18 16:27:52 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 QAA12789 for ; Thu, 18 May 2000 16:27:51 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA26934 for ietf-fax-bks; Thu, 18 May 2000 12:38:42 -0700 (PDT) Received: from lysithea.eastgw.xerox.com (root@lysithea.xerox.com [208.140.33.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26928 for ; Thu, 18 May 2000 12:38:41 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA01819; Thu, 18 May 2000 15:45: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 MAA10482; Thu, 18 May 2000 12:44:57 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 18 May 2000 12:44:56 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A2928@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'MAEDA toru'" , "McIntyre, Lloyd" , ietf-fax@imc.org Subject: RE: New resolutions for TIFF-FX Date: Thu, 18 May 2000 12:44:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maeda-san, Please allow me to clarify the situation with regard to TIFF-FX progression to Draft Standard and TIFF-FX Extension. 1. The progression of TIFF-FX to Draft Standard and the development of TIFF-FX Extension are being done in parallel. There is no dependency in their progress. 2. TIFF-FX status: - it was issued as Proposed Standard RFC 2301 in 1998. - it has since meet the following requirements for consideration as a Draft Standard: a. Demonstration that it is implementable by independent implementers. This is documented in the TIFF-FX Implementation Report. b. Demonstration that it is interoperable when implemented by independent implementers. This is documented in the TIFF-FX Implementation Report. c. Revised to accommodate results of the implementation and interoperability verification process. This is documented in draft-ietf-fax-tiff-fx-06.txt. d. The revised specification has successfully concluded Working Group Last Call for Draft Standard consideration. - WG Chair(s) submission of the latest draft (i.e. draft-ietf-fax-tiff-fx-06.txt) to the IESG for Draft Standard consideration is anticipated very soon. 3. TIFF-FX Extension status: - during the March 2000 Adelaide meeting, the WG concurred direction towards development and distribution of the first draft for the July - August 2000 meeting. - the extension is expected to address: a. ITU-T higher resolutions; b. ITU-T/ISO JBIG2 compression for black & white and color; c. ITU-T extension of MRC (Mixed Raster Content) to accommodate more than 3 layers. The MRC model optimizes image encoding when there are more than one image types within a page - such as text, color picture, business graphics, and colored text; d. Annotations (i.e. visible user information for document editing, non-visible tagging information for search and indexing, and image rendering information for image quality enhancement); e. accommodation of multiple profiles within a file; f. accommodation of more that one TIFF strip within an IFD associated with Foreground and Background layers of Profile M (MRC). I hope this helps. Lloyd > -----Original Message----- > From: MAEDA toru [mailto:maeda@ffm.canon.co.jp] > Sent: Thursday, May 18, 2000 3:41 AM > To: McIntyre, Lloyd; ietf-fax@imc.org > Subject: RE: New resolutions for TIFF-FX > > > Dear McIntyre-san, > > Thank you very much for clear explanation about my question. > I wish to have an up-to-date TIFF-FX standards than a fossil > Draft standard. > I will wait a new version of TIFF-FX RFC for 600 dpi by 21th century. > > Why don't you write tiff-fx-v2-01 now? > Do we have to wait TIFF-FX to Draft Standard status before > writing TIFF-FX > extension draft? > > > Regards > > Toru MAEDA > > > At 10:36 00/05/09 -0700, McIntyre, Lloyd wrote: > >Maeda-san, > >You are correct, in that T.30 has introduced a set of new > resolutions. > >These new resolutions, along with other enhancements (e.g. JBIG2, > >Annotations, more than 3 MRC layers, etc.) are being addressed in the > >planned TIFF-FX extension draft. The first TIFF-FX extension draft is > >scheduled for distribution prior to the next IETF meeting. > This new TIFF-FX > >extension will undergo the normal draft review process and > will then be > >submitted for Proposed Standard consideration. > > > >It is not appropriate to add the new resolutions to tiff-fx-04 since > >tiff-fx-04 reflects RFC2301 revisions that are necessary to > progress this > >version of TIFF-FX to Draft Standard status. > > > >I hope this clarifies the situation. > > > >Regards > > > >Lloyd > > > > > -----Original Message----- > > > From: MAEDA toru [mailto:maeda@ffm.canon.co.jp] > > > Sent: Tuesday, May 09, 2000 12:02 AM > > > To: ietf-fax@imc.org; Lloyd.McIntyre@pahv.xerox.com > > > Subject: New resolutions for TIFF-FX > > > > > > > > > Dear McIntyre-san, > > > > > > ITU-T added new resolutions for T.30. > > > tiff-fx-04 should also include those resolutions as follows. > > > > > > Black and White > > > 600x600 dpi > > > 1200x1200 > > > 300x600 > > > 400x800 > > > 600x1200 > > > > > > Colour and Gray Scale > > > 600x600 dpi > > > 1200x1200 > > > > > > Regards. > > > > > > Toru MAEDA > > > > > > ---------------------------- > > > CANON INC. > > > TORU MAEDA > > > Technology Advancement Div. 3 > > > 3-30-2,Shimomaruko Ohtaku,Tokyo,Japan > > > E-mail maeda@ffm.canon.co.jp > > > TEL +81-3-3757-9738 FAX +81-3-3757-8205 > > > ---------------------------- > > > > > ***************************** > Toru MAEDA > CANON Inc. OIP Technology Adv. 3 > ***************************** > From owner-ietf-fax@mail.imc.org Thu May 18 16:41:15 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 QAA12931 for ; Thu, 18 May 2000 16:41:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27644 for ietf-fax-bks; Thu, 18 May 2000 13:06:26 -0700 (PDT) Received: from lysithea.eastgw.xerox.com (root@lysithea.xerox.com [208.140.33.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27639 for ; Thu, 18 May 2000 13:06:24 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id QAA13403; Thu, 18 May 2000 16:12:44 -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 NAA13558; Thu, 18 May 2000 13:12:35 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2448.0) id ; Thu, 18 May 2000 13:12:36 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE067A2929@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , GK@acm.org, "McIntyre, Lloyd" Cc: Claudio Allocchio , James Rafferty , Hiroshi Tamura , ietf-fax@imc.org, Ned Freed Subject: RE: draft-ietf-fax-feature-schema-v2-01.txt,draft-ietf-fax-featur e-T30-mapping-03.txt Date: Thu, 18 May 2000 13:12:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA27640 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Patrik, This seems reasonable to me. Let us await Graham's concurrence. Lloyd > -----Original Message----- > From: Patrik Fältström [mailto:paf@swip.net] > Sent: Thursday, May 18, 2000 8:50 AM > To: GK@ACM.ORG; Lloyd.McIntyre@pahv.xerox.com > Cc: Claudio Allocchio; James Rafferty; Hiroshi Tamura; > ietf-fax@imc.org; > Ned Freed > Subject: > draft-ietf-fax-feature-schema-v2-01.txt,draft-ietf-fax-feature > -T30-mappi > ng-03.txt > > > In the discussions in the IESG about the documents mentioned in the > Subject, the following is a proposed note to the RFC-Editor to make > the changes stated. > > Please respond and let me know if this is ok or not. I.e. what is > needed is an explicit note stating that this document is obsoleting > RFC 2531. > > Patrik Faltstrom > Area Director, Applications Area > > ------------- > Dear RFC Editor > > Please replace in draft-ietf-fax-feature-schema-v2-01.txt: > 1. Introduction > > This document revises the content feature schema described in RFC > 2531, with clarifications to some of the feature tag descriptions > and addition of one new feature tag. > > with > > 1. Introduction > > This document revises the content feature schema described in RFC > 2531, with clarifications to some of the feature tag descriptions > and addition of one new feature tag. This document thus obsoletes > RFC 2531. > From owner-ietf-fax@mail.imc.org Fri May 19 05:24:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02008 for ; Fri, 19 May 2000 05:24:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA21838 for ietf-fax-bks; Fri, 19 May 2000 01:33:18 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA21834 for ; Fri, 19 May 2000 01:33:17 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id RAA29338; Fri, 19 May 2000 17:39:03 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id RAA00097; Fri, 19 May 2000 17:38:58 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 19 May 2000 08:39:00 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id RAA09346; Fri, 19 May 2000 17:38:54 +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 RAA09753; Fri, 19 May 2000 17:38:53 +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 RAA12513; Fri, 19 May 2000 17:36:02 +0900 (JST) Message-Id: <200005190839.AA00335@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Fri, 19 May 2000 17:39:57 +0900 To: Claudio Allocchio Cc: ietf-fax@imc.org Subject: Is the name of option "T33S" correct? 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, I want to test the interworking of addressing RFC2304 for promoting it to Draft Standard. But, the minutes of Adelade meeting below said that it is difficult to test for many implemetors because the machine must support T33. I think it is misunderstanding that the machine must support T33 to test the interworking. At 08.40 +0900 00-04-27, Hiroshi Tamura wrote: >- draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt > >Interworking is not enough, especially for /T33S issue. >T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress). >It is kind of an application profile. There are fax machines >that support T.30 SUB signal. But there are very few implementations >about T.33. A question was raised about how to validate >if two independent implementations interwork for addressing. >About this question, there was an opinion it is that gateways can >handle the specified address correctly. The option "/T33S=" does not support T33 because "#" character does not be allowed in the sub-addr field as below nevertheless T33 must support "#" character. And we can not write multiple subaddresses in the sub-addr field nevertheless T33 must support it with "#" character. So, I think that "/T33S=" means sub-address of T30. I would like to propose to change the name of t33-sep and T33S to t30-sep and T30S. > qualif-type1 = "/" t33-sep "=" sub-addr > > where > > t33-sep = "T33S" > > sub-addr = 1*( DIGIT ) >4.1 Multiple subaddresses > > 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. Best regards, Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Fri May 19 06:27:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02350 for ; Fri, 19 May 2000 06:27:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27031 for ietf-fax-bks; Fri, 19 May 2000 02:48:26 -0700 (PDT) Received: from canongate.in.canon.co.jp (canongate.in.canon.co.jp [150.61.4.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27026 for ; Fri, 19 May 2000 02:48:25 -0700 (PDT) Received: (from uucp@localhost) by canongate.in.canon.co.jp (3.7W) id SAA04917; Fri, 19 May 2000 18:54:49 +0900 (JST) Received: from (isvw1.cecn.canon.co.jp [150.61.8.152]) by canongate via smap (V2.1) id xma004884; Fri, 19 May 00 18:54:17 +0900 Received: from canongw.cecn.canon.co.jp (localhost [127.0.0.1]) by isvw1.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id SAA18087; Fri, 19 May 2000 18:54:16 +0900 (JST) Received: from ffmmail.ffm.canon.co.jp (localhost [127.0.0.1]) by canongw.cecn.canon.co.jp (8.9.3/3.7W) with ESMTP id SAA14540; Fri, 19 May 2000 18:54:16 +0900 (JST) Received: from 18209 ([172.22.33.253]) by ffmmail.ffm.canon.co.jp (8.7.4/3.4W3) with ESMTP id SAA18871; Fri, 19 May 2000 18:50:29 +0900 (JST) Message-Id: <4.2.0.58.J.20000519185100.00a74770@ffmmail.ffm.canon.co.jp> X-Sender: maeda@ffmpop1.ffm.canon.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 19 May 2000 18:59:15 +0900 To: "Toyoda, Kiyoshi" , Claudio Allocchio From: MAEDA toru Subject: Re: Is the name of option "T33S" correct? Cc: ietf-fax@imc.org In-Reply-To: <200005190839.AA00335@d23n59.rdmg.mgcs.mei.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Toyoda-san, Allocchio-san From the beginning of discussion, T33S means T.33, not SUB in T30. Also SUB in T.30 consists of "*" , "#" , space and numeric digits as defined in Table 3/T.30. Regards, Toru MAEDA At 17:39 00/05/19 +0900, Toyoda, Kiyoshi wrote: >Allocchio-san, > >I want to test the interworking of addressing RFC2304 >for promoting it to Draft Standard. >But, the minutes of Adelade meeting below said that it is >difficult to test for many implemetors because the machine >must support T33. I think it is misunderstanding that the >machine must support T33 to test the interworking. > > >At 08.40 +0900 00-04-27, Hiroshi Tamura wrote: > >- draft-ietf-fax-faxaddr-v2-00.txt, draft-ietf-fax-minaddr-v2-00.txt > > > >Interworking is not enough, especially for /T33S issue. > >T33S conforms to ITU-T T.33(Facsimile routing utilizing the subaddress). > >It is kind of an application profile. There are fax machines > >that support T.30 SUB signal. But there are very few implementations > >about T.33. A question was raised about how to validate > >if two independent implementations interwork for addressing. > >About this question, there was an opinion it is that gateways can > >handle the specified address correctly. > > >The option "/T33S=" does not support T33 because "#" character >does not be allowed in the sub-addr field as below nevertheless >T33 must support "#" character. And we can not write multiple >subaddresses in the sub-addr field nevertheless T33 must support >it with "#" character. So, I think that "/T33S=" means sub-address >of T30. > >I would like to propose to change the name of t33-sep and T33S >to t30-sep and T30S. > > > > qualif-type1 = "/" t33-sep "=" sub-addr > > > > where > > > > t33-sep = "T33S" > > > > sub-addr = 1*( DIGIT ) > > > >4.1 Multiple subaddresses > > > > 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. > >Best regards, > > > >Kiyoshi Toyoda ***************************** Toru MAEDA CANON Inc. OIP Technology Adv. 3 ***************************** From owner-ietf-fax@mail.imc.org Fri May 19 10:38:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05793 for ; Fri, 19 May 2000 10:38:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA10426 for ietf-fax-bks; Fri, 19 May 2000 06:44:05 -0700 (PDT) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10422 for ; Fri, 19 May 2000 06:44:03 -0700 (PDT) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id JAA10564; Fri, 19 May 2000 09:25:05 -0400 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id ; Fri, 19 May 2000 09:41:51 -0400 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F029DD3FF@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'MAEDA toru'" , "Toyoda, Kiyoshi" , Claudio Allocchio Cc: ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? Date: Fri, 19 May 2000 09:41:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To all - ITU-T T.33 is basically a profile which describes the use of the T.30 subaddress in some particular applications, such as use of extensions that go beyond phone numbers. T.33 does refer to all of the characters that are defined in the T.30 subaddress, and just explains how to use them in certain situations, particularly the numeric, # and SPACE characters. As for this discussion, the decision to use the terminology /T33S was made a long time ago after a great deal of mailing list discussion. In the context of RFC 2303 and 2304, only a single subaddress is supported per mailing address and only the numeric characters would be used, since it is being used to define a single extension. For translating this single extension for use in the T.30 SUB, there is no need to use the optional # in the subaddress and if you read T.33, you will see that the # WOULD NOT be placed in the T.30 SUB field for this case. There is absolutely no reason that I can see to re-open the discussion and change the name of the fields, since this matter was discussed and decided a long time ago. Some additional clarification in response to Toyoda-san's questions follow: > -----Original Message----- > From: MAEDA toru [mailto:maeda@ffm.canon.co.jp] > Sent: Friday, May 19, 2000 5:59 AM > To: Toyoda, Kiyoshi; Claudio Allocchio > Cc: ietf-fax@imc.org > Subject: Re: Is the name of option "T33S" correct? > > > Toyoda-san, Allocchio-san > > From the beginning of discussion, T33S means T.33, not SUB in T30. > Also SUB in T.30 consists of "*" , "#" , space and numeric digits as > defined in Table 3/T.30. > > Regards, > > Toru MAEDA > > > At 17:39 00/05/19 +0900, Toyoda, Kiyoshi wrote: > >Allocchio-san, > > > >I want to test the interworking of addressing RFC2304 > >for promoting it to Draft Standard. > >But, the minutes of Adelade meeting below said that it is > >difficult to test for many implemetors because the machine > >must support T33. I think it is misunderstanding that the > >machine must support T33 to test the interworking. > > Actually, if a machine supports either T.30 or T.33, the interworking should be fine, for the reasons noted below (i.e. the rules are really the same in T.30 and T.33 for the single extension case supported in the RFC 2303/4). > > > >At 08.40 +0900 00-04-27, Hiroshi Tamura wrote: > > >- draft-ietf-fax-faxaddr-v2-00.txt, > draft-ietf-fax-minaddr-v2-00.txt > > > > > >Interworking is not enough, especially for /T33S issue. > > >T33S conforms to ITU-T T.33(Facsimile routing utilizing > the subaddress). > > >It is kind of an application profile. There are fax machines > > >that support T.30 SUB signal. But there are very few > implementations > > >about T.33. A question was raised about how to validate > > >if two independent implementations interwork for addressing. > > >About this question, there was an opinion it is that gateways can > > >handle the specified address correctly. > > As noted, for this case, either T.30 or T.33 support should be OK to test interworking. The exact handling of the translation from a sub-addr element to a T.30 device with SUB support would seem to be a gateway matter, although the rules for placement of the numeric characters are defined in T.30 and more precisely described (regarding bit orders, etc.) in T.33. > > > >The option "/T33S=" does not support T33 because "#" character > >does not be allowed in the sub-addr field as below nevertheless > >T33 must support "#" character. And we can not write multiple > >subaddresses in the sub-addr field nevertheless T33 must support > >it with "#" character. So, I think that "/T33S=" means sub-address > >of T30. > > As I noted above, this is an incorrect interpretation of T.33. For the case of a single extension (which is the only case supported in "sub-addr", if you then put this into a SUB field per the T.33 rules, you would simply place the numeric characters in the right-most octets of the T.30 sub field, with the remaining 20 characters being padded by spaces. This is intentionally consistent with the same set of rules that are defined in T.30 (that is, the SUB characters are placed in the right most octets, with padding on the left with Spaces.) There is no use of the # character in this case. So, NO, T.33 does not require use of the # for this case. Therefore, there seems to be total consistency between T.33 and T.30 rules for the translation of the single extension which is permitted in the "sub-addr" element. > >I would like to propose to change the name of t33-sep and T33S > >to t30-sep and T30S. > > > > > > > qualif-type1 = "/" t33-sep "=" sub-addr > > > > > > where > > > > > > t33-sep = "T33S" > > > > > > sub-addr = 1*( DIGIT ) > > Since the rules for T.30 and T.33 are exactly the same for this case, there is no value in making the change. By the way, T.30 is a normative reference within T.33, so T.33 incorporates support for the T.30 SUB by reference. > > > > >4.1 Multiple subaddresses > > > > > > 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. > > Yes, so as a result, there is only use of a single subaddress extension per mail address in RFC 2303/4. Therefore, the # character of T.33, which may be used to separate multiple subaddresses in a T.30 subaddress (per T.33), is never used for "sub-addr". Hopefully this explanation is helpful. So, if there is an attempt to do interworking between RFC 2305 devices and T.30 devices which support SUB for sending and receiving cases, this should meet the interworking requirements. > >Best regards, > > > > > > > >Kiyoshi Toyoda > > ***************************** > Toru MAEDA > CANON Inc. OIP Technology Adv. 3 > ***************************** > Best Regards, James * ----------------------------------- James Rafferty Senior Product Manager, IP Telephony Brooktrout Technology 410 First Avenue Needham, MA 02494 USA Phone: +1-781-433-9462 Fax: 781-433-9268 Email/Internet Fax: jraff@brooktrout.com www.brooktrout.com Your Hook into the New Network(SM) From owner-ietf-fax@mail.imc.org Sat May 20 13:47:04 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 NAA00513 for ; Sat, 20 May 2000 13:47:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23834 for ietf-fax-bks; Sat, 20 May 2000 10:04:04 -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 KAA23830 for ; Sat, 20 May 2000 10:04:02 -0700 (PDT) Received: from GK-VAIO.Dial.pipex.com (userat58.uk.uudial.com [62.188.137.161]) by hose.pipex.net (Postfix) with ESMTP id 28C04454B; Sat, 20 May 2000 18:10:49 +0100 (BST) Message-Id: <4.3.1.2.20000520141059.020baf00@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 20 May 2000 14:13:08 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Graham Klyne Subject: Re: draft-ietf-fax-feature-schema-v2-01.txt, draft-ietf-fax-feature-T30-mapping-03.txt Cc: Lloyd.McIntyre@pahv.xerox.com, Claudio Allocchio , James Rafferty , Hiroshi Tamura , ietf-fax@imc.org, Ned Freed In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA23831 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Parik, I think that's absolutely right. #g -- At 05:50 PM 5/18/00 +0200, Patrik Fältström wrote: >In the discussions in the IESG about the documents mentioned in the >Subject, the following is a proposed note to the RFC-Editor to make the >changes stated. > >Please respond and let me know if this is ok or not. I.e. what is needed >is an explicit note stating that this document is obsoleting RFC 2531. > > Patrik Faltstrom > Area Director, Applications Area > >------------- >Dear RFC Editor > >Please replace in draft-ietf-fax-feature-schema-v2-01.txt: >1. Introduction > > This document revises the content feature schema described in RFC > 2531, with clarifications to some of the feature tag descriptions > and addition of one new feature tag. > >with > >1. Introduction > > This document revises the content feature schema described in RFC > 2531, with clarifications to some of the feature tag descriptions > and addition of one new feature tag. This document thus obsoletes > RFC 2531. ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-fax@mail.imc.org Sun May 21 06:26:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06573 for ; Sun, 21 May 2000 06:26:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA18348 for ietf-fax-bks; Sun, 21 May 2000 02:48:13 -0700 (PDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18343 for ; Sun, 21 May 2000 02:48:11 -0700 (PDT) Received: from [192.168.110.9] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id LAA17463; Sun, 21 May 2000 11:54:33 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: <4.3.1.2.20000520141059.020baf00@pop.dial.pipex.com> References: <4.3.1.2.20000520141059.020baf00@pop.dial.pipex.com> Date: Sun, 21 May 2000 08:53:03 +0200 To: Graham Klyne From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-fax-feature-schema-v2-01.txt, draft-ietf-fax-feature-T30-mapping-03.txt Cc: Lloyd.McIntyre@pahv.xerox.com, Claudio Allocchio , James Rafferty , Hiroshi Tamura , ietf-fax@imc.org, Ned Freed Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14.13 +0100 00-05-20, Graham Klyne wrote: >I think that's absolutely right. Thanks, it is now taken care of. paf From owner-ietf-fax@mail.imc.org Sun May 21 22:18:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12719 for ; Sun, 21 May 2000 22:18:11 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA16511 for ietf-fax-bks; Sun, 21 May 2000 18:31:49 -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 SAA16443 for ; Sun, 21 May 2000 18:31:36 -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 KAA06190; Mon, 22 May 2000 10:37:13 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id KAA23978; Mon, 22 May 2000 10:37:12 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id KAA06045; Mon, 22 May 2000 10:37:17 +0900 (JST) To: jraff@needham.BROOKTROUT.com, maeda@ffm.canon.co.jp, ktoyoda@rdmg.mgcs.mei.co.jp, Claudio.Allocchio@elettra.trieste.it Cc: ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F029DD3FF@nhmail1.admin.brooktrout.com> References: <11740AB18BD4D111BE8F00A0C9B8044F029DD3FF@nhmail1.admin.brooktrout.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: <20000522104254H.tamura@toda.ricoh.co.jp> Date: Mon, 22 May 2000 10:42:54 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 79 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rafferty-san, Thank you for your explnation. I understand what you are saying. But, for implementers who read RFC2303/2304 and T.33(not T.30), I think some clarifications may be necessary for RFC2303/2304. According to /T33S in RFC2303/2304, we cannot use "#". In T.33, "#" is an important element. I think this causes misunderstandings. Someone may think, "If we support /T33S, all features in T.33 must be supported." I fould this is wrong from your explanation. They will find it if they CAREFULLY read RFC2303/2304 and T.33. On the conditions that /T33S remains as it is, can we add some additional descriptions in these RFCs ? For example, "In this case, /T33S means T.30 SUB frame, although digits are only used." (I think Better sentences are necessary. This example is very POOR.) For being Draft Standard, we need interworking. For interworking test, I think it is better to have clarifications about it. T.30 SUB can be implemented more easily than "T.33 Full implementation" > In the context of RFC 2303 and 2304, only a single subaddress is supported > per mailing address and only the numeric characters would be used, since > it is being used to define a single extension. > > For translating this single extension for use in the T.30 SUB, there is no > need to use the optional # in the subaddress and if you read T.33, you will > see that > the # WOULD NOT be placed in the T.30 SUB field for this case. OK. > > >I want to test the interworking of addressing RFC2304 > > >for promoting it to Draft Standard. > > >But, the minutes of Adelade meeting below said that it is > > >difficult to test for many implemetors because the machine > > >must support T33. I think it is misunderstanding that the > > >machine must support T33 to test the interworking. > > > > Actually, if a machine supports either T.30 or T.33, the > interworking should be fine, for the reasons noted below (i.e. > the rules are really the same in T.30 and T.33 for the single extension case > supported in the RFC 2303/4). So, considering this, I think we can add something. > So, NO, T.33 does not require use of the # for this case. Therefore, there > seems to be total consistency between T.33 and T.30 rules for the > translation of the single extension which is permitted in the "sub-addr" > element. This is very important information for interworking. Any suggestions or comments are welcome. Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Sun May 21 23:04:20 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 XAA13892 for ; Sun, 21 May 2000 23:04:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA26175 for ietf-fax-bks; Sun, 21 May 2000 19:30:17 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26166 for ; Sun, 21 May 2000 19:30:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA29320; Sun, 21 May 2000 19:34:02 -0700 (PDT) Date: Sun, 21 May 2000 19:34:02 -0700 (PDT) From: Dan Wing To: Hiroshi Tamura cc: jraff@needham.BROOKTROUT.com, maeda@ffm.canon.co.jp, ktoyoda@rdmg.mgcs.mei.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? In-Reply-To: <20000522104254H.tamura@toda.ricoh.co.jp> Message-ID: <0005211926030.28896-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree the text in RFC2304 could be clearer regarding "#". "#" appears to only be useful for multiple subaddresses (reference T.33, 7/96 edition, section 4.2). Section 4.1 of RFC2304 describes how multiple subaddresses should be handled. I recommend the "Note" in section 2 of RFC2304, which currently reads: Note: See section 4.1 in case multiple sub-addr per fax-mbox need to be specified. be changed to read: Note: In T.33, the "#" character is used to specify multiple subaddresses. However, only digits are permitted in the field defined by this document. Refer to section 4.1 in case multiple per need to be specified. -Dan Wing On Mon, 22 May 2000 10:42 +0900, Hiroshi Tamura wrote: > Rafferty-san, > > Thank you for your explnation. > > I understand what you are saying. > > But, for implementers who read RFC2303/2304 and T.33(not T.30), > I think some clarifications may be necessary for RFC2303/2304. > > According to /T33S in RFC2303/2304, we cannot use "#". > In T.33, "#" is an important element. > I think this causes misunderstandings. > > Someone may think, "If we support /T33S, all features in T.33 > must be supported." > > I fould this is wrong from your explanation. > They will find it if they CAREFULLY read RFC2303/2304 and T.33. > > On the conditions that /T33S remains as it is, > can we add some additional descriptions in these RFCs ? > > For example, > "In this case, /T33S means T.30 SUB frame, although > digits are only used." > > (I think Better sentences are necessary. This example > is very POOR.) > > For being Draft Standard, we need interworking. > For interworking test, I think it is better to have clarifications > about it. T.30 SUB can be implemented more easily than > "T.33 Full implementation" > > > > > In the context of RFC 2303 and 2304, only a single subaddress is supported > > per mailing address and only the numeric characters would be used, since > > it is being used to define a single extension. > > > > For translating this single extension for use in the T.30 SUB, there is no > > need to use the optional # in the subaddress and if you read T.33, you will > > see that > > the # WOULD NOT be placed in the T.30 SUB field for this case. > > OK. > > > > > > >I want to test the interworking of addressing RFC2304 > > > >for promoting it to Draft Standard. > > > >But, the minutes of Adelade meeting below said that it is > > > >difficult to test for many implemetors because the machine > > > >must support T33. I think it is misunderstanding that the > > > >machine must support T33 to test the interworking. > > > > > > Actually, if a machine supports either T.30 or T.33, the > > interworking should be fine, for the reasons noted below (i.e. > > the rules are really the same in T.30 and T.33 for the single extension case > > supported in the RFC 2303/4). > > So, considering this, I think we can add something. > > > > > So, NO, T.33 does not require use of the # for this case. Therefore, there > > seems to be total consistency between T.33 and T.30 rules for the > > translation of the single extension which is permitted in the "sub-addr" > > element. > > This is very important information for interworking. > > Any suggestions or comments are welcome. > > Regards, > -- > Hiroshi Tamura, Ricoh Company, LTD. > E-mail: tamura@toda.ricoh.co.jp > > From owner-ietf-fax@mail.imc.org Mon May 22 03:19:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27248 for ; Mon, 22 May 2000 03:18:59 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA09431 for ietf-fax-bks; Sun, 21 May 2000 23:34:55 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09427 for ; Sun, 21 May 2000 23:34:53 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id PAA00393; Mon, 22 May 2000 15:40:14 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id PAA14871; Mon, 22 May 2000 15:39:57 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 22 May 2000 06:39:59 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id PAA08714; Mon, 22 May 2000 15:39:53 +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 PAA04324; Mon, 22 May 2000 15:39:52 +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 PAA04699; Mon, 22 May 2000 15:36:53 +0900 (JST) Message-Id: <200005220641.AA00338@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Mon, 22 May 2000 15:41:02 +0900 To: Dan Wing Cc: Hiroshi Tamura , jraff@needham.BROOKTROUT.com, maeda@ffm.canon.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: Re: Is the name of option "T33S" correct? In-Reply-To: <0005211926030.28896-100000@omega.cisco.com> References: <0005211926030.28896-100000@omega.cisco.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rafferty-san, Thank you for your explanation. Your explantion will be helpful for implementors. I won't say about changing the name of /T33S anymore. But, I agree the recommendation which Wing-san said below. It will clarify the meaning of /T33S. Best Regards, Dan Wing wrote: >I agree the text in RFC2304 could be clearer regarding "#". > >"#" appears to only be useful for multiple subaddresses (reference T.33, >7/96 edition, section 4.2). Section 4.1 of RFC2304 describes how multiple >subaddresses should be handled. > >I recommend the "Note" in section 2 of RFC2304, which currently reads: > > Note: > See section 4.1 in case multiple sub-addr per fax-mbox need to be > specified. > >be changed to read: > > Note: > In T.33, the "#" character is used to specify multiple subaddresses. > However, only digits are permitted in the field defined > by this document. Refer to section 4.1 in case multiple > per need to be specified. > >-Dan Wing > >On Mon, 22 May 2000 10:42 +0900, Hiroshi Tamura wrote: > >> Rafferty-san, >> >> Thank you for your explnation. >> >> I understand what you are saying. >> >> But, for implementers who read RFC2303/2304 and T.33(not T.30), >> I think some clarifications may be necessary for RFC2303/2304. >> >> According to /T33S in RFC2303/2304, we cannot use "#". >> In T.33, "#" is an important element. >> I think this causes misunderstandings. >> >> Someone may think, "If we support /T33S, all features in T.33 >> must be supported." >> >> I fould this is wrong from your explanation. >> They will find it if they CAREFULLY read RFC2303/2304 and T.33. >> >> On the conditions that /T33S remains as it is, >> can we add some additional descriptions in these RFCs ? >> >> For example, >> "In this case, /T33S means T.30 SUB frame, although >> digits are only used." >> >> (I think Better sentences are necessary. This example >> is very POOR.) >> >> For being Draft Standard, we need interworking. >> For interworking test, I think it is better to have clarifications >> about it. T.30 SUB can be implemented more easily than >> "T.33 Full implementation" >> >> >> >> > In the context of RFC 2303 and 2304, only a single subaddress is supported >> > per mailing address and only the numeric characters would be used, since >> > it is being used to define a single extension. >> > >> > For translating this single extension for use in the T.30 SUB, there is no >> > need to use the optional # in the subaddress and if you read T.33, you will >> > see that >> > the # WOULD NOT be placed in the T.30 SUB field for this case. >> >> OK. >> >> >> >> > > >I want to test the interworking of addressing RFC2304 >> > > >for promoting it to Draft Standard. >> > > >But, the minutes of Adelade meeting below said that it is >> > > >difficult to test for many implemetors because the machine >> > > >must support T33. I think it is misunderstanding that the >> > > >machine must support T33 to test the interworking. >> > > > >> > Actually, if a machine supports either T.30 or T.33, the >> > interworking should be fine, for the reasons noted below (i.e. >> > the rules are really the same in T.30 and T.33 for the single extension case >> > supported in the RFC 2303/4). >> >> So, considering this, I think we can add something. >> >> >> >> > So, NO, T.33 does not require use of the # for this case. Therefore, there >> > seems to be total consistency between T.33 and T.30 rules for the >> > translation of the single extension which is permitted in the "sub-addr" >> > element. >> >> This is very important information for interworking. >> >> Any suggestions or comments are welcome. >> >> Regards, >> -- >> Hiroshi Tamura, Ricoh Company, LTD. >> E-mail: tamura@toda.ricoh.co.jp >> >> > > Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Mon May 22 10:45:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03173 for ; Mon, 22 May 2000 10:45:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA22007 for ietf-fax-bks; Mon, 22 May 2000 07:14:33 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22002 for ; Mon, 22 May 2000 07:14:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA03744; Mon, 22 May 2000 07:18:08 -0700 (PDT) Date: Mon, 22 May 2000 07:18:08 -0700 (PDT) From: Dan Wing To: James Rafferty cc: "'Toyoda, Kiyoshi'" , Hiroshi Tamura , maeda@ffm.canon.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F029DD40D@nhmail1.admin.brooktrout.com> Message-ID: <0005220711530.1511-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 22 May 2000 10:06 -0400, James Rafferty wrote: > So, the Note could be revised to clarify the point that the rules for > T.30 and T.33 subaddresses are identical for the case where a single > address (extension) is contained in the T.30 subaddress. > > Thus, the note could read: > > "Note: > In T.33, the "#" character is used to specify multiple subaddresses. > However, only digits are permitted in the field defined > by this document. Refer to section 4.1 in case multiple > per need to be specified. For the case of a single > subaddress, > such as will be contained in the field, gateway implementors > should be aware that the rules for placement of a > single numeric subaddress in the T.30 Subaddress field are consistent > between T.33 and T.30 (i.e only numeric characters > are used for addresses and SPACE is used for padding). " I'm worried about talking about SPACE, as it isn't legal in . How about this. It takes the above text in a different order with the common case (single subaddress) first, and the less common case (multiple subaddress) second. Notes: For the case of a single subaddress, only numbers are allowed in which is consistent with T.30, T.33, and this document. While T.33 uses SPACE to pad its field, padding isn't necessary in the field defined by this document. For the case of multiple subaddresses, T.33 specifies the "#" character should be used to specify multiple subaddreses. However, only digits are permitted in the field defined by this document. Refer to section 4.1 in case multiple per per need to be specified. -Dan Wing From owner-ietf-fax@mail.imc.org Mon May 22 10:45:52 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 KAA03185 for ; Mon, 22 May 2000 10:45:51 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA21628 for ietf-fax-bks; Mon, 22 May 2000 07:03:47 -0700 (PDT) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21624 for ; Mon, 22 May 2000 07:03:45 -0700 (PDT) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id JAA15681; Mon, 22 May 2000 09:49:39 -0400 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id ; Mon, 22 May 2000 10:06:51 -0400 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F029DD40D@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'Toyoda, Kiyoshi'" , Dan Wing Cc: Hiroshi Tamura , maeda@ffm.canon.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? Date: Mon, 22 May 2000 10:06:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Toyoda-san, Tamura-san, Yes, I agree with Tamura-san's point that some additional clarification about the # can be useful. The point that the behavior of the T.30 SUB and T.33 are the same for the case of a single extension is probably also a useful clarification for implementors. None of these are technical changes, but clarifications for implementors, so it would not hurt (should actually help)the progression to draft standard. I think Dan's text is a good starting point (see below for some proposed additions to this same note). Here are some ideas on some clarifications to the draft text in the ID ietf-fax-minaddrfax-00.txt: Section 2 Change " In the syntax for the fax address a qualif-type1 element has been defined for support of T.33 subaddresses (see section 2 of [13]). The use of this element is OPTIONAL, but compliant implementations MUST be able to support and correctly interpret it when present. Its definition is as follows: qualif-type1 = "/" t33-sep "=" sub-addr" so that the first sentence reads: "In the syntax for the fax address a qualif-type1 element has been defined for support of T.30/T.33 subaddresses (see section 2 of [13])." Also, perhaps add on to Dan's note revision as follows: > Dan Wing wrote: > >I agree the text in RFC2304 could be clearer regarding "#". > > > >"#" appears to only be useful for multiple subaddresses > (reference T.33, > >7/96 edition, section 4.2). Section 4.1 of RFC2304 > describes how multiple > >subaddresses should be handled. > > > >I recommend the "Note" in section 2 of RFC2304, which > currently reads: > > > > Note: > > See section 4.1 in case multiple sub-addr per fax-mbox > need to be > > specified. > > > >be changed to read: > > > > Note: > > In T.33, the "#" character is used to specify multiple > subaddresses. > > However, only digits are permitted in the > field defined > > by this document. Refer to section 4.1 in case > multiple > > per need to be specified. > > So, the Note could be revised to clarify the point that the rules for T.30 and T.33 subaddresses are identical for the case where a single address (extension) is contained in the T.30 subaddress. Thus, the note could read: "Note: In T.33, the "#" character is used to specify multiple subaddresses. However, only digits are permitted in the field defined by this document. Refer to section 4.1 in case multiple per need to be specified. For the case of a single subaddress, such as will be contained in the field, gateway implementors should be aware that the rules for placement of a single numeric subaddress in the T.30 Subaddress field are consistent between T.33 and T.30 (i.e only numeric characters are used for addresses and SPACE is used for padding). " James From owner-ietf-fax@mail.imc.org Mon May 22 10:59:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03345 for ; Mon, 22 May 2000 10:59:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA22355 for ietf-fax-bks; Mon, 22 May 2000 07:27:47 -0700 (PDT) Received: from Brooktrout.Com (truite.brooktrout.com [204.176.74.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22351 for ; Mon, 22 May 2000 07:27:45 -0700 (PDT) Received: from nhmail1.admin.brooktrout.com (nhmail1.admin.brooktrout.com [204.176.75.8]) by Brooktrout.Com (8.9.3/8.9.3/BTI-2.1) with ESMTP id KAA15787; Mon, 22 May 2000 10:10:42 -0400 Received: by nhmail1.admin.brooktrout.com with Internet Mail Service (5.5.2448.0) id ; Mon, 22 May 2000 10:27:54 -0400 Message-ID: <11740AB18BD4D111BE8F00A0C9B8044F029DD411@nhmail1.admin.brooktrout.com> From: James Rafferty To: "'Dan Wing'" , James Rafferty Cc: "'Toyoda, Kiyoshi'" , Hiroshi Tamura , maeda@ffm.canon.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? Date: Mon, 22 May 2000 10:27:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Yes, that's an improvement, but since both T.30 and T.33 use the SPACE, I suggest the following minor tweak: Notes: For the case of a single subaddress, only numbers are allowed in which is consistent with T.30, T.33, and this document. While T.30 and T.33 use SPACE to pad its field, padding isn't necessary in the field defined by this document. For the case of multiple subaddresses, T.33 specifies the "#" character should be used to specify multiple subaddreses. However, only digits are permitted in the field defined by this document. Refer to section 4.1 in case multiple per per need to be specified. On the whole, I think this makes the key point about T.30/T.33 consistency for single subaddresses and how it all ties to this document. James > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, May 22, 2000 10:18 AM > To: James Rafferty > Cc: 'Toyoda, Kiyoshi'; Hiroshi Tamura; maeda@ffm.canon.co.jp; > Claudio.Allocchio@elettra.trieste.it; ietf-fax@imc.org > Subject: RE: Is the name of option "T33S" correct? > > > On Mon, 22 May 2000 10:06 -0400, James Rafferty wrote: > > > So, the Note could be revised to clarify the point that the > rules for > > T.30 and T.33 subaddresses are identical for the case where a single > > address (extension) is contained in the T.30 subaddress. > > > > Thus, the note could read: > > > > "Note: > > In T.33, the "#" character is used to specify multiple > subaddresses. > > However, only digits are permitted in the > field defined > > by this document. Refer to section 4.1 in case > multiple > > per need to be specified. For the case of a single > > subaddress, > > such as will be contained in the field, > gateway implementors > > should be aware that the rules for placement of a > > single numeric subaddress in the T.30 Subaddress > field are consistent > > between T.33 and T.30 (i.e only numeric characters > > are used for addresses and SPACE is used for padding). " > > I'm worried about talking about SPACE, as it isn't legal in > . > > How about this. It takes the above text in a different order with the > common case (single subaddress) first, and the less common > case (multiple > subaddress) second. > > > Notes: > > For the case of a single subaddress, only numbers are allowed in > which is consistent with T.30, T.33, and this document. > While T.33 uses SPACE to pad its field, padding isn't > necessary in the > field defined by this document. > > For the case of multiple subaddresses, T.33 specifies the "#" > character should be used to specify multiple subaddreses. > However, > only digits are permitted in the field defined by this > document. Refer to section 4.1 in case multiple per > per need to be specified. > > -Dan Wing > > From owner-ietf-fax@mail.imc.org Mon May 22 11:05:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03454 for ; Mon, 22 May 2000 11:05:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA22447 for ietf-fax-bks; Mon, 22 May 2000 07:31:36 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22443 for ; Mon, 22 May 2000 07:31:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA04790; Mon, 22 May 2000 07:33:33 -0700 (PDT) Date: Mon, 22 May 2000 07:33:33 -0700 (PDT) From: Dan Wing To: James Rafferty cc: "'Toyoda, Kiyoshi'" , Hiroshi Tamura , maeda@ffm.canon.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: RE: Is the name of option "T33S" correct? In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F029DD411@nhmail1.admin.brooktrout.com> Message-ID: <0005220733260.1511-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looks perfect. Thanks. -Dan Wing On Mon, 22 May 2000 10:27 -0400, James Rafferty wrote: > Dan, > > Yes, that's an improvement, but since both T.30 and T.33 use the SPACE, I > suggest > the following minor tweak: > > Notes: > > For the case of a single subaddress, only numbers are allowed in > which is consistent with T.30, T.33, and this document. > While T.30 and T.33 use SPACE to pad its field, padding isn't necessary > in the > field defined by this document. > > For the case of multiple subaddresses, T.33 specifies the "#" > character should be used to specify multiple subaddreses. However, > only digits are permitted in the field defined by this > document. Refer to section 4.1 in case multiple per > per need to be specified. > > On the whole, I think this makes the key point about T.30/T.33 consistency > for > single subaddresses and how it all ties to this document. > > James > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Monday, May 22, 2000 10:18 AM > > To: James Rafferty > > Cc: 'Toyoda, Kiyoshi'; Hiroshi Tamura; maeda@ffm.canon.co.jp; > > Claudio.Allocchio@elettra.trieste.it; ietf-fax@imc.org > > Subject: RE: Is the name of option "T33S" correct? > > > > > > On Mon, 22 May 2000 10:06 -0400, James Rafferty wrote: > > > > > So, the Note could be revised to clarify the point that the > > rules for > > > T.30 and T.33 subaddresses are identical for the case where a single > > > address (extension) is contained in the T.30 subaddress. > > > > > > Thus, the note could read: > > > > > > "Note: > > > In T.33, the "#" character is used to specify multiple > > subaddresses. > > > However, only digits are permitted in the > > field defined > > > by this document. Refer to section 4.1 in case > > multiple > > > per need to be specified. For the case of a single > > > subaddress, > > > such as will be contained in the field, > > gateway implementors > > > should be aware that the rules for placement of a > > > single numeric subaddress in the T.30 Subaddress > > field are consistent > > > between T.33 and T.30 (i.e only numeric characters > > > are used for addresses and SPACE is used for padding). " > > > > I'm worried about talking about SPACE, as it isn't legal in > > . > > > > How about this. It takes the above text in a different order with the > > common case (single subaddress) first, and the less common > > case (multiple > > subaddress) second. > > > > > > Notes: > > > > For the case of a single subaddress, only numbers are allowed in > > which is consistent with T.30, T.33, and this document. > > While T.33 uses SPACE to pad its field, padding isn't > > necessary in the > > field defined by this document. > > > > For the case of multiple subaddresses, T.33 specifies the "#" > > character should be used to specify multiple subaddreses. > > However, > > only digits are permitted in the field defined by this > > document. Refer to section 4.1 in case multiple per > > per need to be specified. > > > > -Dan Wing > > > > > From owner-ietf-fax@mail.imc.org Wed May 24 02:26:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29962 for ; Wed, 24 May 2000 02:26:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA01778 for ietf-fax-bks; Tue, 23 May 2000 22:47:55 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01757 for ; Tue, 23 May 2000 22:47:43 -0700 (PDT) Received: by bulls.mei.co.jp (8.9.3/3.7W) with ESMTP id OAA10230; Wed, 24 May 2000 14:53:27 +0900 (JST) Received: by dodgers.mei.co.jp (8.9.1/3.7W) with SMTP id OAA02928; Wed, 24 May 2000 14:53:17 +0900 (JST) Received: from [133.185.137.6] by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 24 May 2000 05:53:18 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0.mgcs.mei.co.jp (8.9.3/3.7W-HUB) with ESMTP id OAA16337; Wed, 24 May 2000 14:53:12 +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 OAA11728; Wed, 24 May 2000 14:53:11 +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 OAA22595; Wed, 24 May 2000 14:50:08 +0900 (JST) Message-Id: <200005240554.AA00346@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Wed, 24 May 2000 14:54:25 +0900 To: James Rafferty Cc: "'Dan Wing'" , James Rafferty , Hiroshi Tamura , maeda@ffm.canon.co.jp, Claudio.Allocchio@elettra.trieste.it, ietf-fax@imc.org Subject: Re: Is the name of option "T33S" correct? In-Reply-To: <11740AB18BD4D111BE8F00A0C9B8044F029DD411@nhmail1.admin.brooktrout.com> References: <11740AB18BD4D111BE8F00A0C9B8044F029DD411@nhmail1.admin.brooktrout.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rafferty-san Dan-san, Thank you for your note. It will help implementors to have better understanding about /T33 option and I believe it promotes interworking test of RFC2304. James Rafferty wrote: >Dan, > >Yes, that's an improvement, but since both T.30 and T.33 use the SPACE, I >suggest >the following minor tweak: > >Notes: > > For the case of a single subaddress, only numbers are allowed in > which is consistent with T.30, T.33, and this document. > While T.30 and T.33 use SPACE to pad its field, padding isn't necessary >in the > field defined by this document. > > For the case of multiple subaddresses, T.33 specifies the "#" > character should be used to specify multiple subaddreses. However, > only digits are permitted in the field defined by this > document. Refer to section 4.1 in case multiple per > per need to be specified. > >On the whole, I think this makes the key point about T.30/T.33 consistency >for >single subaddresses and how it all ties to this document. > >James > > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Monday, May 22, 2000 10:18 AM >> To: James Rafferty >> Cc: 'Toyoda, Kiyoshi'; Hiroshi Tamura; maeda@ffm.canon.co.jp; >> Claudio.Allocchio@elettra.trieste.it; ietf-fax@imc.org >> Subject: RE: Is the name of option "T33S" correct? >> >> >> On Mon, 22 May 2000 10:06 -0400, James Rafferty wrote: >> >> > So, the Note could be revised to clarify the point that the >> rules for >> > T.30 and T.33 subaddresses are identical for the case where a single >> > address (extension) is contained in the T.30 subaddress. >> > >> > Thus, the note could read: >> > >> > "Note: >> > In T.33, the "#" character is used to specify multiple >> subaddresses. >> > However, only digits are permitted in the >> field defined >> > by this document. Refer to section 4.1 in case >> multiple >> > per need to be specified. For the case of a single >> > subaddress, >> > such as will be contained in the field, >> gateway implementors >> > should be aware that the rules for placement of a >> > single numeric subaddress in the T.30 Subaddress >> field are consistent >> > between T.33 and T.30 (i.e only numeric characters >> > are used for addresses and SPACE is used for padding). " >> >> I'm worried about talking about SPACE, as it isn't legal in >> . >> >> How about this. It takes the above text in a different order with the >> common case (single subaddress) first, and the less common >> case (multiple >> subaddress) second. >> >> >> Notes: >> >> For the case of a single subaddress, only numbers are allowed in >> which is consistent with T.30, T.33, and this document. >> While T.33 uses SPACE to pad its field, padding isn't >> necessary in the >> field defined by this document. >> >> For the case of multiple subaddresses, T.33 specifies the "#" >> character should be used to specify multiple subaddreses. >> However, >> only digits are permitted in the field defined by this >> document. Refer to section 4.1 in case multiple per >> per need to be specified. >> >> -Dan Wing >> >> > Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Mon May 29 07:22:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29378 for ; Mon, 29 May 2000 07:22:27 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA15988 for ietf-fax-bks; Mon, 29 May 2000 03:31:46 -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 DAA15982 for ; Mon, 29 May 2000 03:31:44 -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 TAA07272 for ; Mon, 29 May 2000 19:39:17 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id TAA18907 for ; Mon, 29 May 2000 19:39:17 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA06751 for ; Mon, 29 May 2000 19:39:06 +0900 (JST) To: ietf-fax@imc.org Subject: draft communication letter to ITU-T Q4/SG8 meeting in June 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: <20000529194516U.tamura@toda.ricoh.co.jp> Date: Mon, 29 May 2000 19:45:16 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 128 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagus, We agreed to send a communication letter to ITU-T Q4/SG8. The rapporteur meeting is held on June 12-15. The following is the draft letter. Please check it. If there are comments, please reply by June 1(if possible, ASAP is better, Sorry for hasting). Because the deadline for input of the document to the meeting is June 2. Any comments are appreciated. [[[]]] parts are comments for only this mail. This is not included in the real letter. ---------------------- Begin --------------------------------------------- TITLE: Communication from IETF Fax Working Group on Current Activities Abstract This letter is to notify current activities of IETF Fax Working Group. At Adelaide meeting held in March, Fax WG newly started and re-chartered. 1 Charter New charter was discussed at Adelaide meeting. There are mainly following items that the group agrees to and aims at. a) Full equivalance of T.30 service over Internet mail b) Offramp and Onramp Gateway c) TIFF-FX extensions d) Implementer's Guide for simple mode and extended mode Except for item b), the group has internet-drafts. The group also agrees to continue the cooperation with ITU-T, in order to enhance the service. Please refer to the attached charter. 2 For Draft Standard The group considers the following RFCs, which T.37 refers to, as being Draft Standard. Existing RFCs Internet drafts a)RFC 2301(TIFF-FX) draft-ietf-fax-tiff-fx-06.txt b)RFC 2303(PSTN address format) draft-ietf-fax-minaddr-v2-00.txt c)RFC 2304(Fax address format) draft-ietf-fax-faxaddr-v2-00.txt d)RFC 2305(Simple mode) draft-ietf-fax-service-v2-01.txt After Adelaide meeting, the group is going forward. Concerning a), there is no technical changes from RFC 2301. There are only clarification issues. The group already discussed it. The group thinks the draft can be submitted to IESG for Draft Standard. The co-chair requested IESG for the consideration. IESG is now considering it. [[[Within a few days, I will request IESG. This letter will be read on June 12-15.]]] Concerning b), c) and d), there are dependancy problems(some references are at proposed standard level) and interworking is not enough. The group is now making effort to solve the matters. There are also no technical changes from existing RFCs. At the same time, the group agrees that draft-ietf-fax-tiff-regbis-01.txt, which will be replaced with RFC 2302(TIFF registration), should be BCP(Best current practice). The co-chair also requested ISEG for the consideration. [[[the same as the above.]]] After approved, these RFCs are replaced with new ones. The group will notify Q4/SG8 of it. 3 FFPIM FFPIM is the acronym of "Full-mode Facsimile Profile of Internet Mail". FFPIM aims at equivalence of T.30 service over Internet mail. There are the following three internet-drafts. a) draft-ietf-fax-ffpim-00.txt b) draft-ietf-fax-timely-delivery-00.txt c) draft-ietf-fax-content-negotiation-01.txt In fact, the draft-ietf-fax-ffpim-00.txt refers to draft-ietf-fax-timely-delivery-00.txt about timeliness and refers to draft-ietf-fax-content-negotiation-01.txt about capability negotiation. With regard to b), the specification defines a set of capabilities which permits an originator to request that the email transport system give a particular timeliness in delivery and then assures if the system will report the success or failure of that request. With regard to c), the specification uses a post-hoc technique that permits an originator to send the best version known by the originator to be supported by the recipient and then sending a better version the recipient requests it. Especially, last year, the group had some requests from Q4 about capability request before sending TIFF-FX file. The draft-ietf-fax-content-negotiation-01.txt realizes it partly, it may meet the requests. They are at rough level and pre-mature. After they are improved very much, the group may think they are sent to ITU-T. 4 Implementer's Guide The draft-ietf-fax-implementers-guide-01.txt is an informational document and clarifies publised RFCs for facsimile communication over Internet mail. This draft is a contribution in this Q4/SG8 meeting as the other document, so the details are not in this letter. Please refer to it. ... Finally, it is noted that the group appreciates your activity and welcomes any comments from you. The group believes the good relationship between them should continue, even after Q4/SG8 is re-organized. ---------------------- End --------------------------------------------- Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon May 29 11:24:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01007 for ; Mon, 29 May 2000 11:24:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26496 for ietf-fax-bks; Mon, 29 May 2000 07:44:15 -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 HAA26492 for ; Mon, 29 May 2000 07:44:13 -0700 (PDT) Date: Mon, 29 May 2000 16:18:59 +0100 To: ietf-fax@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: I'm back. Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Collugues, I'm back today in the office, after being out for a long period... (yes, you know I got married... and then I had to chair the TERENA Networking Conference in Lisbon afterwards). I'm currently chatghing up with my e-mail, but I already read the thread about T.33 : Yes I believe we must clarify the text the the document, and I'll editi it using the various suggestions from the list. If somebody got the meaning wrong from the current version, it simply means we must specify the text in a more clear set of sentences. I'll be back with the revised version of the document in the next days, while I also follow the rest of the discussion. My personal thank you to Tamura-san for taking all the work on him while I was out of service! "see" you soon! Claudio ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 From owner-ietf-fax@mail.imc.org Wed May 31 09:35:20 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 JAA09201 for ; Wed, 31 May 2000 09:35:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06190 for ietf-fax-bks; Wed, 31 May 2000 05:45:56 -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 FAA06185 for ; Wed, 31 May 2000 05:45:54 -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 IAA07314; Wed, 31 May 2000 08:53:32 -0400 (EDT) Message-Id: <200005311253.IAA07314@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-fax@imc.org From: The IESG Subject: Protocol Action: Content feature schema for Internet fax to Proposed Standard Date: Wed, 31 May 2000 08:53:32 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved publication of the following Internet-Drafts: o Content feature schema for Internet fax as a Proposed Standard. o Internet fax T.30 Feature Mapping as Informational. These documents are the product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary Content Feature Schema for Internet Fax (V2) revises the content feature Schema described in RFC 2531, with clarifications to some of the feature tag descriptions, and addition of one new feature tag. The changes from RFC 2531 and this document (listed in Appendix C) are generally clarifications. Internet fax T.30 Feature Mapping describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in the Content Feature Schema for Internet Fax document. Working Group Summary The discussion within the working group was generally noncontroversial. Protocol Quality The clarifications for Content Feature Schema for Internet Fax were based on implementation experience with RFC 2531. Keith Moore reviewed these documents for IESG. Note to RFC Editor: Please replace in draft-ietf-fax-feature-schema-v2-01.txt: 1. Introduction This document revises the content feature schema described in RFC 2531, with clarifications to some of the feature tag descriptions and addition of one new feature tag. with 1. Introduction This document revises the content feature schema described in RFC 2531, with clarifications to some of the feature tag descriptions and addition of one new feature tag. This document thus obsoletes RFC 2531. From owner-ietf-fax@mail.imc.org Wed May 31 23:00:34 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 XAA02169 for ; Wed, 31 May 2000 23:00:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10646 for ietf-fax-bks; Wed, 31 May 2000 19:25:08 -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 TAA10632 for ; Wed, 31 May 2000 19:25:05 -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 LAA04208 for ; Thu, 1 Jun 2000 11:32:52 +0900 (JST) Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by thunder.ricoh.co.jp (8.9.3+3.2W/3.7W) with ESMTP id LAA12185 for ; Thu, 1 Jun 2000 11:32:50 +0900 (JST) Received: from localhost (maple.toda.ricoh.co.jp [133.139.60.73]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id LAA07137 for ; Thu, 1 Jun 2000 11:32:31 +0900 (JST) To: ietf-fax@imc.org Subject: WG Last Call Report - TIFF-FX and TIFF-REG In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000601113851A.tamura@toda.ricoh.co.jp> Date: Thu, 01 Jun 2000 11:38:51 +0900 (JST) From: Hiroshi Tamura X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues, We agree that the following 2 drafts can be submitted to IESG. draft-ietf-fax-tiff-fx-06.txt for Draft Standard draft-ietf-fax-tiff-regbis-01.txt for BCP There are no technical issues. There are no dependency problmes, as we already discussed in ML. To editors of these drafts: Very Sorry for my late action. I will request them to IESG within today(JST). Regards, -- Hiroshi Tamura, Ricoh Company, LTD. E-mail: tamura@toda.ricoh.co.jp