Michael,
Are you saying that a client that wants to validate *all* of the documents
before sending any should just use Validate-Job, one for each of the
documents? If they all validate, then the client can send the documents
with Create-Job and multiple Send-Documents and they will all be accepted.
That will work usually, except for the following two use cases:
1. Use Case 1: One Printer supports multiple dissimilar devices
One case where this scenario doesn't quite work is for a Printer that is
fronting for a number of actual dissimilar devices, in which no one device
is a superset of all of the others. For example, a duplex black and white
printer and a simplex color printer (not an uncommon mixture). Here a
Validate-Job with "sides"='two-sided-long' for the black and white document
will succeed as will a Validate-Job with a "sides"='one-sided' and
"color-effect-type"='color' for the color document. However, the job
containing both documents will not be able to be printed as requested on
either device.
So the Create-Job, followed by the Create-Document for each of the documents
will (MAY/SHOULD/MUST?) get a failure on the second Create-Document, if both
documents cannot be printed in the same Job. 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).
REBUTTAL (against this use case): But some may argue that the simple IPP
Printer "xxx-supported" model for describing the Printer's capabilities
isn't able to correctly represent a Printer that fronts for dissimilar
devices where none is a superset of all of the others. In the example
above, the Printer would have both "sides-supported"='one-sided',
'two-sided-long' and "color-effect-type-supported" = 'color',
'monochrome-grayscale', so the Printer looks like it could support a duplex
color job. So Printers should not attempt to front for dissimilar devices,
unless one is a superset of all of the others. So why are we adding
Create-Document and Send-Document when Validate-Job for each document
suffices as long as Printers don't front for dissimilar devices where none
is a superset of all the others.
ISSUE 01: Perhaps the spec needs a MUST or SHOULD for the Create-Document
validation to include the combination of the previously accepted
Create-Document (and Send-Document/Send-URI) requests for that Job?
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.
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 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.
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).
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?
Perhaps there are other use cases that I have left out as well.
For example PSI has separated Create-Document from a Send-Data equivalent.
So the PSI group needs to participate in the use case discussion.
Let the debate begin...
Tom
-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Thursday, May 01, 2003 18:26
To: McDonald, Ira
Cc: ipp at pwg.org
Subject: Re: IPP> Document Object Spec Comments... [for Thur 5/15]
McDonald, Ira wrote:
> ...
> So, could you possibly explain a little more your various
> comments below by email? And (if you can) join the SM
> telecon in two weeks?
I don't know if I'll be able to, but if I am free I will call in.
> ...
> [I don't understand how you can map Create-Document
> to Validate-Job. Could you explain, please?]
> ...
The spec mentions using Create-Document to validate the format and
attributes of a document prior to submission, which is exactly what
Validate-Job does. While Validate-Job won't reserve a slot for a
document like Create-Document, I see that particular feature of the
Create-Document object as the biggest potential security hole in
the spec with very little benefit. Realistically speaking, if a
document format and specific job template attributes are acceptable
at one time, then they will be acceptable all the time for that
printer object.
If the Create-Document semantics are absolutely required (I don't
see that, but if so the spec should include the justification/reason
for it), then I highly recommend that we either place a limit of 1
outstanding document per job or add a new status code ("server-
error-too-many-documents"?) so that the server can enforce limits to
avoid Denial-of-Service cases.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com