Steve Atkins wrote:
On Feb 3, 2010, at 8:25 AM, Chris Lewis wrote:
Ian Eiloart wrote:
This is one reason to support an IMAP extension.
There's no reason not to. The important thing to realize at this stage is the basic
principles an implementation of a "standard spam button" thing should support:
multiple reporting mechanisms, specifiable destinations, and a couple flavours of content.
That's all a bit "why go for a simple approach, when a complex one will work?",
though.
True to an extent, on the other hand, the alternative is an
un-upgradeable spec that may be obsolete before it's ever used. There's
no need to necessarily specify how each of the variations work nor even
which ones are necessarily valid, just specify how the statements (of
what, where, how) are made. Then each of the "what, where, hows" can be
independently specified as companion specs when people think they need 'em.
Kinda like the return codes of EHLO in ESMTP ;-)
At this point we need to be technology agnostic as much as possible, and
specify what the thing actually does and how to express it header-wise
(or whatever) in keeping with security, usefulness and flexibility.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg