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@canon.co.jp>@pwg.org on 02/21/2001 02:24:36 AM
Sent by: owner-ifx@pwg.org
To: "McDonald, Ira" <imcdonald@sharplabs.com>, "'Wagner,William'"
<wwagner@netsilicon.com>, "McDonald, Ira" <imcdonald@sharplabs.com>,
ifx@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@netsilicon.com]
>Sent: Tuesday, February 20, 2001 9:23 AM
>To: 'MAEDA toru'; McDonald, Ira; ifx@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@ietf.org or ietf@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@canon.co.jp]
>Sent: Tuesday, February 20, 2001 4:45 AM
>To: McDonald, Ira; ifx@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@cisco.com]
> >Sent: Friday, February 16, 2001 10:26 AM
> >To: MAEDA toru
> >Cc: ietf-fax@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.
>--------------------
-----------------------------------
$B%-%d%N%s3t<02q<R(B
$B1GA|;vL35!(BMIE$B?d?J%;%s%?!<(B
$B1GA|;vL35!(BMIE$BBh#23+H/It(B
$BA0ED!!E0(B
146-8501$B!!El5~ETBgED6h2<4];R#3!]#3#0!]#2(B
$BEEOC!!(B03-3757-9738$B!"(BFAX$B!!(B03-3757-8205
-----------------------------------
This archive was generated by hypermail 2b29 : Wed Feb 21 2001 - 11:41:05 EST