Subject: IPP> New HTTP Methods vs POST

From: Don Wright <[email-masked]>
Date: 7 Feb 97 12:40:21 EST

One of the issues we discussed yesterday was if we decided
to use HTTP, should we use POST or create some new methods.
There were several issues discussed about this but one of 
the most significant was if we start with POST and move to
new methods in order to get into the market faster, why 
would the server developers add support for the new methods?

Additionally yesterday, we saw a presentation from Microsoft
about their directions in Internet printing for NT 5.0.
While their directions were "simpler" than some of the work
we are doing with DPA-light, etc. there is still a very
solid set of functions planned.

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.  If we do a 
good job with it, we can minimize the differences where
possible but then have a real reason for the new methods
and reasons to get the server folks to implement this 
higher functionality.  This also could really help us get
something usable to market very quickly while providing
a migration path to the full function print server
solution.

Am I all wet?  All this assumes an HTTP based protocol so
don't hit me with the TCP stream argument again.  Would
this concept work IF we use HTTP?

Don

*************************************************************
* Don Wright ([email-masked])        Lexmark International *
* Manager                               Strategic Alliances *
* 740 New Circle Rd                     Phone: 606-232-4808 *
* Lexington, KY  40511                    Fax: 606-232-6740 *
*************************************************************

---

From: Randy Turner <[email-masked]>
Date: Sat, 08 Feb 1997 07:25:11 -0800

Don Wright wrote:
> Am I all wet?

Well, I don't think Microsoft needs the IETF to "rubber-stamp" an
internet printing standard.  Its like Jeff Case said, "Microsoft is the
world's
largest and most successful standards organization". I am hoping that
Microsoft (and others) are still open to technical contributions from
the
PWG

I think with a few slight modifications to their design, we could say
that it might
approach a minimally conforming implementation of IPP; I personally
don't
see any reason to create two standards, and there are aspects of their
command
structure which impose Microsoft's spooling model on systems that would
consider such a design unnecessary. I would prefer a more leaner
approach
that would lend itself to better performance on HTTP 0.9 and HTTP 1.0
environments and would allow easier implementation (essentially fewer
POST
operations).

Above all, I think we need to stay on track with our requirements and
scenarios. Also, we will need to define levels of conformance so that
IPP
eventually can scale across the widest possible scope of printing
environments
(low end to high end). One of these conformance levels might encompass a
simpler style of printing and status collecting similar to what
Microsoft is
doing. These levels of conformance should be negotiated for proper
interoperation between low-end clients and high-end servers, or
vice-versa.

As an aside, I think a priority should be to make IPP transport
independent,
with separate documents describing individual transport mappings. The
IPP
and transport mapping work can be accomplished (somehwat) in parallel
to achieve timely completion of the work.

Randy

> All this assumes an HTTP based protocol so