PMP Mail Archive: PMP> MOD - document-format-supported using MIME types and

PMP Mail Archive: PMP> MOD - document-format-supported using MIME types and

PMP> MOD - document-format-supported using MIME types and

Tom Hastings (hastings@cp10.es.xerox.com)
Wed, 20 Aug 1997 15:09:18 PDT

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