Subject: IPP>MOD reconsideration of model decision

From: [email-masked] (Robert Herriot)
Date: Mon, 5 May 1997 13:21:59 -0700

Scott,

Here is a change, that I propose for the model document.

At the model meeting last Friday, we decided to add a suffix 'capable'
to production attributes in the Printer's JobTemplate group.  The
'capable' suffix was to allow a printer to distinguish between features
that it is capable of handling ('capable' suffix) and features that it
supports via IPP attributes ('supported' suffix).

An output device that supports IPP would likely have the same values in
the 'supported' attribute as in the 'capable' attribute, in which case
it would not need to have any 'capable' attributes (according to the
Friday proposed rules).  Whereas a print server that has to modify a
PostScript file, might show 'as-is' as the only supported values for
many production attributes, but would show a complete feature list for
each 'capable' attributes.

I think we got the concept right, but we did not get the operation for
the client right.  With Friday rule, when a client presents a set of
potential values for an attribute to an end-user, it implements one of the
following two rules:

   o Rule 1, the client is embedding production attributes in the PDL:
     look for the 'capable' attributes first and then the 'supported' attributes. 

   o Rule 2, the client is explicitly including the IPP production attributes: 
     look for the 'supported' attributes only.  

I think that this complexity, if it is implemented, should be on the
server side, and the client should see one set of allowed values for
each attribute.

A client knows whether it is following rule 1 or 2 (above).  So it
would be better for GetAttributes to have an additional parameter
called "allowed" whose value is 'supported' or 'capable' (default
'supported'). This attribute tells the server whether to follow rule 1
or 2 when producing the list of allowed values for each attribute.

An administrator could see the 'supported' and 'capable' attributes,
but not an end-user. The end-user sees only 'allowed' values.

Note:  If an attribute on the server has a 'supported' suffix, but no
'capable' suffix, then the 'capable' value is the same as the
'supported' value.

The words 'allowed', 'supported' and 'capable' may not be the right words
for these three concepts, but I haven't thought of any better ones yet.

Comments?

Bob Herriot

---

From: JK Martin <[email-masked]>
Date: Mon, 5 May 1997 17:41:52 -0400 (EDT)

Bob,

Perhaps I haven't read your message (below) properly to understand
exactly what you're driving at, so forgive me if these statements
aren't relevant to your message.

On the issue of dealing with embedded, PDL-specific coding within the body
of a document, I thought we reached these conclusions and consensus:

  1.  We don't want to promote the direct embedding of device and job
      controls within print data; instead, we want to move towards complete
      separation of print data and such controls.  (This is what spawned
      the UPD discussion, etc.)

  2.  Parsing print data to extract and/or override such controls by the
      server side of IPP is an untenable situation.

  3.  As a result, we're taking the approach of "whatever is embedded in
      the print data is the responsibility of the client."  If the client
      declares certain attributes--but the print data overrides them during
      the printing process--then the client takes the responsibility for
      the results.

Does this correctly summarize the consensus and direction?

If so, then your statements below might be modified so as not to
suggest that an IPP-aware client can freely elect Rule #1 in which the
cient proceeds to embed device/job controls in the print data.

Sure, a client can do whatever it wants.  I'm just hoping the IPP group
doesn't encourage (in any way) the implementation of IPP-aware clients
that embed device and/or job controls in the print data.

	...jay

----- Begin Included Message -----

>From [email-masked] Mon May  5 16:29 EDT 1997
Date: Mon, 5 May 1997 13:21:59 -0700
From: [email-masked] (Robert Herriot)
To: [email-masked]
Subject: IPP>MOD reconsideration of model decision

Scott,

Comments?

Bob Herriot

----- End Included Message -----

---

From: [email-masked] (Robert Herriot)
Date: Mon, 5 May 1997 15:03:37 -0700

I believe that you are correct in stating that we want to get away from
embedded control information in a PDL file and servers that modify such
embedded information.

But the question is how to handle the transition. There are currently
print servers that modify control information in PostScript documents.
We have said in email during the past few hours, that we will implement
print servers somewhat before output devices support IPP.  If an output
device supports values X and Y for attribute A, and a print server
supports those values only when they are embedded in PostScript, then
we have a problem.  A client GUI that allows submission of pre-existing
PostScript files can show only 'as-is' as the value for attribute A or
show it as grayed out.  A client program for building a directory entry
should show values X and Y.

