ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/whyhttp.pdf
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
separator
sheets are specified by reference to the server; the client expects
the
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
%!PS-...
...
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).
Comments?
...jay
Underscore, Inc.