Here are my comments on version 1.3 of the IPP 1.0: Model and Semantics
spec. I'll comment on Tom's document on printer status on 2/21.
Enjoy!
Keith
1. Section 3.2. Job. Page 8. Line 302.
Remove "This list needs updating:" from list.
2. Section 4.1.3.1. Get-Attributes Request. Page 12.
Line 419.
In my opinion, we should list the special attribute
groups referred to in the subsequent sections of the
spec so it is clear to the reader that an IPP
application may specify these groups in a Get-Attributes
request. These attributes groups include:
- identification (5.2.1)
- jobClient (5.3)
- jobTemplate (5.3)
- jobNotification (5.3.2)
- jobScheduling (5.3.3)
- jobProduction (5.3.4)
- documentProduction (5.3.5)
- textFormatting (5.3.7)
- jobSize (5.3.8)
- numberOfDocuments (5.3.9)
- jobSetByPrinter (5.4)
- jobOwner (5.4.1)
- jobStatus (5.4.2)
- documentData (5.4.3)
- printerDescription (5.5)
- printerStatus (5.6)
- printerBehavior (5.7)
3. Section 5.1. User privilege level. Page 17. Line 530.
The security model implied by the "User privilege level"
tag is not clear to me. I believe a Printer should know
the role (i.e. end-user, operator, admin) of the user
making a print request and should only return attributes
that apply to a person with that role for that Printer.
I do not believe a Printer should rely on a client to
sort through which attributes apply to a user based on
the client's understanding of the user's role. See my
notes for section 6, Security Considerations for more
information.
4. Section 5.1. File type. Page 17. Line 536.
In my opinion, the "File type" tag is too complex for
IPP 1.0. I believe the "File type" tag implies (1) an
IPP application must first determine the datatype of a
document to be printed (2) the application must then
parse through attributes returned by the Printer to pick
out those that apply to that datatype (3) a Printer
implementation must tag these attributes in the first
place. Typically, I see administrators setup a separate
Printer for each datatype supported by a physical
device. For example, for a device that supports PCL and
Postscript, there will be 2 Printers. Each Printer has
its own printer driver (i.e. a PCL or Postscript printer
driver) with default job properties (i.e. job template)
supported by the driver.
5. Section 5.1. Scheduling. Page 18. Line 547.
What specific attributes can have the "Scheduling" tag?
What is a scenario that shows how this tag will be used?
6. Section 5.1. no tag. Page 18. Line 572.
"... this value and schedule it ..." should be "... this
value and schedule the job when ...".
7. Section 5.3.2.1. notification-events. Page 22. Line
690.
This section needs to specify the events for which an
end-user will implicitly receive notification. Line
709-710 implies that an end-user will always receive a
notification if their job is cancelled. So, that
explains why there is not a notification event called
"job-cancelled". This statement also implies a required
behavior of a Printer. This information might be more
clear to the reader if it is stated in the
notification-events section. Here is a proposed
paragraph:
A Printer must notify an end-user when their job is
cancelled and therefore will not be printed by the
Printer.
Or, we can decide to add a "job-cancelled" value.
8. Section 5.3.2.1. notification-events. Page 22. Line
690.
Here is an idea. It is possible that an end-user's job
might be held or resubmitted outside the context of IPP
1.0. The spec could add support for "job-held" and
"job-resubmitted" notification events or else indicate
that these are implicit ala "job-cancelled". Opinions?
9. Section 5.3.3.1. job-priority. Page 23. Line 722.
Please change job-priority to a positiveInteger with
values 0-100 because: (1) this matches the Job MIB (2)
this supports ISO DPA (3) this supports PC platforms.
10. Section 5.3.3.2. job-retention-period. Page 24. Line
774-775.
Add to the NOTE: "The requester may also specify this
job attribute using the input parameter to the Print
operation." Correct?
11. Section 5.3.4.2. copies. Page 26. Line 844-845.
Remove this note because files-are-one-document and
files-are-interleaved are not defined in the spec.
12. Section 5.3.5.2. medium. Page 30. Line 896.
I recommend an additional input-tray of "automatic"
since some printers automatically select the input tray
based on the media requested by the end-user.
13. Section 5.3.6.1. document-format. Page 34. Line 975.
The list of document-formats should be referenced in
this section. Possibly include the formats in an
appendix or reference another spec.
14. Section 5.3.7. Text Formatting. Page 34. Line 981.
Please consider adding the following attributes:
* Font Style (normal, bold, italic, bold-italic)
* Line Numbers (print line numbers in the left margin)
* Text Border (print a border around the text)
* Word Wrap (wrap or don't wrap long lines)
* Number of Columns (single or multi-column text)
* File Name (print file name per page)
* File Time (print time of file per page)
* File Date (print date of file per page)
15. Section 5.3.7 Text Formatting. Page 34. Line 981.
Can Document Production Attributes, such as sides, apply
to printing Text and HTML files? I believe so. If so,
then the spec should state this.
16. Section 5.3.7.14. content-orientation. Page 36. Line
1046.
In my opinion, content-orientation should be a Document
Production attribute. This attribute may apply to all
types of print jobs - not just text jobs - including
jobs that are converted by an IPP print driver from a
graphics API (e.g. Gpi or GDI) to a device datastream
such as Postscript or PCL.
17. Section 5.3.9. Number of Documents. Page 37. Line
1079.
Nit. How does a Printer specify there is no limit on
the number of documents per job? By using an "*"
(asterisk) as the upper number of the range? A large
number?
18. Section 5.4. Job Attributes. Page 38. Line 1093-1099.
The second paragraph indicates that an IPP application
can get the URLs of a Printer's Job Templates and
references attribute "printer-job-templates" neither of
which is supported in IPP 1.0. Here is proposed text
for that paragraph with revisions noted as <>:
A client may use a job template associated with the
selected <P>rinter to initialize the job. To do so, the
client uses the Get-Attributes operation <with the
"jobTemplate" attribute group in the request to a
Printer to obtain all attributes and values that an
end-user or application may specify when printing a job
on the Printer.> Then the client may get the default
attributes, <the default value for each attribute, and
the supported values for each attribute to display this
information to the end-user when they submit a print
job.> <delete: "See the printer-job-templates Printer
attribute."> However, a client need not access the
<j>ob <t>emplate <attributes> to issue a Print
operation; the client can depend on the Printer to
supply the default job attribute values as part of the
Print operation.
19. Section 5.4.1.1. job-originating-user. Page 38. Line
1110.
The spec should state that job-originating-user is
acquired by the Printer from the protocol used for the
Print operation. For HTTP 1.0, this would imply use of
the Authorization request header field on a Print
operation so the Printer can obtain the user id of the
end-user who submits the print request. A proposal is
to change the word "client" at the end of the second
sentence to "protocol".
20. Section 5.4.1.3. user-locale. Page 38. Line 1114.
The spec should reference the source of the valid locale
values. The reference could be a URL or to an appendix
in this spec.
21. Section 5.4.2.2. job-state. Page 40. Line 1137.
In my opinion, the "Printing" job-state should only be
set if a job is actually being printed by a device.
This way, an IPP application can clearly show an
end-user when their job is being printed. I propose we
use "pending" if the job is being spooled or has been
queued for a device and use a job-state-reason to
specify why the job is pending. See comment #23 for
more information.
22. Section 5.4.2.2. job-state. Page 40. Line 1137.
In "Completed" remove "(2) job-discard-time has
arrived." since job-discard-time is not supported.
23. Section 5.4.2.2. job-state-reasons. Page 40. Line
1137.
Please confirm/correct the following table. An asterisk
"*" indicates a combination I don't see in the spec.
job state job state reason condition
unknown n/a n/a
* pending job-spooling job spooling
* pending sending-job-to-printer job being sent
from client or
server to
device
* pending job-queued job queued
pending job-processing job in printer
pending required-resources-not-ready paper out etc.
pending logfile-pending ?
pending logfile-transferring ?
* pending job-held job held in
queue or device
printing n/a job printing
terminating cancelled-by-user job ending
terminating cancelled-by-operator "
terminating aborted-by-system "
retained successful-completion job stacked and
retained
retained completed-with-warnings "
retained completed-with-errors "
retained cancelled-by-user job cancelled
and retained
retained cancelled-by-operator "
retained aborted-by-system "
completed successful-completion job stacked
completed completed-with-warnings "
completed completed-with-errors "
completed cancelled-by-user job cancelled
completed cancelled-by-operator "
completed aborted-by-system "
In my opinion, we should replace "job-incomplete" with
"job-spooling", "sending-job-to-printer" and
"job-queued" so an IPP application can show the end-user
the state of their job throughout the printing process.
24. Section 5.4.2.5. submission-time. Page 41. Line 1149.
In the first sentence, specify that submission-time
indicates date in addition to time.
25. Section 5.4.2.6. number-of-intervening-jobs. Page 42.
Line 1154.
Please change "if performed" to "is performed".
26. Section 5.5.1. printer-name. Page 43. Line 1215.
In my opinion, the spec should keep the "printer-name"
attribute so an Administrator can provide a meaningful
name to the Printer.
27. Section 5.5.2.2. printer-type. Page 44. Line 1221.
Is printer-type necessary in IPP 1.0? How does this
help the end-user?
28. Section 5.5.2.3. maximum-printer-speed. Page 44. Line
1229.
"characters per minute" should be "characters per
second" to match "cps" in standard units. What is the
syntax for 10 ipm?
29. Section 5.6. Printer Status. Page 44-46.
I will comment on Printer Status in a separate note.
30. Section 5.7.1.1. printer-locale. Page 47. Line 1286.
There is no "job-locale" attribute in the spec plus the
locale values are not defined in the spec. Change
"job-locale" to "user-locale" and use the reference in
"user-locale" as a reference to the valid locale values.
31. Section 5.7.1.4. end-user-acl. Page 47. Line 1289.
How is "end-user-acl" used? I believe a Printer should
know its acl (i.e. end-user, operator, admin) for the
end-user who makes a print operation and, based on this
acl, determine if an operation is valid. I do not
believe a Printer should return acls to a client and
then rely on a client to determine if an end-user is
authorized to use a Printer. Besides, I'm not sure we
want acl information flowing across the network. I
propose we remove this attribute.
32. Section 5.7.1.4. scheduling-algorithm. Page 47. Line
1297.
How does this attribute help the end-user? I propose we
remove this attribute from IPP 1.0. I believe we
removed a similar attribute from the Job MIB.
33. Section 5.7.1. Printer Behavior. Page 47. Line 1283.
Please keep "document-formats-supported". This
attribute will help an IPP printer driver determine the
valid formats for a Printer so that the printer driver
can send the most efficient format possible to the
Printer. For example, OS/2 supports a metafile format
as well as device formats such as PCL and Postscript.
It is more efficient to send a metafile across the
network if a Printer supports this format in addition to
a device format.
34. Section 6. Security Considerations. Page 48. Line
1319-1320.
Remove sentence "The authentication mechanism built into
HTTP ..." since the spec does not specify a protocol and
therefore should not specify HTTP.
35. Section 6. Security Considerations. Page 48. Line
1319-1320.
How is an end-user's identity known by the Printer for
operations such as CancelJob and GetAttributes? Does
IPP assert that the underlying protocol provides the
identity of the end-user on print operations? If so,
the spec should state so. For HTTP 1.0, this would
imply use of the Authorization request header field on
such requests (hopefully after the initial logon, the
client will cache the user id and password so as not to
prompt the end-user to logon for every subsequent print
operation).
Here is proposed text for this section with revisions
noted as <>:
This <specification> does not identify any new
authentication mechanisms. <This specification relies
on the underlying protocol to identify an end-user
(possibly using a user id and password) to a Printer for
each print operation. Furthermore, this specification
relies on the Printer to authorize each print operation
and to only return attributes for which an end-user is
authorized to view and specify.>
<delete 2nd and 3rd paragraphs>