Subj: Properties of IPP attributes
From: Tom Hastings
Date: 9/24/97
File: attrprop.doc
This document is an attempt to list the various properties of each IPP
attribute. It is intended as a worksheet in finishing the document and to
see if the WG agrees on these properties for each attribute. Perhaps such a
table would be helpful in the Model document, but that can be decided later.
If it is added, then there is the potential for disagreement with the text.
On the other hand, it is a handy reference for implementors. If it isn't
included in the document, it could be in the FAQ.
NOTE: this table is a work in progress.
There are the following properties of an attribute:
1. Can the client supply it and in which operations?
2. MUST the client supply it and in which operations?
3. MUST the Printer support it and in which operations?
3a. If the Printer MUST support it, which values?
4. MAY the Printer ignore it and in which operations?
5. If the Printer supports it, MUST it be querable?
6. MAY the client query it in Get-Attributes and Get-Jobs?
7. If queriably, which object (Job or Printer) does it go with?
8. If queriable, to which attribute group does it belong?
9. MAY an implemenation support storing/querying an attribute that isn't
required to be stored/queried?
10. Is any order required for any of the attributes?
11. Attribute syntax of the attribute
12. Whether the attribute may be multi-valued or not (1SetOf)
Lets skip the easy ones that belong to the major groups because they are
pretty clear in the current document:
"job-template"
"job-description"
"printer-description"
"all"
This leaves the following operational attributes and response attributes as
how to answer the above 12 questions. I've attempted to include the
agreements from last week's IPP meeting (mainly to drop per-document
attributes):
NOTE - The URI input parameters are NOT shown, since they are represented as
HTTP headers, not Operational Attributes.
EDITORIAL ISSUE: May still be good to include them in the Model document,
then make it clear in the Protocol document how they are mapped to the HTTP
headers.
create operations (Print-Job, Create-Job) request:
Operational Attributes:
"job-name"
"ipp-attribute-fidelity"
Job Attributes:
any Job Template attribute
Document Content:
create operations response:
Job Attributes:
"job-name"
"job-state"
"job-state-reasons"
"job-state-message"
Unsupported Attributes:
any unsupported attributes and any unsupported attribute values
Get-Attributes operation request:
Operational Attributes:
"requested-attributes"
"document-format" - Printer query only
Get-Attributes operation response for a Job:
Job Attributes:
the requested attributes that are supported
Get-Attributes operation response for a Printer:
Printer Attributes:
the requested attributes that are supported
Get-Jobs operation request:
Operation Attributes:
"limit"
"requested-attributes"
Get-Jobs operation response:
Job Attributes:
job attributes grouped by job in any order
NOTE - The requester must request "job-uri" or "job-identifier" in order to
be able to reference any returned job in a subsequent operation. They are
not returned as operational attributes.
Send-Document operation request:
Operation Attributes:
"last-document"
Document Attributes: ISSUE: These are no longer present, correct?
Document Content:
Send-Document operation response:
Job attributes:
"job-name"
"job-state"
"job-state-reasons"
"job-state-mesage"
Unsupported attributes:
any unsupported attributes and any unsupported attribute values
Cancel-Job operation
Operation attributes:
"message"
Job attributes: ???
Status Message ???
List of issues raised:
1. For the Cancel-Job response, the Model document says "optional Status
Message". What attribute or attributes are these?
2. MAY a create operation store the "ipp-attribute-fidelity" attribute on
the Job object so that it can be queried later (or printed on a start
sheet). How can a user or a help desk explain what happened, if
"ipp-attribute-fidelity" cannot be stored? How can a knowledgable user
determine whether his desktop client submits jobs with
"ipp-attribute-fidelity" set to TRUE or FALSE, if the client doesn't expose
this to the user?
3. MAY a create (or Send-Document) opeation store the unsupported attributes
on the Job object for later query? How?
4. If a create operation implementation did store some of the operational
attributes in the Job object, they could be directly queried by name or
included in the "all" group.
NOTE - an exception is made for "job-name" which is part of the
"job-description" group as well as being an operational attribute and is
required to be stored.
5. If an implementation receives an operational attribute with an
unsupported value or receives an operational attribute that is not
supported, does the implementation ignore the attribute or reject the job?
6. If the answer is to reject the job, is that dependent on the value of the
"ipp-attribute-fidelity" attribute or not?
7. If the Printer MAY ignore the value, then maybe it shouldn't be in the
Operational Attributes section and should be moved to the Job Attributes
section?
8. How about future extensions that add operational attributes? Which
version number changes? What about backward compatibility?