Final Internet Fax WG minutes from Oslo follow: Minutes - IETF Fax WG meeting, July 13, 1999 Chair, James Rafferty Reported by Graham Klyne AGENDA Agenda Bashing ITU cooperation review Simple Mode progress to Draft Standard status Current/planned drafts Response to ITU SG8 communications Conneg WG status Milestone update, closing the WG Agenda Bashing The agenda was presented by the chair and accepted. ITU cooperation review James reported on the ITU cooperation status. James and David Crocker went to ITU-T SG8 on behalf of ISOC/IETF in March-April, 1999. T.37 amendment 1 ("full mode") has been proposed which references the IETF Internet Fax "extended mode" RFCs. The amendment Was not accepted due to procedural issues with some ITU country members. But these appear to be minor issues that can and will be resolved, hopefully for approval at the ITU SG8 meeting in September (or February 2000). As noted on the slides, the next steps are to 1) Submit the Conneg RFCs as contributions and 2) Submit any other related documents (future items). Simple Mode progress to Draft Standard status The current drafts were reviewed as follows: Service: RFC2305 (revisions at ) TIFF: RFC2301 (revisions at ) It was noted that there is a need for TWO interworking implementations of EACH feature in order to progress to draft standard. There is also a need to look closely at normative references to other documents, which must also be at least at the draft standard level). Hiroyuki Ohno reviewed the update of the service document (RFC2305 is the current proposed standard). The main change from the -00 to -01 draft was to add the full copyright notice. The 2nd FaxConnect event was generally successful, with demonstrated interoperability between 13 vendors. The event was held simultaneously in San Jose and Tokyo through a collaboration between the Internet Mail Consortium and the Internet Fax Study Association (Japan). For related information about the Fax Connect II event and future related events, see: , www.ifax.or.jp, as well as www.ifaxbus.org (new Internet Fax and Business Communications Association) and http://tanuki.ohnolab.org/info/FAX-Connect2/. Most important parts of simple mode (RFC 2305) are well implemented, with good interworking. One area that still has limited support is the use of the DSN format for non-delivery reports. There were significant improvements in interworking for the simple mode between FaxConnect 1 and FaxConnect 2. James Rafferty and Lloyd McIntyre reported on the status of the update to the TIFF document (RFC2301 is the current proposed standard) Good interworking demonstrated for S profile at Fax Connect II among 10 companies. Interworking of all other profiles has been demonstrated in other venues. (Roughly: S profile - near universal; F profile - 50%; other profiles - few) Lloyd McIntyre noted changes in the draft from revisions -00 to -01, which were one technical change and several editorial. (for details: see LLoyd's slides) The technical change is to designate that the JBIG compression method is defined by T.82 and that T.85 is a constraint profile of JBIG. Accordingly, compression=9 will designated T.82 and T.85 will be designated by a new T.82 options tag extension. There was some discussion about recycling at proposed or incorporating this change in a move to draft standard. Area Director Keith Moore asserted that small changes of this nature do not require recycling, even though "bits on the wire" may change. It was further noted that the dangling reference to ITU T.44 is now fixed: T.44 (MRC) is now approved and stable. In editorial changes, a wording clarification is needed concerning equivalence of inch- and metric- based resolutions, such that implementations are REQUIRED to accept both (200/204, etc) and MAY treat them as equivalent, for consistency with the rules for 200x100 and 200 x 200 resolutions in T.30. Regarding IPR issues, it was noted that the disclosure of licence information is very sensitive. At least one interoperability test participant has an appropriate licence for use of JBIG, and two more are in progress of obtaining a licence. Disclosure of specific licencee information is commercial-in-confidence, and is not currently available. Two interoperability test participants are in the process of obtaining licences for MRC (the basis for TIFF profile M). Keith Moore noted that statements may be made to the IETF secretariat, but do not need to be made public. An interpretation of RFC 2026 is that implementations forming part of the interoperability test must also assert they independently meet licensing requirements where needed. See http://www.ietf.org/ipr.html for the status of ipr claims. James Rafferty and Claudio Allocchio reported on the status of the addressing drafts (updated to current proposed standards RFC2303 and RFC2304) Rafferty stated that he need more evidence about support for specific features of these documents in order to meet the draft standard interworking requirements. The chair requests that any implementers with implementations of these specifications advise him of their implementations. (Offline private information is OK.) It was reiterated that the call for Draft standard requires that accompanying documentation of interworking evidence be submitted to IESG. Current/planned drafts Cover Page: The purpose of this draft is to identify the presence of fax cover page information, allowing for it to be distinct from the primary content of a message; in this respect, a cover page may be "distinguished" content within a message. Three different cover page cases were noted(see slides): 1) NO cover 2) Probably cover information (likely to be a fax onramp case) 3) The cover information is embedded or explicit via manual or automated cover generation Embedded content means that the cover content is part of the primary content, whereas explicit implies a separate MIME part of a multi-part structure. Open issues include 1) disposition of VPIM multipart constructs for Unified Messaging and 2) Is a particular multipart structure required when cover information is present. Keith Moore suggested that he would meet with a small group of fax, VPIM and email people during the week to review the mechanism for multiparts related to "primary content" types (i.e. primary content type is fax, also other content) T.30 mapping < draft-ietf-fax-feature-T30-mapping-01.txt> This document is targeted for informational status and covers how to map T.30 DIS bits to Internet fax content feature expressions. It seems nearly ready for last call as informational. Implementers' guide (no current draft) : There is much desire for this but the chair is looking for an author(s). Some potential sources for material from previous drafts such as "FPIM" were noted. Response to ITU SG8 communications The ITU has no technical issues with T.37 Amendment 1 as is. However, per the first "communication", they would like to see some improvements and "fleshing out" going forward. The chair believes that the Fax WG should have consensus on a written response for ITU SG8 by September 1999. Full mode: Maeda-san reported on the ITU communication. He notes that there is a need to reconcile differing cultures (e.g. in Japanese culture, it is proper form for a fish to be placed on a plate with its head to the left). We need to be sensitive to differences in culture between IETF and ITU. RFC2530, 2531, 2532 meets ITU requirements for time being. But the ITU culture requires: (2.1) capability exchange and confirmation, and clarification on how this should be achieved. (2.2) information to indicate the total number of pages received. (2.3) MDN response should provide more fine-grained information final message disposition in an MDN response. The ITU request further study and discussion and more complete solutions for addressing these requirements. A discussion on a response was led by James Rafferty: (2.1) there is no specific mechanism for DSN/MDN to explicitly request capabilities as well as confirmation. It was noted that the current specification indicates an extended mode fax receiver SHOULD send capability information in response to a request for confirmation, and that SHOULD is a very strong requirement, and should not be disregarded without a very good reason. However, the chair noted that the ITU is asking the WG to strengthen the request requirement. Ryuji Iwasaki-san provided a brief presentation on a capabilities exchange... He noted that if a sender does not know receiver's capability, it must send TIFF-FX Profile S. If a sender needs to send higher capability, the message must be sent (and printed) twice (first time TIFF-S, then higher capability). His proposal is to send a new "request header" with the image AND request capabilities. -- IF a receiver is capable of handling extended capabilities they can choose NOT to print the TIFF-S, and instead request the enhanced document. Graham Klyne also had some ideas along the lines of having the receiver initiate content negotiation in response to an indication from the sender. It was suggested that Iwazaki-san and Klyne should cooperate on a joint proposal. (2.2) need a more complete (i.e. universally available) mechanism for confirmation It was concluded that MDN message extensions should be discussed on the list. (2.3) MDN response to indicate status of attachment processing. Require to indicate status of body part or parts vs message as a whole. In discussion, it was suggested that the likely route is some kind of extension of MDN response. This is feasible, but might make MDN responses quite long so probably any extensions should be sent only if explicitly requested. There is a need to work with VPIM on this, as they are looking at addressing some similar issues. This is another topic for the small ad-hoc with Keith, as well as for followup on the list. Communication 2 on Synchronization: It is stated that there is a need for synchronization between ITU T-series fax recommendations and IETF RFCs, especially where they cross-reference each other. When new T.30 features are added, how are updates to TIFF and fax feature schema handled? The chair presented 4 cases and their potential handling. [[see James' slides for more details]] 1) Revision to T.30 -> New fax feature tags Discuss: Needs IETF review to incorporate (per Conneg rules) (?) 2) New values for existing fax feature tags (based on approved amendments to T.30) Discuss: More streamlined process may be possible to update valid values and IANA registry 3) Revision to T.30 attributes which may affect TIFF (RFC 2301) profiles Discuss : appears to need IETF technical review 4) no change to feature schema is required; maybe just update T.30 mapping. The potential solutions were presented to the group, but further discussion is deferred to the list, due to time constraints. After discussion, the chair will draft a response on this communication to the ITU for early September review by the WG. Conneg WG status This item was skipped, but would be reviewed in the conneg meeting later in the day. Milestone update, closing the WG The chair presented a proposal for updated milestones. Key items were: Implementers' guide: initial draft by August 1999. Simple mode to Draft Standard last call: August 1999 Cover page to last call: September 1999. The chair targeted completion of all open items by the year end and a potential close of the WG after the November meeting. In brief discussion, it was suggested there is a need to look at (a) immediate delivery and (b) security, citing security mechanism RFCs, which might delay a WG close beyond end of year. The chair noted that the latest revision of RFC2305 does reference new IETF security RFCs, but they are at the proposed standard level. Keith Moore stated that the WG should not put security on the critical path for the main fax documents. Possible alternatives are to 1) do a separate document of applicability of e-mail security for Internet fax (Call for author(s).) or 2) maybe just put something in the implementers' guide. Keith Moore suggested that regarding immediate delivery, the WG should consider the "deliver by" proposed extension to SMTP. It was questioned whether this is really a good idea since it seems to invoke session semantics and consequent difficulties already identified on the list. It was concluded that it is possible, but not clear, that the WG will close this year (even if there is some ongoing work to be addressed).