[Standards] publish+configure again

[Peter Saint-Andre]

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:

http://mail.jabber.org/pipermail/standards/2006-August/011864.html

And:

http://mail.jabber.org/pipermail/standards/2006-August/011867.html

Etc.

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 
currently says:

"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:

http://www.jabber.org/muc-logs/council@conference.jabber.org/2007-03-14.html#13:17:28

http://www.jabber.org/muc-logs/council@conference.jabber.org/2007-03-28.html#12:27:29

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 
middle ground.

We had consensus to include auto-create in version 0.13 of the PEP spec 
last August:

http://www.xmpp.org/extensions/attic/jep-0163-0.13.html

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 
publish+configure.

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

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.

Thanks.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070329/ce783c3d/smime-0001.bin