Tom,
My new comments below, marked with <DMC></DMC>.
Dennis
"Hastings, Tom N"
<hastings@cp10.es To: Dennis Carney <dcarney@us.ibm.com>
.xerox.com> cc: sm@pwg.org
Sent by: Subject: RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1 [m y
owner-sm@pwg.org comments]
11/06/2002 06:40
PM
Dennis,
See my comments below (all supporting the -actual concept and just
clarifying what the Printer MUST and SHOULD return for different
situations).
Tom
-----Original Message-----
From: Dennis Carney [mailto:dcarney@us.ibm.com]
Sent: Thursday, October 31, 2002 16:04
To: Hastings, Tom N; sm@pwg.org
Subject: RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1
[m y comments]
Tom,
Thanks for bringing these up. In response to your 4 points:
1. I believe the "-actual" concept should be extended to Document Template
attributes. This means that for every Document Template attribute, there
is a corresponding "-actual" Document Description attribute that reports on
the actual value of that attribute for that document. The question of
which "-actual" attributes are Job Description attributes and which are
Document Description attributes, then, is answered in the Document Object
spec, in Table 6 (Draft 0.4). Of course, if we go with this proposal, I
need to make the extension of the concept to the Document Template
attributes clear in the "-actual" attributes document.
TH> Sounds good to extend to the Document object spec. I'll include in the
next update of the Document object spec, unless the SM face-to-face agrees
otherwise.
<DMC>We'll likely discuss this tomorrow.</DMC>
2. We came to a conclusion, I believe, on this in the teleconference today.
We decided that any design for how to make the actual value of the
"document-format" attribute available to the client would be discussed in
the Document Object spec. There will be no "document-format-actual"
attribute in the "-actual" attributes spec.
TH> So to the Document object spec, I'll add a "document-format-actual"
(documentFormat) as a Document Description attribute. Its clearly single
valued. And an implementation populates it with the value that is actually
detected by the Printer for that document. For the moment, we won't have a
corresponding "document-format-actual" Job Description attribute which
would
raise the question of whether to make it multi-valued or not.
I'll include in the next update of the Document object spec, unless the SM
face-to-face agrees otherwise.
<DMC>I guess I would have preferred you not use a name with suffix "
-actual", as it will naturally get confused with the attributes in the "
-actual" proposal. What about "document-format-detected"? </DMC>
3. I tried to cover this topic in section 3.2, which reads:
3.2 Relationship between "-actual" attributes and Job Template
attributes
A very important point about the new "-actual" attributes is that
support for them is not in any way tied to the support for the
corresponding Job Template attributes. For example, a Printer that does
not support PDL override will not support the "copies" Job Template
attribute either. However, that same Printer SHOULD support the
"copies-actual" attribute if the Printer knows how many copies printed
for a job.
Similarly, the "-actual" attribute's existence is not in any way tied to
the existence of the Job Template attribute on the job creation request.
Whether or not a number of copies was requested, the Printer SHOULD
report on how many copies actually printed if the value is known.
Does this satisfy you?
TH> Not quite. The confusion is caused by including PDL override (which I
assume you mean that the Printer supports "pdl-override" = 'attempted') in
the discussion. Whether or not a Printer supports PDL override, and
whether
not a Printer supports the "copies" Job Template attribute, just as long as
the Printer at least supports a copies instruction in the PDL, the Printer
SHOULD support "copies-actual". Also there is confusion about the support
of -actual attributes in general versus the support of a particular
"xxx-actual" attribute. And lets be clear that we are talking about
support
by the Printer.
How about replacing section 3.2 with:
A very important point about the Printer support of a particular
"xxx-actual" Job Description attribute is that such support is tied neither
(1) to the support for the corresponding "xxx" Job Template attributes nor
(2) whether the Printer attempts to override the PDL for that "xxx" Job
Template attribute (see "pdl-overrides" in [RFC2911 section 4.4.28). For
example, a Printer that does not support the "copies" Job Template
attribute, but does support a copies instruction in the PDL, SHOULD support
the "copies-actual" Job Description attribute in order to indicate the
actual number of copies produced by the Printer. Similarly, a Printer that
supports the "copies" Job Template attribute SHOULD support the
"copies-actual" Job Description attribute whether or not the Printer
attempts to override the copies instruction in the PDL data when the client
supplies the "copies" Job Template attribute. Some Printers MAY support
the
"copies" Job Template attribute and a PDL copies instruction resulting in
the product of the two values. Such an implementation SHOULD also support
the "copies-actual" Job Description attribute.
Or a much briefer equivalent would be:
A Printer SHOULD support a particular "xxx-actual" Job Description
attribute
if the Printer supports either the "xxx" Job Template attribute and/or a
corresponding instruction in the PDL. For Printers that support both,
support of the corresponding "xxx-actual" Job Description attribute SHOULD
be independent of whether or not the Printer attempts to override the PDL
for that Job Template attribute (see "pdl-overrides" in [RFC2911 section
4.4.28).
In fact, this second alternative could replace section 4, Conformance
Requirements (for printers) and simply delete section 3.2. Especially,
because Section 4 is only saying OPTIONAL, rather than RECOMMENDED, which
contradicts section 3.2.
<DMC>I think the important question is whether a printer knows a value or
not. If it does, it SHOULD externalize it using the "-actual" attribute.
If not, it shouldn't. It doesn't matter why 3 copies printed, whether it
was through the PDL, the "copies" attribute, because the printer ran out of
paper and the user canceled the job instead of getting more paper, or
whatever. So to some extent, we shouldn't have to even mention anything
that corresponds to the content of section 3.2. However, I *do* think
this issue will naturally come up--I mean, it was one of the questions you
had, right? People might see "copies-actual" and say, "Hey, I don't
support the "copies" attribute, so obviously I won't support this new
attribute." We need to make it clear the names and semantics of the new
attributes are derived from the old ones, but support for the new ones is
independent of support for the old ones.
So, would it make you happier if I just leave out a mention of pdl-override
in section 3.2, like:
3.2 Relationship between "-actual" attributes and Job Template
attributes
A very important point about the new "-actual" attributes is that
support for them is not in any way tied to the support for the
corresponding Job Template attributes. For example, a Printer that does
not support the "copies" Job Template attribute SHOULD nonetheless
support the "copies-actual" attribute if the Printer knows how many
copies printed for a job.
Similarly, the "-actual" attribute's existence is not in any way tied to
the existence of the Job Template attribute on the job creation request.
Whether or not a number of copies was requested, the Printer SHOULD
report on how many copies actually printed if the value is known.
</DMC>
4. I believe Printers should fill in the values as soon as they have some
strong confidence they know them. I do not believe that in general, the "
-default" attributes necessarily have a strong shot at being right. I feel
strongly that we should not make any rules except to say that the Printer
should not return a value unless it thinks that value is correct--this is
not a guarantee of correctness, but a guarantee that the Printer honestly
*thinks* it is correct. I know that if we went with your proposal, if I
wrote a monitoring app, I would be hesitant to use the value, since it
would too often result in me giving bad information to the user.
By the way, counting on 'pending' or 'pending-held' being the only states
where information is not "final" is wrong. Once a job starts processing,
it might take significant time before the Printer determines a final value.
I don't believe that an "-actual" value can be considered final until the
job enters a completion state (completed, canceled, or aborted), as I say
in section 3.1.
TH> I'm convinced that filling in with the "xxx-default" value would be
sufficiently mis-leading to not be a good idea BEFORE the Printer has
discovered that the PDL doesn't contain the corresponding instruction.
However, after the Printer has discovered that the PDL doesn't have the
instruction either, the Printer MUST populate the "xxx-actual" with its
"xxx-default" value. So the specification needs to say what the Printer
MUST return between the time the Printer receives a Job with an "xxx" Job
Template attribute omitted and when the Printer discovers that the PDL
either (1) has a value for the attribute or (2) does not have a value for
the attribute, so that the Printer sets the "xxx-actual" value from its
"xxx-default" value.
<DMC>The spec says, in section 3.3, to return the out-of-band 'unknown'
value when the value is not yet known.
By the way, your description above is only really valid for printers that
attempt pdl override.</DMC>
Dennis
"Hastings, Tom N"
<hastings@cp10.es To: sm@pwg.org, Dennis
Carney/Boulder/IBM@IBMUS
.xerox.com> cc: ipp@pwg.org
Subject: RE: SM> ACT - IPP
"-actual" attributes downloaded, version 0.1 [m y comments]
10/31/02 10:59 AM
Dennis,
Good concept and good writeup.
I have a few detailed issues/suggestions:
1. Interaction with Document objects
Another reason for more than one value at the job level might be that
different documents have different values.
On the other hand, for the Document object, won't we want to have -actual
for the Document Description attributes too? If so, which -actual
attributes would be Job Description attributes and which would be Document
Description? media-actual would be a Document Description attribute and
job-priority-actual would be a Job Description attribute.
2. Even though "document-format" isn't a Job Template (or a Document
Template) attribute, I think that for a file sniffing Printer, having a
"document-format-actual" (which has to be multi-valued since a
multi-document job could be sniffed to different values).
And for the Document object it would be a Document Description attribute.
3. A printer that doesn't support a Job Template attribute, say,
resolution,
but does in the PDL, could have a resolution-actual attribute, right? This
case needs to be indicated.
4. ISSUE: If a job is submitted with none or few Job Templates supplied,
does the Printer fill in the remaining -actual with its default value?
When? Can it supply the default values for these immediately, before it
has
processed the PDL? And then change the value if the PDL has a
specification
for that attribute? I suggest yes, and then clients know that -actual
values when the job is 'pending' or 'pending-held' are subject to change.
Tom
This archive was generated by hypermail 2b29 : Wed Nov 06 2002 - 22:26:51 EST