1) It looks like consensus is moving towards having a record format that can be verified on disk, etc. I.e., even in the clear, the format should be fairly robust. Hence, there's little need to worry about the authentication stuff in the syslog-reliable draft above the level of transport security, right? I guess what I'm trying to say is, since folks are going to make the messages cryptographically robust even in the clear, there's no need to add cryptographic wrappers to the COOKED format, is there? My proposal is that the draft be worded such that if authenticated messages are to be sent via the COOKED interface, the entire message be delivered in the CDATA portion of an <entry> element, as well as having the attributes of the <entry> element. For example, there might be an entry that looks like <entry processID='141' processName='imapd' facility='24' severity='5' timestamp='20001027T132108Z' ><29> 13:21 imapd[141]: Broken stuff\tH=24 L=65 M=29582</entry> This would allow the "raw" message to be validated and would allow the more complete timestamp formatting (for example) to be carried along as well. 2) I'm not sure if the "received by" headers are useful (i.e., the stuff that's currently in the <trace> element). If you have a message at its destination, you look at where it came from, and trace where it goes via the configuration, right? I don't understand why each message would have to carry its complete history of hops, since that only changes when the configuration changes. If you have an authenticated message, you know where it came from, so you can go to the configuration for that machine, look at where those messages are supposed to go, look at the machine where they go, examine the configuration, and so on. If you *don't* have the message, you're not going to be able to trace where it went from the headers on the message anyway. -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand.
