NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00
Chair(s):
Claudio Allocchio <Claudio.Allocchio@garr.it>
James Rafferty <jraff@brooktrout.com>
Hiroshi Tamura <tamura@toda.ricoh.co.jp>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@innosoft.com>
Mailing Lists:
General Discussion:ietf-fax@imc.org
To Subscribe: ietf-fax-request@imc.org
In Body: In Body: subscribe
Archive: http://www.imc.org/ietf-fax/
Description of Working Group:
Facsimile (fax) serves as a reliable, inexpensive global communications service. As the Internet becomes pervasive, integrating fax and Internet services is appealing in terms of cost savings and opportunities for functional enhancements. This working group will pursue a review and specification for enabling standardized messaging-based fax over the Internet. It will also develop informal requirements for faxInternet gateways as a first step toward devising standards for session-based fax over the Internet. The messaging-based (via e-mail) service will be specified first, since it should produce useful results for the least additional technical effort.
Facsimile/Internet integration can be considered in terms of two user service models, in order of increasing technical difficulty:
o Messaging (as with electronic mail) having high latency o Session-based, for observed delivery, with or without capabilities negotiation
Within these models, a real-time (telephone network replacement) based service is considered to be a subset of the session-based model.
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 dominant fax communications mode in use today is a session-based connection operating in real-timeover the dial up telephone network; hence an Internet-based direct replacement service would potentially save significant long- distance telephone charges. However, it is believed that from a technical standpoint this service is the most difficult task to produce over the Internet, whereas an messaging-based service is likely to be the simplest. In addition, it is anticipated that the two services will ultimately utilize at least some common technical components. Therefore, this working group will initially review and specificy messaging-based fax over the Internet, using as much existing practice as possible.
The working group will take the following steps to specify a core fax-related messaging service over the Internet:
Terminology: Develop a shared set of terminology and definitions, to ensure a common framework for participants having differing backgrounds in Internet protocols and facsimile telecommunication.
Data Representations: Review existing facsimile- related Internet data specifications and accept, modify, replace or augment them, with particular attention to their encapsulation, such as via MIME.
Addressing and transport: Specify the mechanisms for addressing and receipt notification for facsimile data carried via Internet mail.
For session-oriented operation, the following specification will be created, as a basis for further work:
Operational constraints: Detail the operational constraints for achieving session-oriented use of messaging, tailored for timely delivery with the sender waiting for delivery confirmation. Existing protocols and data specifications will be used as much as possible.
The working group will take note of quality of service issues.
The working group will coordinate its activities with other facsimile- related standards bodies.
Goals and Milestones:
Jan 97 |
|
Submit Internet-Draft of data specifications |
Jan 97 |
|
Submit Internet-Draft of terminology document |
Feb 97 |
|
Submit Internet-Draft of messaging-related specification |
Feb 97 |
|
Submit Internet-Draft of operational constraints document |
Apr 97 |
|
Submit terminology document to IESG for publication |
Apr 97 |
|
Submit data specifications to IESG for consideration as a standards track document |
Jun 97 |
|
Submit messaging-related specification to IESG for consideration as a standards track document |
Jun 97 |
|
Submit operational constraints document to IESG for publication as an Informational document |
Internet-Drafts:
· 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
· Timely Delivery for Internet Messaging Services
· Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
· Internet FAX Gateway Protocol
Request For Comments:
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-49 San Diego
15:30 - 17:45, December 11, 2000
Chaired by Claudio Allocchio and Hiroshi Tamura
Reported by Graham Klyne, Claudio Allocchio and Hiroshi Tamura
All slides at the meeting are found at the following URL:
http://www.imc.org/ietf-fax/
----------------------------------------------------------------------
1 Agenda bashing
----------------------------------------------------------------------
Hiroshi Tamura introduced the agenda and it was accepted.
----------------------------------------------------------------------
2 Status of pending Draft Standards
----------------------------------------------------------------------
----------------------------------------------------------------------
2.1 TIFF-FX
----------------------------------------------------------------------
Hiroshi Tamura introduced the current status. There are the two I-Ds.
- draft-ietf-fax-tiff-fx-09.txt (Obsoleting RFC 2301)
- draft-ietf-fax-tiff-regbis-02.txt (Obsoleting RFC 2302)
They are on IESG Last Call. The former should be Draft Standard, while the latter should be BCP. There were no comments at the meeting. The deadline by IESG Last Call is January 2, 2000.
----------------------------------------------------------------------
2.2 Addressing
----------------------------------------------------------------------
Hiroshi Tamura introduced the current status. There are the two I-Ds.
- draft-ietf-fax-minaddr-v2-02.txt (Obsoleting RFC 2303)
- draft-ietf-fax-faxaddr-v2-02.txt (Obsoleting RFC 2304)
The WG Last Call already completed and the WG requested Draft Standard consideration to IETSG. At the meeting. Ned Freed, who is our Area Director, told us that he is in process of reviewing them.
----------------------------------------------------------------------
3 Targeted for Draft Standard
----------------------------------------------------------------------
----------------------------------------------------------------------
3.1 Service (Simple mode)
----------------------------------------------------------------------
Hiroshi Tamura introduced the current status. There is the one I-D.
- draft-ietf-fax-service-v2-02.txt (Obsoleting RFC 2305)
There is a dependancy issue. It refers RFC 2301 (TIFF-FX), RFC 2304 (Addressing) and RFC 1894 (DSN format) normatively. RFC 2301 and 2304 are moving to Draft Standard by effort within Fax WG.
Claudio Allocchio addressed the DSN status. The editors are working these days to produce the new final I-D for Draft Standard in order to proceed. It also needs to collect data about which features are being used by current implementations. There is no MDM dependancy in this document.
----------------------------------------------------------------------
4 On-going Internet-Drafts
----------------------------------------------------------------------
----------------------------------------------------------------------
4.1 Gateway issue
----------------------------------------------------------------------
Katsuhiko Mimura presented the two I-Ds.
- draft-ietf-fax-gateway-protocol-02.txt
- draft-ietf-fax-gateway-options-00.txt
They address internet fax gateway protocol which has two functions: onramp and offramp.
With regard to "protocol-02" I-D, the main differences between the previous version and -02 are as follows.
- Change Title to "Internet FAX Gateway Functions".
- Only "Simple Mode" is applied.
- "Store and Forward" operational mode
- Add addressing and examples
"An offramp gateway MUST process the mailbox string and convert it to a local-phone according to the local dialing rules."
- Move the following items to "options-00" I-D.
[Offramp gateway]
- Drop Duplications
- Automatic re-transmission in the delivery error occurrence
- Error Behavior
- When send return notice
- keep log
[Onramp Gateway]
- Example of User authorization
- keep log
With regard to "options-00" I-D, it aims to "Informational" status. It does not intend to specify the actions for Internet FAX Gateway, but addresses guideline of gateway optional services and some examples.
There were several comments. How to "keep log" is not mentioned in I-Ds. It was suggested that description on security consideration is not enough and the expression "data mode is simple mode" is not suitable. The editor will modify the I-Ds, considering those suggestion.
Currently there are still some points to clarify in the gateway behaviour when non delivery notifications are involved. The I-Ds do not intentioanlly cover the multiple gateway crossing scenario, as it would be a too complex situation to keep into this schema.
The targat date of the final version is March 2001.
----------------------------------------------------------------------
4.2 Implementers Guide
----------------------------------------------------------------------
Hiroshi Tamura presented.
- draft-ietf-fax-implementers-guide-04.txt.
It addresses implementation guidance for RFC 2301, RFC 2305, RFC 2532, etc.
The main difference from the previous version is addition of encoding in ESMTP commands. '+' and '=' must be hex-encoded within optional ESMPT commands like ORCPT.
There were two minor disagreements. One is the content of "Subject" field in DSN and MDN. It was ambiguous and there were suggestive phrases. The ediotors will modify according to it.
The other is the description on "TIFF magic numbers". Disregarding values tends to lead to implementations that try to print random data, which is not a good thing. The advice given is not helpful. It should be checked against the original implementation reports that gave rise to this issue. Mike Moldovan wrote this part, he was asked to clarify it.
There were comments on "multipart/alternative". Simple mode is sent as image/tiff, not multipart/alternative, but receivers are urged to handle multipart/alternative properly. Many current email implementations don't handle multipart/alternative properly.
The WG believes it is very useful, and expecially needed now that products are being released. The final version will be done in January 2001. After the confirmation, the WG Last Call can be done.
----------------------------------------------------------------------
4.3 FFPIM
----------------------------------------------------------------------
----------------------------------------------------------------------
4.3.1 FFPIM itself
----------------------------------------------------------------------
- draft-ietf-fax-ffpim-00.txt
It is expired. ITU-T requests to re-submit it. The editor will do it.
----------------------------------------------------------------------
4.3.2 Content Negotiation and Timely Delivery
----------------------------------------------------------------------
Graham Klyne presented.
- draft-ietf-fax-content-negotiation-03.txt
- draft-ietf-fax-timely-delivery-01.txt
There were no slides. He introduced them very briefly. There were few comments recently. He suggested to us, more review is necessary.
With regard to Timely Delivery, there were lots of comments.
The discussion (as to satisfy a request from ITU-T) revealed that there are still some "last hop" considerations to be clarified before the documents can be finalised: we need to make clear with ITU-T which is the scenario, i.e. if the final "MUA" or "gateway" action is what they intend as final delivery. In such a case, the WG believes we need much more than this simple definitions, and probably new protocols between the final MTA and final MUA. It needs careful review, according to current E-mail architecture.
----------------------------------------------------------------------
4.4 TIFF-FX extension issue
----------------------------------------------------------------------
Lloyd McIntyre presented.
- draft-ietf-fax-tiff-fx-extension1-00.txt
It is the first formal TIFF-FX extension I-D, which the editors already presented at the previous two IETF meetings.
There are 5 extensions (E1 - E5) in the I-D.
E1 - extension of Resolutions
E2 - more than 3 MRC layers
E3 - SharedData
E4 - Profile T, JBIG2 b&w
E5 - JBIG2 and Color
There are required fields for the extension.
- GlobalParametersIFD containing fields that apply across more than one page (global)
- new TIFF-FXExtensions (identification mechanism for TIFF-FX extensions)
There is a recommended field for the extension.
- new MultiProfiles (signals use of extensions and/or more than one different encoding profiles in the processing of a single file)
There are optional fields for the extension.
- new SharedData (enables data to be shared between images, within pages and between pages)
- new T88Options fields (T88Options is similar to T4, T6 and T82Options that are used with MH (G3), MMR (G4) and JBIG1)
There is also an addition of "Compression = 12" for JBIG2.
He addressed that TIFF-FX Extension1 draft 01 is provided prior to the next meeting and Schema (RFC 2879) Extension draft 00 is done after TIFF-FX Extension1 draft 01, possibly prior to next meeting.
There were no comments at the meeting.
----------------------------------------------------------------------
5 PNDN (Partial Non-Delivery Notifications)
----------------------------------------------------------------------
Eric Burger presented.
- draft-ema-vpim-pndn-02.txt
It is the draft from EMA/VPIM. Current DSN only reports "all success" or "all failure". PNDN is useful if one needs per-part reporting. For example, if some critical parts delivered and others not, sender may want to consider successful parts delivered, report on unsuccessful parts. VPIM WG dropped PNDN, because critical content draft is satisfactory. PNDN format is based on DSN format and there are some extensions.
At the meeting, there were no supports to include it in Ifax. Fax WG decided not to continue with the specification. The I-D will be dropped.
----------------------------------------------------------------------
6 Issue from Other WGs
----------------------------------------------------------------------
- Enum itself
Richard Shockey, who is a chair of ENUM WG, presented what ENUM is.
ENUM is to map E.164 telephone number into internet service. The specific output is URI such as "mailto" and "sip", using DNS. It is described in RFC 2916 (E.164 number and DNS). He also introduced current I-Ds and the cooperation between ENUM WG and ITU-T SG2.
There was a comment that ENUM issue may be included in the IFAX implementers guide.
- draft-gallant-enum-ifax-00.txt
Andrew Gallant presented it. He requests to define the eventual Resource Records like t37ifax and t38ifax, which might be usuful for internet fax service. There was a comment about how simple or full mode is selected by ENUM service selection. "t37ifax" does not seem to be enough.
There was a question about whether this item is appropriate for FAX WG. At the meeting, there was no conclusion about it. But, the WG agreed it is be a viable option. Making things like the specification may be considered.
- draft-ietf-vpim-routing-01.txt
Glenn Parsons, who is a co-chair of VPIM WG, introduced it. He presented how VPIM WG uses the EMUN specification, which may be a possible solution also for i-fax. There are Complete Service and Basic Service. There were no comments.
----------------------------------------------------------------------
7 ITU issue
----------------------------------------------------------------------
Hiroshi Tamura and Toru Maeda attended ITU-T SG16 meeting in November and introduced the two letters.
The response is needed by the next SG16 meeting in May or June 2000.
One letter is about Full mode issue. It requests re-issue of FFPIM I-Ds. ITU-T understood the two I-Ds on content-negotion and implmenters guide are satisfactory for their requests. But, ITU-T still needs Fax status information in DSN and MDN, because the same level information as G3fax is important. ITU-T people will write a I-D about it.
The other letter is about Terminal mode issue, which Toru Maeda already presented very briefly at Pittsburgh meeting. T.37 Terminal Mode which supports the transfer of image data, capabilities exchange and confirmation for Store and Forward internet fax terminals having limited memory and small CPU power. It extends Internet fax capabilities to enable all features of Group 3 facsimile to be supported on the Internet using T.30 signals in capability exchange.
ITU-T requests:
- Is it able to add Terminal Mode in the charter of Fax WG for technical discussion in IETF?
- If the charter will not be able amended to discuss Terminal Mode in the Fax WG, IETF is requested to provide reasons for their decisions with required to whether proceed or not proceed the Terminal Mode in IETF.
There were no comments at the meeting. As some people did not read the letter yet, he encouraged us to read it carefully.
----------------------------------------------------------------------
8 Confirmation of Milestone
----------------------------------------------------------------------
Claudio Allocchio addressed this item. Updated milestone is as follows.
Jan 2001 Final draft for implementers guide
Jan 2001 WG Last Call
Jan 2001 Final draft for timely delivery
Mar 2001 WG Last Call
Jan 2001 Final draft for content negotiaton for fax
Mar 2001 WG Last Call
Mar 2001 Final draft of gateway requirements (two I-Ds)
Mar 2001 WG Last Call
(draft of Routing Considerations: We agreed to drop it.)
Mar 2001 -01 draft for TIFF-FX extension
Mar 2001 -00 draft for Schema extention
The followings were not addressed at the meeting, but they must to be confirmed sooner or later.
Jan 2001 Final draft of FFPIM
Mar 2001 WG Last Call
xxx 2001 final draft for TIFF-FX extension
yyy 2001 final draft for Schema extention
These are just plans. They are subject to change according to discussion.
----------------------------------------------------------------------
9 Closing
----------------------------------------------------------------------
Claudio Allocchio announced the FAX WG meeting was closed.
None received.