If I understood your proposed structure, it does not seem that a
standard HTTP reader could find the individual documents within a job,
rather a job looks like an opaque application.
With my proposal, a print operation appears to a standard HTTP reader
to be a series of 1 or more entities, where some entities are
opaque applications and others are documents in standard formats.
It's hard for me to enumerate advantages. It's more a gut feeling
that the best solution is the one which uses an existing structure
as much as possible. Then we take advantage of the structure
as it develops because a job is built from standard off-the-shelf
pieces.
In the simplest case a Print job may just consist of a single HTTP
entity of document data in a standard format. The Printer then infers
the job attributes according to defaulting rules.
Bob Herriot
> From rdebry at us1.ibm.com Mon Nov 25 15:34:56 1996
> From: rdebry at us1.ibm.com> X400-Originator: rdebry at us1.ibm.com> X400-Recipients: ipp at pwg.org> X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245504000002]
> X400-Content-Type: P2-1988 (22)
> To: <ipp at pwg.org>
> Subject: IPP> Re: New Internet-Draft Request (another idea on the protocol
> Date: Mon, 25 Nov 1996 07:51:11 -0500
> Sender: ipp-owner at pwg.org> Content-Length: 2482
> X-Lines: 60
>> Classification:
> Prologue:
> Epilogue:
>> Bob, I am not familiar enough with the real operation of HTTP protocols to know
> whether your idea is a good one or not. I had thought that I could only send
> one enitity at a time, which would require leaving the connection open and
> turning the line around several times to complete transfer of the message when
> sending the document along with the print request. How would this affect
> performance? Obviously this is not a concern when pulling the document later.
>> What are the advantages of allowing "any" software to read the document data?
> Since I only apply the headers when sending the document to be printed I'm not
> sure what I gain? In my proposal, the document content itself still has a
> standard Mime type.
>> ---------------------- Forwarded by Roger K Debry/Boulder/IBM on 11/25/96 05:44
> AM ---------------------------
>> ipp-owner @ pwg.org
> 11/23/96 12:03 AM
>>> To: Scott_Isaacson @ novell.com at internet> cc: ipp @ pwg.org at internet> Subject: Re: New Internet-Draft Request (another idea on the protocol
>>> 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
>>>