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 : Wed Mar 07 2001 - 19:13:27 EST