Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
I have been reviewing the 1.6 version of the model document piece by piece.
I am going to post comments as I go, since there seem to be a large number
of them.
This post will deal with sections 5.1 through 5.2.4.3.2
General comments: Reading through this section, it appears that there are many
attibutes that are optionally supported in the Printer, yet the conformance
statement
at the end of the document would lead one to believe that all attributes must be
supported. We need to work on conformance.
I like Scott's separate document on attributes, but I'd like to see possible
adornments
listed for each attribute and whether or not it is optional. This would help
with conformance.
There is no conformance statement on adornments.
line 771: I'd suggest that availability adornment be optional in the printer.
line 775: I agree with the propsal to remove this tag.
line 782: This section is very confusing. I don't understand the term "visible"
at all.
Why not get rid of the default tag and just list the default value first? What
does the last sentence
(lines 78607) mean?
line 788: Support for scheduling tag should be optional.
line 796: Support for the imbedded tag should be optional in both client and
printer.
I actually think this area is one of the more complex that we could get rid of
(at least in
version 1.0) and not lose significant value. It would not seem to be in the 80%
of
function that we want to hit with version 1.0. It also requires some significant
support in the client to set this tag.
line 799: We need to clearly spell out which attributes allow the best-effort
tag. The notion
of best-effort shouldn't apply in many cases. For example, would I reject a
print job
with no best effort tag when an invalid separator sheet is specificed? I think
some
appropriate default action would be preferred. Lines 806-810 suggest that
support
of this tag in clients is optional. This should be explicitly spelled out.
line 811: Take this out. Why would a client ever bother to set an attribute and
then
take the time to add a tag which says ignore it?
Line 838: All of following attributes do not exist in pairs. At least in the
following sections
there are examples (job-name) where this is the case.
line 848: This paragraph is a little confusing. What is meant by on a
page-by-page
basis? Wouldn't it just be simpler to list the attributes that can apply to
documents?
lines 856-857: This sentence (and detailed descritpions of the individual
attributes
suggests that support for all attributes is not required in the printer. This
seems to
conflict with the conformance statement at the end of the document.
line 859: Since the attribute group is jobTemplate, isn't jobNaming really a
sub-group?
What is the value of providing these subgroup names? Can they be used anyplace,
for example
in getAttributes operation? If so, then this should be spelled out someplace.
If not, then
I don't see any value in applying a name to them.
line 860: What is the value in providing this job-name? Where is it used? If it
has a
place where we see it being used very often then we ought to say where it is,
otherwise why have it? To be consistent with the rest of this section, there
should
be a heading for As a Job Attribute and one for As a Printer Attribute.
line 870: I'm concerned that we've provided no way for an installation to add
values
to attributes, at least type3enum says this is for implementation extensions.
Yet, I
think that separator sheet would be something to be defined on an installation
basis.
line 874: In the case of this attribute we've defined a different way to
specify default
from the normal method which uses the default tag. This is probably a semantic
problem. Maybe we should label "default-sheet" as "stanard-installation-sheet".
Otherwise it seems strange to use the default tag on "none" to say that the
default
sheet is not the default.
line 876-877: This is a case where best-effort doesn't seem to make sense. I
doubt
that we really want to reject a job on the basis of an unsupported job sheet.
It would
be better to always print the standard-installation-sheet.
line 882: The printer should optionally identify the state of readiness of each
job-sheet.
Readiness should be an optionally supported tag.
lines 884-885: This last sentence looks like it belongs in section 5.2.2.1.1.
line 898: Why isn't "none" a standard value? Then there is a consistent way
of parsing the values.
line 913: What does state of readiness mean for notification events? Is there
any
value in providing this tag?
line 916: Is it the case for all jobTemplate attributes that if they are
unspecified as
a printer attribute then the printer does not support the function? A sentence
should
be added here which says "If this attribute is not supported in the printer and
is specified in a print request, it is ignored."
line 928: Should add the words "Not supported as a printer attribute".
lines 932-933: same issues on the function of subgroups.
line 944: Shouldn't ommssion of the attribute indicate that the default priority
is assigned? Wouldn't this be consistent with other unspecified attributes?
line 948: Isn't operator privilege level out of scope for v1.0?
line 950: Should add a sentence that says if the priority attribute is not
supported
in the printer but is specified in a print request, it is ignored.
line 951: I have made this comment before, and it is similar to the case for
job-sheets.
I am concerned that we do not allow administrators to specify values for this
attribute.
Why do we suppose that we as the designers of the protocol, or even
implementors,
know what every installation is going to want as a valid time periods here?
line 967: what does state of readiness mean for this attribute?
line969: add a sentence that says if the attribute is not supported in the
printer but
is specified in the print job, then it is ignored.
line 971: I think that the UI MUST convert from hours and minutes to seconds.
line 980: Wouldn't it be sufficient to specify the max job-retention period?
Why a
range?
line 982: add a sentence that says if this attribute is not supported in the
printer but is
specified in a print job, then it is ignored.
More to come later .................