I've stored version 0.6 of the IPP Document object on the PWG server at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc
which are the same as:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc
The version with revision marks is available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev
.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev
.doc
Version 0.6 contains the agreements reached at the last PWG face to face and
on the SM telecons.
Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just
posted.
The issues will be reviewed during the PWG Semantic Model face to face
meeting, Thursday, 23.
Is this specification ready for Last Call?
Here are 9 ISSUES:
ISSUE 01: It is the [override] specification the allowed these four
"compression", "document-format", "document-name", and
"document-natural-language" operation attributes to be supplied in the
Create-Job request. There needs to be a way for a client to query to see
what was submitted. Possible solutions:
a. OK to have the exception to the no copy down rule for these four which do
not have any corresponding Job Description attributes to hold them?
Otherwise, there would be no queriable record of what the client had
supplied when the client only supplies them in the Create-Job operation.
b. Or would it be better, simpler, and more consistent to define the four
corresponding Job Description attributes and have the Printer just copy the
operation attributes to them, like most other operation attributes?
c. Or should we forget the [override] extension and go back to the RFC2911
Create-Job definition (see [RFC2911] section 3.2.4) which does not allow
these four operation attributes to be submitted in the Create-Job, but
requires that the client supply them each time in each Send-Document and
Sent-URI operation, if the client wants to submit them at all. Then the
Printer just copies them to the corresponding Document Description
attributes and there is no inheritance problem between the Job and Document
level for these four attributes.
ISSUE 02: Should we DEPRECATE the use of the "document-overrides" operation
attribute in Send-Document and Send-URI when supporting this specification?
Or forbid?
ISSUE 03: Should we DEPRECATE the use of the "pages-overrides" operation
attribute in Send-Document and Send-URI when supporting this specification?
Or forbid?
ISSUE 04: Is the definition of "document-format-detail" OK?
ISSUE 05: Should we call this member attribute "os-type", instead of
"platform", in order to agree with the PWG Printer Installation Extension
(see draft-ietf-ipp-install-04.txt)?
ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when
supplied at the job level of a multi-document job depends on the value of
the "multiple-document-handling" Job Template attribute. For the
'single-document' and 'single-document-new-sheet' values, the pages are
numbered as a single set from 1 to n for the job as a whole. For the
'separate-documents-collated-copies' and
'separate-document-uncollated-copies' values, the pages are numbered from 1
to n for each document separately. ISSUE 06: This is a change from
[override], OK?
ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when
supplied at the job level of a multi-document job depends on the value of
the "multiple-document-handling" Job Template attribute. For the
'single-document' and 'single-document-new-sheet' values, the pages are
numbered as a single set from 1 to n for the job as a whole. For the
'separate-documents-collated-copies' and
'separate-document-uncollated-copies' values, the pages are numbered from 1
to n for each document separately. ISSUE 07: This is a change from
[override], OK?
ISSUE 08: Need to add "job-password" to [prod-print2] as a Job Description
attribute to go along with the Operation attribute with suitable security in
Get-Job-Attributes response in order to align with the PWG Semantic Model,
OK?
ISSUE 09: Need to add "job-password-encryption" to [prod-print2] as a Job
Description attribute to go along with the Operation attribute with suitable
security in Get-Job-Attributes response in order to align with the PWG
Semantic Model, OK?
Version 0.6, 13 January 2003, agreements from New Orleans October PWG
meeting and subsequent telecons:
1. Deleted the Cancel-Current-Document and Validate-Document
operations.
2. Deprecated the "input-document-number" operation attribute
from the Document Creation operations.
3. Deleted the "document-mandatory-attributes" operation
attribute to align with the PWG Semantic model. So both specifications have
only the "job-mandatory-attributes" operation attribute. The client can
only supply at the Job Level. The Document Level inherits from the Job
Level.
4. Increased "document-message" operation attribute length from
127 to MAX (1023) octets.
5. Clarified that "ipp-attribute-fidelity" and
"job-mandatory-attributes" can only be supplied at the Job Level; the
Document level inherits their values.
6. Added "ipp-attribute-fidelity" and
"job-mandatory-attributes" Job Description attributes.
7. Added the "media-size-name" as a member attribute of
"media-col" and as a separate Job Template attribute as used by UPnPv1 and
UPnPv2.
8. Added the "media-type" as a Job and Document Template
attribute on its own as used by UPnPv1 and UPnPv2 (as well as leaving it as
a member attribute of the "media-col" Job and Document Template attributes).
9. Renamed "document-printer-up-time" Document Description
attribute to simply "printer-up-time".
10. Added the following Job Description attributes:
"ipp-attribute-fidelity", and "job-mandatory-attributes".
11. Removed the following Document Description attributes:
"ipp-attribute-fidelity".
12. Added the following Document Description attributes:
"document-format-detail", "document-format-detected", "job-id",
"job-printer-uri", "job-uri", "output-device-assigned".
13. Defined all of the Document Description attributes, often with
references to other specifications, so that they appear in the table of
contents.
Send comments to the mailing list.
Thanks,
Tom
P.S. I'll not be attending the meeting.