[JDEV] Problems with auto reply

Wed Nov 27 13:23:31 CST 2002

One other option is to use headers (JEP-33) to do loop detection.

Hopefully once we get disco put to bed, JEP-33 will start to advance again.

-- 
Joe Hildebrand

Tijl Houtbeckers <thoutbeckers at splendo.com> writes:

> Hi Matthias,
>
> Matthias Wimmer <m at tthias.net> wrote on 23-11-2002 15:44:43:
>>
>>Hi Tijl!
>>
>>On Sat, Nov 23, 2002 at 12:50:27PM +0100, Tijl Houtbeckers wrote:
>>> However, I don't think it's necessary.
>>
>>It is! Maybe you don't have these problems at your server because it is
>>used mostly by clients programmed by yourself. 
>
> I'm aware of the problem. However you thinking up some spec. about this 
> won't fix the broken clients outthere. In fact, even if new clients 
> implement this it won't stop the problem. 
>
>>at at the average Jabber
>>server this can be a problem - and people implementing clients (or 
>>bots) are often not aware of the problem. If they would get 
>>information how to handle auto replies in the specs, I'm sure there 
>>would be less problems. 
>
> I think what they need is a better understanding of the concept auto-
> replies. The problem is perfectly avoidable without adding anything to 
> the protocol. So the first step would be fixing the clients so that 
> they're not bugged anymore! As soon as one of the two  clients in this 
> scenario is fixed the problem will become less. But with the solution 
> of extending the protocol both clients have to be fixed, so it will 
> take longer for the problem to go away (if ever). 
>
>>
>>> Why would *anyone* implement the system the way it is now?
>>
>>If nobody would implement the system like it is now, why do we then 
>>have this system? Auto replies have been implemented, that's a fact. 
>>There is even a (depreciated) server module (mod_filter) for this.
>
> I'm not saying noone needs autoreply, I'm just saying noone needs 
> autoreply in this horribly implemented way! It's a *bug* in clients to 
> have this kind of behaviour. That's what I would do if I saw such a 
> problem on my server, file a bug report with the author of the client. 
> When auto-replying either do it just once a session, or don't send 
> autoreplies to the same user within 60 seconds. No matter wich protocol 
> extension is used or not used. 
>
>>
>>> delay before sending out the autoreply! (though thankfully karma 
>>> will slow them down a bit). 
>>
>>My experience shows that already many messages have been exchanged 
>>after karma begins to slow this down. - I don't want to use more 
>>restrictive karma, as this would also limit legal usage of the server.
>
> Not to mention that (as far as I know?) S2S has no karma limits. In 
> some clients that have this "autoreply problem" (like MICQ) I've seen 
> that they at least wait a few seconds before sending back an autoreply. 
> While this is still a buggy way of doing autoreply it at least doesn't 
> flood the network completely. 
>
>>> It could stop itself from sending any more of those confirmation 
>>> messages on autoreplies of that user within the next 60 seconds or 
>>> something (as I already suggested).
>>
>>it would be nice, if this is implemented by a Jabber entity too. But 
>>this doesn't meen that you shouldn't flag automatic messages as being 
>>automatically created.
>
> I don't care if they implement a time limit or once-a-session. As long 
> as they fix the bug! That should be step 1, I have no objection to step 
> 2 being an extension to the protocol. Just don't expect everyone to 
> support it, and remember that without step 1 you'll still run into 
> problems. 
>
>>
>>> The problem with using some kind of 
>>> tag to flag that you don't want an autoreply is that some people 
>>> (who don't like autoreplies) will send it out by default, wich will 
>>> be reason for some client developers (who want their autoreply to 
>>> send anyway) will ignore the tag, wich will bring us back to where 
>>> we started. 
>>
>>Don't be stupid ... I don't think that people send auto replies if they
>>know that the other side doesn't want them. Why should they? It's not 
>>spam, they think that it is nice, but I really expect that they would 
>>accept if somebody doesn't want auto replies.
>
> Well for one, some just won't implement the extension. But don't expect 
> that just cause some people don't want something other won't either. If 
> I want to have a messenger that sends you an automatic message when you 
> send me one, and you indicate in your message through a tag you don't 
> want one. What is my highest priority, doing what the user of my 
> messenger wants (send the autoreply) or do what the user of some other 
> messenger wants (receive no autoreply). Compare it with the type="chat" 
> behaviour that's currently there. Many clients just simply override it 
> to whatever the user wants. I'm not sure if I'd call that stupid. 
>
>>
>>but there is a good idea in this: The flag could also express, that 
>>somebody doesn't want auto replies. Something like this could be the 
>>syntax: 
>>
>><x xmlns='jabber:x:autoreply' isautomatic='true' 
>>wantautomatic='false'/> 
>>
>>> type="autoreply", or if that's too drastic a tag marking that your 
>>> message *is* an autoreply (not that you don't want one back).
>>
>>Please read the messages you have replied to. This is exactly what has 
>>been discussed yet: Mark automatic messages as being machine generated.
>
> I've read them, and I'm just throwing my two eurocents into the 
> discussion with type="autoreply". Hope you don't mind ;) 
>
>>But the idea that you can flag messages to express that you don't want 
>>an automatic reply is interesting too.
>
> Just to be sure, again, I'm not against this kind of extentions. :)
>
> I myself lean towards just using type="autoreply".
> How it works:
> Any message of the type autoreply should be marked with 
> type="autoreply". It's not allowed to respond with another autoreply 
> message to this kind of message. 
>
> Advantages:
> - simple
> - users that don't want want them can filter them out in their own 
> client or on the server, rather then relying on the other client for 
> not sending them. - clients could present autoreplies to the user in a 
> different way, probably without much change in code. - prevents abuse 
> from people who don't want autoreplies faking it. (since they can't use 
> type="chat" anymore then) 
>
> Disadvantages:
> - less possibilities as with a tag. (at the same time it's an 
> advantage, keeps things simple). - perhaps too much of a change to the 
> core protocol? (how's this for type="headline", are you free to use any 
> type you like, or just headline, chat and error?) 
>
> Most things could also be done with something like jabber:x:autoreply I 
> suppose, but I kind of like it this way. Anyway, if I'll ever implement 
> autoreplies I'll ofcourse go with whoever wrote a nice JEP for it, it 
> doesn't matter all that much to me how. :) 
>
>
> -- 
> Tijl Houtbeckers
> Java/J2ME/GPRS Software Engineer @ Splendo
> The Netherlands
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev