Chris,
** Related thread **
>The mail came from me, chrisw@iwl.com. The reason you could not
>tell is because you and I have discovered an interoperability problem
>between Microsoft Internet Mail reader version 4.70.1155 and whatever
>version of Lotus Notes you are using. If you report it as a bug
>to the Lotus Notes team, I will report it to Microsoft.
I suspect interoperability problems are more pervasive than just
Microsoft and Notes. Thus, the plea about 9 months ago to the reflector
for everyone to simply "sign" their e-mail. Works, for now. I'll be
happy to report this situation to the Notes folks.
** End **
>Actually, the Test Suite acts like it is the manager station, so
>the idea is that when a trap is manually generated on the agent,
>the Test Suite intercepts it. However, many of the participants
>had set up other managers on their laptops. So, *if* they had
>configured these other managers to be the trap receiver, then
>that might explain the 100% failure.
>If you did not explicity do anything, then removing the paper
>tray would send a trap that the Test Suite would automatically
>intercept.
Please elaborate how the "Test Suite" informs the agent of it's IP
address so it can receive traps. The point we're stuck on is that you
say there was 100% trap test failure and I say we didn't test 'cause I
don't recall setting up the "manager" as a trap host. I don't understand
the "automatic" part.
>If you re-read RFC2026, you will see that agreeing or disagreeing is
>not really an option. Remember that we have to have at least two
>interoperable implementations for every object, mandatory or optional.
>So, we have to find two printers that have implemented traps, and
>demonstrate that this works. If we cannot do that, then we have to
>remove it from RFC 1759. We could probably take the position that
>since there is not a standardized mechanism for trap registration and
>receipt, that the manner in which the vendors have done it varies.
Why would I be interested in reading RFC2026? Aren't we trying to forward
RFC1759? Are you telling me the IETF is a moving target?
It would help if vendors simply shared whether or not they have
implemented traps. (I think this was done informally at Stardust, but
probably not recorded). Regardless of whether we tested or not, we can
determine the *number* of implementations just by asking. If there are
many, then additional testing is warranted at some point (but I wouldn't
"hold up" the RFC). The lack of v3 standards doesn't mean traps can't be
useful to a printer management application today. If each vendor would
describe their trap host registration procedure, this would facilitate
printer management until v3 gets a standard in place. Trap testing would
not necessarily mandate another on-site "bakeoff". We could probably
find one or two management apps interested enough to assist in collecting
and sharing data. If we can't, this entire topic is mute.
We do implement RFC1759 traps.
>So, why don't you lead the charge here? Give this email to the
>guys in the lab and ask them to re-run the 5.10.x series tests,
>put a sniffer or whatever on wire, and find out what is going on.
'Cause I'm not suggesting we should remove traps from the RFC!
I'm in favor of testing, correcting, sharing implementation experience
and improving interoperability. But, honestly, with respect to moving
the RFC, I don't see parity in scrutinizing traps, given our disposition
on the hrMIB and Interfaces Table.
As I summarized, before, I think the printer MIB is a *useful standard*
which is on a path of continued improvement... sorta' like e-mail,
I guess.
>P.S. Don't forget to report the bug to the Lotus Notes guys.
I won't forget. For your information, I'm using Notes 4.5a.
Harry Lewis - IBM Printing Systems.