Hi folks,
Below is the full text of the IETF Fax WG minutes. A number
of items are of interest to IPPFAX.
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
------------------------------------------------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
This archive was generated by hypermail 2b29 : Thu Dec 28 2000 - 14:05:09 EST