IPP> Re: New Internet-Draft Request (another idea on the protocol

IPP> Re: New Internet-Draft Request (another idea on the protocol

IPP> Re: New Internet-Draft Request (another idea on the protocol

Robert Herriot robert.herriot at Eng.Sun.COM
Mon Nov 25 19:46:18 EST 1996


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



More information about the Ipp mailing list