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

RE: IFX> RE: Fax processing confirmation

From: McIntyre, Lloyd (Lloyd.McIntyre@pahv.xerox.com)
Date: Thu Mar 08 2001 - 16:42:27 EST

  • Next message: Hastings, Tom N: "RE: IFX> New data types [for long text & octetString for IPP WG a genda]"

    The attribute exchange provision should minimize instances of failure to
    process. It is, however, not fool proof.

    The example I provided earlier (i.e. black-and-white and color encodings
    within a single file) is one of those cases where a receiver may have
    indicated provision to process the two attribute sets, however, there is no
    indication that the receiver will be able to process them interchangeable
    within the same file. Section E1.2.2.2 of the TIFF-FX Extension Set 1 draft
    makes provision for a receiver to clearly indicate whether it will be able
    to process different contents within a single file.
    http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-extension1-01.txt

    The MultiProfiles will need to be added to the registered set of RFC 2879
    (Feature Schema) attributes. Given that these are all optional provisions,
    we cannot guarantee that processing failures will not occur.

    Lloyd

    > -----Original Message-----
    > From: Wagner,William [mailto:wwagner@netsilicon.com]
    > Sent: Wednesday, March 07, 2001 4:12 PM
    > To: 'MAEDA toru'; ifx@pwg.org; ietf-fax@imc.org
    > Subject: RE: IFX> RE: Fax processing confirmation
    >
    >
    > Maedo-san,
    >
    > Thank you for your response. I regret that a snowstorm has
    > stranded me in
    > New England, and I was unable to attend the IPP Fax meeting.
    > I hope you all
    > enjoyed the good weather. All of those involved in IPPFAX
    > appreciate your
    > participation and that of other FAX experts.
    >
    > The common point in your response and Mr. McIntyre's message
    > appears to be a
    > means of reporting a problem resulting from an incompatibility between
    > sender and receiver. Indeed, you suggest it is similar to
    > sending a PS3 file
    > to a PS2 IPP Printer.
    >
    > Perhaps I am missing something, but is it not the purpose of
    > the attributes
    > exchange to avoid such mismatches? For the specific example,
    > IPP includes
    > the attribute "document-format" (mimeMediaType). Getting all
    > current printer
    > languages mime-typed is still in progress, but different
    > document formats
    > will be distinguishable. Not only is this an attribute that
    > can be queried
    > by the sender before the document is sent, but the receiver
    > must reject an
    > incoming document with an incompatible document-format.
    >
    > It is recognized that one of the main tasks in IPPFAX is to identify a
    > system whereby the attribute exchange can also deal with attribute
    > interdependencies. But the premise is that the ability of a
    > receiver to
    > accept a document is ascertained before transmission. The notification
    > mechanisms can then be used for page by page progress,
    > certain processing
    > problems (paper handling, memory limits etc), and general job
    > completion.
    > But, if there can be sufficient attributes communication, it
    > should not be
    > needed for processing problems due to capabilities incompatibilities.
    >
    >
    > Best regards,
    >
    > Bill Wagner
    >
    >
    >
    >
    > -----Original Message-----
    > From: MAEDA toru [mailto:maeda.toru@canon.co.jp]
    > Sent: Monday, March 05, 2001 6:30 AM
    > To: Wagner,William; McDonald, Ira; ifx@pwg.org; ietf-fax@imc.org
    > Subject: RE: IFX> RE: Fax processing confirmation
    >
    >
    > 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 : Thu Mar 08 2001 - 16:42:47 EST