[standards-jig] comments on JEP-0060

Tijl Houtbeckers thoutbeckers at splendo.com
Sat Jan 18 01:25:44 UTC 2003

Joe Hildebrand <JHildebrand at jabber.com> wrote on 18-1-2003 2:24:33:
>/me gets caught up in the burgeoning flame war.
>sorry in advance...
>> > Like JoeH said, if we establish a standard for naming var's in 
>> > these xdata forms, then it's completely machine readable. 
>> So at least you admit there is no such standard. (1)
>JEP-0053 is at least a beginning.  Please comment on your 
>of its inadequacies in a separate thread, but suggesting that there 
>*no* standard is a little... disingenuous.

If PGM says there should be a standard established I'm willing to 
his word on it :) I think such a thing should definatly be in the 
of JANA. Anyway all I said it's not in the JEP (JEP-0060 that is) 
it wasn't when I read it, and it wasn't when PGM replied to me. 

>> >In addition, do you 
>> >forsee components or other automated process which set specific 
>> >configuration options for a node, or do they just request instant 
>> >nodes, etc... Please present me with some use-cases and I'll 
>> be happy 
>> >to take them as input into the design process of this 
>> protocol (which 
>> >everyone wants). 
>> In my opinion how this is done is a choice that should be 
>> made entirely 
>> by whoever builds a pubsub component. I don't care if it's 
>> classic jabber messenger based, if it comes from a groupchat room, 
>> if it uses some kind of XML or an x:data form or tiny litte nano 
>> magnets. 
>> A truly generic spec. will allow all of those. 
>That last bit doesn't make any sense to me.  How does having no 
>standard for configuration make the configuration more computer-

I'm not saying there should be no standard defined. I'm *not* against 
having an x:data standard for this. I just don't want it in the 
protocol.. because it's not generic enough. 

>> >There is no requirment that says that 
>> >your pubsub impl MUST "communicate" with humans. 
>> As long as there is no standard or specifaction(see 1)(see 2) I'm 
>> communicating either with humans when I use x:data forms or one 
>> f*ing clever AI. 
>Or a programmer who has looked at the form that an implementation 
>uses, and applies a little bit of string-matching logic, and holds a 
>club over the head of the server implementor not to change the 

Wich would go against PGM's statement that it could be anything.
>Or there's a document that the implementor uses as a contract with 
>users of that service.  I've written lots of programs that know how 
>fill out HTML forms on the web.  I didn't have to write an AI to do 
> I just needed to know what fields that particular form was 

And you seriously want to take this behaviour to Jabber *and prevent 
other methods from being used*? 

