NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Claudio Allocchio <Claudio.Allocchio@garr.it>
Hiroshi Tamura <tamura@toda.ricoh.co.jp>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Ned Freed <ned.freed@mrochek.com>
General Discussion:ietf-fax@imc.org
To Subscribe: ietf-fax-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-fax/
Previous IETF efforts developed specifications for simple and extended Internet mail-based facsimile service profiles, tailored to interwork with the world of T.30 facsimile. This extension effort will take care of differential routing between classic Internet mail and timely deliveries, and consider with particular regard universal messaging issues and its relation with Internet mail.
The WG will produce a final increment of specification for supporting a "full" equivalence of T.30 service over Internet mail. Technical work for this effort includes timely delivery, [image] feature selection/negotiation, document privacy, and integrated specification of Full-mode Facsimile Profile of Internet Mail (FFPIM).
For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required:
o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services
o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet
The working group will also consider the requirements for gatewaying Internet Mail (as profiled for facsimile Simple, Extended modes and FFPIM) with T.30 Facsimile.
The working group will specifically take note of quality of service issues and might decide to produce an Implementer's Guide.
T.30 facsimile carries expectations of message privacy, so that FFPIM must specify a basic facility via the Internet. Although T.30 does not provide document integrity, users frequently believe that it does. Consequently the Faxext working group will also seek specification of a basic authentication facility over the Internet.
T.30 facsimile provides for receiver capability identification to the sender, allowing a sender to provide the "best" fax image the receiver can handle. The Faxext working group will consider mechanisms to provide similar functionality for fax images transferred by e-mail.
Additional areas of discussion will be: Annotated fax messages and universal messaging issues as they relate to FFPIM, as well as schema and TIFF extensions required to support the new JBIG-2 (T.88) compression method.
The working group will continue the excellent pattern of coordinating activities with other facsimile-related standards bodies, in particular the ITU, VPIM and other WGs, and with using work from related IETF efforts.
Done |
|
Submit Internet-Draft of data specifications |
Done |
|
Submit Internet-Draft of terminology document |
Done |
|
Submit Internet-Draft of messaging-related specification |
Done |
|
Submit Internet-Draft of operational constraints document |
Done |
|
Submit terminology document to IESG for publication |
Done |
|
Submit data specifications to IESG for consideration as a standards track document |
Done |
|
Submit messaging-related specification to IESG for consideration as a standards track document |
Done |
|
Submit operational constraints document to IESG for publication as an Informational document |
Jul 01 |
|
Submit final draft for FFPIM to IESG for publication |
Jul 01 |
|
Submit final draft of gateway requirements |
Jul 01 |
|
Submit final draft of TIFF-fx extensions |
Jul 01 |
|
Submit final draft of schema for TIFF-fx extensions |
Jul 01 |
|
Submit second draft of Fax status information |
Jul 01 |
|
Submit second draft of Goal for Terminal Mode |
Jul 01 |
|
Submit second draft of Protocol for Terminal Mode |
Dec 01 |
|
Submit final draft of Fax status information |
Dec 01 |
|
Submit final draft of Goal for Terminal Mode |
Dec 01 |
|
Submit final draft of Goal for Terminal Mode |
· A Simple Mode of Facsimile Using Internet Mail
· File Format for Internet Fax
· Minimal GSTN address format in Internet Mail
· Minimal FAX address format in Internet Mail
· Content Negotiation for Internet Messaging Services
· Implementers Guide for Facsimile Using Internet Mail
· Full-mode Fax Profile for Internet Mail: FFPIM
· Timely Completion for Internet Messaging Services
· Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
· Internet FAX Gateway Functions
· Guideline of optional services for Internet FAX Gateway
· SMTP Service Extension for Content Negotiation of Internet Fax
RFC |
Status |
Title |
RFC2301 |
PS |
File Format for Internet Fax |
RFC2302 |
PS |
Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration |
RFC2303 |
PS |
Minimal PSTN address format in Internet Mail |
RFC2304 |
PS |
Minimal FAX address format in Internet Mail |
RFC2305 |
PS |
A Simple Mode of Facsimile Using Internet Mail |
RFC2306 |
Tag Image File Format (TIFF) - F Profile for Facsimile | |
RFC2542 |
Terminology and Goals for Internet Fax | |
RFC2530 |
PS |
Indicating Supported Media Features Using Extensions to DSN and MDN |
RFC2532 |
PS |
Extended Facsimile Using Internet Mail |
RFC2846 |
PS |
GSTN address element extensions in e-mail services |
RFC2879 |
PS |
Content feature schema for Internet fax |
RFC2880 |
Internet fax T.30 Feature Mapping |
Minutes of Internet fax WG (fax) at IETF-51 London
19:30 - 22:04, August 6, 2001
Chaired by Hiroshi Tamura and Claudio Allocchio
Reported by Graham Klyne, Claudio Allocchio and Hiroshi Tamura
----------------------------------------------------------------------
1 Agenda bashing
----------------------------------------------------------------------
Hiroshi Tamura welcomed the participants and asked for eventual modifications to the proposed agenda. As ther were no specific change requests, the agenda was approved.
----------------------------------------------------------------------
2 Status of Draft Standard consideration
----------------------------------------------------------------------
----------------------------------------------------------------------
2.1 Addressing
----------------------------------------------------------------------
- draft-ietf-fax-minaddr-v2-04.txt
- draft-ietf-fax-faxaddr-v2-04.txt
These two documents were approved by IESG on July 19th 2001 and now are in the RFC editor queue for publication. In the Applications Open Area meeting there was the suggestion to find a way to explicitly state that the specification draft-ietf-fax-minaddr-v2-04.txt is a general specification which is valid in ANY application encoding GSTN (telephone) numbers into an e-mail address. Also, the FAX wg suggested to add such note, possibly in the abstract. The editor will investigate with the ADs if an IESG note in appropriate.
The same needs to emphasize the generality could apply also to other FAX wg documents, like the draft-ietf-fax-content-negotiation-05.txt. The wg suggested the editors to consider it, too.
----------------------------------------------------------------------
2.2 TIFF-FX
----------------------------------------------------------------------
- draft-ietf-fax-tiff-fx-09.txt
- draft-ietf-fax-tiff-regbis-02.txt
The documents approval are slowed down by a series of problems which were detected during the process. ITU-T also needs a quick resolution of the problems as stated in the communication letter from ITU-T SG16 meeting.
The problem, detected at first as an IPR issue raised by Adobe in January 2001, was escalated to IESG and IAB which examined carefully all the aspects, and identified also some additional compatibility issues.
John Klensin (IAB) reported to the WG.
The TIFF Story, actually had many different steps and chapters. During the analysis of the problem, there were many iterations between the IESG and the IAB which at the end pointed out two Separate Issues:
- WG responsibility for interoperability
- IPR questions
At first, the interoperability. This is the "Main IETF Goal" to be achieved, and its meaning should span forward and sideways. The main principles are that:
- Implementations of one protocol must interoperate
- Implementations of related protocols should interoperate
- Deviations must make sense and have a clear rationale behind
In its original goals (and as stated in the charter) the fax wg had to create a Fax Model that should interoperate with fax fabric and interoperate with e-mail fabric. More over, it should avoid having to choose between the two fabrics. For this reason TIFF was chosen because it was widely believed that it would be interoperable with existing viewers and editors, especially viewers expected to be used with image/tiff in e-mail. This should also be the start of the "global messaging service".
The question now is: can we meet all these constrains?
Basic TIFF (TIFF 6.0) does not support colors, and different resolutions, but it is compliant with the existing TIFF readers, and e-mail User Agents (MUAs). It was not enough to accommodate color and higher quality ITU-T encodings, consequently extensions were needed. These extensions were specified in TIFF-FX, and ITU-T decided to adopt and reference it.
However, TIFF-FX functionality goes beyond that of Basic TIFF. There are already de facto extensions to the basic TIFF specifications which are publicly available, and widely deployed within both TIFF readers and MUAs. All the de facto extensions are currently used in MIME type "image/tiff" and most have no interoperability problems. The extensions introduced into TIFF-FX are a superset, many are not viewable by most Ifax devices and an even less amount by software applications.
To avoid interoperability issues arising from the extension, RFC2302 (currently, the draft-ietf-fax-tiff-regbis-02.txt) revised the image/tiff MIME type to add application parameters. The image/tiff application parameters serve to alert viewers to the presence of the TIFF-FX superset. However, many readers do not pay attention to MIME application parameters. Inconsistent use of application parameters is the main reason for the incompatibility, although there may be other reasons.
The IESG and IAB would like the WG to review and document, as a condition for advancing the TIFF-FX specification to Draft Standard:
- whether the choice of "interoperation with e-mail" versus "interoperation with fax" is the right one
- whether a mostly-fax-only TIFF variation is the right choice
- whether the MIME sub-type should be image/tiff or image/tifffx (or equivalent)"
- whether the interoperability profile is right given these issues
- and any other similar tradeoffs that might have been made without full evaluation.
John Klensin then reported on the IPR issues, which invove both Adobe and Xerox.
Adobe: the solution appears to be to have Adobe include the new TIFF-FX encodings in TIFF-7, but Adobe has not committed to produce TIFF-7 and it is not clear what produces that commitment. Moreover, even if they do TIFF-7, they will not commit to including the TIFF-FX features until at least Xerox releases rights to the MRC encoding techniques for all uses of TIFF, not just TIFF-FX, and apply formally to Adobe to have the features and tags included. At last, but not the least, no one at this IETF can commit Adobe.
Xerox: Xerox is willing to release rights for all uses in TIFF if Adobe will adopt them and include them in TIFF-7. But no one here can commit Xerox either.
It thus seems that a viable solution is currently in a deadlock waiting for somebody to make the first move.
***** Consensus at the meeting *****
Some of the original reasons for using TIFF were lightweight, extensibility, its ITU compatibility, and the ability of most MUAs to understand its image/tiff MIME type. The TIFF-FX extensions were needed to meet the current set of ITU-T encodings, but, the extensions introduced compatibility issues with the existing image/tiff MIME type and IPR issues.
A proposal was made to address the compatibility and licensing issues with a slimed-down core specification (a "safe" subset). Portions outside of the core set could be addressed separately and assigned a different MIME type.
Attention remained focused on the reduced TIFF-FX subset and whether the subset should be consistent with Basic TIFF and the original image/tiff registration (i.e. RFC1528) or a new set determined by encodings that are readable by current prominent viewers.
Considering the above, the members present agreed to "safe subset" of TIFF-FX for Draft Standard consideration.
Final consensus will be established on the IFAX ML.
***** Additional summary and next steps *****
A summary of identified TIFF-FX options and WG next steps follows:
[[[Some of them were not directed at the meeting.]]]
[[[Other options are already discussed in ML.]]]
- Level of interoperability should be established by conducting a test of RFC2301 (currently, draft-ietf-fax-tiff-fx-09.txt) using existing mail user agents (MUAs) and tiff capable software applications such as PhotoShop and other tiff viewers. The software viewer test may be accommodated by saving the RFC2301 image/tiff stream to a file with .tif or other appropriate tiff extension.
- An interoperability report should be generated and used to document the set of image/tiff interoperable TIFF-FX encoding parameters, such as coder, resolution, paper size and color components.
- Select a TIFF-FX option to move forward, some of the identified options were:
1. Full TIFF-FX: - retain the currently defined TIFF-FX draft without modification of the encoding set and define both a new MIME type (e.g. image/tifffx or image/tifx) and a new file extension (e.g. .tifx or .tfx). The new MIME type and extension would prevent interoperability issues with image/tiff.
2. Interoperable TIFF-FX: - use the new interoperability document to generate a TIFF-FX subset that is image/tiff interoperable and retains the current image/tiff MIME type and file extension.
3. Interoperable and non-Interoperable TIFF-FX: - use the new interoperability document to generate two subsets, a) Interoperable TIFF-FX, as per #2, and b) non-Interoperable TIFF-FX, which is composed of the remaining encoding subset. As with Full TIFF-FX, define both a new MIME type and a new file extension for the non-Interoperable TIFF-FX.
- The selected TIFF-FX option and the reason must be documented and communicated to the ITU. Also, IPR issues should be communicated.
- Both the resulting specification and the Implementors Guide should contain explanation of the interoperability issues and countermeasures.
Because, some manufacturers already have implementation that deal with more than Profile S with image/tiff, such as Profile J and C, according to RFC2301.
- The resulting specification may be resubmitted to the IESG for Draft Standard consideration.
----------------------------------------------------------------------
3 Targeted for Draft Standard
----------------------------------------------------------------------
----------------------------------------------------------------------
3.1 Service
----------------------------------------------------------------------
- draft-ietf-fax-service-v2-03.txt
The document was sent to IESG on June 23rd with Interworking report (published on June 18th); We added the request to wait for publication until all normative dependencies are elevated to Draft Standard. We also received AD comments which led to a new version circulated on our ML only.
In particular, there is the reference to RFC1894 (DSN), and a reference to RFC2301. We should thus solve TIFF issues, too. Regarding DSN, the editors are preparing the new I-D.
----------------------------------------------------------------------
4 Targeted for Informational
----------------------------------------------------------------------
----------------------------------------------------------------------
4.1 Implementers Guide
----------------------------------------------------------------------
- draft-ietf-fax-implementers-guide-07.txt
The document was sent to IESG on Apr 10th and we had the letter from ITU confirming that T.37 would refer the Implementer's guide. The IETF Last Call on July 26th until August 26th.
It was clearly noted that also in this case we should quickly check if there are specific references to RFC2301 which might be an issue.
----------------------------------------------------------------------
5 On-going Internet-Drafts
----------------------------------------------------------------------
----------------------------------------------------------------------
5.1 Gateway issue
----------------------------------------------------------------------
- draft-ietf-fax-gateway-protocol-05.txt
- draft-ietf-fax-gateway-options-03.txt
Katsuhiko Mimura described the main differences in the final version of gateway documents. "draft-ietf-fax-gateway-protocol-05.txt" defines the minimum requirements for Internet FAX Gateway. It defines a basic Function for the Internet FAX Gateway, whereas "draft-ietf-fax-gateway-options-03.txt" provides Information for Guideline of optional services.
A member objected that the security recommendations are unclear. It is not explicit if the document suggest S/MIME as a MUST solution, or just a possibility. Claudio Allocchio reminded that also the traditional problem of "credentials" (Sender's or Gateway's) needs to be clarified, or at least clearly stated. Maybe it's just fine if the wording is softened - "could be" instead of "is". The WG agreed to issue a WG Last Call, considering the above points.
----------------------------------------------------------------------
5.2 FFPIM
----------------------------------------------------------------------
- draft-ietf-fax-ffpim-01.txt
The specification has been updated today, and mailed to WG ML. The main actions were to remove all editor comments, to add citation and pointer to draft-ietf-fax-esmtp-conneg-00.txt, to add an appendix explaining the Direct Mode and to focus on need for "direct" configuration, including the use of ESMTP Timely and ESMTP Conneg.
Apparently no further substantial work need to be done. In particular about direct mode, some text was added to clarify that it needs some unusual e-mail configuration to work properly. A short discussion if all goals were met did not discovered any missing item. The question is to be repeated to the ML before progressing to WG LC. The only question raised was if this document should reference the "terminal mode" documents or not at all. Dave Crocker and others believe that there should not be any reference, provided the fact that there is still no consensus if the terminal mode documents should go forward.
- draft-ietf-fax-content-negotiation-05.txt
The WG last call ended without comments, thus we sent the request for IETF last call to IESG on July 21st 2001. There were no further comments from the WG at the meeting.
- draft-ietf-fax-esmtp-conneg-00.txt
This specification allows content negotiation to take place at the SMTP level (i.e. between MTAs). In particualr, this service extension is intended for direct SMTP transfers and It can be used within an enterprise's internal network.
A new keyword ("CONNEG") is added to the possible EHLO values, and the server responds with a report of the content capabilities of the device or system that embodies the target RCPT-TO address.
A revised version is expected by November 2001, aiming to the WG Last Call.
- draft-ietf-fax-timely-delivery-03.txt
After some discussion with the ADs, Graham Klyne produced a new version. In it, the feature of allowing a message to be immediately rejected for timely delivery will be dropped. Past experience with this kind of feature is poor (X.400), and the use cases will generally not represent an exacerbation of the congestion. As soon as the document is published, we agreed to go for the WG Last Call.
----------------------------------------------------------------------
5.3 Terminal mode issue
----------------------------------------------------------------------
- draft-maeda-faxwg-terminal-mode-goals-00.txt
- draft-maeda-faxwg-terminal-mode-protocol-00.txt
- draft-maeda-faxwg-fax-processing-status-00.txt
Toru Maeda, the author, were absent.
There were a number of comments on the list about this topic. As he was not here, we will defer further discussion to the ML. However, Claudio Allocchio asked for some opinion of the presents. We added terminal mode to our milestones in the last Minneapolis meeting.
A member commented "draft-maeda-faxwg-fax-processing-status-00.txt" could be used not only in terminal-mode but in existing ones.
A member objected, because RFC2542 already adresses goals, so the new goals document is largely redundant (apart from comments which are more like a protocol specification), and asked if there is an intention to be more specific about *requirements*? He also asked if anybody would object if we did not pursue this document. As the author was not present, we deferred further discussion to the ML.
----------------------------------------------------------------------
5.5 TIFF-FX extension issue
----------------------------------------------------------------------
- draft-ietf-fax-tiff-fx-Extension-1-02.txt
(drtyre-tiff-fx-extension1-02.txt)
- darft-mcintyre-feature-schema-extension1-00.txt
After remembering that all the issues in these documents are related to the previous discussion about TIFF and TIFF-FX issue, and that IPR problems should be clearly investigated also for these proposed extensions, the presentation described the further JBIG2 extensions.
Toward the end of the Schema extension presentation, a member ask how many had read the draft, there was no clarifications as to which draft was being referenced. There was acknowledgement from a member who had reviewed the Schema draft. The requestor then asked whether the work should be continued, without much response. He suggested the lack of interest could lead to a lack of implementations.
A member commented that the extension of resolution is important for implementers. Because RFC2301 only support up to 400x400dpi.
No conclusions were made.
----------------------------------------------------------------------
6 PWG IPP Fax status report
----------------------------------------------------------------------
Lloyd McIntyre reported on behalf of the PWG IPP group. It was made clear that the activity presetnte is carried on within the IEEE unbrella, and also that the IESG did not accepted this activity as a possible IETF one, answering that these activities were already covered by our WG.
There was consensus from the WG that there must be a better coordination with these external efforts, in order to avoid any possible incomaptible products to be developed.
----------------------------------------------------------------------
7 Miscellaneous
----------------------------------------------------------------------
Finally the fax charter was updated on the IETF web pages (July 26th 2001). An applause came from the audience.
----------------------------------------------------------------------
8 Confirmation of milestone
----------------------------------------------------------------------
Here is the updated list of milestones.
Apr 2001 Submit final draft of Implementers Guide for Simple and Extended mode to IESG for publication as Informational.
Done. (see draft-ietf-fax-implementers-guide-07.txt sent to IESG on June 2001)
Jun 2001 Submit final draft for content negotiaton to IESG for publication as Proposed Standard
Done. (see draft-ietf-fax-content-negotiation-05.txt sent to IESG on July 21st 2001)
Sep 2001 Submit final draft for timely delivery to IESG for publication as Proposed Standard
Sep 2001 Submit final draft for FFPIM to IESG for publication
Sep 2001 Submit final draft of gateway requirements
Nov 2001 Submit final draft of TIFF-FX extensions
Nov 2001 Submit final draft of schema for TIFF-FX extensions
Nov 2001 Submit final draft of ESMTP-CONNEG for Last Call
[[[The author of the followings was not here.]]]
Jul 2001 Submit second draft of Fax status information
??? 2001 Submit second draft of Goal for Terminal Mode
??? 2001 Submit second draft of Protocol for Terminal Mode
Dec 2001 Submit final draft of Fax status information
??? 2001 Submit final draft of Goal for Terminal Mode
??? 2001 Submit Final draft of Protocol for Terminal Mode
----------------------------------------------------------------------
9 Close
----------------------------------------------------------------------
The meeting was closed.
Agenda
SMTP Service Extension for Content Negotiation of Internet Fax
FFPIM Upgrade
IFax File Format Issues
Internet FAX Gateway
Status of IPP FAX
The TIFF Story
Revised Points of Service-v2-04
TIFF-FX Extension Set 1 (draft-mcintyre-tiff-fx-extension1-02)
TIFF-FX Extension Set 1 (draft-mcintyre-schema-extension1-00)