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 -----
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 -----