Meeting Minutes - Internet Fax WG 39th IETF, August 1997, Munich Chairs: James Rafferty, Dave Crocker Minutes reported by: Graham Klyne 0. Agenda, goals, etc. ---------------------- 1. TIFF Finalization 2. Service integration issues 3. News/relationship 4. Session mode SMTP proposal 1. TIFF finalization -------------------- TIFF-F: Tiny, core set, separate extension set TIFF-FX: Further extensions (a) TIFF-F Internet draft: Tag Image File Format (TIFF) - Application F Changes in the latest revision are: - Defines application F of TIFF (aka TIFF-F) - Baseline TIFF 6.0 as starting point - Defines and specifies min subset of TIFF-F consistent with histrorical TIFF-F - Range of values for fields consistent with T.4/T.30 recommendations - TIFF overview moved to image/tiff (registration doc) - Clarified practice for readers and writers - Various editorial changes Intended as stable reference for TIFF-F. Internet Draft: Tag Image File Format (TIFF) - image/tiff MIME sub-type registration Defines MIME conent type "image/tiff" Potential referrers are: - VPIM - Internet fax - ITU-T - WIDE James Rafferty, regarding the relationship to WIDE: We now have new and more mature drafts for both TIFF-F (and -FX). WIDE was using a different subset of TIFF. It was agreed in Memphis that TIFF-F should include a definition of a minimum set of TIFF features for Internet fax, but WIDE defined a different minimum set. A meeting between TIFF-F and WIDE authors was held to try and resolve these differences. Issues: 1. differences in fields/values for WIDE vs "minimum" TIFF-F 2. differences between WIDE TIFF file structure and TIFF-F "guidelines" Proposals for alignment: 1. Revise "minimum" TIFF-F values to satisfy WIDE requirements. 2. Revise WIDE to reference "minimum" TIFF-F using multi-page TIFF files (Subfiletype 2). 3. Maintain the principle that all Internet fax readers must read the "minimum" TIFF set. Proposed changes to "minimum" TIFF-F: - Field T4Options: permit 0 in addition to 4 (byte aligned and non-byte aligned). - Field ImageWidth: keep 1728, delete 2048 *** Ageement: The meeting consensus was to accept these proposals. It was proposed to add one additional point to the current TIFF-F recommended "guidelines" for reading/writing tiff files, for better consistency with WIDE: This is to require the IFD to precede the related image. *** Agreement: The meeting consensus was to accept the proposal. The WIDE authors propose a stricter ordering of: header, IFD0, image0, IFD1, image1, ... would be required for the case of writing a TIFF-F file which uses the minimum set of TIFF-F. For the more general case, the TIFF-F recommended "guidelines" will still apply. (The reason for this stricter ordering is to allow low-memory devices to receive fax images. Some other implementations have all IFDs at front) Discussion: Steve Zilles: (a) will this break existing computer-based TIFF writers? (b) it is sometimes useful to put all IFDs at the front so that files can be selectively byte-served. (floor): experience suggests first page is wanted first. Zilles: but what do we want second? Q: why do we want to do this change? A (Ritsuo Shirahama): in case of the paired format used by WIDE, the amount of memory needed to process image is an absolute minimum, there being no need to buffer IFDs. Q: Has a survey of TIFF writers been conducted to determine whether or not they conform to this proposal? A: Existing TIFF-F writers have not been checked. Readers have been checked. A (Neil Joffe?): some legacy TIFF writers put the IFDs at the end. *** Agreement: The consensus in the meeting was to adopt the WIDE proposed ammendment (i.e. (i.e. the stricter IFD/image ordering will apply when writing minimum TIFF-F files). Question about RTCs: does WIDE include this? -- deferred to the list (b) TIFF-FX Internet draft: File Format for Internet Fax Steve Zilles presented an overview of the latest draft on slides. The goal is to achieve a set of nested file formats: TIFF-FX has been revised with this end in mind. The nesting consists of WIDE, TIFF-F and TIFF-FX, covering the following features: WIDE: MH (T.4) b/w TIFF-F: MMR (T.6) b/w TIFF-FX: JBIG (T.82) b/w halftones T.42 JPEG (T.81) colour photo T.43 JBIG (T.82) 'office' colour T.44 MRC Mixes photo/office colour Sect 2: this contains an introduction to TIFF and related Fax concepts, and may be moved to a separate MIME registration document. Sect 2.2, fields for all applications: This has the agreement of the WIDE authors for defining a baseline feature set. GlobalParametersIFD field is new Sect 3: approx correspondence to WIDE, except: - BadFaxLines - CleanFaxData - ConsecutiveBadFaxLines These are not required in minimum set (not usually applicable for Internet-carried fax) The draft has been re-structured to better represent the nested structure of minimum TIFF -> TIFF-F -> TIFF-FX (multiple modes). Summary: The draft's current structure addresses: (a) WIDE (minimum TIFF-F) (b) TIFF-F (c) ITU fax extensions It provides a common structure for the document parts relating to these levels of functionality. Zilles suggested the document is ready to edit as a proposed standard. However, few people in the room had actually read the document. The TIFF authors are directed to complete the integration between TIFF-F and TIFF-FX in the TIFFPLUS document, while also incorporating the latest agreements from this meeting. Q (Neil Joffe): Wants streamable file type for low-memory senders on the Internet. What is the position of the TIFF-FX authors? A: The ordering proposals begin to address this. MRC allows striping of data. But there is a fundamental conflict between low-memory writer and low-memory reader requirements in the context of the TIFF file structure. Further discussion of this point was moved to the list as TIFF file format changes will be needed to resolve low-memory reader/writer requirements conflict. 2. Service integration issues Presented by Dave Crocker, using the WIDE proposal document as a base for discussion. The thrust of this part of the discussion was to present ideas which characterize a user's perception of what constitutes a fax service, with a view to evaluating the extent to which this perception can/should be satisfied by a version 1.0 proposed Internet fax standard. (a) Service goals - Fax emulation -- within reason (fax service emulation, not fax protocol emulation) - Store and forward (asynchronous, not user-observed delivery) - Integrate fax and email user bases - Use of Internet mail technical base in "natural" fashion. A profile of classic Internet email for use as fax transport. (b) Addressing Requirements: - Can reply to message - Can use with mailing lists Leads to requirement that address is not in message body. - Subaddressing This is a somewhat recent ITU feature, which is showing up suprisingly quickly in the installed base. This suggests that any Internet fax address syntax must be able to represent sub-addressing. Sub-addressing is use of address information in addition to the base telephone number to target a specific recipient. **** There is a need to discuss, on the mailing list, the issue of multiple sub-addresses "to the same destination". - Syntax which explicitly identifies an address as a fax number? - Form of telephone phone number to be used? Q (Dan Wing?): Should we follow VPIM spec wrt addressing? A (DC): Yes (in narrow and wide senses) Email address candidates: - Number as mailbox? (user-based knowledge for network routing) GK: this form can also be used for network-based routing knowledge. - Number in service name? (network-based routing knowledge) WIDE proposal: - 12345-67890@domain Steve Patterson - +12345678901@domain Q: use some kind of explicit fax type label? George Pajari has commented on the mailing list that there is not always a country code in a telephone number. - "Pause" ("-") duration - should be specified? - how does gateway process the number wrt its own location, etc. Larry Masinter - pattern proposal posted to mailing list. (floor): what is the end-users' problem that we are trying to solve? -- this should guide our discussion. Claudio Allochio will post to the list a description which shows the consequences of different choices of address format. **** Continuing discussion is moved onto the list. (c) Reliability/acknowledgements E-mail now has DSN, semantically equivalent to fax message confirmation (MCF). Also under way is notification of a message being processed by its recipient (e.g. read). E-mail has no re-transmission concept (in absence of confirmation) -- same as fax. Issue of when confirmation should be sent by gateway: when gateway receives message? when gateway receives confirmation? What about multiple gateway chains? - Experience with s/f fax indicates that having fax confirmation decoupled (delayed) from original call must be an end-to-end confirmation, or troubles result. (But where is the "end".) **** Agreement: The group in the meeting supported the idea that confirmation should be sent when it arrives at final mailbox or fax machine." Should use of DSN be required? - sending from email: selection of DSN notification request is by user. - sending from a fax, use of DSN notification request might be: (a) user chooses?, or (b) DSN use is mandatory?, or (c) implementation dependent choice? There was a feeling in the room that this was an implementation issue. DC: language is needed in the specification to explain this issue, without saying whether or not DSN is mandatory, but defining the fashion in which it must be used if it is used at all. **** Issues of who pays the cost of providing a confirmation callback and the issue that callback may not be possible (due to lack of return path information) should be discussed on the mailing list. (d) Security [[[and identification]]] Identification - label without authentication Authentication - "of undisputed origin". Integrity - usually for free with authentication. Privacy - proof against snooping. Authorization to use service (Denial of service protection?) Larry: FROM of email to correspond roughly to required content of fax identification header line (per US law). DC: proposed that identification behaviour be provided equivalent to fax identification behaviour, but no strong cryptography requirement for authentication, etc. (floor): Need to identify sending fax machine for purposes of sending notification back. DC: On-ramp may need to adjust the FROM:, TO:, SENDER:, and other fields to get notification to work properly. (Some speculation about likely legal requirements for identification, ref. US requirement for all faxes to identify sender). Identification: there are difficult issues need to be addressed. A call was made for information about range of legal requirements of identification in different regions to be posted to the list. DC, Privacy over the Internet: The Internet is perceived as not secure and easily tapped. Therefore the Internet should be assumed to be less secure that telephone system, and therefore IF we are to emulate perceived current fax security THEN we must implement encryption of message data over the Internet, or some other privacy mechanism (e.g. control the path). JR: the user will make the choice. DC: suggested that the authentication and privacy issues would need to be considered in any fax standard, but would probably not be fully specified by this working group. **** Further discussion will take place on the mailing list. Authorization: DC: There is currently no widely-used Internet standard for authorization. Steve Zilles: Authorization to use the service consists of two separate issues: (a) mechanisms to control access to the facilities provided, given the identity of a party who is trying to use them, and (b) mechanisms to verify the identity of a party who is trying to use them. Issue (a) must be dealt with within the service protocol, but issue (b) could be handled by reference to some external authentication mechanism. DC: may pay attention to security without necessarily solving it. Need to explore very wide range of issues related to security, and interactions between them. No specific consensus was reached by the meeting. **** Further discussion is moved to the list. 3. News No time available 4. Session service No time available Closing presentation: Relation to ITU work. James Rafferty briefly summarized the relation of the IETF work to that ongoing in ITU. He noted that some ITU members have expressed interest in using TIFF-F for store and forward fax via e-mail. Some of the current IDs, notably on TIFF, are likely to be submitted to the October ITU SG8 meeting. Cross reference between ITU and IETF documents is now permitted, so this would provide a way for ITU to incorporate IETF work (and vice versa) and reduce the chance of producing conflicting standards. Continued communication and cooperation between the two standards bodies is desirable.