[Standards] Removing PEP nodes?

Peter Saint-Andre stpeter at jabber.org
Thu Aug 16 15:05:40 UTC 2007

Ralph Meijer wrote:
> On Thu, 2007-08-16 at 13:09 +0200, Magnus Henoch wrote:
>> Peter Saint-Andre <stpeter at jabber.org> writes:
>>> Andreas Monitzer wrote:
>>>> On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote:
>>>>> Andreas Monitzer wrote:
>>>>>> Hi,
>>>>>> I'm currently implementing PEP into libpurple, and have some issue
>>>>>> I can't quite find explained in the XEPs: How do I remove a
>>>>>> personal event?
>>>>> I think you would use the syntax defined in XEP-0060:
>>>>> http://www.xmpp.org/extensions/xep-0060.html#publisher-delete
>>>> What should I supply as the item id? I don't have that value.
>>> Why not? You should have received it when the PEP service sent it to
>>> you (the account owner automatically receives a copy).
>> The only reference to this that I can find is section 12.9 of
>> XEP-0060, Auto-Subscribing Owners and Publishers, which says that the
>> service MAY do so.  Did I miss some other place?  Is there anything
>> PEP-specific that specifies this behaviour?
> In both the current 1.0 (section 8) as well as the upcoming 1.1 version
> of XEP-0163 [1], there is the mention of notifications to resources of
> the node owner. The latter mentions that this is subject to filtered
> notifications (section 10.2 of the upcoming 1.10 version of XEP-0060
> [2]). It seems to me that what was meant is that your own account is
> assumed to be in the group of entities that will receive notifications
> when a resource sends the proper entity capabilities with +notify
> suffixes.

Right. I'll check the working copies of XEP-0060 and XEP-0163 to make
sure that this is clearer. The text should say that the service MUST
send a notification to the account owner (subject to caps-based
filtering etc.).

> Reading section 10 of XEP-0060 1.10pre5 again, I am wondering if the
> implementations working on PEP on the server side actually implemented
> it like this. As it is written now, I can have a node with identifier
> 'blah' that sends out notifications with geoloc payload. Clients sending
> the http://jabber.org/protocol/geoloc+notify feature would also receive
> these notifications. I am also wondering how clients would handle that.

Reports from the field would be appreciated. :)

> On item identifiers, they are optional in the publish request, and if
> not provided the server must generate an identifier when the node is
> persistent. If a publisher should send along an item identifier depends
> on how the node is supposed to be used.


> We used to have an explicit 'current' item identifier for the different
> extended presence specs, but these seem to have been removed. I always
> assumed extended presence to have a more transient notion than one which
> may persist a history of changes (as each publish gets a unique id if
> you don't provide one). Peter, could you comment on this?

I don't think the "current" ItemID was ever meant to have special
meaning, it was just what pgmillard put into the examples. We removed
that so that people would no longer get confused.

> In general I think you should simply provide an identifier if you want
> to be able to retract them at a later point in time. I don't think we
> ever discussed how retraction works in the context of PEP.

Any use case not discussed in PEP is to be handled as defined in
XEP-0060. That applies to item retraction as well.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070816/292a07d7/attachment.bin>

More information about the Standards mailing list