Subject: RE: IFX> RE: Fax processing confirmation

From: MAEDA toru <[email-masked]>
Date: Wed, 21 Feb 2001 17:10:38 +0900

William-san

Thank you very much for comments.
I do not care that the IPP notification may still be "work in progress" or not.
I think that the IPP notification describes print job results but not fax 
processing results.
We have to think about difference between print job results and fax 
processing results.

My questions are;
(1) Does the current draft of the IPP notification include fax processing 
status which I proposed?
(2) Which section in the IPP notification does describe it?
(3) Which wg (IPP/fax/IPP FAX) is suitable to discuss it,
if the current draft of IPP notification does not describe it?
(4) Will PWG IPP FAX wg define fax processing status in the IPP 
notification if required?
(5) Can EIFAX and T.37 Full Mode use the IPP notification for fax 
processing results?

Regards.

Toru Maeda

At 12:22 01/02/20 -0500, Wagner,William wrote:
>Maeda-san,
>
>I think Ira McDonald's message may have been misunderstood. The IPP
>notification may still be "work in progress". But, as indicated by the IESG
>message below, the basic mechanisms are up for last call. These documents,
>although they deal with many possible notification events and mechanisms, do
>include "page by page confirmation from the receiver" (or more exactly,
>sheet by sheet confirmation.)
>
>Further, although various notification mechanisms are identified, it is
>assumed that sheet-by-sheet job progress notification is applicable
>primarily to real-time notification connections which  include the "indp"
>method <draft-ietf-ipp-indp-method-03.txt> as well as the "get" method
><draft-ietf-ipp-notify-get-01.txt> alluded to by Ira.
>
>I suggest that the IP FAX community may be interested in commenting on these
>notification approaches.
>
>I would also suggest that the various IFAX approaches each have advantages
>in certain environments. T.37 uses virtually universal EMAIL capabilities.
>T.38 (non-gateway) uses voice over IP, which suggests a voice/fax
>capability. IPP has great flexibility, it can  utilize developments in its
>host HTTP protocol, and provides for authentication and encryption. It is
>unclear that internet fax must settle on a single protocol.
>
>The IESG announcement, dated Mon 2/19/2001. follows.
>
>"The IESG has received a request from the Internet Printing Protocol
>Working Group to consider Internet Printing Protocol (IPP):IPP Event
>Notification Specification <draft-ietf-ipp-not-spec-06.txt> as a
>Proposed Standard.
>
>The IESG will also consider publication of Internet Printing Protocol:
>Requirements for IPP Notifications <draft-ietf-ipp-not-05.txt> as an
>Informational RFC.
>
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by March 5, 2001.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt
>http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-05.txt "
>
>Regards,
>
>William A. Wagner (Bill Wagner)
>Director of Technology
>Imaging Division
>NETsilicon, Inc.
>781-398-4588
>
>
>-----Original Message-----
>From: MAEDA toru [mailto:[email-masked]]
>Sent: Tuesday, February 20, 2001 4:45 AM
>To: McDonald, Ira; [email-masked]
>Subject: IFX> RE: Fax processing confirmation
>
>
>Ira-san
>
>Thank you very much for detailed information about the IPP notification
>that it does not support page by page confirmation from the receiver.
>Fax wg should discuss about fax processing status.
>PWG IPP FAX WG may discuss about the fax processing status also.
>
>Regards.
>
>Toru Maeda
>
>At 12:59 01/02/17 -0800, McDonald, Ira wrote:
> >Hi Dan and IFax folks,
> >
> >Please note that IPP notifications (in-band via IPP channel
> >or out-of-band via SMTP or 'reverse' HTTP) are still
> >work-in-progress in the IETF IPP WG.
> >
> >IPP native protocol itself does NOT provide confirmation that
> >any pages have actually been printed without polling (by the
> >IPP Client) of the IPP Printer.
> >
> >The IEEE/ISTO PWG (Printer Working Group) has chartered IPPFax
> >project, but it isn't very far along yet.  The IETF declined
> >to charter IPPFax as an IETF WG, so this is probably quite
> >far away from an IETF 'standards track' RFC.
> >
> >Cheers,
> >- Ira McDonald, consulting architect at Sharp and Xerox
> >   (active member of IETF IPP WG, author of 'ipp:' URL scheme)
> >   High North Inc
> >
> >-----Original Message-----
> >From: Dan Wing [mailto:[email-masked]]
> >Sent: Friday, February 16, 2001 10:26 AM
> >To: MAEDA toru
> >Cc: [email-masked]; Claudio Allocchio; Hiroshi Tamura
> >Subject: Re: Fax processing confirmation
> >
> >
> >On Fri, 16 Feb 2001 18:57 +0900, MAEDA toru wrote:
> >
> > > Wing-san
> > >
> > > How much confidence of ifax transmission in Simple Mode ?
> > > Does no response mean a good confirmation ?
> > >
> > > I want to add Fax processing confirmation in Full Mode.
> > > In Full Mode, the image file is send as TIFF file over SMTP.
> > > There will be some possibilities to fail to print or process
> > > the TIFF file by some reasons.  These reasons may be
> > > incorrect TIFF parameter for the receiver
> > > or out of capabilities TIFF parameter for the receiver.
> > >
> > > When you put the 10 pages of document on the scanner
> > > and send by ifax Full Mode and you get the confirmation sheet
> > > with  9 pages received successfully, you will find something
> > > wrong with the scanner or the transmission.  You will check
> > > the scanner or the system and may ask to the user of the receiver.
> > >
> > > Comparing to the E-mail system, you can not get information about
> > > how many pages the receiver successfully printed but just received.
> > > You may find that the attached file is not be able to be processed
> > > nor printed by the Email receiver with your inspiration.
> > >
> > > The user of Full Mode ifax will have confidence of the ifax
> > > transmission when the transmitter prints confirmation sheet
> > > with the number of pages printed on the receiver and also
> > > the number of page in error.
> > >
> > > Any comments?
> >
> >IPP provides this sort of confirmation today.  Why not use IPP?
> >
> >-d
>
>--------------------
>MAEDA TORU
>MIE Development Div. 2
>CANON Inc.
>--------------------

