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
> -----Original Message-----
> From: Wagner,William [mailto:wwagner@netsilicon.com]
> Sent: Wednesday, February 21, 2001 2:30 PM
> To: 'MAEDA toru'; McDonald, Ira; ifx@pwg.org; ietf-fax@imc.org
> Subject: RE: IFX> RE: Fax processing confirmation
>
>
> 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.
>
> (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.
>
>
>
> (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:maeda.toru@canon.co.jp]
> Sent: Wednesday, February 21, 2001 3:11 AM
> To: Wagner,William; McDonald, Ira; ifx@pwg.org; ietf-fax@imc.org
> 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;
> (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
> >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(J
> $B1GA|;vL35!(JMIE$B?d?J%;%s%?!<(J
> $B1GA|;vL35!(JMIE$BBh#23+H/It(J
> $BA0ED!!E0(J
> 146-8501$B!!El5~ETBgED6h2<4];R#3!]#3#0!]#2(J
> $BEEOC!!(J03-3757-9738$B!"(JFAX$B!!(J03-3757-8205
> -----------------------------------
>
This archive was generated by hypermail 2b29 : Wed Feb 21 2001 - 20:22:54 EST