After thinking about the protocol issue some more, it seems like there
are two ways to organize the IPP Job Object in HTTP Protocol, the
current proposal or my proposal described below.
1) current proposal: The way proposed in the current document where the
job and all document data is a part of a HTTP single entity-body.
2) my proposal: A job is an HTTP document whose top level content type
is multipart/mixed (an existing type) or perhaps multipart/ipp (a new
type and probably a bad idea). In either case, the first entity has a
content type of application/ippjob and contains the job attributes.
Each remaining entity contains a document and they are all standard
MIME types, such as application/PostScript or text/plain. Such a
document could in the future become a multipart/ippdocument with a
document attribute entity and a document content entity if a document
has attribute overrides. The document data entity could also have a
content-type of multipart/alternative (an existing type) if a client
wanted to have several representations of a document, e.g. HTTP and PDF
and a printer supported such.
The advantage of my proposal is that the document parts are
conventional MIME documents which any software could read. Only the
application/ippjob and application/ippdocument require special software
to process.
I hope others will comment on the pros and cons of these two proposals?
Bob Herriot