Subject: PMP> MOD - document-format-supported using MIME types and 'automatic'

From: Tom Hastings <[email-masked]>
Date: 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

---

From: [email-masked]
Date: Thu, 21 Aug 1997 09:32:35 +0200

The langAutomatic doesn't have to be a MIME type, necessarily.

If you want to, you can define an "application/printable", but
just saying that it's legal to ship "application/octet-stream" to a
printer and let the printer figure out what to do with it would work
just as well.

In E-mail currently, application/octet-stream is used heavily to ship
documents in "let the recipient figure it out" mode.

                   Harald A