Here are my comments and actions on Roger's suggestions
>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.
I don't think this is appropriate in a requirements document. The
model or rationale document would be a better place to say this.
Saying something like "hitting 80% of the end-user requirements
is a goal of the first implementation" sounds like a cop-out to
me. This document lays out the requirements and the implementation
can make an informed decision about what to include in the first
release. Remember, this is NOT suppose to be a design specification
but rather a requirements document.
>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.
OK, added
>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.
OK, added
>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.
OK, changed
>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.
This is not needed again here. It is stated multiple times in the
document and is in fact stated in the immediately preceding
paragraph
>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.
OK
>o Add the phrase "by their IPP attributes" to the last sentence
>of section 2.1.1.
OK
>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.
I have reworded those two sets of bullets.
>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.
OK
>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.
Added a note that they are outside the scope of the IPP protocol
>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.
"New" deleted
>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.
2.1.6 was previously changed to use the "cancel" concept rather
than "alter." The only reference to "alter" is the statement: "Altering
the print job itself is not a V1.0 requirement."
>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.
OK, but I won't mark the whole section as changed.
>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."
OK, I moved this into the TERMINOLOGY section.
>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.
I have removed it from the old section 3.
>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.
I have copied this text into the document replacing section 4.1.
>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.
OK
---------------
Don
**********************************************
* Don Wright don at lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************