Current Meeting Report
Slides
2.1.3 Internet Fax (fax)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
22-Oct-01
Chair(s):
Claudio Allocchio <Claudio.Allocchio@garr.it>
Hiroshi Tamura <tamura@toda.ricoh.co.jp>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Mailing Lists:
General Discussion:ietf-fax@imc.org
To Subscribe: ietf-fax-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-fax/
Description of Working Group:
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.
Goals and Milestones:
| 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 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 |
| Nov 01 | | Submit final draft of TIFF-fx extensions |
| Nov 01 | | Submit final draft of schema for TIFF-fx extensions |
| 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 |
Internet-Drafts:
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 |
| 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 |
| RFC3191 | DS | Minimal GSTN address format in Internet Mail |
| RFC3192 | DS | Minimal FAX address format in Internet Mail |
Current Meeting Report
IETF-FAX WG meeting notes - S. Lake City, Dec 10th 2002
The meeting starts with the Claudio Allocchio (CA) presenting the apologies of Tamura-san to the WG for not being able to be present at the meeting this time, and reporting that similar apologies were received from other WG members which could not attend this meeting due to travel restrictions still in place at their organisations and companies. Two of the documents editor are among the absent ones, Toyoda-san and Maeda-san, but their comments were sent in prior to the meeting and will be reported later on.
CA reminds the group that the meeting is on multicast, thus also a large number of absent people can follow the meeting. Unfortunately it looks like the multicast in one-way only, thus the only way the remote members can interact with the meeting is sending in e-mails to the list.
The proposed agenda in modified (see below) in order to allow John Klensin to join the meeting, thus postponing item 2 after item 7.
................................................
1. Agenda bashing
3 Targeted for Draft Standard
3.1 Service
- draft-ietf-fax-service-v2-05.txt
CA reports on behalf of Toyoda-san.
The draft has been modified according to the suggestions of the Aread Director, in particular:
- the long summeay has been changed into a real short abstract
- the "scope" is changed to "introduction" and it includes the paragraph about intellectual property rights and keywords
- the formating of the appendix B is fixed
The I-D has 2 normitive references
- RFC2301 update (File Format for Internet Fax)
- RFC1894 (An Extensible Message Format for Delivery Notifications - DSN)
With regards to RFC2301 update the iscussion is delayed after point 2 is dealt with. On the other hand Ned Freed (NF) confirms that the processing of DSN document is being finally done, and it is expected to have it approved by the end of January 2002. NF also suggests the WG not to delay document submission and procesing because of other normative documents waiting for approval, but the correct procedure should be to approve these documents, go through the IESG and let the RFC editor to correctly manage the dependencies queue for publication. The working group confirms that the WG last call for this document can now be done. Futher confirmation from the mailig list is expected.
4 Targeted for Proposed Stanadard
4.1 Content Negotiation
- draft-ietf-fax-content-negotiation-05.txt
The document already went throught the IETF last call wich ended without further comments on Nov 16th 2001. The WG thus confirms the document as it is, and asks further confirmation on the mailing lists. We expect the IESG to process it into its queue. The expected publication date is by March 2002.
4.2 Timely Delivery
- draft-ietf-fax-timely-delivery-05.txt
Graham Kline (GK) confirms that the document is ready. The WG last call ended on Dec 6th 2001 without any futher comment. The WG express consensus to progress the document to the IESG for IETF last call. This will be confirmed on the mailing list.
4.3 Fax Gateway
- draft-ietf-fax-gateway-protocol-06.txt
CA reminds that the IETF last call was issued on Nov 26th, and is expected to close at the end of January 2002. If there will be no comments, the the documents will enter the IESG queue.
5 Targeted for Informational
5.1 Fax Gateway
- draft-ietf-fax-gateway-options-04.txt
Also for this document the IETF last call was issued on Nov 26th 2001, and it will end in late January 2002. CA reminds that the WG asked for the IETF last call even if not formally needed as the topic of FAX Gateways has a large number of implication and impact on existing implementations, and thus the document describing the service should have the largest consensus as possible.
6 On-Going Internet-Drafts
6.1 FFPIM
- draft-ietf-fax-ffpim-01.txt
Dave Crocker (DC) apologies for the delay in eding the final version of the document and promises the issue the final version by X-mas 2001. The WG thanks for the X-mas gift... As the document is out, the WG will proceed with WG last call (to be confirmed on the list).
6.2 ESMTP-CONNEG
- draft-ietf-fax-esmtp-conneg-01.txt
Ca refers again on behalf th Toyoda-san. Te I-D was revised according to the comments reveived by Dan Wing, in particular:
- he term "target" and "server" is unified to "target"
- the backslash is not allowed in CONNEG ESMTP lines
- CONNECG-capable clients MUST be able to process successfully CONNEG lines as long as 512 characters (RFC2821).
- the ABNF syntax has been added
- a sample of EHANCHEDSTATUSCODE is added
Thus the milestone date for submission (was November 2001) has been confirmed, and the new milestone for the WG last call is set to January 2001. The WG agrees on the changes, which need to be confirmed on the mailing list.
6.3 Terminal mode issue
- draft-maeda-faxwg-terminal-mode-goals-01.txt
- draft-maeda-faxwg-terminal-mode-protocol-01.txt
- draft-maeda-faxwg-fax-processing-status-01.txt
Maeda-san again could not be present at the meeting, but he sent a message to the mailing list apologising for no work at all and no comments at all on the above documents. CA reminds that at the London meeting the WG agreed that:
- is was not the case to decide there if to drop the documents from the WG charter, and to wait until the next meeting to see if there were further progress and comments on them
- to let the editor have a chance to be present at the meeting to discuss this issue again.
However, not haing received any comment and not having seen any activity on them sine a long time, CA suggests the WG to drop these documents from the current charter. A discussion starts, where DC suggests that it does not seem tha case to keep documents in the boilerplate so long without any discussion and progress on them, and NF and JK remind that if interest arises again from the WG and the mailing list, the I-D can be take on board again, CA asks the presents if there is consensus to drop these documents. No objections to the proposal are made. The mailing list will be asked to confirm the decision to drop these documents, at least for the time being.
6.4 TIFF-FX extension issue
- draft-ietf-fax-tiff-fx-extension-1-01.txt
- darft-mcintyre-feature-schema-extension1-00.txt
Lloyd McIntyre (LM) very briefly informs the WG that in his opinion it makes no sense to work on these documents now, at least until the TIFF-FX issue is set and there are the relevant new documents in a stable status. As such he proposes not ti discuss them now, and wait until the issue is solved. The WG express consensus on this proposal, which should be confirmed on the mailing list. CA also reminds tha a number of comments were received from the WG and implementors on the chances that some of the options will ever be implemented and asks the editor to pay attentions to these comments, in order not to introduce features which has very little change to ever exist in reality. The WG joins in the suggestions an LM agrees on it.
7 Miscellaneous
- draft-allocchio-gstn-01.txt
CA brielfly summarizes the idea behind this I-D. During a discussion after the London meeting with the ADs, it was realised that the specifiations on how to write a "dial-string" (which includes in itself also any E.164 and generic telephone number) into a text string was existing, but it was spread all over a number of different RFCs along the Standard Track. This was creating problems for the new documents editors, and was making the task of the IESG quite hard in trying to keep the new specification coherent with existing standards. It was also realized that nobody ever did the attempt to check that all existing specification where absolutely coherent, and nobody ever wrote a single, short and unique reference document collecting the pieces available around the other documents. CA thus collected the existing information, and searched the existing specification to check for coherence. The resulting document was published and discussed into ietf-fax, vpim, enum and apps-discussion mailing lists, receiving a number of immediate comments, suggestions for clarification and also a syntax error correction. Revision -01 of it is available since some time. CA urges the WG to further comments on it, before the documents is progessed. Larry Masinter (LL) asks if the intention is to progress it to BCP or Standard track, and NF answers that the intention is to be in Standards Track, at first as Proposed (even if a large part of it comes from Draft Standard docs), and the moving it forward. CA suggest the end of January 2002 as a possible date for the IETF last call for it. It is also noted that the ABNF syntax error present in ths I-D is existing in the published version of RFC2846. The editor noted it down fo correction when RFC2846 will be submitted for revision.
- ITU-T
CA reports on behalf of Tamura-san. Since the London meeting, no ITU-T meeting was held, thus the status in ITU-T itself did not change. The last letter from SG16 meeting in June 2001 included their concerns for the status of RFC2301 (TIFF-FX) update, the need for reference to the Implementers Guide in T.37 and the issue about the Terminal Mode documents.
Currently the ITU-T SG16 also expressed informally concerns about the e-mail they recevied from Scoff Foshee (SF) from Adobe, raising IPR issues on the use of Adobe license for TIFF within TIFF-FX and thus ITU-T documents. Tamura-san already reported back to ITU-T informally that the WG the IESG and IAB are working on this issue and they will receive ou formal answer in the next letter due by the February 2002 SG16 meeting. More over in this letter (which will be prepared by the end of January 2002) we will inform SG16 that the Implementers guide is done and is currently in the RFC editor queue, and the the WG (if confirmed on the mailing list) will drop the Terminal Mode documents, due to the lack of progress and discussion on them. John Klensin (JK) confirms that the IAB and IESG have reached a position on the issue (see net paragraph for details).
2. Status of Draft Standard consideration
2.1 TIFF-FX
- draft-ietf-fax-tiff-fx-11.txt
- draft-ietf-fax-tiff-regbis-03.txt
- draft-ietf-fax-tiff-fx-reg-01.txt
CA introduces briefly the topic with a summary of the situation. A number of e-mail has been exchanged between the WG, the WG-chairs, the IESG and IAB and SF from Adobe about the topic. After a long disucssion among the IAB, the IESG and the WG-chairs we reached the consensus that the issues and claims expressed from Adobe seems at least incoherent with the records of the IETF meetings and the mailing lists of the WG and of the IETF. For these reasons the IAB and IESG believes that the WG should continue progressing the documents, as decided on the mailing list after the London meeting, and submit them for appropriate consideration to the IESG as soon as they appear to be ready. JK and NF confirmed this position and invite the WG to proceed on its plans.
CA thanks the IAB and IESG for their clear suggestion, and reminds briefly that the WG at the London meeting expressed the opinion to separate in 2 documents the TIFF and TIFF-FX specifications, but this was changed lately on the mailing list as what has been recorded as "option 5", i.e.:
Single TIFF-FX specification with 2 Content-type
Lloyd then exposes the current status of the above documents, and the progression plan for "option 5" (See also his slides)
There will be a single TIFF-FX specification, which will be progressed. A decision needs to be made on how exactly to reach the needed Draft Standard level. See later in these notes for a detailed discussion.
There will be 2 different MIME content-types:
image/tiff for profiles S and F, which is compatible with all current viewers
image/tiff-fx for profiles J, C, L, M, and any future one. It might also allow profiles S and F.
There will be 2 corresponding file extensions (even if this is not a "strictly standard" decision, the WG believes that it is good practice to define:
.tif (.tiff) for profiles S and F
.tfx for all the other profiles
As a consequence there is a need for 3 documents:
- a revised draft-ietf-fax-tiff-regbis which updates image/tiff content type
- a new registration draft registering image/tiff-fx MIME sub-type and the corresponding file extension (.tfx)
- a revised draft-ietf-fax-tiff-fx which defines which MIME type to use, depending on the used profiles, and updates the rest of the specification as appropriate.
In order to test implementations and interoperability, the following "Test Deliverables" are proposed to the WG:
- A new image-tiff-fx and .tfx validation test both for MIME transport and viewers
- A new viewer validation for profile S and F and image/tiff
The proposed timemelines are:
During this December 2001 meeting:
- make available the 3 new drafts (action done)
- reach consensus on the content of the drafts
- reach consensus on the drafts progressions paths
- agree on the whole Option 5 plan.
Before December 31st 2001:
- update drafts as per the comments received during this meeting and from the mailing list
- correct inside the image/tiff registration the magic number ERROR
Mid January 2002:
- issue the WG last call for image/tiff registration as BCP
- issue the WG last call for image-tiff-fx registration ad Proposed Standard
Mid February 2002
- issue the IESG last call for image/tiff
- issue the IESG last call for image/tiff-fx
- finalize the interoperability test plan, and identify participants
At the March 2002 IETF meeting
- to have image/tiff published as BCP
- to have image/tiff-fx published as Proposed Standard
- to have the test report available
Mid June 2002
- issue the WG last call for image/tiff-fx registration and tiff-fx file format specification as Draft Standards
July 2002 IETF meeting
- issue IESG last call for image/tiff-fx registration and tiff-fx file format specification as Draft Standard
Mid Semptember 2002
- to have image/tiff-fx registration and tiff-fx file format specification approved by IESG as Draft Standards
NF and JK confirmed that normally the 6 month "wait" period between a Proposed Standard publication and its progression to Draft Standard is based on the date of IESG approval, and that the ADs will take particular care to speed up document processing, based on the existing dalay caused by external reasons.
CA asked if there were objections to the proposed plan, and as none was raised, the WG expressed is consensus to proceed as proposed. The mailing list will ba asked to confirm this decision.
LM presented then the status of the 3 drafts.
In image/tiff registration:
- tiff-regbis-03 removes S. Zilles from the authors lists
- tiff-regbis-04 is needed to correct tiff magic number error
In image/tiff-fx registration
- version 01 registers image/tiff-fx MIME sub-type and .tfx extension for profiles J, C, L, M and future extensions, and may be optionally used ALSO for profiles S and F
In itff-fx (version 11):
- the new MIME content-type and extension are added
- a detailed specification on when to use image/tiff and image/tiff-fx is provided
- application parameters are removed from the specification as they might be a source of interoperability problems
- S. Zilles is removed from the author's list
After the presentation, the WG expressed consensus on the current content of the 3 I-Ds, and the mailing list is required to confirm this.
As a general point, Larry Masinter commented that the WG already has a number of issued documents, and a number of documents which were already processed (WG, IESG last calls, RFC editor queue), and that now that a new image/tiff-fx is introduced, the WG needs to check tham all. The only 2 Draft Standard already issued (RFC3191 and RFC3192) do not mention the MIME type thus are ok as they are. The implementers guide needs to be revised, but it is already on the RFC editor queue, for example. NF commented that in such a case the WG is required to check where to make the modifications, and the, depending on the impact of the modifications themselves, the IESG will decide if consider acceptable the modification while in the RFC editor queue, or is some recycling is needed. In case tha latter solution is choosen, then the IESG will again speed up the document progress as possible.
CA asked ALL the editors of current drafts to carefully check their documents (and the member of the WG to help them cross-checking, too) for places where image/tiff and image/tiff-fx split might be involved, and provide the needed corrections and updates ASAP. Again the procedures for the Implementers guide (i.e. the quickiest possible path) will be taken also for these other docments. NF confirms that the IESG will define the exact procedure to be folowed.
As again the question about the possible impat of external IPR issues could have on the tiff-fx specification, JK reminded that there is an appropriate boilerplate text to be included into documents where there "might" be IPR issues, and that this text will point the reader to the appropriate IETF web pages and repository there the IPR issues and claims are kept up to date. IAB is also considering wther this boilerplate should be included in ALL published RFCs, and suggest thus to do so whenver the WG feels it might help in progressing a document.
Then the Draft Progression Path Concurrence is again revised:
- image/tiff revised registration goes from I-D to BCP
- image/tiff-fx goes from I-D to Proposed Standard, waits 6 months, and is updated as I-D which goes then for Draft Standard
The WG expresses consensus on the proposed paths, and the mailing list is asked to confirm it.
The issue of the tiff-fx image file format specification progression path is more complex, as the alternates are:
a) move from I-D to Draft Standard (waiting when dependencies are done)
b) move from I-D to Proposed Standard (recycling) and the issue the updated I-D and more this to Draft Standard.
As the WG does believe this is a question for the IESG (i.e. which of alternate a) or b) should be followed), NF will take it to the IESG which will advice the WG.
As a conclusion, the WG expects the whole set of documents about TIFF and TIFF-FX to be done within September 2002.
8 Confirmation of milestones
- FFPIM
Final draft due for X-mas 2001
- ESMTP-CONNEG
Nov 2001 final draft submitted (Done)
Jan 2002 IETF last call
- TIFF-FX extension
on hold until relevant new documents are at a stable state. Maybe February 2002.
- Terminal mode
Documents dropped, and removed from milestones lists
- RFC2301 revision documents:
(see above the detailed timelines)...
AOB and Close:
the meeting closes at 10:20pm
Slides
Agenda
'ietf-allocchio-gstn-01'
ESMTP-CONNEG-01
SG16 ITU-T Issues
Service-v2-05
TIFF-FX Draft Standard Roadmap