[Standards] pubsub/pep auto-creation

Peter Saint-Andre stpeter at jabber.org
Fri Mar 23 17:35:37 UTC 2007

Rachel Blackman wrote:
>> 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 configuration!
> Great, except...
>> Configure once, publish from everywhere. Seems pretty simple to me. 
>> What am I missing?!?!
> ...you're missing that clients don't always behave as they should.

It seems wrong to design protocols based on the assumption that they 
will be implemented incorrectly. We don't want our protocols to be 
brittle, but I think the developers in our community are smart enough to 
do things right. And if they don't, we file bug reports. :)

> Sometimes because people don't understand the specification (witness how 
> many people got XEP-0115 wrong initially, based on recent discussion!), 

That's because the spec author (c'est moi) wasn't clear enough. The 
solution to that problem is to write clearer specs.

> sometimes because they decide 'well, I won't expose that particular bit 
> of information as a config, it'll just be all public' to save time or 
> whatever.

Given that we're talking about potentially exposing private information 
(e.g., my geolocation), assuming that all information will be public is 
a very bad idea!

> If every client can be trusted to 'play nice,' then you're right and 
> things are just fine as they are in the PEP spec.

Bug reports.

> It has been demonstrated amply in the past, however, that not every 
> client will play nice.  And so people will write workarounds.

Does designing workarounds into the protocol solve the problem?

> So, I think the part you're missing is that those of us arguing for 
> publish+configure are sort of looking ahead at, 'well, given that I 
> don't have any guarantee that Client Z is not going to be re-marking the 
> nodes all public every time it logs in, how can I still ensure the 
> proper behavior?'  

Beat up on the bad developers!

> Because if someone logs in with Client Z to try it 
> out and it changes the node configuration, and then logs in with your 
> client instead and discovers that say, geoloc is now going out 
> publicly... what will happen?  In my experience, it will be YOUR client 
> that gets the bug logged against it, NOT Client Z.

I think we'll discover pretty quickly which are the bad clients.

> So this is basically a 'if things go wrong, how do we fix it easily?'  
> And, of course, the only way to know that things HAVE gone wrong is to 
> check the configuration when publishing to check it against the 
> client-known preferences.

Every time? Just because you don't know which bad client the user might 
have touched in the interim? The same could be true of rosters, presence 
subscriptions, privacy lists, and many other things.

> Sure, the ideal is 'everyone just gets it right,' but how often does 
> THAT happen?  ;)

Well sure. :) So we need that certification program pronto. :)


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/4e4ea6af/attachment.bin>

More information about the Standards mailing list