[Standards] [Operators] [Fwd: Proposed XMPP Extension: Incident Reporting]

Peter Saint-Andre stpeter at stpeter.im
Tue May 5 18:10:33 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
the implementation.

> 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
> http://matthewstechnologyblog.blogspot.com/2008/05/jabber-abuse-handling.html
> - 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.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoAgRkACgkQNL8k5A2w/vxBDQCg9ek10+T9ZqqK99hzIu2tFaJf
jQAAoLaaJ7lS31D9r89apBxhjyGCMYMq
=aAdk
-----END PGP SIGNATURE-----



More information about the Standards mailing list