Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
Tom, I've looked at your comments and have responded to several of them. I am
assuming that Don, as editor of the requirements document has the final say on
what changes are made. These are my suggestions:
1. Mention V1.0 some where and that V1.0 is only end-user.
RKD>> Sounds reasonable
2. ISSUE 01 - Need to flag which requirements are for V1.0 and which are
for a later version.
RKD>> I believe that everything in the current
RKD>> document is end-user related, so is
RKD>> therefore a V1.0 REQUIREMENT. We have
RKD>> discussed some things as being too complex
RKD>> to implement in V1.0, but does that make make
RKD>> it not a requirement? Isn't it okay not to meet
RKD>> all requirements?
3. ISSUE 02 - Add requirement that the client can
specify in each operation whether the responses
to the IPP operation is to be in HTML or IPP.
RKD>> Isn't this a protocol/implementation issue
RKD>> and not a requirement?
4. Page 5, 2.1 End-User 2nd para:
Problem: Cancelling a job not mentioned, and modifying a job is not
currently a V1.0 operation.
Suggested fix: change "altering the print job" to "cancelling the print job".
If modifying a job is a requirement for V2.0, also add something like:
"For Version 2.0, modifying a submitted job."
RKD>> See response to Issue 01.
5. Page 5, 2.1.1 Finding or locating a printer:
Problem: Should be able to find from other desktop tools, in addition to
browsers.
Suggested fix: add "or other desktop tool/application" to the end of the
second sentence.
RKD>> Sounds reasonable.
6. Page 7, what the user typically wants to be able to determine about
status on jobs queued: add "where is(are) my job(s) in the queue?"
RKD>> Sounds reasonable.
7. Page 7, 2nd to last paragraph, first line: Change "Print jobs will be
submitted by background" to "Print jobs will also be submitted by background".
RKD>> Sounds reasonable.
8. Page 8, top, add:
- stapling
- one sided vs. two-sided printing
RKD>> We have said that the list is not exhaustive.
RKD>> Do we really need to add these two? If so,
RKD>> then what other's have we missed?
9. ISSUE 03 - Page 8, 2.1.5 Viewing the status of a submitted print job
Problem: Without some notification defined, interoperability is a serious
problem. Also the model document has some notification methods defined.
I believe that a program needs to be able to receive notification that it
can parse, so just e-mail and html append, while necessary, are not
sufficient notification methods. Last paragraph says that IPP won't define
notification capability.
RKD>> To my remembrance, we have never discussed this as
RKD>> a requirement. Why must we define a machine parsable
RKD>> notification? Cast this in end-user terms.
Suggested fix: IPP will define severval notification methods meeting the
following requirments:
1. A method that is ubitquous and intended for system to human notification
(e-mail).
2. A method that is lightweight and intended for system to human notification
3. (new) A method that is lightweight and intended for system to program
notification.
10. Page 8, section 2.2 Operator and its sub-sections should be labeled
IPP V2.0.
RKD>> I don't know if we need to label the section as
RKD>> V2.0, but we clearly need to say that these are
RKD>> V2.0 operatiions. Same goes for 2.3.
11. Page 9, section 2.3 Administrator - same
12. ISSUE 04 - Page 11, 3. IPP Scenarios, three physical configurations:
Problem: Has fan-out, but needs to add fan-in without adding any additional
complexity to V1.0. Fan-in is useful for giving different personalities
(i.e., different defaults and different capabilites to the same output
device, especially now that many Printer have multiple interpreters in them).
Also fan-in allows the Administrator to specify different access control to
different capabilities of a single output device. To the end-user
and to the IPP V1.0 protocol, such fan-in will be transparent and behave
just as if each accessible Printer controlled a separate output device.
The user might happen to notice that quering jobs on several fan-in Printers
may show the same jobs and that the state of the fan-in Printers seems
to change in lock-step, but that is the only end-user observable consequence
of supporting fan-in of Printer objects to a single output device
(or a set of fan-out output devices).
Suggested fix: Add the following sentence to the third bullet:
"Each IPP Printer object may be associated one-to-one with a disjoint set
of output devices (fan-out) or multiple IPP Printer objects may be associated
with a disjoint set of output devices (fan-in)."
RKD>> I think fan in could be added, but I don't care for your
RKD>> words. Does veryone else agree that we should add fan-in?
RKD>> Tom seems to be the only one I've heard from?
13. Page 12, section 3.1, Printer Discovery
Change "Printer" to "Directory" in:
"The actual protocol used between the client and the Printer is
considered outside the scope of IPP."
RKD>> Agreed.
14. Page 12, some of the bulleted items are results, not inputs to a
directory query filter, such as "how to get more information".
Suggested fix: Separate what can be filtered on input from what can
come back from a Directory entry.
RKD>> I think the section is correct as it stands, all
RKD>> are things to be considered when locating a printer.
RKD>> I don't think we need to break the bulleted list into
RKD>> inputs and outputs.
15. Page 13, add help desk as something that can come back, but can't
be filterred upon in the query.
RKD>> See previous.
16. Page 13, 3.2 Driver Installation
Add "provide instructions to the end-user for installing the driver".
Currently you get get drivers, but you need to know some magic, such as
looking in some magic directory for an .EXE file and double clicking on that.
Phew!!!
RKD>> I guess this could be optionally provided.
RKD>> I don't see the content of a response as being
RKD>> architected as part of IPP anyway.
17. Page 14, last line, add "ready and defaulted" to: "Job submission
attributes supported/required".
RKD>> I'd need to read the model document again to see
RKD>> if this belongs here as a requirement.
18. Page 15, 3.5 Asynchronous Nofication
Clarify whether this is notification to an end-user (V1.0) of printer problems
with his/her job and problems with the Printer for which his/her job is
pending versus (V2.0) and operator that wants notification independent of
whether he/she has a job submitted or not.
RKD>> Does it matter? We will say that operator things are V2.0.
19. Page 16, 4. Objective of the Protocol
Add as an objective that IPP may be used directly by the operating system.
RKD>> I agree.
20. ISSUE 05 - Page 16, after 4.2 add requirements for Extensibility
(that BSD didn't have). I suggest something like:
4.3 Extensibility
The IPP protocol is intended to be extensible by several different means
that facilites interworking and prevents implementation collisions:
- Provide a process whereby implementors can submit proposals for registration
of new attributes, new enumerated values to existing attributes, and new tags
for attributes or attribute values for review and approval. IANA will be the
repository for such accepted registration proposals after review.
Such a process has been used for the Printer MIB (RFC 1759). See type2enum.
- Provide a process whereby implementors can submit proposals for registration
of new attributes, new enumerated values to existing attributes, and new tags
for attributes or attribute values that do not require review and approvel.
IANA will be the repository for such registrations.
Such a process has been used for the Printer MIB (RFC 1759). See type3enum.
- Provide syntax in the protocol so that implementor may add private
(unregistered) attributes, enumerated attribute values, and tags.
RKD>> You have focused on attributes ... don't we need to be
RKD>> even more general? What about adding new operations, etc?
21. Pages 26-...
We've agreed in the Model group to change the response on the Print operation
from getting Printer status, to getting job status that includes whether the
Printer is stopped.
In particular Page 28 should be something like:
job-state=pending, job-state-reasons=printer-stopped
RKD>> Does the requirement have to precisely reflect
RKD>> the model? I don't believe so. The objective of
RKD>> the requirement is to describe in (hopefully)
RKD>> general terms what the end user expects. If we
RKD>> choose to provide more information or use slightly
RKD>> different words in the model that should be okay.
RKD>> Personally, I'd be suspicious of a requirments
RKD>> statement that precisely reflected the terminology
RKD>> and implementation of the protocol. Would sound like
RKD>> we wrote the specifciation first and then justified
RKD>> it by writing the requirement later.
22. Pages 26-...
In the model group we've changed the name of the printer state from
"printing" to "processing" to be more general, and less restrictive.
RKD>> See previous response.
23. Pages 26-...
The state of the job should be renamed from "spooled" to "pending", since
the job may or may not be spooled.
RKD>> See previous response.
24. ISSUE 06 - Page 35, submitting a job to a non-spooling Printer and
printer jams and the end-user chooses to disconnect.
Is this a requirement for the IPP protocol or not?
RKD>> I think it is!
25. Page 52, 8.26 Asynch notification
Separate the cases of any job fails for which I've submitted a job, from
my job failed. Two separate cases.
RKD>> Isn't the second just a special case of the first?