Three previous notes listed 4 significant, 2 significant, and 1 additional
conformance requirements to the IPP Document Object spec and called for
comments on them during the next two weeks, due Friday May 1.
As just announced, we're continuing the review of the IPP Document Object
spec, only on the ipp at pwg.org DL, and discontinuing cross-posting on the
sm at pwg.org and ps at pwg.org, so that people only receive one email message.
This mail note describes the other agreements we reached when reviewing the
IPP Document Object spec and its 9 issues at Thursday's April 17 telecon.
These are not significant enough to make a special call for comment.
However, if you do have comments on these agreements, please send any
comments on these agreements as well to the ipp at pwg.org DL. However, the
review next week Thursday, April 24, will be to continue the original spec
from Table 7, page 41, not a spec updated with these changes.
1. Abstract: Remove the REQUIRED and OPTIONAL from the Abstract
2. Abstract and Introduction: Move Get-Documents to the Job operations row.
3. Introduction: Mention the -actuals Document Description attributes.
4. Footnote 5 ISSUE: The corresponding PSI operation to Create-Document is
Send-Document-By-Push.
5. Page 13, Table 2: Remove the use of the term "Hint". These
Operation/Document Description attributes are not hints, since the Printer
MUST use them if supported.
6. Page 18, Create-Document, Clarify that the Notification Subscriptions
MUST be supplied only in Job Creation operations as specified in [ippntfy],
not in Document Creation operations.
7. Page 25, Move Get-Documents from the Document operations to the Job
operations section.
8. Page 35, Print-Job: add that Print-Job creates a single Document object.
Also clarify that the results of these two operations will be
indistinguishable from a Job created by a Create-Job where the client
supplied Job Template attributes, a Send-Document with no Document Template
attributes, and a Close-Job. In other words, a new client performing a
Get-Job-Attributes and a Get-Documents will see the same results from the
Job created with Print-Job as with a Job created with Create-Job,
Send-Document, and Close-Job provided that the Send-Document doesn't supply
any Document Temlate attributes. Also an old client performing just a
Get-Job-Attributes will see the same results from (1) an old Printer that
accepted the Print-Job, (2) a new Printer that accepted the Print-Job, and
(3) a new Printer that accepted the Create-Job, Send-Document, Close-Job.
However, if a new client supplies Document Temlate attributes on the
Send-Document, instead of the same attributes as Job Template attributes on
the Create-Job, then an old client will not see any of the Documenet
Template attributes when it performs the Get-Job-Attributes operation (since
the Printer does not "copy up" Document Template attributes to the Job Level
on a Get-Job-Attributes on a one document job). ISSUE: OK that the old
client doesn't see the Template attributes?
9. Page 35, Add the same discussion for Print-URI being indistinguishable
from a job created by Create-Job, Send-URI with no Document Template
attributes, and a Close-Job.
10. Page 36, Close-Job, change the MAY to SHOULD for the client to use,
instead of setting "last-document" boolean.
11. Page 36, Close-Job, add that request is rejected if the operation is
already closed with the 'client-error-not-possible' status code.
12. Pages 37-38, Move the Administrative operations (Purge-Jobs,
Cancel-Current-Job, Suspend-Current-Job, and Delete-Document), to a new
Administrative operations section.
13. Page 42, Table 7, Change from Landscape to Portrait, so that it can be
read on a 640 x 480 pixel screen. Remove the remaining four columns to make
it fit.
14. Page 42, Table 7, make a new column for Print-Job and Print-URI, rather
than using the "p" notation.
Resolutions of ISSUES:
15. 7.1.1 document-charset (charset)
ISSUE 01: Since we agreed that this attribute isn't a hint, OK to make it
CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document
formats? AGREED: Yes.
16. 7.1.1 document-digital-signature (type2 keyword)
If the Printer supports this attribute and the value supplied by the client,
the Printer MAY verify the signature according to the rule for that
signature format. If the signature does not verify, then the Printer MUST
either (1) ignore the signature (and MAY indicate on the printed output some
how) or (2) put the job on hold and wait for human intervention, or (3)
abort the job depending on implementation and/or site configuration? Need a
new "job-state-reasons" and "document-state-reasons", depending on
implementation. The Printer gives no additional indication to the client.
ISSUE 02: Is either (1) ignore the signature or (2) put the job on hold the
correct behavior for the Printer if the digital signature doesn't verify or
(3) abort the job depending on implementation and/or site configuration?
AGREED: Add the (3) choice to abort the job. Also need a new
"job-state-reasons" and "document-state-reasons":
'digital-signature-did-not-verify'.
17. ISSUE 03: What if the digital signature is supported, but the signature
fails verification by the Printer when "job-mandatory-attributes" identifies
'document-digital-signature'? Printer MUST support the technology and MUST
verify the signature during the processing of the document. AGREED:
Printer MUST abort the job. The client can resubmit without
"job-mandatory-attributes" if client wants to get the signature ignored.
18. ISSUE 05 from Dennis Carney:
- I brought this up on the call, but I'll mention it again, since I'm not
sure whether it was resolved. You sell a printer. You happen to have
found out that some specific thing goes wrong when a user uses Powerpoint
2000 on Windows NT 4.0, such that your printer always messes up the
printout. How do you specify this in document-format-details-implemented?
And a much simpler issue on these same lines: why would *anyone*, ever,
return any values for the document-creator-application-name-implemented or
document-creator-application-version-implemented member attributes--why
would anyone want to try to list all applications they support? Similarly
for the two "os" member attributes--I might know I don't provide special
drivers for Macintosh, but anyone using an LPR utility on Macintosh, with a
PDF file, *can* print to me from Macintosh. Even if there *were* some OSes
I wanted to say I don't support (which seems doubtful), I have to do this
by listing all *other* OSes? I guess in summary: I can see the use for the
5th-8th member attributes of document-format-details-implemented, but not
for the 1st-4th.
Agreed to add: Note: 1st four attributes are intended more for a document
transformation service which MAY be part of a Printer.
19. document-creator-application-name (name(MAX)) and
document-creator-application-version (text(127))
AGREED: To change the name to document-source-application-name (name(MAX))
and document-source-application-version (text(127))
20. ISSUE 06: Should document-source-application-version be for program
consumption, not human? Such a change would agree with the CIP4 JDF review
comments for the corresponding attribute. AGREED: OK The above description
would be changed as suggested.
21. ftp://ftp.pwg.org/pub/pwg/???.txt ISSUE 04: What should the URL be for
the flat file? What is the formatting conventions for the flat file. Is it
a PWG Schema of sorts? AGREED: The Printer doesn't bang on the list, but
the client might. How about CIP4 host the flat file? Or the PWG finds a
commercial enterprise to host it on a commercial web site. Put schemas
there too?
22. ISSUE 07: Clarify that Document Template attributes share the same
"xxx-default", "xxx-supported", and "xxx-ready" Printer attributes with the
corresponding Job Template attributes and so have the same supported,
default, and ready values. AGREED.
23. ISSUE 08: OK to add mention of the corresponding "xxx-actual" Document
Description attributes that a Printer MAY support and add a reference to the
[ippact] specification? AGREED.
24. ISSUE 09: Ok that the -actual concept is not applied to any
Operation/Document Description attributes, such as the new
"document-charset", "document-digital-signature", "document-format-details"
(it has "document-format-details-detected"), "document-format-version", and
"document-natural-language"? AGREED.
25. Add a 'guaranteed" value for "pdf-override-supported" and
"pdl-override-attributes-guaranteed" Printer Description here for IPPFAX.
Send any comments to the IPP DL only.
Thanks,
Tom