IPP Mail Archive: Re: IPP> New HTTP Methods vs POST

Don Wright wrote:
>
> 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?

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
> don't hit me with the TCP stream argument again. Would
> this concept work IF we use HTTP?
>
> Don
>
> *************************************************************
> * Don Wright (don@lexmark.com)        Lexmark International *
> * Manager                               Strategic Alliances *
> * 740 New Circle Rd                     Phone: 606-232-4808 *
> * Lexington, KY 40511                    Fax: 606-232-6740 *
> *************************************************************