[standards-jig] comments on JEP-0060
thoutbeckers at splendo.com
Sat Jan 18 14:42:53 UTC 2003
David Sutton <jabber at dsutton.legend.uk.com> wrote on 18-1-2003 5:19:13:
>On Sat, Jan 18, 2003 at 02:25:44AM +0100, Tijl Houtbeckers wrote:
>> 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 generic
>> 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.
x:data could be seen as a generic solution for some situations (espc.
after some effort is put into standardization for this). However is
simply does not cover all situations. Note that current usage in the
JEP is not generic at all. I think I've named enough situations where
something else as x:data could be required, usefull or wanted. What a
PubSub spec that does not make the usage of x:data required would reach
is that all those different PubSub implementations will be based on the
same common standard. (and can make use of the same additions to that
The JEP should be about Publish and Subscribe. The JEP does this. A
standard for Configuration of PubSub is also needed ofcourse, but I
don't see why it should be in the same JEP. If it is after all (fine,
I'll learn to live with it) I don't see any reason to make it mandatory.
If it is it's not a generic standard on PubSub.
>> 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
My reason for posting was that the JEP (as it is) is completly unclear
on the subject. I do think everyone agrees on that by now. The JEP does
state that configuration should be possible After this the creator of
the JEP made a statement, that all configuration MUST be done with
x:data. He later changed this to, if configuration is *available* it
MUST be done with x:data.
So Peter Millard proposes we stick with x:data and nothing else. Also
so far I've not heard him say he's in favor of a *mandatory*
standardization of var names in the forms, since configuration can be
Matthew Miller propesed that at minimum x:data should be supported but
that any other method is allowed too.
David Waite pointed out that thus far x:data is not ready for machine
entry since there is no good standard on it yet. He said he has gotten
push-back in the past when trying to establish one. Reading over what's
been said so far in this thread I think next time he tries he'll find
less oposition in his way :)
Ralph Meijer proprosed that we should use x:data for in-band only, and
that we agree on wich var names to use in them. (wether both points are
mandatory or a recommandation is not entirely clear).
Joe Hildebrand propesed that we change the proposed MUST of using
x:data to SHOULD, allowing out of band and alternate in band
Tijl Houtbeckers (hey that's me :) propesed that we cut this JEP in
half, one that focuses strictly on a common generic method for
publishing an subscribing, leaving configuration free for
implementation. And one JEP that documents an implemantion of this
using x:data, including (or maybe in another JEP even) a fixed set of
fieldnames etc. If it makes people happy, there can be a (strict)
recommendation to use x:data configuration for most cases in the first
JEP. Maybe the <configure/> field could be reserved even for it, though
I don't see a need for that since a seperate JEP for x:data config will
mean it has it's own namespace.
Tijl Houtbeckers also propesed that is this is not wanted because
people want this stuff in one big JEP that's possible. As long as it
still allows alternate methods. I'd prefer a strict recommendation to
use x:data, espc. in human<->machine communication within Jabber.
>> 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)
(Note: statements made imply that it does cover OOB).
You're looking at it mostly from a Desktop client prespective I think.
Well, A client would know wich methods are supported (ofcourse) by
using Disco. Clients that don't do Disco could just asume it does and
try, if not they'll get back an error. The only method clients will
have to support is x:data, since this what we'll be using on "public"
PubSub servers that people will have acces to. This won't change just
because you other methods are allowed. Ofcourse it does mean that if
one day we get something 10 times better then x:data for it and many
clients support it our PubSub servers can start supporting it too. I'd
be kind of stupid to rule that out wouldn't it?
Ofcourse, for human<->machine communication we don't have anything is
flexible and great like x:data we could use to configure PubSub. It's
great, I'm all for it. I think for machine<->machine communications
better things exist, and I could think of better ways, depending on
what use my pubsub would have. These PubSub servers might not have a
need for desktop clients to configure them at all. Maybe I want to use
something different like XML-RPC. Maybe I want to use real XML so I can
use XLST. Maybe I want to send stockquotes as configuration data.
Would any desktop client have to support those? Ofcourse not.
Since when did *choice* become a bad thing in open standards?
Keep in mind, even though I don't use x:data as configuration method
any desktop client that implements JEP-0060 could still use it, just
>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.
Again again again, I definatly think there should be a decent x:data
way of doing this. I'm against making it mandatory, and very against
actively suppresing other methods. If others want to do that, well
there is nothing I can do, but I think calling it "generic" is a bit
> 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.
I'm not really talking about the JEP, much more about your component.
Joe's program to automatically create channels works cause your client
is in line with those advisory fields. If anyone changes them his
program will break.
I think Peter Millard choose to use x:data because of it's flexibility
and because desktop clients support (answering) them. Cause at the time
the JEP is being written (now) it's very hard to tell wich different
configuration options will be used. When a human fills in those forms
that's not a problem. It solves the problem for Desktop clients.
When you take it out of this prespective, and put it in the machine<-
>machine prespective this is not valid anymore. The only way (till we
>have that super AI) to fix this is to "strcmp". However this takes
>away most of the reasons we choose for x:data in the first place. In
>fact, in some cases it's valid to make the choice to do this
>different, after all x:data is not as flexible as XML in all cases.
>Then again, all values have predefined default values, so basic
>configuration can be done simply by sending an empty form.
Sure you can do this.. I'll probably do it myself in a lot of cases.
Doesn't mean I think other options should be forbidden.
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards