An entity may wish to subscribe using different subscription options, which it can do by subscribing multiple times to the same node. Support for this feature ("multi-subscribe") is OPTIONAL.
If multiple subscriptions for the same JID are allowed, the service MUST use the 'subid' attribute to differentiate between subscriptions for the same entity (therefore the SubID MUST be unique for each node+JID combination and the SubID MUST be present on the entity element any time it is sent to the subscriber). It is NOT RECOMMENDED for clients to generate SubIDs, since collisions might result; therefore a service SHOULD generate the SubID on behalf of the subscriber and MAY overwrite SubIDs if they are provided by subscribers. If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved).
-When a subscription request is successfully processed, the service MAY send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'urn:xmpp:delay' namespace (see &xep0203;) to indicate it is sent with delayed delivery. (Note that in this example the message notification is sent to the bare JID since that is the subscribed JID.)
In order to remove an entity from the subscriptions list, the owner MUST set the value of the 'subscription' attribute to "none" and the service MUST remove that entity from the subscriptions list and not return it in response to future list requests.
An implementation SHOULD send notification to an entity whose subscription has changed (see the Notification of Subscription State Changes section of this document).
If the node is configured to support the "pubsub#notify_sub" option, the service MUST send to the node owners notifications regarding new subscribers, SHOULD send notifications regarding unsubscribe actions, and MAY send notifications regarding other subscription changes. The relationship between these notifications and the retrieval of the subscriptions list as described under Retrieve Subscriptions List is similar to the relationship between a "roster get" and a "roster push" as described in &xmppim;.
+In particular, the notification consists of a &MESSAGE; stanza containing a <pubsub/> element qualified by the 'http://jabber.org/protocol/pubsub#owner' namespace, which contains a <subscriptions/>l element whose 'node' attribute specifies the NodeID of the relevant node; this <subscriptions/> element in turn contains one <subscription/> element whose 'jid' attribute specifies the address of the subscriber and whose 'subscription' attribute specifies the suubscription state.
+For instance, the following example shows a new subscriber notification.
+The following example shows an unsubscribe notification.
+