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?
Robert Herriot wrote:
> 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 cmanros at cp10.es.xerox.coM 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: manros at cp10.es.xerox.com> >