I have read through the comments posted by Tom, Bob, and Scott
and have the following comments:
In general, I think that the proposal is a good one, and I appreciate
the work done by Tom, Bob and Scott to clarify the handling of
operation attributes.
Section 2.2: Do we need to get to the level of detail suggested
in this paragraph in reporting errors? Why isn't it adequate to
simply say "syntax error"? Don't these errors fall into the same
category as paragraph 2.4, i.e. invalid length looks like a
development time error, not an end user run-time.
It seems that if code is buggy or there is a serious problem in
generating or parsing the request stream, that more than one
error of this type might occur. If we take this to its ultimate
conclusion, we could get carried away with a very sophisticated
error reporting scheme, listing all errors that coccured and where
in the request stream they occured. I don't think we want to do this,
so I'd just settle for "Syntax error" and leave it at that.
Sections 2.3 and 2.4: Same comments as above.
Section 2.5: The sentence "An unsupported attribute is either
one that is not in the Model document or that is in the Model document
but is not required to be supported" is troublesome. One could argue
from this sentence that a supported attribute is therefore one that is
in the Model document and mandatory. Clearly this is not true.
Aren't implemented optional attributes "supported"?
Doesn't supported have to do with what I implement, not what is
in the document? For example, I can implement my own attributes
as extensions to the standard, are these then unsupported according
to the rules stated here? Also, using the logic implied by the sentenc=
e
in 2.5, if I implement an optional attribute, even though it is in the =
model
document, it is unsupported. Is that what you mean?
Section 2.6: I'm somewhat concerned over the statement made in
this section that validation depends upon the specification of the
attribute. We ought to strive for a common rule, it would make
the model much cleaner and I would expect therefore the
processing would be simpler. Certainly there would be fewer
opportunities for misreading or misinterpreting the spec.
Section 4.1: What does the comment "after copies-collated-supported"
gets removed mean? I know Bob had argued against this in the past,
but we lose an important attribute of some devices if we take this out.=
Section 4.2: attributes-natural-languages seems to be the ONLY
attribute in this entire set that has a different rule. Why? I don't
understand the reasoning behind this. If the Printer supports
French only, and I send it English text attributes, is that okay?
on the other hand, job-name and document-name say that any
correct value is "supported", but that the server should reject
unsupported values. These two things seem contradictory. How
do I get an unsupported value to reject??? Why would this case
be different from attribute-natural-language which has the same
rule for defining which values are supported?
Section 4.3: Which-document-format attribute name does not
match the model document, which lists this simply as
document-format. If the client says "Give me the following printer
attributes for document-format=3DIPDS and the printer doesn't
support IPDS, why is the rule accept and ignore? What does
ignore mean - not respond? Send back the listed attributes for
some other (maybe the default) document-format? Either of these
would be incorrect as far as the client was concerned.
This comment applies to which-jobs and my-jobs as well. If I
say send me job attributes for "queued", which is not a valid
value, the paper suggests that the printer accept and ignore.
Again, what does this mean? Do I respond with "completed"
jobs instead? Not respond at all? Seems very strange to me!
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
=