So we are stuck if we want to support today's technology before IPP
output devices arrive.  I have tried to define things so that the
'capable' concept can fall away gracefully when it is no longer
needed.  That is, in time there is no difference between 'capable' and
'supported' values.

> From [email-masked] Mon May  5 14:38:44 1997
> 
> Bob,
>

---

From: [email-masked] (Robert Herriot)
Date: Mon, 5 May 1997 15:52:44 -0700

> From [email-masked] Mon May  5 15:14:09 1997
> 
> Bob,
> 
> > output devices arrive.
> If existing print drivers are considered "today's technology", then
> today's technology won't know anything about IPP, correct?

Correct, but I am thinking UNIX when I talk about print servers that
inject PostScript into document data.  This might happen via a client
GUI, via a client command, or via the selection of a particular logical
printer which causes the server inject some PostScript into the
document (e.g. duplexing).

> 
> Perhaps I'm missing something, then.  Does anyone think that IPP is
> being designed such that today's print drivers can submit jobs to
> an IPP Printer?

I am assuming that in the Window's world, there could be an IPP Print
Provider for IPP printers which would take the PostScript or PCL file
received from the driver and forward it to the Printer using IPP protocol.
I wouldn't expect job attributes to play any role in this case.

> 
> Maybe that's where I'm getting confused.  I'm making the assumption
> that to drive an IPP Printer, you need an IPP-aware print driver.
> Is this assumption incorrect?

If the driver wants to make use of dynamic attribute information, then
the driver needs to be IPP aware. But a driver/GUI could works as it
does currently with static awareness. It can communicate with an IPP Printer
via a new IPP Print Provider, or use the existing one (e.g. lpr). In 
the latter case, the IPP Printer would have an lpr-to-IPP gateway.

---

From: Roger K Debry <[email-masked]>
Date: Tue, 6 May 1997 14:25:53 -0400

I think other's have also responded,  ... comments below:

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

RKD> Yes, in most environments there is
RKD> a separate component that actually
RKD> handles the wire protocol. In various
RKD> systems these are called a port driver,
RKD> port monitor, or redirector. While existing
RKD> print drivers would not have to be changed
RKD> to work with IPP, these components would.

 ...jay

---

From: "Danknick, Dan" <[email-masked]>
Date: Tue, 6 May 1997 11:26:43 -0700

>
>I hope we are all balled up in terminology not technology.  From this
>printer manufacturer's perspective, a printer driver creates the 
>datastream for a printer.  A "redirector" or "port driver" pushes that 
>datastream out the desired physical connection (parallel port, serial
>port, IPX/SPX ethernet, etc.)
>
>My  assumption is that IPP will work with today's drivers but require 
>new "redirector" or "port driver" software.

That is certainly the approach we see as a short term solution.
There are of course a number of ways this can be accomplished,
from Java IPP clients to Navigator plug-ins.

The downside of being on the receive-only end of the print stream is
that
it could be difficult to communicate target printer capabilities to the
PDL
generator in advance.

Dan Danknick
Canon Information Systems

---

From: JK Martin <[email-masked]>
Date: Tue, 6 May 1997 14:34:16 -0400 (EDT)

> Does anyone think that IPP is

Which platforms support such a wire protocol shim?  I thought Windows/NT
and Windows '95 did, but what about:

	Windows 3.1
	Windows for Workgroups
	OS/2 2.x
	OS/2 Warp
	others?

Thanks for the Wintel info.  We Unix folks have different operational
situations, that's for sure.  ;-)

	...jay

---

From: [email-masked] (Robert Herriot)
Date: Tue, 6 May 1997 11:47:25 -0700

> From [email-masked] Tue May  6 04:25:33 1997
> 
> Don

I agree with you, Don, and others who have replied.

---

From: Roger K Debry <[email-masked]>
Date: Tue, 6 May 1997 14:49:33 -0400

I think that I agree with Jay on this one. I fear that we are burdening
IPP with complexity in order to to solve a problem on a small set of
servers. Is the class of servers that changes controls in the Postscript
file a very large piece of the Universe? I suspect not. Rather than solve
every conceivable problem in this very large universe, we ought to
get back on track with the rule I thought we agreed to awhile back --
to solve the few problems well that represent the largest customer
value.  Over time the rest of the world will catch up and do things
**right**. Rule (1) below makes no sense to me. Clients (drivers) that
understand IPP (and therefore know what xxx-capable means)
ought not to imbed controls in the PDL, period!   I think that adding
xxx-capable is adding undue complexity!!!

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/06/97 12:33
PM ---------------------------

        ipp-owner @ pwg.org
        05/05/97 04:14 PM
