Subject: IPP> Comments on Requirements document

From: Roger K Debry <[email-masked]>
Date: Thu, 9 Oct 1997 12:27:15 -0400

I apologize for not being able to participate much recently in the conference
calls. I've just been terriibly busy with my day job and have been traveling a
lot. I did sit down and review the requirements document while on the plane
this week. Here are my comments:

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 should
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 the
sentence that begins "When checking the status on jobs ...". Also
take out the last bullet, how are job priorities assigned. I don't think
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 paragraphs.

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 here.

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 new
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 security
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 exist
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: [email-masked]
phone: 1-303-924-4080

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 9 Oct 1997 12:33:21 PDT

Roger,

Thanks for actually taking the time to go over the Requirements document in
the light of later events. I think that the proposals you have made for
improvements are all contructive and useful.

We need to find out from Don if he has any chance to actually work them
into the document before our next I-D delivery deadline, which is next
Wednesday October 15.

Comments from anybody else on this?

Carl-Uno

>Architecture and Technology
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]