[Standards-JIG] Re: Historical XEPs

Maciek Niedzielski machekku at uaznia.net
Thu Nov 16 22:38:46 UTC 2006

Peter Saint-Andre wrote:
> Maciek Niedzielski wrote:
>> Peter Saint-Andre wrote:
>>> Maciek Niedzielski wrote:
>>>> Yes, XML Storage doesn't need PEP: it just needs well-know PubSub node.
>>>> But if we already decided to have IM-PubSub for PEP, it doesn't make
>>>> sense to write another spec for private nodes and expect server
>>>> developers to implement it.
>>> In fact it's already pretty much in PEP, since a PEP node with an access
>>> model of "whitelist" and no entities on the whitelist effectively
>>> results in a node that enables private data storage. However, nothing in
>>> XEP-0163 (or elsewhere) really explains how that would work in detail.
>> Wasn't this added just to make private storage via PEP possible? ;)
>> It wasn't a part of older PEP, the extended-presence PEP. Now we have
>> PErsonal Pubsub ;)
> Well, the "whitelist" access model is part of the core pubsub protocol.
> And the node owner should always be allowed to subscribe or retrieve
> items. So a "whitelist" access model with no subscribers other than the
> other should enable the owner to use that node however they want, i.e.,
> personal storage / eventing for the owner's resources. Or so it seems to me.

Yes, but (if I can recall well) first versions of the XEP didn't require
PEP service to implement much more than needed for the smart defaults,
so you could have a PEP service without "whitelist" access model.

But it's not so important now.

Maciek                       A: It's against natural order of reading.
 xmpp:machekku at uaznia.net   Q: Why is that?
 xmpp:machekku at chrome.pl   A: People answering above quoted text.
                          Q: What's the most annoying on newsgroups?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061116/13755916/attachment.sig>

More information about the Standards mailing list