"Manros, Carl-Uno B" wrote:
> ...
> I saw that you had voted NO on the PWG document "Override Attributes
> for Documents and Pages".
>> Normally this kind of objection should have come during the PWG IPP
> WG Last Call stage, but ignoring that, the PWG rules state that:
>> "All "NO" votes must include a reason and changes that
> could be made to turn the no to a yes."
>> Can you please submit such a reason and proposed change to the
>pwg-ipp at pwg.org DL with a copy to the pwg at pwg.org DL.
The main reason was the use of collections. I've voiced my
objections to collections before on the IPP DL. With very few
exceptions, collections are not a good solution because of the
complexity they add.
I'm also concerned about how this extension proposal tries to
shoehorn PDL level output control into IPP rather than the
document. IPP provides rather limited IPP job template attributes -
for example, the "media" attribute only supports a single value for
any given job. This makes it unsuitable for selecting media
(the primary use of this extension AFAICT) and I'm sure is one
reason why none of the printer manufacturer's implementations
support media selection using the media attribute (CUPS extended
the media attribute to support a 1setof syntax to work around this
problem, which I posted almost a year ago IIRC...)
If the existing IPP job template attributes are not sufficient
to do media selection, etc. for jobs as a whole, they certainly
aren't sufficient to do it for documents or pages in the
documents.
Finally, page-level control should be the province of the PDL.
If you want to do this with IPP, break the master document into
multiple documents using the different attributes. Don't try
to complicate IPP with an extension that noone will use...
What changes could be made to turn my vote to a yes?
1. Get rid of collections; collections only complicate the
implementation.
2. Get rid of the page-level overrides. These belong in the
PDL.
3. Instead of using collections to describe every document
in a create-job request, provide defaults in the create-job
and overrides in each send-document and send-uri request.
[this brings up the subject of having document objects
associated with each job object]
4. Add new operations - get-job-document-attributes,
set-job-document-attributes, etc. to access and change
individual document attributes.
5. Add new "document-state" document object attribute.
6. Add new "number-documents" job object attribute.
7. Allow a 1setof syntax for the "media" attribute, or
define new media-something attributes that cover the
different values needed (color, weight, source, type,
size)
As you can see, this would be a completely different
implementation and proposal.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com