IFX Mail Archive: RE: IFX> RE: Fax processing confirmation

IFX Mail Archive: RE: IFX> RE: Fax processing confirmation

RE: IFX> RE: Fax processing confirmation

From: MAEDA toru (maeda.toru@canon.co.jp)
Date: Mon Mar 05 2001 - 06:30:18 EST

  • Next message: Hastings, Tom N: "RE: IFX> New data types [for IPP WG agenda]"

    Wagner-san

    Sorry for late response.
    Thank you for detailed answer to my message.

    I add my comments as below.

    At 17:30 01/02/21 -0500, Wagner,William wrote:
    >Maeda-san,
    >
    >Thank you for your response. I will address your questions as best as I can.
    >I understand that IPP appears printer-oriented rather than Facsimile
    >oriented. Correcting that and adding the necessary facsimile features is one
    >reason for the IPP FAX effort. We must consider what notification parameters
    >are significant to the end user in his desire to communicate a document. It
    >is not clear to me that these parameters are so different between remote
    >printing and facsimile.
    >
    >Your questions were:
    >
    >1) Does the current draft of the IPP notification include fax processing
    >status which I proposed?
    >
    >I understand you have proposed "success/failure of document processing and
    >page by page status from the receiver"
    >
    >In a TCP connection, the lower layers ensure the integrity of the
    >transmitted data (or report the inability to sustain a connection);
    >therefore, notification of transmission problems are already covered in any
    >TCP based transmission..
    >
    >It is possible for any transmission (including telephone) to be handled by
    >an intermediate server thereby losing the ability to report on document
    >processing immediately as the document is transmitted. If there is no
    >intermediate server, IPP provides mechanisms for delivering processing
    >information during and immediately after transmission. If there is an
    >intermediate server, defined notification delivery mechanisms such as
    >MAIL_TO (EMAIL message) can still be used to provide notification of final
    >disposition; it is assumed that sheet-by-sheet notification by email would
    >not be practical.
    >
    >Further, the attributes already defined include the sheet-by-sheet
    >completion as well as satisfactory completion with job statistics (e.g.,
    >number of sheets printed). The use of sheets rather than pages reflects the
    >desire to communicate the end result in terms of hardcopy emerging from the
    >receiver. The use of sheets avoids the question of two sided or multiple
    >page up printing.

    Main reason that I propose "document processing" is
    that a TIFF file can not be printed or processed by the receiver.
    The transmission of the TIFF file is ensured by TCP connection.
    But there is some case that the receiver can not print because of its
    capabilities.
    Details are described in Lloyd-san's mail that it is possible to send a
    file that contains more
    than one encodings.

    I am not sure what will happen if PS3 file is send to PS2 IPP printer.

    >(2) Which section in the IPP notification does describe it?
    >
    >The notification mechanism is very general, and only a subset would apply to
    >fax. But see 5.3.2.1.3 Subscribed Job Events in
    ><draft-ietf-ipp-not-spec-06.txt>, especially Job-State-Changed and
    >Job_Progress *(printing a sheet). The sender can "subscribe" to the desired
    >notification events when the job is sent. These events (such as printing a
    >sheet) trigger a notification to the sender or other designated destination
    >with appropriate attribute values.
    >
    >The subscription also defines the method of notification delivery, of which
    >three methods have been documented in current internet drafts.
    >(<draft-ietf-ipp-indp-method-03.txt>, <draft-ietf-ipp-notify-get-01.txt> and
    ><draft-ietf-ipp-notify-mailto-03.txt>)
    >
    >It is likely that, in a fax application, there will be a preferred eventing
    >and delivery, so that the whole gamut of IPP capabilities need not be
    >addressed.

    IFAX may use mailto when IPP notification is extended for ifax status.

    >(3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it, if the current
    >draft of IPP notification does not describe it?
    >
    >I suggest that the IPP FAX working group would be more than happy to discuss
    >additional attribute and feature requirements from the facsimile
    >community.

    I will be grad to discuss it in IPP FAX wg.

    >(4) Will PWG IPP FAX wg define fax processing status in the IPP notification
    >if required?
    >
    >The IPP FAX wg intends to add to the basic IPP capability what is needed to
    >provide FAX functionality to the end users.

    If the file formats of IFAX and IPP are same , we can use same status for them.

    >(5) Can EIFAX and T.37 Full Mode use the IPP notification for fax processing
    >results?
    >
    >Although IPP Notification was not designed to be an all purpose notification
    >capability, it includes may features and other facsimile modes could use a
    >subset of the IPP notification capability. It is not immediately clear to
    >me whether this would be a good idea, although, if devices included a
    >multi-mode Ifax capability, a common notification scheme may have
    >advantages.

    Ifax status will be returned by DSN and MDN, by requesting DSN and MDN from
    the transmitter.
    I am not sure that mailto in IPP notification can be used as DSN and MDN.

    >Best regards,
    >
    >Bill Wagner

    --------------------
    MAEDA TORU
    MIE Development Div. 2
    CANON Inc.
    --------------------



    This archive was generated by hypermail 2b29 : Mon Mar 05 2001 - 06:25:46 EST