diff --git a/xep-0163.xml b/xep-0163.xml
index 955667c4..f8b7001e 100644
--- a/xep-0163.xml
+++ b/xep-0163.xml
@@ -27,8 +27,8 @@
&stpeter;
&ksmith;
In accordance with XMPP Council consensus (1) explicitly defined auto-create, auto-subscribe, filtered-notifications, and last-published features, (2) moved them to XEP-0060, and (3) added appropriate references to XEP-0060 throughout; also added friendly but non-normative How It Works section and removed references to private data storage. Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented.
-
Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.
This section provides a friendly, non-normative introduction to the workings of personal eventing via pubsub (PEP).
There are two sides to personal eventing: what the user does to generate events and what the contact does to receive events. As shown in the following examples, both are simplified in PEP as compared to generic pubsub.
-Imagine that you are a Shakespearean character named Juliet and that you want to generate the following kinds of events that may be of interest to other people:
-We assume that there are three other users who have the following relationship to you:
+Imagine that you are a Shakespearean character named Juliet and that you want to generate events about what music you're listening to, which anyone may see as long as they are authorized to see your online/offline presence (i.e., a pubsub access model of "presence").
+We assume that you have three contacts with the following relationship to you:
Naturally your server doesn't need to send out a disco#info request every time, since it will quickly create a large cache of such extensions!
-So that's the general idea. We'll demonstrate it again with an example of geolocation...
-First your client generates a geolocation event:
-Then your server sends event notifications, this time addressing the event only to Romeo, since the Nurse is not in your Friends roster group:
-And your server knows to send the geolocation notification to Romeo because (1) he is in your Friends group and (2) his client advertised interest in "http://jabber.org/protocol/geolocation" events.
+So that's the general idea.