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

Peter Saint-Andre stpeter at jabber.org
Tue Dec 12 23:11:17 CST 2006

I've started to incorporate our chatroom / mailing list discussion here:




Peter Saint-Andre wrote:
> 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:
> rsakey
> x509cert
> 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
-------------- 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/20061212/9e798159/smime.bin

More information about the Council mailing list