Subject: Re: IPP> Re: Why not use URI for Jobs?

From: [email-masked] (Robert Herriot)
Date: Tue, 2 Sep 1997 13:50:17 -0700

I think that the decision on Job-URI versus Job-Id all boils down to a
decision about one of two directions:

   1) The solution should solve today's problems easily while potentially
   making tomorrow's problem harder.

   2) The solution is allowed to make today's problems harder to solve in
   order to allow for the possiblity that tomorrow's problems be
   easier to solve.

I favor direction #1 which implies Job-Id because I believe that new
technology is most successful when it carries along existing technology
easily.  I also believe that it is not wise to make solving existing
problems substantially harder in order to achieve a payback that is not
well understood and may never happen. In my experience, when a feature
is added for some poorly understood future requirement, it is frequently
never used.

Bob Herriot

> From [email-masked] Sat Aug 30 05:22:08 1997
> 
> OK,
> 
> ask Bob Herriot from Sun or Scott Isaacson from Novell about the details.
> 
> I have actually asked that somebody posts a reply to Randy's comments, so
> that we can get the thing out of the world.
> 
> Carl-Uno
> 
> At 10:20 PM 8/29/97 PDT, you wrote:
> >> I tried to sell exactly the compromise that you just suggested in your
> >> previous message, but people who are closer to implementation told me that
> >> it would not work.
> >
> >Am I still toe-ing the line if I ask you who they are, so I can ask them
> >why it won't work? It would be good to get this resolved to the point
> >that there aren't any technical questions about it being the right path,
> >and I can't figure out why it doesn't work.
> >
> >That is, there are two gateway cases:
> >  LPR client -(gw)-> IPP printer
> >      new printer, just support LPR too
> >      If you really need to map, well, you have to make up
> >      LPR job IDs and keep track of the ID->URL mapping, but
> >      it's a small table.
> >
> >  IPP client -(gw)-> LPR printer
> >      make Job URLs of the form "http://printer/LPRJOBNUMBER/nnnnn"
> >      where nnnnnn is the LPR job number.
> >
> >This doesn't need any auxiliary tables.
> >
> >Larry
> >
> >
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: [email-masked]
>

---

From: Randy Turner <[email-masked]>
Date: Wed, 03 Sep 1997 00:03:10 -0700

These "direction" statements proceed from a false assumption, that
today's
problems are not solved. I say that they are solved. The bulk of the
features
in the model document have come from vendor specification and not from
customer requirements. Originally, we just wanted to "send a document
over the web" to a printer. And Paul Moore's original statement from a
previous PWG meeting was something like "we are just using the web to
locate printers...". SWP was really very simple. I thought we were
looking
at the bigger picture with regards to what advantages the web could
bring
to deployment of distributed printing environments.

The way I read the direction #1 statement is:

1. Lets just concentrate on writing gateways to existing implementations
and
   not allow native IPP implementations; basically preventing other
printer vendors from
   implementing a more powerful job identifier mechanism than our
current
   systems' 4-byte integer. Along with the scalability advantages of Job
URIs, the
   information contained in URIs can assist security, job accounting,
and could even
   assist in job scheduling and/or spooling. We at Sharp are even
exploring the future
   format of IPP outside of HTTP, and the use of IPP: URI schemes, which
would
   be automatically supported by the IPP model in the environment I am
proposing.

I am hoping that with IPP we can not only provide a platform for
advanced
printing today but providing a spring board into future scalable
printing
solutions that are created as a result of what we are doing (if we do
our jobs
right). I think alot of the decisions that have been to date have been
severely
compromised for questionably technical reasons. I just think at our
current
rate of  "feature culling" that we really are going to end up with
nothing new
to offer customers. Just another way to do what is already being done.
I
think we need to carefully consider the environment (the "web") in which

we are planning on deploying IPP (over HTTP). Basically, if are just
going
to use HTTP and the web environment as a tunnel for existing printing
systems, then we are not providing anything new. In fact, if we proceed
down that path, there's nothing that we are doing that HP "JetSend"
can't
do, and possibly better.

If we need to somehow support legacy printing environments job
identification,
then just add a "helper" job identification or other type of attribute
that also can
be used by legacy implementations to identify a job. It doesn't have to
be one
or the other. Why can't we explore the idea of supporting both types of
environments?