The latest proposal certainly resolves the packet size problem,
but it seems that we are still missing some key points that were
uncovered in Ira's exercise to create an SNMP mapping. To me
Ira's SNMP document highlighted three problem areas:
1. Some transports have size limitations that prevent the entire
set of notifcation content attributes to be included.
2. Some of the required attributes are meaningless when using
other transports. For example, SNMP traps do not have any
need for "version-number", "attributes-charset", or
"attributes-natural-language".
3. The format of some of the required attributes may be better
presented in a different manner in some transports. Again,
in SNMP traps the "status-code" and "request-id" are quite
different than would be in an IPP message.
I believe that it is a mistake to try to define a mandatory set
of attributes that is applicable to all transports. I would prefer
to see the Notifications Specification provide a list of possible
attributes and then each "Method" specification fully define the
required attributes. This will allow those transports that can
easily handle large packets to always have the same attribute
content. This should be much easier for IPP servers to
implement.
Notification clients will then always know what attributes will
be returned and will never have to query the printer to determine
what optional attributes are supported and then request those
it needs. This would seem to simplify both clients and servers.
This could make the specification task more difficult (but it is
hard to believe it could be more difficult than it already has
been). We will have to specifiy a mandatory "Method" that
can provide all possible attributes and then carefully define
all those that have limitations to provide the proper subsets.
Ron Bergman
Hitachi Koki Imaging Solutions