I have spent a fair amount of time thinking about your comment,
and I think you are overly pessimistic here. I think that
most of the Requirements scenarios are illustrative, rather than
mandatory, and not meant to force on a specific action.
There is a desire to divide up the protocol into 'printer' and
'management' functions. However, by removing management OBJECTS like
queues, databases, etc., from the model, this leads to conceptual
difficulties when trying to figure out how to deal with printers
without dealing with the fact that there is a queue (i.e. - maximum
length 1, perhaps, mind you) in the printer, and that there is a
database (implicit perhaps) in the printer about what functionality it
supports.
I feel that by putting the various items into the model, and
addressing the operations on the queue and/or database in the
same way as the printer, then things will become clearer.
For example, I feel categorically that the setting up and modification
of the database is NOT part of the IPP standard. This is an
out of band issue, and should not be addressed in the standard,
nor should the behaviour of the printer be addressed during
updates, etc.
On the other hand, I feel that basic queue management functions,
such as restriction of submission of jobs by some criteria
SHOULD be part of the standard; the implementation of this
should NOT be part of the standard. This is currently the way
the MODEL document words things, and I like this concept.
Now, before everybody starts saying that this has been discussed
repeatedly, and that everybody agrees that this is only meant
to handle printers, you have embedded all of the concepts of a
general spooler in your printer REQ document.
Patrick Powell