diff -r 85147c57a544 -r cda390e09aaf libpurple/protocols/jabber/useravatar.c
--- a/libpurple/protocols/jabber/useravatar.c	Sun May 03 18:50:20 2009 +0000
+++ b/libpurple/protocols/jabber/useravatar.c	Sun May 03 18:51:11 2009 +0000
@@ -45,6 +45,9 @@
 static void
 remove_avatar_0_12_nodes(JabberStream *js)
 {
+#if 0
+	See note below for why this is #if 0'd
+
 	/* Publish an empty avatar according to the XEP-0084 v0.12 semantics */
 	xmlnode *publish, *item, *metadata;
 	/* publish the metadata */
@@ -61,16 +64,26 @@
 
 	/* publish */
 	jabber_pep_publish(js, publish);
+#endif
 
 	/*
-	 * This causes ejabberd 2.0.0 to RST our connection unceremoniously,
-	 * so disable it for now (we publish a <stop/> to the metadata node
-	 * instead.
+	 * This causes ejabberd 2.0.0 to kill the connection unceremoniously.
+	 * See https://support.process-one.net/browse/EJAB-623. When adiumx.com
+	 * was upgraded, the issue went away.
+	 *
+	 * I think it makes a lot of sense to not have an avatar at the old
+	 * node instead of having something interpreted as "no avatar". When
+	 * a contact with an older client logs in, in the latter situation,
+	 * there's a race between interpreting the <presence/> vcard-temp:x:update
+	 * avatar (non-empty) and the XEP-0084 v0.12 avatar (empty, so show no
+	 * avatar for the buddy) which leads to unhappy and confused users.
+	 *
+	 * A deluge of frustrating "Read error" bug reports may change my mind
+	 * about this.
+	 * --darkrain42
 	 */
-#if 0
 	jabber_pep_delete_node(js, NS_AVATAR_0_12_METADATA);
 	jabber_pep_delete_node(js, NS_AVATAR_0_12_DATA);
-#endif
 }
 
 void jabber_avatar_set(JabberStream *js, PurpleStoredImage *img)