Subject: IPP> MOD -- xxx-supported attributes

From: Roger K Debry <[email-masked]>
Date: Wed, 7 May 1997 11:40:29 -0400

I agree with your conclusions.

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

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

        ipp-owner @ pwg.org
        05/07/97 09:27 AM
Please respond to [email-masked] @ internet

To: ipp @ pwg.org @ internet
cc:
Subject: IPP> MOD  --  xxx-supported attributes

I was assigned the following task from the last model meeting:

 >> 2. Since we are getting rid of tags, it is not acceptable to live with the
 >> ambiguity as clarified by Tom in last weeks minutes.  That is xxx-supported
 >> values are: 1) client desires to
 >> override the PDL (the same instruction is in the PDL) or 2) client desires
 >> action only when the information is not in the PDL.  This was once being
 >> solved by the embedded and embedded-only tags.  Since we have no tags, the
 >> proposal is to define a set of xxx-capable attributes to go along with the
 >> xxx-supported attributes.  Jim Walker took an action item to write this up
 >> can clarify semantics of xxx-supported, xxx-capable and best-effort and
 >> embedded instructions in PDL.

Here are the three alternatives as I see them:

(1) The server advertises the productions that it is capable of supporting,
 assuming that the client inserts the appropriate printer- and PDL-
 specific sequence in the PDL data stream.  This is the situation
 as we have today in the PC driver world, and the situation that
 most seem to think that we ought to try to get away from.

(2) The server advertises the productions that it can support, assuming
 that the client sends the appropriate IPP attribute in the job (or
 document) control stream, and does not insert any conflicting
 production instructions in the PDL data stream.  This is the ideal
 situation in the UPD world.

(3) The server advertises the productions that it can support, whether the
 client sends the appropriate IPP attribute, and/or has the same or
 conflicting production instructions in the PDL data stream.  This
 is the robust case that everybody *thinks* they want, but I would
 argue that this situation is untenable in general (e.g., I pass a
 document that is already 4-up'ed, and tell the server that I want
 it 2-up'ed, and, by the way, best-effort is do-not-substitute).

I believe that IPP printers ought to *only* support option (2) above.

First of all, we can do option (1) today without the IPP printer
advertising its capabilities.  In this case, the driver would use PPD
files (or whatever other information it already has or wants today) and
generate an appropriate PDL data stream, and forward that data stream on
to an IPP printer with few, if any, IPP attributes.  The driver would not
need to query the capabilities of the printer, as it could just get that
information the same way that it does today.  After all, if we were going
to modify the driver to query the IPP printer, why not go ahead and modify
it to set the appropriate attributes in the job control stream, as in
option (2), rather than in the data stream.

Furthermore, knowing the capabilities supported in option (1) does not
help with pre-generated files either; the user does not know (unless they
have software to scan the file) what capabilities were utilized in
generating the data file, so it does not help that they know what
capabilities the printer will support.

As I have already stated above, I do not believe that option (3) is
supportable, especially if we try to tie this together with the
best-effort attribute.  If we say that the IPP printer can only advertise
the supported attributes that it can override what is specified in the
data file, then will any IPP printers be able to any supported attributes.
In other words, if I am a print server that fronts a duplex printer, yet I
am unable to guarantee that I can override a simplex/duplex capability
specified in a PDL data stream, then I cannot advertise sides-supported.

So, I believe that option (2) is the only option that we should attempt to
specify in IPP, especially version 1.0.  With this option, we can say that
the xxx-supported attribute describes those capabilities that the IPP
printer can support if the associated xxx attribute is specified in the
print job.  If a conflicting instruction is specified in the PDL data
stream, then the results are undefined.

comments welcome...
...walker

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

---

From: JK Martin <[email-masked]>
Date: Wed, 7 May 1997 13:22:36 -0400 (EDT)

Jim,

Thanks for the outstanding analysis and summary.

> [...]
> [...]

I concur with your conclusions and recommendations up and down the line.

	...jay

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

---

From: [email-masked] (Robert Herriot)
Date: Wed, 7 May 1997 19:30:41 -0700

I think that Jim and I have a different understanding of how the UPD
should work in the case where an attribute is specified externally and
embedded in the PDL.

I think that we all agree that in a perfect world, the PDL contains no
embedded attributes and all attributes are specified externally.

Meanwhile, I would expect that customer will want to print existing
documents with attributes embedded in the PDL and want to override them
with external IPP attributes. Certainly, Jim's case of 4-up internally
and 2-up externally presents a problem.  But other attributes, such as
sides to not present a problem, especially if the PDL interpreter
supports IPP attributes.

I also think that I don't understand how option 2 (below) works.  How
does a client know whether an attribute should be embedded or external.
Are there some rules?

I think that IPP needs to support the following scenarios:

   1) UPD printer: the printer honors an external attribute and 
      ignores the corresponding embedded attribute if any, unless 
      the external attribute is absent or has the value 'as-is'.  

      Note: I include true printer features in the list of such external 
      attributes and exclude image transformations, such as n-up.

      Note: embedded attributes that are beyond IPP capabilities (e.g. 
      different media on different pages) require the 'as-is' value.

   2) UPD client: the client queries the IPP printer for attributes and
      generates external attributes. It does not embed control information 
      in the PDL.

      If the printer is an IPP printer, then the supported production
      attributes should be the same as those supported as embedded
      attribute.

      If the printer is a legacy printer (supported by an IPP print
      server), then some attributes supported as embedded by the output
      device may not be supported by the IPP print server.  For such
      a printer, a Windows client would use a legacy driver to gain
      access to all the features. Unix clients should, likewise, use
      their legacy mechanism for accessing a legacy printer. 
      
      Issue: what about the "different media on different pages" raised
      above?

   3) Windows client legacy: the client continues to send just a PDL
      file with attributes embedded in the PDL. The attributes are known
      to the client and do not come from the IPP printer. The IPP printer 
      must not attempt to add external IPP attributes unless their 
      value is 'as-is'.

   4) Unix client/gateway legacy: the client/gateway continues to send
      a PDL and some lpr attributes. The attributes are known to the 
      client and don't come from the IPP printer. The lpr attributes are 
      translated to IPP attributes.
     
I think that all of this argues against the need for 'capable' attributes
because the client software that generates embedded attributes in the PDL
continues to operate as it currently does. And it doesn't use the
external attributes.

The one exception is for setting up the directory service.  Then the
question is which attributes should the printer display: the ones
accessible via IPP attributes or the ones accessible via embedding?
It does seem a bit strange for a client to find printers via the IPP
mechanism and then use a legacy driver to print, but it might still
be useful.

I also wonder, how useful are IPP print servers that talk to legacy
printers if they are unable to support IPP production attributes.
In other words, why would anyone switch from a legacy driver to a UPD
for a legacy printer if they lose functionality?

Those are my thoughts.

Comments welcome.

Bob Herriot

> From [email-masked] Wed May  7 08:28:55 1997
>