My comments below marked by <dmc> </dmc>.
A couple overall comments:
1) It seems like the Document object spec is becoming a grab-bag for all
the ideas we come up with, whether they make sense as part of the Document
object or not--the spec risks becoming a "Here's a bunch of things that we
thought of that would make IPP cooler" spec.
2) I don't like the argument that we should not have OPTIONAL things in the
Document object spec. Here are some reasons:
- Even if we did what was proposed below, there would still be many, many
OPTIONALs in the spec. If we really believe in our argument, those should
all be REQUIRED, right? No? Why not? Oh, so there *is* a line between
what should be OPTIONAL and what should be REQUIRED? Well, if there *is* a
line, that sort of invalidates our argument that there shouldn't be any
OPTIONALs.
- The Document object spec has become more than just an extension. I think
it is seriously rivaling RFC2911 in term of complexity (not in pages, but
in complexity, with all those tables for example). This is NOT a
criticism--having a Document object is a good idea and this spec is a very
good one. But once a spec gets as complex as this one, it is unreasonable
to consider it as just an extension that can have the "luxury" of not
having any OPTIONALs.
Dennis Carney
IBM Printing Systems
--------------------------------------------------
1. Change the Send-URI operation and the corresponding
"reference-uri-schemes-supported" (1setOf uriScheme) Printer Description
attribute from OPTIONAL to REQUIRED for a Printer to support. We agreed
that a conforming implementation MAY have an empty list for the
"reference-uri-schemes-supported" Printer Description attribute.
Reason: PSI requires this operation (and has no OPTIONAL attributes).
Optional operations are much less likely to get support by clients. It is
best practice for an OPTIONAL extension specification (such as this spec)
to
have no OPTIONAL operations, so that user clients will receive the same
level of service from all Printer implementations that support this
extension.
<dmc>
PSI and IPP are different. Look at the PSI "Use Cases" from the Developers
Guide--there are no "Joe is at his desk and wants to print to the printer
down the hall" use cases. That's not the point of PSI. PSI is very
web-oriented, and as such, it makes sense to print by reference. With IPP,
printing by reference is really not mainline, so it should be optional.
And what does Send-URI have to do with the document object? Ok, it is a
way to send a document, but the Document object spec should describe the
Document object, NOT try to redefine the way IPP works, imho.
</dmc>
2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED
for a Printer to support.
Reason: This is the Document object spec and users should be able to modify
a Document object after the job is submitted. Optional operations are much
less likely to get support by users clients. It is best practice for an
OPTIONAL extension specification (such as this spec) to have no OPTIONAL
operations, so that user clients will receive the same level of service
from
all Printer implementations that support this extension.
<dmc>
It seems to have been a long-standing tradition in IPP that the ability to
do "Set"s is optional. I don't see why this should change now. What is so
special about Set-Document-Attributes? Why aren't we mandating the other
"Set" operations as well while we're at it?
</dmc>
3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED for
a Printer to support.
Reason: To go along with the change in the conformance requirements for the
Set-Document-Attributes operation. However, don't REQUIRE
Set-Job-Attributes, since most of the interesting attributes are document
attributes, not job attributes.
<dmc>
I have less problem here since we aren't going to REQUIRED, but my last
comment is valid here as well.
</dmc>
4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for the
"pdl-overrides-supported" Printer Description attribute (REQUIRED in
[rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted'
values. Also add a REQUIRED "pdl-override-attributes-guaranteed" (1setOf
type2 keyword) Printer Description attribute. The values indicate those
Job
Template and Document Template attributes for which the Printer guarrantees
success in overriding the corresponding instruction in the PDL data. The
values of this attribute returned in the Get-Printer-Attributes response
MAY
be colored by the "document-format" operation attribute supplied by the
client in the request, if the Printer's guarrantee depends on the document
format. A conforming Printer MAY return 'none' as the value.
Reason: The IPPFAX needs the ability for the Printer to indicate which Job
Template and Document Template attributes the Printer is able to guarantee
success in overriding the PDL. Waiting for the Production Printing Set2
[ippsave] to be updated does meet the schedule for IPPFAX which is also
trying to go out to last call. Also this extension is analoguous to our
addition of "job-mandatory-attributes" to give a finer granularity to
"ipp-attribute-fidelity" (boolean) operation attribute.
<dmc>
The 'guaranteed' value: So you are only listing this value that already
exists in another spec in the interest of trying to get the value to be
"official" as quick as possible? I guess I can't argue with that, but it
does seem a bit strange to me. I guess [ippsave] is going to be updated to
refer to the Document object spec rather than define this new value?
The "pdl-override-attributes-guaranteed" attribute: I agree that this was a
shortcoming of IPP--the printer had no ability to say which attributes it
could override and which it couldn't. I wonder about its applicability to
the Document object, but...
</dmc>