[Standards] PEP for Private Storage

[Peter Saint-Andre]

Richard Dobson wrote:
> One solution to the configuration problem that just popped into mind is 
> that maybe we could use a different namespace for Private PEP rather 
> than trying to lump it all into the exact same thing as the Public PEP, 
> this easily separates things out, completely avoids the configuration 
> issues for private storage as it would make it impossible for it to ever 
> be public.

What do you mean by "different namespace for Private PEP"? Do you mean 
the node ID (a la Joe's "+private" idea) or the protocol namespace? 
Because PEP just uses the pubsub namespaces in the protocol. I think all 
the profiles or subsets of pubsub should use the pubsub namespaces, no?

> Private PEP would use the exact same protocol as normal PEP but would 
> just be permanently restricted to private storage only, i.e. only your 
> own JID would be able to access it and receive events.
> 
> This means that there need not be much additional code as it would just 
> use the normal PEP engine built into the servers and clients only 
> differences would be a hard coded ACL and different namespace to 
> differentiate it from normal PEP, as far as I can see this makes things 
> very easy to implement, without any of the potensial configuration and 
> leaking problems with using normal PEP.

I agree with the need for a slot-in replacement for iq:private. I don't 
yet see how we can do that cleanly with a disco identity (pubsub/pep vs. 
pubsub/private) because your JID is going to be a virtual pubsub service 
for both. So we need to differentiate private nodes (= whitelist access 
model with no additional entities on the whitelist other than the 
account owner) from public nodes (= all other PEP access models). But I 
don't think it's a good idea to do that with the protocol namespace, 
since IMHO all the pubsub profiles should just use the pubsub namespaces.

But maybe I don't understand your proposal. :)

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- 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/20070404/2f1746ab/smime.bin