IFX Mail Archive: IFX> FW: Minutes of IETF Fax WG from IETF

IFX Mail Archive: IFX> FW: Minutes of IETF Fax WG from IETF

IFX> FW: Minutes of IETF Fax WG from IETF 49 [long note]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Dec 28 2000 - 14:04:09 EST

  • Next message: MAEDA toru: "IFX> Test"

    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