[Standards] XEP-0060: publish-options

Peter Saint-Andre stpeter at jabber.org
Tue Jul 17 22:10:45 UTC 2007

At http://mail.jabber.org/pipermail/standards/2007-July/015878.html and
other messages in that thread, we talked about a kind of publishing an
item only certain preconditionsn are met. Ralph Meijer mentioned that we
could broaden this to include publish-options other than preconditions:


So we might have something like this:

<iq type='set'
    from='hamlet at denmark.lit/blogbot'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
          <link rel='alternate' type='text/html'
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
        <field var='pubsub#access_model'>

It seems to me that the following rules would apply:

1. The <publish-options/> element MUST contain a data form (see XEP-0004).

2. The FORM_TYPE of the data form MUST be
"http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

3. Fields registered with the XMPP Registrar for that FORM_TYPE MUST
specify how they are to be handled by the form-processing entity.

I understand handling of fields that are preconditions, it's what we
outlined before:

1. 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).

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

3. 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.

What other field types do people envision for publishing options? Here
are some possibilities:

- publish this item with the specified metadata

- publish but override node configuration for this item only (yes this
would enable per-item access controls, but let's not talk about that too
loudly and maybe people won't notice... ;-)

Naturally it's up to the implementation or deployment whether it
supports any of these field types.



-------------- 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/20070717/11a3bd0d/attachment.bin>

More information about the Standards mailing list