All,
Comments on issues below.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler@crt.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, September 09, 2002 7:00 PM
To: ipp@pwg.org
Subject: IPP> DOC - IPP Document Object down-loaded, version 0.3
I've down loaded the next draft of the IPP Document Object, version 0.3:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-rev.pdf - 300Kb
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-rev.doc - 1.2Mb
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.pdf - 300Kb
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.doc - 1.2 Mb
<snip\>
ISSUE 1a: Do we need formal definitions of each Operation or is the
comparison with Job operations in Table 2 sufficient?
<PZ> I think an encoding section should be added for the operations <\PZ>
ISSUE 1b: Should Print-Job and Print-URI also be called Document Creation
operations since they create one Document object? The answer probably
depends on the answer to the following issue:
<PZ> Yes they should</PZ>
ISSUE 1c: We're adding a Document Attribute group (tag) to Send-Document
and Send-URI so that a client can supply Document Template attributes. OK
that we don't add this group to Print-Job and Print-URI? The problem with
adding the Document Template attribute group to Print-Job and Print-URI
requests is that there becomes two ways for a client to supply many of the
Job Template attributes that are Document Processing attributes, such as
"media", "number-up", etc., Those two ways in a Print-Job or Print-URI are
(1) in the Job Template attribute group or (2) in the Document Template
attribute group. The PWG Semantic Model is defining each Processing
attribute to be either a Job Processing attribute or a Document Processing
attribute, but not both, so that there will only be one way to submit each
Processing attribute in a PrintJob operation according to whether it is
defined to be a Job Processing Attribute or a Document Processing Attribute.
But for backward compatibility, IPP's Job Template attributes are a mixture
of Job and Document Processing attributes, i.e., "job-priority" and
"job-hold-until" versus "media" and "number-up" are passed mixed together in
the Job Template attribute group.
<PZ> I see no problem with adding the OPTIONAL Document Attribute group to
Print-Job and Print-URI. Clients and Printers that do not support will not
emit or gracefully ignore the group. Clients can determine if a Printer
supports the group by the "operations-supported" attribute or preferably by
a new minor version number (i.e. IPP 1.2). A Client that send both groups
to a Printer that supports them will first apply the Job Template attributes
and then override them with any applicable Document Attributes. The same
way it would if the job creation and document creation occurred separately.
</PZ>
ISSUE 1d: Agree that the Cancel-Current-Document, Delete-Document, and
Set-Document-Attributes operations are OPTIONAL and that the
Cancel-Document, Get-Document-Attributes, Get-Documents, and
Validate-Document operations are REQUIRED as indicated in Table 2 when
supporting the Document object?
<PZ>Agree</PZ>
ISSUE 1e: Currently the returns operation attributes are the same for Job
Creation and Document Creation responses. Should the "document-number" be
added as an additional OPTIONAL response attribute to the Document Creation
responses?
<PZ>The Printer MUST return and the Client SHOULD support </PZ>
According to [override], the "document-overrides" (collection) attribute MAY
be supplied by the client in a Send-Document or Send-URI request as an
Operation attribute to apply document overrides to this and/or subsequent
documents in the job. See the "document-overrides" Job Template attribute
in Table 5 for the listing of the member attributes. However, with the
introduction of the Document object, the "document-overrides" (collection)
attribute SHOULD NOT be used (either as a Job Template attribute or an
Operation attribute). Instead, the client simply supplies the Document
Template attributes (see Table 5) for each Document Creation request (in a
new Document Template attribute group) without needing a collection.
ISSUE 02: What do we want to do with the "document-overrides" collection
attributes when supporting the Document object, which is no longer needed as
either a Job Template, Document Template, or operation attribute in Document
Creation requests? Not completely true, since the "document-copies" member
attribute of the "document-overrides" attribute allows the client to supply
different attributes to different copies of a document. Has anyone
implemented Document Overrides?
<PZ>Deprecate "document-override". Recommend Printers that support the
Document object not support "document-override". The tails case of applying
different attributes to different copies of a document can be easily
accomplished through submitting, or referencing, the same document more than
once in the Job.</PZ>
Similarly, according to [override], the "page-overrides" (collection)
attribute MAY be supplied by the client in a Send-Document or Send-URI
request as an Operation attribute to apply page overrides to this and/or
subsequent documents in the job. See the "page-overrides" Job Template
attribute in Table 5 for the listing of the member attributes. However,
with the introduction of the Document object, the "page-overrides"
(collection) attribute SHOULD be more simply supplied as one of the Document
Template attributes for the document being created only.
ISSUE 03: What do we want to do with the "page-overrides" collection
attributes when supporting the Document object, which is still needed as a
Job Template and Document Template attribute for overriding attributes in
specified page ranges, but is not needed as an operation attribute on
Document Creation requests?
<PZ>Perhaps in deprecating PWG5100.4 we can add "page-overrides" to this
document. In any event "page-overrides" should not be passed as operational
attributes and only as a Job Template or Document Template attribute.</PZ>
ISSUE 04: Is this query behavior of not appearing to copying down supplied
Job attributes to the Document object and not bubbling up supplied Document
attributes to the Job object OK?
<PZ> Definitely OK </PZ>
ISSUE 05: Should we sort the attributes ignoring the [job-]? Currently the
"job-" is used in the sort for attributes.
<PZ> Sort using the full name. If you plan to use the attribute aliases
without the [job-] then the two entries should reference each other/<PZ>
ISSUE 06: How will we register these attributes with IANA, since they will
be registered for IPP use, with the "job-" prefix. Do we add the ones
without "job-" as aliases to the IANA registry as is done for charset
registrations?
<PZ>Yes</PZ>
ISSUE 07: Should we sort the attributes values including the [job-]?
Currently the "job-" is ignored in the sort for attribute values.
<PZ> Sort using the whole name</PZ>
ISSUE 08: How will we register these attribute values with IANA, since they
will be registered for IPP use, with the "job-" prefix. Do we add the ones
without "job-" as aliases to the IANA registry for as is done for charset
registrations?
<PZ>Yes</PZ>
ISSUE 09: What other Printer Description attributes are needed, if any?
<PZ>"ipp-versions-supported" should have a new allowed value. When the
Document Object gets approved the IPP version number should be bumped to
1.2.</PZ>
Thanks,
Tom
This archive was generated by hypermail 2b29 : Tue Sep 10 2002 - 08:03:22 EDT