---------------------------------------------------------------------- 1 Agenda bashing ---------------------------------------------------------------------- Claudio Allocchio introduced the agenda and it was accepted. ---------------------------------------------------------------------- 2 Status of pending Draft Standards ---------------------------------------------------------------------- It is about update of file format for internet fax (TIFF-FX: RFC 2301). Lloyd McIntyre presented changes to TIFF-FX specification (draft-ietf-fax-tiff-fx-07.txt), which were not formally distributed before the meeting. It was confirmed the changes are purely editorial. Sooner or later, it is announced for the distribution. The version 06 is now under Draft Standard consideration. With these changes, document will go forward in IESG without new last call. ---------------------------------------------------------------------- 3 Targeted for Draft Standard ---------------------------------------------------------------------- ---------------------------------------------------------------------- 3.1 Service ---------------------------------------------------------------------- It is about update of RFC 2305. Kiyoshi Toyoda introduced draft-ietf-fax-service-v2-02.txt, which mentions simple mode fax in internet mail. He presented revisions, which are mainly about non-normative issues. All are the minor editorial changes. It was confirmed that the following three normative references need to move to Draft Standard. - File format (RFC 2301) - Fax address format (RFC 2304) - Format extensions for DSN reports (RFC 1894) ---------------------------------------------------------------------- 3.2 Addressing ---------------------------------------------------------------------- It is about update of RFC 2303 and 2304. Claudio Allocchio introduced draft-ietf-fax-minaddr-v2-01.txt, which mentions minimal GSTN address format in internet mail (RFC 2303). He presented the revisions, which are minor clarification and a correction to ABNF. He also introduced draft-ietf-fax-faxaddr-v2-01.txt, which mentions minimal fax address format in internet mail (RFC 2304). He presented clarification of sub-address format (ITU-T T.33, T.30). Digits are only allowed in it, and '#' and spaces are not allowed. No multiple sub-addresses are allowed. He also introduced RFC 2846 (full addressing), which includes many pre-defined address elements and IANA registration procedures. Kiyoshi Toyoda introduced interworking report about RFC 2304, in order to elevate RFC 2304 to Draft Standard. There are two attendees:TOYOCOM and MGCS. There was a test configuration in which a IFAX device sends document to an offramp gateway through internet and the gateway sends to G3 fax or onramp fax for sub-address. All syntax defined in RFC 2304 were tried for test. The tests satisfied the items of "RFC 2304 interworking configuration Matrix" which has delivered to Fax Connect 2 (http://www.imc.org/imc-faxconnect/). It was confirmed that "formal" report is necessary for request of Draft Standard consideration. ---------------------------------------------------------------------- 4 Internet-Drafts ---------------------------------------------------------------------- ---------------------------------------------------------------------- 4.1 Gateway issue ---------------------------------------------------------------------- Katsuhiko Mimura presented draft-ietf-fax-gateway-protocol-00.txt. It mentions internet fax gateway protocol which has two functions: onramp and offramp. a) Addressing How offramp gateway extract fax number from mail address was introduced. A question was raised about provision for separate identification of country code, to allow receiving system to isolate local dialing part. The standard defines only fully qualified numbers with leading '+', so system should know to expect a country code. Other numbers do not have a defined meaning, and is not appropriate to try and specify behaviour in these cases. Should a receiver be expected to know its own local dialing codes? Beyond scope of this specification, but implementations needs to takeaccount of these issues. Suggested text is as follows: "Gateway MUST process the mailbox string and convert it to a local dial string according to the local dialing rules". b) File format conversion There is difference between the format of internet fax (TIFF-FX) and the one of GSTN fax. Some conversion is necessary. c) Drop duplications There are the same messages to multiple mail boxes at the same domain. There is some confusion about exactly what this means. There is the following descriptions in the draft: An offramp gateway MUST drop the duplicate mail by confirming whether Message-ID is the same as old one. This is to avoid the duplication of the transmission to same facsimile device over GSTN. It is suggested that the MUST be softened to MAY or SHOULD. Message IDs cannot be guaranteed to be unique (notwithstanding e-mail specification). Also, it is noted that mailing lists can change text without changing message-ID. A question was raised on what is scope of duplicate detection (period of time). d) Automatic retransmission An offramp gateway may automatically retry to send fax data in the case of delivery failure. Questions were raised on whether or not specification to link any retransmissions to the original ones is provided and whether or not retransmissions must be constrained to local legal operating requirements. There was a comment that retransmission specification is not described in ITU-T T.30. It was commented to add a note that retransmission issues may be particularly sensitive, and must be handled with care, because the sending user will not generally be present to deal with any transmission failures. e) Error behaviour Retransmission depends on the contents of errors. It is necessary to distinguish between T.30/fax "soft" errors (for which retransmission may be appropriate -- e.g. line busy) and "hard" errors (for which retransmission is not appropriate -- e.g. paper out). He suggests this issue should be addressed in another draft. f) Return notice When mail to fax is multicast or broadcast and a delivery error happens, there is an issue about when and how return notice should be done. He suggests this issue should also be addressed in another draft. g) Onramp gateway Onramp gateway functions fax to mail. It is noted that current version is based strictly on simple mode. But, WG may need to decide whether we wish to be restricted to this scope, or whether to address extended /full mode issues from the start. h) Addressing with FAX terminal There is the following description in the draft: An onramp gateway MUST have the function that onramp gateway analyze destination address from address data sent by facsimile device over GSTN. Direct and indirect addressing are discussed. Direct uses given number directly as mailbox name, and uses prefix to select destination domain. Indirect may use number mapping table to select destination mailbox and domain. i) Authorization by DTMF It is necessary that authorization should be done at onramp gateway. GSTN users send UserID and Password to onramp gateway in some ways such as sending DTMF after dialing. j) Next version -01 He promises to announce the next version soon. ---------------------------------------------------------------------- 4.2 Implementers Guide ---------------------------------------------------------------------- Vivian Cancio presented draft-ietf-fax-implementers-guide-02.txt. It is a guide for simple and extended modes. She explained changes to current drafts. There are mainly corrections to the examples (MDN and MTA/ESMTP) and the addition of the case of receiving multiple TIFF attachments, in which it is recommended extended mode recipient returns an error when it is unable to decode any of the attached files. A question was raised on a reasonable mechanism for a sender to determine whether or not an MDN/DSN has been sent *after* the TIFF image has been processed. This information may be useful to automatic status logging systems. ---------------------------------------------------------------------- 4.3 FFPIM ---------------------------------------------------------------------- Graham Klyne presented it. it consists of the following three drafts. a) draft-ietf-fax-ffpim-00.txt b) draft-ietf-fax-timely-delivery-00.txt c) draft-ietf-fax-content-negotiation-02.txt Timely delivery draft will be moved forward, because now DELIVERBY has become RFC 2852. Concerning content negotiation, he explained the overview again. There are a number of technical issues in the negotiation draft that really should have some group discussion on the list, such as use of 'Original-recipient", content-id, cache-control, "content-alternative" header, MDN extensions. They are highlighted in the draft. Further suggestions and comments are invited. For now, it is noted that there may be security concerns (message tracing) if negotiation is allowed with recipients not named by the sender. The distinction between 'definitive' and 'informative' introduces some unintended complexities, and the "sender decides" model for quality decisions seems to be adequate. But it is noted that it should not be done for now. ---------------------------------------------------------------------- 4.4 TIFF-FX extension issue ---------------------------------------------------------------------- Lloyd McIntyre presented it. It is not formally distributed. But it is draft-mcintyre-fax-tiff-fx-extension-00.txt in http://www.imc.org/ draft-mcintyre-fax-tiff-fx-extension. >From the contents of the Adelaide meeting in March, MRC:multi-strip background and foreground layers and Annotation are deleted, because they are immature. They are candidate for future draft. Therefore, the extension includes new field values and/or relaxed constraints (higher resolutions and MRC with more than 3 MRC layers) and new fields and/or profiles(more than one profile within document and JBIG2). He presented these new field values like 600x600dpi, relaxed constrains like more than 3 MRC layers, JBIG2 etc. He also explained overview of relation of changes to current TIFF-FX profiles. It was confirmed that the enhancements require new tags to be approved by Adobe, for which a formal WG request may be required. ---------------------------------------------------------------------- 5 Issue from VPIM WG ---------------------------------------------------------------------- Glenn Parsons, who is a co-chair of VPIM WG, introduced the internet fax related issues discussed in VPIM WG. ---------------------------------------------------------------------- 5.1 Partial Non-Delivery Notifications (draft-ietf-vpim-pndn-00.txt) ---------------------------------------------------------------------- It describes the interaction between systems sending multipart Internet main to systems that cannot render parts of the sent message. In particular, it describes an extension to the Delivery Status Notification mechanism. ---------------------------------------------------------------------- 5.2 Critical Content of Internet Mail (draft-ietf-vpim-cc-00.txt) ---------------------------------------------------------------------- It mentions method for sending user Agent (or sender) to indicate body parts that the sender deems critical. "Content-Criticality" entity on each body parts is proposed and there are "critical", "important" and "ignore". For example, receiver rejects message if critical part is undeliverable and notify sender. The issue of backward compatibility is also introduced. ---------------------------------------------------------------------- 5.3 Content Hint for Internet Mail (draft-ietf-vpim-hint-00.txt) ---------------------------------------------------------------------- It mentions method of identifying message as belonging to a (small number of) enumerated message classes, such that it does not require scanning the entire message, etc. Top-level "Content-Hint" header is proposed and there are initial types like "voice-message", "fax-message" and "video-message". There are security considerations. Some concerns are raised and careful discussion is needed. ---------------------------------------------------------------------- 6 ITU issue ---------------------------------------------------------------------- ---------------------------------------------------------------------- 6.1 Letter from Q4/SG8 ---------------------------------------------------------------------- Hiroshi Tamura attended ITU-T Q4/SG8 meeting in June and introduced it. There were the following three items to be discussed at Q4 meeting. - Implementers guide from FAX WG - Request issues - Terminal mode (Refer the following section 6.2.) T.37 will refer implementers guide after draft-ietf-fax-implementers-guide-0x.txt is completed. There were the same requests as the ones WG received last year. a) Enhancement of capability mechanism b) Fax processed status information c) MDN enhancements A question was raised on capability mechanism. In fact there was little discussion in June Q4 meeting. Draft response to ITU-T was introduced. For a), WG's content-negotiation draft is one solution. For b), there is no direct discussion now and fax-specific information may be difficult in MDN/DSN. For c), some clarification is in implementers guide, but may not be enough. Through the introduction, there were comments that PNDN (Partial Non-Delivery Notifications), which VPIM WG discusses, may solve b) and c) partly. (Refer the following section 7.) It was emphasized that any interested people can propose in IETF and IETF is welcome to direct contribution at IETF WGs by ITU people. There was also introduction of WG plan for new SGx meeting in November. It includes notification of WG status, response to request issues and input to newly assigned RFCs. They will be decided in ML until November. ---------------------------------------------------------------------- 6.2 Terminal mode ---------------------------------------------------------------------- Toru Maeda presented terminal mode discussion that is taking place in ITU-T Q4/SG8. The target of terminal mode is easiness to implement and color fax. He commented simple mode and EIFAX as follows. Simple mode is not good for FAX terminal because of no capability exchange and no confirmation. EIFAX is not good for FAX terminal because of complexity for embedded system. ---------------------------------------------------------------------- 7 Confirmation of Milestone and charter ---------------------------------------------------------------------- Claudio Allocchio introduced. WG confirmed milestones and there were no objections. There was also call to all members to get draft reviews quickly. Some members commented that PNDN issue should also be discussed in FAX WG. Whether to take it and add in WG charter will be discussed in ML. AD agrees to it. ---------------------------------------------------------------------- 8 Closing ---------------------------------------------------------------------- Meeting was closed.