IPP Mail Archive: Re: IPP> HTTP transport for IPP

Re: IPP> HTTP transport for IPP

Randy Turner (rturner@sharplabs.com)
Fri, 11 Apr 1997 10:32:11 -0700

Roger K Debry wrote:
>
> 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
>
> ---
>
> 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

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