[Fwd: Re: [Council] meeting log 2006-11-29, PEP]

Peter Saint-Andre stpeter at jabber.org
Fri Dec 1 12:12:13 CST 2006


-------- Original Message --------
Subject: Re: [Council] meeting log 2006-11-29, PEP
Date: Fri, 1 Dec 2006 07:51:17 -0700
From: Joe Hildebrand <jhildebrand at jabber.com>
To: XMPP Council discussion list <council at jabber.org>
CC: Peter Saint-Andre <stpeter at jabber.org>
References: <000501c71464$add21560$0302a8c0 at IANSHARP>
<1164885220.2123.28.camel at se-135> <456F1700.8050909 at jabber.org>

cc'ing stpeter, in case I can't post to the council list...

What about a item type that can be published as a pointer to another

<iq type='set' from='portia at merchantofvenice.lit/pda' id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://www.w3.org/2005/Atom'>
      <item id='a1s2d3f4g5h6bjeh936'>
        <item xmlns='http://jabber.org/protocol/disco#items'

servers could know about this, and forward subscriptions based on
registered interest for the original node.  The hard part is keying
the publishes to the external node, so that recipients know why they
got this bit of data published to them.

On Nov 30, 2006, at 10:38 AM, 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
> -- 
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.shtml

Joe Hildebrand

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/20061201/3f531e69/smime.bin

More information about the Council mailing list