Michael,
I wasn't completely clear on my suggestion about adding new keywords to
"job-sheets" Job Template attribute. My intention was that you consider
adding three new keywords to the existing IPP/1.1 "job-sheets" (type3
keyword | name) Job Template attribute that you are already supporting in
CUPS. I had not intended that you implement the 'collection' attribute
syntax at all. Unfortunately, the spec that I referred to (PPE spec) did
have the 'collection it too.
So making my suggestion again, how about just adding the following keywords
to the CUPS "job-sheets" (type3 keyword | name) Job Template attribute,
instead of adding the two new "banner-start" and "banner-end" Job Template
attributes?
In other words, just add the following three keywords to "job-sheets":
'job-start-sheet' A job sheet MUST be printed to indicate the start of the
job.
'job-end-sheet' A job sheet MUST be printed to indicate the end of the
job.
'job-wrap-sheets' Job sheets MUST be printed to indicate the start and end
of
all the output associated with the job.
(If you don't like the name of the last one, suggest a better name for us to
agree on, like 'job-start-and-end-sheets').
ISSUE: Does it make sense to have an end sheet without a start sheet? If
not, we should eliminate the 'job-end-sheet' value.
Wouldn't it be simpler to use these values in CUPS, rather than introducing
two new Job Template attributes?
About collections:
On the subject of "job-sheets" and "media" and collections that is in the
PWG "Production Printing Extension" (PPE) spec:
I agree that neither you (nor anyone else) should implement the PPE spec at
this time (with its 'collection' attribute syntax extension to
"job-sheets"). The PPE spec has been reviewed only slightly by the PWG and
has already has push back on extending "job-sheets" (type3 keyword | name)
and "media" (type3 keyword | name) by adding the 'collection' attribute
syntax to the IPP/1.1 attributes to give:
"job-sheets" (type3 keyword | name | collection) and
"media" (type3 keyword | name | collection)
Instead, the suggestion for the next version of the PPE spec is to add two
new OPTIONAL attributes and leave the IPP/1.1 attributes as they are. Then
we would have:
"job-sheets" (type3 keyword | name) and
"job-sheets-col" (collection)
"media" (type3 keyword | name) and
"media-col" (collection)
If the Printer supports the "xxx-col" (collection) Job Template attribute,
it MUST also support the (simpler) IPP/1.1 "xxx" (type3 keyword | name) Job
Template attribute.
The "media-col" collection has all sorts of member attributes that represent
the characteristics of media, such as "media-size", "media-weight",
"media-color", etc.
The "job-sheets-col" (collection) attribute would have the following member
attributes:
"job-sheets (type3 keyword | name)
"media" (type3 keyword | name)
that allow a production printing client to control the media on which the
job start and/or end sheet is printed.
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Monday, March 20, 2000 19:33
To: Hastings, Tom N
Cc: IPP Mailing List
Subject: Re: IPP> New CUPS 1.1 beta and set-job-attributes extension
[why not use "job-sheets"?]
"Hastings, Tom N" wrote:
> ...
> Wouldn't it be simpler to use these values in CUPS, rather than
> introducing two new Job Template attributes?
1. The PPE uses COLLECTIONS for this stuff
2. Collections are still being defined.
3. CUPS currently does not do anything with collections (it will
store the raw data, but that is all)
4. Without collections the job-sheets attribute cannot support
what CUPS needs to do.
Given those things, it is unlikely in the EXTREME that we will
change our design this close to a final release.
It is *possible* that we can change the names of the attributes
to "job-sheets-*", however I am concerned that we might step on
future attributes. Possible names:
job-sheets-supported
job-sheets-start-default
job-sheets-end-default
job-sheets-start
job-sheets-end
At least that would be in line with the IPP spec, but that also
means we must support "job-sheets" and "job-sheets-default". I'm
not sure how we would map that given the ambiguity in the spec...
Another possibility might be to overload the "name" value to use
"start,end" for the "job-sheets" and "job-sheets-default" attributes,
however that might break clients that try to compare them against
the "job-sheets-supported" values.
In any case, any change we make now CANNOT include support for the
PPE spec.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, March 20, 2000 14:06
To: Michael Sweet
Cc: IPP Mailing List
Subject: RE: IPP> New CUPS 1.1 beta and set-job-attributes extension
[why not use "job-sheets"?]
Michael,
There are two new Job Template attributes: "banner-end" and "banner-start"
that CUPS/1.1 is introducing that I was curious about. It was our intention
that the IPP/1.0 "job-sheets" (type3 keyword | name) Job Template attribute
would perform the function that your two new Job Template attribute are
performing. While we only had two values defined in IPP/1.0 and IPP/1.1:
'none' and 'standard', we thought that it would be simple to add more values
whenever someone wanted.
In fact, the PWG "Production Printing Attributes, Set1" spec proposes three
new keywords for use with the IPP/1.1 "job-sheets" Job Template attribute:
job-start-sheet A job sheet MUST be printed to indicate the start of the
job.
job-end-sheet A job sheet MUST be printed to indicate the end of the job.
job-wrap-sheets Job sheets MUST be printed to indicate the start and end of
all the output associated with the job.
Wouldn't it be simpler to use these values in CUPS, rather than introducing
two new Job Template attributes?
>From your CUPS spec:
4.1.1 Print-Job Request
The following groups of attributes are supplied as part of the Print-Job
Request:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language" attributes as
described in section 3.1.4.1 of the IPP Model and Semantics document.
"printer-uri" (uri):
The client MUST supply a URI for the specified printer.
Group 2: Job Template Attributes
"banner-end" (name(127)):
(CUPS 1.1 and higher)
The client OPTIONALLY supplies a banner page that is printed after any files
in the print job. The name of "none" is reserved to indicate that no banner
page should be printed. If the client does not specify this attribute then
the value of the "banner-end-default" printer object attribute is used.
"banner-start" (name(127)):
(CUPS 1.1 and higher)
The client OPTIONALLY supplies a banner page that is printed before any
files in the print job. The name of "none" is reserved to indicate that no
banner page should be printed. If the client does not specify this attribute
then the value of the "banner-start-default" printer object attribute is
used.
Other Job Template Attributes
Comments?
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Monday, March 13, 2000 05:44
To: IPP Mailing List
Subject: IPP> New CUPS 1.1 beta and set-job-attributes extension
Hi, All!
We're getting close to the second beta release of CUPS 1.1. Part of
the next beta release is support for the set-job-attributes operation
(see draft-ietf-ipp-job-printer-set-ops-01.txt)
HOWEVER
The current implementation of the set-job-attributes in CUPS will
support changing of the job-printer-uri attribute, which is currently
marked as READ-ONLY in the spec. I've mentioned this problem before,
but let me summarize once again:
1. The job-printer-uri attribute needs to be changeable to
support a "move-job" type operation.
2. We can eliminate certain "special case" problems such as
moving jobs to a different server by restricting the new URIs
to the same server, or allowing the server to reject changes
if they are not possible (e.g. SHOULD support moving to a
different server, MUST support moving to a different printer
object on the same server...)
3. To support implementations that maintain a separate job ID
space for each printer object, the set-job-attributes
operation would then also report the current job-id and
job-uri attributes in the response data.
Our current options with CUPS are to ship it with a non-conforming
implementation of set-job-attributes, or register yet another
extension operation that performs exactly the same functionality
as set-job-attributes but allows the job-printer-uri attribute to
be changed.
Thoughts?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com