Don, following are comments on the latest draft. Sorry these are a bit late,
but I have been traveling this week. I don't think that any of these comments
are significant conceptual issues, but rather are mostly editorial nits.
Overall document - do we need quotation marks around terms like end-user? This
is really a nit, but I find that they make the document uncomfortable to read.
Section 1 Terminology:
In the last sentence of the first paragraph you seem to mention all of the
possible IPP functions except two major end-user functions that version 1.0
addresses, namely submitting print jobs and querying device capability. I'd
siggest adding these to that last sentence.
The last paragraph talks about all requirements not being IPP 1.0
requirements. In fact some of the requirements (for example instance creation)
are not even going to be done with IPP. Therefore, I'd suggest that the first
sentence in the last paragraph on this page be modified to something like
"Throughout this document, certain requirements will be identified as not being
part of version 1.0 of the protocol or as being satisfied by means outside of
IPP. For example, ..."
Section2 Requirements:
I don't understand the example in the first paragraph of "Operator needs
physical access to the device." I'd recommend either clarifying this, or
picking a different example .
Section 2.1 End User:
In the last sentence where you enumerate the categories of function, I'd
suggest changing "viewing printer status" to "viewing printer status and
capabilities".
I think that the last item should be "Altering the attributes of a job" rather
than "altering the status of a job".
Section 2.1.1 Finding or locating a printer
The first sentence should start "End-Users want to ..." rather than "End-users
wants to ..."
Section 2.1.1 Create an instance of the printer
I think we should specify what we think the role of IPP is in providing this
function. I think we all clearly agree that "decompressing, unpacking, and
other installation actions" are far outside the scope of IPP.
In some environments, support organizations do not allow their end users to
install drivers and create printers on their desktops. This would be an
administrative function. Do we need to point this out?
Section 2.1.3 Viewing the status of a printer
Change the title to Viewing the status and capabilities of a printer.
Do operators and adminstrators have different privileges when viewing status of
jobs on a printer? I thought that the general agreement was that operators
need to be able to view the status of all jobs on a printer, while end users
only need to see the status of their jobs. Although this distinction might be
beyond the level of detail we want to put in the document, I think the fact
that end-users, operators, and administrators require different privileges is
an important point to note.
Section 2.1.4 Submitting a print job
Could you add "Production printing applications" to the list of normal
applicationsin the second sentence of the first paragraph of this section?
In the second paragraph, it seems to me that there are only two ways to
reallydetermine that the format of the data matches the capability of the
printer; either the printer figures it out based on scanning the datastream, or
the client queries the printer and generates the right data stream based on the
query.
Section 2.2 Operator
The last sentence of the first paragraph says "Operator requirements are not
needed for V1.0 of the protocol." Should this read "Operator requirements will
not be addressed ..."? Thay are probably needed, else they wouldn't be
requirements.
Maybe the last sentence is a place to talk about different privileges for
operators vs. end users.
Section 2.2.1 Alerting
I'd suggest changing "the printer" to "a printer" in places where the phrase
appears in this section.
Section 2.3 Adminsitrator
In the first paragraph change "Administrative requirements are not needed ..."
to Adminsitrative requirements are not addresses ..."
The requirements of the Adminsitrator include this of both the end user and
operator.
I suspect that this list of function is quite incomplete. Either we ought to
try to reasonably complete the list or say that the list is probably not
complete and more detail will be added when Adminsitrative functions are
addressed in the protocol. For example, Adminstrators will build directory
entries, fill in admin set attribute values (e.g. printer location), assign
printers to queues, set up policy, etc. etc. etc.
Section 4 Objectives of the Protocol
In the second paragraph chnage the second paragraph to read "Any platform
capable of support a WEB Browser shall be supported as a client".
Section 4.1 Security
I don't think that we agreed that privacy is a V2.0 requirement
Section 4.2 Interaction with LPD
Should the last sentence read "However, it should be possible to create a
gateway between LPD and IPP"?
Section 4.3 Extensibility
I think we ought to add a sentence that suggests that versioning of the
protocol will also provide extensibility, e.g. version 2 will be a proper
superset of version 1, and the version of the protocol to be run will be
negotiable. Furthermore, I believe that proper definition of operations,
defaults, and recognition of attribute types and values is all imporatant to
extensibility. For example, any printer must have the ability to return an "I
don't support this attribute" when queried and and take appropriate action
(default, best-effort, refuses teh job) when such an attribute appears in a
print request.