[IPP] Hewlett-Packard has reviewed the IPP FaxOut specification and has comments

[IPP] Hewlett-Packard has reviewed the IPP FaxOut specification and has comments

[IPP] Hewlett-Packard has reviewed the IPP FaxOut specification and has comments

Kennedy, Smith (Wireless Architect) smith.kennedy at hp.com
Wed Jun 26 05:39:55 UTC 2013


Greetings,

Below are comments from HP regarding the IPP FaxOut specification final call (wd-ippfaxout10-20130501.pdf).

Cheers,
Smith

/**
    Smith Kennedy
    Hewlett-Packard Co.
    smith.kennedy at hp.com
*/



4.1.2:
- The notion of "spooling vs. streaming" seems to assume that a device is one or the other, regardless of the job size.  I don't think this is necessarily the case.  Some spooling devices may have expansive secondary storage such as a hard disk.  But some spooling devices may support spooling up to some much more restricted limit, such as 5-10 pages, if they are storing it in RAM.  For these devices, one might expect spooling support up to some job size, and beyond that it should be used as a streaming device.  But how should this be handled and enforced?  Client side, or FaxOut service side?  Or should such devices always present themselves as streaming devices to clients, and not try to spool small fax jobs?  

- Exactly how does the IPP FaxOut Printer Object communicate to the IPP client that it is streaming vs. spooling?  Should it be done using the maximum size of an incoming fax job, using one of the following?
   - job-k-octets-supported (RFC 2911)
   - *-k-octets-supported if it depends on the format?

If not in this manner, which seems non-optimal because it is basically an implied interpolation, an explicit attribute seems necessary.

- Is the error handling described here adequate?  Under what conditions would there need to be "larger portions of the job" retransmitted?  Only in the event of a phone line connection failure?  In that case, would the sending fax only send the pages unsent?  Or would it be expected to resend the entire job?  Are retries in the "processing" state?


4.1.4:
- Why must the job be retained for 300 seconds?  A streaming device will only retain the last page.
- Feedback: "(section 7.4.21)" should be "(section 7.4.22)".  This logging facility is confusing and seems incompletely described, here or in 7.4.22.

4.2:
- Note 1: "MUST NOT" for Print-Job operation?  That seems a bit extreme…  Is this expected to be only true for the /ipp/faxout Printer Object but not for the /ipp/print Printer Object (if present)?

4.3:
- What is the purpose of margins here?  Is this just for rendering local to the IPP Faxout device? (Guessing the answer is yes…)
- "pages-per-minute" and "pages-per-minute-color" - how will this be determined for fax?
- Should there be an "include-fax-header" job attribute? (this is a page header with the sender's name & #, date, time, page X of Y, etc.)   Legal requirements around this?
- "Note 4" seems to not have any attributes that reference it.  Was this supposed to be referenced by the "input-source-supported" attribute?

6.1:
- Send-Hardcopy-Document operation and streaming devices and a resend - will the client be expected to resend if the job included a Send-Hardcopy-Document operation?

7.2.2.3:
- What document formats must be supported by the printer for the logo?  Size limits?  JPS3 had the printer-icons attribute defined in such a way that the icon must be in a particular format (PNG) and particular sizes.
- Guessing that the schemes supported could be determined by "reference-uri-schemes-supported" but that attribute is not listed in the IPP FaxOut spec at all


7.4.22:
- How is this intended to work?  Can this be a URI to a service on a host other than the one hosting the IPP FaxOut Printer Object?  What should happen if the fax log hits a size limit? Is the size limit advertised?

7.4.26:
- Should this value be the country-defined value?

7.4.27:
- What is the point of retry-interval-supported for streaming devices?  And which entity is responsible for keeping count for the retries?  Is it the IPP FaxOut device, or the client?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3319 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130626/9f4fec97/attachment.p7s>


More information about the ipp mailing list