Subject: Re: IPP> Job-URI discussion

From: Scott Isaacson <[email-masked]>
Date: Tue, 09 Sep 1997 09:34:33 -0600

Below are my thoughts on all of the Job URI/Job ID discussions recently. 
Even though I have just been a lurker lately, I hope my possition for
support for Job URIs is well known.  I endorse 100% of what Randy has
offered.

My ideas:

1)  Gateways issues are not the real issue.  I agree with Randy's comments
about the IPP model not being constrained by gateway implementation issues 
(agreeing with see Randy's comments below).  Gateways, by definition, do
impedence matching between  two different systems (models).   Gateways are
necessary but not front runner  cases.

2) The real issue is support for existing client access (API).  One of the
most critical features of IPP is that all existing (unmodified applications
and print drivers) can be used with an IPP print provider.  We call this
"application printing" (print from any application once the printer has been
"installed" to the desktop).  In the Windows enviroments this means writing
an IPP print provider under the EXISTING printing interfaces.  In other
environments it means basically the same thing (writing a modular piece that
can slip in under EXISTING interfaces).  So the real question is "Can
exiting client printing models and APIs be supported by the new IPP model?" 
and remember that I mean all client printing models, not just "one
particular vendor".  Again, after all the discussion I am convinced the
answer is YES. The reasons often associated with a NO answer is only that it
would be MORE DIFFICULT,  not  impossible.  I have never seen a "it can not
be done" argument?  Did I miss it?  This is software, we can do anything! 
However, we do need to be pragmatic.  What is the exact perfomance vs future
potential tradeoffs?   Too bad that is far too unknown right now.  

3) In other Internet (non IPP specific circles) there is much theoretical
debate over the difference between URNs (location transparent names) and
URIs (often location dependent IDs).  If often wonder if the same principles
in those arguments do not apply to this Job URI vs Job ID discussion (just
up one more layer of abstraction).

Scott Isaacson

>>> Randy Turner <[email-masked]> 09/08 2:47 PM >>>
> Overall, I don't consider this particular gateway problem to be
> worthy of altering the original model. The real value in getting
> IPP to users is not enabling LPR clients, its enabling IPP clients
> being able to locate IPP printers via the WEB and subsequently
> printing to them. I think we're spending too much time trying to
> save gateway writers a few lines of code.

---

From: Jim Walker <[email-masked]>
Date: Tue, 09 Sep 1997 15:06:36 -0500

I personally feel that the Job-URL (sic) is the *only* way to go.
>From my persepective, any solution that associates a job with a
specific printer is immediately broken.  The existing URL model
can be supported in my existing client environment, whereas the
proposed <printer-URL, job-ID> model would be a severe obstacle.
In our environment, a job is an object in and of itself; it may
be easily moved from one printer to another.

so there...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX