The following people attended the telecon to review the issues in the
document and those raised on the DL. This mail note accumulates all of the
issues and summarizes the agreements reached so far. We only got through
issues 1-3.
Comments.
1. Need a better title than "Set operations". Its confused with the "Set2
operations" and "Set3 operations".
2. The file name shouldn't differ from other file names by just a single
letter.
3. The operation attributes and Printer Description attributes should be
move after the Set-Printer-Attributes and Set-Job-Attributes descriptions,
so that the meat of the spec comes first, not after 13 pages.
> ISSUE 01 - Is there a better way to model the Printer attributes that
> depend on the interpreter (that is still compatible with IPP/1.1)? It
> should be clear to the operator whether the Set-Printer-Attributes
> operation is affecting all interpreters or just the one specified by the
> "document-format" operation attribute (or its default)? There have been
> suggestions to have "xxx-exceptions" (collection) Printer Description
> attributes where "xxx" is the document-format that indicate for each
> interpreter explicitly which Printer attributes are specialized for it.
> For example: "application-postscript-exceptions" (collection) and
> "application-vnd-hp-pcl-exceptions (collection). Or have a
> "set-all-interpreters" (boolean) Set-Printer-Attributes operation
> attribute that sets all interpreters.
We agreed to keep the idea of interpreter object, but not call it an object,
since it isn't a target of any operations. The name
"document-format-varying" Printer attributes will be used instead.
We also agreed to add one Printer Description attributes:
"document-format-varying-attributes" (1setOf type2 keyword) to list those
Printer attributes ("xxx-supported", "xxx-default", etc) that can vary for
different document formats.
We agreed to add one operation attribute to the Set-Printer-Attributes
operation:
"document-format-varying-scope" (type2 keyword) with values:
'all-document-formats'
'single-document-format'
The client can all supply attributes that are shared for all document
formats in the request. It is up to the client to help the administrator
know which attributes can vary by document-format and which are shared by
all document formats.
The client MUST supply this operation attribute. We could not agree on the
default behavior if the client omits the attribute, so the Printer MUST
reject the request and return 'bad-request' error.
>> ISSUE 02 - Should the attribute names be modified (e.g., with a unique
> suffix) to identify them as "factory defaults"? At the IPP WG meeting,
> some individuals thought that this would make some of the factory default
> handling easier to specify/implement. Also, some of the attributes could
> be prefixed/suffixed to indicate that they are [only] applicable to
> specific document formats. Although preliminary discussion appears
> encouraging, the topic was deferred for more detailed examination.
We agreed to remove the "factory-defaults" operation attribute from the
Get-Printer-Attributes operation. Its name is confusing and this
functionality is only needed by system administrators, so should be in a
separate operation. It was pointed out that the word "support" in
"xxx-supported" should have been "xxx-policy" to clarify that the values are
the current policy, not the inherent support that the device possesses.
The working name for the new operation is something like:
Get-Printer-Settable-Values
It returns the values of queried attributes that the Printer will allow in
the Set-Printer-Attributes operation. Presumably a 'all' value can be
supplied.
Ron, Mike, Carl-Uno, Bob, Harry, will review a strawman version before
circulating it to the DL.
>> ISSUE 03 - While reviewing the Set-Printer-Attributes operation at the IPP
> WG meeting, it was suggested that a more general mechanism should be
> defined for handling and supporting side effects - such as modifying
> values of any related attributes.
We agreed that the validation of the Set-Printer-Attributes MUST be
performed on the entire result of the set, not one attribute at a time.
This make the validation like the Set-Job-Attributes operation.
We agreed that there MUST be no side effects of a Set-Printer-Attributes
operation. Either the client supplies ALL of the attributes that need to be
changed in a single Set, or the entire set is rejected, if there is some
constraint violation. For example, if the system administrator is
restricting supported values in an "xxx-supported" attribute, the
"xxx-default" MUST also be supplied, if the old value would no longer be in
the new "xxx-supported" list. Similarly, if an operation sets the
"media-ready" attribute to a value that is not in the "xxx-supported" list,
the Printer MUST reject it. Therefore, the operator has to supply both the
"media-ready" and the "media-supported", if a new medium is being loaded
that wasn't in the policy values in the "media-supported" attribute.
>> ISSUE 04 - How does a client indicate in a Set-Job-Attributes operation
> that a Job attribute is to be removed from the Job object? At the IPP WG
> meeting, there was general agreement that the protocol should support the
> ability to "unset" values.
>> ISSUE 05 - There is no need to be able to remove a particular attribute
> value from a (multi-valued) attribute, is there?
>> ISSUE 06 - Removing an attribute from a Printer is not needed, correct?
>> ISSUE 07 - Is it OK that Set-Job-Attributes validates independently from
> how the "ipp-attribute-fidelity" operation attribute had been supplied in
> the Job Creation operation? Its not currently stored with the Job object.
>> ISSUE 08 - For simplicity, is it OK that we don't have an
> "ipp-attribute-fidelity" operation attribute for the Set-Job-Attributes
> operation, so that the behavior is as if it were supplied with the 'true'
> value?
>> ISSUE 09 - Should Bob Herriot's Set-Printer-Attributes rules and
validation tables be added to the spec or to the Implementer's Guide:
The three page analysis is available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-validating-set-operations-000111.d
oc
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-validating-set-operations-000111.p
df
ISSUE 10 - There needs to be an attribute which specifies those attributes
which can have name values added to the xxx-supported attributes, e.g.
"attributes-with-names" and its value would contain a subset of the three
attributes names: "media", "job-hold-until" and "job-sheets".
ISSUE 11 - Should we add a new Printer Description attribute that specifies
the allowed values for "job-priority-supported", e.g.
"job-priority-supported-values(1setOf (integer(1:MAX) |
rangeOfInteger(1:MAX)))? Or should we simply REQUIRE that an implementation
that supports setting "job-priority-supported" also support any value from
1 to 100?
ISSUE 12 - Section 9.2.1 includes "attributes-natural-language" in the list
of Job
attributes that MUST NOT be settable. However, it seems useful and not hard
to implement, if a user's client sets the wrong natural language, that the
user could change it after job submission, so that messages would come in
the proper (supported) language). Ok to remove "attributes-natural-language
from
the list of Job attributes that MUST be READ-ONLY?
ISSUE 13: If a Printer supports the Set-Printer-Attributes operation, should
the new Get-Printer-Settable-Values operation (see Issue 02) be REQUIRED or
just RECOMMENDED?
ISSUE 14: Clarify READ-ONLY when only one value is settable
A Printer vendor is allowed to set an attribute to be read-only if an
attribute can have only one value for the life-time of the printer. But a
Printer vendor need not set such an attribute to be read-only. The
following are examples where read-only is not suitable:
The sides-default can only have the value "one-sided" because an admin
set
sides-supported to "one-sided" only.
The sides-supported attribute can only have the value "one-sided"
because the
duplexer has not yet been installed. But when it is installed,
side-supported
can also have the value "two-sided-long-edge".
It would be OK for "sides-supported" and "sides-default" to be read-only for
a Printer which a vendor never intends to sell a duplexer for. It would also
be OK for this Printer to have both of these attributes be writeable with
"one-sided" being the value, as specified by the factory setting of
"sides-supported".
>> ISSUE 15: Move "job-message-from-operator" and
"printer-message-from-operator" to
> another spec?
>
No, just move them to the end of this spec.
ISSUE 16: Should we remove the "printer-message-operation" from the spec?
It indicates which operation was used to set the
"printer-message-from-operator".
ISSUE 17: Should we remove the version example? Is the example incorrect?
The example is:
As another example, if the "ipp-versions-supported" Printer Description
attribute (see [ipp-mod] section 4.4.14) is settable in a particular
implementation, then changing its value with a Set-Printer-Attributes
operation MUST affect the protocol versions that are accepted or rejected.
Such an implementation will need to be able to reject values for versions
that it contains no code support for.
>> ISSUE 18: Remove one of the "attribute-scope" operation attribute values.
>Agreed to remove the last one and have only two values: one that sets only
one document-format-varying attribute and one that sets all
document-format-varying attribute. Either one can also set any attributes
that are common to all document-formats.
Please send any comments on these issues to the mailing list.
Thanks,
Tom