------------14F92C081EDA0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 at lexmark.com) Lexmark International *
> * Manager Strategic Alliances *
> * 740 New Circle Rd Phone: 606-232-4808 *
> * Lexington, KY 40511 Fax: 606-232-6740 *
> *************************************************************
------------14F92C081EDA0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
<HTML><BODY>
<DT> 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? </DT>
<DT> </DT>
<DT>Well, I don't think Microsoft needs the IETF to "rubber-stamp"
an</DT>
<DT>internet printing standard. Its like Jeff Case said, "Microsoft
is the world's</DT>
<DT>largest and most successful standards organization". I am
hoping that</DT>
<DT>Microsoft (and others) are still open to technical contributions
from the</DT>
<DT>PWG</DT>
<DT> </DT>
<DT>I think with a few slight modifications to their design, we could
say that it might</DT>
<DT>approach a minimally conforming implementation of IPP; I personally
don't</DT>
<DT>see any reason to create two standards, and there are aspects of their
command</DT>
<DT>structure which impose Microsoft's spooling model on systems that would</DT>
<DT>consider such a design unnecessary. I would prefer a more leaner
approach</DT>
<DT>that would lend itself to better performance on HTTP 0.9 and HTTP 1.0</DT>
<DT>environments and would allow easier implementation (essentially fewer
POST</DT>
<DT>operations). </DT>
<DT> </DT>
<DT>Above all, I think we need to stay on track with our requirements and</DT>
<DT>scenarios. Also, we will need to define levels of conformance so that
IPP</DT>
<DT>eventually can scale across the widest possible scope of printing environments</DT>
<DT>(low end to high end). One of these conformance levels might encompass
a</DT>
<DT>simpler style of printing and status collecting similar to what Microsoft
is</DT>
<DT>doing. These levels of conformance should be negotiated for proper</DT>
<DT>interoperation between low-end clients and high-end servers, or vice-versa.</DT>
<DT> </DT>
<DT>As an aside, I think a priority should be to make IPP transport
independent,</DT>
<DT>with separate documents describing individual transport mappings. The
IPP</DT>
<DT>and transport mapping work can be accomplished (somehwat) in parallel</DT>
<DT>to achieve timely completion of the work.</DT>
<DT> </DT>
<DT>Randy</DT>
<DT> </DT>
<DT> </DT>
<DT>> 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 at lexmark.com)
Lexmark International *
> * Manager
Strategic Alliances *
> * 740 New Circle Rd
Phone: 606-232-4808 *
> * Lexington, KY 40511
Fax: 606-232-6740 *
> *************************************************************
</DT>
</BODY>
</HTML>
------------14F92C081EDA0--