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-772-2479
Bill Wagner Wrote:
Roger, I am obviously missing your points. Understanding that the use
of HTTP for IPP is under consideration and is not yet 'cast in stone'
1. Could you be more explicit on why Post must be used for status
query, considering that this does appear to make impossible the use of
unmodified, un-embellished browsers and the function can be performed
quite well with existing browsers?
RKD> It does not have to be used for status query. My point is that
RKD> if you generate html in the printer to report status, you are
RKD> are not using IPP - - you are using something else.
2. I think there has been much discussion on why HTTP may not be ideal
for job delivery. I am sure you did not mean to be flippant in saying
'why not', but I think a more positive reason might be helpful to
understanding.
RKD> We have prototyped a lot of the IPP function using http.
RKD> Since it seems to work well, I don't know why it should
RKD> be an option.
3. It was my understanding that HTTP was transaction based, and
therefore the scenario outlined below, if HTTP were the transport,
would require two connections. There would also, presumably, be a
response to delivery of the job. If therefore, the query for
capabilities and job delivery are different connections, why the
constraints on the HTTP used for capabilities query? Indeed, there
appears to be no need to require that the same transport be used.
RKD> The reason I don't think the flow doesn't work is that the
RKD> HTML is meant to be human readable, not parsable
RKD> programmatically. Therefore the client cannot use
RKD> the information that comes back on subsequent
RKD tranactions.