Michael wrote:
I've never seen such a combination, but assuming that such a composite
printer object exists, it *should* be smart enough to route B&W jobs
to the B&W printer and color jobs to the color printer. If the job
gets bound to a single output device then the implementation is no
better than one that exposes multiple printer objects.
<th>
I assume that a client submitting a single job containing a black and white
document and a color document to the same Printer wanted them to be printed
together. Perhaps, even asking for multiple copies collated, so that they
could be handed out at a meeting. So such a composite Printer shouldn't
split up a Job, sending one document to one device and the other to the
second device.
If the client didn't care whether the two documents came out together on a
single device as a single job, then the client should submit each document
to two separate Printers, where one controls a black and white device and
the other controls a color device.
</th>
> ...
> Then the client can decide to break the job into two jobs and submit
> each document as separate jobs or find another Printer (without
> having sent *any* document data for either document).
How is this different from the Send-Document case?
<th>
The difference is that the client didn't send any data for the first (black
and white) document when discovering that the Printer can't accept the
second (color) document and print both of them on a single device.
</th>
> ...
> 2. Use Case 2: client doesn't have all of the documents up front
>
> A second use case that the Create-Document operation allows is a
> client that is collecting documents over a period of time (if the
> Printer's "multiple-operations-time-out" Printer Description
> attribute value is large enough). For example a mail reader or a
> browser that submits each document as the user selets it, but want
> all of the documents to come out as one job. (Of course, you could
> argue that the client should buffer up all of the selected documents
> as the user selects them and then submit them all at once with
> Create-Job and Send-Document). That client could perform each
> Create-Document operation as the document was available, but not send
> the data for any until the client was assured that all documents
> would be acceptabel to the Printer. (Note: if the client sends the
> data as each document was available, then that client could have used
> the Send-Document instead.)
>
> I'll add some more explanation of this in the spec.
But that, too, doesn't hold up. Nothing prevents the client from
mixing Validate-Job and Send-Document operations on-the-fly.
<th>
Of course, a client can do a Validate-Job before each Send-Document, to get
the same effect as the Create-Document, Send-Data, except for the validation
across documents in the Job.
</th>
> 3. Denial of Service attacks with multiple Create-Document requests
>
> You mention the down side to having Create-Document is the denial of
> service where a client could issue a large number of Create-Documents
> and use up the Printer's slots for documents. However, how is this
> any different to such a malicious client issuing a large number of
> Create-Job operations? It seems to me that a robust Printer
Because for Create-Job we have defined a status code that allows the
server to tell the client that they can't create any more jobs,
which allows the server to provide configurable max-jobs,
max-jobs-per-printer, max-jobs-per-user, etc. limits to prevent a
DoS attack or simple abuse (CUPS provides all of these BTW...)
> implementation has to design its data structures and use of disk
> memory so as not to have artificial limits of either Jobs or
> Documents. Only when the total space is used up would be the denial
> of service occur. So a robust Printer implementation also needs to
> defend against an excessive number of Create-Job requests and
> Create-Document requests.
Indeed, and such implementations already exist.
Also, just because you have disk/RAM available doesn't mean that you
want to allow a user to successfully attack your server.
Again, in my comments I suggested that *if* Create-Document and
Send-Data were absolutely necessary (and I still haven't heard a
compelling reason for it), then we should also define a similar
status code which allows the server to apply limits to the number
of reserved documents in a job and tell the client when it can't/
won't add another to a job.
<th>
Yes, it would be a good idea to define a new status code, so that the client
would know for sure not to try again for those implementations that have a
hard limit.
</th>
> I'll add some discussion of these two denial of service attacks in
> the Security Considerations section. Presumably, a Printer would
> return either a 'server-error-service-unavailable (0x0502)' status
> code ([rfc2911] section 13.1.5.3) or a 'server-error-temporary-error'
> (0x0505) status code ([rfc2911] 13.1.5.6).
Neither of these is specific enough to be of any use to the client;
unless it knows that it *cannot* create another document in a job,
then it will keep retrying, right?
> 4. Bottom line on Create-Document operation:
>
> ISSUE 02: So the real debate should be whether these two use cases
> are sufficiently compelling to have the added complexity of
> Create-Document and Send-Data? Or is doing a Validate-Job for each
> document sufficient (either before the Create-Job or before each
> Send-Document) and we can remove Create-Document and Send-Data from
> the spec?
I personally don't think that Create-Job and Send-Data are necessary,
and as presently defined they open up a serious (and obvious)
security hole WRT DoS attacks. While we cannot provide absolute
protection against such attacks, we *can* provide the necessary hooks
so that implementations can provide controls/limits/algorithms and
properly handle DoS cases.
<th>
Let's see if the PSI folks have a compelling use case for Create-Document,
Send-Data.
Let's see whether others find the two use cases that I cited to be useful
enough to warrant the added complexity of Create-Document and Sent-Data.
</th>
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Sun May 04 2003 - 06:59:35 EDT