[Standards-JIG] Pubsub questions
stpeter at jabber.org
Thu Feb 2 17:31:34 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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:
from='hamlet at denmark.lit/elsinore'
> 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
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards