[Standards] publish+configure again
stpeter at jabber.org
Thu Mar 29 19:17:07 UTC 2007
As promised in yesterday's XMPP Council meeting, here is a summary of
the discussion we had about pubsub/PEP, specifically the desire for an
atomic publish-and-configure action in the context of automatic node
creation for PEP (XEP-0163). In fact this email was supposed to be an
objective summary, but it has turned out to be include my opinions on
where we go from here (read the room logs and list archives for
context). So much for my reputation as a neutral third party. :)
First, some history.
When we re-defined PEP at the devcon last July, we specified that the
PEP service must automatically create the node if it does not exist when
a client attempts to publish to that node.
See last paragraph in the following list message:
The question was naturally raised: what if you want to configure the
node when it is auto-created? The answer at the time was "if you want
something other than the default node configuration, you need to go
through the regular node creation sequence". That's what XEP-0163
"When an account owner attempts to publish an item to a PEP node and
that node does not already exist, the PEP service MUST automatically
create the node with default configuration. However, if the account
owner wishes to create a node with a configuration other than the
default (e.g., a node with an access model of "open", "roster", or
"whitelist"), the account owner MUST follow the node creation protocol
specified in XEP-0060."
More recently, a number of developers have suggested that it would be
quite helpful to support an atomic publish+configure action in PEP.
Among other things, this would enable a "fire-and-forget" model that is
similar to how jabber:iq:private works today, so that client developers
could easily rip out support for iq:private and replace it with PEP
publish+configure to a whitelist node.
We have discussed this at length recently on the list and in the last
two Council meetings:
So far we do not have unanimity on the issue. I think we may have rough
consensus. This message is intended to clearly lay out the issues so
that we can break the impasse and move forward.
As I posted before, I see two options:
1. Get rid of auto-create-on-publish. If the node does not exist on
publish, the server shall return a not-found error, forcing the client
to go through the full node-creation sequence.
2. Support configuration-with-auto-create-on-publish (also called
publish+configure or p+c). If the node does not exist on publish, the
server shall create the node and apply the specified configuration.
I don't see a third option, because it seems to me that auto-create
without the ability to apply the desired configuration is an untenable
We had consensus to include auto-create in version 0.13 of the PEP spec
And that feature was approved by the Council when XEP-0163 was advanced
to Draft on September 20 of last year.
So I don't see how we can try to remove that feature now. Well, we could
try, but the number of -1 votes that would materialize in the Council
make that a non-starter.
Thus I think we need to look seriously at publish+configure. Many
(perhaps even most) developers want the feature. I am not saying that
developers are omniscient (we all know I'm not!), but we are a
developer-driven standards organization so if many or most of the
developers in our community want a feature then we need to consider it.
And maybe the wisdom of crowds should be telling us something...
The desire for publish+configure seems to be driven by several factors:
1. It would make client development simpler (no complex error cases to
handle with multiple requests and responses). See Rule #2 in XEP-0134.
This is a good thing.
2. In particular, it would enable publish+configure to be a drop-in
replacement for jabber:iq:private (XEP-0049). Since we have wanted to
get rid of iq:private for a long time, this is also a good thing.
3. It would provide an atomic action that avoids certain race conditions
that can arise if publish leads to auto-create without configuration.
And the main objections to publish+configure seem to be:
1. It's harder for servers to implement (requires special-casing logic
for p+c requests). But see Rule #2 in XEP-0134.
2. The error handling is not well-defined. For instance, what if there
is an error in both the publish and the configure parts?
3. Clients will send publish+configure every time, so the protocol will
be more verbose. That's not good for mobile devices or general bandwidth
usage. Plain auto-create does not add protocol, but p+c does.
Here is my take:
1. According to our protocol design guidelines (XEP-0134), simplifying
client development is a good thing. We don't simplify client development
(or complicate server development) beyond necessity, but if push comes
to shove we err in favor of simple clients. This is a factor in favor of
2. The server logic is not necessarily more complex if a server chooses
not to support auto-create and publish-and-configure (no one is forcing
a pubsub implementation to be a PEP implementation). We need to define
pubsub service discovery features for these (see Section 10 of XEP-0060)
so that servers can advertise whether they support these features
(support can also be implicit if the service has a service discovery
identity of "pubsub/pep"). So if a pubsub server doesn't support those
features, it can simply return errors in response to a publish request
if the node does not exist (<item-not-found/>) or if the publish request
contains configuration (<bad-request/>). But yes a PEP server would need
to do some special casing. Life is harder for server developers.
3. It is true that the error handling is not well-defined in relation to
publish+configure. So let's define it.
4. The ability for client developers to easily replace (a) IQ-set via
iq:private with (b) PEP publish to a whitelist node is very attractive.
5. Avoidance of race conditions through an atomic publish+configure
action is a good thing.
6. The typical publish request may become more verbose in PEP use cases
(especially if clients always do publish+configure, which is not
necessary but they probably will to be safe, unless they care deeply
about packet size). However, it is not clear that publish+configure is
more verbose than requesting and receiving the node configuration from
the service (and potentially checking the default configuration).
Whether the total bandwidth used is more verbose may depend on a number
of factors, including session length. But if the session is long then
the client may want to receive notification of updated node config,
which is also verbose. So this objection seems like a wash to me, or at
least not deeply compelling. (Also, I would note that since a pubsub
service is a reflector (one publish results in many notifications), it
would be more valuable to slim down the notify side than to worry too
much about the publish side -- and pubsub notifications are pretty verbose!)
7. Acceptance of publish+configure will most likely lead to significant
adoption of PEP, which is one of the items on our roadmap for 2007 (and
it's on the roadmap because we all want to stop overloading presence
with things like mood and tune). We like to achieve goals that are
listed on our roadmap. :) If at the same time we can deprecate
iq:private, then we've got two for one. (I think we need a separate spec
that describes how to do iq:private functionality via PEP to a whitelist
Am I missing anything?
IMHO we have rough consensus to accept the publish+configure in PEP
(XEP-0163) as a logical extension of the existing auto-create feature.
We need to define these features more carefully, including pubsub
service discovery <feature/> vars and error handling. We need to clearly
specify the costs, benefits, and hazards of publish+configure. We need
to write some implementation notes about the server-side special casing
logic. We need to write a XEP that shows how to replace iq:private with
PEP. But that's just spec work, and I can commit to defining that in a
proposed 1.1 version of XEP-0163, which the Council can officially
consider in a future meeting (probably in 2 or 4 weeks).
Rough consensus is good. Some running code would be even better so that
we could test this out and see what some of the issues might be. Perhaps
we can get at least one client and server developer to commit to coding
this into their PEP implementations for experimentation? That would be
quite helpful when the Council decides to vote on version 1.1.
Please note: the Council does not have anything to vote on yet because I
need to provisionaly modify XEP-0163 as outlined above. Once I do that
(I will commit to finishing a first pass next week), we can have a more
detailed discussion. However, feedback on this topic is welcome here on
the list even before the document is updated so that we can determine if
we really do have rough consensus.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards