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
At 09:27 AM 10/9/97 PDT, Roger K Debry wrote:
>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: rdebry at us.ibm.com>phone: 1-303-924-4080
>>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: manros at cp10.es.xerox.com