IFX Mail Archive: IFX> FW: notes from the ietf FAX wg meetin

IFX Mail Archive: IFX> FW: notes from the ietf FAX wg meetin

IFX> FW: notes from the ietf FAX wg meeting at IETF 51

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Aug 14 2001 - 17:08:12 EDT

  • Next message: Hastings, Tom N: "RE: IFX> TIFF contact person at Adobe"

    Here is the statement about the IPPFAX presentation that Lloyd made at the
    Internet FAX WG at the IETF meeting:

     5.4 PWG IPP Fax status report

    Lloyd reported on behalf of the PWG IPP group. (see slides for a detailed
    description of documents and status). Is 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

    Also included in the Internet FAX WG minutes are the discussions about:
    A. Interoperability problems with the image/tiff MIME type and some existing
    TIFF readers.

    My summary/questions:

    It seem likely that TIFF/FX will need a new MIME type, such as
    image/tiff-fx, instead of image/tiff; application=faxbw and =faxcolor, at
    least for the profiles that deployed TIFF readers can't handle (J, C, L, and

    If a new MIME type, will the MIME type have parameters to indicate the
    profile or profiles that are inside? For example:

       image/tiff-fx; profile=c,f

    What MIME type will our Universal Image Format (UIF) use?

    Can it be new parameter values for parameters on the (new) image/tiff-fx
    MIME type, such as:

       image/tiff-fx; profile=uif-c,uif-f

    B. The Adobe IPR issue with the IETF over Atobe's license to the IETF to use
    TIFF in producing TIFF/FX.

    My summary/questions:

    Adobe needs to resolve their issues with the licensing of TIFF to the IETF
    and Xerox needs to resolve their issues with Adobe on licensing MRC for use
    in TIFF.

    Will the IEEE-ISTO need to get a license from Adobe for the IPP FAX WG's
    Universal Image Format (UIF) which builds on TIFF/FX?

    Would Adobe grant us one?

    The Internet FAX WG is carrying on discussions about the notes on the
    ietf-fax@imc.org mailing list, if you want to know more.


    -----Original Message-----
    From: Claudio Allocchio [mailto:Claudio.Allocchio@garr.it]
    Sent: Thursday, August 09, 2001 09:26
    To: ietf-fax@imc.org
    Cc: klensin@jck.com
    Subject: notes from the ietf FAX wg meeting at IETF 51


    here are the notes from the meeting we had on monday evening. Sorry for
    being late, but (apart from an "editing accident" which deleted the first
    version of the notes) I tried to be as most precise as possible, as some
    issues are very important to be understood also on the mailing list by
    those who were not present at the meeting.

    Please drop comments and integrations to our ML. Thanks again o Graham
    Klyne who took the base notes.

    Claudio Allocchio

    Short notes of the ietf FAX WG meeting - IETF 51 London, UK

    At the meeting start the co-chair welcomed the participants, and asked for
    eventual modifications to the proposed agenda. As ther were no specific
    change requests, the agenda was approved.

    Tamura-san announced that Maeda-san was unfortunaely not present at the
    meeting, thus we would add more time to the discussion of the TIFF issues.

    2. Status of Draft Standard consideration
      2.1 Addressing

    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 need to emphasize the generality could apply also to other FAX wg
    documents, like the draft-ietf-fax-content-negotiation-05.txt ones and the
    wg suggested the editors to consider it, too.

     2.2 TIFF-FX

    The documents approval is slowed down by a series of problems which were
    detected during the process. ITU-T also needs a quick resolution of there
    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
    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 shoud also be the start of the "global messaging service".

    The question now is: can we meet all these constrains? Is TIFF the right
    choice to accomplish them?

    Basic TIFF does not support colors, and different resolutions, but is it
    compliant with the existing TIFF readers, and e-mail User Agents (MUAs).
    However, if we want to cover also the "extensions" that ITU-T is
    requesting for fax service (e.g. colors, resolutions, etc...) Basic TIFF
    is not enough, and it will need extensions. These extensions were
    specified into TIFF-FX, and ITU-T decided to adopt and reference it.
    However TIFF-FX is already beyond Basic TIFF.

    Actually there are already de facto extensions to basic TIFF
    specifications which are publicly available, and widely deployed within
    both TIFF readers and MUAs. All there de facto extensions are currently
    used in MIME type "image/tiff" and there are not interoperability
    problems. However the extensions intriduced into TIFF-FX are a superset,
    and thus only some Ifax devices can correctly handle them.

    So, the IESG and IAB would like the WG to review and document, as a
    for advancing the TIFF 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 this should be image/tiff or image/tifffx (or equivalent)
     - hether the interoperability profile is right given these issues
     - and any other similar tradeoffs that might have been made without full

    The IAB believes now it is late in the game, so these reviews may not
    change anything, but they are important for learning, and context, and
    predicting problem areas and determining whether the meta-qualifications
    for Draft Standard are met.

    John Klensin then reported on the IPR issues, which invove both Adobe and

    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 encoding techniques for all uses of
    TIFF, not just fax and Xerox (or maybe IETF) 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.

    Thus it seems a viable solution currently in a deadlock waiting for
    somebody to make the first move.

    At last, we have the ITU issue, who is referencing our documents. But ITU
    approach to IPR is different, and a licence issued to the IETF might not
    fully apply also to ITU. There is a strict need to coordinate with ITU
    also on these IPR matters, to avoid future problems. It is in fact clear
    that what was released to IETF is not automatically released to ITU (and

    The discussion of the problem and the WG conclusions.

    The original reasons for using TIFF were lightweight, extensibility and
    its ITU compatibility, and it ability to be understood as a MIME type
    image/tiff by most of the MUAs.

    The extensions are actually needed to meet the new specification which
    ITU-T had done, but the new extensions also introduce impatibility and IPR
    possible clashes.

    Dave Crocker suggest as a first prroximation solution to skim down the
    core specification to a "safe" subset, and pursue the other issues
    separately, with a separate MIME type.

    Scott Forshee suggested also that other focus has been on JPEG-2000
    specifications , and work is progressing on a different (planned) MIME
    type including MRC capabilities. However igher level features of
    JPEG-2000 are generally not widely deployed. He proposed the wg to
    reconsider JPEG-2000 as an alternate to TIFF-FX. Moreover, part of the
    reason for Adobe's objections are to keep the use of TIFF freely

    There were objections to this proposal, stating the JPEG-2000 is not yet
    in good shape, has not yet a MIME type registered, too, and its wide
    deployment is not existing at the moment.

    A discussion followed, considering if one should simply use the version
    label into MIME typ definition to define which level of TIFF is being
    used, or just a totally new type.

    Claudio Allocchio suggested that image/tiff should be used onlyfor minimum
    interoperable features and anything else should have a different name and
    label; this will have to happen for TIFF-7 in any case.

    Lloyd McIntyre suggested as simple solution to revert to previously
    registered version of TIFF, i.e. TIFF 6.0, excluding also any widely
    deployed de facto extensions. There was a discussion on this, and Scott F.
    stated that TIFF 6.0 was issued in 1992, with updates via by technical
    notes, which are widely implemented. Thus RFC 2302 is OK with the way
    that Adobe and others use TIFF. We should focus on the TIFF-FX spec, to
    cut it back to non-controversial features.

    At this point Claudio A. asked the wg members present at the meeting if
    anyone strongly oppose the approach proposed by Dave C.?

    Larry Masinter and Johm Klensin suggested that to be concerned with what
    is practised is more important than compatibility with what is registered.
    "The Right Thing to do is look at reality and try to get it right".

    The wg expressed consensus on the above approach. This consensus need to be
    confirmed by the mailing list.

    Claudio A. summarised the conclusions to be reported into the minues, and to
    facilitate the understanding of the approach by anybody including those not
    present at the meeting:
      - we must consider for interoperability test of RFC2301 also existing
        mail user agents (MUAs), and they should be able to read image/tiff
        bodyparts generated bu Ifax devices. Interoperability is the choice.

      - we must also consider interoperability with existing tiff capable
        software, e.g. saving the image/tiff to a file and reading it with ...
        Photoshop, and other tiff files readers.

     - we should produce a new interoperability report, and based on this
       we should detail the revision of RFC2301, to fit any feature which
       proved to interoperate in all above cases, even if not included in
       basic TIFF 6.0 specification.

     - thus existing tiff-fx Ifax devices go beyond this, as they my generate
       extensions which do not interoperate correctly with the above

     - thus we should define how to create a NEW format (both for files and
       for MIME readers) with a different name which may be tiff-fx, or totally
       different, to make clear to implementers and devices that "this is an
       extended new format" (even if based on tiff in origin).

     - the reason for removing from RFC2301 revision some features is
       because they do not interoperate on the global service, even if they
       proved to interoperate among Ifax implementaions.

     - the "recuded set" specification will be submitted for Draft Standard

     - we should, at the same time, produce a new "extended specification"
       docuement, which includes the extensions existing in RFC2301 and
       dropped in the Draft Standard document, and might also include the
       further extensions proposed for "full mode". This document(s) should
       also define a different MIME type registration for this extended
       specification. This new specification should go as Proposed Standard

     - we need to investigate if it is possible to declare RFC1301 "Updated"
       by the new Draft Standard document, at least until the new "Proposed
       Standard" document obsoletes RFC2301. ADs suggestions are expected.

     - we should carefully inform ITU-T of the reasons of this choice.

     - the Draft Standard version of the specification would also not have
       (apparently) IPR issues related, and the extended mode one should
       carefully consider IPR problems while being specified.

    Furthermore, we should explain, probably in the new extended document, and
    probably into the implementers guide, the compatibility reasons which led
    us to this choice. In fact some manufactures already have more than
    profile S(simple mode) implementations with MIME type image/tiff, for
    example, Profile C(color) with image/tiff, according to existing RFC2301
    and RFC2302.

    After more than one hour, we closed the topic and moved forward.

    3 Targeted for Draft Standard
      3.1 Service

    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 Mailing
    List only.

    In particular, there is the reference to RFC1984 (DSN), and a reference to
    RFC2301. We should thus solve TIFF issues, too.

    4 Targeted for Informational 1 min (25min)
     4.1 Implementers Guide

    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 (if
    specifically refer to TIFF-FX features which could be dropped into the
    Draft Standard skimmed version.

    This very same revision and check is needed for the whole set of other

    5 On-going Internet-Drafts
     5.1 Gateway issue

    Mimura-san 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. (See slides for
    detailed differences)

    Larry M. 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 A. 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 as the first comment into the Last Call.

     5.2 FFPIM

    The specification has been updated today, and mailed to the 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 and some other 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.


    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.


    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.


    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
    aggreed to go for the WG Last Call.

     5.3 Terminal mode issue

    There were wuite a number of comments on the list about this topic. As the
    author is not here we will defer further discussion to the ML. However
    Claudio A. asked for some opinion of the presents. We added to our
    milestones the documents in the last Minneapolis meeting.

    Larry M.objected that RFC2542 already discusses 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.4 PWG IPP Fax status report

    Lloyd reported on behalf of the PWG IPP group. (see slides for a detailed
    description of documents and status). Is 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

     5.5 TIFF-FX extension issue

    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 (see slies) described the further JBIG2

    Larry M. asked how many in the room read the draft: One person. As such
    the question was raised if we should continue the work, if there is
    interest in doing it or not, provided that at a certain point the
    specification will have to undego interoperability tests, and the lack of
    interest could lead to a lack of implementations. There was at the moment
    no conclusion to ths question, as we need to check first the status of the
    TIFF issue evolution.

    6 Miscellaneous

    Finally the fax charter was updated on the IETF web pages. (July 26th 2001).
    An applause came from the audience.

    7 Confirmation of milestone

    Here is the updated list of milestones *** (please double check it !!!) ***

    Apr 2001 Submit final draft of Implementers Guide for
                    Simple and Extended mode to IESG for publication as
                    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
                    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
    These two need further work - see discussion

    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

    The meeting ended at 22:04


    Claudio Allocchio             G   A   R   R
                            Project Technical Officer
    tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
    fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

    PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09

    This archive was generated by hypermail 2b29 : Tue Aug 14 2001 - 17:09:17 EDT