IPP> REQ - Last minute scenario comments

IPP> REQ - Last minute scenario comments

IPP> REQ - Last minute scenario comments

Carl-Uno Manros cmanros at cp10.es.xerox.com
Tue Jan 28 21:11:41 EST 1997


here are my comments on the scenario document.

Major scenario concern:

I am still unhappy about the Printer Discovery scenarios, at
least if we assume that they will be realized by directory
or name service functions only. 

They seem to be asking for a lot more detail to be put into
the directory than I had anticipated.  My going in assumption
has been that we want to have a limited number of directory
attributes on which we can do searches to LOCATE Printers, but
not to find out about ALL the detailed capabilities of a Printer.
My feeling is that we should not plan on having more than
10 - 15 directory attributes for a printer, or we are going 
to overload the directory administration with too much detail
that all has to be maintained in addition to the Printing system.
The X.500 standard has defined the attributes for a Device, I
suggest that we build on that and add a limited number of printer
specific attributes - but not dozens of them. 

If we want to get more detailed information about a printer's 
capabilities, I would expect to go and ask for that Printer's 
attribute list, using the IPP. Any variable information, such as 
media loaded, or printer state has nothing to seek in the directory.

As further examples, I would consider information about security 
details and payments to be part of the printer information, but not 
in the directory entry. In the directory I would expect to just 
find out whether the printer has unrestricted access or not - period.

However, we should be able to keep the basic scenario requirements, 
but not assume that everything is happening in one simple interchange.
The realization of the scenarios should be possible through a com-
bination of a directory search and one or several list inquiries
on Printer objects in IPP. (The steps in between may or may not be 
visible to the user).

Editorial concern:

We need to explain more clearly what the bullited lists mean:

Example: In scenario picture 3.0, the response bullits obviously
mean that they are alternative responses, but in the following 
scenarios 3.1 etc. the bullits stand for a sequence of parameters.
BTW, the parameter "tell me the status of the job", I would put at 
the end of the list, as it should reflect the job state after the 
other parameters have been acted on as reflected in the response. 
(This ambiguity occurs in many more scenarios).

More detailed scenario comments:

In scenario 3.8, which was addeded as result of an earlier request 
from me, I would like to have "chunks" as in scenario 3.6, and not
have "Letter-to-Mom" as example, but rather "Long-Run-of-Invoices"
of undeterminable length (when the job starts printing).

I think that scenario 4.0 needs to get refined into more than 
just Getting Status. In effect there are at least the following kind 
of functions described under scenario 4.

1) Getting detailed information about a printer's capabilities (static)

2) Getting information about a printer's status (variable)

3) Getting information about a job's status (variable) and fixed attributes.

In scenario 5, I suggest taking out (Email) in the heading. Maybe we could 
come up with some alternative to email in the more detailed scenarios, such 
as "beeper with display" (wonder if they will have URLs soon?).

We need to make more detailed scenarios for different security environments,
as already planned by the Security subgroup. Until that work is done, I think
we should keep down the number of security feature details in this version
of the scenarios - we probably get them wrong. 



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

More information about the Ipp mailing list