Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
1 vs 2:
If you're going to use HTTP, use HTTP/1.1. POST in HTTP/1.0
had a problem because of the requirement for content-length:
you'd have to spool the entire print job locally in order
to submit it reliably.
<RKD> The protocol proposal that I made at the PWG
<RKD> meeting would work with either HTTP/1.0 or 1.1
<RKD> since it provides for sending chunks of data in
<RKD> a way that is independent of the underlying
<RKD> protocol.
2 vs 3:
Do what makes sense. There's no value in "first 2, then 3".
So if 2 works, keep it, and if it doesn't work, don't try
to do it first.
<RKD> I personally favor using HTTP Post, just because we
<RKD> know that the print server can be written on top of
<RKD> existing HTTP Servers using CGI or Server side APIs.
<RKD> However, I'd like to see someone provide some help
<RKD> with this by helping us to understand performance
<RKD> and load issues. If there is significant performance
<RKD> or load advantage to new HTTP methods, then I'd
<RKD> propose we look seriously at that option.
<RKD>
4:
I think people were seriously suggesting that IPP be an
option on top of LPR.
<RKD> I did not hear this proposal. What I heard was
<RKD> a proposal to put IPP directly on top of TCP/IP.