[PubSub] PEP PIP PAP PUP -- POP!

Peter Saint-Andre stpeter at stpeter.im
Tue Apr 7 16:04:36 CDT 2009


On 3/6/09 7:36 AM, Dirk Meyer wrote:
> Hi,
> 
> the thread is a bit older but I'm sure there was a solution. I'm working
> on XEP-0189: Public Key Publishing and it has the following
> requirements:
> 
> 1. The pubsub-on-a-jid feature used by PEP is very nice. I do not want
>    to search for my XMPP server. I also only have one bare JID as
>    publisher.

IMHO XEP-0189 is a reasonable use of PEP.

> 2. There was some discussion at the Summit if PEP has a history. Maybe
>    it makes no sense of 'eventing', XEP-0189 requires it. So maybe we do
>    not call what we do in XEP-0189 PEP. Anyway, the pubsub-on-a-jid
>    feature together with history should work.

I see no reason to forbid history in PEP.

> 3. I want to have two nodes for public key publishing. One for all my
>    devices my friends are allowed to see and one to manage a list of
>    friend certificates only my devices can access. So two nodes with
>    different name and different config but the same namespace.

Yes, I think we clarified that in Brussels by proposing to get rid of
the one-node-per-namespace rule. I have yet to update the PEP or PubSub
specs along those lines.

> Now back to the thread:
> 
> Ralph Meijer wrote:
>> On 2009-02-11 18:05, Peter Saint-Andre wrote:
>>> Right, but that can be pubsub-on-a-jid -- I don't think we want to
>>> restrict a virtual pubsub service associated with a bare JID to be all
>>> and only "PEP".
>> No, I'm saying that the default node configurations of all
>> pubsub-on-a-jid implementations would at least be compatible with the
>> smart defaults' as defined in XEP-0163. The alternative is that
>> existing PEP clients are going to discover stuff about the nodes they
>> want to subscribe to, or create and publish to. This kind of negates
>> the existence of XEP-0163. That may not be as bad, though.
> 
> So the defaults from pubsub-on-a-jid is based on PEP: no history. But I
> should be able to change that by setting pubsub#persist_items and
> pubsub#max_items to something I like for that use case.

Yes, I think so.

>>> I'm in favor of defining reasonable semantics for a given payload type.
>>> For rich presence that is similar to presence (what's in PEP now). For
>>> Atom or public keys or whatever, that might be something different. But
>>> I need to think about it some more before I come to any hard conclusions
>>> on the topic...
>> We seem to disagree at this point.
> 
> Speaking of payload types. I want to have two nodes based on the same
> namespace. How should I call these? I can't use urn:xmpp:tmp:pubkey for
> both nodes. Maybe add an extra 'name':
> 
> urn:xmpp:tmp:pubkey;devices
> urn:xmpp:tmp:pubkey;friends

I would change ";" to ":" but that's just aesthetics.

> The auto-subscribe feature would act on the URN and the enhanced
> version. So I can provide urn:xmpp:tmp:pubkey+notify and get devices and
> friends (everything from that namespace) or I can only provide
> urn:xmpp:tmp:pubkey;devices+notify and get only device information. The
> handling of ';' may not be the correct usage of an URN, but I guess it
> should give you an idea.

I think we agreed that +notify matches on the NodeID, not the payload
namespace. Once we remove the one-node-per-namespace rule, this implies
that you would advertise support for the following:

urn:xmpp:tmp:pubkey:devices+notify
urn:xmpp:tmp:pubkey:friends+notify

However, advertising support for urn:xmpp:tmp:pubkey+notify would give
you nothing, because there would not be a node with that name.

Or so it seems to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090407/bb1b3efb/attachment.bin 


More information about the PubSub mailing list