[Standards] pubsub/pep auto-creation

Peter Saint-Andre stpeter at jabber.org
Fri Mar 23 16:51:47 UTC 2007

I'm working hard to get updated Jingle specs out today so I don't have a 
lot of time for this topic, but I too was thinking about user interface 
on the plane last night so I'll reply here.

Ian Paterson wrote:
> Ralph Meijer wrote:
>> On Thu, 2007-03-22 at 23:09 +0000, Pedro Melo wrote:
>>> I think what me and others are saying is that we don't trust the 
>>> node  to keep its configuration, and prefer to send the 
>>> configuration  parameters on each publish to make sure they are correct.
>>> if I only connect with my usual client, that would be wasteful, I  
>>> agree. But if we start using multiple clients/resources  (PC, Mobile  
>>> phone, agents) then trusting the node configuration to stick is tricky.
>> Like Peter, I don't understand this. Why wouldn't the configuration
>> stick? Are we now assuming programming errors or deployment issues to
>> guide our protocol design?
> No, the user may simply be logged in with another client that may change 
> the configuration. Such changes may be legitimate since when specifying 
> a well-known node, a XEP may make the value of a configuartion field 
> optional, or it may not specify a value for the field at all (perhaps 
> because that configuration field wasn't even defined when the XEP was 
> written).
> I think we need to consider the likely user interface for a real life 
> example.

I agree. Let's say that I want to start publishing my geolocation info. 
I will explicitly set that up via the client I'm using at the time and 
will set the node config to (say) publish only to my Friends roster 
group. So the PEP service will store that preference for all eternity, 
until I decide to change it (as Ralph says, a rare occurrence compared 
to the volume of publishes). If I use another client, that client should 
respect the previous node configuration and not change it willy-nilly, 
or even show it to me at all (assume that I knew what I was doing when I 
set up the node). After all the same individual (me) is controlling all 
the clients that may interact with the PEP service so I don't understand 
why the config would change all the time. And storing the preference in 
iq:private seems really silly to me, because the PEP service itself 
already has a way to store the preference -- it's called the node 

> The example being used on this list has been of a node that may be 
> legitimately configured to be "public" or "private". For example, 
> imagine a "Home Address" node. The client will probably present the user 
> interface for the node in a dialog box with the address fields, and with 
> a checkbox "Publish my Home Address publicly".
> That user interface will force the client to either:
> 1. configure the node every time it publishes, or
> 2. request the configuration of the node before every publish (the user 
> may be logged in with another client) and then, at least some of the 
> time, reconfigure the node before publishing.

Why? You don't need to configure the node every time you publish and you 
don't need to request the config every time. Just assume that the user 
set it up according to their preferences the first time around. I told 
the PEP service that I wanted my geolocation info to go to my Friends 
group, so don't please bother me about it again -- that decision was 
made and I'm quite happy about it, thank you. If this is the first time, 
you get an error flow and prompt the user to answer the question "who 
should be able to see your geolocation information"? The user answers 
that question once and never fiddles with it again (unless they really 
want to).

Configure once, publish from everywhere. Seems pretty simple to me. What 
am I missing?!?!


Peter Saint-Andre
XMPP Standards Foundation

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

More information about the Standards mailing list