[Standards-JIG] JEP-0060 Implementation issues

Ralph Meijer jabber.org at ralphm.ik.nu
Sat Oct 30 21:49:36 UTC 2004


Hi,

While rewriting Idavoll, an implementation of a pubsub service as described
in JEP-0060, I have encountered a few issues with the specification. I keep
a list of these in the source code repository at JabberStudio, but I thought
I'd already share what I have encountered so far, and possible solutions.

The following is based on revision 1.78 of jep-0060.xml in CVS.

Issue #1
--------

Node configuration is optional. If node configuration is not supported by an
implementation, what is sent back to a client that sends a node creation
request with a configure node attached?

Clearly this is not correct behaviour since the client should have first gotten
a configuration form from the service. Because the service doesn't implement
node configuration, the request for such a form should have been rejected
in the first place.

Possible solution: send a not-acceptable stanza error with a
node-not-configurable error attached.

Issue #2
--------

Services may implement notifying subscribers of retraction of previously
published items from a node. On top of that, services may also support
purging all items from a node. Section 8.2.4 (Purge All Node Items) states
that, when purging all items, notifications should be sent out as if all
items were retracted one by one.

Clearly, when a lot of items are present in the persistent storage for a
particular node, purging such a node would generate a potentially huge amount
of traffic.

Possible solution: introduce a new type of event notification for purging
a node by adding a <purge/> element to the pubsub#event namespace and using
it like this:

  <message to="subscriber1" from="pubsub.jabber.org">
    <event xmlns="http://jabber.org/protocol/pubsub#event">
      <items node="generic/pgm-mp3-player">
        <purge/>
      </items>
    </event>
  </message>

Issue #3
--------

An editorial issue. Examples 58 and 62 are identical.

Issue #4
--------

What error should be returned when outcast users are trying to perform an
action?

What if the requestor is not the outcast user, but for example a service
administrator?

Issue #5
--------

Why not return forbidden when the requestor's JID doesn't match the jid
attribute in various actions (for example subscribe)?

Issue #6
--------

What to do when receiving an unsubscription request with a subid attribute,
when subids are not supported? Ignore or reply with for example bad-request?

Issue #7
--------

Section 8.1.8 (Unsubscribe from a Node) states:

  If the requestor is not an existing subscriber, the pubsub service MUST
  return a <not-authorized/> error.

This is odd. The jid attribute on the unsubscribe element should be
considered, not the requestor's JID (the from attribute on the iq). A
not-authorized (or forbidden, see #5) can be returned if the requestor
doesn't match the jid attribute, like in subscribing. Otherwise, if there
is not subscription for the jid, it might be appropriate to send an
unexpected-request error, along with a not-subscribed child in the
pubsub#error namespace.



That's it for now. Feel free to comment or, for the authors, alter the JEP-0060
text.

-- 
Groetjes,

Ralphm



More information about the Standards mailing list