A *pure* implementation conforming to RFC 1759 cannot include alert(18).
A better question would be "Does the inclusion of alert(18) cause
interoperability problems?"
Since the main reason for conformance is to insure interoperability, a
100% conforming implementation will interoperate. Also, many
non-conforming features will also interoperate. Is this one of them? My
guess would be yes, but a check with management app vendors should be
initiated to verify this assumption.
Changing alert(18) to a type 2 enum does not solve the problem. The
fact of the matter is, you cannot change an existing RFC.
Why not simply upgrade to the new Printer MIB (RFC 3???) ifthis feature is
absolutely required.
Ron Bergman
Dataproducts Corp.
On Thu, 4 Jun 1998, Tom Hastings wrote:
> RFC 1759 says that implementations conforming to RFC 1759 may implement
> type 2 and type 3 enums that are registered after 1759 has been published.
>
> In order to use the new type 2 alert code:
>
> -- Alert Group
> alertRemovalOfBinaryChangeEntry(1801)
> -- A binary change event entry has been
> -- removed from the alert table. This unary
> -- change alert table entry is added to the
> -- end of the alert table.
>
> an implementation has to include the new type 1 alert(18) code
> in the alert table and trap (which is defined in the draft Printer MIB):
>
> prtAlertSeverityLevel warningUnaryChangeEvent(4)
> prtAlertTrainingLevel noInterventionRequired(7)
> prtAlertGroup alert(18)
> prtAlertGroupIndex the index of the row in the
> alert table of the binary
> change event that this event
> has removed.
> prtAlertLocation unknown (-2)
> prtAlertCode alertRemovalOfBinaryChangeEntry(1801)
> prtAlertDescription <description or null string>
> prtAlertTime the value of sysUpTime at
> the time of the removal of the
>
> With hind site we should have made the PrtAlertGroupTC a type 2
> enum, instead of a type 1 enum. But we didn't.
>
> Alternatively, since the alert group codes starting at 30 are type 2,
> why not also indicate that the alert code 18 is also type 2, so that
> implementations conforming to RFC 1759 can use it?
>
> Or am I just being too fussy here? Should implementators conforming to
> RFC 1759 feel free to implement the alert(18) type 1 code?
>