The following is a summary of potentially material changes made 
between draft-ietf-xmpp-im-21 and draft-ietf-xmpp-im-22 (minor 
editorial fixes are not mentioned in this summary).

2. Syntax of XML Stanzas

For consistency, changed "stanzas in the ... namespaces" to "stanzas 
qualified by the ...  namespaces"; this change was made in several 
other sections as well.

2.1.2 Child Elements

As in draft-ietf-xmpp-core-23, changed "CDATA" to "XML character data" 
here and throughout.

2.1.2.3 Thread

Specified that the XML character data contained in the <thread/> element
is not intended to be human-readable.

2.2.1 Types of Presence

Removed the word "notification" from the definition of unsubscribe, 
since presence notifications are restricted to "type='unavailable'" 
and no 'type' only.

2.2.2.1 Show

Specified that the XML character data contained in the <show/> element
is not intended to be human-readable.

2.2.2.3 Priority

Specified that the XML character data contained in the <priority/> 
element is not intended to be human-readable.

3. Session Establishment

Corrected XML error in first example (bind and session elements were not
closed).

4.2 Specifying a Message Type

Added 'xml:lang' attribute to examples here and also in presence examples.

5. Exchanging Presence Information

Corrected definition of "presence notification" since there is no such 
thing as type='available' (availability is implicit in the semantics of 
the presence stanza if no type is included). Also clarified that 
"directed presence" is a presence notification stanza with a 'to' 
address.

7.4 Adding a Roster Item

Added the following clarifying note after the second example.

   As required by the semantics of the IQ stanza kind as defined 
   in [XMPP-CORE], each resource that received the roster push 
   MUST reply with an IQ stanza of type "result" (or "error").

8.2 User Subscribes to Contact

In step 2, specified exactly which resource receives the IQ result by 
changing "MUST reply with an IQ result related to the roster set" to
"MUST reply to the sending resource with an IQ result indicating the 
success of the roster set"; this change was made in several other
sections of the text.

In step 6, corrected "user" to "contact" in several instances (copy and
paste error). Also changed "configured preferences" to "the contact's 
configured preferences" so that it is clear that these preferences are 
determined by the human user and not "pre-configured" in some sense or 
set by the server; this change (addition of either "the user's" or "the 
contact's" was made in several other sections of the text.

8.3 Creating a Mutual Subscription

As previously discussed, removed the very last sentence of this section
("The user's server MUST now send the user's current presence 
information to the contact.") since it merely repeats information from
step 4 but lacks a necessary proviso regarding the enforcement of
privacy lists.

8.5.1 Case #1: Cancelling When Subscription is Not Mutual

In step 3, changed "(2) MUST deliver the "unsubscribed" state change
notification to the user;" to "(2) MUST deliver the "unsubscribed"
state change notification to all of the user's available resources;".
This was done in order to clarify that such stanzas are delivered to 
all available resources. This change was also made in Sections 8.5.2 
and 8.6.

8.6 Removing a Roster Item and Cancelling All Subscriptions

Added 'id' attributes to examples.

10. Blocking Communication

Made terminology consistent by changing "privacy rules" to "privacy
lists" in several places within this and other sections.

10.1 Syntax and Semantics

Changed "JIDs are matched in the following order:" to "JIDs SHOULD be
matched in the following order:" since the lack of a conformance term
was unnecessarily informal and potentially confusing.

Per feedback from one WG member, specified that a subscription type of
"none" includes entities that are totally unknown to the user and 
therefore not in the user's roster at all.

Corrected several instances of "accept" to "allow" since the former is
not an allowable value of the 'action' attribute.

10.6 and 10.8

Corrected juliet@example.com to romeo@example.net in the IQ results.

In the narrative text associated with these and other examples, changed 
"user" to "entity" since not all blocked addresses will be associated 
with a human user.

11.1 Inbound Stanzas

Changed "the hostname of the server itself" to "a hostname of the server
itself", since virtual hosting is allowed and a server may be hosting
more than one domain. This change was made in Section 11.2 as well.

11.2 Outbound Stanzas

In step 2, changed "If the address record resolution fails" to "If the
"xmpp-server" address record resolution fails".

In step 3, changed "If the SRV lookup fails" to "If both SRV address
record resolutions fail".

12.2 Clients

Corrected reference to draft-ietf-xmpp-e2e-07.

Appendix B. XML Schemas

Added imports and error groups, fixed several errors.