I saw many of the issues as "low hanging fruit". I have my responses to
issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on
and issues 14 to 17 are basically work to be done. This leaves issues 9 and
11. These involve how to represent the supported values for the document
format detail attributes. I think we will need to dedicate a large chunk of
time for this issue in Thursday's teleconference.
Are there any comments on these issues or my responses?
ISSUE 00: Or should we just delete "input-document-number" operation
attribute when we republish pwg5100.4 without "document-overrides?
<PZ>Delete "input-document-number". Document numbers start at 1 and
monotonically increment as documents are added to the Job.</PZ>
ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the
object on which it operates?
<PZ>No, keep it Send-Data. I see no reason for the longer name. The only
data we send is associated with a Document. We don't have
ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support
it, since PSI is using it?
ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute
for a Printer to support (if it supports the Document object)? Otherwise,
clients won't support it and will be stuck with the "ipp-attribute-fidelity"
<PZ>It should be an OPTIONAL Operation Attribute that a Printer MUST support
if the Printer supports the Document Object.</PZ>
ISSUE 04: The "document-overrides" attribute is also useful in combination
with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the
Input Page stream concatenated across the Input Documents into separate
Output Documents. For example, making every 10 Input Pages be a separate
Output Document but the client only wants to staple the first Output
Document. ISSUE 04: But what about Subset Finishing? Can we it be done
<PZ>Get rid of "document-overrides" in favor of the Document. Place the
burden of the example corner case on the Client. The results can be easily
achieved through the use of Documents and page-overrides.</PZ>
ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE
the Printer to continue to support the "page-overrides" as an operation
attribute in Send-Document and Send-URI as well as a Document Template
ISSUE 06: OK that "document-container-summary" is only one level deep?
<PZ>Yes, this information is not a manifest of the contained documents.
It is used to determine if a Printer can process the Document. Clients
are free to send individual compressed Documents if a manifest of a Job's
contents is required.</PZ>
ISSUE 07: Is the description of "document-container-summary" attribute OK?
<PZ>Clarify that a manifest can be accomplished by the Client sending
individually compressed Documents.</PZ>
ISSUE 08: Are the conformance requirements for the
"document-container-summary" attributes OK?
ISSUE: 09: How can a Printer indicate which combinations of
document-creator-application-version (text(127)), document-creator-os-name
(name(40)), document-creator-os-version (text(40)),
document-format-device-id (text(127)), document-format-version (text(127),
document-format (mimeMediaType) and "document-natural-language
(naturalLanguage) are supported?
ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to
ISSUE: 11: The problem with separating "document-format" and
"document-format-version" is how can a Printer describe what versions are
supported, since the versions have to be associated with the document
ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X.
ISSUE 12: Or should the official ISO standard number, part number and date,
be used instead, e.g., "ISO nnnnn.n-2001"?
ISSUE 13: The definition of "document-natural-language" in [rfc2911]
§18.104.22.168 and [pwg5100.4] §5.1.7 is single-valued. OK that this Document
Description attribute isn't 1setOf? Or should we extend
"document-natural-language" to 1setOf naturalLanguage) and keep the same
name? Or change the name to "document-natural-languages"?
<PZ>Keep single-valued. It will handle the vast majority of cases and
keep things simple</PZ>
ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table
14 that go with the Document Template attributes.
ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx
in the IANA Registration of Document Template attributes.
ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx
in the IANA Registration of Job Template attributes being defined.
ISSUE 17: TBD - Need to list the keyword attribute values in the IANA
Registration section. Do so by reference to the values registered for
Xerox Architecture Center
Email: PZehler at crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
800 Phillips Rd.
Webster NY, 14580-9701
Send any comments to the SM mailing list.