[Standards] Re: [Standards-JIG] XEP-0163: PEP updates

Peter Saint-Andre stpeter at jabber.org
Thu Jan 18 16:05:10 UTC 2007

Ian Paterson wrote:
> 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.

That sounds good to me.

> 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.

Since no one has come forward with a really motivating example, I take 
it that the trial balloon of PEP 1.1 has been shot down. Therefore I 
have reverted CVS back to the 1.0 version.

As you were...


Peter Saint-Andre
XMPP Standards Foundation

-------------- 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/20070118/41635bc5/attachment.bin>

More information about the Standards mailing list