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
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 08/21/97 07:53
AM ---------------------------
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:
langAutomatic(37),
-- 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:
'auto-detected'
'auto-detectedd-best-effort'
'not-auto-detected'
or using the Printer MIB terminology of 'sense', insted of 'detect':
'auto-sensed'
'auto-sensed-best-effort'
'not-auto-sensed'
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:
'document-format-not-required'
'document-format-recommended'
'document-format-required'
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
and MIME-type.
Printer MIB
-----------
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.
Comments?
Tom