Subject: Re: IPP> HTTP transport for IPP

From: Roger K Debry <[email-masked]>
Date: Fri, 11 Apr 1997 13:24:22 -0400

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
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?

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

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.

---

From: Randy Turner <[email-masked]>
Date: Fri, 11 Apr 1997 10:32:11 -0700

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

> RKD> URLs for the job, based on the operation being

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> 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
[email-masked]