[Standards-JIG] bot-challenge proto-JEP

Ian Paterson ian.paterson at clientside.co.uk
Fri Sep 2 12:46:54 CDT 2005


Peter wrote:
> 1. Romeo sends [a stanza] to Juliet.
> 
> 2. Juliet's server sends a [challenge] message to Romeo's client,
> including a plaintext body, a URL (JEP-0066), and a data form.
> 
> 3. Romeo replies to the plaintext challenge, visits the URL, 
> or returns the form.
> 
> 4. If he passes one of the tests, he gets another message 
> from Juliet's server telling him that he's cleared to 
> communicate with Juliet.

All this is good - and it fits Bot Challenges exactly :)


> > Q3: Is his [stanza] forwarded to Juliet?
> We need to decide whether the recipient's server queues up the
stanzas. 
> But I think that's a bad idea because what if 
> the sender generates 1000 messages to be queued up?

The sender (and/or its server) should be flagged as a SPIM bot after a
few messages queue up. So I think the server should do this (simple
clients, efficiency).


> > [I think we pretty much reached consensus on this list that people
want
> > to continue to be able to send messages to other people without
being on
> > their rosters.]
>
> Without being on their rosters, or without having a presence 
> subscription? Or both?

To continue to be able to send messages to other people without having a
presence subscription and without first being explicitly added to a list
by the other person.

*Your question suggests you may still be considering making
subscription='none' into a list of correspondents that are free to
communicate without challenges? IMHO it's not a good idea:

1. We've agreed SPIM blocking will be handled by the server. But IMHO
servers should not add or remove items from users' rosters or privacy
lists (without an explicit request from the client). So, IMHO, we need a
third list of 'correspondents' that the server manages. To make things
simple, it can even be 100% transparent to the clients (although we
might eventually want a protocol to delete it).

2. I don't want my roster to grow any bigger. Should a mobile client be
forced to download a list of all the user's correspondents, when all the
user wants is her roster?

3. iq:privacy rules do not differentiate between JIDs on the roster with
subscription='none' and JIDs not on the roster.

4. For most people, personal contacts (roster entires) and one-time
correspondents are not the same thing, so we shouldn't mix them.

5. Why not have a third list?


One more question about the above:
Q4: Why is the "plaintext challenge", you mentioned in your point 3, not
in the form too? (see Bot Challenges)


*Can you give us a more detailed description of your ideas of how this
should work? I'm still not sure what you're suggesting as an alternative
to privacy2 - or whatever we want to call it
(http://www.clientside.co.uk/jeps/jep-privacy2/jep-privacy2.html).

- Ian




More information about the Standards-JIG mailing list