Subject: IPP> REQ - Comments/issues on Feb 17 (01a) Requirements document

From: Tom Hastings <[email-masked]>
Date: Wed, 5 Mar 1997 12:59:13 PST

Here are my comments on the Requirements document (in addition to changing
the "WEB Browser-based" terminology).  Issues are labeled ISSUE n:

1. Mention V1.0 some where and that V1.0 is only end-user.

2. ISSUE 01 - Need to flag which requirements are for V1.0 and which are 
for a later version.

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.

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

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.

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?"

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

8. Page 8, top, add:
   - stapling
   - one sided vs. two-sided printing

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

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)."

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

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.

15. Page 13, add help desk as something that can come back, but can't
be filterred upon in the query.

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!!!

17. Page 14, last line, add "ready and defaulted" to: "Job submission 
attributes supported/required".

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.

19. Page 16, 4. Objective of the Protocol
Add as an objective that IPP may be used directly by the operating system.

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.

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

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.

23. Pages 26-...
The state of the job should be renamed from "spooled" to "pending", since
the job may or may not be spooled.

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?

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.

---

From: Patrick Powell <[email-masked]>
Date: Wed, 5 Mar 1997 17:20:31 -0800 (PST)

Prof. Patrick Powell
Dept. Electrical and Computer Engineering,
San Diego State University,
San Diego, CA 92182-1309
Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577
email: [email-masked]

> (or a set of fan-out output devices).

I would like to note that this comment appears to be in line with my 
revised model of the Printer.  By having 'Interface URLs' corresponding 
to the various protocols for connecting to the printer,  you can have the 
fan-in capability Mr. Hastings has outlined.  Also, the queue and active 
job handler will also fit in well with this model.

> whether he/she has a job submitted or not.

I have thought about the problem of asynchronous notification,   and in my
outlined changes introduced a 'Administrator' object.  This will be the 
object that is in charge of and generating notification.  Note that now 
it will have attributes, etc. that can be examined and requested.

Patrick Powell