[Council] meeting log 2006-11-29, PEP

Peter Saint-Andre stpeter at jabber.org
Thu Nov 30 11:38:08 CST 2006

Ralph Meijer wrote:
> On Thu, 2006-11-30 at 09:48 +0000, Ian Paterson wrote:
>> Hi,
>> I'm +1 for PEP enabling multiple nodes under one namespace. This will be 
>> useful for some use cases (e.g. several blog feeds per person).
>> However, IMHO we *also* need to keep the possibility of well-known node 
>> names (and well-known item IDs). Well-known is good because it eliminates 
>> unnecessary discovery steps.
> Well, if you allow multiple nodes under one namespace, this doesn't
> work. There can be only one node at a well-known node, so you need to
> discover the node's identity to see if it is a leaf or collection.

I think the phrase "multiple nodes under one namespace" is a bit
confusing. What we're talking about here is the ability to maintain and
publish to multiple nodes with the same payload type.

Now I suppose it is also possible to maintain a collection node that
aggregates syntactically similar but semantically distinct leaf nodes,
but that is a separate issue.

So let's take the example of public keys. Maybe I have two different nodes:


Both nodes have a payload type of "http://www.w3.org/2000/09/xmldsig#"
(see XEP-0189). But they are not necessarily aggregated via a collection
node. However, we might want to maintain a registry of well-known PEP
nodes so that "rsakey" and "x509cert" are reserved and are known to have
a payload type of "http://www.w3.org/2000/09/xmldsig#".

>> Another example might be if Peter sends me a signature and the fingerprint 
>> of his public key, but I have no copy of his public key, then it is easiest 
>> for me to make a straight request for the public key 
>> (node:'urn:xmpp:pubkeys', id='thefingerprint'). I can only do this if PEP 
>> allows the pubkeys XEP to specify well-known node names and item ID values.
>> Note: For these two example use cases we need to be able to persist more 
>> than one publish event. i.e. persist multiple items independently of when 
>> they were published. Do people think this requirement could be added to PEP?

I don't quite follow the need for well-known ID values -- I guess you'd
use the same node ("rsakey" or whatever) to publish the pubkey and the
signature and the fingerprint, and you'd want the recipient to be able
to retrieve each one separately?

> I suppose it could. I see that these use cases want to use PEP for
> storage, and not necessarily for its pubsub behavior. For the latter the
> actual node name is rarely important, but for the former the node is the
> primary entry point. We seem to be struggling for a way to merge the two
> behaviors into using one protocol.
> I have to think more about this.
>> Finally, can I please also get people's feedback on the idea for PEP and/or 
>> pubsub posted to the list on Nov 19th:
> As the particular node would only have be created once in the lifetime
> of the user account, I don't think we should do this.
> If you meant to do access control on item level, I tend to say feature
> creep.

Didn't we talk about that before and pull away from it?


Peter Saint-Andre
Jabber Software 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/council/attachments/20061130/1e5696d1/smime.bin

More information about the Council mailing list