A PEP service MAY support other use cases, affiliations, access models, and features, but such support is OPTIONAL.
-Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &xep0030; information request to the server:
+Naturally, before an account owner attempts to complete any PEP use cases, its client SHOULD determine whether the account owner's server supports PEP; to do so, it MUST send a &xep0030; information request to its own bare JID:
If a server supports PEP, it MUST return an identity of "pubsub/pep" (as well as a list of the namespaces and other features it supports, including all supported XEP-0060 features):
+If the account owner's server supports PEP and the account is provisioned for PEP, the server MUST return an identity of "pubsub/pep" on behalf of the account (as well as a list of the namespaces and other features it supports, including all supported XEP-0060 features):
A contact MAY send service discovery requests to the account owner's bare JID &BAREJID;. If the contact already has a subscription to the account owner's presence, this is not necessary in order to receive notifications from the account owner via personal eventing. However, a user without a presence subscription needs to do so in order to discover if the account owner is a virtual pubsub service and to discover the account owner's eventing nodes. The relevant protocol flows are demonstrated in XEP-0060.
Note: When returning disco#info results, the account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items without first subscribing.