Subject: IPP> New HTTP Methods vs POST -Reply

From: [email-masked]
Date: Mon, 10 Feb 1997 17:46:06 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

I support Scott's view. Let's keep moving down the path we are on  -- get the
protocol right,
then do whatever mappings we think are appropriate as a second step. I don;t
think that we
could standardize on the Microsoft approach because they are passing Microsoft
internal
data structures around.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/10/97 12:12
PM ---------------------------

        ipp-owner @ pwg.org
        02/10/97 10:11 AM

To: ipp @ pwg.org@internet
cc:
Subject: IPP> New HTTP Methods vs POST -Reply

Don,

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

>>> Don Wright <[email-masked]> 02/07/97 10:40am >>>
> So.... what if we were to take the Microsoft approach and map
> that to HTTP POST, standardize what they are doing and
> call it SIPP (Simple Internet Printing Protocol).  Meanwhile,
> we can continue working on the DPA-light oriented approach,
> create new HTTP methods, and call that IPP.

I think that we should keep with the name IPP and keep it as simple as
possible.  The print protocol (semantics and operations) should basically
be the same across all mappings on transports.  In other words there
could be a mapping of IPP on:

1. HTTP 1.0 POST
2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features)
3. HTTP 1.x extended methods
4. Raw TCP
5. Internet RPCs
6. IIOP
7. etc, etc.

In other words, lets not create two things, but one thing.  Call it IPP.  Then
as Randy and you have pointed out in later (than this) emails, propose
multiple "mapping documents".

I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and
reasonable first step deployment.  Maybe we will learn more as we go
through the first step which will make additional choices more clear.

Scott

---

From: Babak Jahromi <[email-masked]>
Date: Mon, 10 Feb 1997 15:13:20 -0800

>Yes. but that's happenig only in one case, and it only contains user id and a
>couple of other basic job properties. It would take me at most 15 minutes of
>coding to change that structure to its IPP equivalent.
>
>Babak

---

From: [email-masked]
Date: Tue, 11 Feb 1997 10:31:38 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

Babek, sounds encouraging.  I was going to make a few changes to the
white paper anyway to reflect your notion of getting the job handle before
sending
the data. I thought that everyone liked this scheme.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/11/97 07:53
AM ---------------------------

        ipp-owner @ pwg.org
        02/10/97 04:14 PM

To: ipp @ pwg.org@internet, Roger K Debry/Boulder/IBM
cc:
Subject: RE: IPP> New HTTP Methods vs POST -Reply

---

From: [email-masked]
Date: Wed, 12 Feb 1997 10:31:11 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

1 vs 2:
If you're going to use HTTP, use HTTP/1.1. POST in HTTP/1.0
had a problem because of the requirement for content-length:
you'd have to spool the entire print job locally in order
to submit it reliably.

<RKD> The protocol proposal that I made at the PWG
<RKD> meeting would work with either HTTP/1.0 or 1.1
<RKD> since it provides for sending chunks of data in
<RKD> a way that is independent of the underlying
<RKD> protocol.

2 vs 3:
Do what makes sense. There's no value in "first 2, then 3".
So if 2 works, keep it, and if it doesn't work, don't try
to do it first.

<RKD> I personally favor using HTTP Post, just because we
<RKD> know that the print server can be written on top of
<RKD> existing HTTP Servers using CGI or Server side APIs.
<RKD> However, I'd like to see someone provide some help
<RKD> with this by helping us to understand performance
<RKD> and load issues. If there is significant performance
<RKD> or load advantage to new HTTP methods, then I'd
<RKD> propose we look seriously at that option.
<RKD>

4:
I think people were seriously suggesting that IPP be an
option on top of LPR.

<RKD> I did not hear this proposal.  What I heard was
<RKD> a proposal to put IPP directly on top of TCP/IP.