I agree with your conclusions.
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
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 walker at dazel.com @ 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 <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX