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 jkm at underscore.com Mon May 5 14:38:44 1997
>> 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 ipp-owner at pwg.org Mon May 5 16:29 EDT 1997
> Date: Mon, 5 May 1997 13:21:59 -0700
> From: Robert.Herriot at Eng.Sun.COM (Robert Herriot)
> To: ipp at pwg.org> Subject: IPP>MOD reconsideration of model decision
>> 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
>>> ----- End Included Message -----
>>