IPP> PRO,MOD> User model for clients

IPP> PRO,MOD> User model for clients

IPP> PRO,MOD> User model for clients

rdebry at us.ibm.com rdebry at us.ibm.com
Mon Feb 10 17:42:53 EST 1997

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

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 at internet
Subject: Re: Re[2]: 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?

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.

More information about the Ipp mailing list