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 <maeda.toru at canon.co.jp>@pwg.org on 02/21/2001 02:24:36 AM
Sent by: owner-ifx at pwg.org
To: "McDonald, Ira" <imcdonald at sharplabs.com>, "'Wagner,William'"
<wwagner at netsilicon.com>, "McDonald, Ira" <imcdonald at sharplabs.com>,
ifx at pwg.org
cc:
Subject: RE: IFX> RE: Fax processing confirmation
Ira-san
>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
At 23:41 01/02/20 -0800, McDonald, Ira wrote:
>Maeda-san and Bill,
>>Thanks for the clarifications, Bill.
>>Note that the IESG 'last call' is on the _model_ for IPP
>notifications. None of the actual IPP notifications
>delivery methods (including 'ippget' in-band IPP notifications,
>most appropriate for a fax-like experience) are up for IESG
>'last call' yet.
>>And the page-by-page job notifications are OPTIONAL in the
>IPP notifications model spec.
>>Personally, I don't think 'indp' (IPP Notifications Delivery
>Protocol) which requires that the IPP Client take the role
>of HTTP _server_ and accept incoming HTTP connections from
>the IPP Printer (in order to receive notifications) is at all
>appropriate for a fax-like behavior over the Internet.
>>Of course, I think IPP _does_ have good future potential for
>realtime fax-like behavior over the Internet. It just isn't
>there yet.
>>Cheers,
>- Ira McDonald, consulting architect at Sharp and Xerox
> High North Inc
>>PS - Note that all IPP sessions use an HTTP connection for a
>transport protocol and thus have firewall issues for public
>Internet use (just like end-to-end SMTP does).
>>-----Original Message-----
>From: Wagner,William [mailto:wwagner at netsilicon.com]
>Sent: Tuesday, February 20, 2001 9:23 AM
>To: 'MAEDA toru'; McDonald, Ira; ifx at pwg.org>Subject: RE: IFX> RE: Fax processing confirmation
>>>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
>iesg at ietf.org or ietf at ietf.org 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:maeda.toru at canon.co.jp]
>Sent: Tuesday, February 20, 2001 4:45 AM
>To: McDonald, Ira; ifx at pwg.org>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:dwing at cisco.com]
> >Sent: Friday, February 16, 2001 10:26 AM
> >To: MAEDA toru
> >Cc: ietf-fax at imc.org; 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
-----------------------------------