-----------------------------------
キヤノン株式会社
映像事務機MIE推進センター
映像事務機MIE第２開発部
前田　徹
146-8501　東京都大田区下丸子３−３０−２
電話　03-3757-9738、FAX　03-3757-8205
-----------------------------------

---

From: "Wagner,William" <[email-masked]>
Date: Wed, 21 Feb 2001 17:30:25 -0500

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.

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.

(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.

(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.

(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.

Best regards,

Bill Wagner

-----Original Message-----
From: MAEDA toru [mailto:[email-masked]]
Sent: Wednesday, February 21, 2001 3:11 AM
To: Wagner,William; McDonald, Ira; [email-masked]; [email-masked]
Subject: RE: IFX> RE: Fax processing confirmation

William-san

Thank you very much for comments.
I do not care that the IPP notification may still be "work in progress" or
not.
I think that the IPP notification describes print job results but not fax 
processing results.
We have to think about difference between print job results and fax 
processing results.

My questions are;

Regards.

Toru Maeda

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 21 Feb 2001 17:22:27 -0800

For those wondering what value there is in providing notification
information that distinguishes the processing status of each page, let me
clarify by stating that it is possible to send a file that contains more
than one encodings. Envision a document with both black-and-white and color
pages. It is more efficient, both in file size and image quality, to code
the black-and-white pages with a bi-level coder such as MMR (G4) and the
color pages with a multi-level coder such as JPEG. TIFF-FX does not restrict
both encoding being interleaved throughout the file. Given this condition,
it is conceivable that a decoder may   able to render the bi-level but not
the color pages.

The draft-ietf-fax-tiff-fx-Extension1-01.txt draft makes provision for
signaling such mixed content documents/files so that a decoder will not be
caught off guard.

Lloyd   

> From: Wagner,William [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 2:30 PM
> To: 'MAEDA toru'; McDonald, Ira; [email-masked]; [email-masked]
> >although they deal with many possible notification events 
> and mechanisms,
> do
> >I suggest that the IP FAX community may be interested in 
> commenting on
> these
> >notification approaches.
> >

---

From: MAEDA toru <[email-masked]>
Date: Thu, 22 Feb 2001 20:30:35 +0900

Kugler-san

Thank you very much for the information about the page-by-page job
notifications in the IPP draft.
I read the section.

'job-progress' will be send for each sheet.
I am not sure that user can find the error page number
and the total number of pages printed from 'job-progress'.

It's idea is similar idea as the fax processing status.

The fax processing status will be sent in one MDN message
with summarized information after printing a TIFF-FX file,
such as total number of printed page and error page with error code.
"page" in the fax processing status should be "page" in the TIFF-FX file 
but not sheet.

'job-progress' should be extended as 'job-summary'
to report summarized information after printing
for the fax processing status.

Regards.

Toru Maeda

At 08:56 01/02/21 -0700, Carl Kugler wrote:

>See section 5.3.2.1.3  "Subscribed Job Events", in the document you cited:
>
>'job-progress': OPTIONAL - when the Printer has completed Printing a
>       sheet. See the separate [ipp-prog] specification for additional
>       attributes that a Printer MAY send in an Event Notification caused
>       by this Event. The "notify-time-interval" attribute affects this
>       Event by causing the Printer NOT to send an Event Notification
>       every time a 'job-progress' Events occurs. See section 5.3.8 for
>       full details.
>
>
>      -Carl
>
>
>MAEDA toru <[email-masked]>@pwg.org on 02/21/2001 02:24:36 AM
>
>Sent by:  [email-masked]
>
>
>To:   "McDonald, Ira" <[email-masked]>, "'Wagner,William'"
>       <[email-masked]>, "McDonald, Ira" <[email-masked]>,
>       [email-masked]
>cc:
> >And the page-by-page job notifications are OPTIONAL in the
> >IPP notifications model spec.
>
>Please let me know which section describes the page-by-page job
>notifications,
>   since I could not find it in
>http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt.
>
>Shall I check other drafts?
>
>
>Reagrds.
>
>
>Toru Maeda

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