As I was present at the meeting with April L. and Eric A. where a pub/sub model was suggested as a protocol, I had some ideas on this later in my hotel: I've not looked into RSS and so don't know how well it would fit our needs as a protocol to convey information between reputation system layers. The SIQ protocol sees HTTP as being used for reliable, secure, and complex data transfers, but it is used in a query/response model. I did note that HTTP Server Side Push could be used to provide publish/subscribe support. But as many of you know, HTTP Server Side Push can be resource intensive for a server especially, if there is not a regular flow of data to warrant maintaining an open connection. Since we are concerned about mail in general, I was wondering why introduce a new protocol at all? Also RSS I've heard is not as efficient as some others of its breathen. Why not use a mailing list like publish/subscribe model where the content of the message is delivered to and structured for the reputation client using RFC 2821/2822/et al. SMTP+AUTH can be used by the reputation server to identify itself and assert that the messages come from a reliable and known source. And this can be used at all layers of the infrastructre too (aggreators, caches, MTAs, even MUAs). Re-using RFC 2821/2822 et al. simplifies things a lot. All we need do is specify the requirements of the delivery and define a basic message structure that all reputation clients could handle. It also means that we could leverage much of the existing MTA software through plugins, modules, filters, etc. as the delivery backbone and so avoid many of the pitfalls related to writing servers and clients. This idea appeals to me a lot, but I've had no feedback from anyone I've mentioned this to. I'd be willing to write a new Internet draft for such a protocol if I could get some input. Anthony (Snert) Howe