On 1/4/2009 5:29 AM, Eric Butler wrote:
Should pep nodes be returned in the result of a disco#items query on a
bare JID? Section 5.2 of XEP-0060 makes it sound like this should be the
case, but it's not completely clear, and ejabberd does not return them.
If not, what's the correct way to get a list of your pep nodes?
Affiliations request?
XEP-0163 section 6.1 says that a PEP server should return the
pubsub<feature>s on behalf of a user for a disco#info request, however
ejabberd 2.0.2_2 does not. Is this an implementation bug, or am I
misunderstanding the specifications? Here's what I do get:
<iq to='[email protected]'
id='disco1'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq from="[email protected]" type="result"
to="[email protected]/Psi" id="disco1">
<query xmlns="http://jabber.org/protocol/disco#info";>
<identity category="pubsub" type="pep" />
<feature var="vcard-temp" />
<feature var="http://jabber.org/protocol/commands"; />
</query>
</iq>
That looks like a clear implementation bug based on section 6.1 of
XEP-0163 as you mention. Section 5.2 of XEP-0060, however, I think is
not relevant because that relates to a hierarchy of nodes, and PEP does
not provide for this, allowing only one node per namespace (and not in a
hierarchy).
An affiliations request would get all affiliations, not only your owner
ones, but I suppose the data should be extractable from there. I suppose
the only other way would be to add Jabber Search support for this
particular need.
Even in the full Pubsub, I don't see a way to query for all nodes of a
user, as one is apparently confined to constrain by payload namespace
(12.14).
How are clients expected to behave when they see a pubsub/pep
<identity>? What's the purpose of this, assuming you also get
pubsub-related<feature>s?
http://xmpp.org/extensions/xep-0030.html#info-basic gives a definition
of <identity/>. For one, I think there is just one element to check, to
know whether PEP is supported at all (and to know it is PEP, not full
Pubsub). Since Service Discovery can also be used to discover other
types of services, it could be possible that the node is just being
queried to find out what kind of service it supports.
XEP-0060 mentions that events can be "transient" or "persistent", could
someoe please clarify what these are? I didn't find it very clear,
though I may have missed the definitions.
Transient means that items published to a node will not be retained for
later retrieval there, except if the pubsub#last-published feature is
supported, in which case, the node will retain the last item published
there... Persistent means that they will be retained up to the maximum
number defined by the option pubsub#max_items.
best wishes,
Brett
