[JDEV] Problems with auto reply

[Tijl Houtbeckers]

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