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.