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

Peter Saint-Andre stpeter at stpeter.im
Mon Sep 22 22:13:34 UTC 2008

Peter Saint-Andre wrote:
> On 05/23/2008 7:26 AM, Florian Zeitz wrote:
>> Hash: SHA1
>>> It seems rather messy to delete the node and then re-create it all the
>>> time. For example, lots of geolocation services enable you to specify
>>> certain locations that are private. So when you move to a private
>>> location, you want to stop publishing temporarily. But you might start
>>> publishing again 20 minutes later or whatever. So why delete the node
>>> (along with all its subscriptions) only to re-create it so soon?
>>> Peter
>> Agreed. Deleting and recreating nodes probably creates (server) overhead
>> I didn't really think about. Probably retracting the node (which is what
>> Miranda, Psi and Gajim SVN do) is equally bad and has the added penalty
>> of not being required for PEP.
>> On the other hand defining empty states (or a <mu /> element as Dave
>> Cridland suggested) doesn't sound right to me either, because User
>> Tune/Nickname/Mood/Activity/Geolocation/Weather/Clothing as I understand
>> it mainly defines a generic XML format to express "things".
>> Outside the context of PEP lack of information in this XML is useless.
>> The XML just wouldn't be present in the first place. BUT in PEP this
>> requires deleting/retracting the node...
>> Another thought: Delete nodes, BUT make sure it's a rare case.
>> Normally, as you point out, people who published information will do it
>> again. The node should only be deleted if they really don't want to
>> publish any information.
>> When this is the case is different for every "User *", but I think the
>> XEPs can be defined in a way that it is a rare case that people don't
>> want to publish any information.
>> So let's look at this per XEP:
>> User Tune:
>> normally people will listen to music or not and publish the song or a
>> stopped state accordingly. The case that people are secretly listening
>> to a song is probably relatively rare.
>> User Mood:
>> This has the problem that not every possible mood is present. Adding a
>> "something else" option might be a solution here (Or is it valid to only
>> send <text />? I think clients don't allow it...). I personally wouldn't
>> publish my mood at all (maybe in rare cases) because I think it's to
>> personal. People who decide to publish it will probably do it all the time.
>> User Activity:
>> Same as User Mood IMHO. A "doing something else" state would help .
>> User Geolocation:
>> Defining a <private /> state would help. Admittedly this is very similar
>> to providing no information at all which is what I didn't want to
>> define, but IMHO this privacy statement is still a bit different from no
>> information.
>> User Nickname:
>> People who don't want a nickname any more will probably not want one for
>> a longer period of time.
>> I think if this changes were made nodes wouldn't be deleted to often,
>> but still could be if no information is to be published, in which case
>> deleting the node is the "right thing" to do IMHO.
> Those proposals are fine with me.

What about defining the following in XEPs 107, 108, etc.?

<iq type='set'
    from='juliet at capulet.lit/ca486eba-0f9a-11dc-8835-000bcd821bfb'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/mood'>
        <mood xmlns='http://jabber.org/protocol/mood'/>

<iq type='set'
    from='juliet at capulet.lit/ca486eba-0f9a-11dc-8835-000bcd821bfb'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/activity'>
        <activity xmlns='http://jabber.org/protocol/activity'/>

That is just like what we do in User Tune.


Peter Saint-Andre

More information about the Standards mailing list