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

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

rdebry at us1.ibm.com rdebry at us1.ibm.com
Mon Nov 25 07:51:11 EST 1996


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