IPP> IPP Phone Calls and MIME-type

IPP> IPP Phone Calls and MIME-type

IPP> IPP Phone Calls and MIME-type

don at lexmark.com don at lexmark.com
Sat Aug 23 16:43:09 EDT 1997


I see no reason to add MIME types to the MIB.  If we do our
job right, all the MIME types should map to a printer ENUM.
Since host system have infinite resources for all this trash ;>)
it shouldn't be any problem to correlate them there rather than
down in the printer agent.


Don


**********************************************
* Don Wright                 don at lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************






... stuff deleted ...


These reasons are relevant, but not strictly compelling, IMHO. Consider
the following proposal:
The Printer MIB retains the prtInterpreterLangFamily object and adds a
new object prtInterpreterLangFamilyMIMEtype. The use of the first
object is Deprecated, but not Obsoleted. The MIME-type registry is
updated to have all the types that are in the prtInterpreterLangFamily
enum registry. A new value is added to the prtInterpreterLangFamily enum
registry. This value stands for "There is no prtInterpreterLangFamily
enum assigned so use the prtInterpreterLangFamilyMIMEtype value
instead". (Note this could be a new value or it could be an action taken
when the "Unknown" value of the prtInterpreterLangFamily enum is seen.)
This allows future formats to be registered only in the MIME-type list
and to provide a way to tell a MIB client that it should use the
prtInterpreterLangFamilyMIMEtype value instead of the
prtInterpreterLangFamily value.
... more stuff deleted ...



More information about the Ipp mailing list