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

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

McDonald, Ira imcdonald at sharplabs.com
Thu May 1 19:47:38 EDT 2003


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?]

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Monday, April 28, 2003 11:08 PM
To: ipp at 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
        Send-Document.

     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 at easysw.com
Printing Software for UNIX                       http://www.easysw.com



More information about the Ipp mailing list