All,
I hope you all are reading the Document Object specification and preparing
for Thursday's teleconference. The Document Object specification we will
use for review is still:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip 1353 KB
Please forward any new issues or comments to the list. Below are my
opinions
on the 5 outstanding issues.
Pete
__________________________________________________________________________
ISSUE 1:
Since we agreed that this attribute isn't a hint, OK to make it
CONDITIONALLY REQUIRED for Printers that support charset-ambiguous document
formats?
<PZ>Yes</>
ISSUE 2:
If the Printer supports this "document-digital-signature" Operation
attribute and the value supplied by the client, the Printer MUST 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 or
(2) put the job on hold and wait for human intervention, 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?
<PZ>It should also be valid to abort the job. In any event the JobState
and JobStateReasons should give an indication to the client. I think we
will
need a new JobStateReason such as InvalidSignature. How does this apply to
documents within a job? Do we (1) ignore the signature and print the
document and job, (2) Put the job on hold and wait for human intervention
(and
what about partially printed jobs?) (3) abort the document and continue
printing the job (4) abort the document and job (once again what about
partially printed jobs. This would be cleaned up if we mandated that
document-signatures are evaluated at submission time. This may not be
practical given the latency involved in contacting the certificate
authority<PZ>
ISSUE 3:
This Printer behavior is backwards compatible with a Printer that doesn't
support the "digital-signature" attribute. However, if the Printer supports
the "job-mandatory-attributes" attribute (see section 8.1.2) and the client
supplies the "job-mandatory-attribute" Operation attribute with the
'digital-signature' keyword value, then the Printer MUST reject the job if
the "digital-signature" attribute is supplied with a value that isn't
supported by the Printer (or the Printer doesn't support the
"digital-signature" attribute at all). Thus the client can force the
Printer to reject a signed document for a signature technology that the
Printer does not support. 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'?
<PZ>The digital-signature should be treated as any other mandatory value
with an invalid value. The job should be rejected, Document-signature
and its value should be returned. This assumes the signature is evaluated
at submission time.<PZ>
ISSUE 4:
The values of the "document-format" and their corresponding
"document-format-version" values will be kept in a flat text file on the PWG
server for use by the PWG and CIP4. Implementers and implementations will
be able to access this file at any time (at CD writing time, install time,
vendor update time, and/or at power-up time, etc.). New values will be
added to the flat file by its Maintainer after sending to the PWG list for a
two week review whenever they are registered with or standardized by some
recognized body, such as IANA, CIP4, ISO, etc. ACTION ITEM (Tom): Get CIP4
buy-in to use the same flat file (which will require an additional field for
the JDF FileType attribute. ACTION ITEM (Tom and Ira): Propose a format for
the file. The URL is:
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?
<PZ>I never thought that schemas would be retrieved real time from printers
and print clients. I assumed that the namespace would indicate the schema
used. Clearly Printers would not need to access the schema since it already
knows what it has implemented and the instance document would be valid for
the schema. Print clients do not need to know all the possible semantic
elements and values. It only needs the elements and values for the target
Printer. The client would have built in support for the PWG schema to
validate a Printer's instance document against. That leaves a general
purpose web service client that will somehow be able to derive and present
the semantic meaning behind the PWG schema in a user friendly way. (yeah
there are a lot of those out there)<PZ>
ISSUE 5:
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.
<PZ>These seem most useful for transformation services such as a PSI Server.
Printers would probably try and describe the document formats they support
in the most generic way. A transformation service may want to be very
explicit about the source document formats it is able to transform into
printer ready formats.<PZ>
Tom
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler@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
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 10:41:38 EDT