My comments marked with MS>>> below.
Babak
>-----Original Message-----
>From: Randy Turner [SMTP:rturner at sharplabs.com]
>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...
>