IPP Mail Archive: Re: Re[2]: IPP> PRO,MOD> User model for clients

Re: Re[2]: IPP> PRO,MOD> User model for clients

rdebry@us.ibm.com
Mon, 10 Feb 1997 17:42:53 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080

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
AM ---------------------------

ipp-owner @ pwg.org
01/30/97 07:04 PM

To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet
cc:
Subject: Re: Re[2]: IPP> PRO,MOD> User model for clients

Roger,

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?

Bob Herriot

> 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.
>