All,
One of our GSoC 2018 students is working on a test file for the subject candidate standard, which is a collection of optional operation and Job Template attributes. After doing a quick read-through this morning I'm very concerned about several aspects:
1. There is no rationale section with use cases, exceptions, or requirements, so it is hard to know what the focus of this specification is or why all of these attributes are being defined.
2. All attributes are OPTIONAL, except for a few REQUIRED ones that have been imported from other specifications (instead of simply referencing them).
3. The new Job-scope attributes ("job-copies", "job-cover-back", "job-cover-front", "job-finishings", and "job-finishings-col") seem unnecessary and confusing. And given that there is no real discussion or rationale for adding a third layer of job processing to IPP, how would one implement this?
4. The "ipp-attribute-fidelity" and "job-mandatory-attributes" operation attributes (that are checked at Job submission) are "promoted" to Job Description (what we'd now call Job Status) attributes, without a corresponding definition of the amended semantics for the corresponding Job Creation operations. (and ideally these should have been exposed as xxx-supplied attributes...)
5. "document-digital-signature (keyword)" only identifies that an embedded digital signature exists, which doesn't seem particularly useful information for the Printer.
6. "document-format-version (text)" is not useful since "text" is plain text and not a registered keyword.
7. "document-format-details (collection)" has problems - none of the identifying document-source-xxx member attributes uses keywords for the application or OS names, even though the OS names are coming from an IANA registry, and document-format-device-id is not something we want to use now. Plus, all of these contain unauthenticated PII.
8. The definition of the 'job-digital-signature-wait' value of "job-state-reasons" is confusing. Ordinarily we'd have a Printer wait for confirmation at the console and not because the job was submitted with an unsupported value (so what is the Printer waiting for?)
9. "document-format-details-default" makes no sense for any member attributes *except* document-format-xxx.
10. The conformance section is a mess.
At a minimum I propose we deprecate the following attributes and values:
- "document-digital-signature", "document-format-details", "document-format-version", "job-copies", "job-cover-back", "job-cover-front", "job-finishings", "job-finishings-col" and the corresponding xxx-actual, xxx-default, xxx-supplied, and xxx-supported attributes.
- The 'job-digital-signature-wait' value for "job-state-reasons"
I realize this guts about half of the content of this specification, but I don't see a way to "fix" the definitions or resolve the privacy/verification issues... Ideally we should do an errata update of 5100.7, but I know *I* don't have the bandwidth for that at the moment. And these days we'd just do an IPP Registration document since this is just a collection of OPTIONAL attributes and values being registered.
Thoughts?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer