Subject: IPP> HTTP transport for IPP

From: Harry Lewis <[email-masked]>
Date: Wed, 9 Apr 1997 18:47:02 -0400

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

Randy, I thought your presentation at the PWG meeting in Austin was excellent.
I have reviewed your internet draft on using HTTP 1.1 as a transport for IPP
and have the following comments:

1. The idea of returning 3 URL (Data, Status, Modify) upon job submission is an
excellent means of facilitating end-user job status and ability to cancel one's
job. However, sometimes there may be an administrative application that wants
to modify jobs. Unless this application had also received the Modify URL, it
would be unable to cancel or modify jobs in the "IPP queue".

I think this might be accomplished by a QUERY to the "root" IPP service URL
which would return a list of currently active and pending print jobs. It would
be crucial that, included with this list would be the Modify URLs. Note there
may need to be some authentication regarding who gets these.

2. Although you were not specific about every type of print service and/or job
data that would be accommodated, I think future versions might want to address
sending and querying resources like fonts and forms that are available on the
printer.

Again, I think your paper is a great contribution at understanding how IPP will
map to HTTP 1.1. Thanks.

Harry Lewis - IBM Printing Systems

---

From: Harry Lewis <[email-masked]>
Date: Thu, 10 Apr 1997 18:00:25 -0400

Classification:
Prologue:

Bob Herriot asked...

>Does anyone else think that we should strive for one job URL, and have
>the operation specified in the message, or am I alone?

I still like the idea of 3 URLs for the following reasons

1. The data URL (as I understand it) can point directly to a "virtual
   printer" with specific PDL, and/or configuration. I think this
   could be powerful in directing jobs to the appropriate device or
   instance of a device.

2. The status URL is basically a guaranteed unique printer assigned
   job ID to be used to monitoring job progress, state etc. If we
   didn't return this as a URL, we'd need some other means of
   accomplishing this in the protocol and I doubt we could do much
   better than a URL. I was only pointing out, with my earlier msg,
   that just returning this status URL to the submitter does not
   facilitate administrative actions by separate, standalone
   applications.

3. I believe the main benefit of the Modify URL is that it can be
   subject to higher scrutiny in terms of authentication. Otherwise,
   I'd say Status and Modify could be the same URL - both pointing
   to a specific job. So I see Modify URL as the status URL with a
   password, if you will. I do not see the need for separate URLs for
   each modify operation (hold, cancel, move etc.). But, then, I'm
   not tuned in to all the subtle nuances of who gets to manage what
   in a DPA environment, so, if you need multi levels of authentication,
   you might want multiple modify URLs.

Harry Lewis

---

From: [email-masked] (Robert Herriot)
Date: Thu, 10 Apr 1997 19:13:11 -0700

> From [email-masked] Thu Apr 10 18:49:32 1997
> 
> > This seems like a datastructure problem where it is usually better to return
> > a pointer to the root of the structure than to return several
> > components at the next level.
> 
> This statement implies that there might be a 'hierarchy' represented by
> the URLs that are returned. There could be, but then again they may be
> distinct. Basically, the multiple URL method allows you to construct the
> 99% case (whatever it turns out to be), and it also allows you to divide
> up the chores of the print system, according to either:

I think that part of the issue here is whether there is a "root" job URL
from which other job URL's can be obtained, and if so, whether the
specialized job URLs are optimizations that save a trip to the server.
--------------------
 
> Having more than one URL allows a system designer to distribute 
> functionality, rather than having all clients experiencing a bottleneck
> by hammering away at a single URL for all operations.

I would expect this problem to solved by distributing the printers 
across many servers rather than distributing the URL for each job.
-----------------------------
> 
> There's no decision here if I understand you statement. We specify
> in the standard which URLs to return (logically). Or, if you mean that
> we have to architect code that has to make this decision, it would
> also have to make the same decision about which resource to call on
> if you embed the operations in the pipe to a single URL.

I mean that the standard would have to specify this.
--------------------------------
> 
>   For example, the GetJobs operations probably doesn't return
> > the SendJob URL -- maybe I'm wrong, but that is the problem.  In
> > addition, the 3-URL solution may lead to our needing to define a
> > mechanism/attribute for get one type of job URL from another, e.g. the
> > modify job URL from the query URL.
> 
> The only operation in my proposal that returns URL strings is the
> "Create-Job" operation. 

What does GetJobs return?  I assume that a client that wants to do
a GetAttributes or CancelJob would not necessarily be the same client
that did the Create-Job and thus could only get the URL's via a GetJobs
query.

> > Bob Herriot

---

From: [email-masked] (Robert Herriot)
Date: Fri, 11 Apr 1997 13:06:17 -0700

> From [email-masked] Fri Apr 11 10:27:02 1997
> 
> 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.
> 
>
 
My simple mind has the same problem.  I expect a one-to-one
correspondence between a URL and an object, be it a printer
or job object.  I don't expect a particular object, such as
a job, to have 3 URLs even buried in the protocol. It adds
complexity to the protocol and probably ends up being hard
to hide from an end-user.

Bob Herriot