[Standards] XEP-107 and XEP-108: Empty Value?

Peter Saint-Andre stpeter at stpeter.im
Mon May 5 03:54:37 UTC 2008


On 05/04/2008 6:30 PM, Florian Zeitz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephan Maka wrote:
>> No, I think the missing part is that only some PEP extensions include
>> an empty variant of their XML representation to reset the indicated
>> event node. There is a fine »Delete And Notify« request in section
>> 7.2.2.1 of XEP-0060 (Publish-Subscribe), but no PEP XEP is using it,
>> although it is the generic PubSub way of retracting an item.
>>
> Actually no PEP extension includes an empty variant of their XML
> representation. The only PEP extension that has an empty variant defines
> it to mean "I have stopped music playback" and not "I'm not sending you
> information any more".
> PEP XEPs don't have to "use" anything specifically they can just rely on
> what is defined in XEP-0163. Item retracting isn't really needed see below.
> 
>>> But I don't know why you think it is optional. XEP-0163 says a PEP
>>> service MUST implement it. I think client implementations should
>> From http://www.xmpp.org/extensions/xep-0163.html#defaults
>> | 5. Recommended Defaults
>> | 
>> | A PEP service MUST:
>> | 
>> |     * Support the node discovery, node creation, node deletion,
>> |       publish item, subscribe, unsubscribe, and item retrieval use
>> |       cases specified in XEP-0060.
>>
>> node deletion:
>>     http://www.xmpp.org/extensions/xep-0060.html#owner-delete
>>
> Yes I confused node deletion and item retraction somehow. I'm sorry
> 
>> Yip, and this should be specified. Gajim trunk is sensible to the
>> currently-specified empty element event.
>>
> Yes it is, and that actually is wrong.
> Only XEP-0118 (User Tune) actually defines an empty element event. All
> others don't, but Gajim reacts to empty elements and actually sends them
> to for all the XEPs it supports (Tune, Activity and Mood).
> 
> As far as I can tell there are currently 3 behaviors as far as
> retracting information:
> 1. Send an item retraction as defined in 7.2.2.1 of XEP-0060 (PubSub)
> This is what Miranda and Psi do.
> It's bad because not all implementations support it and supporting it is
> not required in XEP-0163 (PEP).
> 
> 2. Send empty elements
> Gajim does this if you turn off sending events.
> 
> 3. Don't allow it
> Gajim and Pidgin don't offer the possibility to retract information in
> the UI. Gajim as mentioned above sends empty elements if you turn
> sending PEP events off completely, but otherwise it does nothing.
> 
> 
> My proposed solution:
> What XEP-0163 (PEP) does require is node deletion. For some reason no
> implementation I know off does support this, but IMHO it is actually the
> way to go.
> PEP has the concept of one node per namespace, so to retract information
> from a certain PEP extension you just have to delete the node with it's
> namespace as name.
> 
> This has two benefits.
> 1. Theoretically every implementation supports it as it is required by
> XEP-0163.
> 2. You don't have to specify notify="1" to make it work, as is the case
> for <retract/> (Well maybe not really a benefit but something I stumbled
> over ;) )

Hmm. We didn't think about this case enough when we defined all these
personal eventing payloads.

IMHO, for personal eventing there is a difference between (1) deleting
an event and (2) setting your state back to neutral. #1 rewrites history
by effectively saying "well no I didn't have that last mood, please
ignore it" whereas #2 says "yeah I was angry before but now I'm not". If
we use personal eventing payloads as input to lifestreaming systems then
I think we want to preserve the history but define neutral states for
all of these.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


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


More information about the Standards mailing list