Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
Sure browsers parse html, but you would have to define very concrete html
syntax for IPP attributes and values if the client were going to do anything
pther than simply display the information.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/10/97 09:39
ipp-owner @ pwg.org
01/30/97 07:04 PM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
Subject: Re: Re: IPP> PRO,MOD> User model for clients
What did you mean by your comment below? HTML certainly is parseable
programmatically for displaying. Web browsers do it all the time.
Is there something more that you expect the client to do with HTML?
> 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.