[Standards] [Operators] [Fwd: Proposed XMPP Extension: Incident Reporting]
stpeter at stpeter.im
Tue May 5 18:10:33 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 4/29/09 8:51 AM, Matthew Wild wrote:
> On Wed, Apr 29, 2009 at 5:42 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> FYI. This proposal emerged from discussions among some operators and
>> server vendors at XMPP Summit #6 in February...
> The current proposal doesn't look bad. A few notes follow.
> The <solution> and <suggestion> elements should most certainly contain
> <ip> elements, the reporter in most cases won't know the IP, except in
> the case of suspicious registrations.
Those elements are essentially undefined right now. So let's define them. :)
> Waqas also told me he had reservations about using the server's roster
> this way, and overloading presence subscriptions with something they
> are not. I'm not really fussed either way, but it would be interesting
> to know what others think of this.
I think the point is that a server deployment has some kind of whitelist
of peers with which it shares incident reports. Whether that is based on
a server roster + presence subscription or some other method is up to
> It would also be useful to have a way of forwarding reports on to
> other servers, perhaps including the originator. Otherwise perhaps we
> need a way to ask a "friend" server who they trust, as a means of
> bootstrapping our own list.
Good idea. I suppose we could use XEP-0144 for that (or something similar).
> Suggestion and solution elements could also be present in the initial
> report, not sure if the XEP is allowing this, but it should probably
> be said explicitly.
I don't see why they would be disallowed.
> One question is whether servers accept reports from unknown servers
> when the report relates to users on that server. For reasoning, see
> the blog post I wrote a while back at
> - The idea is that the abuser's login server collects reports from
> anyone, and once satisfied that there really is a problem it can act
> (either automatically or by notifying the admin).
Yes, I think it's always good to provisionally accept reports about your
users, then bubble those up to the admins somehow. So what you say makes
sense to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards