[Standards-JIG] privacy2 anti-SPIM proto-JEP
ian.paterson at clientside.co.uk
Mon Aug 29 17:45:57 UTC 2005
> 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.
2. Technically (if not in spirit), the JEP provides an alternative to
standard XMPP. It does not redefine any XMPP namespace (for example).
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.
> The matching rules specified in Section 10.1 of RFC 3921
> imply that the proposed "domain" type is unnecessary.
Thanks for pointing that out. I'll remove the "domain" type from the
> 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...
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
4. IMHO servers shouldn't add entries to the roster without the client's
> 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.
More information about the Standards