[Standards-JIG] privacy2 anti-SPIM proto-JEP
stpeter at jabber.org
Mon Aug 29 18:31:31 UTC 2005
Ian Paterson wrote:
>>I continue to think that changes to the RFCs need to happen
>>through the Internet Standards Process, not in the JSF.
> I really do agree where possible. But:
> 1. We need something about SPIM agreed and implemented yesterday. Google
> needs to implement something on their server, and any client that wants
> to chat with Google Talk users (including the Google Talk Client) would
> have to implement the bot-challenge response.
The fact that something is needed yesterday is not a great reason to
mess with the Internet Standards Process. The IETF moves slowly for a
reason -- they are trying to define protocols that will be used for a
long time. It's too early to rev the XMPP RFCs because (1) we need more
experience with some of the protocols -- especially privacy lists
because very few servers and clients have implemented them yet, and (2)
it would be very beneficial to hold an interoperability event (with
output of interop reports) before we push them forward to Draft.
> 2. Technically (if not in spirit), the JEP provides an alternative to
> standard XMPP. It does not redefine any XMPP namespace (for example).
And I submit that's not a great idea. Yet. The potential for confusion
I realize that people feel a need for speed to address the spim issue
and I don't mean to be obstructionist. All I'm saying is that let's not
rush into changes that may or may not be needed. I'm all for
experimentation, but I'm also in favor of thinking the problem through
before we change the RFCs.
> Of course the JEP could be either absorbed, or *replaced* (if the IETF
> decides there is a better way) when RFC 3921bis eventually comes around.
> Allowing a few JEPs now might buy us the time and experience to do RFC
> 3921bis better than if we have to rush it.
I'd like to also think about other measures we can take outside of
changing the RFCs. There are quite a few, I think (see my proto-JEP).
Even beyond those, here is how I envision the spim-preventing flow using
1. I set my privacy lists to disallow messages from people not in my
roster but allow subscription requests. I also tell my server to send a
certain text string as the XML character data of the <text/> in the
<message type='error'/> that the server returns when it receives a
message from someone who's not in my contact list; the error SHOULD be
<not-authorized/> so you know to send me a subscription request. (NOTE:
This violates RFC 3921, which says that the server MUST NOT return an
error here, so we need to figure that out, but at least it's changing a
MUST NOT to a MAY rather than changing semantics.)
2. You send me a message (although your client should force you to send
me a subscription request first if it cares about preventing spim as
much as people think it should).
3. My server returns a <not-authorized/> error to you (along with my
text that says "hey, you're not in my roster, send me a subscription
request first, eh?").
4. You send me a subscription request which includes a <status/> child
that describes why you want to subscribe to my presence.
5. My client shows me your request, the <status/> text, enables me to
check your vCard (or successor), etc. (see my proto-JEP on best practices).
6. If I approve your subscription because I think you're a nice person,
everyone is happy and I don't need to change my privacy lists.
7. If I decline your subscription because I think you're a nasty bot
(optionally including a <status/> element telling you why), you're not
happy but at least I don't need to change my privacy lists.
8. If I decide that we need to chat before I can figure out if you're a
nice person or a nasty bot, my client updates my privacy list to allow
communication with you on a temporary basis (allow based on JID). If I
then decide to deny your subscription request because I think you're a
nasty bot rather than a nice person, my client again updates my privacy
list to deny communication with you (I would say all communication,
including subscription requests) and we're back to square one.
>>1. Why do we need the "correspondent" type? Just add someone
>>to your roster and use the "subscription" type. Forcing the
>>server to keep track of everyone you have communicated with
>>in the last year seems like overkill to me.
> Either way the server will have to keep track of these people (whether
> you call them correspondents or subscriptions). Also 'one year' is only
> an example policy. It could be the 'last month', or the 'last 100
> correspondents', or up to 8KB of JIDs...
IMHO that's what we have rosters for.
> 1. Correspondents and roster entries are two very different things and
> should be kept separate.
> 2. I don't want to download the list of all my correspondents every time
> I login (my roster is big enough already).
> 3. Correspondents make clients more simple (they are transparent to the
I don't follow your reasoning here.
> 4. IMHO servers shouldn't add entries to the roster without the client's
Certainly not -- that's disallowed by RFC 3921 and there's no reason to
>>I have to think about the challenge action some more, since
>>it seems to me that the success or failure of the challenge
>>is a precondition to deciding whether to allow or deny...
> Yes. If a human fails the challenge then their client should give them
> the option to resend the message immediately.
Jabber Software Foundation
More information about the Standards