Subject: RE: IFX> RE: Fax processing confirmation

From: MAEDA toru <[email-masked]>
Date: Mon, 05 Mar 2001 20:30:18 +0900

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

---

From: "Wagner,William" <[email-masked]>
Date: Wed, 7 Mar 2001 19:11:42 -0500

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:[email-masked]]
Sent: Monday, March 05, 2001 6:30 AM
To: Wagner,William; McDonald, Ira; [email-masked]; [email-masked]
Subject: RE: IFX> RE: Fax processing confirmation

Wagner-san

Sorry for late response.

>provide FAX functionality to the end users.

If the file formats of IFAX and IPP are same , we can use same status for
them.

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

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Thu, 8 Mar 2001 13:42:27 -0800

The attribute exchange provision should minimize instances of failure to
process. It is, however, not fool proof.

The example I provided earlier (i.e. black-and-white and color encodings
within a single file) is one of those cases where a receiver may have
indicated provision to process the two attribute sets, however, there is no
indication that the receiver will be able to process them interchangeable
within the same file. Section E1.2.2.2 of the TIFF-FX Extension Set 1 draft
makes provision for a receiver to clearly indicate whether it will be able
to process different contents within a single file.
http://www.ietf.org/internet-drafts/draft-ietf-fax-tiff-fx-extension1-01.txt

The MultiProfiles will need to be added to the registered set of RFC 2879
(Feature Schema) attributes.  Given that these are all optional provisions,
we cannot guarantee that processing failures will not occur.

Lloyd

> From: Wagner,William [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 4:12 PM
> To: 'MAEDA toru'; [email-masked]; [email-masked]
> >Thank you for your response. I will address your questions 
> as best as I
> can.
> >oriented. Correcting that and adding the necessary facsimile 
> features is
> one
> >number of  sheets printed). The use of sheets rather than 
> pages reflects
> the
> >The notification mechanism is very general, and only a 
> subset would apply
> to
> >The subscription  also defines the method of notification 
> delivery, of
> which
> >(<draft-ietf-ipp-indp-method-03.txt>, 
> <draft-ietf-ipp-notify-get-01.txt>
> and

---

From: MAEDA toru <[email-masked]>
Date: Mon, 12 Mar 2001 18:35:02 +0900

Wagner-san

>participation and that of other FAX experts.

There was windy and cool.
There was no bikini girl in Tampa beach.

>needed for processing problems due to capabilities incompatibilities.

There will be no guarantee that processing failures will not occur in IPP-FAX
with capabilities exchange.
Users will have a confidence on IPP-FAX transmission,
if they get page-by-page confirmation instead of job completion.

>Bill Wagner

Toru Maeda

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