The only thing that worries me a bit is the complexity of this when
the IPP Printer is on a server that is driving multiple physical printers.
If the physical printers have different capabilities in this regard (maybe
one senses languages A and B, another senses B and C, one has
not autosensing capability at all, and the last I can't tell. What does the
server report in this case?
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 08/21/97 07:53
ipp-owner @ pwg.org
08/20/97 04:25 PM
Please respond to ipp-owner at pwg.org @ internet
To: ipp @ pwg.org @ internet
cc: pmp @ pwg.org @ internet, jmp @ pwg.org @ internet
Subject: IPP> MOD - document-format-supported using MIME types and 'a
We had an IPP telecon today and discussed the issue of changing IPP from
using Printer MIB enums for document-format to using MIME-types.
Attending: Steve Zilles, Ira McDonald, Lee Farrell, Roger deBry, Tom Hastings
I took the action item to write up the discussion on this point.
A problem that Don brought up in the e-mail was that we would have
trouble registering a MIME-type for the Printer MIB langAutomatic enum:
-- Automatic PDL sensing. Automatic
-- sensing of the interpreter
-- language family by the printer
-- examining the document content.
-- Which actual interpreter language
-- families are sensed depends on
-- the printer implementation.
The solution that we came up with today for IPP is to add a
Printer attribute called: "document-formats-detected" (or
"document-formats-auto-sensed"?). This new IPP attribute solves two problems:
1. it would eliminate the need to register an equivalent langAutomatic
MIME type which would probably be refused
2. we make it clear to the client which of the document-formats-supported
can be auto-sensed. Some implementations support more document-formats
than can be automatically sensed. For example, some implementation support
PostScript, PJL, and some document format that cannot be reliabilbly sensed.
The "document-formats-detected" Printer attribute would be multi-valued
that parallels the "document-formats-supporter Printer attribute and
has a value for each of the values of the "document-formats-supported"
Printer attribute. Each value would be a keyword that indicates whether the
corresponding document format is auto-sensed or not. Perhaps, we can even
have more than two keyword values depending on the degree or reliability
that the PDL can be sensed. The keyword values might be:
or using the Printer MIB terminology of 'sense', insted of 'detect':
Alternatively, the same values could indicate whether the
client needs to supply the "document-format" attribute when submitting
each document or not, so that the following keyword values might be better
names for the corresponding semantics:
Job Monitoring MIB
The Job Monitoring MIB has both representations for document format, so
we'll certainly leave the Job Monitoring MIB with both Printer enum
We also discussed the suggestion from Munich that the Printer MIB
should add a new object to contain the MIME-type that corresponds to the
interpreter language. There was support for having BOTH the current
enum and the MIME-type and the both are useful. For example, the Printer
MIB still needs to indicate langAutomatic(37), since we would not be
adding the equivalent of the IPP "document-formats-detected" to the MIB.
For interpreter table entries that indicate langAutomatic(37), the
corresponding MIME-type name would be a zero-length string.
So we would reject the suggestion to make the prtInterpreterLangFamily object
obsolete. We even can give the above reason not to deprecate it.