PMP> Closure on MIME vs. Enums

PMP> Closure on MIME vs. Enums

Bill Wagner bwagner at digprod.com
Thu Sep 4 13:19:40 EDT 1997


     Some hopefully not so random thoughts.
     
     Although I asked this question at the start of the MIME crisis, I have 
     seen no answer.  What is the use, purpose, advantage or significance 
     of a MIME type identification to a printer? I do not ask this 
     argumentatively, but because if there is a proper advantage, it should 
     be the justification for making printers MIME cognizant. If there is 
     no advantage, then there is no reason to include MIME type 
     understanding in the printers or in the MIB.
     
     If there is no purpose to using MIME to identify input types to 
     printers, why is it imperative that it is used in the IPP? Again, I 
     think that a reasonable statement of what purpose it serves is 
     desirable. The statement that it makes IPP compatible with faxes, 
     e-mail and whatever seems to be not germane because, as far as I 
     understand, IPP is intended to go to printers. The statement that our 
     area coordinators require it is, I believe doing them the disservice 
     of suggesting that they have no valid reason or are disinclined to 
     share it.
     
     I would protest Steve's suggestion that, 'if a printer has implemented 
     the Printer MIB and also IPP, that printer must recognize both MIME 
     and lang enums' by observing that the statement is not applicable in 
     many cases. The printer MIB is concerned with printer parameters and 
     the printer must do at least the instrumentation for the MIB. On the 
     other hand, IPP may (and in many cases will) be done by the NIC or by 
     some enhanced HTTP server ahead of the printer. (I believe one 
     contention was that it would be done by an NT system.)
     
     That, of course, suggests an answer the question of the MIME to Enum 
     conversion: if MIME types have no significance to printers other than  
     that they are necessary in IPP for other, unspecified non-printer 
     reasons, it should be the IPP server that does the conversion 
     (assuming that a simple conversion is possible... which is a different 
     issue that someone ought to consider).
     
     At any rate, I agree that modification of the printer MIB at this 
     point is not warrented.
     
     Bill Wagner, DPI/Osicom




______________________________ Reply Separator _________________________________
Subject: Re: PMP> Closure on MIME vs. Enums
Author:  Harry Lewis <harryl at us.ibm.com> at Internet
Date:    9/4/97 10:35 AM




I agree with Lloyd and Jay, in principle. I was at the IPP call yesterday and 
stated there should be no reason for IPP's choice of MIME representation of 
printer languages to impact Printer MIB. Use of enums is entrenched (and 
appropriate) in the MIB and double registry already exists (ex: PS - registered 
both as MIME and prtInterpreterLangFamily enum with IANA).
     
The real question is where does the mapping between MIME and enum occur. Here, 
you get into a debate over thin client vs. starved printer. This will not 
resolve due to the wide variety of platforms, printing system views and printer 
controller architectures our community represents.
     
The only reasonable rebuttal (to my initial premise, above) came from Steve 
Zilles who pointed out that, if a printer has implemented the Printer MIB and 
also IPP, that printer must recognize both MIME and lang enums. This fact (and 
burden) seems unavoidable, given the choice of MIME in IPP.  Still, one could 
question the usage model that requires MIME in the MIB vs. in the IPP code. I 
suppose it would alleviate a (very) simple mapping in the client, should they 
uses SNMP for auto-configuration to determine languages supported. This would 
seem like a fairly weak argument.
     
Just in case the prevailing forces (or our own consensus) leads us to include 
MIME in the Printer MIB, it would be nice to know how the IETF process would 
accommodate this. In other words, if we were to whip up a new, optional list of 
prtLangMIMEType, as suggested, would the IETF allow this to slip in without 
effecting the status and schedule of the Printer MIB?
     
In general, I think the greater harm may well be to IPP in that we have chosen 
to take a very communications and "host side" view when making decisions, 
failing to recognize the cost of storage in embedded devices... the very reason 
enums exist.
     
     
Harry Lewis
     
     
------ Forwarded by Harry Lewis on 09/04/97 07:59 AM ------
     
     
pmp-owner at pwg.org on 09/04/97 12:12:43 AM 
Please respond to pmp-owner at pwg.org @ internet 
To: lpyoung at lexmark.com @ internet
cc: pmp at pwg.org @ internet
Subject: Re: PMP> Closure on MIME vs. Enums
     
     
Excellent statement, Lloyd.  There is no real justification for the IPP effort 
to be impacting the Printer MIB effort, particularly with regard to the
issue of MIME types vs. enum definitions.
     
    ...jay
     
     
lpyoung at lexmark.com wrote:
     
> Evidently there is some opinion in the IPP working group that
> the Printer MIB is stalled with the IETF because of the MIME vs 
> enum discussion for interpreter types. I wanted to assure
> everyone within the PMP working group that as far as Chris and 
> I are concerned this is not the case at all. Chris and I are
> working on taking the Printer MIB as currently defined forward 
> to our Area Directors as a Draft Standard.
>
> >From the minutes of the last IPP conference call, an issue is 
> going to be raised against the Printer MIB in the Atlanta IPP 
> working group session to "keep the same Printer MIB registry, 
> do not deprecate it, add a new optional, printerLangMIMEType". 
> My position is and will be that the Printer MIB is closed and 
> moving forward on the standards track. I have not seen enough 
> justification to halt this process to add this new object.
> Regards,
> Lloyd
>
> ------------------------------------------------------------ 
> Lloyd Young                       Lexmark International, Inc. 
> Senior Program Manager            Dept. C14L/Bldg. 035-3
> Strategic Alliances               740 New Circle Road NW 
> internet: lpyoung at lexmark.com     Lexington, KY 40550
> Phone: (606) 232-5150             Fax: (606) 232-6740
     
     
     
     
     



More information about the Pmp mailing list