Please respond to [email-masked] @ internet

To: jkm @ underscore.com @ internet, Robert.Herriot @ Eng.Sun.COM @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD reconsideration of model decision

>      look for the 'capable' attributes first and then the 'supported'
attributes. > >    o Rule 2, the client is explicitly including the IPP
production attributes: >      look for the 'supported' attributes only. > >
I think that this complexity, if it is implemented, should be on the > server
side, and the client should see one set of allowed values for > each attribute.
>
 > A client knows whether it is following rule 1 or 2 (above).  So it > would
be better for GetAttributes to have an additional parameter > called "allowed"
whose value is 'supported' or 'capable' (default > 'supported'). This attribute
tells the server whether to follow rule 1 > or 2 when producing the list of
allowed values for each attribute. > > An administrator could see the
'supported' and 'capable' attributes, > but not an end-user. The end-user sees
only 'allowed' values. > > Note:  If an attribute on the server has a
'supported' suffix, but no > 'capable' suffix, then the 'capable' value is the
same as the > 'supported' value. > > The words 'allowed', 'supported' and
'capable' may not be the right words > for these three concepts, but I haven't
thought of any better ones yet. > > Comments? > > Bob Herriot > > > -----
End Included Message ----- > >

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 06 May 1997 14:31:11 -0600

Bob,

Below you suggest the need for a client to query on "allowed" attributes and
the server fills in the correct supported or capable if they are both
implemented.  I have reviewed your email, and still don't get the need for
your suggestion.

My understanding:

A client queries the Printer and gets back some attributes.  Since it gets
xxx-supported and xxx-capable, it knows the difference in semantics of the
two and does the right thing.  If it sees a value in xxx-capable, it knows
that it must format some PDL string in order to realize the request.  If it
sees a xxx-supported attribute it knows that is must supply a corresponding
xxx attribute in the print request or live with the default (the xxx
attribute at the Printer).

Scott

>>> Robert Herriot <[email-masked]> 05/05 2:21 PM >>>
Scott,

attributes. 

   o Rule 2, the client is explicitly including the IPP production
attributes: 
     look for the 'supported' attributes only.  

Comments?

Bob Herriot

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 06 May 1997 14:53:31 -0600

Jay makes some excellent summary principles below:

>>> JK Martin <[email-masked]> 05/05 3:41 PM >>>
>  

IPP aware clients better to the right thing (the UPD for example) -- where
the right thing is IPP-aware client can NOT freely embed device/job controls
in the print data.  The IPP group realizes there must be a transition period
where we continue to work with what we got (non IPP aware clients) while at
the same time moving to a brave new world.

Scott

---

From: [email-masked] (Robert Herriot)
Date: Tue, 6 May 1997 13:58:25 -0700

> From [email-masked] Tue May  6 13:34:29 1997
> 
> Bob,
> 

Perhaps, I didn't explain the idea clearly.  I intended that the client
wouldn't have to do the work of looking for both 'capable' and
'supported' attributes.  Instead the server would do the same work and
just send an 'allowed' attribute with the value of the 'capable' or
'supported' according to the two rules I defined (included further down
in this email).  With my rule, a client using IPP attributes only uses
'allowed' attributes and can be totally unaware of the 'capable'
parameter to getAttributes.  A client that will imbed all production
attributes still uses the 'allowed' attributes, but specifies the
'capable' parameter to the getAttributes operation.  Without my
proposed change, such a client would have to look for 'capable' and
'supported' attribute when building a GUI -- perhaps not a big thing
for this legacy support, but I would rather that legacy support be in 
a server as much as possible.

---

From: JK Martin <[email-masked]>
Date: Tue, 6 May 1997 17:15:53 -0400 (EDT)

Bob,

Ok, so I'm dense...  I still can't quite come to grips with your
explanation below, and I'm really trying!

> a server as much as possible.

Perhaps a line drawing or two would serve to clarify these situations?
Something like a set of quick pictures of the scenarios you describe?

	...jay

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 06 May 1997 15:20:50 -0600

>>> JK Martin <[email-masked]> 05/06 12:34 PM >>>
> 

