[Standards-JIG] XEP-0163: PEP updates

Ian Paterson ian.paterson at clientside.co.uk
Wed Jan 3 19:10:39 UTC 2007

Peter Saint-Andre wrote:
> The motivating example here is public keys (see XEP-0189), since you 
> might have RSA keys, DSA keys, X.509 certs, etc.

Hmm, it's an example, but I'm not sure it's "the motivating example". 
Clients are likely to support muliple public key formats (to ensure 
compatibility), and key publishing is a relatively rare event, so I 
doubt clients will typically mind receiving publishing events for all 
key types. If I'm wrong, and they do care, then XEP-0189 could always 
specify multiple registered nodes (instead of multiple "middle layer" 
wrapper elements/namespaces).

In fact XEP-0189 might motivate a design closer to v1.0 of PEP... 
Although clients should store their own secure copies of other user's 
public keys, some clients will not have access to sufficient secure 
storage space and will instead choose to store only the key fingerprints 
- requesting the full keys whenever they are required.

Therefore, the ideal design for XEP-0189 might be for PEP to allow the 
publishing client to always use the registered NodeID specified in the 
XEP (e.g., 'urn:xmpp:pubkeys') and set the (non-opaque) ItemID of each 
key to be the fingerprint of the key. Clients would then be able to 
request any specific key straight-off without having to perform any 
other PEP query.

I tend to agree with Kevin and Remko's comments (see extracts below) - 
that although "pubsub#type" filtering adds useful functionality (and 
could be used instead of registered NodeIDs to implement XEP-0189 and 
the other XEPs built on PEP):

1. It might be an unnecessary complication of PEP.
2. XEPs requiring multiple nodes that serve up the same kind of payload 
(e.g. blog feeds) could/should be built on XEP-0060 instead.

Of course someone might still come up with a really motivating example 
to change our minds.

- Ian

Kevin Smith wrote:
> On 3 Jan 2007, at 03:19, Peter Saint-Andre wrote:
>> Remko Tronçon wrote:
>>> Removing the one-to-one mapping introduces some problems
>>> ...
>>> I realize that hardcoding the namespace in the pubsub node might not
>>> be in line with the pubsub spec, but i'm affraid we will be putting
>>> burden on the client again
>>> ...
>>> Isn't multiple items per node enough to solve the issues
>> Well, I'm not yet totally convinced that the one-to-one mapping is 
>> truly evil. :-)
> [The loss of the one-to-one mapping] may not be truly evil, but it 
> certainly penalises the simplicity, and I'm not sure yet that we gain 
> anything by it.
>> You raise some good points. The concern people have is that you might 
>> legitimately need or want to have multiple nodes that serve up the 
>> same kind of payload.
>> Now there are two possible responses:
>> 1. If your data feeds are that complicated, just use pubsub.
>> 2. Let's modify PEP in some way to support the desired complexity.
> It seems to me that people would like everything to be shoehorned into 
> PEP - why is this? Personal keys seem like they're probably reasonable 
> to be PEPped, but blogging seems well outside that realm to me.
>> I like the simplicity of PEP. The whole point of PEP is simplicity. 
>> If we make PEP more complex, then it becomes unnecessary.
>> In summary, I am loath to give up the simplicity of PEP, but I want 
>> to make sure we can solve the problems that people want to solve
> Well, it's clear we can't solve all problems with PEP - pubsub was 
> meant to solve all problems,  and is excessively complex for some 
> uses, if we let PEP grow to solve all problems, it'll a) be too 
> complex too, and b) be pubsub on a JID. If what people want is to 
> always have pubsub on a JID, we should probably address that 
> independently.

More information about the Standards mailing list