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

[Ian Paterson]

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.

Discovery is fine when users are browsing data. But for cases where the 
client already knows exactly what it needs, if it has to perform discovery 
steps before it can actually request the data then IMO that is bad:
1. The need for asynchronus code goes against our simple client mantra
2. Introduces delays (bad for users)
3. More network traffic (especially if you need to disco#info multiple 
items)

For example, imagine we were to write a Web of Trust XEP based on PEP. If we 
allow well-known node names then, to discover if Peter is reliable I can 
make a single request to each contact on my roster (see stanzas below). This 
would not be possible if nodes (and item IDs) are not well-known.

<iq type='get' to='ralphm at ik.nu' id='pep1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:wot'>
      <item id='stpeter at jabber.org'/>
    </items>
  </pubsub>
</iq>


<iq type='result' to='ian at zoofy.com' from='ralphm at ik.nu' id='pep1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:wot'>
      <item id='stpeter at jabber.org'/>
        <level xmlns='urn:xmpp:wot'>9</level>
      </item>
    </items>
  </pubsub>
</iq>

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?


Finally, can I please also get people's feedback on the idea for PEP and/or 
pubsub posted to the list on Nov 19th:

"To make PEP-based Private Data Storage easy for clients, we
would need to allow automatic node creation for persistent as well as
transient nodes (in addition to for any access model). For example by
supporting a <configure/> sibling of the <publish/> element (see stanza
below)? The <configure/> element would be ignored if the node already
exists. This would also be a nice short-cut for clients to use in cases
other than Private Data Storage."

<iq from='juliet at capulet.com/balcony' type='set' id='create-bookmarks'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/prefs'>
      <item id="fje98djh2j9s">
        <storage xmlns='storage:bookmarks'>
          <url name='Complete Works of Shakespeare'
               url='http://the-tech.mit.edu/Shakespeare/'/>
        </storage>
      </item>
    </publish>
    <configure>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#node_config</value>
        </field>
        <field var='pubsub#access_model'><value>whitelist</value></field>
        <field var='pubsub#persist_items'><value>1</value></field>
      </x>
    </configure>
  </pubsub>
</iq>


- Ian