[Standards] private storage revisited

Peter Saint-Andre stpeter at jabber.org
Fri Jul 6 22:59:11 UTC 2007

Thanks for the helpful post, Ralph. Comments inline.

Ralph Meijer wrote:

> First of I want to restate the issue: the publisher wants to publish an
> item to a node that has a certain access model. There are two ways to
> solve this:
> 1. No auto create.
> In this case, there is no magical node creation on publish. A publish to
> a non-existing node fails, the client will create a node with the
> desired configuration and then republishes.

I agree with you that this is fine behavior. But we let auto-create
sneak in last year and people don't want to let go of it now...

> 2. Auto create.
> Here, as long as all nodes are to be created equal, with the default
> configuration, all is well. However, if you are having a service that
> hosts both extended presence nodes and private access nodes, you will
> want to have different configurations for the nodes that are created
> automatically on publish. Obviously you can check before each publish,
> but that is undesirable for various reasons.


> I still oppose the idea of publish+configure because it is not what it
> seems. What we want is this: on publish, if the node exists, only
> process the request if the node has this access model, or, if the node
> does not exist, create a node that has this access model.


> So whatever you would add to the request, doesn't actually
> (re-)configure the node. It is some kind of precondition for the publish
> request to succeed. The auto node creation is a side effect.

Also correct.

> But having the one-trick pony of an attribute for the access model feels
> icky to me. What if we do allow the publisher to attach a form with
> 'publishing options', 'publishing conditions', or whatever we want to
> call them? Something not called <configure/>.

That seems acceptable to me, because as you say it's not really a
configuration. And people seem to be interested only in access models,
not in configuring every possible option (at least for now as you say).

> For now we would only have a check on the access model in there. But it
> does leave the door open for future enhancements.

Though probably *not* every possible configurable option (friendly name
of the node, default language, or whatever).

> Ian seemed to agree on this idea.


> I do want to note that prefer 1) from above more, but if we have 2),
> like we do now, I think this is the next best thing.

Or the next-least-worst thing. ;-)

So we'd have something like this:

<iq from='juliet at capulet.com/balcony' type='set' id='foo'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/activity'>
        <activity xmlns='http://jabber.org/protocol/activity'>
          <text xml:lang='en'>My nurse's birthday!</text>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
        <field var='pubsub#access_model'>

If the node exists and the precondition is not met (in this case, if the
access model is something other than "whitelist"), then the publish
fails with a suitable error condition (probably <conflict/> along with
some pubsub-specific condition).

If the node exists and the precondition is met, then the publish succeeds.

If the node does not exist, then the service auto-creates the node with
default configuration in all respects except those specified in the
preconditions (in this case, the node would be created with an access
model of "whitelist") and the publish succeeds.



Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070706/bb1abd51/attachment.bin>

More information about the Standards mailing list