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