SM> My responses to existing issues and a reminder to be ready for Th ursday

SM> My responses to existing issues and a reminder to be ready for Th ursday

SM> My responses to existing issues and a reminder to be ready for Th ursday

Zehler, Peter PZehler at
Tue Apr 15 10:41:30 EDT 2003


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:   1353 KB

Please forward any new issues or comments to the list.  Below are my
on the 5 outstanding issues.


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

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
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
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

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>

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:  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>

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>


				Peter Zehler
				Xerox Architecture Center
				Email: PZehler at
				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

More information about the Sm mailing list