Internet Fax Work Group Meeting - August 26 and 27 Chair: James Rafferty Reported by: Graham Klyne ITU cooperation review - James Rafferty (see slides "ITU Cooperation") The chair reviewed the status of cooperation with the ITU Study Group 8. The groups cooperated to produce the simple mode specifications. The clear message from ITU is that they are pleased with the results so far, which has included direct participation by ISOC delegates at ITU meetings and want to continue the ISOC/ITU relationship for the next level of Internet fax standards. The "Communication" from ITU sets out ideas on full mode requirements, which have triggered some further discussions. Rafferty reviewed the ITU meeting schedule, which calls for meetings in early November and next March. The ITU would like to begin the approval process for the "full mode" of Internet Fax at the November meeting. In line with this, the chair proposes that the group focus its efforts and aim to submit and stabilize WG core work on "extended mode" by the November ITU meeting in order to help ensure a single coherent standard for Ifax. In particular, the group needs to be clear about which extended mode components can be completed in this timescale, and which others which must be deferred for later consideration. The work submitted in August will be the DSN, MDN RFCs and the -eifax- draft. Final version(s) of -eifax- based work would be targeted for ITU submission by October 1998. Also, a response to the ITU "communication" should be drafted by the end of September 1998. The room was supportive of the direction outlined, and is prepared to work aggressively to meet the deadlines over the next two months. . WG charter review - James Rafferty (See slides "Charter Review".) The chair reviewed plans to update the charter. It is proposed that "Full mode" be pared down to core essentials that can be agreed quickly. This would be followed by related work that would continue over the next several months. There is also a need to review the "simple mode" documents, with view to going to "draft standard" (also needing documentation of interworking implementations). The core documents targeted for completion within the WG during September are : -eifax- and "-features-schema-". An issue was raised that this schedule may be held up by 'conneg' documents schedule (especially -reg- and -media-features-). It was noted that the -reg- document is pending an IETF Last Call. oncern was also expressed that there should be time to take account of any comments that may come from the ITU review. The chair believes this can take place immediately following the ITU November meeting. In this scenario, the ITU would need RFC numbers by December 1998. The Address extensions document is also approaching stability and is also targeted for completion in the near term. The chair also reviewed items which are not on the immediate critical path, but could be addressed within the work group. (See "Charter review III" slide) Some of the confirmation issues may require review of some aspects of e-mail architecture, so must be dependent on other groups as well as our own. The Mailcap BOF held this week is expected to result in a new WG, which may provide mechanisms that are useful for exchanging fax capabilities. E164 resolution may also have some applicability to what the WG needs in this area. A question was raised about developing real-time fax standards in the WG, but indications are that this is out of scope for the current Ifax working group, especially since the ITU has already developed the real time T.38 recommendation. Another possible solution is IPP (looking somewhat like real-time fax). From the AD: we would need substantial justification to take on work that competes directly with ITU T.38. In another charter related item, there was consensus in the room that the-goals- document should be put to WG last call (as informational) to document the problem we were trying to solve. Revisions to the "simple mode" RFCs will be considered and related milestones will be included in the updated charter. A comment was made that a milestone should be in the charter for completing security-related work, but it was noted that the ability to do so in a timely manner is dependent upon progress in e-mail security. It was suggested that security is probably related to capability exchange (e.g. key/ certificate and capability distribution may be combined). There was support for the charter direction as outlined; the chair will prepare an updated draft charter for circulation to the mailing list. Store-and-forward extended/full mode - Dan Wing Dan Wing outlined steps to be taken to reduce the -eifax- draft to a core document. (See slides used for Dan's presentation) 1. Emphasis on describing standard operation of the "eifax system", which consists of the Sender+receiver+infrastructure(MTAs). Thus compliance applies to the overall system, not specific components. - Consensus OK. 2. Reduce section discussing security and encryption, by using references to other documents and eliminating overlap with RFC2305. The security section will be retained, but simplified. - Consensus OK. 3. Remove references to quick delivery, offramps. These will be addressed in separate documents. Plan to write separate documents covering onramp/offramp behavior. A separate document will be written to clarify the roles -- this may be in the communication to the ITU, followed up by a formal document. Terms will be described in the -goals-document. Detailed wording is left to the document author(s). - Consensus OK. Confirmation of Receipt Dan Wing reviewed proposed changes to the wording of the -eifax sections on Delivery Confirmation and Processing confirmation. The proposed wording changes were first reviewed for understanding and then the chair conducted a consensus check on each of the proposals. Slide 7 - There is new wording proposed for DSN/MDN requests tosimplify those sections. "If EIFax sender wishes to receive processing confirmation it MAY request an MDN". (i.e. use of MDNs to learn about processing is part of the standard, but is not mandated). References in the current draft to different behaviors depending upon the type of recipient are eliminated. Consensus: Yes Slide 8 - Addition MDN: "If a recipient receives an MDN request ... MAY indicate success ... SHOULD indicate processing failure". There are possible problems here if multiple clients are used against a mailbox. There are ad-hoc solutions to this scenario, but no "standard" solution was offered (apart from, possibly, user choice). There was a voice raised requesting "SHOULD" for processing success. But "SHOULD" is a strong requirement, and there are potential architectural issues. The wording deliberately talks about "recipient" rather than "user agent" or other more technically specific terms, to allow flexibility in overall system implementation. Behavior of any single component will generally need to vary (e.g. be configurable) depending upon the scenario in which it is deployed. It was suggested that the wording needs strengthening, but MAY/SHOULD/MUST is not appropriate. Also, try for consistency of wording style in the successive sections. - Consensus OK on the principle, with author(s) to find better form of words. There was a plea to the e-mail community for a possible mechanism that can be mandated to return (non-)processability information (unlike MDN). It was indicated by Ned Freed that mandated processing-failure messages might be achievable in the short term, for automated recipients, but probably not for human recipients. [Further discussion and consensus gathering deferred until the next day, where these points were re-visited] Slide 8 - Addition DSN: "If MTA knows that user will not process message, it MAY generate delivery failure 5.6.x". The rationale is that an MDN response cannot be unsolicited, but a DSN may be used to generate unsolicited notice of non-processable messages. This is consistent with the existing Ifax (simple mode) work. There was discussion suggesting that MAY should be SHOULD and that a simplified wording was possible. The author agreed to consider alternative wording overnight. . On-demand SMTP Ned Freed provided a brief review of three possible options for using SMTP in on- demand situations. This may be applicable in Ifax for situations such as for dialup or occasionally connected clients. SMTP is a "push" protocol (only). POP/IMAP are "pull" protocols, but not appropriate for some uses Three "pull" (on-demand) options: 1. TURN command -- in RFC821 This causes the client and server roles roles to be reversed, but it is wide-open to abuse. This option has been deprecated in the DRUMS updates to RFC821, so it is not recommended. 2. ETRN 1C: ETRN domain.com 2S: 220 service started Host (2) then connects to host (1) as a client. This overcomes the spoofing problem: a new connection is created, which is safer. The main problem is that it doesn't work with dynamic address assignment (i.e. no domain name defined). This is defined in proposed standard, RFC 1985. 3. AUTH + ATRN Same as TURN in most ways on-the-wire, except: (a) requires use of SMTP AUTH (b) adds domain parameter to ATRN This can be implemented without having a full SMTP server on the port (i.e. the software recognizes ATRN, then becomes a client.) The scope is for an entire domain, not an individual mailbox. The author indicated this *could* be addressed in the current proposal, but has not been to date. It was pointed out that ATRN (with SMTP pipelining) is a better choice than POP from a performance standpoint for single-mailbox downloads. The Mailing list for ATRN is The current draft is: , which was scheduled for review in the mail extensions BOF the next day. The implications and requirements for using ATRN for Ifax need more discussion. ** The meeting continued on Thursday, resuming where it left on the matters of confirmation within the -eifax draft and proposed wording changes, before continuing with the planned Thursday agenda. Slide 7 (re-visited) Addition MDN: "If a recipient receives an MDN requestà SHOULD respond to the MDN". Comments from after yesterday's meeting that different MDN response criteria might apply to automated recipients vs human recipients. Suggested words: "If the recipient is an unattended terminal, the MDN response MAY be automated". - Consensus OK on principle, with author(s) to find better form of words. Slide 8 (re-visited) Addition DSN: "If MTA is able to determine that the message cannot be processed, it SHOULD generate delivery failure with status 5.6.x". Rationale: an MDN response cannot be unsolicited. Using DSN in this way allows the possibility of unsolicited non-processable messages. It is likely that a new status code will be defined, rather than using 5.6.x. - Consensus OK, wording may be simplified by author Slide 9 - Miscellaneous changes were reviewed: - define processing - add note that DSN is deterministic - re-write intro and section 2 with emphasis on *system* - Remove 7.1 (multiple POP clients) - RFC 974 to implementation note - Consensus OK Reporting extensions (See James' slide) The chair noted that there is a reporting-extensions draft. It appears that extensions to the current DSN/MDN model may be needed, but these must be done by the e-mail community and will take place over a longer timeframe than the immediate -eifax work. Capabilities/Identification (See James' slide) The chair noted a strong requirement to report failure to process. This may need some extension to the e-mail notification framework -- it doesn't fully fit either DSN or MDN. Dan Wing presented a single slide (slide 12) on proposed changes to the -eifax draft related to capabilities. The mechanism is unlikely to be finalized in current timeframes, therefore manual configuration of sender is explicitly allowed. The immediate focus will be on media features, not other T.30 capabilities. There was a suggestion that the SDP protocol (Session Description Protocol.) [RFC ????] should be considered for ideas. (James' slide "Cap Exchange - Features" -- list of current drafts) (James' slide "Cap Exchange - Features (2)") Lloyd McIntyre discussed T.30 capabilities and how it related to the -eifax work. Relevant items include TIFF profiles, paper size, resolution options, coding and colour model options. Toru Maeda announced a new draft was sent to the fax list that proposes an alternative approach to capability exchange using a new MIME type and empty message to trigger transmission. There was a comment on a "metadata" content-disposition draft. Content features might be sent in a body part thus labeled. This suggests a new MIME type for carrying media feature metadata. Some work is being initiated. Contacts for this are Ted Hardie/Chris Newman. vCard specification was suggested as a way of carrying this information, rather than a new MIME type. There is also possible tie-in with LDAP and certificate access. A straw poll was conducted on developing a draft for fax media feature schema development, to capture ideas in T.30 as they relate to Ifax. General consensus - OK A straw poll was also conducted on the definition of a related MIME type for capabilities. There was no consensus, so this question is to be deferred to the mailing list. Capabilities -- feature representation Conneg chair Ted Hardie reported that the registration draft has gone through WG last call, and is requested to go to IETF last call. The algebra draft exists to define a framework for combining individual media features into capability statements. - Consensus OK to use 'conneg' framework for fax feature schema Capabilities -- Mechanisms (James' slide "Cap Exchange - Mechanisms") There was a comment from the room about dependence on directory-based mechanisms for distributing capability information, since there is evidence of resistance to deploying this kind of approach. It is suggested that the use of e-mail (e.g. DSN, MDN,etc.) may be a more popular option for actual deployment -- at least in the near term. Another comment is that a combination of directory and other methods may be deployed. E.g. directory is local source of information, with e-mail used to communicate across organization boundaries. This suggests that both MIME and LDAP schema should be defined. It was noted that the 'Mailcap' BOF (which is likely to become a work group) may produce a useful mechanism. The Mailing list is ; to subscribe, send to with SUBSCRIBE in the body.). The chair summarized by noting that the aggressive target for the -fax-features-schema- WG last call is by September 15. This is 2nd core document for EIFAX. The choice of preferred mechanism probably must come later. Schedule - core documents (James' slide "Proposed Schedule - Core Documents") The chair reviewed the core documents with last call dates and schedule for submission to ITU. The timetable had been accepted by the room during the charter agenda item. Review of Other drafts: -fulladdr-03- (Claudio) Claudio Allocchio reviewed the -fulladdr-03- draft. The details in this document are not fax-specific, but part of a generalization of the framework adopted for simple mode. The Mixer folks want to use this approach. He believes that it is nearly ready for last call. There was some discussion on how the draft related to the use of fields for cover page generation. The framework of -fulladdr- is claimed to easily support the common case of fax cover generation, with extensibility using references to less common cases. This is a tricky problem, without a clear single solution at this time. Also, It was noted that the cover page is really an offramp issue, to be picked up in a later document. Dan Wing reviewed ietf-fax-smtp-session-04.txt. This document has been declared out of scope for the Fax WG by the AD. There was a suggestion to promote it as an experimental private contribution. Also may be useful as an option for message tracking. Toru Maeda reviewed draft-ietf-fullmode-application--00.txt with related slides. He notes various applications in Group 3 fax, including - Polling, Subaddress and password, - Relay broadcast, and - BFT transmission. There was only brief discussion. It is not clear if direct support for these applications is needed in the extended mode of Ifax. For example, MIME is an equivalent for BFT in e-mail, so BFT conversion to MIME may simply be an onramp/ offramp issue. Simple mode interworking (James' slide "Simple Mode Interworking") The chair noted that activities are beginning to address simple mode interworking based on the standards track RFCs 2301-2305. Those interested should sign up for the following mailing lists. <http://www.imc.org/imc-faxconnect> The date and location have been determined. Detailed planning is to start early in September. This is an Engineering event, NOT a marketing event. It will be attendee driven testing and may include some T.38 testing. It was noted that moving to draft standard involves documenting interoperability on each feature. There was a call for testing framework submissions (to the mailing list) to help build framework for interoperability documentation. Lloyd McIntyre and Rob Buckley reviewed current activities in TIFF interworking based on RFC 2301. TIFF profile testing has matured quickly. The concept is to start with known images, pass through a TIFF writer and reader and then do a compare with the original. Test cases are designed to cover all features and options. Prototype utilities have been developed for a TIFF file validator, comparators, viewers. It is anticipated that these would eventually are be available in a product form. To date, profiles S,F,C,M have all been tested and interchanged. (M at preliminary stages.) The goal of the companies involved is that all of the profile testing would be complete by December 1998. The chair then closed the meeting and thanked the participants for productive efforts.