IPP> DOC - IPP Document Object down-loaded, version 0.3
Hastings, Tom N <hastings <at> cp10.es.xerox.com>
2002-09-09 22:59:33 GMT
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
I reformatted as a real IEEE-ISTO draft standard using the template that Ron
Bergman used for the Media Name Standard.
The PWG meeting agreed to process it on the IPP mailing list, rather than as
part of the Semantic Model or PSI work. The PWG Semantic Model will refer
to it for the details of the Document object semantics. Please send
comments to the IPP dl. Questions:
a. Should we have a teleconference in the coming weeks to discuss further?
b. Or do we need face to face time at the PWG meeting in November in New
Orleans?
c. Or both?
Please also send comments on the 15 issues that are in the document (see
below).
Most of the Document object attributes have corresponding Job attributes
approved in other IPP standard documents. And the 7 Document object
operations are analogous to the corresponding Job operations.
Here is the Abstract:
This IPP specification extends the IPP Model and Semantics [RFC2911] by
defining a Document object. The [RFC2911] Job object is extended to contain
one or more Document objects which are passive objects operated on by the
Job. The Document object is created by the [RFC2911] Send-Document and
Send-URI operations. The extension also adds a Document Attributes group
(and tag) to these requests which contains any Document Template attributes
to be applied to this Document object being created, overriding any
corresponding Job Template attribute supplied at the job level (including
the "document-overrides" operation attributes at the Job or Document level).
There are seven new operations defined for Documents once they have been
created: Cancel-Current-Document, Cancel-Document, Get-Document-Attributes,
Get-Documents, Delete-Document, Set-Document-Attributes, and
Validate-Document.
This specification also lists all of the attributes defined in other IPP
specifications to show their relationship to corresponding attributes
defined in this IPP specification for use with the Document object. The
full semantics of the "document-state" and "document-state-reasons" Document
Description attributes is given along side of the corresponding [RFC2911]
"job-state" and "job-state-reasons" Job Description attributes.
The purpose for specifying the Document object, is so that we can have a
common semantic specification for use in IPP, the PWG Semantic Model, the
PWG PSI project, and the Free Standards Group Job Ticket API which all have
a Document object.
Here is the change log:
18 Annex B: Change Log (informative)
Version 0.3, 9 September 2002:
1. Reformatted as an IEEE-ISTO standard and added the usual
sections for a standard.
2. Added "original-requesting-user-name" Operation attribute to
Table 3.
3. Added "y" to "output-bin" in Table 5 so it MAY be a Document
Template attribute.
4. Clarified the * and ** in Table 6 - Job and Document
Description attributes.
5. Added section 7 all of the Printer attributes defined In any
IPP standard.
6. Allocated operation-id enums in section 8 to the 7 Document
operations.
7. Added the conformance section 9
8. Completed the IANA Considerations section 12.
Here are the 15 issues. They weren't renumbered from the first draft sent
out just before the August meeting in Santa Fe.
ISSUE 1a: Do we need formal definitions of each Operation or is the
comparison with Job operations in Table 2 sufficient?
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:
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.
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?
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?
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?
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?
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?
ISSUE 05: Should we sort the attributes ignoring the [job-]? Currently the
"job-" is used in the sort for attributes.
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?
ISSUE 07: Should we sort the attributes values including the [job-]?
Currently the "job-" is ignored in the sort for attribute values.
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?
ISSUE 09: What other Printer Description attributes are needed, if any?
Thanks,
Tom
RSS Feed