On Wed Sep 15 21:47:30 2010, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Spim Markers and Reports
Abstract: This document defines an XMPP protocol extension that
enables XMPP entities to interact with spim filters by marking
unsolicited or suspicious XMPP stanzas.
URL: http://www.xmpp.org/extensions/inbox/spim.html
This looks basically sound.
A couple of minor niggles:
1) The <mark/> element's text would be more usefully enclosed within
a <comment/> element or some such, since that makes it substantially
easier to extend later.
2) I'd rather that the <query/> element in the complaint reporting
protocol was actually a <report/> element containing <mark/> element,
and otherwise mirrored the elements used by filters precisely. This
allows simplistic reporting as well as more complex cases, such as
reporting a false positive, if the filter allows it.
3) It's not entirely clear to me how multiple filters would work, but
I assume that they are all trusted by the home server. In this
instance, a server supporting spin-marker should be able to strip all
spim-marker elements on input over S2S. Also, it seems generally
likely to me that you'd want to push a report to a uniform set of
filters.
My gut feel - and I may be way off the mark - is that filtering
really ought to be largely a black box to clients that exposes a
(form based?) configuration interface.
This means that to the client, there is typically one filtering
entity - the server. If there is an additional one (such as a
border-guard), then the server - if it's aware - will have to be
configured to know about it - any other markings will need to be
stripped. It seems sensible that the server would use the external
spim filter as input data to its own, however, and then simply strip
out the old markings.
Then any message can be reported as spim or not - in general, anyway
- to just the server, which would fan-out reports to filters.
So in practise, I think the deployment patterns for this would end up
very close to the deployment patterns for XEP-0258, and I think it's
worthwhile optimizing the protocol for that. Furthermore, I think
this reduces or eliminates most of the security concerns. (Which,
BTW, are very well thought through).
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