>> >The requirement is 
>> >that a node be configurable (discussed above), and that 
>> configuration 
>> >must use the x-data protocol so that it can be presented to 
>> >when desirable to do so. 
>> Wich is exactly what x:data was once meant for. Wich is great, and 
>> it works great. If I want to communicate with humans. If I don't 
>> want to communicate with humans (or in a way that does not involve 
>> x:data, eg for client that don't support it) I have no need for 
>> x:data do I? 
>No, but you need a generic protocol for specifying which name/value 
>pairs you need filled out.  You might want some type information for 
>redundancy (ala XMLRPC).

Good point, imagine an implementation that wants to use XMLRPC or 
instead of (static) x:data. 

>I bet by the time you are done defining that protocol, it will look
>suspiciously like x:data.

At some point I can imagine the requirments would need something like 
x:data could do. I might go with an x:data solution, I might go with 
something else. I honestly hope that I can convince you and PGM that 
x:data is not the right solution for all situation. I think it's 
narrowminded to rule out the use of any other solution. 

>Now, sometimes users *will* want to be able to configure a node 
>manually. In that case, you'll have to create a way of prompting a 
>user for the data also.

I'm sure you can find enough usecases where x:data is handy. So can 
I'm not attacking x:data here. I'm attackting the fact that x:data 
shows up in a generic solution, while it's not generic enough. 

>> *sighs* I guess I have to keep saying this over and over. I'm NOT 
>> opposed to using x:data with PubSub. In fact, it's brilliant! For 
>> *some* uses of PubSub. I've never said anywhere that humans 
>> don't need 
>> pubsub. I've never said you can't write a JEP on using x:data with 
>> PubSub. In fact I've even suggested it! Where are you getting 
>> all this 
>> from? I hope it doesn't have to do with your own remark above. 
>No, but you are saying that you don't think *this* jep should 

I said that I think it's better of in a seperate JEP, and I very 
clearly stated there is a great need for an x:data solution. I also 
suggested that, though I think a seperate JEP would be much better, 
can in the same JEP. As long as the ridicoules requirment and ruling 
other solutions is not in the JEP anymore. 

>I thought that PGM's offer to include this language should have
>been good enough:
>* Any node configuration available MUST be done using the x-data 
>protocol. What this means is that in some cases of pubsub, a node 
>not have any configuration. In those cases, the server MUST respond 
>the iq-get for the config form with an error-501: Not Implemented.
>but I didn't see any comment from you on that.

Because what he should change first then is that every node should be 
able to be configured. Apart from that it's still saying the same 
thing, either you get x:data or you get nothing, still not even out 
band configuration! 

>What about changing 
>MUST to SHOULD?  Would that be acceptable to you?  
>Then you could 
>configure the nodes with whatever protocol you want, 

This is all I'm asking basically.. that last sentence (!)

>but people that 
>want to interoperate can still do so.

So I'd be absolutly willing to settle for this.. since this is all 
asking for all the time. I'm only worried your usage of the word 
is not really in line with the RFC usage. It's not there to allow 
exceptions to a rule in this sort of way I think. MAY sounds better 
I think it could be solved in a better way, if we all agree that 
methods should be allowed. 

>> Ok, at least admit:
>> That (considering the current state of x:data amongst other 
>> making x:data the mandatory means of configurating nodes make the 
>> JEP as it currently is too horribly flawed to be called generic 
>> PubSub. 
>What "current state"?  It is a Final JEP.  It works.  It's been 
>implemented in lots of places.

I wasn't talking about x:data but about JEP-0060. Again: people seem 
think I have a thing against x:data, I don't :). What I meant was, 
*also* considering that x:data is not *yet* standardized in a decent 
way for "machine-reading", and there is nothing in the JEP to make 
more possible,  and all the other problems I have pointed out in this 
JEP, at least admit that the JEP-0060 as it is, it too flawed to be 
called "generic PubSub". 

I can see it might not have been entirely clear I meant JEP-0060, 
combined with the horrible grammar, my apologies for that. 

>Other JEPs already depend on it (MUC).  
>Implementations of MUC exist, and it works fine for that as well.  
>I've even written code that knows how to process x:data forms 
>human intervention in order to create/configure MUC rooms, so I know 
>it is possible. 

This is only possible because the usage in MUC is static. As PGM has 
been saying from the start, for JEP-0060 the reason x:data has been 
choosen is because the configuration can be anything ("I want this 
to show what are POSSIBLE configuration options for pubsub nodes"). 

Even if there would be a fixed subset, I still I think it's a bit of 
hack (having all those designed to be human readable forms flying 
and forth to a dumb bot who doesn't need it anyway). That's not my 
biggest problem with it though. 

>I take offense at "horribly flawed" without any suggestions for 
>improvement. I'll assume that you meant something a little less 
>inflamatory, until I see concrete examples of how x:data could be 

But I like x:data :) (for human-machine interaction anyway)

>And, it would have been nice to see those comments during 
>the previous JEP process. 

I'll be keeping an eye out if there's gonna be a clear 
definition/standardization for using x:data in machine<->machine 
interaction. But I think most of it shall be duplicating what already 
exists in XML. I don't see the difference for a machine to parse an 
x:data form or XML, except that XML has a lot more possibilities (and 

>> That the JEP cleary states "A node owner must be able to configure 
>> node." 

(here you can see I talk about JEP-0060 not x:data)

>>and that you've clearly stated "Nodes MUST be 
>> configured using x-
>> data". (Ofcourse you've toned this down a little now). 
>> That this means you've basically said: if you make an 
>> that does not use x:data to configure nodes you do not use 
>> JEP-0060 for 
>> your PubSub. 
>particularly if you ignore PGM's potential compromise, it says that.

PGM's "compromise" clearly states MUST. The only way to not use 
is use no configuration at all. Hardly a compromise. 

If PGM agrees with me (and you?) that other methods should be allowed 
we could turn it into a "SHOULD" or preferably "MAY". If we agree on 
this however, I'd like to hear some argument though for not splitting 
it into two JEPS, it would be a lot clearer. 

You'd have JEP-0060, generic PubSub, the basis of all PubSub 
implementations. You'd have JEP-0070, an extention that uses x:data 
configure PubSub. (optionally) You'd have JEP-0071, an 
extention/alternative to JEP-0070 that uses a fixed set of x:data 
(standerdized by JANA), so machine<->machine communication is 

These first two is what most clients and PubSub would implement, and 
lot would also implement 71 to allow automation of tasks. 

Maybe then someone decides to make JEP-0073, to allow older clients 
do some of this with normal messages. Meanwhile I write an automated 
PubSub system that exposes an XML-RPC interface on the Jabber 
and release informational JEP-0076 on it. DeveloperX comes along and 
adds support for XHTML forms cause his neato client supports that, 
releases JEP-0078. 

Then someone comes up with JEP-0080, a generic extentsion to JEP-0060 
to allow presence based publishing, JEP-0070 client are not broken 
since they can change the x:data forms at will, JEP-0071 needs to be 
updated a bit to take advantage of this. 

To me it sounds like everyone could be happy with this. Ofcourse you 
could role 60,70 and 71 into one JEP and only allow 73, 76 and 78 
through a questionable exception of the rules as suggested, and make 
a lot harder for 80. I know wich one I prefer though :) 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list