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/
smime.p7s
Description: S/MIME Cryptographic Signature
