Subject: IPP>REQ Comments on latest draft

From: Roger K Debry <[email-masked]>
Date: Thu, 20 Mar 1997 12:39:11 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

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.

---

From: JK Martin <[email-masked]>
Date: Thu, 20 Mar 1997 15:58:58 -0500 (EST)

> suggest changing "viewing printer status" to "viewing printer status and

True, view printer capabilities is quite essential.  However, since this
section of the document attempts to enumerate functions (rather than just
describing them in prose form), viewing status and viewing capabilities
should be two separate lines in the enumeration list.

> than "altering the status of a job".

Absolutely.  The statement of "altering the *status* of the job" has come
up frequently in the near past, and these words should be changed to
reflect reality.  Thanks for pointing this out, Roger.

> administrative function.  Do we need to point this out?

Hmm...  This sends up a couple of red flags to me.  Is IPP specifically
directed to solve only the needs of the Enterprise, or is IPP supposed to
equally apply to SOHO and home (ie, consumer) environments?  SOHO/consumer
environments typically do not have system administrators.

> Change the title to Viewing the status and capabilities of a printer.

Similar to the comment near the top, these two features should be described
separately.  A user might first query the capabilities of the printer before
submitting a print job (in which case the status may not be relevant), and
then query the printer for status after the job has been submitting (in which
case the printer's current capabilities are irrelevant).

> [...]

Considering the schedule, we should probably opt to simply state that the
functionality "includes, but is not limited to" that presented in the list.

> capable of support a WEB Browser shall be supported as a client".

So much for protocol independence for IPP...  ;-)

	...jay

---

From: Roger K Debry <[email-masked]>
Date: Thu, 20 Mar 1997 16:17:22 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

RKD> I didn't intend to suggest that IPP doesn't apply to SOHO
RKD> environment, or other environments where end users
RKD> typically install drivers. Just wanted to point out that
RKD> environments exist where end users are not allowed to.
RKD> When we get around to admin functions we may want to
RKD> allow an administrator to lock users out of this function.