I've copied the .doc, .pdf, and .txt files to:
ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.doc
ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.pdf
ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.txt
The .txt file follows:
Subj: Future Model change: early binding of defaults is more understandable
to end-users
From: Tom Hastings
Date: 2/2/98
File: clearer-defaulting.doc
This paper proposes a future upwards-compatible tweak to the Model
document that preserves the current semantics for attribute defaulting
(default value is used only if the PDL does not contain a corresponding
embedded instruction), but makes it clearer to the end-user what the
default values are/were for the end-user's job. This tweak also allows
the system administrator to change the defaults on a Printer object
without affecting any submitted jobs, thereby allowing us to drop the
warning note on page 60.
The idea is for the Printer object to copy its "xxx-default" attributes
and values to the Job object in the create operation for any supported
attribute that the client does not supply. In other words, the "xxx-
default" value is bound to the Job object at create time, instead of
using the Printer object's value at job processing time. Since the name
of the Job attribute is "xxx-default", not "xxx", it is clear that the
value is used only if the document data does not contain an equivalent
instruction. This is "early" binding of defaults to the Job object.
The user can query the Job object before or after the job is printed to
see what the defaults are/were. This is particularly helpful to a user
who is surprised at his/her print job results and wants to check what
attributes the job had (while the job is in the 'completed' state). It
is also helpful to the user while the job is in the 'pending' or
'pending-held'state.
The simplest change is to extend the definition of Job Template Job
attributes to include the "xxx-default" attributes (column two of the
table in section 4.2). Then the Get-Attributes operation returns both
"xxx" and "xxx-default" Job object attributes (in response Group 3) when
the requester supplies the "job-template" value in the "requested-
attributes" operation attribute.
The changes to the Model document are not that many (page/line numbers
refer to the ipp-model-980116.pdf version):
1. Page 15, lines 521-523: modify the explanation of job template Job
attributes:
"job-template" attributes: These attributes are OPTIONALLY supplied
by the client or end user and include job processing instructions
which are intended to override any Printer object defaults and/or
instructions embedded within the document data. (See section 4.2)
to give:
"job-template" attributes: These attributes are either "xxx" or
"xxx-default" attributes. The "xxx" attributes are OPTIONALLY
supplied by the client or end user and include job processing
instructions which are intended to override any Printer object
defaults and/or instructions embedded within the document data. The
"xxx-default" attributes supplied by the Printer object when the
client does not supply the corresponding "xxx" attribute. The "xxx-
1
instructions embedded within the document data. (See section 4.2)
2. Page 20, line 705, add to the description of Job Template attribute
the phrase: "and which were supplied as defaults by the Printer
object in case the document contains no such corresponding
instructions embedded in the data" to give:
The Job object can later be queried to find out what Job Template
attributes were originally requested in the create request and which
were supplied as defaults by the Printer object in case the document
contains no such corresponding instructions embedded in the data, and
such attributes are returned in the response as Job Object
Attributes.
3. Page 20, line 709, delete the phrase ", though such attributes are
returned in the response as Printer Object Attributes" to give the
following:
The Printer object can be queried about its Job Template attributes
to find out what type of job processing capabilities are supported
and/or what the default job processing behaviors are, though such
attributes are returned in the response as Printer Object Attributes.
4. Page 33, after line 1168, add the following bullet to the list:
- Copies its "xxx-default" attributes to the Job object for any
"xxx" Job Template attribute not supplied by the client.
5. Page 33, lines 1169-1171, change the last bullet from:
- at job processing time, uses its corresponding default value
attributes for the supported Job Template attributes that were not
supplied by the client as IPP attribute or embedded instructions in
the document data.
to:
- at job processing time, uses the Job's "xxx-default" attributes for
the supported Job Template attributes that were not embedded
instructions in the document data.
6. Page 48, lines 1708-1709, replace "first column" with "first and
second columns" in the description of the "job-template" attribute
group name in the Get-Job-Attributes operation description to give:
- 'job-template': all of the Job Template attributes that apply to a
Job object (the first and second columns of the table in Section
4.2).
7. Page 60, line 2084, add the sentence:
The Printer object indicates its default value for each "xxx"
attribute by copying its corresponding "xxx-default" attribute and
value to the Job object as part of the create job operation.
8. Page 60, lines 2086-2088, delete the note:
Note: Since an administrator MAY change the default value attribute
after a Job object has been submitted but before it has been
processed, the default value used by the Printer object at job
processing time may be different that the default value in effect at
job submission time.
9. Page 61, lines 2120:2127, indicate that column two (xxx-default) is a
Job Template attribute for both the Job and Printer objects as
follows:
The table below summarizes the names and relationships for all Job
Template attributes. The first two columns of the table (labeled
"Job Attribute") show the name and syntax for each Job Template
attribute in the Job object. These are the attributes that can
optionally be supplied by the client in a create request. The last
two columns (labeled "Job/Printer: Default Value Attribute" and
"Printer: Supported Values Attribute") shows the name and syntax for
each Job Template attribute in the Printer object (the default value
attribute and the supported values attribute). A "No" in the table
means the Job and Printer SHALL NOT support the attribute (that is,
the attribute is simply not applicable). For brevity in the table,
the 'text' and 'name' entries do not show (MAX).
10. Page 62, line 2129, change the column two heading from "Printer:
Default Value Attribute" to "Job and Printer: Default Value
Attribute"
11. Page 151, lines 5134-5135: add to the end of the sentence:
by copying its "job-priority-default" attribute and value to the Job
object
to give:
IF NOT supplied by the client, use the value of the Printer object's
"job-priority-default" attribute at job submission time by copying
its "job-priority-default" attribute and value to the Job object.
12. Page 151, lines 5145:5146: add to the end of the sentence:
by copying its "job-hold-until-default" attribute and value to the
Job object
to give:
IF NOT supplied by the client, use the value of the Printer object's
"job-hold-until-default" attribute at job submission time by copying
its "job-hold-until-default" attribute and value to the Job object.
13. Pages 155-156, lines 5300:5302: add:
and the corresponding Printer object's "xxx-default" is copied to
the Job object
to give:
If an attribute has no values after removing unsupported values from
it, the attribute is removed from the Job object and the
corresponding Printer object's "xxx-default" is copied to the Job
object (so that the normal default behavior at job processing time
will take place for that attribute).
14. Page 156, lines 5304:5306: add:
and the corresponding Printer object's "xxx-default" is copied to
the Job object
to give:
If an attribute has no values after removing conflicting values from
it, the attribute is removed from the Job object and the
corresponding Printer object's "xxx-default" is copied to the Job
object (so that the normal default behavior at job processing time
will take place for that attribute).
15. Page 156, line 5318, add:
(but not "xxx-default") to give:
Note: All "xxx" (but not "xxx-default") Job Template attributes that
are persistently stored with the Job object are intended to be
"override values"; that is, they that take precedence over whatever
other embedded instructions might be in the document data itself.
16. Page 156, lines 5323:5328, change the paragraph to describe copying
the "xxx-default" Printer object attributes to the Job object, to
give:
There are some cases, where a Printer supports a Job Template
attribute and has an associated default value set for that attribute.
In the case where a client does not supply the corresponding
attribute, the Printer copies its "xxx-default" attributes to
populate Job attributes when creating the new Job object. These
copied Job default values are only used later at Job processing time
if no other IPP attribute or instruction embedded in the document
data is present.
17. Page 156, lines 5329:5335, change the first sentence of the note to
explain the copying of the lower precedance "xxx-default" attributes,
rather than "xxx" to the Job object, giving:
Note: If the default values associated with Job Template attributes
that the client did not supply were to be used to populate the Job
object as "xxx" (instead of "xxx-default") attributes, then these
values would become "override values" rather than defaults. If the
Printer supports the 'attempted' value of the "pdl-override-
supported" attribute, then these override values could replace values
specified within the document data. This is not the intent of the
default value mechanism. A default value for an attribute is used
only if the create request did not specify that attribute (or it was
ignored when allowed by "ipp-attribute-fidelity" being 'false') and
no value was provided within the content of the document data.