IFX Mail Archive: IFX> Short notes from IFax WG at IETF 54

IFX> Short notes from IFax WG at IETF 54

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Jul 22 2002 - 16:58:55 EDT

  • Next message: Rick Seeler: "IFX> RE: request for "PDFax" sample pdf"

    Hi folks,

    From Claudio Allochio (co-chair of IETF IFax WG).

    Cheers,
    - Ira McDonald
      High North Inc

    ---------------------------------------------------------------------
    Short notes from the Internet Fax WG meeting

    Hallo,

    here are my usual quick short notes about our meeting which was held
    jointly with the Voice Profile for Internet Mail WG, last Tuesday, July 1=
    6
    2002. Please drop in your comments/updates.

    After wecoming the partecipats to his home town Yokohama, Tamura-san
    proposed to change slightly the order of the agenda discussion, moving th=
    e
    CONNEG and FFPIM topics at the end of the Fax part of the meeting. The
    change was approved unanimously, in order to allow more space to these
    topics without compressing the other ones. We also received apologises
    from Ned Freed who could not be with us, but Patrick Falstrom is here
    replacing him.

    Tamura0san reported that the following documents are already in the
    RFC editor's queue:

    - draft-ietf-fax-implementers-guide-08.txt
    - draft-ietf-fax-content-negotiation-05.txt
    - draft-ietf-fax-tiff-regbis-05.txt
    - draft-ietf-fax-tiff-fx-reg-01.txt

    and assured the WG that the chairs are taking action with the RFC Editor
    in order to have the RFC number assigned ASAP (i.e. prior to publication)
    to the TIFF-FX/TIFF couple of documents. It is needed for reference in
    oter documents, and by the ITU, too.

    Following, Tamura-san presented the list of documents whose IETF last cal=
    l
    was completed without significative comments:

    - draft-ietf-fax-gateway-protocol-08.txt
    - draft-ietf-fax-gateway-options-05.txt
    - draft-ietf-fax-service-v2-05.txt

    These ones refer to DSN (RFC1894 update) and to TIFF-FX
    (draft-ietf-fax-tiff-fx-11.txt). Greg Vaudreuil reported about the status
    of DSN: after IANA questions were answered in April, and an extended
    implementation report submitted in early June, the document is
    currently on IESG table, without any apparent outstanding issue. The
    AD will check its status, too (see slides).

    The ID draft-ietf-fax-tiff-fx-11.txt is waitig for the supplementary
    implementation report to be published (see later on).

    On the IESG queue (Area Director review stage) we also have
    draft-ietf-fax-timely-delivery-05.txt. There were no comments and
    modification since the last meetings, thus we just wait for the AD review
    and for the reference to draft-vaudreuil-1983ext-01.txt to be solved. The
    latter status was also updated by Greg: very similar situation than DNS,
    no outstanding issues, and waiting for AD review before going to the IESG
    table.

    The discussion then moved to the TIFF-FX implementation report.
    The original report and the additional (new) report to be submitted.
    Tamura-san explained (see slides) that the CIAJ (Communications and
    Information network Association of Japan), whose members practically
    contain all the fax manufactures, agreed to perform an extended further
    IFax and TIFF-FX implementation test, to supplement the original report
    already submitted in 2001 for Profile S, F and J. In the TIFF-FX and IFax
    test are taking part Oki Data, Canon, Kyocera Mita, Sharp, Toshiba-Tec,
    NEC, Fuji-Xerox, Brother, Matsushita, Minolta, Murata and Ricoh. The
    testing for Profile C, L and M is planned. Some testing for Profile C was
    done successfully last month, and the remains will be done by the end of
    August. The supplementary report will include Specified product name,
    Supported tag information, License validation for some profiles, and will
    be submitted by the end of September. Patrik explicitly reminded that the
    license statement should specify that the company has exercised also the
    proof of "independend licensing" in implementing their products.

    Claudio then made a short report About the addressing
    (draft-allocchio-gstn-03.txt) documents. After the last meeting and the
    suggestions from the WG, version 03 was published in March. The only
    difference from version 02 was that the "implementer's note" regarding
    'pause' and 'tonewait' was turned into a reccommended (SHOULD, MAY)
    implementation specification. As there were not further comments, and a
    numver of IDs are starting to use the docuement as a reference, the ADs
    decided to issue the IETF last call: the request was submitted on July
    15th.

    Toyoda-san reported on the ID in preparation to register IFax service in
    ENUM with IANA. The returned DNS NAPTR record will specify an email
    address that is to be used for reaching the target system fax mailbox. Th=
    e
    email address is then used in accordance with =E2=80=9CSimple Mode=E2=80=9D=
     RFC2305,
    =E2=80=9CExtended Mode=E2=80=9D RFC2532 or FF Patrik Faltstrom, as editor=
     of the
    current ENUM NAPTR record specification reported the discussion of the
    preceding day at the ENUM wg, where the final syntax was again discussed,
    and now the final decsion will be taken on the mailing list. Thus the Ifa=
    x
    ENUM ID will have to follow the discussion, and conform with it. However
    this is not a problem for the IFax case, as we do not require specific
    hyerarchical syntax for the resource record data fields. Patrik and the W=
    G
    asked the editor now to submit the text of the ID, and discuss it within
    the FAX WG, with CC to the ENUM mailing list. Toyoda-san will do it withi=
    n
    a short time.

    The next ITU-T SG16 meeting is planned for October 2002. Tamura-san will
    report there about our activities. As a WG the documents which are
    referenced by ITU-T documents and need some processing are:

      =E2=80=9Cimage/tiff=E2=80=9D MIME Sub-type Registra
      =E2=80=9Cimage/tiff-fx=E2=80=9D MIME Sub-type Registration
      Implementers Guide

    where we are asking the RFC Editor at least for the assignement of the RF=
    C
    number. He will also report on the status of the TIFF-FX issue, which
    should progress after the supplementary implementation report is submitte=
    d
    in September.

    Claudio passed then to summarize the status of the discussion which
    started on the mailig lists after the IETF last call was issued for the
    Service Extension for Content Negotiation (please note the new version at
    http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.=
    txt
    not yet available at ID repository).

    On the mailing lists (including the IETF general one), we saw discussion
    which mainly can be grouped under these three major topics:

     - is the proposal doing layreing violations of the model MTA-MUA?
     - how the proposal handles the multi relays case?
     - which is the most efficient/more elegant specification approach,
       i.e. use RCPT TO or another sepcific command and then RCPT TO?

    On the mailing list the dabate did not show yet a clear direction, and
    the WG discussion should help in clarifying ideas. After this introductio=
    n
    Dave started the debate, thanking Claudio for his very neutral
    introduction of the topics, and explained the reasons why he is convinced
    that the current approach taken into the document should be the one to go
    for. On the layering violations (i.e. the MTA knowing the MUA capabilitie=
    s
    and keeping information about it to report back to the sender MUA), Dave
    suggested that we should be pragmatic, and consider that for most of the
    cases where Internet Fax is involved, the final MTA and MUA are on the
    same host, and very often are the same piece of software. This mihgt not
    be the case in all possible circumstances, but it will quite well fit the
    model. Furthermore, most of the Ifax traffic whould be point to point,
    without relaying. There were comment reminding that in most of the
    corporate cases, this might turne false, as filrewalls and single
    entrance SMTP relay are in common use, and this might introduce
    complications into the paradigm. After a discussion about the general
    model, which showed that there is not a common behavihours expected from
    the current SMTP messaging system, the WG pointed out that this is not a
    situation specific to Ifax, but it applies in general to all messaging
    purpouses, incliding VPIM, MIME etc... Solving the basic philosophycal
    problem thus requires the involvement of the whole SMTP area epxertise
    people, and not only the FAX WG. The debate on this should this continue
    either on the general IETF list, or considered to be moved to the area
    covered by the proposed WG on "unified messaging" having a BOF later
    during the week (lemonade). The discussion then focused on the
    implementation methods, i.e.should we use an option into the RCPT TO
    command, and thus use a single command, or should be issue first another
    command, and then when capabolities fo the recipient(s) are discovered,
    only then issue the set of RCPT TO commands? The aim should be the
    efficiency of the interaction in the transport system between MTAs, and
    also some MUAs. Dave defended the current specification, where a singl
    command (RCPT TO) is used to ask and discover capabilities of the
    recipient MUA, while Greg prefered the idea of another command to be
    issued before the RCPT TO sequence is started, in order to sort first
    recipients depending on capabilities. Claudio, removing momentarily his
    chair hat, also supported the single command, in favour of a more
    practical, even if probably less elegant, approch. Patrik reminded that
    Ned commented a lot on this topic, and at the end asked the WG to come to
    a conclusion on this two alternates. Harald, as a member of the IESG, als=
    o
    reminded that this is the fundamental topic where the IESG should be
    convinced of the best solution, and also removing his IESG hat for a
    moment, he instead suggested that two separate commands whould do an
    easier job for implementors. Claudio reminded that there is no apparent
    prevalent opinion on how the current SMTP system behaves, and reminded
    that some implementers this the SMTP world is mostly "one recipient per
    MTA" when there is not a firewall or similar security measires in effect,
    and "many users per relay MTA" where these measueres are in effect. A
    query to the ones present in the room showed 2 hands in favour of a simpl=
    e
    command (current specification), 3 hands in favour of using 2 separate
    commands and the vast majority of the WG which did not make its ming on
    it, yet (the FAX WG is not so good in humming, we use hands). Keeping in
    mind that also many other people not present in the room have opinions on
    this topic, the further discussion and decision was moved to the mailing
    lists involved, including the general IETF list.

    After more that 45 minutes of debate we moved to the next topic, FFPIM.
    Dave reported the the newest version of the document contained some minor
    edits (upon suggestions from Dan Wing), and asked to those presents some
    questions:

     - Use of ESMTP options as MAY or SHOULD?
     - FPIM conformance require RFC2305 and RFC2532 conformance?

    as there was no clear opinion of those presents, there questions are now
    taken to the mailing list for final decsion.

    More over, the document refers to CONNEG specification. It was agreed tha=
    t
    the CONNEG text should be more detailed, and that we should of course
    adapt it to the output of the dicussion about it.

    At this point we handed over to VPIM agenda points, and Glenn Parsons
    chaired the rest of the meeting. Note that the FAX and VPIM WGs confirmed
    their will to continue with joint meetings until all their work is
    finished, and thus will meet agin together in Atlanta, in November 2002.

    -------------------------------------------------------------------------=
    -----
    Claudio Allocchio G A R R Claudio.Allocchio@ga=
    rr.it
                            Project Technical Officer
    tel: +39 040 3758523 Italian Academic and G=3DClaudio; S=3DAll=
    occhio;
    fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr; =
    C=3Dit;

         PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=3D0C5C2A0=
    9



    This archive was generated by hypermail 2b29 : Mon Jul 22 2002 - 17:04:48 EDT