o I think it would be good to have something in the introductory text
explaining our rationale for determining what were version 1.0 IPP
req'ts. In particular, I think some words of the tone that our goal was=
to hit the 80% mark quickly and that rapid deployment was a
major objective, would be important things to say. Otherwise it is
hard to understand why some things aren't considered valid req'ts
for version 1.0.
o In the terminology section, the discussion is cast in terms of an
overall internet printing solution. I think this is fine, and as it sho=
uld
be. However, a sentence or two simply explicitly saying that IPP is
but one key component of an internet printing solution would seem
important. Then going on to say how things like locating printers and
creating printer instances is enabled by IPP seems to work better.
o The latter part of the first paragraph in section I and the second
paragraph seem to be too Browser-centric. I think these could be
deleted altogether, or based on the previous comment simply say
that HTTP, and Web Browsers are **other** components of a
complete internet printing solution. As it stands, one could easily
come away believing that IPP running on a browser is a major
requirement of IPP.
o I think the third paragraph of section I is slightly misleading.
While it says that "No assumption is made about multi-tiered
printing solutions", it does not make clear that such solutions
are in fact supported by the protocol. I think as written, it might
leave the reader believing server congurations are not
supported. Just a few word changes would fix this.
o Section 2 introduces the three user roles, end-user, operator,
and adminsitrator. Although we say it elsewhere, I think it important
to say right here that only end-user functions are considered as
version 1.0 requirements.
o In the second paragraph of section 1.2, I'd spell out the six
categories more carefully. For example, finding/locating should
be finding/locating a printer, local instance should be creating
a local isntance of a printer, etc.
o Add the phrase "by their IPP attributes" to the last sentence
of section 2.1.1.
o In the last set of bullets in section 2.1.3, I'd suggest taking out t=
he
sentence that begins "When checking the status on jobs ...". Also
take out the last bullet, how are job priorities assigned. I don't thin=
k
there is anything in IPP that describes **HOW** priorities are
assigned. I think this would read better with these changes and
better reflect actual usage.
o I think section 2.1.4 needs some work. I believe we defined three
distinct usages: Printing from an application, which places a req't on
the protocol to support streaming, pushing a previously created file,
and print by reference (pull). The simple push case doesn't get
covered as this section is written.
Also, the second paragraph seems confusing and I am not sure it
adds much to the document. In any case, the three bullets listed here
are all outside the scope of IPP. I believe that everything that needs =
to
be said in terms of requirements here is said in the following paragrap=
hs.
o In the second paragraph of section 2.1.6, the second sentence begins
"New notification means ...". I don't think the word New is required he=
re.
o In section 2.1.6, I would prefer that we say changing job properties =
or
changing job attributes, instead of Altering the print job.
o Section 4 would seem to better fit before section 3. Thus all of the=
general discussion of requiremetns comes first, then the high level
scenarios, then the datailed scemarios comes last.
o In section 3.0, there is quite some discussion of the three physical
environments supported in the scenarios. In fact, the physical
environments are quite transparent and aren't discussed in any
way in any of the scenarios. If it is appropriate to keep these three
models in the requirements document, then I'd suggest that this
discussion be moved to section 1.o and replace or supplement
the third paragraph in section 1 which says that "No assumption
is made about multi-tiered environments."
Also, we long ago decided to get rid of the notion of inside and
outside of firewalls in the security document. I'd suggest taking
this discussion out of section 3 and supplementing the security
discussion in paragraph 4.1.
o Replace section 4.1 with the following (from the security ID):
It is required that the Internet Printing Protocol be able to operate
within a secure environment. Wherever possible, IPP ought to make
use of existing security protocols and services. IPP will not invent ne=
w
security features when the requirements described in this document
can be met by existing protocols and services. Examples of such
services inlcude Transport Layer Security (TLS) and HTTP Digest
Authentication.
Since we cannot anticipate the security levels or the specific threats
that any given IPP print administrator may be concerned with, IPP
must be capable of operating with different secuity mechanisms and
policies as required by the individual installation. The initial securi=
ty
needs of IPP are derived from two primary considerations. First, the
printing environments describes in this document take into account
that the client, the Printer, and the document to be printed may all ex=
ist
in different security domains. When objects are in different security
domains the requirements for authentication and message protection
are much stronger than when they are all in the same domain.
Secondly, the sensitivity and value of the content being printed will
vary from one instance of a print job to another. For example, a
publicly available document does not need the same level of
protection as a payroll document does. Message protection
requirements include data origin authentication, privacy, integrity,
and non-repudiation.
o In section 8, the appendix, you should preface this entire section
with the caveat that these scenarios describe internet printing
applications, which are **enabled** with IPP, and that many of the
flows shown are not actually within the scope of IPP. Also, you
should mention that many of the IPP flows are beyond the scope of
version 1.0.
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080
=