Subject: [IPP] Discussion on IPP FaxOut

From: "Petrie, Glen" <[email-masked]>
Date: Thu, 30 May 2013 07:40:39 -0700

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", "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", and "Imaging Devices
[IPP FaxOut Services???] that can only stream print jobs to a single
destination URI MUST support retransmission of the current page".   

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. 

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.

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.

Glen

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

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Thu, 30 May 2013 10:56:56 -0400

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" <[email-masked]> 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

---

From: "Petrie, Glen" <[email-masked]>
Date: Thu, 30 May 2013 08:01:09 -0700

Thanks for the feedback Mike.

________________________________

From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, May 30, 2013 7:57 AM
To: Petrie, Glen
Cc: [email-masked]
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"
<[email-masked]> 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.

 

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.