Document object, Meeting Notes, Thursday, March 20, 2003
File: document-object-meeting-notes-20030320.doc
Attendees: Peter Zehler, Dennis Carney, Gail Songer, Ira McDonald, Bob
Tailor, Tom Hastings, Harry Lewis.
The notes are edited into Peter's response to the outstanding issues.
We resolved all of the issues on the telecon. See the notes below.
Please send any comments on these minutes now, so I can reflect in the
updated document.
[Editor's note: we changed the semantics of the "document-format-details"
operation attribute at the end of the telecon from the member attributes
being Must Honor to being Best Effort, but didn't revisit the name of the
corresponding "document-format-details-allowed" (1setOf collection) Printer
attribute. Since the Printer will allow other attributes and values (and
ignore them), the "-allowed" suffix is now mis-leading. So Ira and I
suggest that we change the suffix from "-allowed" to "-implemented". So
change "document-format-details-allowed" to
"document-format-details-implemented". OK? I've assumed this change in the
following notes.]
ACTION ITEM (Tom): Update and post the spec today or tomorrow.
ACTION ITEM (Pete): Update and post the Semantic Model to reflect the
agreements (probably Monday).
Hold a second one hour review, next Thursday, March 27, 2003, same time
(10:00 AM PST, 1:00 PM EST). Peter and Bob to setup the teleconference and
webex, respectively.
Tom
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>
AGREED.
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>
AGREED: to keep name as Send-Data
ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support
it, since PSI is using it?
<PZ>Yes</>
AGREED.
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>
AGREED: The Printer MUST support the "job-mandatory-attributes" operation
attribute, client MAY supply.
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>
AGREED: Subset finishing is how to staple ranges of pages that cover all of
a single document? Do subset finishing with "page-overrides", instead of
"document-overrides" (which is being deleted). One possibility is to use
"pages-per-subset" (1setOf integer) as one of the member attributes of the
"page-overrides" since "pages-per-subset" is a Job Template attribute that
applies to an Input Document. Tom to talk to Claudia Alimpich from IBM as
well, since the concept of subset finishing is also in the FSG Job Ticket
API.
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</>
AGREED: If a Printer supports "page-overrides":
a. the Printer MUST support both the "page-overrides" as (1) an operation
attribute (for backward compatibility and clients that don't support the
Document object) and (2) as a Document Template attribute in Send-Document
and Send-URI requests. The client MAY supply "page-overrides" as either a
Job Template attribute or an operation attribute in Send-Document and
Send-URI requests.
b. the Printer MUST support "page-overrides" as a Document Template
attribute, not as an operation attribute in Create-Document requests.
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>
AGREED: That is it OK to have only one level for the summary details
attribute that the Printer uses to accept or reject jobs.
6.1 Should have two separate attributes, one for summary details and one for
a "document-manifest" which has a separate entry for each file in a
container and needs to allow nesting to be expressed.
ACTION (Tom and Bob): Advocate two separate attributes with CIP4, rather
than defining one form that tries to do both.
6.2 We'll won't add the manifest attribute to IPP Document object at this
point.
6.3 Need a better word than container and a better word than summary.
Agreed to go back to "document-format-details" and clarify that it is
unordered and applies to a single document file as well as a container file
containing multiple files.
6.4 Move the top level operation/Document Description attributes (except
"document-format" which remains at both levels) back to be member attributes
of the "document-format-details" collection operation/Document Description
attribute. So the following Document Description attributes will be the
member attributes of the "document-format-details" operation/Document
Description attribute:
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 (mimeMediaType
document-format-device-id (text(127))
document-format-version (text(127)
document-natural-language (naturalLanguage)
6.5 Allow, but don't require, the client to supply one of the collection
values to describe the details about the top level container format
(application/zip and multipart/related) as well.
6.6 Add a "document-format-details-detected" Job Description attribute which
the Printer MAY support and fill in with detected values. Keep
"document-format-detected" as a separate Job Description attribute, so that
collections aren't required by a Printer that only wants to reflect the
document format detected.
6.7 The "document-format-details" will remain an operation attribute that
the Printer MUST copy to the corresponding Document Description attribute,
same as for the "document-format" operation/Document Description attribute.
6.8 Other Document Description attributes that the Printer detects/updates,
such as "k-octets", are a separate concept and aren't to be added to
"document-format-details" or "document-format-details-detected".
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>
AGREED.
ISSUE 08: Are the conformance requirements for the
"document-container-summary" attributes OK?
<PZ>No opinion</>
AGREED: A Printer MUST support the "document-format" and the
"document-format-version" member attributes, and MAY support any of the
other member attributes:
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-natural-language (naturalLanguage)
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?
AGREED:
9.1 Add a "document-format-details-supported" (1setOf type2 keyword) Printer
Description attribute which lists the member attributes of
"document-format-details" that the Printer supports. Values:
document-creator-application-name, document-creator-application-version,
document-creator-os-name, document-creator-os-version, document-format,
document-format-device-id, document-format-version, and
document-natural-language.
9.2 We won't define "xxx-supported" attributes that go with each of the
member attributes of "document-format-details", since the member attributes
are not orthogonal to each other. Instead, define a
"document-format-details-implemented" (1setOf collection) Printer
Description attribute whose member attributes show collections of values
that go together.
The member attributes of "document-format-details-implemented" are:
document-creator-application-name-implemented (1setOf name(MAX))
document-creator-application-version-implemented (1setOf text(127))
document-creator-os-name-implemented (1setOf name(40))
document-creator-os-version-implemented (1setOf text(40))
document-format-implemented (1setOf mimeMediaType
document-format-device-id-implemented (1setOf text(127))
document-format-version-implemented (1setOf text(127)
document-natural-language-implemented (1setOf naturalLanguage)
9.3 Except for "document-format", all other member attributes supplied by a
client are supplied as "hints", that is Best Effort (i.e., treat as if
fidelity is false), whether the Printer's
"document-format-details-implemented" Printer Description attribute has that
member attribute or not and whether or not the Printer's
"document-format-details-supported" has that keyword for that member
attribute. The "document-format" operation attribute and member attribute
of "document-format-details" remain as a Must Honor attribute (i.e., treat
as if fidelity is true and reject the job if the document-format isn't
supported).
9.4 Currently, "ipp-attribute-fidelity" and the new
"job-mandatory-attributes" do NOT apply to operation attributes, only to Job
Template attributes. However as an exception, "ipp-attribute-fidelity" and
the new "job-mandatory-attributes" will be defined to apply to the
"document-format-details" operation attribute and all its member attributes.
For example, the client can supply the following keyword value for the
"job-mandatory-attributes" attribute:
'document-format-details.document-format-os-name' indicating that the
Printer MUST honor the OS name or MUST reject the job. The
"document-format" member attribute (and operation attribute) will remain
forever mandatory (Must Honor) as in [RFC2911], independent of
"ipp-attribute-fidelity" and "job-mandatory-attributes".
Example of a single set of values for a Printer of
"document-format-details-implemented" (1setOf collection):
{{document-format=application/ps, document-format-version=1, 2, 3},
{document-format=application/ps, document-format-version=3,
document-natural-language=en, fr, de},
{document-format=application/vnd.hp-PCL, document-format-version=5e},
{document-format=application/msword, document-format-version=5.0, 6.0,
2000,
document-format-os-name=MACOS, WINDOWS}
}
Typically, there will only be one value for "document-format" in each
collection. However, there can be more than one occurrence of a collection
value with the same "document-format". See above example which has two
PostScript collection values.
ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to
support?
<PZ>Yes</>
AGREED: Printer MUST support the "document-format" and
"document-format-version" member attributes if it supports the
"document-format-details" collection attribute. The Printer MAY support
additional member attributes.
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.
AGREED: The "document-format-details-implemented" (1setOf collection)
Printer Description attribute describes which versions go with each document
format. See ISSUE
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</>
AGREED: Use examples as agreed in CIP4 from the ISO standard itself, such
as 'PDF/X-1:2001' and 'PDF/X-1a:2001' which are from the same ISO standard.
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>
AGREED: Clarify that the first language in the document is used as the
value.
ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table
14 that go with the Document Template attributes.
<PZ>OK</>
AGREED
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</>
AGREED
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</>
AGREED
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</>
AGREED
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