Windows 95 and Windows NT make a very open and explicit Printer Provider
interface.  In the DOS and Windows worlds, this has been implemented at a
"redirector" - really deep, under the covers, fairly "unknown" to the OS
itself, lives a redictor that traps interrupts and puts itself between the
application and the low level OS port interfaces.  If a job comes it it
"steals" the job away from the OS and "redirects" it out to the network.  It
can also have configuration information in it os send along (not runtime)
but preconfigured job attributes to cause certain behavior of the back end
job processiong instrcutions.  In the Novell world, this was done with the
capture command.  When I "captured" the port, jobs would be redirected with
the parameters set a capturing time.   There are also similar redirectors in
the OS/2 and OS/2 Warp worlds, but I forget how formal the interfaces are
(that is if it is a more low level "redirector" interface or a higher level
"provider" interface).

Scott

---

From: Scott Isaacson <[email-masked]>
Date: Tue, 06 May 1997 15:50:05 -0600

Roger, my comments are below

>>> Roger K Debry <[email-masked]> 05/06 12:49 PM >>>

An implemented xxx-capable attribute on a Printer means:

This printer is capable of the features implied by the values of this
attribute, however, in order to have a job realize these features, the
instructions must be in the PDL, not in the external attributes.

An implemented xxx-supported attribute on a Printer means:

This printer supports the features implied by the values of this attribute,
however, in order to have a job realize these features, the instructions
must be in the Job attributes (not in the PDL) and if a similar instruction
happens to be in the PDL, this printer can override that with the value in
the Job attribute.

xxx-capable allows us to work with existing, non IPP aware printer drivers.
xxx-supported allows us to move to a better future with Job attribute,
printer capabilities, and control all outside the PDL (the only reason it is
all mumbled up in the PDL is becuase there has never really been a separate
control channel to a printer, just a data channel).

If we go with Jay's suggestion and just let a client "get what they get" if
they submit job attributes as well as PDL encodded instructions, then maybe
xxx-capable is just for the directory entry (the printer is capapable of
some feature, get the right legacy driver, non IPP aware, and you are off
and running with no job attributes).   But I think it is useful for the
directory at least, perhaps not for client queries directly at the printer.

Scott

---

From: Roger K Debry <[email-masked]>
Date: Tue, 6 May 1997 18:24:15 -0400

It seems to get more complicated by the minute ...

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/06/97 04:21
PM ---------------------------

        ipp-owner @ pwg.org
        05/06/97 03:29 PM

To: Robert.Herriot @ Eng.Sun.COM @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD reconsideration of model decision

Bob,

 ...jay

---

From: Roger K Debry <[email-masked]>
Date: Wed, 7 May 1997 10:04:42 -0400

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/07/97 07:35
AM ---------------------------

        SISAACSON @ novell.com
        05/06/97 04:20 PM

To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet
cc:
Subject: Re: IPP>MOD reconsideration of model decision

RKD> This seems a bit of an oxymoron. If a client is capable of
RKD> understanding what an xxx-capable attribute is at all, then
RKD> it must be ipp-aware. If it is ipp-aware, it is a new driver
RKD> which ought to exploit ipp by setting controls as ipp
RKD> attributes, not imbedding them in the PDL.

RKD> How do I change attributes on a page-by-page basis then?

RKD> I'm really lost --- sorry to be dense but I don't understand
RKD> how xxx-capable allows a non-ipp aware driver to do anything
RKD> (since it is non-ipp aware it doesn't understand any ipp
RKD> attributes so how does it know what ipp-capable means?) Are
RKD> we are worried about a client which takes an existing PDL
RKD> file and submits it for printing? If so, what does it care
RKD> about xxx-capable for since it does not build the PDL. If we
RKD> are worried about some clients that take the existing PDL and
RKD> add controls to it, I'd ask once again how many of those are
RKD> there and does that number justify this added complexity.

RKD> Think about this alternative. Just as we have agreed that
RKD> downloading and installing a print driver is outside the
RKD> scope of IPP, why not declare the way that *legacy* drivers
RKD> get information about the printer, i.e. xxx-capable, to be
RKD> outside the scope of IPP. That's the way that drivers work
RKD> today, they use ppd files or other side files which describe
RKD> capabilities of the device required to generate the correct
RKD> ouput. We have provided an attribute which points to a place
RKD> where drivers and driver installers live. Why not let ppd files
RKD> or other side files live at the same place? Now when I install
RKD> a legacy device as an IPP printer I get the driver *and* the
RKD> ppd (or whatever) files that the driver would normally use anyway.

Scott