IPP> Why HTTP and thoughts on forms etc

IPP> Why HTTP and thoughts on forms etc

IPP> Why HTTP and thoughts on forms etc

JK Martin jkm at underscore.com
Mon Dec 9 04:07:00 EST 1996

Thanks to Roger for posting his thoughts on "Why HTTP?" for the IPP


After reading both this document and Bob Herriot's response, I tend to
agree with Bob regarding the overall utility and compliance to be had
using MIME encodings.  Seems like the MIME approach gives us the kinds
of structuring, attributes and name space possibilities that will be
required for reasonably comprehensive submission capabilities.

Bob also hit the nail on the head with regard to issues surrounding
advance knowledge of the content length of a stream that is part of the
submitted job.  By employing an encoding method (ie, framing format)
that does not require advance knowledge of the stream length, embedded
systems will have a much better chance of supporting advanced
techniques, particularly those that are normally found only on today's
"host" systems (that have far more resources, such as disk capacity). 
After seeing how MIME has been successfully used over the last several
years, I don't believe boundary generation is a problem.  Sure, we'll
end up with some necessarily long boundaries, but as a percentage of the
total transaction size, those boundaries should be viewed as
insignificant IMHO.

Just to make sure I understand the ideas Bob proposed in his reply to
Roger's posting with regard to the use of MIME encodings, I'd like to
walk through a job submission scenario to identify the various content
components.  This scenario may be a bit more complex than the "average"
print job found in a LAN environment, but should serve to note the kinds
of complexities that might be required for a submission mechanism:

  A client wants to submit a job containing four documents to a printer.
  These documents contain (in sequence) Postscript, PCL, G3 fax, and
  plain text.  The client also wants to include a number of separator
  sheets, including a banner sheet, a trailer sheet, and a special
  "cover" sheet for just the G3 fax document.  Furthermore, the
  sheets are specified by reference to the server; the client expects
  server to insert the proper type of sheet where specified within the
  job (ie, the client does not actually generate the separator sheets).

If I understand Bob's approach, the resulting content of the POST
message to the printer *could* be structured as shown below (in an
abstract manner).  Note that I don't have the MIME spec handy, so some
of the content-type values are probably bogus.  Also, the indentations
are meant to illustrate the encapsulated components (rather than calling
out the actual "boundary" begin/end lines), and comments are preceded
with "--" ala ASN.1 specs:

  Content-type: multipart/mixed;                -- Outer msg "wrapper"
    Content-type: application/ippjob;           -- Job attribute set
      Username: Jane Doe
      ...                                       -- Other job attributes
    Content-type: application/ippseparator;     -- Banner sheet
      Type: banner
      Color: blue
      ...                                       -- Other banner options
    Content-type: application/postscript        -- The 1st document
    Content-type: application/pcl               -- The 2nd document
    Content-type: multipart/mixed               -- The 3rd document
      Content-type: application/ippdocument     -- 3rd document options
        Cover-sheet: fax
        From: John Doe
        ...                                     -- Other cover options
      Content-type: fax/g3                      -- The 3rd document
    Content-type: text/plain                    -- The 4th document
    Content-type: application/ippseparator;     -- Trailersheet
      Type: trailer
      Color: default
      Inserts: processing-time, sheets-used, interpreter-messages
      ...                                       -- Other trailer options

Granted, banner and trailer sheets (provided in this manner, by the
server) could be implemented as job attribute options similar to that
done for the fax cover sheet.

Bob, is this the kind of structuring you're thinking about?  Is the
structuring shown above consistent with MIME rules, etc?

If so, then this approach looks *very* powerful and flexible to me.  By
using MIME a client can either hand-craft separator sheets--and pass
them to the server is just addition documents, as is often done
today--or can invoke special features and/or resources provided by the
server using standard tag mechanisms (ie, attributes).



        Underscore, Inc.

More information about the Ipp mailing list