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

RE: IPP> Document Object Spec Comments... [for Thur 5/15]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu May 01 2003 - 19:47:38 EDT

  • Next message: Mike Sweet: "Re: IPP> Document Object Spec Comments... [for Thur 5/15]"

    Hi Michael,

    Next week's SM telecon is cancelled.

    But two weeks from now (Thur 5/15) we intend to devote to
    addressing your concerns about the Document Object spec.
    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?

    Today, we decided to break the current Document Object
    spec into _three_ specs:

    1) IPP Document object - only document specific stuff
    2) IPP Extensions for IPPFAX/PSI - only the extensions
        needed for PSI and/or IPPFAX (but NOT the higher
        REQUIRED conformance for any operation or attribute
        - that is left to the IPPFAX or PSI specs themselves)
    3) Miscellaneous IPP Extensions - stuff we want to add
        to IPP, but not on the critical path for PSI/IPPFAX

    We expect that these three specs progress (to Candidate
    Standards) in the numeric order above (Document object
    first, because it's critical to several PWG standards
    and several FSG Open Printing standards).

    [I don't understand how you can map Create-Document
    to Validate-Job. Could you explain, please?]

    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Mike Sweet [mailto:mike@easysw.com]
    Sent: Monday, April 28, 2003 11:08 PM
    To: ipp@pwg.org
    Subject: IPP> Document Object Spec Comments...

    First, given the number of changes/issues, I think we need to do
    another revision and review of the spec.

    OK, here is a list of problems with the current document object
    spec draft:

         1. Create-Document and Send-Data are not well thought out.
            Assuming that the current Validate-Job operation is
            insufficient to validate the document format and job
            template attributes for a document file, Create-Job
            adds a serious Denial-of-Service vulnerability - just
            do a bunch of Create-Job calls to use up all of the
            server's resources.

            My recommendation is to map PSI's Create-Document operation
            to Validate-Job with the additional job/document template
            attributes in the spec, and to map Send-Data to

         2. All MUSTs for the document-format-details collection
            attributes should be CMUSTs.

         3. document-format-details opens up a big can of security
            worms, and has very limited usefulness. Like print-by-
            reference, "packaged" files sometimes need authentication
            (passwords). They also can (and often do) contain embedded
            paths which are a serious security risk as well as an
            interop nightmare. If the purpose is for supporting web
            page printing, XHTML-Print is probably the way to go...

            Also, it is not clear how a client is supposed to determine
            whether the server supports this attribute; the absense of
            document-format-details-supported may not be sufficient
            since some implementations (e.g. CUPS) may choose not to
            send collection attributes that are not requested to
            avoid compatibility problems with clients that do not
            support collections...

    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Thu May 01 2003 - 19:48:34 EDT