I agree with Peter's suggested resolutions to ISSUE 03, but need to test our
understanding of the terminology, since I think that the spec needs to say
that "job-mandatory-attributes" is a REQUIRED attribute in the Document
Object spec, not OPTIONAL, in order to agree with Peter's suggestion.
Peter wrote:
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"
attribute?
<PZ>It should be an OPTIONAL Operation Attribute that a Printer MUST support
if the Printer supports the Document Object.</PZ>
When we say anything is "REQUIRED" in the Document Object spec, we mean it
is REQUIRED if the Printer conforms to the Document Object specification,
i.e., supports the Document Object. [This semantic for the word REQUIRED is
true for any IPP extension specification].
Here is what the Document Object spec says in the Conformance Terminology
section to try to make the scope of the term "REQUIRED" clear:
2.1 Conformance Terminology
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance as
defined in RFC 2119 [rfc2119] and [rfc2911] section 12.1. If an
implementation supports the extension defined in this document, then these
terms apply; otherwise, they do not. These terms define conformance to this
document (and [rfc2911]) only; they do not affect conformance to other
documents, unless explicitly stated otherwise. To be more specific:
REQUIRED - an adjective used to indicate that a conforming IPP Printer
implementation MUST support the indicated operation, object, attribute,
attribute value, status code, or out-of-band value in requests and
responses. See [rfc2911] "Appendix A - Terminology for a definition of
"support". Since support of this entire Document Object specification is
OPTIONAL for conformance to IPP/1.1, the use of the term REQUIRED in this
document means "REQUIRED if this OPTIONAL Document Object specification is
implemented".
RECOMMENDED - an adjective used to indicate that a conforming IPP Printer
implementation is recommended to support the indicated operation, object,
attribute, attribute value, status code, or out-of-band value in requests
and responses. Since support of this entire Document Object specification
is OPTIONAL for conformance to IPP/1.1, the use of the term RECOMMENDED in
this document means "RECOMMENDED if this OPTIONAL Document Object
specification is implemented".
OPTIONAL - an adjective used to indicate that a conforming IPP Printer
implementation MAY, but is NOT REQUIRED to, support the indicated operation,
object, attribute, attribute value, status code, or out-of-band value in
requests and responses.
It has been suggested (and I put in the proposed PWG Template) that it is
not good to repeat the definitions of terms that appear in other
specifications, since the definition may inadvertantly be changed. Also we
don't need to use the term "NEED NOT" which [rfc2911] introduces and
explains in section 12.1. So I'll recast the 5 uses of NEED NOT to be MAY
in the next version.
So how about this much shorter explanation for the Document Object section
2.1 Conformance Terminology:
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
MAY, and OPTIONAL, have special meaning relating to conformance as defined
in RFC 2119 [rfc2119]. If an implementation supports the extension defined
in this document, then these terms apply; otherwise, they do not. These
terms define conformance to this document (and [rfc2911]) only; they do not
affect conformance to other documents, unless explicitly stated otherwise.
For example, the term REQUIRED in this document means "REQUIRED if this
OPTIONAL Document Object specification is implemented".
Comments?
Tom
-----Original Message-----
From: Zehler, Peter
Sent: Tuesday, March 18, 2003 06:52
To: Hastings, Tom N; sm at pwg.org
Subject: My response to some of the 18 Document issues...Comments?
All,
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?
Pete
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
CreateJob-Document
or Create-Printer-Job.</PZ>
ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support
it, since PSI is using it?
<PZ>Yes</>
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"
attribute?
<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
without "document-overrides"?
<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
attribute?
<PZ>Yes</>
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?
<PZ>No opinion</>
ISSUE: 09: How can a Printer indicate which combinations of
document-creator-application-name (name(MAX)),
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
support?
<PZ>Yes</>
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
format.
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"?
<PZ>No opinion</>
ISSUE 13: The definition of "document-natural-language" in [rfc2911]
§3.2.1.1 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.
<PZ>OK</>
ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx
in the IANA Registration of Document Template attributes.
<PZ>OK</>
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.
<PZ>OK</>
ISSUE 17: TBD - Need to list the keyword attribute values in the IANA
Registration section. Do so by reference to the values registered for
corresponding attributes.
<PZ>OK</>
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler at crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701
<snip>
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf
<snip>
Send any comments to the SM mailing list.
Thanks,
Tom