[IPP] Discussion on IPP FaxOut

[IPP] Discussion on IPP FaxOut

[IPP] Discussion on IPP FaxOut

Petrie, Glen glen.petrie at eitc.epson.com
Thu May 30 15:01:09 UTC 2013


Thanks for the feedback Mike.

 

________________________________

From: Michael Sweet [mailto:msweet at apple.com] 
Sent: Thursday, May 30, 2013 7:57 AM
To: Petrie, Glen
Cc: ipp at pwg.org
Subject: Re: [IPP] Discussion on IPP FaxOut

 

Glen,

 

Since we are in PWG Last Call, these would be great as last call
comments, but my responses are inline...

 

On May 30, 2013, at 10:40 AM, "Petrie, Glen"
<glen.petrie at eitc.epson.com> wrote:

	All,

	 

	I have not had the cycles to review the IPP-FaxOut specification
until now and was greatly surprised at the some of the requirements and
specification.   

	 

	For example "IPP FaxOut Jobs MUST be retained for a minimum of
300 seconds"

 

Job history in order for the client to know the disposition of the job
(there are already legal requirements for retaining fax history longer
than this anyways)

 

	, "Printers [IPP FaxOut Service???] MUST support scaling and
color space conversion of document data to match the negotiated
facsimile image format at the job processing time"

 

If the IPP Printer reports color fax support, the client may send a
color document to fax.  But if the receiver does not support color fax
we want the IPP Printer to send it B&W unless ipp-attribute-fidelity and
print-color-mode are specified to force color fax.

 

	, and "Imaging Devices [IPP FaxOut Services???] that can only
stream print jobs to a single destination URI MUST support
retransmission of the current page".   

 

Retransmission of the current page is a basic fax protocol requirement;
all MFDs I know of can buffer at least 1 page of fax data, and most
buffer a lot more...

 

	There are many of these types of requirements that appear to be
Client and/or the Imaging Devices "product/implementation design
specifications" and not what I expected to be API interfaces capability
and job submission specifications.

	 

 

We did have a lot of discussion about that last year, which resulted in
all of the language to support low-end MFDs that could only buffer a
single page and could not handle full retransmission.





For instance, the IPP FaxOut Service should be provide capability on
"Job Retention times supported", "Fax Scaling Supported", "Color Spaces
Conversion Supported" and "Retransmission Supported" versus this
specification setting device and client design and implementation
requirements for these capabilities.

 

 

As I mentioned above, legal requirements for fax vary but basically all
of them require a retained job history far longer/larger than 300
seconds (5 minutes).

 

The Printer reports its supported scaling/colorspace conversion
capability by reporting whether it supports color and what PWG Raster
resolutions and types it supports.  And a fax-capable MFD already has to
support scaling (to the negotiated resolution) and probably dithering
and colorspace conversions from its scanner.

 

	An example of the simplest fax out would be something like
"no-cover, single-sheet, one-recipient, (jpeg) image - to - fax binary
CCITT Encoding, no-retry, no-job-hold-after".  Anything beyond that
should be based on the capability of the specific IPP FaxOut Service
implementation and/or the Client implementation but independent of a
"MUST" requirement of the PWG / IPP FaxOut Service specification.
However, the PWG / IPP FaxOut Service specification must define how
capability information is specified.

	 

 

The only required format is PWG Raster, which has several attributes
that describe the supported resolutions and color spaces.

 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130530/bd1f3a67/attachment-0001.html>


More information about the ipp mailing list