IPP Mail Archive: RE: IPP> Document Object Spec Comments...

IPP Mail Archive: RE: IPP> Document Object Spec Comments...

RE: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Sat May 03 2003 - 20:15:48 EDT

  • Next message: Mike Sweet: "Re: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]"

    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@easysw.com]
    Sent: Thursday, May 01, 2003 18:26
    To: McDonald, Ira
    Cc: ipp@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@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Sat May 03 2003 - 20:16:29 EDT