Here is the second of my three assignements. It is, I believe, self explanatory.
Steve
RE: Section 15.3 Suggested Attribute Processsing Algorithm
This section begins with the assumption that all operations (create
requests and get-attribute requests) are being considered and moves, in
step 3. to only considering create requests from that point forward. The
algorithm should not this specialization in step 3. and described what
happens to non-create or validate Job operations in some later step. For
example, we might create a step 3a. that specifies:
3a. If the requested operation is not a create request (Print-Job,
Print-URI or Create-Job operation) or a Validate-Job operation, then go to
step XX below.
Text must be written for step XX.
Secondly, step 2. rejects an operaton if the version number does not match.
The description of minor version differences indicates that a version
descrepency is OK if
a. the requested version number has the same Major version number and the
minor version number is higher than supported by the Printer object, and.
b. any attributes that are not known to the recipient of the operation
SHALL be ignored. (note that this is only OK if the
"ipp-attribute-fidelity" attribute has the value 'false'.)
In step 7., the "nor" following the initial clause should be an "or".
The following is proposed as a rewrite of steps 8 and 9.
8a. If the requested operation is the Validate-Job operation and a
"document-uri" attribute is supplied in the request, then the
"document-uri" is validated as specified in section 3.2.3, Validate-Job
Operation. If the Printer is able to accept the request and the validation
of any "document-uri" succeeded, then the Printer object returns the status
code "successful-ok". Otherwise, it returns a set of unsupported attributes
and/or the appropriate error status code.In either case the processing of
the operation is completed and no objects are created.
8b. The operation is a create request. If the Printer is able to accept the
create request (either as is or the "ipp-attribute- fidelity" attribute is
set to 'false' and some of the requested attributes can be ignored or have
their values substituted), then the Printer creates a new Job object . The
Job object is populated with those Job Template attributes from the create
request that the Printer object can honor. If the"ipp-attribute-fidelty"
attribute is set to 'true', this is necessarily all the Job Template
attributes in the accepted create request. If the"ipp-attribute-fidelty"
attribute is set to 'false', this is all the Job Template attributes that
are not ignored and/or have no value substitution. Thus, some of the
requested Job Template attributes may not appear in the Job object because
the IPP processor was not able to honor those attributes. The attributes
that were honored are persistently stored with the Job object for that Job.
A Get-Attributes operation on that Job object will return only those
attributes that a persistently stored with the Job object.
All 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 print
datastream itself. However, it is not possible for all implementations to
realize the semantics of "override". End users may query the Printer's
"pdl-override" attribute to determine if the Printer either attempts or
does not attempt to override print data instructions with IPP attributes.
9. 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
does not use its default values to populate Job attributes when creating
the new Job object; only Job Template attributes actually in the create
request are used to populate the Job object. The Printer's default values
are only used at Job processing time if no other IPP attribute or
instruction embedded in the print data is present.
If the default values associated with un-requested Job Template attributes
were used to populate the Job object, then these values would become
"override values" rather than defaults. If the Printer supports the
'attempted' value of the "pdl-override" attribute, then these override
values could replace values specified within the print datatsteam. This is
not the intent of the default value mechanism. A default value for an
attrbute SHALL be 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 print
datastream.
--------------------------------------------------------------
Stephen N. Zilles | e-mail: szilles at adobe.com |
Adobe Systems Inc. | |
Mailstop W14 | tel: (work) (408) 536-4766 |
345 Park Avenue | (Admin) (408) 536-4751 |
San Jose, CA 95110-2704 | fax: (408) 537-4042 |
--------------------------------------------------------------