IETF Internet Fax Work Group Minutes by Glenn Parsons were taken with extreme care and detail, but were then compressed and distorted by Dave Crocker. First Session, December 11, 1997 - 9:30-11:30 There were pre-meeting subgroup meetings for TIFF, Service and Addressing. This additional effort by working group participants was extremely productive. The working group is under intense pressure to complete all the technical work by the end of this meeting. Specifically, an immediate set of documents is required for ITU use. The ITUÕs deadline to publish (or more accurately to submit it to the ITU secretariat for translation and distribution for ITU member voting) their Internet Fax specifications is February 1. In order for IETF document to be used in this document, they need to be published RFCs by Feb. 1. This means the IESG will need them by January 1, and to facilitate this the WG 2 week last call must start tomorrow. Crocker concluded by noting his uncertainty if the TIFF-FX document will be able to move forward in this timeframe. Agenda * TIFF-F * Addressing * Service * TIFF-FX Other documents to be addressed as makes sense and time allows. . The ITU documents in context: * F.Ifax - service definition Unlikely that the IETF will influence/overlap this document * T.Ifax1 - Store & Forward protocol There is overlap with the IETF on this document. The goal is for the ITU to include references to IETF documents in this protocol to solve various pieces of the puzzle. This document outlines a clear migration path of features. * T.Ifax2 - Real time protocol Documents The document contributions that needed to be discussed were listed and mapped against the agenda and a priority. I-D Drafts (latest version) Priority Agenda Order 1 A 1 A 1 C 1 C 1 C 1 B 1 B 1 B C C 1 C The final two documents are for use in the ITU discussion and are not part of the WGÕs program. The group was asked who had read the various documents being discussed. Only the core group of chairs/editors had read them all. No significant jump in readership was noted until the question was reduced to just TIFF-FX & TIFF-F (on the final question, slightly more indicated reading TIFF-F). TIFF-F Work on TIFF-F has been ongoing for the better part of a year. The documents on TIFF-F and image/tiff were submitted for last call in September. Several comments were received and all were adequately addressed and are represented in the latest versions of the documents. The recommendation is to forward these documents to the IESG for approval and publication: Proposed Standards RFC Informational RFC No objections were voiced, except a concern for application parameter being completed before these documents could go forward. Question whether standards track was required for registration. However, RFC 2026 was indicated to state otherwise. A number of times, during the working group's two meeting, the matter of syncrhonizing with the ITU schedule was addressed. The desire is to make this document a standards track document in order to facilitate the ITU referencing this document in its specification. If we do not do this there might be divergence between the ITU and IETF specifications. There was discussion about the specific need for an IETF document to be standards track, before the ITU would incorporate it as part of a specification by reference. No firm answer is available but there is strong indication that anything less than standards track will not be incorporated. Since the TIFF-F document had been slated for Informational, this engendered debate about the need and about its relationship with TIFF-FX. A comment was made that reiterated the point that a different ITU and IETF standard for the same thing will be very bad for the marketplace as implementors will have to choose which to implement and customers may become disenchanted. Addressing As background, the main addressing document has been added to over the past several months to add functionality and features to the fax addressing case and further to make the addressing more general in the ÔparentÕ PSTN case. Further, as a result of the generalization, the group has received requests from other services (e.g., voice messaging, SMS, GSM) to add in details for their service in the document. In the revised timeline these would only slow down progression, so the main document was split and slimmed down. The result was two simple short documents that defined the minimum address format for the general PSTN case and the specific fax case. The group agreed to include implementation notes in the document with specific indications (like NOTE:) but these have not been added yet. Allocchio sent the documents to the list and briefly reviewed them on an overhead for the group in this fashion: Fax specific The specific case for fax is defined with the LHS as: "FAX=" global-phone [ "/TSUB=" sub-addr ] where global-phone = "+" 1*( DIGIT , ( "-" / "." ) ) sub-addr = 1*( DIGIT , ["#" , "*"] ) T.33 subaddresses indeed do optionally need # & *. Global The general case is: service-selector "=" global-phone This may be extended using: "/" label "=" value This can be viewed as a source routing mechanism for telephone numbers (noting that source routing has been since removed from email addresses). Further the service selector is essentially equivalent to using a LHS & RHS combination like <123456@offramp.service.net>. Rafferty confirmed that the key use for this addressing is for the offramp to use the LHS as a route to deliver the fax. The chair then asked the room to confirm a proposed action to keep the original addressing document as a place holder (to perhaps later include all the addressing schemes) but to immediately progress the two new shorter documents to last call. This was agreed with no opposition. However, it was suggested to include the fax specific addressing within the service document. There was some concern about this but it was left to the editorÕs and chairÕs best judgment. The result would be reviewed during the last call. Service Three key issueswere identified: confirmation, security and offramp gateways. The document editor took the group through the current draft. The Transport section of the service document noted SMTP, POP, and IMAP as protocols. The group had a lively debate about acceptable, versus mandatory transport protocols. The Format section notes that the TIFF-F minimum set will be used in the image/tiff; application=f content-type with MIME and base64. The theme of debating TIFF-F versus TIFF-FX was continued... To simplify the specification it was suggested that this document should merely point to MIME and indicate that conformance to MIME is required and not restate everything. The Confirmation section (on delivery notifications or DNs) was discussed in the breakout meeting in some detail. There are two kinds of Internet Mail delivery notifications that can be used (both use the multipart/report construct): * Delivery Status Notifications (DSN) These are for MTA-to-MTA confirmation of delivery or non- delivery. ESMTP support of a special keyword is required for requesting a positive DN. Negative DN can be sent without any ESMTP requirements. * Message Disposition Notifications (MDN) These are UA generated receipt notifications that would occur after the delivery of the message. A positive DN must be requested using a header field, while a negative DN can be sent without any requirements on headers or SMTP. The result for the service document was summarized as: * a sender MAY request a positive DSN (but its handling is out of scope) * a negative DN MUST be sent on failure, and it SHOULD be a DSN * a receiver SHOULD be able to process a DSN It was noted that Notifications can pertain to two levels of failure: 1. MTA transfer/delivery 2. process failure (e.g., TIFF rendering failed) Leaving out positive DNs is leaving not a large, but a gigantic hole in the specification. PSTN fax has set the expectation for Internet fax. That is, there must failure/delivery notification. Implementors notes are needed to try to start explaining this meaning. There is some emerging sense of need for an Implementors guide, in addition to the specification documents currently being developed. The group then debated the relative assurance levels being attempted by the IETF and the ITU groups. This is made complicated by variations in notification semantics, variations in notification support, and probably also by variations in the goals of the working group participants. One concern is that once the message is delivered, and a DSN cannot be sent (for subsequent processing failure) that there was no recourse. A suggestion was to add in requesting a positive DN, using MDN as optional. For content, there is a concern about sending anything beyond the minimum set of TIFF-F since there are no capabilities mechanisms defined. The frequent battle between simplicity with few choices, versus power with many, was joined, concerning content. After the meeting, there was a demo of a TIFF-FX implementation with the purpose of getting implementation testing underway. Second Session December 11, 1997 - 9:30-11:30 Introduction Those attending the meeting supported a commitment to meet a schedule for completing all technical work by today in order to make the core IETF fax documents available for reference by the ITU. Given that, the dates presented yesterday are not firm but are instead a conservative estimate. There are two milestones that it is felt IETF RFCs are required in order to facilitate reference by the ITU recommendations. The first is to have RFCs available at the start of the ITU ballot, the second is to have RFCs available at the start of the ITU rapporteurs meeting. Herman Silbiger (ITU Internet Fax question rapporteur) clarified that at a minimum the text of the documents is required for the rapporteursÕ meeting starting January 12. Additionally, final text is required before the TSB begins translation of the documents for balloting on February 1. Absent any formal agreement, the IETF working group is guessing what will be acceptable and by when. The process to becoming published as an RFC was explained: 1. IESG Last Call Upon receipt the IESG will issue a 2 week last call for comments on the document. This process may reveal issues that have to be addressed before further progression. 2. IESG Consideration After last call comments have been addressed, the IESG will consider the request for progression. Consideration often takes 1-3 months as there are many topics on the IESGÕs plate. As a result, it helps to Ôgrease the wheelsÕ to speed this up -- Crocker has already done this. As well, this process may result in additional issues that have to be addressed before further progression. 3. RFC Editor This is an independent process of the IESG and has been known to be prone to delays due to backlog. However, the RFC Editor hopes to keep this process to under a month. Agenda * Introduction * Service * TIFF Application Parameter * TIFF-FX * Straw polls Service Rafferty introduced that the agenda for this section would be as follows: * Review of Informal Meeting proposal - Larry Masinter * Discussion & Consensus - James Rafferty * Security Considerations - Dan Wing 1. Summary Clarifications will be added to indicate that this is the Ôsimple modeÕ and that extensions to this document will follow. Further, ÔInternet Mail protocolsÕ will be used in place of SMTP and the conformance language of RFC 2119 will be referenced. 2. Scope: Services It will be clarified that this document details communication between various services: network printer, network scanner, Internet mail host & offramp gateway. An IFAX device is a combination of these features that can send or receive. However, the onramp case is not mentioned here as it is too broad. 3. Scope: Cases The specific cases will be noted as follows: Internet mail host -> Network printer Internet mail host -> Offramp gateway Network scanner -> Network printer Network scanner -> Internet mail host Network scanner -> Offramp gateway 4. Scope A G3 fax device is defined as a classic terminal that uses T.30. As well, email addresses may be used to send to G3 fax devices via an IFAX offramp. 5. Transport This section was split, with some text moved to the gateway section. Only the SMTP related text remains. 6. Gateway direction It was agreed that onramps are out of scope. However, cover page addressing, confirmation and failure are in scope. 7. Gateway (text from Transport) It is noted that gateways do not represent classic Internet mailboxes and that ÔdeliveryÕ is defined as being to the gateway and not to the G3 fax device. 8. Mailbox Protocols The use of POP/IMAP protocols are described here. 9. Failure to process The agreement is that a message cannot be lost (e.g., discarded) without any notice. A failure action is required but not specified (but needs to be careful enough to avoid mail loops). 10. MIME Formats The document will reference RFC 2049 for MIME conformance. Only exceptions will be noted in an Annex. 11. Headers There is uncertainty whether the requirement on all RFC822 headers should be retained for fax. The document will reference RFC822bis but require the at least Date & Message ID be present. 12. Mulitpart Again, there is uncertainty over the acceptability of the proposal. Should multiple TIFF files within a multipart/mixed be supported (e.g., a multipage, multifile fax)? The proposal is that multipage documents SHOULD be sent as one file, but accepting the multipart/mixed with many files MUST be supported. It is recommended that the multipart structure not be used. A further note is that if any part of a multipart message fails to render then the entire message fails. 13. Confirmation For delivery failures, a negative DN MUST be sent and it SHOULD be in DSN format. Failure to process errors are also required. 14. Addressing The addressing document will be referenced 15. Security Considerations (deferred to next discussion section.) 16. Image File Format It is proposed to change the name from ÔTIFFÕ to ÔImage File FormatÕ. Further, specific word wrangled text is proposed that notes the minimum set must be sent if there is no prior knowledge (and that capabilities is out of scope). 17. Exceptions to MIME Several exceptions are proposed: - no requirement to send text/plain - no requirement to place results in a file, but may invoke Ôfailure to processÕ - may print/fax rather than ÔdisplayÕ 18. References These need to be updated. After the review, the material was discussed: 1. Summary Is this a conformance document? A concern was raised about how the ITU would map their optional/mandatory to the IETFÕs various conformance levels. An editorial pass will be made over this section to align with the technical material. Consensus: Agreed (none oppose) Services 1. Scope: Cases A suggestion was offered to define cases in terms of sender and receiver. This was rejected as it was one of many options that was already evaluated. Consensus: Agreed (none oppose) 2. Scope There were no questions on the email addressing and forwarding points. Consensus: Agreed (none oppose) 3. Transport There were concerns about the precise wording of this section, the degree of requirement and the ability to use non-email transport. Consensus: Split (about 1/8 of room for and 1/8 against) 4. Gateway direction This is editorial instructions for the editing team. The group will see final text in the last call next week. Consensus: Agreed (none oppose) 5. Gateway (text from Transport) Consensus: Agreed (none oppose) 6. Mailbox Protocols The use of POP/IMAP protocols are described here as optional. Parsons notes that the wording suggests that a system may be compliant if it only supports POP. There was a suggestion that this should be local implementation issue (i.e., out of scope) -- the current text implies non- interoperability. Consensus on point 1: Split, so defer to list (about 1/8 of room for and 1/8 against)) Failure to process is also mentioned on this slide and was separated, for polling. Consensus on point 2: Agreed (none oppose) 7. Failure to process Concerns over degree of specificity in instructions and permission for alternatives, possibly resulting in lost notifications. Should notice be to the sender or receiving operator? Should DSNs or MDNs be required? The recommendation was to use the form described in the slides. Consensus: Agreed (about 1/8 of room for and none against) 8. MIME Formats The current service document says nothing so adding the MIME conformance is required at a minimum, but some tutorial text has also been added. The actual exceptions are noted on another slide (and in the document Annex). Consensus: Agreed (none oppose) 9. Headers RFC822 will be referenced as RFC822bis will not be ready in time. There are some open issues here that need to be addressed on the list (i.e., mandate which headers, which headers map to the cover page). However, it was proposed at least Date and Message-ID SHOULD be present. Consensus on points that are not open: Agreed (none oppose) 10. Mulitpart Typically, a multipage fax is contained in one file (actually TIFF-F & TIFF-FX require this). If there are multiple TIFF files within a message, the confirmation must be based on all of the files. Recipients MUST process a multipart/mixed content with multiple TIFF files. Consensus: Agreed (about 1/8 of room for and none against) The requirement might be to process any multipart/*. There was a suggestion for multiple files to sequentially number the pages from 1 to n for all the files combined. These were open issues. 11. Confirmation A negative DN MUST be set, but it should be a DSN. Consensus: Agreed (about 1/3 of room for and none against) 12. Addressing The fax-address will be noted. Consensus: Agreed (about 1/4 of room for and none against) 13. Security Considerations ...skipped 14. Image File Format It is proposed to change the name from ÔTIFFÕ to ÔImage File FormatÕ. Consensus on name: Agreed (none opposed) As there was potential dissension here, Rafferty held a different poll on the new text. Consensus: Rough consensus (about 1/3 of room for and several against) Concerns from some participants: The minimum set MUST NOT be used without capabilities negotiation. RFC 2119 words should be swapped in. 15. Exceptions to MIME RFC 2049 might require that implementations MUST send text/plain. This will be followed up on the list. Consensus on intent: Agreed (about 1/3 of room for and none against) 16. References Consensus: Agreed (about 1/3 of room for and none against) Security Current proposal for the security considerations section. This section has not received the same review this week as the other sections of service document have. The proposed security issues: · Eavesdropping Both on the wire (IPsec, TLS) and on disk (PGP-MIME, SMIME) · Unsolicited fax Both junk faxes and blasts resulting in denial of service · Spoof sender · Authenticated Recipient Only the intended recipient should be reading the fax · Viewing faxes in public · Sender identification Whether it is the email From addresses or the telephone number The proposal would be sent to the list by Wing next Tuesday. TIFF-FX Status of the latest TIFF-FX draft: Revised this week based on comments received and distributed hard copies of the 04 draft to the group -- it will be sent to the list next week. TIFF-FX now integrates TIFF-F (as of the 03 draft) and is consistent with the image/tiff content registration. Further, all facsimile features represented in the document are ITU standards and all relevant ITU standards are represented. The document is consistent with current and emerging industry practice and provides a consistent framework for TIFF. Currently, the document is organized with section 2 introducing features and tags common to all profiles of TIFF. Sections 3-8 then delineate the details for the profiles of: · S - Minimum Set TIFF · F - TIFF-F · J - JBIG · C - Colour · P - Palette colour · M - Mixed Raster Content A diagram that reflected the ITU structure of these profiles: MH (S) / \ B&W / \ Colour ------------ ---------- / \ \ MMR JBIG (J) JPEG (C) / \ --- \ / \ JBIG (P) MRC (M) There was a concern that the F profile (i.e., TIFF-F) was not noted in this model. McIntyre explained that this was because it did not exactly fit since it combines both MH and MMR. It is claimed that TIFF-FX contains the definition of TIFF-F that has been reviewed extensively. Further, TIFF-FX has been reviewed and specific comments have been received (a summarizing table of the comments was handed out). Interoperability can by guaranteed by conforming to each of the profile levels (S, F, J, C,P,M). The TIFF-FX authors recommend that it be progressed to last call as a standards track document. The concern is over the degree of public comment on the TIFF-FX document so far. Straw Polls (Reduced meeting attendance by this time.) First, does the group agree that the Requirements document (i.e., Terminology & Goals) should be progressed immediately to last call and then forwarded to the IESG as an Informational RFC? Consensus: Agreed (none oppose) To permit TIFF-F to be included by reference by the ITU, is the group comfortable to progress TIFF-F to the IESG with standards track status? Consensus: Split (about 1/8 of room for and 1/8 against) Finally, is the group comfortable to progress TIFF-FX with standards track status? Consensus: Rough consensus (about 1/8 of room for and several against) Application Parameter A proposal from several informal meetings and discussions this week to resolve the role and use of the optional application parameter in the image/tiff content-type. There were three possible roles perceived for this parameter: 1. capability indication 2. hint to application dispatcher 3. hint on the reproduction requirement It was agreed that the first role was an overloading of this parameter and the intent would only be as a hint. Eight options were listed by the informal group: 1. no parameter 2. fax 3. fax, color fax 4. F (B&W), J (JBIG), C (colour), M (mixed) 5. S,F,J,C,P,M 6. comma separated list of #4 7. comma separated list of #5 8. two dimensional list of #3 9. two dimensional list of #4 A straw poll of the informal group resulted in a split amongst all options except 5 & 6. However, most votes were for option 2 or 3 (with other people later expressing a preference for 3). If there are any changes required, minor editorials will be made to the appropriate documents. Tthe group was polled based on the suggestion that a preference be stated on option 3. Does the group accept defining the values of the application parameter as fax or colour fax? Consensus: Rough consensus (about 1/8 of room for and several against) Upcoming Meetings There are several important Internet Fax meetings coming up. TIAÕs TR29 which decides US input into the ITU (actually various members will be meeting off-line after this meeting) will have an official meeting before the June ITU meeting. Non TIA members may attend once before having to become a member. The ITU rapporteurÕs meeting will be held starting January 12 in New Jersey. Only ITU members may attend but conveniently the Internet Society is a member. As a result, Crocker&Rafferty will coordinate official designation of anyone who wants to attend as an ISOC delegate. The details of this meeting will be posted to the list next week. The meeting was adjourned with applause.