> > There is also a matter of what an application is supposed > to do when > > logging fails. Some applications should proceed uninterrupted. > > Others may need to block. I don't know whether text is > appropriate. > > It's not part of the protocol, but it does fall under > common modes of > > failure. The reason this would be an issue with TLS (or > BEEP for that > > matter) and not with UDP is that one doesn't block with UDP. > > I think Eliot is on the right track. However, I wouldn't > differentiate between the actions that a sender or receiver > is to take when authentication fails - both cases should have > a recommendation that the device log the failure _and_ > attempt to inform the administrator of the problem. This > might be pop-ups to the unsuspecting user who won't know what > to do about it, it might be messages printed on the console, > it might be a blinky light on the printer, etc. (Most > networked printers that I'm seeing these days have nice > displays that are starting to give informative > messages.)
My perception is logging does not necesarily mean send events over network to syslog server,. Webopedia says log is "to record an action". If there is no syslog connection available, it is still possible to log the message in local storage. I just checked the printer in my office, it does log events locally. It is reckoned the buffer for log is very small because there are only 50 records, acutally the printer fails from time to time:-( Thanks, Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
