Harry,
Thank you for some of the history as to why the Printer MIB selected
enums rather than MIME types. However, I would argue that double
registration is not an acceptable solution. This will require an
embedded print server to support both enums and MIME types. It
would be best if we only had to deal with one form or the other.
My preference would certainly be enums!
I have listened to the argument for and against MIME types since the
start of the IPP effort. I am of the opinion that this is more of a
religious issue than a technical one. And like other religious
issues, will never be settled! So, unless the IETF will agree to
accept enums, we will be stuck with having to support both.
I also am disappointed that the IETF has announced the strong stand
against accepting the Job MIB as a Proposed Standard. The support
for this standard by printer vendors has indicated a real need for
this effort to progress. I believe that a Proposed Standard would
encourage the development of more applications that support the MIB
than if the MIB was an Informational RFC. I would like to obtain a
straw vote from the group on this topic.
To my understanding, the real objection from the IETF is that they
believe that the MIB is primarily intended for users. I do not
fully agree with this position. In small installations where peer-
to-peer printing is the norm, this is most likely to be true. In
large installations, where printing is directed through a server,
I expect that the server will be the central point of communications.
(This is configuration 3 in the Job MIB document.) SNMP would be
used between the server and the printer and the user would obtain
status using a new (e.g. IPP) or existing (e.g. lpd) protocol. It
should also be noted that usage of the Job MIB would be primarily on
intranet and not internet applications.
These discussions are not new to the JMP participants. All of these
details have been discussed to death in the PWG meetings and on the
mail list. Would a more complete presentation of these issues to the
IETF change their minds regarding the decision regarding the status
and acceptance of the MIB?
Ron Bergman
Dataproducts Corp.
On Tue, 19 Aug 1997, Harry Lewis wrote:
> Harald - thank you for clarifying the IESG Printer and Job MIB issues
> and sharing this with the appropriate PWG projects which make up the
> majority of concerned parties. This is very helpful!
>> My interpretation is that you are resigned to double registration at
> this point. I agree, and view double registration (integers and text)
> of PDLs and coded character sets as a natural result of Evolution and
> Overlap of application and management standards .
>> Evolution - MIME was pretty fresh when the Printer MIB was laying down
> it's definitions and, while discussed, the connection between MIME and
> print jobs was not so obvious then.
>> Overlap - like it or not, the Printer MIB *is* used by some end-user
> applications to determine device configuration and capabilities and
> IPP will be involved in "managing" print jobs. This unacknowledged
> overlap may have contributed to some of our most difficult discussion
> during development of IPP which related to the use of text strings vs.
> integers.
>> It would be hard to avoid double registration for both reasons.
>> AS FOR THE Job MIB, you have listed some very reasonable points which
> somewhat change the notion which has carried the JMP team - that of
> creating an Internet Standard - but do not necessarily undermine or
> resist the desire to have a standard Job MIB within the printer industry
> which is also an informational RFC. I'd like to hear more comment on
> this from the Chair and other members of the JMP and IPP.
>> I have two main concerns...
>> 1. First, the IESG may not understand the role the Job MIB plays in the
> administration and accounting of print jobs. Thus, I fear your statement...
>> >- The IETF has no consensus position that it is a Good Thing to deploy
> > MIBs as a means of users' access to information (as opposed to an
> > administrator's access). In particular, the access control models
> > currently being defined in the SNMPv3 group are not based on the idea
> > that all users need MIB access; we do not want to bring this idea into
> > that process, for fear of delaying it further.
>> ...may be applied to the Job MIB with more weight than is actually warranted.
>> 2. Second, I'm concerned about the effect on IPP if the Job MIB is
> treated as informational by the IESG. It should be viewed as a Good Thing
> to facilitate harmony between standards - especially those routed within
> a particular industry and standards organization. Folks in the printer
> industry have been active in defining and deploying solutions based on
> Internet Standards, and I don't think we're unique in potentially having
> overloaded some. As application and management standards evolve, it is
> reasonable for controlling bodies, like the IETF, to project a clearer
> picture of the purpose and relationship between standards. But, this
> needs to be done in an atmosphere which acknowledges and, if possible,
> accommodates this evolution and the resulting current state of affairs.
>> Thanks, again, for helping disseminate an accurate view of the IEGS's
> stance on these issues.
>> Harry Lewis
>