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

From: [email-masked]
Date: Mon, 25 Nov 1996 07:51:11 -0500

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@internet
cc: ipp @ pwg.org@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

---

From: [email-masked] (Robert Herriot)
Date: Mon, 25 Nov 1996 16:46:18 -0800

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 [email-masked] Mon Nov 25 15:34:56 1996
> From: [email-masked]
> X400-Originator: [email-masked]
> X400-Recipients: [email-masked]
> X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002245504000002]
> X400-Content-Type: P2-1988 (22)
> To: <[email-masked]>
> Subject: IPP> Re: New Internet-Draft Request (another idea on the protocol
> Date: Mon, 25 Nov 1996 07:51:11 -0500
> Sender: [email-masked]
> Content-Length: 2482
> X-Lines: 60
> 
> Classification:
> Prologue:
> Epilogue:
>