[standards-jig] comments on JEP-0060
jabber at dsutton.legend.uk.com
Sat Jan 18 04:19:13 UTC 2003
On Sat, Jan 18, 2003 at 02:25:44AM +0100, Tijl Houtbeckers wrote:
> 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.
generic implies data encapsulation capable of different formats
depending on the situation at hand - x:data does that. By specifying a
standard, you're actually limiting how generic the data transfer is.
Just a thought.
> >> >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*?
note: in-band method I think you mean
> >> >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.
I'd just like to point out one little flaw with the whole 'lets make
everything so generic with different possibilities of configuration' -
how does a client know which method to use? Are you going to code every
possible in-band system into a client? (Note: OOB is not covered by the
JEP, nor should it be)
By fixing on one data encapsulation, you make it much easier to know how
to send the data. You are then only having to deal with which data is to
be send in-band.
> >> 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").
The statement that the usage in MUC is static is flawed - The x:data
fields given in the JEP are advisory - If an implementation wanted to
add/remove them, there is nothing to stop them from doing that.
Then again, all values have predefined default values, so basic
configuration can be done simply by sending an empty form.
> 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 :)
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
More information about the Standards