SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)"

SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)"

SM> Dead-on-arrival proposal from "IPP Document Object Spec available for Thursday, April 10, SM Telecon, 10-11 PDT (1-2 EDT)"

don at lexmark.com don at lexmark.com
Wed Apr 9 16:07:59 EDT 2003


In regards to issue 4 and some background preceding it:

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

I CANNOT SUPPORT USING THE PWG SERVER BY ANYTHING OTHER THAN HUMAN
BEINGS!!!!!

Any proposal that endorses or proposes access by machines "at install time"
or "at power-up time" is simply not workable unless some other company
wants to support what will become multiple machines with giant bandwidth
pipes to the internet to support millions of printers and other devices.

I suggest you find another solution.

*******************************************
Don Wright                 don at lexmark.com

Chair,  IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright at ieee.org / f.wright at computer.org

Director, Alliances and Standards
Lexmark International
740 New Circle Rd C14/082-3
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
*******************************************



---------------------- Forwarded by Don Wright/Lex/Lexmark on 04/09/2003
04:01 PM ---------------------------

"Hastings, Tom N" <hastings at cp10.es.xerox.com>@pwg.org on 04/09/2003
07:54:04 AM

Sent by:    owner-ps at pwg.org


To:    sm at pwg.org
cc:    ps at pwg.org
Subject:    PS> IPP Document Object Spec available for Thursday, April 10,
       SM Tel     econ, 10-11 PDT (1-2 EDT)


I've finished the editing on the IPP Document Object Spec and have down
loaded it to:

ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip   1353
KB
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.doc.zip   326 KB

This will be reviewed on Thursday, April 10, SM Telecon, 10-11 PDT (1-2
EDT).

Sorry for the short notice, but the editing took way more time than I
thought.

Version 0.9, 7 April 2003, agreements from the April 3 telecon:
 1.   Added "document-charset" (charset),
"document-digital-signature" (type2 keyword), "document-format-version"
(text(127)), and "document-natural-language" (naturalLanguage) Operation
and
Document Description attributes and corresponding "xxx-default" and
"xxx-supported" Printer Description attributes.
 2.   Changed the "document-natural-language" member attribute of
"document-format-details" (1setOf collection) operation attribute to be
1setOf, but kept the top level "document-natural-language" Operation
attribute as single-valued.
 3.   Added Summary Table 2 of new Operation/Document Description
attributes.
 4.   Defined CONDITIONALLY REQUIRED and CMUST Conformance Terms.
 5.   Deleted the "document-id-uri" Operation attribute no longer
needed by PSI.
 6.   Changed "ipp-attribute-fidelity" so it doesn't affect
operation attributes, so it is the same as in [RFC2911].
 7.   Clarified the operation attributes supplied at the Job Level
in Print-Job and Print-URI versus Create-Job by introducing the "p"
notation
in Table 7.
 8.   Added columns to  Table 7 to show the corresponding Document
Description attributes and the "xxx-default" and "xxx-supported" Printer
Description attributes.
 9.   Clarified that all of the new Operation attributes are
hints, except "document-charset" and "document-format" and that the client
can turn them into Must Honor by supplying their keyword attribute names in
the "job-mandatory-attributes Operation attribute.
 10.  Add the unique lang prefix from the Printer MIB to all
"document-format-version" values, so that they can all be in a single flat
list for the Printer's "document-format-version-supported" Printer
Description attribute.

There are four issues embedded in the document and a 5th from Dennis (see
below):

6.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?

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?

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

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?

and here is 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.

Tom







More information about the Sm mailing list