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