I agree with Don. The host is the appropriate place to map
prtInterpreterLangFamilyTC enums and MIME types.
Harry Lewis
----------- Forwarded by Harry Lewis/Boulder/IBM on 08/25/97 03:51 PM ----------
ipp-owner at pwg.org on 08/23/97 03:02:54 PM
Please respond to ipp-owner at pwg.org @ internet
To: szilles at Adobe.COM @ internet
cc: pmp at pwg.org @ internet, Ipp at pwg.org @ internet
Subject: Re: IPP> IPP Phone Calls and MIME-type
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 ...