[IPP] TIC has reviewed the IPP INFRA specification and has comments

[IPP] TIC has reviewed the IPP INFRA specification and has comments

[IPP] TIC has reviewed the IPP INFRA specification and has comments

William Wagner wamwagner at comcast.net
Mon Feb 23 17:47:05 UTC 2015

Sorry I am late, but I suspect that the review period will need to be extended.

Comments below are primarily areas  that I think may be confusing to new readers, based upon my re-reading the spec after some time. Thanks,

Bill Wagner


Footer:  Copyright date range will need to be changed to 2013-2015

Section 3.2, line 401: Introduction of Jane at end of paragraph is confusing (what is Jane?) Suggest "Each of the use cases in this section involve Jane (the User) initiating a print action and selecting a Printer, with her Client querying the Printer status and capabilities and displaying any important status information:" Alternatively, just refer to the User rather than "Jane".

Section 3.2, General Comment. I appreciate that we have spent much time on Use Cases to the extent that we just want to ignore them now.  But I suggest that use cases may be important to the new reader to understand the circumstances  to be addressed by the newly specified capabilities.  Why the specified capabilities are needed is perhaps more significant than how the capabilities work.  Perhaps the second paragraphs  could be dropped in each of the use cases ?  But if the ‘how’ descriptions are kept, I suggest that the reader may consider the Output Device to be a Printer. Therefore it would be better to use "Infrastructure Printer" rather than just "Printer" when it is intended.  Following suggestions to the first use case apply to all of the use cases. 

Section 3.2.1, line 410:  Suggest "...has a document, stored on her phone, that she is to print prior to a meeting. The Wi-Fi network does not provide access to the Print Output Device she wishes to use." That is, identify why  traditional IPP would not work.

Section 3.2.1, Line 414: Suggest " ...request to the Infrastructure Printer with the Job Ticket and attached document data. The Proxy for the desired Output Device pulls this information from the Infrastructure Printer, validates ... from the Infrastructure Printer and causes the document to be printed, providing status updates to the Infrastructure Printer."

Section 4.1.1, line 570: "... MUST NOT perform any pre-processing for things that can be done by the Proxy in order to follow established Late Binding principles."  I suggest that MUST NOT is too strong.  There may be reasons (speed, for example) where it is desirable for the Infrastructure Printer to act even though the Proxy may report the capability. Also, I assume that generally you attribute all capabilities downstream of the Proxy to be Proxy capabilities. Perhaps this might be made more clear in the discussion of Figure 3. Certainly, a viable configuration is to have the Proxy a simple translating application on a general purpose computer, or a minimal stand-alone device, in any case with no imaging preprocessing capabilities. However, for the discussion, the Proxy acquires the capabilities of all downstream devices it represents, to the extent that the owner(s) of those devices has made the capabilities accessible.

Section 4.1.8: Do we have some convention when citing specification titles (e.g., Quote marks, Underline. It is not clear what the title is vs the surrounding words. 

Section 4.2, line 870: semicolon before "however".

Section 5, General:  The paragraph for each operation clearly indicates that the Proxy is the only possible authenticated user for these operations. But each operation also identifies Requesting User attribute in a more general way as supplied by the Proxy, but not as being the Proxy.  Section 8.3. of RFC2911 refers to "job-originating-user-name" and the "job owner", which would suggest the original job originator rather than the Proxy. It is unclear who or what this attribute should refer to. This situation also appears in Section 6, although since these are less Job related operations, there is less potential for confusion.

Section 5.4, line 1190: ” If the Output Device has previously sent..." This is confusing, since the Proxy sends the messages, not the Output Device.

Section 7.4.5: I am less certain about making the path a MUST.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20150223/9b18d859/attachment.html>

More information about the ipp mailing list