IPP> HTTP transport for IPP

IPP> HTTP transport for IPP

IPP> HTTP transport for IPP

Randy Turner rturner at sharplabs.com
Fri Apr 11 13:32:11 EDT 1997

Roger K Debry wrote:
> 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-924-4080
> ---
> Actually, in a true client situation, the end-user
> never sees URLs, in fact, he doesn't even have to
> know the term 'URL'. And in the browser case, using
> multiple URL strings with CGI parameters as HTTP
> POST targets is the natural way to encode IPP
> operations.
> RKD> Yes, a GUI can hide all of this complexity,
> RKD> but in other discussions we have recognized
> RKD> that there may be end users using a command
> RKD> line interface. How does a true client solve
> RKD> this problem for them?

There's really no difference, you would have multiple
command line applications that are IPP-operation
specific (similar to LPR and LPQ and LPRM), that all
start with queries to the root "URL".

> ... snip ....
> I would propose the same solution for any transport.
> In my opinion, funneling everything through 1 URL
> is too monolithic a solution when we have the
> flexibility of URLs as object identifiers.
> RKD> So, if we decided to go with a different URI scheme,
> RKD> such as IPP://xxxxx.xxxxx.xxxxx, without the underlying
> RKD> http services, then you would still propose multiple
> RKD> URLs for the job, based on the operation being
> RKD> performed?

Yes, but the 3 URLs I'm proposing are defined in a "macro"
way, meaning that they are "types" of URLs to which 
different command sub-types may be issued via 
application/ipp message types. Take for instance, the MODIFY
URL. This URL "IS" operation specific, meaning that it
handles MODIFY operations, but MODIFY in this sense is a
macro or higher-level way of thinking of this object. It
really says that this URL is used for any command to modify
the state of the job; so, it is logically specific to one
type of job access, but it is capable of handling many 
types of IPP-specific sub-commands such as cancel, requeue,
re-prioritize, modify-attributes, etc. or whatever we come
up with.

> RKD> I guess my simple mind finds it hard to grasp why
> RKD> we have one object, a print job, to which we give a
> RKD> different name, depending upon what action we
> RKD> are taking on that object.

Again, its not 1 URL for each specific action, its 1 URL
for each CLASS of actions you want to perform on the object.


Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com

More information about the Ipp mailing list