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
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@cp10.es.xerox.com