IPP> PRO,MOD> User model for clients

IPP> PRO,MOD> User model for clients

Bill Wagner bwagner at digprod.com
Wed Jan 29 16:45:36 EST 1997


     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?
     
     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.
     
     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.
     
     Bill Wagner, DPI




______________________________ Reply Separator _________________________________
Subject: Re: IPP> PRO,MOD> User model for clients
Author:  rdebry at us.ibm.com at Internet
Date:    1/29/97 2:33 PM




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


Don Wright wrote:


Here you are clearly wrong.  Lexmark's MarkVision for
the WEB is able to provide printer and printer Queue status
on unmodified, unassisted browsers today.  If our scenarios
and models do not support this mode of operation then a
grave design error has been made.


RKD> Don, I'm not sure what you mean here. Clearly one can
RKD> continue to use existing browsers as you have in
RKD> MarkVision for the web. However, you can't, in my mind,
RKD> mix the two.  For example, the following seems to be
RKD> difficult, if not impossible:


Client                                    Printer


 --------------------------------------------->
   get printer capabilities (IPP request)


 <--------------------------------------------
   capabilities (html ala MarkVision)


 --------------------------------------------->
   print request, using capabilities (IPP)



More information about the Ipp mailing list