Subject: RE: IPP> New HTTP Methods vs POST

From: Babak Jahromi <[email-masked]>
Date: Sun, 9 Feb 1997 20:00:30 -0800

My comments marked with MS>>> below.

Babak

>-----Original Message-----
>From:	Randy Turner [SMTP:[email-masked]]
>Sent:	Saturday, February 08, 1997 7:25 AM
>To:	Don Wright
>Cc:	ipp%pwg.org
>Subject:	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
>MS>>> Not really the case. We (MS) do want to be compatible with IPP, and it
>would be costly for us not to. For example consider today's scenario: Every
>vendor installs its own networking solution on Windows machines to support
>their network printers (plain TCP code, SNMP code, DPA stuff, etc.). This
>makes Windows clients bloated and complex. Our  customers who buy Windows
>family of OSes suffer from it. So we definitely see value to have a built-in
>support in the OS for a protocol that most printers understand. 
>
>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).
>
>MS>>> One clarification: The number of POSTs needed in MS's approach to ship
>the job data to the server is arbitrary. In our today's implementation, it is
>equal to the number of times Spooler calls print provider's WritePrinter(),
>but this is not inherent in the protocol. You could choose to ship the whole
>job data in a single POST, and the server would be happy with it (even though
>the client's firewall may not be). I could easily modify our Print Provider
>to collect all the data and ship it in a single or larger POST(s) at the
>EndDoc time (and I might actually do that if the performance tests show the
>need). But there is nothing in the protocol that imposes the number of the
>POSTs. The protocol I presented in the meeting had really little to do with
>our Spooler architecture. It might have appeared that way beacause I chose to
>define it by describing how it could be implemented on top of Win32 Internet
>APIs and how it maps to Windows Print Provider calls.
>
>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.
>MS>>> The simplicity it the key. If you want to see the support in the OS,
>you need to keep it simple. An overly complete DPA-like protocol won't get
>implemented any time soon simply because few people have the time to do it.
>Remember we are running with the Internet clock now...
>

---

From: Don Wright <[email-masked]>
Date: 10 Feb 97 8:49:55 EST

Randy Turner said:

>world's largest and most successful standards organization". I am 
>hoping that Microsoft (and others) are still open to technical 
>contributions from the PWG

It is not my intention to "rubber-stamp" Microsoft's current 
implementation; however, I think we can learn a lot by examining 
their much simpler approach and creating an OS independent 
standard on par with their proposal.

>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).

I think we are in basic agreement here.  My major difference
is to use the simple POST implementation for the minimally 
conforming implementations and us the new methods (should we
map to HTTP) for the more robust implementations.

>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.

I have agreed with this plan all along.

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