My comments below, marked with <dmc></dmc>. (The comments are only on
items 3, 5, and 6.)
Dennis Carney
IBM Printing Systems
"Hastings, Tom N"
<hastings@cp10.es To: ipp@pwg.org
.xerox.com> cc:
Sent by: Subject: IPP> 6 agreements from the IPP Document Object Spec review, April 24, 2003
owner-ipp@pwg.org
04/25/03 05:49 PM
Attendees: Gail, Bob, Pete, Lee, Dave, Jerry T, Tom (did I miss anyone?)
We'll have one more page by page review next Thursday, May 1. PETER: OK?
Or do you want to look at the updated document (which isn't quite done)?
We reached the following agreements:
1. Add "document-format-version-detected" Job Description attribute to go
with "document-format-detected" and "document-format-details-detected" Job
Description attributes.
2. Remove the feature that "job-mandatory-attributes" can supply the
keyword
names for the 7 document Operation/Description attributes ("compression",
"document-charset", "document-digital-signature", "document-details",
"document-format", "document-format-version", and
"document-natural-language"). So none of these 7 document
Operation/Description attributes can be validated with Create-Job, because
none of them can be submitted with Create-Job. These 7 MUST be submitted
with Document Creation operations when they are supplied. All of these 7
document Operation/Description attributed can be supplied in a
Validate-Job.
However, the Printer will only reject Validate-Job for the two that
[rfc2911] REQUIRES: "document-format" and "compression". For the other 5
if
unsupported attributes or values are supplied, the Printer MUST return them
in the Unsupported Attributes response with a
'successful-ok-ignored-or-substituted-attributes' status code.
3. The comment that we need a way for a Printer to say it will accept any
value for a particular attribute was discussed, including adding a general
'any'. The problem with adding 'any' as a value of the "xxx-supported"
Printer attributes is that the Printer validation now needs a special case
check when comparing "xxx" attributes supplied by the client with
"xxx-supported Printer attribute. Also clients have to know that they
can't
display 'any' as a value and have to know that they can't send 'any' in the
request, even though the value is one of the values of the Printer's
"xxx-supported" attribute.
So we agreed that the way already defined in [pwg5100.3] section 6.1):
user-defined-values-supported (1setOf type2 keyword) Printer Description
attribute lists the Job Template (and Document Template) attributes that
the
Printer will accept any value. However, with the current definition, it
doesn't allow the Document Operation/Description attributes to be named.
So
there is no way for the Printer to say it will accept any "document-format"
value. However, the Printer MUST accept any other value of any of the
other
7 Document Operation/Description attributes. We also agreed that for the
SM
Schema it was preferable to indicate by some additional attribute that the
Printer would accept any value for an attribute, rather than introducing an
'any' value.
ISSUE: So we may still have an issue if there is a need for a Printer to
accept any document format. One solution would be to extend the
"user-defined-values-supported" to allow the "document-format" and
"compression" keyword attribute values.
<dmc>
What does it mean for a printer to accept any document-format/compression?
It will accept formats it has never heard of and attempt to print them
anyway, presumably without any "formatting" or decompression? Sort of like
equating any unknown document format to just 'text/plain'?
</dmc>
ISSUE: OK to extend "user-defined-values-supported" to include
'document-format' and 'compression' attribute values?
ISSUE: If we also allow the "user-defined-values-supported" to include
'document-format-details' and its member attributes, e.g.,
'document-format-details.document-source-application-version', then the
Printer can say that it implements "any" version. Doesn't this solve Bob
Taylor's truth in advertizing requirement? So a Printer that doesn't want
to bother clients with returning versions that aren't in its implemented
list, the Printer can include the
'document-format-details.document-source-application-version' value is the
Printer's "user-defined-values-supported".
4. Add '[job-]errors-detected' value to "job-state-reasons" and
"document-state-reasons", but do not add "[job-]errors-count" Job/Document
Description attribute. Knowing the number of errors isn't more helpful, to
just knowing that one or more errors occurred. Losing data is an error,
while substituing some other font is only a warning, since no infomration
was lost.
5. ISSUE: For a conversion service or a Print Service that converts the
document format, there isn't a way to indicate the desired final format and
there isn't a way to represent the current document format for a document
that is being converted, where the current format might be different from
either the supplied format or the desired format.
<dmc>
Maybe I just have to get my mind reset, but IPP as a conversion or Print
service? Isn't IPP tailored to *print*? Wouldn't we need (a bunch?) more
attributes detailing where the job/document was supposed to go when it had
been "converted"? I'm also wondering whether there would be (a bunch of?)
attributes/state-reasons that are either meaningless, whose meaning is
totally different, or whose meaning is unclear/ambiguous in the conversion
case. Do we *really* want to try to go there?
</dmc>
AGREED:
a. Add the following 2 attributes as Job Template/Document Template
attributes (but not to the "document-format-details" collection Operation
attribute):
"document-format-requested" and "document-format-version-requested" Job
Template/Document Template attribute, so that there are also
"document-format-requested-default" and
"document-format-version-requested-default" Printer attributes and also
"document-format-requested-supported" and
"document-format-version-requested-supported" Printer attributes. And
corresponding "document-format-requested-actual" and
"document-format-version-requested-actual" Job Description attributes.
b. Add the following pair to the READ-ONLY Document Description attributes:
"document-format-current" and "document-format-version-current" Document
Description attributes. The Printer sets these to the "document-format"
and
"document-format-version" supplied by the client and changes them as the
processing proceeds, eventually winding up with the values supplied in the
"document-format-requested" and "document-format-version-requested"
attributes.
6. Suggestion to move some of the Document object spec to a separate spec.
Proposals:
1. Separate operation and attributes into REQUIRED/CONDITIONALLY REQUIRE
versus OPTIONAL for a Printer to support.
2. Move out only those things which make sense to implement even when not
supporting the Document object:
A. "job-mandatory-attributes" Job Creation Operation attribute
B. "document-charset" Operation attr, "-default", "-supported"
C. "document-digital-signature" Operation attr, "-default", "-supported"
D. "document-format-details" Operation attr, "-default", "-supported",
"-implemented"
E. "document-format-version" Operation attr, "-default", "-supported"
(B-E would have coresponding Document Description attributes indefined only
in the Document Object spec, along with "compression", "document-format",
and "document-natural-language" Document Description attributes).
F. Close-Job operation
G. job-copies (integer(1:MAX)) Job Template attribute
H. job-cover-back (collection) Job Template attribute
I. job-cover-front (collection) Job Template attribute
J. job-finishings (1setOf type2 enum) Job Template attribute
K. job-finishings-col (1setOf collection) Job Template attribute
L. media-size-name (type3 keyword | name(MAX))
M. media-type (type3 keyword | name(MAX))
N. "ipp-attribute-fidelity" Job Description attribute
O. "job-mandatory-attributes" Operation/Job Descritoin attributes
P. "pdl-override-supported" new value 'guaranteed' (which is already in see
[ippsave] section 8.1)
AGREED: Move only G through M. Keep the rest in the IPP Document object
spec because they are related to Document objects, even though they might
be
useful when not supporting the Document object.
<dmc>
Unless I'm missing something, G-K are only already-existing Job Template
attributes that have been renamed with "job-" on the front. Why would
anyone want to implement these renames unless they were doing the Document
object?
And M is also already-existing, in 5100.3. What is new about it that we
would need a new spec?
</dmc>
Please comment on the IPP mailing list about any of these agreements.
Tom
This archive was generated by hypermail 2b29 : Mon Apr 28 2003 - 09:30:07 EDT