[Standards] publish+configure again

Pedro Melo melo at simplicidade.org
Fri Mar 30 09:47:03 UTC 2007

Hi Ralph,

On Mar 30, 2007, at 8:44 AM, Ralph Meijer wrote:
> The reason I always look to XEP-0060, too, is that I envision that
> people want more than what PEP provides now, in the future. In some
> other thread there was mention of more access control on what you
> publish. Things like being able to configure your subscription will be
> interesting, too (only send me notifications when my presence is
> 'online' or 'chat').

I'm a big fan of XEP-0060, but for simple IM, I think we will only  
need PEP at our shop.

We do want to use XEP-0060 for Atom notifications for example. This  
is working right now. Our current notification service uses a  
XEP-0060 payload. We don't have the subscription part yet (it's done  
over the web) but that will come in time.

For global XEP-0060 deployments, in which XMPP becomes the standard  
notification protocol for whatever, I think we will need to add  
support for local proxy, in which I can subscribe to your remote  
nodes via my own server XEP-0060 component. This will allow basic  
multicast-like delivery.

Without it, I don't think XEP-0060 will have much use for us, for  
large scale deployments. But I think I'm going of topic now :)

> So, I think for Personal Eventing, server implementations will  
> start off
> with PEP as it is now, and gradually add features from XEP-0060. We  
> have
> a lot of discoverable features, so clients can detect what's there.

I know that you see PEP as a subset of XEP-0060, and I agree that  
right now there is no reason not to be. But I think we should have an  
open-mind that PEP might evolve into a separate path, if we ever need  
it to.

> * If we decide to add p+c, will it be required to implement?

I would hope so, but only for PEP, not necessarily XEP-0060 requirement.

> * Will the regular node creation flow and configuration still be in  
> PEP?

I don't have an opinion right now on this one. I think mobile client  
developers would like it to be there, given that they have more bw  

> * Client authors: would you implement that flow, too?

Not in the first implementation.

> Just like Magnus is saying, I think for most non-private-storage use
> cases for PEP, you would almost never need/want to change the
> configuration of a node after it has been created.

More or less: I would use p+c with geoloc for example, but not for  
use tune. Both are not private-storage type of node.

> * Client authors: would you send configuration forms every publish
>   request?

Only on the ones we want to make sure the configuration is kosher.  
For us, that means for those nodes in which we think the customer is  
very concern about privacy, in the sense that the information will  
only be sent to the proper contacts. This is very subjective and  
sometimes subject to local decisions, I think. Something that  
europeans regard as not terrible important privacy-wise, japanese  
people might see that as totally private.

That's one of the reasons we want this: we don't believe that what is  
the default configuration to publish protocol X is something that  
should be in the standard, given that it is a cultural thing.

> Actually I think this holds for the private storage case as well,  
> but it
> seems some client authors are afraid that other clients will cause
> havoc.

Yes. At least we are.

> * Could someone explain this bit for me?

See above: we don't believe that the private/public nature of each  
node is something that can be made a standard given all the culture  
differences around. So we expect that client authors will eventually  
allow customers to decide the level of  trust/security/privacy they  
want per node. This might be shocking for some, but it is a concern.

Even with simple user tune stuff, we already have customers who see  
that with different privacy levels, ranging from roster to public.

> * If you don't trust the other client, how can you be sure it doesn't
>   mess up other things like the roster, your password or misuse the
>   nifty remote control support you might have added?

I don't have it. But there are other solutions for those already.  
There wasn't one for PEP.

For password, for example, we just don't allow it to be changed over  
the protocol.

But my main concern with pep is that I don't believe all the clients  
will have the same ideas about privacy levels for each node. That is  
what concerns me. I might use the word "rogue clients" before and  
that might have been a bit harsh. Even "good clients" with different  
ideas from my own about the privacy level of some node might be a  

For example, my mobile phone has assisted GPS (or whatever is  
called), that allows me to know my position with a reasonable error.  
I might want to have my jabber client on the mobile phone to publish  
that to a restricted set of friends, but my laptop to publish to my  
entire roster.

The reason to want this, is that I want all my buddies to know where  
am I working at the moment, but I only want my family and closest  
friends to know how I get from one place to the other, or where am i  
right now.

So even with good clients, trusted ones, I see the need to have  
different settings per publish.

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
Jabber ID: melo at simplicidade.org
Use Jabber!

More information about the Standards mailing list