Subject: Re: IPP> Re: REQ - Last minute scenario comments

From: JK Martin <[email-masked]>
Date: Sat, 01 Feb 1997 02:05:07 -0500

Harry,

I agree entirely with your arguments countering Larry Masinter's
original message.  Larry had some excellent ideas, but your statements
make the issue (and the attendant problems) much clearer, IMHO.

Your final statment, though, compels me to respond with a comment,
particulary since we have tossed this subject around quite a bit
between you and I over the last year or two:

> Last year, before IPP was even a gleam in the PWG's eye, I proposed
> an encapsulation scheme - at that point - to associate information
> that would be needed for the Job MIB along with the Job during
> submission. The idea got a very cool reception. I thought, perhaps
> due to the fact that members who manage PDLs would rather extend
> their own. Perhaps my proposal appeared too much like an extension
> of "my" PDL (IPDS), or perhaps we just weren't ready for consensus on
> the need for a STANDARD means of associating Job information with the
> job?

My argument then is the same as it is now: Print Data is Print Data,
and Job Control is Job Control (protocol and parameters), and the
two should be separate in the requisite protocol transactions.

Munging the two together just causes all kinds of parsing problems
that usually end up impacting future extensions.  A Client should be
able to say "Here's some print data, please print it this way for
such-and-such a person", and the Server should operate on that data,
often in a relatively opaque manner (assuming the "Server" is
architecturally separate from the RIP or similar imager).

Sure, both PostScript and PCL embed all kinds of stuff in the print
data stream...but I believe that's because there has never been a
STANDARD PRINTING PROTOCOL in the world that everyone could play to.

Sheesh, that's all I really want.  A standard printing protocol.
It just doesn't seem like that's too much to strive for, given the
large body of experience in the Tower of Babel that has existed up
to now.

Ah, I feel better now.  Thanks for letting me get that off my chest.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Larry Masinter <[email-masked]>
Date: Sat, 1 Feb 1997 10:19:43 PST

I think I might have left out the context of my argument. I'm not
arguing for always embedding job control information into PDLs. I'm
arguing that the STANDARD PROTOCOL should have a clear definition of
what is job control and what is print data. I was arguing AGAINST the
situtation where a gateway would like to say "don't send this
information in the job control, only send it in the print data,
because I'm a gateway to a device that only knows about print data".

I see how my analysis taken outside of that context might have been
seen as an argument for putting EVERYTHING inside the print data, but
that's not what I meant at all.

Larry

---

From: Randy Turner <[email-masked]>
Date: Mon, 03 Feb 1997 10:40:31 -0800

> > the need for a STANDARD means of associating Job information with the

I think some of the solutions we are coming up with do munge
the world of job control and PDL. This is because alot of the PDLs
we deal with (lets use Postscript as an example) have job control
built into them as well. I remember when I was reading the
DPA specifications, the standard states that the user can use
the DPA job submission attributes to override what is specified in
the PDL. I don't know how many people on the list have actually
spent time inside the architecture of a postscript interpreter, but
the above DPA requirement forces some major architectural changes
in most PDL implementations I am aware of. 

There are some aspects of the job that are PDL-independent, like
do I want this on standard paper stock or transparency. But once
the final form PDL is generated (either directly from an 
application, or through a device-specific print driver) I would
hope that we would not be attempting to override the PDL with
our IPP-specific job control. Some parameters, like the paper/
transparency decision would be ok, but I think we should stay
away from any job control that attempts to change the imaging
characteristics (aspect ratio, fonts, media size, etc.) that
might conflict with parameters that were used to generate the
PDL. 

I guess I'm basically a purist and agree with Jay that we need
to keep job control and PDL separate; with job control specifying
more "macro" types of job characteristics like "Does this
printer support Postscript?" or "I would like this printed on
transparency", etc. Also, its very hard to do directory lookups
on anything more job-specific than this without doing parsing
of the PDL to determine the actual job requirements, so I think
the directory service attributes need to reflect the parameters
and printer characteristics that are easy to obtain, similar to
the "macro" type of job characteristics I have described.

Since we agreed in an earlier teleconference to utilize existing
device specific print drivers and just insert IPP as a "redirector",
we have basically agreed to be PDL-independent, so we can't parse
the job stream, nor do we have a mechanism for transmitting print
job metadata from the device-specific driver through some other
"channel".

Boy, you're right Jay, it does feel better to unload all this
baggage.

Randy

-- 
Randy Turner