[Standards-JIG] Pubsub questions

Peter Saint-Andre stpeter at jabber.org
Thu Feb 2 17:31:34 UTC 2006

Hash: SHA1

Matt Tucker wrote:

> Many thanks for your answers to my previous pubsub questions. A few new
> ones after reading through the new pubsub version:

Good deal, questions are appreciated, since I take them as a sign that
people are implementing the spec. :-)

> 1) What's the difference between JID and entity and/or not authorized
> vs. prohibited in the following cases?
> "If the service does not support node creation, or the requesting JID
> does not have authorization to create nodes, the service MUST respond
> with a <feature-not-implemented/> error"

The latter case seems wrong to me. E.g., if the requesting entity is
blacklisted from creating nodes (a service-wide outcast), returning
forbidden seems right to me. So I think that text needs to be fixed.

BTW, the text may still be inconsistent on "JID" and "entity", but I
think "entity" is used in most places and I'll make that consistent by
usually changing "JID" to "entity".

> "If the requesting entity is prohibited from creating nodes, the service
> MUST respond with a <forbidden/> error"

Yes, that seems right to me.

> 2) Section "6.1 Subscribe to a Node" says:
> "The service MUST also send the last published item to the new
> subscriber (note that in this case the IQ-result is sent to the full JID
> whereas the message notification is sent to the bare JID that
> subscribed)"
> Question: does this also apply to nodes that are not using persistent
> published items? If yes, then nodes not using persistent published items
> should still always persist the last published item?

Yes, that is the intent and (I think) the consensus of the list, but
it's not set in stone yet and I want to make sure we all agree on it
before we move forward with version 1.8 of the JEP. See the proposed
text in the requirements:

"A service MUST cache the last item published to a node (even if that
node is not configured to persist items) and MUST send that item (or
notification thereof) to entities that subscribe to the node."

> 3) Users can subscribe to the Root Collection Node just like any other
> node. So, if the Root Collection Node is a special type of Node then is
> it also possible to configure the Root Collection Node? 

I don't see why not. E.g., a sysadmin might modify the rules for the
root collection node to send only notifications and not send payloads
(since sending payloads could get awfully expensive in terms of bandwidth).

> If yes, then how
> can we distinguish a "8.3 Request Default Configuration Options" from a
> "Get the root collection node configuration" request? 

Heh, that's a good catch. :-)

I'm not sure how to handle that yet.

If we continue to use <configure/> to retrieve the default config
options, then the only solutions I can think of involve special-casing
or hardcoded node names like "root" or "default".

Another option is to change the syntax for retrieving the default node
configuration options, to something like this:

<iq type='get'
    from='hamlet at denmark.lit/elsinore'
  <pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>

> What error should
> we return if an owner (i.e. a sysadmin) tries to delete the Root
> Collection Node?

I think <not-allowed/>. That is, no one is allowed to delete the root
collection node.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

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

More information about the Standards mailing list